Treat a vulnerability as an emergency when it is severe or actively exploited and the affected asset matters. NIST's patching guide splits the work into routine patching, emergency patching, emergency mitigation, and unpatchable assets. Decide the criteria for each before the incident, not during it.
The four scenarios in NIST SP 800-40 Rev. 4
The guide lists these risk response scenarios:
- Routine patching: the standard process for patches on a regular release cycle that have not been elevated to emergency status.
- Emergency patching: the procedure for a crisis, such as a severe vulnerability or one being actively exploited.
- Emergency mitigation: a temporary measure before a patch is available, or when a patch is flawed or disruptive.
- Unpatchable assets: isolation or other methods for systems that cannot easily be patched, such as end of life products.
It also warns that routine patching is often postponed, which creates windows of opportunity and makes emergency patching harder because earlier patches may be prerequisites.
Emergency criteria checklist
A vulnerability usually qualifies for the emergency path when several of these are true:
- There is reliable evidence of exploitation in the wild, such as a listing in CISA's Known Exploited Vulnerabilities catalog.
- The affected component is internet facing or otherwise reachable by attackers.
- The vulnerable code is used in your product or environment.
- Successful abuse would give control of the system or expose sensitive data.
- Exploitation is easy to automate. SSVC includes an Automatable decision point for this.
One yes is usually not enough. Two or three, especially active exploitation plus exposure, are a strong case.
What changes on the emergency path
| Aspect | Routine | Emergency |
|---|---|---|
| Schedule | Regular cycle and outage windows | Accelerated, hours or days |
| Approvals | Normal change process | Pre agreed fast approver |
| Testing | Phased rollout | Small canary group first, then wide |
| Communication | Release notes | Direct notice to owners and leadership |
| Follow up | Normal | Remove any temporary mitigation once patched |
NIST suggests that even in an emergency it may help to deploy a patch to a small number of canary assets first, a period that could last from a few minutes to a few hours.
When to mitigate first
If no patch exists, or the patch is risky, apply a mitigation: disable the feature, restrict access, add a gateway rule, or isolate the asset. NIST says to plan for replacing emergency mitigations with permanent fixes, and to set and enforce schedules for both patch deployment and removal of the mitigation.
Prepare before you need it
Write down who can declare an emergency, who approves, how to reach owners out of hours, and what mitigations are pre approved for each class of asset. NIST notes that without the processes and tools for mitigation, too much time can be lost.
Try it yourself
Open the demo and see how a fix that is already available is separated from findings that still need a workaround. Look at how that changes which items are urgent.
Click through it at your own pace, or open it full screen.
Quick check
Is every critical CVSS score an emergency?
No. Severity alone does not decide it. Exploitation evidence, exposure, and whether your code is affected matter as much.
Do emergency patches skip testing?
Not entirely. A short canary rollout is still recommended where possible.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning (also available as a PDF)
- CISA Known Exploited Vulnerabilities Catalog
- CISA, SSVC guide
Last reviewed: 19 October 2026.
