Patch management is inventory, identification, prioritization, deployment and verification. The middle three are what tooling is for. The inventory decides what can be patched at all, and independent verification decides whether it was, which is the step most programs leave out.
- You cannot patch systems you do not know you have
- Prioritize by active exploitation, not by severity score
- A deployment report is a claim. A vulnerability scan is evidence
- The commonest gap is a machine that never rebooted
- Third party software carries more exploited flaws than the OS
On this page
- What a patch is, and why patch management matters
- The five steps of patch management, and which ones are hard
- Prioritizing patches, when everything is urgent
- Deploying patches in rings
- Verifying, which is where patching programs fail
- What to do about the systems that cannot be patched
- Patch management and compliance
- Patching Macs, and why the Windows playbook does not transfer
- Patching through an RMM, and what it does not cover
- Where people go wrong
- Comparison
- FAQ
Why it mattersWhat a patch is, and why patch management matters
A patch is a piece of code a vendor releases to change software that is already installed. Patches reach operating systems, applications, firmware and, increasingly, cloud workloads and container images, and they arrive for three different reasons.
- Security updates close known vulnerabilities, and they are the reason patch management is treated as a security function.
- Bug fixes correct issues that affect stability or performance without being security flaws.
- Feature updates add or change functionality, and are the ones most likely to break a workflow.
Organizations run this as a formal process for three reasons.
Security. A known, unpatched vulnerability is the cheapest way into a network. CISA's alert on WannaCry, dated May 12, 2017, notes that Microsoft had released the security update for the vulnerability on March 14, 2017. Every organization it hit had two months to patch.
Uptime. Bug fixes remove the crashes and performance issues that generate tickets, and a planned maintenance window costs less than an unplanned outage.
Compliance. Frameworks such as PCI DSS and HIPAA expect evidence that security patches are applied on a defined schedule, which is covered below.
Patch management and vulnerability management
The two get confused because they share tools and reports. Vulnerability management is the wider security process: scan the assets, find vulnerabilities, rank them and track remediation. Remediation is sometimes a patch. It can also be a configuration change, a compensating control or retiring the asset.
Patch management is the remediation path for the vulnerabilities a vendor has fixed, and it also handles patches that have nothing to do with security. The scanner finds the issues, the patch management tools fix many of them, and the scanner then confirms the fix.
The processThe five steps of patch management, and which ones are hard
Every vendor describes a patch management lifecycle and they broadly agree on the process. The steps are not equally difficult, and knowing which two carry the weight changes how you spend your time.
Inventory the systems. This is asset management: a list of every endpoint and server in the environment, cloud workloads and virtual machines included, what operating system it runs, what software is installed on it, what version, and how much it matters.
The inventory is genuinely hard, it goes stale weekly, and everything downstream is limited by its accuracy. A patch management tool reports on the systems it knows about, and the system it does not know about is the one that carries the risk.
Identify the available patches. Software vendors publish security patches on their own schedules, most usefully on a predictable day of the month. This step is close to fully automated by any competent patch management tool, which is why it gets the least attention and deserves the least.
Prioritize by risk. More patches and updates exist every month than any team can test and deploy, so the question is which ones go first. This is where judgment lives, and it is covered in its own section below.
Deploy. Push the patch to the systems, in a controlled order, with a way to stop if something goes wrong. Patch management tooling does this well. The design decision is the order, not the mechanism.
Verify. Confirm the patch is present and the system actually rebooted, which the reboot event IDs will tell you along with which component asked for it. This is the step that separates a patch management program from a patch management report, and it is the one most often left out.
The first and the last are the ones that decide whether the middle three were worth doing, and they are the two most patch management programs treat as formalities.
PrioritizationPrioritizing patches, when everything is urgent
A medium sized environment generates more applicable security updates per month than most teams can handle carefully. Prioritizing by risk is therefore the actual work, and severity scores alone are a poor way to do it.
Is it being exploited right now? This is the strongest risk signal available and it is public. The US catalog of known exploited vulnerabilities exists precisely to name the vulnerabilities attackers are using rather than the ones that theoretically score highest. A medium severity vulnerability with working exploit code in circulation outranks a critical one nobody has attacked.
Is the affected system reachable from the internet? A vulnerability in a service published to the world and the same vulnerability on an internal segment are not the same risk. Exposure changes the answer more than the severity rating does.
What does the system hold or control? The domain controller, the backup server and the finance workstation carry more business risk than a meeting room display, so a patch to one is not a patch to the other.
How bad is the failure if the patch breaks something? A patch to a critical line of business system that nobody can afford to have down needs testing that a patch to a laptop fleet does not.
Then look at the severity score. It is a useful tiebreaker and a poor primary sort, because it describes the vulnerability in isolation rather than the risk in your environment. Where that score comes from, and why for most vulnerabilities it may never arrive at all, is the NVD.
| Signal | Weight | Why |
|---|---|---|
| Known to be exploited | Highest | Someone is already using it |
| Internet facing | High | Exposure is the multiplier on everything else |
| Asset criticality | High | What the system holds decides the cost of being wrong |
| Blast radius if the patch fails | Medium | Decides how much testing is needed, not whether to patch |
| Severity score | Low as a sort key | Describes the vulnerability, not your network |
RolloutDeploying patches in rings
Patch testing is one of the standard patch management best practices, and the safe way to do the testing is not a lab followed by a deployment to everything. It is to deploy patches in stages where each stage is real production, and to make the early stages small.
Ring 0, the pilot. The IT team's own endpoints, plus a handful of volunteers across the organization. Updates land here first, and issues surface on people who can describe them properly.
Ring 1, a representative slice. Five to ten percent of the endpoints, chosen from across the organization to include each major hardware model and each significant application. Broad enough to catch issues the pilot cannot.
Ring 2, the general population. Every other system, after the earlier rings have run clean for a defined period.
Ring 3, the servers and the fragile systems. Deliberately last and deliberately slower, in a maintenance window, with a rollback plan and a tested backup.
| Ring | Who is in it | Soak time | Rollback plan |
|---|---|---|---|
| 0, pilot | The IT team and a few volunteers | 2 to 3 days | Reimage, and nobody minds |
| 1, slice | 5 to 10 percent of endpoints | 3 to 5 days | Uninstall the patch |
| 2, general | Every remaining endpoint | The rest of the month | Uninstall, at scale |
| 3, servers | Servers and fragile systems | A maintenance window | A tested backup, decided first |
Two rules make patch rings work rather than merely exist, and teams that skip them end up with a slower version of deploying to everything at once.
Each ring needs a defined soak time. A ring that advances the same afternoon is not a ring, it is a delay. Give it long enough for a patching problem to be noticed and reported.
Emergency security patches jump the queue by decision, not by accident. A vulnerability under active exploitation on an internet facing system is patched immediately, and that risk decision is made explicitly rather than by someone deciding to be helpful.
VerificationVerifying, which is where patching programs fail
A patch management console reports that a security patch was deployed successfully to 847 systems. That is a claim by the patch management tool about what it did, not evidence about what is running.
Three things routinely make that claim untrue.
The system has not rebooted. Many patches are staged and take effect on restart. A user who never restarts their laptop has a system that reports the patch as installed and is still running the vulnerable software. This is the single most common gap in patch management.
The patch failed after the tool stopped watching. Disk space, a pending reboot from an earlier update, a conflicting package. The deployment succeeded and the patch never installed.
The endpoint was off. Laptops, machines on leave, anything intermittent. The report covers what was reachable in the window, and the risk accumulates quietly across the environment.
The fix is to verify from something other than the deployment tool. A vulnerability scan run independently checks what is present on the systems rather than what was sent to them, and the difference between the two numbers is the honest measure of a patching program.
Any patch management program where those two numbers have never been compared is reporting on itself.
ExceptionsWhat to do about the systems that cannot be patched
Most organizations have assets that cannot take security updates: a machine running the software that drives an expensive instrument, an application whose vendor is gone, a device whose manufacturer stopped publishing patches.
Pretending these will be patched eventually is the failure. They need a plan of their own, outside the normal patching cycle.
Write down the patching exception, with an owner and a date. An exception without a review date is a decision nobody ever makes again.
Isolate it on the network. Its own VLAN, with rules naming exactly what it may talk to. If it cannot be updated, it can be surrounded.
Remove what it does not need. No internet access, no email, no browsing, no shared credentials with anything else, so an unpatched vulnerability has nothing to reach.
Monitor it harder than anything else. It is the system where a compromise will succeed, so it should be the one you notice first.
Put a replacement date in a budget. An unpatchable system is a business risk with a due date, and the date only exists if somebody writes it down.
CompliancePatch management and compliance
A large share of patch management programs exist because a compliance framework requires one, and the compliance requirements are worth reading rather than assuming. They differ less across frameworks than most teams expect.
Every major framework asks for the same three things in different words: a documented patch management process, evidence that it runs, and a defined window for critical patches. PCI DSS names a compliance window for critical patches explicitly.
HIPAA speaks in terms of risk analysis and reasonable safeguards, which in practice means being able to show why your patch cadence is the right one for your organization. SOC 2 asks for the patch management process, the evidence, and the exceptions.
The compliance requirement and the security requirement are the same requirement seen from two directions, with one difference that matters across every organization. Security wants the risk gone. Compliance wants proof the process ran.
A program built only for the second produces excellent reports from the deployment tool and never compares them against a vulnerability scan, which is how an organization passes an audit and gets breached through an unpatched system in the same quarter.
Three artifacts satisfy both, and organizations that keep them stop rebuilding the same evidence for every audit. A written patch management policy naming cadence, ownership and windows. A record of which patches were deployed and when. A documented, dated exception list for the systems no patch will reach, with the compensating controls beside each one.
macOSPatching Macs, and why the Windows playbook does not transfer
Everything above assumes the operating system hands you a catalog of patches to approve and push. On a Mac managed through Apple's device management it does not. The update is declared, with a deadline, and the device works out the rest.
On macOS 14 and later, and iOS 17 and iPadOS 17, that is the Software Update declarative configuration. Apple's own description is one line: use the Software Update configuration to enforce software updates at a certain time. It arrives through MDM, the same enrollment that carries the rest of a device's policy.
Automatic installation has three settings. Apple lists them as letting the user choose whether automatic installation is on, turning it off, and turning it on. That setting governs routine updates. It does not govern a deadline.
A deadline overrides the deferral. Apple states that organizations can enforce specific software updates at a chosen time regardless of configured deferrals. So the deferral is the waiting period, the enforcement date is the end of it, and the second one wins.
The deadline is local time. The date is written without a time zone offset and read as the device's own local time, so one configuration enforces at the same hour in every office rather than at the same instant everywhere.
Custom deferral runs from 1 to 90 days, and Apple notes that a major upgrade can be deferred for longer than a routine update. It adds that over-the-air updates are typically available for up to 180 days after release, so a device on the longest deferral can still fetch the update it was held back from.
The practical reading, which is ours rather than Apple's: the rings above map onto deferral windows, with the pilot on a short deferral, the general population on a longer one, and an enforcement date as the backstop behind both.
Apple silicon needs a bootstrap token to finish on its own. Apple: on a Mac with Apple silicon, the Mac uses a bootstrap token (if one is available) to authorize the update or the Mac prompts the user for their credentials.
On a machine nobody is sitting at, a prompt means the enforced update waits. Confirm the management service has escrowed a token for every Apple silicon Mac before relying on a deadline to land.
Where Mac patching usually goes wrong is not in any of that. It is in assuming the Windows tooling covers the Macs because both appear in the same inventory.
Through an RMMPatching through an RMM, and what it does not cover
Most small and midsize companies do not buy a patch management product. They get patching as a module of the remote monitoring and management platform their provider already runs, which is why RMM patch management is what the process above actually looks like in practice.
What the RMM adds over the operating system's own tools. Windows Update and its management services patch Windows and Microsoft products. The gap is everything else on the machine: browsers, PDF readers, conferencing clients, runtimes.
An RMM agent closes that gap through a software catalog, often built on package managers, and that third-party coverage is the main reason the module earns its place.
Coverage differs sharply between platforms, and the difference is not advertised. Tactical RMM's feature list names Windows patch management and nothing else. NetLock RMM says it patches Windows, Linux, macOS and Docker, plus third-party applications through winget, Chocolatey and Flatpak.
Atera lists Chocolatey and Homebrew for software installation. Before assuming a mixed fleet is covered, read the vendor's own list of what each agent patches.
On Macs the RMM is not enough on its own. Enforcing an operating system update on Apple silicon needs the bootstrap token held by a device management service, as the section above describes, so an RMM without an MDM behind it can start Mac updates and not finish them. RMM for Mac covers what the agent can and cannot do there.
The console reports deployment; verification is still yours. An RMM patch report says a job ran and which endpoints failed. That is the start of the verification step, not the end of it, and the failures are the part worth reading, because an agent that lost contact with the console simply does not appear in the run at all.
When a dedicated tool is worth it. Large estates, servers with tight maintenance windows, and companies that need patch compliance evidence for an audit tend to outgrow the module. The patch management software ranking compares the dedicated tools on coverage, automation and reporting.
PitfallsWhere people go wrong
Patching what the tool can see and calling it complete. Coverage is a property of the inventory. A number expressed as a percentage of known endpoints says nothing about the unknown ones, and the unknown ones carry the risk.
Sorting by severity score. It ranks the vulnerability rather than the risk, and it puts theoretical critical issues ahead of the medium severity vulnerability being exploited this week.
Never verifying independently. The deployment report and a vulnerability scan disagree in every environment, and the size of the disagreement is the number worth reporting to whoever owns the risk.
Treating third party software as optional. Operating system patch management is solved by default tooling. The browsers, the runtimes, the PDF readers and the collaboration clients are where the exploited vulnerabilities actually are, and that software needs the same patch management process.
Third party patching belongs in the patch policy as a requirement, with its own tools if the operating system tooling does not reach it.
Letting reboots be voluntary. Staged patches do nothing until restart, so patching without a reboot policy is patching on paper. A deadline and a forced reboot are unpopular and necessary.
Having no rollback plan for servers. The plan is a tested backup and a documented way back, decided before patching and not during the incident.
Skipping firmware and network devices. Switches, firewalls, access points and hypervisors are rarely in the patch management tool and are among the most valuable systems to compromise, which makes their vulnerabilities the highest risk gap in most organizations.
Making emergencies routine. If every month contains an out of band emergency, the normal patching cycle is too slow, and fixing the cycle is the answer rather than more emergencies.
ComparisonWhat a workable cadence looks like for each kind of system
| Criterion | Workstations | Servers | Network devices |
|---|---|---|---|
| Normal cadence | Monthly, automatic | Monthly, in a window | Quarterly |
| Emergency patches | Immediate | Immediate, with a backup | Immediate, with a rollback |
| Ring based rollout | Yes | Yes, servers last | Rarely, too few devices |
| Reboot handling | Forced with a deadline | Scheduled | Scheduled, often out of hours |
| Usually in the patch tool | Yes | Yes | No |
| Where most exploited vulnerabilities live | Third party software | Internet facing services | Remote access and VPN |
The last row is worth sitting with. Patching attention follows the operating system because that is what the tooling covers, and the vulnerabilities being exploited are disproportionately in the browsers and runtimes on the left and the remote access appliances on the right.
FAQFrequently asked questions
What is patch management?
The process of identifying which patches apply to the software your systems run, deciding which to install first, deploying them safely, and confirming they are actually running.
What are the steps in the patch management process?
Inventory the systems, identify available patches, prioritize them by risk, deploy in a controlled order, and verify the result independently of the deployment tool.
How often should patching happen?
Monthly for endpoints and servers as a baseline, quarterly for network devices, and immediately for any critical vulnerability under active exploitation on an exposed system.
How do I decide which patches to install first?
Start with whether the vulnerability is being exploited in the wild, then whether the system is reachable from the internet, then what the machine holds. Severity scores are a tiebreaker.
What is a patch management policy?
A written statement of patch cadence, responsibility, testing requirements, reboot rules and the process for exceptions. Its value to a team is that decisions are made once rather than during every incident, and its value at audit time is that compliance evidence already exists.
Should patches be tested before deployment?
Yes, and rings are a better patch management mechanism than a lab. A pilot group of real users on real work finds what a test system will not.
Why do patched systems still show as vulnerable?
Usually because they have not rebooted. Many patches are staged and take effect only on restart, and the patch management tool reports them as installed either way.
What is the difference between patch management and vulnerability management?
Vulnerability management finds and tracks vulnerabilities, of which only some are fixed by patches. Patch management is the process that applies the fixes. The vulnerability scan is how one checks the other.
What about systems that no patch will reach?
Document the exception with an owner and a review date, isolate the system on its own network segment, remove any access it does not need, monitor it closely, and put a replacement date in a budget. Most compliance frameworks accept a documented exception and none accept an undocumented one.
Do I need to patch third party applications?
Yes, and it is where most of the risk on an endpoint is. Browsers, runtimes and document readers account for a large share of exploited vulnerabilities and their updates are frequently outside default operating system tooling.
How long should a patch take to deploy?
Within the month for routine updates and within days for anything critical under active exploitation. The number worth tracking is the time from release to verified installation across the environment.
Is automatic patching safe?
For workstations, generally yes, and safer than the alternative. For servers and network devices, automatic patching without a window and a rollback plan trades one risk for another.
How do I measure whether patch management is working?
Compare the deployment tool's coverage against an independent vulnerability scan. The gap between them, and the trend in that gap, is the honest measure of the patching program.
How is Mac patch management different?
Mac patch management has two halves. macOS updates are controlled through MDM, using declarative device management to enforce a version by a deadline. Third party applications need a separate tool, because Apple's mechanism does not cover them. A Windows patching product rarely handles either half well.
Keep readingRelated concepts
Read next · Network security IDS vs IPS A system that cannot be patched has to be surrounded instead, and this is one of the things that surrounds it. Open this next12 min- Directory and identity · 13 min Group Policy Explained Reboot deadlines and update behavior on Windows are enforced through policy rather than through the patch tool.
- Endpoint management · 13 min MDM Explained The tool that gets patches onto laptops that are rarely on the office network is the same one managing them.
- Platforms · 10 min What a Kernel Is, and Why a Driver Can Take Down the Machine Why kernel level agents need staging.
- Managed IT · 10 min What Is an MSP, and What Are You Actually Buying What the monitoring and patching half actually involves.
- Windows administration · 10 min How to Update Drivers in Windows 11 and 10, and When to Leave Them Alone Where driver updates come from, how to approve them across a fleet, and how to undo a bad one.
- Operations · 13 min The Blue Screen Is a Decision, and It Leaves Evidence How the offending driver usually got there.
- Windows administration · 10 min How to Stop Windows Update Without Leaving Your PCs Unpatched Pausing, deferring and disabling Windows updates compared, and which one a business should use.
- Vulnerability management · 10 min The NVD, the CVE and the Score That Does Not Decide Anything How the queue gets prioritized in the first place.
- Operations · 10 min The ELK Stack, and the Licensing Question Underneath It Where the record of what was patched, and when, is actually searched.
- Managed IT · 11 min IT Outsourcing, and the Decision Behind It The half of the work that standardizes across every buyer.
- Windows administration · 11 min The DISM Command, and What Each Repair Switch Actually Does What to run when an update leaves the component store damaged.
- Windows administration · 11 min How to Reset a Graphics Driver, and What Windows Already Does for You The driver update that comes back after a rollback, and how to stop it.
- Platforms · 12 min Open Source Operating Systems, and Where the Cost Actually Goes The discipline these systems need as much as any other.
- Operations · 10 min Server Management, and the Routine Nobody Owns Until It Is Too Late The whole recurring routine a server needs, and which parts fail silently when nobody owns them.
- Remote access · 11 min SSL VPN Explained, and the Reason It Needs Patching First The process this device has to be an exception to.
- Operations · 9 min Windows Server End of Life, Version by Version What has to keep working after the upgrade.
- Backup · 12 min Immutable Backups, and the Setting That Decides Whether They Work What shortens the dwell time the retention has to cover.
- Managed IT · 11 min RMM for Mac, and Why the Agent Only Works as Well as the MDM Behind It Why the bootstrap token decides whether an RMM can finish a Mac update unattended.
- Managed IT · 13 min Open Source RMM, and What Each Project’s License Actually Allows Which of the open source RMM projects patch Windows only, and which patch macOS and Linux too.
- Windows administration · 10 min MSI vs EXE, for the Person Who Has to Deploy the Software MSI and EXE installers compared for silent deployment, with the switches and exit codes that matter.
- Windows · 8 min Reboot Event IDs, and the One That Names the Culprit The event that records which patching component did it.