Official intent
Manage known vulnerabilities in OT — patch, or apply compensating controls, on a schedule production can accept. The official source remains authoritative.
Read the official campaign ↗You cannot patch OT like IT. Many devices can only be updated during rare maintenance windows, run vendor-certified firmware, or cannot be taken down at all. Managing known vulnerabilities in OT means knowing what you are exposed to, deciding per device whether to patch or compensate, and doing it on a risk-ranked schedule the process can tolerate — not on IT's clock.
Who this applies to: Every environment with networked control equipment. The decision is never 'patch everything' — it is patch-or-compensate, taken deliberately per device.
Why it matters
OT vulnerabilities are long-lived and widely published, and adversaries know these systems are rarely patched. But blind patching can break a validated process or void a warranty. A disciplined program — patch where you safely can, compensate where you cannot — closes real exposure without gambling with uptime or safety.
Risks this reduces
- Long-lived, publicly documented vulnerabilities on devices that are rarely updated
- Internet-reachable control equipment
- Process disruption caused by patching without vendor approval or testing
- Unpatchable devices treated as unmanaged rather than compensated
Patching or updating firmware on live OT can disrupt a validated process or trip safety functions. Apply vendor-approved patches only, test in a lab or during an approved maintenance window with the process owner present, and keep a tested rollback. When a patch is too risky, a documented compensating control is the correct answer — not forcing the update.
Who owns it
OT engineer
Plant / OT leader, IT / security lead, Vendors
Medium
Medium
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: OT-02 — Validated OT asset inventory, OT-03 — OT network segmentation
- A validated inventory with firmware versions, so advisories can be matched to devices
- Vendor advisory subscriptions for the products you actually run
- Agreed maintenance windows and a rollback method for each device class
Action timeline
- Cross-reference the OT inventory against known-exploited and vendor advisories
- Flag any internet-reachable OT device
- Cross-reference the inventory against vendor advisories and the known-exploited catalogue, and rank by exposure and process impact
- Apply compensating controls — isolation, access restriction — to the worst findings you cannot safely patch yet
- Rank findings by exposure and process impact
- Apply compensating controls (isolation, access limits) to the worst that cannot be patched now
- Schedule vendor-approved patches into the next maintenance windows
- Test patches in a lab or on non-critical units first
- Document each patch-or-compensate decision
- Subscribe to vendor and ICS advisories for ongoing coverage
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Map known vulnerabilities to the validated OT inventory using vendor advisories and ICS sources.
- Rank each by real risk — exposure, reachability, and impact on the process — not raw score.
- For each, decide patch or compensate with the process owner, honoring vendor certification.
- Apply patches through vendor guidance and maintenance windows, tested first and with rollback.
- Where patching is unsafe, apply and document compensating controls, and review decisions on a cadence.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
No view of OT exposure; 'we can't patch anyway' stands in for a decision.
Is there anything at all — a tool, a document, a person who owns it? - Documented
A policy defines how OT vulnerabilities are ranked and when a compensating control replaces a patch.
Is the intent written down, with a named owner and a scope? - Configured
Advisory monitoring is in place and findings are matched to inventoried devices.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
Every high-risk finding has either an applied vendor-approved patch or a documented compensating control.
Does it cover everything in scope, with the exceptions written down? - Measured
Exposure is tracked against the inventory over time, and decision latency and coverage are reported.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
Decisions are logged with a named approver and reviewed on a cadence; compensating controls have expiry and re-evaluation dates.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Confirm every high-risk OT vulnerability has either an applied patch or a documented compensating control.
- Verify no OT device with a known-exploited vulnerability is reachable from outside its zone.
- Check that patches were vendor-approved and applied in an authorized window with a rollback on hand.
Evidence to retain
OT vulnerability/patch policy including compensating-control criteria
Vulnerability-to-asset mapping and applied compensating controls
Maintenance-window patch records with test and rollback notes
Decision log of patch-or-compensate with review dates
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| High-risk findings addressed | High-risk OT findings with an applied patch or documented compensating control ÷ high-risk findings. | 100%. |
| Internet-reachable OT devices | Inventoried OT devices reachable from the internet. | Zero. |
| Advisory-to-decision time | Days from a relevant vendor or ICS advisory to a recorded patch-or-compensate decision. | Within the interval the plant agreed. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
Patching a controller mid-shift and halting the line, treating an unfixable device as acceptable with no compensating control, and ignoring advisories because “we can't patch anyway.” Unpatchable is not the same as unmanaged.
Two sized paths
Subscribe to the advisories for the handful of vendors you actually run, and check them against your inventory monthly. When you cannot patch, write down what you did instead — isolation, tighter access, monitoring — and when you will revisit it. That written decision is the whole practice at small scale.
Correlate advisories against the inventory continuously, rank by reachability and process impact rather than raw score, validate patches in a lab or on non-critical units first, and maintain a reviewed decision log where every compensating control carries an expiry date.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Every patch is a change to a validated process. Apply only vendor-approved updates, test on a bench or non-critical unit first, schedule inside approved windows with the process owner present, keep a tested rollback, and record the decision either way. Declining to patch is a legitimate outcome when it is documented and compensated. Identification carries the same discipline as remediation: active vulnerability scanning of live control networks can stall or crash controllers and instrumentation, so identification should rest on passive traffic analysis and configuration and firmware records — any active technique is vendor-approved, tested on bench equipment first, window-scheduled, and agreed with the process owner, or it does not run.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The publication addresses patching under availability and vendor-certification constraints, including compensating controls where patching is not viable.
What this does not claim: 800-82 is guidance, not a compliance standard.
Why: The Technical Report is specifically about patch management for industrial automation and control systems.
What this does not claim: A Technical Report, not an International Standard — informative guidance within a voluntary industrial series. Conformance language does not apply to it.
Why: Vulnerability identification and software maintenance outcomes cover the identify-and-decide cycle.
What this does not claim: The CSF describes outcomes, not testable controls.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.11.2Vulnerability scanningPartial implementation supportModerate
Why: Where OT systems fall inside the CUI boundary, the practice's advisory correlation — matching vendor and ICS advisories and the known-exploited catalogue against a validated inventory with firmware versions — is vulnerability identification fitted to equipment that active scanning could disrupt.
What this does not claim: May partially address the requirement, and only for OT assets actually within the assessed boundary — most OT sits outside it. The practice deliberately identifies vulnerabilities passively rather than by scanning, so the organization must be able to show an assessor that advisory correlation plus a validated inventory reaches what the requirement's periodic scanning intends; the requirement text does not contemplate control-system constraints, and the argument has to be made, not assumed.
Review status: Technical review complete.
Open the 3.11.2 page →3.11.3Vulnerability remediationPartial implementation supportModerate
Why: The practice's patch-or-compensate decision is remediation under production constraints: vendor-approved patches validated on a bench and applied inside agreed maintenance windows with rollback ready, and documented compensating controls — isolation, tighter access — with expiry dates when patching must wait.
What this does not claim: May partially address the requirement, and only inside the CUI boundary; the requirement does not contemplate control-system patch constraints, so an assessor will probe whether a compensating control genuinely reduces the risk the missing patch leaves open. A declined patch is defensible only while its written decision, mitigation, and re-evaluation date stay current — an expired compensating control is just an unremediated finding with paperwork.
Review status: Pending NIST SME review.
Open the 3.11.3 page →3.14.1Flaw identification and remediationPartial implementation supportModerate
Why: Managing known vulnerabilities on a schedule production can accept is this requirement translated to control systems: flaws are identified against vendor advisories and corrected — or deliberately compensated for — asset by asset.
What this does not claim: May partially address the requirement, and only for OT assets inside the assessed boundary. 'Timely' means something different when the patch window is the annual shutdown and the vendor must qualify every update: where patching would risk production or safety, the practice compensates with isolation, monitoring, or hardening rather than correcting, and that residual gap belongs in the plan of action, documented rather than hidden. 800-171's text does not contemplate control-system patch constraints.
Review status: Technical review complete.
Open the 3.14.1 page →NIST SP 800-171 Rev. 3
03.11.02Vulnerability Monitoring and ScanningPartial implementation supportModerate
Why: The practice runs the same monitor-and-remediate cycle for the OT estate, adjusted to production reality: vulnerability identification through passive discovery and vendor advisories, patching inside maintenance windows, and compensating measures where patching would threaten operations.
What this does not claim: May partially address the requirement for the OT portion of an assessed boundary. Active scanning can crash fragile controllers, so the practice often substitutes passive discovery and advisory monitoring — a legitimate method, but one an assessor will expect to see documented as the organization's defined approach rather than assumed. Where a vulnerability cannot be remediated within the defined response times, the compensating measure and its formal acceptance must be recorded, or the gap between the parameter and the plant's reality becomes the finding.
Review status: Pending NIST SME review.
Open the 03.11.02 page →03.14.01Flaw RemediationPartial implementation supportModerate
Why: The practice handles known OT vulnerabilities the way control environments demand — patching in maintenance windows where vendors allow it, compensating with isolation and monitoring where they do not — which advances flaw remediation for the OT systems inside an assessed boundary.
What this does not claim: May partially address the requirement, and only where OT assets fall within the CUI system boundary — much OT does not. A compensating measure manages a flaw's risk without correcting the flaw, so each one needs its own documented justification, and the organization-defined update periods still govern wherever patching is possible.
Review status: Pending NIST SME review.
Open the 03.14.01 page →Review status
| Technical review | Reviewed — pending SME sign-off |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.1 |
This guide has been reviewed by practitioners but is awaiting sign-off from a subject-matter expert in this specific domain. Treat the safety and change-control guidance as a floor, not a ceiling, and validate it against your own process and vendor requirements.