A patch management tool can report 98% compliance while a fifth of the estate has a silent agent, while its own server runs months behind on updates and while one console account can push a script to every device you own. This health check is a recurring, measurable review of the patching platform itself: the console or cloud tenant, management and distribution servers, the agents on devices, the content catalogue and custom packages, its integrations, and the accounts and credentials that operate it. It turns the questions an endpoint lead, internal auditor or CISO would ask into twelve metrics with formulas and thresholds that can be compared quarter on quarter.
This page measures the tool; it does not tell you how to harden it or how to run a patching programme. For hardening, use Securing the patch management tool itself; for the programme, use the Patch Management Guide and the NIST SP 800-40 Rev 4 Patch Management Guide. The check is vendor-neutral and applies to cloud endpoint management services, self-hosted patch servers and third-party application catalogues.
What this health check covers
NIST SP 800-40 Rev. 4 describes patch deployment in four phases, prepare, deploy, verify and monitor, and notes that verification at scale generally needs automation. That automation is the tool, so its blind spots become the programme's blind spots. It is also a high-value target: MITRE ATT&CK T1072 Software Deployment Tools records how access to enterprise deployment software can give code execution on every connected system. The review covers:
- Reach: whether the tool can see and act on every device it should, and whether its agents are alive.
- Truthfulness: whether the tool's compliance figures agree with an independent source such as authenticated vulnerability scans.
- Delivery: whether approved content actually installs, and how long the tool's own pipeline takes from release to a device.
- Content integrity: whether catalogue and custom packages are verified and approved before release.
- The tool as a privileged system: administrators, scoping, service accounts, integration credentials, guardrails and audit logging.
Who runs it: the endpoint or infrastructure engineering lead collects the data; security operations and vulnerability management review it; the head of IT operations or CISO signs off. What it is not: a review of patching service levels across the organisation, exceptions and risk acceptance; those are programme outcomes and sit in the vulnerability management programme review. Teams searching for a "patch management audit checklist", "patch compliance KPI" or "patch agent health report" can use the table as-is.
Key takeaways
- Coverage comes before compliance. A compliance percentage is calculated over devices the tool can see; reconcile against the asset inventory first.
- Trust, but verify the tool's own numbers. NIST SP 800-40 Rev. 4 prefers authenticated scanning because passive or infrequent scanning tends to under-report; compare tool-reported state with scan results.
- Agent health is a security metric. A device whose agent has not checked in for 14 days is unmanaged, whatever its last compliance state says.
- The tool can run code everywhere. Measure administrators, scoping and guardrail bypasses with the same rigour as domain administration.
- Patch the patcher. The tool's own servers, agents and catalogue connectors need to be within your own patching deadlines.
How to use this template
Copy the metrics table and findings log into your own tracker and run this Patch management tool health check at the cadence below. Collect each figure from the data sources described, score it against the green, amber and red bands, and log every amber or red result as a finding with an owner and a due date. Keep each completed review so you can see trends. Where you run more than one patching tool (for example one for servers and one for endpoints), run the check per tool and report both.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Agent check-in and failed deployment review | Weekly | Endpoint operations | Endpoint lead | Stale agent list, failure report, tickets raised |
| Inventory reconciliation against asset register | Monthly | Endpoint operations | Endpoint lead | Matched, missing and unknown device lists |
| Full metrics review (this page) | Quarterly | Endpoint or infrastructure engineering lead | Head of IT operations or CISO | Metrics table, raw extracts, findings log |
| Console role and scope recertification | Quarterly | Identity governance | Endpoint lead | Role, scope and integration credential list with decisions |
| Kill switch and rollback test | Twice a year | Endpoint lead | Head of IT operations | Test record, time to pause, devices affected |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "In scope" means devices in the asset register that the tool is meant to manage, split by maintenance group (for example servers, endpoints, tier 0) as NIST SP 800-40 Rev. 4 recommends.
| ID | Metric | Formula | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| PMT-01 | Managed device coverage | In-scope devices with an enrolled agent or managed connection ÷ in-scope devices in the asset register | Tool device inventory, asset register or CMDB, directory computer objects | At least 98% | 93% to below 98% | Below 93% |
| PMT-02 | Agent check-in health | Enrolled devices that checked in within 7 days ÷ enrolled devices | Tool agent last-contact report | At least 97% | 90% to below 97% | Below 90% |
| PMT-03 | Reported state accuracy | Sampled devices where the tool's patch state matches an authenticated vulnerability scan for the same updates ÷ sampled devices (sample at least 100 per maintenance group) | Tool compliance report, authenticated scan results | At least 97% agree | 90% to below 97% | Below 90% |
| PMT-04 | Deployment success rate | Device installs that succeeded on first or automatic retry ÷ device installs attempted in period | Deployment job results, agent installation logs | At least 95% | 85% to below 95% | Below 85% |
| PMT-05 | Content pipeline time | Median hours from vendor release of a critical update to its availability in the tool's pilot ring, for updates in the period | Catalogue sync logs, approval records, vendor release dates | 24 hours or less | Over 24 to 72 hours | Over 72 hours |
| PMT-06 | Unsupported platform reach | In-scope device types or operating system versions the tool cannot patch (no agent, no catalogue content) ÷ in-scope device types and versions | Tool supported platform list, asset register | Below 2% | 2% to 5% | Above 5% |
| PMT-07 | Verified and approved content | Packages and scripts released to production rings with a recorded signature or hash check and a second-person approval ÷ packages and scripts released | Package library metadata, approval records | 100% | 95% to below 100% | Below 95% |
| PMT-08 | Estate-wide administrators | Human accounts able to deploy to all devices or run scripts estate-wide ÷ human accounts with any console role | Role and scope assignment export, directory groups | Below 5%, all phishing-resistant MFA | 5% to 10% | Above 10%, or any without MFA |
| PMT-09 | Tool service and integration credentials | Service accounts, client push accounts, API keys and tenant applications past rotation policy, unused for 90 days or holding rights beyond their purpose ÷ all such credentials | Service account inventory, tool integration list, secrets store metadata | Below 5% | 5% to 15% | Above 15%, or a push account with domain administrator rights |
| PMT-10 | Guardrail bypasses | Production deployments above the target cap, or script, uninstall or wipe jobs, run without the required second approval ÷ such jobs in period | Tool audit log, change records | 0 | Bypass via documented emergency route, reviewed within 5 days | Any undocumented bypass |
| PMT-11 | Tool self-patching | Tool servers, distribution points and agents running a version within the vendor's current supported release and your own patching deadline ÷ tool components | Tool component version report, vendor supported version list | 100% | 95% to below 100% | Below 95%, or any unsupported server version |
| PMT-12 | Audit log forwarding | Tool components (console or tenant, servers, distribution points) whose audit events reached the SIEM in the last 7 days ÷ components | Tool logging settings, SIEM source inventory | 100% | Gaps under 7 days | Any component silent for 7 days or more |
Programme measures such as mean time to remediate by severity, service level attainment and open exceptions are deliberately left out: they belong to the vulnerability management programme review, so the two checks do not double count.
How to collect the data
- Reconcile devices. Export the tool's device list with last contact time, the asset register or CMDB, and directory computer objects with last logon. Match on serial number or hardware identifier first, then hostname (PMT-01, PMT-02). Unmatched register entries are coverage gaps; unmatched tool entries are inventory gaps to send back to asset management.
- Cross-check against scans. Pick a random sample per maintenance group, take the tool's per-device update state for the last two monthly cycles and compare with authenticated vulnerability scan results for the same updates (PMT-03). Disagreements usually mean superseded updates, pending reboots or failed detection rules.
- Read deployment results. Export job results with per-device status and error codes (PMT-04). Group failures by cause: disk space, reboot pending, agent error, content download failure.
- Time the content pipeline. For each critical update in the quarter record vendor release time, catalogue sync time, approval time and pilot ring availability (PMT-05). The Patch Tuesday Guide gives the monthly rhythm for the main operating system vendors.
- Map supported platforms. List device types and operating system versions in the register and mark which the tool can patch (PMT-06). Unsupported ones need their own maintenance group and plan.
- Audit the package library. Export packages and scripts released to production rings with their verification and approval records (PMT-07).
- Export access. List console roles with scope, assignment type and MFA status, and every non-human credential with created, rotated and last-used dates and its effective rights (PMT-08, PMT-09). Record each in your NHI inventory with an owner; see the NHI Ownership Guide.
- Read the audit log. Filter for deployments above the cap and for script, uninstall and wipe jobs, and match each to its approval (PMT-10). Confirm events arrive in the SIEM from each component (PMT-12).
- Check component versions. Export versions of servers, distribution points and agents, and compare with the vendor's supported release list (PMT-11).
Red flags that need action now
- A client push or content access account with domain administrator rights, or one account valid on every tier including domain controllers.
- A single console role that can target tier 0 servers and ordinary endpoints alike, held by a lower-tier team.
- A script or estate-wide deployment run outside change windows with no approval record.
- A new or changed custom package with no signature, hash check or second reviewer.
- More than 10% of enrolled agents silent for 14 days or more.
- The tool's own management server running an unsupported version or missing a critical update.
- Audit logging off, or retained only inside the tool where patch administrators can change it.
- Tool compliance at 95% or above while authenticated scans show widespread missing updates on the same devices.
If a red flag suggests the tool is being misused, switch to If your patch management tool is compromised.
Findings log
Record each amber or red result and each red flag. Carry open items forward.
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-PMT-01 | [e.g. 640 register servers with no agent, mostly in two network segments] | PMT-01 | [High] | [Endpoint operations lead] | [Date] | [Open] |
| HC-PMT-02 | [e.g. Client push account is a member of domain administrators] | PMT-09 | [Critical] | [Platform owner] | [Date] | [Open] |
| HC-PMT-03 | [Description] | [ID] | [Critical / High / Medium / Low] | [Role] | [Date] | [Open / In progress / Closed / Risk accepted] |
Suggested due dates: critical within 7 days, high within 30 days, medium within 90 days. A risk acceptance needs a named approver and expiry; the Vulnerability Risk Acceptance and Exception Template works for tool findings too.
Remediation map
| Finding type | Where to fix it |
|---|---|
| Admin roles, scoping, service accounts, guardrails, logging | Securing the patch management tool itself |
| Coverage gaps, unknown devices | Asset Inventory and CMDB Security Guide |
| Poor deployment success, slow content pipeline, ring design | Patch Management Guide, NIST SP 800-40 Rev 4 Patch Management Guide |
| Unsupported platforms, unpatchable devices | Patch Management Policy Template (maintenance groups and exceptions) |
| Tool numbers disagree with scans | Vulnerability Scanning Guide |
| Slow emergency content | Emergency Out-of-Band Patching Playbook |
| Over-privileged or unowned tool credentials | Secrets Management Guide, Privileged Access Management Guide |
Framework mapping
| Area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 |
|---|---|---|---|
| Coverage and agent health (PMT-01, 02, 06) | ID.AM-01, ID.AM-02 | CM-8, SA-22 | Control 1, Control 2 |
| Accuracy, delivery, pipeline (PMT-03 to 05) | PR.PS-02, ID.RA-01 | SI-2, RA-5 | Control 7 |
| Content integrity (PMT-07) | PR.PS-02 | SI-7, CM-14 | Control 2, Control 16 |
| Access, credentials, guardrails (PMT-08 to 10) | PR.AA-05 | AC-2, AC-6, CM-3, IA-5 | Control 5, Control 6 |
| Self-patching and logging (PMT-11, 12) | PR.PS-02, PR.PS-04 | SI-2, AU-2, AU-6, AU-9 | Control 7, Control 8 |
Related guides
- Securing the patch management tool itself: the hardening this check measures.
- Patch Management Guide: the programme the tool serves.
- Vulnerability Management Maturity Model: place the results on a maturity level.
- If your patch management tool is compromised: when a red flag is an incident.
- Patch Management Buyer's Guide: when findings point to replacing the tool.
References
- NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- NIST: SP 1800-31, Improving Enterprise Patching for General IT Systems
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Software Deployment Tools
- CIS: Critical Security Controls v8.1
Related NHI Mgmt Group resources: Securing the patch management tool itself, Patch Management Guide, NIST SP 800-40 Rev 4 Patch Management Guide, If your patch management tool is compromised.