Patch Management Best Practice: Fast, Without Outages

Patch management best practice means planning how to install software fixes (patches) on time without stopping the systems people depend on. A patch is a change to installed software, firmware or an operating system that corrects a security or functionality problem, most often a vulnerability that attackers can use to break in. NIST SP 800-40 Rev. 4 describes enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades across an organization, and frames it as preventive maintenance. This guide turns that planning guidance into steps an IT team can follow.

Why patching is hard

Patching pulls in two directions. Deploying faster shortens the time attackers have, but leaves less time to test and raises the risk of disruption. Testing first lowers the risk of disruption but leaves systems exposed for longer. NIST adds that testing uses a lot of staff time and can still miss problems. Many organizations end up patching only when a severe flaw is being widely exploited, which NIST calls reactive patching. The alternative is proactive patching: fixing many vulnerabilities before attackers are likely to use them.

NIST argues that the way of thinking about this needs to change. A disruption caused by patching is often seen as harm the organization does to itself, and a disruption caused by an attack as harm done by someone else. NIST calls that view misleading: disruptions from patching are largely controllable, while disruptions from security incidents are largely uncontrollable. A patch that fails can be handled on the organization's own schedule. A compromise means incident response, and the missing patch usually has to be installed anyway.

Four principles from NIST

NIST SP 800-40 Rev. 4 builds its recommendations on four principles:

• Problems are inevitable, so prepare for them: some patches will cause trouble. Teams should be ready to fix it instead of delaying patches out of fear
• Simplify decision making: assessing every new vulnerability from scratch is not feasible, so decide in advance how each kind of asset (the machines, devices and software an organization uses) will be handled
• Rely on automation: NIST says an organization cannot keep up with patching without it, including in emergencies
• Start improvements now: some changes take years, but other practices can improve in the meantime

Patching is not the only risk response

NIST lists four ways to respond to the risk from a vulnerable piece of software:

• Accept: live with the risk, for example because existing controls already block exploitation or the impact is low
• Mitigate: reduce the risk by patching, disabling a vulnerable feature or upgrading, or by adding controls such as a firewall or network segmentation
• Transfer: share the consequences with another party, for example through cyber insurance or by moving to software-as-a-service (SaaS), where the provider does the patching
• Avoid: remove the exposure entirely, for example by uninstalling the software or retiring the asset

Installing a patch, update or upgrade is the only response that can remove a vulnerability completely without removing functionality. But NIST lists reasons why installing immediately is sometimes not possible: no patch exists yet, the vendor no longer supports the product (end-of-life), the system must wait for a scheduled outage window, or the manufacturer requires delayed updates for safety-related equipment in highly regulated sectors, because of the testing and certification needed first. And even when patching is possible, an organization may choose a different response.

Plan in advance: assets, groups and plans

NIST recommends making the decisions before a new vulnerability appears, in this order: keep an up-to-date inventory of software and assets, define the scenarios you must handle, put every asset into a maintenance group, then write a maintenance plan for each group in each scenario.

On the inventory, NIST says checking monthly or quarterly with a vulnerability scan no longer works. The realistic goal is a close-to-complete inventory that automation keeps current. It must include OT (systems and devices that monitor or control physical equipment, such as in a plant), IoT (everyday network-connected devices such as cameras and sensors) and container assets (a container is a package that bundles an application with what it needs to run).

NIST gives four example scenarios, each needing its own plan:

• Routine patching: the standard process for patches on a regular release cycle. Most patching falls here. NIST warns it is often postponed because installing can interrupt operations, and that postponing makes later emergency patching harder
• Emergency patching: for a severe or actively exploited vulnerability. Run the same process as routine patching, on a much faster schedule
• Emergency mitigation: a temporary measure, such as turning off a feature or isolating a machine, used before a patch exists or when a patch is flawed. It must be replaced by a permanent fix on a set schedule, and the mitigation removed
• Unpatchable assets: for example products the vendor no longer supports, or equipment that must run without interruption. They need long-term protection by means other than patching

A maintenance group is a set of assets with similar characteristics that generally have the same maintenance needs in each scenario: the patch schedule, whether testing is needed, outage restrictions, and how serious a compromise would be. NIST says not to label assets that cannot be patched as "exceptions". Those assets still need maintenance, so they get a group of their own.

NIST's simplified examples show how different the groups can be:

