Skip to content
CONFIGLANE
Enquire

OT Security · Operations

Cyber Vision as a data source: OT visibility that keeps working

In many companies OT monitoring ends up as a second dashboard: introduced, admired, and after three months only opened when something is on fire. Yet Cisco Cyber Vision is explicitly built as a data source — with a REST API that carries the visibility to where the work happens.

By ConfiglanePublished 5 min readOT Security

The short version

  • According to Cisco's documentation, Cyber Vision provides visibility on all assets in the industrial network including profiles and communication patterns, plus vulnerabilities, risk scores and anomalies.
  • Segmentation is designed in: assets are grouped into zones, and that information is shared with Cisco Secure Firewall or Cisco ISE for enforcement.
  • The Classic API (version 5.5) is a REST API under https://<Center>/api/3.0/ with token authentication; it covers active discovery, activities, sensors, devices, baselines and components.
  • The underrated area is baselines: deviations and discrepancies can be retrieved — “nothing ever changes in OT” becomes a checkable statement.

There is a reliable test of whether a monitoring system carries its weight: who looks at it when nothing is on fire? For the second dashboard in the building, the honest answer is often: nobody. That is not a tooling problem but a connection problem — the visibility stays stuck in a screen instead of landing in the systems where work already happens: the ticket, the firewall policy, the evidence folder.

Cisco Cyber Vision is built for the other path. The documentation describes the platform as continuous visibility into the OT security posture: all assets in the industrial network with detailed profiles and communication patterns, plus vulnerabilities, risk scores, intrusions and abnormal behaviour. And it states the decisive sentence right there: assets are grouped into zones, and that information is shared with Cisco Secure Firewall or Cisco ISE for enforcement.

The API behind it: sober, complete, reachable

Technically, access is unspectacular — and that is the good news. The Classic API (version 5.5) is a REST API; every request starts with your own center's base URL under /api/3.0/, authentication is via API token, and requests can be tested directly in the center. No extra gateway, no cloud dependency for data access.

AreaWhat can be queried and managed
Active discoveryCreate and maintain discovery profiles, start and stop scans, fetch results and status
ActivitiesCommunication between endpoints including flows and tags — the basis of any communication matrix
SensorsSensor lists, settings, statistics and packaging files for deployment
DevicesDevice details including vulnerabilities, risk scores and external communications
BaselinesCreate reference states, retrieve and review deviations and discrepancies
ComponentsComponent details, vulnerabilities and variables for analysis
The functional areas of the Classic API (version 5.5)

Three connections that carry their weight

What do you do with this data? Three uses have proven to be the ones that hold — each takes the visibility out of the screen:

  • Enforce zones instead of admiring them. The zone grouping goes to ISE or Secure Firewall — the observed communication matrix becomes lived segmentation. What segmentation has to prove as evidence is covered in NIS2 network segmentation.
  • Baseline deviations into the reporting path. Whoever has to receive and triage manufacturer reports under the CRA from 11 September 2026 needs their own current state on tap — the piece on the CRA reporting obligation describes the receiving side.
  • Inventory and risk scores as evidence. Asset list, vulnerability posture and external communications per device are exactly the artefacts auditors and insurers ask for first — queryable instead of compiled by hand.

Division of labour with the automation chain

In our way of working, Cyber Vision does not replace a source of truth — it is the actual-state view of the OT that sits next to the intent instance: NetBox holds what should be true; Cyber Vision observes what actually talks. The pairing is the same as in the IT network, just with a different sensor — described in NetBox as the source of truth. How we introduce Cyber Vision and hand it over to operations is on the OT security service page.

The way in is deliberately unspectacular: start read-only. Query inventory, activities and risk scores and put them where the team already works. Controlling calls — discovery profiles, baselines — come only once the reading side is understood. That is how the second dashboard becomes a data source that keeps working when nobody is looking.

Sources

Every evidenced claim in this article can be traced here. The retrieval date shows how fresh the check is.

  1. Introduction — Cisco Cyber Vision 5.5, Classic APIopens in a new tab

    Cisco DevNet · retrieved 27 August 2026

  2. Getting Started — Cisco Cyber Vision 5.5, Classic API (base URL, API token)opens in a new tab

    Cisco DevNet · retrieved 27 August 2026

FAQ

Frequently asked questions about the Cyber Vision API

Does Cyber Vision replace a firewall or ISE?

No — it feeds them. Cyber Vision groups assets into zones and, according to Cisco's documentation, shares that information with Cisco Secure Firewall or Cisco ISE for enforcement. Visibility comes from Cyber Vision; enforcement stays with the enforcement points.

What does the API add over the dashboard?

The dashboard answers questions when somebody asks. The API works unattended: zones flow into segmentation, baseline deviations into the reporting path, inventory and risk scores into evidence and tickets. Visibility nobody has to fetch is the only kind that holds up in daily operations.

Does this help with NIS2 and CRA evidence?

Yes, in two places: the documented communication matrix and the zones prove segmentation as an observed state, not an intention. And the queryable inventory with its vulnerability posture is the receiving side for manufacturer reports — without your own current state, no report can be triaged.

Classic API or New UI API?

Cisco splits by interface: the Classic API (version 5.5) manages the data of the classic UI, and the new UI has its own New UI API. For integrations, what counts is which data world they attach to — that choice belongs at the start of the integration effort, not at the end.

Where do you start?

With purely read-only queries: device list, activities, risk scores — with a token against your own center's base URL. Once this data lands where the team works, the value is proven; only then come controlling calls such as discovery profiles or baseline maintenance.

Read next

Network Automation

Ansible on IOS XE: changes you can read before they runMerged, replaced, overridden: how resource modules turn commands into state, why no run starts without a dry run and a diff — and which states run without any device at all.

Network Automation

NetBox as the source of truth: the intended state comes firstAutomation needs one instance that says what should be true. Why NetBox holds the intended state instead of importing the live one, the order to fill it, and the handover to Ansible.

Related service

OT SecurityVisibility and segmentation for production networks — with Cisco Cyber Vision
CONFIGLANEOT Security · Operations

OT Security

OT assessment. Understand first, then protect deliberately.

A production network cannot be assessed responsibly from a device list alone. We map assets, communication relationships and operational boundaries, optionally using Cisco Cyber Vision, and turn visibility into prioritised next steps.

Discuss an OT assessment

Assessment → first dependable change