NIST SP 800-40 Rev 4 Patch Management Guide: Planning Enterprise Patching

Patching fails in most organisations not because teams lack tools but because nobody has decided, in advance, how each kind of asset will be maintained when a routine update, an exploited zero-day or an unpatchable system turns up. NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, by Murugiah Souppaya (NIST) and Karen Scarfone (Scarfone Cybersecurity), was published as final on 6 April 2022 and replaced Rev. 3 from July 2013. It reframes patching as preventive maintenance, "a standard cost of doing business", and gives a planning method built on risk response scenarios, maintenance groups, maintenance plans and actionable metrics. This guide walks through that method, where identity and credentials fit, how to implement and evidence it, and how it maps to SP 800-53, CSF 2.0 and the CISA KEV catalogue. For the policy wording itself use the Patch Management Policy Template; this page explains the NIST planning model behind it.

Key takeaways

• Four risk responses, one that keeps functionality. NIST lists accept, mitigate, transfer and avoid, and notes that patching and upgrading are the only responses that remove a vulnerability without removing functionality.
• Plan for four scenarios. Routine patching, emergency patching, emergency mitigation and unpatchable assets each need their own pre-agreed procedure.
• Group assets, not exceptions. Assign every asset to a maintenance group with similar maintenance needs, and create groups for unpatchable assets instead of tracking them as an ever-growing exception list.
• Measure against deadlines and importance. NIST favours percentage patched by deadline and mean and median time to patch, broken down by vulnerability and asset importance, over raw counts of open vulnerabilities.
• Buy maintainable software. The final recommendation is to consider software maintenance in procurement, with a sample eight-question supplier questionnaire.

What it is and who it applies to

SP 800-40 Rev. 4 is NIST guidance for enterprise patch management planning. It is aimed at the people who own enterprise maintenance decisions, from technology and security leadership to the teams that run patching, and its examples span laptops, datacentre servers, legacy OT, smartphones and public cloud containers. Federal agencies use it with SP 800-53 controls; other organisations adopt it voluntarily. Patch management technologies are largely out of scope: those are covered by its companion, SP 1800-31, Improving Enterprise Patching for General IT Systems, an NCCoE practice guide published in final form on the same date.

Structure and key requirements

The publication has three sections (introduction, risk response approaches for software vulnerabilities, recommendations), plus mappings to NIST guidance and an acronym list. The core is the software vulnerability management life cycle and the seven recommendations.

The life cycle

1. Know when new vulnerabilities affect your assets, using inventory and vulnerability feeds such as the NVD.
2. Plan the risk response: assess risk, choose the response and decide how to implement it.
3. Execute in four phases: prepare (acquire, validate, test, schedule, coordinate), implement (distribute, install, change configuration, resolve issues), verify (confirm installation and effect) and continuously monitor (confirm the response stays in place).
4. Administer throughout: documentation, audit logging, reporting and change management.

NIST adds four principles: problems are inevitable so be prepared, simplify decision making, rely on automation, and start improvements now.

The four risk responses

The seven recommendations

Maintenance plans by scenario

• Routine: phased deployment starting with canary assets, flexible timing for users, then a grace period after which installation is enforced.
• Emergency patching: the same approach on an accelerated schedule with brief canary testing, often run as part of incident response. See the Emergency Out-of-Band Patching Playbook.
• Emergency mitigation: pre-planned and preferably automated measures such as deactivating a feature or isolating assets, used when no patch exists or the patch is flawed, then replaced by the permanent fix on an enforced schedule.
• Unpatchable assets: pre-approved long-term mitigations, such as micro-segmentation and software-defined perimeters (SP 800-207), with periodic reassessment of risk and cost.

SP 800-40 points to the CISA Known Exploited Vulnerabilities catalogue and Binding Operational Directive 22-01, under which federal agencies must remediate newly added vulnerabilities within two weeks, as a reference point for emergency timing. See the CISA KEV Catalogue Guide.

Identity and NHI requirements

SP 800-40 itself does not address credentials for patching tools, and refers readers to SP 1800-31 for the security of patch management systems. In practice identity is central to doing the plan safely, for three reasons.

• Patching tools are privileged non-human identities: deployment agents, configuration management service accounts and cloud automation roles can install code on every endpoint they manage. Treat them as Tier 0 where they reach domain controllers or identity systems: vault their credentials, scope them per maintenance group and monitor their use. See the Service Account Security Guide and the Privileged Access Management Guide.
• Authenticated scanning needs credentials: NIST stresses accurate low-level data, citing authenticated scanning. Scanner accounts need read access everywhere, so give them least privilege, rotation and an owner.
• Patching does not revoke stolen secrets: the "verify" and "continuously monitor" phases must include credential hygiene when a vulnerability exposed keys or tokens. In the ToolShell SharePoint exploitation, attackers read ASP.NET machine keys, and access persisted after patching until the keys were rotated and IIS restarted. Add "rotate exposed secrets" as a standard step in the emergency patching plan.

