From /hotpatch to $1.50 a Core: The Live-Patch Pipeline Microsoft Built and Then Made Public

1. The hook: a $1.50-per-core-per-month reboot bill#

Microsoft's Visual C++ compiler ships a /hotpatch switch. The flag is small, almost forgettable: when set, the compiler guarantees that the first instruction of every function is at least two bytes long and that no jump within the function targets the prologue. Those two bytes are the enabling primitive for everything that follows in this article. They are the place where a running operating system can be quietly amended without being stopped.

On July 1, 2025, Microsoft began charging $1.50 USD per CPU core per month for the right to use that primitive on Windows Server 2025 outside Azure. The 26 years in between are the subject of this article.

The shock of a metered subscription on a 30-year-old compiler feature is the question this article exists to answer. Three current Windows hot-patch products run on top of a single internal engineering pipeline:

• Windows Server 2022 Datacenter: Azure Edition, GA on February 16, 2022, free for Azure VMs. The first public surface of the modern pipeline.
• Windows 11 Enterprise 24H2 client, GA on April 2, 2025, license-gated through Intune Autopatch.
• Windows Server 2025, GA on July 1, 2025 over Azure Arc at $1.50 USD per CPU core per month for on-premises and multi-cloud machines, with the reboot frequency reduced from 12 times a year to 4.

"Hotpatching is an impact-less update technology which has been keeping the Azure fleet up-to-date for years with zero impact on customer workloads." -- Microsoft's Windows OS Platform team, November 2021

That single sentence is the load-bearing claim. The customer-facing product launched in February 2022 was not a research result. It was the externalization of an internal pipeline that had been quietly servicing Azure for years. The 2022, 2025, and 2025 GA dates are the points at which Microsoft turned the same engineering machine outward, one customer surface at a time.

So the question. Microsoft did not invent in-memory function replacement on Windows in 2022. Microsoft shipped it in 2003. Why did it take 17 years to come back? The answer threads through a failed first attempt, a state-aligned APT, the entire Linux live-patching family tree, and an architectural change that did not exist when the original mechanism was designed. The compiler flag does not change. Everything around it does.

2. The 2003 original: Server 2003 SP1 hotpatching and why it mattered#

In May 2011, a German systems engineer named Johannes Passing sat down with a Server 2003 kernel and a debugger and reverse-engineered, function by function, how an MS06-030 hot patch landed in memory. His walkthrough is one of the cleanest contemporaneous records of a Microsoft feature that nearly nobody used. The trace looks like this, copied verbatim from his debugger session:

nt!MmLoadSystemImage
nt!MmHotPatchRoutine+0x59
nt!ExApplyCodePatch+0x191
nt!NtSetSystemInformation+0xa1e

NtSetSystemInformation, with the magic class SystemHotpatchInformation, dispatched into ExApplyCodePatch, which called MmHotPatchRoutine, which finally called MiPerformHotPatch to walk the patch image's metadata and rewrite the target driver's instructions. The example Passing followed targeted mrxsmb.sys and rdbss.sys for the SMB bug that MS06-030 fixed. The patch worked. It worked in production. And almost nobody ever shipped one.

The enabling primitive is the compiler flag from §1. The MSVC documentation states the contract: when /hotpatch is used at compile time, every function begins with an at-least-two-byte first instruction with no internal jumps to it. The x86 convention that fell out of this was the famous mov edi, edi instruction at the start of every Windows function -- a 2-byte NOP-equivalent that, per Raymond Chen's verbatim Microsoft DevBlogs description, can be replaced with a two-byte JMP $-5 instruction to redirect control to five bytes of patch space that comes immediately before the start of the function without ever being read in a half-modified state.

The 2003 design paired this prologue convention with a payload format and a delivery syscall. The OpenRCE community published the format details in 2006: the hot-patch image was a normal PE module with a section called .hotp1, at least 80 bytes long, beginning with a HOTPATCH_HEADER followed by a relocation-and-replacement table. On kernel-mode targets, MmHotPatchRoutine walked the headers and rewrote the live .text. On user-mode targets, an updating agent enumerated the running processes and injected a remote thread into each one to perform the equivalent rewrite. The mechanism shipped in Server 2003 SP1 and was available on XP SP2 across x86, IA-64, and x64. Primary sources disagree on the service-pack attribution: the OpenRCE 2006 writeup labels availability as "Server 2003 SP0, XP SP2 x86, ia64, x64," while Johannes Passing's 2011 walkthrough and Microsoft's 2016 MMPC blog both say "Server 2003 SP1." The article picks the Microsoft-leaning side; the OpenRCE attribution remains in tension.

It also never really shipped. The Server 2003 hotpatch engine was a credible developer feature that did not become an operational habit. A handful of advisories ever produced a .hotp1 payload; the feature was quietly retired by Windows 8. Why? Three structural reasons -- and a fourth that did not become visible until 2016.

So the four failures of the 2003 design:

1. No consistency model. The prologue overwrite was atomic at the instruction level, but the design said nothing about a thread that was already executing the function body. If an in-flight call could finish in the old code while a new call into the same function landed in the new code, certain bug fixes that changed semantics across the call were unsound. The 2003 engine handled the easy cases and trusted the patch author for the rest.
2. No architectural trust anchor. Any kernel-mode code with permission to call NtSetSystemInformation(SystemHotpatchInformation) could install a "hot patch." Driver signing and Authenticode were the only line of defense, and Microsoft would discover ten years later that they were not enough.
3. No servicing-model integration. Hot patches were ad-hoc per-advisory artifacts. There was no quarterly baseline, no hotpatch-month cadence, no servicing-stack-level expectation that a customer would receive a hot patch instead of a reboot. Operations teams had to opt into each one.
4. Limited content coverage. Function-body replacement only. No struct-layout migration, no driver-version transitions in the boot path, no ELAM. The pool of advisories that could ship as a .hotp1 was small.

