Parag Mali - tag: authentication

From Password-in-the-Pipe to Cloud-Issued Session: Twenty-Six Years of RDP Authentication

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

**Remote Desktop Protocol** has spent twenty-six years retreating from one design decision: in 1998, "the user's password becomes the target's credential." Five generations now coexist on a Windows estate. **Classic credential delegation** sends the user's NT one-way function into the target's `lsass.exe`. **Network Level Authentication via CredSSP** [@rdpbcgr-credssp] (Windows Vista, 2006) moves authentication before the session starts but still delivers credential material. **Restricted Admin mode** [@ms-adv-2871997] (Windows 8.1 / Server 2012 R2 RTM, October 17, 2013) stops delivering credentials and runs the user's session as the target's machine identity. **Remote Credential Guard** [@msl-rcg] (Windows 10 1607, August 2, 2016) forwards Kerberos operations back to the caller's `lsass.exe`, with VTL1 trustlet protection conditional on the caller having local Credential Guard enabled. **PRT-over-RDP** [@msl-prtrdp-mstsc] (October 11, 2022 cumulative updates) uses a Microsoft Entra ID Primary Refresh Token cookie scoped to the Conditional Access app `a4a365df-50f1-4397-bc59-1a1564b8bb9c`. **CVE-2018-0886** [@nvd-2018-0886] (CredSSP MITM) and **CVE-2019-0708** [@nvd-2019-0708] (BlueKeep, pre-auth channel-setup) are the canonical RDP CVEs. The residual classes are RBCD against `TERMSRV` [@shamir-wagging], PRT extraction at the session host [@mollema-prt2], and the architectural SYSTEM-on-target floor that no RDP mode can close.

1. Four sekurlsa Dumps, One Target

A red-team operator with SYSTEM on a single Windows 11 25H2 host runs mimikatz sekurlsa::logonpasswords four times in a row [@mimikatz-github]. Each time, a different user has just disconnected an RDP session. Each time, the dump looks different.

The first dump shows the user's NT one-way function. The second dump shows the target machine's identity instead of the user's. The third dump shows the user's identity but no hash that can be replayed anywhere. The fourth dump shows no password-equivalent material for the user at all -- only a Primary Refresh Token bound to the target's own TPM.

Four RDP sessions, one target, four entirely different post-exploitation pivots. The difference is not in what the attacker did. The difference is in which authentication mode the client negotiated before the session was established.

This article is about those four modes -- classic, Restricted Admin, Remote Credential Guard, and PRT-over-RDP -- and the fifth (NLA via CredSSP) that sits underneath them all. It is the story of a twenty-six-year retreat from "the user's password becomes the target's credential."

The wire-protocol selectors are public, even if their names mostly are not. The RDP_NEG_REQ structure [@rdpbcgr-negreq] sets requestedProtocols to one of PROTOCOL_RDP (0x00), PROTOCOL_SSL (0x01), PROTOCOL_HYBRID (0x02) for CredSSP-based NLA, PROTOCOL_HYBRID_EX (0x08), or PROTOCOL_RDSAAD (0x10) for the Entra-based path. Inside PROTOCOL_HYBRID, two flags bits switch the sub-mode: RESTRICTED_ADMIN_MODE_REQUIRED (0x01) and REDIRECTED_AUTHENTICATION_MODE_REQUIRED (0x02). Five wire-level paths. Five different answers to the same question: what does the target's lsass.exe end up holding?

The next twelve sections walk each mode end-to-end, the CVEs that broke each layer, the Microsoft Learn comparison matrix verbatim, the residual class that survives each generation, and the operational guide for the engineer who has to make these primitives interoperate on Monday morning. Before we can read the four dumps, we have to understand the one credential-delivery decision every later generation was built to correct. That decision shipped in 1998.

2. Terminal Services and the Password-in-the-Pipe Era (1998-2005)

In 1998 Microsoft shipped a remote-display product that solved an obvious problem -- run a Windows desktop over the network -- and a second, less obvious problem along the way: every machine that accepted an RDP connection now needed to be a credential reservoir for every user who connected to it.

The product was Windows NT 4.0 Terminal Server Edition [@wiki-nt4tse], built on top of MultiWin technology that Microsoft had licensed from Citrix the previous year [@wiki-rdp]. The protocol that carried the display and the keystrokes was the Remote Desktop Protocol, version 4.0, listening on TCP port 3389 (and, much later, UDP port 3389 for the QUIC variant) [@wiki-rdp]. The protocol itself was an extension of the ITU-T T.128 application-sharing protocol [@wiki-rdp], with RC4 channel encryption layered on top using a 40-bit, 56-bit, or 128-bit session key (a FIPS-validated 3DES variant was added in Server 2003) [@rdpbcgr-index].

timeline title Twenty-six years of RDP authentication 1998 : NT 4.0 Terminal Server Edition / RDP 4.0 : Password delivered to target's lsass 2001 : SMBRelay (cDc) names credential-in-motion attack 2006 : Windows Vista / RDP 6.0 ships NLA via CredSSP 2013 : Windows 8.1 / 2012 R2 ships Restricted Admin 2014 : KB2871997 backports Restricted Admin to Win 7 2016 : Windows 10 1607 / 2016 ships Remote Credential Guard 2018 : CVE-2018-0886 CredSSP RCE; AllowEncryptionOracle 2019 : CVE-2019-0708 BlueKeep pre-auth channel-setup RCE 2022 : KB5018418 ships PRT-over-RDP / Entra SSO for RDP 2025 : Win 11 24H2 KIR recovers from RDP-stack regression Microsoft's multi-user remote-desktop subsystem, introduced in Windows NT 4.0 Terminal Server Edition (1998) [@wiki-rdp]. Renamed to Remote Desktop Services in Windows Server 2008 R2. Provides interactive Windows sessions over TCP/3389 using the Remote Desktop Protocol, an extension of the ITU-T T.128 application-sharing protocol family.

Authentication, in 1998, looked nothing like authentication today. The client opened a TCP/3389 connection. The server sent a Proprietary Certificate containing an RSA public key. The client generated a 32-byte Client Random, encrypted it with that RSA public key, and both sides derived RC4 session keys from the shared random [@rdpbcgr-index].

The user then typed a username and password into the remote login screen, and the password traveled into the target's Winlogon process inside that RC4 channel. The target's lsass.exe ran NTLM challenge-response against a domain controller (or against its local SAM) and, on success, materialised an interactive session for the user. The target now held the user's NT one-way function for the lifetime of that session.

The architectural property was simple: the target was the credential reservoir. Five accounting clerks who RDP'd into a Terminal Server during a shift left five NT-OWF entries in that host's lsass.exe memory. An attacker who later got SYSTEM on the Terminal Server held the credential material for all five.

Two years later, Windows 2000 made Terminal Services a built-in server feature, and Windows XP Professional (October 2001) shipped the desktop-side variant under the brand "Remote Desktop" [@wiki-rdp]. The credential-aggregation surface, previously confined to dedicated Terminal Server hosts, now extended to every workstation in the estate.

The first public articulation that credential material in motion is itself an attack surface came on March 31, 2001, when Sir Dystic of Cult of the Dead Cow released SMBRelay at the @lanta.con convention in Atlanta [@cdc-smbrelay]. SMBRelay was an SMB man-in-the-middle that hijacked an inbound NTLM authentication and relayed it onward.The Wikipedia SMBRelay article gives March 21, 2001 [@wiki-smbrelay], but the primary source -- Sir Dystic's own publication at cultdeadcow.com -- says March 31, 2001 [@cdc-smbrelay]. Primary-source dating wins. The Wikipedia article also says "receives a connection on UDP port 139," which is incorrect; NetBIOS Session Service has always run over TCP/139, and the SMBRelay v0.98 source listing on cultdeadcow.com explicitly binds a TCP socket to port 139. RDP was not yet a direct target, but the principle was now public: pass-the-hash and credential relay would work against any protocol that put credential material on the wire.

RDP 5.2 (Server 2003, XP SP2) responded to the wire-confidentiality problem in 2003 by adding an optional Security Layer = SSL setting that wrapped the RDP traffic in TLS [@rdpbcgr-index]. The header byte called selectedProtocol could now take the value PROTOCOL_SSL = 0x01, meaning the channel was TLS-encrypted before the legacy basic-settings exchange ran. TLS solved the wire-snooping problem."Security Layer = SSL" in RDP 5.2 was transport confidentiality only. The TLS handshake authenticated the server's certificate (or did not, in many production configurations); the user authentication still happened later, inside the basic-settings exchange and the Logon_Info PDU. The credential the target ended up with was identical to classic-RDP credential delivery. The distinction between "TLS protects the wire" and "TLS protects the credential" is the load-bearing precision the next section will need. It did not solve the credential-aggregation problem.

By 2005 the architectural problem was named. Microsoft's eventual response would shape the next two decades of Windows authentication strategy. It would also, on its first attempt, fix the wrong half of the problem.

3. Network Level Authentication via CredSSP (2006-2013)

Network Level Authentication is the policy that requires authentication before the RDP session is established. NLA is not a protocol. NLA is implemented by CredSSP -- the Credential Security Support Provider -- running over TLS [@rdpbcgr-credssp]. The difference between those two sentences is the one that matters.

Windows Vista (November 2006) shipped RDP 6.0, the first Windows release to include NLA and CredSSP support. NLA was selectable in System Properties but did not become the Remote Desktop default until Windows 7 / Server 2008 R2 [@wiki-rdp]. The MS-CSSP open specification documents CredSSP's role and its lineage, with the protocol summary listing its first revision in December 2006 [@mscssp-index] -- the same shipping window as Vista.

MS-CSSP defines CredSSP as a protocol that "enables an application to securely delegate a user's credentials from a client to a target server" [@mscssp-index]. That phrasing matters: from CredSSP's own design statement, the credential is delegated to the target. The credential still ends up on the target. The protocol design did not change that property; it changed when the delivery happens and what protects it on the wire.

A policy on the RDP server that requires the connecting user to authenticate before the RDP session is established (before the basic-settings exchange and the virtual-channel binding). Implemented by CredSSP over TLS [@rdpbcgr-credssp]. NLA reduces denial-of-service exposure and gates the pre-auth channel-setup attack surface (the failure mode BlueKeep would later exploit) but does not change the credential material the target receives. The Microsoft authentication protocol, specified in MS-CSSP [@mscssp-index] and used by RDP and Windows Remote Management, that "amalgamates" TLS with Kerberos and NT LAN Manager [@rdpbcgr-credssp]. CredSSP runs SPNEGO inside a TLS channel, performs Kerberos or NTLM authentication inside SPNEGO, and finally delivers a `TSCredentials` payload to the target. CredSSP is what NLA *is*, at the wire. The CredSSP payload structure that carries the user's credential material to the target after the SPNEGO and Kerberos/NTLM phases complete [@mscssp-index]. The classic form is `TSPasswordCreds` (username + domain + plaintext password). Two later forms -- the credential-less form for Restricted Admin and the redirected form (`TSRemoteGuardCreds`) for Remote Credential Guard -- change what travels in this slot without changing the surrounding exchange.

The wire choreography is documented verbatim in section 5.4.5.2 of MS-RDPBCGR. CredSSP is "essentially the amalgamation of TLS with Kerberos and NT LAN Manager (NTLM)" [@rdpbcgr-credssp]. The exchange runs in this order:

Client opens TCP/3389.
RDP_NEG_REQ carries requestedProtocols & PROTOCOL_HYBRID = 0x02 (or PROTOCOL_HYBRID_EX = 0x08, which adds an Early User Authorization Result PDU) [@rdpbcgr-negreq].
TLS handshake completes inside the RDP transport.
SPNEGO negotiates Kerberos or NTLM inside the TLS channel.
Kerberos or NTLM authenticates the user (and, for Kerberos, the server as well).
The TSCredentials payload is sent to the target inside the still-open TLS channel. "Once Kerberos or NTLM has completed successfully, the user's credentials are sent to the server" [@rdpbcgr-credssp].
The RDP basic-settings exchange and virtual-channel binding proceed.

sequenceDiagram autonumber participant C as Client (mstsc.exe) participant T as Target (lsass.exe + termsrv) participant K as KDC / domain controller C->>T: TCP/3389 + RDP_NEG_REQ (PROTOCOL_HYBRID 0x02) T-->>C: RDP_NEG_RSP (PROTOCOL_HYBRID selected) C->>T: TLS Client Hello T-->>C: TLS Server Hello + cert chain C->>T: SPNEGO NegTokenInit inside TLS C->>K: AS-REQ / TGS-REQ for target SPN K-->>C: AS-REP / TGS-REP C->>T: AP-REQ inside SPNEGO inside TLS T-->>C: AP-REP (mutual auth) C->>T: TSCredentials (TSPasswordCreds) T->>T: lsass logs user on, NT-OWF cached C->>T: RDP basic-settings exchange + session

Note: "Enable NLA" in the System Properties dialog flips a server-side policy that requires the connecting client to authenticate via CredSSP before the RDP session is established. NLA is that policy. CredSSP [@mscssp-index] is the wire protocol that satisfies it. When operators say "we require NLA," they mean "we accept only requestedProtocols = PROTOCOL_HYBRID or PROTOCOL_HYBRID_EX," which is enforced by Windows refusing the RDP_NEG_REQ if those bits are not set. The protocol carrying the credential to the target is CredSSP, today and twenty years from now.

What NLA accomplishes is real. The unauthenticated RDP channel-setup code -- basic-settings exchange, virtual-channel binding, the MS_T120 handler that BlueKeep would exploit a decade later -- is no longer reachable from the network. An attacker who reaches TCP/3389 must complete a CredSSP handshake (with valid Kerberos or NTLM credentials) before any RDP-stack code beyond the negotiation header runs. That is a denial-of-service mitigation and a pre-auth-RCE mitigation. It is not a credential-isolation mitigation.

What NLA does not accomplish is what happens at step 6. The output of CredSSP is TSPasswordCreds, which is the user's plaintext password (or its NTLM equivalent in some paths) delivered to the target's lsass.exe. Mimikatz sekurlsa::logonpasswords against the target after the session ends returns the user's NT-OWF [@mimikatz-github, @wiki-mimikatz], exactly as it would against a 1998-era classic-RDP target. The 2014 Microsoft Mitigating Pass-the-Hash whitepaper (version 2) [@msl-pthv2] named this failure mode eight years after NLA shipped: NLA is necessary but not sufficient.

Mimikatz had given the failure mode a name. Benjamin Delpy released the first version in May 2011, initially closed-source [@wiki-mimikatz]. In September 2011 a version of the exploit was used in the DigiNotar incident [@wiki-mimikatz]. By 2012, on a Windows estate running NLA-mandatory RDP since 2007, attackers were still pivoting from a compromised admin's workstation to every server that admin had logged into, harvesting NT-OWFs as they went. NLA was on the wire. The Pass-the-Hash playbook still worked.

NLA moved when the authentication happened. It did not change what the target ended up with. Pass-the-Hash against a 2012-era CredSSP-authenticated RDP target was identical to Pass-the-Hash against a 1998-era classic-RDP target. Microsoft's architectural response shipped in October 2013 -- and it was a structurally different idea.

4. BlueKeep, CVE-2018-0886, and the Two Failure Modes of CredSSP

The same NLA that mitigates BlueKeep also introduces CVE-2018-0886. The CVE class is not a coincidence. CredSSP is both the protocol that gates the pre-auth channel-setup code and the protocol whose own logic now has to be correct. Two CVEs anchor this section, six years apart.

CVE-2018-0886: CredSSP Remote Code Execution

On March 13, 2018, Microsoft patched a CredSSP logical flaw discovered by Preempt (now CrowdStrike) [@crowdstrike-credssp]. The NVD record states the vulnerability allows "a remote code execution vulnerability due to how CredSSP validates request during the authentication process" [@nvd-2018-0886] and classifies it as CWE-287 (Improper Authentication). The affected matrix is wide: Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1 / RT 8.1, Windows Server 2012 and R2, Windows 10 (1507 through 1709), Windows Server 2016, and Windows Server version 1709 [@nvd-2018-0886].

The mechanism is a man-in-the-middle injection. Preempt's disclosure timeline (verbatim from the CrowdStrike advisory) is "20/08/2017: Initial disclosure to MSRC; 30/08/2017: MS repro attack and acknowledge issue; 18/09/2017: Microsoft requested an extension on 90 days SLA; 12/03/2018: Microsoft fixes CVE-2018-0886 as part of March patch Tuesday" [@crowdstrike-credssp]. The attack scenarios are real-world: ARP poisoning on a flat LAN, KRACK against a poorly-patched Wi-Fi network, or a vulnerable router on the path between client and target.

The vulnerability consists of a logical flaw in Credential Security Support Provider protocol (CredSSP), which is used by RDP (Remote Desktop Protocol) and Windows Remote Management (WinRM)... The vulnerability can be exploited by attackers by employing a man-in-the-middle attack. -- CrowdStrike (formerly Preempt) [@crowdstrike-credssp]

The architectural lesson is that CredSSP's role as a security boundary creates a second security boundary inside the protocol itself. NLA gates the pre-auth code path behind CredSSP. If CredSSP has a bug, NLA does not protect anything beyond it; the bug is the pre-auth code path.

The AllowEncryptionOracle deployment incident

KB4093492 (May 8, 2018) is the worked example of how a protocol-layer compatibility shim becomes a deployment hazard [@msl-kb4093492]. The patch introduced a three-state registry value at HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\AllowEncryptionOracle. The states are:

Force Updated Clients (0) -- the client refuses to communicate with non-patched servers.
Mitigated (1) -- the client accepts patched servers and refuses unpatched servers (default after May 8, 2018).
Vulnerable (2) -- the client accepts both, preserving compatibility with unpatched servers (transitional default).

On May 8, 2018, Microsoft flipped the default from Vulnerable (2) to Mitigated (1). The KB article states bluntly: "By default, after this update is installed, patched clients cannot communicate with unpatched servers" [@msl-kb4093492]. RDP between patched and unpatched estates broke worldwide for a week. The diagnostic Event ID 6041 (LsaSrv, "Error encountered while reading from the protected payload of the bilateral exchange") appeared in millions of system logs.

Note: A protocol-layer compatibility shim is itself a deployment surface. The May 2018 default-flip from Vulnerable (2) to Mitigated (1) [@msl-kb4093492] was correct as a security posture and disastrous as a rollout sequence. Patch the servers before the clients; verify with Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters'; do not assume that "GPO push to clients" is the right first step.

CVE-2019-0708: BlueKeep

On May 14, 2019, Microsoft shipped a fix for a use-after-free in the MS_T120 virtual-channel binding handler inside termdd.sys -- the kernel-mode driver that handles RDP transport-layer code [@wiki-bluekeep]. The vulnerability, named BlueKeep by Kevin Beaumont on Twitter and discovered by the UK National Cyber Security Centre [@wiki-bluekeep], allowed pre-authentication remote code execution at SYSTEM on the target. The NVD record (CVE-2019-0708) lists references to PacketStorm exploits, Siemens advisories, the MSRC vendor advisory, and the CISA Known Exploited Vulnerabilities catalog [@nvd-2019-0708].

The affected matrix is "Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2" [@wiki-bluekeep]. Microsoft issued out-of-band patches for the end-of-life operating systems (Windows XP and Server 2003) [@wiki-bluekeep] -- a step the company reserves for vulnerabilities expected to be weaponised at scale. CISA, the NSA, and Microsoft all issued emergency advisories.

The common shorthand for BlueKeep is that it was "a vulnerability in pre-NLA RDP." The shorthand is wrong, and the precision matters because it sets up the wrong intuition for every authentication mode that follows.

NLA existed natively in every BlueKeep-affected operating system from Windows Vista onward -- Windows 7, Server 2008, and Server 2008 R2 all shipped NLA support, and many of those estates ran with NLA on. Windows XP and Server 2003 did not ship NLA natively; CredSSP / NLA was retrofitted to both via KB951608 (March 2009) [@wiki-bluekeep]. BlueKeep is a vulnerability in the channel-setup code reachable when NLA is not enforced -- the channel-setup code being the MS_T120 virtual-channel binder in termdd.sys, which is reachable only after the negotiation header but before the basic-settings exchange when CredSSP is not gating the path [@wiki-bluekeep].

