NIST SP 800-40 Rev. 4: enterprise patch management planning, explained

NIST Special Publication 800-40 Revision 4, "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology," defines enterprise patch management as "the process of identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades throughout an organization." Published in April 2022 by Murugiah Souppaya (NIST) and Karen Scarfone (Scarfone Cybersecurity), it deliberately steps back from patch-management technology — the focus of its 2013 predecessor — to patch-management planning, treating patching as "a cost of doing business" and preventive maintenance for technology rather than a disruption to be tolerated only when forced.

Four versions, two different jobs

SP 800-40 has been rewritten with a different emphasis each time: the original 2002 edition, Procedures for Handling Security Patches, covered basic patching mechanics; Version 2.0 (2005), Creating a Patch and Vulnerability Management Program, added process and metrics; Revision 3 (2013), Guide to Enterprise Patch Management Technologies, assumed readers already understood the basics and focused on implementing patch-management tooling. Revision 4 deliberately reverses that trajectory: the document states it "is based on the assumption that, in the overall scope of enterprise patch management, organizations would benefit more from rethinking their patch management planning than their patch management technology," and discusses specific products only minimally, pointing instead to the companion NIST SP 1800-31 for technology implementation detail.

Four ways to respond to a vulnerability

Section 2.1 frames patching as one of four possible risk responses to a software vulnerability, not the only one:

Response	What it means
Accept	"Accept the risk from vulnerable software as is" — rely on existing controls, or judge the potential impact low enough to need no action
Mitigate	"Reduce the risk by eliminating the vulnerabilities" (patch, disable the feature, upgrade) "and/or deploying additional security controls" (firewalls, network segmentation)
Transfer	"Reduce the risk by sharing some of the consequences with another party" — cybersecurity insurance, or moving to a SaaS provider that owns the patching
Avoid	"Ensure that the risk does not occur by eliminating the attack surface" — uninstall the software, decommission the asset, or disable the vulnerable capability

By default, an organization accepts risk simply by continuing to run software it has not patched. Patching, updating or upgrading are the only responses, per the document, that can eliminate a vulnerability outright "without removing functionality" — every other response trades away some capability, cost or risk-ownership instead.

The patching life cycle

SP 800-40 describes a software vulnerability management life cycle that applies across all four risk responses: know when a new vulnerability affects your assets (via vendor feeds, researchers, or the NVD); plan the risk response (assess the risk, choose a response, decide how to implement it); then execute it through four common phases — prepare (acquire, validate and test the patch, or prepare a replacement asset), deploy (distribute, validate and install the patch, and change configuration/state as needed), verify (confirm the response actually took effect), and monitor (continuously confirm the patch, or its removal of the vulnerable asset, stays in place and is not reversed by a user, an attacker, or a restored backup).

Four scenarios to plan for, not react to

Section 3.3 sets out four risk-response scenarios every organization should have a maintenance plan for in advance, rather than improvising when one occurs:

Scenario	What it covers
Routine patching	The standard, regular-release-cycle procedure — most patching, but also the kind most often "postponed and neglected" because it lacks urgency
Emergency patching	An accelerated version of routine patching for a severe or actively-exploited vulnerability
Emergency mitigation	A temporary measure (disabling functionality, isolating an asset) used before a patch exists, to be replaced by a permanent fix once one is available
Unpatchable assets	Long-term isolation or other mitigation for assets that cannot be patched at all, e.g. end-of-life vendor support

SP 800-40 recommends phased, canary-first rollouts even for routine patching — deploying to a small subset of assets first to catch problems before a wider rollout — and the same approach on an accelerated timeline for emergency patching.

Maintenance groups instead of exceptions

Rather than labeling hard-to-patch assets as one-off "exceptions," SP 800-40 recommends assigning every asset to a maintenance group: a set of assets sharing similar technical and mission characteristics (software to patch, outage restrictions, existing compensating controls, impact if compromised) that therefore need the same maintenance plan for each of the four scenarios above. The document's own worked examples include groups like "legacy OT assets" (unsupported software, network isolation and physical security as the only mitigations, high impact if compromised) and "containers with customer-facing applications in the public cloud" (highly tolerant of downtime, but high impact if compromised) — illustrating that a maintenance group is defined by shared maintenance needs, not just by device type.

Metrics that are actually actionable

SP 800-40 warns that overly simple patch metrics (e.g. a single "percent patched" number) are not actionable because they obscure whether the organization is handling its most important risk first. It illustrates a more useful approach with a notional matrix cross-referencing vulnerability severity against asset importance, reporting the percentage of assets patched by each maintenance plan's deadline plus average and median time-to-patch for each combination — making it possible to see, for example, whether high-severity vulnerabilities on high-importance assets are being remediated meaningfully faster than low-severity ones on low-importance assets, rather than just tracking an aggregate completion rate.

Where CISA's KEV catalog fits in

SP 800-40 points directly at CISA's Known Exploited Vulnerabilities (KEV) Catalog as a prioritization input, noting that "CISA's Binding Operational Directive 22-01 requires federal agencies to remediate new vulnerabilities added to the catalog within two weeks," while "other organizations may voluntarily choose to use the catalog to help prioritize their patching efforts." That directive has since been superseded — see our KEV and EPSS prioritization guide for the current BOD 26-04 risk-tiered deadlines and how KEV and FIRST's EPSS combine into a prioritization signal that feeds directly into the "plan the risk response" step of SP 800-40's life cycle.

Where this sits next to other NIST guidance

Patch management is the execution layer that acts on signals from elsewhere in the NIST stack: it needs the up-to-date asset and vulnerability visibility described in NIST SP 800-137's continuous monitoring (ISCM) guidance to know what to patch in the first place, draws on SP 800-53 controls such as SI-2 (Flaw Remediation) and CM-8 (System Component Inventory) that SP 800-40's own appendix maps directly to its recommendations, and complements rather than replaces a severity or exploitation-based prioritization layer such as CVSS or SSVC.

A workable starting point

1. Define your maintenance groups before the next emergency, not during one — group assets by shared patching constraints and impact, not just by device category.
2. Write a maintenance plan for all four scenarios, including "unpatchable," so a legacy or unsupported asset has a documented mitigation rather than an undocumented gap.
3. Use canary rollouts for routine patching to catch operational problems before they affect the whole fleet, and the same pattern, compressed, for emergency patching.
4. Track time-to-patch by severity and asset importance together, not as a single aggregate number, so slow remediation of your highest-risk combinations doesn't hide behind a healthy overall percentage.

SoftWSP's device and firmware security work can help turn a firmware SBOM and vulnerability feed into a maintenance-group-based patching plan, rather than a flat, unprioritized CVE list: see device & firmware security services.

This guide summarises a public NIST publication; it does not constitute legal or compliance advice.