Every MSP has a patching story, and for most of us it’s the same story: the RMM detects missing updates, pushes them on a schedule, and then wrestles with the reboot. That last part is where the whole thing gets ugly — reboot scripts, maintenance windows, “please save your work” popups, the machine that never reboots because someone always clicks later. We’ve all built elaborate scaffolding around a fundamentally clumsy act. Windows 11’s hotpatch, delivered through Intune, quietly removes the reason that scaffolding exists. When someone asks whether it’s worth moving Windows patching off the RMM, my answer is yes for the OS layer — and here’s why.

What the RMM Is Really Doing (and Where It Struggles)

Strip an RMM patch policy down to its bones and it’s doing three things: figuring out what’s missing, installing it, and rebooting to make it stick. The first two it does well. The third is where every patching headache actually lives.

Reboots are the part your RMM can’t make painless. It can schedule them, defer them, nag about them, force them at 2 a.m. and hope the laptop is awake — but it can’t make a security update take effect without one. So compliance drags. The patch is “installed” but not in force until the reboot lands, and the reboot is exactly the thing users dodge. Your RMM dashboard goes green on “deployed” while the fleet stays quietly exposed until people finally restart.

What Hotpatch Changes

Hotpatch applies Windows 11’s monthly security updates in memory, without a reboot. Microsoft splits the year into four baseline months (January, April, July, October) that ship as a full cumulative update and do need a restart, and eight hotpatch months in between that install the same class of security fixes and simply take effect.

Do the math on that against your RMM’s reboot problem: eight of the twelve monthly cycles a year stop needing a reboot at all. The single step your RMM handles worst is the step hotpatch deletes. The update is in force the moment it lands — no reboot script, no maintenance window, no “restart later” loop keeping a machine unpatched for a week.

The Case for Moving Windows Patching to Intune

You’re using the tool built for the job. RMM patching bolts an update engine onto a remote-management agent. Intune drives Windows Update for Business — the native servicing pipeline Microsoft actually designed to patch Windows. Hotpatch only exists on that native path; your RMM can’t deliver it no matter how good its scripting is. To get rebootless patching, the delivery has to come through Intune.

Compliance gets faster and more honest. Because there’s no reboot standing between “installed” and “in effect,” the gap an attacker lives in — patch available, patch not yet applied — closes the moment the update lands. Your reporting stops lying to you, too: “deployed” and “protected” become the same state instead of separated by however long it takes a user to restart.

Smaller payloads, less bandwidth. Hotpatch packages are meaningfully smaller than full cumulative updates, so they download faster and cost less on the wire — which matters when you’re patching hundreds of endpoints on mixed connections instead of pushing a fat cumulative through the RMM to each one.

It layers onto your rings, it doesn’t replace your strategy. Moving to Intune doesn’t mean rebuilding how you stage updates. Your update-ring configuration is honored right alongside the hotpatch policy — pilot ring, broad ring, all of it intact. You’re changing the delivery mechanism, not the rollout discipline.

And underneath all of it, the benefit every service desk feels immediately: fewer forced reboots means fewer interruptions, which means fewer “why did my PC restart in a meeting” tickets. The reboots you stop forcing are tickets you stop closing.

Be Honest About Scope — This Doesn’t Retire the RMM

If I’m making this case to a colleague, I make it honestly: hotpatch replaces the Windows quality update portion of your patching, not everything your RMM does. Hotpatch covers monthly Windows security updates. It does not patch third-party applications — Chrome, Adobe, the long tail of line-of-business apps — and it isn’t your driver or firmware story either. Those either stay on the RMM or move to Intune’s own app and driver management as a separate decision.

So the real move is narrower and cleaner than “rip out the RMM”: take Windows OS patching off it and give that job to Intune, where it can be done without reboots. The RMM keeps doing the things it’s genuinely good at.

There’s one caveat that turns from footnote into fire drill if you skip it: don’t run two patch engines against the same machines at once. If your RMM is still pushing Windows cumulative updates while Intune’s Windows Update for Business is managing the same device, they will fight — double downloads, conflicting reboot behavior, confusing compliance data. Part of adopting hotpatch is turning off Windows OS patching in the RMM for those devices. Pick one owner for Windows updates. That’s the discipline that makes the switch clean.

The Prerequisites — Confirm Before You Promise

Hotpatch is strict about eligibility, and a pilot lives or dies on checking this first. A device needs all of the following:

  • Windows 11, version 24H2 or later — older builds are simply not eligible.
  • An eligible license — Windows 11 Enterprise E3/E5, Enterprise F3, Education A3/A5, Microsoft 365 Business Premium, or Windows 365 Enterprise. A client on plain Windows 11 Pro with Business Basic doesn’t qualify until the licensing changes. Check this before you build anything.
  • Virtualization-Based Security (VBS) with Memory Integrity (HVCI) enabled — the security foundation the in-memory patching relies on.
  • The current baseline installed — a device must be on the quarter’s baseline before that quarter’s hotpatches apply.
  • An x64 (Intel/AMD) CPU — Arm64 devices need compiled hybrid PE usage (CHPE) disabled first.

The one that surprises people is VBS: enabling it for the first time takes a single reboot — ironic on a feature whose pitch is “no reboots.” But it’s a one-time cost. Once VBS is on it stays on, and every hotpatch month after is genuinely rebootless. Say that up front so the first reboot doesn’t read like a broken promise.

What It Takes in Intune

The build is two policies. One Settings Catalog policy to enforce Virtualization-Based Security (enable Hypervisor Protected Code Integrity, using Enable without UEFI lock so you don’t strand yourself needing physical access for remote troubleshooting or reimaging). And one Windows Quality Update policy under Windows Update to allow quality updates with hotpatch turned on.

That’s the whole lift — two policies on top of the rings you already run. Compare that to the reboot orchestration you’ve been maintaining in the RMM, and the trade looks pretty good.

Roll It Out Like It Matters

Treat the first deployment like any fleet-wide change: a pilot ring of devices you know meet every prerequisite — right OS build, right license, VBS confirmed running — with the RMM’s Windows patching already disabled on those same machines. Watch the hotpatch compliance report before you widen it. Devices that miss a prerequisite don’t fail loudly; they quietly fall back to standard updates and keep asking for reboots. You’d rather catch that on ten machines than a thousand.

The Full Runbook

The reference notes behind this — the exact prerequisites, the annual baseline/hotpatch calendar, and the click-by-click for both Intune policies including the VBS caveats — live in my knowledge base as a copy-pasteable runbook, so I’m not rebuilding the setting paths from memory the next time a tenant is ready to move Windows patching off the RMM:

→ Windows 11 Hotpatch Notes — part of my open MSP Microsoft 365 knowledge base on GitHub.

The runbook gets you the deployment. The case is simpler: your RMM’s weakest patching step is the reboot, and hotpatch delivers Windows security updates without one — on the native pipeline built for exactly that — for eight months out of twelve. Leave the RMM the jobs it’s good at, and let the platform that was designed to patch Windows do the patching.