"Who Is This Code?" -- The Quiet 33-Year Reinvention of App Identity in Windows

Two identities, one operating system#

On July 27, 1993 -- the day Windows NT 3.1 shipped -- the new operating system could prove with cryptographic precision who Alice was, which group she belonged to, which file she was allowed to open, and at what level of privilege she was running. It could prove exactly nothing about the program she had just double-clicked.

Thirty-three years later, "Alice" has barely changed. The code she runs has acquired a publisher signature stamped onto its Portable Executable file, a kernel-loader gate that refuses to load unsigned drivers, a signer level in a runtime lattice that decides whether one process can read another's memory, a Package SID derived from a Crockford-Base32 hash of the manifest publisher ^[1], a publisher-rule entry in a centrally managed App Control policy ^[2], a Mark-of-the-Web alternate data stream from the browser that downloaded it ^[3], a SmartScreen reputation score ^[4], a possible entry on a Microsoft-curated denylist that overrides its own valid signature ^[5], and -- on a Pluton-equipped 2026 laptop -- a hardware-attested measurement of the boot chain that loaded it ^[6]. Every one of those identities was forced into existence by a specific failure of the one before. This is that story.

A modern symptom makes the asymmetry concrete. In April 2026, attackers seized the publishing pipeline for the @bitwarden/cli npm package -- a credential they had no business holding -- and shipped a backdoored release for ninety-three minutes before maintainers caught it ^[7]. Code identity, as it existed at every layer of every operating system that consumed that package, said the artifact was authentic. The signature was valid. The publisher's account was real. The package metadata was correct. Every check passed. And the binary was hostile. That gap, between "who shipped it" and "is it safe to run," is the same gap NT 3.1 first stepped over in 1993 and that Windows has been trying to close ever since.

The Bitwarden case sits in a long company. Stuxnet's stolen Realtek and JMicron driver-signing keys (2010) ^[8], Flame's MD5 collision against Microsoft's own intermediate CAs (2012) ^[9], the ASUS ShadowHammer pipeline compromise (operation 2018, disclosed 2019) ^[10], every "Bring Your Own Vulnerable Driver" rootkit since 2018 -- they all have the same shape. A valid Windows-anchored signature, on code the publisher did not intend to ship, on a machine that loaded it without complaint.

Every Windows code-identity primitive introduced since 1996 was forced into existence by a specific failure of the layer before it. The article's spine is that cascade.

The pieces in 2026 are not a feature checklist. They are a layered system, each layer answering a question its predecessor structurally could not. If you read the Microsoft Learn pages one at a time you see eight unrelated products. If you read them in the order their failures forced them into existence, you see one operating system slowly learning to name the code it runs.

timeline
title Windows code identity, 1993 to 2026
1993 : NT 3.1 ships : user-only principal
1996 : Authenticode : publisher signature on PE
2002 : Trustworthy Computing memo : SDL forcing function
2006 : Vista x64 KMCS : refusal of unsigned kernel code
2010 : Stuxnet : stolen Realtek + JMicron keys
2012 : AppContainer : per-app SID
2012 : Flame : MD5 collision against MS CA
2013 : Windows 8.1 PPL : signer level as runtime ACL
2015 : Device Guard / WDAC : publisher policy
2019 : ASUS ShadowHammer disclosed : compromised pipeline (2018 operation)
2020 : Pluton announced : in-die security processor
2022 : Driver Block List default-on : signed != trusted
2024 : CrowdStrike outage : placement is identity
2025 : MVI 3.0 user-mode preview : kernel/user split

Timeline sources, in row order (Mermaid syntax does not permit inline tokens inside the timeline block; each event is independently cited in the surrounding prose as well): 1993 NT 3.1 ^[11]; 1996 Authenticode ^[12]; 2002 Trustworthy Computing memo ^{[13] [14]}; 2006 Vista x64 KMCS ^[15]; 2010 Stuxnet ^[8]; 2012 AppContainer ^[1]; 2012 Flame MD5 collision ^{[9] [16]}; 2013 Windows 8.1 PPL ^{[17] [18]}; 2015 Device Guard / WDAC ^[2]; 2019 ASUS ShadowHammer disclosed (operation 2018) ^[10]; 2020 Pluton announced ^[6]; 2022 Driver Block List default-on ^[5]; 2024 CrowdStrike outage ^{[19] [20]}; 2025 MVI 3.0 user-mode preview ^{[21] [22]}.

If user identity was easy, why did code identity take thirty-three years -- and where exactly did each generation break?

Why code had no name#

Helen Custer's 1992 Inside Windows NT opens its security chapter on a single principle: the user is the principal ^[11]. Every action the kernel arbitrates is attributable to a user account. The token that the kernel manufactures at logon carries a Security Identifier (SID) for the user, SIDs for each group the user belongs to, a privilege bitmap, and a set of impersonation flags. Every Discretionary Access Control List on every securable object is evaluated against that token ^[23]. The kernel never asks what binary is running. It asks who is running it.

