Automated Patch Management and Third-Party Patching: A Practical Guide
Manual patching does not survive contact with a real fleet. At twenty devices you can click through updates on a Friday afternoon. At two hundred, spread across several offices or clients, the only patching that happens reliably is the patching that happens without anyone remembering to do it.
This guide covers what automated patch management actually means, the difference between operating system and third-party application patching, why third-party apps are the part most programs miss, how to automate without handing a bad update the keys to every device at once, and what to look for in tooling.
What Is Automated Patch Management?
Automated patch management is the use of software to carry out the patch lifecycle on a policy you define, instead of a technician performing each step by hand. The lifecycle has six stages, and each can be automated to a different degree:
- Discovery. Devices are scanned on a schedule for missing updates.
- Classification. Each update is tagged by source, category, and severity.
- Approval. Rules decide which updates are approved automatically and which wait for a person.
- Scheduling. Approved updates are assigned to a deployment ring and a maintenance window.
- Deployment. Updates install, and reboots happen inside the allowed window.
- Verification and reporting. Results are recorded per device, failures are surfaced, and compliance reports are generated.
Automated does not mean unattended. The goal is to remove human effort from the steps that need no judgment (scanning, scheduling, installing, recording) so that people spend their time on the steps that do: exceptions, emergency decisions, and rollbacks. A program where every patch installs everywhere the moment it is released is automated, but it is not managed.
OS Patching vs Third-Party Application Patching
Operating system patching covers updates published by the OS vendor: Windows cumulative and feature updates, macOS updates, and Linux distribution packages. There is one vendor per platform, one built-in update mechanism, a mostly predictable release schedule, and consistent severity metadata. It is the most mature part of almost every patching program.
Third-party patching (also written 3rd party patching) covers everything else installed on the device: browsers, PDF readers, archive utilities, runtimes such as Java and .NET, collaboration and meeting apps, remote access tools, and line-of-business software. There are dozens of vendors, each with its own installer format, release cadence, versioning scheme, and idea of what a security advisory looks like.
| OS patching | Third-party patching | |
|---|---|---|
| Vendors | One per platform | Dozens |
| Update mechanism | Built into the OS | Varies per application, or none |
| Release cadence | Mostly predictable | Irregular and frequent |
| Severity metadata | Consistent | Inconsistent or absent |
| Install behavior | Well understood | Varies: per-user installs, running processes, custom installers |
| Typical coverage | High | Often partial |
Why Third-Party Apps Get Missed
Third-party applications are some of the most exposed software on any device. Browsers and document readers process untrusted content from the internet all day. Yet they are routinely the least patched. The reasons are structural, not a matter of effort.
No single update channel. There is no equivalent of Windows Update that covers every application. Each one has to be tracked individually, or covered by a package manager or catalog that does it for you.
Built-in auto-updaters fail quietly. Many applications update themselves, which sounds like the problem is solved. In practice updaters are blocked by standard user permissions, disabled by an old deployment setting, or wait indefinitely for the app to restart. Nobody gets an alert when an auto-updater stops working.
Incomplete inventory. Software gets installed by users, by other installers, and by past technicians. If you do not know an application is present, you are not patching it. Per-user installs in a profile folder are especially easy to miss.
Nobody is logged in. Some third-party update mechanisms only run inside a user session. Servers, kiosks, and machines where the user signed out can go months without updating applications even when the tooling is otherwise working.
Reporting hides the gap. If your patch compliance number only counts OS updates, a device can show as fully patched while running a browser several versions behind. The metric looks healthy because it does not measure the problem.
Fear of breaking a business application. Line-of-business software sometimes depends on a specific runtime version. One bad experience leads to a blanket exclusion that never gets revisited.
The fix is to treat third-party applications as first-class patch targets: inventoried, scanned, approved, deployed through the same rings, and counted in the same reports as OS updates.
How to Set Up Approval Rings and Automation Safely
The risk with automation is speed. A bad update deployed manually hits a few devices before someone notices. A bad update deployed automatically hits all of them. Rings and approval rules are how you keep the speed without the blast radius.
1. Start with inventory and a baseline scan
Before automating anything, find out where you stand. Scan every device for missing OS and third-party updates. Expect the third-party numbers to be worse than you assumed.
2. Define rings
A ring is a group of devices that receives updates at the same stage of rollout. A common structure, with example soak times you should adjust for your own fleet:
| Ring | Who | Example delay after release |
|---|---|---|
| Ring 0 | Your own IT devices | 0 to 2 days |
| Ring 1 | A pilot group at each site or client | 2 to 4 days |
| Ring 2 | General workstations | 5 to 10 days |
| Ring 3 | Servers and business-critical systems | 10 to 14 days, or manual approval |
Make the pilot ring representative. It should include at least one device running each important business application, not just the IT team’s laptops.
3. Set approval rules per ring
Early rings can approve and install automatically. That is their job. Later rings either wait for a deferral period to pass or wait for a person to approve. A reasonable starting rule set:
- Security updates, critical and high severity: auto-approve in all workstation rings, with the ring delay as the safety margin
- Other security and quality updates: auto-approve in Rings 0 and 1, deferral in Ring 2
- Feature updates and major version upgrades: manual approval everywhere
- Servers: auto-approve into a maintenance window only after earlier rings are clean, or keep manual
4. Pin and block deliberately
For applications that must stay on a specific version, pin that version for the affected devices only, record why, and set a date to revisit it. A pin is an exception, and exceptions should expire. Our patch management policy template has an exceptions section you can adapt.
5. Bind deployment to maintenance windows
Approval decides what installs. The maintenance window decides when. Keep them separate so that an auto-approved patch still cannot reboot a server at 2 PM.
6. Define stop conditions
Decide in advance what halts a rollout: a failure rate above a threshold in any ring, a crash report from the pilot group, or a vendor advisory. When a stop condition hits, defer the patch for later rings and investigate. Know how you will roll back before you need to.
7. Keep an emergency path
An actively exploited vulnerability should not wait fourteen days for Ring 3. Define who can compress the rings, what approval they need, and how it gets recorded.
8. Roll out the automation itself in stages
Turn on automated OS patching for workstations first. Add third-party patching next, starting with browsers, where updates are frequent and breakage is rare. Add servers last.
9. Review the results
Automation that nobody reviews drifts. Each month, check failed installs, devices that have not reported in, and patches stuck in deferral. For the wider operational playbook, see Patch Management Best Practices for MSPs.
What to Look for in Tooling
Whether it is a standalone patching product or part of an RMM, evaluate against the problems above.
- OS coverage for the platforms you actually run. Windows, macOS, and Linux if you have them. Ask how each is implemented, because depth varies by platform.
- Third-party coverage, and how the catalog is maintained. Which applications, who curates it, and how quickly new versions appear.
- Patching without a logged-in user. Essential for servers and unattended machines.
- Rings with per-ring approval rules. Including deferral periods and different rules by update category or severity.
- Approve, defer, and reject states, plus version pinning or blocking.
- Maintenance window enforcement that the patch scheduler actually respects.
- Per-device job results. You need to see which devices failed and why, not just a fleet percentage.
- Rollback support, with honest documentation of where it does and does not work.
- Vulnerability context. CVE data attached to patches helps you prioritize. See patch management vs vulnerability management for how the two fit together.
- Multi-tenant scoping for MSPs. An approval for one client should not silently apply to another.
- Reporting that includes third-party apps, with timestamps you can hand to an auditor.
- Control over the native OS updater, so updates do not install outside your policy.
Where Breeze Fits
Disclosure: we build Breeze, an open source RMM with 60+ modules, so treat this section as a vendor describing its own product.
Here is what Breeze does against that list, limited to what is documented in our feature pages and release notes. Patch management covers scanning for updates, approving, rejecting, or deferring them, deploying through patch jobs with per-device outcomes, and rollback, with approvals scoped per organization. Third-party application patching shipped in v0.65.16 with a curated catalog of common applications, CVE data pulled from OSV.dev, and filters that separate OS updates from third-party updates. Third-party patching uses winget, and since v0.92.0 it runs on servers and unattended machines with no user signed in. Update rings provide staged deployment with ring ordering, deferrals, and deadlines. Auto-approval is governed by rings, policies can auto-approve by severity with optional deferral windows, and specific applications can be pinned or blocked by version. Rings and approvals can be defined partner-wide. A configuration policy setting can suppress the built-in Windows Update auto-install so updates flow only through Breeze. Maintenance windows can suppress scheduled patch actions and are resolved through the policy hierarchy. Release notes also document macOS and Linux OS patching fixes, so check the current notes for platform depth before you rely on it.
If you are comparing options, see the free RMM page and pricing.
Run Breeze on your own fleet
Start the Cloud Beta in minutes, or deploy for free with Docker Compose.