What is patch management?

The WannaCry ransomware attack is a textbook example of the gap patch management exists to close. Patch management is the process of identifying, testing, deploying, and verifying software updates across an organization’s devices, servers, and applications. Patches fix security vulnerabilities, resolve bugs, and sometimes add features. A good patch management program makes sure the most dangerous flaws get fixed first, updates don’t disrupt the business, and every change is documented for audits.

Patch management vs. vulnerability management vs. configuration management

People mix these three up. A house analogy helps:

You need vulnerability management to know where the problems are and patch management to fix them, ideally working from the same inventory.

What patch management should cover

Plenty of teams patch Windows and stop there. But a forgotten printer or an old PDF reader is as usable an entry point as an unpatched server. A complete program covers:

• Operating systems: Windows, macOS, and Linux updates that fix kernel vulnerabilities and stability issues.
• Third-party applications: browsers, PDF readers, office suites, and media players. Attackers target these often, and they tend to be patched less consistently than the OS.
• Firmware and hardware: BIOS, UEFI, network devices, printers, and IoT devices. This is the category most programs miss, and unpatched firmware can let malware survive a full OS reinstall.
• Cloud and virtual workloads: under the shared responsibility model, the cloud provider secures the infrastructure and you patch the VMs, containers, and software running on top of it.

The growing vulnerability problem

WannaCry spread through a flaw in Windows’ file-sharing protocol, SMBv1. The UK’s Department of Health and Social Care later estimated the cost to the NHS at £92 million: £19 million in lost output and £73 million to restore data and systems (Computer Weekly). FedEx, Honda, and Nissan were hit too. The attackers used a known flaw against machines that had missed a two-month-old update.

Since then, the problem has grown. Verizon’s 2026 Data Breach Investigations Report found that exploiting vulnerabilities is now the most common way attackers get in, at 31% of breaches, up from 20% a year earlier. It’s the first time in the report’s 19-year history that vulnerability exploits have overtaken stolen credentials.

Volume is climbing too. In June, FIRST (the Forum of Incident Response and Security Teams) raised its 2026 forecast to about 66,000 CVEs, up from a February median of 59,427.

Most of those will never matter to you. CISA’s Known Exploited Vulnerabilities (KEV) catalog, the list of flaws confirmed to be under active attack, had 1,587 entries as of May 1, 2026. When FIRST filtered this year’s surge down to KEV entries and vulnerabilities with an EPSS score above 10%, the actionable patching burden stayed flat. So the total keeps climbing, but the urgent subset has stayed about the same size, which is why we’d argue prioritization is now the most important skill in patch management.

Speed is where most teams fall behind. Organizations took a median of 43 days to remediate known exploited vulnerabilities last year, up from 32, and only 26% of those vulnerabilities were fully remediated (Verizon DBIR 2026). Against the 7-day target we recommend for critical patches (see the SLA table below), that’s a long window.

Visibility makes it worse. An Enterprise Strategy Group study found that 34% of devices were unmanaged at organizations with 1,000 to 4,999 devices: remote laptops that rarely connect to the VPN, shadow IT apps, forgotten cloud VMs. Tool sprawl is a big part of it. Half of organizations using more than 15 endpoint tools had over 20% of their devices unmanaged, compared to 5% for teams using fewer than 5.

The balancing act: speed vs. stability

Patch too aggressively and a bad update can crash hundreds of machines. ITIC’s 2024 survey found that for over 90% of mid-size and large enterprises, a single hour of downtime costs more than $300,000. Patch too cautiously and known vulnerabilities stay open.

In most cases, the second risk is the bigger one. IBM’s 2025 Cost of a Data Breach Report put the global average breach at $4.44 million, and the U.S. average at a record $10.22 million.

Equifax is the cautionary tale here. According to the FTC, the company was alerted in March 2017 to a critical vulnerability in its consumer dispute database, ordered it patched within 48 hours, and didn’t discover the patch had never been applied until July, after attackers were already inside. Equifax agreed to pay up to $700 million in a settlement with the FTC, the CFPB, and 50 states and territories (FTC).

Hybrid work makes all of this harder. A laptop on coffee-shop Wi-Fi needs the same patches as a server at headquarters, and it’s much harder to reach.

Who feels this the most

Hospitals, banks, and factories that run around the clock have the least room for maintenance windows, since even a short outage can delay patient care or stop a production line. Healthcare and finance also carry regulatory risk, where a patching failure can lead to fines or legal liability. And large organizations with servers, cloud workloads, and remote laptops spread across regions often struggle with the most basic question: what do we have, and is it patched?

