Why a successful patch job is not verification
Deployment status says a job ran. Verification says the exposure is gone. The two are recorded by different things, and only one of them should close a ticket.
A patch tool saying “success” tells you that a job ran. It does not tell you that the vulnerability is gone. For an MSP the difference matters most at the point where a ticket is closed and a customer is told the issue is fixed.
NIST treats these as separate steps. Its enterprise patch management guide (SP 800-40 Rev. 4)[1] lists “verify the risk response” after the response is implemented, and says that for patching “this means confirming that the patch is installed and has taken effect.” The guide then adds a further step: continuously monitoring that the response stays in place.
This article uses two terms. Deployment status is what the patch tool, RMM or ticket records: a job ran, an installer returned a code, a technician closed the ticket. Verification is a fresh observation that the exposure is no longer there.
Why a successful job is not a fixed vulnerability
None of these failure modes is exotic. Each one leaves a green status next to a vulnerable system.
The change has not taken effect
NIST notes that making a patch take effect can need “restarting patched software, rebooting the operating system or platform” it runs on, or changing configuration settings[1]. A job that installs the files and waits for a reboot can report success while the old code is still running.
Wrong asset or wrong scope
The job patched the machines it was pointed at. The vulnerable host may be a different one, an unmanaged one, or one outside the RMM policy. A patch tool can only report on assets it knows about.
A second instance
The patched package is not the only copy. A bundled runtime, a container image, a second install path or a standby node can carry the same flaw after the main install is updated.
The fix was undone
NIST describes monitoring to confirm that a patch “has not been uninstalled by a user or an attacker” and that “an unpatched version of the software has not been restored from a backup”[1]. It also lists reverting to a previous version as a possible response to patch side effects.
A version banner is not proof
A version string may be unchanged after a vendor backports a fix, and may change without the fix being active. Banners are a hint. Where the vendor documents how a fix shows up, check for that.
The exposure is not the package
Some risk comes from configuration or exposure rather than a missing update: a management interface open to the internet, a weak setting, a service that should not be running. A patch job does not address these, and a compensating configuration change is not recorded by the patch tool at all.
What verification evidence looks like
NIST says the robustness of verification “can vary a great deal” with an organization’s needs, and that automated means are generally needed to verify at scale[1]. What counts as evidence depends on the finding. These are the usual forms, from weakest to strongest.
| Evidence | What it shows | What it does not show |
|---|---|---|
| Job or ticket status | Work was attempted and recorded | That the exposure is gone |
| Inventory shows a newer version | The installed package changed | That the running service restarted, or that other copies were updated |
| Authenticated version or configuration check | The running build or setting on that host | How the service looks from outside |
| Recheck of the specific finding | The same test that found the problem no longer finds it | Hosts the test could not reach |
| Re-observed external exposure | The service is no longer reachable or no longer vulnerable from where an attacker would stand | Internal-only paths |
The strongest evidence repeats the original observation. If an external scan found the flaw, an external recheck is the proof. If an authenticated check found it, run the authenticated check again.
Partial verification, and recording what you could not check
Fleet work rarely verifies cleanly. Of ten affected endpoints, nine may be rechecked and one may be offline. Recording that as “fixed” overstates what you know. A more useful record has three parts:
- Which assets were rechecked and what the recheck observed.
- Which assets could not be checked, and why (offline, credentials failed, out of scope).
- What happens next: a date to retry, or an owner who will chase the gap.
Verification is also not a one-time event. NIST’s life cycle ends with monitoring that “the risk response continues to be in place”[1], which in practice means a later recheck, particularly after restores and rebuilds.
A practical closing routine
- Close tickets on a recheck result, not on job status.
- Keep the evidence (what was checked, when, by which method) attached to the ticket.
- Treat anything you could not re-observe as open or unverified, and say so to the customer.
- For exploited vulnerabilities in particular, CISA’s directives tie federal agencies to remediation timelines and require internal validation and reporting on status[2]. Those directives bind agencies, not MSPs, but they show the expected standard: a status you can substantiate.
How Exploit Hound handles this
Product behaviour, not an industry claim
- After a change, Exploit Hound re-checks the exposure with the same non-destructive check that found it, and rebuilds the exposure graph.
- A closed ticket or a successful RMM job is not treated as proof of a fix.
- A recheck that could not reach everything is recorded as partial, and anything that could not be re-checked is reported as unverified, never as fixed. The ticket stays open on the part that could not be checked.
- Findings carry the terms detected, high confidence and safely validated, defined on the terminology section.
PSA and RMM integrations are Beta. The recheck does not depend on how the change was made, so a technician can make the change directly and still have it verified. See remediation verification and the sample report for what this looks like.
Common questions
If the RMM says the patch installed, why isn’t that enough?
It shows that a job ran. NIST’s patch guide separates installing a patch from verifying that it is installed and has taken effect, and a reboot, a second instance or a restored backup can leave the vulnerable code in place.
What is the minimum evidence to close a patching ticket?
A fresh observation of the specific finding: a recheck of that finding, an authenticated version or configuration check, or a re-check of external exposure. Record what was checked, when, and what could not be reached.
What should I tell a customer when only some assets could be verified?
Say which assets were confirmed fixed, which could not be checked and why, and when the gap will be rechecked. Report unchecked assets as unverified, not as fixed.
Sources
- [1] NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning (April 2022): sections 2.2 and 2.3 (verify the risk response; reboot and restart; side effects and rollback; monitoring that a patch stays installed)
- [2] CISA BOD 26-04, Prioritizing Security Updates Based on Risk (June 2026): remediation timelines, internal validation and enforcement, status reporting; supersedes BOD 22-01
- NIST SP 800-40 Rev. 4 (PDF)
See the workflow on demonstration data first
The interactive demo runs in your browser on invented data and needs no sign-up. The pilot guide sets out a scoped evaluation on one customer.