Skip to content
Made in the UK

Vulnerability Remediation

How do MSPs track and fix failed patches?

By , CEO, CybaVerse. Last reviewed

MSPs track failed patches by comparing what their RMM says was deployed with what a vulnerability scan says is still missing, then sorting failures by cause, such as pending reboots, low disk space or offline devices. Each cause gets its own fix, and an item only closes when a rescan confirms the vulnerability has gone.

This page is part of our vulnerability remediation guide.

Why do patches fail?

Patches fail for ordinary reasons: a device was off, a reboot never happened, disk space ran out, a service was locked or an installer clashed with other software. NIST SP 800-40 notes that software updates is a routine but disruptive process, and some failures are expected in every cycle.

The risk is not that failures happen, but that nobody notices. An RMM may report an update as approved or deployed while the device is still vulnerable. For Cyber Essentials, a high or critical fix that has been available for more than 14 days is a failure, whatever the RMM says.

How do you find failed patches?

Find failed patches by checking outcomes rather than activity. A vulnerability scan shows what is still missing on each device, regardless of what was attempted. Compare that with your RMM's deployment report every cycle, and treat any gap between the two as a failure to investigate and resolve.

  • Scan after every cycle. See what is still missing.
  • Compare with RMM reports. Find updates marked done that are not.
  • Check devices that did not report. Offline devices are failures too.
  • Track the age of each gap. Prioritise anything nearing 14 days.

How should you fix failed patches, step by step?

The steps below work for most MSP teams. Group failures by cause rather than working device by device, because one cause, such as a pending reboot, often explains dozens of failures. Fix the cause, retry, then confirm with a fresh scan before closing anything.

  1. Step 1: List every failure

    Combine the scan results and RMM reports into one list per client.

  2. Step 2: Sort by cause

    Group by reboot needed, disk space, offline, installer error or unknown.

  3. Step 3: Fix the cause

    Schedule reboots, free disk space, or chase offline device owners.

  4. Step 4: Retry the patch

    Redeploy in a controlled window, starting with a small group.

  5. Step 5: Rescan to confirm

    Close the item only when a scan shows the vulnerability has gone.

  6. Step 6: Escalate stubborn devices

    Rebuild or replace devices that fail repeatedly.

How do you keep this under control across clients?

Across many clients, keep one view of every open failure with its age and owner. A weekly review of anything older than seven days stops items drifting past the 14-day Cyber Essentials deadline. We hear from MSPs that a small number of stubborn devices cause most of the repeat work each month.

CauseTypical fixOwner
Pending rebootScheduled out-of-hours rebootMSP
Low disk spaceClean-up or storage upgradeMSP
Offline deviceContact user or clientClient
Installer errorManual install or repairMSP
Repeated failureRebuild or replaceMSP and client

Where does CybaOps fit?

CybaOps shows MSPs what is still vulnerable after each patch cycle, across every client, so failures are visible rather than hidden in deployment reports. The Remediation Engine can then fix security issues automatically, so gaps get closed rather than just reported.

  • CybaVM gives continuous internal and external vulnerability scanning, prioritised in one place in CybaOps.
  • Internal scans run several times a day and external scans run daily.
  • CybaOps ties vulnerabilities to the assets they affect, so teams fix what matters first.
  • The CybaOps agent can be deployed through your existing RMM.

Failed updates

How MSPs track and fix failed updates

MSPs track failed patches by comparing what their RMM says was deployed with what a vulnerability scan says is still missing, then sorting failures by cause, such as pending reboots, low disk space or offline devices.

01 Findings from

Multi-tenantPartner / MSP CustomerCustomerCustomer+
CybaOps by CybaVerse

Failed updates

02 The 6-step path

  • Role-based access
  • UK-based analysts
  • ISO 27001

03 Outcomes

Explore

Hover or tap any part of the diagram to see what it does.

  • Remediation in
  • CybaVM
  • CybaRemediate

What else do MSPs ask about failed patches?

These are the follow-up questions MSP engineers ask most about failed patches.

Is a deployed patch the same as a fixed device?

No. A deployment report shows an attempt, not the outcome. Only a scan of the device confirms the vulnerability has gone. Some fixes also need a reboot or extra configuration before they take effect.

How many retries should we allow?

Two controlled retries is a sensible limit for most teams. After that, investigate the device directly. Repeated failures usually mean a deeper problem, such as corruption or old hardware, that retries will not fix.

Should offline devices count as failures?

Yes. An offline device is not patched and may still be used. Track it, contact the owner and include it in the next cycle. If it is lost or retired, update the asset list.

See how failed patches show up in CybaOps.

Book a CybaOps demo