What is the difference between patching and compensating controls in application security?

How patching and compensating controls differ in practice

Patching and compensating controls solve different problems. Patching changes the vulnerable application, library, or runtime so the weakness is removed at the source. Compensating controls leave the flaw in place but lower the chance of exploitation, limit blast radius, or reduce exposure until remediation is possible. That distinction matters because the security posture after each option is materially different.

Patch-based remediation is the cleanest outcome because it eliminates the known failure mode rather than surrounding it with safeguards. Compensating controls are usually time-bound and context-dependent, because they rely on assumptions about traffic patterns, network placement, request validation, or operational discipline that can break if the environment changes.

When compensating controls are acceptable, and when they are only a temporary bridge

Compensating controls become practical when patching is delayed by compatibility testing, release windows, vendor dependency, or outage risk. In those cases, the control should directly narrow the exploit path, for example by restricting access, filtering malicious input, disabling the exposed feature, or reducing the reachable attack surface. NHIMG’s Virtual Patching and Compensating Controls Guide is useful here because it focuses on what to do when fixing the code is not immediately possible.

A compensating control is only credible if it is specific to the weakness and can be shown to reduce the exact exposure. Generic hardening is not enough when the vulnerable path remains directly reachable. The practical question is whether the control blocks the vulnerable behaviour, slows exploitation enough to buy time, or simply adds noise without materially changing risk.

In application security, the strongest compensating controls often sit at the edge or request layer: filtering unsafe inputs, enforcing stricter authorization rules, rate limiting dangerous functions, or disabling the affected endpoint altogether. Network segmentation can help, but only if it actually reduces who can reach the vulnerable code. If the flaw is internet-facing, a local-only mitigation usually does not substitute for patching.

How to decide which path reduces risk fastest

The right sequence is usually to patch first unless there is a proven blocker. If patching is delayed, use a compensating control that is tightly bound to the exploit path, then set an expiry for the exception so the temporary measure does not become permanent. NHIMG’s Remediation SLAs and Vulnerability Exceptions Guide is a good fit for this decision because it ties exceptions to deadlines, controls, and renewal discipline.

For teams managing exposed applications, it is also useful to distinguish between a patch exception and a risk acceptance decision. If you cannot explain how the compensating control changes exposure in measurable terms, the issue has probably moved from operational mitigation to explicit residual risk. NHIMG’s Security Control Types Guide helps frame that distinction by separating compensating controls from preventive, detective, and corrective measures.

Risk and Threat Considerations

The main risk with compensating controls is false confidence. Attackers do not need a perfect path if a weak mitigation still leaves the vulnerable code reachable, especially when the flaw is externally exposed or easy to automate. Controls such as WAF rules or feature disablement can reduce exposure, but they may be bypassed, misconfigured, or outpaced by changes in traffic, dependencies, or attacker technique.

Failure mechanism: The vulnerable component stays deployed, so the organisation is betting on an external barrier, configuration rule, or operational restriction remaining effective against the exact exploit path. If that barrier is incomplete or bypassed, the original flaw is still present and exploitable.

Impact: Exposure can persist long after the organisation believes it has “handled” the issue, which can lead to compromise, service disruption, or a delayed breach response when the temporary mitigation fails.

Practitioner Guidance

What to verify: Confirm that the compensating control specifically blocks or narrows the vulnerable behaviour, not just the surrounding system. Test the bypass case, not only the happy path, because many temporary mitigations fail under alternate routes, direct object access, or malformed requests.

Decision rule: If the vulnerable code is internet-facing or handles sensitive data, treat patching as the priority and use compensating controls only as a time-bounded bridge. If the control cannot be validated against the exploit path, do not treat it as equivalent to remediation.

Practitioner takeaway: Patching removes the flaw, compensating controls only reshape the risk, so the operational goal is to keep the temporary control narrow, testable, and short-lived until the fix is in place.

Related resources from NHI Mgmt Group

• Guide: Application Security Guide
• How should security teams choose between patching and compensating controls?
• Why do application security tools need to be paired with IAM and NHI controls?
• How should security teams prioritise patching when Microsoft vulnerabilities affect identity and cloud controls?
• What do security teams get wrong about patching AI application platforms?