For 1993's threat model, the user-as-principal model was defensible. NT 3.1 lived on multi-user workstations in a trusted local-area network. The attacker the designers worried about was a malicious insider, a contractor with the wrong group membership, an admin who exceeded his authority. Code arrived on floppies and CDs from coworkers and shrink-wrapped vendors; nobody downloaded executables off the public internet, because for most of the world there was no public internet to download them from.

Then came Internet Explorer 3.0 in August 1996 and ActiveX. Microsoft repositioned OLE/COM as a cross-internet component model and committed to letting any compliant ActiveX control execute inside the browser ^[12]. The decision was not casually made; it was the strategic foundation of Microsoft's bet on the web. But its consequence at the security layer was immediate and devastating.

If Alice double-clicks a control on a web page, the operating system's question is "who is running this?" The answer is "Alice." She is allowed to run anything she wants. The control does whatever it likes -- with her token, her files, her privileges, her network access. The user-as-principal model has no second axis to invoke.

There was no theoretical fix at this layer. Alice did genuinely request the download. She did genuinely double-click. NT had no other principal to consult. The model was complete, internally consistent, and exactly wrong for the new threat surface.

What was missing was a cryptographic, network-portable identity for the code itself, attached to the binary in a way nobody downstream could forge. If the kernel cannot see the code, who can put a name on it -- and how do we attach that name to a running PE?

The first naive attempt: Authenticode (1996)#

On August 7, 1996, Microsoft and VeriSign jointly announced the first cryptographic answer Windows had ever offered to "who is this code?" The press release ran twenty-two paragraphs and named every design choice that the next thirty years of Windows code identity would inherit: an X.509 certificate issued by an external commercial Certificate Authority, a PKCS#7 SignedData blob attached directly to the binary, and verification at download or install time by Internet Explorer 3.0 ^[12].

"The new Microsoft Authenticode technology uniquely identifies the publisher of a piece of software and provides assurance to end users that it has not been tampered with or modified." -- Microsoft press release, August 7, 1996 ^[12]

That sentence is the founding promise of Windows code identity. Read it once and the rest of the article becomes inevitable. Authenticode promises two things. It identifies the publisher. It detects tampering. It does not promise that the publisher is trustworthy, that the publisher's key is uncompromised, or that the bytes it covers are safe to execute. Three decades of failure modes follow from exactly that scoping.

The mechanism is precise enough to demand a diagram. SignTool computes a hash that deliberately skips three regions of the PE: the checksum field (which the loader recomputes), the certificate-table directory entry, and the certificate table itself. The signature does not have to sign the bytes of its own embedding ^[24].

It then forms a PKCS#7 SignedData structure ^[25] containing the hash, an algorithm identifier, the X.509 chain, and an optional RFC 3161 timestamp. That blob is appended to the certificate table. At verify time, WinVerifyTrust recomputes the hash, walks the chain to a trusted root, and (if a timestamp is present) honours signatures that were valid as of the timestamped time even if the issuer has since revoked the certificate ^[26].

sequenceDiagram
participant Dev as Developer
participant Sign as SignTool
participant PE as PE binary
participant Win as WinVerifyTrust
participant CA as CA / chain store
Dev->>Sign: signtool sign /a app.exe
Sign->>PE: hash bytes (skip checksum + cert table)
Sign->>PE: build PKCS#7 SignedData
Sign->>PE: append RFC 3161 timestamp
Sign->>PE: write into Attribute Cert Table
Note over Win: at install / download time
Win->>PE: re-hash same byte ranges
Win->>PE: extract PKCS#7 SignedData
Win->>CA: verify X.509 chain to trusted root
CA-->>Win: chain ok
Win-->>Win: trust verdict (advisory pre-Vista)

Three structural failure modes shipped on day one and still ship in 2026.

Userland was advisory. A signed .exe ran. An unsigned .exe also ran. Internet Explorer would prompt the user with a publisher name, but the prompt was a UI feature, not a kernel gate. The signature was a credential offered for inspection, never a wall the loader refused to cross. Closing this gap took ten years for kernel code (Authenticode 1996 ^[12] -> KMCS, Vista 2006 ^[15]) and nineteen years for managed user-mode policy (Authenticode 1996 ^[12] -> Device Guard, 2015 ^[2]). Unmanaged consumer Windows in 2026 still permits arbitrary unsigned .exe to run if the user clicks through SmartScreen.

The signed hash did not cover the whole file. This is CVE-2013-3900, disclosed by Microsoft on December 10, 2013 in security bulletin MS13-098 ^[27]. The Authenticode hash skips the certificate-table region by design, and the verifier in WinVerifyTrust did not constrain the size of the unsigned PKCS#7 blob. An attacker could append arbitrary unauthenticated bytes inside the WIN_CERTIFICATE structure of an already-signed PE without invalidating the signature.

The fix was a registry value, EnableCertPaddingCheck=1, that turned on strict verification. Microsoft chose not to enable it by default. Twelve years later, the National Vulnerability Database still records the same scoping note: "Microsoft does not plan to enforce the stricter verification behavior as a default functionality on supported releases of Microsoft Windows" ^[28]. CISA added CVE-2013-3900 to its Known Exploited Vulnerabilities catalog on January 10, 2022 -- eight years after disclosure, because attackers were still abusing the unfixed default ^[28].