The benefits of effective patch management

The main benefit is security. Every patched vulnerability is one less way in for the ransomware groups that scan the internet for unpatched systems.

The rest are operational. Updates fix many of the bugs behind application crashes and blue screens, so people lose less time to broken tools. Some patches include performance fixes, which can stretch the useful life of older hardware a little. Vendors often ship new features alongside security updates, so staying current keeps those within reach. And a documented, consistent process is what auditors want to see.

The patch management process

Every effective program follows the same basic lifecycle:

1. Discover: Maintain a real-time inventory of every device and application.
2. Assess: Identify which available patches apply to which systems.
3. Prioritize: Rank patches by exploitability and business impact, not release order.
4. Test: Deploy to a small pilot group to catch compatibility problems.
5. Deploy: Roll out in stages during approved maintenance windows.
6. Verify: Confirm patches installed correctly and systems are stable.
7. Report: Document what was patched, when, and by whom.

Many teams run this cycle around Microsoft’s Patch Tuesday (the second Tuesday of each month) and handle critical out-of-band patches as they arrive. Whether a monthly rhythm is fast enough depends on what you run.

How to build a patch management program in 5 steps

1. Build your foundation

Before you deploy a single update, you need four things in place:

• An asset inventory that includes every computer, server, printer, IoT device, VM, and cloud workload. Automated, real-time discovery is the most practical way to find shadow IT.
• Criticality tags. A customer-facing database carries far more risk than a breakroom laptop, so tag systems by business impact and data sensitivity.
• Agreed maintenance windows, set in advance so reboots don’t land during peak hours or month-end close.
• A tested rollback plan. A patch is only as safe as your ability to undo it, so have point-in-time recovery ready and aim to restore in minutes.

» Don’t miss these other patch management best practices

2. Design your workflow

Start with risk. Patch vulnerabilities in CISA’s KEV catalog first, then remote code execution flaws and anything on internet-facing systems. Cosmetic fixes and low-severity issues on isolated machines can wait for the regular cycle.

Then set deadlines by severity instead of one flat 30-day goal. These are the tiers we recommend:

Stage every rollout. Send the patch to a pilot group of non-critical, tech-savvy users first, so a bad update hits ten people and not ten thousand.

Log what was patched, when, who approved it, what the pilot showed, and what went wrong. Auditors will ask for it, and so will whoever troubleshoots the next failed update.

3. Set clear success metrics

Four numbers tell you whether the program is working, and they’re what leadership will want to see:

• Mean time to remediate (MTTR): the time from patch release to full deployment, measured against your SLA tiers.
• Patch compliance rate: the share of your fleet that’s fully up to date. Many teams target 95% or higher.
• First-pass success rate: the share of patches that install correctly on the first try. Mature automated programs typically reach 85% to 90%.
• Time to detect: how quickly you learn about a new critical vulnerability. With continuous scanning, this should be hours.

» Learn more about the benefits of IT benchmarking

4. Choose the right platform

Whatever you choose should take the repetitive work off your team. Look for policy-based deployment, so patches roll out on the schedule and rules you define (the Atera platform lets you build patch deployment profiles that run in the background). You’ll also want Windows, macOS, Linux, and third-party app coverage in one console, which Atera provides in a single view. Built-in compliance reporting saves you from assembling audit trails by hand. And vulnerability data should feed directly into patch decisions, so priorities come from real risk and not the calendar.

Manual vs. automated vs. autonomous patching

With autonomous IT, your team sets the rules and priorities, and AI agents do the execution within them.

Atera brings this into patch management in two ways. AI Copilot helps technicians generate custom PowerShell scripts for complex patching scenarios from a plain-language description. And when a patch causes problems for end users, Robin by Atera steps in. Robin is an AI technician that remediates Tier-1 and complex Tier-2 technical incidents end to end by autonomously taking real actions on devices, servers, and networks, without needing a technician in the loop. So an app that stops working after an update can be fixed before the ticket reaches your help desk.

» See these best enterprise AI platforms for IT management

5. Adapt your strategy for always-on environments

Hospitals, data centers, and trading platforms can’t wait for a standard maintenance window. If you run a high-availability cluster, patch one node while its twin carries the load, check it, then switch and patch the second. On Linux, live patching tools like TuxCare and Canonical Livepatch apply kernel security fixes without a reboot. For everything else, the rule is simple: if a system can’t be patched without downtime, it needs a failover, so you can take the primary offline while users stay on the secondary.

» » Ready to take control of patching? Start a free trial with Atera