• Laptops for standard users: tolerant of downtime, protected by controls running on the laptops, moderate impact if compromised
• On-premises data center: must follow scheduled outage windows, protected by network controls, high impact if compromised
• Legacy OT assets: no patches available, mitigated by network isolation and physical security, high impact if compromised
• Customer-facing containers in the public cloud: highly tolerant of downtime, high impact if compromised

How to patch without causing outages

For routine patching, NIST suggests phased deployment. A small group of assets gets the patch first and acts as a canary: if it shows problems, the rollout stops, or a temporary mitigation is used while the problem is fixed. In effect, this is how the patch gets tested.

For larger rollouts that affect users directly, NIST gives an example of two rounds: a few days with technically skilled users such as system administrators, then a few weeks with early adopters across the organization who report any problems.

NIST also advises offering some flexibility on when routine patches go in, then forcing installation once a grace period ends. Forcing can be direct, by triggering the install, or indirect, by blocking network access for assets that are still unpatched. A routine patch need not go in immediately, but at some point it must.

Every patch should go through the same steps, following the life cycle described in NIST SP 800-40 Rev. 4:

• Prioritize and schedule: decide which patch is more urgent, and fit the work into the organization's change management
• Validate: confirm the patch is authentic and unaltered before testing or installing it, preferably automatically
• Test: try it before production use. A canary group is one way
• Deploy: distribute and install, restart if needed, and resolve side effects. Plan in advance how to uninstall the patch, revert to the previous version or restore from backup
• Verify: confirm the patch is installed and has taken effect. At scale this needs automation
• Monitor: confirm the patch stays in place: nobody uninstalls it, and no older unpatched software is restored from a backup

Emergencies use the same approach on a faster schedule. NIST says that even then a canary stage can confirm the patch is not corrupted and does not break the software. This stage could last from a few minutes to a few hours, and the full rollout could follow within hours or days, depending on how urgent it is. For emergency mitigations, NIST says to have automated ways to apply them ready in advance, because otherwise too much time may be lost.

Decide what to patch first

Prioritizing needs both the asset and the vulnerability. On the asset side, NIST says each machine's technical and business characteristics matter, not only the software and version. Examples to record are what kind of platform it is, who administers it, what controls already protect it, how important it is to the organization, whether laws or contracts set deadlines for fixing vulnerabilities, and when it may be rebooted.

On the vulnerability side, CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with reliable evidence of exploitation in the wild. CISA says organizations should use it as one input to their prioritization, not the only one.

NIST SP 800-40 Rev. 4 cites the catalog, and CISA's directive BOD 22-01 (a Binding Operational Directive, an order for US federal agencies), which required new entries to be fixed within two weeks. As of October 2026, CISA's page lists BOD 22-01 as revoked and replaced by BOD 26-04, issued on 10 June 2026.

BOD 26-04 is binding only for US federal civilian agencies. Other organizations can borrow its four factors as a model, though CISA does not require them to. The factors set how urgent a fix is:

• Asset exposure: is the vulnerable asset reachable from public networks by unauthenticated or untrusted parties
• KEV status: is the vulnerability in the KEV catalog
• Exploit automation: can an attacker automate every step needed to exploit it
• Technical impact: does exploitation give partial or total control of the asset. Total control includes cases where the exploit reliably reveals login credentials

The BOD 26-04 timelines are not fixed, and they change with the four factors. The only specific figure in the text of CISA's directive page is for the highest-risk category, marked "& forensic triage": remediate or mitigate within three calendar days, and also check whether the system was already compromised (forensic triage). Lower-risk vulnerabilities can wait longer, up to the next system upgrade. The full timeline table is not in the page text, so this guide does not reproduce it.

For how CVSS (a severity score), EPSS (an estimate of how likely a vulnerability is to be exploited) and KEV fit together, see CVSS vs EPSS vs KEV: Prioritizing Vulnerability Fixes.

OT and assets that cannot be patched

In OT, a patch can do more than interrupt a service. NIST SP 800-82 Rev. 3 says patches should be tested offline, and that regression testing (checking that existing functions still work) is advised. A patch may remove a vulnerability yet introduce a greater risk from a production or safety perspective. NIST says patches should be deployed during planned OT outages, and that knowledgeable OT personnel should decide when and how.

Many OT systems run operating system versions the vendor no longer supports, so no patch exists. NIST also notes that not all vendors report vulnerabilities to CISA, so organizations should subscribe to vendor notifications as well.