Timestamped signatures survive revocation. The trust evaluator in WinVerifyTrust is told to trust signatures as of the timestamped instant, not as of now. Removing this property would invalidate large catalogs of legitimate, archived signed software whose signing certificates have since expired ^[26]. The same property is what let the Stuxnet drivers load on every Windows machine that received them, because Microsoft revoked the Realtek and JMicron certificates after Stuxnet had already shipped.

Pull these three threads together and the first aha falls out. Authenticode names the publisher, not the code. A signed binary is a credential, not a verdict. The signature proves the bytes came from a holder of the publisher's private key. It does not prove the publisher is trustworthy, that the publisher's key has not been stolen, or that the bytes are safe to execute. Every failure mode of the next twenty-five years lives in that gap.

Six years of failure modes had to accumulate before Microsoft executive priorities caught up. On January 15, 2002, Bill Gates sent the "Trustworthy Computing" memo company-wide, declaring security a higher priority than features and freezing engineering work for security review across every Microsoft product ^{[13] [14]}. The memo did not specify a code-identity mechanism. It is in this story because every later code-identity primitive -- the Security Development Lifecycle's mandatory SignTool integration, the XP SP2 hardening pass that produced MOTW, and the Vista work that produced KMCS -- shipped under the executive cover the memo provided ^[30].

If unsigned code still runs in userland, what makes us think the same primitive will work for a kernel driver -- where the wrong binary owns the operating system?

The first refusal: KMCS, EV, and the WHQL pipeline (Vista, 2006)#

Vista x64 shipped in November 2006 as the first Windows release that refuses to load unsigned kernel code ^[15]. The refusal was uncompromising. The kernel loader and the Plug-and-Play manager call into WinVerifyTrust for every driver image; if the chain does not terminate at one of a small set of Microsoft-trusted roots, MmLoadSystemImage returns STATUS_INVALID_IMAGE_HASH and the driver does not load.

The mechanism is a load-time gate. In 2026, Microsoft offers three signing tiers that all terminate at a Microsoft cross-signed cert: HLK-tested (the full Windows Hardware Lab Kit run, eligible for retail Windows Update distribution), attestation-signed (lighter-weight, EV cert plus Microsoft attestation key, no hardware testing), and preproduction (developer signing for pre-release Windows builds) ^{[31] [32]}. Driver .cat catalog files extend Authenticode coverage from a single PE to an entire driver package, including INF files and supporting executables ^[33].

EV certificates -- Extended Validation, with mandatory hardware-security-module key storage and audited issuance -- became the practical floor for kernel signing. The reason was not pedagogical. A Domain Validated Authenticode cert from a commodity CA in that era could be obtained cheaply, often with little more than a working email address. EV raised the cost and binding strength of the publisher claim by an order of magnitude.

Then, on June 17, 2010, Sergey Ulasen of the Belarusian anti-virus vendor VirusBlokAda flagged a strange piece of malware on a customer machine in Iran. It had been signed ^[34].

The Stuxnet dropper carried two kernel drivers, mrxnet.sys and mrxcls.sys, signed with legitimate Authenticode certificates issued to Realtek Semiconductor and JMicron Technology -- two Taiwanese hardware vendors. Investigators concluded the private keys had been physically exfiltrated from the publishers' Taiwanese offices. Microsoft and VeriSign revoked the Realtek certificate on July 16, 2010 and the JMicron certificate shortly afterward ^[8]. While the certs were valid, Vista x64 KMCS happily loaded both drivers on every system it touched.

The Stuxnet certificates were not anomalies. The same failure shape -- valid Microsoft-rooted signature, on code the publisher did not intend to ship, on a healthy KMCS-enforcing kernel -- replays at predictable intervals.

ASUS ShadowHammer in 2018, disclosed by Kaspersky in 2019, added a third variant. The attackers did not steal an HSM-bound key. They compromised ASUS's signing pipeline and got their backdoor signed by ASUS's production signing key in the normal course of a normal release, distributed through ASUS Live Update ^[10]. Kaspersky's analysis recorded "trojanized updaters were signed with legitimate certificates (eg: 'ASUSTeK Computer Inc.')" and that "over 57,000 Kaspersky users have downloaded and installed the backdoored version of ASUS Live Update." The trust root, the chain, the cert -- all valid. The bytes -- attacker-controlled.

KMCS verified that a driver was signed, not that it was safe. Signing alone was not enough. But what was?

The second refusal: identity as a runtime attribute (PPL, 2013)#

Until October 17, 2013, code identity gated whether code could load. Windows 8.1 quietly shipped a structural shift: code identity now also gated what one running process could do to another ^[17]. Alex Ionescu, then independent and previously a co-author of Windows Internals, was the first person to publish a detailed external map of the new mechanism. The lineage runs back to Vista's 2006 Protected Process model, originally introduced as a DRM container for protected media playback; PPL is the security-grade descendant of that primitive, repurposed seven years later as a general-purpose process-protection mechanism ^[30].

