Most patching is routine. When a vulnerability is severe or already exploited, it becomes emergency patching. If no usable patch exists, you use emergency mitigation. If the asset can never be patched, you plan long-term isolation. NIST SP 800-40 Rev 4 names these four risk response scenarios.
Why name the scenarios at all
Teams that treat every patch the same end up with two failure modes. Either everything is urgent and engineers burn out, or nothing is urgent and the queue grows. NIST asks organizations to define the scenarios ahead of time so that the choice is made by a plan, not by whoever is loudest on the day.
Scenario 1: routine patching
This is the standard procedure for patches that arrive on a regular release cycle and have not been raised to emergency status. NIST notes that most patching falls here. It also warns that routine patching is often postponed because installs can interrupt operations, for example through reboots. Postponing it gives attackers more windows of opportunity, and it makes later emergency patching harder, because earlier patches that new ones depend on must be installed first.
Scenario 2: emergency patching
This is the procedure for a crisis, such as a severe vulnerability or one that is being actively exploited. If any vulnerable asset is already compromised, emergency patching may be part of incident response. NIST suggests using the same general approach as routine patching on a much faster schedule. Even then, a short canary stage on a few assets can confirm the patch is not corrupted and does not break the software. That stage could last minutes to a few hours, with the wider rollout over the following hours or days.
Scenario 3: emergency mitigation
Sometimes the patch is not ready, or the patch itself is the problem. NIST describes cases where a patch is flawed and does not fix the vulnerability, disrupts other systems, or is even compromised. In those cases you apply a temporary mitigation, such as turning off a feature or isolating an asset. The key planning point is that the mitigation is temporary. Once a permanent fix exists, schedules should be set and enforced for both deploying the patch and removing the mitigation.
Scenario 4: unpatchable assets
Some assets cannot be patched in a reasonable time. The vendor may not provide patches because the product is end of life, or the system may need to run uninterrupted. NIST says these assets need an approved set of long-term mitigations for each group, such as isolation, and they need to be reviewed again over time. A new vulnerability in an unpatchable asset may require a different mitigation than before.
A simple way to pick the scenario
- Is there evidence of exploitation, or is the severity extreme for an asset you expose? Go to emergency.
- Is a trustworthy patch available? If not, go to emergency mitigation.
- Can the asset take patches at all? If not, go to the unpatchable plan.
- Otherwise, routine.
Write the answers down per asset group, not per incident. For the exploitation signal, see how to use exploit data in prioritization and the CVE, CVSS, EPSS and SSVC comparison.
Click through it at your own pace, or open it full screen.
Safeguard can help with the first step, knowing what you run, through SBOM and dependency scanning, reachability analysis and policies that gate builds. The free scan at https://gold.safeguard.sh/scan shows where you stand.
Quick check
Is a vulnerability with a CVSS score of 9 always an emergency?
No. Severity is one input. Exploitation evidence and whether the vulnerable component is exposed in your environment decide whether it is an emergency or a routine item with a short deadline.
Can a mitigation replace a patch permanently?
For ordinary assets, NIST expects mitigations to be replaced by permanent fixes. For unpatchable assets, long-term mitigations are the plan, and they need periodic review.
Sources
- NIST SP 800-40 Rev 4, Guide to Enterprise Patch Management Planning
- NIST SP 800-40 Rev 4 full text (PDF)
Last reviewed: 19 October 2026.
