They should patch where it is safe, but document compensating controls where patching would disrupt operations or is not technically feasible. The key is to tie each exception to a risk decision, track it against the asset inventory, and revisit it as part of the maintenance cycle rather than leaving it open-ended.
How patching decisions should be made in OT
In OT, patching is a risk decision, not a reflex. The right approach is to patch where the asset can tolerate it, then treat any deferral as an explicit exception with ownership, expiry, and review. That keeps operational continuity intact while preventing “temporary” exceptions from becoming permanent exposure.
OT teams usually have to balance security benefit against process interruption, safety impact, vendor support constraints, and testability. Where a patch cannot be applied safely, the compensating control has to be strong enough to reduce exposure in a measurable way, and the decision should be recorded against the affected asset, not handled as a generic policy waiver.
Good practice is to separate “patch now” from “risk accepted for now.” A patch can be delayed because downtime is unsafe, validation is incomplete, or the vendor has not certified the change, but the deferral still needs a decision trail that shows what risk remains and who accepted it.
What compensating controls need to achieve
Compensating controls in OT should narrow the attack path enough to make the patch delay defensible. That usually means reducing exposure, limiting who or what can reach the system, and increasing visibility so changes in behaviour are noticed quickly. If the control does not change the practical risk profile, it is not an effective substitute.
Controls often need to be layered because OT environments are long-lived and heterogeneous. Network segmentation, strict remote access rules, allowlisting, protocol filtering, monitoring for abnormal commands, and physical or procedural restrictions can all help, but they should be chosen because they directly reduce the specific risk introduced by the unpatched asset.
The decision should also stay tied to the asset inventory. If the organisation cannot show which assets are patched, which ones are exempt, and which compensating controls protect each exception, the patching programme will drift into assumption rather than governance. Security Exceptions and Risk Acceptance Guide is a useful reference for structuring that exception lifecycle.
How to keep exceptions from becoming open-ended
Every exception should have a maintenance-cycle review, not just an initial approval. That matters in OT because the risk context changes when assets are replaced, maintenance windows open up, compensating controls degrade, or a vulnerability becomes actively exploited. A once-acceptable deferral may become unacceptable without the asset itself changing.
The review process should ask whether the original reason for deferral still exists, whether the compensating control is still operating as intended, and whether a safer patch path has emerged. If the answer to any of those is no, the organisation should either patch or re-authorise the exception with updated justification.
That is why exception governance and asset governance need to move together. A patch exception that is not linked to the asset register, the maintenance plan, and the residual risk owner tends to survive past its useful life. Segregation of Duties (SoD) Guide helps illustrate how formal control exceptions should be bounded, approved, and monitored rather than left to informal operator judgement.
Risk and Threat Considerations
Delayed patching in OT can create a wider exposure window than in IT because the affected systems are often long-lived, difficult to restart, and connected to high-consequence physical processes. A weak compensating control can leave the organisation with the appearance of risk reduction while the exploitable condition remains intact.
Failure mechanism: Attackers, or simply opportunistic malware, tend to target the unpatched asset path that remains reachable through flat networks, shared administration channels, weak remote access, or poorly monitored vendor connections. If the compensating control does not materially reduce that path, the exception becomes an enduring point of entry.
Impact: The likely result is loss of operational integrity, broader plant disruption, or unsafe process changes if the vulnerable asset is reached and manipulated. Even when the issue begins as a maintenance decision, the consequence can escalate into operational outage, safety impact, or lateral movement into adjacent systems.
For OT-specific threat and control context, CISA Industrial Control Systems and NIST SP 800-82 Rev 3, OT Security Guide both reinforce the need to treat segmentation, access restriction, and maintenance planning as part of the risk decision, not as afterthoughts. The CISA Known Exploited Vulnerabilities Catalog is especially important when a delayed patch is associated with active exploitation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | RA-3 — Risk Assessment | OT patch exceptions require documented residual-risk decisions. |
| CM-3 — Configuration Change Control | Patch timing and compensating controls depend on controlled change approval. | |
| CA-7 — Continuous Monitoring | Exception validity depends on ongoing review of control effectiveness and exposure. | |
| Recommendation — Assess residual risk before granting or renewing an OT patch exception. Require formal change control for OT patching and exception approvals. Monitor deferred OT patches and compensating controls for drift or failure. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | OT compensating controls commonly rely on segmentation and restricted connectivity. |
| CIS-7 — Continuous Vulnerability Management | The question is fundamentally about prioritising and managing patch exceptions over time. | |
| Recommendation — Segment OT networks to reduce exposure when patching must wait. Track vulnerable OT assets and revisit patch deferrals on a defined cycle. | ||
Practitioner Guidance
What to prioritise: Start with the highest-consequence assets and the exceptions that rely on the weakest compensating controls. If a control only adds documentation but does not materially shrink exposure, treat that exception as a patching priority rather than a solved risk.
What to verify: Confirm that each deferred patch has an owner, an expiry condition, a compensating control that can be evidenced, and a direct tie to the asset record. If you cannot produce all four, the exception is not operationally controlled.
Practitioner takeaway: In OT, the goal is not to avoid patch exceptions, but to make every exception time-bound, asset-specific, and continuously revalidated against the real exposure it leaves behind.
Related resources from NHI Mgmt Group
- When should organisations prioritise compensating controls over immediate patching?
- How do organisations operationalise NHI ownership at scale?
- What is the difference between human IAM controls and NHI governance?
- What is the difference between patching a vulnerability and reducing identity blast radius?