The mechanism lives in the kernel's EPROCESS object. When process A opens process B, the kernel calls into RtlTestProtectedAccess (and downstream PsTestProtectedProcessIncompatibility) before any DACL evaluation ^[35]. If A's signer level is below B's, sensitive access masks are silently stripped from the returned handle. The classic effect: an attacker running with a SYSTEM token, holding SeDebugPrivilege, calling OpenProcess on LSASS, gets back a handle without PROCESS_VM_READ. Mimikatz can no longer dump the LSASS process memory.

The signer level itself is set by an Enhanced Key Usage extension on the Authenticode certificate Microsoft issues to the binary's publisher. Antimalware vendors receive a certificate carrying the Antimalware EKU; only Microsoft-internal binaries carry WinTcb ^[36]. Identity, in this model, is an EKU OID baked into a Microsoft-issued Authenticode cert, attached to the binary, evaluated by the kernel at every cross-process access check.

flowchart TD
A[WinSystem]
B[WinTcb]
C[Windows]
D[Lsa]
E[Antimalware]
F[CodeGen]
G[Authenticode]
A --> B --> C --> D --> E --> F --> G
H["Caller (signer level X)"] -- "OpenProcess(target T, signer Y)" --> I{"X >= Y ?"}
I -- yes --> J["full access mask"]
I -- no  --> K["VM_READ / VM_WRITE / CREATE_THREAD stripped"]

LSASS-as-PPL is the canonical demonstration of the mechanism in practice. Setting HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL=1 causes the next boot's LSASS to start with PsProtectedSignerLsa. From that moment, no process below the Lsa signer level can read LSASS memory, regardless of the user account. Mimikatz still runs as code; its OpenProcess(LSASS, PROCESS_VM_READ) call returns a handle with the read right stripped, and its memory dump fails with STATUS_ACCESS_DENIED before it ever sees a credential blob ^[36].

ELAM -- Early Launch Antimalware -- is the same idea applied to boot. An ELAM driver, signed with a Microsoft-issued antimalware certificate, runs before any third-party boot driver and gets to vote on which subsequent drivers are allowed to load ^[37]. Signer level enters the boot chain at the earliest moment third-party code can enter the boot chain.

PPL's invention is conceptual, not just mechanical. Code identity becomes a runtime ACL between two running processes, not merely a load-time gate. App Control, HVCI, and the Driver Block List all operate on this same conceptual frame: identity continuously evaluated, in context, while code is executing.

PPL was, and is, the right idea. It is also incomplete in two ways that drove every subsequent layer.

The first gap is BYOVD -- Bring Your Own Vulnerable Driver. A signed-but-vulnerable driver such as RTCore64.sys (shipped with MSI Afterburner), Capcom.sys (shipped with the Street Fighter V anti-cheat), or gdrv.sys (shipped with Gigabyte motherboard utilities) gives any local administrator arbitrary kernel read/write through an IOCTL. Because these drivers are validly KMCS-signed, they load. From kernel mode, the attacker simply zeroes the Protection byte in the target process's EPROCESS structure, and PPL evaporates. The signing chain is sound. The signer level is correctly evaluated. The mechanism that decides which kernel code is allowed to exist -- not just to be signed -- is what fails.

The second gap is the user-mode side. PPLdump and PPLfault demonstrated that confused-deputy DLL loads inside higher-PPL services could be turned into an arbitrary memory read of LSASS. Microsoft eventually patched PPLdump in Windows 10 21H2 build 19044.1826, but the failure class remains structural: trusting a higher-signer process to safely load DLLs from publisher-controlled paths is a foot-gun every time a new such service ships ^{[38] [35]}.

If signer level is the principal for OS-internal processes, what is the principal for the next layer up -- the application?

The application becomes a principal: AppContainer and the Package SID#

Two processes, same user, same machine. One can read the user's SSH private keys. The other cannot. Same token. Same DACLs on the file. Different verdict. That is the AppContainer promise ^[39], and to keep it the operating system needs a cryptographic identity for the application itself -- something derived from the application, not from the user, that ACLs can name.

Windows 8 shipped AppContainer in 2012. Internally it was called LowBox, the name surviving in the legacy documentation ^[40]. Windows 10 generalised the model into MSIX, the modern app-package format ^[41].

The cryptographic move is in how the SID is built.

The derivation is dense enough to deserve a worked example. Microsoft Corporation plus the Microsoft.WindowsCalculator package name yields Microsoft.WindowsCalculator_8wekyb3d8bbwe -- the suffix is the Crockford-Base32 PublisherId of Microsoft Corporation's subject DN ^[1]. Every MSIX package whose Publisher DN matches will share that suffix; every package whose Publisher DN differs will have a different suffix; an attacker who does not hold the publisher's signing key cannot make a package masquerade as belonging to that publisher's family.

