When no patch exists, apply a temporary mitigation: disable the affected feature, isolate the asset, or restrict access. NIST SP 800-40 Rev 4 says organizations should prepare these in advance, because without ready procedures and tools too much time is lost and assets may be compromised.
What counts as a mitigation
NIST says mitigations may require deactivating system functionality, or isolating an asset from other assets. It also says to have automated mechanisms to apply those changes. The point is speed. A change that takes a week to approve is not an emergency mitigation.
Common options, in rough order of disruption:
- Restrict who can reach the service, for example to a VPN or an allowlist.
- Turn off the vulnerable feature or module if the vendor documents how.
- Apply a vendor workaround from the advisory.
- Isolate the host from sensitive networks.
- Take the service offline.
Prefer the vendor's own workaround when one exists, since it has been tested against the product.
Prepare before you need it
You will not design this during an incident. Pre-approve a short menu of mitigations per asset group, and know who can trigger them. NIST's planning model asks you to define a plan per group and per scenario, so the mitigation menu belongs in each group's plan. See maintenance groups.
Questions to settle ahead of time:
- Who can approve downtime for a customer facing service?
- Can you change network rules quickly and safely?
- Do you know every place the affected software runs? Without an inventory, you cannot mitigate everywhere.
Mitigation can also be about a bad patch
NIST points out that mitigations are sometimes needed because of problems with a patch itself. A patch might be flawed and not actually correct the vulnerability, might disrupt other systems, or might even be compromised. If a patch is the problem, a mitigation holds the line while you sort it out.
Plan the exit
NIST says mitigations vary and may or may not need to be rolled back afterward. When a permanent fix such as a patch is available, it must be deployed and the mitigation removed, with schedules set and enforced for both. Record the mitigation in your tracker with an owner and a removal date. Forgotten mitigations are a source of odd outages months later.
Verify, do not assume
After applying a mitigation, test it. Confirm the vulnerable path is closed using the same test the advisory or your scanner uses, and check that the service still works for legitimate users. If you can, watch logs for attempts that match known exploit patterns while you wait for the fix.
Safeguard's zero-day discovery and reachability analysis can help show which of your projects actually call the vulnerable code, which narrows where mitigation is needed. See also how to handle a zero-day vulnerability.
Click through it at your own pace, or open it full screen.
Quick check
Is a WAF rule enough as a mitigation?
It can reduce exposure, but it is a stopgap. Treat it as temporary, test that it blocks the attack path, and still schedule the real patch.
Who decides to take a service offline?
Decide that before the incident. Name the person or role and the conditions in the group plan.
Sources
Last reviewed: 19 October 2026.
