Compensating Controls for Systems You Cannot Patch

The gap between a 3-day critical patch SLA written in a policy document and the 67-day median actual remediation time documented in the field is not primarily a people problem. It reflects structural constraints that SLA authors typically do not account for. Vendor support dependencies are the most common: many OT and medical device vendors prohibit unauthorized patching and void support contracts if the OS is modified outside their release process. Regression testing requirements for regulated systems can legitimately require 60 to 90 days of validation before a patch can be applied to a production ERP or financial clearing system. Continuous availability requirements in manufacturing, utilities, and healthcare create windows where the system cannot be taken offline for any patch maintenance. The Horizon3 2025 Attack Intelligence Report documents that the average time-to-exploit after CVE disclosure has dropped to 5 days: meaning that by the time most regulated organizations complete their patch approval process, the CVE has already been actively exploited in the wild. The answer is not to abandon patch SLAs but to have a structured compensating control framework ready to deploy the moment a patch is confirmed infeasible within the SLA window.

Compensating controls are not one-size-fits-all. The right control depends on how an attacker would reach and exploit the vulnerable system. CVSS v3.1 encodes this in the Attack Vector and Authentication metrics, and organizing your compensating controls around these dimensions ensures you are blocking the actual exploitation path rather than checking a compliance box. The three tiers below cover the vast majority of enterprise CVEs on systems with patching constraints.

For Tier 1 CVEs, the compensating control must reduce network reachability to the absolute minimum. The goal is to eliminate or severely constrain the attack surface without taking the system offline. VLAN isolation places the vulnerable system on a dedicated network segment with firewall-enforced ingress and egress rules: only authorized management hosts and application dependencies can reach the system, and all other traffic is dropped. Perimeter firewall ACLs restrict access to specific source IP ranges if VLAN isolation is not immediately feasible. Host-based firewall rules provide a third layer of enforcement if network controls cannot be applied in time. Beyond isolation, deploy an IDS/IPS signature for the specific exploitation pattern: most major vulnerability disclosures are followed within 24 to 48 hours by Snort and Suricata rule releases that detect active exploitation attempts. Log every connection attempt to the vulnerable port from any source outside the authorized access list. This connection logging is the evidence that compensating controls were active and functioning during the period the system remained unpatched.

Authenticated CVEs give defenders a meaningful intervention point that does not exist in Tier 1: the authentication layer. Strengthening authentication does not close the underlying vulnerability but it raises the cost of exploitation from network-accessible to credential-required-plus-network-accessible. Multi-factor authentication enforcement on the vulnerable service is the highest-impact single control for this tier: it blocks the bulk of opportunistic credential-based exploitation while requiring no changes to the vulnerable software itself. Privileged access workstation (PAW) requirements restrict which endpoints can authenticate to the vulnerable system, reducing the attack surface from any endpoint on the network to a small set of hardened management stations. Service account audit and rotation addresses the common case where the vulnerable service runs under an overprivileged account whose credentials are reused across multiple systems. In parallel, deploy behavioral detection rules in your SIEM that alert on authentication patterns consistent with exploitation: off-hours logins, authentication from new source IPs, or rapid sequential authentication attempts. The NIST SP 800-53 AU-2 and AC-17 control families provide a compliance mapping for these monitoring requirements.

A compensating control without documentation is indistinguishable from an ignored vulnerability in an audit. The documentation structure matters as much as the control itself. A risk acceptance record that satisfies PCI DSS, SOC 2, and most regulatory frameworks requires seven elements: the CVE identifier and CVSS score, the affected system and business justification for why patching within SLA is infeasible, the compensating controls deployed with specific implementation details, the residual risk assessment (what attack scenarios remain possible despite the controls), the monitoring evidence confirming the controls are active, the approval authority (typically CISO or risk committee), and the review date when the risk acceptance will be re-evaluated. The review date is the element most commonly omitted: auditors increasingly look for evidence that risk acceptances have expiration dates and are not perpetual deferrals. Set review dates at 90 days for critical CVEs on the CISA KEV list and 180 days for high-severity CVEs with deployed compensating controls. At each review, confirm the controls are still functioning, confirm the patch remains infeasible, and reaffirm or escalate the risk acceptance.

Compensating controls are a risk reduction strategy, not a risk elimination strategy. There are three conditions under which a compensating control framework is not adequate and the organization must escalate to a harder decision. First, if the CVE is on the CISA KEV list and the affected system is internet-facing with no feasible network isolation option, the residual risk is likely unacceptable for most organizational risk tolerances: the system either needs to be isolated from the internet or decommissioned. Second, if the vulnerable system holds data regulated under HIPAA, PCI DSS, or state privacy laws and the compensating controls cannot demonstrate effective containment of the exploitation path to regulated data, legal counsel needs to be involved in the risk acceptance decision. Third, if the same system has accumulated multiple unpatched critical CVEs over time, the aggregate exploitation surface may exceed what compensating controls can meaningfully address: a formal decommission and replacement plan with a timeline is a more honest response than layering controls on a system that has become structurally insecure. Compensating controls work best as a time-bounded bridge to eventual patching, not as a permanent operating posture.