async function publisherIdOf(publisherDN) {
const data = new TextEncoder().encode(publisherDN);
const digest = await crypto.subtle.digest('SHA-256', data);
const first8 = new Uint8Array(digest.slice(0, 8));
// Crockford Base32 alphabet (no I, L, O, U)
const alpha = '0123456789abcdefghjkmnpqrstvwxyz';
let bits = 0n;
for (const b of first8) bits = (bits << 8n) | BigInt(b);
let out = '';
for (let i = 0; i < 13; i++) {
  out = alpha[Number(bits & 31n)] + out;
  bits >>= 5n;
}
return out;
}
const dn = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US';
publisherIdOf(dn).then(pid => console.log('PFN suffix candidate:', pid));
console.log('Real PFN: Microsoft.WindowsCalculator_8wekyb3d8bbwe');
console.log('Note: the real algorithm is documented in package-identity-overview; this snippet demonstrates the structure, not the exact hash.');

Capabilities sit at the same layer. When an MSIX manifest declares <Capability Name="internetClient" />, the package is tagged at install time with a capability SID of the form S-1-15-3-1, and the Windows Filtering Platform evaluates outbound TCP connections against that SID, not against the user's ^[42]. Mandatory Integrity Control labels (Low/Medium/High) compose with the AppContainer SID rather than replacing it ^[43]. A broker process running outside the AppContainer is the only path back to user-scoped resources, and the broker keys its trust decisions on the calling Package SID.

The aha is the same shape as the PPL aha but at the layer above. Two binaries running as the same user can be authorised differently because the Package SID is derived from the manifest publisher and the package cannot forge it. AppContainer is not a sandbox you opt into. It is a SID you have. Capability ACLs name that SID. The firewall keys on it. The MIC label composes with it. The broker checks it.

The limits are also visible. AppContainer is opt-in for Win32 desktop apps that have not been packaged. Forshaw's 2021 Project Zero analysis of the AppContainer firewall identified loopback-exemption and namespace-isolation holes that Microsoft classified as WontFix ^[42]. Per-app sandbox identity solves the Modern-app problem; it does not solve the legacy Win32 problem. For that, the operating system needs a policy plane that names code in publisher vocabulary instead of path vocabulary.

What does an enterprise admin do when the application refuses to be packaged at all?

The policy plane: AppLocker, App Control, and the publisher rule#

Path-based whitelisting failed for the same reason path-based ACLs failed. Anything writeable can be planted. AppLocker, shipped in Windows 7 in 2009, still stays in the box for compatibility, but Microsoft's own documentation recommends App Control for Business -- the rebranded Windows Defender Application Control -- for new deployments ^{[44] [2]}. The change is not cosmetic. It is the difference between filename-as-identity and Authenticode-publisher-as-identity.

The certificate-and-publisher rule levels run from strictest to broadest as Hash > FileName > FilePath > FilePublisher > SignedVersion > LeafCertificate > Publisher > PcaCertificate, with a parallel WHQL-only family for kernel drivers ordered WHQLFilePublisher > WHQLPublisher > WHQL ^[2]. Hash is the strictest (this exact byte string); PcaCertificate is the broadest signer-based level (anything signed under that intermediate CA). Microsoft documents RootCertificate as not supported, and FilePath -- available for user-mode binaries from Windows 10 1903 onward -- is path-based and so inherits the failure modes the publisher-rule model was designed to escape.

The LeafCertificate > Publisher adjacency is the subtle one. LeafCertificate pins to one specific signing certificate, so a renewal under a new leaf cert no longer matches. Publisher matches any certificate with the same PCA + leaf-CN combination, including future renewals. LeafCertificate is the stricter of the two ^[2].

The practical sweet spot is FilePublisher. It binds an allow rule to the tuple (certificate authority + leaf publisher CN + original filename + minimum version). That tuple survives recompiles: a benign update from the same publisher under the same name, signed by the same key, with a higher version still passes. It does not survive tampering. Change the original filename in the resource section, change the publisher, change the leaf certificate, and the rule no longer matches.

The Code Integrity engine evaluates an App Control policy on every PE load -- user mode and kernel mode alike. With HVCI active, the policy lives behind the Hyper-V security boundary; even an NT-kernel-level attacker with arbitrary memory write cannot edit it without breaking out of the virtualization layer ^[2]. Deny rules always win; an explicit deny can never be undone by any number of allows on the same binary.

App Control inherits the same structural ceiling Authenticode put in place. Allow Signer = Microsoft Windows admits the entire LOLBins inventory -- regsvr32, mshta, installutil, rundll32, every signed-by-Microsoft binary an attacker can call to execute arbitrary content. Allow Signer = ASUSTeK would have admitted ShadowHammer (operation 2018, disclosed 2019), every byte of which carried a valid ASUS production signature ^[10]. The publisher-rule model is the right primitive for managed endpoints, and the LOLBins / supply-chain-attack failure modes are the structural ceiling on what the primitive can prove.

PKI-rooted publisher policy still trusts the publisher's key custody. When the key is stolen or the binary is signed but malicious, what does the operating system fall back on?

Reputation as identity: Mark of the Web and SmartScreen#

A novel binary, signed by a freshly issued EV cert, has zero history. PKI says yes. Reputation says: I have never seen this before -- run it past the user.

