What should organisations do when a web vulnerability cannot be fixed right away?

What Organisations Should Do First When a Web Vulnerability Cannot Be Fixed Immediately

When a patch is not available or cannot be deployed quickly, the priority is to shrink the attack surface that remains. That usually means restricting who can reach the affected function, reducing exposure to the internet or untrusted users, and adding compensating controls that make exploitation harder and easier to detect. The goal is not to “wait safely”, it is to manage residual risk deliberately.

Compensating controls should be specific to the weakness, not generic security theater. If the flaw is reachable only through a narrow path, reduce that path. If it is observable in logs, increase monitoring. If the vulnerable feature can be disabled or reconfigured, do that temporarily. If the workaround changes business operations, document the trade-off so owners understand what has been accepted and why.

In practice, the best short-term control is often the one that most directly breaks the exploit chain. For a web issue, that may mean rate limiting, WAF rules, tighter authentication gates, network segmentation, feature flags, safer configuration defaults, or temporary removal of the exposed endpoint. If the workaround introduces its own risk, teams should treat it as an interim control with an expiry date, not as a permanent substitute for remediation.

How to Judge Whether a Temporary Control Is Good Enough

A temporary control is only useful if it materially reduces the chance of exploitation or the impact of compromise. Organisations should compare the asset’s value, the exposure path, and the likely abuse scenario. A low-value internal app with limited reach can tolerate a simpler workaround than a public-facing system that processes sensitive data or sits on a trusted path into other environments.

That decision should also reflect how much of the exploit chain remains intact. If the weakness still allows unauthenticated access, remote code execution, or data disclosure, the workaround must be stronger than a simple notification banner or ticket comment. By contrast, if the issue is reachable only after authentication, shrinking access and strengthening detection may be enough while a fix is queued.

• Confirm whether the vulnerable component is internet-facing, partner-facing, or internal only.
• Determine whether the flaw enables access, execution, disclosure, or privilege change.
• Check whether a configuration change can remove the vulnerable condition without breaking the service.
• Track an expiry date for the workaround so it does not become the new normal.

For web vulnerabilities that expose authentication, session, or access paths, the surrounding control environment matters as much as the flaw itself. Organisations can also use OWASP API Security Top 10 and CIS Controls v8 to reinforce access control, logging, and vulnerability management while remediation is pending.

Risk Acceptance, Monitoring, and Remediation Discipline

If the organisation cannot reduce exposure enough, the remaining choice is formal risk acceptance. That should be a conscious business decision, not an informal “we will revisit it later” arrangement. Acceptance is only defensible when the owner understands the impact, the temporary control is documented, and the vulnerability has a scheduled remediation path. In security terms, unmanaged residual risk is usually worse than acknowledged residual risk.

Monitoring matters because temporary controls can fail silently. A workaround that looks adequate on day one may be bypassed later through a new route, a configuration drift, or a dependency change. Teams should watch for exploitation attempts, unexpected access patterns, and drift in the compensating control itself. In especially sensitive cases, the operational evidence should be strong enough to show whether the workaround is still protecting the vulnerable path.

Organisations should also keep an eye on remediation latency. NHIMG research shows that 91.6% of secrets remain valid five days after the targeted organisation is notified, which is a useful reminder that notification does not equal exposure reduction. Even when the issue is not a secret itself, the same pattern applies: if the fix is delayed, the compensating controls need to be real, measurable, and owned.

Practitioner Guidance

What to prioritise: Start with exploit-path interruption, not with administrative debate. If the issue can be gated, isolated, or temporarily disabled, do that before spending time on broader policy discussion.

What to verify: Confirm that the interim control actually blocks or limits the vulnerable path in production conditions. A control that works in a test case but fails under normal traffic or alternate routing is not sufficient.

Decision rule: If the flaw remains publicly reachable and can still be exploited with low effort, treat the situation as high urgency and escalate for stronger containment. If exposure is narrow and the business impact of the workaround is material, document a time-bound exception and reassess frequently.

Practitioner takeaway: The right response is usually not “patch later”, it is “reduce blast radius now, prove the workaround is effective, and force a dated decision on when the real fix must land.”

Related resources from NHI Mgmt Group

• How should security teams handle critical vulnerabilities when patching cannot happen right away?
• What should organisations do when a critical firewall vulnerability affects devices they cannot patch immediately?
• Why does relying on traditional vulnerability management create risk when organisations cannot reliably see everything exposed to the internet?
• What should organisations do first when their vulnerability remediation process cannot keep up with digital transformation?