The fourth failure -- the one Microsoft discovered the hard way -- is the subject of the next section.

3. Why the 2003 pipeline failed: politics, operations, and PLATINUM#

In April 2016, Microsoft Threat Intelligence published a report on a state-aligned APT group it tracked as PLATINUM. The mainstream coverage of that report named the group's activity as dating to 2009 and described its tradecraft: PLATINUM was abusing the same NtSetSystemInformation(SystemHotpatchInformation) interface Microsoft itself had shipped, to inject backdoors named Dipsing, Adbupd, and JPIN into winlogon.exe, lsass.exe, and svchost.exe. Microsoft's own MMPC blog said of the hot-patch tradecraft itself, preserved verbatim on the Wayback Machine: "Using hotpatching in the malicious context has been theorized, but has not been observed in the wild before." The April 2016 disclosure was the first in-the-wild observation. The exact start date for PLATINUM's use of the technique is not in the public record; what is in the record is that the mechanism Microsoft had introduced as a customer feature had quietly become a detection-evasion technique by the time Microsoft caught it.

In retrospect Microsoft drew a two-part lesson, visible in the structure of the modern design. First: in-memory code mutation is necessary if you want to live-patch a fleet at any reasonable scale, because reboots are too expensive and operationally too political to schedule monthly. Second: in-memory code mutation cannot ship safely without an architectural trust anchor distinct from the kernel code being mutated, and it cannot ship operationally without a delivery system that constrains what mutations are allowed. The Server 2003 engine had the first half. It had nothing resembling the second half.

Both halves of that lesson took 17 years to be ready. Hardware-mediated isolation under Virtualization-Based Security (VBS) shipped in Windows 10 in 2015; HVCI (the Hypervisor-protected Code Integrity component) and the Secure Kernel matured through subsequent releases; and the cumulative-update servicing model that replaced the GDR/QFE branch split arrived with Windows 10 and was back-ported to Windows 7 and 8.1 in October 2016. Each of those preconditions had to be standard before a successor hot-patch design could exist.

The mechanism of hot patching is older than the product. Microsoft did not invent in-memory function replacement on Windows in 2022. It shipped it in 2003, watched it fail operationally, and then discovered in April 2016 that PLATINUM, a group active since 2009, had been weaponizing the same primitive. The work that took 17 years was not the binary rewriting. It was the trust anchor, the servicing discipline, and the management plane that would make rewriting a fleet's .text safe to operate.

While Microsoft's 2003 attempt was atrophying in the field, an MIT graduate student named Jeff Arnold was about to publish what would become the canonical academic treatment of the same problem -- and the Linux community was about to spend a decade and a half working through every consistency-model variant a function-replacement system can have. The Linux side of the story is the next four sections in compressed form.

4. Linux takes the wheel: Ksplice, kpatch and kGraft, mainline livepatch#

In June 2008, Jeff Arnold submitted his MIT Master of Engineering thesis. The cover page names him and his supervisor, M. Frans Kaashoek, only. The thesis's claim, presented as a measurement rather than a hope: 42 of 50 (84%) of all significant x86-32 Linux security patches from May 2005 to December 2007 could be applied to a running kernel by Ksplice without a human writing new code. The patches were applied by treating the source diff as a binary diff and lifting the object-level differences onto the running kernel under stop_machine() quiescence.

Ten months after the thesis, in April 2009, Arnold and Kaashoek's EuroSys paper tightened the headline number: 56 of 64 patches from May 2005 to May 2008, or 88% of significant x86-32 Linux kernel security patches, applied with no new code. That number became the founding empirical claim of the entire field. Every live-patcher built since has been measured against it.

Then the field stalled. Oracle acquired Ksplice on July 21, 2011, pulled Red Hat support, and made the technology Oracle Linux Premier Support customers only. For three years, Linux had no community-shipped live patcher.

timeline
title Live-patching, 1996 to 2026
1996-1999 : MSVC /hotpatch ships
2005      : Server 2003 SP1 hotpatch engine
2008-2009 : Ksplice (Arnold and Kaashoek)
2011      : Oracle acquires Ksplice
2014      : kGraft (SUSE) and kpatch (Red Hat)
2015      : Linux 4.0 merges in-tree livepatch
2016+     : Hybrid consistency model lands
2016+     : VBS and HVCI mature in Windows 10
2018-2021 : Microsoft Azure host fleet on internal hot patch
Feb 2022  : Server 2022 Azure Edition public GA
Apr 2025  : Win11 Enterprise 24H2 client GA
Jul 2025  : Server 2025 over Arc at $1.50/core/month

The stall ended in early 2014 with two near-simultaneous re-attempts at the same problem. SUSE's Jiri Kosina and Jiri Slaby published kGraft on February 3, 2014, as a 600-line patch that built on the kernel's existing ftrace infrastructure plus a per-task "two universe" model, with switchover at kernel-exit. SUSE presented kGraft at the Linux Foundation Collaboration Summit on March 27, 2014, and issued a press release crediting SUSE Labs as the origin. Red Hat's kpatch project had announced publicly on February 26, 2014; on May 1, 2014, Josh Poimboeuf sent the kpatch RFC to LKML, with Seth Jennings co-named on the development team. Red Hat published Poimboeuf's introductory blog describing kpatch's four components: a build tool, a per-fix hot-patch module, the kpatch core module that hooked ftrace, and a userspace utility.

The two designs differed at exactly one place: the consistency model. Kpatch chose stop_machine plus a backtrace check -- "a sledgehammer," in LWN's contemporaneous phrase, that halted every CPU and walked every task's stack to verify the old code was not in flight before swapping it for the new. kGraft chose a per-task flag and a lazy migration at kernel-exit -- elegant in concept, but with an unbounded transition tail for tasks that never crossed back into user mode. Kpatch could not patch always-on-stack functions like schedule(), do_wait(), or irq_thread(); LWN estimated a few dozen such functions in a typical kernel. kGraft could in principle patch anything but might never finish converging.