MOTW is not an Authenticode replacement. It is a parallel, origin-based identity: the binary's provenance, encoded as data the file system carries with it, separate from any signature. Origin is the input to SmartScreen. SmartScreen submits a hash of the binary together with publisher metadata to a Microsoft-hosted reputation service; if the service has not seen the binary before, or has not seen enough downloads to be confident, the user gets the familiar "Windows protected your PC" prompt that requires an explicit More info / Run anyway click ^[4].

The pipeline is parallel to Authenticode and App Control, not a successor. PKI says "this signature chains to a real publisher." Reputation says "this hash has been observed N times in the last 30 days, with prevalence trending up; the publisher account is six years old; M of the downloads were from machines later flagged for malware." None of those signals are derivable from a signature.

The bypass surface is now well-known. Container formats (ISO, IMG, VHD, 7z) historically did not propagate MOTW to files extracted from them, because their on-disk representation does not preserve alternate data streams. Phishing campaigns adapted: send the attacker's .exe inside an .iso, the user mounts the .iso, double-clicks the .exe, and SmartScreen sees a binary with no MOTW and offers no warning.

Microsoft's response combined fixes -- VHD and ISO MOTW propagation in Windows 11 22H2, MOTW-aware extraction in OneDrive and the new Windows Archive APIs -- with two attack-surface-reduction rules that gate execution on prevalence and trust independently of MOTW ^[45]. The most useful is rule 01443614-cd74-433a-b99e-2ecdc07bfc25, "Block executable files from running unless they meet a prevalence, age, or trusted list criterion."

Office is the most consequential consumer of MOTW. A Word, Excel, or PowerPoint file carrying a ZoneId=3 Mark of the Web opens in Protected View: read-only, in a sandboxed renderer, with macros and active content disabled, until the user clicks "Enable Editing" on the message bar ^[46].

The 2022 wave of HTML-smuggling and ISO-borne malware that bypassed SmartScreen still tripped over Protected View at the document layer, and the post-2022 macro-blocked-by-default change extended the same MOTW-gated logic from container files to embedded VBA. Origin is now an input to two parallel pipelines: SmartScreen's reputation check on the executable, and Office's read-only-until-confirmed gate on the document.

A useful way to read the layered system at this point: Authenticode answered "who shipped it?" KMCS answered "is the kernel allowed to load it?" PPL answered "is this running process allowed to touch that one?" AppContainer answered "what application is this?" App Control answered "does the enterprise honour this publisher?" MOTW and SmartScreen answer the question PKI cannot: "have we seen this before, and from where?" When PKI identity is necessary but not sufficient, reputation closes the gap -- statistically, never absolutely.

PKI says yes; reputation says unknown. What does the operating system do when Microsoft itself says no to a signature it just minted?

The breakthrough: signed is not trusted (Driver Block List, 2022)#

December 8, 2021. Microsoft launches the Vulnerable and Malicious Driver Reporting Center ^[47]. The blog post enumerates the failure shape that drove it: drivers that "map arbitrary kernel, physical, or device memory to user mode," drivers that "provide access to storage that bypass Windows access control," drivers whose IOCTLs let a local admin become an arbitrary kernel writer. Every one of those drivers was signed. Every one of those signatures was valid. Every one of those binaries was loadable on a default Windows install.

By the Windows 11 22H2 update in September 2022, the Vulnerable Driver Block List was enabled by default ^[5]. The mechanism is a Microsoft-curated SiPolicy.p7b (the same WDAC binary policy format), distributed through Windows Update and Defender intelligence updates, enforced by the Code Integrity engine -- with HVCI when present -- at every driver load. The published rules deny drivers by publisher, original filename, and hash. Critically, the publisher's signature is still valid. The Block List is an explicit Microsoft veto layered on top of a working PKI verdict.

"The blocklist included in this article ... usually contains a more complete set of known vulnerable drivers than the version in the OS and delivered by Windows Update." -- Microsoft Learn, Microsoft recommended driver block rules ^[5]

That sentence, in Microsoft's own documentation, is the breakthrough. Microsoft is openly admitting that the version of the list shipped with the operating system trails the curated reference list. Curation is now a continuous, asynchronous activity, distinct from signing. The list ships on a quarterly cadence. New BYOVD drivers ship faster than that. The LOLDrivers community catalogue tracks hundreds of vulnerable drivers, many of which are not (yet) on Microsoft's list ^[48].

The Block List has a write-time companion. ASR rule 56a863a9-875e-4185-98a7-b882c64b5ce5, "Block abuse of exploited vulnerable signed drivers," prevents writing a known-vulnerable driver to disk in the first place ^[45]. The defence is layered: the Block List denies load; the ASR rule denies install; together they form a curtain across the BYOVD attack class. Together they do not close the BYOVD class -- the catalogue is a list, the threat is a set, and the gap is structural.

A signature attests who. A reputation score attests unfamiliar versus seen-good. A block list attests Microsoft has revoked trust at runtime, even though the signature still verifies. These are three distinct identity layers, and 2022 is the year all three were finally co-deployed by default on the same operating system.

