octovision Vulnerability Management: CVE Matching and OT Risk Priority

octovision vulnerability management matches known vulnerabilities (CVEs) against the exact firmware and software versions that octoplant reads from each device, then helps a team decide which ones matter. AMDT describes it as CVE matching against trusted asset data with “risk prioritization” so teams focus on the vulnerabilities that matter most, and octoplant.com lists vulnerability management “with asset context” among its functional areas. This page explains the mechanism, the criticality model added in 2026, how false positives are handled, and how to turn a ranked list into decisions that suit a plant where patching means downtime.

It belongs to the octovision overview in the AMDT cluster.

How octovision vulnerability management matches CVEs

The input is the version read from the device. octoplant’s backup jobs record vendor, type, firmware and software versions. octovision compares those against published CVE data. Because the version comes from the configuration rather than from traffic fingerprinting, the match starts from a stronger fact: a PLC on firmware 32.011 is matched as 32.011, not as “probably 32.x”.

The CVE data updates itself. The Summer Release 2026 added automatic server-side CVE updates. That matters more than it sounds. A new advisory published on Thursday is matched against the whole inventory without anyone importing a feed, so the question “are we affected?” has an answer before the Monday meeting.

The score starts with CVSS. CVSS measures how severe a vulnerability is in the abstract. It knows nothing about whether the affected controller runs a palletiser or a reactor’s safety interlock. That is the gap the criticality model fills.

Criticality: adding asset context to CVSS

The Summer Release 2026 introduced criticality classification across three dimensions, in AMDT’s words “process criticality, need for protection and safety classification”:

• Process criticality. What stops if this device stops? A bottleneck filler and a spare labeller do not carry the same weight.
• Need for protection. How exposed is the asset and how sensitive is what it holds? A controller reachable from the plant network differs from one on an isolated skid.
• Safety. Does the device take part in a safety function? Any change to it carries a different validation burden.

This is the step that makes the list usable. A plant with 2,000 matched CVEs cannot act on all of them. A plant that can say “these 40 sit on process-critical, safety-relevant assets reachable from level 3” has a work plan.

An illustrative case. Two identical controllers carry the same high-severity CVE. One runs a case erector on a line with a spare machine beside it, behind a firewall rule that allows only the engineering workstation. The other runs the clean-in-place sequence for a filler, shares a flat network with the office floor and sits inside a safety-relevant interlock chain. CVSS scores them the same. Criticality puts the second one at the top of the list and the first one into a quarterly review, which is the order any experienced controls engineer would have chosen by hand. The tool’s job is to make that judgement repeatable across thousands of assets and several sites.

The same idea underpins ServiceNow’s OT Vulnerability Response, which ranks by the criticality of the process a device controls.

Exploitation signals: what CVSS and criticality leave out

CVSS describes how bad a vulnerability could be, and criticality describes how much the asset matters. Neither says whether anyone is actually exploiting it. Two free public sources answer that, and they belong in any OT prioritisation method:

Signal	Publisher	What it tells you	How to use it in OT
CVSS base score (v4.0 specification)	FIRST	Technical severity of the vulnerability, in the abstract	The starting point, never the ranking on its own
Known Exploited Vulnerabilities (KEV catalog)	CISA	That a CVE has been exploited in the wild	A KEV entry on a reachable, critical asset goes to the top of the queue
EPSS (Exploit Prediction Scoring System)	FIRST	A daily probability that a CVE will be exploited in the next 30 days	Separates the few likely-to-be-used CVEs from the long tail
ICS advisories (CISA ICS advisories)	CISA, with vendors	Affected versions and the vendor’s mitigation, often including network measures when no patch exists	The source for compensating controls

AMDT’s public material does not mention KEV or EPSS as of October 2026, including the Summer Release 2026 notes. Ask whether octovision uses them. If it does not, the export described under OTSSM and integrations lets a security team join them in its own tooling, and the combination of version-exact matching, criticality and exploitation evidence is a stronger ranking than any one of them.