Two near-equivalent re-attempts, one tree-shaped politics problem: only one design could be merged. LWN's coverage of the contest is now the canonical retrospective. The compromise came in Linux 4.0, released April 12, 2015: merge the ftrace-based common core, defer the consistency-model question. Both kpatch and kGraft survived as out-of-tree front-ends on top of the in-tree core.

A year later, Josh Poimboeuf landed the hybrid consistency model that the in-tree v1 had postponed. The result is what the kernel.org documentation today calls, in three converged paragraphs of formerly contested design:

"Livepatch has a consistency model which is a hybrid of kGraft and kpatch: it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching." -- Documentation/livepatch/livepatch.rst, kernel.org

The hybrid uses three convergence approaches in sequence: walk every task's stack at a quiescent point (kpatch's stack-check), transition any remaining tasks lazily at kernel-exit (kGraft's per-task), and finally handle idle "swapper" tasks and forked tasks with separate convergence rules. The architecture is gated on HAVE_RELIABLE_STACKTRACE, which is itself a non-trivial per-architecture invariant.

// Toy simulator of the hybrid livepatch consistency model.
// Each task is in one universe (0 = old, 1 = new). The transition
// finishes when every task has migrated.

function simulate({ nTasks = 100, perTickKernelExit = 0.20, stackCheckPass = 0.60 }) {
const tasks = Array.from({ length: nTasks }, () => ({ universe: 0, blocked: false }));
let tick = 0;
let converged = 0;

// Phase 1: stack check (kpatch). Migrate every task whose stack does NOT contain
// a patched function. We model this as a per-task pass probability.
for (const t of tasks) {
  if (Math.random() < stackCheckPass) {
    t.universe = 1;
    converged++;
  }
}

// Phase 2: per-task kernel-exit (kGraft). Each tick, a fraction of remaining
// tasks transition the next time they cross from kernel to user mode.
while (converged < nTasks && tick < 1000) {
  tick++;
  for (const t of tasks) {
    if (t.universe === 0 && Math.random() < perTickKernelExit) {
      t.universe = 1;
      converged++;
    }
  }
}

return { tick, converged, total: nTasks };
}

const r = simulate({ nTasks: 100, perTickKernelExit: 0.20, stackCheckPass: 0.60 });
console.log('Converged ' + r.converged + '/' + r.total + ' tasks in ' + r.tick + ' ticks');
console.log('Phase 1 (stack check) caught ~60 percent; phase 2 (kernel-exit) caught the rest.');

The key insight from this decade and a half of Linux engineering, stated as an empirical observation that has not been overturned: function-level live patching is tractable if and only if you accept that struct-layout changes still require a reboot. Every Linux generation between 2008 and 2026 confirms this rule. Ksplice's 88% is precisely the fraction of patches that happen to leave data structures alone.

While the Linux community was building the hybrid, Microsoft was watching from inside Azure -- and was rebuilding hot patching from scratch on a different foundation.

5. The modern mechanism: HPAT, IMAGE_HOT_PATCH_BASE, NtManageHotPatch, and the Secure Kernel#

On November 19, 2021, the Windows OS Platform blog published a piece called "Hotpatching on Windows". Buried in the second paragraph is the load-bearing sentence: "The hotpatch engine requires the Secure Kernel to be running." That single requirement is the architectural pivot. It is what separates the modern pipeline from the 2003 original, from Ksplice, and from every Linux livepatch design built before or since. It is also the answer to the trust-anchor failure that PLATINUM exploited.

Walk the chain of structures, in the order the kernel walks them. There are six steps.

5.1. Compile time: hot-patch metadata into every patchable PE#

The target binary is built with hot-patch metadata. The eligible scope, according to the November 2021 blog, covers user-mode DLLs and EXEs, kernel-mode drivers, the hypervisor, and the Secure Kernel itself. Modern Microsoft compiler toolchains lay the metadata into a structured table inside the binary; the published reference is the PE optional header's load-config directory.

5.2. Image metadata: the IMAGE_HOT_PATCH_INFO and IMAGE_HOT_PATCH_BASE chain#

HotPatchTableOffset points at an IMAGE_HOT_PATCH_INFO structure. The Microsoft Rust bindings document its fields verbatim: Version, Size, SequenceNumber, BaseImageList, BaseImageCount, BufferOffset, ExtraPatchSize. The BaseImageList is itself an RVA into one or more IMAGE_HOT_PATCH_BASE records, with fields SequenceNumber, Flags, OriginalTimeDateStamp, OriginalCheckSum, CodeIntegrityInfo, CodeIntegritySize, PatchTable, and BufferOffset.

The two fields that are doing the real work, semantically, are OriginalTimeDateStamp and OriginalCheckSum. They name the exact base image to which the patch binds. The HPAT proper -- the Hot Patch Address Table reachable from the PatchTable field -- enumerates each patchable site inside the base image: where the prologue lives, what bytes go there, and how to redirect to the replacement function body.

flowchart TD
A[PE optional header] --> B["IMAGE_LOAD_CONFIG_DIRECTORY64"]
B --> C["HotPatchTableOffset (RVA)"]
C --> D["IMAGE_HOT_PATCH_INFO\nVersion / Size / SequenceNumber\nBaseImageList / BaseImageCount"]
D --> E["IMAGE_HOT_PATCH_BASE\nOriginalTimeDateStamp\nOriginalCheckSum\nCodeIntegrityInfo / Size\nPatchTable"]
E --> F["HPAT entries\nper-function patch sites"]
F --> G["Replacement function bodies\n(in the patch PE)"]

5.3. Patch payload: a separate signed PE32+#

Each hot patch ships as a separate signed PE32+ image. The patch image's own IMAGE_HOT_PATCH_BASE.OriginalTimeDateStamp and OriginalCheckSum must match the base image's load-time fields exactly. The kernel refuses to apply a hot patch whose binding metadata does not match the running base. This is the binding rule that prevents a hot patch produced for kernel32.dll build N from accidentally landing on build N+1.

The patch PE may export a special function __PatchMainCallout__. If present, it is invoked automatically after the patch is loaded in each process as a per-process initialization hook -- a hot-patch equivalent of a DLL's DllMain.

5.4. NtManageHotPatch: the dedicated syscall#

The 2003 design overloaded NtSetSystemInformation(SystemHotpatchInformation). The modern design has its own syscall. The ntdoc reference records the signature verbatim:

NTSTATUS NtManageHotPatch(
    _In_      HOT_PATCH_INFORMATION_CLASS HotPatchInformationClass,
    _Out_writes_bytes_opt_(HotPatchInformationLength) PVOID HotPatchInformation,
    _In_      ULONG HotPatchInformationLength,
    _Out_opt_ PULONG ReturnLength
);

The same reference notes the syscall's PHNT_VERSION >= PHNT_WINDOWS_11 availability gate, which corresponds operationally to Windows 11 and Windows Server 2022 and later. The call dispatches on HotPatchInformationClass in the style of NtQuerySystemInformation, with separate operations to create, activate, map, and list patches.

5.5. Trust anchor: the Secure Kernel under HVCI#

The pivotal architectural difference. Per the Windows OS Platform team's November 2021 blog: the Secure Kernel mediates patch validation and the actual .text rewrite. The Secure Kernel is the kernel-side counterpart to the Isolated User Mode (IUM) trustlet world, running in Virtual Trust Level 1 (VTL1) under VBS, with HVCI enforcing the invariant that executable code pages must be signed by an entity the normal kernel trusts.

5.6. Per-process rollout: ntdll callback and PatchMainCallout#

No global stop-the-world. The kernel enumerates running processes and calls a notification callback inside ntdll.dll in each process, which re-maps the patched code from a kernel-curated view into the process's address space. If the patch PE exports __PatchMainCallout__, that function runs in each process immediately after the patch lands. The per-process model means the patch transition is asynchronous and decentralized; there is no equivalent of Linux's stop_machine() quiescence, and no equivalent of kGraft's per-task universe flag. The cost is a more complex security boundary -- the Signal Labs analysis observes that a process can attempt to load a hot patch repeatedly with a payload that fails validation, producing a denial-of-service vector against specific target processes if administrative privileges have been compromised.

sequenceDiagram
actor Admin as Administrator
participant UM as User-mode caller
participant NK as Normal kernel
participant SK as Secure Kernel (VTL1)
participant Proc as Each running process
participant NTDLL as ntdll.dll per process

Admin->>UM: Initiate patch install
UM->>NK: NtManageHotPatch(class=Activate)
NK->>SK: Forward patch PE for validation
SK->>SK: Verify signature, OriginalTimeDateStamp,\nOriginalCheckSum, code-integrity hash
SK->>SK: Walk HPAT, rewrite .text under HVCI
SK-->>NK: SUCCESS
NK->>Proc: Walk processes that mapped the base image
NK->>NTDLL: Invoke per-process notification callback
NTDLL->>NTDLL: Re-map patched code into address space
alt Patch exports <strong>PatchMainCallout</strong>
NTDLL->>Proc: Invoke <strong>PatchMainCallout</strong>()
end
NTDLL-->>NK: Per-process completion

Walking the HPAT chain in code#

The chain from optional header to per-function patch site is small enough to walk by hand. The block below is a teaching skeleton: it does not execute against a real PE binary; it shows the field-by-field traversal that a kernel-side validator performs every time NtManageHotPatch(Activate) is called.

// Teaching skeleton. The shapes match the public Microsoft documentation
// (ms-image-load-config64, ms-rs-image-hot-patch-info, ms-rs-image-hot-patch-base).
// The structures are populated with placeholder values; a real kernel-side
// validator reads bytes from the on-disk PE and the in-memory image.

function walkPatchChain(peImage) {
const optionalHeader = peImage.optionalHeader;
const loadConfig     = peImage.read(optionalHeader.loadConfigRVA, 'IMAGE_LOAD_CONFIG_DIRECTORY64');
const hpatTableRVA   = loadConfig.HotPatchTableOffset;
if (!hpatTableRVA) {
  return { eligible: false, reason: 'no HotPatchTableOffset; binary not compiled hotpatchable' };
}

const info = peImage.read(hpatTableRVA, 'IMAGE_HOT_PATCH_INFO');
const bases = [];
for (let i = 0; i < info.BaseImageCount; i++) {
  const baseOffset = info.BaseImageList + i * peImage.sizeOf('IMAGE_HOT_PATCH_BASE');
  const base = peImage.read(baseOffset, 'IMAGE_HOT_PATCH_BASE');
  bases.push(base);
}

// The kernel verifies a patch by matching THIS image's OriginalTimeDateStamp
// and OriginalCheckSum against the patch PE's corresponding fields. If they
// mismatch, the kernel refuses the patch with STATUS_HOT_PATCH_FAILED.
return {
  eligible: true,
  info,
  bases,
  bindingFields: bases.map(b => ({
    stamp: b.OriginalTimeDateStamp,
    checksum: b.OriginalCheckSum,
    patchTableRVA: b.PatchTable
  }))
};
}

The three architectural differentiators#

Three differences from the 2003 design, stated bluntly because they are the load-bearing distinctions:

1. Dedicated NtManageHotPatch syscall instead of overloaded NtSetSystemInformation. Distinct attack surface, instrumentable separately, with its own access-control rules.
2. Signed PE32+ patch images verified by the Secure Kernel, not bare driver-signing on a .hotp1 payload. The verifier sits in VTL1, architecturally distinct from the kernel that holds the .text mapping.
3. HPAT metadata baked into every patchable binary at compile time, not a single-flag prologue plus .hotp1 section pair. The metadata names the patchable sites individually, with a per-site flag vocabulary that admits future operations the 2003 engine could not represent.

The Secure Kernel is the load-bearing innovation, not HPAT. HPAT is mechanism -- a structurally cleaner version of the 2003 metadata, with per-site flags and binding fields the older format did not have. The architectural advance is that HVCI's "executable pages were signed" invariant is preserved across a hot patch because the new pages came from a signed PE whose signature chains to Microsoft and the normal kernel cannot bypass that verification. Linux livepatch trusts the standard module-signing policy enforced by the kernel it is patching. Microsoft's modern design moves the verifier into a different, architecturally isolated kernel.

The mechanism is now complete. What remains is the pipeline around it.

6. The three-stack decomposition: mechanism, delivery, management#

There is no single thing called "Windows hot patching." There are three layers that look like one thing if you squint -- and explaining them as one thing is the most common pedagogical mistake in this space. Each layer has its own engineering team, its own failure modes, its own primary documentation. Treat them in order.

Layer A -- the kernel mechanism. Everything in §5: HPAT, IMAGE_HOT_PATCH_BASE, NtManageHotPatch, and the Secure Kernel. Microsoft documents Layer A unevenly. The structure definitions are public via the Rust windows-docs bindings (IMAGE_HOT_PATCH_INFO, IMAGE_HOT_PATCH_BASE) and the IMAGE_LOAD_CONFIG_DIRECTORY64 reference. The syscall signature is in the community-maintained ntdoc reference. The most thorough public field-level documentation of the runtime behavior is Signal Labs' reverse-engineering writeup and an independent PoC repository that exercises the syscall. There is no equivalent of the kernel.org Documentation/livepatch/livepatch.rst file inside Microsoft's official docs.

Layer B -- the servicing model. This is where the operational pipeline lives. The Microsoft Learn reference for Hotpatch on Windows Server describes the cadence verbatim: hot patching first establishes a baseline with the current Cumulative Update for Windows Server, and every three months that baseline refreshes with the latest Cumulative Update. Between baselines, two hotpatch-only releases ship: months in which the only payload is the security-update delta as a signed hot-patch PE.

There are two types of baselines, again per Microsoft Learn. Planned baselines are the quarterly LCU drops that follow the cumulative-update cadence -- one each January, April, July, October. Unplanned baselines preempt a hotpatch month when the month's security content cannot ship as a hot patch: a kernel struct-layout change, a driver update, an SSU, a language-pack update, or any security fix in a non-hotpatchable component. The promise is that the channel maintains parity with the content of security updates issued to the regular non-Hotpatch Windows update channel. Customers who run hot patching are not getting a curated subset of fixes. They are getting the same fix set, in a different delivery mode.

gantt
title Windows Hotpatch servicing cadence
dateFormat YYYY-MM-DD
axisFormat %b
section Servicing
Planned baseline LCU (reboot)  :crit, b1, 2026-01-01, 30d
Hotpatch only                  :h1, 2026-02-01, 30d
Hotpatch only                  :h2, 2026-03-01, 30d
Planned baseline LCU (reboot)  :crit, b2, 2026-04-01, 30d
Hotpatch only                  :h3, 2026-05-01, 30d
Hotpatch only                  :h4, 2026-06-01, 30d
Planned baseline LCU (reboot)  :crit, b3, 2026-07-01, 30d
Hotpatch only                  :h5, 2026-08-01, 30d
Hotpatch only                  :h6, 2026-09-01, 30d
Planned baseline LCU (reboot)  :crit, b4, 2026-10-01, 30d
Hotpatch only                  :h7, 2026-11-01, 30d
Hotpatch only                  :h8, 2026-12-01, 30d

The reboot frequency on a hot-patch-eligible fleet drops from 12 a year to 4 a year, per Microsoft's April 24, 2025 Windows Server blog. That 3:1 reduction is the operational claim. It is conditional on the fleet being eligible every month -- on no month's security content being non-hotpatchable -- so the realized reduction depends on which CVEs Microsoft has to fix in any given quarter.

Layer C -- the management plane. Layer C is where compliance, telemetry, ring-based rollout, eligibility detection, and fallback behavior live. There are three management surfaces for the three product variants:

• Azure Update Manager for Azure VMs running Server 2022 Datacenter: Azure Edition and Server 2025 Datacenter: Azure Edition. The control plane is built into the VM SKU; onboarding is a SKU selection and an update-management association.
• Intune Autopatch for Windows 11 Enterprise 24H2 clients. The Microsoft Learn doc for Autopatch hot patching lays out the license requirements (Windows 11 Enterprise E3/E5, Microsoft 365 F3, Education A3/A5, M365 Business Premium, or Windows 365 Enterprise), the prerequisite that VBS must be turned on, and the silent-fallback behavior for ineligible devices: a Hotpatch-policy-enrolled device that does not meet the prerequisites simply receives the regular LCU instead.
• Azure Arc Hotpatch for Server 2025 outside Azure. The connection to Azure Arc is the delivery channel; the meter that runs at $1.50 per CPU core per month is operationalized through Arc.

Telemetry is a property of Layer C. The kernel patch engine reports per-process completion to the normal kernel; the normal kernel reports per-machine completion to whichever Layer C surface is in charge of that machine. Conflating "the kernel reports patch success" with "Microsoft is telemetering my workload" is wrong in the same way conflating Layer A with Layer C is wrong.

flowchart LR
subgraph LayerA["Layer A: Kernel mechanism"]
A1["HPAT + IMAGE_HOT_PATCH_BASE"]
A2["NtManageHotPatch syscall"]
A3["Secure Kernel under HVCI"]
A1 --> A2 --> A3
end
subgraph LayerB["Layer B: Servicing model"]
B1["Quarterly baseline LCU"]
B2["2 hotpatch-only months between baselines"]
B3["Unplanned baselines for non-hotpatchable content"]
B1 --> B2 --> B3
end
subgraph LayerC["Layer C: Management plane"]
C1["Azure Update Manager (Server, Azure)"]
C2["Intune Autopatch (Win11 24H2 clients)"]
C3["Azure Arc Hotpatch (Server 2025, outside Azure)"]
end
LayerC --> LayerB --> LayerA

So: what is hot-patchable? Per the Microsoft Learn Hotpatch Autopatch documentation, Hotpatch updates are Monthly B-release security updates that install and take effect without requiring you to restart the device. And what is not?

On Arm64 Win11 24H2 clients, Hotpatch is additionally incompatible with servicing CHPE OS binaries located in %SystemRoot%\SyChpe32. Operators who depend on CHPE for x86-on-Arm64 app compatibility cannot enable Hotpatch on those devices today.

"The experience is so seamless you don't even know what happened. There are no process restarts, no logging out, no performance impact. No glitch in the video playing or transaction dropping. Everything just works as if nothing has happened." -- Nevine Geissa, Partner Group PM, Windows Servicing and Delivery, Microsoft Inside Track

Three layers, three failure modes. The Linux side of the story made different choices at each. The next section does the head-to-head along the axes that actually matter.

7. Windows hot patching vs Linux livepatching: different primitives, same problem#

Two well-engineered systems. One shared goal. Four divergent answers. The comparison is not "Windows is better" or "Linux is better." The comparison is that each design made specific architectural choices that follow logically from preconditions the other system did not have.

The trust-anchor row is the load-bearing one. Linux's in-tree livepatch documentation describes the consistency model in considerable detail; it describes the kernel-module-signing policy in less detail because the policy is the same one Linux uses for any kernel module. The verifier is the kernel itself. If an attacker who has obtained the necessary capability to install kernel modules can also forge or replace the module-signing key, the verifier is downstream of the attacker. Windows's design moves the verifier behind an architectural boundary. The normal kernel that mediates the syscall does not perform the verification. The Secure Kernel does, in VTL1, behind a hypervisor that the normal kernel cannot subvert without first compromising the Secure Kernel directly.

The redirection row is the next most consequential. The Linux design uses ftrace trampolines because ftrace had already solved the safe-rewriting problem inside Linux when kpatch and kGraft started. Layering live patching on top of ftrace meant the live-patcher's mechanical scope was small: "redirect callers of this function." The Windows design rewrites the function prologue directly with an instruction-sized atomic write. The two primitives have different failure modes. ftrace adds a permanent indirection cost to every traced function on the system; the in-place rewrite has zero steady-state cost but a more complex one-time write.

flowchart TD
Start["Start: install patch P"] --> Phase1{"Phase 1: stack check (kpatch)"}
Phase1 -- "Task's stack clean" --> Migrate1["Migrate task to new universe"]
Phase1 -- "Patched fn on stack" --> Phase2{"Phase 2: wait for kernel-exit (kGraft)"}
Phase2 -- "Task crosses kernel-exit" --> Migrate2["Migrate at exit"]
Phase2 -- "Stuck in kernel" --> Phase3{"Phase 3: idle-loop + forced-signal fallback"}
Phase3 -- "Idle swapper" --> Migrate3["Migrate idle task"]
Phase3 -- "kthread" --> Special["Reliable-stacktrace gate; kthreads remain hard"]
Migrate1 --> Done["Patch live for task"]
Migrate2 --> Done
Migrate3 --> Done

The scope row tells a related story. The November 2021 Windows OS Platform blog explicitly says Windows hot patches can target user-mode binaries, drivers, the hypervisor, and the Secure Kernel itself. Linux's livepatch is kernel-only by design; Oracle's Ksplice has user-mode add-ons for glibc and OpenSSL available to Oracle Linux Premier Support customers, but no other mainstream Linux live-patcher covers user-mode. The Windows choice to cover user-mode is operationally significant: many high-impact security fixes target services that run in lsass.exe, svchost.exe, or product-specific user-mode daemons, and Linux's userspace equivalent of those fixes still requires the affected processes to be restarted.

A brief tour of what is going on in the field today. Ksplice is Oracle-Linux-Premier-Support-only since the 2011 acquisition, with the glibc/OpenSSL user-mode coverage being the most distinctive remaining feature. kpatch is in maintenance mode; the build tooling has been promoted into the kernel tree as klp-build, and the project's GitHub README documents the deprecation explicitly. kGraft survives as an out-of-tree front-end primarily for SUSE customers, with the relevant consistency-model logic having been merged into the in-tree hybrid years ago. Windows Modern Hotpatch is the system this article is about.

Both systems work. Both have ceilings. The next section is where the ceiling actually is.

8. The theoretical ceiling: what no function-replacement system can ever do#

Every live-patching system on Earth ships with the same warning, in different words. There is a class of patches that none of them can apply. The class is well-defined and the explanation is not engineering -- it is logic.

Data-layout changes. A patch that changes the layout, size, or invariants of any static data structure read or written by code not also being patched in the same transaction breaks every function-replacement live-patcher. Ksplice's 88% headline is precisely the fraction of patches that happen to leave data structures alone. The 12% that does not is what every live-patching design defers to reboot.

The reason is structural. Suppose a kernel struct foo has fields (a, b, c) and the patch wants to add a field d. Every function that reads or writes a foo operates on the old layout; new functions added by the patch operate on the new layout. The transition window contains threads in flight that hold pointers into the old struct, and any new code that allocates or writes a foo would corrupt them. The general algorithmic question -- "can this layout change be applied safely to an arbitrary running kernel?" -- is undecidable in the general case, because deciding it is equivalent to deciding what an arbitrary running program's memory invariants are.

Boot-anchored measurements. ELAM (Early Launch Anti-Malware) drivers, DRTM (Dynamic Root of Trust for Measurement) and Secure Launch components, and other measurement-scoped binaries have their hashes extended into TPM PCRs at boot. A hot patch that mutates such a binary after attestation breaks the post-attestation invariant: the verifier downstream of the attestation expected a measured value that no longer corresponds to the running binary. The post-rewrite memory is not inside the original attestation envelope; the attestation has to be re-rooted, which requires a reboot. Microsoft's exclusion list reflects this -- drivers (including ELAM), boot-loader components, and Secure Launch / DRTM measurement-scoped binaries are not hot-patchable in the published servicing model.

Inlined or always-on-stack code. Function-replacement systems require a single entry point per logical function. A function that has been inlined into every caller has no entry point to patch. A function that is always somewhere on a stack -- kpatch's classic examples of schedule(), do_wait(), and irq_thread() -- effectively behaves as if inlined for the purpose of the live-patcher, because the stack-check phase can never converge on a quiescent moment. LWN's coverage estimated a few dozen such functions on a typical Linux kernel; the equivalent class for Windows is the never-quiescent kernel entry points that one cannot patch without first taking the system out of operation.

Concurrency invariants. Lock-free algorithms, RCU readers in flight, and code execution orderings that the patch quietly changes require quiescence beyond what any function-replacement primitive offers. The Linux livepatch consistency-model debate at LWN 634649 and the kernel.org livepatch.rst §7 "Limitations" document this class of constraint: a patch that subtly changes the order of memory operations in a function that participates in a lock-free protocol can leave readers observing impossible states across the transition. The literature on this is mostly cautionary, not exhaustive; the live-patcher's job is to assume any patch that touches concurrent code is unsafe by default and require the patch author to argue otherwise.

The empirical upper bound, again, is the Ksplice 88% number from a finite window of x86-32 Linux security patches between May 2005 and May 2008. Microsoft has not published a comparable automation-rate study for the modern Windows pipeline; the public claim is that the channel maintains parity with the content of security updates issued to the regular non-Hotpatch channel, with unplanned baselines preempting hotpatch months when the content is not eligible. That is an operational claim, not a percent-of-CVEs measurement.

The ceiling on every live-patching system is Rice's theorem applied to memory-layout semantics. No general algorithm decides whether an arbitrary data-layout change is safe to apply to an in-flight program; therefore every live-patcher treats data-layout changes the same way -- defer to reboot. The 12% that remains is the open research problem live-patching has been carrying for 18 years; Ksplice's 88% set the ceiling no successor has moved.

The remaining 12% is the problem of the next generation. The open problems are the subject of §9.

9. Open problems: where the pipeline is still evolving#

Hot patching is "done" only in the sense that it ships. Four problems remain open as of May 2026.

9.1. Confidential VMs and the attestation envelope#

AMD SEV-SNP and Intel TDX provide a measured launch of a guest VM image attested to a relying party. Microsoft's own Azure confidential-VM documentation states the contract verbatim: "Azure confidential VMs boot only after successful attestation of the platform's critical components and security settings", and an in-VM workload can issue an attestation request to "verify that your confidential VMs are running a hardware instance with either AMD SEV-SNP, or Intel TDX enabled processors." The attestation establishes that a specific image -- byte for byte, hash for hash -- is what is running inside the confidential VM. If NtManageHotPatch later rewrites guest .text, is the post-rewrite memory inside the attestation envelope? Does the relying party need to re-verify? Microsoft has not publicly documented this interaction. The hot-patch SKU eligibility list covers Server 2022 and Server 2025 Datacenter: Azure Edition; confidential VM SKUs run on adjacent Azure infrastructure; the documented intersection is a gap. Framed as a documented gap, not speculated beyond.

9.2. The subscription metering question#

$1.50 per CPU core per month for Server 2025 hot patching over Azure Arc is the first time a major OS vendor has metered live patching with a per-CPU-core meter rather than per-machine (Canonical Livepatch via Ubuntu Pro) or per-CPU-pair (Oracle Ksplice bundled into Oracle Linux Premier Support). Azure Arc is itself a management plane, so the framing is "metered, per-core, on a management plane" rather than "metered outside any subscription tier." Forbes' coverage confirms the pricing and the July 1, 2025 GA. The economic question -- does pricing accelerate or decelerate patch adoption across the global Windows Server fleet? -- has no public data yet. The fairness question -- should faster patching cost more, when faster patching makes the world safer? -- has no answer that does not depend on assumptions about which fleets are doing the patching.

9.3. Detection and abuse of the same primitive#

Signal Labs has shown that the same NtManageHotPatch mechanism can be repurposed for in-memory code injection PoCs under specific privilege conditions; an independent PoC repository corroborates by exercising the syscall against a controlled target. The risk is structurally similar to the 2003-era hot-patch abuse Microsoft disclosed in April 2016, but with two important differences: the modern path requires the Secure Kernel to validate a signed payload (the 2003 path did not), and operators have an explicit registry knob -- HotPatchRestrictions=1 at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management -- documented as the way to disable CHPE servicing on Arm64 so those devices remain eligible for hot patching. EDR vendors who want to distinguish legitimate Microsoft-signed hot patches from hostile injection have to instrument both the syscall and the registry state. This is solvable, but it is not solved by default in every EDR.

9.4. Arm64 client porting and CHPE#

Arm64 Windows 11 24H2 hot patching remains in preview as of the April 2025 GA for x64, with the CHPE compatibility issue acting as the visible technical gate.

The Linux equivalent of the Arm64 porting story is the HAVE_RELIABLE_STACKTRACE gate and the related kthread caveats. Kthreads on architectures without reliable stack-trace support remain a hard case for the in-tree hybrid consistency model.

For an operator deciding today which of these open problems matters, the answer depends on which of the three Windows products is theirs. The next section is the practical decision tree.

10. The operator's decision: adopting hot patching in 2026#

The operator question is not "should I hot-patch?" but "which of the three products is mine and what does it actually cost?" Walk through the tree.

10.1. Windows Server 2022 Datacenter: Azure Edition#

Free on Azure IaaS. The product was announced as generally available on February 16, 2022 (this is also confirmed by a contemporaneous external mirror). Onboarding is a SKU selection (-Hotpatch suffix variants), an Azure Update Manager association, and a baseline alignment to the current LCU. The Server 2022 hotpatch initially shipped Server-Core-only; the Desktop Experience GA on July 18, 2023 removed the operationally-large adoption blocker for admins who refused Server Core. From that date forward, all common Server 2022 Azure Edition VM configurations are hot-patch-eligible.

10.2. Windows Server 2025 Datacenter / Standard via Azure Arc#

$1.50 USD per CPU core per month outside Azure, [generally available since July 1, 2025](https://www.microsoft.com/en-us/windows-server/blog/2025/04/24/tired-of-all-the-restarts-get-hotpatching-for-windows-server/). Free on Azure IaaS / Azure Local for Server 2025 Datacenter: Azure Edition VMs. The math at$1.50/core/month is mechanical: a 128-core machine is $192/month or$2,304/year for the hot-patch subscription; an eight-machine 128-core cluster is $18,432/year. Whether that price is justified depends on the operator's per-reboot cost.

// Per-fleet break-even calculator. Inputs are organization-specific.
// The function returns whether the Arc hot-patch subscription is cheaper
// than the cost of the avoided reboots, assuming 8 hot-patch months a year
// (4 reboots/year baseline vs 12 without hot patching).

function breakEven({ cores, perCoreMonthly = 1.50,
                   rebootsAvoidedPerYear = 8,
                   costPerRebootEvent,
                   fleetSize = 1 }) {
const subscriptionAnnual = cores * perCoreMonthly * 12 * fleetSize;
const avoidedRebootCost  = costPerRebootEvent * rebootsAvoidedPerYear * fleetSize;
return {
  subscriptionAnnual,
  avoidedRebootCost,
  netSavings: avoidedRebootCost - subscriptionAnnual,
  worthIt: avoidedRebootCost > subscriptionAnnual
};
}

// Example: a 128-core box, 100-machine fleet, $1,200 per reboot event
// (coordination, downtime, ops overhead). 8 hotpatch months avoided per year.
const r = breakEven({
cores: 128, fleetSize: 100, costPerRebootEvent: 1200, rebootsAvoidedPerYear: 8
});
console.log('Subscription annual: $' + r.subscriptionAnnual.toLocaleString());
console.log('Avoided reboot cost: $' + r.avoidedRebootCost.toLocaleString());
console.log('Net savings        : $' + r.netSavings.toLocaleString());
console.log('Worth it           : ' + r.worthIt);

10.3. Windows 11 Enterprise 24H2 client#

License-gated through Intune Autopatch. The license bar, per Microsoft Learn, is one of Windows 11 Enterprise E3/E5, Microsoft 365 F3, Education A3/A5, M365 Business Premium, or Windows 365 Enterprise. VBS must be on. Ineligible devices (VBS off, CHPE binaries present on Arm64, or any other policy mismatch) silently fall back to LCU; the device's user experience is unchanged except that hot-patch months still require the usual monthly reboot. Hot patching is staged via Intune Autopatch quality update policy with the hot-patch toggle enabled; eligibility detection runs per device. The Bleeping Computer coverage of the April 2025 client GA cross-confirms the dates and the licensing model.

The Autopatch default-on flip turns hot patching into the default for eligible Windows 11 24H2 Enterprise devices in the May 2026 servicing cycle; opt-out controls become effective on April 1, 2026 for organizations that need to delay the transition.

10.4. Operational rules that apply to all three#

• Quarterly baseline alignment is non-negotiable. A machine that drifts off the current quarterly baseline cannot consume the next hot-patch month; it falls back to a full LCU until it realigns.
• Unplanned baselines preempt hot-patch months for un-hotpatchable security content. Operators cannot opt out of an unplanned baseline. The fix Microsoft has to ship for a kernel-struct-changing zero-day will land as a reboot-requiring LCU regardless of Hotpatch policy.
• Monitor patch state via the management plane. Azure Update Manager (Server, Azure), Intune Autopatch dashboards (clients), and Arc Hotpatch (Server outside Azure) each report per-device or per-VM patch state. Alert on baseline drift; alert on Hotpatch-policy-enrolled devices that have silently fallen back to LCU.

The remaining questions are the ones every reader hits. The FAQ is next.

11. Frequently asked questions#

Hot patching is a pipeline, not a feature. The mechanism Microsoft shipped in February 2022 is older than the public product; the real engineering work between 2003 and 2022 was the trust anchor (the Secure Kernel under HVCI, mature only after 2015), the servicing discipline (cumulative-update model from 2016, hot-patch / baseline cadence from 2022), and the management plane (Azure Update Manager, then Intune Autopatch, then Azure Arc, each a separate operations product layered on the same kernel engine). The mechanism is the easy part. The hard part is the architecture around it that makes in-memory mutation safe to operate at fleet scale.

Whether $1.50 per CPU core per month is worth it for your fleet is a math problem you can now do. Whether the Confidential VM attestation interaction gets cleanly documented before the next product wave is somebody else's problem. The compiler flag has not changed in 30 years. Everything around it has.