Patch management is one of the highest-leverage services an MSP delivers. It runs every day in the background, satisfies a clause in almost every cyber insurance application, sits at the heart of compliance attestations for clients in regulated industries and quietly compounds into recurring revenue when it’s packaged well. It also gets harder, not easier, every year.
The reason is structural. An internal IT team patches one environment, with one set of stacks, one set of maintenance windows, one approval workflow. An MSP runs the same playbook fifty or a hundred times in parallel, on top of fifty or a hundred different environments that don’t share a single common rule. That’s not a scaled-up version of internal IT patching. It’s a different operating model.
Datto RMM’s patch management software is built for that operating model and is used by thousands of MSPs to run patching across millions of client endpoints, providing a clear view of where MSP patch programs hold up under load and where they fall apart.
This article explores why patching is an MSP service line worth taking seriously, what makes multitenant patching genuinely different, the operational model behind a working program, and how mature MSPs package and price the work.
Why patch management is a real MSP service line, not a task
For most MSPs, patching started as a checkbox in the managed services agreement. It was bundled into the per-endpoint fee, ran somewhere in the background and showed up in monthly reports as a percentage. It was a cost of doing business, not a service in its own right.
That positioning has aged badly. Three forces have pushed patching out of the back office and into the center of how MSPs sell, deliver and price.
The first is cyber insurance. Underwriters now treat patching as a baseline control. A documented patch SLA, evidence that critical CVEs are remediated promptly and an external attack-surface scan are standard items on application forms and renewal questionnaires. Marsh’s Q2 2025 Global Insurance Market Index reported the ninth consecutive quarterly reduction in commercial cyber rates, partly because controls have improved across the insured base. Carriers are also auditing more aggressively mid-term, with patching cadence among the high-impact controls that determine whether a claim gets paid. An MSP that can produce per-client patch evidence on demand is selling something materially different from one that can’t.
The second is the threat data. Roughly 50,000 CVEs were published in 2025, a 22% increase year over year, and around 30% of vulnerabilities listed in CISA’s Known Exploited Vulnerabilities catalog are weaponized within 24 hours of disclosure. The window for a competent patching program has compressed from weeks to days. For MSPs serving SMBs that have no internal security capability, that compression makes patching the most cost-effective protection the client buys.
The third is liability. The MSP insurance market reports a meaningful share of MSPs filing cyber-related claims in recent years, with botched patch deployments and unpatched client networks among the recurring claim categories. The contractual exposure is real. An MSA that promises patching as part of the service, paired with a client breach traceable to an unpatched system, is exactly the scenario a Tech E&O claim is built on.
Treated together, these forces turn patch management from an operational afterthought into a packaged service line with its own SLAs, evidence pack, and price. The MSPs that have made that shift are running healthier margins on the same client base because they’re charging for an outcome (a defensible patch posture) rather than an activity (running updates).
For a deeper look at the underlying discipline, Kaseya’s guide on what patch management is covers the foundational concepts the rest of this post builds on.
What makes MSP patch management genuinely different
Generic patch management content treats the multitenant problem as “patching, but with more clients.” That framing misses what actually changes. The work isn’t bigger. It’s structurally different in the following five ways:
Different stacks per client
A single internal IT team standardizes on one OS build, one approved browser, one productivity suite and a handful of line-of-business apps. An MSP serving fifty SMBs is supporting fifty different application footprints, from the ophthalmologist running a specialized practice management system on an older Windows Server, to the architecture firm running CAD software with stubborn driver dependencies, to the law firm whose document management platform breaks if a specific Office update lands first. The patch tool has to model that diversity without forcing every client onto the same release train.
Different maintenance windows
A factory client patches at 3 am on Sunday because that’s the only time the line is down. A retailer patches midweek because the weekend is peak revenue. A medical practice can’t reboot any workstation between 8am and 6pm. Every client has a window, and the windows don’t align. Running a single maintenance schedule across the book is the fastest way to break a client meeting and lose the account. The tool must handle the schedule per client, in local time, with overrides for the inevitable exceptions.
Different SLAs and approval workflows
Some clients want every critical patch deployed within 48 hours, no human approval required. Others want their CIO to sign off before anything touches production. A third group has compliance frameworks that mandate a specific staged-deployment approach with documented testing evidence. Multitenant patching means running multiple approval workflows side by side, with an audit trail that proves which client got which patch on which schedule under whose authority.
Per-client reporting and attestation
Every client wants their report. The format has to make sense to the client’s CFO, not just the MSP’s technician. Compliance-aligned reports for HIPAA, PCI DSS, ISO 27001, NIS2 and Cyber Essentials need to be producible per client, on demand, without manual work. Cyber insurance evidence packs, which now sit at the center of underwriting conversations, must map to the carrier’s specific requirements. White-labeled reporting that puts the MSP’s branding on a polished compliance document is what turns a technical activity into a defensible service deliverable.
Billing and packaging
Internal IT doesn’t bill itself — an MSP does. This means every patching activity that consumes time has to either fold into a fixed fee, generate a billable line item or feed a margin calculation. The tool has to play with the PSA. Time entries from failed deployments need to land in the right ticket queue. Per-endpoint counts need to reconcile to the licensing agreement. None of this is glamorous, and all of it determines whether the service line is profitable or not.
A tool that handles these five dimensions cleanly is what separates a multitenant platform from an internal IT tool with a tenant selector bolted on.
The operational model: How a mature MSP runs patching as a service
The MSPs that run patching at scale don’t treat it as a series of one-off deployments. They treat it as a managed product with its own lifecycle, its own evidence trail and its own service commitments. The model has four moving parts.
A standardized baseline policy
Every client starts on the same default policy unless there’s a specific reason to deviate. The default is opinionated: patches scanned daily, security updates auto-approved with a 48-hour pilot delay, reboots scheduled outside business hours, third-party applications patched on the same cycle as the OS. Deviations are documented per client with a stated reason (compliance, legacy app dependency, change-control requirement) and a review date. This is the discipline that makes scale possible. Bespoke patch handling for every client is how MSPs end up with technicians who can only support certain accounts and a documentation trail that no one can audit.
Deployment rings, even at the MSP scope
Internal IT teams use rings to limit blast radius. MSPs need them more, not less, because a bad patch doesn’t break one company, it breaks ten or twenty simultaneously. The mature pattern uses the MSP’s own infrastructure as Ring 0, a small group of friendly clients (often the MSP’s own staff) as Ring 1, the broader low-risk client base as Ring 2, and the high-stakes clients (medical, legal, financial, manufacturing OT) as the final ring with extra hold time. The tool has to support holding deployment between rings based on telemetry from earlier rings, not just on a fixed timer. Check out our post on automated patch management to get more detail on the ring mechanics.
A written exception register
Every “this client can’t take this patch” decision goes in a register, with a named owner, a stated reason, a compensating control and a review date. This sounds like overhead. It’s actually what protects the MSP when something goes wrong six months later and the client asks why their database server wasn’t patched. The exception register also produces a useful operational signal: clients with growing exception lists are clients whose risk profile is drifting, which is a QBR conversation rather than an incident waiting to happen.
Per-client compliance evidence as a continuous output
The patch program should produce its own audit evidence as a byproduct of operating, not as a quarterly fire drill. Per-device patch status, time-to-patch by severity, exception register, and a compliance-mapped report for each client’s regulatory framework should generate on demand. This is where the difference between a tool that supports MSPs and a tool built for MSPs becomes most visible. Single-tenant platforms can produce reports, but the work to slice them by client, brand them, and package them for an underwriter is manual. Multi-tenant platforms produce them as the natural output of how they’re structured.
The deeper point: a working MSP patch program looks more like a manufacturing process than an IT activity. Standardized inputs, controlled variation, telemetry at every stage, evidence as a byproduct. The technicians review the exceptions and the failures. The system runs the rest.
Tooling: What an MSP needs that internal IT tools don’t provide
Most patch management tools were built for internal IT and adapted for MSPs later. The architectural constraints show up quickly. An MSP evaluating a platform should test for the following capabilities specifically, because they’re where adapted-for-MSP tools tend to break.
A multitenant console that’s actually multitenant. The technician should see all clients in one view, with the ability to drill into any one client’s environment without logging out and back in, and with role-based access that prevents cross-client data leakage. Surface-level multi-tenancy (a client filter on a single-tenant console) doesn’t survive a real workload.
Per-client policy with global override. The MSP defines a default policy at the global level. Each client can have site-level overrides for the inevitable exceptions, without losing the global policy as a baseline. Datto RMM, for example, supports global patch management policies with per-site overrides on schedule, power and approval rules, which is the right structural model for MSP-scale management.
Maintenance-mode integration with monitoring. When a patch window opens, the alerts that the patching activity will trigger should suppress automatically for that window, so the NOC isn’t responding to false-positive reboots and the per-client alert log stays clean. This is a small feature that saves a meaningful amount of after-hours work.
Off-network and roaming endpoint coverage. SMB clients have hybrid workforces. Laptops connect from home, hotels, and coffee shops. The tool needs to deploy patches over the internet without requiring VPN connectivity, retry cleanly when devices come back online, and report visibility into the long tail of devices that missed the window.
Third-party application catalog with MSP-relevant breadth. OS patching is largely a solved problem. The differentiator is third-party catalog depth and freshness, because most exploited CVEs in 2025 sat in third-party software, not the OS. A catalog of 200 to 300+ applications, kept within a few business days of vendor release, is what closes the gap. The companion post on third-party patch management goes deeper on the operational specifics.
Native PSA integration. The patch tool has to feed the PSA cleanly. Failed deployments should generate tickets in the right queue, with the right priority, against the right contract. Without that integration, technicians are double-keying data from one system into another, which is where margin disappears.
White-label reporting. The reports the client sees should look like the MSP’s product, not the vendor’s. Logo, colors, language — this sounds cosmetic. Clients perceive it as professionalism, and professionalism is what justifies the price.
Vulnerability-data integration. The patch tool should know what’s in the CISA KEV catalog and surface it. A platform that can show “you have 12 devices running an OS version with an actively exploited CVE, here’s the patch, deploy now” is fundamentally more useful than one that just lists missing patches in alphabetical order.
Packaging and pricing patterns
The commercial framing is where most MSPs leave money on the table. Patching usually gets bundled into the managed services fee at no incremental margin, which means the MSP carries all the risk and captures none of the upside. The mature pattern unbundles it.
Per-endpoint pricing on a tiered model is the most common structure. A baseline tier covers OS and core third-party patching with monthly compliance reporting. A higher tier adds expanded third-party catalog coverage, a documented SLA on critical-patch deployment time, white-labeled compliance reports, and quarterly audit evidence packs. A premium tier for regulated clients adds attested SLAs, named technician oversight, and integration with the client’s compliance reporting (HIPAA, PCI DSS, NIS2). Each tier maps to a different per-endpoint price, with the higher tiers carrying meaningfully higher margin.
Per-client pricing layered on top of per-endpoint is how some MSPs handle the variable cost. The per-endpoint fee covers the deployment activity. A flat per-client monthly fee covers the policy management, exception register, and reporting overhead, which doesn’t scale linearly with endpoint count. A 10-endpoint client and a 200-endpoint client both consume similar amounts of policy and reporting work; only the deployment differs.
Patching as a standalone service line is the most ambitious pattern, sometimes branded as Patching-as-a-Service or PMaaS. The MSP delivers patching to clients who use a different MSP for the rest of their IT, or to internal IT teams who want to outsource the patch program specifically. This is harder to sell and operate, but it commands a premium price and isolates the patch work from the broader managed services contract.
Across all three patterns, the unit economics depend on automation. The MSPs that turn patching into a healthy margin are the ones whose tool runs the routine work without a technician watching, leaving the team to handle exceptions, emergency response, and client communication. The MSPs whose technicians are clicking through approvals every Patch Tuesday are the ones losing money on the service line and don’t realize it.
Compliance and liability: The real backstop
Patching has been about security for years. It’s now also about contractual exposure.
The cyber insurance shift is the most visible piece. Carriers are no longer satisfied with checkbox attestations. They want evidence: patch SLAs documented and met, third-party application coverage demonstrated, a defensible process for emergency patches. An MSP that can produce that evidence per client at audit time is helping the client renew their policy. An MSP that can’t is exposing the client to non-renewal and themselves to a Tech E&O claim if a breach traces to an unpatched system covered by the MSA.
Compliance frameworks that impact SMB clients are becoming more specific about patching cadence. PCI DSS 4.0 requires critical security patches within a month of release. HIPAA requires timely patching as part of its Security Rule. NIS2 is now in force across the EU and extending into UK supply chains while ISO 27001:2022 is now the de facto baseline for clients selling into enterprise procurement. Each one assumes evidence, not just activity.
The MSP positions for all of this is straightforward: patch management isn’t a feature, it’s a defensible service that the client can point at when their auditor, insurer or board asks about cyber risk posture. Selling it that way also tends to land better than selling on technical features. CFOs care about audit findings and insurance premiums. Patching, framed correctly, speaks to both.
For MSPs whose programs are still loose around the edges, our blog on building a patch management policy walks through the document a mature program runs on.
Common MSP patching mistakes and how to avoid them
A few patterns recur across MSPs whose patch programs look fine on paper but produce problems in practice.
Treating clients as variations on the MSP’s preferred policy rather than starting from each client’s risk profile. The MSP’s preferred 48-hour pilot delay is not a fit for a health care client whose compliance framework requires longer testing windows nor is it a fit for a manufacturing client whose downtime cost makes 48 hours too short.
Approving patches in bulk without segmenting servers from workstations from OT or critical-line-of-business systems. A blanket approval that lands a patch on a domain controller at the same time as a marketing laptop is how outages happen.
Trusting the deployment-success metric without correlating to a vulnerability scan. The patch tool reports what it sent. The scanner reports what’s actually fixed. The gap between the two is where the audit findings sit.
Letting the third-party application catalog become the bottleneck. OS patching feels solved — third-party patching often isn’t. MSPs that haven’t audited their third-party coverage in the last 12 months are usually surprised by what they find.
Treating reporting as an afterthought. The clients who renew on patching-rich contracts are the ones who see polished, branded, compliance-mapped reports every month. The clients who push back on price are the ones who get a CSV.
For the underlying disciplines that prevent most of these patterns, our post on patch management best practices covers the operational habits that separate working programs from struggling ones.
How Kaseya helps MSPs with patch management
A working MSP patch program needs a platform reliable enough that the team trusts the automation, multi-tenant enough that the work scales without proportional headcount, and visible enough that the client can see the value. That’s the design brief Datto RMM’s patch management is built against, and it’s where the operating model and the tooling stop being separate conversations.
Global Patch Management policies with site-level overrides on schedule, reboot behavior and approval rules give MSPs the per-client flexibility they need without abandoning a standardized baseline. Maintenance Mode suppresses monitoring alerts during patch windows automatically, removing a common source of after-hours noise. Patch Now handles the emergency deployments that don’t wait for the regular cycle. The Software Management module covers third-party patching across over 200 Windows and macOS applications, kept within a few business days of vendor release. Native Autotask PSA integration closes the loop on tickets, billing, and per-client compliance reporting.
Datto RMM is also part of Kaseya 365, the unified subscription that bundles RMM, security, backup, and automation into a single per-endpoint price, which is how many MSPs consolidate the operational cost of running multiple separately-licensed tools.
The work itself doesn’t change much from year to year. What changes is the stakes. Cyber insurance underwriters are paying attention. Clients in regulated industries need defensible evidence. The threat data is getting worse and the patch windows are getting shorter. None of that argues for running patching as a checkbox in the back office. All of it argues for running it as a service line that earns its keep, on a platform built for the way MSPs operate.