False positives and AI guidance

False-positive management lets a team mark a CVE as not applicable to a specific asset, so it “no longer resurfaces for review”. Typical reasons: the vulnerable service is disabled, the affected module is not installed, or the CVE applies only to a hardware variant the plant does not run. Without this, every weekly review re-litigates the same findings and the team stops reading the list.

AI-supported guidance turns a finding into suggested next steps based on best practices, and AMDT states it can run on-premises. Treat it as a first draft for the engineer, not a decision. The AI Companion page covers the governance questions.

A prioritisation workflow for octovision vulnerability management

1. Confirm coverage. Check octoplant job status for the affected sites. A stale version gives a stale match.
2. Classify criticality once, properly. Engineering, maintenance and safety should agree the three classes per asset. Revisit them when the process changes.
3. Triage new matches weekly. Mark false positives with a written reason.
4. Rank by CVSS combined with criticality, and by exposure: is the device reachable from outside its zone?
5. Pick a response for each top item: patch, compensate or accept (table below).
6. Plan patches as changes. Take an octoplant backup, schedule the window, apply, then compare against the approved version.
7. Record the decision and the evidence, so the next audit sees reasoning, not just a status.

Measure the process, not just the backlog. Useful numbers for a monthly review: the time from CVE publication to a triage decision, the share of top-ranked items with a decision recorded, and the count of critical assets with no compensating control. A falling raw CVE count can simply mean nobody imported last quarter’s assets.

Why patching in OT is different

In IT, the default response to a critical CVE is to patch within days. In OT that default fails for concrete reasons: firmware updates often need a controller stop, may require a matching engineering software version, can change behaviour that was validated, and in regulated plants may trigger revalidation. Many controllers run for 15 or 20 years, and some vulnerabilities will never get a patch.

So the real control is often the network. Segmentation, tight conduits between zones and restricted engineering access reduce exposure for the devices you cannot patch this year. Our guide to OT network segmentation in brownfield plants covers how to do that without a rebuild, and an OT network assessment establishes what exposure actually exists.

Response options: patch, compensate or accept

Response	When it fits	What it costs the plant	Evidence to keep
Patch	A fix exists, the asset is reachable or critical, and a window is available	Downtime, testing, possible revalidation	Backup before, compare after, change record
Compensate	No patch, or no window soon; exposure can be reduced	Network or access changes, monitoring	The control applied and who verified it
Accept	Low exposure and low criticality, or retirement is near	Residual risk, reviewed periodically	Reasoned acceptance with an owner and a review date

Where the honest answer is “this hardware will never be fixed”, the decision moves from vulnerability management to lifecycle and obsolescence planning.

How it compares

Vulnerability management from configuration data is becoming a crowded idea. Software Defined Automation announced integrated PLC vulnerability management at Automate 2026. Siemens offers SINEC Security Guard for vulnerability management on its own estate, and announced in October 2024 that its output would flow into ServiceNow workflows. Claroty supplies vulnerability data that enriches Rockwell’s FactoryTalk AssetCentre, and Industrial Defender pairs vulnerabilities with configuration baselines in utilities. octovision’s distinguishing point is multi-vendor version data taken from the same system that can back up and restore the device.

Where it gets hard

• Version to CVE mapping is messy. Vendors name firmware inconsistently, and advisories often describe ranges. Ask how ambiguous matches are shown.
• Criticality needs people. The classes are only as good as the cross-functional agreement behind them, and that meeting is the hard part.
• Unmanaged assets match on whatever the CSV says. Imported rows inherit the quality of their source.
• A ranked list is not remediation. Without change windows and an owner, the queue only grows. Plants that succeed tie the queue to the maintenance schedule.

---

Related: octovision overview · octovision Asset Inventory · Change detection · NIS2 and IEC 62443 · AMDT hub