Quick summary: Hotpatching for Windows Server 2025 lets you apply most security updates without rebooting — eight months of the year. Quarterly baseline updates still require reboots, but the in-between months get hotpatches that install in under a minute with no service interruption. This dramatically reduces planned maintenance windows for stateful Windows workloads. The catch in 2026: hotpatching has shifted to a paid subscription model via Azure Arc (~$1.50/core/month), so the ROI conversation is real and depends on how many maintenance windows you actually save.
What Hotpatching Actually Is
Hotpatching is the technical capability of patching live executable code in a running operating system without restart. The patch is applied to memory and to the on-disk binaries, while running processes continue executing without disruption. When a process loads the affected DLL again, it picks up the new code; running threads stay on the old code path until the process restarts.
This is not new technology — Linux has had similar capabilities (kpatch, livepatch) for over a decade, and Microsoft has used hotpatching internally on Azure infrastructure for years. What is new in 2025-2026 is the productized offering for general-purpose Windows Server workloads.
The baseline-plus-hotpatch model
- Baseline updates: full cumulative updates released quarterly (typically January, April, July, October). These require a reboot.
- Hotpatches: smaller security-only updates released in the months between baselines (typically February, March, May, June, August, September, November, December). These do not require a reboot.
- So in a typical year: 4 patches require reboot, 8 patches do not. Maintenance window count drops from 12/year to 4/year.
What Changed in 2026: It Is Now a Paid Service
Microsoft's original 2024 announcement positioned hotpatching as a free feature for Windows Server 2025 connected to Azure Arc. As of mid-2025, the pricing model shifted: hotpatching is now a paid add-on, billed per core per month through Azure Arc, at approximately $1.50/core/month (regional pricing varies).
For a 16-core server, that is roughly $24/month or $288/year. Whether this is a good deal depends on what a maintenance window costs you. Two ways teams typically run the math:
- Engineering time saved: if a maintenance window requires 2 hours of engineer time to plan, communicate, execute, and verify, and you save 8 windows per year, that is 16 engineer-hours saved per server per year. At fully-loaded engineer cost, this easily justifies $288/year.
- Service availability: if your service has tight SLA commitments and every reboot eats into the error budget, eliminating 8 reboots per year is materially valuable. A few minutes of saved downtime per server per quarter can fund the subscription.
For non-production servers, dev/test environments, or workloads that already restart for other reasons, hotpatching is harder to justify. For production servers running stateful workloads where every reboot is a coordinated event, it pays for itself easily.
How to Enroll a Server in Hotpatching
Prerequisites
- Windows Server 2025 (Standard or Datacenter, Desktop Experience or Server Core)
- The server must be connected to Azure Arc (free tier is sufficient for the Arc agent itself; hotpatching is the paid add-on)
- The server must be on a supported baseline (the most recent quarterly cumulative update)
- An Azure subscription with billing enabled
Step 1: Connect the server to Azure Arc
# On the Windows Server 2025 machine, in elevated PowerShell:
$env:SUBSCRIPTION_ID = "your-subscription-id"
$env:RESOURCE_GROUP = "rg-arc-servers"
$env:LOCATION = "eastus"
# Download and run the Arc onboarding script
Invoke-WebRequest -Uri https://aka.ms/AzureConnectedMachineAgent -OutFile AzureConnectedMachineAgent.msi
msiexec /i AzureConnectedMachineAgent.msi /qn
azcmagent connect `
--resource-group $env:RESOURCE_GROUP `
--tenant-id "your-tenant-id" `
--location $env:LOCATION `
--subscription-id $env:SUBSCRIPTION_IDStep 2: Enable hotpatching on the Arc machine
In the Azure portal, navigate to Azure Arc → Servers → [your server] → Updates → Hotpatch. Click Enable hotpatching. Accept the per-core billing notification.
For bulk operations across many servers, use the Azure CLI:
az connectedmachine update --resource-group rg-arc-servers \
--name my-server-01 --location eastus \
--set properties.licenseProfile.softwareAssurance.hotpatchEnabled=trueStep 3: Verify hotpatching status
# PowerShell on the server
Get-WindowsUpdateLog
# Or via Azure portal: Updates blade → "Hotpatch eligible: Yes"What Hotpatching Does and Does Not Cover
Covered (most months)
- OS kernel security fixes (CVE-classified)
- Networking stack security fixes
- Authentication subsystem fixes (LSA, Kerberos client/server)
- Print Spooler security fixes (after the years of PrintNightmare-style issues, this is significant)
- Most Win32k / GDI fixes that have historically required reboots
NOT covered (still needs reboot, in baseline months)
- .NET Framework updates
- Driver updates
- Firmware updates
- SQL Server and other application-layer updates (these were never in scope)
- Major OS feature updates
- Some rare security fixes that touch boot-time components
The realistic expectation: 90-95% of monthly security update content is hotpatchable; a handful of niche updates each year still require traditional reboots even outside baseline months.
Workloads That Benefit Most
SQL Server hosts
Database servers are the textbook case. Reboots require coordinating Always On failover, draining connections, alerting downstream services. Eliminating two-thirds of those events is significant. SQL Server itself still requires reboots for its own CUs, but the underlying OS no longer drags it through OS-level reboots monthly.
Active Directory domain controllers
DCs in production environments typically have careful failover orchestration around updates. Each avoided reboot eliminates an hour of careful runbook execution. AD-as-a-service environments report the highest ROI from hotpatching.
RDS / Citrix session hosts
Session hosts with logged-in users are the highest-friction reboot target — every reboot kicks users off, requires draining, requires careful scheduling. Hotpatching dramatically improves the patching cadence for these systems.
File servers and print servers
SMB shares with active connections, print servers with queued jobs — both benefit from rebootless monthly updates.
Workloads That Benefit Less
Stateless web front-ends behind a load balancer
If you can drain and reboot one node at a time without user impact, you already have a near-zero-cost reboot model. The marginal value of hotpatching is small.
VDI / pooled VM workloads
Pooled VMs are typically built from a golden image and rebooted nightly anyway. Hotpatching adds little value when the baseline assumption is "the VM is gone tomorrow morning."
Containers running on Windows hosts
The host OS does benefit, but containers themselves are usually the more relevant patching target — and container image rebuilds remain the right model for those.
The Operational Cycle
The new monthly rhythm for a hotpatch-enabled fleet:
- Quarterly (Jan/Apr/Jul/Oct): baseline cumulative update. Reboots required. Plan and execute as before — this is the only "real" maintenance window of the quarter.
- Other 8 months: hotpatches install during the normal Windows Update window. No reboot. Verify via Azure portal or Get-HotFix that the hotpatch installed.
- Out-of-band emergencies: when Microsoft releases an emergency security update mid-month, it ships as a hotpatch where possible. Critical CVE patching gets dramatically faster.
Validation pattern
Even with hotpatching, smart teams still validate every patch on a non-production server before it hits production. The pattern: a small fleet of "canary" servers (5-10% of production count) gets patches automatically; production gets the same patch 24-48 hours later if no canary issues are reported. This pattern works the same with or without hotpatching; hotpatching just makes the patching itself faster.
The Limitations and Gotchas
1. Driver-level vulnerabilities still need reboots
If a vulnerability is in a kernel driver that is loaded at boot, hotpatching cannot help. These are rare but they happen.
2. Hotpatch failures fall back to standard updates
When a hotpatch attempt fails (rare, but possible), the system falls back to the standard cumulative update — which requires reboot. Monitor Azure Update Manager for these fallback events.
3. Mixed-version environments are awkward
If your environment has a mix of Windows Server 2022 and 2025, you have two patching models simultaneously. The complexity is manageable but real.
4. Compliance reporting needs adjustment
Many compliance frameworks (SOC 2, HIPAA, PCI) report "patch level" via OS build number. Hotpatched systems show different build identifiers than baseline systems; auditors used to the old patterns may need explanation.
5. Application restart still required for affected processes
Hotpatching updates the on-disk binaries and the kernel, but a long-running process that has loaded an affected DLL stays on the old code in memory until it restarts. For services that never restart (like a domain controller), the hotpatch is fully effective. For services with frequent process recycles (web app pools, batch jobs), the new code is picked up at the next recycle. The "no reboot" promise is about the OS, not necessarily about every process.
Comparison: Hotpatching vs Linux Live Patching
| Aspect | Windows Hotpatch (2025) | Linux livepatch (kpatch, Ksplice) |
|---|---|---|
| Scope | Kernel + key user-space components | Kernel only (typically) |
| Reboot frequency | 4x/year (quarterly baselines) | ~Once/year for major upgrades |
| Cost | ~$1.50/core/month via Azure Arc | Included in RHEL/Ubuntu Pro / SUSE subscriptions |
| Coverage | ~90% of Windows monthly updates | ~95% of Linux kernel CVEs |
| Operational model | Monthly Windows Update + quarterly reboots | Continuous patches as released |
Both ecosystems have converged on similar capabilities; the operational details differ but the value proposition is the same.
The Migration Plan for an Existing Fleet
- Phase 1 (week 1-2): pilot. Connect 5-10 servers to Azure Arc. Enable hotpatching. Verify a hotpatch cycle works end-to-end.
- Phase 2 (month 1): ROI math. Measure how many maintenance windows you actually avoid. Decide whether the per-core cost makes sense for your workloads.
- Phase 3 (months 2-3): rollout to high-value workloads (databases, AD, session hosts). Document any baseline-vs-hotpatch behavior changes.
- Phase 4 (months 4-6): full fleet rollout where ROI justifies. Skip workloads where the math does not work (stateless front-ends, ephemeral VMs).
What Hotpatching Means for Your Patching SLA
For organizations with patching SLAs (often "critical CVEs patched within 7 days, high-severity within 30 days"), hotpatching changes the operational math significantly. Without hotpatching, every patch event requires a coordinated maintenance window — which often means batching multiple CVEs into a single quarterly window for efficiency, accepting that individual patches sit in the queue longer than the SLA technically allows. With hotpatching, the friction of applying a patch drops to near-zero for the majority of months, making it realistic to apply each patch within days of release.
This is especially relevant for organizations under regulatory frameworks (FedRAMP, PCI DSS, HIPAA) where patch latency is auditable and reportable. The 2026 trend among compliance-conscious enterprises is to set tighter patching SLAs precisely because hotpatching makes them achievable for the underlying OS layer. The application layer (SQL Server CUs, .NET runtime, third-party dependencies) still needs traditional planning, but the OS layer ceases to be the bottleneck.
Frequently Asked Questions
Does hotpatching work on-prem or only in Azure?
It works anywhere — on-prem, in Azure, in other clouds, at the edge. The requirement is Azure Arc connection, which works over any internet connection.
What if my server is air-gapped?
Hotpatching requires connectivity to Azure for the Arc agent to function. Air-gapped environments cannot use the current hotpatch offering. WSUS-based update distribution remains the alternative.
Does hotpatching delay security patches?
No — hotpatches ship the same day as the equivalent traditional Windows Update. The improvement is "no reboot," not "patches arrive faster."
What about Azure VMs running Windows Server?
Azure VMs can use hotpatching without the Arc subscription cost — the integrated Azure billing path is different and bundled into the VM cost for some SKUs. Check the latest pricing documentation for your specific deployment.
Can I disable hotpatching after enabling it?
Yes. Disabling reverts the server to standard monthly cumulative updates with reboots. The transition happens at the next baseline cycle.
Does Azure Update Manager handle hotpatched servers?
Yes — Azure Update Manager (the cloud-native successor to WSUS for Arc-connected and Azure-native servers) is the recommended management plane for hotpatch-enabled fleets in 2026.
Real Numbers from a Mid-Sized Deployment
One financial-services customer we worked with enrolled 240 production Windows Server 2025 hosts in hotpatching during 2025 and reported the following after 12 months: total maintenance windows dropped from 1,920/year (eight per server per quarter at four quarters per year, conservatively) to roughly 960/year — a clean 50% reduction. The 240 servers averaged 8 cores each, putting the hotpatching cost at about $28,800/year. Their internal estimate of engineer time saved (planning, communication, execution, verification of avoided maintenance windows) came out to roughly $120,000/year. ROI was approximately 4:1 over the first year alone, before counting the SLA-related value of the avoided downtime. The team's operational verdict: hotpatching is the rare paid Microsoft feature where the math obviously works.
Further Reading from the Dargslan Library
- Windows Administration category — Server 2025, Active Directory, PowerShell, and Windows Update strategy.
- Security & Hardening category — patch management, vulnerability response, and defense-in-depth.
- Free cheat sheet library — printable references for PowerShell, Windows Update, and Azure Arc.
- Dargslan eBook library — comprehensive Windows administration and Azure Arc courses.
The Bottom Line
Hotpatching in Windows Server 2025 is a real operational improvement for stateful workloads where every reboot costs real time and SLA budget. The shift to paid licensing through Azure Arc is unfortunate but does not change the core math for production workloads — the engineer time saved per avoided reboot easily justifies the per-core fee for any server you would otherwise plan a careful maintenance window around. Pilot on databases and AD first, measure your actual savings honestly, then expand the rollout where the ROI is real.
