Compensating Controls in OT: How to Validate Risk When You Cannot Patch

Patching is not always the safest immediate response to an OT vulnerability. A controller may require continuous operation. A vendor may not have approved the update. The asset may be running an unsupported operating system, or the next maintenance window may be months away.

In these situations, the practical question is not simply, “Is the vulnerability patched?” It is, “Can an adversary still reach and exploit the vulnerable asset, and would our other controls stop the attack before operational consequences occur?”

OT compensating control validation is the process of gathering evidence that alternative safeguards reduce the likelihood or impact of exploitation when a vulnerable industrial asset cannot be patched. Adversarial Exposure Validation strengthens that process by testing complete attack paths rather than assuming that an individual control works because it is configured or documented.

Why patching OT systems is often constrained

OT patching decisions must account for safety, availability, process integrity, equipment behavior, vendor support, and maintenance schedules. Even an important security update may require engineering review, compatibility testing, a planned outage, and a recovery procedure.

Common reasons for deferring a patch include:

• The vendor has not approved or tested the update.
• The asset cannot be restarted without interrupting production.
• The update could affect a validated process or safety function.
• Replacement parts, firmware, or technical support are unavailable.
• The system depends on legacy applications or protocols.
• The organization lacks a safe environment for compatibility testing.
• The next approved maintenance window has not arrived.

A patch deferral does not automatically mean accepting the full vulnerability risk. It means the organization needs controls that interrupt exploitation, restrict attacker access, detect malicious behavior, reduce potential impact, or combine these outcomes.

What counts as an OT compensating control?

A compensating control is an alternative safeguard used when the preferred security measure cannot be implemented immediately. In vulnerability management, the preferred measure is often a vendor-approved patch or secure product upgrade.

Potential OT compensating controls include:

• Network segmentation between enterprise, industrial DMZ, supervisory, and control zones
• Firewall rules restricting source, destination, port, protocol, and direction
• Jump hosts and controlled remote-access paths
• Multifactor authentication on systems that mediate access to OT
• Removal or restriction of unused services and protocols
• Application allowlisting on compatible hosts
• Access control changes that reduce available privileges
• Passive monitoring and alerts for relevant adversary behavior
• Protocol-aware inspection where operationally appropriate
• Physical access restrictions
• Isolation of the vulnerable asset or cell
• Backup, recovery, and manual operating procedures that limit impact

The existence of one or more of these controls is not proof that the vulnerability is adequately mitigated. A firewall rule may be bypassed through another route. A jump host may be reachable with compromised enterprise credentials. Monitoring may generate an alert without enabling a timely response. An isolated asset may still communicate through an undocumented conduit.

Validation must examine how the controls behave together along the relevant attack path.

The difference between documenting and validating a control

A control is documented when its intended design and configuration are recorded. It is implemented when the safeguard exists in the environment. It is validated when evidence shows that it interrupts, detects, or limits a realistic attack scenario.

That distinction matters because vulnerability scans and asset inventories primarily identify conditions. They do not, by themselves, prove whether an attacker can move from an accessible entry point to the vulnerable OT asset.

A useful validation exercise should answer four questions:

1. Reachability: Can an attacker reach the vulnerable service from a realistic starting point?
2. Exploit conditions: Are the protocol, privilege, authentication, version, and configuration conditions required for exploitation present?
3. Control effectiveness: Which preventive or detective control interrupts the path, and at what stage?
4. Consequence: If the control fails, what process, safety, production, or recovery impact could follow?

This changes vulnerability prioritization from a score-based exercise into an evidence-based risk decision.

A practical OT compensating control validation workflow

1. Define the vulnerability and the patch constraint

Record the affected assets, vulnerable versions, relevant services, vendor guidance, and reason the patch cannot be applied. Include the owner of the exception and the date or condition that will trigger reassessment.

Avoid treating the vulnerability identifier or severity score as a complete risk statement. Capture the conditions an attacker would need to exploit it in this specific environment.

2. Identify realistic attacker starting points

Do not evaluate the asset in isolation. Potential starting points may include:

• A compromised enterprise workstation
• Remote-access infrastructure
• A vendor connection
• An engineering workstation
• An industrial DMZ service
• Another host in the same control zone
• Physical or local access

