What happens when a vulnerability cannot be patched immediately?

What compensating controls do when a patch has to wait

When a vulnerability cannot be patched immediately, the goal is to reduce exposure fast enough that the vulnerable system is less attractive, less reachable, and less capable of being abused. Compensating controls buy time, but they do not change the underlying flaw, so they should be treated as temporary risk reduction, not closure.

The most effective controls usually work by shrinking the attack surface. That can mean isolating the affected device or service, removing unnecessary network paths, tightening firewall or segmentation rules, disabling the vulnerable feature, or constraining who can use the system. The right control depends on how the flaw is reached and what an attacker could do after entry.

Because compensating controls are temporary, they should be specific to the exposure rather than generic hardening. If the vulnerable component is externally reachable, network restriction often matters most. If exploitation depends on a feature, protocol, or privilege path, turning that path off or limiting access can be more effective than broad configuration changes. The practical question is not whether the control is elegant, but whether it makes exploitation materially harder until the fix lands.

How to decide which workaround is strong enough

A compensating control is only useful if it changes the attacker’s cost or reach in a meaningful way. A control that is easy to bypass, inconsistently applied, or impossible to verify should not be treated as a substitute for remediation. The more severe the vulnerability, the more the workaround should be validated as an actual barrier, not a paper control.

That is why teams often pair temporary restrictions with monitoring and explicit exception handling. If a patch must wait, security and operations should agree on the exact scope of the exception, what systems remain exposed, and what evidence shows the workaround is still active. In practice, this is where vulnerability management discipline matters most, and teams should use the Vulnerability Management Guide to align the exception with asset scope, prioritisation, and verification.

Permanent fixes should still be tracked as a priority item, not an open-ended backlog entry. When patching is delayed because of compatibility, change freeze, or operational dependency, the temporary control must have an owner and an expiry condition. Otherwise, the workaround tends to become normalised and the exposure lingers long after the original urgency has passed.

What teams should check while the flaw remains open

Once a vulnerability is known but still unpatched, the main concern is whether it has already been used against the environment. Teams should review logs, endpoint telemetry, authentication activity, configuration changes, and any signs that the affected host or service behaved unexpectedly. If the flaw is actively exploited in the wild, this check should happen before the patch is finally applied, not after.

For exposed or actively exploited issues, authoritative tracking sources help determine urgency and triage. The CISA Known Exploited Vulnerabilities Catalog shows which weaknesses have confirmed exploitation, while the NIST National Vulnerability Database provides the canonical vulnerability record and associated product data. For prioritisation where patch windows are tight, FIRST EPSS can help separate likely exploited issues from lower-probability ones.

When a workaround is applied, teams should also verify whether the risk shifted rather than disappeared. For example, restricting access may lower exposure but increase reliance on a small set of trusted paths or admin workflows. If those paths are weakly monitored, the temporary control can create a different blind spot even while it reduces the original attack surface.

Practitioner Guidance

What to prioritise: Start with the control that most directly blocks the original exploit path, not the control that is easiest to document. If remote reachability is the issue, reduce exposure first; if feature abuse is the issue, disable or fence the feature first.

What to verify: Confirm the workaround is actually enforced at the boundary that matters, and that you can prove it with logs, rules, or configuration state. A compensating control that cannot be independently verified is usually just an assumption.

Escalation / exception: Treat any unpatched, internet-reachable, or actively exploited vulnerability as a time-bounded exception with named ownership. If the exception has no expiry or no monitoring requirement, it is not a compensating control, it is residual risk.

Practitioner takeaway: The purpose of a compensating control is to make exploitation harder while the fix is pending, but the security decision is not complete until the team has verified exposure reduction, monitored for compromise, and committed to a permanent remediation path.

Related resources from NHI Mgmt Group

• What happens when a vulnerable OpenSSH server cannot be patched immediately?
• What happens when a vulnerable service cannot be patched immediately and segmentation is not in place?
• What breaks when a production container vulnerability cannot be patched immediately?
• What happens when attackers remain active after a vulnerability has been patched?