Parag Mali - tag: windows-hello

"The Vault is Solid. The Delivery Truck is Not." -- Microsoft Recall's Two-Year Re-Architecture from Plaintext SQLite to VBS Enclaves

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

In May 2024 Microsoft shipped Recall as a plaintext SQLite database guarded only by a SYSTEM-only filesystem ACL. Three independent researchers -- Kevin Beaumont, James Forshaw, and Alexander Hagenah -- broke it in four weeks. The September 27, 2024 re-architecture moved every sensitive operation into a VBS Enclave, sealed the master key with TPM 2.0, gated each access on a fresh Windows Hello biometric, and filtered credentials with Microsoft Purview Exact Data Match before persistence. It is the cleanest available case study of Pluton, VBS, the Secure Kernel, Hello ESS, and Purview composing into one feature. One seam remains: the non-enclave UI host that Hagenah's April 2026 TotalRecall Reloaded exploits, restating the original threat-model limit at a different layer.

1. The Script That Did Not Ship

On June 5, 2024 -- thirteen days before Microsoft Recall was scheduled to ship on Copilot+ PCs -- a Swiss security researcher named Alexander Hagenah pointed a fifty-line Python tool at the directory C:\Users\<user>\AppData\Local\CoreAIPlatform.00\UKP\ and pulled every screenshot Windows had taken of his desktop for the previous day in two seconds [@rec-19] [@rec-20]. The database was a plaintext SQLite file. The screenshots were plaintext PNGs. Microsoft Defender for Endpoint, monitoring an off-the-shelf information-stealer running in the same user context, took roughly ten minutes to react -- by which time the Recall data was gone [@rec-19] [@rec-15].

Hagenah called the tool TotalRecall and committed it to GitHub the same day [@rec-13]. His own description of what it did, as quoted by Malwarebytes Labs: "The database is unencrypted. It's all plain text. Pulling one day of snapshots took two seconds at most" [@rec-20]. His description of why he released it, as quoted by Help Net Security: "They should know it can be dangerous" [@rec-19].

This is the script that did not ship. Why it did not ship is the entire rest of this article.

Note: The code in the snippet below is the logic of a TotalRecall-style extractor against the May 20, 2024 Recall preview. It is a JavaScript transcription of a PowerShell or Python operation that would have worked against an unencrypted SQLite file in a known directory. The June 7, 2024 delay-and-recommit announcement [@rec-02] withdrew that design before broad release; the September 27, 2024 re-architecture [@rec-03] replaced it. The block exists to teach the historical failure, not to provide a runnable attack against the shipping product.

{` // Simulated extraction logic. Models the May 2024 Recall preview behaviour: // plaintext SQLite at a known user-profile path, plaintext PNGs alongside it. // The September 2024 re-architecture replaced both the storage format // and the trust model. This is a teaching example only.

const recallDir = String.raw`C:\Users\\AppData\Local\CoreAIPlatform.00\UKP`; const databaseFile = `${recallDir}\\ukg.db`; const imageStore = `${recallDir}\\ImageStore`;

// Step 1: Copy the SQLite file and the PNG cache out of the profile. // In the original preview, a same-user process could read both without // elevation, because the only protection was a SYSTEM-context filesystem ACL // that Forshaw demonstrated was bypassable from the user's own context. function exfiltrate() { copyRecurse(recallDir, '/tmp/recall_dump'); // Step 2: open the SQLite file with any client and select the OCR'd text. const ocr = openSqlite(databaseFile); return ocr.query('SELECT c1, c2 FROM WindowCaptureTextIndex_content'); }

// Step 3: every PNG in ImageStore is a snapshot of the desktop, named by // the integer key the SQLite row uses to join. No decryption needed in // the May 2024 preview. console.log('Recall data size:', exfiltrate().length, 'rows'); console.log('Time elapsed (Hagenah measurement): ~2 seconds'); console.log('Defender remediation latency (Beaumont measurement): ~10 minutes'); `}

The audit cast that turned the May 20 announcement into the June 7 retreat had three named protagonists. Kevin Beaumont, writing on his DoublePulsar blog on May 30, framed the threat model: Recall was a high-value secret store on a live, logged-on system, and the dominant live-system adversary was user-context malware, not offline disk theft [@rec-15] [@rec-19] [@rec-16]. James Forshaw, an active Google Project Zero researcher, published Working your way Around an ACL on June 3, demonstrating that the SYSTEM-only filesystem ACL Microsoft had relied on as a same-user isolation boundary was not in fact a boundary [@rec-14]. Hagenah's TotalRecall, posted June 5, turned Beaumont's framing and Forshaw's filesystem-ACL bypass into a runnable artifact [@rec-13] [@rec-19].

Each was load-bearing. Without any one of them, Microsoft's June 7 delay-and-recommit blog [@rec-02] could not have landed where it did, when it did.

What was Microsoft trying to do, that this script could undo?

2. The Four-Week Public Security Audit

Recall was supposed to be the marquee Copilot+ PC feature. Satya Nadella and Yusuf Mehdi previewed it at the Microsoft campus event on May 20, 2024, as one of three launch-exclusive AI experiences alongside Live Captions and Cocreator [@rec-01]. The hardware story was unusual: every Copilot+ PC would ship with Microsoft Pluton enabled by default, on Snapdragon X Elite or X Plus silicon, starting at $999, with broad GA scheduled for June 18 [@rec-01]. Recall would not appear on Intel or AMD Copilot+ PCs at launch, only on the Snapdragon silicon that defined the category.

Twenty-eight days later, the June 18 GA target was gone. Here is what happened in those four weeks.

An information-stealer is a class of malware whose purpose is to enumerate and exfiltrate browser-saved credentials, session cookies, password manager databases, cryptocurrency wallets, and other user-accessible secret stores from a logged-on Windows session. Modern variants (RedLine, Vidar, LummaC2) ship as commodity components in malware-as-a-service marketplaces. Beaumont's structural point about Recall was that adding a new high-value local store to the InfoStealer target list trivially extends an existing economic market; no novel attack capability is required.

May 30, 2024 -- Beaumont names the threat model

Kevin Beaumont's post on DoublePulsar opened with a sentence Microsoft never fully recovered from: "Recall enables threat actors to automate scraping everything you've ever looked at within seconds" [@rec-15] [@rec-19]. His structural point was that BitLocker addresses the wrong half of the threat model for a feature like Recall. BitLocker protects data at rest against an offline adversary who picks up a powered-off laptop; it does nothing against a logged-on user whose machine is running an information-stealer in the same session. Recall, by storing months of OCR'd screenshots in a user-readable directory, was not a target adjacent to the InfoStealer marketplace -- it was the new high-value target inside it.

Beaumont also published a measurement: in his test against Defender for Endpoint, the InfoStealer was detected, but automated remediation took roughly ten minutes to fire. By then his Recall extraction script had already finished [@rec-19] [@rec-15]. The asymmetry mattered. Defender's behavioural rules were calibrated against years of stealing browser cookies, not against the sudden appearance of a brand-new bulk-capture corpus that an attacker would race to exfiltrate first.

Recall enables threat actors to automate scraping everything you've ever looked at within seconds. -- Kevin Beaumont, DoublePulsar, May 30, 2024 [@rec-15] [@rec-19]

June 3, 2024 -- Forshaw publishes the ACL bypass

Three days later, James Forshaw of Google Project Zero published Working your way Around an ACL on Tyranid's Lair [@rec-14]. The post was not nominally about Recall; it was a methodological piece on how a same-user, non-elevated process could escalate to SYSTEM-context file access by impersonating SYSTEM-context services that handle user-supplied input. The worked example was C:\Program Files\WindowsApps, with a footnote linking to a Mastodon thread by Albacore noting that the Recall database directory had a structurally similar ACL.

Forshaw's epigrammatic conclusion -- "any privilege escalation (or non-security boundary cough) is sufficient to leak the information" -- captured the structural critique [@rec-14]. The asterisks around non-security boundary pointed at the MSRC servicing criteria [@rec-11]: Microsoft's own published policy says that UAC and admin-to-kernel transitions are not security boundaries. If those are not boundaries, and the SYSTEM-only filesystem ACL on the Recall directory was the only thing standing between a same-user process and the database, then there was no boundary at all.

June 5, 2024 -- Hagenah commits TotalRecall

Hagenah's tool turned the framing into an artifact [@rec-13] [@rec-19] [@rec-20]. The first README, preserved on the Wayback Machine, characterised Recall as "a 'privacy nightmare'" and noted matter-of-factly that the database was an unencrypted SQLite file readable in two seconds [@rec-13] [@rec-20]. Hagenah's stated motive, via Help Net Security: "They should know it can be dangerous" [@rec-19]. The "they" in that sentence was both the Microsoft engineering team that built the original design and the broader user base about to receive it.

flowchart LR A["May 20
Nadella + Mehdi
Copilot+ launch
Recall previewed"] --> B["May 30
Beaumont
threat-model framing"] B --> C["June 3
Forshaw
SYSTEM ACL bypass"] C --> D["June 5
Hagenah
TotalRecall PoC"] D --> E["June 7
Davuluri
delay + recommit"] E --> F["June 13
Recall removed
from June 18 GA"]

June 7, 2024 -- Davuluri retreats and recommits

Pavan Davuluri -- promoted to President of Windows + Devices on March 26, 2024 -- published the delay-and-recommit blog on June 7 [@rec-02].Wired's coverage of the same announcement referred to Davuluri as "Microsoft's corporate vice president for Windows and devices" [@rec-16]. That was his prior title; the President of Windows + Devices appointment had been announced ten weeks earlier. Most outlets had not yet updated their style sheets, which is the small reason you may have seen two different titles in the same week's coverage. Three commitments anchored the post: Recall would be opt-in at setup rather than on by default ("If you don't proactively choose to turn it on, it will be off by default"); Hello Enhanced Sign-in Security would gate access to stored snapshots; and decryption would happen "just in time," only when the user authenticated [@rec-02].

The Insider rollout was promised, then slipped on August 21 and again on October 31, before finally landing in November. These three properties did not yet have a mechanism. The mechanism would arrive on September 27. But the commitment came first, in plain English, on June 7 -- and it was the commitment that bought the engineering team the time to design the architecture that would honour it.

Three commitments without a mechanism. What was the mechanism going to be?

3. What the Original Recall Design Was Trying

Microsoft did not ship Recall in May 2024 because they thought encryption was unnecessary. They shipped it because they thought the protections they already had were sufficient. Four assumptions. Each one was load-bearing, and each one was wrong.

Before naming them, it is worth crediting what the original design got right, because that commitment survived the re-architecture intact. The data flow was on-device only. Snapshots, OCR'd text, and the local semantic index never traversed the Microsoft Diagnostic Data telemetry pipeline; nothing left the device by design [@rec-01]. That property is preserved in the Generation 3 architecture [@rec-03] and is reiterated in the IT administrator documentation [@rec-08]. The original engineering team did not get the privacy framing wrong as a category. They got the isolation framing wrong.

BitLocker is the Windows full-volume encryption feature. Its threat model is offline disk theft: an adversary who removes a powered-off laptop's storage and tries to read its contents on another machine encounters AES-XTS-encrypted blocks instead of plaintext files. BitLocker is transparent when the device is powered on and the user is logged in; it does not authenticate any individual file access against the running operating system. Beaumont's structural point in §2 was that BitLocker's threat model and Recall's threat model do not overlap: Recall's adversary is a process running in the live, logged-on session. The Data Protection API is the Windows user-mode interface for protecting per-user secrets with a key derived from the user's logon credentials. Browsers historically used DPAPI to protect saved-credential databases; the well-known weakness is that any process running as the user can call `CryptUnprotectData` against the same files and get plaintext back. DPAPI did *not* appear in the original Recall design -- the pre-audit framing that imagined Recall as "DPAPI used incorrectly" was a misreading. The actual original Recall stored a plaintext SQLite file under filesystem ACLs alone, as Hagenah's tool demonstrated [@rec-20] [@rec-19]. The September 2024 re-architecture also does not use DPAPI; it uses TPM-sealed master keys released to a VBS Enclave on Hello ESS authentication [@rec-03].

Assumption 1: The SYSTEM-only filesystem ACL is a same-user isolation boundary

The directory C:\Users\<user>\AppData\Local\CoreAIPlatform.00\UKP\ was protected by an ACL that permitted SYSTEM to read and write, and denied the logged-on user direct access. The original design treated this as an isolation boundary between user-context code and the Recall database. Forshaw's June 3 post refuted this directly [@rec-14]: a same-user process can obtain SYSTEM-context file access by impersonating a SYSTEM-context service that handles user-supplied input. The technique is generic, well documented in the Tyranid's Lair archive, and predates Recall by years. Once Forshaw published the worked example, the original ACL stopped looking like a boundary and started looking like a speed bump.

Assumption 2: BitLocker-at-rest is sufficient because the live system is trusted for the logged-on user

The original team assumed that an attacker against Recall data would necessarily be either (a) an offline adversary with physical possession of the powered-off disk -- defeated by BitLocker -- or (b) an attacker with administrator access -- out of scope per the MSRC servicing criteria [@rec-11]. Beaumont demolished this by pointing at a third class: an in-session, user-context InfoStealer that is already common, already on the InfoStealer-as-a-service price list, and trivially extensible to dump a new SQLite file [@rec-15] [@rec-19]. BitLocker's threat model and Recall's threat model did not overlap; assuming they did was the mistake.

Assumption 3: Defender's automated remediation will outrun InfoStealer exfiltration

Even granting the existence of in-session adversaries, the original assumption was that Defender for Endpoint's behavioural detection would catch them before they finished. Beaumont's measurement said otherwise: the InfoStealer was detected, but automated remediation took roughly ten minutes to land, by which point the exfiltration of a Recall snapshot directory had finished in two seconds [@rec-19] [@rec-15]. The asymmetry was not a Defender bug; it was a category problem. Defender's response is calibrated for the historical InfoStealer corpus (browser cookies, credential databases); a new bulk corpus introduces a race the existing rules were not tuned for.

Assumption 4: Same-user, administrator-level access is not a security boundary anyway

This last assumption is technically correct, per the MSRC servicing criteria [@rec-11]. UAC, admin-to-kernel, and same-user post-authentication are documented non-boundaries. The argument goes: if a feature is "in the user's trust boundary" -- any code running as the user can access it -- then any attacker who is already running as the user has by definition already won. The feature has nothing further to defend.

The trouble is that the demonstrated Recall attacks did not require admin. Beaumont's testing and Forshaw's ACL impersonation both operated from standard-user context [@rec-15] [@rec-14]. "Same-user attacks are out of scope" is a different statement from "attacks that succeed without elevation are out of scope," and the original Recall design conflated the two.The Malwarebytes coverage of Hagenah's tool described the attack as requiring "administrator rights" [@rec-20]. This was an overstatement -- Beaumont and Forshaw both established that admin was not required. Subsequent coverage in Help Net Security used the stricter framing [@rec-19].

Key idea: Same-user code is in the user's trust boundary unless the architecture explicitly authenticates per-access. A SYSTEM-only filesystem ACL is not authentication; it is access control under an assumption (no impersonation) that the Windows DACL model does not enforce in the user's favour. BitLocker is not authentication either; it is data-at-rest encryption with a key already released by the time the user is logged on. The original Recall design relied on both of these to act like per-access authentication, and neither one was built to do that.

If "same-user code is in the user's trust boundary" was the bug, what does an architecture look like that authenticates per-access?

4. From the June 7 Commitment to the September 27 Architecture

The June 7 retreat named three properties: opt-in, Hello-gated, just-in-time decrypted. The architecture that enforces those properties did not exist on June 7. It existed by September 27, was previewable on November 22, and shipped across Snapdragon, Intel, and AMD between April 25 and May 13, 2025. Here is the path between the commitment and the architecture.

Generation 0: The substrate that already existed

Before Recall, the VBS Enclave primitive was already running in production -- but in a corner of the Windows-server stack that desktop engineers rarely visited. SQL Server 2019 introduced Always Encrypted with secure enclaves on November 4, 2019, almost five years before the Recall preview [@rec-10]. The feature lets a database hold client-encrypted columns and still answer equality and range queries inside an enclave that is part of the sqlservr.exe process but isolated from the rest of it. The Microsoft Learn page for VBS Enclaves cross-links Always Encrypted as a sibling consumer of the primitive [@rec-06].

This matters for two reasons. First, the September 27 architecture did not require Microsoft to invent VBS Enclaves -- the primitive shipped in 2019 and had been stable in production for half a decade by the time Recall reached for it. Second, the original input to this article incorrectly imagined Recall as "the first VBS-enclave product outside the credential set"; the correct claim is narrower. Recall is the first VBS-enclave deployment in the Windows desktop shell to receive sustained adversarial review. SQL Server 2019 is the substrate precedent; Recall is the desktop-shell debut.

Microsoft Pluton is a security processor design that integrates root-of-trust functionality, including TPM 2.0 services, directly into the main system-on-chip rather than on a separate discrete chip on the motherboard. The integration matters because the LPC or SPI bus between a discrete TPM and the CPU is the attack surface used by bus-sniffing attacks; on a Pluton-equipped device that bus does not exist for the security-processor traffic. Microsoft publishes the chipset availability list: AMD Ryzen 6000, 7000, 8000, 9000 and Ryzen AI; Intel Core Ultra 200V, Series 3, Series 3 processors; Qualcomm Snapdragon 8cx Gen 3 and Snapdragon X Series [@rec-24]. Pluton firmware updates ship through Windows Update. A TPM is a tamper-resistant cryptographic processor that holds keys which can be released to the operating system only when a set of preconditions (the values of platform configuration registers, the presence of an authenticated user, the result of an attestation) is met. TPM 2.0 is the version family in current shipment. Recall uses the TPM for *sealing* -- binding the Recall master key to the boot state of the machine and to the identity of the user, so the key cannot be released to a different OS instance or a different user even with full disk access.

Generation 1: The May 20, 2024 design

Already covered in §3. Four assumptions, all wrong; one runnable counter-example (Hagenah's TotalRecall); zero mechanism to make the assumptions right.

Generation 2: The June 7 commitment

The Davuluri blog of June 7 [@rec-02] was not an architecture; it was a set of properties the next architecture would have to enforce. Opt-in is a UX commitment; Hello-gated is a credential commitment; just-in-time decryption is a key-management commitment. Each one rules out a class of approach -- opt-in rules out silent default-on; Hello-gated rules out a key that can be read without biometric attestation; just-in-time rules out a long-lived plaintext cache. None of them, taken alone, prescribes a specific design.

Generation 3: The September 27, 2024 architecture

This is the load-bearing announcement. Davuluri's blog [@rec-03] and David Weston's companion SecurityWeek interview [@rec-17] together describe four security and privacy design principles and five architectural components.

The four principles, drawn from Davuluri's blog [@rec-03]:

The user is always in control. Recall is opt-in at setup, with Hello enrolment required before any snapshot capture.
Sensitive data in Recall is always encrypted, and keys are protected. The blog specifies that encryption keys are bound to the TPM, tied to the user's Hello Enhanced Sign-in Security identity, and can only be used by operations inside a VBS Enclave.
Recall services that operate on snapshots and associated data are isolated. Snapshot processing, OCR, semantic embedding, and the sensitive-content filter all run inside the enclave; the on-disk database holds only ciphertext.
Users are present and intentional about the use of Recall. Hello ESS with anti-hammering and rate-limiting governs each authorisation; PIN fallback is permitted only after Hello has been set up.

The five components: Secure Settings, Semantic Index, Snapshot Store, Recall UI, and Snapshot Service [@rec-03]. Davuluri's architecture diagram labels four of them as inside the trust boundary and one of them -- Recall UI -- as explicitly outside it. The line is verbatim: "Recall components such as the Recall UI operate outside the VBS Enclaves and are untrusted in this architecture." That line is the seam §8 will return to.

It's now fully encrypted, and tied to the user's physical presence. -- David Weston, CVP Enterprise and OS Security, in conversation with Ryan Naraine [@rec-17]

The composition is not novel cryptography. The novelty is the layering: VBS Enclaves (Generation 0 substrate), TPM-2.0 key sealing (a primitive Windows has shipped since 2012), Hello ESS (an attestation primitive cataloged on Microsoft Learn since the Windows 11 launch [@rec-25]), and Microsoft Purview Exact Data Match filtering (a content-classification primitive previously seen in the Microsoft Purview enterprise product) compose into a single user-facing feature. Each layer was already production-stable; the September 27 design wires them together.

First observable build and broad rollout

The first observable build of Generation 3 was Insider Dev Channel Build 26120.2415 on Snapdragon Copilot+ PCs, KB5046723, released November 22, 2024 [@rec-04] [@rec-18]. The first-run experience in that build asks the user to opt in to saving snapshots and to enrol Windows Hello [@rec-04]. Build 26120.2510 (December 6, 2024) extended Insider preview to AMD and Intel Copilot+ PCs. GA across all three silicon vendors landed in the April 25, 2025 Windows Experience Blog announcement [@rec-05], with broad rollout in the May 13, 2025 Patch Tuesday cycle [@rec-21]. The IT-admin manageability surface -- AllowRecallEnablement, DisableAIDataAnalysis, snapshot-retention policy, disk-allocation policy, per-app exclusion list -- is documented in Manage Recall on Microsoft Learn [@rec-08].

flowchart TD G0["Gen 0 (Nov 4, 2019)
SQL Server 2019
Always Encrypted with secure enclaves
(VBS Enclave substrate precedent)"] G1["Gen 1 (May 20, 2024)
Plaintext SQLite
SYSTEM-only filesystem ACL
(Did not ship)"] G2["Gen 2 (June 7, 2024)
Opt-in commitment
Hello-gated commitment
Just-in-time decryption
(Commitment, no architecture)"] G3["Gen 3 (Sept 27, 2024)
VBS Enclave + TPM-sealed
Hello ESS + Purview EDM
(Architecture)"] G4["Gen 4 (Apr 25 - May 13, 2025)
GA on Snapdragon, Intel, AMD
Intune surface matured"] G5["Gen 5 (April 2026)
TotalRecall Reloaded
AIXHost.exe DLL injection
(UI seam disclosed)"] G0 --> G1 G1 -- "Plaintext SQLite + filesystem ACL broken in 4 weeks" --> G2 G2 -- "Commitment needs a mechanism" --> G3 G3 -- "Cryptographic chain holds; shipped to GA" --> G4 G4 -- "UI host outside enclave by design" --> G5

The structural takeaway is this. Composing three primitives Microsoft had already shipped -- VBS Enclaves, TPM 2.0 sealing, and Hello ESS -- plus a fourth (Purview EDM filtering) yielded the September 27 architecture that enforces the three June 7 properties. None of the four primitives is new in 2024; the application of all four to a personal-context store running in the desktop shell is.

If "VBS Enclave + TPM-sealed key + Hello ESS" is the answer, what does the inside of the enclave actually do?

5. Inside the Enclave: VBS as the Load-Bearing Primitive

Microsoft's own September 27 architecture diagram draws five boxes. One of them is labelled untrusted. Here is what the other four do, and why the untrusted one matters.

A Virtualization-based Security (VBS) Enclave is, in Microsoft's own words on the Learn page that defines the primitive, "a software-based trusted execution environment inside the address space of a host application" [@rec-06]. Concretely, it is a sub-region of a normal user-mode (VTL0) process that is promoted to VTL1 by the Secure Kernel. Code inside the enclave can see its own memory and the bytes the host explicitly passes in across the enclave boundary; the host process cannot see plaintext inside the enclave, and neither can the rest of the operating system, including the kernel and any administrator. The primitive requires VBS and HVCI to be enabled, and Windows 11 Build 26100.2314 or later [@rec-06]. The Windows hypervisor partition that hosts VBS divides each running guest into two virtual trust levels: VTL0 (normal user mode and kernel) and VTL1 (Isolated User Mode and the Secure Kernel). The Secure Kernel is a minimal, signed component that runs in VTL1; it is what enforces the isolation guarantee between VTL0 and VTL1. Code in VTL0 cannot read VTL1 memory; the hypervisor enforces this at the second-level page table. The VBS Enclave primitive uses VTL1 as the substrate for the enclave sub-region. Enhanced Sign-in Security, per the canonical Microsoft Learn definition, "provides an additional level of security to biometric data with the use of specialized hardware and software components. Virtualization Based Security (VBS) and Trusted Platform Module 2.0 are used to isolate and protect user's authentication data, and to secure the data communication channel" [@rec-25]. The face-matching algorithm runs in VBS; the sensor-to-algorithm path is an isolated, certificate-authenticated channel. ESS-capable IR cameras and presence sensors are a hardware prerequisite; absent ESS hardware, Recall degrades to a PIN/password fallback.

The five components

Snapshot Service is a Protected Process Light (PPL) that captures the screen at approximately 5-second intervals and feeds the raw frames into the enclave. PPL means the Snapshot Service is signed at a level the rest of user mode cannot inject into. Plaintext frames and per-snapshot keys do not live in the Snapshot Service's address space; they cross into the enclave immediately on capture.
VBS Enclave is the trust boundary. Inside it: OCR over the raw frame; semantic vector embedding for search; sensitive-content filtering via the Microsoft Purview Exact Data Match libraries; per-snapshot key derivation from a TPM-sealed master; AES-256-GCM authenticated encryption of the snapshot and the embedding. Plaintext OCR output never crosses the enclave boundary.
Snapshot Store is the on-disk database of AES-256-GCM-encrypted per-snapshot blobs and encrypted embeddings. No process -- not even the Snapshot Service that wrote the file, not the kernel, not an administrator -- can decrypt the blobs without going back through the enclave with a Hello-authenticated session grant [@rec-03].
Semantic Index is the query path over the encrypted embeddings. A user query traverses the enclave so that the plaintext embedding (and the plaintext OCR text it points at) never leaves the trust boundary.
Recall User Experience (UI) runs outside the enclave. Microsoft's architecture diagram labels it untrusted. The UI receives only data the enclave has authorised for the current session, after Hello ESS, with a timeout, with anti-hammering and rate-limiting on the authorisation window [@rec-03].

AES-256-GCM is the Galois/Counter Mode of operation for AES with a 256-bit key, specified by NIST SP 800-38D [@rec-26]. It is an authenticated encryption with associated data (AEAD) primitive: each ciphertext carries an authentication tag computed over the ciphertext and the associated data, and decryption fails if the tag does not verify. Recall uses AES-256-GCM per snapshot, with a per-snapshot key derived inside the enclave. The published architecture identifies AES-256-GCM as the primitive but does not document the key derivation function or the per-snapshot nonce scheme. Purview EDM is a content-classification primitive from the Microsoft Purview enterprise data-loss-prevention product family. It matches text against high-precision patterns: structured credentials, national-identifier formats (US Social Security Numbers, EU identifier formats), payment card numbers under Luhn checksum. In Recall, the EDM library runs inside the enclave on the OCR output, *before* the per-snapshot encryption step. Matches are excluded from the persistent record; the screenshot of a credit-card form has the card number stripped from the OCR text and (per Weston's framing in SecurityWeek) is treated as a sensitive class that does not enter the snapshot store [@rec-17]. flowchart TD SS["Snapshot Service
PPL, VTL0
captures every ~5s"] ENC["VBS Enclave (VTL1 sub-region)
OCR + embedding
Purview EDM filter
per-snapshot key derivation
AES-256-GCM encrypt"] STORE["Snapshot Store
on-disk
AES-256-GCM ciphertext only"] IDX["Semantic Index
encrypted embeddings"] UI["Recall UI
(VTL0, UNTRUSTED in architecture)"] HELLO["Hello ESS
per-access biometric"] TPM["TPM 2.0
sealed master key"] SS --> ENC TPM --> ENC HELLO --> ENC ENC --> STORE ENC --> IDX STORE --> ENC IDX --> ENC ENC -- "post-auth release" --> UI

The per-snapshot key chain

Davuluri's blog specifies the chain but does not publish either the key derivation function used to expand the TPM-sealed master into a per-snapshot key, or the per-snapshot nonce scheme fed into AES-256-GCM. The pseudocode below reconstructs the structure from the published primitives. Microsoft has not published the literal KDF or nonce scheme; this is the shape of the computation, not the verbatim source.

Reconstructed sketch of the enclave-side write path. Microsoft has published the primitives (TPM 2.0 sealing, Hello ESS gating, VBS Enclave isolation, AES-256-GCM per snapshot, Purview EDM filtering) but has NOT published the literal KDF or nonce scheme. This is a structural reconstruction for teaching purposes.

def enclave_write_snapshot(raw_frame, snapshot_id): # Step 1: in-enclave OCR over the raw screen capture. ocr_text = enclave_ocr(raw_frame)

# Step 2: Purview EDM filter strips known-sensitive patterns
# (credentials, national IDs, PAN) BEFORE persistence.
filtered_text = purview_edm_filter(ocr_text)

# Step 3: semantic embedding for the search index.
embedding = enclave_embed(filtered_text)

# Step 4: derive a per-snapshot key from the TPM-sealed master.
# The master was released into the enclave on Hello ESS authentication.
snapshot_key = kdf(master_key_in_enclave,
                   context=b"recall-snapshot",
                   salt=snapshot_id)

# Step 5: AES-256-GCM authenticated encryption with a fresh nonce.
nonce = derive_nonce(snapshot_id)
aad   = serialize_metadata(snapshot_id, timestamp=now())
ciphertext, tag = aes_256_gcm_encrypt(
    snapshot_key,
    nonce,
    plaintext=concat(raw_frame, filtered_text, embedding),
    aad=aad,
)

# Step 6: persistent write. Nothing plaintext crosses the enclave boundary.
snapshot_store.put(snapshot_id, ciphertext, tag, nonce, aad)

The Hello ESS layer plugs in at step 4: the TPM-sealed master is released into the enclave only on a fresh, ESS-attested authentication, and the release path uses the certificate-authenticated sensor-to-VBS channel described on the Hello ESS Learn page [@rec-25]. Failed authentication trips the standard TPM anti-hammer lockout. PIN fallback is permitted only after Hello has been set up.

sequenceDiagram participant User participant Sensor as Hello ESS sensor participant SK as Secure Kernel (VTL1) participant TPM as TPM 2.0 participant Encl as Recall VBS Enclave (VTL1) participant Store as Snapshot Store User->>Sensor: present face / fingerprint Sensor->>SK: ESS-authenticated biometric attestation SK->>TPM: request key release on attested context TPM->>SK: sealed master key (released to VTL1 only) SK->>Encl: hand master key into enclave Encl->>Encl: derive per-snapshot key, AES-256-GCM encrypt Encl->>Store: ciphertext + AEAD tag + nonce Microsoft's documentation distinguishes two patterns that share the same VTL1 substrate. A *VBS Enclave* is a sub-region of a VTL0 host process that is promoted to VTL1 by the Secure Kernel [@rec-06]. An *[IUM Trustlet](/blog/vbs-trustlets-what-actually-runs-in-the-secure-kernel/)* (like LsaIso, the Credential Guard worker) is a full Isolated User Mode process that runs wholly in VTL1. Both rely on the same hypervisor partition and the same Secure Kernel. The terminology matters because the September 27 architecture blog [@rec-03] and the developer-facing Tech Community explainer [@rec-07] both use *VBS Enclave* throughout for Recall, distinct from LsaIso. The pre-audit framing that called Recall "a new IUM trustlet" was a category mistake; the architecture is a sub-region-of-host-process enclave, not a full trustlet process. Both patterns are governed by the MSRC security boundary policy [@rec-11], which lists VBS as a boundary against the kernel and against administrative users. VBS Enclaves are not new -- SQL Server 2019 *Always Encrypted with secure enclaves* established the substrate roughly five years before Recall (see §4 Generation 0). What Recall contributes is not the substrate but the deployment context: a personal-context store on the desktop shell, with a UX that puts the trust boundary in front of consumers and an adversarial review history (Hagenah, Beaumont, Forshaw) that no SQL Server feature has attracted. flowchart LR subgraph VBS_Encl["VBS Enclave pattern (Recall)"] H["Host process
(VTL0, e.g. Snapshot Service)"] --- E["Enclave sub-region
(VTL1)"] end subgraph IUM["IUM Trustlet pattern (LsaIso / Credential Guard)"] L["Trustlet process
(entirely in VTL1)"] end SK["Secure Kernel (VTL1)"] HV["Hypervisor partition"] VBS_Encl --> SK IUM --> SK SK --> HV

Davuluri's September 27 blog adds two transparency commitments that bear on how much of this architecture an outside reviewer can verify. First, Microsoft's internal MORSE team (Microsoft Offensive Research and Security Engineering) ran a penetration test of the Generation 3 design before disclosure [@rec-03]. Second, an unnamed third-party security vendor performed an independent review. Neither report is public. §9 will return to this transparency gap.

Key idea: The cryptographic boundary in Generation 3 is above the filesystem. A process with full filesystem access reads only AES-256-GCM ciphertext. A kernel-mode caller reads only ciphertext. An administrator reads only ciphertext. The boundary is at the enclave, not at the file. This is qualitatively different from "add encryption to the SQLite file" and is the reason the Generation 3 design closes the four Generation 1 failures rather than merely patching them.

If the cryptographic chain holds against the kernel and against administrators, where can it ship?

6. Where Recall Ships in May 2026

The post-September-2024 Recall is no longer a preview. Here is the silicon it runs on, the policies an IT admin sees, and the exclusion surfaces a user can configure.

Shipping silicon

The chipset matrix is documented on the Microsoft Pluton Learn page [@rec-24] and corroborated by the GA announcement [@rec-05]. The pattern is consistent: every Copilot+ PC carries TPM 2.0 services, but the attachment of those services varies by silicon vendor.

Silicon family	Security processor	Typical TPM attachment
Qualcomm Snapdragon X Elite / X Plus	Pluton (integrated)	TPM 2.0 services delivered by Pluton on-die
Intel Core Ultra 200V (Lunar Lake), Series 3, Series 3	Pluton (integrated, where present) and discrete TPM 2.0	Discrete TPM 2.0 plus Pluton-equivalent integration
AMD Ryzen AI 300 series and Ryzen 6000-9000	AMD Pluton Security Processor	Pluton-equipped SKUs; some retain discrete TPM 2.0

PPL is the Windows process-protection level that gates which processes are permitted to inject code into, debug, or read the memory of a given target process. A PPL process is signed at a specific signer level; only processes signed at an equal-or-higher level can interact with its address space using the privileged debug or memory-access APIs. The Recall *Snapshot Service* is a PPL at a signer level the rest of user mode cannot reach. The *Recall UI* (covered in §8) is not a PPL, and that distinction is the architectural seam Hagenah's April 2026 disclosure exploits.

The Pluton-versus-discrete-TPM trade-off is small but real. A Pluton-integrated TPM has no off-die bus carrying the security-processor traffic that an attacker can sniff with a logic analyser; the integration is in-package. A discrete TPM has a documented bus-sniffing attack surface that the Secured-core PC requirement set (HVCI, System Guard Secure Launch, Kernel DMA Protection) is designed to mitigate but does not eliminate.The bus-sniffing attack is not specific to Recall; it is a general TPM-attachment concern that applies to BitLocker, Credential Guard, and any other TPM-sealed key. Recall inherits both the threat and the mitigation set from the platform.

For most Copilot+ PCs in 2026, the practical difference is small. The architectural correctness of the September 27 design does not depend on the choice.

The management surface

The IT-admin management surface is documented in Manage Recall on Microsoft Learn [@rec-08]. The defaults differ between consumer and managed devices: on a managed device, "Recall is disabled and removed" by default, and an explicit Intune policy is required to allow enrolment. The relevant Intune Settings Catalog entries are:

AllowRecallEnablement -- the explicit consent gate for any organisation that wants Recall to be available on its managed fleet. Threat model addressed: unintended consumer-default opt-in on managed devices; without this policy explicitly set to "allowed," the Manage Recall page's managed-device default ("disabled and removed") stands.
DisableAIDataAnalysis -- the Group Policy gating surface for Copilot+ AI features. Threat model addressed: organisations that want a single switch to keep all on-device AI processing (Recall, Click to Do, future shell features) off the fleet, rather than enumerating each feature individually.
Snapshot-retention and storage-allocation policies -- data-minimisation controls for the per-device snapshot corpus. Threat model addressed: bounding the maximum size of any single exfiltration window in the event a future UI-host weakness is found; fewer snapshots and shorter retention reduce the corpus exposed to a successful post-authentication extraction.
Per-app exclusion list -- per-window snapshot exclusion for applications the operator designates. Threat model addressed: high-value secrets surfaced by the password manager, the corporate VPN client, and similar sensitive UIs that should never enter the snapshot corpus regardless of how strong the storage encryption is.

Microsoft Purview Endpoint DLP adds a parallel policy surface for window-level snapshot exclusion of any application handling regulated data [@rec-08]. Group Policy parity exists for the same surfaces, for organisations that have not yet adopted Intune.Intune management of Recall was not a 2026 debut. The Manage Recall documentation was published alongside the Insider preview in late 2024 and matured through the April-May 2025 GA cycle. The 2026 work is stabilisation, not introduction.

User-facing surfaces

End users encounter Recall through a small number of touchpoints documented in the Insider preview blog [@rec-04] and the developer integration page [@rec-09]. The keyboard shortcut Win+J launches the Recall UI. The Out-Of-Box Experience asks the user to opt in to saving snapshots and to enrol Windows Hello before any capture begins. The per-app exclusion list is reachable from Settings. Storage allocation defaults are configurable, with a documented audit path through the Manage Recall policy reference.

Note: On a managed-device pilot, deploy the AllowRecallEnablement Intune policy before the OOBE flow begins on the device. If the policy lands after the user has completed OOBE, you leave a small window in which the user could opt in under the consumer default. Pre-deploying the policy makes the managed-device default (Recall disabled) authoritative from first boot.

Recall is the on-device-only Copilot+ feature, on a defined silicon set, with a defined management surface. Who else ships in this space, and how do their architectures compare?

7. Competing Approaches Under the Same UX Label

Three other architectures ship a search-your-past-screen or near-adjacent UX in the 2024-2026 window. Each made a different choice about where the trust boundary lives.

Rewind.ai (macOS, 2022 to present)

Rewind.ai is the closest architectural predecessor to the May 2024 Recall design. It captures the user's macOS screen, OCRs the captures, and stores them locally in an SQLCipher-encrypted SQLite database, with the database key held in the macOS Keychain [@rec-28] [@rec-29] [@rec-30]. There is no per-query biometric prompt; there is no Secure Enclave gating on each access. Architecturally, Rewind relies on macOS sandboxing and FileVault for the surrounding protection.The vendor security page at rewind.ai/security resolves to a domain-parking template as of May 2026, so this architectural description is INFERRED_DETAIL drawn from the Nudge Security third-party profile [@rec-28] and the SQLCipher canonical pages [@rec-29] [@rec-30] rather than a vendor-published spec.

SQLCipher uses AES-256-CBC per page with a per-page random IV and HMAC-SHA512, deriving the key from a passphrase via PBKDF2-HMAC-SHA512 with 256,000 default iterations [@rec-30]. That is reasonable file-encryption; it is not per-access authentication. A same-user process that can read the SQLCipher key out of Keychain has plaintext access to every screen capture the user has ever taken -- structurally the same condition that broke the May 2024 Recall design, on a different operating system with a different sandbox model.

Apple Intelligence Personal Context + Private Cloud Compute (2024 to present)

Apple's Personal Context personalisation is not a search-your-past-screen product. It is structured-app-data personalisation: messages, mail, calendar, photo metadata, and similar surfaces. The on-device tier runs in the Apple Silicon Secure Enclave. The off-device tier -- Private Cloud Compute -- carries a binary-transparency-style commitment that the cloud nodes process personal data only inside a hardened OS image whose source code Apple publishes for outside review [@rec-27]. The PCC architecture is included in this comparison not because it is a Recall analogue (it isn't), but because it shows what Apple has chosen to ship at the adjacent problem class: structured data personalisation, not screen-history.

Consumer cloud-capture devices (Limitless, Plaud, and similar)

Consumer cloud-capture devices invert the trust model. The capture happens on a dedicated wearable or microphone; the processing happens on a vendor's cloud tier; the storage lives in the vendor's account model with end-to-end encrypted upload and vendor-side AES-256-GCM at rest. This is architecturally the opposite of Recall: on-device-only is replaced by on-vendor-cloud, and the trust boundary is at the vendor's perimeter rather than at the user's silicon. The internals of any specific vendor's stack are not in the scope-mandated source set; the entry exists to establish the existence of the cloud-tier alternative, not to certify any specific vendor's claim.

The eight-dimension matrix

Architecture	On-device only	Hardware-rooted master	TEE-isolated compute	Per-access biometric	Pre-persistence filter	TEE-isolated UI plane	KDF/nonce documented	CVE record
Recall Gen 1 (May 2024, did not ship)	Yes	No	No	No	No	No	N/A	Pre-release
Recall Gen 3+4 (Sept 2024 - May 2026)	Yes	Yes (TPM 2.0, Pluton where available)	Yes (VBS Enclave)	Yes (Hello ESS)	Yes (Purview EDM)	No (UI explicitly untrusted)	Partial	No CVE through May 2026
Rewind.ai (macOS)	Yes	Keychain-rooted	Limited	No	No	No	N/A	N/A
Apple Personal Context + PCC	Hybrid	Yes (Secure Enclave)	Yes (Secure Enclave / PCC)	Yes	Apple-managed	Apple-managed	Partial	N/A
Consumer cloud-capture	No	Vendor cloud	Vendor cloud	Vendor flow	Vendor flow	Vendor flow	Not public	N/A
SQL Server 2019 AE w/ enclaves	Server-side	Yes (TPM-attested)	Yes (VBS Enclave)	N/A	N/A	N/A	Yes (documented)	Patched as needed

Recall Generation 3+4 is the only design in the surveyed set that checks five of the six "ideal" properties: on-device-only data flow, hardware-rooted master key, TEE-isolated sensitive compute, per-access biometric authentication, and pre-persistence sensitive-content filtering. The sixth ideal property -- TEE-isolated plaintext delivery to the UI plane -- is the architectural seam §8 explores.

flowchart LR A["On-device only
YES"] B["Hardware-rooted master
YES"] C["TEE-isolated compute
YES"] D["Per-access biometric
YES"] E["Pre-persistence filter
YES"] F["TEE-isolated UI plane
NO -- UI is explicitly untrusted"] A --> G((Recall Gen 3+4)) B --> G C --> G D --> G E --> G F -. "the seam" .-> G

Five of six properties. What does the missing sixth cost?

8. What the VBS Enclave Model Cannot Do

Microsoft's September 27, 2024 architecture is the strongest design Windows has shipped for an on-device personal-context store. It is not the strongest design that is theoretically possible -- and it is honest about which classes of attack it does not address. Here are five.

8.1 The UI host runs outside the enclave

This is the load-bearing limit. Davuluri's blog states it directly: "Recall components such as the Recall UI operate outside the VBS Enclaves and are untrusted in this architecture" [@rec-03]. The architecture diagram labels the UI box untrusted. The blog says this in September 2024, eighteen months before anyone publishes an exploit for it. The seam is documented.

In April 2026, Alexander Hagenah released TotalRecall Reloaded against the Generation 3+4 design [@rec-12]. The tool has two files: totalrecall.exe, an injector, and totalrecall_payload.dll, the payload. The injector locates the AIXHost.exe UI host via CreateToolhelp32Snapshot, allocates memory in the target with VirtualAllocEx, writes the path of the payload DLL with WriteProcessMemory, and spawns a remote thread pointing at LoadLibraryW. Once loaded, the payload reads decrypted Recall data out of the AIXHost.exe address space, where the enclave has just delivered it after the user's legitimate Hello authentication [@rec-12] [@rec-22].

Hagenah's verbatim characterisation, from the README: "No admin required. Standard user. No kernel exploit. No crypto bypass. Just COM calls." [@rec-12]. The tool ships three execution modes -- --launch (start AIXHost.exe and inject), --stealth (operate without UI signals), and --wait (attach to a future legitimate AIXHost.exe instance) [@rec-12]. The --stealth mode patches a function called DiscardDataAccess inside a DLL referred to as Baker.dll, which would otherwise discard the decrypted snapshot data on UI dismissal.The Baker.dll DiscardDataAccess patch is a reverse-engineering detail rather than a load-bearing architectural point, but it illustrates the surface area available to an injected payload inside the UI host's address space. Anything the UI process can do to a memory region, an injected DLL can do too.

The vault is solid. The delivery truck is not. -- Alexander Hagenah, TotalRecall Reloaded README, April 2026 [@rec-12]

The disclosure timeline is in the public record. Hagenah submitted a full disclosure to the Microsoft Security Response Center on March 6, 2026, including source code and build instructions [@rec-23]. Microsoft opened a case nine days later and closed it on April 3, 2026 with the determination that the behaviour "operates within the current, documented security design of Recall" [@rec-23]. The public release of the tool followed.

Note: Per iTnews's coverage of the disclosure, Microsoft's MSRC response after a month of review was that the demonstrated behaviour "operates within the current, documented security design of Recall" [@rec-23]. The phrasing is precise. The September 27, 2024 architecture blog [@rec-03] publishes that the UI host is outside the enclave; the MSRC servicing criteria [@rec-11] publish that same-user post-authentication code is not a security boundary. Hagenah demonstrated what "untrusted in this architecture" means in practice; MSRC confirmed the demonstration is consistent with the published model. Reasonable readers may disagree on whether the published model is the right model; the present article does not take a side and leaves that judgment to the reader.

sequenceDiagram participant User participant Inj as totalrecall.exe (standard user) participant AIX as AIXHost.exe (UI host, VTL0) participant Hello as Hello ESS / VBS Enclave participant Pay as totalrecall_payload.dll User->>AIX: Win+J launches Recall UI AIX->>Hello: request snapshot data User->>Hello: present biometric Hello->>AIX: deliver decrypted snapshot to address space Inj->>AIX: CreateToolhelp32Snapshot, locate process Inj->>AIX: VirtualAllocEx, write payload path Inj->>AIX: WriteProcessMemory with payload DLL path Inj->>AIX: CreateRemoteThread targeting LoadLibraryW AIX->>Pay: LoadLibraryW loads the payload DLL Pay->>AIX: read decrypted data from same address space Pay-->>Inj: exfiltrate plaintext snapshots AppContainer is the Windows process-isolation primitive that restricts a process's access to filesystem, registry, network, and inter-process surfaces to an explicit capability list declared at process launch. Universal Windows Platform applications and modern packaged applications launch inside an AppContainer by default; the kernel enforces the capability set on every access to a securable object. A Generation 6 Recall UI launched inside an AppContainer would not be able to load arbitrary user-supplied DLLs into its address space, because the AppContainer's capability set would not include the broad inter-process token-and-memory-access capabilities that Hagenah's injector relies on (`OpenProcess` for `PROCESS_VM_WRITE` and `PROCESS_CREATE_THREAD` against an out-of-container target are gated by the AppContainer's integrity level and capability set).

Key idea: The Generation 3 cryptographic chain holds -- as §5 established, a process with full filesystem access, a kernel-mode caller, and an administrator all read only ciphertext. The architectural seam is at the plaintext-delivery boundary -- the UI host, by Microsoft's own published architecture, is explicitly outside the enclave. Closing this seam would require a Generation 6 design that combines a high-signer Protected Process Light for the UI host, AppContainer with capability-restricted code-loading, and WDAC-enforced code integrity for the UI process tree. No such Microsoft commitment exists as of May 2026.

The deeper observation is one of recurrence. The Generation 1 failure was "same-user code is in the user's trust boundary, and the architecture relied on a filesystem ACL rather than per-access authentication." The Generation 5 disclosure is "same-user code is in the user's trust boundary, and the architecture relied on the UI host being a normal user-mode process." Different layer; same threat-model limit, restated.

8.2 Rubber-hose against an authenticated user

No per-access authentication scheme can defeat a coerced legitimate user. If the user is physically compelled to authenticate with Hello and then operate the UI, the architecture authorises a release into the UI plane that the coercer can read off the screen, off a screenshot, or off a redirected output device. The September 27 design explicitly does not address this threat class, and no plausible Generation N design within the same UX category can. The control here is procedural -- duress codes, panic gestures, or a separate "do not authorise" PIN -- rather than cryptographic.

8.3 NPU and GPU side channels

The VBS Enclave is the trust boundary for CPU-side computation. The Neural Processing Unit that drives Recall's semantic embedding is not in the enclave; neither is the integrated GPU. Side-channel attacks on AI accelerator memory hierarchies are unstudied territory in the published Copilot+ PC literature as of May 2026. There is no public proof of a Recall-specific NPU side channel; there is also no published assurance that one does not exist. This is "unknown unknown" territory, which is honest to state and dangerous to pretend has been ruled out.

8.4 OCR model integrity

The local OCR model loads from disk; the code inside the enclave reads and uses the weights. Microsoft has not publicly committed to a signed-weights verification step for the OCR model at enclave load. An attacker with administrator access could in principle substitute poisoned weights -- weights that deliberately mis-OCR specific credential formats so that the Purview EDM filter does not catch them, thereby smuggling sensitive plaintext through the filter and into the persistent store. Admin compromise is an out-of-scope class per the MSRC servicing criteria [@rec-11], but the OCR-integrity story would be more legible if the enclave verified a signature on the model file at load time.

8.5 Substrate compromise

A Secure Boot bypass, a Secure Kernel vulnerability, or a hypervisor escape takes down VBS itself, not Recall specifically. Saar Amar and Daniel King's Black Hat USA 2020 Breaking VSM by Attacking SecureKernel [@rec-32] remains the canonical historical treatment of the SK attack surface; the substrate has been hardened in response and is not proven secure. Recall inherits whatever the substrate's residual risk is in any given month. Patching is by way of the normal Windows servicing cadence.

Microsoft, by its own published servicing criteria, accepts each of these limits as architectural choices, not defects. What does the public record not tell us, that an independent reviewer would need to know?

9. Where the Public Record Runs Out

Five things the September 27 blog does not say, and one structural question it raises that the next five years of Windows shell features will answer.

9.1 The KDF and nonce scheme are not public

Davuluri's blog [@rec-03] specifies that each snapshot is encrypted with a per-snapshot key derived from a TPM-sealed master, and that the AEAD primitive is AES-256-GCM. It does not publish the key derivation function, the per-snapshot nonce derivation, or the associated-data inputs to GCM. The §5 pseudocode is a structural reconstruction; the literal source is in aeon.dll (or equivalent) and is not documented. The practical consequence is that third-party formal cryptographic review of the per-snapshot construction is foreclosed. MORSE's internal penetration test and the unnamed third-party security vendor's review [@rec-03] were performed against the literal implementation; both reports are non-public.

9.2 On-device OCR model integrity

The OCR model loads from disk and runs inside the enclave. There is no public Microsoft commitment that the enclave verifies a signature on the model weights at load time. The §8 OCR-integrity attack -- admin substitutes poisoned weights to defeat Purview EDM -- is bounded by the admin-is-out-of-scope MSRC policy [@rec-11], but a verified-load step would tighten the story.

9.3 InPrivate / password-field pause signal forgery

Davuluri's blog mentions that Recall pauses snapshot capture during InPrivate browsing and in password fields [@rec-03]. The signalling API by which the browser or the credential UI tells the Snapshot Service to pause is not fully documented. Whether a malicious browser extension can suppress legitimate pauses (forcing a snapshot of an InPrivate page) or spuriously trigger them (denial-of-service against legitimate snapshot capture) is unstudied in the public record.

9.4 The authorisation-window timeout is not exposed by policy

The Intune ADMX template documented in Manage Recall [@rec-08] exposes AllowRecallEnablement, DisableAIDataAnalysis, snapshot retention, storage allocation, and the per-app exclusion list. It does not, as of May 2026, expose the authorisation-window timeout as a configurable policy. An enterprise that wants to require re-authentication every N minutes during a Recall session does not have a Microsoft-supported knob for it.

9.5 The pattern question

This is the structural one. Microsoft has now shipped a VBS-enclave-backed feature in the desktop shell and has open-sourced the developer-facing SDK at microsoft/VbsEnclaveTooling [@rec-31]. The repository ships a code generator and a NuGet SDK, requires Windows 11 24H2 Build 26100.3916 or later, and supports C++17 and C++20 in the host with C++20 and Rust 1.88+ in the enclave [@rec-31].The SDK lowers the barrier to building a VBS Enclave dramatically. A developer who wants to put a small piece of sensitive computation (credential handling, secrets storage, on-device LLM context) inside an enclave no longer has to reverse-engineer Recall's implementation; they can write against a documented API.

The forward question is whether other desktop-shell features adopt the same pattern. Encrypted clipboard history, encrypted recent-files, on-device LLM context windows, the password manager Edge currently keeps in user-mode RAM -- each is a candidate. Hagenah's AIXHost.exe class suggests the pattern, naively applied, repeats the same UI-host weakness for every consumer. A VBS-Enclave-backed clipboard with a normal user-mode UI host inherits the same seam.

Microsoft's internal Offensive Research and Security Engineering team ran a penetration test against the Generation 3 architecture before the September 27 announcement [@rec-03]. An unnamed third-party security vendor performed an independent review. Neither report is public. The September 27 blog cites their existence to establish that adversarial review happened; it does not cite findings, methodology, or scope. This is not a criticism so much as a public-trust framing: the residual confidence a reader can place in the architecture is gated on the credibility of two reports they cannot read. Hagenah's April 2026 disclosure is the first publicly verifiable adversarial review of the UI surface; it found exactly what the architecture diagram already warned about. That coincidence is reassuring about the *honesty* of the published model; it does not by itself certify any property the published model does not cover.

Microsoft is not going to fix the AIXHost.exe class in 2026. What can a Copilot+ PC operator actually do with the shipping Recall today?

10. Deploying Recall Safely

Six knobs, in order. Setting them in this order turns the September 2024 architecture into a deployable enterprise posture.

Procurement. Pluton-or-discrete-TPM-2.0 hardware plus ESS-capable biometric sensor (IR camera plus presence sensor, or equivalent). Without ESS-capable biometrics, the Hello-gated architecture degrades to a PIN or password fallback, which is weaker than the architecture intends [@rec-25] [@rec-24].
Policy enablement. Deploy the Intune AllowRecallEnablement policy explicitly. The Microsoft Learn Manage Recall page states that "By default, Recall is disabled and removed on managed devices" [@rec-08]; the consumer OOBE default is opt-in but applies only to unmanaged devices. The managed-device default is authoritative once policy is in force, so deploy first, then provision.
Data minimisation. Deploy the snapshot-retention and disk-allocation policies from the Manage Recall policy reference [@rec-08]. Fewer snapshots and shorter retention reduce the maximum size of any single exfiltration window.
Sensitive-app exclusion. Enable the Microsoft Purview Endpoint DLP integration for window-level snapshot exclusion of any application handling regulated data (PHI, PCI, PII), and populate the per-app exclusion list with the local password manager, the corporate VPN client, and any other surfaces with high-value secrets [@rec-08]. This is the operator-controlled complement to the in-enclave Purview EDM content filter.
Defence-in-depth for the AIXHost.exe class. Deploy Smart App Control plus a Windows Defender Application Control (WDAC) policy to deny untrusted DLL loading on the device. DLL injection requires a process to load the payload; a WDAC policy with User-Mode Code Integrity (UMCI) enabled blocks the load of any DLL -- including Hagenah's payload -- that does not match a signer or hash allow-list in the policy. The LoadLibraryW call still executes; the load fails because the code-integrity check rejects the unsigned payload. None of these are in the Recall architecture; they are platform-level controls the operator must enable.
Audit and monitoring. Existing InfoStealer behaviour rules in Microsoft Defender for Endpoint will flag bulk reads of the Recall directory as high-confidence indicators. The point worth being precise about here: these are the pre-existing InfoStealer behaviour rules, not a Recall-specific signature; they fire on the access pattern (rapid enumeration of a personal-data directory) rather than on the file format. Configure Defender and your SIEM to alert on the directory.

Note: A tempting deployment "fix" is to disable VBS entirely as a way to prevent the Snapshot Service from running. This is a net security regression. VBS is the substrate for Credential Guard, HVCI, the Hello ESS algorithm isolation, and the Recall enclave itself. Disabling VBS eliminates the protection the Generation 3 architecture provides while leaving the desktop attack surface open. If the goal is to prevent Recall from running, use AllowRecallEnablement or DisableAIDataAnalysis instead.

The list of things not to bother doing: manual AES-256-GCM on the SQLite file (the enclave already does this); manual scrubbing of the Recall directory on a schedule (the retention policy already does this); writing a custom Defender signature for the Recall directory (existing InfoStealer behaviour rules already cover the access pattern); relying on the OOBE opt-in default for an enterprise pilot (that default applies to unmanaged devices only).

{` // Conceptual audit. The real script needs PowerShell on Windows; // this is the logic an operator's audit cmdlet would implement.

type DevicePosture = { pluton_present: boolean; tpm_2_0_present: boolean; hello_ess_enrolled: boolean; smart_app_control: "on" | "off" | "evaluation"; wdac_policy: "enforced" | "audit" | "none"; allow_recall_enablement: "allowed" | "disabled" | "not-set"; retention_days: number; defender_directory_alert: boolean; };

function auditRecallPosture(d: DevicePosture): string[] { const findings: string[] = [];

if (!d.tpm_2_0_present) findings.push("FAIL: no TPM 2.0; sealing path unavailable."); if (!d.pluton_present) findings.push("INFO: discrete TPM 2.0; bus-sniffing residual risk."); if (!d.hello_ess_enrolled) findings.push("FAIL: Hello ESS not enrolled; per-access biometric degraded to PIN."); if (d.smart_app_control === "off") findings.push("WARN: Smart App Control off; AIXHost.exe injection class wide open."); if (d.wdac_policy !== "enforced") findings.push("WARN: WDAC not in enforcement mode; LoadLibraryW gating absent."); if (d.allow_recall_enablement === "not-set") findings.push("WARN: AllowRecallEnablement not set; OOBE default may apply."); if (d.retention_days > 30) findings.push("INFO: retention >30 days; consider tightening for high-risk roles."); if (!d.defender_directory_alert) findings.push("WARN: Defender directory-enumeration alert not configured.");

return findings.length ? findings : ["OK: posture matches Gen 3+4 deployment guide."]; } `}

If you have gotten this far, you have the questions a reader walks in with answered. Here are the questions a reader walks out with.

11. Frequently Asked Questions

No. The September 27, 2024 architecture blog [@rec-03] and the IT-admin *Manage Recall* documentation [@rec-08] both state that snapshots, OCR text, and the semantic index are processed and stored entirely on-device. The Microsoft Diagnostic Data telemetry pipeline does not carry snapshot data. This is the one property the original May 2024 design got right, and it survived the re-architecture intact. No. Session-replay tools record interactive sessions for product analytics and ship the recording to a vendor cloud. Screen recording for accessibility (e.g., screen readers, magnification) operates on the live frame and does not persist a corpus. Compliance archiving (e.g., legal-hold mailbox archives) is a server-side, vendor-managed retention surface. Recall is on-device, personal, search-indexed over OCR text and embeddings, and gated on Hello biometric. The architectural lineage and the threat model differ for each. Yes, on a discrete TPM 2.0 SKU. The Microsoft Pluton chipset list [@rec-24] enumerates the Pluton-equipped silicon; Copilot+ PCs that are not on that list satisfy the Recall hardware requirements via a discrete TPM 2.0. The trade-off is the bus-sniffing surface discussed in §6: a Pluton-integrated TPM has no off-die bus to sniff for the security-processor traffic. The architectural correctness of the September 27 design does not depend on the choice; only the bus-sniffing residual risk does. Different threat models. BitLocker's threat model is offline disk theft: an adversary with the powered-off laptop in hand. The May 2024 Recall design borrowed BitLocker's "data at rest is encrypted" framing without absorbing that the dominant Recall adversary is a logged-on session adversary (an InfoStealer running as the user), against which BitLocker has nothing to say. Microsoft did not delay BitLocker because the original 2007 BitLocker matched the threat model it claimed to address; they delayed Recall because the original 2024 Recall did not. No, as of May 2026. The Hagenah AIXHost.exe class disclosed in April 2026 [@rec-12] [@rec-22] [@rec-23] was reported to MSRC on March 6, 2026; Microsoft closed the case on April 3, 2026 with the determination that the behaviour "operates within the current, documented security design of Recall" [@rec-23]. That determination is consistent with the published MSRC servicing criteria [@rec-11], which do not list same-user post-authentication as a security boundary. No CVE was assigned. No. The on-device NPU is required for the semantic-embedding step, and the Copilot+ hardware baseline (Pluton or discrete TPM 2.0 plus an NPU at a minimum throughput tier plus an ESS-capable biometric sensor) is a hard prerequisite [@rec-09] [@rec-04]. There is no CPU-only fallback for the embedding pipeline, and the on-device-only data flow forecloses a cloud fallback by design. No. As covered in §5, a VBS Enclave is a sub-region of a VTL0 host process that is promoted to VTL1 by the Secure Kernel [@rec-06]. An IUM trustlet (e.g., LsaIso, which backs Credential Guard) is a full Isolated User Mode process that runs wholly in VTL1. Both rely on the same hypervisor partition and Secure Kernel substrate, and the MSRC servicing criteria treat both under the VBS boundary policy [@rec-11], but the patterns are architecturally distinct. Microsoft's own documentation uses "VBS Enclave" terminology for the Recall case throughout [@rec-03] [@rec-06] [@rec-07]. Click to Do is a separate Copilot+ feature with a separate but partially overlapping privacy story; the November 22, 2024 Insider blog [@rec-04] bundles the two opt-in flows in the same first-run experience. Click to Do operates on the *current* screen rather than a history of past screens, and it does not maintain a persistent corpus. The bundling is a UX choice, not an architectural sharing of the snapshot store. No, even as administrator. The Snapshot Store holds AES-256-GCM ciphertext; the per-snapshot keys are derivable only inside the enclave; the master is sealed by the TPM and released to the enclave only on a fresh Hello attestation. An administrator with full filesystem access to the snapshot directory reads ciphertext [@rec-03] [@rec-11]. The Hagenah AIXHost.exe class [@rec-12] is *post-authentication* extraction from the UI host's address space, not an administrator-side read of the encrypted data. The cryptographic chain holds against admin; the seam is at the UI plane.

The arc this article walks -- a vendor ships, an audit lands, the vendor re-architects, an audit finds a seam, the vendor confirms the seam was in the published model -- is what the security feedback loop looks like when it works as designed. Naming each phase is what lets a reader recognise the same loop the next time a major Windows feature ships. The architecture diagram that ships with the next personal-data feature out of Redmond will, if the pattern holds, label its UI host the way Davuluri's labels the Recall UI: as untrusted, in writing, in advance. The reader who has walked this far should know to look for that label, and to evaluate the feature on whether the architecture names its seam rather than hiding it.

On a Copilot+ PC, the following PowerShell cmdlets (run as administrator) give you the device-side view: `Get-Tpm` for TPM 2.0 presence and Pluton attestation; `Get-CimInstance -Namespace root\cimv2\Security\MicrosoftTpm -ClassName Win32_Tpm` for detailed TPM state; `Get-LocalUser | Where-Object Enabled` plus the Hello enrolment surface in Settings for Hello ESS state; `Get-MpComputerStatus` for Defender status; and the Intune device-status portal for `AllowRecallEnablement` and related policies [@rec-08]. The §10 audit-script logic above describes the cross-check structure.

Fuzzy Extractors and the One Inequality That Explains Why Windows Hello Doesn't Use One

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

A fuzzy extractor turns a noisy, low-entropy biometric reading into a stable, uniformly random cryptographic key, with a public helper string that leaks negligibly little about the key. The Dodis-Reyzin-Smith 2004 construction is the canonical primitive: a secure sketch composed with a strong randomness extractor, governed by a single security inequality that bounds the extractable key length by the source min-entropy, minus the code redundancy, minus twice the security parameter. For consumer face and fingerprint at realistic noise levels, that inequality forbids a cryptographically useful key. Windows Hello -- and Apple Face ID -- consequently use a *match-then-unwrap-TPM-sealed-key* architecture instead, in which the biometric is a gate, not an input to key derivation.

1. Why can't a fingerprint just be a password?

A developer building a login system writes key = SHA256(fingerprint_image), ships it, and never logs in again. Two scans of the same finger produce two slightly different images, the hash is avalanche-sensitive by design, and the cryptographic key is unrecoverable on every authentication after the first. The fix is not a bigger hash. The fix is a new cryptographic primitive.

The mistake is universal because the temptation is universal. A fingerprint feels like a password: it identifies you, it is hard to forge, and you carry it everywhere. So why not just hash it into a 256-bit key the way every developer has hashed a password for thirty years? The answer is mechanical. SHA-256 is an avalanche function: flipping a single input bit flips, on average, half the output bits. A fingerprint sensor returns a slightly different image every time you press your finger to the glass; one stray dust mote, one degree of rotation, one pixel of pressure variation, and the input has changed in thousands of bits. The hash is statistically independent of the previous one. The key is gone.

{// Two near-identical 128-bit "fingerprint readings" differing in just 5 bits const enc = new TextEncoder(); async function sha256Hex(bytes) { const h = await crypto.subtle.digest('SHA-256', bytes); return [...new Uint8Array(h)].map(b => b.toString(16).padStart(2,'0')).join(''); } const w1 = new Uint8Array(16); for (let i = 0; i < 16; i++) w1[i] = (i * 37) & 0xff; const w2 = w1.slice(); w2[3] ^= 0x01; w2[7] ^= 0x10; w2[11] ^= 0x02; w2[12] ^= 0x40; w2[15] ^= 0x80; const h1 = await sha256Hex(w1), h2 = await sha256Hex(w2); let diff = 0; for (let i = 0; i < 64; i++) if (h1[i] !== h2[i]) diff++; console.log('reading 1 hash:', h1); console.log('reading 2 hash:', h2); console.log('hex digits that differ:', diff, '/ 64'); console.log('the second hash shares nothing with the first');}

Any biometric authentication scheme has to confront two simultaneous problems. The first is that biometric readings are noisy: two scans of the same finger differ in many bits, two photos of the same face under different lighting differ in millions. The second is that biometric distributions are low-entropy: fingerprints, faces, and even irises are far from uniformly random bitstrings; they cluster heavily, and a clever guesser can do much better than brute force.

The Dodis-Reyzin-Smith framing of these two facts, in the introduction of their 2004 paper, is precise: "strings that are neither uniformly random nor reliably reproducible seem to be more plentiful" than the well-behaved strings classical cryptography assumes [@dors-2008-siamjc]. Hao, Anderson, and Daugman put the engineering version of the problem in one sentence: "the main obstacle to algorithmic combination is that biometric data are noisy; only an approximate match can be expected to a stored template. Cryptography, on the other hand, requires that keys be exactly right, or protocols will fail" [@hao-anderson-daugman-2005-tr].

A pair of algorithms $(\text{Gen}, \text{Rep})$ such that $\text{Gen}(w) \to (R, P)$ produces a uniformly random key $R \in \{0,1\}^\ell$ and a public helper string $P$, while $\text{Rep}(w', P) \to R$ recovers the same key $R$ for any $w'$ within distance $t$ of $w$. The helper $P$ may be public; it must leak only negligibly about $R$ under any source $W$ of sufficient min-entropy [@dors-2008-siamjc].

A fuzzy extractor is the primitive built to solve exactly this design problem. Given a noisy source $w$ with at least $m$ bits of min-entropy, $\text{Gen}$ produces a stable key $R$ and a public helper $P$; given any reading $w'$ within Hamming distance $t$ of the original, $\text{Rep}$ recovers $R$ identically. The helper $P$ is allowed to be public; the security guarantee says $P$ leaks at most $\varepsilon$ bits about $R$ in statistical distance. This primitive is the right answer to the developer's mistake at the top of the section, and it has been the subject of twenty years of beautiful cryptographic theory.

So here is the puzzle the rest of the article will solve. Every major consumer biometric authentication product -- Windows Hello (2015), Apple Touch ID (2013), Apple Face ID (2017) -- has explicitly avoided this primitive. None of them derives a cryptographic key from your biometric. Why? The answer takes nine more sections, and it bottoms out on one inequality.

2. Historical origins: the 1990s problem statement

By the late 1990s the smartcard-and-PKI deployment wave had forced an uncomfortable question on the cryptographic community: how do you bind a long-lived private key to a person rather than a device? Smartcards were cheap to mass-produce, but they were also cheap to steal, and PINs got shared the moment any user found them inconvenient. Tying the key to a fingerprint or an iris reading promised a way out, but the underlying mathematics had not yet been written down.

Two foundational tools were already in the cryptographic toolkit and would later become load-bearing pieces of the fuzzy extractor. The first was the 1979 Carter-Wegman construction of universal hash functions: a family ${h_s}$ such that for any two distinct inputs $x \ne y$, $\Pr_s[h_s(x) = h_s(y)] \le 1/|\text{range}|$ [@carter-wegman-1979]. The second was the 1989 Impagliazzo-Levin-Luby Leftover Hash Lemma (LHL), which proved that applying a randomly chosen universal hash to any min-entropy source yields an output statistically indistinguishable from uniform, up to a precise entropy budget [@ill-1989]. Together, these two results were a randomness-extraction toolkit waiting for an application.Carter-Wegman 1979 is the deepest ancestor of every information-theoretic fuzzy extractor. The strong extractor at the heart of the Dodis-Reyzin-Smith construction is, mechanically, a Carter-Wegman universal hash with a random seed -- the LHL is what proves its output is uniform.

The min-entropy of a random variable $W$ is $H_\infty(W) = -\log_2 \max_w \Pr[W = w]$. It is the entropy measure that captures *worst-case* guessing difficulty: a source with $m$ bits of min-entropy cannot be guessed correctly with probability greater than $2^{-m}$ in one try. Min-entropy is the right measure for cryptographic key derivation because Shannon entropy is too generous when the distribution is peaked [@dors-2008-siamjc].

In May 1998, at the IEEE Symposium on Security and Privacy, Davida, Frankel, and Matt published the first formal-cryptographic proposal for binding a private signing key to a biometric. Their scheme used majority-decoding with a BCH error-correcting code to absorb the noise in repeated iris readings, then used the corrected reading to release a stored long-lived signing key [@davida-frankel-matt-1998], [@dblp-davida-frankel-matt-1998]. The construction worked, in the sense that it ran end-to-end on test data. But the paper had no notion of a strong extractor, no parameter inequality bounding the extractable key length, and no security theorem against a generic adversary. The reader was asked to trust the construction by inspection.

That same period saw the rise of a completely different approach. In 2001, Ratha, Connell, and Bolle of IBM proposed cancelable biometrics: instead of trying to derive a cryptographic key from the biometric, apply a non-invertible application-specific transformation $T_i$ to the feature vector before storage, so that a compromised template can be revoked and re-issued under a fresh $T_j$ [@ratha-connell-bolle-2001]. The goal was template protection, not key derivation.

The three properties Ratha et al. demanded of $T_i$ -- irreversibility (the transform cannot be inverted to recover the original feature vector), unlinkability (two transforms of the same biometric cannot be matched), and renewability (a compromised transform can be replaced) -- would two decades later be codified verbatim by ISO/IEC 24745:2022 as the universal properties of any biometric template protection scheme [@iso-iec-24745-2022], [@rathgeb-uhl-2011]. Cancelable biometrics partitions the design space alongside fuzzy extractors: the former transforms a biometric template, the latter derives a cryptographic key from it.

Davida, Frankel, and Matt had shipped a working construction without a unifying primitive. Juels and Wattenberg, within twelve months, would publish a cleaner construction with the same gap; and within seven years Dodis, Reyzin, and Smith would close it. The next section is the story of those precursors, and the structural defect they share.

3. Early approaches: fuzzy commitment and fuzzy vault

Two precursor constructions, six years apart, get most of the way to a fuzzy extractor without naming the primitive. They are simultaneously the foundation everything later builds on and the ad-hoc constructions the 2004 Dodis-Reyzin-Smith paper would retroactively classify as components of a real abstraction rather than a complete one.

3.1 Juels-Wattenberg 1999: fuzzy commitment

Ari Juels and Martin Wattenberg, at the 1999 ACM Conference on Computer and Communications Security, introduced the fuzzy commitment scheme [@juels-wattenberg-1999-pdf]. The construction is short enough to write on a napkin. Fix a binary error-correcting code $\mathcal{C} \subseteq {0,1}^n$ that corrects up to $t$ errors. To commit to a noisy biometric reading $w \in {0,1}^n$:

Pick a random codeword $c \stackrel{R}{\leftarrow} \mathcal{C}$.
Publish the commitment blob $(h(c), \delta)$ where $\delta := w \oplus c$ and $h$ is a cryptographic hash.

To decommit with a fresh reading $w'$ within Hamming distance $t$ of $w$, compute $c' := D(w' \oplus \delta)$ where $D$ is the code's decoder; check $h(c') \stackrel{?}{=} h(c)$. If the check passes, the commitment opens. The argument that the scheme is binding (the committer cannot later open to a different value) and hiding (the commitment leaks nothing about $w$) goes through in the random-oracle model.

sequenceDiagram participant U as User (commit) participant S as Storage participant V as Verifier (decommit) U->>U: Pick random codeword c U->>U: Compute delta = w XOR c U->>U: Compute t = hash(c) U->>S: Publish (t, delta) Note over V: Time passes, user re-scans V->>S: Fetch (t, delta) V->>V: Read fresh w' near w V->>V: Compute c' = Decode(w' XOR delta) V->>V: Check hash(c') == t V-->>V: Open commitment to c

Fuzzy commitment is elegant, but it has three structural gaps that DRS 2004 will later expose.

First, the construction is a commitment, not an extractor: it binds a hash of a codeword, not a uniformly random key, and it cannot be plugged directly into a key-derivation pipeline. Second, it assumes Hamming-distance noise, which fits iris codes (Daugman's IrisCodes are fixed-length bitstrings whose pairwise distance is fractional binomial) but does not fit fingerprint minutiae sets or face embeddings. Third, and most damagingly, the construction leaks under correlated re-enrolment. In 2009, Simoens, Tuyls, and Preneel demonstrated "how to link and reverse protected templates produced by code-offset and bit-permutation sketches" [@simoens-tuyls-preneel-2009]; if a user enrols twice with two slightly different readings $w_1, w_2$ of the same finger, the helper pair $(\delta_1, \delta_2)$ leaks $w_1 \oplus w_2$, which is closer to zero than uniform and reveals the noise distribution.

3.2 Juels-Sudan 2002 / 2006: fuzzy vault

Three years later, Ari Juels and Madhu Sudan extended the same idea to unordered sets, the natural metric for fingerprint minutiae [@juels-sudan-2002-pdf], [@juels-sudan-2006-dcc]. The fuzzy vault locks a secret $\kappa$ in a vault as follows:

Encode $\kappa$ as the coefficients of a polynomial $p$ of degree $k$ over a finite field.
For each element $a_i$ of the genuine biometric set $A$, publish the point $(a_i, p(a_i))$.
Add many chaff points $(x_j, y_j)$ with $y_j \ne p(x_j)$ to drown the genuine points in noise.

A user whose set $B$ overlaps sufficiently with $A$ identifies enough true points to Reed-Solomon-decode $p$, recovers $\kappa$, and unlocks the vault. The construction handles set-difference noise naturally and was widely deployed in fingerprint authentication research between 2002 and 2010.Watch the citation. The conference version is IEEE ISIT 2002 (single-page proceedings extended abstract; full author PDF is the canonical text). The journal version is Designs, Codes and Cryptography 38(2):237-257, February 2006 -- not IEEE Transactions on Information Theory as one widely-circulated secondary source claims.

But the fuzzy vault inherits and amplifies the precursor's defects. Walter Scheirer and Terrance Boult, in 2007, enumerated three concrete attacks: Attack via Record Multiplicity (ARM), Surreptitious Key Inversion (SKI), and Blended Substitution [@scheirer-boult-2007]. The Attack via Record Multiplicity exploits exactly the same correlated-re-enrolment weakness fuzzy commitment has: two vaults locking the same biometric under different polynomials reveal the underlying set $A$ by intersecting the published points. The Scheirer-Boult paper opens with a sentence that is, in retrospect, the diagnosis of the entire pre-DRS literature: "while many PETs for biometrics have attempted a formal analysis of their security, a significant oversight has been the issue of the risk from attacks that use multiple records" [@scheirer-boult-2007].

3.3 The structural defect both constructions share

Stand back. Both constructions handle noise tolerance via an error-correcting code, and both produce a security argument by hashing or hiding the result. Neither construction separates these two responsibilities. The noise-tolerance layer (the code) and the uniformity layer (the hash) are entangled in the same blob of public data. That entanglement is structurally why neither can prove a generic security theorem against a generic adversary: every security argument is tied to specific assumptions about the source distribution, the code, and the random oracle, and slight changes to any of them break the analysis. The fix is not a better code or a better hash. The fix has a name: decomposition.

A pair of algorithms $(\text{SS}, \text{Rec})$ such that $\text{SS}(w) \to s$ produces a public sketch $s$, and $\text{Rec}(w', s) \to w$ recovers the original $w$ for any $w'$ within distance $t$ of $w$. The sketch is allowed to leak some information about $w$, but the residual *average min-entropy* $\tilde H_\infty(W \mid \text{SS}(W))$ must remain at least some target $\tilde m$ [@dors-2008-siamjc].

That word -- decomposition -- is what Dodis, Reyzin, and Smith would deliver, on Thursday May 6, 2004, in Interlaken, Switzerland, at EUROCRYPT.

4. Evolution: five generations at a glance

Before walking through the DRS 2004 decomposition in detail, it helps to see where it sits in the family tree. Every construction the rest of this article mentions belongs to one of five generations, ordered by what failure of the previous generation it closes.

flowchart LR G0["Gen 0
hash(w)
fails on noise"] --> G1["Gen 1
Juels-Wattenberg 1999
fuzzy commitment"] G1 --> G15["Gen 1.5
Juels-Sudan 2002/2006
fuzzy vault"] G15 --> G2["Gen 2
Dodis-Reyzin-Smith 2004
fuzzy extractor"] G2 --> G3a["Gen 3a
Boyen 2004
reusable"] G2 --> G3b["Gen 3b
BDKOS 2005 / DKKRS 2012
tamper-resilient"] G2 --> G4["Gen 4
Fuller-Meng-Reyzin 2013
computational, LWE-based"] G2 --> G5["Gen 5
CFPRS 2016
reusable low-entropy"]

The table below names each generation, its central insight, and the new failure mode it exposes that motivates the next generation. Read it top to bottom; each row solves a problem the row above raised.

Gen	Year	Authors / venue	Central insight	New failure exposed
0	--	folk	$\text{key} = h(w)$	Avalanche destroys key on every re-scan
1	1999	Juels-Wattenberg, CCS [@juels-wattenberg-1999-pdf]	Code-offset: hide $w$ inside $\delta = w \oplus c$ for random codeword $c$	Hamming-only; no extractor; leaks under re-enrol
1.5	2002 / 2006	Juels-Sudan, ISIT / DCC [@juels-sudan-2002-pdf], [@juels-sudan-2006-dcc]	Polynomial-on-set with chaff points; handles set-difference	Vulnerable to record-multiplicity and key-inversion attacks [@scheirer-boult-2007]
2	2004 / 2008	Dodis-Reyzin-Smith, EUROCRYPT / SIAM JC [@drs-2004-eurocrypt], [@dors-2008-siamjc]	Decomposition: secure sketch + strong extractor; one inequality	Forbids construction at consumer biometric entropy
3a	2004	Boyen, CCS [@boyen-2004-ccs-eprint]	Reusable fuzzy extractors; chosen-perturbation security	Outsider model needs XOR-homomorphic sketch; insider model needs RO
3b	2005 / 2012	Boyen-Dodis-Katz-Ostrovsky-Smith, EUROCRYPT [@bdkos-2005-eurocrypt]; DKKRS, IEEE TIT [@dkkrs-2012-ieeetit]	Tamper-resilient fuzzy extractors; helper-data integrity against active adversary	Active-adversary lower bound: $\Omega(\log(1/\varepsilon))$ extra entropy
4	2013 / 2020	Fuller-Meng-Reyzin, ASIACRYPT / I&C [@fmr-2013-asiacrypt-eprint], [@fmr-2020-iandc]	Skip the sketch; LWE-based computational construction extracts key length equal to source min-entropy	Negative result: every computational HILL secure sketch still implies an ECC with $2^{m-2}$ codewords
5	2016	Canetti-Fuller-Paneth-Reyzin-Smith, EUROCRYPT [@cfprs-2016-eurocrypt]	Per-bit digital lockers; sample-then-extract; reusable for low-entropy sources	Depends on digital-locker idealisation; restricted source class

Read this way, the family tree tells a story. Each successor generation closes a real defect: Boyen 2004 closes the multi-enrolment leak that Simoens-Tuyls-Preneel would later make concrete; BDKOS 2005 closes the helper-data tampering problem; FMR 2013 attacks the min-entropy floor itself by trading information-theoretic security for an LWE assumption; CFPRS 2016 chases the low-entropy regime where every prior generation gave up. None of them dethrones the foundational decomposition. They all live inside the framework DRS established.Watch two attribution traps. Boyen 2004 is a sole-author paper -- "Reusable Cryptographic Fuzzy Extractors" by Xavier Boyen [@boyen-2004-ccs-eprint], not "Boyen and Reyzin" or "Boyen et al." And Fuller-Meng-Reyzin 2013 appeared at ASIACRYPT 2013, not EUROCRYPT 2013; the misattribution is widespread in secondary sources [@fmr-2013-asiacrypt-eprint].

Generation 2 is the load-bearing entry. Every later claim about what a fuzzy extractor can and cannot do traces back to it. The next section walks through the construction in mechanical detail, because the inequality at its centre is the artefact every later section will reference.

5. The breakthrough: Dodis-Reyzin-Smith 2004 in detail

May 6, 2004. Interlaken, Switzerland. Session 16 ("New Applications"). Yevgeniy Dodis (NYU), Leonid Reyzin (Boston University), and Adam Smith (then MIT) present a paper that will be widely cited as the foundational work of the area [@drs-2004-eurocrypt]. The journal version, published in 2008 in SIAM Journal on Computing with Rafail Ostrovsky added as a fourth author, is the canonical reference text for every formal definition the field uses [@dors-2008-siamjc].The conference paper is three-author Dodis-Reyzin-Smith; the 2008 SIAM Journal on Computing version is four-author and adds Ostrovsky. Cite whichever fits your context, but get the author count right.

The paper's contribution is not a new algorithm. It is a decomposition and a security inequality. The two halves of the decomposition are the secure sketch and the strong randomness extractor, and the inequality bounds the extractable key length in terms of source min-entropy, code redundancy, and security parameter.

5.1 The secure sketch: information reconciliation

A secure sketch is the noise-tolerance layer. Formally, an $(\mathcal{M}, m, \tilde m, t)$-secure sketch is a pair of functions $(\text{SS}, \text{Rec})$ over a metric space $(\mathcal{M}, \text{dis})$ such that, for any $w, w'$ with $\text{dis}(w, w') \le t$, $\text{Rec}(w', \text{SS}(w)) = w$, and for any source $W$ with min-entropy $H_\infty(W) \ge m$, the average min-entropy $\tilde H_\infty(W \mid \text{SS}(W)) \ge \tilde m$ [@dors-2008-siamjc].

Average min-entropy, also called conditional min-entropy, generalises min-entropy to the case where partial information $Y$ about $W$ is public. Formally, $\tilde H_\infty(W \mid Y) = -\log_2 \mathbb{E}_{y \leftarrow Y}\!\left[\max_w \Pr[W = w \mid Y = y]\right]$. It is the right entropy measure for sketches because the sketch $\text{SS}(W)$ is public and an adversary's best guess of $W$ averages over the possible sketch values [@dors-2008-siamjc].

Two canonical sketch constructions matter. The code-offset sketch picks a random codeword $c$ from an $[n, k, 2t+1]$ binary error-correcting code and publishes $s = w \oplus c$. To recover, compute $c' = D(w' \oplus s)$ where $D$ is the code's decoder; then return $w = s \oplus c'$. The entropy loss is at most $n - k$ bits. The syndrome sketch publishes $s = H \cdot w^T$ where $H$ is the parity-check matrix of the same code; recovery solves a coset-leader problem. The entropy loss is identical; the syndrome variant just publishes a shorter helper. PinSketch, the canonical sketch for set-difference metrics, lives in section 6 of the journal paper [@dors-2008-siamjc].

{// Simulate a tiny [16, 11, 3] code: 11 data bits, 5 parity bits via a fixed generator. // Real code-offset uses BCH/Reed-Solomon; this is a toy that shows the structure. function parity(w, mask) { let p = 0; for (let i = 0; i < 16; i++) if ((mask>>i)&1) p ^= (w>>i)&1; return p; } const masks = [0b1111111111100000, 0b1111110000011110, 0b1111000011111101, 0b1100111111111011, 0b0011111111110111]; function encode(data11) { let cw = data11 & 0x7FF; for (let i = 0; i < 5; i++) cw |= parity(data11, masks[i]) << (11 + i); return cw; } // Sketch: pick a random codeword c, publish s = w XOR c const w = 0b0110110010110101; // imagine this is the user's first reading const data = Math.floor(Math.random() * 2048); const c = encode(data); const s = w ^ c; console.log('First reading w =', w.toString(2).padStart(16,'0')); console.log('Random codeword c =', c.toString(2).padStart(16,'0')); console.log('Public sketch s = w XOR c =', s.toString(2).padStart(16,'0')); // Re-scan: the user reads w' with one bit flipped const wp = w ^ (1 << 7); console.log('Re-scan reading w\\' =', wp.toString(2).padStart(16,'0')); const cp = wp ^ s; console.log('Decoder input c + e =', cp.toString(2).padStart(16,'0')); console.log('The decoder sees the noisy codeword and corrects it back to c -- so Rec recovers w from w\\' and s.');}

5.2 The strong randomness extractor: from sketch-residual to uniform key

A strong randomness extractor is the uniformity layer. The relevant formal statement is the average-case form of the Leftover Hash Lemma.

A function $\text{Ext}: \{0,1\}^n \times \{0,1\}^d \to \{0,1\}^\ell$ is an *average-case* $(n, \tilde m, \ell, \varepsilon)$-strong extractor if, for every joint distribution $(W, I)$ over $\{0,1\}^n \times \{0,1\}^*$ with $\tilde H_\infty(W \mid I) \ge \tilde m$, the statistical distance $\text{SD}((\text{Ext}(W; S), S, I), (U_\ell, S, I)) \le \varepsilon$ where $S$ is the (public) extractor seed and $U_\ell$ is uniform [@dors-2008-siamjc]. Let $H$ be a universal hash family with output length $\ell$. For any source $W$ with $\tilde H_\infty(W \mid I) \ge \tilde m$, the distribution $(S, H_S(W), I)$ is $\varepsilon$-close in statistical distance to $(S, U_\ell, I)$ whenever $\ell \le \tilde m - 2 \log(1/\varepsilon) + 2$ [@ill-1989], [@dors-2008-siamjc]. The Leftover Hash Lemma is therefore the single inequality that powers every information-theoretic strong extractor used in practice.

The LHL says: take any min-entropy source, hash it with a randomly chosen universal hash, and what comes out is statistically indistinguishable from uniform, up to a precise budget. Pay $2 \log(1/\varepsilon) - 2$ bits of entropy at the door; everything left over is uniform.

5.3 Composition

The composition is the whole point. Define $\text{Gen}(w) := (R, P)$ where $P = (\text{SS}(w), \text{seed})$ and $R = \text{Ext}(w; \text{seed})$. To recover, $\text{Rep}(w', P)$ runs $w = \text{Rec}(w', \text{SS}(w))$ and recomputes $R = \text{Ext}(w; \text{seed})$. The composition is an $(\mathcal{M}, m, \ell, t, \varepsilon)$-fuzzy extractor, and the security proof is now algebraic.

The helper data $P$ in a fuzzy extractor is the public part of the output of $\text{Gen}$. It consists of the secure sketch $\text{SS}(w)$ plus the extractor seed. It must be available at recovery time, but it need not be secret. The security guarantee says that even an adversary who sees $P$ in full learns at most $\varepsilon$ bits about the extracted key $R$ in statistical distance [@dors-2008-siamjc]. flowchart TD W["Noisy reading w"] --> SS["Secure sketch SS"] W --> EXT["Strong extractor Ext"] SEED["Random seed"] --> EXT SS --> P["Public helper P = (sketch, seed)"] SEED --> P EXT --> R["Uniform key R"] P --> REP["Rep at recovery"] WP["Noisy reading w'
(within distance t)"] --> REP REP --> R2["Same uniform key R"]

5.4 The load-bearing inequality

Compose the two entropy budgets. The sketch starts with $H_\infty(W) \ge m$ bits of min-entropy and leaks at most $n - k$ to its public sketch; what remains is $\tilde H_\infty(W \mid \text{SS}(W)) \ge m - (n - k)$. Feed that residual into the LHL with security parameter $\varepsilon$, and the extractor delivers a uniform key of lengthThe constant $+2$ at the end of the inequality is an artefact of how DORS 2008 states the average-case Leftover Hash Lemma in Lemma 2.4; the conference paper writes it as $-O(1)$.

$$\ell \;\le\; H_\infty(W) - (n - k) - 2\log(1/\varepsilon) + 2.$$

This inequality is the artefact every later section will reference. Walk it term by term. The first term is the source min-entropy: the actual information content of the biometric. The second term is the code redundancy: the entropy paid to absorb noise. The third term is the security parameter cost: every halving of the adversary's distinguishing advantage costs two bits. The final $+2$ is a small constant.

{function extractableKeyLen(m, codeRedundancy, epsilon) { const securityCost = 2 * Math.log2(1 / epsilon); return m - codeRedundancy - securityCost + 2; } // Iris source (Daugman 2003: ~249 dof = effective bits), 128-bit security, BCH [255,131,37] console.log('iris @ eps=2^-80:', extractableKeyLen(249, 124, 2 ** -80).toFixed(1), 'bits'); // Fingerprint at the upper end of Pankanti-Prabhakar-Jain 2002 (~70 effective bits) console.log('fingerprint @ eps=2^-80:', extractableKeyLen(70, 124, 2 ** -80).toFixed(1), 'bits'); // Face embedding under correlated illumination noise (~30-50 effective bits) console.log('face @ eps=2^-80:', extractableKeyLen(40, 124, 2 ** -80).toFixed(1), 'bits'); // Loosen security to eps=2^-40 and see if fingerprint recovers console.log('fingerprint @ eps=2^-40:', extractableKeyLen(70, 124, 2 ** -40).toFixed(1), 'bits');}

Run that calculator on realistic numbers. At a security parameter of $\varepsilon = 2^{-80}$, the third term alone eats 160 bits. A standard $[255, 131, 37]$ BCH code (which corrects up to 18 errors in 255 bits) burns another 124 bits. To extract a 128-bit AES key, the source must supply at least 410 bits of min-entropy.

Set $m = 70$ (fingerprint upper bound per Pankanti et al. 2002), $n - k = 124$ (BCH redundancy), and $\varepsilon = 2^{-80}$. The extractable key length becomes $70 - 124 - 160 + 2 = -212$ bits. A negative bound means the construction is not slow or expensive: it is *infeasible* at any parameter setting. Try loosening security to $\varepsilon = 2^{-40}$: still $70 - 124 - 80 + 2 = -132$. Even pushing the security parameter all the way down to $\varepsilon = 2^{-10}$ (laughably weak by OS-authenticator standards) leaves you at \$70 - 124 - 20 + 2 = -72$ bits. The fingerprint source simply does not have the entropy budget for the construction at any meaningful security level.

The iris, at Daugman's 249 statistical degrees of freedom [@daugman-2003-pdf], [@daugman-2004-csvt], is just barely enough -- and only because Hao, Anderson, and Daugman engineered a careful two-layer Hadamard-then-Reed-Solomon code that exploits the block structure of iris noise to achieve a high error-correction rate per information bit, sufficient to extract 140 bits from the 2048-bit iris code at 99.5% recovery success [@hao-anderson-daugman-2005-tr]. The fingerprint, at 40 to ~70 effective bits per Pankanti, Prabhakar, and Jain [@pankanti-prabhakar-jain-2002], is not even close. The face embedding, at 30 to 50 raw bits and considerably less under correlated illumination and pose noise, is further still.

Key idea: The DRS 2004 key-length inequality is the article's load-bearing artefact. Every later claim that a fuzzy extractor cannot work on consumer biometrics traces back to it. The construction is not slow or expensive on these sources -- it is mathematically forbidden, in the sense that the extractable key length is negative at the security parameter an operating-system authenticator demands.

This is the inequality that forbids the construction on consumer-grade face or fingerprint at the security bar an operating system authenticator demands. The rest of the article is the four-generation effort to escape the forbidding, and the architectural choice every shipped consumer product made instead.

6. State of the art: by metric space and by successor generation

The DRS 2004 framework is parameterised by metric space and source class. To navigate the field, think of every fuzzy-extractor instantiation as a pair of choices: pick a sketch suited to the source's metric, then pick an extractor suited to the source's entropy profile. The state of the art is best read as a two-axis table.

6.1 Sketches by metric space

Metric space	Sketch construction	Code or technique	Where it fits
Hamming distance	Code-offset / syndrome [@dors-2008-siamjc]	$[n,k,2t+1]$ BCH	Iris codes; SRAM PUFs
Set difference	PinSketch (DORS 2008 section 6) [@dors-2008-siamjc], [@reyzin-lab-home]	Symmetric-difference syndrome decoding; sublinear in universe size	Fingerprint minutiae sets; many-out-of-many tokens
Edit distance	Embed into Hamming via low-distortion encoding	Ostrovsky-Rabani-style embeddings	DNA sequences, typed passwords
Continuous (face / fingerprint embeddings)	Quantise then Hamming	Lloyd-Max or learned quantisers	Face deep-features; the worst empirical entropy profile

The continuous-source case is where the consumer biometric story gets ugly: quantising a learned embedding loses entropy in proportion to the quantiser's resolution, and the residual is the entropy budget the sketch has to work with.

6.2 Generation 3a: Boyen 2004 reusable fuzzy extractors

Xavier Boyen, about five months after the DRS conference paper, attacked the multi-enrolment problem head on [@boyen-2004-ccs-eprint]. A reusable fuzzy extractor remains secure when the same source is enrolled multiple times under correlated but different readings $w_1, w_2, \ldots, w_q$. Boyen formalises two threat models. The outsider chosen-perturbation attack allows the adversary to choose the noise patterns between enrolments; Boyen shows that fuzzy extractors built from XOR-homomorphic sketches (code-offset is one) are secure against outsider adversaries with bounded perturbations. The insider chosen-perturbation attack additionally gives the adversary access to the extracted keys $R_1, \ldots, R_q$; this stronger model requires a random-oracle assumption. The Canetti-Fuller-Paneth-Reyzin-Smith 2016 paper would later argue that the outsider model's perturbation class is "unlikely to hold for a practical source," quoting the paper directly [@cfprs-2016-eprint].

6.3 Generation 3b: BDKOS 2005 / DKKRS 2012 tamper-resilient fuzzy extractors

A different defect of the DRS construction: the public helper $P$ is not authenticated. If an active adversary can rewrite $P$ on its way to the verifier, the verifier reconstructs the wrong key, and the security analysis falls apart. Xavier Boyen, Yevgeniy Dodis, Jonathan Katz, Rafail Ostrovsky, and Adam Smith addressed this in 2005 with the tamper-resilient fuzzy extractor [@bdkos-2005-eurocrypt]. Their Theorem 1 builds a tamper-detecting secure sketch in the random-oracle model: publish $(\text{pub}^, h)$ where $\text{pub}^$ is a standard sketch and $h = H(w, \text{pub}^*)$; at recovery, recompute the tag and reject on mismatch. The full tamper-resilient fuzzy extractor (BDKOS §3.2) then composes this tamper-detecting sketch with a strong extractor. The standard-model construction came later, in 2012, from Dodis, Kanukurthi, Katz, Reyzin, and Smith, by replacing the random oracle with an algebraic manipulation detection (AMD) code, with entropy loss $O(\log(1/\varepsilon))$ above the passive bound [@dkkrs-2012-ieeetit], [@cdfpw-2008-eurocrypt].

6.4 Generation 4: Fuller-Meng-Reyzin 2013 computational fuzzy extractors

By 2013 the field had hit a wall. The DRS inequality forbids information-theoretic constructions on low-entropy consumer biometrics. Fuller, Meng, and Reyzin asked the obvious next question: does the wall come down if you trade information-theoretic security for computational security? Their answer, in Computational Fuzzy Extractors at ASIACRYPT 2013, is half negative and half positive [@fmr-2013-asiacrypt-eprint], [@fmr-2020-iandc].

The negative half: "for every secure sketch that retains $m$ bits of computational entropy, there is an error-correcting code with $2^{m-2}$ codewords" [@fmr-2013-asiacrypt-eprint]. The coding-theory lower bound survives the relaxation to computational HILL pseudoentropy. The positive half: skip the sketch entirely. Treat the biometric reading as an LWE error vector, use a random linear code, and base security on the Learning With Errors problem. The construction extracts a key length equal to the source min-entropy, with security under standard LWE assumptions.

6.5 Generation 5: Canetti-Fuller-Paneth-Reyzin-Smith 2016 reusable low-entropy

The final piece of the contemporary state of the art is CFPRS 2016 [@cfprs-2016-eurocrypt], [@cfprs-2016-eprint]. Ran Canetti, Benjamin Fuller, Omer Paneth, Leonid Reyzin, and Adam Smith built a fuzzy extractor that is reusable, handles low-entropy distributions, and works under realistic correlated noise. The key technique is per-bit digital lockers: for each bit of the source, store a digital locker keyed on a random subset of input bits. Recovery samples subsets, queries the lockers, and majority-votes. The construction depends on a digital-locker idealisation, but CFPRS show that any reusable fuzzy extractor for low-entropy sources requires either the random-oracle model or an equivalent strong assumption, which limits the room to remove the idealisation.

6.6 The one consumer-biometric construction that ever cleared the bar

Across two decades of theoretical work, exactly one published consumer-biometric fuzzy extractor has cleared the DRS bar at production-grade parameters. Hao, Anderson, and Daugman, in a 2005 Cambridge tech report and a 2006 IEEE Transactions on Computers paper, presented an iris fuzzy extractor that "can generate up to 140 bits of biometric key, more than enough for 128-bit AES" with "a 99.5% success rate" on 70 eyes [@hao-anderson-daugman-2005-tr], [@hao-anderson-daugman-2006-ieeetc]. The construction layers a Hadamard code (handles single-bit errors) with a Reed-Solomon code (handles burst errors) inside the code-offset sketch, then runs LHL.The Hao-Anderson-Daugman code is a two-layer Hadamard-then-Reed-Solomon composition. The inner Hadamard layer is HC(6) at rate $7/64 \approx 1/9$ (7 bits encoded into 64 bits per block, 32 blocks per 2048-bit iris code), and absorbs noise within each block; the outer RS(32, 20) over $\text{GF}(2^7)$ tolerates up to six block errors across the 32 blocks. The composition costs more redundancy than a single BCH code but matches the iris noise statistics better. The iris is the only common biometric where the entropy budget is generous enough to absorb that much redundancy and still leave 140 bits over.

The state of the art, taken together, is wide and mature. Every successor either requires the source to have an entropy profile most consumer biometrics lack, or uses idealisations (random oracle, digital locker, LWE-with-specific-error-distribution) that no production cryptosystem wants to depend on. The next two sections make that boundary precise.

7. Competing approaches: six paradigms

Step back from the fuzzy-extractor lineage and put it in competitive context. There are at least six distinct approaches to binding cryptographic operations to a biometric, and only two of them derive a key from the biometric. The other four use the biometric as a gate on a key generated elsewhere. ISO/IEC 24745:2022 codifies three protection properties -- irreversibility, unlinkability, and renewability -- that any biometric template protection scheme should provide [@iso-iec-24745-2022], and the Rathgeb-Uhl 2011 survey is the open-access reference that maps each approach to the three properties [@rathgeb-uhl-2011].

Approach	Representative work	Derives key?	Irreversibility	Unlinkability	Renewability
Information-theoretic fuzzy extractor	Dodis-Reyzin-Smith 2004 family [@dors-2008-siamjc]	Yes	Yes (under min-entropy)	Hard under correlated re-enrol	Yes (rotate seed and sketch)
Computational fuzzy extractor	Fuller-Meng-Reyzin 2013 / CFPRS 2016 [@fmr-2013-asiacrypt-eprint], [@cfprs-2016-eurocrypt]	Yes	Yes (under LWE / digital locker)	Improved over information-theoretic	Yes
Cancelable biometrics	Ratha-Connell-Bolle 2001 [@ratha-connell-bolle-2001]	No	Yes (by transform design)	Yes (transform key)	Yes (re-enrol under fresh transform)
Homomorphic encryption biometric matching	Engelsma-Jain-Boddeti HERS [@engelsma-jain-boddeti-hers-arxiv]	Partial	Yes (under HE)	Yes	Yes
Secure-element match-on-chip	Apple Secure Enclave [@apple-platform-security], [@apple-secure-enclave]	No	Hardware-anchored	Yes (per-device)	Yes (hardware key rotation)
Match-then-unwrap-TPM-sealed-key	Windows Hello ESS [@ms-learn-ess], [@ms-learn-hello-business]	No	Hardware-anchored	Yes (per-device)	Yes (rotate TPM-sealed key)

A class of biometric template protection schemes in which a non-invertible, application-specific transformation $T_i$ is applied to the feature vector before storage. The stored template is then $T_i(\text{features})$; matching is performed in the transformed space; and a compromised template can be revoked by re-enrolling under a fresh transform $T_j$. The goal is *template protection*, not cryptographic key derivation: no uniformly random key falls out of the construction. ISO/IEC 24745 names three properties such a transform must satisfy: irreversibility, unlinkability, and renewability [@ratha-connell-bolle-2001], [@rathgeb-uhl-2011]. The international standard *Information security, cybersecurity and privacy protection -- Biometric information protection* (ISO/IEC 24745:2022 Edition 2, 63 pages, published February 2022 [@iso-iec-24745-2022]) defines three properties of any biometric protection scheme -- irreversibility, unlinkability, renewability -- without prescribing any specific cryptographic primitive. The standard is paywalled at CHF 204, which is why most academic and engineering treatments cite the open-access Rathgeb-Uhl 2011 survey [@rathgeb-uhl-2011] as a proxy for the property definitions. The three properties are deliberately neutral: a fuzzy extractor, a cancelable transform, a homomorphic-encryption matcher, and a hardware-anchored secure element can all in principle satisfy them, and the standard is silent on which is best.

The two derive approaches (rows 1 and 2 in the table) follow the genealogy this article has been tracing. The remaining four are gate approaches: each generates the cryptographic key by some independent means -- a TPM-sealed asymmetric key, a Secure Enclave-bound key, a homomorphic-encryption keypair -- and uses the biometric only to decide whether to release the key. The cancelable-biometrics approach is even more conservative: it does not even tie a key to the biometric at all; it only protects the template against compromise.

Why is the derive versus gate distinction so deep? Because it determines who is responsible for the key's secrecy. In a derive model, the biometric is the secret; if the biometric leaks (a photo of your face, a latent print on a glass), the cryptographic key is at risk. In a gate model, the secret is independent of the biometric -- usually a hardware-anchored private key that never leaves the secure element -- and the biometric is just a soft second factor that decides whether the user is allowed to use the secret.

Hardware-anchored gate schemes also get to rely on attestation: a TPM or Secure Enclave can prove to a remote relying party that the key it just used is bound to a specific device, by a specific user, in a specific authentication ceremony. A pure software fuzzy extractor cannot make any of those claims.

This is the decisive architectural distinction in the field. Every shipped consumer biometric authenticator on the planet picks gate. The next two sections explain why: section 8 walks through three theoretical lower bounds that draw the perimeter inside which any fuzzy extractor can live, and section 10 walks through the Windows Hello architecture as the concrete embodiment of gate.

8. Theoretical limits

Three lower-bound results, taken together, draw the perimeter inside which any fuzzy extractor can live. The section 5 inequality was the first. Two more come from later papers, and they are sharper than the basic inequality suggests.

8.1 The min-entropy floor

The DRS section 5 inequality already gives a floor: $\ell \le H_\infty(W) - (n-k) - 2\log(1/\varepsilon) + 2$. Fuller, Reyzin, and Smith in 2020 sharpened this with an impossibility result for universal information-theoretic fuzzy extractors.

They define a stronger notion they call fuzzy min-entropy, $H^{\text{fuzz}}{t,\infty}(W) := -\log \max{w_0} \Pr[W \in \mathcal{B}t(w_0)]$, and prove that the gap between the universal-construction bound $H\infty(W) - \log|\mathcal{B}t|$ and the optimal bound $H^{\text{fuzz}}{t,\infty}(W)$ can be a large fraction of $n$ bits. For Daugman's iris parameters ($n = 2048$, $H_\infty \approx 249$, $\log|\mathcal{B}_t| \approx 1024$), the universal bound sits more than 1000 bits below the fuzzy-min-entropy upper bound -- a gap of $\approx 0.5n$ -- and Theorem 5.1's impossibility region pushes the worst-case gap up toward $h_2(\tau) \cdot n$ for higher noise rates [@frs-2020-ieeetit]. The implication: a single universal construction cannot extract the optimal key length from every high-fuzzy-min-entropy source; some sources require source-specific constructions to close the gap, and the DRS bound is essentially tight in the worst case.

Plug realistic numbers into the floor. The table below is the empirical perimeter the cryptographic community has lived inside for two decades.

Source	Approx. raw entropy	Effective entropy under correlated noise	Clears DRS bar at $\varepsilon = 2^{-80}$ for 128-bit key?
Iris [@daugman-2003-pdf], [@daugman-2004-csvt]	~249 dof	~249 dof (matched-illumination scans)	Yes (demonstrated [@hao-anderson-daugman-2006-ieeetc])
Fingerprint minutiae [@pankanti-prabhakar-jain-2002]	~70 bits at best image quality	40-70 bits depending on sensor	No
Face deep-feature embeddings	30-50 bits raw	Often much less under illumination / pose	No
SRAM PUF [@intrinsic-id-sram-puf], [@tuyls-skoric-kevenaar-2007-springer]	thousands of bits (entire SRAM page)	thousands of bits (controlled noise)	Yes (deployed in over a billion devices)

Watch Daugman's 249 figure carefully. It is the number of degrees of freedom in the Hamming distance distribution between IrisCodes from different irises, fit to a fractional binomial with $N = 249$ and $p = 0.5$. It is not the raw min-entropy of an iris image: an iris sensor returning 249 bits of high-quality iris data is not the same as 249 bits of min-entropy. Daugman's 2003 Pattern Recognition paper makes the distinction explicitly [@daugman-2003-pdf].

Note: Across every consumer biometric the industry has deployed, the iris is unique in clearing the DRS bar at production parameters. Daugman's 249 statistical degrees of freedom give the iris a budget more than three times the budget of fingerprint, and an order of magnitude more than face. Hao, Anderson, and Daugman 2006 demonstrate a 140-bit iris key with 99.5% success on 70 eyes [@hao-anderson-daugman-2006-ieeetc] -- the only published consumer-biometric fuzzy extractor ever to clear the DRS bar at production parameters. The catch: iris sensors are intrusive, expensive, and rarely shipped in consumer phones or laptops.

8.2 Reusability impossibility

Boyen's 2004 insider chosen-perturbation game is unconditionally insecure for adversaries who can choose enough perturbations [@boyen-2004-ccs-eprint]. CFPRS 2016 cite this impossibility result and work around it by restricting attention to a digital-locker-amenable source class [@cfprs-2016-eprint]. The practical implication is that any fuzzy extractor that wants to be reusable across many enrolments has to either (a) restrict the source class (CFPRS's path) or (b) accept a security degradation per re-enrol. Neither option is appealing for a consumer device that may see its user re-enrol after every kernel update, every sensor recalibration, or every routine credential rotation.

8.3 Active-adversary lower bound

A passive adversary sees the helper $P$ but does not modify it; an active adversary can rewrite $P$ between enrolment and recovery. BDKOS 2005 and DKKRS 2012 prove that protecting against active adversaries requires either a one-time setup secret (a shared seed established out of band), an authenticated channel between enrolment and recovery, or a min-entropy surplus of $\Omega(\log(1/\varepsilon))$ above the passive bound [@bdkos-2005-eurocrypt], [@dkkrs-2012-ieeetit]. For $\varepsilon = 2^{-80}$, the active-adversary surcharge is 80 bits.

8.4 Combining the three bounds

Stack the three bounds on top of each other for a consumer face / fingerprint source. The min-entropy floor is the hardest barrier: with 40 to 80 effective bits and 160 bits of security-parameter cost plus 100-plus bits of code redundancy, the extractable key length is negative. The reusability impossibility forecloses the workaround of pretending that re-enrolments are uncorrelated -- they are not, because real biometric drift is highly correlated. The active-adversary bound forecloses the workaround of pretending the helper data is safe in transit. A software-only fuzzy extractor cannot meet a consumer-OS security bar at consumer biometric quality. What you do instead is the next section.

9. Open problems

Four problems remain, ordered by how directly each one blocks deployment in a Windows Hello-class product.

Note: 1. Deployable face / fingerprint fuzzy extractors under realistic correlated noise. Engelsma, Cao, and Jain's 2019 DeepPrint reduces intra-user fingerprint variance via learned representations [@engelsma-cao-jain-2019-arxiv], but no published construction has cleared the DRS bar on a realistic test set under correlated noise. 2. Reusable computational fuzzy extractors without idealisations. CFPRS 2016 uses digital lockers, which require either a random oracle or an equivalent strong assumption [@cfprs-2016-eurocrypt]. Eliminating that idealisation is open. 3. Post-quantum information-theoretic fuzzy extractors. Fuller-Meng-Reyzin's LWE-based construction is already post-quantum on the computational side [@fmr-2013-asiacrypt-eprint], [@fmr-2020-iandc], but an information-theoretic construction tailored to PQ-style noise distributions is open. 4. The PUF-to-biometric architectural gap. Fuzzy extractors are deployed only for PUFs (Synopsys PUF IP (including QuiddiKey), over a billion devices [@intrinsic-id-sram-puf]) where the noise model is controlled. Closing the architectural gap to consumer biometrics, where the noise model is adversarial and environmental, is open.

Each of these is hard, and none has a credible path to a consumer-OS-grade deployment in the next product cycle. Take them one at a time.

The first is the most obviously blocking. Even if every fingerprint sensor in the world tomorrow began returning DeepPrint embeddings instead of minutiae sets, the entropy budget would still be tens of bits below the DRS bar. The bottleneck is the source distribution, not the encoder. Improving the encoder helps -- a learned representation with lower intra-user variance shifts the noise distribution toward zero, which lets you use a code with less redundancy -- but the inequality still bites. The community's working belief is that no consumer fingerprint sensor will ever ship enough min-entropy to clear the bar at the security parameter an OS authenticator demands.

The second is more nuanced. Digital lockers are useful in practice -- they are the central tool that lets CFPRS 2016 handle reusability for low-entropy sources -- but they depend on the random-oracle model. The random-oracle model is fine for theoretical work; it is uncomfortable for a production cryptosystem that has to survive an FIPS evaluation and a NIST audit. The hope is that non-malleable extractors or correlation-resistant universal hash families can replace digital lockers in the CFPRS construction without losing the reusability guarantee. Promising directions exist; none has matured into a deployable construction.

The third sounds esoteric but matters. The information-theoretic DRS construction has been quietly post-quantum since 2004: the LHL holds against quantum adversaries up to a constant factor, and BCH decoding is classical [@dors-2008-siamjc]. But once you move to the computational fuzzy extractors of FMR 2013 or CFPRS 2016, the security argument depends on a hardness assumption (LWE or digital-locker-as-RO) that one wants to be confident survives the post-quantum transition. LWE is widely believed to be PQ-secure; digital lockers are not yet rigorously analysed against quantum adversaries.

The fourth, the PUF-to-biometric gap, is where the theoretical and engineering communities meet most uncomfortably. The fuzzy extractor works in practice: Synopsys PUF IP (including QuiddiKey) embeds a code-offset / syndrome-based fuzzy extractor in over a billion devices, "deployed and proven in over a billion devices certified by EMVCo, Visa, CC EAL6+, PSA, ioXt, and governments across the globe" per the vendor [@intrinsic-id-sram-puf]. The SRAM PUF has thousands of bits of min-entropy and a controlled noise model: powering up the SRAM gives a startup pattern that is reliable across temperature and voltage swings to within a few percent of bits. The signal-to-noise ratio is dramatically better than any consumer biometric.Pierre-Alain Dupont, Julia Hesse, David Pointcheval, Leonid Reyzin, and Sophia Yakoubov's 2018 EUROCRYPT paper Fuzzy Password-Authenticated Key Exchange [@dupont-hesse-pointcheval-reyzin-yakoubov-2018] is a recent direction that decouples fuzzy extraction from key agreement: rather than extract a key once and use it, two parties run a password-authenticated key exchange whose "password" is a noisy biometric. Fuzzy PAKE sidesteps the helper-data leakage problem because the helper is consumed inside an interactive protocol that does not commit it to long-term storage.

The bright line between PUF and biometric is the *noise model*. An SRAM PUF lives in a single device, sees temperature and voltage variation between $-40^\circ$C and $+85^\circ$C, and operates against an adversary who can read the SRAM but cannot rewrite the silicon. The noise distribution is empirically measurable, and the entropy budget is enormous -- thousands of bits per page. A consumer fingerprint sensor, by contrast, lives outside the trust boundary: the noise distribution depends on skin moisture, sensor cleanliness, finger angle, and an adversary who can lift a latent print from a glass. The fuzzy-extractor framework is the right answer for the PUF case and the wrong answer for the consumer biometric case, and the difference is the noise model, not the cryptography.

Each of these problems is interesting on its own merits, but none of them has a credible path to a consumer-OS-grade deployment in the next product cycle. So what does a consumer OS actually do? That is the punchline.

10. The punchline: why Windows Hello does not use a fuzzy extractor

State the claim flatly. Windows Hello, in every shipping configuration since Enhanced Sign-in Security was introduced with Windows 11, performs match-then-unwrap, not derive-from-biometric. The biometric is a gate, not an input to key derivation. The cryptographic credential a Windows Hello user authenticates with is a TPM-bound asymmetric keypair generated independently during provisioning; the biometric matcher merely decides whether to authorise the TPM to use that key. The full architecture is documented verbatim in Microsoft Learn's Enhanced Sign-in Security and Windows Hello for Business pages [@ms-learn-ess], [@ms-learn-hello-business].

10.1 Enrolment

When a Windows user enrols a face or a fingerprint, the biometric data path runs inside a Virtualisation-Based Security (VBS) trustlet, not in the kernel and not in the camera driver. Microsoft's documentation is explicit:

"When ESS is enabled, the face algorithm is protected using VBS ... The hypervisor allows the face camera to write to these memory regions providing an isolated pathway to deliver face data from the camera to the face matching algorithm" [@ms-learn-ess].

The face image never lands in regular kernel memory. It is delivered by the hypervisor into a memory region readable only by the VBS-resident face-matching trustlet, which extracts a feature template, encrypts it with VBS-only keys, and writes the encrypted blob to disk. For fingerprint, ESS supports only sensors with on-device matching: "ESS is only supported on fingerprint sensors with match on sensor capabilities" [@ms-learn-ess]. The sensor itself runs the matcher and never exposes the template to the host operating system.

A user-mode process that runs inside Virtual Trust Level 1 (VTL 1) on Windows, isolated from the normal-world kernel (VTL 0) by the Hyper-V hypervisor. Trustlets are the unit of code that the Secure Kernel hosts and that VBS-protected operations execute inside. Examples include the LSA Isolated process (Credential Guard) and the biometric matcher (Windows Hello with Enhanced Sign-in Security) [@ms-learn-ess].

In parallel, the credential the user will actually authenticate with is generated. Microsoft Learn's Windows Hello for Business page describes this verbatim: "The provisioning flow requires a second factor of authentication before it can generate a public/private key pair. The public key is registered with the IdP, mapped to the user account" [@ms-learn-hello-business]. The private key never leaves the TPM. It is sealed against a TPM policy that requires the boot integrity to be intact, the user account to be the same, and the VBS-resident biometric matcher to have signalled a match success. The keypair is a per-user, per-device, per-IdP credential; nothing about it is a function of the user's biometric.

10.2 Authentication

At authentication time, the user presents a face or a finger; the VBS-resident matcher compares the live template to the stored template; on success, the matcher signals the TPM via a secure channel to unwrap the asymmetric private key for use in an IdP challenge response. The Microsoft documentation states the architecture in two sentences:

The Windows biometric components running in VBS establish a secure channel to the TPM ... When a matching operation is a success, the biometric components in VBS use the secure channel to authorize the usage of Windows Hello keys for authenticating the user with their identity provider, applications, and services. -- Microsoft Learn, Windows Hello Enhanced Sign-in Security [@ms-learn-ess]

The authentication ceremony itself is described in the Windows Hello for Business page: "Regardless of the gesture used, authentication occurs using the private portion of the Windows Hello for Business credential. The IdP validates the user identity by mapping the user account to the public key registered during the provisioning phase" [@ms-learn-hello-business]. The IdP sees a cryptographic proof that the user-registered TPM-bound key signed the challenge; it never sees anything that depends on the biometric.

flowchart LR subgraph "DRS fuzzy extractor (theoretical)" D1["Read biometric w"] --> D2["Gen(w) -> (R, P)"] D2 --> D3["Store helper P on disk"] D2 --> D4["Use R as key"] D5["Re-read w' near w"] --> D6["Rep(w', P) -> R"] D6 --> D7["Use R as key"] end subgraph "Windows Hello (production)" W1["Read biometric w in VBS"] --> W2["Compute template T"] W2 --> W3["Encrypt and store T with VBS-only key"] W4["Generate TPM-bound keypair (sk, pk)"] --> W5["Register pk with IdP"] W4 --> W6["Seal sk to TPM with policy"] W7["Re-read w' in VBS"] --> W8["Match w' against T"] W8 --> W9["Authorise TPM unwrap via secure channel"] W6 --> W9 W9 --> W10["TPM signs IdP challenge with sk"] end

10.3 Why this is the right design

Map each architectural choice to a fuzzy-extractor limit from section 8.

The min-entropy gap is real. Face and fingerprint min-entropy under correlated real-world noise is below the DRS bar for any cryptographically meaningful key length at the security parameter an OS authenticator must hit. Section 5's inequality forbids the construction; no amount of clever engineering moves the constants. Microsoft's engineers, when faced with the choice between deriving a 128-bit key from a 40-bit source and binding the key to a TPM, made the only choice the math allows.

Helper-data leakage compounds under re-enrolment. Every time a user re-enrols (new device, sensor recalibration, post-incident credential refresh), a new helper string would be published. Simoens, Tuyls, and Preneel established that correlated code-offset helpers link and reverse [@simoens-tuyls-preneel-2009]. Hardware-anchored match-then-unwrap rotates the TPM-sealed asymmetric key under standard key-management rules instead, sidestepping the cryptographic reusability problem entirely. Key rotation under a hardware root of trust is a solved problem; reusability in a software fuzzy extractor remains an active research area.

Reusability across user-account-rebuild scenarios. PIN reset, device wipe-and-restore, and credential rotation become key-management problems (rotate the TPM-sealed key) rather than cryptographic-reusability problems (rotate the fuzzy extractor and trust the CFPRS bound). The former has thirty years of operational practice behind it; the latter has none.

Hardware-anchored attestation is easier to reason about. TPM seal-policy binding gives a hardware-anchored security argument that a relying party can verify: the trustlet measurement, the biometric-match-success signal, and the boot integrity all have to match before the key unwraps. A software-only fuzzy extractor cannot match this attestation chain. The IdP at the other end of an authentication ceremony can ask the TPM for a quote attesting that the key was used inside a specific code module on a specific device; no software construction makes that proof.

Key idea: In every shipped consumer biometric authenticator on the planet, the biometric is a gate, not an input. The cryptographic key is generated separately during provisioning -- as a TPM-bound asymmetric keypair on Windows Hello, as a Secure-Enclave-bound key on Apple Face ID, as a StrongBox-bound key on Android [@android-keystore] -- and unwrapped on match success. The key is never derived from the biometric.

10.4 The sibling case: Apple Face ID and Touch ID

Apple's Secure Enclave Processor performs the same architectural pattern, with the Secure Enclave playing the role Windows assigns to the trustlet-plus-TPM pair. The Apple Platform Security guide is explicit:

"Apple's biometric security architecture relies on a strict separation of responsibilities between the biometric sensor and the Secure Enclave, and a secure connection between the two. The sensor captures the biometric image and securely transmits it to the Secure Enclave. During enrollment, the Secure Enclave processes, encrypts, and stores the corresponding Optic ID, Face ID, and Touch ID template data. During matching, the Secure Enclave compares incoming data from the biometric sensor against the stored templates to determine whether to unlock the device or respond that a match is valid" [@apple-platform-security], [@apple-secure-enclave].

Two vendors, independently, converged on the same architecture. Both vendors hire the strongest cryptographers in the world. Neither built a fuzzy extractor. The architectural pattern is now the consensus answer to the consumer biometric authentication problem.

Apple's Secure Enclave Processor is the architectural sibling of the Windows VBS trustlet plus TPM combination. The Secure Enclave is an ARM-based coprocessor with its own kernel, its own memory, and its own boot chain, physically isolated on the Application Processor die. During Face ID or Touch ID enrolment, the biometric sensor transmits its raw image directly to the Secure Enclave over a hardware-isolated link; the Secure Enclave extracts the template, encrypts it under a per-device key sealed to the Secure Enclave's UID, and stores it. During matching, the Secure Enclave compares the live template against the stored template inside its own memory, and on success authorises the use of cryptographic keys held in the same coprocessor. The pattern is identical to the Windows Hello pattern: derive nothing from the biometric; gate a hardware-bound key on the match decision [@apple-platform-security].

Twenty years of theoretical work; zero production consumer-OS biometric authenticators on the planet use any of it for face or fingerprint key derivation; and the engineers who said no were right, for reasons traceable to a single load-bearing inequality at the heart of the 2004 EUROCRYPT paper.

11. Frequently asked questions

No. Both perform match-then-unwrap rather than derive. Windows Hello generates a TPM-bound asymmetric keypair during provisioning [@ms-learn-hello-business]; the biometric matcher, running inside a VBS trustlet, authorises the TPM to use that key on a match-success signal [@ms-learn-ess]. Apple Face ID and Touch ID follow the same pattern with a Secure-Enclave-bound key in place of a TPM-bound one [@apple-platform-security]. In neither case is the cryptographic key a function of your biometric reading. Yes -- in SRAM PUFs. Synopsys PUF IP (including QuiddiKey), built on Intrinsic ID SRAM PUF technology, is "deployed and proven in over a billion devices certified by EMVCo, Visa, CC EAL6+, PSA, ioXt, and governments across the globe" [@intrinsic-id-sram-puf]. The PUF noise distribution is controlled and the entropy budget is enormous, so the DRS construction works exactly as advertised. Consumer face and fingerprint biometrics are a different regime: the noise model is adversarial, the entropy budget is small, and the construction's inequality forbids the key length an OS authenticator needs. Because the hash is avalanche-sensitive by design: a single-bit input change flips, on average, half the output bits. Two scans of the same finger differ in many bits, so two hashes differ in roughly half their bits. The cryptographic key is statistically independent of the previous one, and the user can never log in again after their first authentication. This is the failure mode that motivates the fuzzy-extractor primitive in section 1 [@hao-anderson-daugman-2005-tr]. Because of the load-bearing inequality at the heart of the EUROCRYPT 2004 paper. For consumer face and fingerprint biometrics at the security parameter an operating system authenticator demands ($\varepsilon = 2^{-80}$ or stronger), the extractable key length is negative: the source min-entropy is too low to absorb the cost of code redundancy plus the security parameter [@dors-2008-siamjc], [@frs-2020-ieeetit]. No amount of clever engineering moves the constants. Yes. The iris is the only common biometric that comfortably clears the DRS bar. Daugman's 2003 Pattern Recognition paper reports 249 statistical degrees of freedom across 9.1 million iris-to-iris comparisons [@daugman-2003-pdf]; Hao, Anderson, and Daugman in 2006 demonstrated a 140-bit iris key with 99.5% recovery success on 70 eyes [@hao-anderson-daugman-2006-ieeetc]. But iris sensors are expensive, intrusive, and rarely shipped in consumer phones or laptops, so the result has not generalised to mainstream consumer authentication. Deep-learning encoders such as Engelsma-Cao-Jain's DeepPrint reduce intra-user variance by mapping noisy raw biometric readings into compact embeddings [@engelsma-cao-jain-2019-arxiv]. That reduces the noise the secure sketch has to absorb and lets the code use less redundancy. But the deep encoder does not add min-entropy to the source: the underlying fingerprint is still a 40-to-80-bit source. No published construction has been shown to clear the DRS bar on a realistic correlated-noise test set for any consumer biometric other than iris. Unlikely without one of two changes. Either (a) the sensor stack would have to gain entropy -- for instance, adding an iris camera to a future Surface device would put the source above the DRS bar -- or (b) a CFPRS-style reusable computational fuzzy extractor would have to mature past the digital-locker idealisation [@cfprs-2016-eurocrypt]. Even then, the operational advantages of hardware-bound asymmetric keys (TPM-anchored attestation, IdP-friendly key rotation, no helper-data leakage on re-enrolment) are large enough that a fuzzy extractor would have to clear a high bar to displace the current architecture.

The fuzzy extractor is the right primitive for the right source. SRAM PUFs are that source; consumer face and fingerprint biometrics are not. The 2004 inequality drew the line, two decades of theory have refined the line, and every shipped consumer biometric authenticator on the planet has chosen to live on the other side of it.

WebAuthn and Passkeys on Windows: From CTAP to the Credential Provider Model

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

**Password plus push-notification MFA is no longer a strong authenticator.** 2024-2026 adversary-in-the-middle phishing kits walk straight through it. WebAuthn and passkeys are strong -- but only if you score them against the right axes (phishing resistance, verifier-compromise resistance, replay/relay resistance, step-up, recovery), not the inherited know/have/are taxonomy. This article walks the five-axis criteria framework, the WebAuthn Level 3 plus CTAP 2.x protocol layer, and the Windows-specific stack: `webauthn.dll`, Windows Hello as the user-verification gesture, the Windows 11 24H2 third-party passkey provider plug-in model, hybrid transport from a phone, and the seven attestation conveyance formats. The thesis the article lands on: every passkey deployment in production is exactly as strong as the weakest path back into the account, and that path is universally weaker than the authentication ceremony itself.

1. Two factors, no security

A junior engineer at a mid-size firm types her Microsoft 365 credentials into what looks exactly like the real login.microsoftonline page, approves the push notification on her phone, and an hour later the security team is reading her inbox -- because the attacker was, too. The kit is Tycoon 2FA, the technique is reverse-proxy adversary-in-the-middle, and the marketing claim that "password plus MFA is two factors" just lost to a commodity off-the-shelf service. The same class of phishing-as-a-service kit (Evilginx, Caffeine, EvilProxy, Tycoon 2FA) is the dominant phishing toolset in 2024-2026; the kit sits between the user and the real Microsoft login page, captures the credentials and the post-MFA session cookie in flight, and hands a live session to the attacker [@sekoia-tycoon-2fa].

Replay the exact same attack against a colleague whose only authenticator is a WebAuthn passkey. The kit serves the look-alike page; the page hands the browser a WebAuthn PublicKeyCredentialRequestOptions blob with a fresh challenge. The browser builds clientDataJSON with type: "webauthn.get", the actual origin the user is on (the look-alike domain login-microsoft0nline.example, protocol scheme included), and the challenge. The authenticator computes the RP-ID hash from that origin, looks up its stored credential, and finds nothing -- it never registered a passkey for that domain. There is no signature to relay. The kit gets bytes that the real Microsoft server will reject on the first verification step. Microsoft's own documentation puts it bluntly: passkeys "use origin-bound public key cryptography, ensuring credentials can't be replayed or shared with malicious actors" [@ms-entra-passwordless].

The know/have/are taxonomy ranks these two ceremonies as the same. Password plus push is "something you know" plus "something you have," and so is password plus a passkey on a YubiKey. The taxonomy predicts that both ceremonies are roughly twice as strong as one factor alone. The phishing kit demolishes one and bounces off the other. The taxonomy is wrong.

The right question is not "how many factors did the user produce?" It is "what does the attacker have to defeat?" The know/have/are buckets group authenticators by what the user feels they are producing. The criteria framework groups them by what an attacker has to defeat. Only the second taxonomy predicts the outcome of a real-world attack. The phishing kit walks through password plus push because nothing in that ceremony binds the user's secret to a specific origin. It bounces off the passkey because the passkey signs over the origin the browser is actually on, and no amount of reverse proxying changes that string.

If the taxonomy is wrong, what is the right one? That is the question §2 answers.

2. The criteria framework: five axes that actually predict outcomes

The replacement for know/have/are is a five-row table. The rows are what an attacker has to defeat, not what the user thinks they are producing. The spine of the table is taken from NIST SP 800-63-4 (final, August 2025) [@sp80063-4-final], NIST SP 800-63B-4 [@sp80063b4-html], the FIDO Alliance Authenticator Certification Levels [@fido-certification-levels], and the IETF channel-binding lineage that runs from RFC 5056 (Williams, November 2007) [@rfc5056] through RFC 9266 (Whited, July 2022) [@rfc9266].

An authenticator whose protocol prevents a relying party impersonator (an adversary-in-the-middle) from inducing the authenticator to release a usable credential value. NIST SP 800-63B-4 formalises the requirement as *verifier-impersonation resistance*. The practitioner formulation, courtesy of Yubico, is verbatim: an authenticator is phishing-resistant if it binds its output to a communication channel or a verifier name [@yubico-nist-guidance].

Axis 1: phishing resistance

The criterion: can a look-alike domain induce the user (or the user's authenticator) to release a credential value that the look-alike then replays to the real verifier? Password plus any unbound second factor (SMS-OTP, TOTP, push) fails the criterion -- the kit just forwards every value the user produces. WebAuthn passes it by construction: the authenticator signs over clientDataJSON, which the browser fills in with the actual origin the user is on, and the signature is computed jointly over a hash of the RP identifier derived from that origin. The RP refuses any signature whose RP-ID hash does not match the registered rpId.

The mechanism by which WebAuthn enforces phishing resistance: the browser writes the user's actual origin into `clientDataJSON.origin`, the authenticator signs over the SHA-256 hash of the canonical RP identifier (`rpIdHash` in `authenticatorData`), and the relying party validates that `rpIdHash` matches the RP identifier under which the credential was registered. The cryptography is trivial. The value is in the binding.

Microsoft's Entra documentation states the criterion verbatim: passkeys "provide verifier impersonation resistance, which ensures an authenticator only releases secrets to the Relying Party (RP) the passkey was registered with and not an attacker pretending to be that RP" [@ms-entra-passwordless].

Axis 2: verifier-compromise resistance

The criterion: if the relying party's authentication database is exfiltrated, can the attacker use the stolen material to log in? Passwords fail this criterion in the worst possible way -- a salted hash is replayable after offline cracking, and a billion-row password dump is the standard primary input to credential stuffing. The public-key model passes the criterion definitionally. The relying party stores only the credential's public key; no signature is ever made by the relying party. Even a complete database leak gives the attacker zero authenticators.

This criterion is older than WebAuthn by half a century. Morris and Thompson's 1979 password paper made the verifier-compromise case for hashing passwords on a multi-user UNIX system [@morris-thompson-1979]; the WebAuthn move is the realisation that even bcrypt'd password databases lose this criterion eventually, because the work factor that protects them today is one Moore's-law decade away from being trivial.

Axis 3: replay and relay resistance

The criterion: can an attacker who observes one successful authentication replay it later, or relay it to a different verifier? OTP-based ceremonies (HOTP [@rfc4226], TOTP [@rfc6238]) provide partial replay resistance via a per-instance counter or timestamp, but they offer almost no relay resistance: the AitM kit forwards the OTP through its proxy within the OTP's validity window.

WebAuthn passes the criterion with three layered mechanisms. The first is a fresh challenge issued by the RP for every ceremony, which the authenticator signs over. The second is a per-credential signature counter included in authenticatorData, monotonically increasing on each use (the relying party rejects any assertion whose counter is not strictly greater than the previous one, modulo the synced-passkey carve-out we will reach in §7). The third is channel binding -- the structurally correct answer to relay attacks, which sits at the TLS layer rather than the application layer.The IETF Token Binding stack (RFC 8471, RFC 8473, both October 2018) [@rfc8471] [@rfc8473] was the most ambitious attempt at the channel-binding criterion at the application layer. Both RFCs remain Proposed Standard at the IETF -- the datatracker history pages record no Historic reclassification event for either [@rfc8471-history] [@rfc8473-history] -- but Chromium removed support in version 70 in October 2018, the same month the RFCs were published, and no major browser has implemented them since [@wiki-token-binding]. The clientDataJSON.tokenBinding field is therefore a no-op in 2026 production. WebAuthn solves the criterion above the channel by signing the origin into the assertion itself.

The cleaner channel-binding answer is RFC 9266 tls-exporter for TLS 1.3 (Whited, July 2022) [@rfc9266], which extends RFC 5056's channel-binding framework into the TLS 1.3 world -- but no major browser wires tls-exporter into WebAuthn out of the box as of January 2026. The current WebAuthn deployment treats the origin string in clientDataJSON as the primary channel binding, with HTTPS itself providing the underlying TLS guarantee.

Axis 4: step-up and session continuity

The criterion: can the relying party demand a fresh authentication for a high-value action (transfer money, change password, invite a user), and can it tell the difference between a session that was authenticated with strong factors and one that was authenticated with weak factors? WebAuthn answers this with two flag bits in authenticatorData. UP (user present) is set when the authenticator detected a presence test -- a touch, a click, an NFC tap. UV (user verified) is set when the authenticator additionally verified the user via PIN, biometric, or other gesture. A relying party that demands userVerification: "required" can force UV=1 on the assertion; an RP that issues a fresh challenge for a high-value action gets a fresh signature tied to that challenge.

Generic transactional confirmation -- "sign a description of this specific transaction" -- was attempted in WebAuthn's earliest drafts via the txAuthSimple and txAuthGeneric extensions [@webauthn-fpwd]. Neither extension was ever implemented by browsers, and both are absent from the Level 3 specification surface as of January 2026 [@webauthn-l3-cr-dated]. The Secure Payment Confirmation flow in WebAuthn Level 3 [@webauthn-l3-cr] is the productised replacement for payment transactions; general transactional authorisation remains an open problem.

Axis 5: recovery and lifecycle

The heretical thesis: this is the only axis that matters in production, and it is the axis on which every modern platform still bottoms out at a single-factor primitive. We will foreshadow it here and land on it in §17. A passkey ceremony that scores AAL3 phishing-resistant at the authentication moment can be a single-factor SMS-OTP at the recovery moment -- and the system's AAL is the recovery flow's AAL, not the authentication ceremony's. Microsoft's Entra documentation already flags account recovery as a load-bearing deployment cost: FIDO2 keys "can increase costs for equipment, training, and helpdesk support -- especially when users lose their physical keys and need account recovery" [@ms-entra-passwordless].

Note: The single most predictive question about an authentication system is not "what factor does the user produce at sign-in?" but "what factor produces the credential when the user has lost the original one?" We come back to this in §17.

The criteria table as a spine

The five axes give the article its spine. Every later section fills in a row of the same five-column table. The columns are the strongest authenticators we have shipped: password, password plus SMS-OTP, password plus TOTP, password plus push with number matching, device-bound FIDO2 hardware key, synced passkey, and a hypothetical "recovery-flow-aware" composite. The criteria-aware ranking (§13) re-orders that table in a way the know/have/are taxonomy cannot.

Key idea: The know/have/are taxonomy groups authenticators by what the user feels they are producing. The criteria framework groups them by what an attacker has to defeat. Only the second taxonomy predicts the outcome of a real-world attack.

If these are the right axes, when did we figure that out?

3. Where the taxonomy came from

The know/have/are taxonomy did not appear all at once. The 1970s and 1980s operating-systems literature already grouped authentication factors into "something the user knows," "something the user has," and "something the user is" -- it was a way of talking about the design space, not a regulatory criterion. The taxonomy entered U.S. federal procurement via the Department of Defense's Trusted Computer System Evaluation Criteria in December 1985 -- the Orange Book, DOD 5200.28-STD [@wiki-orange-book] -- which required identification and authentication at every assurance class above D and made passwords the canonical something you know in federal IT. The Orange Book did not invent the taxonomy; it codified it.

Two decades later, in June 2004, NIST canonised the same taxonomy as the U.S. federal regulatory framework. NIST SP 800-63 Electronic Authentication Guideline -- by William Burr, Donna Dodson, and W. Timothy Polk -- defined four assurance levels and tied each to a combination of authenticator categories that the levels could accept [@sp80063-2004-v1] [@sp80063-2004-pdf]. Burr's framework absorbed two decades of accumulated practice with hardware OTP tokens. The canonical commercial OTP product, RSA SecurID, had shipped in 1986 -- a key fob that produced a fresh code each minute using a built-in clock and a factory-encoded seed [@wiki-rsa-securid] -- and SP 800-63 explicitly accepted SecurID-class authenticators at the higher assurance levels. The four-level structure (later AAL1 through AAL3 in the post-2017 redesign) lasted through SP 800-63-1 (2011), -2 (2013), -3 (2017), and -4 (2025); every revision is recognisably the same shape [@nist-sp80063-3-final].The CSRC bibliographic page for the 2004 first edition renders the leading author as a blank entry preceded by a stray comma, an artefact of Burr's retirement from NIST after publication. The actual cover-page authorship is Burr, Dodson, and Polk -- the citation in the references list above uses the correct three-name form.

In parallel, the cryptographic protocol literature was building the criteria taxonomy that would eventually displace know/have/are. Bellcore's Neil Haller published RFC 1760 in February 1995 -- the S/KEY one-time password system, a Lamport hash chain that produced a fresh login secret each time and that an eavesdropper could not replay [@rfc1760]. Haller's text already says the technique was first suggested by Leslie Lamport, which makes 1995 the first IETF standardisation of replay-resistance as a design criterion. RFC 4226 (HOTP, December 2005) [@rfc4226] and RFC 6238 (TOTP, May 2011) [@rfc6238] generalised the same idea into the synchronised counter and time-based variants the world now calls "authenticator app" codes.

The verifier-impersonation criterion got its first IETF expression in November 2007. Nico Williams' RFC 5056 On the Use of Channel Bindings to Secure Channels defined the concept that "the two end-points of a secure channel at one network layer are the same as at a higher layer," and bound authentication at the higher layer to the channel at the lower layer [@rfc5056]. RFC 5056 was the protocol-literature acknowledgement that authentication needed to be tied to something the network attacker could not change -- the channel itself, not just the user's typing.

Kim Cameron's The Laws of Identity, published on identityblog.com in May 2005, captured the same idea from a higher-level perspective. The seven Laws are a framework for federated identity on the open Internet; Laws 2 ("minimal disclosure for a constrained use") and 4 ("directed identity") are the conceptual ancestors of WebAuthn's origin binding and per-RP key pair design [@identityblog-laws]. Cameron was Microsoft's Chief Architect of Identity through this period, and the Laws shaped a generation of Microsoft thinking on identity. The Laws preceded the consortium that would actually ship the protocol by eight years.

The criteria framework was *available* in the literature by 2007: replay resistance from S/KEY (1995), channel binding from RFC 5056 (2007), origin binding from Cameron's Laws of Identity (2005). It did not displace know/have/are in regulatory documents until NIST SP 800-63-3 in 2017 (which introduced the "phishing-resistant authenticator" term) and SP 800-63-4 in 2025 (which made verifier-impersonation resistance a first-class criterion). Why the gap? The know/have/are taxonomy is *legible to procurement* -- it produces neat checkboxes. The criteria taxonomy is *cryptographically meaningful* but produces fewer neat checkboxes. Regulation prefers checkboxes until breach data forces a change. gantt title Authentication standards lineage, 1985-2026 dateFormat YYYY axisFormat %Y section Regulatory codification Orange Book DOD 5200.28-STD :1985, 5y NIST SP 800-63 v1 :2004, 7y NIST SP 800-63-3 (phishing-resistant) :2017, 8y NIST SP 800-63-4 final :2025, 2y section Criteria origin (IETF/W3C) RFC 1760 S/KEY :1995, 10y RFC 4226 HOTP :2005, 6y RFC 5056 Channel binding :2007, 4y RFC 6238 TOTP :2011, 7y RFC 8471 Token Binding :2018, 1y RFC 9266 tls-exporter :2022, 4y section Identity literature Cameron Laws of Identity :2005, 8y section FIDO and W3C FIDO Alliance launch :2013, 1y FIDO U2F 1.0 :2014, 5y WebAuthn FPWD :2016, 3y WebAuthn L1 + CTAP 2.0 :2019, 2y WebAuthn L2 + CTAP 2.1 :2021, 1y Passkey commitment May 2022 :2022, 1y WebAuthn L3 CR :2023, 3y CTAP 2.2 PS :2025, 1y section Windows Windows 10 1903 webauthn.dll :2019, 3y Windows 11 22H2 ECC :2022, 2y Windows 11 24H2 plug-in model :2024, 2y

By 2007 the criteria framework was on paper. By 2013 there was a consortium for it: the FIDO Alliance launched on 12 February 2013 [@fido-launch-pdf], with six founding members [@wiki-fido-alliance]. Earlier identity-layer attempts -- Mozilla Persona / BrowserID, launched July 2011, with decommissioning announced January 2016 and the service shut down on 30 November 2016 [@wiki-mozilla-persona] -- had tried to build a browser-mediated identity layer at the HTTP level and failed to achieve traction. The FIDO consortium took a different bet: solve the authentication ceremony first, leave the identity-layer above it to OIDC and SAML. What happened first in a browser?

4. U2F: the first browser ceremony designed against phishing

December 2014. Yubico, Google, and NXP Semiconductors publish FIDO 1.0 / Universal 2nd Factor (U2F) [@fido-u2f-overview]; U2F 1.0 reached Proposed Standard status on 9 October 2014, with the broader FIDO 1.0 announcement window running through December [@wiki-u2f]. The Universal 2nd Factor Wikipedia article catalogues the design tradeoffs explicitly: U2F's challenge-response is "signed (encoding originating domain/website) to prevent interception and reuse" [@wiki-u2f]. This was the first time a browser ceremony was designed against the phishing-resistance criterion as a primary goal rather than as an afterthought.

The U2F ceremony has five field-level moving parts. An AppID string identifies the relying party, derived from the page's origin so a phisher's domain cannot produce a U2F signature for the real bank. A challenge is a per-ceremony nonce the relying party generates. A key handle is an opaque blob the authenticator returns at registration and supplies on every later assertion; the relying party uses it to address the right credential on the next challenge. A signature counter increments monotonically on every assertion, letting the relying party detect simple cloning. And the signature itself is an ECDSA P-256 signature over the AppID hash, the challenge, the counter, and a presence flag.

The AppID rule is the load-bearing piece. The browser computes the AppID from the actual origin the user is on; the authenticator signs over its hash; the relying party compares it to the AppID under which the credential was registered. A look-alike domain produces a different AppID, which produces a different signature, which the real verifier rejects. This is the same trick WebAuthn will later generalise as rpId binding -- and it is the trick that makes U2F structurally immune to the AitM kits that will demolish password plus push a decade later.

The canonical deployment paper is Security Keys: Practical Cryptographic Second Factors for the Modern Web, by Juan Lang, Alexei Czeskis, Dirk Balfanz, Marius Schilder, and Sampath Srinivas, in the Financial Cryptography 2016 preproceedings [@lang-fc2016-pdf]. The paper documents Google's internal rollout: a hardware second factor for every employee, replacing the company's previous OTP-based MFA. The empirical scoreboard for the criteria framework gets its first data point here -- after the rollout, Google reported zero phishing-related account takeovers on employee accounts during the deployment period. This is not a controlled study; it is the largest natural experiment in deployed phishing resistance the industry had seen.

Note: U2F is the moment the authentication community made a structural design choice: phishing resistance is a property of the protocol, not of user training. No amount of "look for the lock icon" advice closes the phishing gap; a protocol that signs over the origin closes it by construction.

U2F's limitation is that it is, by design, a second factor. The password under it remains the load-bearing weak link: a credential-stuffer can reuse the password against a service that does not require U2F, and a phisher can still capture the password even if they cannot capture the U2F signature. The AppID idea was correct; what was missing was the willingness to make the strong factor the factor, not a layer on top of a weak one. The bridge from U2F to FIDO2 is exactly that move.

The other piece U2F got right and FIDO2 inherited is the principle that the credential is device-bound by default. The U2F Wikipedia summary captures the consequence: "no recovery of the key is possible" if the device is lost [@wiki-u2f]. This is the same property that makes synced passkeys, when they arrive in May 2022, a productisation rather than a cryptographic move. The bytes are the same. The lifecycle is different.

If the second factor is doing all the work, why not make it the factor?

5. FIDO2 + CTAP 2.0 + WebAuthn Level 1: the spec lands

March 4, 2019. The World Wide Web Consortium and the FIDO Alliance announced that the Web Authentication specification was an official W3C Recommendation [@w3c-fido-press-release]; the dated Recommendation slug is REC-webauthn-1-20190304 [@webauthn-l1-rec]. Same day, with January 30, 2019 as the underlying CTAP 2.0 Proposed Standard date [@ctap-2-0-ps]. The pair is what the industry markets as FIDO2.

The reframe was decisive. A platform authenticator -- Windows Hello on Windows, Touch ID on macOS, the Android Keystore on Android -- was now a first-class FIDO authenticator. The user's laptop or phone could be the authenticator. The browser did not need a separate USB device; it could call into the OS instead. This is the move that made FIDO2 a consumer technology, not just a security-team technology.

The *relying party* is the web service that owns the user's account. The *rpId* is a string identifying that party for credential scoping; it must be a registrable suffix of the page's origin (so `login.bank.com` may use `bank.com` as its `rpId`, but `evil.com` may not). All WebAuthn signatures are made over the SHA-256 hash of the `rpId`, which the browser derives from the actual origin and writes into `clientDataJSON`. The relying party validates the signature against the public key registered for that `rpId`. Phishing resistance is `rpId` binding, full stop [@webauthn-l3-cr].

The Web IDL surface that WebAuthn Level 1 standardised is small. navigator.credentials.create({publicKey: ...}) registers a new credential; navigator.credentials.get({publicKey: ...}) produces an assertion. Both return PublicKeyCredential objects. The complexity is not in the API; it is in the byte-level structures the API exchanges.

A registration ceremony looks like this. The relying party generates a PublicKeyCredentialCreationOptions blob containing a fresh challenge, the rpId, the user's account identifier, the list of algorithms the RP supports, the desired user verification, and an optional list of credentials the user already has. The browser passes this to the authenticator and gets back two byte blobs. The first is clientDataJSON -- a UTF-8 JSON blob containing type: "webauthn.create", the origin the browser was actually on, and the challenge. The second is authenticatorData -- a binary blob containing the rpIdHash (SHA-256 of the canonical rpId), the flags byte (with UP, UV, AT, ED bits), the signature counter (initially zero, sometimes non-zero), the new credential's identifier, the AAGUID identifying the authenticator model, and the credential's public key in COSE_Key format. An optional attestation statement binds those bytes to a hardware root of trust.

A 16-byte identifier the authenticator includes in `authenticatorData` to identify its make and model. Some authenticators emit an all-zeros AAGUID for privacy. Microsoft's Entra ID hardware-vendor matrix lists dozens of FIDO2 keys with their AAGUIDs and supported transports [@ms-entra-fido2-hardware]; the FIDO Metadata Service is the authoritative directory. sequenceDiagram participant U as User participant B as Browser participant A as Authenticator participant R as Relying Party R->>B: PublicKeyCredentialCreationOptions {challenge, rpId, user, pubKeyAlgs} B->>B: build clientDataJSON {type:create, origin, challenge} B->>A: authenticatorMakeCredential(clientDataHash, rpId, user, ...) A->>U: prompt for user gesture (UV) U->>A: present gesture (PIN, fingerprint, face) A->>A: generate (pubKey, privKey) and sign attestation A->>B: clientDataJSON, authenticatorData, attestationStatement B->>R: attestationResponse {clientDataJSON, attestationObject} R->>R: verify origin, rpIdHash, signature, then store pubKey, credentialId R->>U: account created

An authentication ceremony is the same shape with one structural change: the RP supplies PublicKeyCredentialRequestOptions with a fresh challenge, the authenticator finds the credential matching the rpId, prompts the user for a gesture (if userVerification is requested), and produces an assertion -- a signature over authenticatorData || SHA-256(clientDataJSON) with the credential's private key. The relying party verifies the signature against the stored public key.

The Windows-side surface debuts in the same window. Microsoft Learn states verbatim that Microsoft "introduced the W3C/Fast IDentity Online 2 (FIDO2) Win32 WebAuthn platform APIs in Windows 10 (version 1903)" [@ms-learn-webauthn-apis]. May 2019. webauthn.dll ships. From that moment on, every browser on Windows -- Edge, Chrome, Firefox, Brave -- talks WebAuthn through one Win32 surface. The Microsoft Learn passkey overview makes the underlying architecture explicit: "When these APIs are in use, Windows 10 browsers or applications don't have direct access to the FIDO2 transports for FIDO-related messaging" [@ms-learn-webauthn-apis]. The OS is the dispatcher.

The W3C/FIDO press release named the launch implementations: Windows 10, Android, Chrome, Firefox, Edge, and Safari (in preview) [@w3c-fido-press-release]. Microsoft, Google, Mozilla, and Apple all shipped within the same year. WebAuthn became the most-implemented strong-authentication standard on the consumer web inside eighteen months.

{` // A reader can paste in their own clientDataJSON and authenticatorData // (base64url-encoded as Microsoft returns them) to see how the parser // walks the bytes. Origin binding is one SHA-256 invocation away from // being a one-liner; the value is in the binding, not the cryptography.

const clientDataB64 = "eyJ0eXBlIjoid2ViYXV0aG4uZ2V0Iiwib3JpZ2luIjoiaHR0cHM6Ly9sb2dpbi5taWNyb3NvZnRvbmxpbmUuY29tIiwiY2hhbGxlbmdlIjoiUk5KU2V6NjFqdyJ9"; const authDataB64 = "Y9JZsAcVeQOLgxs9Ux7QYZpyTaB-OkpdyPwQk7P9YsoFAAAAFw";

function b64urlDecode(s) { s = s.replace(/-/g,'+').replace(/_/g,'/'); while (s.length % 4) s += '='; return Uint8Array.from(atob(s), c => c.charCodeAt(0)); }

const clientDataBytes = b64urlDecode(clientDataB64); const clientData = JSON.parse(new TextDecoder().decode(clientDataBytes)); console.log("clientDataJSON.type =", clientData.type); console.log("clientDataJSON.origin =", clientData.origin); console.log("clientDataJSON.challenge=", clientData.challenge);

const authData = b64urlDecode(authDataB64); const rpIdHash = authData.slice(0, 32); const flags = authData[32]; const signCount = (authData[33]<<24) | (authData[34]<<16) | (authData[35]<<8) | authData[36]; console.log("authenticatorData rpIdHash =", Array.from(rpIdHash).map(b=>b.toString(16).padStart(2,'0')).join('')); console.log("authenticatorData flags = 0x" + flags.toString(16), "UP="+(flags&1), "UV="+((flags>>2)&1), "BE="+((flags>>3)&1), "BS="+((flags>>4)&1), "AT="+((flags>>6)&1)); console.log("authenticatorData signCount=", signCount); `}

The credential's public key is encoded as a COSE_Key map -- a CBOR object whose algorithm identifier is one of the entries in the IANA COSE Algorithms registry [@iana-cose-registry]. As of the registry's 2026-03-04 update, no post-quantum algorithm is in WebAuthn-recommended status; ECDSA P-256 and EdDSA Ed25519 remain the workhorses. The companion Post-Quantum Cryptography on Windows article walks the algorithm-side rollout.

Level 1 settled the field-level shape. What did the next two years sharpen?

6. CTAP 2.1: the wire protocol every security key is speaking

15 June 2021. The FIDO Alliance published CTAP 2.1 as a Proposed Standard [@ctap-2-1-ps]. CTAP 2.1 is the CBOR-on-the-wire version most security keys in 2024-2026 are running; CTAP 2.2 (Proposed Standard, 14 July 2025) [@ctap-2-2-ps] refines a few corners, and CTAP 2.3 is the Proposed Standard the FIDO Alliance lists alongside it [@fido-specs-download]. Each version adds capability without breaking the previous one's commands.

The Client-to-Authenticator Protocol -- the wire format the browser speaks to a roaming authenticator over USB-HID, NFC, or BLE. CTAP1 (the original U2F messages) carries APDU-style binary structures; CTAP2 carries CBOR-encoded commands. A *CTAP2 authenticator* (also called a FIDO2 or WebAuthn authenticator) implements the CTAP2 command set; modern keys also implement CTAP1 for backwards compatibility [@ctap-2-0-ps].

The CTAP2 command-byte table is the surface a browser actually dispatches to. Each command is a single byte followed by a CBOR-encoded request map. The table below names the commands in order and the criterion-table cell each one strengthens.

Command byte	Command name	What it does	Criterion strengthened
0x01	`authenticatorMakeCredential`	Registration: generate a fresh keypair bound to `(rpId, user.id)`	Phishing resistance (origin binding)
0x02	`authenticatorGetAssertion`	Authentication: sign the challenge with the credential's private key	Phishing + replay + verifier-compromise
0x04	`authenticatorGetInfo`	Capability discovery: list supported algorithms, extensions, transports, `UV` modes	Step-up (lets RP know what's available)
0x06	`authenticatorClientPIN`	Manage the PIN, issue `pinUvAuthToken` with permissions bitmap and `rpId` scoping	Step-up + replay
0x07	`authenticatorReset`	Wipe all resident credentials on the device	Lifecycle
0x09	`authenticatorBioEnrollment`	On-token fingerprint enrolment (CTAP 2.1)	Step-up (`UV=1`)
0x0A	`authenticatorCredentialManagement`	List, enumerate, and delete resident credentials per RP	Lifecycle / recovery
0x0B	`authenticatorSelection`	"Pick this device" prompt when multiple authenticators are present	UX (no criterion change)
0x0C	`authenticatorLargeBlobs`	Per-credential blob store under the credential	Step-up (extension data)
0x0D	`authenticatorConfig`	Enable enterprise attestation, toggle `alwaysUv`, set minimum PIN length	Verifier-compromise + lifecycle

Three pieces of CTAP 2.1 are worth pulling out because they meaningfully change the criteria-table cells.

pinUvAuthToken and permissions. CTAP 2.0's PIN-protocol let the browser obtain a pinAuthToken and use it across any command. CTAP 2.1 introduced a permissions bitmap and rpId scoping on the token so that a token issued for one relying party's ceremony cannot be replayed against a different relying party's ceremony on the same authenticator [@ctap-2-1-ps]. This closes a class of host-side mischief: an attacker who got the PIN out of one ceremony could not previously be stopped from spending it on a different rpId.

credProtect. A new extension that lets the RP request a higher protection level on the resident credential -- specifically, that the authenticator should refuse to list the credential without a UV=1 gesture. The first generation of WebAuthn discoverable credentials were enumerable by any host that could speak CTAP2 to the connected key; credProtect lets the RP say "don't show this credential's existence to anything that doesn't pass user verification first."

Enterprise attestation. CTAP 2.1 added an explicit enterprise attestation mode in which the authenticator binds its attestation statement to a list of relying parties the device's enrolling organisation has pre-approved. This is the bridge that makes vendor attestation useful in managed enterprises without leaking the user's specific device identity to every relying party.The largeBlob extension (CTAP 2.1, command 0x0C) gives each credential a small per-credential blob store. RPs use it for things like cached short-lived tokens or per-user policy. The 2024 release notes for the Windows webauthn.dll API surface flagged largeBlob support as one of the additions in Windows 11 22H2 [@ms-learn-webauthn-apis]; a March 2023 Review Draft [@ctap-2-2-rd] foreshadowed the 2.2 refinements that landed in July 2025.

All of this is for experts. When did this stop being a security-team conversation and start being a consumer product? What changed in May 2022?

7. Passkeys: the productisation moment

5 May 2022. Apple, Google, and Microsoft jointly committed at the FIDO Alliance to a common passwordless sign-in standard [@fido-aav-passkey-commitment]. The press release is short on protocol detail and long on user-facing language. The headline commitment, verbatim: "Allow users to automatically access their FIDO sign-in credentials (referred to by some as a 'passkey') on many of their devices, even new ones, without having to reenroll every account" [@fido-aav-passkey-commitment]. Passkey entered the public lexicon. Andrew Shikiar, the FIDO Alliance's executive director and CMO at the time, named it in the press call.

Allow users to automatically access their FIDO sign-in credentials (referred to by some as a 'passkey') on many of their devices, even new ones, without having to reenroll every account. -- Apple, Google, and Microsoft, joint FIDO Alliance announcement, 5 May 2022 [@fido-aav-passkey-commitment]

The cryptographic move in May 2022 was small. The protocol bytes are the same FIDO2 / WebAuthn / CTAP2 bytes that shipped in March 2019. What changed was twofold: (a) the three platform vendors aligned their sync fabrics so that a passkey created on a user's phone would appear on the user's laptop, and (b) the user-facing terminology consolidated from a confusing menagerie ("discoverable credential," "resident key," "client-side discoverable credential") onto a single product term -- passkey.

A WebAuthn credential whose `user.id` and account metadata are stored *on the authenticator*, so the authenticator can produce an assertion without the relying party first supplying a credential identifier. The CTAP 2.0 spec calls these *resident keys* [@ctap-2-0-ps]; the WebAuthn Level 2 spec calls them *client-side discoverable credentials* [@webauthn-l2-latest]; the May 2022 vendor commitment rebranded them as *passkeys* [@fido-aav-passkey-commitment]. All three terms refer to the same on-the-wire object.

Discoverable credentials unlock usernameless sign-in. The relying party does not need to tell the authenticator which credential to use; the authenticator looks up its own resident credentials for the supplied rpId, shows the user the matching account, and asks for the user-verification gesture. This is the UX primitive every consumer-passkey flow leans on.

WebAuthn Level 3 (W3C Candidate Recommendation, latest snapshot dated 13 January 2026 [@webauthn-l3-cr] [@webauthn-l3-cr-dated]) is the spec generation that productises passkeys. Level 3 standardises:

The hybrid transport (formerly known as caBLE), §6.3.3 of the L3 spec, which lets a phone act as a roaming authenticator for a nearby laptop via QR code plus ephemeral ECDH plus BLE proximity. We cover hybrid in §12.
JSON-serialisation helpers -- PublicKeyCredentialCreationOptionsJSON and PublicKeyCredentialRequestOptionsJSON -- that make WebAuthn easier to drive from a server SDK without manual base64url juggling.
getClientCapabilities() so the relying party can probe what the client supports before issuing the ceremony.
The credProps, prf, largeBlob, credProtect, and Secure Payment Confirmation extensions, each of which sharpens one cell of the criteria table.

The mid-2025 cadence picked up: CTAP 2.2 Proposed Standard on 14 July 2025 [@ctap-2-2-ps] refined hybrid-transport semantics and tightened credProtect.

The synced-vs-bound distinction is the structural new thing about passkeys. Before May 2022 a FIDO2 credential lived in one secure element; lose the YubiKey, lose the credential. Synced passkeys put the private key into a sync fabric -- Apple iCloud Keychain (originally 2013) [@wiki-icloud], Google Password Manager (Chrome password sync, late 2000s onward), Microsoft Authenticator (originally 2015) [@wiki-ms-authenticator], and Microsoft Account passkey sync (general availability for consumer accounts on 2 May 2024) [@ms-security-passkeys-consumer] -- and let it appear on every device the user signs into. The mechanism is end-to-end encryption against a sync-fabric key that the platform vendor cannot read; Apple's Advanced Data Protection model is the strongest current public realisation [@apple-adp-kb].

The price: the long-term private key has left the original authenticator. NIST is unambiguous about the consequence. The April 2024 supplement Incorporating Syncable Authenticators into NIST SP 800-63B [@sp80063sup1] -- since absorbed into NIST SP 800-63B-4 final, July 2025 [@sp80063b4-html] -- classifies synced passkeys at AAL2, not AAL3, because the key is no longer pinned to a single tamper-resistant element. Yubico's commentary captures the dichotomy verbatim: "FIDO passkeys that are not synced -- device-bound passkeys like YubiKeys -- and are properly stored in dedicated hardware have an AAL3 rating" [@yubico-nist-guidance].

The WebAuthn spec made the distinction observable. Two new flag bits in authenticatorData -- BE (Backup Eligible) and BS (Backup State) -- tell the relying party whether the credential is in principle syncable (BE=1) and whether it is currently backed up (BS=1) [@webauthn-l3-cr]. The RP can decide policy from those flags: a banking RP can require BE=0 (device-bound) credentials for AAL3 transactions, while accepting BS=1 (synced) credentials for AAL2 sign-in.

Microsoft's own numbers tell the productisation story in raw counts. The May 2024 Microsoft Security blog announcing passkey support for consumer accounts notes that Microsoft was "detecting around 115 password attacks per second" when Windows Hello first shipped in 2015; "less than a decade later, that number has surged 3,378% to more than 4,000 password attacks per second" [@ms-security-passkeys-consumer]. The 1 May 2025 World Passkey Day post escalates again: "we observed a staggering 7,000 password attacks per second (more than double the rate from 2023). [...] now we see nearly a million passkeys registered every day." It also reports that "passkey sign-ins are eight times faster than a password and multifactor authentication," and that "more than 99% of people who sign into their Windows devices with their Microsoft account do so using Windows Hello" [@ms-security-world-passkey-day].

Key idea: Passkeys are not a new cryptographic primitive. They are a productisation moment in which discoverable credentials became consumer-grade UX. The protocol moves were two years earlier; the product move is what changed the criteria-table scoreboard.

Passkeys are a productisation moment. On Windows specifically, what does the platform actually do between navigator.credentials.create and the TPM?

8. The Windows platform authenticator: `webauthn.dll` end-to-end

May 2019. Windows 10 version 1903. The Win32 platform WebAuthn API shipped, and from that moment on every browser and every native application on Windows that wants to do WebAuthn calls webauthn.dll. The header file webauthn.h is in the Windows SDK and is also published on GitHub at github.com/microsoft/webauthn [@github-ms-webauthn]. The reference page on Microsoft Learn enumerates every function the API surfaces [@ms-learn-win32-webauthn]. The 1903 ship date and the subsequent feature additions are documented verbatim by Microsoft Learn: "Microsoft has long been a proponent of passwordless authentication, and has introduced the W3C/Fast IDentity Online 2 (FIDO2) Win32 WebAuthn platform APIs in Windows 10 (version 1903). Starting in Windows 11, version 22H2, WebAuthn APIs support ECC algorithms and starting in Windows 11 version 24H2 WebAuthn APIs support plugin passkey managers" [@ms-learn-webauthn-apis].

When these APIs are in use, Windows 10 browsers or applications don't have direct access to the FIDO2 transports for FIDO-related messaging. -- Microsoft Learn, *WebAuthn APIs for password-less authentication on Windows* [@ms-learn-webauthn-apis]

That sentence is the entire architectural premise. The OS dispatches FIDO2 ceremonies. The browser does not own the CTAP2 stack, the USB-HID transport, the NFC reader, the BLE pairing, or the Hello UV gesture. It hands webauthn.dll a request and gets back an assertion.

The API surface is a small set of functions. The ceremony surface is two functions, the management surface is the remainder.

WebAuthNAuthenticatorMakeCredential -- the registration entry point. Caller supplies origin / rpId / user / algorithms / attestation preference / authenticator-selection criteria. Returns an attestation object.
WebAuthNAuthenticatorGetAssertion -- the authentication entry point. Caller supplies origin / rpId / allowed credential IDs (or empty for usernameless) / user-verification preference / mediation (Conditional UI, see §9). Returns an assertion.
WebAuthNGetApiVersionNumber -- a monotonically increasing integer that lets callers feature-detect. Version 1 is Windows 10 1903; versions step up as Windows adds ECC algorithms (22H2), the plugin model (24H2), and the EXPERIMENTAL_*2 surface (Insider builds via KB5072046 [@github-ms-webauthn]).
WebAuthNGetCancellationId / WebAuthNCancelCurrentOperation -- cooperative cancellation; the browser asks webauthn.dll to drop the active ceremony.
WebAuthNGetPlatformCredentialList / WebAuthNDeletePlatformCredential -- resident-credential management for synced passkeys held by the OS provider.
WebAuthNIsUserVerifyingPlatformAuthenticatorAvailable -- the isUVPAA capability probe; the RP uses this to decide whether to offer a passkey enrolment flow at all.
WebAuthNFreeAssertion / WebAuthNFreeCredentialAttestation / WebAuthNFreePlatformCredentialList -- caller-side memory release; the OS allocates on the heap and the caller is responsible for Free.
WebAuthNGetErrorName / WebAuthNGetW3CExceptionDOMError -- translate the Win32 HRESULT into a WebAuthn-spec error string.

flowchart TD A[Browser or native app] --> B[webauthn.dll: WebAuthNAuthenticatorMakeCredential] B --> C[Windows Hello UI: prompt for PIN, fingerprint, or face] C --> D[Windows Hello / Hello for Business: verify gesture] D --> E[CNG NCRYPT: keypair generation request] E --> F[TPM 2.0: generate keypair inside the TPM] F --> G[TPM 2.0: TPM2_Certify over the new credential public key] G --> H[webauthn.dll: build attestation object with packed or tpm format] H --> B B --> A A --> I[Relying party: verify attestation, store credential public key]

The criteria-framework consequence of that call graph is that the private key never leaves the TPM. Microsoft Learn states the property verbatim: "The private keys can only be used after they're unlocked by the user using the Windows Hello unlock factor (biometrics or PIN)" [@ms-learn-passkeys]. The TPM enforces use through its own access-control rules; even kernel malware on the host cannot exfiltrate the raw private key, only request operations gated on the user's gesture. This is what gets a Windows-platform-bound passkey on a TPM to AAL3 even when synced passkeys are bounded at AAL2.

The API version sentinel tells a clean feature-evolution story.

Windows release	API version (approx.)	Notable additions
Windows 10 1903 (May 2019)	v1	Initial Win32 surface: make/get credential, isUVPAA
Windows 10 1909 / 20H1	v2	UV preference, signal-handling refinements
Windows 11 21H2 (Oct 2021)	v3	Hybrid transport (caBLE) entrypoints
Windows 11 22H2 (Sep 2022)	v4-v5	ECC algorithms (ECDSA P-256 platform credentials), Conditional UI mediation
Windows 11 23H2 (Oct 2023)	v6	largeBlob, credProps, refined cancellation
Windows 11 24H2 (Oct 2024)	v7	Plug-in passkey managers (`WebAuthNPlugin*`), redesigned Hello UX
Insider builds (KB5072046)	v7+	EXPERIMENTAL_WebAuthNPluginAddAuthenticator2, EXPERIMENTAL_WebAuthNPluginPerformUserVerification2, EXPERIMENTAL_WebAuthNPluginUpdateAuthenticatorDetails2 [@github-ms-webauthn]

The three EXPERIMENTAL_*2 APIs in github.com/microsoft/webauthn are Insider-only and will lose the EXPERIMENTAL_ prefix as they stabilise. The naming convention is the standard Windows SDK signal for "we want feedback before this becomes load-bearing public API."

Note: On Windows, do not roll your own CTAP2 stack. webauthn.dll handles USB-HID, NFC, BLE, hybrid transport, Conditional UI, plug-in dispatch, and Windows Hello user verification in a single call. The Win32 reference at learn.microsoft.com/en-us/windows/win32/api/webauthn/ is the source of truth, the header file is at github.com/microsoft/webauthn, and the YubiKey 5 series [@yubikey5-overview] plus the Entra-listed FIDO2 vendors [@ms-entra-fido2-hardware] are the supported keys.

The criterion-table consequence of dispatching FIDO2 through one OS surface is that every browser is automatically as strong as the OS. Edge does not need its own attestation logic; neither does Chrome, Firefox, or Brave. They all call the same webauthn.dll, which routes the registration to the TPM (for platform-bound passkeys), to USB-HID (for roaming security keys), or to a plug-in (for Windows 11 24H2 third-party providers, §10).

The webauthn.dll surface answers one half of the question. The other half is: what does the user actually see?

{` // Origin binding is computationally trivial. The value is in the binding, // not the cryptography. This snippet computes SHA-256 of an origin's // effective rpId and compares against the rpIdHash a real authenticator // would have signed. Paste in a clientDataJSON.origin and the // authenticatorData.rpIdHash from the earlier snippet to verify.

async function rpIdHash(rpId) { const enc = new TextEncoder().encode(rpId); const hash = await crypto.subtle.digest("SHA-256", enc); return Array.from(new Uint8Array(hash)).map(b => b.toString(16).padStart(2,'0')).join(''); }

(async () => { const goodOrigin = "login.microsoftonline.example"; const badOrigin = "login-microsoft0nline.example"; const goodRpId = "login.microsoftonline.example"; const badRpId = "login-microsoft0nline.example"; console.log("rpIdHash(", goodRpId, ") =", await rpIdHash(goodRpId)); console.log("rpIdHash(", badRpId, ") =", await rpIdHash(badRpId)); // The two hashes differ in every byte. A passkey registered against // login.microsoftonline.example cannot be induced to sign for the look-alike // because the authenticator computes the second hash from clientDataJSON.origin // and refuses to use the credential bound to the first one.

// Replay resistance illustration: a signCount of 0x10 followed by 0x0F // is illegal (counter regressed). RPs reject this for BS=0 credentials. const oldCount = 0x10, newCount = 0x0F; console.log("signCount regression (BS=0)?", newCount <= oldCount ? "REJECT" : "ACCEPT"); })(); `}

9. Conditional UI: passkey autofill that looks like password autofill

The bridge between users' password-trained mental model and the new asymmetric-crypto reality is a UX primitive called Conditional Mediation -- the spec name -- or Conditional UI in informal use. The relying party renders a normal-looking username field. The browser sees that the page has called navigator.credentials.get({mediation: "conditional", publicKey: {...}}) and quietly offers the user's passkey as one of the autofill suggestions, alongside whatever the user has typed and whatever the password manager remembers. The user clicks the passkey suggestion, completes a Windows Hello gesture, and they are signed in. No popup. No modal. No "do you want to use a passkey?" dialog.

A WebAuthn invocation mode in which the browser offers the user's discoverable credentials *inside* the same autofill UI it uses for saved passwords, rather than via a modal credential picker. The relying party calls `navigator.credentials.get({mediation: "conditional", publicKey: {...}})`; the browser silently consults the platform authenticator (and, on Windows 11 24H2, the plug-in passkey providers) for credentials matching the `rpId`. The capability is probed via `PublicKeyCredential.isConditionalMediationAvailable()` [@webauthn-l3-cr].

The canonical engineer-perspective walkthrough is Adam Langley's Passkeys post on imperialviolet.org, dated 22 September 2022 [@imperialviolet-passkeys]. Langley walks the flag-page invocation needed on early Chrome Canary builds -- chrome://flags#webauthn-conditional-ui -- and the capability surface: isUserVerifyingPlatformAuthenticatorAvailable() to decide whether to offer enrolment, isConditionalMediationAvailable() to decide whether to render the autofill hint at all. The post is the first time most working engineers saw what passkeys would actually look like at the page level.

On Windows the browser calls WebAuthNAuthenticatorGetAssertion with the Conditional mediation flag set; webauthn.dll consults its resident credential store, finds passkeys matching the rpId, and surfaces a small in-line affordance for each. The full-screen Windows Hello modal becomes a small in-place gesture acquisition. From the user's perspective the password-manager metaphor is unchanged; from the cryptography's perspective the work product is a public-key signature over an origin-bound challenge.

The L3 spec section 5.1.4 is the normative reference for the mediation modes [@webauthn-l3-cr]. The four modes are: silent (no user interaction), optional (browser decides), conditional (autofill), and required (modal). Conditional is the one that makes passkeys feel like passwords -- and that is precisely why it took the consumer-passkey rollout off the security-team conversation and into product reviews.

The Microsoft Learn passkey overview ties the UX to the Windows ship vehicle: "Starting in Windows 11, version 22H2 with KB5030310, Windows provides a native experience for passkey management" [@ms-learn-passkeys]. The Settings -> Accounts -> Passkeys page is the management UI; Conditional Mediation surfaces those passkeys at sign-in time. The passkeys.dev developer directory [@passkeys-dev] is the FIDO Alliance's collected resource for relying parties implementing the flow.

The UX implication is the one Adam Langley underlined in the September 2022 post: the password-autofill metaphor is the load-bearing UX primitive that makes passkeys consumer-ready. The cryptography was solved in 2014. The UX took eight more years.

But what if the user's passkey lives in 1Password or Bitwarden, not in Windows itself?

10. The Windows 11 24H2 third-party passkey provider model

8 October 2024. Microsoft published the Windows Developer Blog post Passkeys on Windows: authenticate seamlessly with passkey providers [@ms-windev-passkeys-blog] as a pre-conference announcement ahead of the FIDO Alliance's Authenticate 2024 conference (14-16 October 2024 in Carlsbad, California). The post announced three deliverables: "1. A plug-in model for third-party passkey providers. 2. Enhanced native UX for passkeys. 3. A Microsoft synced passkey provider." 1Password and Bitwarden were the named launch partners; Dashlane joined the roster shortly thereafter. The post says verbatim: "Microsoft is partnering closely with 1Password, Bitwarden and others on integrating this capability" [@ms-windev-passkeys-blog].

The plug-in model is the first OS-level passkey-provider API on a major desktop platform. macOS Sonoma and iOS 17 had shipped a parallel design (ASCredentialIdentityStore plus ASCredentialProviderExtension) [@apple-ascredentialprovider]; Android 14 had added Credential Manager support [@android-credman]; Windows 11 24H2 is the desktop OS that matches the mobile platforms. The mechanism is a COM interface called IPluginAuthenticator, declared in pluginauthenticator.idl [@github-ms-webauthn]. A passkey-manager vendor ships a packaged Windows app that registers a COM object implementing the interface, supplies an AAGUID and a friendly name, and lets the OS dispatch ceremonies to it.

The Plugin API surface is six functions on the OS side and one COM interface on the vendor side. From webauthnplugin.h and the Microsoft Learn reference [@ms-learn-webauthn-apis]:

WebAuthNPluginAddAuthenticator -- register the plug-in with the OS. The vendor app calls this on first run.
WebAuthNPluginAuthenticatorAddCredentials -- supply the OS with the credentials the plug-in currently has, so the OS can render them in pickers.
WebAuthNPluginAuthenticatorRemoveCredentials -- the inverse; remove credentials the plug-in no longer holds.
WebAuthNPluginPerformUserVerification -- request Windows Hello UV on behalf of the plug-in. The plug-in does not take the UV gesture itself; Windows Hello does, so the gesture-to-credential trust path is OS-mediated.
WebAuthNPluginRemoveAuthenticator -- the vendor's uninstall path.
WebAuthNPluginGetAuthenticatorList -- enumerate which plug-ins the OS knows about.

Three additional EXPERIMENTAL_*2 functions ship in Insider build KB5072046 and refine the registration, UV, and update flows. The list, verbatim from the github.com/microsoft/webauthn README: EXPERIMENTAL_WebAuthNPluginAddAuthenticator2, EXPERIMENTAL_WebAuthNPluginPerformUserVerification2, EXPERIMENTAL_WebAuthNPluginUpdateAuthenticatorDetails2 [@github-ms-webauthn].

The Microsoft-authored reference implementation is the Contoso Passkey Manager sample in microsoft/Windows-classic-samples [@github-ms-passkey-sample]. The sample's build manifest is explicit: "Windows SDK version 10.0.26100.7175 or higher. Operating system requirements: Windows 11 version 25H2. Build Major Version = 26200 and Minor Version >= 6725. Windows 11 version 24H2. Build Major Version = 26100 and Minor Version >= 6725" [@github-ms-passkey-sample]. The Microsoft Learn tutorial Third-party passkey providers on Windows walks the same sample step by step [@ms-learn-thirdparty].

Note: The Microsoft Learn third-party tutorial carries an explicit disclaimer: "Contoso Passkey Manager is designed for passkey creation and usage testing only. Don't use the app for production passkeys" [@ms-learn-thirdparty]. The sample illustrates the COM contract; it does not replace a vetted vendor's credential vault.

flowchart TD A[Browser or native app] --> B[webauthn.dll] B --> C{"Provider picker"} C -->|Windows Hello / platform| D[CNG + TPM 2.0] C -->|Roaming hardware| E[USB-HID / NFC / BLE] C -->|Third-party plug-in| F[COM: IPluginAuthenticator] F --> G[1Password / Bitwarden / Dashlane vault] F --> H[WebAuthNPluginPerformUserVerification] H --> I[Windows Hello UI] I --> H G --> F F --> B B --> A

The user-facing flow follows the same logic as the macOS / iOS / Android equivalents. The user installs 1Password or Bitwarden from the Microsoft Store. The vendor app calls WebAuthNPluginAddAuthenticator on first launch. The user enables the provider in Settings -> Accounts -> Passkeys -> Advanced options [@ms-windev-passkeys-blog]. From that point on, when any browser or native app on Windows starts a WebAuthn ceremony, webauthn.dll presents the user with a picker -- "use a passkey from Windows Hello, from 1Password, from Bitwarden, from a hardware security key, or from your phone" -- and routes the ceremony to the selected provider. The plug-in itself returns an attestation object and an assertion; Windows Hello handles user verification on the plug-in's behalf via WebAuthNPluginPerformUserVerification. The Windows trust boundary still owns the gesture acquisition.

The plug-in model adds credential-store choice; it does not change the lock-screen credential. The plug-in cannot replace Windows Hello at the lock screen; lock-screen sign-in remains the platform authenticator. The plug-in cannot proxy domain credentials -- Kerberos and NTLM are unaffected. The plug-in is *not* a replacement for the legacy `CredMan` (Credential Manager) generic-credential surface; that surface is still where Windows applications stash Basic-Auth-style credentials. The plug-in model is, specifically, a WebAuthn credential store. Everything else stays where it was.

The criterion-table consequence is mixed. The plug-in model strengthens user choice and recovery, because a user with an existing 1Password / Bitwarden vault can reuse the recovery primitives they already know. It weakens verifier-compromise resistance relative to a pure platform-bound passkey, because the long-term key now lives in the vendor's vault rather than the TPM -- and the vendor's vault becomes another point of compromise. It does not change phishing resistance, replay resistance, or step-up, because those are properties of the WebAuthn ceremony and the plug-in still produces a WebAuthn-shaped assertion.

What 1Password, Bitwarden, and Dashlane each ship in their plug-in implementations follows the same template: registration requests get either a packed attestation statement (for vendor-signed batch attestation keys) or a none attestation (most consumer flows), and authentication assertions come back the same shape as any other WebAuthn assertion. The plug-in itself decides whether the credential is BE=1, BS=1 (synced in the vendor's cloud) or BE=0, BS=0 (device-bound to the local install).

A plug-in supplies the credential. But the attestation statement on registration tells the relying party what kind of credential it is. That's a separate API surface -- what shapes does it come in?

11. The seven attestation conveyance formats

The IANA WebAuthn registry lists seven format identifiers for the attestation statement a registration ceremony can produce [@iana-webauthn-registry]. The registry is reachable via RFC 8809 (Hodges, Mandyam, M.B. Jones, August 2020) [@rfc8809] and the canonical normative definitions are in WebAuthn Level 2 §§8.2-8.8 [@webauthn-l2-latest], whose dated Recommendation is at REC-webauthn-2-20210408 [@webauthn-l2-rec]. The seven, in registry order: packed, tpm, android-key, android-safetynet, fido-u2f, apple, and none. Each is one option a relying party can require, accept, or ignore.

The mechanism by which a WebAuthn registration ceremony optionally produces a signature over the new credential's public key (and `authenticatorData` containing the `rpIdHash`), chained to a vendor or platform root. The relying party validates the chain to establish that the new credential's private key is held by a specific authenticator model or certification level. Attestation is distinct from authentication; attestation runs once at registration, authentication runs every sign-in. The WebAuthn `attestation` parameter on registration controls whether the RP asks for an attestation statement at all (values: `none`, `indirect`, `direct`, `enterprise`).

The table below summarises what each format teaches the relying party.

Format	What the RP verifies	Trust anchor required	Criterion strengthened	Current adoption
`packed`	Signature over `authenticatorData \|\| clientDataHash` by batch attestation key or self-attestation key	Vendor X.509 cert chain or none (self)	Verifier-compromise (model identity), optional anti-fraud	Default for most CTAP2 keys; dominant in production
`tpm`	TPM 2.0 `TPM2_Certify`-style quote over the new credential public key	AIK / EK chain to TPM vendor root	Verifier-compromise + device-bound storage	Windows platform-bound passkeys
`android-key`	Android Keystore attestation chain	Google-rooted hardware-attestation CA	Verifier-compromise + StrongBox / TEE residency	Android platform passkeys
`android-safetynet`	SafetyNet API-derived attestation token	Google SafetyNet CA	Legacy; declining	Legacy Android; SafetyNet deprecation announced June 2022; migration deadline end of January 2024; complete shutdown end of January 2025
`fido-u2f`	ECDSA P-256 signature with vendor X.509 cert	Vendor U2F-era cert	Verifier-compromise (legacy)	Legacy U2F-era hardware keys; declining
`apple`	Anonymous Apple-issued attestation chain	Apple anonymous-attestation CA	Verifier-compromise without device de-anonymisation	Apple platform passkeys
`none`	No attestation; credential public key plus AAGUID only	None	None	The default for synced-passkey consumer flows

A few of these deserve a paragraph each.

packed is the spec default and the most widely deployed. The authenticator emits one signature over the concatenation of authenticatorData and a hash of clientDataJSON, using one of three keys: (a) a per-authenticator-model batch attestation key whose X.509 chain anchors to the vendor's attestation root (the privacy-vs-anti-fraud trade-off -- the cert reveals the device model, but not which specific user owns which device); (b) an Anonymisation CA or Enterprise Attestation key, which lets a managed enterprise distinguish its own devices without leaking that information to consumer relying parties; or (c) a self-attestation key derived from the credential itself, which proves only that the private key signs and makes no identity claim.

tpm is the format the Windows platform authenticator emits when the user has a TPM 2.0. The signing object is a TPM TPM2_Quote-style structure with the TPM's Attestation Identity Key (AIK), chained back to the TPM vendor's Endorsement Key (EK) root certificate. This is the most cryptographically opinionated attestation in the registry: it proves the credential is held by a specific TPM vendor's part. The Windows TPM article in this series walks the AIK / EK chain end to end.

apple is Apple's anonymous-attestation design. The X.509 chain ends in an Apple anonymous-attestation CA; cryptographically the relying party can verify the cert chain back to Apple's root, but the cert itself is engineered to not reveal the user's specific device. This is the privacy-vs-anti-fraud trade-off resolved in favour of privacy: a relying party gets "this came from a real Apple device" without learning which Apple device.

android-safetynet is the legacy format that lots of installed-base Android passkeys still use. Google announced the SafetyNet Attestation API's deprecation in June 2022 in favour of Play Integrity; the migration deadline was extended to end of January 2024, with complete shutdown landing end of January 2025 [@android-safetynet-deprecation]. Any new Android passkey registered in 2025 or later uses android-key or none instead. Relying parties with old android-safetynet credentials in their database must accept both formats during the transition window; new credentials use the new path.

fido-u2f is the U2F-era legacy format, descended directly from the December 2014 U2F design [@fido-u2f-overview]. ECDSA P-256 signing key plus a vendor X.509 cert. Modern keys still emit it for U2F-mode CTAP1 ceremonies, but every modern CTAP2 ceremony uses packed instead.

none is the most-deployed format in consumer flows -- and the recommended default for any relying party that does not have a specific anti-fraud requirement. The RP asks for attestation: "none"; the authenticator returns just the credential public key and the AAGUID, with no signature chain. The privacy benefit is real: attestation deanonymises the user's device by model, and a relying party that does not need that information should not collect it. The 2024-2026 best practice is attestation: "none" for consumer passkey flows. NIST SP 800-63B-4 (final) inherits this caution [@sp80063b4-html].

Note: Use attestation: "none" for consumer flows; the privacy cost of direct outweighs the anti-fraud benefit for low-value accounts. Use attestation: "direct" only when (a) you have a documented anti-fraud requirement, (b) you can verify the chain against the FIDO Metadata Service, and (c) you accept that the cert reveals the authenticator model. Use attestation: "enterprise" only inside a managed enterprise where the user's device is corporately enrolled.

All seven formats assume the authenticator is on the same device as the browser. What happens when it isn't?

12. Hybrid transport: a phone authenticator for a laptop browser

A user on a borrowed Windows laptop with no Windows passkey signs in to their bank by scanning a QR code with their iPhone. The phone is the authenticator. The laptop is the WebAuthn client. The protocol that ties them together is hybrid transport, formerly known as caBLE (Cloud-Assisted Bluetooth Low Energy), standardised in W3C WebAuthn Level 3 §6.3.3 [@webauthn-l3-cr].

A WebAuthn transport in which a roaming authenticator (typically a mobile phone) cooperates with a WebAuthn client on a nearby device (typically a laptop) via three concurrent channels: an out-of-band channel (QR code) for one-time setup, BLE for proximity, and HTTPS to a discoverable cloud tunnel relay for the actual ceremony bytes. The cryptographic binding is an ephemeral ECDH key exchanged through the QR code; the BLE proves proximity, not identity; the tunnel relay carries the encrypted ceremony [@webauthn-l3-cr-dated].

The ceremony, simplified: the laptop's browser asks the user to use a phone, generates an ephemeral ECDH keypair, and renders a QR code containing the Tunnel Service URL the phone should connect to, the laptop's ephemeral public key, and a derived HMAC key. The phone's camera scans the QR code and derives a shared secret with the laptop via ECDH. The phone then advertises its presence over BLE, the laptop listens for the BLE beacon to confirm physical proximity, and both endpoints connect to the Tunnel Service URL over HTTPS. From that point on, the laptop and the phone exchange CTAP2 ceremony messages, encrypted under the ECDH-derived key, through the tunnel relay. The phone produces a WebAuthn assertion locally using whatever authenticator is on the phone (the Secure Enclave on iPhone, the Android Keystore on Android), encrypts it for the laptop, and the laptop forwards it to the relying party.

sequenceDiagram participant U as User participant L as Laptop browser participant P as Phone authenticator participant T as Tunnel Service participant R as Relying Party L->>R: navigator.credentials.get R->>L: PublicKeyCredentialRequestOptions L->>L: generate ephemeral ECDH keypair L->>U: display QR code (tunnel URL, ephem pubkey, HMAC seed) U->>P: scan QR code P->>P: derive shared secret via ECDH P->>L: BLE advertisement (proximity proof) L->>L: confirm BLE advertisement P->>T: HTTPS connect to tunnel URL L->>T: HTTPS connect to tunnel URL T->>L: relay encrypted CTAP2 traffic T->>P: relay encrypted CTAP2 traffic P->>U: prompt for user verification U->>P: present gesture P->>P: produce WebAuthn assertion (origin-bound) P->>T: encrypted assertion T->>L: encrypted assertion L->>R: assertion R->>U: signed in

The criterion-table consequence is precise. Phishing resistance is preserved because the origin in clientDataJSON is the laptop's actual browser origin, which the phone signs over the same way it would for its own browser. The QR code is the cryptographic binding, not the BLE advertisement; the BLE advertisement is a proximity signal that proves the phone is physically near the laptop, but it does not authenticate the phone. The Tunnel Service is a relay, not a trust anchor; even if the tunnel were compromised, the encrypted ceremony bytes would be unreadable without the ECDH-derived key.

The design is attributed in the WebAuthn L3 spec to the W3C WebAuthn-3 editor masthead -- Jeff Hodges, J.C. Jones, Michael B. Jones, Akshay Kumar, and Emil Lundberg as current editors, with Dirk Balfanz as a previous editor [@wiki-webauthn]. The original caBLE design and the L3 §6.3.3 productisation were led by Google's Chrome security and Android Identity teams; the canonical reference is W3C WebAuthn Level 3 §6.3.3 itself.

Hybrid transport is the only competitor to the Windows platform authenticator that involves no Windows-side credential storage. The Windows laptop holds nothing -- no key, no recovery state, no cached credential. Every ceremony round-trips to the phone. This is the use case the bank-on-a-borrowed-laptop story illustrates: you can sign in to your accounts on a machine you do not own without leaving a credential behind.

How do other authentication approaches score on the criteria framework?

13. Competing approaches scored against the criteria

The criteria-framework table makes the competitive field legible. Five rows, six competing columns: password alone, password plus SMS-OTP, password plus TOTP, password plus push with number matching, smart card / PIV, and device-bound or synced passkey. The NIST SP 800-63B-4 AAL grading [@sp80063b4-html] and the NIST syncable-authenticator supplement [@sp80063sup1] anchor the right edge of the table; Yubico's commentary corroborates the dichotomy between device-bound (AAL3) and synced (AAL2) passkeys [@yubico-nist-guidance].

Criterion	Password	Password + SMS-OTP	Password + TOTP	Password + Push (number match)	Smart Card / PIV	Device-bound passkey	Synced passkey
Phishing resistance	None	None (AitM relays the OTP)	None (AitM relays the TOTP)	Partial (number match defeats most kits)	Strong (origin-bound via TLS client auth)	Strong (`rpId` binding)	Strong
Verifier-compromise resistance	None	None (SMS infra leaks)	Partial (TOTP seed on server)	Partial	Strong (public-key only)	Strong	Strong
Replay / relay resistance	None	Weak (OTP relay in 30-60 s)	Weak (TOTP relay in 30 s)	Strong (number match per challenge)	Strong (per-handshake nonce)	Strong (challenge + counter)	Strong
Step-up / continuity	None	None	None	Partial	Strong (PIN re-prompt)	Strong (`UV=1`)	Strong
Recovery floor	Reset via SMS	SMS-OTP all the way down	TOTP seed reset via SMS	SMS / password	Admin re-issue	RP-dependent backup key	Sync-fabric recovery (Recovery Key + Recovery Contact)
NIST AAL ceiling	AAL1	AAL2 nominal (SMS-OTP RESTRICTED in 800-63-3 [@nist-sp80063-3-final]; deprecated in 800-63-4 [@sp80063-4-final])	AAL2	AAL2	AAL3	AAL3	AAL2

Push MFA needs a paragraph of nuance. Vanilla push -- "tap to approve" -- is phishable by default because the attacker can simply trigger the push at the moment they have the password, and a fatigued user taps. Number matching (the user types a code shown on the laptop into the phone, or vice versa) defeats most kits because it ties the push to a specific session. Location binding (the push is rejected unless the phone is geographically near the laptop) adds another layer. The net is "partial" phishing resistance -- much better than vanilla push, not as strong as origin binding.

Smart cards and PIV deserve their own paragraph because they are not historically associated with WebAuthn but score well on the criteria. A PIV card with a PIN provides strong phishing resistance via TLS client authentication (origin-bound at the TLS layer), strong verifier-compromise resistance via the public-key model, and strong replay resistance via per-handshake nonces. The weakness is recovery: a lost card requires an administrative reissue, which scales poorly for consumer flows. The companion App Identity in Windows article in this series walks the Windows smart-card stack end to end.

OATH-TOTP is interesting in the criteria table because it is phishing-vulnerable by construction. The TOTP code is the same on the legitimate origin and the look-alike; the AitM kit forwards the code through. Google Authenticator's cloud-sync feature additionally broke the verifier-compromise property in a subtle way: if the user's Google account is compromised, the synced TOTP seeds give the attacker a complete second-factor toolkit [@google-auth-sync-2023].

SAML and OIDC federation are not competitors to WebAuthn in the criteria table -- they are transport layers above WebAuthn. A SAML or OIDC identity provider does the WebAuthn ceremony for the user; the IdP then issues a SAML assertion or an OIDC ID token to the relying party. WebAuthn underneath is the strong primitive; SAML and OIDC are the enterprise transport for the resulting assertions.

WebAuthn wins decisively on four of five rows. What's left in row five? The recovery row.

14. Theoretical limits: the corners WebAuthn cannot reach

Even with everything from §§4-12 in place, WebAuthn has corners it cannot defend. The relevant impossibility results are well-known in the protocol literature; they are worth naming because they tell a practitioner where defence-in-depth has to come from.

Coerced consent. WebAuthn cannot distinguish a willing user from a coerced one. The protocol's only signal is "the user performed the gesture" -- a fingerprint, a PIN, a face match. No protocol whose only observable is gesture completion can tell whether the user was free at the moment of the gesture. NIST SP 800-63B-4 does not classify physical coercion among the attacks it defends against [@sp80063b4-html]; this is a general impossibility, not a WebAuthn-specific weakness.

Note: A user under duress can be made to present a gesture. WebAuthn cannot detect this. The compensating control is transactional -- step-up authentication with a fresh challenge for high-value actions, and out-of-band confirmation for transactions above a risk threshold. The protocol cannot solve coercion; the application layer must.

Kernel-level malware on the client. Malware with kernel privilege on the user's device can race the legitimate user. If the malware can call into webauthn.dll and trigger a Hello UV prompt the user blindly approves, it can extract assertions. The mitigation is TPM-bound keys plus the Hello ESS trustlet (covered in the companion Windows Hello and Credential Guard articles), not WebAuthn itself. WebAuthn protects against network attackers; defending against a kernel-mode attacker on the same device requires the OS's secure-kernel architecture.

Sync-fabric compromise. Compromise of Apple iCloud, Google account recovery, or Microsoft's recovery-key service effectively compromises every passkey held there. Apple's Advanced Data Protection model [@apple-adp-kb] is the strongest currently-shipped consumer realisation of the end-to-end-encrypted sync invariant, and even it depends on the user retaining their Recovery Contact or Recovery Key in some form. The NIST April 2024 supplement classifies synced passkeys at AAL2 for exactly this reason: the private key leaves the original authenticator [@sp80063sup1]. Yubico's commentary makes the practitioner consequence explicit: device-bound is AAL3, synced is AAL2 [@yubico-nist-guidance].

Username enumeration and discoverable-credential privacy. Discoverable credentials let an authenticator answer "do you have a credential for this rpId?" without further information. A relying party that asks the question maliciously can enumerate which of its users have set up a passkey. The credProtect extension introduced in CTAP 2.1 [@ctap-2-1-ps] requires UV=1 to even list the credential, which closes most of the leak; it is not universally deployed.

Counter-regression false positives on synced passkeys. The per-credential signature counter is per-authenticator. A passkey synced across two devices will see the counter desynchronise between them. WebAuthn L3 §6.1.1 explicitly permits a zero-counter for synced passkeys; relying parties that treat any counter regression as evidence of cloning will produce false positives. Treat counter regression as evidence of cloning only for BS=0 (device-bound) credentials. This is a deployment foot-gun, not a protocol flaw.

flowchart LR A[rpId binding / origin in clientDataJSON] --> P[Phishing resistance] B[Public-key model / no shared secret] --> V[Verifier-compromise resistance] C[Per-RP challenge + signCount + BS=0] --> RR[Replay / relay resistance] D[UP and UV flags + freshness] --> S[Step-up / continuity] E[BE / BS flags + sync fabric] --> AV[Availability] F[Recovery Key + Recovery Contact] --> RC[Recovery] G[TPM 2.0 / hardware secure element] --> AAL[AAL3 device-bound] H[End-to-end encrypted sync fabric] --> AAL2[AAL2 synced]

These are the protocol limits. The biggest practical limit is one the protocol cannot fix at all -- recovery. The protocol can specify what factor produces the credential at sign-in; it cannot specify what factor produces the credential when the original one is lost. That is the application-layer question every relying party answers differently, and it is the question §17 will land on.

15. Open problems: what's still moving in late 2025 / early 2026

Standardisation is not done. Several major surfaces are still in active draft.

WebAuthn Level 3 is currently a W3C Candidate Recommendation [@webauthn-l3-cr]; the dated CR snapshot is 13 January 2026 [@webauthn-l3-cr-dated]. The expected progression is Candidate Recommendation to Proposed Recommendation to Recommendation through 2026, with no major spec-breaking changes expected at this point in the process. The active editor masthead is Hodges, J.C. Jones, M.B. Jones, Kumar, and Lundberg [@wiki-webauthn].

CTAP 2.2 is a FIDO Proposed Standard as of 14 July 2025 [@ctap-2-2-ps]; CTAP 2.3 is also listed at FIDO's specifications download page [@fido-specs-download]. The 2.2 and 2.3 revisions refine hybrid transport, credProtect, and PIN-protocol handling without breaking 2.1's command-byte table.

Cross-vendor passkey portability. The FIDO Alliance Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) Working Drafts, dated 3 October 2024 [@fido-cxp-wd], are the standards effort. The draft text identifies the problem: "the transfer of credentials between two different providers has traditionally been an infrequent occurrence... As it becomes more common for users to have multiple credential providers that they use to create [and] manage credentials, it becomes important to address some of the security concerns with regard to migration" [@fido-cxp-wd]. Apple has signalled CXP-based import for iOS; Bitwarden has signalled support. The likely 2026 trajectory is CXP becoming a Proposed Standard and Windows / Android / iOS implementing it as the OS-level import-export passkeys surface.

Transactional authorisation. The earliest WebAuthn drafts included txAuthSimple and txAuthGeneric extensions [@webauthn-fpwd]; neither was ever implemented by browsers, and both are absent from L3. The productised path is Secure Payment Confirmation (a sibling spec to WebAuthn), but it covers only payment transactions. General "sign a description of this transaction" remains an open problem. Conjecture: payment-confirmation becomes the template that gets generalised in WebAuthn Level 4.

Quantum-safe attestation. The IANA COSE algorithm registry (last updated 2026-03-04) currently has no PQC algorithm in WebAuthn-recommended status [@iana-cose-registry]. ECDSA P-256, EdDSA Ed25519, RSA-PKCS1.5, and RSA-PSS are the registered options, all quantum-breakable in principle. A long-lived TPM AIK signed today is forgeable to a quantum-capable adversary at any future date. The companion Post-Quantum Cryptography on Windows article in this series walks the algorithm-side rollout; the WebAuthn deployment side is open. The most plausible trajectory is ML-DSA (FIPS 204) entering the WebAuthn COSE registry by 2027 and existing TPM AIKs receiving a parallel ML-DSA enrolment.

Standards are still moving. What should a practitioner do today?

16. Practical guide: what to do this week

Six pieces of operational advice, each tied to a primary source.

1. Windows developers: use webauthn.dll, do not roll your own. The Win32 reference at learn.microsoft.com/en-us/windows/win32/api/webauthn/ [@ms-learn-win32-webauthn] is the only surface you should be calling. The OS handles USB-HID, NFC, BLE, hybrid transport, Conditional Mediation, plug-in dispatch, and Windows Hello UV in one call. The header is at github.com/microsoft/webauthn [@github-ms-webauthn]; the Microsoft Learn overview is at learn.microsoft.com/.../hello-for-business/webauthn-apis [@ms-learn-webauthn-apis].

2. Relying parties: default to attestation: "none", userVerification: "required", residentKey: "preferred". This is the 2024-2026 consumer-flow baseline. attestation: "none" preserves user privacy and interoperates with every authenticator type. userVerification: "required" forces UV=1 and the gesture acquisition. residentKey: "preferred" enables usernameless sign-in on platforms that support it without burning a credential slot on older authenticators that don't. The Microsoft Entra passwordless documentation [@ms-entra-passwordless] and the WebAuthn Level 3 spec [@webauthn-l3-cr] are the references.

3. Enterprise IT: device-bound FIDO2 keys for AAL3 (admin, finance, tier 0); synced passkeys for AAL2 workforce. NIST SP 800-63B-4 [@sp80063b4-html] formalises the dichotomy via the syncable-authenticator supplement [@sp80063sup1]. Yubico's enterprise commentary makes the operational point: device-bound passkeys on dedicated hardware are AAL3; synced passkeys are AAL2 [@yubico-nist-guidance]. For admin accounts use FIDO Alliance L3-certified hardware [@fido-certification-levels] -- YubiKey Bio, Feitian BioPass, the Entra-listed vendors at learn.microsoft.com/.../concept-fido2-hardware-vendor [@ms-entra-fido2-hardware].

4. Windows 11 24H2 end users: enable third-party passkey providers in Settings. Settings -> Accounts -> Passkeys -> Advanced options. Toggle the provider on for any vendor you trust (1Password, Bitwarden, Dashlane) [@ms-windev-passkeys-blog]. The Microsoft Learn third-party tutorial walks the flow [@ms-learn-thirdparty]. If you do not use a third-party vault, the Microsoft synced passkey provider is enabled by default on 24H2 systems signed in with a Microsoft Account.

5. Security architects: write down your recovery flow first. Score it against the five-axis criteria table from §2 before you design the authentication factors. The recovery row's strength is the system's ceiling, not the floor; the authentication ceremony cannot raise it. Microsoft Entra's own guidance flags account recovery as a deployment risk: FIDO2 keys "can increase costs for equipment, training, and helpdesk support -- especially when users lose their physical keys and need account recovery" [@ms-entra-passwordless]. §17 lands this argument.

6. Incident responders: collect ETW events from the WebAuthn provider. Plug-in authenticator registration events on managed devices are a high-signal indicator -- a newly enrolled IPluginAuthenticator on a privileged user's machine should be treated as a credential-store change requiring review. The companion ETW on Windows article in this series walks the WebAuthn provider events end to end.

Open PowerShell as the signed-in user (no admin needed for your own credentials) and call into the `webauthn.dll` `WebAuthNGetPlatformCredentialList` API via a managed wrapper, or use the Settings -> Accounts -> Passkeys page directly. There is no first-class `Get-WebAuthnCredential` cmdlet as of Windows 11 25H2; the Settings page is the supported management surface. The Microsoft Learn passkey overview is the canonical reference [@ms-learn-passkeys].

Most of this is engineering. One row of the table has resisted engineering for fifty years. That's where the article lands.

17. Recovery: your weakest factor is always your recovery flow

The thesis surfaced in §2 and deferred through twelve sections is the one the article lands on. The argument is direct, almost embarrassingly so: every authentication system that admits any external recovery primitive is, in the formal sense, at most as strong as that primitive. Strong authentication ceremonies coexist with weaker recovery ceremonies in every consumer platform in production, and the system's assurance level is the minimum of the two, not the maximum.

*Your weakest factor is always your recovery flow.*

To make the claim concrete, score every major platform's recovery flow against the same five-axis criteria table.

Apple iCloud Keychain (with Advanced Data Protection). Apple's published model has three recovery primitives [@apple-adp-kb]: (a) a trusted device the user previously signed into; (b) an iCloud Recovery Contact -- another Apple ID owner the user has nominated to attest their identity; and (c) an iCloud Recovery Key -- a 28-character string the user must retain [@apple-recovery-key]. Apple's published architecture is the strongest current consumer realisation of the end-to-end-encrypted invariant: the recovery primitives unlock an HSM-backed escrow cluster that holds the user's iCloud Keychain encryption material, but Apple itself does not hold the keys in plaintext. The fundamental dependency is the Apple ID password plus, originally, SMS-OTP at device-trust establishment.

Google Password Manager (with Google Account end-to-end encrypted passkey sync). Trusted-device fallback, security-key fallback, recovery code, recovery phone, recovery email. The recovery floor reduces, in the worst case, to SMS-OTP via the recovery phone. Google's architecture is end-to-end encrypted in the steady state but the trust establishment depends on Google account recovery, which depends on out-of-band verification primitives the user enrolled at account creation.

Microsoft Account. The October 2024 Windows Developer Blog states the recovery primitive verbatim: "you will be prompted to save a recovery key that will be used to verify your identity and protect your passkeys through end-to-end encryption" [@ms-windev-passkeys-blog]. The recovery key is a high-entropy string the user retains; if they lose it, the recovery flow falls back to the secondary factors the user enrolled (alternate email or SMS-OTP via the recovery phone). As with Google, the worst-case recovery floor is the weakest of the secondary factors the user enrolled.

Microsoft Entra ID (enterprise). Entra's Temporary Access Pass (TAP) is the strongest enterprise recovery primitive currently shipped: an administrator issues a time-bound passwordless TAP that the user redeems to bootstrap a new authenticator. TAP is stronger than consumer flows because of accountability -- the admin's identity is on the issuance -- but weaker than the authentication ceremony itself because the admin is socially engineerable. Microsoft documents the TAP issuance and redemption flow in detail [@ms-entra-tap].

1Password, Bitwarden, Dashlane under the 24H2 plug-in model. Each vendor's master password and secondary recovery primitive becomes the de facto floor of the entire passkey ceremony when the plug-in is the credential store. 1Password's master password plus Secret Key, Bitwarden's master password plus 2FA recovery code, and Dashlane's device trust plus master password -- each is the recovery floor for every passkey the vault holds. The Microsoft Learn third-party tutorial reinforces the warning, in context: "Contoso Passkey Manager is designed for passkey creation and usage testing only. Don't use the app for production passkeys" [@ms-learn-thirdparty].

flowchart TD A[Apple iCloud Keychain ADP] --> A1[Recovery Contact] A --> A2[Recovery Key 28 chars] A --> A3[Trusted device] A3 --> A4[Apple ID password + SMS-OTP at trust establishment] B[Google Password Manager] --> B1[Recovery code] B --> B2[Recovery phone] B --> B3[Recovery email] B2 --> B4[SMS-OTP] C[Microsoft Account] --> C1[Recovery Key] C --> C3[Alternate email] C --> C4[Recovery phone -> SMS-OTP] D[Entra ID enterprise] --> D1[Temporary Access Pass] D1 --> D2[Admin: socially engineerable] E[1Password / Bitwarden / Dashlane vault] --> E1[Master password + Secret Key / 2FA recovery code] A4 --> Z[Weak shared-knowledge or SMS-OTP floor] B4 --> Z C4 --> Z D2 --> Z E1 --> Z

The diagram looks busy because it is. Every major platform's recovery flow is a different combination of trusted-device fallback, recovery code or key, recovery contact, and an out-of-band primitive (SMS-OTP, email, or admin attestation). Every one of those out-of-band primitives is weaker than origin-bound public-key cryptography. The cryptographic ceremony scores AAL3 phishing-resistant at the authentication moment; the recovery primitive scores AAL1 or AAL2 at the recovery moment. The system's AAL is the minimum.

NIST SP 800-63B-4's AAL2 / AAL3 split makes the recovery story explicit. Section 5.1 of SP 800-63B-4 enumerates permitted recovery primitives; every one is at most as strong as its underlying factor. The April 2024 supplement [@sp80063sup1] caps synced passkeys at AAL2 because the long-term private key has left the original authenticator -- the same logic that caps the recovery row applies to the sync fabric. Auditors who care about AAL3 for tier-zero accounts will require *both* a device-bound authenticator and a documented recovery flow whose own strength is at AAL3. The current best-practice composition is two device-bound hardware authenticators in different physical locations, each registered as primary for the other's recovery.

Key idea: Every passkey platform in production in 2026 -- Apple, Google, Microsoft, Entra, 1Password, Dashlane, Bitwarden -- bottoms out, in its recovery flow, in some combination of trusted-device fallback and SMS-OTP-equivalent shared knowledge. That floor is the AAL ceiling for the entire system.

The protocol literature has been clear about this for fifty years and the regulatory literature has been catching up since 2017. NIST SP 800-63-3 introduced "phishing-resistant authenticator" as a first-class term; SP 800-63-4 (2025) [@sp80063-4-final] makes verifier-impersonation resistance a normative criterion. Neither standard solves recovery; both standards explicitly enumerate what counts as a recovery primitive without specifying how to compose them into an AAL-graded flow. There is no IETF or FIDO Alliance standard that says "here is a recovery flow whose strength is AAL3." There may never be -- recovery is application-specific, and the only general protocol is "social attestation" (multiple human witnesses), which does not scale.

The same WebAuthn ceremony that scores AAL3 phishing-resistant at the authentication moment can be a single-factor SMS-OTP at the recovery moment. Your weakest factor is always your recovery flow. That is the line. It is the line every working security architect should write down, score against, and design recovery against -- before designing the authentication factors.

18. FAQ

No. A password is a shared secret -- the user types a string, the server stores a hash of the same string, and an eavesdropper who captures the string in flight or compromises the server's database has a credential they can replay. A passkey is one half of an asymmetric keypair: the private key lives in the authenticator (TPM, secure enclave, hardware key, or end-to-end-encrypted sync fabric), and only its public key reaches the server. An eavesdropper who captures a passkey ceremony in flight has nothing they can replay; a server-database leak yields public keys that authenticate no one. WebAuthn Level 3 [@webauthn-l3-cr] and the Microsoft Entra "origin-bound public key cryptography" framing [@ms-entra-passwordless] are the references. Insecure relative to device-bound; secure relative to passwords. The NIST syncable-authenticator supplement (April 2024) [@sp80063sup1] and SP 800-63B-4 (July 2025) [@sp80063b4-html] cap synced passkeys at AAL2, because the long-term private key has left the original authenticator. Device-bound passkeys on dedicated hardware -- "FIDO passkeys that are not synced ... and are properly stored in dedicated hardware have an AAL3 rating" [@yubico-nist-guidance] -- can reach AAL3. The right answer is to use device-bound keys for tier-zero accounts and synced passkeys for the bulk of consumer flows. Hello *uses* biometrics but provides the *user-verification gesture* for WebAuthn; the credential itself is asymmetric and lives in the TPM. Microsoft Learn states the property verbatim: "The private keys can only be used after they're unlocked by the user using the Windows Hello unlock factor (biometrics or PIN)" [@ms-learn-passkeys]. The biometric is one mode of the Hello UV gesture, not the credential. If you disable face or fingerprint, your PIN still unlocks the passkey. No. Attestation is privacy-leaking for synced passkeys; `attestation: "none"` is the 2024-2026 default for consumer flows. Use `attestation: "direct"` only when you have a documented anti-fraud requirement and can verify the chain against the FIDO Metadata Service. Use `attestation: "enterprise"` only inside a managed enterprise where the user's device is corporately enrolled. The relevant references are WebAuthn Level 2 §§8.2-8.8 [@webauthn-l2-latest] and the IANA WebAuthn registry [@iana-webauthn-registry]. No. The cryptographic binding is the QR-code-encoded ephemeral ECDH key. Bluetooth is a transport and a proximity signal; it is not a trust anchor. The QR code transfers the laptop's ephemeral public key plus a derived HMAC seed; the phone derives the shared secret via ECDH; the BLE advertisement merely proves the phone is physically close to the laptop. The encrypted CTAP2 ceremony bytes travel over HTTPS through a discoverable tunnel relay. WebAuthn Level 3 §6.3.3 is the normative description [@webauthn-l3-cr]. No. A Windows passkey can be used with PIN-only user verification; the biometric is one mode of the Hello UV gesture, not the credential. The credential is in the TPM, indexed under your Microsoft Account container, and the PIN is one valid unlock factor. If you use a third-party passkey provider via the 24H2 plug-in model, that provider may use its own master password as the UV gesture; the OS still mediates the gesture acquisition through `WebAuthNPluginPerformUserVerification` [@ms-learn-webauthn-apis]. Microsoft cannot see your TPM-sealed Windows Hello private key; the TPM does not expose the raw key material to the OS, let alone to Microsoft. Apple's iCloud Keychain with Advanced Data Protection [@apple-adp-kb] and Google's end-to-end-encrypted passkey sync mean the sync provider cannot see the plaintext keys either. *But* the recovery path can still expose them under specific conditions: an attacker who compromises your recovery contact, recovery key, or your account's out-of-band recovery primitives (SMS-OTP, recovery email) effectively defeats the end-to-end encryption invariant. The plaintext keys are not what gets exfiltrated; the recovery primitives are.

This article is one of a series on Windows authentication primitives. NTLMless: The Death of NTLM in Windows (2026-05-10) covers the legacy authentication protocol passkeys are displacing. Windows Hello, Demystified covers the user-verification gesture WebAuthn leans on. Adminless: Administrator Protection in Windows (2026-05-10) and App Identity in Windows (2026-05-08) cover the privilege-escalation and code-identity primitives that surround the authentication stack. The companion Kerberos on Windows (2026-05-11) covers the enterprise transport for the resulting assertions; ETW on Windows (2026-05-11) covers the telemetry surface for incident responders.

The Windows passkey stack is the productisation moment for a forty-year-old protocol-literature insight: authentication should be tied to something the network attacker cannot change. WebAuthn ties it to the origin in clientDataJSON, signed by a credential whose private key never reaches the wire. Windows 10 1903 made it a Win32 surface; Windows 11 24H2 made it a plug-in surface; Authenticate 2024 made it a default. The protocol bytes are FIDO2; the consumer experience is autofill. The Windows part is the dispatcher between them.

The criteria framework is the diagnostic kit. Use it on every authentication system you ship. Score it against five axes, not three. Write down the recovery flow first. Match the authentication ceremony to the recovery flow you can actually defend. And remember the line: your weakest factor is always your recovery flow.

Adminless: How Windows Finally Made Elevation a Security Boundary

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

**Administrator Protection (informally "Adminless") replaces Windows 11's split-token UAC with a separate, system-managed local user account.** The operating system creates this **System Managed Administrator Account (SMAA)** per local admin, links it to the primary admin via paired SAM attributes, and uses it to host elevated processes in a fresh logon session gated by Windows Hello. The kernel asks LSA to authenticate "a new instance of the shadow administrator" without any SMAA credential because the SMAA has none. The mechanism makes the elevation path a security boundary for the first time, with bulletin-grade fixes when it fails. Microsoft shipped it in KB5067036 on October 28, 2025, then reverted it on December 1, 2025 over an application-compatibility issue, not a security failure. This article walks the twenty-year argument that produced the design, the nine pre-GA bypasses Forshaw found and Microsoft fixed, and exactly where the new boundary still leaks.

1. Two tokens, one user, twenty years

Open an elevated console on a Windows 11 device with the registry value TypeOfAdminApprovalMode = 2 set, and run whoami /all. The user name is no longer yours. It is ADMIN_<sixteen random characters> -- a local account you never created, owned by an operating-system component you never ran, in a logon session that did not exist five seconds ago and will not exist five seconds after the console closes.

For twenty years, an elevated Windows command prompt reported the same user name as the unelevated one. The integrity level changed. The token changed. The user did not. That single architectural fact is the load-bearing premise of every UAC bypass ever published. The Vista User Account Control design from 2006 issued two tokens at logon for a member of the local Administrators group: a filtered standard-user token for everyday work, and a full admin token linked to it via the TokenLinkedToken field [@ms-uac-how-it-works]. When the user clicked Yes on a consent prompt, the Application Information service called CreateProcessAsUser with the linked token. Same user. Same profile. Same HKCU. Same logon session. Different integrity level.

Four resources stayed shared between the filtered and full tokens, and four categories of attack grew out of them. Files dropped in a writable directory the elevated process trusts. Registry values planted under HKEY_CURRENT_USER that an elevated binary reads before it consults HKEY_CLASSES_ROOT. COM elevation monikers that hand the attacker an elevated IFileOperation interface. Path-resolution overrides that redirect %SystemRoot% for a single auto-elevating process. The UACMe project [@uacme] catalogues 81 such methods, each one a load against the shared-resource shape of Vista's split token.

Administrator Protection inverts that shape. The elevated administrator becomes a different account with a different security identifier, a different profile directory, a different NTUSER.DAT hive, a different authentication-ID LUID, and a different DOS device object directory under \Sessions\0\DosDevices\. The operating system manages the account itself. It is created on demand the first time the policy is enabled, linked to the primary admin via paired Security Account Manager attributes, used in a fresh logon session for every elevation, and the elevated token is destroyed when the process exits [@ms-developer-blog-2025, @call4cloud-osint].

The feature ships under four names -- Administrator Protection in Microsoft Learn, Adminless as the community shorthand this article uses, ShadowAdmin in the samsrv.dll engineering symbols, System Managed Administrator Account (SMAA) in the Windows Developer Blog [@ms-admin-protection, @ms-developer-blog-2025, @call4cloud-osint] -- and §6 walks each in turn. The launch arc was short: announced at Ignite 2024 by David Weston on November 19, 2024 [@bleepingcomputer-2024], surfaced earlier that fall in Insider Preview build 27718 on October 2, 2024 [@ms-insider-build-27718], shipped to stable Windows in KB5067036 on October 28, 2025 [@ms-kb5067036], and disabled on December 1, 2025 over a WebView2 application-compatibility regression [@forshaw-pz-jan2026, @ms-admin-protection].

This article walks what changed and what did not. By the end you will know exactly which UAC bypass families are dead, exactly which survive, exactly what the December 2025 revert was about, and exactly where the new boundary still leaks. The path runs through twenty years of design tradeoffs and seven years of binary-level fixes that never converged on a real boundary. It runs through nine Project Zero bypasses Microsoft fixed before shipping. It ends at a question Microsoft's own design documents do not yet answer: when the prompt is a credential gate instead of a click-through, what is left for the attacker to do?

The first thing to understand is what UAC was trying to do, and why Microsoft said for twenty years it was not a security boundary.

2. "Convenience, not boundary": UAC as Microsoft conceived it

Why did Vista ship UAC at all? For most of Windows history, every interactive logon for a member of the local Administrators group produced one full-admin token. The desktop shell ran as a full administrator. Every child process inherited those rights. The worm era of 2003 to 2005 demonstrated, repeatedly, that one process running in user context owned the whole machine. By 2006 the cost of admin-by-default had become impossible to defend [@wikipedia-uac].The pre-Vista Limited User Account (LUA) was Microsoft's first attempt at a fix. The conceptual ancestor of the filtered token failed in practice because roughly half of the third-party application base broke under it, and the documented workaround -- RUNAS.EXE -- was operationally hostile enough that almost no one used it.

The redesign that produced UAC pivoted on a single observation. Forcing administrators to run as standard users had failed because too much software assumed admin rights. So Vista would give each admin user two identities. One would be standard-user enough to run the desktop, the browser, and the day-to-day applications without privilege. The other would carry the admin rights, and the operating system would arrange for the user to opt into it on a per-task basis.

Mark Russinovich's June 2007 article Inside Windows Vista User Account Control in TechNet Magazine [@russinovich-2007-vista] remains the canonical reference for the design. The mechanism is two tokens at logon; the integrity-level taxonomy (Low, Medium, High, System) gating object access; file-system and registry virtualisation rerouting writes by legacy apps; and Mandatory Integrity Control enforcing the no-write-up rule at the kernel-object boundary.

The mechanism by which Vista UAC assigns two distinct access tokens to a single interactive logon for a member of the local Administrators group. The Local Security Authority issues both at logon: a filtered standard-user token with most privileges removed and the Administrators group marked as deny-only, and a linked full administrator token referenced from the filtered token's `TokenLinkedToken` field [@ms-uac-how-it-works].

The disclaimer that follows the design is the single most quoted sentence Russinovich ever published about UAC. The article will lift it verbatim once, because every Administrator Protection design decision falls out of its absence:

It's important to be aware that UAC elevations are conveniences and not security boundaries. -- Mark Russinovich, *Inside Windows Vista User Account Control*, TechNet Magazine, June 2007 [@russinovich-2007-vista]

This is not an accidental disclaimer. It is the canonical Microsoft classification, preserved into the Microsoft Security Servicing Criteria document [@msrc-servicing-criteria]. James Forshaw of Google Project Zero, writing in January 2026, re-states the position verbatim: "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-pz-jan2026]. The classification is what determined what Microsoft would and would not pay attention to. A "security boundary" gets a security bulletin when an attacker crosses it. A "security feature" does not. A bypass of a boundary is a vulnerability. A bypass of a feature is a quality bug. For twenty years, UAC bypasses were quality bugs.

The two-tokens-at-logon mechanism is the shape from which the entire bypass canon grows. The twenty years of evolution that follow run along a single timeline.

timeline title Privilege separation in Windows, NT 3.1 to Administrator Protection 1993 : NT 3.1 ships multi-user accounts and DACLs but admin-by-default desktop culture 2006 : Vista UAC introduces the split-token model and Mandatory Integrity Control 2009 : Davidson publishes the first UAC bypass; Windows 7 ships auto-elevation 2014 : hfiref0x's UACMe catalogue collects the bypass canon 2016 : enigma0x3 publishes the registry-hijack family (eventvwr, fodhelper, sdclt) 2019 : CVE-2019-1388 (consent.exe certificate dialog) is the lone UAC LPE bulletin 2024 : Insider Preview build 27718 surfaces Administrator Protection; Ignite 2024 announces it 2025 : KB5067036 ships the SMAA on stable Windows, then reverts on December 1 2026 : Forshaw's nine pre-GA bypasses all fixed; the elevation path is now a security boundary

To see why the entire bypass canon grew out of the split-token shape, the next section walks the mechanic at function-name granularity. It is the load-bearing pre-history of everything that comes after.

3. The Vista UAC split-token in detail

The mechanics at logon. The Local Security Authority Subsystem Service (LSASS) validates credentials. For a user in the local Administrators group, it constructs two tokens. The filtered token has its dangerous privileges removed and the Administrators SID marked deny-only; the full token retains them. The Token Manager wires the filtered token's TokenLinkedToken field to a handle on the full token. LSASS hands the filtered token to winlogon.exe. Winlogon launches userinit.exe. Userinit launches explorer.exe. The shell, holding the filtered token, becomes the parent process from which every user-initiated process inherits [@ms-uac-how-it-works].

The kernel structure that connects the filtered standard-user token to the linked full administrator token in Vista's split-token model. A process holding the filtered token can read the `TokenLinkedToken` field via the `GetTokenInformation` API to discover the handle of the full token, and pass that handle to `CreateProcessAsUser` to launch an elevated child. The same link is the structural premise of token-stealing attacks: any code path that can read or impersonate the linked token bypasses the consent UI entirely [@ms-uac-how-it-works, @forshaw-pz-jan2026].

The shell shares four resources with anything launched under the full token.

The same user security identifier. Both tokens carry the same primary SID. Files, registry keys, and kernel objects that grant access to the user grant identical access to both processes.
The same %USERPROFILE% directory tree. C:\Users\<user>\ is the home of both. The Documents folder, the Downloads folder, the AppData hives, and any application-specific subdirectory belong to one user.
The same HKEY_CURRENT_USER hive. Both tokens map HKCU to the same NTUSER.DAT file. An elevated process that reads a user setting reads the value the unelevated user wrote.
The same logon-session LUID. The Locally Unique Identifier that identifies an interactive logon session is the same on both tokens. The kernel uses that LUID as a key for per-logon-session caching: the DOS device object directory at \Sessions\0\DosDevices\<LUID>, drive-letter mappings, mapped network drives, and the credential cache.

The elevation pipeline. A user clicks Yes on a UAC prompt. The mechanism beneath that click runs through a chain of named function calls.

sequenceDiagram participant User as User shell (filtered token) participant AppInfo as appinfo.dll (Application Information service) participant Consent as consent.exe (secure desktop) participant LSA as LSASS participant New as Elevated child process

User->>AppInfo: ShellExecute / CreateProcess "as admin"
AppInfo->>AppInfo: RAiLaunchAdminProcess RPC
AppInfo->>AppInfo: Read manifest requestedExecutionLevel
AppInfo->>AppInfo: Check ConsentPromptBehaviorAdmin
AppInfo->>Consent: Launch consent.exe on Winlogon desktop
Consent->>User: Show Yes / No prompt
User-->>Consent: Click Yes
Consent-->>AppInfo: Approved
AppInfo->>LSA: Resolve TokenLinkedToken handle
AppInfo->>New: CreateProcessAsUser(linked full token)
Note over New: Same SID and profile and HKCU and logon session
Note over New: Integrity level High

The prompt runs on the secure desktop, the same Winlogon-owned Winsta0\Winlogon desktop where the credential-entry dialog appears at logon, not the user's interactive Winsta0\Default desktop [@ms-uac-how-it-works]. User Interface Privilege Isolation (UIPI) blocks lower-integrity input from reaching higher-integrity windows; the secure-desktop switch is its first defence against synthetic-keystroke attacks against the prompt itself.The secure desktop is not invulnerable. It changes the integrity-isolation context, but a process holding the filtered token can still trigger the switch (that is the whole point of clicking Yes), and code running before the switch can in principle modify the surrounding UI state. CVE-2019-1388 in late 2019 turned out to exploit a different aspect entirely -- a UI-interaction path through the consent.exe certificate-viewer dialog -- and not the secure-desktop switch itself.

Compare this to what comes next. Both tokens share four resources. Each of those resources is a category of attack waiting for a researcher to find it. The next section is the story of what happened when Microsoft tried to make UAC less annoying by silently elevating its own Microsoft-signed binaries -- and what the bypass canon did with the change.

4. Windows 7 auto-elevation and the birth of the bypass canon

A specific moment. December 2009. Leo Davidson publishes Windows 7 UAC whitelist: Code-injection Issue / Anti-Competitive API / Security Theatre on pretentiousname.com [@davidson-2009]. The title is the argument. The page itself is sprawling, contentious, and on a few key technical points exactly right. Microsoft's response, in Davidson's own words: "this is a non-issue, and ignored my offers to give them full details for several months." Microsoft Security Essentials eventually classified the binary (not the technique) as HackTool:Win32/Welevate.A and HackTool:Win64/Welevate.A; in Davidson's pointed observation, "recompiling the binaries in VS2010 means they are no longer detected" [@davidson-2009].Davidson kept writing into his original page over the following decade. A marker buried inside the text reads "As I was typing more words into this page, this appeared in my text editor at the 10,000th word!" In March 2020 he removed the proof-of-concept binaries, noting "I got sick of the page being marked as malware, even by Google (FFS)." The prose remains the canonical first source on UAC bypasses [@davidson-2009].

What Windows 7 added, in October 2009, to fix Vista's prompt-fatigue problem [@russinovich-2009-win7]:

The autoElevate=true manifest attribute, embedded in selected Microsoft-signed Windows binaries.
An internal whitelist of Microsoft-signed binaries living under %SystemRoot%\System32.
The COM Elevation Moniker -- already shipping in Vista (BIND_OPTS3, syntax Elevation:Administrator!new:<CLSID>) -- was the activation primitive. Windows 7 extended implicit auto-elevation to qualifying COM servers whose registrations matched the new whitelist criteria, so callers such as IFileOperation, ICMLuaUtil, and IColorDataProxy could be launched elevated without a consent prompt under the Win7 model [@russinovich-2009-win7, @uacme]. The dedicated registry-curation surface, the COMAutoApprovalList (HKLM\Software\Microsoft\Windows NT\CurrentVersion\UAC\COMAutoApprovalList) that UACMe Method 49 references verbatim, did not ship in Windows 7; it was introduced seven years later in Windows 10 RS1 (build 14393, August 2016) as a Redstone-1 hardening that replaced implicit COM auto-elevation with explicit list curation [@uacme].
The default consent-prompt behaviour ConsentPromptBehaviorAdmin = 5: prompt for consent for non-Windows binaries [@russinovich-2009-win7].

The Windows 7 mechanism by which selected Microsoft-signed binaries elevate without showing the consent prompt to a user who is a member of the local Administrators group. The Application Information service consults a whitelist of signature, path, and manifest attributes; if the binary qualifies, `appinfo.dll` calls `CreateProcessAsUser` with the linked full token and no UI step at all [@russinovich-2009-win7]. A COM activation syntax introduced in Windows Vista that lets an unelevated caller request an elevated instance of a COM server class. The `IBindCtx` is augmented with a `BIND_OPTS3` structure carrying a window handle to attribute the prompt to. The bind moniker `Elevation:Administrator!new:<CLSID>` causes the COM Service Control Manager to launch the server elevated. UACMe methods that target `IFileOperation`, `ICMLuaUtil`, and `IColorDataProxy` all descend from this mechanism [@russinovich-2009-win7, @uacme].

Davidson's technique against the new whitelist is one paragraph of detail. Use the IFileOperation COM elevation moniker, which itself auto-elevates, to write a planted CRYPTBASE.DLL into %SystemRoot%\System32\sysprep\. The path is a writable destination from the limited token because IFileOperation runs elevated. Then launch sysprep.exe, which is auto-elevated as a Microsoft-signed binary in System32. Sysprep loads CRYPTBASE.DLL from its own directory before the system path. The attacker's DLL runs at High integrity in the elevated sysprep process [@davidson-2009, @uacme]. No prompt. The whitelist did the work.

The bypass canon. Davidson's technique was the start, not the totality. The successors walked the same shape across families.

The DLL side-load family. Sysprep was the canonical instance. Subsequent variants targeted cliconfg.exe, mcx2prov.exe, migwiz.exe, and setupsqm.exe -- each an auto-elevating Microsoft binary that loaded a DLL from a writable directory before consulting the system path. Microsoft removed the auto-elevation attribute from many of these binaries over the Windows 10 1709 cycle, but did so one binary at a time [@uacme].
The registry-hijack family. Matt Nelson's August 2016 disclosure of an eventvwr.exe plus HKCU\Software\Classes\mscfile\shell\open\command bypass [@enigma0x3-2016-eventvwr] established the pattern. An auto-elevating binary consults HKEY_CURRENT_USER before HKEY_CLASSES_ROOT for a value the binary trusts to dispatch a child process. The limited user, who owns HKCU, writes whatever they want into the value. The elevated binary executes the attacker's command line. March 2017 produced sdclt.exe plus App Paths [@enigma0x3-2017-app-paths] and sdclt.exe plus IsolatedCommand [@enigma0x3-2017-sdclt]; May 2017 produced the fodhelper.exe plus ms-settings variant [@uacme]. All fileless. All generalising to any auto-elevating binary that walks HKCU before HKCR.
The COM-elevation-moniker abuse family. UACMe's Method 1 (Davidson's original IFileOperation) ages into Methods 41 (ICMLuaUtil, Oddvar Moe, via ucmCMLuaUtilShellExecMethod) and 43 (IColorDataProxy paired with ICMLuaUtil, Oddvar Moe derivative, via ucmDccwCOMMethod), each one a different COM interface that auto-elevates and exposes a method useful for arbitrary file or registry write [@uacme].
The environment-variable and path-poisoning family. Per-process %windir% or %SystemRoot% redirection via registry shims and Image File Execution Options, redirecting auto-elevating binaries to load resources from attacker-controlled directories.

Key idea: The Windows 7 auto-elevation whitelist was the bypass. The day Microsoft shipped a class of binaries that could elevate silently based on signing and path, the entire problem of UAC bypass reduced to "make one of those binaries do something the attacker wants it to do." Every UACMe method that targets a Microsoft-signed binary in System32 descends from this design choice. The 81-method catalogue is not a list of separate vulnerabilities; it is one architectural mistake spreading through the binary inventory.

Enter hfiref0x's UACMe [@uacme]. The project has been on GitHub since 2014. It currently lists 81 named methods. Each entry pairs the method number with the author credit, the target binary, the technique class, and the "Fixed in" build number. The README, taken together, is the institutional memory of UAC's failure as a boundary. Forshaw's January 2026 framing is the operational summary: "A good repository of known bypasses is the UACMe tool which currently lists 81 separate techniques for gaining administrator privileges" [@forshaw-pz-jan2026].

Microsoft chose to fix individual bypasses rather than redesign the model. The next section asks whether seven years of fixes ever caught up.

5. 2017-2024: incremental hardening, no convergence

The middle Windows 10 era was the moment Microsoft treated UAC bypasses as a quality problem and shipped fixes at quality-fix cadence, not security-bulletin cadence. The work was real, but it was always one binary or one interface at a time.

The named milestones, kept short.

Windows 10 1709 (October 2017). Beginning with this build, IFileOperation auto-elevation for callers other than Explorer was restricted [@uacme]. The originating Davidson 2009 family of bypasses, against the sysprep + planted-CRYPTBASE shape, ceased to function for processes other than the shell itself.
Tighter appinfo.dll manifest parsing across multiple Windows 10 builds. Stricter binary-signature checks. Stricter path checks. Stricter manifest checks. Each of these closed individual bypass methods; none of them closed a family.
Per-binary hardening recorded in UACMe's "Fixed in" column. UACMe version 3.5.0 retired roughly eighty percent of the 2014-vintage catalogue as obsolete; the v3.2.x branch retains the full historical record. The project's README warns that "since version 3.5.0, all previously 'fixed' methods are considered obsolete and have been removed. If you need them, use v3.2.x branch" [@uacme].
CVE-2019-1388 (November 2019; reporter: Eduardo Braun Prado via Trend Micro's Zero Day Initiative). The lone departure from the "UAC bypasses get no CVE" rule. A UI-interaction path through consent.exe's certificate-viewer dialog: an unsigned application could trigger consent.exe to display a certificate dialog whose "View Certificate" link launched Internet Explorer running as NT AUTHORITY\SYSTEM, and IE's File menu opened cmd.exe at the same integrity level [@nvd-cve-2019-1388]. Microsoft fixed it on the November 2019 Patch Tuesday and gave it an LPE bulletin.

CVE-2019-1388 was a prompt-UI bug -- specifically, a crash-path that surfaced an IE process at SYSTEM integrity via the certificate viewer -- not a UAC-bypass bug in the categorical sense. The classification distinction matters: Microsoft did not change its position that UAC was not a boundary; the bulletin treated this as a separate UI defect that incidentally crossed the boundary. CISA later added the CVE to the Known Exploited Vulnerabilities Catalog [@nvd-cve-2019-1388].

The accumulating evidence by 2024 was three observations.

UACMe's catalogue has grown from its 2014 origins to 81 methods today [@uacme]. Each family of attack survived the individual fixes. As Davidson predicted in 2009, the auto-elevation whitelist was the structural problem; patching each whitelisted binary as a separate bug was a treadmill, not a convergence.

Microsoft's own Security Servicing Criteria continued to classify UAC as a security feature, not a boundary, throughout the period [@msrc-servicing-criteria, @forshaw-pz-jan2026]. The decision was load-bearing. Fixing the elevation pipeline at quality cadence meant accepting that bypasses would appear quarterly and would not appear in the Patch Tuesday bulletins until the day Microsoft changed its mind about the classification.

The third piece of evidence is what the attackers were doing while the defenders were churning the binary list. Microsoft's own number, quoted by the Windows Developer Blog from the Microsoft Digital Defense Report 2024, is 39,000 token-theft incidents per day [@ms-developer-blog-2025]. A token, once stolen from an elevated process, requires no further bypass: it is a bearer credential good for the lifetime of the logon session. The same logon session is the one the unelevated user and the elevated process share under the split-token model. The "one logon session" property of UAC's design is the structural premise that token theft depends on.

There is one further thread worth naming here. Forshaw's broader 2022 Kerberos work in the user-credential-delegation space is a thread that survives the elevation-redesign question entirely. The May 2022 Exploiting RBCD using a normal user account post [@forshaw-2022-rbcd] is the representative artifact. Network-credential delegation primitives -- Resource-Based Constrained Delegation, User-to-User Kerberos, S4U2Self -- operate at a layer beneath token-level elevation, and survive even a perfect SMAA design because they do not run through the elevation path at all.

Piecewise fixes never converged on a boundary. The question that drove the next five years of Microsoft work was the obvious one: if the issue is the shared-resource model itself, what is the smallest plausible change that fixes it?

6. The breakthrough: the System Managed Administrator Account

The load-bearing design decision is one sentence. Stop trying to make one user account play both roles. The elevated administrator should be a different account with a different SID, a different profile, a different HKCU, a different logon session, and a different DOS device object directory -- and the operating system should manage that account itself.

What is striking about the design is how prosaic the underlying mechanism is. Multi-user accounts have shipped with Windows NT since version 3.1 in 1993. The architecture for running an elevated process under a separate local user has been present in NT for thirty-three years. What changed is that Microsoft finally chose to enforce the multi-user model for privilege separation, by making the operating system itself create and manage the second account, link it to the primary admin via paired Security Account Manager attributes, and use it for every elevation. The sophistication is in linkage, in lifecycle, and in removing auto-elevation, not in any single new primitive.

Note: The thing that changes between UAC and Administrator Protection is not the elevation mechanism (a manifest, a prompt, a CreateProcessAsUser call) but the elevation classification. An elevation bypass used to be a quality bug. It is now a security-bulletin vulnerability. Every Administrator Protection design decision -- separate account, fresh logon session, removed auto-elevation, Hello-gated consent -- is a consequence of the classification change.

The names. Microsoft Learn's term is Administrator Protection [@ms-admin-protection]. Microsoft's announcement material at Ignite 2024 and in the Insider Preview build 27718 post uses the same "Administrator Protection" label [@ms-insider-build-27718]; Adminless is the community shorthand that stuck. The internal engineering term in samsrv.dll (the Security Account Manager service DLL) is ShadowAdmin [@call4cloud-osint]. The Windows Developer Blog's canonical term for the underlying entity is the System Managed Administrator Account (SMAA) [@ms-developer-blog-2025].

The hidden local user account that Windows creates per primary administrator when the `TypeOfAdminApprovalMode` policy is set to 2. The SMAA has its own random user name (typically `ADMIN_`), its own SID, its own profile directory under `C:\Users\ADMIN_\`, its own `NTUSER.DAT` and therefore its own `HKCU`, and its own membership in the local Administrators group. The operating system uses it to host elevated processes; the user never logs into it directly [@ms-developer-blog-2025, @call4cloud-osint].

The SMAA lifecycle. Four beats. Each anchored to a verified source.

Provisioning. When TypeOfAdminApprovalMode = 2 is set under HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System (either by Group Policy or by the Intune Settings Catalog), samsrv.dll's ShadowAdminAccount::CreateShadowAdminAccount runs once per existing local-administrator account. CreateRandomShadowAdminAccountName produces an ADMIN_<random> name. AddAccountToLocalAdministratorsGroup adds the new account to the Administrators group. Accounts managed by Windows LAPS (Local Administrator Password Solution) are skipped; their lifecycle is owned by a different subsystem and Microsoft did not want the SMAA mechanism to fight LAPS rotation [@call4cloud-osint].

Linking. Two paired SAM attributes encode the trust relationship between the two accounts. The primary admin's user record gets a ShadowAccountForwardLinkSid attribute pointing at the SMAA's SID. The SMAA's user record gets a ShadowAccountBackLinkSid attribute pointing back at the primary admin. These two attributes are the only structural relationship between the two accounts; everything else -- profile, HKCU, group memberships -- is independent [@call4cloud-osint].

Two paired SAM-database attributes that encode the trust relationship between a primary admin user and its System Managed Administrator Account. The forward link sits on the primary admin's record and points at the SMAA's SID. The back link sits on the SMAA's record and points back at the primary admin. The Application Information service uses the forward link at elevation time to resolve which SMAA to launch the elevated process under [@call4cloud-osint]. The registry value under `HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System` that selects the elevation policy. Value 0 disables UAC. Value 1 selects classic Admin Approval Mode (the Vista / Win7 / Win10 split-token behaviour). Value 2 selects Admin Approval Mode with Administrator Protection: every elevation routes through the SMAA path. The value is set by Group Policy ("User Account Control: Configure type of Admin Approval Mode") or by an Intune Settings Catalog policy and requires a reboot to take effect [@ms-admin-protection, @call4cloud-osint].

Per-elevation use. appinfo.dll's RAiLaunchAdminProcess RPC endpoint reads TypeOfAdminApprovalMode. When the value is 2, it walks the forward link to find the calling user's SMAA, launches consent.exe on the secure desktop in credential prompt mode (not Yes/No), authenticates the primary user via Windows Hello (PIN, fingerprint, face, or password fallback), asks the kernel to ask LSA for a fresh primary token for the SMAA in a brand-new logon session, and calls CreateProcessAsUser with that token, the user's requested executable, and the SMAA's profile environment [@ms-developer-blog-2025, @ms-admin-protection, @forshaw-pz-jan2026]. The credential-less LSA logon at the heart of step three of this beat is walked in §7.

Teardown. When the elevated process exits, the SMAA's token handle goes out of scope. The logon session is reaped. The elevated profile directory remains on disk at C:\Users\ADMIN_<random>\ -- it has to, to preserve per-elevation user state across reboots -- but the live admin token does not. There is no persistent High-integrity process running between elevations [@ms-developer-blog-2025].

flowchart TD Start[Policy enabled: TypeOfAdminApprovalMode = 2] --> Provision Provision[samsrv.dll: CreateShadowAdminAccount per local admin] --> Naming Naming[CreateRandomShadowAdminAccountName -> ADMIN_random] --> AddGroup AddGroup[AddAccountToLocalAdministratorsGroup] --> Link Link[SAM linkage: ShadowAccountForwardLinkSid /
ShadowAccountBackLinkSid] --> Idle[SMAA exists, no token live] Idle -->|Each elevation| RPC[appinfo.dll: RAiLaunchAdminProcess] RPC --> Prompt[consent.exe: Hello credential prompt] Prompt --> LSA[Kernel asks LSA: credential-less logon for SMAA] LSA --> Run[CreateProcessAsUser with SMAA token] Run -->|Process exits| Teardown[Token handle released;
logon session reaped] Teardown --> Idle Windows creates a temporary isolated admin token to get the job done. This temporary token is immediately destroyed once the task is complete, ensuring that admin privileges do not persist. -- David Weston, Microsoft Ignite 2024 keynote, November 19, 2024 [@bleepingcomputer-2024]

Key idea: The single design decision behind Administrator Protection: the elevated and unelevated halves of an administrator must be different accounts. Different SID, different profile, different HKCU, different logon session, different DOS device object directory. The shared-resource attacks of the UAC bypass canon cannot persist if there are no shared resources.

The mechanism is now described. The next section walks it at function-name granularity for a single elevation, end to end -- and in particular, the credential-less LSA logon at step six that does the load-bearing work of minting the SMAA token without any SMAA credential.

7. The elevation pipeline end to end

Walk a single elevation. Nine steps.

The caller invokes ShellExecute or CreateProcess with an elevation request. For the shell-launched case the user right-clicks an executable and selects "Run as administrator"; the same RPC endpoint serves manifest-declared requestedExecutionLevel = "requireAdministrator" callers and Elevation:Administrator!new:<CLSID> COM moniker requests.
appinfo.dll's RAiLaunchAdminProcess RPC endpoint, hosted inside the Application Information service in svchost.exe, receives the call [@ms-uac-how-it-works].
appinfo reads HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\TypeOfAdminApprovalMode.
If the value is 2 (Admin Approval Mode with Administrator Protection), appinfo reads the calling user's SAM record, locates the ShadowAccountForwardLinkSid attribute, and validates the corresponding ShadowAccountBackLinkSid on the SMAA's SAM record. The linkage check is what binds a given elevated process to a given primary user; without both attributes pointing at each other, the elevation is refused [@call4cloud-osint].
appinfo launches consent.exe on the secure desktop in credential prompt mode rather than the classic Yes/No mode. The prompt asks the primary user to authenticate via Windows Hello (PIN, fingerprint, face, or password fallback), not the SMAA. The SMAA has no human credentials. The Windows Developer Blog states the property explicitly [@ms-developer-blog-2025], and Forshaw's January 2026 post restates it in operational terms: "The user does not need to know the credentials for the shadow administrator as there aren't any. Instead UAC can be configured to prompt for the limited user's credentials, including using biometrics if desired" [@forshaw-pz-jan2026].
On a positive Hello result, appinfo.dll -- running as NT AUTHORITY\SYSTEM inside the Application Information service -- asks the kernel to ask LSA for a fresh primary access token for the SMAA's SID in a brand-new logon session. The LSA logon is credential-less. The kernel asks LSA to authenticate "a new instance of the shadow administrator," and LSA fulfils the request without any SMAA credential because the SMAA has no credential to verify. The trust architecture mirrors the way the Service Control Manager asks LSA for service-account tokens: SCM is trusted to ask for the token; LSA mints it on the strength of the request rather than on the strength of any credential. In Administrator Protection, appinfo.dll is the trusted requester, and its request is gated on the user-side Hello result it received in step 5. The Forshaw verbatim that anchors the mechanism is below this section [@forshaw-pz-jan2026, @ms-developer-blog-2025].
appinfo calls CreateProcessAsUser with the SMAA token, the user's requested executable, and the SMAA's profile environment block (USERPROFILE=C:\Users\ADMIN_<random>, USERNAME=ADMIN_<random>, the SMAA's NTUSER.DAT mapped as HKCU).
The new process loads at High integrity, holding the SMAA's primary token, in a fresh logon session with a freshly minted authentication-ID LUID. The DOS device directory at \Sessions\0\DosDevices\<LUID> does not yet exist; the kernel will create it on first reference.
Subsequent SeAccessCheck calls on system objects evaluate against the SMAA's local Administrators group membership and succeed. The elevated process can write to HKLM, modify program files, install services, load WHQL-signed drivers (subject to App Control for Business and HVCI), and otherwise behave as a member of the Administrators group [@ms-developer-blog-2025].

The mechanism by which the Local Security Authority mints a primary access token for the SMAA without verifying any SMAA credential. `appinfo.dll`, running as `NT AUTHORITY\SYSTEM` inside the Application Information service, requests the logon on the SMAA's behalf after the primary user has succeeded against the Hello credential gate. LSA fulfils the request because the *requester* is trusted; the architecture mirrors the way the Service Control Manager requests service-account tokens. The "credential-less" label is descriptive of the SMAA side of the exchange: the SMAA never has a human credential to verify, so LSA cannot and does not ask for one [@forshaw-pz-jan2026, @ms-developer-blog-2025].

The trust architecture is not new in Administrator Protection. The Service Control Manager has asked LSA for service-account tokens since Windows NT 3.1 in 1993; LSA accepts the request because SCM is the trusted requester, not because the service account presented a credential. Administrator Protection generalises the same pattern to elevation: appinfo.dll is the trusted requester, and the SMAA is its functional analogue of a service account. What is new is the user-side gate -- the trusted requester only makes the request after a positive Hello result on the primary user's credential.

in Administrator Protection the kernel calls into the LSA and authenticates a new instance of the shadow administrator. This results in every token returned from `TokenLinkedToken` having a unique logon session, and thus does not currently have the DOS device object directory created. -- James Forshaw, *Bypassing Windows Administrator Protection*, Google Project Zero, January 26, 2026 [@forshaw-pz-jan2026]

The "unique logon session" property in Forshaw's quote is exactly the structural property the lazy-DOS-device-directory bypass exploits, and §12 walks that exploit in full. For now, the load-bearing observation is the credential-less logon itself: the SMAA token is real, the logon session is real, the integrity level is real, but no SMAA credential ever changes hands. The trust is in the requester, gated by a Hello gesture from the primary user.

sequenceDiagram participant User as User shell (primary admin filtered token) participant AppInfo as appinfo.dll (NT AUTHORITY\SYSTEM) participant SAM as samsrv.dll / SAM database participant Consent as consent.exe (secure desktop) participant Hello as Windows Hello / TPM participant LSA as LSASS participant Elev as Elevated SMAA process

User->>AppInfo: ShellExecute "as admin"
AppInfo->>AppInfo: RAiLaunchAdminProcess RPC
AppInfo->>AppInfo: Read TypeOfAdminApprovalMode = 2
AppInfo->>SAM: Resolve ShadowAccountForwardLinkSid
SAM-->>AppInfo: SMAA SID + backlink check OK
AppInfo->>Consent: Launch consent.exe (credential mode)
Consent->>Hello: Request Hello gesture for primary user
Hello-->>Consent: PIN / biometric / password verified
Consent-->>AppInfo: Approved
AppInfo->>LSA: Credential-less logon for SMAA (trusted-requester pattern)
LSA-->>AppInfo: Fresh SMAA primary token and fresh LUID
AppInfo->>Elev: CreateProcessAsUser with SMAA token and profile
Note over Elev: Different SID and USERPROFILE and HKCU and LUID
Note over Elev: Integrity level High -- DOS device dir not yet created

A practical illustration of the shift, displayed as the diff between the pre-AP and post-AP elevated console session.

{` // Modelled output of 'whoami /all' run from an elevated console. // Before: TypeOfAdminApprovalMode = 1 (classic UAC). // After: TypeOfAdminApprovalMode = 2 (Administrator Protection).

const before = { user: 'CONTOSO\\alice', sid: 'S-1-5-21-123456789-987654321-1122334455-1001', profile: 'C:\\Users\\alice', authId: '0x3e7:0x000abcde', integrity: 'S-1-16-12288 (High)', groups: ['BUILTIN\\Administrators (Enabled)'] };

const after = { user: 'WIN11-PC\\ADMIN_9f2c7e1bdc4a8033', sid: 'S-1-5-21-123456789-987654321-1122334455-1051', profile: 'C:\\Users\\ADMIN_9f2c7e1bdc4a8033', authId: '0x3e7:0x000abf42', integrity: 'S-1-16-12288 (High)', groups: ['BUILTIN\\Administrators (Enabled)'], shadowBacklink: 'CONTOSO\\alice' };

console.log('Different user name:', before.user !== after.user); console.log('Different SID:', before.sid !== after.sid); console.log('Different profile:', before.profile !== after.profile); console.log('Different LUID:', before.authId !== after.authId); console.log('Same integrity:', before.integrity === after.integrity); `}

The pipeline is now a single chain of named function calls. The next section asks what changed about the four shared-resource properties from §3, and which UAC-bypass family each fix forecloses.

8. The four shared-resources fixes, precisely

Each of the four shared resources from §3 maps to a precise Administrator Protection fix, and each fix maps to a named UAC-era attack class it forecloses.

Shared resource (UAC)	Administrator Protection fix	UAC-era attack class foreclosed
Same SID across both tokens	SMAA has its own SID; no shared user identity	Same-user file and registry ACE confusion
Same `%USERPROFILE%`	SMAA has `C:\Users\ADMIN_<random>\`	DLL side-load family (sysprep / CRYPTBASE)
Same `HKCU` hive	SMAA has its own `NTUSER.DAT`	Registry-hijack family (eventvwr, fodhelper, sdclt)
Same logon-session LUID	SMAA gets a fresh LUID per elevation	Token-theft via `TokenLinkedToken`; logon-session DOS device hijack

Profile separation. The SMAA owns its own %USERPROFILE% directory tree under C:\Users\ADMIN_<random>\. Files created by elevated processes land there by default. Library folder divergence is the most visible consequence: an elevated Notepad's File > Save dialog opens at the SMAA's Documents, not the primary user's. The primary user cannot see those files in their own Explorer without explicit cross-profile navigation. The structural property that closes is the writable-shared-directory premise of the Davidson 2009 DLL side-load family. Sysprep + CRYPTBASE was a profile-shared attack; without a shared profile, the elevated binary searches a different directory tree from the one the limited user can write to [@ms-developer-blog-2025].

Registry separation. The SMAA's HKCU maps to the SMAA's NTUSER.DAT, not the primary user's. When eventvwr.exe, running in an SMAA process, queries HKCU\Software\Classes\mscfile\shell\open\command, it reads the SMAA's hive, not the primary user's. The primary user has no write access to the SMAA's NTUSER.DAT. The entire registry-hijack family -- eventvwr / mscfile [@enigma0x3-2016-eventvwr], fodhelper / ms-settings, sdclt / IsolatedCommand [@enigma0x3-2017-sdclt], sdclt / App Paths [@enigma0x3-2017-app-paths] -- forecloses on the same property: the elevated binary's HKCU lookup walks a hive the attacker does not control [@ms-developer-blog-2025].

Logon-session separation. Every SMAA elevation gets a fresh authentication-ID LUID. The Local Security Authority allocates a new logon session for each elevation; when the elevated process exits, the session is reaped. Per-logon-session kernel resource caches, including the DOS device object directory at \Sessions\0\DosDevices\<LUID> and the credential cache, do not flow across the boundary. Token handles cannot be reused. Drive-letter overrides under the limited user's logon session do not appear in the SMAA's session [@forshaw-pz-jan2026].

No auto-elevation. The autoElevate=true manifest attribute is no longer honoured by appinfo.dll under TypeOfAdminApprovalMode = 2. Every elevation that previously went silent now prompts. The Windows Developer Blog states the change directly: "With administrator protection, all auto-elevations in Windows are removed and users need to interactively authorize every admin operation" [@ms-developer-blog-2025]. Forshaw's January 2026 framing of the consequence: "as auto-elevation is no longer permitted they will always show a prompt, therefore these are not considered bypasses" [@forshaw-pz-jan2026]. This is the single most consequential fix in the design. The auto-elevation whitelist was the bypass; removing the whitelist eliminates the class at the source, including the entire silent-elevation primitive class that Forshaw's older RAiProcessRunOnce research relied on.

Multi-user separation is the original UNIX privilege model. The `root` user holds privilege; ordinary users do not; the boundary between them is the file-permission system enforced by the kernel. Windows NT shipped the same primitives in 1993 -- discretionary access control lists on every securable object, per-user profiles, multi-user logon sessions -- but the surrounding culture treated Administrator-as-default as the path of least resistance. The architectural sophistication in Administrator Protection is in *linkage* (the SAM forward / back attributes), *lifecycle* (provisioning on policy enable, teardown on process exit), and *enforcement* (removal of auto-elevation as a mechanism). The primitives themselves are old.

The four fixes share a property. Each one breaks a shared resource that an attacker depends on. But there is one more piece of the redesign that has not yet been described: the prompt itself is no longer a Yes/No click-through. The next section asks what happens when the consent UI becomes a credential.

9. Windows Hello as the consent gate

The classic UAC prompt is a Yes / No on the secure desktop. Administrator Protection turns the prompt into a credential prompt for the primary user's Windows Hello: a PIN, a fingerprint, a face match, or a password fallback. The credential is for the primary user, not the SMAA, because the SMAA has no human credentials; the Hello verification is what authorises the cross-profile elevation [@ms-admin-protection, @ms-developer-blog-2025, @forshaw-pz-jan2026].

To talk precisely about what the gate does, name the primitive it closes. Under classic UAC, the consent prompt treated a click on the secure desktop as sufficient evidence of consent; physical presence was the entire evidence requirement. That primitive shows up in three sub-cases that the UAC literature has documented for two decades.

The primitive by which the legacy UAC consent dialog accepted a click on the secure desktop as sufficient evidence of consent, without verifying *who* clicked. Three operational sub-cases follow. *Unattended-session click-through* -- an attacker (or co-located third party) with brief physical access to an unlocked screen showing a UAC prompt clicks Yes on the presumption that whoever is at the keyboard is the legitimate user. *Habituated-click click-through* -- the legitimate user has clicked Yes on hundreds of UAC prompts and clicks one more without conscious attention. *Pretext click-through* -- a malicious application argues a legitimate-looking case to the user and elicits the Yes click. Administrator Protection's credential gate cost-raises all three sub-cases without fully eliminating any [@forshaw-pz-jan2026, @ms-admin-protection].

Unattended-session click-through. An attacker who walks up to an unlocked screen showing a UAC prompt can click Yes and elevate. The legitimate user has authenticated; the prompt assumes the person at the keyboard is the legitimate user. Post-AP, the click is not sufficient. The Hello biometric or PIN is required, and the attacker (who does not know either) cannot complete the gesture. Microsoft's Ignite 2024 framing addresses this primitive implicitly with "elevation rights only when needed" and "interactively authorize every admin operation" [@bleepingcomputer-2024].

Habituated-click click-through. A user who has clicked Yes on hundreds of UAC prompts over the course of a year clicks Yes on a malicious one as reflex. The classic UAC prompt requires no attentional engagement beyond physical presence and a click. Hello's gesture (a four-digit PIN entry, a fingerprint press, a face-recognition glance) is higher-friction and harder to perform inattentively. The Windows Developer Blog frames the property as "just-in-time administrator privileges, incorporating Windows Hello to enhance both security and user convenience" [@ms-developer-blog-2025].

Pretext click-through. A malicious application that argues its case to the user -- a fake installer, a re-skinned setup utility, a Trojan masquerading as a legitimate update -- can elicit a Yes click pre-AP. Post-AP, the user is also asked for a credential, which is a stronger user-side check. The user is more likely to interrogate "why am I being asked for my PIN again?" than "why is a prompt appearing?" Microsoft Learn captures the intent as "users are aware of potentially harmful actions before they occur, providing an extra layer of defense against threats" [@ms-admin-protection].

None of the three sub-cases is fully eliminated. Forshaw is explicit that visible-prompt bypasses are not classified as security vulnerabilities by Microsoft's design-document position: bypasses that result in a visible prompt are not security bulletins, because the user could equivalently have launched the prompt themselves [@forshaw-pz-jan2026]. What the gate does is cost-raise each sub-case. The unattended-screen attack requires a stolen PIN or coerced biometric. The habituated user must perform a gesture they cannot perform inattentively. The pretext attack must justify the second authentication, not just the first.

What it does not close is worth naming, because three primitives that look like they belong on the credential gate's account sheet were already closed by independent mechanisms, and the article should say so to avoid the common over-attribution mistake.

Synthetic-keystroke SendInput against consent.exe. Already closed by UIPI in Vista 2006, and doubly closed by the secure-desktop switch to Winsta0\Winlogon. Even UI Access processes -- whose purpose is to bypass UIPI for accessibility -- cannot reach into the secure desktop [@forshaw-pz-feb2026].
Headless UI Automation against the prompt. Same UIPI / secure-desktop boundary closes it. Redundant with respect to the credential gate.
CVE-2019-1388-class UI-interaction paths surfaced through the prompt's own UI. Closed by Microsoft's November 2019 HHCtrl patch and the cert-viewer UI redesign, prior to any Administrator Protection development [@nvd-cve-2019-1388].

The credential is hardware-rooted via TPM or Pluton on capable hardware. The PIN is unsealed only under the user's gesture; the biometric flows through Enhanced Sign-in Security (ESS) on capable hardware; the credential itself never leaves the Trusted Platform Module or Pluton enclave when ESS is engaged [@ms-windows-hello-ess]. The detail of the Hello architecture itself -- FIDO2 attestation, the ngc protector, the ESS isolation path through the Secure Kernel -- belongs to the Windows Hello article in this series, and is not re-derived here.

The new risk the gate does not close is the obvious one. Phishing the prompt now phishes a real credential, not just consent. A malicious application that can convince the user to authenticate on its behalf gets the elevation the user would otherwise have given to a legitimate request. The credential remains hardware-rooted and is not exfiltrated to the malware, but the elevation produces a working SMAA token in the attacker's process. This is the surface §15 carries forward to open problems.

Key idea: The credential gate closes one specific primitive: consent-without-identity-verification. It cost-raises three sub-cases (unattended-session, habituated-click, pretext click-through) without eliminating any. The structural boundary is profile separation plus fresh logon session plus auto-elevation removal; the credential gate is the fourth, defence-in-depth, property that ensures the boundary cannot be silently crossed by anyone holding only the limited user's physical access.

The prompt is a credential gate, but it remains a UI element. The next section asks how this elevation model compares to what other operating systems do.

10. Competing approaches: what other operating systems do

Three one-paragraph treatments. The article does not re-derive each system; it positions Administrator Protection against the field.

Linux: sudo plus PolKit pkexec plus PAM modules. The authority model on Linux is file-based. /etc/sudoers (or its LDAP equivalent) is the policy table; the sudoers plugin reads it and decides whether to permit a given user to run a given command [@sudo-ws-sudoers]. PolKit -- polkitd and its authentication-agent helpers -- is the parallel mechanism for GUI privileged-service requests, with actions and mechanisms separated in the polkit configuration files [@polkit-docs]. Biometric integration arrives through the PAM stack: pam_fprintd for fingerprint, pam_u2f for FIDO2 tokens, pam_yubico for Yubikeys. There is no profile separation by default; sudo -i switches HOME to root's home directory but does not separate per-elevation. The model is per-command authorisation, not per-account isolation.

macOS: Authorization Services plus Touch ID via pam_tid. GUI elevation prompts are gated by authorizationdb, a property-list-format policy database whose rules name which credentials (admin password, Touch ID, system-wide entitlements) authorise which actions [@apple-auth-services]. Touch ID is verified by the Secure Enclave Processor; the credential never leaves the SEP, and Authorization Services integrates with pam_tid to allow sudo invocations to use the gesture [@apple-pam-tid]. There is no separate admin profile; Transparency, Consent, and Control (TCC) guards privileged resource access at the per-action level, not the per-profile level. The Mac architecture privileges hardware-rooted consent (Touch ID, Secure Enclave) over account separation.

Microsoft's own sudo.exe (Windows 11 24H2). An inbox terminal transport that triggers the existing UAC or Administrator Protection pipeline; not an alternative to either [@ms-sudo-docs]. The forceNewWindow mode opens an elevated console in a new window. The disableInput mode keeps the elevated console in the current window but blocks keyboard input to it from the unelevated terminal. The normal (inline) mode preserves POSIX-style pipes between the unelevated and elevated processes. Microsoft Learn warns explicitly about the inline mode: "Sudo for Windows can be used as a potential escalation of privilege vector when enabled in certain configurations" [@ms-sudo-docs]. The mechanism is RPC between the unelevated and elevated sudo.exe processes; the elevation itself still goes through appinfo.dll.

Intune Endpoint Privilege Management (EPM). Cloud-policy-driven virtual-account elevation [@ms-epm-overview]. EPM performs elevation via a virtual account that is not a member of the local Administrators group; the elevation rights are conferred only for the duration of the policy-permitted action. Three elevation modes are available: Automatic (no user interaction), User-confirmed (a prompt), and Elevate as Current User (the action runs as the user's elevated identity rather than the virtual account). EPM is architecturally complementary to Administrator Protection: EPM is the enterprise policy story, Administrator Protection is the per-device architecture story. The two can coexist on the same device.

The distinguishing property of Administrator Protection in this comparison is whole-profile separation: the SMAA's own profile, the SMAA's own HKCU, the SMAA's own library folders, plus a fresh logon session per elevation. Neither Linux sudo nor macOS Authorization Services provides that property as a default desktop primitive. EPM provides per-elevation isolation via the virtual account but does not give the elevated process a persistent profile, which is what makes Administrator Protection's compatibility story so different from EPM's.

Administrator Protection is the architecturally tightest desktop elevation model now in production. The next section asks where the boundary still leaks.

11. Theoretical limits: what Administrator Protection cannot fix

Four structural ceilings.

Showing a prompt is not crossing the boundary. Microsoft's design position is explicit: bypasses that result in a visible elevation prompt are not security bulletins, because the user could equivalently have right-clicked "Run as administrator." Forshaw's January 2026 post states the position verbatim: "I expect that malware will still be able to get administrator privileges even if that's just by forcing a user to accept the elevation prompt" [@forshaw-pz-jan2026]. The operational consequence is that social-engineering the consent dialog remains a structural attack surface. The prompt is a UI element. The boundary is the credential gate. The gate is only as strong as the user's resistance to whatever pretext induces them to authenticate.

The MSRC servicing-criteria definition of a security boundary: a logical separation between code or data of different trust levels, intended to be enforced by the operating system and accompanied by a Microsoft commitment to issue a security update when an unauthorised crossing is found. UAC under the classic split-token model is classified as a *security feature*, not a boundary; bypasses receive quality-fix attention but not security-bulletin attention. Administrator Protection is the first elevation mechanism classified as a security boundary, with bulletin-grade fixes when it fails [@msrc-servicing-criteria, @forshaw-pz-jan2026].

Admin equals kernel. Once code is running inside an SMAA elevated process, it has the local Administrators group; it can write to HKLM; it can install services; it can load WHQL-signed drivers; it can call into kernel-mode interfaces gated by SeLoadDriverPrivilege and the App Control for Business policy. The MSRC servicing-criteria position that "admin-to-kernel is not a security boundary" continues to apply inside the SMAA [@msrc-servicing-criteria]. Administrator Protection makes the path to admin into a boundary; it does not change the relationship between admin and kernel. Driver-loading controls remain the domain of WHQL signing, the Microsoft Vulnerable Driver Blocklist (default-on in Windows 11 since the 2022 update), App Control for Business policies, and Hypervisor-protected Code Integrity (HVCI) [@ms-vuln-driver-blocklist]. The App Identity article in this series covers the App Control mechanism in detail.

The SMAA is in the local Administrators group. Discretionary access control list-based exposures of admin-only resources -- CREATOR OWNER ACEs on persistent objects, world-writable DACLs on certain \Sessions\0\DosDevices entries, default-permissive ACLs on a handful of legacy registry trees -- still grant the SMAA full access. The boundary is between standard user and SMAA, not between SMAA and SYSTEM. The SMAA is a high-privilege actor inside the operating system; the relationship between it and the rest of the privileged surface is unchanged.

Out of scope per Microsoft Learn. Remote logon, roaming profiles, backup-admin accounts, Managed Service Accounts and group Managed Service Accounts (MSAs and gMSAs), virtual accounts for services, and domain-admin scenarios are explicitly outside the Administrator Protection model in its current form [@ms-admin-protection]. The feature is local-machine-only, interactive-admin-only. Domain administrators who log into a workstation will not see the SMAA path; service accounts under LOCAL SERVICE, NETWORK SERVICE, or IIS_IUSRS are unaffected.

Key idea: A genuine architectural ceiling on consent-prompt elevation: the prompt is a UI element; the boundary is the credential gate; the gate is only as strong as the user's resistance to social engineering. Closing the gap requires out-of-band consent (smartcard, phone push) or per-action policy without human consent in the loop (EPM's automatic mode). Neither is the default.

Four limits, four sentences. The next section walks the concrete evidence of what actually leaked in the pre-GA Insider Preview builds, and what Microsoft did about it.

12. Forshaw's nine bypasses, classified

Between October 2024, when Administrator Protection first appeared in Insider Preview build 27718, and October 2025, when KB5067036 made the feature available on stable Windows, James Forshaw of Google Project Zero audited the mechanism and found nine separate silent-bypass paths. Microsoft fixed all nine -- either in the KB5067036 ship or in subsequent security bulletins [@forshaw-pz-jan2026]. The fact pattern is the structural confirmation that Administrator Protection is now treated as a security boundary. Under the UAC classification, none of those nine would have received CVEs. Each one would have been a quality bug. The bypass canon ran for twenty years without bulletins. The fact that the first cohort of Administrator Protection bypasses produced nine bulletin-eligible fixes is exactly the change in posture the classification change implies.

All the issues that I reported to Microsoft have been fixed, either prior to the feature being officially released (in optional update KB5067036) or as subsequent security bulletins. -- James Forshaw, *Bypassing Windows Administrator Protection*, Google Project Zero, January 26, 2026 [@forshaw-pz-jan2026]

Walk the nine as three classes.

The lazy DOS device directory hijack

The single most interesting vulnerability in the feature's history; Forshaw's January 26, 2026 deep analysis [@forshaw-pz-jan2026]; Project Zero issue 432313668 [@pz-issue-432313668]. The mechanism turns on a behaviour change Administrator Protection itself introduced. Every SMAA elevation gets a fresh logon session, which means the per-logon-session DOS device object directory at \Sessions\0\DosDevices\<LUID> is not created at SMAA logon time. The kernel routine SeGetTokenDeviceMap creates the directory lazily, on the first reference. The owner of the new directory is the owner of the access token that triggered the creation [@forshaw-pz-jan2026, @theregister-2026].

The impersonation level (`SecurityIdentification`) at which an impersonating thread can read security information about the impersonated token -- the SID set, the privilege set -- but cannot perform privileged operations or open kernel objects as the impersonated user. The kernel allows access checks to consult an identification-level token for *reading* the security information; certain code paths inadvertently use that information for *granting* operations, which is the structural primitive Forshaw's lazy DOS device directory exploit depends on [@forshaw-pz-jan2026].

The SECURITY_IMPERSONATION_LEVEL enumeration in winnt.h defines four levels in ascending order: SecurityAnonymous (value 0), SecurityIdentification (1), SecurityImpersonation (2), SecurityDelegation (3). SecurityIdentification is the second-lowest -- it sits one above SecurityAnonymous -- and is the level Windows uses when it wants to ask the kernel "what would this token be allowed to do?" without actually doing the operation. The trap is when a code path that runs as the caller uses an identification-level impersonation to read a token property -- here, the linked-token field -- and the resulting object inherits the caller's owner SID rather than the impersonated token's.

The exploit chain. An attacker running as the primary user (filtered token, Medium integrity) starts an elevation. Before the SMAA process touches its DOS device directory, the attacker impersonates the SMAA's TokenLinkedToken at identification level and triggers a code path that walks the directory. The kernel creates \Sessions\0\DosDevices\<SMAA_LUID> lazily; in the affected code path, the owner of the new directory becomes the attacker's primary token's owner SID rather than the SMAA's.

The attacker plants a C: symbolic link inside the directory pointing at an attacker-controlled location. When the elevated SMAA process loads its DLLs, the resolution walks \Sessions\0\DosDevices\<SMAA_LUID>\C: first; the symlink redirects the load to the attacker's directory; the attacker's DLL runs in the High-integrity SMAA process [@forshaw-pz-jan2026].

sequenceDiagram participant Att as Attacker (limited user) participant Kern as "Kernel (SeGetTokenDeviceMap)" participant SMAA as SMAA elevated process

Note over SMAA: Fresh logon session -- DOS device dir not yet created
Att->>Att: Impersonate SMAA TokenLinkedToken at Identification level
Att->>Kern: Reference \Sessions\0\DosDevices\<SMAA_LUID>
Kern->>Kern: Lazy-create directory
Note over Kern: Owner SID inherited from impersonating token
Att->>Kern: Create C: symlink under attacker control
SMAA->>Kern: Resolve C: at first DLL load
Kern-->>SMAA: Returns attacker symlink target
SMAA->>SMAA: Load attacker DLL at High integrity

What makes this bypass extraordinary is that it is caused by the feature's design. Pre-Administrator-Protection, the user's primary logon session was created at desktop logon and the DOS device directory existed before any elevation. Lazy directory creation never came up. The SMAA design's "fresh logon session per elevation" property -- the same property Forshaw's January 2026 pull-quote in §7 establishes via the credential-less LSA logon -- is exactly the precondition the lazy-creation path exploits.

Microsoft's pre-GA fix has two parts. First, the manifest-parsing access check uses the SYSTEM-impersonating-the-low-user identity rather than the user's primary token. Second, the DOS device directory is materialised with the correct owner before any user-controlled code path can trigger the lazy-creation path [@forshaw-pz-jan2026]. The Register's coverage of the disclosure noted "the most notable of the nine bugs he reported was a Logon Sessions flaw that relied upon five different Windows behaviors. He added that he likely only found it because he was previously familiar with the OS's 'weird behavior when creating the DOS device object directory'" [@theregister-2026].

The five UI Access bypasses

Forshaw's February 2026 post details the second class, comprising five of the nine bypasses [@forshaw-pz-feb2026]. UI Access is a token flag retrofitted in Vista to let accessibility applications cross UIPI. To qualify, an executable needs three things: a manifest declaring uiAccess="true", a trusted code-signing certificate, and an installation location under an administrator-only directory (typically %ProgramFiles%). The Application Information service's RAiLaunchAdminProcess endpoint launches qualifying UI Access processes without showing the consent prompt, on the theory that the three-criteria check is itself sufficient evidence of administrator approval [@forshaw-pz-feb2026].

The token flag (`TOKEN_UIACCESS`) that allows a process to interact with windows of higher integrity level than its own, bypassing User Interface Privilege Isolation. UI Access is meant for accessibility software (screen readers, on-screen keyboards) that needs to interact with elevated UI. To qualify, an executable must carry a `uiAccess="true"` manifest, a trusted code-signing certificate, and an administrator-only installation directory; qualifying processes run without showing the consent prompt and at integrity level High [@forshaw-pz-feb2026].

Under classic UAC, a UI Access process ran with the filtered standard-user token bumped from Medium to High integrity -- not with the full admin token. Forshaw's February 2026 post states the mechanism verbatim: "the service will take a copy of the caller's access token, enable the UI Access flag and increase the integrity level... If the caller is a limited user of an UAC administrator it will set the integrity level to High" [@forshaw-pz-feb2026].

Under Administrator Protection, the pre-GA design preserved that behaviour unchanged: the UI Access process inherited the limited user's primary token (not the SMAA's), bumped to High integrity. That decision was the structural flaw. A High-integrity process under the limited user can interact with the SMAA's windows whenever a High-integrity SMAA process exists on the same desktop, send messages to them, read clipboard data, and -- through GetProcessHandleFromHwnd -- obtain a process handle on the SMAA process that lets the limited-user process inject code into it.

The five UI Access variants exploit different sub-categories of the same structural property. The Quick Assist binary, a remote assistance application on Windows 10 and 11 that carries the uiAccess flag, is one such variant; R41N3RZUF477 published a public proof-of-concept that exploits the BrowserExecutableFolder group policy to make Quick Assist load WebView2 from an attacker-controlled directory [@quickassist-bypass]. The remaining four exploit, respectively, weaknesses in the secure-application-directory check, the manifest parsing routine, COM marshalling in UI Access contexts, and message-only window handling [@forshaw-pz-feb2026].

Microsoft's pre-GA fix is structural: UI Access processes no longer run as the limited user. They are created with a filtered copy of the SMAA's token (the SMAA's SID, the SMAA's profile, but with SeLoadDriverPrivilege and similar removed). Profile separation is restored at the cost of a more complex token-creation path [@forshaw-pz-feb2026].

The remaining three: implementation flaws

The third class -- three bypasses described by Forshaw only as "implementation flaws and long-standing UAC issues" -- is not detailed publicly [@forshaw-pz-jan2026]. The article does not invent details. Forshaw names the category and cites the framing; the engineering specifics are presumably in Microsoft Security Response Center advisories or are still under disclosure. What can be said is that two of the three appear from Forshaw's framing to be UAC-era bugs that Administrator Protection inherited rather than introduced, and one is an Administrator-Protection-specific implementation flaw.

The bypass canon ran for twenty years without bulletins. The fact that all nine pre-GA Administrator Protection bypasses received fixes -- including a deep one rooted in the feature itself -- is the structural confirmation that the elevation path is now a boundary. The next section asks why Microsoft pulled the feature in December 2025.

13. The compatibility surface and the December 2025 revert

About one month after KB5067036 made Administrator Protection available, Microsoft pulled it. Forshaw, writing in January 2026, gives the canonical attribution: "As of 1st December 2025 the Administrator Protection feature has been disabled by Microsoft while an application compatibility issue is dealt with. The issue is unlikely to be related to anything described in this blog post so the analysis doesn't change" [@forshaw-pz-jan2026]. Microsoft Learn confirms: "The feature previously listed in the October 2025 non-security update (KB5067036) has been reverted and will roll out at a later date" [@ms-admin-protection, @ms-kb5067036].The November 2025 KB5067036 amendment is worth knowing. Microsoft included an unrelated fix for an AutoCAD MSI-repair UAC-prompt regression in the same cumulative; that fix shipped and was not reverted. The WebView2 installer regression is what caused the Administrator Protection revert specifically [@ms-kb5067036].

The structural causes. The Windows Developer Blog (May 2025) [@ms-developer-blog-2025] enumerates the surface where applications break under the SMAA model.

Single sign-on does not cross. Domain and Microsoft Entra credentials cached for the primary user's session are not available inside the SMAA's session. Any elevated process touching Microsoft Graph, Entra ID, or Kerberos-protected resources must re-authenticate. The login dialogs an elevated installer triggers are not failures of the application; they are consequences of the separated logon session.
Network drives do not carry. Drive-mapping in the primary user's session is not inherited by the SMAA. Installers that mount network shares to install per-machine components break. The workaround for affected installers is to use UNC paths directly rather than drive letters.
Library folders diverge. Files saved to Documents, Desktop, Downloads, or Pictures from an elevated app land in C:\Users\ADMIN_<random>\ rather than the primary user's home. A user clicks Save in an elevated text editor and saves to "Documents"; from their own Explorer, the file is invisible.
HKCU diverges. Application settings -- theme, recent-files lists, per-user COM registrations, last-opened paths -- live in the SMAA's HKCU, not the primary user's. The canonical example in Microsoft's documentation is Notepad's dark-mode theme [@ms-developer-blog-2025]: the primary user sets the theme; an elevated Notepad opens in the default theme; the two sessions never agree.
WebView2 installers fail. The error message "Microsoft Edge can't read and write to its data directory" is the recognisable symptom of an installer that assumes one shared profile. The WebView2 runtime stores per-user state in AppData\Local\Microsoft\EdgeWebView\ under whichever profile is active at install time; if the runtime is installed under the SMAA's profile and then used by an unelevated application running as the primary user, the data-directory write fails. This is the regression that triggered the December 2025 revert.
Hyper-V and WSL incompatibilities. Microsoft Learn explicitly tells IT administrators not to enable Administrator Protection on devices that require Hyper-V or WSL [@ms-admin-protection].
Visual Studio. Microsoft's own development environment is "not supported in such a configuration" when run elevated. Extensions don't carry; settings don't carry; project-dialog paths point at the SMAA's profile rather than the developer's actual workspace.

Note: Microsoft Learn explicitly excludes Hyper-V and WSL devices from the recommended enablement set [@ms-admin-protection]. Symptoms of incorrect enablement include WSL distribution startup failures (the WSL service runs under a different account from the launching user, and the SMAA's logon-session-isolation properties interact badly with WSL's named-pipe communication) and Hyper-V Manager connection errors that are difficult to attribute to the elevation model.

I guess app compatibility is ultimately the problem here, Windows isn't designed for such a radical change. I'd have also liked to have seen this as a separate configurable mode rather than replacing admin-approval completely. -- James Forshaw, *Bypassing Windows Administrator Protection*, Google Project Zero, January 26, 2026 [@forshaw-pz-jan2026] Administrator Protection is the right architecture, and the compatibility surface is the bill of materials for twenty years of admin-as-default assumption. Application developers have written installer logic, theme-persistence code, drive-letter assumptions, and HKCU-shared state into shipping software for two decades, on the structural premise that the elevated process and the unelevated user share a profile. The December 2025 revert is the first iteration's learning round, not a structural failure. The same revert pattern accompanied the Windows Vista UAC rollout in 2006-2007, the Windows 7 auto-elevation introduction in 2009 (which itself softened the Vista prompt fatigue at the cost of the bypass canon), and the Smart App Control rollout in Windows 11 22H2. Microsoft will re-enable Administrator Protection when the WebView2 regression and a handful of installer-pattern fixes have shipped.

The architecture survives audit. The deployment is held back by twenty years of accumulated software assumptions. The next section asks what tools defenders now have that they did not have before.

14. The audit and detection surface

Every privileged operation on a device with Administrator Protection enabled now generates an ETW (Event Tracing for Windows) event in the Microsoft-Windows-LUA provider [@ms-admin-protection]. This is the first time the elevation pipeline itself is the source of a stable, operationally useful audit trail.

The basics.

Provider: Microsoft-Windows-LUA, GUID {93c05d69-51a3-485e-877f-1806a8731346}.
Event ID 15031: Elevation Approved.
Event ID 15032: Elevation Denied or Failed.

Each event carries the caller user SID, the application name and path, the elevation outcome, the SMAA used to host the elevation, and the authentication method (Hello PIN, biometric, password) [@ms-admin-protection]. The authentication method field records the primary user's Hello credential, not the SMAA's; the SMAA's authentication in step 6 of §7 is the credential-less LSA logon and has no method field of its own. The Microsoft Learn-documented logman invocation to capture the trace is short:

The Event Tracing for Windows provider that surfaces Administrator Protection elevation events. Provider GUID `{93c05d69-51a3-485e-877f-1806a8731346}`. Event ID 15031 marks an elevation that succeeded; Event ID 15032 marks an elevation that was denied or failed. Each event carries fields for the caller's SID, the application path, the elevation outcome, the SMAA used, and the authentication method [@ms-admin-protection].

{` // Pseudocode for a detection pipeline that reads ETW Event 15031 // (Administrator Protection elevation approved) and flags unusual // application paths per SMAA correlation key.

const allowList = new Set([ 'C:\\Windows\\System32\\mmc.exe', 'C:\\Windows\\System32\\regedit.exe', 'C:\\Windows\\System32\\cmd.exe', 'C:\\Program Files\\Microsoft VS Code\\Code.exe', ]);

function onEtwEvent(event) { if (event.provider !== 'Microsoft-Windows-LUA') return; if (event.id !== 15031) return;

const smaa = event.fields.shadowAccountName; const app = event.fields.applicationPath; const auth = event.fields.authenticationMethod; const user = event.fields.callerUserSid;

if (!allowList.has(app)) { emit({ severity: 'high', title: 'Unexpected elevation under Administrator Protection', smaa, app, auth, user, hint: 'Was the Hello prompt phished?' }); } } `}

Note: For detection engineers, the ADMIN_<random> name is the highest-value correlation key on the device. It is stable per primary admin (the SMAA name is created once and persists across elevations), distinct from the limited-user SID (the SMAA has its own SID, so user-by-SID correlations and SMAA-by-name correlations are independent axes), and present in every ETW 15031 / 15032 event. A detection rule that groups elevations by SMAA name and flags unexpected application paths is the canonical "someone phished a Hello prompt" alert pattern.

Defenders now have the audit trail they did not have under UAC. The next section asks what residual attack surface survives the SMAA architecture, the Hello gate, and the new audit trail.

15. Open problems: what survives

Five residual attack surfaces, each acknowledged in Microsoft's own documentation, Forshaw's Project Zero posts, or the operational literature on Windows privilege escalation.

The user is still the weak link. Every elevation depends on a human accepting the prompt. The Hello credential gate makes that human's decision more costly to fake than the classic Yes/No, but the gate does not change the fact that a successful prompt is a successful elevation. The three sub-cases of consent-without-identity-verification from §9 -- unattended-session, habituated-click, pretext click-through -- are cost-raised, not closed. Phishing-the-prompt remains a live attack surface and Microsoft does not classify it as a vulnerability [@forshaw-pz-jan2026]. Out-of-band consent -- a phone-push approval channel, a smartcard tap, a separate hardware key tap -- would close the gap; none of these is the Administrator Protection default.

Loopback authentication. The structural property that Windows services authenticate to themselves over the local network stack is independent of the SMAA model. SMB to localhost, Kerberos against the local machine account, NTLM challenge-response between processes on the same box -- these protocols predate UAC and are not changed by Administrator Protection. Forshaw's broader 2022 Kerberos research [@forshaw-2022-rbcd] catalogues the class. The NTLMless article in this series covers SMB signing, Extended Protection for Authentication (EPA), and channel binding mitigations that defenders should pair with Administrator Protection to close the loopback path.

Service-account SeImpersonatePrivilege. The Potato lineage of attacks (cataloged in the Access Control article in this series) runs in service accounts (IIS_IUSRS, LOCAL SERVICE, NETWORK SERVICE), not in interactive admin sessions. Administrator Protection scopes itself to interactive admin elevation; the Potato class is structurally out of scope.

Service-account Potato attacks run inside `IIS_IUSRS`, `LOCAL SERVICE`, and `NETWORK SERVICE` rather than in interactive admin sessions. The attacker has compromised a service that holds `SeImpersonatePrivilege`, then uses one of several primitives (the SSPI / NEGOEX dance, the EFS RPC interface, a printer-spooler endpoint) to coerce a higher-privileged service into authenticating against the attacker's local socket, and impersonates the resulting token. Administrator Protection's promise is around the *interactive elevation* path -- the flow from a logged-in user clicking an installer to an elevated process running. Potato is a separate problem class with its own mitigations: removing `SeImpersonatePrivilege` from service accounts that don't need it, applying EPA, and patching the named primitives one by one.

Driver loading once inside an SMAA elevation. Admin equals kernel applies once a process is running inside the SMAA. Vulnerable-driver loading, kernel-mode code execution, and rootkit installation fall under the §11 "admin equals kernel" ceiling -- WHQL signing, the Vulnerable Driver Blocklist, App Control for Business, and HVCI remain the four-mechanism mitigation surface, with the App Identity article in this series covering the App Control mechanism. Administrator Protection does not change the relationship between admin and kernel; it changes the relationship between standard user and admin.

The Hello credential phishing surface. The prompt now phishes a real credential rather than a click-through approval. A malicious application that successfully argues its case to the user gets a Hello gesture against the primary user's PIN or biometric. The credential remains hardware-rooted; ESS-engaged biometrics never leave the TPM or Pluton enclave; the malware does not learn the PIN. But the malware does get the elevation. The Windows Hello article in this series covers FIDO2 / ESS / PIN architecture hardening. Defender-side mitigation is the ETW 15031 / 15032 detection rule set on unexpected application paths [@ms-admin-protection].

The boundary is real, the audit trail is new, and the five-class residual surface is the next decade of work. The next section turns to operator-side practicalities.

16. Practical guide

Six tips, each tied to one Microsoft Learn or Windows Developer Blog primary source. Remember that, as of December 2025, Microsoft has reverted the rollout and the feature is currently disabled on stable Windows; the guidance below applies once Microsoft re-enables it. The Spoiler below contains the verbatim commands.

Enable. Set TypeOfAdminApprovalMode = 2 via Group Policy ("User Account Control: Configure type of Admin Approval Mode" -> "Admin Approval Mode with Administrator Protection") or via the Intune Settings Catalog OMA-URI. A reboot is required for the new policy to take effect [@ms-admin-protection, @ms-kb5067036].
Verify. Run whoami in an elevated console. The profile name shows ADMIN_<random>. Run whoami /priv to confirm the SMAA has the Administrators group enabled [@ms-admin-protection, @call4cloud-osint].
Capture. Start the ETW trace with the documented logman invocation; filter for Event IDs 15031 and 15032 [@ms-admin-protection]. The provider GUID is stable across builds.
Do not enable on devices that require Hyper-V or WSL. Re-evaluate when Microsoft re-enables the broad rollout [@ms-admin-protection, @forshaw-pz-jan2026].
For application developers, follow the Windows Developer Blog (May 19, 2025) guidance [@ms-developer-blog-2025]: install per-user packages unelevated; use %ProgramFiles% (and accept the elevated install path); avoid context switching during install; avoid sharing files between elevated and unelevated profiles; remove auto-elevation dependencies. The auto-elevation manifest attribute is no longer honoured under Administrator Protection, so any installer that relied on silent elevation needs to be reworked.
For IT admins on already-enabled devices broken by an elevated install: disable Administrator Protection temporarily, reinstall the application unelevated, then re-enable [@ms-developer-blog-2025].

Enable via Group Policy registry value (administrator console, persists across reboots):

# Set TypeOfAdminApprovalMode to 2 (Admin Approval Mode with Administrator Protection)
reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v TypeOfAdminApprovalMode /t REG_DWORD /d 2 /f
# Reboot required:
shutdown /r /t 0

Capture the elevation event trace:

logman start AdminProtectionTrace -p {93c05d69-51a3-485e-877f-1806a8731346} -ets
:: After some elevations:
logman stop AdminProtectionTrace -ets
:: Process the .etl with PerfView, Message Analyzer, or:
wevtutil qe Microsoft-Windows-LUA/Operational /q:"*[System[(EventID=15031 or EventID=15032)]]" /f:text

Verify the SMAA presence after enablement:

Get-LocalUser | Where-Object Name -like 'ADMIN_*'
# After an elevation, run from the elevated console:
whoami
# Expect: WIN11-PC\ADMIN_<random16hex>

Note: The single most common mistake in response to an Administrator Protection compatibility problem is to disable UAC globally by setting EnableLUA = 0. This returns the device to the Windows XP single-token model, removes Mandatory Integrity Control enforcement on application processes, and effectively defeats every layer of UAC and Administrator Protection together. It is universally discouraged. The correct fix is per-application, via manifest, or per-device, via the documented Administrator Protection compatibility list.

Six tips, one boundary, one operational checklist. The next section answers the most common misconceptions.

17. Frequently asked questions

No. Administrator Protection runs in `appinfo.dll` inside the Application Information service, which runs in `svchost.exe` in VTL0 (the normal Windows kernel context). The SMAA itself is a normal SAM-database account, not a Virtual Secure Mode trustlet. The cross-process protections of Virtualization-Based Security apply to LSASS Credential Guard and a handful of other VTL1 services; the elevation pipeline is not one of them. The Secure Kernel article in this series treats VTL0 / VTL1 separation in detail. Partially. Administrator Protection replaces Admin Approval Mode UAC when `TypeOfAdminApprovalMode = 2`. The credential-prompt path (the over-the-shoulder elevation that asks a standard user to enter an administrator's credentials) and classic Admin Approval Mode (`TypeOfAdminApprovalMode = 1`) coexist with Administrator Protection across different configurations [@ms-admin-protection]. On a device with Administrator Protection enabled, only the interactive admin's elevation path goes through the SMAA; the standard-user-asking-for-admin-credentials path is unchanged. No. There is absolutely an admin token; it lives in a different account, in a different logon session, for a bounded lifetime. The marketing language describes lifetime and isolation, not nonexistence [@ms-developer-blog-2025, @bleepingcomputer-2024]. The SMAA's token persists for the lifetime of the elevated process; when the process exits, the token handle is released and the logon session is reaped. Between elevations, no SMAA token exists in memory. No. Malware can still elevate if the user accepts the Hello prompt. The boundary Administrator Protection creates is between *silent* elevation and *consented* elevation, not between any elevation and none. Microsoft's design position is explicit: "I expect that malware will still be able to get administrator privileges even if that's just by forcing a user to accept the elevation prompt" [@forshaw-pz-jan2026]. The three sub-cases of consent-without-identity-verification from §9 are cost-raised, not eliminated. What changes is that the elevation must be visible. Defenders gain the ETW 15031 audit trail as a result. No. EPM uses a virtual elevated account on a per-request basis with cloud-side policy, and the virtual account is *not* a member of the local Administrators group [@ms-epm-overview]. Administrator Protection uses a persistent local SMAA per admin user, with on-box `appinfo.dll` policy, and the SMAA *is* a member of the local Administrators group [@call4cloud-osint]. EPM is centrally policy-driven and works on standard-user devices; Administrator Protection is per-device architecture and applies only to interactive admin users. The two can coexist on the same device. No. Per Microsoft Learn, remote logon, roaming profiles, and backup admins are out of scope [@ms-admin-protection]. A domain administrator who logs into a workstation interactively will not see the SMAA path. Microsoft has stated that domain scenarios may be added in future iterations; the current GA-target form is local-machine-only, interactive-admin-only. No. Mimikatz inside the elevated SMAA session still has `SeDebugPrivilege` and can call `OpenProcess` on `lsass.exe` to dump LSASS unless LSA Protection (Run As Protected Process Light) and Credential Guard are also enabled. Administrator Protection protects the *elevation path*; it does not protect the *resulting privileged session*. To protect the privileged session, pair Administrator Protection with LSA Protection (`RunAsPPL=1`), Credential Guard, App Control for Business, and HVCI. The Secure Kernel article in this series covers the LSA Protection mechanism.

The misconceptions are cleared. The next section returns to the opening hook with the new vocabulary the article has built.

18. The user-elevation companion to Credential Guard

Return to the two whoami /all outputs from §1, this time with the vocabulary the article has built.

The first output shows the primary user under classic UAC. One SID, one profile, one HKCU, one logon-session LUID; the elevated console is the same user as the unelevated console, distinguished only by the integrity level on the token.

The second output shows the same login under Administrator Protection. A different user name -- ADMIN_<random> -- with a different SID linked to the primary admin via ShadowAccountForwardLinkSid and ShadowAccountBackLinkSid. A different profile under C:\Users\ADMIN_<random>\. A different NTUSER.DAT mapped as HKCU. A fresh authentication-ID LUID minted by LSASS through the credential-less logon path described in §7, on the strength of appinfo.dll's trusted request and a Hello gesture the primary user just performed. An ETW Event 15031 in the Microsoft-Windows-LUA provider, freshly emitted, recording the elevation as approved, the application path, and the authentication method.

The thesis lands. The elevation path is now itself a security boundary, with bulletin-grade fixes when it fails. Administrator Protection is the user-elevation companion to Credential Guard. Where Credential Guard isolated LSA secrets from admin-equals-kernel inside the machine -- the Secure Kernel article in this series covers the VBS-rooted isolation in detail -- Administrator Protection isolates the elevation path from the standard-user session. The two answer the two halves of the question the foundational Access Control article in this series left open: if admin equals kernel and tokens are bearer credentials, what is left to harden? The answer is the path that gets you there (Administrator Protection) and the data that is there once you arrive (Credential Guard).

The December 2025 revert is the first iteration's learning round. The architecture is the right one. The application base catches up next. Forshaw's framing in February 2026 -- that Microsoft might have shipped this as a configurable mode rather than replacing admin approval completely -- is a reasonable critique, and the re-enablement is likely to address it. Until then, the operational reality on most stable Windows devices is the classic split-token model, with all the bypass canon it implies, and the SMAA design remains an Insider-Preview-and-policy-opted-in posture.

What stays unchanged is the structural insight. The mechanism Microsoft used to make the elevation path a boundary is not novel; multi-user accounts have shipped in Windows NT since 1993. What changed is the classification. Microsoft accepted, after twenty years of evidence, that the elevation pipeline needed to be a security boundary, and accepted with it the engineering cost: separate accounts, separate profiles, separate logon sessions, removal of auto-elevation, a credential gate instead of a click-through, an audit-trail ETW provider, and a willingness to ship bulletin-grade fixes for every Forshaw finding. The classification was the engineering decision. Everything else followed.

This is what it took, in mechanism and in time, to make the elevation path real [@forshaw-pz-jan2026].

No Secrets to Steal: How Windows Hello Eliminated the Shared Secret

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

**Windows Hello replaces passwords with biometric authentication backed by hardware cryptography.** Your face or fingerprint unlocks a private key sealed inside a TPM chip -- no biometric data ever leaves your device, and no shared secret crosses the network. After a decade of enterprise growing pains and a cat-and-mouse security arms race, Microsoft made passwordless the default for new accounts in May 2025, with passkeys now achieving a 98% sign-in success rate. The password's 64-year reign is ending -- but open problems in biometric spoofing, credential portability, and quantum-resistant cryptography mean the replacement is still under construction.

Why Passwords Must Die

In 2024, Microsoft observed 7,000 password attacks every second [@ms-passkeys] -- more than double the rate from 2023. Picture this: a user types their carefully memorized 16-character password into what looks like a corporate login page. The page is a phishing replica. In under a second, that password -- the one they have been rotating every 90 days for three years -- belongs to someone else.

Microsoft observed 7,000 password attacks per second in 2024. The password Corbato invented as a quick fix in 1961 had become the single greatest attack surface in computing.

The problem is not weak passwords. The problem is passwords themselves. They are shared secrets -- a piece of information that both you and the server know. Anything a server stores can be stolen. Anything you type can be intercepted. Anything you memorize can be phished. These are not implementation bugs. They are design properties.

It was not supposed to be this way. In 1961, Fernando Corbato [@wiki-password] introduced computer passwords at MIT as a quick fix for multi-user mainframes. Users needed separate file spaces on the Compatible Time-Sharing System (CTSS), and a secret string was the simplest way to provide per-user isolation. It was a temporary measure for a specific engineering constraint.

That temporary measure lasted 64 years.

What if authentication did not require a secret at all? What if your face unlocked a cryptographic key -- and that key never left your device? That is the promise of Windows Hello. But the story of how we got here passes through a gelatin finger, a low-cost USB device, and a near-infrared camera that shattered assumptions about what "secure" really means.

The Password's 64-Year Reign: A Brief History of Authentication Failure

In 1966, a software bug in MIT's CTSS printed the master password file to every user's terminal -- the first known password breach [@wiki-password].The 1966 CTSS incident was not a hack. A system administrator accidentally swapped the login message file with the master password file. Every user who logged in that day saw everyone else's password on screen.

It was a sign of things to come. For the next six decades, every generation of authentication would solve one problem -- and reveal a deeper one.

gantt title Authentication Evolution dateFormat YYYY axisFormat %Y section Passwords Plaintext passwords on CTSS :1961, 1979 section Hashed UNIX crypt / hashed passwords :1979, 1993 section Network Auth NTLM challenge-response :1993, 2000 Kerberos / Windows AD :2000, 2015 section Biometrics Software biometrics via WBF :2009, 2015 section Windows Hello Hello + TPM asymmetric auth :2015, 2021 ESS + VBS + Cloud Trust :2021, 2024 Passkeys and passwordless default :2024, 2026

Generation 0: Plaintext passwords (1961)

Corbato's CTSS stored passwords in plaintext [@wiki-password] in a file accessible to administrators. The model was simple: the user enters a string, the system compares it to a stored copy, and access is granted on match. The key assumption -- that only the legitimate user knows the password -- held exactly as long as the system remained uncompromised. Which was about five years.

Generation 1: Hashed passwords (1970s)

The obvious fix: do not store passwords in plaintext. In 1979, Robert Morris and Ken Thompson published the design behind UNIX's crypt() function [@wiki-crypt], a one-way hash based on a modified DES algorithm with a 12-bit salt. Even if an attacker stole the hash file, they could not directly read the passwords. They would have to try every possible password and compare hashes -- a brute-force attack.

For a while, that was computationally infeasible. Then Moore's Law caught up. By the late 1990s, EFF's DES Cracker and distributed.net had reduced 56-bit DES keysearch to 22 hours and 15 minutes [@eff-des], making DES-based crypt() increasingly untenable against well-funded attackers. Users also chose weak, predictable passwords, and attackers built rainbow tables that mapped common passwords to their hashes instantly.

Windows made this worse. LAN Manager (LM) hashes [@ms-lm-hash] uppercased every password, limited them to 14 characters, and split them into two 7-byte halves hashed independently.The LM hash design was spectacularly bad. By splitting a 14-character password into two 7-character halves, it reduced the brute-force search space from 95^14 to 2 x 95^7 -- a reduction of over 34 trillion times. An attacker could crack each half separately.

Rainbow tables could crack LM hashes in seconds. Microsoft eventually disabled LM hashing by default in Windows Vista, but the damage to enterprise networks had been done.

Generation 2: Network challenge-response (1990s)

The next insight: stop transmitting passwords over the network. NTLM [@ms-lm-hash] used a challenge-response protocol -- the server sends a random nonce, the client computes a response using the nonce and the password hash, and the server verifies the response. The password never crosses the wire.

Kerberos [@ms-kerberos], adopted in Windows 2000, improved further with mutual authentication, time-limited tickets, and single sign-on. It was elegant protocol engineering.

But the fundamental problem remained: shared secrets. NTLM was vulnerable to pass-the-hash attacks [@mitre-pth] -- an attacker who obtains the password hash can authenticate without ever knowing the password. Kerberos tickets could be stolen (Golden Ticket, Silver Ticket attacks). Both systems still depended on users choosing strong passwords, which they consistently failed to do.

Generation 3: First software biometrics (2000s)

By the early 2000s, fingerprint readers appeared on Windows laptops. The idea was appealing: replace "something you know" with "something you are." No password to remember, no password to steal.

Microsoft introduced the Windows Biometric Framework (WBF) [@ms-wbf] in Windows 7 (2009), standardizing the API and driver interface. Before WBF, each fingerprint reader vendor -- AuthenTec, Validity, UPEK -- shipped proprietary middleware that injected into the Windows logon process. The result was inconsistent security, driver conflicts, and no centralized management.

But WBF solved the wrong problem. It standardized the API while leaving the security model unchanged: biometric templates stored with weak encryption in user-accessible files, matching running in OS user space, and no hardware isolation whatsoever.

In 2002, Tsutomu Matsumoto at Yokohama National University demonstrated the "gummy finger" attack -- creating gelatin replicas of fingerprints that fooled approximately 80% of commercial readers [@gummy-finger]. The materials cost just a few dollars. Without liveness detection and hardware protection, biometrics were security theater.

The pattern was unmistakable. Each generation protected a different layer -- plaintext storage, hash computation, network transmission, biometric convenience -- but each left the next layer exposed. By 2013, passwords were fundamentally broken, and software-only biometrics were not the answer. Then Apple proved something nobody expected.

The Catalyst: How Touch ID Changed Everything

September 2013. Apple unveils the iPhone 5S [@apple-touchid] with a fingerprint sensor embedded in the home button. It was not the first phone with a fingerprint reader -- Motorola's ATRIX 4G shipped with a biometric fingerprint reader in 2011 [@motorola-atrix]. But it was the first one that hundreds of millions of people actually used.

What made Touch ID different was not the sensor. It was the Secure Enclave -- a dedicated secure subsystem integrated into Apple's system-on-chip and isolated from the main processor [@apple-secure-enclave]. The enclave runs its own microkernel, stores biometric material in protected memory, and keeps the matching pipeline outside the reach of normal iOS processes. Apple designed it so the biometric path stayed inside the enclave boundary rather than becoming just another app-visible API.

Note: Apple controlled the sensor, the SoC, the Secure Enclave hardware, and iOS. This vertical integration meant the entire biometric pipeline -- from sensor capture through template matching to key release -- could be designed as a single trust chain. No Windows OEM could match this in 2013 because the sensor, CPU, and OS came from three different vendors with no unified security model.

That architecture established a pattern that Windows Hello would later follow with the TPM. Both isolate secrets in hardware, but they do different jobs: the Secure Enclave is a richer coprocessor that protects both biometric processing and keys, while the TPM is a narrower trust anchor for key storage, signing, and attestation. Apple's newer Secure Enclave documentation also emphasizes encrypted enclave memory, whereas Windows later needed ESS and VBS to give its broader PC system a comparable isolation boundary [@apple-secure-enclave; @ms-ess].

Touch ID proved two things simultaneously: that consumer biometrics could be both secure and delightful, and that the key to secure biometrics was hardware isolation, not better algorithms.

The FIDO Alliance had already been working on the standards side. Founded in July 2012 [@fido-launch] by Michael Barrett (PayPal's CISO), Ramesh Kesanupalli (Nok Nok Labs), and partners including Lenovo, Validity Sensors, and Infineon, the Alliance set out to create open standards for strong authentication that would replace passwords. Its first protocols split the problem in two: UAF defined a passwordless flow where a device-local biometric or PIN unlocks a per-service key pair [@fido-uaf], while U2F defined a hardware-token second factor that signs a challenge after the user taps the device [@fido-u2f]. FIDO2 later unified these ideas into the WebAuthn + CTAP stack used for passkeys today [@fido-how].

The convergence was forming: consumer demand (Apple proved people wanted biometrics), open standards (FIDO defined how it should work), and enterprise need (Microsoft tracked thousands of password attacks per second). Apple showed what was possible. The FIDO Alliance defined how it should work. Microsoft was about to show how to do it at the scale of an entire operating system.

The Breakthrough: Windows Hello's Architecture

On March 17, 2015, Joe Belfiore announced Windows Hello. The key insight was not an algorithm -- it was an architecture. What if the biometric never leaves the device, and the authentication secret is a cryptographic key that even the server never sees?

A dedicated security chip soldered to a computer's motherboard (or implemented in firmware) that generates, stores, and manages cryptographic keys. The TPM can create key pairs where the private key is physically bound to the chip and cannot be exported -- even the operating system cannot extract it. Windows Hello uses TPM 2.0 to seal authentication keys. A cryptographic system using two mathematically related keys: a public key (shared openly) and a private key (kept secret). Data encrypted with one key can only be decrypted with the other. In Windows Hello, the TPM holds the private key and signs authentication challenges; the server holds only the public key, which is useless to an attacker.

Here is how Windows Hello authentication [@ms-whfb] works:

sequenceDiagram participant U as User participant B as Biometric Sensor participant D as Device OS participant T as TPM Chip participant S as Identity Server U->>B: Present face or fingerprint B->>D: Capture biometric sample D->>D: Match against stored template Note over D: Local verification only D->>T: Request private key release T->>T: Verify TPM-bound policy T-->>D: Private key available for signing S->>D: Send challenge nonce D->>D: Sign nonce with private key D->>S: Return signed assertion S->>S: Verify signature with public key S->>D: Authentication success

Step 1: Enrollment. The TPM generates an asymmetric key pair -- RSA-2048 or ECDSA P-256. The private key is sealed inside the TPM and cannot be exported. The public key is registered with the identity provider (Azure AD, Entra ID, or on-premises AD) [@ms-whfb].

Step 2: Biometric enrollment. The user registers their face (via a near-infrared camera) or fingerprint. The biometric template is stored locally on the device, protected by the OS.

Step 3: Authentication. The user presents their biometric gesture. The device verifies it locally against the stored template. If the match succeeds, the TPM releases the private key. The identity server sends a random challenge nonce; the device signs it with the private key and returns the signed assertion. The server verifies the signature using the stored public key. No shared secret ever crosses the network.

Key idea: Windows Hello's breakthrough was architectural, not algorithmic. By pairing biometrics with hardware-backed asymmetric cryptography, it eliminated shared secrets entirely. No biometric data ever leaves the device. No password hash sits on a server waiting to be stolen. Each authentication is a fresh, unreplayable cryptographic signature.

The probability that a biometric system incorrectly accepts an unauthorized person. Windows Hello requires a facial recognition FAR below 0.001% (1 in 100,000) [@ms-biometric-reqs]. Apple's Face ID is documented at less than 0.0001% (1 in 1,000,000) for a single enrolled face [@apple-faceid-security]. Lower is better -- but zero is theoretically impossible. A camera technology that captures light in the 700--1000 nanometer wavelength range, invisible to the human eye. Windows Hello uses NIR cameras because infrared illumination works regardless of ambient lighting and is harder to spoof with printed photos or screens -- standard displays do not emit near-infrared light. Or so everyone assumed until 2025.

Note: Without a TPM, Windows Hello falls back to software key storage, dramatically weakening the security model. The private key becomes a file protected by the OS rather than a secret sealed in tamper-resistant silicon. Always verify TPM 2.0 is present and active before relying on Hello's security properties.

A Trusted Platform Module is not a general-purpose processor. It is a purpose-built chip (or firmware module) designed for a narrow set of cryptographic operations: key generation, key storage, signing, and attestation.

When Windows Hello enrolls a user, the TPM generates a key pair using its internal random number generator. The private key never exists outside the chip's boundary -- it is generated inside the TPM and stays there. The TPM enforces access policies: it will only release the key for signing after the device OS confirms that the biometric match succeeded. Even a compromised operating system kernel cannot extract the private key from a hardware TPM.

This is fundamentally different from software key storage, where the key is a file on disk that any sufficiently privileged process can read.

The PIN paradox

Windows Hello also revived the humble PIN -- and made it more secure than a complex password. A Hello PIN [@ms-whfb] is device-bound: it unlocks the TPM-stored private key on that specific device. A stolen PIN is useless without physical access to the hardware. Compare this to a password, which works from any device on earth. A 4-digit PIN on Windows Hello is architecturally more secure than a 20-character password reused across services.Microsoft Passport was briefly announced as a separate product in early 2015 -- the cryptographic key infrastructure behind Windows Hello. By late 2015, the branding was merged. "Microsoft Passport" was retired and its functionality absorbed into "Windows Hello" and "Windows Hello for Business." The separate brand caused market confusion and was quickly abandoned.

The biometric FAR can be expressed mathematically. For a face recognition system with $n$ enrolled users and a per-comparison FAR of $p$, the probability of at least one false acceptance across all comparisons is:

$$P(\text{false accept}) = 1 - (1 - p)^n$$

For Windows Hello's required FAR of $10^{-5}$ [@ms-biometric-reqs] and a single user, this gives a 0.001% chance per authentication attempt. With 1,000 attempts, the cumulative probability rises to roughly 1% -- which is why lockout policies and anti-hammering protections exist.

{` // This demonstrates the core idea behind Windows Hello's authentication. // In the real system, the private key lives in the TPM and never leaves.

async function simulateHelloAuth() { // Step 1: Enrollment -- generate key pair (TPM does this in hardware) const keyPair = await crypto.subtle.generateKey( { name: "ECDSA", namedCurve: "P-256" }, true, // extractable for demo only; TPM keys are NOT extractable ["sign", "verify"] ); console.log("Key pair generated (simulating TPM enrollment)");

// Step 2: Server sends a challenge nonce const challenge = crypto.getRandomValues(new Uint8Array(32)); console.log("Server challenge:", Array.from(challenge.slice(0, 8)).map(b => b.toString(16).padStart(2, '0')).join(''));

// Step 3: Device signs the challenge with the private key const signature = await crypto.subtle.sign( { name: "ECDSA", hash: "SHA-256" }, keyPair.privateKey, challenge ); console.log("Signed assertion:", new Uint8Array(signature).slice(0, 16).join(',') + '...');

// Step 4: Server verifies with the public key const valid = await crypto.subtle.verify( { name: "ECDSA", hash: "SHA-256" }, keyPair.publicKey, signature, challenge ); console.log("Server verification:", valid ? "SUCCESS" : "FAILED"); console.log("\nNote: The private key never left the device."); console.log("The server only has the public key -- useless to an attacker."); }

simulateHelloAuth(); `}

Windows Hello solved the fundamental password problem: no shared secrets ever traverse the network. But the story does not end here -- because researchers would soon discover that protecting the key was not enough if you could not trust the camera.

The Enterprise Gambit: Windows Hello for Business

Windows Hello delighted consumers. But enterprise IT administrators asked a harder question: how do I deploy this to 50,000 machines managed by Active Directory?

The W3C Web Authentication API -- a browser standard that lets websites request public-key-based authentication from platform authenticators (like Windows Hello) or roaming authenticators (like security keys). WebAuthn became a W3C Recommendation on March 4, 2019, forming the browser-side component of the FIDO2 standard alongside CTAP (Client-to-Authenticator Protocol).

Windows Hello for Business (WHfB) [@ms-whfb] launched in 2016 with two trust types, each carrying its own infrastructure burden:

Certificate Trust required a full Public Key Infrastructure -- a Certificate Authority hierarchy, CRL distribution points, certificate templates, and ADFS (Active Directory Federation Services). For organizations that already had PKI, this was a natural fit. For everyone else, it meant weeks of setup.

Key Trust required Windows Server 2016+ domain controllers with AD schema extensions. Simpler than Certificate Trust, but still demanded on-premises infrastructure that many cloud-first organizations were trying to eliminate.Yogesh Mehta, Principal Group Program Manager at Microsoft, evangelized Windows Hello for Business at Ignite 2016. He would later be credited as a key figure in the FIDO2 certification effort. The original Belfiore blog post URL announcing Windows Hello is now lost to link rot.

Two milestones accelerated adoption. In March 2019, WebAuthn became a W3C Recommendation [@w3c-webauthn] -- a universal browser API for public-key authentication. Android had already been FIDO2-certified in February 2019 [@fido-android-certification]; two months after WebAuthn's recommendation, Windows Hello became one of the first FIDO2-certified platform authenticators built into a desktop operating system [@fido-certification]. Together, these meant that Windows Hello could authenticate not just to Windows, but to any FIDO2-supporting website through any modern browser.

Note: Unless you have specific PKI requirements, Cloud Trust -- announced by Microsoft in 2022 [@ms-cloud-trust-ga] -- eliminates much of the complexity of certificate and key trust deployments. It requires Entra ID configuration and Microsoft Entra Kerberos rather than a full on-prem PKI or ADFS stack, which is why Microsoft now treats it as the default recommendation for many hybrid organizations.

flowchart TD A[Choose a WHfB Trust Model] --> B{Cloud-native org using Entra ID?} B -->|Yes| C[Cloud Trust -- Recommended] B -->|No| D{On-prem AD still required?} D -->|Yes| E{Existing PKI infrastructure?} D -->|No| C E -->|Yes| F[Certificate Trust] E -->|No| G[Key Trust] C --> H[Simplest deployment: Entra ID only] F --> I[Most complex: CA + CRL + ADFS] G --> J[Moderate: Server 2016+ DCs required]

Cloud Trust delegates all validation to Entra ID. No on-premises PKI, no ADFS, no certificate templates. Best for organizations that are cloud-native or hybrid with Azure AD.

Key Trust requires Windows Server 2016+ domain controllers with AD schema extensions. Choose this if you need on-premises AD support but do not have PKI.

Certificate Trust requires the full PKI stack -- CA hierarchy, CRL distribution, ADFS. Choose this only if your organization already has PKI infrastructure and needs certificate-based authentication for regulatory compliance.

Enterprise deployment was painful -- multiple trust models confused administrators, and adoption was slower than hoped. But it was about to get much worse. In July 2021, a researcher with a low-cost USB board would demonstrate that Windows Hello's most basic assumption was wrong.

The Security Arms Race: When Researchers Fought Back

Omer Tsarfati had a simple question: what happens if you plug in a USB device that claims to be an IR camera? The answer would force Microsoft to rethink Windows Hello's entire trust model.

The USB camera bypass (CVE-2021-34466)

In July 2021, Tsarfati at CyberArk Labs [@cyberark-bypass] revealed that Windows Hello's facial recognition accepted input from any USB device presenting itself as an IR camera -- with no attestation, no hardware trust verification, and no device identity check.Tsarfati's attack required only a single IR frame -- not video, not a 3D reconstruction, just one static infrared image of the target's face. The simplicity of the attack was what made it so alarming.

Using an NXP evaluation board [@cyberark-bypass], Tsarfati constructed a custom USB device that replayed a single IR frame of a target's face. Plug it in, and Windows Hello authenticated the attacker as the target. At the time, 85% of Windows 10 users employed Windows Hello [@cyberark-bypass] -- making this a massive attack surface.

The insight was devastating: the TPM protected the key, but nobody protected the camera. Windows Hello's threat model assumed trusted camera hardware. The USB specification makes no such guarantee.

A Windows feature that uses the hardware hypervisor to create an isolated virtual environment (Virtual Trust Level 1, or VTL1) separated from the main OS kernel (VTL0). Even if an attacker gains SYSTEM-level access to the Windows kernel, they cannot read memory in VTL1. Windows Hello's Enhanced Sign-in Security uses VBS to isolate biometric processing.

Microsoft's response: ESS and VBS

Microsoft's answer came with Windows 11: Enhanced Sign-in Security (ESS) [@ms-ess], which moved biometric matching into the VBS-protected enclave described above. Even a compromised Windows kernel cannot access templates or tamper with the comparison pipeline there.

flowchart TD subgraph VTL0["VTL0: Normal OS Environment"] A[Windows Kernel] B[Applications] C[Standard Drivers] end subgraph VTL1["VTL1: Secure World -- ESS"] D[Biometric Matching Engine] E[Encrypted Template Storage] F[Credential Isolation] end G[Hypervisor] --- VTL0 G --- VTL1 H[Secure Biometric Sensor] --> D A -.->|Blocked by Hypervisor| D B -.->|Blocked by Hypervisor| E

Alongside ESS, Microsoft rolled out Cloud Trust in 2022 [@ms-cloud-trust-ga], eliminating the need for on-premises PKI for many deployments. Two problems -- biometric isolation and deployment complexity -- were finally being addressed in parallel.

Red Bleed: the NIR assumption shatters (CVE-2025-26644)

The arms race was not over. In August 2025, researchers Bowen Hu, Kuo Wang, and Chip Hong Chang at Nanyang Technological University presented "Red Bleed" [@red-bleed] at USENIX Security 2025. Microsoft had already patched CVE-2025-26644 [@wiz-cve] in April 2025, but the full attack was now public.

Windows Hello's NIR facial recognition relied on a critical assumption: no commercial display can emit near-infrared light. The researchers shattered this assumption [@nvd-red-bleed] with a custom-built LCD screen costing less than $400 that could display NIR images. They trained a Variational Autoencoder to convert widely available RGB photos -- from social media, video calls, public sources -- into convincing NIR facial videos. The result: a presentation attack that bypassed Windows Hello face authentication and prompted liveness-detection hardening [@red-bleed-pdf]. The Red Bleed attack name references the "red bleed" phenomenon in LCD panels where a small amount of near-infrared light leaks through the color filters -- the researchers amplified this effect with a custom panel.

Microsoft's April 2025 patch strengthened liveness detection and anti-spoofing measures for NIR authentication.

Faceplant: the template swap (CVE-2026-20804)

The third major attack came from ERNW Research in August 2025. At Black Hat USA 2025, Baptiste David and Tillmann Oßwald's official conference briefing "Windows Hell No for Business" [@blackhat-windows-hell-no] detailed the Faceplant template-injection attack, which they later documented technically on ERNW's research blog [@faceplant].

In practice, an attacker with local administrator privileges could enroll their own face on one machine, extract the resulting template, and transplant it into the victim's biometric database on the target device. After injection, Windows Hello accepted the attacker's face for the victim's account. ERNW traced the weakness to software-protected templates that a local administrator could extract and replace on non-ESS systems [@faceplant].

ESS blocks this attack completely -- biometric templates in VTL1 are inaccessible even to local administrators. But many enterprise PCs lack ESS-compatible hardware.

Note: Many enterprise PCs -- particularly those shipped without an ESS-certified built-in biometric sensor, including many AMD-based and older Intel-based machines -- lack ESS capability. On these machines, biometric templates remain in software-protected storage vulnerable to the Faceplant attack. Verify hardware compatibility before assuming biometric isolation is active.

flowchart TD A["2015: Windows Hello Launch"] --> B["2021: CVE-2021-34466\nUSB Camera Spoofing"] B --> C["Microsoft Response:\nESS + VBS Isolation"] C --> D["2025: CVE-2025-26644\nRed Bleed NIR Attack"] D --> E["Microsoft Response:\nLiveness Detection Update"] E --> F["2025: CVE-2026-20804\nFaceplant Template Injection"] F --> G["Defense: ESS Hardware\nIsolation Blocks Attack"] G --> H["Ongoing: Adversarial ML\nArms Race"] classDef fake fill:#7a3030,stroke:#c44b4b,color:#fce8e8 class B fake,stroke:#333 class D fake,stroke:#333 class F fake,stroke:#333 classDef real fill:#2f5a3a,stroke:#5fa872,color:#dff5e4 class C real,stroke:#333 class E real,stroke:#333 class G real,stroke:#333

Key idea: Each generation of authentication protected a new layer -- but every layer revealed the next attack surface. The TPM protected the key. ESS protected the biometric pipeline. Liveness detection hardened NIR authentication. Security is never a single solution. It is a stack, and each layer needs its own defense.

The arms race revealed a humbling truth: biometric authentication is not a silver bullet. It is a layered defense -- and each layer needs its own protection. But while researchers probed Windows Hello's defenses, the industry was converging on something bigger.

The Convergence: Passkeys and the Passwordless Future

May 5, 2022. Apple, Google, and Microsoft [@passkeys-announcement] -- three companies that agree on almost nothing -- issued a joint announcement: they were all committing to passkeys.

A FIDO2/WebAuthn credential built on the same public-key model as Windows Hello. Passkeys can be device-bound (like traditional Hello credentials, stored in the TPM) or synced across devices through a credential manager such as iCloud Keychain or Google Password Manager. The local biometric or PIN check stays on-device; the relying party only sees public keys and signatures.

FIDO2 had a usability problem. Credentials were bound to a single device. Lose your laptop, lose your credentials. Passkeys solved this by introducing synced credentials -- private keys encrypted and distributed across a user's devices through their platform credential manager. The FIDO Alliance's protocol [@fido-how] maintained the cryptographic guarantees (no shared secrets, phishing resistance) while adding the portability users demanded."World Password Day" was symbolically renamed "World Passkey Day" in May 2025, when Microsoft announced that new accounts would default to passwordless authentication.

The numbers tell the story

By May 2025, Microsoft made new accounts passwordless by default [@ms-passkeys]:

Nearly 1 million passkey registrations daily [@ms-passkeys]
98% passkey sign-in success rate [@ms-passkeys] vs. 32% for passwords
Passkey sign-ins 8x faster [@ms-passkeys] than password + MFA

How the platforms compare

Dimension	Windows Hello (WHfB)	Apple Face ID / Passkeys	Google Passkeys	FIDO2 Hardware Keys
Hardware root of trust	TPM 2.0	Secure Enclave	TEE / Titan M	On-key secure element
Credential sync	No (device-bound)	Yes (iCloud Keychain)	Yes (Google PM)	No (hardware-bound)
Cross-platform	Windows only	Apple + QR/BT bridge	Android/Chrome + QR/BT	Universal USB/NFC/BT
FAR (face)	< 0.001%	< 0.0001%	Varies by OEM	N/A
Enterprise management	Intune, GP, Conditional Access	Limited (Apple MDM)	Android Enterprise	Manual provisioning
Recovery on device loss	Re-enroll on new device	iCloud backup restore	Google Account restore	Requires backup key
NIST AAL level	AAL2	AAL2	AAL2	AAL3-eligible
Best suited for	Windows enterprise	Apple platform	Android / cross-platform web	High-assurance regulated

Sources: Microsoft biometric requirements [@ms-biometric-reqs], Apple passkey security [@apple-passkeys-security], Google passkeys [@google-passkeys], FIDO specifications [@fido-specs]

Google's passkey story is centered on Google Password Manager: passkeys created on Android or Chrome sync across Android, ChromeOS, Windows, macOS, Linux, and Chrome browsers where the same account is available [@google-passkeys]. FIDO2 hardware security keys (YubiKey, Google Titan) take the opposite approach: the credential stays on a dedicated secure element, works across platforms via USB/NFC/Bluetooth, and must be provisioned deliberately on each account [@fido-u2f; @fido-how]. That trade-off buys the highest assurance available today; multi-factor cryptographic hardware authenticators are the mainstream route to NIST AAL3 [@nist-aal].

sequenceDiagram participant U as User participant B as Browser participant A as Platform Authenticator participant S as Relying Party Server U->>B: Click Register with Passkey B->>S: Request registration options S->>B: Return challenge + relying party info B->>A: navigator.credentials.create() A->>U: Prompt biometric verification U->>A: Present face / fingerprint / PIN A->>A: Generate key pair in TPM A->>B: Return public key + attestation B->>S: Send credential to server S->>S: Store public key for user S->>B: Registration complete

{` // This shows the structure of a WebAuthn registration request. // In production, the challenge comes from your server.

const registrationOptions = { publicKey: { // Random challenge from the server (32 bytes) challenge: crypto.getRandomValues(new Uint8Array(32)),

// Your service identity
rp: {
  name: "Example Corp",
  id: "example.com"
},

// User identity
user: {
  id: new Uint8Array([1, 2, 3, 4]),
  name: "alice@example.com",
  displayName: "Alice"
},

// Acceptable key types (ES256 = ECDSA P-256)
pubKeyCredParams: [
  { type: "public-key", alg: -7 }  // ES256
],

// Request a resident/discoverable credential (passkey)
authenticatorSelection: {
  residentKey: "required",
  userVerification: "required"  // Biometric or PIN
},

// 5-minute timeout
timeout: 300000

} };

console.log("Registration options structure:"); console.log(JSON.stringify(registrationOptions.publicKey.rp, null, 2)); console.log("\nKey algorithm: ES256 (ECDSA P-256)"); console.log("Resident key: required (discoverable passkey)"); console.log("User verification: required (biometric or PIN)"); console.log("\nIn production, call: navigator.credentials.create(registrationOptions)"); `}

Deploying Windows Hello Today

For consumers, the simplest path is built into Windows: open Settings > Accounts > Sign-in options, create a Windows Hello PIN first, then enroll face or fingerprint if the hardware is present [@ms-whfb]. If Windows only offers PIN, the machine lacks a compatible biometric sensor. On a laptop with an IR camera or certified fingerprint reader, enrollment takes a few minutes and the credential becomes device-bound immediately.

For enterprises, Microsoft now recommends starting with Cloud Trust unless certificate-based authentication is a hard requirement. A practical rollout checklist is short: confirm devices are Entra joined or hybrid joined, deploy Microsoft Entra Kerberos, verify Windows 10 21H2+/Windows 11 clients and Windows Server 2016+ read-write domain controllers in each site, then push Use Windows Hello for Business plus Use cloud trust for on-premises authentication through Intune or Group Policy [@ms-cloud-trust-ga]. That is dramatically lighter than standing up PKI, ADFS, and certificate templates.

ESS deserves its own hardware check. A TPM alone is not enough: ESS depends on Windows 11, VBS-capable hardware, and compatible secure biometric sensors [@ms-ess]. Unsupported systems can still use Hello, but they fall back to the older software-protected biometric path. Hardware inventory determines whether you are getting the modern threat model or merely the old UX.

Note: Start with a pilot group, require a Hello PIN for every enrolled user, and issue at least one backup FIDO2 security key to admins and help-desk staff. The cleanest password migration is additive: enroll Hello first, prove recovery works, then remove password prompts from the highest-value workflows last.

For password migration, avoid a flag day. Keep passwords as break-glass recovery while you move device sign-in, Microsoft 365, VPN, and high-value internal apps onto Hello or passkeys first [@ms-entra-passwordless]. Measure enrollment completion, recovery success, and hardware exceptions. Once those numbers stabilize, tighten Conditional Access so phishing-resistant credentials satisfy MFA and passwords become the fallback of last resort.

After 64 years, the password is finally losing its grip. But the story of Windows Hello is not a triumph -- it is a lesson in the limits of security engineering.

The Limits: What Remains Unsolved

Biometrics fail in a way passwords do not: they are hard to rotate.

You cannot change your face. This single fact defines the deepest unsolved problem in biometric authentication.

Passwords can be rotated. Security keys can be replaced. But you have one face, ten fingerprints, and two irises. If a biometric template is compromised, there is no "reset" button.

A technique for generating revocable biometric templates by applying non-invertible mathematical transformations to the original biometric data. If a transformed template is compromised, a new transformation can be applied to create a fresh template from the same biometric trait. In theory, this solves the irrevocability problem. In practice, the trade-off between non-invertibility and matching accuracy remains unresolved.

The biometric floor

The theoretical limit on biometric authentication error is the Bayes error rate [@jain-biometric] -- the minimum achievable error when the genuine-user and impostor score distributions overlap. Per information theory, the error probability is bounded by Fano's inequality:

$$P_e \geq \frac{H(X|Y) - 1}{\log |X|}$$

where $P_e$ is the probability of error, $H(X|Y)$ is the conditional entropy of identity given the biometric sample, and $|X|$ is the number of possible identities. Current systems achieve a FAR of $10^{-5}$ to $10^{-6}$, but the theoretical minimum [@jain-biometric] -- given perfect sensors and optimal classifiers -- could be orders of magnitude lower. The practical gap is driven by sensor noise, environmental variability, and aging of biometric features.

Five open problems

1. Cross-platform credential portability. Passkeys are currently vendor-locked. An Apple passkey does not transfer to a Google account. The FIDO Alliance published draft CXP/CXF specifications [@fido-cxp] in late 2024 for encrypted credential exchange, but full cross-vendor interoperability is not expected before late 2026.

2. The adversarial ML arms race. Generative AI can create increasingly convincing biometric spoofs -- the Red Bleed attack [@red-bleed] used a VAE to convert RGB photos to NIR facial videos. Discriminative AI tries to detect these spoofs. This is an open-ended arms race with no known endpoint.

3. Account recovery. When all biometric and device-based credentials fail, how does a user recover their account? Most services fall back to email or SMS [@ms-entra-passwordless] -- reintroducing the very phishable factors they were designed to eliminate. Recovery codes are functionally passwords.

Note: Systems that fall back to passwords or SMS for account recovery reintroduce the very vulnerabilities they were designed to eliminate. A truly passwordless system needs passwordless recovery -- and no universal solution exists yet.

4. The quantum threat. Shor's algorithm [@nist-pqc] on a sufficiently large quantum computer would break all ECDSA and RSA authentication -- including every FIDO2 credential in existence. NIST finalized post-quantum standards [@nist-pqc] (ML-DSA, SLH-DSA, ML-KEM) in 2024, but no FIDO2 authenticator ships with post-quantum support as of 2026.

All current FIDO2/WebAuthn authentication uses ECDSA P-256, which provides 128-bit classical security. Breaking a single credential requires approximately $2^{128}$ operations -- far beyond any existing computer.

Shor's algorithm changes this equation. A cryptographically relevant quantum computer could factor the elliptic curve discrete logarithm problem in polynomial time, breaking ECDSA entirely. No such computer exists today, but the "harvest now, decrypt later" threat means adversaries may be collecting signed assertions now to verify forged credentials later.

NIST finalized its first post-quantum cryptography standards in 2024 [@nist-pqc]: ML-DSA (formerly CRYSTALS-Dilithium) for signatures, ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation, and SLH-DSA (formerly SPHINCS+) for hash-based signatures. The FIDO Alliance and W3C are exploring hybrid signature schemes that combine classical ECDSA with post-quantum algorithms, but no timeline for standardization has been published.

5. The ESS hardware gap. ESS requires specific secure sensors and VBS-capable CPUs [@ms-ess]. Many enterprise PCs -- particularly those shipped without an ESS-certified built-in biometric sensor, including many AMD-based and older Intel-based machines -- lack ESS capability. On these devices, Windows Hello falls back to the pre-ESS security model, leaving them vulnerable to attacks like Faceplant.

6. Accessibility and inclusion. Biometric authentication creates barriers for people with facial differences, missing fingers, or conditions that affect biometric stability. A passwordless future must ensure that non-biometric alternatives (PINs, hardware keys) remain first-class options, not afterthoughts. Behavioral biometrics -- keystroke dynamics, gait analysis, continuous session verification -- represent an emerging parallel path that may expand authentication options beyond traditional biometric modalities.

Open PowerShell as administrator and run:

Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard -ClassName Win32_DeviceGuard | Select-Object VirtualizationBasedSecurityStatus

A value of 2 means VBS is running. Then check the biometric service:

Get-WinEvent -LogName Microsoft-Windows-Biometrics/Operational -MaxEvents 10 | Format-List

Look for events indicating ESS-protected biometric operations. If your device lacks ESS, consider disabling biometric sign-in on sensitive accounts and using FIDO2 hardware keys instead.

Key idea: Biometric traits are permanent and finite. Unlike passwords, they cannot be changed if compromised. This irrevocability is the deepest unsolved challenge in passwordless authentication -- and no amount of better sensors or smarter algorithms can change the fact that you have one face, ten fingerprints, and two irises.

The theoretically ideal system would combine zero-knowledge biometric verification, post-quantum cryptographic authentication, hardware-attested revocable credentials, and cross-platform portability. None of this exists yet.

The password's 64-year reign is ending, but its replacement is still under construction. Every generation of authentication solved one problem and revealed a deeper one. The question is not whether passwordless authentication will win -- it is whether we can build it before the attackers catch up.

Frequently Asked Questions

No. Biometric data never leaves the device. During enrollment, your face or fingerprint template is stored locally, protected by the operating system (and by VBS on ESS-enabled devices). Only a public key is registered with the identity provider (Azure AD / Entra ID) [@ms-whfb]. Microsoft's servers never receive, store, or process your biometric data. Standard photos cannot. Windows Hello uses near-infrared cameras [@ms-biometric-reqs] with anti-spoofing algorithms that distinguish between live faces and flat images. However, researchers have demonstrated advanced attacks: CVE-2021-34466 [@cyberark-bypass] used a custom USB device emulating an IR camera, and the Red Bleed attack [@red-bleed] used a custom NIR-emitting LCD display. Both have been patched, but the arms race continues. No -- it is more secure. A Windows Hello PIN is device-bound [@ms-whfb]: it unlocks a TPM-stored private key on that specific hardware. A stolen PIN is useless without physical access to the device. A password, by contrast, works from any device on earth and can be phished, reused, or leaked in a breach. Consumer Windows Hello [@ms-whfb] ties authentication to a personal Microsoft account. Windows Hello for Business integrates with Azure AD / Entra ID with enterprise management capabilities: conditional access policies, Intune deployment, multiple trust models (cloud, key, certificate), and group policy controls. They share the same biometric and TPM technology but have different management and security models. No. Passkeys build on Hello's foundation. Windows Hello acts as the platform authenticator for FIDO2 passkeys [@fido-how] on Windows -- your biometric gesture unlocks the passkey stored in the TPM. Passkeys extend Hello's model to cross-platform and cross-service authentication via the WebAuthn standard [@webauthn-3]. With device-bound credentials (traditional Windows Hello), you re-enroll on the new device using your Microsoft or organizational account. With synced passkeys, credentials restore from your credential manager -- iCloud Keychain [@apple-passkeys-security] for Apple, Google Password Manager [@google-passkeys] for Android/Chrome. Registering a FIDO2 hardware security key [@fido-specs] as a backup authenticator is strongly recommended. Not indefinitely. The asymmetric cryptography underlying Hello and FIDO2 (ECDSA P-256) is theoretically vulnerable [@nist-pqc] to quantum computers running Shor's algorithm. No quantum computer can break it today, and the timeline for cryptographically relevant quantum computers remains uncertain. NIST finalized post-quantum cryptography standards in 2024, but no FIDO2 authenticator ships with post-quantum support yet. Migration planning should begin now.