OT attacks may begin outside the control network. Validation should therefore include relevant [IT-to-OT attack paths](https://frenos.io/resource/from-it-to-ot-cyber-digital-twin), not only communication within the plant floor.

3. Model the path to the vulnerable asset

Map the systems, identities, trust relationships, network conduits, services, and privileges that could connect an attacker’s starting point to the target.

Useful inputs can include firewall configurations, network data, asset inventories, vulnerability findings, architecture diagrams, identity information, and existing security telemetry. Perfect visibility is helpful but should not be a prerequisite for beginning. Gaps and assumptions should be clearly marked so that teams know where additional discovery is needed.

4. Map every compensating control to the attack path

For each proposed control, document:

• The attack step it is intended to prevent or detect
• Its enforcement point
• The assets, users, and protocols it covers
• Known exceptions and bypass conditions
• The evidence needed to confirm effectiveness
• The owner responsible for maintaining it

For example, “OT is segmented” is too broad. A testable statement is: “Only the approved jump host can initiate the required management protocol into the target zone, and the jump host cannot be reached directly from standard enterprise user networks.”

5. Test the path without endangering production

Direct exploit attempts, active scanning, or aggressive red-team activity can create unacceptable risk for fragile or safety-critical systems. A [cyber digital twin can support OT security testing](https://frenos.io/blog/how-digital-twins-are-changing-ot-security-testing) by representing relevant architecture, connectivity, vulnerabilities, and control relationships outside live production.

Within the modeled environment, defenders can simulate adversary techniques and evaluate whether the complete path reaches the vulnerable asset. This can reveal alternate routes, shared credentials, permissive conduits, or chained weaknesses that an isolated control review may miss.

Digital-twin validation does not eliminate the need for accurate source data or engineering review. The model’s assumptions, coverage, and evidence should remain visible to decision-makers.

6. Classify the validation result

Use decision-oriented outcomes rather than a simple pass or fail:

• Blocked: The modeled path is interrupted by an enforced preventive control.
• Detected and containable: The path can progress, but relevant activity should be detected with a defined response capable of limiting impact.
• Partially mitigated: One path is controlled, but alternate routes or important assumptions remain.
• Exposed: A complete path to the vulnerable asset remains available.
• Inconclusive: Data or model gaps prevent a defensible determination.

An “inconclusive” result is useful. It identifies exactly what evidence must be collected before risk acceptance is justified.

7. Prioritize remediation by attack-path reduction

If several vulnerable assets cannot be patched, prioritize actions that eliminate the greatest number of consequential paths. A firewall correction, remote-access restriction, or identity change may reduce exposure across multiple assets at once.

This approach complements traditional vulnerability management. It does not replace asset visibility, scanning, monitoring, or engineering expertise. It helps those teams focus on the vulnerabilities and control gaps that contribute to reachable, exploitable paths.

8. Revalidate whenever the environment changes

A compensating control is not permanent evidence. Revalidate after:

• Firewall or routing changes
• New remote-access connections
• Asset replacements or firmware changes
• Identity and privilege changes
• New vulnerability or threat information
• Control tuning or monitoring changes
• Maintenance outages
• Major architecture changes

Continuous validation is particularly important in environments where patch deferrals last for extended periods.

Evidence required for a defensible risk decision

A compensating-control record should give security, engineering, operations, and leadership a shared view of the decision. At minimum, include:

This evidence is more useful than a closed ticket labeled “mitigated” because it explains why the risk decision is reasonable and what could invalidate it.

How Frenos supports Adversarial Exposure Validation in OT

Frenos uses agnostic data ingestion to turn fragmented OT information into operational security context. Its cyber digital twin supports simulated adversary techniques and IT-to-OT attack-path validation without testing live production systems.

For unpatchable or temporarily unpatched assets, teams can use this approach to:

• Determine whether vulnerable services are reachable from realistic entry points
• Identify the controls that actually interrupt an attack chain
• Find alternate routes around proposed compensating controls
• Prioritize changes by their effect on exploitable paths
• Reassess exposure as architecture, vulnerabilities, and controls change
• Provide engineering and leadership with evidence supporting residual-risk decisions

The goal is not to replace security controls, vulnerability management, monitoring, or OT teams. It is to validate and prioritize them using transparent attack-path evidence.

Frequently asked questions

Can segmentation compensate for an unpatched OT vulnerability?

Segmentation can reduce risk if it prevents unauthorized systems or identities from reaching the vulnerable service. It should be validated against realistic and alternate attack paths. A broad statement that an asset is “behind a firewall” is not sufficient evidence.

Does monitoring count as a compensating control?

Yes, but monitoring is primarily detective. Its value depends on whether the relevant behavior produces telemetry, the alert is actionable, and responders can contain the attack before operational impact. Preventive and detective controls are often strongest when combined.

Is a high CVSS score enough to require immediate OT patching?

Severity is an important input, but an OT decision should also consider reachability, exploit conditions, existing controls, operational consequences, and the risk introduced by the patching process. Deferral should still be time-bound, documented, and validated.

Should teams test compensating controls directly in production?

Limited production verification may be appropriate when engineering and operations approve a tightly controlled procedure. Aggressive scanning or exploitation can create safety and availability risks. Simulation in a high-fidelity digital twin enables broader attack-path testing without interacting with production assets.

Validate the path, not just the exception

When patching is delayed, OT teams need more than a vulnerability exception and a list of controls. They need evidence showing whether an adversary can still reach the vulnerable asset, where defenses stop the path, and what residual risk remains.

Frenos applies cyber digital twins and simulated adversary techniques to validate OT attack paths without testing live production systems. [Request a demo](https://frenos.io/contact) to see attack paths in your OT environment and assess defenses without production impact.