The Last 10% of Patching

A patch dashboard, a schedule and a hope and a prayer will get a fleet to about 90% patched. Getting patch compliance, the share of your devices with every approved update installed, from 90% to 99% is the hard part, and it's the part that matters most. Here's what sits in that last 10%, and how Mingo works through it.

How We Get to 90%

I ran patching at MSPs for years. Patch Tuesday comes, the policy fires overnight and the dashboard goes mostly green by morning. Everyone relaxes. But that last 10% is where the real risk sits, and it rarely fixes itself.

Traditional patching is built for the machines that behave. You set an approval policy, pick a maintenance window and let the RMM push updates. For most of the fleet, that works.

The process usually looks like this:

1. Approve the month's updates, or auto-approve by category.
2. Assign patches to "non-critical" or "less important" machines to test.
3. Push them to everything in the overnight window.
4. Force or schedule a reboot.
5. Check the dashboard in the morning.
6. Re-run the failures and hope they go through this time.

Steps 1 to 4 are automated. Steps 5 and 6 are where the hope and the prayer come in. Nobody owns them, and they compete with every ticket in the queue.

Step 5 also trusts whatever the dashboard reports. In one r/msp thread, admins describe RMMs showing machines as current while updates sat pending:

What Sits in the Last 10% of Patch Compliance

The failures are rarely random. Each one has a cause, and each cause needs someone to go and look. The usual suspects:

• Pending reboots. The update installed but the machine never restarted, or the reboot hung. The dashboard says "installed" and the device is still exposed.
• Failed installs. A cryptic error code, a corrupted update cache or a servicing stack that is out of date.
• Low disk space. The update downloads, runs out of room and quietly rolls back.
• Broken services. Windows Update itself is disabled, stuck or blocked by another tool.
• Offline and sleeping devices. Laptops that are never on during the window and drift further behind every month.
• Machines nobody wants to touch. The domain controller, the line-of-business server, the CEO's laptop. They get excluded "for now" and stay that way.

Two of them show up in this r/msp thread: a broken update agent that reports a client as fully patched, and laptops that are offline when the window opens.

None of these is hard to fix on its own. The problem is that there are dozens of them each month, all slightly different, and each needs a technician to investigate.

Why the Last 10% Matters Most

The 10% that fails is not a random sample of your fleet. It's weighted toward the machines that are hardest to manage, and those are often the ones that matter most.

The server you excluded because a reboot is risky is the one holding your client's data. The laptop that is never online in the window is the one that travels and connects to hotel Wi-Fi. The device with a broken update service has probably been broken for months.

Attackers don't need your whole fleet. They need one unpatched machine, and they will find the 10% faster than your monthly report will. A 90% dashboard looks like a pass, but to an attacker it is a list of targets.

The numbers back this up. In the 2026 Verizon DBIR, exploited vulnerabilities overtook stolen credentials as the top way breaches start. Only 26% of known-exploited vulnerabilities were fully remediated, down from 38% a year earlier, and the median fix took 43 days.

There is a business cost too. The MSP that lets the gap grow is the one explaining a breach to a client who was told they were "fully managed".

How Mingo Closes the Gap

Mingo, the AI agent in OpenFrame, does the investigation work that steps 5 and 6 never get. It treats each failure as a problem to diagnose.

1. Check before patching. Mingo looks for blockers first: low disk space, pending reboots, broken update services. On a domain controller it checks health before anything is touched.
2. Check after patching. Did the machine come back? Are the key services running? Did dcdiag pass? Is DHCP still handing out IPs? A failed system is caught the same day, not when a user complains the next morning.
3. Investigate the failures. For each device that failed, Mingo works out why. That might mean reading the event logs, checking the update cache or finding the service that's blocking the install.
4. Write the fix, and wait for approval. Mingo proposes the fix and a technician approves it before anything runs. If something goes wrong, there's a rollback path.
5. Report on what's left. You get a patch compliance report with CVE risk, linked to the function of each machine in your fleet. A critical flaw in MSMQ isn't an issue if none of your machines run MSMQ, and Mingo will tell you that.

Here's step 3 done by hand, one machine at a time:

Mingo doesn't patch faster. What changes is that the failures get the same attention as the successes, every month, without waiting for a technician to have a free afternoon.

What It Isn't

I'm an AI skeptic, so I'll be straight about this. Mingo is not "set it and forget it", and it doesn't promise 100%.

Think of it as a very fast, very patient technician working through the failures. You stay in control: nothing is applied to a device until a person approves it. Some machines will still need hands-on work, and an offline laptop can't be patched until it comes back online.

What changes is where your technicians spend their time. Instead of re-running failed jobs and guessing, they review Mingo's diagnosis and approve the fix. Approving a fix takes minutes. Working out the cause yourself can take an afternoon.

The 9% That Counts

Going from 90% to 99% doesn't sound like much. In my experience it's the hardest 9% in patching, and it's where most of the risk is.

If your patch dashboard is green except for the same stubborn machines every month, try this. Start a free OpenFrame trial, connect a few devices, ask Mingo why the failed ones are failing, and see what comes back. OpenFrame is $1 per device, with no lock-in on the monthly plan.

Still choosing the tool that pushes the patches? Our patch management software comparison covers 11 of them.

You may need a dashboard, but you shouldn't have to rely on hope.