Pull up your patch compliance report. Odds are it looks good. Ninety-something percent of endpoints current on the operating system, reboots landing inside the window, exceptions documented and defensible. That number is real and you earned it.
Now ask a different question about the same machines. What version is the PDF reader on? The remote access client? The browser your client’s entire staff lives inside for eight hours a day? The database engine running under the line of business app someone installed in 2019 and nobody has touched since?
For most MSPs there is no report that answers that. There is no cycle that keeps it true, and no one whose job it is to check.
Two jobs wearing one name
The industry has one word for all of this, and the word is doing too much work.
Your RMM patches the operating system. That is a real job and your RMM is good at it. Microsoft ships on a predictable cadence, the updates arrive through one channel, the RMM knows how to stage them, and you already have a reboot window your clients have agreed to. It is a solved problem with an owner and a report.
The software running on top of the operating system is a different job entirely. Dozens of vendors, each on their own release schedule, each with their own update mechanism, none of them coordinated with the others or with the OS cycle. Some update themselves if a user clicks the prompt. Some need an installer pulled down and run. Some have not been opened in eleven months and are sitting four major versions behind.
Same fleet. Same endpoints. A completely different problem. Calling both of them patching is how the second one stays invisible.
The exposure moved and the reporting did not
The 2026 Verizon Data Breach Investigations Report put vulnerability exploitation at the top of the initial access list for the first time in the report’s nineteen year history. It is now the way about a third of breaches start, ahead of credential abuse.
That finding got read across the industry as a patching story, and it is only partly one. The Known Exploited Vulnerabilities catalog is not a list of operating system flaws. It is full of the layer above: VPN clients, file transfer tools, document readers, web frameworks, remote access software. The things attackers reach for are frequently not the things your OS cycle touches.
This means a fleet can realistically sit at ninety-eight percent OS compliance and still be full of software an attacker already knows how to use.
The report is accurate. It is just answering a question that is no longer the whole question.
Why the second job goes unowned
It is not laziness, and not a skills gap. Three structural reasons.
There is no inventory. You cannot keep current what you have not enumerated, and most environments have never had a complete, cross-client software inventory that updates itself.
There is no single path. The OS has one update channel. The layer above it has as many channels as it has vendors, and stitching those together by hand across a book of clients is a project nobody has time to start.
There is no report. This is the quiet one. The OS cycle produces a number you can show a client and put in a QBR. Software currency produces nothing, so it competes for attention against everything that does. What gets measured gets done, and this has not been measured.
Effort alone does not close the gap completely
Here is the part that should change how you think about staffing this.
That same DBIR found the share of known exploited vulnerabilities getting fully remediated went down year over year, not up, and the median time to fully remediate one went up by about a third. Even the strongest programs leave most of their known exploited items open a week after they surface. That ceiling holds across organizations regardless of maturity, budget, or tooling.
Read that carefully. It is not a finding about effort. It is a finding about queue economics. The volume of new exploitable software arriving every month has outrun what any human review cycle can process, and the gap between a vulnerability becoming public and becoming useful to an attacker is now measured in days.
You cannot hire your way across that volume. Adding a technician adds throughput to a queue that is growing faster than the throughput you added, and simply does not scale. The only thing that changes the shape of the problem is removing the human step from the routine cases so your people spend their attention on the exceptions and escalations.
Where Cork fits
Cork does not patch operating systems and has no interest in trying. Your RMM owns that, it does it well, and replacing a working cycle with a second one is not an improvement.
What Cork does is the job sitting above it. We observe the software inventory across every client from the tools you already run, cross reference it against what is actually being exploited in the wild rather than what merely scores high, and then push the updates through package managers using the RMM you already have deployed.
The MSP controls the remediation schedule: scoped to one client or all of them, at any cadence. Limited by software or by severity. Running on a schedule you set, inside a window you choose.
No new agent on the endpoint. No second console. The operating system stays exactly where it is, on your cycle, under your control.
A current fleet and a stale fleet can look identical
That is the whole point of separating the two jobs. On the report you have today, they may look identical. Both show green, but one of them has an entire category of exposure that nothing in the reporting picture is watching.
Naming the second job is the first step. Once you can see the layer above the operating system, keeping it current turns out to be considerably easier than you would expect from how long it has been ignored.