When requestedProtocols = PROTOCOL_RDP (0x00) and the server permits it, the client skips the CredSSP gate and walks straight into the basic-settings exchange. The MS_T120 channel binding happens in that pre-authentication window. NLA closes that window by requiring PROTOCOL_HYBRID (0x02) (or _HYBRID_EX 0x08) before any RDP-stack code beyond the negotiation header runs. The mitigation guidance every operator received in May 2019 -- "enable NLA" -- worked because of this layering, not because BlueKeep was a vulnerability in a pre-NLA era.

The framing matters because the same precision applies to every later mode. Restricted Admin, Remote Credential Guard, and PRT-over-RDP all sit on top of CredSSP gating (or, for PRT-over-RDP, on top of a different gate entirely). None of them protect anything in the channel-setup phase. NLA does.

The BlueKeep out-of-band patch for Windows XP and Server 2003 [@wiki-bluekeep] is one of the rare exceptions to Microsoft's end-of-life policy. The 2017 WannaCry / EternalBlue cycle made Microsoft cautious about wormable pre-auth RCE on end-of-life operating systems; BlueKeep met the same threshold. The pattern -- a pre-auth RCE in long-deployed Windows networking code, with end-of-life patches issued out-of-band -- recurs about once every five years.

NLA mitigates BlueKeep but does not stop Pass-the-Hash. CredSSP itself has a non-trivial logical-attack surface. The architectural response to the Pass-the-Hash failure had already shipped five years before BlueKeep -- and it took the opposite approach. Instead of delivering the credential more securely, it stopped delivering the credential at all.

5. Restricted Admin: User Is the Machine (2013)

On October 17, 2013, Microsoft shipped a feature whose entire architectural insight fits in one sentence: stop delivering the user's credential to the target, and let the target log the user on as the target itself.

The feature is Restricted Admin mode, part of the CredSSP protocol family. It first shipped with Windows 8.1, Windows Server 2012 R2, and Windows RT 8.1 at RTM. Microsoft Security Advisory 2871997 states this verbatim: "Supported editions of Windows 8.1, Windows Server 2012 R2, and Windows RT 8.1 already include these features and do not need the 2871997 update" [@ms-adv-2871997]. The advisory is the load-bearing primary that pins the October 2013 ship date, because the advisory itself was the backport notice for older operating systems.

The shorthand "Restricted Admin shipped with KB2871997 in 2014" is a recurring misreading worth defusing. Restricted Admin shipped on three separate dates:

October 17, 2013 -- Windows 8.1, Windows Server 2012 R2, and Windows RT 8.1 RTM. Restricted Admin is in the box. No update required [@ms-adv-2871997].
May 13, 2014 -- KB2871997 backported the CredSSP-layer support to Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, and Windows RT [@ms-adv-2871997]. The advisory text reads verbatim: "On May 13, 2014, Microsoft released the 2871997 update for supported editions of Windows 8, Windows RT, Windows Server 2012, Windows 7, and Windows Server 2008 R2 that improves credential protection and domain authentication controls to reduce credential theft. This update provides additional protection for the Local Security Authority (LSA), adds a restricted admin mode for Credential Security Support Provider (CredSSP)..." [@ms-adv-2871997].
October 14, 2014 -- the RDP-client-side backport in KB2984972 (Win 7 / Server 2008 R2), KB2984976 (Win 7), KB2984981 (Win 7), and KB2973501 (Server 2012). Without the client-side update, Win 7 clients could not initiate a Restricted Admin RDP connection even though their CredSSP layer supported the protocol after May 2014 [@ms-adv-2871997].

If you read "2014 KB2871997" as the introduction date, the feature looks like a Windows-7-and-back retrofit. It is the opposite: Restricted Admin was a Windows 8.1 RTM feature whose value to the existing fleet was unlocked by two later backports.

The wire protocol

Restricted Admin opt-in lives in two bytes on the wire, both documented verbatim in MS-RDPBCGR. The client sets RDP_NEG_REQ.flags & RESTRICTED_ADMIN_MODE_REQUIRED = 0x01 to signal the request: "Indicates that the client requires credential-less logon over CredSSP (also known as 'restricted admin mode'). If the server supports this mode then it is acceptable for the client to send empty credentials in the TSPasswordCreds structure" [@rdpbcgr-negreq]. The server confirms support by setting RDP_NEG_RSP.flags & RESTRICTED_ADMIN_MODE_SUPPORTED = 0x08 in the response: "Indicates that the server supports credential-less logon over CredSSP" [@rdpbcgr-negrsp].

The CredSSP exchange itself runs end-to-end. TLS handshake completes; SPNEGO selects Kerberos or NTLM; the user authenticates. At step 6 -- where classic CredSSP would send a populated TSPasswordCreds -- the client sends an empty TSPasswordCreds. No password, no NT-OWF, no forwarded TGT. The target receives no credential material.

A CredSSP sub-mode signalled by the `RDP_NEG_REQ.flags & RESTRICTED_ADMIN_MODE_REQUIRED 0x01` bit [@rdpbcgr-negreq]. The client completes authentication to the target but sends an empty `TSPasswordCreds` payload; the target then logs the user on using the target's own machine account, restricting the session to actions the local Administrators group can perform. Introduced at Windows 8.1 / Server 2012 R2 RTM (October 17, 2013) [@ms-adv-2871997]; backported to Windows 7 / Server 2008 R2 via KB2871997 (May 13, 2014) and the October 14, 2014 client-side KBs.

The mechanism: the user becomes the machine

When the target sees an empty TSPasswordCreds and the RESTRICTED_ADMIN_MODE_REQUIRED flag, it does not refuse the logon. It logs the user on by impersonating the target's own machine account (<TARGETNAME>$). The machine account is in the local Administrators group by default; the user requesting the session must already be a member of the same group on the target. Microsoft Learn states the access prerequisite for Restricted Admin as "Membership of Administrators group on remote host" [@msl-rcg].

sequenceDiagram autonumber participant C as Client participant T as Target participant K as KDC C->>T: RDP_NEG_REQ (PROTOCOL_HYBRID 0x02 + flags 0x01) T-->>C: RDP_NEG_RSP (flags 0x08 supported) C->>T: TLS handshake C->>K: Kerberos AS / TGS for target SPN C->>T: AP-REQ inside SPNEGO (user authenticated) C->>T: TSPasswordCreds (EMPTY) T->>T: LogonUser as TARGET$ machine account T->>T: Token in local Administrators C->>T: RDP session as machine identity

Note: The breakthrough in Restricted Admin is not a new crypto primitive. It is the realisation that the target can act on the user's behalf by impersonating itself -- the target's own machine account -- which is already a local Administrator. The session has access to local resources, the user has full administrative use of the target, and the target's lsass.exe holds no user credential material. The trade is the user's downstream identity: the session cannot use the user's credentials for SSO, because the session is not the user. The session is the target.

The trade-offs, verbatim from Microsoft Learn

Microsoft Learn publishes a comparison matrix that lays out the trade-offs across Remote Desktop (classic), Remote Credential Guard, and Restricted Admin [@msl-rcg]. For Restricted Admin, the row entries are:

Prevent use of user's identity during connection: yes.
Prevent use of credentials after disconnection: yes.
Prevent Pass-the-Hash: yes.
Single sign-on to other systems: no.
Multi-hop RDP: no.
Supported authentication: any negotiated by CredSSP (Kerberos or NTLM).
Credentials supported from the client: signed-in credentials, supplied creds, saved creds.
RDP access granted with: membership of Administrators on the remote host [@msl-rcg].

This is the architectural trade. The user is gone the moment the session ends. The attacker who compromises the target during the session gets local Administrator -- but via the machine identity, not via the user's credential.

The RBCD residual class

There is no free lunch. Restricted Admin's "user becomes the machine identity" design creates a different residual surface. If the attacker can write the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target's computer object in Active Directory, the attacker can use Resource-Based Constrained Delegation to S4U2self + S4U2proxy a Kerberos service ticket for TERMSRV/<target> and RDP in as anyone.

Elad Shamir documented this in his January 28, 2019 essay "Wagging the Dog" [@shamir-wagging]. The TL;DR points are precise: "Resource-based constrained delegation does not require a forwardable TGS when invoking S4U2Proxy. S4U2Self works on any account that has an SPN, regardless of the state of the TrustedToAuthForDelegation attribute... if an attacker can control a computer object in Active Directory, then it may be possible to abuse it to compromise the host. S4U2Proxy always produces a forwardable TGS, even if the provided additional TGS in the request was not forwardable" [@shamir-wagging].

A Kerberos delegation model introduced in Windows Server 2012 where the *target* resource controls which principals can delegate to it via the `msDS-AllowedToActOnBehalfOfOtherIdentity` attribute on its own computer object. Combined with S4U2self and S4U2proxy, RBCD lets any principal that can write that attribute on a target's computer object obtain a forwardable Kerberos service ticket for any service on the target, including `TERMSRV` (the RDP service principal) [@shamir-wagging]. See the companion *NTLMless* article on this site for the wider S4U and Kerberos-relay discussion. Computer accounts just got a lot more interesting. Start hunting for more primitives to trigger attack chains! -- Elad Shamir, *Wagging the Dog* (2019) [@shamir-wagging]

Dec0ne's KrbRelayUp (2022) productionised the chain as "essentially a universal no-fix local privilege escalation in windows domain environments where LDAP signing is not enforced (the default settings)" [@krbrelayup]. The tool wraps Rubeus, KrbRelay, and ADCSPwn for a kerberos-relay-to-RBCD-to-ShadowCred-to-S4U2self-to-SCMUACBypass chain that ends in SYSTEM on the target. Restricted Admin's machine-identity-as-session design is exactly what this chain rewards: the attacker walks away with Administrator on the target via the machine identity, with no need to harvest the user's credential.

Restricted Admin solves the credential-aggregation problem for jump servers. It does so by eliminating SSO and requiring local Administrator on the target -- which means it cannot be the answer for regular user RDP. If the target needs to act as the user during the session but never holds the user's credentials, the only place those credentials can live is back on the caller. That insight took three more years to ship.

6. Remote Credential Guard: Challenges Redirect to Caller (2016)

Remote Credential Guard is what you get if you take Restricted Admin's "no credential material delivered to the target" rule and add "but the target still needs to act as the user during the session." Both halves are achievable. The cost is one extra RPC round-trip for every Kerberos operation the session performs -- and a hard dependency on Kerberos itself.

On August 2, 2016, Microsoft shipped Windows 10 1607 (the Anniversary Update) and Windows Server 2016 with Remote Credential Guard [@msl-rcg]. The Microsoft Learn page states the design property in one sentence: "Remote Credential Guard helps protecting credentials over a Remote Desktop (RDP) connection by redirecting Kerberos requests back to the device that's requesting the connection. If the target device is compromised, the credentials aren't exposed because both credential and credential derivatives are never passed over the network to the target device" [@msl-rcg].

The wire protocol

Opt-in lives in two more flag bits on the CredSSP negotiation. The client sets RDP_NEG_REQ.flags & REDIRECTED_AUTHENTICATION_MODE_REQUIRED = 0x02 to signal the request: the flag indicates "the client can send a redirected logon buffer in the TSRemoteGuardCreds structure" [@rdpbcgr-negreq]. The server confirms by setting RDP_NEG_RSP.flags & REDIRECTED_AUTHENTICATION_MODE_SUPPORTED = 0x10: "Indicates that the server supports credential-less logon over CredSSP with credential redirection (also known as 'Remote Credential Guard')" [@rdpbcgr-negrsp].

The credential payload changes. Instead of an empty TSPasswordCreds (Restricted Admin) or a populated one (classic CredSSP), the client sends a TSRemoteGuardCreds. The ASN.1 structure is documented verbatim in MS-CSSP [@mscssp-trgcreds]:

TSRemoteGuardCreds ::= SEQUENCE {
    logonCred         [0] TSRemoteGuardPackageCred,
    supplementalCreds [1] SEQUENCE OF TSRemoteGuardPackageCred OPTIONAL
}

The payload does not carry a password or a hash. It carries a handle that lets the target forward authentication challenges back to the caller. MS-CSSP states that "The logon credential is passed to the Negotiate package, which in turn passes the credential to the default authentication package" [@mscssp-trgcreds] -- the negotiate package on the target receives a redirect-handle, not a credential.

A CredSSP sub-mode signalled by the `RDP_NEG_REQ.flags & REDIRECTED_AUTHENTICATION_MODE_REQUIRED 0x02` bit [@rdpbcgr-negreq]. The session preserves the user's identity (unlike Restricted Admin), but every downstream Kerberos operation is performed by the caller's `lsass.exe` on behalf of the session, forwarded via RPC. Kerberos-only -- no NTLM fallback. Introduced in Windows 10 1607 and Windows Server 2016 (August 2, 2016) [@msl-rcg]. The CredSSP payload used by Remote Credential Guard [@mscssp-trgcreds]. A `SEQUENCE` of a `logonCred` and zero or more `supplementalCreds`, each of type `TSRemoteGuardPackageCred`. The handle is opaque to the target's authentication package; the target uses it only to request operations from the caller.

The runtime mechanism

The interesting half of Remote CG runs after the session establishes. Suppose the user, now logged into the target as themselves, opens a file from a network share, mounts a database connection, or starts a second RDP hop. Each of those actions needs a Kerberos service ticket. The session host does not call KerbCreateTicket() itself. It packages an RPC request and sends it back to the caller's machine, where the caller's lsass.exe performs the operation using the caller's TGT and session key, then returns the resulting service ticket to the target session.

sequenceDiagram autonumber participant C as Client + caller lsass participant T as Target session host participant K as KDC participant F as File server (TGS target) C->>T: RDP_NEG_REQ (flags 0x02) T-->>C: RDP_NEG_RSP (flags 0x10) C->>T: TLS handshake C->>T: TSRemoteGuardCreds (handle) T->>T: Session start as user identity T->>C: RPC: TGS-REQ for cifs/fileserver C->>K: TGS-REQ K-->>C: TGS-REP C-->>T: TGS-REP forwarded back T->>F: AP-REQ with forwarded TGS F-->>T: AP-REP, SMB session

The cost is a round-trip per Kerberos operation. Over a LAN that is a few milliseconds; over a WAN that can be 50 milliseconds or more.About 5ms LAN, 50ms WAN, per operation.Remote CG is the only RDP authentication mode with runtime overhead proportional to downstream Kerberos hops. Classic CredSSP, Restricted Admin, and PRT-over-RDP all complete their credential exchange before the session starts; the session then talks to downstream services using credentials that already live on the target. Remote CG keeps the credentials at home and pays an RPC round-trip every time the session needs one. On a chatty workload -- mounting multiple SMB shares, opening many database connections, or chaining RDP hops -- this overhead is observable.

The trustlet conditional

A common belief about Remote Credential Guard is that it stores the redirected-authentication signing material in the caller's VBS trustlet LsaIso.exe. That is partly true and worth getting precise.

Remote Credential Guard always redirects challenges to the caller's lsass.exe. Where the long-lived signing material lives on the caller is a separate question:

If the caller has local Credential Guard enabled, the secrets that back the redirected operations live in the caller's VTL1 LsaIso.exe trustlet, isolated from VTL0 user-mode code on the caller.
If the caller does not have local Credential Guard, the same material lives in regular user-mode lsass.exe on the caller, with no VTL1 isolation.

The protocol still works in both cases. The redirection still happens. What changes is the protection the caller's lsass gets from an attacker who later compromises the caller. See the companion Credential Guard article on this site for the LsaIso internals.

The "isolated LSA" trustlet that runs in VTL1 under Virtualization-Based Security when Credential Guard is enabled. Stores credential-derived secrets (NTLM hash, Kerberos session key, TGT key, certificate private keys) outside the reach of VTL0 code, including kernel-mode rootkits. Documented in detail in the companion *Credential Guard* article on this site.

Note: Remote Credential Guard always protects the credential from the target -- the target never sees it, regardless of caller configuration. Remote Credential Guard protects the credential from a post-compromise of the caller only if the caller has local Credential Guard enabled. The shorthand "Remote CG runs in a VBS trustlet" is true only for the second protection; for the first, the protection lives in the protocol, not in VBS.

Kerberos-only -- and what that means for NTLM-mixed estates

Remote CG depends on Kerberos. Microsoft Learn is explicit: "Must use Kerberos authentication to connect to the remote host. If the client can't connect to a domain controller, then RDP attempts to fall back to NTLM. Remote Credential Guard doesn't allow NTLM fallback because it would expose credentials to risk" [@msl-rcg].

The reason is structural. NTLM challenge-response sends a chosen-plaintext-style hash of the user's NT-OWF to the target. Remote CG's redirection scheme works for Kerberos because the target can ask the caller to mint a service ticket; there is no equivalent operation in NTLM. Remote CG has nothing to redirect that does not eventually require the caller to hand over usable hash material.

Operationally, this means a 2026 estate that has not finished NTLM deprecation work cannot universally deploy Remote CG. Any RDP path that would fall back to NTLM -- a workgroup machine, a target whose Kerberos SPN registration is broken, a destination behind a DC-isolating firewall rule -- refuses to negotiate Remote CG and either fails the session or falls back to Restricted Admin (depending on the RestrictedRemoteAdministration GPO setting). See the companion NTLMless article on this site for the wider context.The UWP Remote Desktop client (the modern Microsoft Store variant) does not support Remote Credential Guard [@msl-rcg]. Only the classic mstsc.exe Win32 client implements the negotiation. Operators planning to enforce Remote CG must inventory which client binaries connect to which targets; mixing UWP clients into a Remote-CG-mandatory target pool produces silent connection failures.

Remote CG closes credential-after-disconnection and Pass-the-Hash without sacrificing SSO. It does so by demanding Kerberos and one extra RPC per downstream hop. But the model assumes the user has on-prem-AD-routable Kerberos credentials -- which a Microsoft-Entra-joined laptop without hybrid join does not. The next generation throws away Kerberos entirely.

7. PRT-over-RDP: No Password, No Hash, No Ticket (2022)

On October 11, 2022, Microsoft shipped the first RDP authentication mode that has no lsass.exe-credential-delivery story to tell -- because there is no NTLM hash, no Kerberos ticket, and no password in the entire exchange. The credential is a JSON Web Token issued by Microsoft Entra ID.

The shipping vehicle was the October 2022 cumulative updates: KB5018418 (Windows 11), KB5018410 (Windows 10 20H2+), and KB5018421 (Windows Server 2022). KB5018418's release notes pin the date precisely: "Release Date: 10/11/2022. Version: OS Build 22000.1098" [@msl-kb5018418]. The Microsoft Learn page for the feature lists the same prerequisites: "The remote PC and your local device must be running one of the following operating systems: Windows 11 with 2022-10 Cumulative Updates for Windows 11 (KB5018418) or later installed" [@msl-prtrdp-mstsc].