For assets that cannot be patched, NIST asks for long-term mitigations other than patching, chosen from an approved set for each maintenance group and reviewed in advance by security architects. One example is isolating assets with micro-segmentation (dividing the network into very small, tightly controlled segments). NIST also says to re-evaluate these alternatives periodically, both for whether they still reduce the risk enough and whether the asset is still worth the extra cost. In OT, network zones are how this is done in practice; see IEC 62443 Explained: Industrial Control System Security and Network Segmentation and Micro-segmentation: Start Safely. The ISA/IEC 62443 series also has a part on patch management in industrial systems, Part 2-3.

Measure progress in a way that means something

NIST says a simple number, such as the percentage of vulnerabilities patched across the whole organization, is not actionable. If 10 percent of assets are unpatched, is that the most important assets or the least important? NIST's example (which it labels as notional) instead reports, for each combination of asset importance and vulnerability importance, the percentage patched by the deadline in the maintenance plan, and the mean and median time to patch.

Metrics are only as good as the data under them. NIST warns that scanning monthly makes the number of vulnerabilities look much smaller than it is, and that unauthenticated scans (which do not log in to the machine) generally under-report compared with authenticated scans (which do). Different audiences also need different views, from system administrators to executives.

Common mistakes

• Treating patching as optional work that can wait: NIST calls it a normal cost of doing business. If it is delayed until an incident, the missing patch has to be installed anyway
• Waiting for a big headline before acting: reactive patching means rushing in the middle of a crisis instead of following a plan
• Labeling hard assets as "exceptions": systems that cannot be patched are left with no protection plan, when NIST says to give them a maintenance group of their own
• Postponing routine patches indefinitely: it widens the window for attackers and makes later emergency patching harder, because earlier patches the new one depends on must go in first
• Using a monthly scan as the asset inventory: the inventory goes out of date quickly and the vulnerability count looks smaller than it is
• Reporting one overall percent-patched number: it does not say whether the unpatched machines are important
• Installing patches with no way back: installation can cause side effects that require uninstalling the patch or restoring the system, so plan this first
• Using the same patch rules for IT and OT: NIST SP 800-82 says OT patches should be tested offline and deployed during planned outages
• Leaving temporary mitigations in place: once a patch exists it must be installed and the mitigation removed, with schedules set and enforced for both

Start today

• Start an asset inventory: note what each device is, who administers it, what protects it, how important it is, and when it can be rebooted
• Create maintenance groups, with no "exceptions" group: begin with a few groups like NIST's examples and adjust later
• Write down the four scenarios and who decides: who declares an emergency patch, and who approves it
• Pick a canary group and a deadline you can enforce: for each group, name the machines that patch first, the grace period, and how installation is forced when it ends
• Prepare emergency mitigations in advance: how to isolate a machine or turn off a feature, and how to remove the measure later
• Find the assets that cannot be patched and name what protects them: for example network isolation, with a review date to check it is still enough
• Ask vendors about patching before you buy: NIST's sample questions include how many years they will fix vulnerabilities, how often they release patches, whether a restart is needed, and whether patches can be uninstalled
• Choose metrics tied to asset importance: for example the percentage patched by the deadline, and the mean and median time to patch

To see where your patch and vulnerability management stands, try the self-assessment. For the wider program that covers finding, assessing and closing vulnerabilities, see A Vulnerability Management Program That Works.

Scope and accuracy

The information here comes from NIST SP 800-40 Rev. 4 (April 2022) and NIST SP 800-82 Rev. 3 (September 2023), read from the NIST PDFs (the first in full, the second the relevant sections), and from CISA web pages read on 22 October 2026. NIST SP 800-40 Rev. 4 sets no fixed deadlines for routine patching; each organization sets its own in its maintenance plans. The BOD 26-04 page and the KEV catalog may be updated, so check the current version before relying on them, and for equipment that affects human safety, follow the manufacturer's instructions first.

Knowing which components software contains helps find the systems that need a patch faster; see SBOM and Software Supply Chain Security.

References and further reading

• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning: source of the four principles, four risk responses, scenarios, maintenance groups and metrics
• NIST SP 800-82 Rev. 3: Guide to OT Security: guidance on patching in OT (section 6.2.11)
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk: the four factors and the timelines for US federal agencies
• CISA: Patch Smarter, Not Harder: CISA's post explaining risk-based patch prioritization
• CISA Known Exploited Vulnerabilities Catalog: vulnerabilities exploited in the wild, and CISA's advice to use it as an input to prioritization
• CISA BOD 22-01 (revoked): the original directive that created the KEV catalog, now revoked
• ISA/IEC 62443 series of standards: the parts of the series, including Part 2-3 on patch management