Implementation steps

1. Baseline the inventory. Reconcile CMDB, endpoint management, cloud accounts and scanner data so every asset has an owner and a known software list. See the Asset Inventory and CMDB Security Guide.
2. Define maintenance groups. Start with five to ten groups based on technical characteristics and business importance. Put end-of-life and must-run-continuously assets in their own groups.
3. Write one plan per group per scenario. For each, record the patch source, test approach, canary set, deployment window, grace period, enforcement method, rollback method and approver.
4. Set deadlines in a matrix. Build your version of NIST's Table 1, a vulnerability mitigation time matrix that crosses vulnerability importance (low, medium, high, critical) with asset importance (low, moderate, high). Use KEV listing, EPSS or SSVC to set vulnerability importance. See the SSVC Guide.
5. Pilot with canaries. Run each routine plan on a canary ring first and measure failure rate and rollback time before widening.
6. Rehearse emergencies. Run a tabletop for an exploited zero-day with no patch: who decides on mitigation, how isolation is triggered, how quickly the permanent fix follows.
7. Automate measurement. Feed deployment and scan data into dashboards for the metrics below, with authenticated scanning to confirm installation.
8. Update procurement. Add the supplier maintenance questionnaire to purchasing and renewal reviews.

Choosing a response: decision guidance

Small organisations: three or four maintenance groups (staff devices, servers, network edge, cloud services) and vendor-managed patching for SaaS are usually enough; transfer through SaaS is a legitimate response in SP 800-40. Large organisations: expect more groups, per-group owners, and a central function that sets the deadline matrix and reports metrics while platform teams own execution. In both cases the biggest gains come from deciding the emergency mitigation and unpatchable plans before they are needed.

Procurement questions

The sample supplier questionnaire in SP 800-40 covers whether the supplier plans vulnerability updates and how often it releases them, how many years it commits to correcting vulnerabilities, its release schedule, whether it runs a vulnerability disclosure and incident response programme, what emergency mitigations it offers when no patch exists, how disruptive updates are (restarts and reboots), and what pre-release testing and rollback it supports. Put these into tender scoring, not only into contract schedules.

Evidence and assessment

NIST advises against simple counts of unpatched vulnerabilities, because they ignore importance and change with scanner coverage. Report median as well as mean: a few long-running exceptions inflate the mean and hide whether the normal process is fast.

Mapping to other frameworks

NIST's own mapping in the publication is to SP 800-53 (CM-2, CM-3, CM-8, RA-7, SI-2, SR-2, SR-3, SR-5) and to CSF 1.1 subcategories; the CSF 2.0 and CIS columns are an informal cross-walk. The attacker behaviour that timely patching blocks is captured in ATT&CK T1190 Exploit Public-Facing Application, T1210 Exploitation of Remote Services and T1068 Exploitation for Privilege Escalation. See the CIS Control 7 Continuous Vulnerability Management Guide.

Common pitfalls

• Exceptions as a permanent state: hundreds of individual exceptions with no review date. NIST's fix is a maintenance group with its own long-term mitigation plan.
• Treating emergencies as ad hoc: no pre-approved mitigation or isolation steps, so the first hours of a zero-day go on debate.
• Patched but still compromised: closing the hole without hunting for persistence or rotating exposed secrets, as the ToolShell case showed.
• No plan for "no patch yet": in the Ivanti Connect Secure exploitation, VPN zero-days were disclosed on 10 January 2024 but patches arrived on 31 January, and CISA told agencies to rotate stored service account credentials, API keys and certificates. That gap is exactly what the emergency mitigation scenario is for.
• Metrics without importance: one global patch percentage that hides slow remediation on critical assets.
• Buying unmaintainable software: products with no stated support term or rollback, discovered only after deployment.

Practitioner checklist

• Confirm you are using SP 800-40 Rev. 4 (April 2022), not Rev. 3.
• Assign every asset to a maintenance group, including unpatchable assets.
• Approve routine, emergency patching, emergency mitigation and unpatchable plans for each group.
• Publish a deadline matrix by vulnerability and asset importance, with KEV-listed items on the emergency track.
• Report percentage patched by deadline and mean and median time to patch, by importance.
• Vault, scope and monitor the credentials of patching and scanning tools.
• Add secret and key rotation to emergency patching where a flaw could expose them.
• Add the software maintenance questionnaire to procurement.

Standards and references

• NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• NIST: SP 800-40 Rev. 4 (PDF)
• NIST: SP 1800-31, Improving Enterprise Patching for General IT Systems
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• CISA: Known Exploited Vulnerabilities Catalog
• MITRE ATT&CK: Exploit Public-Facing Application (T1190)

Related NHI Mgmt Group resources: Patch Management Guide · Patch Management Policy Template · Risk-Based Vulnerability Management Guide · Emergency Out-of-Band Patching Playbook