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

Why Passwords Must Die#

In 2024, Microsoft observed 7,000 password attacks every second ^[1] -- 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 [@corbato-ctss; @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 ^[2].

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       :2007, 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 ^[2] 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 ^[3], 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 under 22 hours ^[4], 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 ^[5] uppercased every password, limited them to 14 characters, and split them into two 7-byte halves hashed independently.

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 ^[5] 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 ^[6], 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 ^[7] -- 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) ^[8] 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 ^[9]. The materials cost less than $10. 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 ^[10] 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 ^[11]. 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 ^[12]. 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.

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 ecosystem 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 ^[13] 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 ^[14], while U2F defined a hardware-token second factor that signs a challenge after the user taps the device ^[15]. FIDO2 later unified these ideas into the WebAuthn + CTAP stack used for passkeys today ^[16].

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?

Here is how Windows Hello authentication ^[17] 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) ^[17].

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.

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 PIN paradox#

Windows Hello also revived the humble PIN -- and made it more secure than a complex password. A Hello PIN ^[17] 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.

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}$ ^[18] 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?

Windows Hello for Business (WHfB) ^[17] 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.

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

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 ^[24] 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.

Using an NXP evaluation board ^[25], 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 ^[24] -- 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.

Microsoft's response: ESS and VBS#

Microsoft's answer came with Windows 11: Enhanced Sign-in Security (ESS) ^[26], 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 ^[23], 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" ^[27] at USENIX Security 2025. Microsoft had already patched CVE-2025-26644 ^[28] 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 ^[29] 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 ^[30]. ※ 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" ^[31] detailed the Faceplant template-injection attack, which they later documented technically on ERNW's research blog ^[32].

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 ^[32].

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

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"]
style B fill:#f66,stroke:#333
style D fill:#f66,stroke:#333
style F fill:#f66,stroke:#333
style C fill:#6f6,stroke:#333
style E fill:#6f6,stroke:#333
style G fill:#6f6,stroke:#333

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 ^[33] -- three companies that agree on almost nothing -- issued a joint announcement: they were all committing to passkeys.

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 ^[16] maintained the cryptographic guarantees (no shared secrets, phishing resistance) while adding the portability users demanded.

The numbers tell the story#

By May 2025, Microsoft made new accounts passwordless by default ^[1]:

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

How the platforms compare#

Sources: Microsoft biometric requirements ^[18], Apple passkey security ^[34], Google passkeys ^[35], FIDO specifications ^[36]

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 ^[35]. 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 ^[37].

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 ^[17]. 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; @ms-whfb-deploy]. 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 ^[26]. 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.

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 ^[38]. 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.

The biometric floor#

The theoretical limit on biometric authentication error is the Bayes error rate ^[39] -- 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 ^[39] -- 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 ^[40] 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 ^[27] 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 ^[38] -- reintroducing the very phishable factors they were designed to eliminate. Recovery codes are functionally passwords.

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

5. The ESS hardware gap. ESS requires specific secure sensors and VBS-capable CPUs ^[26]. Many enterprise PCs -- particularly AMD-based or older Intel machines -- lack the hardware. 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.

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

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

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#