The Driver Block List is the operational expression of a 25-year admission. After 1996's "the new Microsoft Authenticode technology uniquely identifies the publisher," after Vista's "we will refuse unsigned kernel drivers," after Windows 8.1's "signer level mediates inter-process access," after Windows 10's "App Control names policy in publisher vocabulary," Microsoft's December 2021 blog post said something different. It said: a signature is a publisher claim; trust is a different claim; we, Microsoft, will curate the second claim continuously, even when we ourselves issued the first one. Identity has become curated, not just verified.

If even Microsoft can no longer trust a valid signature, where does trust ultimately have to live?

The 2026 stack and the hardware future#

The eight primitives from the previous sections do not run in isolation. They compose. A modern Windows boot -- on a Pluton-equipped 2026 laptop running Windows 11 24H2 with HVCI on, App Control in enforce mode, Smart App Control on, and Microsoft Defender as the active anti-malware -- evaluates code identity continuously, top to bottom, from firmware through user mode.

flowchart LR
A["UEFI Secure Boot
firmware-rooted PKI"] --> B["Pluton / TPM
measured boot, PCRs"]
B --> C["KMCS
chain-to-Microsoft"]
C --> D["Driver Block List
Microsoft curated veto"]
D --> E["ELAM
signer-level boot gate"]
E --> F["User-mode Authenticode
publisher attribution"]
F --> G["PPL signer-level
runtime ACL"]
G --> H["AppContainer + Package SID
per-app principal"]
H --> I["App Control for Business
publisher policy"]
I --> J["MOTW + SmartScreen
origin + reputation"]
J --> K["Pluton attestation
device-identity claim"]

The hardware root has shifted in five years. Pluton, announced on November 17, 2020 by Microsoft together with AMD, Intel, and Qualcomm, is a security processor integrated into the CPU die rather than a discrete TPM chip on the motherboard bus ^[49]. AMD Ryzen 6000-series and later (including Ryzen AI), Intel Core Ultra Series 3 and 200V, and Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series ship Pluton as the on-die TPM. Pluton's firmware is updated through Windows Update -- not through OEM-controlled SPI flash patches -- and Microsoft has been rewriting the firmware in Rust ^[6].

The architectural significance is twofold. The trust root is no longer a chip with its bus exposed to a trace-and-sniff attacker. The firmware update path is now a Microsoft-controlled channel rather than thirty different OEM-controlled channels. The same hardware root is what BitLocker depends on when it seals the Volume Master Key to a measured boot chain via TPM PCRs ^[50]. On Pluton, those PCR measurements live in-die rather than on a bus-exposed chip, and the sibling article BitLocker on Windows traces what that buys and what it does not.

Then came July 19, 2024.

CrowdStrike's Falcon kernel driver loaded a malformed Channel File 291 update that triggered an out-of-bounds memory read inside csagent.sys and raised an invalid page fault ^[20], bug-checking roughly 8.5 million Windows endpoints simultaneously ^[19]. The driver was correctly Microsoft-signed through the Hardware Developer Center attestation pipeline. Every code-identity layer in the stack -- KMCS, the cross-cert, the EV cert, the attestation key, even the Block List -- said yes. The thing that went wrong was not identity. It was that an identity-blessed driver, running in kernel mode, can fail in ways that take entire continents offline.

Microsoft's reaction was structural. On September 12, 2024, David Weston published the recap of the September 10 WESES summit Microsoft had hosted with its endpoint-security partners, committing to provide "additional security capabilities outside of kernel mode" so that EDR vendors could run their detection logic in user mode ^[21].

On June 26, 2025, the Windows Resiliency Initiative announced a private preview of the new endpoint security platform, scheduled for July 2025 delivery to selected MVI partners: Bitdefender, CrowdStrike, ESET, and SentinelOne ^[22]. CrowdStrike's representative was Alex Ionescu, now its Chief Technology Innovation Officer -- the same Alex Ionescu whose 2013 Breakpoint talk publicly mapped PPL signer levels. The arc had closed in twelve years.

MVI 3.0 -- the Microsoft Virus Initiative, version three -- adds Safe Deployment Practices as a contractual condition: staged rollouts, deployment rings, monitoring. The same playbook Microsoft itself follows for Windows updates after the 2024 outage ^[20].

The conceptual move is the same one PPL made in 2013, projected one layer higher. Then: identity becomes a runtime ACL between processes. Now: identity-bound placement (kernel mode versus user mode) becomes a trust dimension co-equal with identity-bound signing. The question is no longer "is this driver signed and on the allow list?" The question is "should code with this identity be running in this context at all?"

If even attested, signed, blessed kernel code can fail catastrophically, what could code identity in principle ever prove -- and what is provably out of reach?

Theoretical bounds and open problems#

Two papers from the 1980s bound everything that followed.

Fred Cohen's 1984 paper at IFIP-Sec, republished in Computers & Security in 1987, proved that perfect virus detection is undecidable: there is no algorithm that, given an arbitrary program, can decide whether it is a virus ^[54]. Reputation systems are necessarily heuristic. The "first 1,000 downloads" gap -- the window where SmartScreen has not yet seen enough of a new binary to be confident -- is structural, not a tuning problem. You cannot close it by waiting harder.

Ken Thompson's 1984 ACM Turing Award lecture, "Reflections on Trusting Trust," made a different point about a different layer ^[55]. Thompson exhibited a compiler that, when used to build itself, inserted a backdoor into a target program; when used to build the compiler, propagated the backdoor invisibly to the next-generation binary. Signing what the compiler emitted never proved the compiler was unmodified. SLSA Level 3+ provenance, reproducible builds, hermetic build environments ^[56] push the bound back one level. They do not eliminate it.

A third bound is Authenticode-specific. Asynchronous revocation, the property that lets pre-revocation timestamped signatures continue to verify forever, is the reason Stuxnet's drivers loaded after Realtek's certificate was revoked, and the reason every other stolen-key compromise has a window of cryptographic legitimacy ^[8]. Synchronous global revocation would invalidate large catalogs of legitimate, archived, signed software whose signing certs have since expired. There is no fix inside the design.

Pulled together, these bounds explain the persistent gap. Stolen-but-not-yet-revoked publisher keys are the same failure mode replayed three times in sixteen years: Stuxnet (2010, Realtek and JMicron), ASUS ShadowHammer (operation 2018, disclosed 2019, ASUSTeK production key), Bitwarden CLI (2026, npm publishing credential). The Pluton firmware-update pipeline is the most credible architectural response yet -- a Microsoft-controlled key-rotation channel that does not depend on OEM-side custody -- but it does not eliminate the class. It compresses the response window.

The other open problem is identity for non-PE artifacts. The Authenticode hash and the WDAC publisher rule were designed for Portable Executable files; everything else gets uneven coverage. PowerShell .ps1 scripts can be signed and gated through Constrained Language Mode, which the runtime enters automatically when an AppLocker or App Control policy is in force ^[57]. .NET assemblies have strong-name signatures, separate from Authenticode and explicitly not a security boundary; Microsoft's own documentation warns "do not rely on strong names for security" ^[58].

JIT-compiled code -- the most common shape of "code" in 2026 -- is signed only insofar as the JIT host is signed. The JIT itself produces unsigned bytes. Container images, WSL guests, AI model files, and (now) agent prompts all live outside the Authenticode universe entirely. Each is its own substrate, with its own emerging signing scheme, and the unification has not happened.

$\text{trust}_{2026}(\text{binary}) = \text{publisher}(\text{binary}) \land \text{provenance}(\text{build}) \land \text{placement}(\text{runtime}) \land \text{reputation}(\text{telemetry}) \land \neg \text{revoked}(\text{Microsoft})$

That conjunction is the 2026 verdict. None of its terms are sufficient on their own. Each was forced into existence by a failure of the term before. The arc from "who launched this thread?" in 1993 to that conjunction in 2026 is what thirty-three years of forced moves produced.

What does the layered system look like in practice on a 2026 endpoint -- and what should an admin actually do?

Practical guide#

Six concrete recommendations for a 2026 Windows fleet, each tied to a primary Microsoft Learn or MSRC source.

function loadDecision({ signed, signerLevel, motwed, onBlockList, allowedByAppControl, smartScreenVerdict }) {
  if (onBlockList) return 'BLOCK -- Microsoft veto, signature ignored';
  if (signed === false && allowedByAppControl === false) return 'BLOCK -- unsigned, App Control denies';
  if (signerLevel === 'WinTcb' || signerLevel === 'WinSystem') return 'LOAD -- protected process';
  if (allowedByAppControl === false) return 'BLOCK -- App Control deny';
  if (motwed && smartScreenVerdict === 'unknown') return 'WARN -- SmartScreen, user gate';
  if (motwed && smartScreenVerdict === 'malicious') return 'BLOCK -- SmartScreen';
  return 'LOAD';
}
console.log(loadDecision({
  signed: true, signerLevel: 'Authenticode',
  motwed: true, onBlockList: false,
  allowedByAppControl: true, smartScreenVerdict: 'good',
}));

Where this is going#

Pluton-rooted device attestation, MVI 3.0's user-mode security platform, SLSA build provenance, and the post-CrowdStrike push to make placement a first-class identity attribute are all in motion in 2026 ^{[22] [56]}. The follow-on articles -- Driver Block List in production, App Control with HVCI on real fleets, Secure Boot internals, the Pluton firmware-update channel -- are the operational complement to the conceptual story this article has told.

The arc that began with Windows NT 3.1 having no answer to "who is this code?" now has eight overlapping answers, each insufficient on its own. Identity in 2026 is a multi-layered claim about a binary's publisher, its build provenance, its runtime placement, and its reputation, evaluated continuously while the code is running. The arc from 1993's "who launched this thread?" to 2026's "is this signed binary, in this placement, with this build provenance, on Microsoft's curated honour list, today, on this hardware-attested device?" is the answer thirty-three years of forced moves produced -- and the question the next thirty-three years will keep asking, because none of the bounds Cohen and Thompson proved have moved.