PRT-over-RDP (Microsoft's official name: "Microsoft Entra single sign-on for Remote Desktop") is sometimes attributed to "2025." The misreading is worth defusing because the date affects what one believes is on the deployment frontier.

The feature shipped in October 2022 [@msl-prtrdp-mstsc, @msl-kb5018418]. The 2025 angles are two: Windows 11 24H2 reached broad consumer GA in October 2024, and a CredSSP/RDP regression in 24H2 produced session hangs and 65-second disconnects in early 2025; Microsoft rolled out a Known Issue Rollback ("KIR") via Group Policy in March 2025, and the Windows 11 24H2 release-health page now reads "There are no active known issues at this time" as of March 27, 2025 [@msl-24h2-status]. PRT-over-RDP itself has been a generally-available feature since October 2022; the 2025 events were deployment-stack stability work, not feature ship dates.

The wire protocol

Microsoft introduced a new value for requestedProtocols -- PROTOCOL_RDSAAD = 0x10 [@rdpbcgr-negreq] -- and an entirely new sub-protocol underneath it, "RDS AAD Auth." Section 5.4.5.4 of MS-RDPBCGR documents it verbatim: "RDS AAD Auth is a variation of Enhanced RDP Security that is used to authenticate a user to an Azure AD-joined device or to a Hybrid Azure AD-joined device. Server authentication, encryption, decryption, and data integrity checks are implemented by using the TLS security protocol, while user authentication is accomplished by exchanging RDS AAD Auth PDUs directly following the TLS handshake" [@rdpbcgr-rdsaad].

The CredSSP exchange is replaced entirely. No SPNEGO. No Kerberos. No NTLM. No TSCredentials. The TLS handshake still happens, because TLS is providing the wire confidentiality and server authentication. After the TLS handshake, the new RDS-AAD-Auth PDU stream takes over. The user-side credential becomes a PRT-cookie scoped to a Conditional Access application.

A long-lived OAuth refresh token bound to a Microsoft-Entra-joined or hybrid-joined device. The PRT holds proof of the user's primary authentication (typically including a Windows Hello for Business gesture or FIDO2 ceremony) and signs short-lived JWT cookies that authenticate the user to Entra-ID-integrated applications. The PRT's signing key is held in the device's TPM where possible. See the companion *Entra ID and the Primary Refresh Token* article on this site for the full mechanism. The Cloud Authentication Provider, an LSA authentication package introduced for Microsoft Entra ID (then Azure AD) sign-in. CloudAP runs inside `lsass.exe` and manages PRT issuance, refresh, and the minting of PRT-cookies for downstream authentication. On the target side of a PRT-over-RDP session, CloudAP validates the inbound PRT-cookie and produces the user's Windows session token without ever contacting a domain controller [@mollema-prt2].

The mechanism: from `.rdp` file to Entra-issued session

The client-side flow starts with an .rdp connection file that includes enablerdsaadauth:i:1 [@msl-rdp-files]. The official MSTSC user-facing label is "Use a web account to sign in to the remote computer." When the user clicks Connect:

The local CloudAP plugin generates a PRT-cookie scoped to the Conditional Access application a4a365df-50f1-4397-bc59-1a1564b8bb9c ("Microsoft Remote Desktop"). The Microsoft Learn documentation pins this app ID verbatim: "Conditional Access policies can be applied to the application Microsoft Remote Desktop with ID a4a365df-50f1-4397-bc59-1a1564b8bb9c to control access to the remote PC when single sign-on is enabled" [@msl-prtrdp-mstsc].
mstsc.exe opens TCP/3389 (or UDP/3389 for Shortpath) and sends RDP_NEG_REQ with requestedProtocols = PROTOCOL_RDSAAD (0x10) [@rdpbcgr-negreq].
TLS handshake completes; the target's server certificate is validated against the Entra device-identity.
The client sends RDS-AAD-Auth PDUs containing the PRT-cookie [@rdpbcgr-rdsaad].
The target's CloudAP plugin validates the cookie against Microsoft Entra ID. Entra ID evaluates the Conditional Access policies that target a4a365df-..., including device compliance, location, sign-in risk, and Authentication Strength.
On success, Entra ID issues an access token scoped to the target. The target's CloudAP plugin signs the user in. The RDP session starts.

sequenceDiagram autonumber participant C as Caller (CloudAP + mstsc) participant T as Target (CloudAP + termsrv) participant E as Microsoft Entra ID C->>C: CloudAP mints PRT-cookie for a4a365df C->>T: RDP_NEG_REQ (PROTOCOL_RDSAAD 0x10) T-->>C: RDP_NEG_RSP (PROTOCOL_RDSAAD selected) C->>T: TLS handshake C->>T: RDS-AAD-Auth PDU with PRT-cookie T->>E: Validate cookie + apply CA policies E-->>T: Access token for target SPN T->>T: CloudAP signs user in C->>T: RDP session as Entra principal The `.rdp` connection-file property that opts into RDS-AAD-Auth (PRT-over-RDP) [@msl-rdp-files]. Verbatim from Microsoft Learn: "Determines whether the client will use Microsoft Entra ID to authenticate to the remote PC. When used with Azure Virtual Desktop, this provides a single sign-on experience. This property replaces the property `targetisaadjoined`." The two valid values are `0` (disable) and `1` (enable).

Two GUIDs, two purposes

PRT-over-RDP brings two distinct Microsoft Entra IDs into play, and the article must keep them separate.The user-facing Conditional Access application "Microsoft Remote Desktop" has the application ID a4a365df-50f1-4397-bc59-1a1564b8bb9c [@msl-prtrdp-mstsc]. The AVD-side configuration uses a distinct service principal "Windows Cloud Login" with ID 270efc09-cd0d-444b-a71f-39af4910ec45 [@msl-avdsso], configured via Update-MgServicePrincipal ... -Settings @{ isRemoteDesktopProtocolEnabled = $true }. Both IDs exist for legitimate reasons; both pages are alive; they configure different layers. The Conditional Access policy in the admin console targets a4a365df-...; the AVD-side enablement flag flips on 270efc09-.... The a4a365df-... application is the user-facing PRT-cookie audience; Conditional Access policies that gate RDP sign-in (require WHfB, require compliant device, block from foreign geographies) target this app ID. The 270efc09-... service principal is the AVD-side enablement flag for the configuration described in Azure Virtual Desktop documentation: "Your session hosts must be Microsoft Entra joined or Microsoft Entra hybrid joined. Session hosts joined to Microsoft Entra Domain Services or to Active Directory Domain Services only aren't supported" [@msl-avdsso].

Note: PRT-over-RDP is the first RDP authentication mode whose wire-protocol selector does not have a CredSSP underneath it. PROTOCOL_RDSAAD (0x10) [@rdpbcgr-negreq] is its own path. The user's credential is a JWT cookie [@msl-prtrdp-mstsc] signed by a key derived from the device's session key (and bound to the TPM where possible). There is no NTLM hash to extract from the target; there is no Kerberos session key to relay. The residual surface is PRT-extraction from the caller's CloudAP cache -- not from the target.

PRT-over-RDP is the first RDP authentication mode that is intrinsically phishing-resistant when paired with Windows Hello for Business [@msl-prtrdp-mstsc]. It is also the first mode that requires both endpoints to be Microsoft-Entra-joined (or hybrid-joined) [@msl-avdsso]. A 2026 enterprise estate ends up running all five modes in parallel -- none retiring the others -- because no single Pareto-optimal point dominates the others.

8. Five Modes, One Matrix, 2026 Operational Reality

By 2026 the RDP authentication stack ships five compositional modes, negotiated by two distinct mechanisms in MS-RDPBCGR. The requestedProtocols field [@rdpbcgr-negreq] selects between classic RDP, TLS, CredSSP, and RDS-AAD-Auth. The flags byte signals the Restricted Admin and Remote Credential Guard sub-modes inside CredSSP. A real estate runs all five in different connection paths. None of them retire the others.

The Microsoft Learn page for Remote Credential Guard publishes the canonical practitioner-grade comparison matrix [@msl-rcg]. Reproducing it verbatim:

Property	Remote Desktop	Remote Credential Guard	Restricted Admin
Single sign-on (SSO) for sessions	Yes	Yes	No
Multi-hop RDP	Yes	Yes	No
Prevent use of user's identity during connection	No	No	Yes
Prevent use of credentials after disconnection	No	Yes	Yes
Prevent Pass-the-Hash	No	Yes	Yes
Supported authentication	Any negotiable by SSP	Kerberos only	Any negotiable by SSP
Credentials supported from the client device	Signed-in creds, supplied creds, saved creds	Signed-in creds only	Signed-in creds, supplied creds, saved creds
RDP access granted with	Remote Desktop Users (target)	Remote Desktop Users (target)	Administrators (target)

The matrix anchors three points of precision. First, "Prevent use of user's identity during connection" is No for both classic Remote Desktop and Remote Credential Guard. Only Restricted Admin can promise that the user's identity is not exercised on the target -- because only Restricted Admin replaces the user's identity with the target's machine identity.

Second, "Prevent use of credentials after disconnection" is Yes for Remote CG and Restricted Admin but No for classic. Third, "RDP access granted with" is the access control primitive, not the credential primitive: Restricted Admin demands Administrators-group membership on the target because the user is impersonating the machine account.

The matrix excludes the two non-CredSSP modes -- classic-RDP (PROTOCOL_RDP = 0x00) and PRT-over-RDP (PROTOCOL_RDSAAD = 0x10). Extending the matrix to all five modes:

Property	Classic RDP	NLA (CredSSP)	Restricted Admin	Remote Credential Guard	PRT-over-RDP
Wire selector	`PROTOCOL_RDP 0x00`	`PROTOCOL_HYBRID 0x02`	CredSSP + `0x01` flag	CredSSP + `0x02` flag	`PROTOCOL_RDSAAD 0x10`
Credential delivered to target	Password in RC4 channel	Password in TLS (TSPasswordCreds)	Empty TSPasswordCreds	TSRemoteGuardCreds handle	Entra PRT-cookie (JWT)
Target session identity	User	User	Machine (`TARGET$`)	User	User (Entra principal)
User credential at target lsass	Yes (NT-OWF + plaintext)	Yes (NT-OWF)	No	No	No
SSO to downstream services	Yes	Yes	No	Yes (via caller RPC)	Yes (Entra token cache)
Multi-hop RDP	Yes	Yes	No	Yes	Yes (Entra)
Requires Administrators on target	No	No	Yes	No	No
NTLM fallback allowed	Yes	Yes	Yes	No	No
Pre-auth-RCE protection (NLA)	No	Yes	Yes	Yes	Yes (via TLS-first gate)
First shipped	RDP 4.0 / 1998	RDP 6.0 / Vista / Nov 2006	Win 8.1 / Server 2012 R2 / Oct 17, 2013	Win 10 1607 / Server 2016 / Aug 2, 2016	KB5018418 / Oct 11, 2022
Canonical CVE	BlueKeep (channel-setup)	CVE-2018-0886 (CredSSP RCE)	RBCD against TERMSRV	Kerberos RBCD residual	PRT-extraction at session host

Key idea: The five modes are not strictly ordered. Each occupies a different point on the Pareto frontier of (no-credential-leak × SSO × universality × Kerberos-compatibility). An operator's job is to choose two of {Entra-issued sessions, on-prem Kerberos SSO, no credential delegation, no local-admin requirement} per RDP pair -- the matrix exists because nobody gets all four.

The 2026 operational defaults split along clean lines. The universal baseline is NLA mandatory (refuse PROTOCOL_RDP = 0x00), AllowEncryptionOracle = 0 (Force Updated Clients) [@msl-kb4093492], NTLMv1 disabled at the domain controller, and the target-side GPO "Remote host allows delegation of nonexportable credentials" set so Remote CG can opt in without prompting. On top of that baseline:

Admin-tier jump servers: Restricted Admin (RestrictedRemoteAdministration GPO mode 1, "Require Restricted Admin") [@msl-rcg].
User-tier domain RDP: Remote Credential Guard (RestrictedRemoteAdministration GPO mode 2 for "Require Remote Credential Guard", or mode 3 for "Restrict credential delegation" -- the composite that prefers Remote CG and falls back to Restricted Admin when Remote CG cannot complete) [@msl-rcg].
Entra-joined estates and AVD / Cloud-PC: PRT-over-RDP via enablerdsaadauth:i:1 [@msl-rdp-files], gated by Conditional Access on the a4a365df-... app [@msl-prtrdp-mstsc].
Legacy compatibility lane: NLA-mandatory classic CredSSP, accepting that the target's lsass will hold credential material for the session duration.

Note: Regardless of which higher-level mode you choose, four settings should be on every Windows target before you read further: NLA mandatory; AllowEncryptionOracle = 0 [@msl-kb4093492]; NTLMv1 disabled; "Remote host allows delegation of nonexportable credentials" set so Remote CG opt-in does not prompt. These four are the floor. Everything else is a per-target choice on top of them.

The matrix is the load-bearing artifact. The next four sections walk what it does not solve: the perimeter mitigations the matrix excludes, the theoretical limits no mode can close, the open problems still in the literature, and the practical guide an operator runs on Monday.

9. Adjacent Mitigations: What Else Protects RDP (And What It Does Not Protect)

Six adjacent mechanisms get called "RDP security" in vendor marketing. None of them are credential-protection mechanisms. They solve different problems at different layers, and conflating them with the five-mode matrix is the load-bearing operational confusion in modern RDP deployments.

Remote Desktop Gateway / RDS Gateway. A network-layer reverse-proxy that tunnels RDP inside HTTPS on TCP/443. The Gateway terminates the TLS connection from the internet, authenticates the user (often via smart card or Microsoft Entra), and forwards the inner RDP session to the back-end target. Gateway solves "RDP exposed to the internet on TCP/3389." It does not change which CredSSP sub-mode the inner session negotiates. If the inner session is classic-NLA, the target's lsass receives the user's NT-OWF, gateway or not.

Note: A common misconception is that an RDS Gateway "protects credentials." It does not. The Gateway proxies the RDP session, which still negotiates classic, Restricted Admin, Remote CG, or PRT-over-RDP between the client and the back-end target. The Gateway is a perimeter primitive, not an authentication mode. An operator who deploys RDS Gateway and enforces Remote CG on the back-end pool has stacked two complementary mitigations. An operator who deploys RDS Gateway and leaves the back-end pool on classic NLA has hardened the perimeter without changing the post-exploitation pivot.

Just-Enough Administration (JEA) over PowerShell Remoting. The "don't use RDP for admin in the first place" answer. JEA constrains a PowerShell Remoting session to a curated set of cmdlets executed under a managed virtual account. The transport is WSMan over HTTPS (TCP/5986 with TLS, or TCP/5985 plain), not RDP.

WSMan has its own CredSSP exposure -- CVE-2018-0886 affects WinRM as well as RDP [@nvd-2018-0886] -- but a JEA endpoint configured for RunAsVirtualAccount does not delegate the operator's credentials at all. JEA combined with Remote Credential Guard for the remaining graphical-admin paths is the de facto 2026 reference architecture for admin-tier work.

A PowerShell-Remoting feature that constrains a remote session to a whitelisted set of commands executed under a managed virtual account, eliminating credential delegation for the operator. JEA is not an RDP mode; it is the "use a different protocol entirely" alternative for administrative tasks that do not need a graphical session. Configured via PowerShell session-configuration files (`.pssc`) and role-capability files (`.psrc`).

Smart-card and FIDO2 as the underlying credential. A user can authenticate to NLA / CredSSP using a smart card (Kerberos with PKINIT) or, for PRT-over-RDP, a Windows Hello for Business or FIDO2 ceremony. The credential type matters for phishing resistance and for replayability. It does not change what the target ends up with after the CredSSP exchange completes. A smart-card-backed NLA session still ends with a Kerberos session key in the target's lsass.exe. Phishing-resistant authentication is necessary but not sufficient; the post-exchange credential isolation lives in Restricted Admin, Remote CG, or PRT-over-RDP.

Azure Bastion / AWS Session Manager. Cloud-managed jump-host services that present a web UI and proxy RDP / SSH connections to back-end VMs without exposing 3389 to the internet. Bastion handles the network-layer exposure problem. The credential-protection guarantees still depend on which CredSSP sub-mode the inner RDP session negotiates. Bastion does not magic away the requirement to also configure Restricted Admin or Remote CG on the back-end pool.

RDP-over-QUIC / AVD RDP Shortpath. The Microsoft Azure Virtual Desktop "Shortpath" feature carries RDP traffic over UDP, with four variants documented verbatim on Microsoft Learn: "RDP Shortpath for managed networks; RDP Shortpath for managed networks with ICE/STUN; RDP Shortpath for public networks with ICE/STUN; RDP Shortpath for public networks via TURN" [@msl-shortpath]. The transport sits on QUIC, the UDP-based transport standardised in RFC 9000 [@rfc-9000].

The Tech Community announcement of public-networks GA states verbatim: "We are pleased to announce the general availability of RDP Shortpath for public networks... We started deploying RDP Shortpath in September and now the feature is 100% rolled out" [@tc-shortpath-blog]; the announcement is dated late 2022. The TURN-relayed variant is GA in late 2024 per the Microsoft AVD blog series.

Microsoft's QUIC/UDP transport for RDP, used inside Azure Virtual Desktop and Windows 365 [@msl-shortpath]. Four variants cover managed networks, ICE/STUN-mediated traversal, public-network NAT traversal, and TURN-relayed paths through restrictive NAT. The authentication stack above the transport is unchanged from TCP-based RDP; QUIC replaces TCP/TLS with UDP/QUIC at the bottom of the stack only.

What changes with QUIC transport is the detection surface. Network sensors keyed on TCP/3389 + TLS handshake + CredSSP TS Request/Response see nothing for an AVD Shortpath session; what they should look for instead is UDP/<ephemeral> + QUIC handshake + STUN/ICE candidate exchange. The credential-protection guarantees are identical to the underlying RDP mode; the visibility-engineering work is real.FreeRDP and xrdp -- the two widely-used non-Microsoft RDP stacks -- implement a subset of the five modes. xrdp does not implement CredSSP server-side, so xrdp targets are reachable only via PROTOCOL_RDP or PROTOCOL_SSL; an operator who enables NLA on an xrdp host has effectively prevented Windows clients from connecting. FreeRDP supports classic, NLA / CredSSP, and Restricted Admin as a client, but does not implement Remote Credential Guard or PRT-over-RDP. Detection engineering for mixed-stack estates must account for these limits.

Conditional Access, Microsoft Entra PIM, Just-In-Time access. Workflow-level controls that grant RDP access (the user must satisfy a PIM activation request before the JIT-provisioned admin group adds them; the Conditional Access policy must pass before the PRT-cookie is minted). These are orthogonal to what happens during the RDP session. A PIM-elevated admin session that runs classic-NLA RDP still leaves the admin's credential in the target's lsass when the session ends.

None of these mechanisms change the credential the target ends up with. That is the load-bearing fact. The next section walks the four classes of attack that no RDP mode -- regardless of how many adjacent mitigations are stacked -- can close.

10. Theoretical Limits: The Four Things RDP Authentication Cannot Close

The five modes between them close credential delegation (Restricted Admin), credential-after-disconnection (Restricted Admin and Remote CG), the password-and-hash entirely (PRT-over-RDP), and the pre-auth channel-setup surface (NLA). The four limits below are what is left. Each has a formal lower bound. None is closable by a sixth mode.

Limit 1: The SYSTEM-on-target floor

Any RDP mode that grants the user an actionable identity on the target permits a SYSTEM-on-target adversary to use that identity for as long as the user stays connected. The session host kernel must materialise the user's security token to enforce ACL checks. An attacker with SYSTEM on the target can call OpenProcessToken against any process in the user's session, then DuplicateTokenEx and ImpersonateLoggedOnUser to perform actions as the user. Microsoft Learn encodes this as "Prevent use of user's identity during connection: No" for both Remote Desktop and Remote Credential Guard [@msl-rcg].

Remote Credential Guard helps protecting credentials over a Remote Desktop (RDP) connection by redirecting Kerberos requests back to the device that's requesting the connection. If the target device is compromised, the credentials aren't exposed because both credential and credential derivatives are never passed over the network to the target device. -- Microsoft Learn [@msl-rcg]

That sentence promises protection of credentials. It does not promise protection of the user's identity in-session. The two properties are different and only one is closable by an authentication-protocol redesign.

Note: No RDP mode can simultaneously give the target the ability to act as the user and prevent a SYSTEM adversary on the target from acting as the user. The defense is not to close in-session impersonation; the defense is to not put the user on a compromised target. Restricted Admin closes it by giving up the user's identity entirely. Every mode that preserves the user's identity (classic, NLA, Remote CG, PRT-over-RDP) leaves the SYSTEM-on-target floor open.

Limit 2: The CredSSP residue

Even on a 2026 Entra-joined estate using PRT-over-RDP, CredSSP remains on the wire for every RDP path touching a non-Entra-joined endpoint. Legacy admin tooling, multi-hop sessions into on-prem servers, RDS deployments, hybrid scenarios -- all of them fall back to CredSSP. CredSSP has shipped at least one logical-flaw RCE (CVE-2018-0886) [@nvd-2018-0886] and the AllowEncryptionOracle compatibility window [@msl-kb4093492] remains a deployment hazard whenever a new CredSSP patch ships.

The architectural answer (deprecate CredSSP wholly, replace it with RDS-AAD-Auth for every RDP path) is not on Microsoft's public roadmap. MS-CSSP's current revision is 21.0, dated April 23, 2024 [@mscssp-index] -- the protocol is actively maintained, not deprecated. Operationally, CredSSP is a permanent fixture of any Windows estate that includes on-premises identity.

Limit 3: The RBCD-against-TERMSRV class

Restricted Admin closes credential delegation. It does not close the machine-identity-as-attack-primitive class. Any principal that can write msDS-AllowedToActOnBehalfOfOtherIdentity on a target's computer object can S4U2self + S4U2proxy a TERMSRV/<target> ticket and RDP in as any account -- including a Domain Admin [@shamir-wagging]. Dec0ne's KrbRelayUp productionises this as "a universal no-fix local privilege escalation in windows domain environments where LDAP signing is not enforced (the default settings)" [@krbrelayup].

The phrase "no-fix" is doing real work. The chain depends on default LDAP-signing settings, default kerberos delegation behaviour for resource-based constrained delegation, and the user-creatable computer object quota of ms-DS-MachineAccountQuota = 10 [@shamir-wagging] -- four configurations that are independently defensible per protocol but that compose into the chain. Tightening any one of them mitigates KrbRelayUp; Microsoft has not chosen to do so by default.

Limit 4: The Entra-only / on-prem-only gap

PRT-over-RDP requires both endpoints to be Microsoft-Entra-joined or hybrid-joined [@msl-prtrdp-mstsc, @msl-avdsso]. Restricted Admin and Remote CG require Kerberos and on-premises Active Directory. The two architectures do not compose: a non-hybrid Entra-joined estate cannot deploy Restricted Admin or Remote CG; an on-prem-AD estate cannot deploy PRT-over-RDP. Hybrid join is the bridging primitive, but it has its own configuration cost (Entra Connect, device-write-back, certificate trust, password hash sync), and many estates have hybrid-join enabled for only a subset of devices.

The five RDP modes occupy different points on a four-axis Pareto frontier: (no-credential-leak × SSO × universality × Kerberos-compatibility). No mode dominates any other on all four axes simultaneously.

Classic credential delegation gives universality and SSO and Kerberos-compatibility, at the cost of credential-leak protection.
NLA via CredSSP adds pre-auth-RCE gating, but the credential-leak axis is identical to classic.
Restricted Admin gives credential-leak protection and Kerberos-compatibility, at the cost of SSO and the universality of the "any user" property (because of the Administrators-group requirement).
Remote Credential Guard gives credential-leak protection and SSO, at the cost of universality (Kerberos-only).
PRT-over-RDP gives credential-leak protection and SSO and modern phishing-resistant authentication, at the cost of Kerberos-compatibility and the Entra-joined-everywhere requirement.

The operator's job is composition: pick the mode that matches each RDP pair's constraints, accept that two of the four axes will fail for that pair, and use the other modes for the other pairs. A typical 2026 enterprise pool runs (at least) NLA-mandatory classic for legacy, Restricted Admin for admin-tier, Remote CG for user-tier domain RDP, and PRT-over-RDP for AVD. Four authentication modes on one estate is the normal state.

Three of the four limits are bounded: they may shrink as Microsoft deprecates NTLM, ships VBS-trustlet protection for CloudAP on session hosts, or unifies the Entra and on-prem identity surfaces. One is architectural and applies to every authentication protocol ever proposed: SYSTEM on the target equals the user's identity for as long as the user stays connected. The next section walks the active research where the bounded limits are still moving.

11. Open Problems: Where Research and Operations Are Still Moving

Five open problems sit on the RDP authentication stack right now. Three are research-class. Two are operational-class. None has a "just ship a patch" answer.

Open Problem 1: PRT extraction at the session host

A session host that serves N concurrent RDP-in connections with PRT-over-RDP caches at least N CloudAP entries. A SYSTEM adversary on the session host can dump all of them. Dirk-jan Mollema's August 2020 follow-up to his original PRT abuse research [@mollema-prt2] describes the underlying primitive in collaboration with Benjamin Delpy (Mimikatz author). The verbatim quote is decisive:

Around the same time Benjamin Delpy took up my 'challenge' of recovering PRT data from lsass with mimikatz. We combined forces and ended up with tooling that is not only able to extract the PRT and associated cryptographic keys (such as the session key) from memory, but can also use these keys to create new SSO cookies or modify existing ones. Interesting enough, it turns out that despite the session key of the PRT is stored in the TPM whenever possible, this doesn't prevent us from extracting the PRT and the required information to create SSO cookies. The result of this is that regardless of whether the PRT is protected by the TPM or not, with Administrator access it is possible to extract the PRT from LSASS and use the PRT on a different device than it was issued to. -- Dirk-jan Mollema, *Digging Further Into the Primary Refresh Token* (2020) [@mollema-prt2]

That property -- the PRT and session key are recoverable from CloudAP lsass.exe memory irrespective of TPM protection -- holds on the receiving session host the same way it holds on the issuing device. This is the 2026 mirror of the 2008 "RDP into the Citrix jump server and dump credentials" problem.

The architectural answer is to run CloudAP inside a VBS trustlet (analogous to LsaIso.exe for NTLM and Kerberos) on every session host. Microsoft has not publicly committed to that work. The original PRT post [@mollema-prt1] notes that "if there is no TPM the keys are stored in software... If a TPM is present, the keys required to request or use the PRT are protected by the TPM and can't be extracted under normal circumstances" -- but "under normal circumstances" excludes the SYSTEM-on-target adversary the session-host scenario assumes.

Open Problem 2: CredSSP is not deprecable

MS-CSSP revision 21.0 (April 23, 2024) [@mscssp-index] is a maintained protocol; no Microsoft roadmap deprecates it. The role transitions from "the authentication layer for RDP and WinRM" to "the compatibility shim for everything that does not speak RDS-AAD-Auth," but compatibility shims do not retire in the absence of a forcing function. Every CredSSP CVE in the next decade lands on a still-deployed surface. The AllowEncryptionOracle deployment pattern [@msl-kb4093492] is not the last of its kind.

Open Problem 3: Remote CG NTLM exclusion and the hybrid-estate user experience

Remote Credential Guard is Kerberos-only [@msl-rcg]. The RestrictedRemoteAdministration GPO mode 3 is the composite "Restrict credential delegation" policy that prefers Remote CG and falls back to Restricted Admin when Remote CG cannot complete [@msl-rcg].

The result is a fragmented user experience: on Monday a user RDPs to server01 and gets Remote CG (SSO works); on Tuesday the user RDPs to server02 whose DC trust path has a transient routing problem and gets Restricted Admin (SSO does not work). The user observes "RDP to server02 is broken" and files a ticket; the platform team observes "the GPO fall-back is working as designed." This pattern persists until NTLM is universally removed from the estate, which is itself an open multi-year project. See the companion NTLMless article on this site for the wider deprecation arc.

Open Problem 4: The Entra / on-prem composition gap

Real enterprise estates are a Venn diagram of Entra-only desktops, hybrid-joined Windows 11 laptops, and on-prem-AD-only servers. PRT-over-RDP works between Entra-joined and hybrid-joined endpoints [@msl-prtrdp-mstsc]; Restricted Admin and Remote CG work between Kerberos-routable endpoints; the four cells in the 2x2 ({client-Entra, client-AD} x {target-Entra, target-AD}) have different authentication paths. Hybrid join bridges the two architectures for devices that support it. A conjecture worth stating plainly: the two architectures will not fully converge before 2030. The intermediate state -- four authentication modes running on the same estate at the same time -- is the steady state, not a transition.

Open Problem 5: Windows 11 24H2 KIR as a deployment-fault recovery surface

In early 2025, Windows 11 24H2 shipped an authentication-stack change that broke CredSSP-mediated RDP in a subset of configurations, manifesting as session hangs at the login screen or 65-second disconnects mid-session. Microsoft rolled out a Known Issue Rollback ("KIR") via Group Policy in March 2025; the policy name is widely attributed in industry press as "Windows 11 24H2 and Windows Server 2025 KB5053598 250314_20401 Known Issue Rollback." The Windows 11 24H2 release-health page now reads "There are no active known issues at this time" as of March 27, 2025 [@msl-24h2-status], indicating the KIR cycle has resolved.

Note: Known Issue Rollback is now a primary operational tool for managing authentication-stack regressions in Windows. When a feature update breaks CredSSP, RDP, or any other load-bearing authentication primitive, the response is no longer "wait for the next monthly patch"; it is "push the KIR-disable Group Policy through your management plane." Operators should be familiar with the KIR mechanism before the next regression cycle. The 2025 24H2 RDP regression [@msl-24h2-status] is the worked example.

Open Problem 6: QUIC transport and the network-layer detection surface

AVD RDP Shortpath for public networks has been GA since late 2022 [@tc-shortpath-blog, @msl-shortpath]; the TURN-relayed variant is GA from late 2024. QUIC is specified in RFC 9000 [@rfc-9000] and replaces TCP/3389 + TLS with UDP/<ephemeral> + QUIC. The IOC surface for "RDP session in progress" changes from a TLS handshake plus CredSSP TS Request/Response on TCP/3389 to a QUIC handshake plus STUN/ICE candidate exchange on a UDP port assigned at runtime.

Network-detection engineering for this surface has not finished re-tuning. A reasonable conjecture: the QUIC detection surface stabilises by 2027 around per-tenant Conditional Access app-ID telemetry (sign-in log entries for a4a365df-50f1-4397-bc59-1a1564b8bb9c [@msl-prtrdp-mstsc]) rather than network-layer packet signatures.

These open problems share a common shape. They are all about composition. The five modes have to interoperate; the credential-isolation has to extend to the session host; the detection has to span TCP and QUIC. None of them has a feature-shaped answer. The next section walks the practical guide for making the existing primitives work in your environment today.

12. Practical Guide, FAQ, and Closing

Here is what to do with this stack this week, depending on which side of the wire you live on.

For the administrator / platform engineer

The four configurations below are the universal baseline. Set them everywhere; then choose a higher-level mode per RDP pair.

Enforce NLA. GPO: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security -> Require user authentication for remote connections by using Network Level Authentication. Verify with PowerShell: (Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\CIMV2\TerminalServices -Filter "TerminalName='RDP-Tcp'").UserAuthenticationRequired returns 1.
Enforce AllowEncryptionOracle = 0. Set "Encryption Oracle Remediation" to "Force Updated Clients" under Computer Configuration -> Administrative Templates -> System -> Credentials Delegation. Verify with Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters' -- the AllowEncryptionOracle value should be 0 [@msl-kb4093492].
Deploy Restricted Admin or Remote CG. Set the RestrictedRemoteAdministration GPO mode under "Restrict delegation of credentials to remote servers" to 1 (Require Restricted Admin), 2 (Require Remote Credential Guard), or 3 (Restrict credential delegation -- the composite that prefers Remote CG and falls back to Restricted Admin when Remote CG cannot complete). Pair with the target-side "Remote host allows delegation of nonexportable credentials" GPO [@msl-rcg].
Enable PRT-over-RDP for Entra-joined estates. Distribute .rdp files with enablerdsaadauth:i:1 [@msl-rdp-files]; gate sign-in via Conditional Access policy on the application a4a365df-50f1-4397-bc59-1a1564b8bb9c [@msl-prtrdp-mstsc]; pair with Windows Hello for Business or FIDO2 for phishing-resistant primary authentication.

Before enabling Remote CG on any target, inventory the NTLM-only paths into it. Workgroup machines, machines whose target SPN registration is incomplete, machines reachable only across DC-isolating firewall rules -- all of them will refuse the Remote CG negotiation when Kerberos cannot complete.

The exact GPO and registry settings for the four-baseline configuration:

NLA: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security -> Require user authentication for remote connections by using Network Level Authentication. Registry: HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\UserAuthentication = 1.
AllowEncryptionOracle: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Encryption Oracle Remediation -> Force Updated Clients. Registry: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\AllowEncryptionOracle = 0.
Restricted Admin / Remote CG: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Restrict delegation of credentials to remote servers. Registry: HKLM\Software\Policies\Microsoft\Windows\CredentialsDelegation\RestrictedRemoteAdministration = 1|2|3 (1 = Require Restricted Admin; 2 = Require Remote Credential Guard; 3 = Restrict credential delegation -- the composite that prefers Remote CG and falls back to Restricted Admin when Remote CG cannot complete) [@msl-rcg].
Target-side trust: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Remote host allows delegation of nonexportable credentials -> Enabled.

Apply via Group Policy, Intune ADMX, or local policy. Reboot is not required for these settings to take effect, but new RDP connections must be opened after the policy applies for the negotiation to reflect the new state.

For the security researcher

The wire-level distinction between modes is observable. Capture an RDP handshake with Wireshark (the RDP dissector is built-in). The RDP_NEG_REQ and RDP_NEG_RSP packets show the requestedProtocols and selectedProtocol fields and the Restricted Admin / Remote CG flag bits. PROTOCOL_HYBRID = 0x02 plus RESTRICTED_ADMIN_MODE_SUPPORTED = 0x08 in the response indicates the negotiated CredSSP sub-mode.

{// MS-RDPBCGR selectedProtocol bitmask: see learn.microsoft.com/.../b2975bdc function decodeNegRsp(selectedProtocol, flags) { const protocols = []; if ((selectedProtocol & 0x01) !== 0) protocols.push("PROTOCOL_SSL (TLS)"); if ((selectedProtocol & 0x02) !== 0) protocols.push("PROTOCOL_HYBRID (CredSSP)"); if ((selectedProtocol & 0x04) !== 0) protocols.push("PROTOCOL_RDSTLS"); if ((selectedProtocol & 0x08) !== 0) protocols.push("PROTOCOL_HYBRID_EX"); if ((selectedProtocol & 0x10) !== 0) protocols.push("PROTOCOL_RDSAAD (Entra)"); if (protocols.length === 0) protocols.push("PROTOCOL_RDP (classic)"); const subModes = []; if ((flags & 0x08) !== 0) subModes.push("Restricted Admin supported"); if ((flags & 0x10) !== 0) subModes.push("Remote Credential Guard supported"); console.log("Protocols:", protocols.join(" + ")); console.log("Sub-modes:", subModes.length ? subModes.join(", ") : "none"); } // Example: PROTOCOL_HYBRID + Remote CG flag decodeNegRsp(0x02, 0x10); // Example: PROTOCOL_RDSAAD (PRT-over-RDP) decodeNegRsp(0x10, 0x00);}

On the target, the distinction between Restricted Admin and the other modes shows up in the Windows event log. Event 4624 (logon-type 10, RemoteInteractive) records the subject; for Restricted Admin the subject is TARGET$ (the machine account) while for classic, Remote CG, and PRT-over-RDP it is the user's account. A quick check: open an elevated cmd inside the RDP session and run whoami. Returns <target>$ under Restricted Admin; returns the user's domain or Entra account otherwise.

Mirrors four PowerShell checks an operator runs on a Windows target.

checks = { "NLA required": "(Get-WmiObject Win32_TSGeneralSetting -Namespace root/CIMV2/TerminalServices -Filter \"TerminalName='RDP-Tcp'\").UserAuthenticationRequired", "AllowEncryptionOracle == 0": "(Get-ItemProperty 'HKLM:/Software/Microsoft/Windows/CurrentVersion/Policies/System/CredSSP/Parameters').AllowEncryptionOracle", "Restricted Admin GPO": "(Get-ItemProperty 'HKLM:/Software/Policies/Microsoft/Windows/CredentialsDelegation').RestrictedRemoteAdministration", "PRT-over-RDP opt-in": "Select-String -Pattern 'enablerdsaadauth:i:1' (Get-ChildItem -Recurse -Filter *.rdp)", } expected = {"NLA required": 1, "AllowEncryptionOracle == 0": 0, "Restricted Admin GPO": "1, 2, or 3", "PRT-over-RDP opt-in": "present in .rdp file"} for label, cmd in checks.items(): print(f"{label}: expect {expected[label]}; run -> {cmd}") `}

For PRT-over-RDP detection, the highest-fidelity signal lives in Microsoft Entra ID's sign-in logs: a successful sign-in entry against the application ID a4a365df-50f1-4397-bc59-1a1564b8bb9c [@msl-prtrdp-mstsc] indicates an RDP session was authenticated using the Entra path. Correlate with the target's local event log for the same user / timestamp to verify session establishment.

For the red-team operator

The post-exploitation pivots differ by mode, as the four sekurlsa::logonpasswords dumps in §1 illustrated:

Classic / NLA: Pass-the-Hash against the target's lsass.exe cache is trivial. sekurlsa::logonpasswords returns user's NT-OWF.
Restricted Admin: PtH yields the target's machine account (TARGET$), not the user. Pivot: RBCD against TERMSRV via the Wagging-the-Dog chain [@shamir-wagging] or KrbRelayUp [@krbrelayup].
Remote Credential Guard: PtH yields nothing useful for the user; the credential never reached the target. Pivot: in-session impersonation via SYSTEM-on-target while the user is connected; use OpenProcessToken against a user-session process.
PRT-over-RDP: No NTLM hash, no Kerberos ticket. Pivot: PRT extraction (sekurlsa::cloudap) from the target's CloudAP cache; the Dirk-jan Mollema PRT-cookie-mint flow [@mollema-prt2] applies.

For the detection engineer

Five signal sources, ranked by fidelity:

The selectedProtocol and flags fields in the RDP_NEG_RSP packet identify the negotiated mode at the wire.
Event 4624 (logon-type 10) on the target identifies the session principal: machine-account name under Restricted Admin, user name otherwise.
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational Event ID 1149 records successful RDP session connections.
RDS Gateway connection logs, if a Gateway is in the path.
Microsoft Entra ID sign-in logs for the application ID a4a365df-50f1-4397-bc59-1a1564b8bb9c [@msl-prtrdp-mstsc] for PRT-over-RDP sessions.

For BlueKeep-class detection on patched estates: the MS_T120 channel name appearing in an RDP Erect Domain Request or Attach User Request is a high-fidelity IOC. Legitimate clients do not request that channel by name [@wiki-bluekeep].

No. NLA is the *policy* on the RDP server that requires authentication before the RDP session is established (before the basic-settings exchange and virtual-channel binding). NLA is *implemented by* CredSSP -- the Credential Security Support Provider, specified in MS-CSSP [@mscssp-index] -- running over TLS. When operators say "we require NLA," they mean "we accept only `requestedProtocols = PROTOCOL_HYBRID` or `PROTOCOL_HYBRID_EX`," both of which select CredSSP under the hood [@rdpbcgr-credssp]. No. NLA prevents pre-authentication remote code execution in the RDP channel-setup code (mitigating BlueKeep [@wiki-bluekeep]) and reduces denial-of-service exposure. NLA does not change what the target's `lsass.exe` ends up holding at the end of the CredSSP exchange. A CredSSP `TSPasswordCreds` exchange ends with the user's password or NT-OWF cached on the target. Mimikatz `sekurlsa::logonpasswords` works against a 2012-era NLA-authenticated target identically to a 1998-era classic-RDP target. No. Restricted Admin makes the target act as *itself*: the user's session runs as the target's machine account, the target sees no user credentials, but the connecting user must already be a local Administrator on the target [@msl-rcg]. Remote Credential Guard makes the target forward operations *back to the caller*: the session runs as the user, SSO works, the connecting user only needs Remote Desktop Users group membership on the target, but the path is Kerberos-only [@msl-rcg]. Restricted Admin gave up SSO to gain universality. Remote CG kept SSO at the cost of NTLM compatibility. Partly. Remote Credential Guard always redirects Kerberos challenges to the caller's `lsass.exe`. The long-lived signing material lives in the caller's VTL1 `LsaIso.exe` trustlet *only if* the caller has local Credential Guard enabled. Without local Credential Guard, the material is in regular user-mode `lsass.exe` on the caller. The protocol works in both cases; the protection from a post-compromise of the caller is stronger with local Credential Guard on. No. BlueKeep (CVE-2019-0708) is a use-after-free in the `MS_T120` virtual-channel binding inside `termdd.sys`, reachable in the RDP channel-setup phase *before* NLA gating completes [@wiki-bluekeep, @nvd-2019-0708]. NLA shipped natively in every BlueKeep-affected operating system from Windows Vista onward (Windows 7, Server 2008, Server 2008 R2); Windows XP and Server 2003 did not ship NLA natively but could be retrofitted via KB951608 (March 2009). The mitigation guidance "enable NLA" worked because NLA *gates* that pre-auth code path behind a successful CredSSP handshake. BlueKeep is "a vulnerability in the channel-setup code reachable when NLA is not enforced," not "a vulnerability in an era predating NLA." No. Microsoft Entra single sign-on for Remote Desktop shipped in the October 11, 2022 cumulative updates: KB5018418 for Windows 11, KB5018410 for Windows 10 20H2 and later, and KB5018421 for Windows Server 2022 [@msl-prtrdp-mstsc, @msl-kb5018418]. The 2025 angles are the Windows 11 24H2 broad GA wave (October 2024) and the March 2025 Known Issue Rollback for a 24H2 RDP regression [@msl-24h2-status]. The Entra-PRT-backed RDP authentication mode itself has been generally available since late 2022. Only for Azure Virtual Desktop and Windows 365. On-premises RDP defaults to TCP/3389 with TLS. RDP-over-QUIC is implemented in AVD's RDP Shortpath feature, with four variants documented in Microsoft Learn covering managed networks, ICE/STUN traversal, public networks via ICE/STUN, and TURN-relayed paths [@msl-shortpath]. Public-networks GA was announced in late 2022 [@tc-shortpath-blog]; the TURN-relayed variant is GA in late 2024. The QUIC transport itself is RFC 9000 [@rfc-9000]. The authentication stack above the transport is unchanged from TCP-based RDP.

Key idea: The five modes coexist because each makes a different Pareto trade-off, and no estate has the luxury of running just one. The matrix is the artifact you live with.

From password-in-the-pipe to cloud-issued session, every generation of RDP authentication has closed exactly the failure mode that motivated the next. Classic delegation made the credential-aggregation problem visible; NLA gated the pre-auth channel and inadvertently introduced its own CVE class. Restricted Admin gave up the user's identity to stop delivering credentials; Remote Credential Guard recovered the identity at the cost of Kerberos-only routing; PRT-over-RDP abandoned both Kerberos and NTLM in favour of Entra-issued cookies bound to per-application Conditional Access policies.

The residual classes -- RBCD against TERMSRV, PRT extraction at the session host, the in-session SYSTEM-on-target floor -- are what is left, and at least one of them is architectural rather than fixable.

The four sekurlsa::logonpasswords dumps in §1 are no longer four mysteries. They are four readings of a single matrix: which requestedProtocols byte the client offered, which flags bits the server accepted, and which credential payload (or which absence of a credential payload) the target received before it built the user's session. The protocol selectors are public. The trade-offs are public. The matrix is yours to compose, RDP pair by RDP pair, with full knowledge of what each choice puts on the wire and what it leaves in lsass.exe.

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.

Kerberos in Windows: The Other Half of NTLMless

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

**Kerberos was a 1988 protocol that solved one problem: mutual authentication on an untrusted network using a trusted third party.** Then it got piled on for thirty-three years. In 2026 NTLM is being switched off, the AS-REQ / AS-REP / TGS-REQ / TGS-REP skeleton is finally the single load-bearing authentication path for Windows, and the eleven attack primitives that exposed every joint of that skeleton between 2014 and 2022 are still mostly fixable by configuration, not by protocol. This is the companion to [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/): what happens to the protocol that takes over.

1. A Chain Without NTLM

Imagine a defender who has done every NTLM retrofit Microsoft has shipped. NTLM is disabled by default on the workstations. RestrictNTLMInDomain is on at the domain controller. SMB signing is enforced. Extended Protection for Authentication is set on every IIS endpoint. ESC8 has been patched. The defender has read the NTLMless post and ticked every box.

A low-privileged user on that network opens a PowerShell prompt. They run Powermad to create a fresh computer account. The default MachineAccountQuota is still 10, which means any authenticated domain user can create up to ten computer objects in Active Directory by design [@shenanigans-rbcd]. They then write a single LDAP attribute, msDS-AllowedToActOnBehalfOfOtherIdentity, on a target file server they have any write permission against. They ask the Key Distribution Center for a service ticket via Rubeus s4u, present that ticket to the target file server, and walk in as Administrator. Total elapsed time: less than this paragraph. Total NTLM in the chain: zero.

Note: The post-NTLM Resource-Based Constrained Delegation chain depends on three properties of Kerberos that are features, not bugs: (a) the default MachineAccountQuota = 10 setting on every fresh Active Directory forest, (b) the S4U2Proxy guarantee that always produces a forwardable TGS even when the input ticket was not forwardable, and (c) the absence of any KDC-side check on whether the requesting principal is a "trusted delegator". All three are documented behaviours of the protocol. None of them is a CVE [@shenanigans-rbcd].

The chain has a name and a primary disclosure: Elad Shamir's "Wagging the Dog" post on shenaniganslabs.io, January 28, 2019 [@shenanigans-rbcd]. The weaponised tooling is GhostPack's Rubeus, the C# Kerberos toolset that ships ready-made commands for s4u, asktgt, kerberoast, and diamond [@ghostpack-rubeus]. The single-line elevation wrapper that splices together Powermad, KrbRelay, Rubeus, and an SCM bypass is KrbRelayUp, published by Mor Davidovich ("Dec0ne") on April 24, 2022; its README scopes itself as a universal no-fix local privilege escalation in Windows domain environments where LDAP signing is not enforced (and that is the default) [@krbrelayup].

sequenceDiagram participant U as Low-priv user participant DC as Domain Controller / KDC participant T as Target file server U->>DC: Powermad: create machine account FAKE (machine account) U->>DC: LDAP write set RBCD attribute on T to allow FAKE U->>DC: AS-REQ for FAKE -> TGT U->>DC: S4U2Self as Administrator (non-forwardable TGS returned) U->>DC: S4U2Proxy with TGS returns forwardable TGS for cifs on T U->>T: AP-REQ presenting Administrator TGS T->>U: SYSTEM access on T

Read the chain twice. The first read shows that every step is a documented Kerberos exchange. The second read shows that removing NTLM did nothing to it. Restrict-NTLM, EPA, SMB signing, ESC8 -- the entire NTLM-retrofit catalogue has no edge against a Kerberos-only attack path that uses S4U2Self, S4U2Proxy, and the Resource-Based Constrained Delegation attribute exactly as Microsoft documented them in [@ms-kerberos-overview].

This is the article's load-bearing thesis. Removing NTLM did not remove the attack surface; it shifted the attack surface onto a protocol that is also thirty-three years old, also retrofitted, and now also the only load-bearing one. In October 2023, Matthew Palko, Microsoft's Principal Group Product Manager for Windows authentication, wrote the post that committed Microsoft publicly to deprecating NTLM and named the Kerberos features that would replace it [@ms-palko-evolution]. The NTLMless companion article walked through the NTLM-side mechanics of that transition. This one walks through the Kerberos side.

The question that drives everything that follows is the question the chain above forces: how did Windows arrive at a state where the most catastrophic post-NTLM Active Directory attack chain depends on Kerberos working exactly as the 1989 designers intended?

2. Origins: Needham, Schroeder, Athena, and 1988

Kerberos is not new engineering. The story of Windows authentication in 2026 starts with two Xerox PARC researchers and a 1978 paper in Communications of the ACM.

In December 1978, Roger M. Needham and Michael D. Schroeder published "Using Encryption for Authentication in Large Networks of Computers" in CACM 21(12), pages 993 to 999 [@needham-schroeder]. The paper is paywalled on the ACM Digital Library, but RFC 4120's own Background section names it as the parent protocol [@rfc4120] and the Wikipedia article on the Needham-Schroeder protocol preserves the message structure verbatim [@wiki-needham-schroeder]. The symmetric-key version of that protocol is five messages long, and it is the structural blueprint of every "ticket from a trusted third party" design that followed.

$$A \to S:\ A, B, N_A$$ $$S \to A:\ {N_A, K_{AB}, B, {K_{AB}, A}{K{BS}}}{K{AS}}$$ $$A \to B:\ {K_{AB}, A}{K{BS}}$$ $$B \to A:\ {N_B}{K{AB}}$$ $$A \to B:\ {N_B - 1}{K{AB}}$$

A and B are the principals; S is the trusted third party; K_AS and K_BS are pre-shared long-term keys; K_AB is the session key that S mints for the conversation; N_A and N_B are nonces. The "ticket" is the part of the third message that A cannot decrypt and just forwards to B. That structure -- a server-issued cryptographic envelope intended for somebody else and opaque to the carrier -- is what becomes the Kerberos TGS thirty-eight years later.

Three years later, in August 1981, Dorothy Denning and Giovanni Maria Sacco published "Timestamps in Key Distribution Protocols" in CACM 24(8), 533-536. The paper is also paywalled on dl.acm.org, but the Wikipedia secondary preserves the finding: the Needham-Schroeder symmetric protocol is vulnerable to a replay attack if an attacker recovers an old session key [@wiki-needham-schroeder]. Denning and Sacco proposed timestamps as the fix. This is the structural reason every Kerberos ticket carries a timestamp and every Kerberos network requires a synchronised time service today.

A Kerberos administrative boundary, written in uppercase like `CONTOSO.COM`, that scopes a set of principals (users, services, computers) sharing a single Key Distribution Center. Every Kerberos ticket names the issuing domain in its `EncTicketPart.crealm` and `EncTicketPart.cname` fields. Active Directory binds one Kerberos domain to one AD forest root by default [@ms-kerberos-overview].

Between 1983 and 1991, MIT Project Athena -- the joint MIT, DEC, and IBM campus computing effort led by Jerome Saltzer -- needed a working authentication service for a distributed workstation network running over a hostile campus LAN. The Athena Technical Plan Section E.2.1, "Kerberos Authentication and Authorization System" [@mit-athena-plan], is the canonical internal design document. Steve Miller and Clifford Neuman did the protocol work; Jeffrey Schiller ran the network operations.

In February 1988, MIT published two complementary artefacts. Bill Bryant wrote "Designing an Authentication System: a Dialogue in Four Scenes" -- a pedagogical script in which an engineer named Athena designs her way step by step from "users type their password to every server" to "users obtain time-limited tickets from a trusted third party". Bryant's dialogue is the most cited pre-protocol document about why Kerberos exists in the shape it does [@mit-dialogue]. The same month, Jennifer Steiner, Clifford Neuman, and Jeffrey Schiller presented "Kerberos: An Authentication Service for Open Network Systems" at the USENIX Winter Conference in Dallas [@cerias-steiner1988]. The protocol that paper described -- later called Kerberos version 4 -- carried forward to v5 with ASN.1 encoding, extensibility hooks, and pre-authentication, but the AS / TGS / AP message-triple skeleton it specified is unchanged thirty-eight years later.

On January 24, 1989, MIT shipped the first public release of Kerberos v4 [@wiki-kerberos]. Five years later, in September 1993, the IETF adopted Kerberos v5 as RFC 1510 [@rfc1510]. RFC 1510 added ASN.1 encoding, cross-domain trust, and an extensibility hook called PA-DATA that every Kerberos extension since has used. In July 2005, RFC 4120 replaced RFC 1510 as the Kerberos v5 standard [@rfc4120].

sequenceDiagram participant C as Client participant AS as Authentication Service participant TGS as Ticket-Granting Service participant S as Application Server C->>AS: AS-REQ: identify yourself AS->>C: AS-REP TGT encrypted to TGS, session key wrapped under client long-term key C->>TGS: TGS-REQ: present TGT, ask for service ticket TGS->>C: TGS-REP service ticket encrypted to S, session key wrapped under TGT session key C->>S: AP-REQ: present service ticket S->>C: AP-REP: mutual auth confirmation

Kerberos in 2026 is the same protocol as Kerberos in 1988, with thirty-three years of extensions piled on top. The skeleton you draw on a whiteboard for a graduate seminar is exactly the skeleton a Windows 11 24H2 machine throws at a 2025 domain controller. The interesting question is what those thirty-three years of extensions did to the inside of every message.The default maximum clock skew between client and KDC in Windows Kerberos is five minutes (300 seconds), set by Group Policy "Maximum tolerance for computer clock synchronization" and documented in [@ms-kerberos-overview]. The five-minute window is the residue of Denning and Sacco's 1981 timestamp fix.

3. The Wire in 2026: Six Messages and an Encryption Matrix

Every Kerberos textbook draws the same six-message diagram you saw in Section 2. The diagram has been unchanged since 1988. What is different in 2026 is everything inside the messages.

Look first at the AS-REQ. In raw RFC 4120 the AS-REQ carries a req-body (client name, target name, requested lifetime, requested enctypes) and an optional padata field [@rfc4120]. That padata slot is the load-bearing extensibility hook of the entire protocol. Every Kerberos enhancement since 1993 has been a new PA-DATA type: PA-ENC-TIMESTAMP (the encrypted-timestamp pre-auth blob), PA-PK-AS-REQ (PKINIT [@rfc4556]), PA-FX-FAST-REQUEST (FAST armoring [@rfc6113]), PA-AS-FRESHNESS (PKINIT freshness [@rfc8070]). The skeleton survives only because the joints are extensible.

A `SEQUENCE OF { padata-type, padata-value }` field in the Kerberos AS-REQ and AS-REP messages, introduced in RFC 1510 (1993) and carried forward unchanged into RFC 4120 §5.2.7 (2005). PA-DATA is the only protocol-level hook by which a Kerberos client can prove possession of a credential before the KDC issues a Ticket-Granting Ticket, and the only hook by which an enhancement like FAST or PKINIT can attach new behaviour to the AS exchange without breaking compatibility with older clients [@rfc4120].

The AS-REP returns the TGT. The TGT itself is encrypted under the TGS's long-term key, so the client cannot inspect it. What the client can inspect is the EncTicketPart flag bitfield wrapped in the TGT envelope. RFC 4120 §2 enumerates the ticket-flag positions, including forwardable, proxiable, postdated, renewable, initial, pre-authent, hw-authent, transited-policy-checked, and ok-as-delegate [@rfc4120]. (may-postdate looks like a sibling but is a KDCOptions request bit per RFC 4120 §5.4.1, not a TicketFlags bit.) Pay attention to forwardable. In 2020, Jake Karnes of NetSPI demonstrated that an attacker who knew a service account's long-term key could decrypt the S4U2Self output ticket, set forwardable = 1, re-encrypt, and feed the ticket back to the KDC's S4U2Proxy step. The KDC accepted it. The bypass is CVE-2020-17049 and the attack is called Bronze Bit [@cve-2020-17049] [@netspi-bronze-bit].

Inside the ticket's AuthorizationData field is the Microsoft-specific construction that turns Kerberos into a Windows authorisation system. The Privilege Attribute Certificate, defined in [MS-PAC] revision 26.0 [@ms-pac-overview] [@ms-pac-deeplink], carries the user's SID, their group SIDs, their logon name, timestamps, and three cryptographic signatures: a Server signature, a KDC signature, and -- since CVE-2022-37967 in November 2022 -- a Full PAC Signature that covers the entire encoded PAC structure instead of just the existing signatures [@cve-2022-37967].

A Microsoft-specific authorization data element that the Kerberos KDC attaches to every ticket it issues for a Windows principal. The PAC carries the user's SID, group SIDs, logon name, and timestamps, and is signed by the KDC's `krbtgt` key and by the target service's key. The PAC, not the Kerberos ticket itself, is what gives a Windows file server the access-control information it needs to make a permission decision. Defined in [MS-PAC] [@ms-pac-overview]. The KB article URL ends in `cve-2022-37967` and the body text begins by referring to "CVE-2022-37966". This is not a typo in the citation -- it is a Microsoft filing artefact. November 2022 Patch Tuesday paired two Kerberos CVEs: CVE-2022-37967 (Full PAC Signature, KrbtgtFullPacSignature) and CVE-2022-37966 (default session-key encryption type). KB5021131 covers the deployment of the encryption-type bypass side. A sibling article, KB5020805, covers the Full PAC Signature side. When citing KB5021131 alongside the Full PAC Signature, both CVE numbers are relevant [@ms-kb-5021131] [@cve-2022-37967].

Then there is the encryption matrix. Kerberos abstracts ciphers behind the RFC 3961 framework [@rfc3961], which defines an enctype as a tuple of (encrypt, decrypt, checksum, string-to-key, key-derivation) functions. The history of Windows Kerberos is the history of which enctypes were the default at any given time.

Enctype	Number	Spec	Status in 2026
DES-CBC-CRC	1	RFC 3961 [@rfc3961]	Disabled by default since Server 2008 R2 [@ms-kile-227]
DES-CBC-MD5	3	RFC 3961 [@rfc3961]	Disabled by default since Server 2008 R2 [@ms-kile-227]
RC4-HMAC	23	RFC 4757 [@rfc4757]	Informational, not Standards Track; default-removed in mid-2026 per [@ms-beyond-rc4]
AES-128-CTS-HMAC-SHA1-96	17	RFC 3962 [@rfc3962]	Default since Server 2008; cross-version compatible
AES-256-CTS-HMAC-SHA1-96	18	RFC 3962 [@rfc3962]	Default since Server 2008; the mid-2026 destination
AES-128-CTS-HMAC-SHA256-128	19	RFC 8009 [@rfc8009]	Specified in [MS-KILE] bit K [@ms-kile-227]; no default-enable timeline
AES-256-CTS-HMAC-SHA384-192	20	RFC 8009 [@rfc8009]	Specified in [MS-KILE] bit L [@ms-kile-227]; no default-enable timeline

Enctype 23 is the row that built every Kerberoasting career. Kannan Jaganathan, Larry Zhu, and John Brezak of Microsoft published RFC 4757 in December 2006 [@rfc4757]. The IESG note on the RFC is unusually candid: the document is Informational, not Standards Track, because RC4-HMAC "do[es] not provide all the required operations in the Kerberos cryptography framework [RFC 3961]" and because of "security concerns with the use of RC4 and MD4". The choice that made enctype 23 dangerous, however, was upstream of the RFC. To make Windows 2000's Kerberos rollout backward-compatible with the existing SAM password database, Microsoft set the RC4-HMAC long-term Kerberos key equal to the NT hash of the user's password -- the same hash NTLM was already storing. As Microsoft's own October 2024 Kerberoasting guidance puts it verbatim: "RC4 is more susceptible to the cyberattack because it uses no salt or iterated hash when converting a password to an encryption key" [@ms-kerberoasting-guidance].

The function that converts a typed password into a Kerberos long-term symmetric key. For RC4-HMAC (enctype 23), `s2k(password) = MD4(UTF-16-LE(password))` -- the NT hash, no salt, no iteration. For AES-CTS-HMAC-SHA1-96 (enctypes 17 and 18), `s2k(password, salt) = PBKDF2-HMAC-SHA1(password, salt, 4096, dklen)` followed by RFC 3962 post-processing into a 128- or 256-bit AES key. The salt is the concatenation of the Kerberos domain name and the user principal name [@rfc3962].

The cryptography in that definition is short enough to read end-to-end. Here it is in JavaScript using the Web Crypto API:

{` async function kerberosStringToKey256(password, salt) { const enc = new TextEncoder(); const passKey = await crypto.subtle.importKey( "raw", enc.encode(password), { name: "PBKDF2" }, false, ["deriveBits"] ); const rawBits = await crypto.subtle.deriveBits( { name: "PBKDF2", salt: enc.encode(salt), iterations: 4096, hash: "SHA-1", }, passKey, 256 ); const hex = [...new Uint8Array(rawBits)] .map((b) => b.toString(16).padStart(2, "0")) .join(""); return hex; }

const password = "Summer2026!"; const salt = "CONTOSO.COMalice"; const keyHex = await kerberosStringToKey256(password, salt); console.log("PBKDF2-HMAC-SHA1 output (truncated AES-256 key):", keyHex); `}

That 32-byte output is the value LSA stores when an account is configured with msDS-SupportedEncryptionTypes bit E set. When a Kerberoasting attacker steals the TGS-REP, what they crack offline is which password produces that key. The RFC 3962 post-processing -- a single round of DK(key, "kerberos") -- shapes the output to AES key length but does not slow the dictionary attack down. The dispositive defence is not in the cryptography; it is in the password (or, more precisely, in not having one at all -- the move to gMSA and dMSA replaces typed passwords with KDC-generated random secrets [@ms-gmsa] [@ms-dmsa]). PBKDF2 at 4,096 iterations is well below modern PHC recommendations -- the 2023 OWASP guideline for PBKDF2-HMAC-SHA1 is 1.3 million iterations [@owasp-password-storage] -- but the 4,096 figure is wired into RFC 3962 and is the same on every supported Windows version. Service accounts using gMSA bypass this entirely: the gMSA's "password" is a 240-character random secret rotated every 30 days, derived by the Microsoft Key Distribution Service rather than entered by a human [@ms-gmsa].

The wire in 2026 is therefore six messages and a matrix of seven enctypes. The protocol skeleton is forty years old. In 2014 a SANS instructor named Tim Medin gave a forty-five-minute talk that turned every one of those enctypes into a problem.

4. The Attack Cascade: 2014 to 2022

September 26-28, 2014. Louisville, Kentucky. DerbyCon 4. Talk slot T120. Tim Medin -- then at Counter Hack Challenges, also a SANS instructor -- walks on stage with a forty-five-minute talk titled "Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades" [@irongeek-derbycon4]. The talk demonstrates that any authenticated domain user can request a TGS for any Service Principal Name in the directory, and that the service-portion of the returned ticket is encrypted under the SPN account's long-term key -- which, under RC4-HMAC enctype 23, is the NT hash of the password. Cracking the ciphertext is reduced to a dictionary attack against whatever password an admin set on the service account.

That talk is the moment Kerberos becomes interesting to attackers. The next eight years play out as a cascade. Five generations, each one named after the canonical primitive that defined it, each one exposing a different structural property of the protocol, each one earning its own engineered Microsoft response years later.

A unique identifier for a service instance in Active Directory, written in the form `service-class/host:port/service-name` (for example `HTTP/web01.contoso.com`). Kerberos uses the SPN to look up which account holds the long-term key that decrypts the service ticket. Any account that has an SPN -- a user account that has had `setspn -A` run against it, every machine account in the directory, every gMSA -- is a candidate for Kerberoasting [@adsecurity-kerberoast].

Generation 1, 2014: Kerberoasting

Tim Medin's primitive [@irongeek-derbycon4]. Will Schroeder's PowerShell weaponisation as Invoke-Kerberoast (later rolled into the C# Rubeus) [@ghostpack-rubeus]. Sean Metcalf's operational walkthrough on adsecurity.org [@adsecurity-kerberoast]. MITRE catalogued the technique in 2020 as ATT&CK T1558.003, which preserves the structural definition verbatim: "Portions of these tickets may be encrypted with the RC4 algorithm, meaning the Kerberos 5 TGS-REP etype 23 hash of the service account associated with the SPN is used as the private key and is thus vulnerable to offline Brute Force attacks" [@mitre-t1558-003].

The structural insight is the part that matters. The TGS-REP is encrypted with the service account's long-term password-derived key, so any domain user who can issue a TGS-REQ can mine ciphertext offline against any dictionary they care to assemble. The Kerberos protocol has no mechanism by which the KDC could tell whether the requesting user has any business asking for that SPN, because RFC 4120 has no concept of "this service is for these users". Anyone with a TGT gets the service ticket.

Microsoft's engineered response did not arrive until ten to twelve years later. Server 2012 introduced Group Managed Service Accounts: passwords randomised to 240 characters, derived by the Microsoft Key Distribution Service via kdssvc.dll, rotated every 30 days, retrievable from a domain controller by member hosts that are explicitly authorised in msDS-GroupMSAMembership [@ms-gmsa]. Server 2025 then introduced Delegated Managed Service Accounts (dMSA), which take the next structural step: the dMSA's secret is "derived from the machine account credential" held by the domain controller, and "the secret can't be retrieved or found anywhere other than on the DC" [@ms-dmsa]. The October 2024 Microsoft Security Blog formalised the Kerberoasting guidance in a single page that names RC4 as the load-bearing weakness and announces the deprecation [@ms-kerberoasting-guidance]. The December 2025 Beyond-RC4 announcement closed the cadence with a calendar date [@ms-beyond-rc4].

Generation 2, 2014-2017: Mimikatz Kerberos and AS-REP Roasting

Benjamin Delpy publishes mimikatz 2.0 on April 6, 2014; the v2 banner inside the repository README reads verbatim mimikatz 2.0 alpha (x86) release "Kiwi en C" (Apr 6 2014 22:02:03) [@mimikatz]. The Kerberos module contains two commands that define the era: kerberos::golden (forge a TGT from the KRBTGT account's long-term key, granting Domain Admin equivalence indefinitely) and kerberos::silver (forge a TGS from any service account's long-term key, granting impersonation of any user against that service).

The structural insight: RFC 4120 has no online ticket validation [@rfc4120]. Once a ticket carries the right signatures, the service trusts it. Whoever holds a long-term key forges any ticket that key signs. Possession of a key collapses to ticket forgeability.

Around 2017, the same team behind Rubeus publicises AS-REP Roasting [@ghostpack-rubeus]: the same offline-cracking primitive as Kerberoasting, but against any account whose userAccountControl has UF_DONT_REQUIRE_PREAUTH (the DONT_REQ_PREAUTH flag) set. With pre-authentication disabled, the KDC will return an AS-REP encrypted under the user's password-derived key to anyone who asks for it, no proof of password possession required. The dispositive Microsoft response was already in place: pre-authentication has been required by default for all new Active Directory accounts since Windows 2000, and the flag has to be deliberately cleared by an administrator. The remaining vulnerability is operational hygiene -- finding the handful of legacy accounts an organisation has left with pre-auth disabled.

Generation 3, 2018-2020: Delegation Abuse

Three primitives in three years.

SpoolSample / PrinterBug. Lee Christensen (tifkin_, SpecterOps) published the PoC on GitHub on October 5, 2018 [@spoolsample]. The MS-RPRN remote-procedure-call interface includes a method, RpcRemoteFindFirstPrinterChangeNotificationEx, that any authenticated user can invoke against any host's spooler service to ask the spooler to please call back to an attacker-controlled address. The spooler obediently authenticates outbound using the machine account's credentials. Combined with unconstrained Kerberos delegation on the attacker-controlled host, the inbound authentication captures the target machine's TGT.

Wagging the Dog (RBCD). Elad Shamir's January 28, 2019 post on shenaniganslabs.io [@shenanigans-rbcd]. The TL;DR of the post is the load-bearing structural disclosure: "Resource-based constrained delegation does not require a forwardable TGS when invoking S4U2Proxy. S4U2Self works on any account that has an SPN, regardless of the state of the TrustedToAuthForDelegation attribute. S4U2Proxy always produces a forwardable TGS, even if the provided additional TGS in the request was not forwardable. By default, any domain user can abuse the MachineAccountQuota to create a computer account and set an SPN for it, which makes it even more trivial to abuse resource-based constrained delegation to mimic protocol transition" [@shenanigans-rbcd]. Every clause of that TL;DR points at a documented behaviour. The chain in this article's Hook is built directly on top.

Bronze Bit. Jake Karnes at NetSPI; CVE-2020-17049; disclosed November 10, 2020 [@netspi-bronze-bit] [@cve-2020-17049]. The NVD entry preserves Microsoft's verbatim description: "A security feature bypass vulnerability exists in the way Key Distribution Center (KDC) determines if a service ticket can be used for delegation via Kerberos Constrained Delegation (KCD). To exploit the vulnerability, a compromised service that is configured to use KCD could tamper with a service ticket that is not valid for delegation to force the KDC to accept it" [@cve-2020-17049]. The bypass: any service in possession of its own long-term key can decrypt the S4U2Self output ticket, flip the forwardable bit in EncTicketPart, and re-encrypt with the same key. Pre-2020 the KDC's S4U2Proxy validation accepted the resulting ticket because nothing on the ticket independently attested whether the forwardable flag had been set by the KDC or by the service itself. Microsoft's November 10, 2020 fix, per the NVD entry verbatim, "addresses this vulnerability by changing how the KDC validates service tickets used with KCD" so that the tampered flag is rejected [@cve-2020-17049]. The PAC signatures, contra a common framing, were never meant to cover the EncTicketPart flag bits in the first place.

Microsoft's engineered responses: the November 2020 Bronze Bit patch [@cve-2020-17049] tightened the KDC's S4U2Proxy ticket-validation step; KB5008383 (November 2021) [@ms-kb-5008383] issued the canonical "set ms-DS-MachineAccountQuota = 0 for non-administrator users" guidance; LDAP signing and channel binding work, ongoing since the NTLMless era, became the dispositive control against the relay variant of the chain.

Generation 4, 2021-2022: Certificate-Based Ticket Forgery and Kerberos Relay

Certifried. Oliver Lyak (ly4k) at IFCR disclosed CVE-2022-26923 to Microsoft, who patched on May 10, 2022 [@cve-2022-26923]. The attack exploited a quirk of how Active Directory Certificate Services (ADCS) bound a certificate's identity to an AD account when the certificate was used for PKINIT. Before the strong-mapping fix, AD's account-lookup at PKINIT time used the certificate's Subject Alternative Name (SAN) and matched the User Principal Name. If an attacker controlled a machine account, they could change the machine's dNSHostName to match a domain controller's, request a certificate via the (overly-permissive) default Machine template, and use the resulting certificate to PKINIT-authenticate to the KDC as that domain controller. Microsoft's response is documented end-to-end in KB5014754 [@ms-kb-5014754]: a new "strong certificate mapping" requirement that pins each issued certificate to a specific account SID via an X.509 extension (OID 1.3.6.1.4.1.311.25.2). The original release moved to Compatibility mode on May 10, 2022; full Enforcement mode took effect on February 11, 2025; Disabled-mode rollback was removed on April 11, 2023; the remaining Compatibility-mode fallback was removed on September 9, 2025 [@ms-kb-5014754].

KrbRelayUp. Mor Davidovich (Dec0ne), April 24, 2022 [@krbrelayup]. The README's universal-no-fix-LPE framing is preserved in the PullQuote below. The chain wraps Powermad (machine account creation), KrbRelay (Kerberos relay to LDAP), Rubeus (S4U2Self bypass of Protected Users, RBCD privilege addition), and SCMUACBypass (a wrapper that uses the resulting ticket to open the local Service Control Manager and create a service running as NT AUTHORITY\SYSTEM). The class of attack is "Kerberos relay" -- the post-NTLM cousin of NTLM-relay. The dispositive control is not a Kerberos patch; it is domain-wide LDAP signing plus channel binding plus Extended Protection for Authentication on ADCS Web Enrolment.

A universal no-fix local privilege escalation in windows domain environments where LDAP signing is not enforced (the default settings). -- Mor Davidovich, KrbRelayUp README, April 2022 [@krbrelayup]

Generation 5, 2022-2023: Forged-Ticket Sophistication

Diamond Ticket. Charlie Clark at Semperis co-authored a blog post in 2022 with Andrew Schwartz at TrustedSec disclosing the modern Diamond Ticket technique [@semperis-diamond] [@trustedsec-diamond]. The Semperis byline names the antecedent: a 2015 Black Hat EU presentation by Tal Be'ery and Michael Cherny ("Watching the Watchdog") that introduced the "Diamond PAC" idea. Verbatim from the Semperis post: "Golden Ticket attacks take advantage of the ability to forge a ticket granting ticket (TGT) from scratch, Diamond Ticket attacks take advantage of the ability to decrypt and re-encrypt genuine TGTs requested from a domain controller (DC)" [@semperis-diamond]. The structural insight is that a Diamond Ticket has a legitimately issued, KDC-signed PAC at its base; only the privilege-claim fields inside the PAC are tampered. Before the November 2022 Full PAC Signature fix, the existing Server and KDC signatures only covered specific sub-structures, leaving room to modify the parts they did not sign.

Sapphire Ticket. Charlie Bromberg, also known online as "Shutdown", at Synacktiv [@pgj11-diamond-sapphire] [@thehacker-recipes-sapphire]. The community wiki The Hacker Recipes, which Bromberg maintains, documents the Sapphire Ticket technique end-to-end at thehacker.recipes/a-d/movement/kerberos/forged-tickets/sapphire [@thehacker-recipes-sapphire]. The verifiable third-party attribution lives at pgj11.com, which records verbatim: "One brand new technique is Sapphire Ticket. Created by Charlie Shutdown (twitter.com/_nwodtuhs) this approach is more stealthy. You can create a TGT impersonating any user assembling real TGT and real PAC combining S4U2Self + U2U ... He extended Ticketer from Impacket to add this attack" [@pgj11-diamond-sapphire]. The Sapphire Ticket bolts a legitimately KDC-issued PAC (obtained by chaining the S4U2Self and User-to-User Kerberos extensions to request a service ticket to oneself with the PAC of an arbitrary target user) onto a Diamond-style ticket. The result presents PAC signatures that the KDC itself produced. Unit 42's December 2022 "Next-Gen Kerberos Attacks" writeup is the secondary that joined Diamond and Sapphire into the same article and named them collectively the "Precious Gemstones" [@unit42-precious-gemstones]. Some secondary sources attribute Sapphire Ticket to Charlie Clark of Semperis. The misattribution probably stems from Clark's separate "AS Requested STs" post on the Semperis blog, which discusses a different technique exploiting unarmored machine-account AS-REQs and is not the Sapphire Ticket primary [@semperis-as-sts]. The verified Sapphire-Ticket originator is Charlie Bromberg (Shutdown, Synacktiv) per [@pgj11-diamond-sapphire]. The adsecurity.org URL ?p=2293 is Sean Metcalf's "Cracking Kerberos TGS Tickets Using Kerberoast -- Exploiting Kerberos to Compromise the Active Directory Domain" (not Metcalf's separate KRBTGT-account post, which lives at a different URL). The page is the operational walkthrough that pairs with Tim Medin's 2014 DerbyCon disclosure [@adsecurity-kerberoast].

Microsoft's engineered response to both Diamond and Sapphire was CVE-2022-37967, the KrbtgtFullPacSignature [@cve-2022-37967] [@ms-kb-5021131]. It is the first PAC-handling protocol change since Windows 2000's introduction of the PAC. After full enforcement, the KDC adds a Full PAC Signature that covers the entire encoded PAC, not just the existing sub-signatures. Diamond and Sapphire variants that modify any PAC field beyond what the Server and KDC sub-signatures already covered will fail validation.

The accounts most vulnerable to Kerberoasting are those with weak passwords and those that use weaker encryption algorithms, especially RC4. RC4 is more susceptible to the cyberattack because it uses no salt or iterated hash when converting a password to an encryption key, allowing the cyberthreat actor to guess more passwords quickly. -- Microsoft Security Blog, October 11, 2024 [@ms-kerberoasting-guidance]

The Spine Table

Generation	Year	Primitive	Structural Insight	Microsoft Response
1	2014	Kerberoasting [@irongeek-derbycon4]	TGS-REP is encrypted with the SPN account's long-term key; offline-crackable	gMSA (2012) [@ms-gmsa]; dMSA (2025) [@ms-dmsa]; Beyond-RC4 (2025-2026) [@ms-beyond-rc4]
2	2014-2017	Golden / Silver Ticket [@mimikatz]; AS-REP Roasting [@ghostpack-rubeus]	RFC 4120 has no online ticket validation [@rfc4120]; long-term key = forge equivalence	KrbtgtFullPacSignature (2022) [@cve-2022-37967]; preauth-required default since Windows 2000
3	2018-2020	SpoolSample [@spoolsample]; RBCD [@shenanigans-rbcd]; Bronze Bit [@cve-2020-17049]	MS-RPRN coercion; S4U2Proxy always returns forwardable; pre-2020 KDC did not independently validate the EncTicketPart flags	Bronze Bit patch (Nov 2020); KB5008383 MachineAccountQuota=0 (Nov 2021); LDAP signing
4	2022	Certifried [@cve-2022-26923]; KrbRelayUp [@krbrelayup]	ADCS template SAN-binding ambiguity; LDAP defaults unsigned	KB5014754 strong-mapping [@ms-kb-5014754]; LDAP signing + EPA on /certsrv/
5	2022	Diamond [@semperis-diamond]; Sapphire [@pgj11-diamond-sapphire] [@unit42-precious-gemstones]	PAC sub-signatures did not cover the encoded PAC structure	KrbtgtFullPacSignature (CVE-2022-37967, Nov 2022) [@cve-2022-37967]

timeline title Kerberos attack cascade section 2014 Sep 2014 : Kerberoasting (Tim Medin, DerbyCon 4) Apr 2014 : Mimikatz 2.0 (Golden / Silver Tickets) section 2017 2017 : AS-REP Roasting (Rubeus weaponisation) section 2018-2020 Oct 2018 : SpoolSample (PrinterBug, Lee Christensen) Jan 2019 : Wagging the Dog / RBCD (Elad Shamir) Nov 2020 : Bronze Bit (Jake Karnes, NetSPI) section 2022 Apr 2022 : KrbRelayUp (Mor Davidovich) May 2022 : Certifried (Oliver Lyak / ly4k) 2022 : Diamond Ticket (Clark / Schwartz) 2022 : Sapphire Ticket (Charlie Bromberg) Nov 2022 : KrbtgtFullPacSignature (Microsoft fix)

Eight years. Eleven structural primitives. One protocol. By 2022 the cascade slowed, not because the protocol got better, but because every primitive a thirty-three-year-old design could expose had been exposed. The 2022 Microsoft response, KrbtgtFullPacSignature, was the first one that targeted the structural properties (PAC coverage of its own structure) rather than the per-primitive patches that defined the 2014-2020 era. To see why that was a turning point, it helps to see exactly what the defensive cadence looked like before then.

5. The Defensive Cadence Before 2023

Each of the eleven primitives in Section 4 shipped with a fix. By 2022 every named primitive had a fix. And yet the cascade kept producing new primitives. Why?

The answer is in the shape of the defensive controls. Walk them in chronological order.

Protected Users (Server 2012 R2, October 2013) [@ms-server-2012-r2]. A new security group that triggers five non-configurable client-side protections and four non-configurable domain-controller-side protections [@ms-protected-users]. The client side: CredSSP "doesn't cache the user's plain text credentials"; Windows Digest "doesn't cache the user's plaintext credentials"; "NTLM stops caching the user's plaintext credentials or NT one-way function (NTOWF)"; "Kerberos stops creating Data Encryption Standard (DES) or RC4 keys ... or long-term keys after acquiring the initial Ticket Granting Ticket (TGT)"; "The system doesn't create a cached verifier at user sign-in or unlock" [@ms-protected-users]. The domain-controller side, also verbatim: members "cannot authenticate with NTLM authentication ... use DES or RC4 encryption types in Kerberos preauthentication ... delegate with unconstrained or constrained delegation ... renew Kerberos TGTs beyond their initial four-hour lifetime" [@ms-protected-users]. The limit is the obvious one: Protected Users breaks every workflow that relied on delegation, RC4, or NTLM, and there are many such workflows still in production.

Authentication Policy Silos (Server 2012 R2). A scope construct that lets administrators apply Protected-Users-equivalent constraints (no RC4, no unconstrained delegation, mandatory FAST) to tiered subsets of an organisation rather than per-account. The standard tier-zero / tier-one / tier-two split fits neatly under three silos [@ms-privileged-access].

A container of users, computers, and managed service accounts in Active Directory that scopes a single authentication policy. Members can be required to authenticate only from designated hosts, must use AES enctypes, may be excluded from delegation, and (when paired with FAST armoring) sign their AS-REQ inside a machine-account or anonymous-PKINIT armor. Available since Server 2012 R2; the operational granularity that Protected Users does not provide on its own [@ms-protected-users].

Restricted Admin (2014) and Remote Credential Guard (2016) [@ms-remote-credential-guard]. The RDP-side companions that block credential exposure on the target host. Both work by changing what gets sent on the wire during a remote sign-in: Restricted Admin (Windows 8.1 / Server 2012 R2 era) uses the user's TGT to authenticate via Kerberos network logon, so no credentials reach the target; Remote Credential Guard (Windows 10 1607, August 2016) performs the same trick but for interactive sessions, redirecting CredSSP back to the originating workstation [@ms-remote-credential-guard].

Credential Guard (Windows 10 RTM, 2015) [@ms-credential-guard]. Virtualization-Based-Security-isolated LSASS: secrets that LSASS would otherwise hold in user-mode memory are moved into the LSAISO trustlet running in Virtual Trust Level 1. SYSTEM on the box cannot read VTL1 memory. Credential Guard is the ceiling against memory-side ticket and key theft, and is one of the cross-link points to the NTLMless companion article.

FAST armoring (RFC 6113, April 2011). Sam Hartman and Larry Zhu's "A Generalized Framework for Kerberos Pre-Authentication" defines the FAST (Flexible Authentication Secure Tunneling) channel [@rfc6113]. The AS-REQ is wrapped in an outer armor envelope, keyed under the machine account's TGT (for a domain-joined client), an anonymous PKINIT TGT (for a non-domain-joined client), or a compound identity. The armor envelope encrypts the PA-ENC-TIMESTAMP blob and authenticates the entire request, closing the offline-cracking path that targets the encrypted-timestamp pre-auth. The limit: FAST is client opt-in, not on by default, and Server 2012 R2 domain functional level is the floor for compound identity. Many production environments still do not require FAST on their tier-zero accounts.

gMSA (Server 2012). The dispositive Kerberoasting defence for service accounts [@ms-gmsa]. The Microsoft Key Distribution Service (kdssvc.dll) computes a 240-character random password, rotated every 30 days, and member hosts authorised in msDS-GroupMSAMembership can retrieve it from a domain controller. The decisive property that gMSA closes is the human-typed-password assumption: there is no password to remember, write down, or share.

LDAP signing and channel binding. The dispositive KrbRelayUp defence. Set LDAPServerIntegrity = 2 to require signing on every LDAP bind, and LdapEnforceChannelBinding = 2 to require channel binding on TLS-bound LDAP connections. Both are off by default in older domain functional levels, which is exactly the default the [@krbrelayup] README is targeting when it calls itself "no-fix".

KrbtgtFullPacSignature (November 2022). The first PAC-handling protocol change since Windows 2000's introduction of the PAC. After full enforcement, every PAC carries an additional Full PAC Signature covering the entire encoded structure, not just sub-pieces; Diamond and Sapphire variants that previously evaded validation by tampering with un-covered fields now fail [@cve-2022-37967] [@ms-kb-5021131].

MachineAccountQuota = 0 guidance (KB5008383, November 2021) [@ms-kb-5008383]. The dispositive RBCD defence as a configuration: setting the directory-wide ms-DS-MachineAccountQuota attribute on the domain root to zero prevents non-administrative users from creating computer accounts at all, which kills the first step of the chain in Section 1's Hook.

Key idea: Each defensive control patches a primitive. No control patches the structural property of the protocol -- that any long-term symmetric key is forge-equivalent for every ticket type that key signs, and that the protocol's offline-validation guarantee makes online ticket revocation incompatible with the design.

Defence	Target Primitive	Structural Limit
Protected Users [@ms-protected-users]	Pass-the-Hash, Pass-the-Ticket, RC4 pre-auth	Breaks delegation, RC4, and NTLM; four-hour TGT cap may break legacy apps
Authentication Policy Silo [@ms-protected-users]	Per-tier scope of Protected-Users behaviour	Requires Server 2012 R2 DFL; FAST armoring requires Server 2012 R2 too
Credential Guard	LSASS memory theft (Mimikatz `sekurlsa::`)	Does not prevent ticket theft via legitimate Kerberos APIs
FAST (RFC 6113) [@rfc6113]	PA-ENC-TIMESTAMP offline cracking	Client opt-in; not on by default
gMSA [@ms-gmsa]	Kerberoasting on service accounts	Human-managed service accounts unaffected
LDAP signing + channel binding	KrbRelayUp [@krbrelayup]	Off by default in older domains
KrbtgtFullPacSignature [@cve-2022-37967]	Diamond and most Sapphire variants	Does not stop Sapphire variants whose tampered PAC was issued legitimately
MachineAccountQuota = 0	RBCD chain [@shenanigans-rbcd]	Default value is `10`; setting requires admin action

Read the table the way an attacker reads it. Each row is necessary; no row is sufficient. The "structural limit" column is the next-attack catalogue. Protected Users does not stop a Diamond Ticket forged from a stolen KRBTGT key. Credential Guard does not stop the operator who has SYSTEM on a domain controller. FAST does not stop AS-REP Roasting (because AS-REP Roasting only happens on accounts with pre-auth disabled, where FAST is moot). gMSA does not protect a service account someone still manages manually with a Notes-saved password.

The pattern is the answer to the section's opening question. Every control attacks one primitive -- a key, a flag, a coercion path, a ticket lifetime -- and none of them closes the protocol-level structural property that any long-term symmetric key in the domain is forge-equivalent for any ticket type that key signs. By 2022 the engineering catalogue was complete. The 2023 announcement was the first plan that targeted the structure.

What would a structural fix even look like, given that any "online revocation" change would also give up Kerberos's O(1) service-side validation, and given that any "deprecate the long-term key" change has to back-compat to clients that have not been touched since Server 2008? The October 2023 Palko post had answers.

6. The Breakthrough: Closing the Domainless Gap

October 11, 2023. Matthew Palko, Microsoft's Principal Group Product Manager for Windows authentication, publishes "The evolution of Windows authentication" on the Windows IT Pro Blog. The article's <meta property="article:modified_time"> reads 2023-11-11T01:30:49.108-08:00 in the raw HTML; the description metadata reads "Discover how we're securing authentication and reducing NTLM usage in Windows" [@ms-palko-evolution]. It is the first time Microsoft commits publicly to deprecating NTLM, and the first time Microsoft names the three load-bearing engineering features that move Kerberos from "domain-only" to "load-bearing-for-everything".

The plan has four moving parts. Each one closes a specific reason that NTLM survived for thirty years.

IAKerb: Kerberos without KDC line-of-sight

The structural reason NTLM lived through Server 2003, Server 2008, Server 2012, and Server 2019 is that Windows had no Kerberos-equivalent path for the case where a client cannot reach a KDC. A laptop on a hotel network, a hybrid Azure-joined workstation that can reach the application server but not the AD DC, a workgroup machine attempting to access a domain file share -- all of those flowed back to NTLM by default, because Kerberos required a working AS-REQ to the domain controller before it could mint a TGT.

IAKerb (Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API) closes that gap. The draft IETF specification, draft-ietf-kitten-iakerb, is by Benjamin Kaduk, Jim Schaad, Larry Zhu, and Jeffrey E. Altman [@iakerb-draft]. The mechanism is GSS-API encapsulation: the client wraps each AS-REQ, AS-REP, TGS-REQ, and TGS-REP message inside a GSS-API token addressed to the application server, and the application server proxies the token to the KDC the server can reach. From the client's perspective, it is talking to the application server; from the KDC's perspective, the AS exchange came from the application server. The protocol's verbatim problem statement reads: "encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server" [@iakerb-draft].

Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API. An extension to GSS-API Kerberos (RFC 4121) that encapsulates Kerberos AS / TGS exchanges inside GSS-API tokens between client and application server, so the application server can proxy them to a KDC the server can reach but the client cannot. Documented in the IETF draft `draft-ietf-kitten-iakerb` by Kaduk, Schaad, Zhu, and Altman [@iakerb-draft]. A Kerberos Key Distribution Center implemented as an in-process service inside the local Windows Security Authority (LSASS) on a workgroup or Azure-joined machine. The Local KDC issues tickets backed by the local SAM password database, exposing no Kerberos port to the network; clients reach it only through IAKerb encapsulation tunnelled through the application protocol. Closes the "local account auth has no KDC" gap that has kept NTLM alive for workgroups since Windows NT 3.1 [@ms-palko-evolution] [@fosdem-localkdc].

MIT krb5 added IAKERB support fifteen years ago. The README for krb5-1.9, released December 22, 2010, says verbatim: "Add support for IAKERB -- a mechanism for tunneling Kerberos KDC transactions over GSS-API, enabling clients to authenticate to services even when the clients cannot directly reach the KDC that serves the services" [@mit-krb5-19-readme] [@mit-krb5-19-page]. The capability sat in MIT's mainline Kerberos for over a decade. Windows did not ship the equivalent because, until NTLM was on a deprecation path, Windows did not need it -- NTLM filled the line-of-sight gap. Once NTLM was on the road to removal, IAKerb stopped being optional. The sixteen-year gap between MIT krb5-1.9 IAKERB (December 22, 2010) and Microsoft's planned H2 2026 broad enable is the cleanest evidence that Microsoft's NTLM deprecation is the forcing function for the Kerberos refit, not a side effect. The specification was waiting for the customer demand to catch up.

Local KDC: Kerberos for the workgroup

The second structural reason NTLM survived was that Windows local accounts had no concept of "domain". Without an AD domain, there was no KDC. Without a KDC, there were no Kerberos tickets. Local-account authentication therefore flowed through NT challenge-response (NTLMv2) by default.

Local KDC closes this. The Local KDC, shipping in Windows 11 24H2 and Server 2025 with broad enablement targeted for H2 2026 [@ms-palko-evolution], is a Kerberos KDC built directly on top of the local SAM database. LSA derives an AES-256 long-term key from the local account's password rather than persisting the legacy RC4 NT hash. The Local KDC exposes no listening Kerberos port; clients reach it only through IAKerb encapsulation inside the application protocol (SMB, RDP, HTTP).

The parallel open-source path was demonstrated by Alexander Bokovoy and Andreas Schneider at FOSDEM 2025, where they presented "localkdc: A General Local Authentication Hub" [@fosdem-localkdc]. The abstract reads verbatim: "A local Kerberos Key Distribution Center (KDC) is not a new invention. It is a useful tool in combination with the Kerberos IAKerb extension but also allows to map SSO from a web authentication to local authentication or in a network environment isolated from the rest of the enterprise environment ... how use of NTLM in SMB protocol will be replaced by a localkdc in combination with IAKerb" [@fosdem-localkdc]. Samba 4.21 carries the prototype implementation.

The Bokovoy / Schneider talk is the cleanest external evidence that Local KDC is a *protocol-level* architecture, not a Microsoft-proprietary one. Samba, Heimdal, MIT krb5, and Microsoft are converging on the same design: an in-process KDC, GSS-API-tunnelled Kerberos exchanges, AES-keyed local accounts. The IETF draft-ietf-kitten-iakerb specification [@iakerb-draft] is the shared standardisation layer. Add support for IAKERB -- a mechanism for tunneling Kerberos KDC transactions over GSS-API, enabling clients to authenticate to services even when the clients cannot directly reach the KDC that serves the services. -- MIT krb5-1.9 release notes, December 22, 2010 [@mit-krb5-19-readme]

PKINIT and the freshness extension

The third gap NTLM filled was non-password credentials. Windows Hello for Business, smart cards, and Federal Information Processing Standard token logon all need to translate "I hold this private key" into "I hold this Kerberos TGT". PKINIT (Public Key Cryptography for Initial Authentication in Kerberos), RFC 4556, by Larry Zhu (Microsoft) and Brian Tung (Aerospace Corporation), is the protocol for that [@rfc4556]. The AS-REQ carries a PA-PK-AS-REQ PA-DATA element wrapping an AuthPack CMS structure signed by the client's private key; the AS-REP carries the TGT keyed for the client to decrypt with either RSA key transport or Diffie-Hellman key exchange.

The 2006 RFC 4556 PKINIT had a replay window: an attacker who recorded a signedAuthPack could replay it indefinitely until the client's certificate expired. RFC 8070, "PKINIT Freshness Extension," by Michiko Short, Seth Moore, and Peter Miller of Microsoft (February 2017) closed it [@rfc8070]. The AS-REP issues an opaque PA-AS-FRESHNESS blob in a preliminary KDC-error round-trip; the client must echo the blob in its next signed AS-REQ; replays after the freshness window fail. Verbatim from RFC 8070 abstract: "exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINIT Authentication Service (AS) exchange" [@rfc8070].

Together, RFC 4556 plus RFC 8070 anchor every modern non-password Windows credential: Windows Hello for Business, smart-card logon, FIDO2 keys mediated by Windows Hello, and the upcoming Entra-issued cloud TGTs. The 2022 Certifried CVE [@cve-2022-26923] forced the strong-mapping layer on top of all of this: every certificate used for PKINIT must carry an X.509 extension binding it to a specific AD account SID. KB5014754 [@ms-kb-5014754] tracks the rollout; see §4 for the full Compatibility / Enforcement / rollback-removal date sequence.

FAST armoring as default

The fourth gap was the trust assumption at the start of an AS-REQ: the encrypted-timestamp pre-auth blob, PA-ENC-TIMESTAMP, is keyed under the client's password-derived key, which is offline-crackable on observation. FAST (RFC 6113) wraps the AS-REQ inside an armor envelope keyed under a separate key the attacker does not see [@rfc6113]. In a domain-joined client the armor key is derived from the machine account's TGT; in a non-domain-joined client it is derived from an anonymous PKINIT TGT; in a compound-identity scenario it is the combination of both.

What changes in the 2023 plan is the default-on posture: Authentication Policy Silos can now require FAST for every AS-REQ from a silo member, and Local KDC clients use anonymous PKINIT armoring out of the box because the SAM-derived long-term key is the only credential available and offline-crackability would be catastrophic.

sequenceDiagram participant C as Client (no KDC reach) participant S as Application Server participant KDC as KDC (reachable from S) C->>S: GSS-API token: IAKerb (AS-REQ wrapper) S->>KDC: AS-REQ (forwarded) KDC->>S: AS-REP (forwarded) S->>C: GSS-API token: IAKerb (AS-REP wrapper) C->>S: GSS-API token: IAKerb (TGS-REQ wrapper) S->>KDC: TGS-REQ (forwarded) KDC->>S: TGS-REP (forwarded) S->>C: GSS-API token: IAKerb (TGS-REP wrapper) C->>S: AP-REQ presenting service ticket S->>C: AP-REP -- session established

The Gap-to-Closure Mapping

NTLM-fallback gap	Engineered closure	Primary source	Ship target
Client has no KDC line-of-sight	IAKerb GSS-API encapsulation	[@iakerb-draft]	Windows 11 24H2 / Server 2025; broad enable H2 2026 [@ms-palko-evolution]
Local accounts have no domain KDC	Local KDC on SAM + AES-256 derivation	[@ms-palko-evolution] [@fosdem-localkdc]	Windows 11 24H2 / Server 2025
Non-password credentials need an AS path	PKINIT (RFC 4556) + Freshness (RFC 8070) + strong mapping (KB5014754)	[@rfc4556] [@rfc8070] [@ms-kb-5014754]	Enforcement February 11, 2025; Disabled mode removed April 2023; Compatibility mode removed Sept 9, 2025
AS-REQ pre-auth is offline-crackable	FAST armoring (RFC 6113) default-on in silos	[@rfc6113]	Available since Server 2012 R2; default-on with new silos

After thirty-three years of layered extensions, Kerberos in 2026 is finally a single-protocol authentication path for every Windows scenario. Domain-joined, workgroup, Azure-joined without AD line-of-sight, local-account to local-account. The mechanism that closes the last gap -- IAKerb -- is a sixteen-year-old MIT protocol coming to Windows for the first time. What's left for Kerberos to fix is encryption-type hygiene, and a December 2025 Microsoft post named the calendar dates for that too.

7. The Beyond-RC4 Cadence

December 3, 2025. The Microsoft Windows Server Blog publishes "Beyond RC4 for Windows authentication" [@ms-beyond-rc4]. The post is short and specific. Verbatim: "By mid-2026, we will be updating the domain controller default assumed supported encryption types. The assumed supported encryption types is applied to service accounts that do not have an explicit configuration defined. Secure Windows authentication does not require RC4; AES-SHA1 can be used across all supported Windows versions since it was introduced in Windows Server 2008" [@ms-beyond-rc4]. For the first time in twenty years, RC4-HMAC is on a removal cadence with a calendar date and an enforcement CVE.

The rollout has three phases.

Phase 1, January 2026, audit only. Domain controllers gain new fields in Event ID 4768 (TGT issued) and Event ID 4769 (TGS issued): msDS-SupportedEncryptionTypes, Available Keys, and Session Encryption Type. The fields tell an administrator, for each ticket issued, which enctypes the requesting account had configured and which one the KDC actually chose. Two new PowerShell auditing scripts ship in the microsoft/Kerberos-Crypto GitHub repository: List-AccountKeys.ps1 enumerates every account and the enctype configuration on each; Get-KerbEncryptionUsage.ps1 parses the 4768 / 4769 log stream and prints accounts still requesting or being issued RC4 tickets [@ms-beyond-rc4]. Verbatim from the post: "we have enhanced existing information within the Security Event Log and developed new PowerShell auditing scripts. These enhancements are available in Windows Server versions 2019, 2022, and 2025" [@ms-beyond-rc4].

Phase 2, April 2026, default flip. The "assumed" msDS-SupportedEncryptionTypes on accounts that have no explicit setting changes from "anything the client asks for, including RC4" to "AES-SHA1 only". AES-SHA1 (RFC 3962 enctypes 17 and 18) has shipped on every supported Windows version since Server 2008 [@rfc3962], so the flip is theoretically backward-compatible with every domain-joined client; in practice the casualties are third-party Kerberos clients (legacy Linux MIT krb5 with RC4-only keytabs, network-attached-storage appliances stuck on older krb5 libraries, SQL Server linked servers with manually-configured service-principal RC4 entries).

Phase 3, mid-2026, enforcement. RC4 tickets require explicit per-account opt-in. The enforcement boundary is CVE-2026-20833, called out by name in the Microsoft post [@ms-beyond-rc4]. After that date, an account that has not had msDS-SupportedEncryptionTypes explicitly written to include 0x4 (RC4) will not be issued RC4 tickets, and DCs will reject any TGS-REQ that asks for one against an account configured AES-only.

Note: The mid-2026 RC4-default removal is gated on CVE-2026-20833, named in the December 2025 "Beyond RC4" post as the enforcement boundary [@ms-beyond-rc4]. The audit window closes when this date lands. Production environments that have not migrated their service accounts to gMSA or explicitly set msDS-SupportedEncryptionTypes will find Kerberos authentication failing for those accounts the day Phase 3 ships.

The interesting question is why the migration destination is AES-SHA1 (enctypes 17 and 18) and not AES-SHA2 (enctypes 19 and 20). RFC 8009 specifies AES-SHA2 [@rfc8009]; Microsoft's [MS-KILE] §2.2.7 supported-encryption-types bit table includes bits K (AES128-CTS-HMAC-SHA256-128) and L (AES256-CTS-HMAC-SHA384-192) [@ms-kile-227]. Linux MIT krb5 has shipped RFC 8009 since version 1.15 (December 2016) [@mit-krb5-115]. Cross-domain interoperability between AES-SHA2 Windows and AES-SHA2 MIT works. The remaining work is purely Microsoft-side default enablement and the auditing infrastructure analogous to the RC4 cadence.

The Beyond-RC4 post does not name an AES-SHA1 -> AES-SHA2 timeline at all. The audit-default-enforce cadence Microsoft has now demonstrated for RC4 -- audit instrumentation in event logs, default flip with backward-compatible enctypes, enforcement gated by a named CVE -- has no announced analogue for AES-SHA1 yet.

Key idea: The cadence Microsoft has is audit, default, enforce. The RC4 to AES-SHA1 transition has all three: audit instrumentation in Phase 1, the default flip in Phase 2, and named enforcement via CVE-2026-20833 in Phase 3. The AES-SHA1 to AES-SHA2 transition has none. The [MS-KILE] bits exist; the cross-domain interoperability works; the Microsoft-side rollout is the missing piece. The microsoft/Kerberos-Crypto GitHub repository ships the two PowerShell auditing scripts (List-AccountKeys.ps1, Get-KerbEncryptionUsage.ps1) that the December 2025 post names as the Phase 1 instrumentation. They are the right tools for an administrator who wants to find their RC4-dependent service accounts before the audit window closes mid-2026 [@ms-beyond-rc4].

Mid-2026 is the audit-window-closes date. The question for every AD operator is which of their service accounts will still be requesting RC4 tickets when the default flips, and whether their detection tooling sees them in the window. Two quarters from now, the answer "we'll just turn RC4 off and see what breaks" stops being a defensible operating posture.

timeline title Beyond-RC4 rollout section Phase 1 -- Audit Jan 2026 : Event 4768 / 4769 fields msDS-SupportedEncryptionTypes Available Keys Session Encryption Type Jan 2026 : Kerberos-Crypto GitHub repo with List-AccountKeys.ps1 and Get-KerbEncryptionUsage.ps1 section Phase 2 -- Default flip Apr 2026 : Assumed msDS-SupportedEncryptionTypes flips to AES-SHA1-only for accounts without explicit configuration section Phase 3 -- Enforcement Mid 2026 : CVE-2026-20833 enforcement boundary -- RC4 tickets require explicit per-account opt-in

8. What Removing NTLM Cannot Buy You

After everything in Section 6 and Section 7 ships, Kerberos in 2026 is still vulnerable to four classes of attack. None of them are protocol bugs; all of them are protocol structure.

Kerberos has its own relay class. The KrbRelayUp README explicitly scopes itself to Windows domain environments where LDAP signing is not enforced -- the post-NTLM cousin of NTLM-relay [@krbrelayup]. The relay primitive survives the move from NTLM to Kerberos because the attack does not target the authentication protocol -- it targets the LDAP protocol's lack of mandatory integrity, and any authenticated bind (Kerberos or NTLM) is fair game once the channel is unsigned. The dispositive control is LDAP signing plus channel binding domain-wide, plus Extended Protection for Authentication on every AD CS Web Enrolment endpoint. It is a configuration, not a protocol fix. The NTLMless companion article walks through the LDAP-side work in detail.

The long-term-key problem is intrinsic to symmetric Kerberos. Whoever holds the krbtgt account's long-term key forges any TGT (the Golden Ticket primitive). Whoever holds an SPN account's long-term key forges any TGS for that service (the Silver Ticket primitive). RFC 4120's offline-validation property [@rfc4120] requires that the service trust the key alone -- the AP-REQ contains no callback to the KDC; the service decrypts the ticket, validates the signatures, and decides. Any change that adds an online "is this ticket still valid?" check also gives up Kerberos's O(1) service-side scaling and the offline-validation guarantee that makes the protocol cheap. Authentication Policy Silos, Protected Users, TPM-backed credentials, and Credential Guard all raise the cost of obtaining the key; they do not close the forge-equivalence property. Mathematically, if you have the key, you are the principal.

The PAC is a signed vouching token, not a verified live query. KrbtgtFullPacSignature [@cve-2022-37967] closes the modification side of Diamond and Sapphire. It does not close the staleness side. A user removed from Domain Admins at 09:00 still presents service tickets attesting Domain Admin membership until the ticket expires (default 10 hours user TGT, 7 days renewable; Protected Users members are capped at 4 hours [@ms-protected-users]). The PAC vouching window is the residual stale-authorization gap. The defender's option is shorter ticket lifetimes or out-of-band ACL flips at the service tier; the protocol itself has no callback by which a service learns about a group-membership change before the ticket expires.

Domainless does not mean keyless. Local KDC binds the SAM password to an AES-256 long-term key. The wire form of pass-the-hash is gone: there is no NT hash on the line, no LMv2 challenge response, no DES-CBC-MD5 keytab. But a NT AUTHORITY\SYSTEM-level attacker on the box still recovers the AES key, because LSA must materialise that key in user-mode memory to hand it to Kerberos. The chip- and VBS-based countermeasures (TPM-backed credentials, Microsoft Pluton, Credential Guard) remain orthogonal and necessary; none of them is replaced by Local KDC.

Key idea: H2 2026 ships Kerberos as the load-bearing single authentication protocol; it does not ship a Kerberos in which (1) the Kerberos-relay class is closed, (2) long-term-key forge-equivalence is closed, (3) PAC staleness is closed, or (4) local-key recovery from a SYSTEM-level attacker on the box is closed. The arc is a transition between tradeoffs, not out of them.

The Phase-3-as-transition-between-tradeoffs framing is mirrored in the [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/) companion article's Section 8 -- the symmetric framing is deliberate. Read the two articles together as a paired diagnosis: NTLMless is the eulogy and the migration story; this article is the inheritance and the to-do list.

9. Open Problems and the 2026-2027 Edge

Five problems sit on the May-2026 research agenda. None has a shipping Microsoft answer.

The AES-SHA1 to AES-SHA2 Windows-default timeline. RFC 8009 [@rfc8009] is nine years old. The [MS-KILE] §2.2.7 supported-encryption-types bit table already includes the AES-SHA2 bits K and L [@ms-kile-227]. Linux MIT krb5 shipped RFC 8009 in version 1.15 (December 2016) [@mit-krb5-115]. Cross-domain Kerberos interop between MIT clients and Windows DCs over AES-SHA2 works in the laboratory. What is missing is a Microsoft-side equivalent of the audit / default / enforce cadence already in place for the RC4 transition, especially because the hard part is not the cryptography but the long tail of third-party Kerberos clients and pre-2017 keytabs that an AES-SHA2 audit would have to enumerate before the default can flip. The 8009 cadence is the largest Windows-side cryptographic gap that has no announcement.

Quantum risk. Kerberos symmetric primitives (AES-128 and AES-256) retain a Grover-bound effective security margin of 64 and 128 bits respectively, which is durable against the near-term cryptographically-relevant quantum computer. PKINIT is the exposed half: the CMS signature chains in AuthPack are RSA or ECDSA per RFC 4556 §3.2 [@rfc4556], and both are broken by Shor's algorithm. Anonymous PKINIT, used for FAST armoring on non-domain-joined clients, has the same exposure. Microsoft has not announced a PKINIT-specific post-quantum cryptography plan; the Kerberos team's standardisation tracking sits on the IETF kitten working group's queue rather than on a shipping Windows roadmap. Cross-link to the post-quantum cryptography sibling article in this series.

dMSA field-deployment maturity. Server 2025 introduced Delegated Managed Service Accounts as the successor to gMSA [@ms-dmsa]. The protocol-level differences -- "Authentication for dMSA is linked to the device identity ... dMSA uses a randomized secret (derived from the machine account credential) that is held by the Domain Controller (DC) to encrypt tickets" -- close several gMSA gaps, including the multi-tenant-key problem. But the 14-day account-migration window, the four-ticket-lifetime startup state during which both the legacy account and the dMSA can authenticate, and the cross-domain plus cross-forest behaviours are still being shaken out in field deployments. As of the May 2026 reading, dMSA is shipping but not yet the default for new service accounts.

Cross-cloud Kerberos. Kerberos Cloud Trust for Windows Hello for Business is the architectural piece that lets an Azure-joined laptop obtain TGTs from Entra ID rather than from an on-premises DC, with the on-premises DC trusting Entra's signatures via federation. Per [@ms-palko-evolution] the architecture is planned but unproven in the field at scale. The role of Local KDC in pure-Entra (no AD on-prem) deployments is still being defined. The trust graph for "Local KDC + Entra ID + on-premises AD" is one of the open architectural problems the Palko post mentions but does not yet detail.

Open-source IAKerb and Local KDC. Samba's localkdc work, demonstrated by Alexander Bokovoy and Andreas Schneider at FOSDEM 2025 [@fosdem-localkdc], is the most public open-source mirror of Microsoft's Local KDC plan. Heimdal has a partial implementation. MIT krb5 IAKERB has been shipping since krb5-1.9 on December 22, 2010 [@mit-krb5-19-readme] and is mature. The Local-KDC-on-the-SAM pattern is new to the Windows world specifically; in the open-source world the equivalent (a Kerberos KDC fed from a local user database) has existed in textbooks since Kerberos v4.

Each of the five problems is a residual. Each is the next decade's research. None of them invalidates the Phase 3 shipping commitment. The article's load-bearing closing claim is honest about that: H2 2026 is a transition, and what comes next will be its own multi-year cadence.

10. What an AD Engineer Should Do This Quarter

If you read nothing else from this article, read this. Seven controls; each one is tied to one primary Microsoft Learn or MSRC URL; each one closes one of the attack primitives in Section 4. Cross-link to the parallel practical-guide section in the NTLMless companion article.

Note: Run the two PowerShell scripts in microsoft/Kerberos-Crypto: List-AccountKeys.ps1 enumerates every account's configured enctypes; Get-KerbEncryptionUsage.ps1 parses your Event 4768 / 4769 stream and lists accounts still requesting or being issued RC4 tickets. The audit window closes mid-2026 when Phase 2 flips the default [@ms-beyond-rc4]. Every account on the list above is a Phase-3 production incident if you do nothing.

Note: Do not rely on the mid-2026 default flip. Explicitly write msDS-SupportedEncryptionTypes with the value 0x18 (AES-128 + AES-256, no RC4) on every service account that does not have a documented RC4 dependency. For service accounts that do, write 0x1C (AES-128 + AES-256 + RC4) and put a calendar reminder against the RC4 dependency so it gets remediated before Phase 3 [@ms-beyond-rc4].

Note: Manually-managed service-account passwords are the Kerberoasting attack surface per [@ms-kerberoasting-guidance]. gMSA gives you 240-character KDS-derived passwords rotated every 30 days [@ms-gmsa]. dMSA on Server 2025 binds the account secret to the device identity and stores it only on the domain controller, where it can be further protected by Credential Guard [@ms-dmsa]. There is no service-account workflow gMSA or dMSA does not cover; the migration is operational, not architectural.

Note: Setting ms-DS-MachineAccountQuota on the domain root to zero kills the first step of the RBCD chain in Section 1 [@shenanigans-rbcd] and the KrbRelayUp chain [@krbrelayup]. The default value of 10 has been the de facto attack-surface enabler since Windows 2000. The control is one PowerShell line: Set-ADDomain -Identity (Get-ADDomain) -Replace @{'ms-DS-MachineAccountQuota'=0}. The breakage surface is small: only legitimate computer-account bootstrap workflows that today rely on user-driven djoin.exe.

Note: Protected Users gives every member the five non-configurable client protections plus the 4-hour TGT cap [@ms-protected-users]. Wrap an Authentication Policy Silo around the same population to add mandatory FAST armoring [@rfc6113] and per-silo logon-from constraints. Both controls have been available since Server 2012 R2; the operational reason most environments still have not adopted them is the breakage in legacy delegation workflows. Audit and remediate those workflows; do not skip Protected Users.

Note: Set LDAPServerIntegrity = 2 (require signing) and LdapEnforceChannelBinding = 2 (require channel binding on TLS-bound connections) via Group Policy. This is the dispositive KrbRelayUp defence [@krbrelayup] and the dispositive defence against any Kerberos-relay-class attack that targets the LDAP control plane. Pair with Extended Protection for Authentication on every AD CS Web Enrolment endpoint to close the Certifried-style certificate-issuance variant [@ms-kb-5014754].

Note: Flight the RC4DefaultDisablementPhase Group Policy setting in your Insider channel; pilot non-production AES-only configurations on a representative subset of service accounts; identify legacy NAS appliances, Linux MIT krb5 clients with keytabs older than 2017, and SQL Server linked-server SPNs before Phase 2 closes the audit window [@ms-beyond-rc4]. Phase 3 ships with CVE-2026-20833; production environments that have not run the audit will discover the dependency list the day enforcement lands.

Three quarters from now (mid-2026), every default in this list will have changed. Do the work in the audit window or do it in the post-flip ticket queue. The cost of an audit-window migration is a quarter of engineering time; the cost of a post-flip remediation is a sixty-minute outage on every undocumented RC4 dependency the directory holds. Cross-link to the Pluton, TPM, and Credential Guard sibling articles for the hardware-backing layer that protects the long-term keys these controls assume.

11. Frequently Asked Questions

AES-SHA1 (RFC 3962 enctypes 17 and 18) is enough against the 2026 attack picture: there is no known cryptographic attack against AES-256-CTS-HMAC-SHA1-96 within Kerberos's threat model, and AES eliminates the salt-less / iteration-less Kerberoasting weakness of RC4-HMAC [@rfc3962] [@ms-kerberoasting-guidance]. AES-SHA2 (RFC 8009 enctypes 19 and 20) is the obvious next step and is supported by [MS-KILE] bits K and L [@ms-kile-227]. Quantum threats are not the immediate worry for symmetric Kerberos; the exposed surface is PKINIT, not the ticket cipher.The Grover speedup applied to AES-256 leaves an effective 128-bit security margin, which is durable for the lifetime of any current cryptographic system [@nist-pqc]. Yes, for delegation, and that is the point. Per [@ms-protected-users], members cannot use unconstrained or constrained delegation, cannot use DES or RC4 in Kerberos pre-auth, and have their TGT capped at four hours. Workflows that today rely on a domain admin's TGT being forwardable to a downstream service must be reworked. Use Authentication Policy Silos for the per-account scope where some delegation must remain. Yes, with risk. The mid-2026 enforcement boundary CVE-2026-20833 [@ms-beyond-rc4] is the formal cutover. Disabling RC4 today by setting `msDS-SupportedEncryptionTypes` to `0x18` (AES-only) on accounts will work, but expect breakage from Linux clients with MIT krb5 keytabs older than 2017, network-attached-storage appliances with hard-coded RC4 entries, and SQL Server linked-server SPNs that have not been updated. The audit-then-migrate cadence in Section 10 is the operationally honest path. No. It kills *unsigned-PAC* Golden Tickets and most Diamond and Sapphire variants that tampered with PAC fields outside the original sub-signatures [@cve-2022-37967]. If an attacker has the actual `krbtgt` long-term key, they still mint correctly-signed tickets -- the Full PAC Signature is computed with that same key. The defence is rapid `krbtgt` rotation (the dual-password scheme means you must rotate twice with an interval) plus Credential Guard to keep the key out of LSASS user-mode memory. PKINIT [@rfc4556] exists, Active Directory Certificate Services exists, Windows Hello for Business is built on top of PKINIT. The reason "everywhere" was hard is Certifried (CVE-2022-26923) [@cve-2022-26923] and the strong-mapping retrofit [@ms-kb-5014754]: the original ADCS templates allowed a certificate's Subject Alternative Name to be set independently of the AD account that requested the certificate, which let an attacker mint a certificate claiming to be a domain controller. Strong mapping (the SID-binding X.509 extension) closed that, but the rollout took years to land in Enforcement mode (see §4 for the full date sequence). It eliminates the *wire* form. There is no NT hash on the LSA-to-Local-KDC path; the long-term key is an AES-256 derivation. A SYSTEM-level attacker on the box still recovers that AES key, because LSA must hold it in user-mode memory to hand to the Kerberos SSP. The chip-side defences (TPM, Microsoft Pluton, Credential Guard) remain orthogonal and necessary per [@fosdem-localkdc]. Local KDC closes the relay-from-the-wire class, not the SYSTEM-on-the-box class. Kerberos Cloud Trust for Windows Hello for Business issues TGTs from Entra ID and federates trust back to on-premises AD, so an Entra-joined laptop can present a domain-trusted Kerberos ticket to a file server it has never directly authenticated to. The on-premises KDC role is partially federated; the on-prem AD signs nothing for the Entra-issued TGT but trusts Entra's signature via Cloud Trust. Per [@ms-palko-evolution] the architecture is shipping in stages. The full story is its own article in this series. Not in this decade. The architectural trajectory is "Kerberos + PKINIT + FAST + Local KDC + IAKerb + Authentication Policy Silos + TPM-backed long-term keys" -- not a replacement protocol. The closest thing to a replacement on the horizon is post-quantum PKINIT, which is more of a re-cipher than a re-protocol. The Kerberos message triple (AS-REQ, TGS-REQ, AP-REQ) is genuinely durable.Compared with the 28-year deprecation cycle NTLM took, replacing Kerberos would be a thirty-year project on the same precedent. Microsoft's stated direction is to harden the joints, not to throw out the skeleton. The commands below assume Server 2019 or later with the `microsoft/Kerberos-Crypto` repo cloned locally. Run on a domain controller; output names every account whose configured `msDS-SupportedEncryptionTypes` allows RC4 or has no explicit setting (in which case it inherits the pre-Phase-2 default of "anything goes"). Cross-reference with the 4768 / 4769 audit stream from `Get-KerbEncryptionUsage.ps1` to identify which of those accounts is actually being issued RC4 tickets in practice.

# Enumerate accounts and configured enctypes
Import-Module ActiveDirectory
.\List-AccountKeys.ps1 -OutputCsv accounts.csv

# Parse 4768 / 4769 events for issued ticket enctypes
.\Get-KerbEncryptionUsage.ps1 -LookbackDays 30 -OutputCsv tickets.csv

# Join the two on account name -- the accounts that
# both have RC4-allowed AND were issued RC4 tickets
# are your Phase 3 incident list.

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.

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.

Parag Mali - tag: authentication

From Password-in-the-Pipe to Cloud-Issued Session: Twenty-Six Years of RDP Authentication

1. Four sekurlsa Dumps, One Target

2. Terminal Services and the Password-in-the-Pipe Era (1998-2005)

3. Network Level Authentication via CredSSP (2006-2013)

4. BlueKeep, CVE-2018-0886, and the Two Failure Modes of CredSSP

CVE-2018-0886: CredSSP Remote Code Execution

The AllowEncryptionOracle deployment incident

CVE-2019-0708: BlueKeep

5. Restricted Admin: User Is the Machine (2013)

The wire protocol

The mechanism: the user becomes the machine

The trade-offs, verbatim from Microsoft Learn

The RBCD residual class

6. Remote Credential Guard: Challenges Redirect to Caller (2016)

The wire protocol

The runtime mechanism

The trustlet conditional

Kerberos-only -- and what that means for NTLM-mixed estates

7. PRT-over-RDP: No Password, No Hash, No Ticket (2022)

The wire protocol

The mechanism: from .rdp file to Entra-issued session

Two GUIDs, two purposes

8. Five Modes, One Matrix, 2026 Operational Reality

9. Adjacent Mitigations: What Else Protects RDP (And What It Does Not Protect)

10. Theoretical Limits: The Four Things RDP Authentication Cannot Close

Limit 1: The SYSTEM-on-target floor

Limit 2: The CredSSP residue

Limit 3: The RBCD-against-TERMSRV class

Limit 4: The Entra-only / on-prem-only gap

11. Open Problems: Where Research and Operations Are Still Moving

Open Problem 1: PRT extraction at the session host

Open Problem 2: CredSSP is not deprecable

Open Problem 3: Remote CG NTLM exclusion and the hybrid-estate user experience

Open Problem 4: The Entra / on-prem composition gap

Open Problem 5: Windows 11 24H2 KIR as a deployment-fault recovery surface

Open Problem 6: QUIC transport and the network-layer detection surface

12. Practical Guide, FAQ, and Closing

For the administrator / platform engineer

For the security researcher

For the red-team operator

For the detection engineer

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

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

2. Historical origins: the 1990s problem statement

3. Early approaches: fuzzy commitment and fuzzy vault

3.1 Juels-Wattenberg 1999: fuzzy commitment

3.2 Juels-Sudan 2002 / 2006: fuzzy vault

3.3 The structural defect both constructions share

4. Evolution: five generations at a glance

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

5.1 The secure sketch: information reconciliation

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

5.3 Composition

5.4 The load-bearing inequality

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

6.1 Sketches by metric space

6.2 Generation 3a: Boyen 2004 reusable fuzzy extractors

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

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

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

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

7. Competing approaches: six paradigms

8. Theoretical limits

8.1 The min-entropy floor

8.2 Reusability impossibility

8.3 Active-adversary lower bound

8.4 Combining the three bounds

9. Open problems

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

10.1 Enrolment

10.2 Authentication

10.3 Why this is the right design

10.4 The sibling case: Apple Face ID and Touch ID

11. Frequently asked questions

Kerberos in Windows: The Other Half of NTLMless

1. A Chain Without NTLM

2. Origins: Needham, Schroeder, Athena, and 1988

3. The Wire in 2026: Six Messages and an Encryption Matrix

4. The Attack Cascade: 2014 to 2022

The mechanism: from `.rdp` file to Entra-issued session

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