A patch management tool is the one system allowed to install code on every laptop and server you own, so buying one is a decision about trust and control as much as catalogue size. Most products patch Windows well; they differ on third-party applications, Linux and macOS depth, catalogue speed, rollout safety and whether their reports prove a fix is installed. This vendor-neutral guide is for endpoint, infrastructure and vulnerability management teams running an RFP or replacing a tool, including managed service providers choosing remote monitoring and management (RMM) patching, and ends with a proof of concept. For the process itself (SLA tiers, rings, emergency patching) see the Patch Management Guide.
Key takeaways
- Coverage means the catalogue, not the OS list. Score products against your own top third-party applications and measure how many days new releases take to reach the catalogue.
- Prioritisation needs exploitation data. The tool should rank work using the CISA Known Exploited Vulnerabilities (KEV) catalogue, EPSS and your asset context, not CVSS alone.
- Deployment control is what lets you go fast. Rings, maintenance windows, reboot handling and tested rollback let you shorten deadlines without outages.
- Reports must prove installation. A "succeeded" job is not a patched device; demand verified installed state, pending-reboot status and percentage patched by deadline.
- The patch console is a tier-zero system. Anyone controlling it can run code everywhere, so admin RBAC, package signing, agent supply chain and the tool's privileged service accounts belong in the evaluation.
Define requirements
Start from an inventory, not a feature list: devices by OS and version, servers by role and change constraints, the 50 most installed third-party applications, devices that rarely connect to the corporate network, and anything air-gapped.
- Platforms in scope: Windows client and server, macOS, the Linux distributions you run, and whether firmware, hypervisors or network devices belong in the same tool.
- Existing stack: your unified endpoint management (UEM) platform, vulnerability scanner, IT service management (ITSM) and change process, configuration management database (CMDB) and SIEM. Decide early whether patching comes from the UEM, a dedicated tool or both. See the UEM Buyer's Guide.
- Policy and deadlines: write the SLA tiers first, then test whether each product can enforce and report them. NIST SP 800-40 Rev. 4 recommends measuring "the percentage of assets that were patched by the corresponding maintenance plans' deadlines" and warns that simple counts of vulnerabilities patched "are not actionable".
- Control obligations: NIST SP 800-53 SI-2 and its enhancements SI-2(2) Automated Flaw Remediation Status, SI-2(3) Time to Remediate Flaws, SI-2(4) Automated Patch Management Tools and SI-2(5) Automatic Software and Firmware Updates; CIS Controls v8.1 Safeguards 7.3 and 7.4 (automated OS and application patching, monthly or more often); ISO/IEC 27001:2022 Annex A 8.8 and 8.32. See the Vulnerability Management Guide.
| Delivery model | Best fit | Watch for |
|---|---|---|
| Patching module inside the UEM | Laptop-heavy, cloud-managed estates already standardised on one UEM | Thin third-party catalogue, weak server and Linux support |
| Dedicated cloud patch tool with an agent | Mixed OS estates and remote workers; strong third-party focus | Agent coverage gaps, internet dependency for servers in restricted zones |
| On-premises server-based tool | Regulated, disconnected or bandwidth-constrained estates; explicit server approvals | Infrastructure to run and patch; slower catalogue updates |
| Agentless (credential-based) patching | Servers where agents are not allowed, appliances, small estates | Privileged scanning credentials stored centrally, no coverage when offline |
| Remote monitoring and management (RMM) patching | Managed service providers serving many client tenants | Tenant separation, one console reaching every customer |
Size changes the answer. A small organisation gains most from automatic updates, a good third-party catalogue and deadline enforcement in a cloud tool. A large or regulated estate also needs maintenance groups with owners, server orchestration, scoped RBAC, full API coverage and audit evidence.
Evaluation criteria
Weight the criteria to your inventory and test each one on real devices.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| OS coverage | Windows, macOS and each Linux distribution you run, with feature and quality updates, drivers and firmware where relevant | Linux or macOS limited to inventory or scripts you write |
| Third-party catalogue breadth | Covers most of your top 50 applications, including per-user installs and both 32-bit and 64-bit; custom package support for the rest | Catalogue size quoted as a number with no list; no per-user application handling |
| Catalogue speed and quality | Published median days from vendor release to catalogue; documented testing; fast withdrawal of bad packages | No latency figures or test process |
| Prioritisation | KEV flag, EPSS score, CVSS, asset criticality and exposure in one view; automatic emergency workflow for KEV items | CVSS-only severity; KEV checked by hand |
| Deployment rings and windows | Rings with automatic promotion, halt criteria, maintenance windows per group, deadlines and grace periods, pause | Single "deploy to all" job; windows only per device |
| Reboot handling | Pending-reboot detection, user deferral limits, forced restart at deadline, server sequencing, support for hotpatch and kernel live patching | Reports "installed" while the device still needs a restart |
| Rollback | Uninstall or version rollback per ring, pre-patch snapshot hooks for servers, previous kernel kept | Rollback means "deploy the old installer yourself" |
| Remote and offline devices | Internet-based patching without VPN, peer-to-peer caching, bandwidth throttling, offline import for air-gapped sites | Devices must reach a corporate server; no catch-up when a laptop returns |
| Servers and Linux | Pre and post scripts, cluster and application-aware sequencing, local repository mirrors, approval per maintenance group | Workstation logic applied to servers; no change ticket link |
| Compliance reporting and SLA tracking | Percentage patched by deadline per group and tier, median time to remediate from vendor release, verified installed state, exports and API | Job success counts; dashboards that cannot be exported |
| Integrations | Scanner reconciliation, UEM, ITSM change tickets, CMDB, SIEM events | One-way CSV exports; integrations needing an admin account |
| Security of the tool | Scoped RBAC, phishing-resistant MFA and SSO, approval for scripts and custom packages, signed catalogue and agent, admin audit log | Single global admin role; unsigned custom packages; shared API keys |
Prioritisation and reboots deserve a demonstration
KEV lists a vulnerability only when it has a CVE ID, "reliable evidence" of active exploitation and "a clear remediation action", which makes it a low-noise emergency trigger. EPSS adds a daily 0 to 1 probability that a CVE "will be exploited in the wild in the next 30 days", but FIRST states that "EPSS should never be treated as a risk score", so the tool must combine it with asset exposure and value rather than sort by it alone. On reboots, Windows Server hotpatch installs security updates "without having to restart", but quarterly baseline updates still need one; Red Hat says kernel live patching aims "to reduce the required reboots for security-related patches, not to eliminate them entirely". A tool that hides those restarts reports servers as compliant when they are not.
Catalogue integrity and agents
SP 800-40 says "a patch's authenticity and integrity should be confirmed, preferably by automated means". Microsoft's documentation for third-party updates in Configuration Manager is a useful benchmark for what to ask any product: custom catalogues "must use https and the updates must be digitally signed", catalogue signing certificates must be reviewed and approved, sync fails if a signing certificate changes until it is re-approved, and the product "doesn't allow unsigned updates to be published". Agents report continuously, including off-network; agentless tools need stored privileged credentials and network reach to every target. Many estates use agents for endpoints and agentless for restricted servers.
Where identity fits: the patch tool is a privileged NHI hub
MITRE ATT&CK T1072 Software Deployment Tools notes that access to enterprise-wide endpoint management software "may enable an adversary to achieve remote code execution on all connected systems", including effects "such as wiping the hard drives on all endpoints"; one listed procedure used "a patch management system for an anti-virus product" to distribute wiper malware. The Stryker cyberattack showed the same pattern through a device management console. Evaluate:
- Admin RBAC: roles scoped by device group and action, script and custom package deployment separated from routine approvals, and a second approver for tenant-wide jobs. See the Privileged Access Management Guide.
- Privileged service accounts and API clients: agentless scanning, distribution and deployment accounts often hold local admin rights on every server, and integrations call the API with keys. Prefer per-zone accounts, no interactive logon, vaulted and rotated credentials, read-only API scopes by default and an exportable list. See the Service Account Security Guide.
- Vendor and MSP access: after the July 2021 ransomware attacks through a vulnerable MSP remote management product, CISA advised customers to keep MSP accounts out of administrator groups, limit them to managed systems and disable them when unused. Apply the same to vendor support access.
- Supplier security: the CISA Secure by Demand guide suggests asking for SSO at no extra cost, MFA by default, no default passwords, security logs kept for at least six months, an SBOM and a vulnerability disclosure policy.
Questions to ask vendors
- Show us your catalogue entries for our top 50 applications. For the last ten critical third-party releases, how many days passed between vendor release and catalogue availability?
- How do you test, sign and verify packages, and how quickly have you withdrawn a faulty one?
- How is a device that installed an update but has not restarted shown in reports and SLA figures?
- Show the workflow when a CVE affecting our estate is added to KEV.
- Following NIST SP 800-40's question, "Do you provide rollback capabilities for uninstalling patches?" Demonstrate it per ring on Windows, macOS and Linux.
- How do remote laptops that never use the VPN, and air-gapped sites, receive content and report status?
- How does the agent update itself, how is it signed, and what privileges does it run with? Do you publish an SBOM for it?
- Which roles and API scopes can deploy scripts or custom packages to all devices, and can those actions require a second approver?
- For MSPs: can one compromised technician account reach every client tenant?
- What is the pricing unit (workstation, server, per tenant), and are third-party catalogue, Linux, servers, reporting or API access add-ons?
Red flags
- Third-party coverage described by catalogue size only, with no list or latency data.
- Compliance figures based on deployment job success rather than verified installed state.
- No rings, halt criteria or rollback, or rollback that depends on re-deploying old installers by hand.
- Agentless mode that needs a domain-wide admin account stored in the console.
- Any administrator can push scripts or unsigned packages to every device with no approval and no alert.
Proof of concept
- Scope it: enrol each OS and version, two server roles with different windows, remote laptops off VPN and any air-gapped device. Agree pass criteria first.
- Test the catalogue: install old versions of ten of your most common third-party applications, including per-user installs, and confirm detection and update.
- Run rings: configure pilot, limited and broad rings with deadlines and windows, deploy a monthly cycle, then halt the second ring and roll back one update on each OS.
- Test reboots: leave devices pending restart and check reports show them as not compliant.
- Simulate a KEV emergency: time detection, prioritisation and canary deployment for a KEV-listed CVE on a pilot device.
- Reconcile: compare the tool's patched state with an authenticated vulnerability scan and an ITSM ticket.
- Attack the console: try deploying a script to all devices from a scoped admin and an API client; confirm denial or approval and SIEM alerts. List every privileged credential the tool uses.
- Measure and decide: percentage patched by deadline per ring, median days from vendor release to install, catalogue coverage of your top 50 applications, devices reporting within 24 hours, and identities able to deploy to all devices. Keep these metrics after go-live.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Patch Management Guide · Vulnerability Management Guide · UEM Buyer's Guide · Zero-Day and Exploited Vulnerabilities Guide · Service Account Security Guide