Industrial control system advisories arrive faster than plants can patch, and most OT teams have no repeatable way to decide which ones matter. CISA, national CERTs and automation suppliers publish a steady flow of ICS advisories, many with high CVSS scores, few with patches that can be installed this month, and almost none that say how exposed your particular site is. This guide sets out a triage process built for OT: collecting advisories in CSAF, matching them to an inventory with exact versions, deciding with SSVC adapted for safety and exposure, choosing between vendor fixes and compensating controls, and measuring the result. It is for OT security leads, vulnerability analysts supporting plants and product security contacts at asset owners. It builds on the general Vulnerability Management Guide and does not repeat it.
Key takeaways
- Automate intake with CSAF. CISA and major suppliers publish machine-readable CSAF 2.0 advisories, which lets you match products and versions without reading every PDF.
- Exposure decides most OT priorities. The same flaw is urgent on an internet-reachable gateway and tolerable on a controller behind two conduits; record exposure per asset, not per product.
- Use SSVC, not CVSS alone. SSVC decision points such as Exploitation, Automatable, System Exposure and Public Well-being Impact fit safety-critical environments better than a single score.
- The answer is often a mitigation. CSAF remediations include vendor_fix, mitigation, workaround, no_fix_planned and none_available; plan for all five, not just patches.
- Close the loop with evidence. Every applicable advisory needs a decision, an owner, a control and a review date, and the metrics should show time to decision as well as time to fix.
Why OT vulnerability management needs its own process
- Scanning is limited: active scanners can disrupt older controllers and network stacks, so OT relies more on passive network monitoring, configuration exports and supplier data. See the Safe Active Scanning and Testing in OT Guide.
- CPE matching is weak: ICS products are often missing from or poorly described in CPE data, and firmware versions in advisories use the supplier's own scheme. Matching has to use supplier product names, order numbers and versions.
- Fixes are slow: firmware updates wait for outages and supplier qualification, so most advisories end in mitigation for months. See the OT Patch Management Guide.
- Impact is physical: the consequence of exploitation is loss of view, loss of control or a safety event, which generic IT scoring does not capture.
- Advisories assume a hardened deployment: CISA ICS advisories commonly repeat the same recommended practices (minimise network exposure, keep control systems behind firewalls, use secure remote access). If those are not in place, the risk of every advisory goes up.
Advisory sources and how to collect them
| Source | What it provides | Machine-readable | Notes |
|---|---|---|---|
| CISA ICS advisories (ICSA) and medical advisories (ICSMA) | Coordinated advisories for many suppliers, CVSS scores, mitigations | CSAF 2.0 in the cisagov/CSAF repository | CISA also republishes partner supplier CSAFs, keeping their original dates and revision history |
| Supplier PSIRTs (for example Siemens ProductCERT) | First-party advisories, affected order numbers and versions, fix availability | Many publish CSAF; Siemens ProductCERT declares the csaf_trusted_provider role with a ROLIE feed | Usually the most precise version data; subscribe for every supplier in your inventory |
| CISA KEV catalogue | Confirmed exploitation in the wild | JSON and CSV | Few ICS entries, so absence from KEV is weak evidence of safety. See the CISA KEV Catalogue Guide |
| National CERTs and sector ISACs | Regional advisories, sector context, threat reporting | Varies | Useful for exploitation context and sector targeting |
| Integrator and service provider notices | Impact on the systems they built | Rarely | Require notification in contracts. See the OT Product Procurement Guide |
Collect CSAF properly: CSAF 2.0 is an OASIS Standard (18 November 2022). Providers publish a provider-metadata.json file, discoverable through a well-known URL, security.txt or DNS, which points to ROLIE feeds or directory listings and to the OpenPGP keys used to sign documents. Pull from those feeds, verify signatures and integrity files, and store each document with its revision history so that updated advisories trigger re-triage. For format detail see the CSAF Security Advisories Guide.
Matching advisories to your assets
An advisory is only actionable once you know which installed assets it touches. In CSAF the product_tree lists vendor, product name and version branches (including version ranges), and each vulnerability carries product_status lists such as known_affected, known_not_affected, fixed, first_fixed, last_affected, recommended and under_investigation.
- Normalise the inventory: supplier, product family, order or part number, hardware revision, firmware version and installed software modules for every asset. See the OT Asset Visibility Guide.
- Map supplier identifiers: use the CSAF
product_identification_helperwhere present (CPE, PURL, model or serial numbers, SBOM URLs) and maintain your own mapping table for the rest. - Match automatically, review by hand: auto-match on product and version range, then have an OT engineer confirm the hits and the near misses (similar order numbers, modules installed in a rack).
- Record not affected with a reason: CSAF VEX profiles carry justifications such as component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary and inline_mitigations_already_exist. Keep the same reasoning for your own not-affected decisions. See the VEX Guide.
- Attach context per asset: Purdue level, zone, reachable conduits, internet exposure, safety function and redundancy.
Reading an ICS advisory: what to extract
Whether it arrives as CSAF or as a web page, an ICS advisory carries the same handful of facts. Extract them into the triage record once, so that later decisions do not depend on rereading the text.
| Advisory element | Where it sits in CSAF | What to record | Common trap |
|---|---|---|---|
| Affected products and versions | product_tree, product_status | Exact version ranges and order numbers, mapped to your assets | Ranges that include the version installed on a spare or test bench but not production |
| Vulnerability and weakness | cve, cwe, notes | CVE, CWE and a one-line plain description for operations | Several CVEs in one advisory with different fixes |
| Severity scores | scores | CVSS vector, not only the number, so attack vector and privileges are visible | Network attack vector scored for a device that is only reachable on a local fieldbus |
| Exploitation status | threats (exploit_status), notes | Known exploitation, public exploit or none known, with date | Status changes after publication and is only shown in a revision |
| Remediations | remediations | Category, fixed version, mitigation text, any restart or downtime the supplier notes | Fix requires a newer engineering software version as well as new firmware |
| Revision history | document.tracking | Version and date of the document you triaged | Working from version 1 when version 3 widened the affected range |
Record the triage against the advisory revision. When a supplier or CISA publishes a new revision, compare product status and remediations against the stored version and reopen only the assets that changed.
Prioritising with SSVC in an OT context
CISA's SSVC tree uses five decision points and four outcomes. The values below come from the CISA SSVC Guide; the OT reading is guidance for applying them on a plant.
| Decision point | Values | How to answer it for OT |
|---|---|---|
| Exploitation | None, Public PoC, Active | Active if in KEV or a credible government or supplier report; Public PoC if exploit code or detailed write-up exists |
| Technical Impact | Partial, Total | Total if the flaw gives full control of the device, including credential disclosure that leads to full control |
| Automatable | No, Yes | Assume Yes if unknown, as SSVC advises; remote code execution and command injection are usually Yes |
| Mission Prevalence | Minimal, Support, Essential | Essential for controllers, HMIs and SCADA servers running the process; Support for historians and reporting |
| Public Well-being Impact | Minimal, Material, Irreversible | Material or Irreversible where loss of control could cause physical harm, environmental release or loss of a critical service |
Add exposure: the CERT/CC deployer model includes System Exposure (Small, Controlled, Open) and says that a deployer who does not know where devices are or how they are reached should assume Open. It also notes that mitigations which reduce exposure legitimately change the priority. Record exposure per asset and re-run the decision when a conduit changes.
| SSVC outcome | CISA meaning | Typical OT response |
|---|---|---|
| Track | No action now; remediate within standard timelines | Add to the next qualified patch window; review on advisory update |
| Track* | Monitor closely for change; standard timelines | As Track, plus watch for exploitation or new exposure |
| Attend | Supervisory attention; remediate sooner than standard | Compensating controls within days, patch at the earliest safe window |
| Act | Leadership attention; remediate as soon as possible | Same-day containment (remove exposure, block ports, disable remote access), emergency change with operations |
CVSS and EPSS still help: CVSS v4 environmental and supplemental metrics can express safety and recovery, and EPSS adds a probability signal, though OT products are a small share of the data behind it. See the SSVC Guide, the CVSS v4 Guide and the EPSS Guide.
Choosing the remediation path
CSAF defines five remediation categories. Each needs a different action on the plant.
| CSAF category | Meaning for the asset owner | What to do |
|---|---|---|
| vendor_fix | A fixed version or patch exists | Qualify and schedule; apply interim mitigations until the window |
| mitigation | Supplier-described configuration or control reduces risk | Apply and record evidence; often the main action for months |
| workaround | Changes how the product is used to avoid the flaw | Check operational impact with engineering before applying |
| no_fix_planned | No fix will be produced (often end of life) | Long-term compensating controls and a replacement plan with a date |
| none_available | No fix yet | Mitigate now, track the advisory for revisions |
- Compensating controls that most often work: remove internet exposure, restrict the vulnerable service to named hosts at the conduit, disable unused protocols or web servers on the device, enforce brokered remote access with MFA, set controllers to RUN mode with write protection, and monitor the protocol for the exploitation pattern. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
- Write the plan down: NERC CIP-007-6 R2 already requires bulk electric system entities to evaluate patches at least every 35 calendar days and either patch or hold a dated mitigation plan; the same discipline suits any sector. See the NERC CIP Guide.
- Exceptions: accepted risk needs an owner, the control relied on and an expiry date. See the Remediation SLAs and Vulnerability Exceptions Guide.
Running the triage process
- Daily intake: pull CSAF feeds and KEV, de-duplicate CISA republications of supplier advisories, and flag revised documents.
- Applicability within days: match to inventory and record affected, not affected (with justification) or under investigation.
- Decision within 35 days at most: run SSVC per affected asset group with OT engineering, choose the remediation path and owner.
- Escalate Act outcomes immediately: notify operations and site leadership, apply containment, and open an emergency change.
- Verify: confirm mitigations by evidence (rule export, exposure scan, configuration export) and fixes by version check.
- Re-triage on change: advisory revision, new KEV listing, new exploitation reporting or a change in a conduit reopens the decision.
- Report monthly to plant and security leadership with the metrics below.
Small and large organisations: a single site with a few suppliers can run this in a spreadsheet with supplier email subscriptions and a monthly review. Multi-site operators need a CSAF-aware tool or OT security platform feeding a central queue, with site engineers owning decisions. See the OT Security Platform Buyer's Guide.
Where identity fits
A large share of ICS advisories concern credentials: hard-coded or default passwords, unauthenticated engineering functions and weak session handling. The decisive mitigation is often an identity control (change defaults, disable shared accounts, require authentication on engineering protocols where the product supports it) rather than a patch. KEV entry CVE-2023-6448 for Unitronics Vision PLCs and HMIs is an insecure default password. Track these advisories with your OT identity owner. See the OT and ICS Identity and Access Guide.
Detection and measurement
- Detect exploitation attempts: use passive OT monitoring for unexpected engineering protocol sessions, firmware or program downloads, new external connections from devices named in open advisories, and scanning of their service ports. See the OT Network Security Monitoring Guide.
- Watch exposure: run external attack surface checks for any device model with an open Act or Attend decision.
- Median days from advisory publication to applicability decision.
- Percentage of applicable advisories with a recorded SSVC decision within 35 days.
- Open Act and Attend decisions without a verified compensating control (target zero).
- Percentage of OT assets with exact supplier, part number and firmware version in inventory.
- Number of assets in no_fix_planned status and the share with a funded replacement date.
- Advisory revisions re-triaged within 7 days.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.RA-01, ID.RA-08, ID.AM-02 | Identify and record vulnerabilities, process to receive and respond to disclosures, software inventory |
| NIST SP 800-53 Rev. 5 | RA-5, SI-5, SI-2, CM-8 | Vulnerability monitoring, security alerts and advisories, flaw remediation, inventory |
| NIST SP 800-82 Rev. 3 | OT overlay and flaw remediation guidance | Test before deploying, compensating controls for OT |
| IEC 62443 | TR 62443-2-3, 62443-2-1 | Patch information exchange and asset owner programme. See the IEC 62443 Guide |
| NERC CIP | CIP-007-6 R2 | 35-day evaluation and mitigation plans |
| CIS Controls v8.1 | 7.1, 7.2, 7.5 | Vulnerability management process, remediation process, automated scanning of internal assets |
| MITRE ATT&CK for ICS | T0819, T0866, T0883, T0890 | Techniques that unpatched OT exposure enables |
Common failure patterns
- Triage by CVSS base score: every 9.8 becomes urgent, analysts burn out and the genuinely exposed asset waits in the same queue.
- Product-level matching: "we have that PLC family" without firmware versions produces false positives and missed modules.
- Ignoring advisory revisions: suppliers update affected versions and fixes; a one-time triage goes stale.
- Treating no fix as no action: no_fix_planned advisories on end-of-life devices sit unmitigated because there is nothing to patch.
- Reading KEV absence as safety: few ICS flaws are listed, and exploitation of OT is under-reported.
- Mitigations without evidence: a decision says "behind firewall" but nobody checked the rule or the remote access path.
Practitioner checklist
- Subscribe to CSAF feeds from CISA and every supplier in the OT inventory, and verify signatures.
- Hold exact supplier, part number and firmware version for every OT asset.
- Record exposure (Small, Controlled, Open) and safety impact per asset group.
- Decide every applicable advisory with SSVC within 35 days, with OT engineering present.
- Keep not-affected decisions with VEX-style justifications.
- Plan for all five CSAF remediation categories, including no_fix_planned.
- Verify compensating controls with evidence and set review dates.
- Re-triage on advisory revisions, KEV additions and conduit changes.
- Report time to decision, open Act and Attend items and inventory accuracy monthly.
Standards and references
- OASIS: Common Security Advisory Framework Version 2.0
- CISA: Stakeholder-Specific Vulnerability Categorization
- CISA: SSVC Guide
- CERT/CC: SSVC Documentation
- CISA: CSAF advisories repository
- NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
- NERC: CIP-007-6 Cyber Security, System Security Management
- CISA: Known Exploited Vulnerabilities Catalog
Related NHI Mgmt Group resources: Vulnerability Management Guide · OT Security Guide · Vulnerability Prioritisation Guide · MITRE ATT&CK for ICS Guide · OT Patch Management Guide