The short answer
Compensating Controls
A compensating control reduces the risk of a vulnerability by a means other than fixing it: a firewall rule that lets only the engineering workstation reach the vulnerable port, the vulnerable service disabled in the device configuration, a protocol-aware firewall that blocks the function the exploit uses, application allowlisting that stops the payload from running, monitoring that alerts on the attempt, a keyswitch left in run, a locked panel, or a procedure that removes the exposure. The control is chosen by matching it to the attack path the advisory describes, it is recorded against the specific vulnerability with a review date, it is tested to confirm that the vulnerable interface is now unreachable or the function blocked, and it stands until the patch is applied or the device is replaced, which remains on the plan.
Key points
- A compensating control covers a specific attack path; match it to what the advisory says the attacker needs.
- Restricting reachability is the most general control: if nobody who could exploit it can reach it, the vulnerability is dormant.
- Disable the vulnerable service where the device allows; the best control is an interface that is not there.
- Protocol-aware firewalls can block the function code or the message type the exploit uses while allowing normal polling.
- Test the control the way an attacker would: try to reach the port from where they would be.
- Record it against the vulnerability with a review date, and keep the patch or replacement on the plan.
Matching the control to the vulnerability
An advisory describes an attack path: a network-reachable web server on port such and such that accepts an unauthenticated request; a programming protocol that lacks authentication; a file parser in the engineering software that can be tricked by a crafted project file; a debug port left open. A compensating control works when it breaks that path. A firewall rule breaks a network path; a disabled service removes the target; a protocol filter blocks the message; allowlisting stops the payload; a procedure stops the crafted file from being opened. A control that does not touch the path, such as antivirus for a controller vulnerability, is reassurance rather than protection.
| Vulnerability type | Compensating controls | Notes |
|---|---|---|
| Network service on a controller or device with no fix | Firewall rule limiting the port to the engineering workstation; disable the service if not needed; VLAN isolation | Verify the rule with a test from the control network |
| Unauthenticated programming or configuration protocol | Protocol-aware firewall blocking programming functions except from the engineering workstation during a change window; keyswitch or mode set to run; program change detection | Common on older controllers; the combination is the standard answer |
| Vulnerable web interface on a device | Disable the web server; restrict to the management VLAN; access only through the jump host | Most device web servers are not needed in operation |
| Vulnerability in engineering or configuration software | Allowlisting on the engineering workstation; project files only from trusted sources through the transfer path; the workstation isolated from email and the office | The attack needs a person to open a file; the procedure is the control |
| Remote access product vulnerability | Disable the product until patched; require the VPN and jump host path; multi-factor authentication | Exposed products are patched or turned off, not mitigated for long |
| Denial of service on a controller | Rate limiting or protocol filtering at the firewall; monitoring; a documented manual fallback | Local control keeps the process running through a controller reboot |
| Information disclosure | Restrict reachability; rotate the credentials it could expose | Often accepted at low consequence with the restriction in place |
| Physical port or local attack | Locked panel, port blockers, intrusion alarm, access log | Physical security is a compensating control |
Choosing and applying
- 1
Read the attack path
From the advisory: the interface, the protocol, the privileges needed, whether user interaction is required.
- 2
List the controls that break it
From the table and the segmentation design; prefer the one that removes the interface, then the one that restricts reachability, then the one that filters or detects.
- 3
Check the side effects
A disabled service that the SCADA used; a firewall rule that blocks the vendor tool; a keyswitch that stops legitimate edits. The functional description and the conversation map say what the interface is used for.
- 4
Apply through change management
The control is a change, with a backup, a window, and a verification.
- 5
Test as the attacker
From the office, from the control network, from the engineering workstation: can the port be reached, does the function get through. The test result is in the record.
- 6
Record
Against the vulnerability: what the control is, where it is configured, who applied it, the test, and the review date. Also in the asset entry, so that a future change to the firewall or the device does not silently remove it.
When the control is the permanent answer
Some vulnerabilities will never be patched: the vendor has no fix, or the device is past support, or the fix requires hardware the utility will not replace for years. For those the compensating control is permanent, and it is designed as such: layered, so that a single failure does not expose the device; monitored, so that attempts are seen; and reviewed, so that a change in exposure is noticed. The replacement stays on the plan even so, because a device that depends on a firewall rule for its safety is one rule change from exposure, and the risk assessment carries it every year until it is gone.
Frequently asked questions
- Is a compensating control as good as a patch?
- It can be as effective against the specific attack path, and it is sometimes better, because restricting reachability protects against the vulnerabilities not yet published as well. It is not a substitute for the general habit of patching, and it depends on the control staying in place, which a patch does not.
- What is a protocol-aware firewall?
- A firewall that understands the control protocols, Modbus, DNP3, EtherNet/IP and others, and can allow or block by function: permit reads from the SCADA, permit writes to specific registers, block programming and firmware functions except from a named workstation. Industrial firewalls offer this, and it is the most precise compensating control for controller vulnerabilities.
- Can we just isolate the whole control network and call it done?
- Isolation of the control network from the office and the internet is the foundation, and it is the first compensating control for every vulnerability at once. It does not protect against the engineering laptop that was on the internet last night, the contractor with a USB drive, or the vendor remote session. Layered controls inside the isolation are still needed for the components that matter most.
- How do we prove to an auditor that the control works?
- With the test in the record: from the places an attacker could be, the attempt to reach the interface fails, with a screenshot or a log. Repeat the test at the review and file it. A control that has been tested is evidence; one that has been configured is a claim.
Related topics
- Risk-Based PatchingDeciding what to patch first when everything cannot be patched at once: priority from exposure, exploitation, and consequence rather than scores, tiers with timelines, different rules for servers, network gear, and controllers, and the written accept decision.
- Advisories and AlertsWhere a utility learns its equipment has a known vulnerability and what to do with the news: the government and vendor advisory feeds, the sector center, the exploited catalog, subscribing by product, a weekly triage on exposure and consequence, and records.
- Firewall Rule DesignWriting the rule set for a control network boundary: default deny, one rule per conduit with its reason, hosts not subnets, protocol and port and function, direction and initiator, logging on every rule, and the review that removes forgotten rules.
- Industrial FirewallsFirewalls built for control networks: how they differ from office firewalls, where they belong in a utility network, transparent versus routed modes, Modbus and DNP3 awareness, logging, and the ruggedized units that protect one controller or a remote site.
- Controller HardeningWhat can be locked down on a PLC or RTU: keyswitch and mode, credentials, unused services, access lists, firmware, and the engineering workstation that is the real target.
- Controller Mode Switch and KeyswitchThe physical switch on the front of a controller: what RUN, REMOTE, and PROGRAM mean, why most controllers are left in REMOTE and why that matters, a policy for a utility, how mode is monitored and alarmed, and what to do on platforms with no keyswitch.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.