# The Card That Wasn't a Card: How Windows Authentication Outgrew the Smart Card Metaphor > Smart cards, virtual smart cards, and Windows authentication 1996-2026: from PC/SC and PIV through the 2014 NTLM-secondary defect to WHfB and FIDO2. *Published: 2026-05-26* *Canonical: https://paragmali.com/blog/the-card-that-wasnt-a-card-how-windows-authentication-outgre* *License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/* --- **The Windows smart card story is the story of a metaphor.** Roland Moreno's 1974 "card with a secret" became Windows 2000's `SCardSvr.exe`, then Windows 8's TPM Virtual Smart Card (a software card with the same PC/SC interface), then Windows Hello for Business (which threw the card edge away and talks to the TPM directly), then FIDO2 (which added the origin binding the card was never designed for). The cryptographic primitive -- a non-exportable asymmetric key under a local gesture -- survives every transition. The 2014 disclosure that smart-card-required accounts still mint a harvestable NTLM hash is closed not by any change to the card but by Microsoft's 2024-2026 NTLM removal plan. The card was always cryptographically sound; the protection terminated at the act of signing. ## 1. A Smart Card Login That Mints an NTLM Hash Picture May 2014. A Department of Defense contractor pushes her Common Access Card into a Windows 7 workstation, types a six-digit PIN, and watches the lock screen melt into her desktop. The RSA-2048 private key that just signed her [Kerberos](/blog/kerberos-in-windows-the-other-half-of-ntlmless/) pre-authentication blob lives inside a tamper-resistant secure element she cannot extract from the card. The cryptography is excellent. Three hours later, an attacker on the same network owns her domain account without ever touching the card [@dirteam-aorato] [@kb-2871997]. How is that even possible? Hold that question. The answer is the spine of this article. The contractor here is a composite figure, not a documented incident. The mechanism (CAC + Windows 7, RSA-2048 signing inside the card, an NT hash recoverable from LSASS three hours later) is the one Aorato disclosed in 2014 [@dirteam-aorato] and Microsoft documented in KB 2871997 [@kb-2871997]. The scenario is faithful to the published attack chain; the person and the office park are illustrative. The protocol that ran when she logged in is PKINIT, defined by [RFC 4556](#) [@rfc-4556] and profiled for Windows in `[MS-PKCA]` [@ms-pkca]. PKINIT lets a Kerberos client present an X.509 certificate as pre-authentication for the Authentication Service Request (AS-REQ), with a digital signature proving possession of the matching private key. In a Windows smart card logon the signing happens inside the card. The Microsoft Smart Card Key Storage Provider hands the card a hash; the card returns a signed `AuthPack` containing a `PKAuthenticator` (timestamp, nonce, paChecksum) and Diffie-Hellman parameters; that signed `AuthPack` rides in the `PA-PK-AS-REQ` pre-authentication data of the AS-REQ [@rfc-4556] [@ms-pkca]. So far, so good. The Key Distribution Center (KDC) verifies the signature, validates the certificate chain, mints a Ticket-Granting Ticket (TGT), and returns it. Our contractor sees her desktop. But the KDC has a second job she does not know about. Her account is flagged "smart card required for interactive logon," so she has no password. Windows must still authenticate her to a legacy SMB1 server or any network application that speaks only NTLM. The clean answer would be "it cannot." The answer Microsoft shipped in Windows 2000 is: the KDC silently maintains an NTLM-equivalent secondary credential for every smart-card-only user, rotating it at logon, so legacy services keep working [@kb-2871997] [@msrc-kb-2871997]. That secondary credential is an NT hash. Once her session is live, an NT hash sits in the Local Security Authority Subsystem (LSASS) memory of every machine she touches. The smart card never sees it. The card cannot police it. It is sixteen bytes of MD4 output that the OS minted around the cryptographic operation the card refused to delegate. A non-NTLM-derived NT hash that Windows maintains for accounts configured to log on with a smart card or other non-password credential, so that legacy NTLM-accepting services (SMB1, pre-Windows-2000 applications, some printers) continue to authenticate the user. The hash is computed from a random secret, not the card key, and is rotated by the KDC. From a pass-the-hash attacker's perspective, it is indistinguishable from a password-derived hash and equally replayable. Three hours later, an attacker who has phished a privileged helpdesk account runs `sekurlsa::logonpasswords` from a copy of `mimikatz` [@mimikatz-gh] against the LSASS process on a server the contractor logged into earlier that day. The output looks like `NTLM : a1b2c3...`. The attacker pipes that NT hash into a `pass-the-hash` against any NTLM-accepting service in the forest. Because [RFC 4757](#) [@rfc-4757] makes the RC4-HMAC Kerberos long-term key identical to the NT hash, the attacker can also forge Kerberos pre-authentication for the smart-card-required account and request its TGT. The card sat in a reader the attacker never touched. None of that mattered. This is the inversion the article exists to explain. The card protected the key. The card did not, and could not, protect the identity. Microsoft documented the gap on May 13, 2014 as KB 2871997, "Update to improve credentials protection and management" [@kb-2871997]; the Microsoft Security Response Center followed with a blog overview of the threat model and the defence-in-depth response [@msrc-kb-2871997]. The disclosure came from Tal Be'ery and his team at Aorato, a Tel Aviv security startup Microsoft would acquire six months later. The period-accurate operator analysis lives in Sander Berkouwer's July 15, 2014 writeup, cited here because the original Aorato post is offline [@dirteam-aorato]. How did Windows arrive at an architecture where a tamper-resistant cryptographic token could leave the user's identity wide open? To answer that we go back to a 1974 patent in Paris. ## 2. How Cards Got a Chip Roland Moreno was twenty-nine when he filed his first smart-card patent family in 1974. A self-taught Parisian, a former pinball-machine fixer and humorist who had washed out of the Sorbonne, he wired an off-the-shelf microchip to a ring of contacts on a small plastic substrate and walked the result over to INPI, the French patent office. The patent family -- known in the secondary literature as `carte a memoire` -- did not invent the integrated circuit, the credit-card form factor, or even the idea of embedding silicon in plastic. What Moreno added was a property: the card holds a secret the cardholder cannot extract [@wp-moreno] [@wp-smart-card]. That property is the entire story. Helmut Groettrup, a West German engineer, got there first. He filed German patents DE1574074 and DE1574075 in February 1967 for a tamper-proof identification switch based on a semiconductor device, and added a joint Austrian filing with Juergen Dethloff in September 1968 [@bmpos-history] [@wp-smart-card]. The standard French historiography credits Moreno with the secured-memory refinement rather than the form factor. The inventor question depends on which property you treat as load-bearing. Three other people belong in this section. In 1977 Michel Ugon, an engineer at Honeywell Bull's CP8 division in France, built the first microprocessor smart card -- a card with a CPU on it, not just memory. In 1978 Bull filed the SPOM patent that collapsed CPU and EEPROM onto one chip, the architectural change that made mass production tractable [@bmpos-history] [@cnam-pdf]. And from 1987 to 1995 the International Organization for Standardization froze the card edge into a vendor-neutral wire format with the four parts of ISO/IEC 7816 [@wp-smart-card]: physical characteristics, electrical and transmission protocols, and -- the part that would matter most for Windows -- the command set. The international standard for contact smart cards, in four parts that interest software architects: Part 1 covers physical characteristics, Part 3 covers electrical interface and the T=0 and T=1 transmission protocols, and Part 4 covers the organisation, security, and command set for interchange. ISO/IEC 7816-4:2020 is the current edition of Part 4. Application Protocol Data Unit. The request/response unit a host application exchanges with a smart card. The command APDU starts with a four-byte header `CLA INS P1 P2` (class, instruction, two parameter bytes), followed by an optional length byte `Lc` and `Lc` bytes of data, and an optional expected-response-length byte `Le`. The response APDU is `[data] SW1 SW2`, where the two status word bytes encode success or a card-side error. A worked APDU example makes this concrete. To select the PIV application on a smart card, a host sends `00 A4 04 00 0B A0 00 00 03 08 00 00 10 00 01 00`. The first byte is `CLA = 00` (interindustry class). The second is `INS = A4` (SELECT). `P1 = 04` indicates that the parameter is an application identifier. `P2 = 00` selects the first occurrence. `Lc = 0B` says eleven data bytes follow, and those eleven bytes are the full PIV AID per NIST SP 800-73-4 [@sp-800-73-4-upd1]: nine bytes for the registered application identifier (`A0 00 00 03 08 00 00 10 00`) followed by the two-byte PIV application version identifier (the PIX, `01 00`, per SP 800-73-4 Part 1 §2.2). The card replies with optional file control information and the status word `90 00`, which means success. Every operation the Windows smart card stack performs decomposes, eventually, into a sequence of these short frames. timeline title Card-as-authenticator timeline 1967-1968 : Groettrup and Dethloff file IC-on-card patent 1974 : Moreno files carte a memoire family 1977-1978 : Ugon and Bull build CPU smart card and SPOM 1987-1995 : ISO/IEC 7816 parts 1, 3, 4 published 1996 : PC/SC Workgroup founded 2000 : Windows 2000 ships SCardSvr.exe 2007 : Microsoft Base Smart Card CSP and minidriver model 2011 : Windows 7 SP1 inbox PIV/GIDS minidriver 2012 : Windows 8 ships Virtual Smart Card 2015 : Windows Hello announced 2024 : NTLMv1 removed in Windows 11 24H2 By 1996 the card edge was settled. Three thousand-odd APDU specifications and proprietary applets later, the only remaining question was: how does a personal computer talk to a card reader? Smart card readers lived in two operationally incompatible worlds, the bank-teller world and the workstation world, and the workstation world was held back by a vendor-driver swamp. So in 1996 a consortium called the PC/SC Workgroup formed. The contemporary record names Microsoft, IBM, Hewlett-Packard, Sun Microsystems, Siemens Nixdorf, and Bull as founders, with Schlumberger and other card vendors joining shortly after [@wp-pcsc] [@sc-architecture]. The PC/SC specification series ("Interoperability Specification for ICCs and Personal Computer Systems") names exactly the right abstractions: a Smart Card Resource Manager that brokers access to attached readers, an Interface Device Handler that abstracts reader hardware, and a Service Provider that exposes a uniform programming surface to applications [@sc-architecture]. A personal computer talks to a smart card by speaking PC/SC, in user-mode, through whatever service the OS provides. Personal Computer/Smart Card. The 1996 industry consortium and its specification series that define how a smart card reader is exposed to a desktop operating system. PC/SC factors the stack into reader hardware (Interface Device), an Interface Device Handler driver, a Smart Card Resource Manager (a system service brokering access), and a Service Provider exposing a uniform API to applications. Microsoft answered the implementation question in February 2000 with `SCardSvr.exe`, the Smart Cards for Windows service that shipped in Windows 2000 [@sc-architecture]. And immediately created a new problem: every card vendor still wanted to own the cryptographic provider. ## 3. From SCardSvr to Base CSP: Eleven Years to a Vendor-Neutral Stack Windows 2000 shipped smart card logon as a vendor-neutral primitive. Within months, the operational reality bit. Every card vendor shipped a different CryptoAPI plug-in, every plug-in needed installing per machine, per card, sometimes per user. Walk down the stack. At the bottom is the reader, attached over USB or, in early-2000s deployments, an internal serial port. Above the reader is the Interface Device Handler driver supplied by the reader vendor. Above the driver is `SCardSvr`, Microsoft's Smart Card Resource Manager service. `SCardSvr` exposes a user-mode API called WinSCard: `SCardEstablishContext`, `SCardConnect`, `SCardTransmit`, `SCardDisconnect` [@winscard-api]. WinSCard is the C-level entry into PC/SC; an application that wants to send raw APDUs to a card uses WinSCard directly [@sc-architecture]. The Windows user-mode API surface for PC/SC. Canonical entry points include `SCardEstablishContext`, `SCardListReaders`, `SCardConnect`, `SCardTransmit`, and `SCardDisconnect`. An application sending raw APDUs to a smart card uses WinSCard; higher-level Windows components (Kerberos client, certificate enrolment, the lock-screen credential provider) reach the card indirectly through the Cryptographic Service Provider or Key Storage Provider layers. Cryptographic clients do not want to write APDU sequences. They want to call `CryptSignHash` or `NCryptSignHash` and have a signature appear. Translating those API calls into the card's APDU command set is the job of a Cryptographic Service Provider in the CryptoAPI 1.0 world and a Key Storage Provider in the [CNG (Cryptography Next Generation)](/blog/cng-architecture-bcrypt-ncrypt-ksps/) world. From 1996 to 2007, almost every card vendor wrote its own CSP. The Schlumberger CSP. The Gemalto CSP. The Axalto CSP. The ActivIdentity CSP. Each was an in-process DLL that talked to the card through WinSCard, applied vendor-specific quirks, and exposed a CSP interface to Windows. A plug-in for CryptoAPI 1.0 that provides cryptographic services (key generation, signing, hashing, key storage) to applications. CryptoAPI loads a CSP in-process. For smart cards, the CSP translates CryptoAPI calls into card-specific APDUs through WinSCard. Microsoft Base Smart Card CSP, shipped in 2007, replaced the per-vendor CSP with a single CSP that delegated card-specific behaviour to a much smaller minidriver. The CNG-era plug-in that provides key storage and asymmetric cryptographic operations. CNG separates algorithm providers (BCrypt: hashing, symmetric, signature primitives) from key storage providers (NCrypt: key lifecycle, key-protected operations). The Microsoft Smart Card Key Storage Provider is the CNG-side path for smart card and Virtual Smart Card keys; the Microsoft Platform Crypto Provider is its sibling that talks to the TPM directly. The architecture had two problems by 2003. First, an N x M combinatorial. Every new card vendor multiplied integration cost for every cryptographic application, and vice versa. Large enterprises ran two or three CSPs per workstation; subtle bugs in signature padding or PIN caching only surfaced when an application built for vendor A's CSP met a card configured for vendor B's. Second, a security problem: each CSP ran in-process with every CryptoAPI client, so a buggy or compromised third-party CSP could reach critical OS components. Microsoft's answer was the Smart Card Minidriver Specification, finalised around the Vista launch in 2006-2007. Microsoft would ship one CSP -- the Microsoft Base Smart Card CSP -- containing the cryptographic state machine common to all PIV-style cards. Per-card behaviour would live in a much smaller DLL called a minidriver, loaded by the Base CSP when it recognised the card. The specification, `dn631754`, currently maintained at v7.07, says exactly this: "The Microsoft Smart Card Base CSP and KSP is a refinement of the architecture that separates commonly needed CAPI-based CSP and CNG-based KSP functionality, respectively, from the implementation details that must change for every card vendor" [@sc-minidrivers] [@sc-minidriver-spec]. The CNG-side sibling, the Microsoft Smart Card Key Storage Provider, plugs into the same minidriver layer. CNG is the post-Vista cryptographic platform: BCrypt for algorithm primitives, NCrypt for key lifecycle and storage [@cng-storage]. The Smart Card KSP supports DH 512-4096, ECDH P256/P384/P521, ECDSA P256/P384/P521, and RSA 512-16384 [@cng-ksp-list]. Both the legacy Base CSP and the modern KSP route through the same minidriver, so a card vendor writes one DLL and gets compatibility with both CryptoAPI 1.0 and CNG applications. flowchart TD A[Reader hardware] --> B[IFD driver] B --> C[SCardSvr Smart Card Resource Manager] C --> D[WinSCard user-mode API] D --> E[Microsoft Base Smart Card CSP and Smart Card KSP] E --> F[Card minidriver DLL] F --> G[ISO 7816-4 APDU on the card] H[CryptoAPI 1.0 client] --> E I[CNG NCrypt client] --> E CryptoAPI's `CryptSignHash` walks the Base CSP; CNG's `NCryptSignHash` walks the Smart Card KSP; both end up issuing the same APDU sequence through the same minidriver to the same card. | Property | CryptoAPI Base CSP | CNG Smart Card KSP | |---|---|---| | Era | CryptoAPI 1.0, pre-Vista to present (legacy support) | CNG, Vista onward | | Entry point | `CryptAcquireContext`, `CryptSignHash` | `NCryptOpenStorageProvider`, `NCryptSignHash` | | Implementation DLL | `basecsp.dll` | `microsoft smart card key storage provider` registered through `ncrypt.dll` | | Per-card extension | Smart card minidriver | Same smart card minidriver | | Algorithm range | RSA, basic ECC | RSA, full Suite B ECC, large key ranges | By 2008 the architecture was elegant. But every PIV card still needed a minidriver acquired from somewhere -- a CD, a vendor ftp site, an enterprise distribution share. And in 2004 the US federal government was about to make the smart card mandatory for several million people who could not wait for a vendor disk. ## 4. PIV, GIDS, CAC, and the Inbox Driver That Removed the Last Install Step On August 27, 2004, President George W. Bush signed Homeland Security Presidential Directive 12, a one-page policy with one operational sentence: there shall be "a mandatory, government-wide standard for secure and reliable forms of identification issued by the federal government to its employees and contractors" [@hspd-12]. HSPD-12 did not specify how. It pointed at the National Institute of Standards and Technology and said "make it so." NIST's response was FIPS 201, the Personal Identity Verification standard, first published in February 2005. The current revision, FIPS 201-3, was published in January 2022, superseding FIPS 201-2 from 2013 [@fips-201-3] [@fips-201-3-pdf]. Where FIPS 201 specifies the credential -- what a PIV card is, biometrically, biographically, visually -- the companion NIST SP 800-73 specifies the card-edge interface: file system, data objects, APDU command set [@sp-800-73-4-upd1]. The US federal smart card identity credential defined by FIPS 201 and its companion NIST Special Publications. FIPS 201 defines what a PIV credential is; NIST SP 800-73 defines the card-edge interface (file structure, data objects, APDU command set) so any host can talk to any PIV-compliant card; SP 800-78 covers cryptographic algorithms; SP 800-76 covers biometrics; SP 800-79 covers card issuer accreditation. The numbers are striking. NIST reports "close to five million PIV Cards today provide multifactor authentication to federal IT resources and facilities" [@nist-piv-home]. The largest single cohort is the DoD Common Access Card (CAC), which by 2002 numbers had reached more than one million card readers across more than 1,000 issuance sites in more than 25 countries [@wp-cac]. Microsoft, watching from Redmond, faced two choices: negotiate a separate minidriver for the GSC-IS card-edge applet some federal agencies were using, or ship an inbox class minidriver that auto-discovered PIV-compliant cards out of the box -- and for completeness, supported a Microsoft-defined alternative called the Generic Identity Device Specification. GIDS, Microsoft's complementary card-edge profile, shipped v1.0 in April 2010 and v2.0 in October 2012 [@gids-spec]. It was a profile for card vendors and TPM integrators who wanted a Microsoft-blessed alternative to PIV, and it would become important to Windows 8's Virtual Smart Card design. The Generic Identity Device Specification, a Microsoft-published smart card profile for identity credentials. GIDS v1.0 published April 2010; v2.0 published October 2012. GIDS coexists with PIV at the inbox minidriver layer: Windows' inbox `msclmd.dll` recognises both, allowing zero-install integration for any card that implements either applet. The inbox driver shipped in Windows 7 SP1 in February 2011. Microsoft Learn is direct: "Windows provides an inbox generic class minidriver that supports Personal Identity Verification (PIV)-compliant smart cards and cards that implement the Generic Identity Device Specification (GIDS) card edge" [@inbox-minidriver]. The auto-discovery sequence is sequential: `msclmd.dll` issues a `SELECT` for the PIV AID; if the card returns `90 00`, Windows treats it as PIV. If the PIV select fails, the driver tries the GIDS AID; if that succeeds, Windows treats the card as GIDS. If both selects return a "neither-AID-exists" status, Windows still proceeds as if the card were GIDS, and the inbox driver continues to handle it. Only an unknown SELECT error makes the inbox driver decline and Windows fall back to a vendor minidriver [@inbox-minidriver]. The effect: any PIV-compliant card (CAC, Yubico YubiKey 5 [@yubico-piv], any FIPS 201-compliant federal credential) worked on a stock Windows 7 SP1 install with zero additional software. With the card-edge problem solved and the install problem closed, what remained was the protocol Windows logon would use. That protocol is PKINIT. Public Key Cryptography for Initial Authentication in Kerberos. Specified by [RFC 4556](#) [@rfc-4556] and profiled for Windows by `[MS-PKCA]` [@ms-pkca]. PKINIT lets a Kerberos client present an X.509 certificate, and prove possession of the private key, as pre-authentication for the Authentication Service Request (AS-REQ), instead of a password-derived shared secret. The Windows AS Exchange remains otherwise unchanged: the client receives a TGT encrypted with a session key established under the public-key exchange. The PKINIT structure that carries the client's proof of possession. It contains a `PKAuthenticator` (cusec, ctime, nonce, paChecksum) and Diffie-Hellman parameters. The client signs the `AuthPack` with the private key corresponding to its certificate, then embeds the signed structure in the `PA-PK-AS-REQ` pre-authentication data of the Kerberos AS-REQ. The granularity matters: the signature covers the `AuthPack`, not the AS-REQ as a whole. In a Windows smart card logon the path from PIN to TGT runs through eight named components. Walk it once and the rest of the article becomes legible. sequenceDiagram participant U as User at lock screen participant CP as Credential Provider participant LSA as LSASS Kerberos client participant KSP as Microsoft Smart Card KSP participant MD as Minidriver participant CARD as Smart card participant KDC as Domain Controller KDC U->>CP: Insert card, type PIN CP->>LSA: Logon attempt with PIV credential LSA->>KSP: NCryptSignHash on AuthPack hash KSP->>MD: Card-specific sign request MD->>CARD: VERIFY PIN, then SIGN APDU CARD-->>MD: Signed AuthPack bytes, SW=9000 MD-->>KSP: Signed AuthPack KSP-->>LSA: Signed AuthPack LSA->>KDC: AS-REQ with PA-PK-AS-REQ pre-auth KDC->>KDC: Verify signature, cert chain, freshness KDC-->>LSA: AS-REP with TGT LSA-->>CP: Logon success, session keys cached CP-->>U: Desktop Notice what the card sees and what it does not. It sees a hash to sign and a PIN to verify. It does not see "I am authenticating to KDC `DC01.contoso.local` for user `jdoe`." A PIV card is a signing oracle. The relying party identity, the freshness, the replay window, the binding of signature to context: all of that lives in the protocol above the card, not in the card itself. We come back to this in section 8. > **Key idea:** The cryptographic primitive at the centre of the smart card metaphor -- a non-exportable asymmetric key, bound to a tamper-resistant element, gated by a local gesture -- is the longest-lived object in this lineage. The interface around the primitive (PC/SC, CryptoAPI, CNG, NCrypt-direct, WebAuthn) is what changes every generation. By 2013 the cryptographic story was excellent. PKINIT was a clean Kerberos AS exchange. The card protected the key. The KDC issued a TGT. Then, in a few months in 2014, one researcher in Tel Aviv showed that the protection ended at the very moment of signing. ## 5. KB2871997 and the NTLM Secondary Credential Tal Be'ery, then Vice President of Research at Aorato, sat down in early 2014 with a question that should have had a boring answer. If an Active Directory account is flagged "smart card required for interactive logon," and the user has no password, is the account immune to pass-the-hash? The answer is no. Aorato's original disclosure post is offline; Microsoft acquired Aorato in November 2014 and the research became the foundation of what is now Microsoft Defender for Identity. The period-accurate operator analysis that survives in public is Sander Berkouwer's July 15, 2014 dirteam.com writeup, cited here in lieu of the dead original [@dirteam-aorato]. The attack is built from three off-the-shelf parts. The first is the NTLM secondary credential we met in section 1: every smart-card-only account in Active Directory has a usable NT hash on the KDC, maintained for legacy compatibility. The second is the harvesting tool. Benjamin Delpy's `mimikatz` had reached its 2.0-alpha milestone in April 2014; the README documents `sekurlsa::logonpasswords` extracting NT hashes from LSASS, plus `sekurlsa::pth` and golden-ticket forgery for replay [@mimikatz-gh]. The third is the cryptographic identity that makes hashes Kerberos-relevant. [RFC 4757](#) section 2 establishes that the RC4-HMAC long-term key in Kerberos is the NT hash itself, "for compatibility reasons" [@rfc-4757] [@dirteam-aorato]. Compose those three parts. An attacker with administrative footing on any machine the user has touched runs `sekurlsa::logonpasswords` against LSASS and gets the NT hash. By RFC 4757 the hash is a usable Kerberos RC4-HMAC pre-authentication key for the user; pre-auth is a function of the long-term key, so the attacker can request a TGT. Or they replay the hash directly via SMB. The card sits, intact, in the user's reader. Nothing about it has changed. "The smart card's tamper-resistance was real. But the cryptographic guarantee terminated at the act of signing -- not at the authentication outcome." This is the article's central inversion. The card was right. The system was wrong. The card protected the *key*; the OS minted *credentials around* that key the card could not police; the protection terminated at the signing operation; the identity did not. Given an interactive shell as Local System or a debug-privileged user, the harvest is two commands: ``` privilege::debug sekurlsa::logonpasswords ``` `sekurlsa::logonpasswords` walks LSASS sessions and prints any cached NT hashes, including the rotated secondary credential for smart-card-required users. The pass-the-hash replay is one more: ``` sekurlsa::pth /user:JaneDoe /domain:CONTOSO /ntlm:a1b2c3... ``` This launches a process whose Kerberos ticket cache accepts the supplied NT hash as the RC4-HMAC pre-auth key for the named principal. Any tool spawned from that process can request service tickets for the user. The smart card need not be in any reader on any machine on the network. KB 2871997 and the Pass-the-Hash mitigations (KB 2984972, 2984976, 2984981) addressed this defence-in-depth; NTLM removal addresses it structurally. Microsoft's response shipped on May 13, 2014 as Security Advisory KB 2871997, "Update to improve credentials protection and management." It is mostly a registry change and a recommended Group Policy: set `HKLM\SYSTEM\CurrentControlSet\Control\Lsa\TokenLeakDetectDelaySecs` to 30 seconds [@kb-2871997]. The June 2014 MSRC blog added more context, especially around a new security group called [Protected Users](/blog/who-is-allowed-to-log-in-where-the-kdc-side-answer-to-creden/) [@msrc-kb-2871997]. Protected Users, added to Windows Server 2012 R2 domains and Windows 8.1 clients, blocks NTLM, blocks DES and RC4 in Kerberos pre-authentication, blocks both forms of delegation, and prevents offline sign-in caching [@protected-users]. Add a privileged account to Protected Users and you force it off the RC4-HMAC code path. An attacker who steals the NT hash no longer has a usable Kerberos pre-auth key, even though the hash itself is still recoverable. Microsoft's later response was [Credential Guard](/blog/the-empty-hash-credential-guard-the-lsaiso-trustlet-and-the-/), which isolates credential material in a Virtualization-Based Security (VBS) container called LSAISO, separated from LSASS by a Hyper-V trust boundary. On Windows 11 22H2 and Server 2025, Credential Guard is enabled by default on domain-joined, non-DC systems that meet hardware requirements, protecting NTLM hashes, Kerberos TGTs, and stored domain credentials [@credential-guard]. > **Note:** The KB 2871997 family (TokenLeakDetectDelaySecs, Protected Users, LSA Protection / RunAsPPL, Credential Guard later) is defence-in-depth. It makes hash theft harder, the harvested hash less universally useful, and lateral movement more visible. None of those measures removes the secondary NT hash itself. The structural fix is to [remove NTLM](/blog/ntlmless-the-death-of-ntlm-in-windows/). That work began in earnest with the 2023 "evolution of Windows authentication" announcement and reached its first hard milestone with the NTLMv1 removal in Windows 11 24H2 and Windows Server 2025 [@evolution-windows-auth] [@ntlmv1-removal]. If the card alone could not deliver the protection, perhaps the right move was to throw away the *physical* card entirely. Microsoft had shipped exactly that experiment eighteen months earlier. ## 6. Virtual Smart Cards in Windows 8 On October 26, 2012, Microsoft shipped Windows 8. Buried in the new features, alongside the Start screen redesign and the Hyper-V client, was a command-line tool named `tpmvscmgr.exe` that created a smart card without any plastic. The tool is still there. Open an elevated prompt on a current Windows installation and type `tpmvscmgr create /name vsc1 /AdminKey DEFAULT /PIN PROMPT`, and the system manufactures a new entry under `ROOT\SMARTCARDREADER\` that any PC/SC client sees as a freshly inserted card [@tpmvscmgr]. The pitch is mechanical. Every Windows 8+ device with a [Trusted Platform Module](/blog/the-tpm-in-windows-one-primitive-twenty-five-years-and-the-c/) already has the cryptographic substrate of a smart card on the motherboard: a tamper-resistant chip, a non-exportable key store, dictionary-attack resistance, an isolated execution environment for crypto. Why not implement the smart card abstraction in software, with the TPM as the backing chip [@vsc-overview] [@vsc-understanding]? The Microsoft Learn "Virtual Smart Card Overview" makes the framing crisp. The three core properties of a smart card -- non-exportability, isolated cryptography, anti-hammering -- map directly onto TPM capabilities. Non-exportability becomes TPM key wrapping. Isolated cryptography becomes signing inside the TPM. Anti-hammering becomes the TPM's dictionary-attack counter [@vsc-overview] [@vsc-understanding]. A TPM-backed software smart card introduced in Windows 8 (October 2012). A VSC exposes the same PC/SC card edge as a physical card -- the same WinSCard API, the same Base CSP, the same Microsoft Smart Card KSP, the same minidriver model. The chip backing the card is the TPM, soldered to the motherboard, rather than a removable IC on a plastic substrate. From the perspective of any application using the WinSCard API, a VSC is indistinguishable from a permanently-inserted physical smart card. > **Note:** Windows 8 shipped Virtual Smart Cards in October 2012. The Trusted Computing Group did not ratify TPM 2.0 until 2014. VSCs are therefore a *TPM-binding policy* technology, not a TPM-2.0-bound technology; Microsoft Learn lists TPM 1.2 as the documented minimum. TPM 2.0 works and is the practical choice on modern Windows 11 installations, but the architecture predates it [@vsc-overview] [@vsc-understanding]. The beauty of the design is that nothing above the chip changed. Applications still call `CryptSignHash` or `NCryptSignHash`. The Base CSP and Smart Card KSP still route through a minidriver. The minidriver still sends APDUs through WinSCard to a reader. The only differences: the reader is a software pseudo-device named `Microsoft Virtual Smart Card`, and the card behind it is the TPM dressed up as an ISO 7816-4 applet. flowchart LR subgraph Physical [Physical smart card] A1[Application] --> B1[CSP/KSP] B1 --> C1[Minidriver] C1 --> D1[WinSCard] D1 --> E1[USB reader] E1 --> F1[Plastic card IC] end subgraph Virtual [Virtual smart card] A2[Application] --> B2[CSP/KSP] B2 --> C2[Minidriver] C2 --> D2[WinSCard] D2 --> E2[Virtual reader] E2 --> F2[TPM on motherboard] end The cryptographic substrate underneath the abstraction is the TPM, and the binding policy is per-device. The Microsoft Learn "Understanding and Evaluating Virtual Smart Cards" article is precise: "Non-exportability: Because all private information on the virtual smart card is encrypted by using the TPM on the host computer, it can't be used on a different computer with a different TPM" [@vsc-understanding]. The property that makes a VSC tamper-resistant also makes it un-migratable. A TPM clear destroys the keys irrecoverably. We return to that in section 8. The canonical primary source for the architecture is the "Understanding and Evaluating Virtual Smart Cards" whitepaper on the Microsoft Download Center. The download page reports `Version: July 2014, Date Published: 7/15/2024` [@vsc-whitepaper]. The 2014 revision is canonical. "The card was a metaphor. Microsoft kept the byte-for-byte PC/SC interface and put the TPM behind it." A worked provisioning example brings the design to ground. The `tpmvscmgr create` command takes four arguments that matter for security policy: the administrative key (`/AdminKey {DEFAULT | PROMPT | RANDOM}`), the PIN policy (`/PIN PROMPT` or `/PIN DEFAULT`), the attestation mode (`/attestation {AIK_AND_CERT | AIK_ONLY}`), and the card's reader instance, surfaced under `ROOT\SMARTCARDREADER\000n` in Device Manager [@tpmvscmgr]. {` function provisionVSC(opts) { const adminKeyMap = { DEFAULT: '0102030405060708' + '0102030405060708' + '0102030405060708', PROMPT: '[user-supplied 48 hex chars]', RANDOM: '[random 24-byte key the admin must record]', }; const attestationNote = { AIK_ONLY: 'Identity-binding only; no platform certificate chain stored on the card.', AIK_AND_CERT: 'Full AIK-and-EK-cert chain stored; supports federated re-enrolment.', NONE: 'No attestation; the card is identity-only.', }; return { cardName: opts.name, adminKey: adminKeyMap[opts.adminKey] || 'invalid', pin: opts.pin === 'PROMPT' ? '[user-typed PIN, min 8 chars, alphanumeric+special allowed]' : '12345678', attestation: attestationNote[opts.attestation || 'NONE'], advice: opts.adminKey === 'DEFAULT' ? 'WARN: default admin key is documented; treat as factory-default.' : 'OK: admin key not factory-default.', }; } console.log(provisionVSC({ name: 'vsc-jdoe', adminKey: 'RANDOM', pin: 'PROMPT', attestation: 'AIK_AND_CERT', })); `} The default administrative key `010203040506070801020304050607080102030405060708` is documented in the public `tpmvscmgr` page [@tpmvscmgr]. Any VSC provisioned with `/AdminKey DEFAULT` should be treated as factory-default; in production, supply (`PROMPT`) or randomise (`RANDOM`) the admin key and store it separately. The provisioning chain has four hard-to-script steps: run `tpmvscmgr create` as administrator; request and install an authentication certificate from a PKI the domain trusts (typically Microsoft Certificate Services with an enterprise CA and a smart card auto-enrolment template); set the user PIN; log the user out and back in. Each step is a place an enterprise rollout can stall. > **Key idea:** Microsoft kept the PC/SC card edge byte-for-byte and put the TPM behind it. The Virtual Smart Card was, technically, exactly that: a software smart card whose chip happened to be soldered to the board. The cryptographic primitive at the centre did not change; only the form factor of the chip carrying it did. VSCs solved the physical-distribution problem. They did not solve the user-experience problem -- and they introduced a new one no Windows feature had ever produced quite this way: a credential a hardware reset could permanently destroy. ## 7. WHfB, FIDO2, and the Card Edge That Got Discarded On March 17, 2015, Joe Belfiore announced [Windows Hello](/blog/your-face-is-not-your-password-inside-windows-hellos-hardwar/) on the Windows Experience Blog: "I'd like to introduce you to Windows Hello -- biometric authentication which can provide instant access to your Windows 10 devices" [@windows-hello-blog]. The consumer pitch was face and fingerprint. The mechanism underneath, in the enterprise variant called Windows Hello for Business (WHfB), was the same TPM-bound asymmetric key the Virtual Smart Card had used -- except there was no virtual reader, no virtual minidriver, and no virtual APDU. WHfB talks to the TPM directly through the Microsoft Platform Crypto Provider, a CNG Key Storage Provider that calls into the TPM rather than into a smart card minidriver [@whfb-overview] [@whfb-how-it-works]. The PC/SC card edge had been removed from the path entirely. The cryptographic primitive (non-exportable TPM-bound asymmetric key, gated by a local gesture, used to sign an authentication request) survived; the interface around the primitive simplified. Microsoft Learn describes WHfB in five phases: device registration, provisioning, key synchronisation, certificate enrolment (cert-trust only), authentication. The public key is registered with the identity provider and mapped to the user account; the private key never leaves the device [@whfb-how-it-works]. WHfB ships in three deployment models -- cloud-only, hybrid, on-premises -- and two trust types: key-trust and cert-trust [@whfb-deploy]. Key-trust is cloud-first. The TPM-bound public key is registered with Microsoft Entra ID; authentication is a public-key proof of possession to Entra, which mints whatever downstream artifacts a federated service needs (PRT, refresh token, optional Kerberos TGT via the cloud Kerberos service). No X.509 certificate sits in the user's path. Cert-trust adds an X.509 wrapper for downstream services that require one: an enterprise PKI issues a smart-card-logon-style certificate bound to the TPM key, and the WHfB authentication produces a Kerberos PKINIT exchange against an on-premises DC, just as a physical smart card would. The certificate is the adapter to brownfield infrastructure that still expects a smart-card-shaped credential [@whfb-deploy]. So far the lineage has been Windows-specific. [FIDO2](/blog/webauthn-and-passkeys-on-windows-from-ctap-to-the-credential/) is not. WebAuthn 2 is a W3C Recommendation; CTAP 2.1 is a FIDO Alliance specification [@webauthn-2] [@ctap-2-1]. Together they specify a cross-vendor protocol for public-key authentication to web relying parties, with one load-bearing property the smart card lineage never had: origin binding. The property that a WebAuthn credential is scoped to a specific relying party identifier (the RP ID, typically a domain name) and the authenticator will refuse to sign an assertion for any other RP ID. The W3C WebAuthn 2 specification states: "the public key credential can only be accessed by origins belonging to that Relying Party. This scoping is enforced jointly by conforming User Agents and authenticators" [@webauthn-2]. A PIV smart card has no equivalent property; it will sign whatever the host hands it. Origin binding is the structural fix to a class of relay attacks. A PIV smart card cannot tell whether it is signing a Kerberos AuthPack for the legitimate KDC or a maliciously crafted blob for an attacker-controlled relay; the card has no notion of "what is this signature for." A WebAuthn authenticator does. It hashes the RP ID into the signed assertion, the relying party verifies the RP ID matches its own origin, and a phishing site cannot trick the authenticator into producing a signature it will accept. Microsoft Entra ID supports FIDO2 in two flavours. *Device-bound passkeys* live on a FIDO2 security key (a YubiKey 5 [@yubico-piv]) or in Microsoft Authenticator and cannot be extracted. *Synced passkeys* are credentials a platform synchronises across the user's devices through a cloud passkey provider [@entra-passkeys-howto] [@entra-passwordless]. The trade-off is sharp: device-bound passkeys support attestation (the relying party can verify authenticator hardware at registration); synced passkeys do not. For workforce identity, Microsoft's passwordless strategy describes a four-step journey: deploy a password-replacement option, reduce user-visible password surface, transition to passwordless, eliminate passwords [@passwordless-strategy]. WHfB and FIDO2 are the two recommended replacements. What about smart cards? The Microsoft Learn Virtual Smart Card Overview now opens with a Warning box that reads, in full: "Windows Hello for Business and FIDO2 security keys are modern, two-factor authentication methods for Windows. Customers using virtual smart cards are encouraged to move to Windows Hello for Business or FIDO2. For new Windows installations, we recommend Windows Hello for Business or FIDO2 security keys" [@vsc-overview]. The deprecation signal could not be more explicit. Physical PIV and CAC cards are not deprecated -- the federal government is not switching off PIV -- but the structural recommendation for greenfield is now WHfB or FIDO2. Why did Virtual Smart Cards not survive into the WHfB era? Three reasons. The first is provisioning UX. A VSC requires four steps (`tpmvscmgr create`, certificate enrolment, PIN set, logon round-trip) where WHfB requires one (a setup wizard the user runs at first sign-in). Each VSC step can fail in idiosyncratic ways: the enterprise CA template not configured for VSCs, the user's certificate request rejected, the PIN policy mismatched between the GPO and the card. Even when every step succeeds, the user sees a "smart card" UI -- card reader prompts, PIN entries -- that does not match the device they are holding. The second is recovery. A TPM clear destroys VSC keys irrecoverably. Microsoft Learn states the constraint plainly [@vsc-understanding]: "all private information on the virtual smart card is encrypted by using the TPM on the host computer." Recovery would have to be re-enrolment under a federated attestation chain. The AIK-and-EK-cert attestation mode in `tpmvscmgr` exists [@tpmvscmgr], but it never grew into a productised re-enrolment story; the practical answer was always "issue a new card." The third is the multi-device world. VSCs bind one credential to one device. By 2017 most enterprise users had at least two devices: a laptop and a phone. By 2022 most had three. A credential metaphor borrowed from the era of one workstation per user could not stretch. Where do physical smart cards still belong in 2026? Three places. First, federal PIV / DoD CAC: the badge IS the credential, the issuance lifecycle is owned by an external organisation, and the cards have to work cross-platform and cross-application in a way a Windows-only credential cannot. Second, high-assurance regulated industries (banking, healthcare imaging, court systems) where existing PKI investment and signed-document workflows make the card the institutional artifact, not just an authentication factor. Third, "smart card removal locks workstation" cases (operating-room PCs, trading-floor terminals) where the physical act of pulling the card out of the reader is the security control. Where does Entra Certificate-Based Authentication fit? Entra CBA is the cloud-native PIV/CAC path. A federal user logs into Entra ID directly with their PIV/CAC card, bypassing the on-premises ADFS infrastructure that was the traditional cloud-bridge for federal organisations. Entra CBA preserves the PIV credential while replacing the on-premises STS, and is the practical answer to "we have to keep PIV, but also we are migrating to cloud." The table below condenses the comparison. | Method | Where the key lives | Origin binding | NTLM secondary | Provisioning steps | Multi-device | Phishing resistance | Recovery | Suitable for new deployments | |---|---|---|---|---|---|---|---|---| | Physical PIV / CAC | Removable IC | No (relay possible) | Yes (until NTLM removed) | High (PKI + issuance) | Yes (cross-device by physical movement) | Conditional | Re-issue card | Federal/DoD only | | TPM Virtual Smart Card | On-device TPM | No | Yes (until NTLM removed) | High (4-step) | No (bound to one TPM) | Conditional | Re-enrol | Not recommended (deprecation Warning) | | WHfB key-trust | On-device TPM | Limited (RP=Entra) | Reduced (cloud Kerberos) | Low (in-OS wizard) | Per-device enrolment | Yes (relative) | Re-enrol via device registration | Yes (cloud/hybrid) | | WHfB cert-trust | On-device TPM | Limited (RP=AD) | Yes (until NTLM removed) | Medium (PKI required) | Per-device enrolment | Conditional | Re-enrol; CA-issued cert | Yes (brownfield PKI) | | FIDO2 security key | External authenticator (e.g., YubiKey) | Yes (WebAuthn RP ID) | Not applicable (no Kerberos) | Low | Yes (key is portable) | Yes (origin-bound) | Spare key or backup credential | Yes (high-assurance) | | Entra device-bound passkey | TPM or external authenticator | Yes (WebAuthn RP ID) | Not applicable | Low | Per-device | Yes | Re-enrol | Yes | | Entra synced passkey | Cloud-synced (no attestation) | Yes (WebAuthn RP ID) | Not applicable | Low | Yes (cloud-synced) | Yes (origin-bound) | Cloud provider recovery | Yes (consumer, low-friction) | The architecture is now mature. But the lineage has a hard ceiling no architecture can cross: a signing oracle cannot tell you what it signed *for*. ## 8. What a Card Edge Can and Cannot Mediate Set aside provisioning UX. Set aside NTLM legacy. Set aside everything Windows-specific. What are the *structural* limits any card-edge-or-equivalent design must accept? Six, by my count, and each one is anchored to a primary source. **The card edge is a signing oracle, not a transcript witness.** A PIV card receives a hash and returns a signature. It does not know what protocol the signature is for, what relying party requested it, or whether the same hash has been requested two minutes ago by an attacker on a wireless network. PKINIT's vulnerability to relay was open from 2006 (RFC 4556) until 2017 (RFC 8070, which added a freshness token to the AS exchange) [@rfc-4556] [@rfc-8070]. The fix had to live in the *protocol*, not in the card. The card cannot prove what it signed *for*. **The card has no notion of relying-party identity.** This is the structural defect WebAuthn fixes. A WebAuthn authenticator includes the RP ID in the signed assertion and refuses to release a signature for the wrong RP. The W3C specification states this property explicitly [@webauthn-2]. A PIV card does not. To add an equivalent property to the smart card lineage would have meant changing the SP 800-73 command set; it was easier to throw the PC/SC card edge away and start over with FIDO2. **Cryptographic protection at the card edge cannot reach downstream OS-minted credentials.** This is the 2014 NTLM-secondary lesson at its most general. The card protects a key; the OS may mint credentials around that key the card cannot police. Microsoft KB 2871997 closed the leak with defence-in-depth retrofits (TokenLeakDetectDelaySecs, Protected Users, RunAsPPL, eventually Credential Guard) [@kb-2871997] [@msrc-kb-2871997] [@protected-users] [@credential-guard]; the structural close had to wait for the 2024-2026 NTLM removal programme [@ntlmv1-removal]. Any future credential the OS mints around the card's key is, by construction, outside the card's authority. **Revocation must be reachable, and the card cannot tell you when it is not.** A PIV card's certificate is a relying-party-side concept; revocation status is a property of the issuing PKI, not the card. CRL distribution points and OCSP responders are the relying party's problem to reach. When a domain controller cannot reach the CRL, the policy choice is to fail open or fail closed; either policy carries risk. The `[MS-PKCA]` Windows profile specifies server-side certificate-validation processing -- including revocation checking -- as a property of the KDC, not the credential the card presented [@ms-pkca]. The card signed correctly either way. **Certificate-to-user mapping must be strongly bound, and again the card cannot help.** When a domain controller receives a PKINIT request, it must map the presented certificate to an Active Directory account. The Certifried CVE class disclosed in May 2022 (CVE-2022-26923, CVE-2022-26931, CVE-2022-34691) showed that weak mapping -- by Subject Alternative Name UPN without a strong identifier bound into the certificate -- lets an attacker who can enrol against an over-permissive template impersonate any account [@kb-5014754]. The card signed exactly what it was asked to sign; the structural defect was at the KDC's mapping step. Microsoft KB 5014754 closed the mapping defect by requiring strong certificate-to-account binding; we return to its multi-year deployment timeline in §9 [@kb-5014754]. **Hardware-bound keys cannot be teleported -- and this is both feature and limit.** Non-exportability is the central promise of the entire lineage. It is also the bound. A TPM clear or a hardware replacement destroys the key. The recovery story has to be re-enrolment, not restore. Microsoft Learn states the constraint for VSCs and the same constraint applies, structurally, to every TPM-bound or external-authenticator credential -- including FIDO2 device-bound passkeys [@vsc-understanding]. Synced passkeys recover this property by giving up attestation; you cannot have both. "Non-exportability is the property. It is also the bound." > **Key idea:** An ideal card-lineage authenticator refuses to sign without RP-issued freshness, refuses to release a signature outside its RP scope, leaves no downstream-cacheable credential material, attests to its hardware at registration, and supports identity portability via re-enrolment-under-attestation rather than key portability. No shipping authenticator delivers all five of these authenticator-side properties in a workforce-grade product today; the two RP-side limits (revocation reachability, certificate-to-user mapping) are necessarily closed at the relying party, not the authenticator. The combination is the work of the next decade. | Limit | What it forbids | Primary source | |---|---|---| | Signing oracle, not transcript witness | Card cannot prove signature was for the intended protocol context | RFC 4556 / RFC 8070 [@rfc-4556] [@rfc-8070] | | No RP identity | Card cannot refuse a relay; relay window must close in protocol | WebAuthn 2 [@webauthn-2] | | No reach to downstream OS credentials | Card protects key, not identity around the key | KB 2871997, MSRC [@kb-2871997] [@msrc-kb-2871997] | | Revocation is not self-asserting | Card cannot vouch for its own validity; KDC must reach the PKI | [MS-PKCA] [@ms-pkca] | | Strong cert-to-user mapping is not card-asserted | Relying party must bind certificate to AD account; card has no view of the mapping | KB 5014754 [@kb-5014754] | | Non-exportability bounds portability | Key dies with the chip; recovery must be re-enrolment | VSC Understanding [@vsc-understanding] | Some limits are being closed. The signing-oracle limit is mitigated by RFC 8070 freshness tokens; the RP-identity limit is closed for new credentials by WebAuthn; the downstream-credential limit is being closed by NTLM removal; the strong-mapping limit was closed by KB 5014754 on shipping AD infrastructure between February and September 2025. Others are inherent: a non-exportable key is, by definition, not portable. The next decade of smart-card-lineage work is being shaped by which is which. ## 9. Open Problems for the Next Decade Five problems are still open in 2026. Each has a candidate fix in flight; none has shipped to general availability for the workforce case. **PIV / CAC in a post-NTLM Windows estate.** NTLMv1 was removed from Windows 11 24H2 and Windows Server 2025 [@ntlmv1-removal]; NTLMv2 is on the deprecation track [@deprecated-features]. What does "smart card required for interactive logon" *mean* in a forest with no NTLMv1 secondary credential? The historical answer was "the KDC mints an NT hash so legacy services keep working." The new answer must be either "no NT hash; legacy services break" or "an NT hash for NTLMv2 only, restricted by SCRIL rotation and Protected Users membership." Microsoft has not yet published a complete blueprint for what federal PIV deployments look like after NTLMv2 also retires. Credential Guard's role in the transition is to make any residual secondary credential harder to harvest [@credential-guard] [@protected-users]. **The recovery primitive that never shipped.** TPM-clear or device replacement destroys TPM-bound keys; this is the cost of non-exportability. AIK-and-EK-cert attestation in `tpmvscmgr` could in principle support federated re-enrolment with strong proof of platform identity [@tpmvscmgr], and the Entra passkey enrolment flow supports attestation-required policies [@entra-passkeys-howto], but neither path matured into a "your VSC died; here is how the help desk restores you in fifteen seconds" story. Synced passkeys recover this property by giving up attestation. Workforce-grade attestation *and* easy recovery, together, is still not shipping. **The certificate-based-authentication hardening lag.** Microsoft's KB 5014754 hardens certificate-based authentication on Windows domain controllers against the Certifried CVE class (CVE-2022-26923, CVE-2022-26931, CVE-2022-34691) by requiring strong certificate-to-user mapping at the KDC. The CVE class was disclosed on May 10, 2022. The mitigation moved DCs to Enforcement mode by default on February 11, 2025, with a fallback to Compatibility mode still available; the override was finally retired on September 9, 2025 [@kb-5014754]. The KB's own change log records several intermediate slips of the Full-Enforcement target (the original commitment was a 2023 milestone, slipping to February 2025 and then to September 2025) [@kb-5014754]. That is roughly three years from CVE disclosure to default Enforcement and a further seven months to end-of-override on shipping infrastructure -- and the gap from the *first published* Full-Enforcement target to the actual end-of-override stretches the slip to a multi-year story in its own right. The lesson is sobering: in a brownfield estate, the time from "CVE disclosed" to "hardening fully enforced on every domain controller" is measured in *years*, not weeks. Separately, RFC 8070 PKINIT freshness tokens (February 2017) are a *different* hardening programme [@rfc-8070]; Windows has not deployed RFC 8070 freshness as the default in the broad estate, and the article's RunnableCode in §10 illustrates the freshness exchange rather than documenting deployed Windows behaviour. Any protocol-level fix to the smart-card lineage in 2026 will, on the KB 5014754 evidence, take three to four years to land -- and longer if the standards process itself slips, as RFC 8070's still-undeployed status (over nine years since publication) suggests. **Cross-platform card-edge longevity.** OpenSC and pcsc-lite still implement NIST SP 800-73 on macOS and Linux; the cross-platform PIV story works for basic logon. But the modern features Windows keeps adding -- attestation chains, device-bound credential extensions, integration with the Entra passkey APIs -- lag on the open-source side. Whether PC/SC outlives the platforms that built it is genuinely uncertain. Some federal organisations will keep PIV alive cross-platform as policy; many private-sector deployments will quietly move off. **Post-quantum signature algorithms on smart cards.** PIV's current baseline is RSA-2048 and ECDSA P-256 -- not post-quantum resistant. NIST's post-quantum standardisation selected ML-DSA (Module Lattice DSA, formerly Dilithium) and SLH-DSA (Stateless Hash-Based DSA, formerly SPHINCS+); both have key and signature sizes substantially larger than RSA-2048 or ECDSA P-256, and both will stress the storage and bandwidth budgets of a typical PIV card. SP 800-73-4 has no slots for post-quantum keys today [@sp-800-73-4-upd1] [@fips-201-3]. A future revision will have to accommodate them, and the existing population of $\approx$ five million PIV cards [@nist-piv-home] will not all be PQ-capable at once. The transition runs on a card-issuance cycle: roughly $T_{\text{transition}} \approx T_{\text{issuance}} + T_{\text{rollout}}$, each term in the multi-year range. Architecture is a question about which problems your design *cannot* solve. The next section is for the architect who has to choose right now, with all five problems still open. ## 10. Choosing Between PIV, VSC, WHfB, and FIDO2 in 2026 Four operator-grade callouts. Pick the one that matches your context. > **Note:** Stay on PIV / CAC for the foreseeable future. FIPS 201-3 is the current standard and SP 800-73 the current card-edge interface; policy mandates are not changing on a tactical timeline [@fips-201-3] [@nist-piv-home]. Add Entra Certificate-Based Authentication for cloud workloads so the same PIV card authenticates to Microsoft 365 and Azure resources without going through on-premises ADFS. For the three operational controls -- Credential Guard, Protected Users membership for privileged accounts, and NTLMv1-removal status -- see the federal-IT checklist in the §9 Aside. Do not rely on the smart card alone to defeat NTLM-secondary-credential abuse until NTLM removal has reached your environment. > **Note:** Pick WHfB key-trust if you are cloud-first or hybrid, cert-trust if you have an existing on-premises PKI you need to honour [@whfb-deploy] [@whfb-how-it-works]. Add FIDO2 security keys for the populations that need cross-device portability or strict phishing resistance: contractors, executives, IT administrators, anyone whose credential theft would be catastrophic [@webauthn-2] [@passwordless-strategy]. Do not pick Virtual Smart Cards for new deployments; the Microsoft Learn VSC Overview deprecation Warning quoted verbatim in §7 applies [@vsc-overview]. > **Note:** Continue to operate it but plan migration to WHfB. Audit your recovery and re-enrolment process: a TPM clear destroys VSC keys irrecoverably, so any disaster-recovery plan that assumes you can move a credential between devices is wrong [@vsc-understanding]. Do not assume your VSC deployment is "supported" the way it was in 2014; the deprecation Warning quoted in §7 applies here [@vsc-overview]. The cleanest exit path is to enrol the same users into WHfB cert-trust against your existing PKI, then retire the VSC layer once the WHfB credential is operational. > **Note:** FIDO2 security keys with attested device-bound credentials [@webauthn-2] [@ctap-2-1], paired with Microsoft Entra ID passkeys. Use attestation-required profiles for high-assurance populations (so the relying party can verify the authenticator hardware) and attestation-optional profiles for less sensitive populations who benefit from synced-passkey recovery [@entra-passkeys-howto] [@entra-passwordless]. The trade-off remains: device-bound passkeys are attestable but not portable; synced passkeys are portable but not attestable. Match the profile to the population, not the population to the profile. For the architect who wants to see how PKINIT freshness enforcement would work if the RFC 8070 extension were enforced, the JavaScript below simulates the nonce check. The KDC issues a freshness token; the client includes it in the signed `PKAuthenticator`; the KDC verifies that the token in the signed structure matches the one it issued. This is illustrative protocol behaviour, not the Windows default today. {` function kdcIssueFreshness() { const token = Math.random().toString(16).slice(2, 18); return { token, issuedAt: Date.now() }; } function clientSignAuthPack({ freshness, cardSign }) { const pkAuthenticator = { cusec: 0, ctime: Date.now(), nonce: Math.floor(Math.random() * 1e9), freshness: freshness.token, paChecksum: 'sha256-of-paData', }; const signature = cardSign(JSON.stringify(pkAuthenticator)); return { pkAuthenticator, signature }; } function kdcVerify({ pkAuthenticator, signature }, issued) { const tooOld = Date.now() - issued.issuedAt > 5 * 60 * 1000; if (tooOld) return { ok: false, reason: 'freshness token too old' }; if (pkAuthenticator.freshness !== issued.token) { return { ok: false, reason: 'freshness token does not match' }; } return { ok: true }; } const issued = kdcIssueFreshness(); const cardSign = (msg) => 'sig(' + msg.length + ')'; const signed = clientSignAuthPack({ freshness: issued, cardSign }); console.log('Honest client:', kdcVerify(signed, issued)); const replayed = { ...signed, pkAuthenticator: { ...signed.pkAuthenticator, freshness: 'stale-token-1234' } }; console.log('Replayed with stale token:', kdcVerify(replayed, issued)); `} Whichever method you choose, no method alone defeats the legacy compatibility surfaces the card was never designed to police. The structural fix lives in the protocol-removal programme finishing through 2026 and beyond. ## 11. Frequently Asked Questions Yes functionally and cryptographically; no physically. A VSC exposes the same PC/SC card edge, Microsoft Smart Card KSP, and minidriver model as a physical card. Above the minidriver layer, every Windows component sees it as a smart card. Tamper-resistance comes from the host TPM rather than a removable IC; Microsoft Learn lists TPM 1.2 as the documented minimum -- VSCs predate TPM 2.0 [@vsc-overview] [@vsc-understanding]. No, by construction. The card signs internally and returns the signature. The only material that leaves during normal operation is the signed output (or, for key exchange, an unwrapped symmetric session key the card has decrypted with the wrapping key). The private key is generated on-card during enrolment and cannot be extracted; that property is the load-bearing security claim of the entire lineage. Legacy NTLM compatibility. Many pre-Windows-2000 services speak only NTLM, and accounts flagged "smart card required for interactive logon" must still authenticate to them. KB 2871997 (May 13, 2014) added auto-rotation of the secondary credential at logon, reducing but not eliminating the attack surface [@kb-2871997]. The structural fix is NTLM removal: NTLMv1 has now been removed in Windows 11 24H2 and Windows Server 2025 [@ntlmv1-removal]. Yes. The YubiKey 5 series exposes a PIV applet that the inbox `msclmd.dll` minidriver recognises out of the box [@yubico-piv] [@inbox-minidriver]. Insert the YubiKey and Windows treats it as a PIV-compliant smart card; the same enrolment, PKINIT, and lock-screen workflows apply. The YubiKey 5 can act as a FIDO2 authenticator concurrently, which is the practical way to bridge smart-card and origin-bound passkey workflows on the same device. Conditionally. PKINIT signs an `AuthPack` containing a nonce and a paChecksum; with the RFC 8070 freshness extension and a correctly validated KDC certificate, an attacker cannot trivially replay or relay an `AuthPack` signed by the client's smart card [@rfc-4556] [@rfc-8070]. But PKINIT is not origin-bound in the WebAuthn sense -- the card has no notion of which KDC the signature is for. If a trust assumption fails (an attacker plants a certificate in the client's NTAuth store, for example), the card will happily sign for the wrong KDC. WebAuthn's RP-ID-bound assertion is a stronger guarantee [@webauthn-2]. See the §6 Callout "VSCs predate TPM 2.0" for the full timeline. TPM 1.2 is the documented minimum; TPM 2.0 is the practical choice on Windows 11, which itself requires TPM 2.0 for the OS [@vsc-overview]. Three reasons, all expanded in §7: provisioning UX, TPM-clear recovery, and the multi-device world. Windows Hello for Business delivered the same TPM-bound-key benefits without the PC/SC abstraction cost (no virtual reader, no virtual minidriver, no APDU layer); FIDO2 then added cross-device portability and origin binding, neither of which the VSC architecture could deliver. The Microsoft Learn VSC Overview deprecation Warning quoted verbatim in §7 makes the recommendation explicit [@vsc-overview] [@passwordless-strategy]. Both are CNG Key Storage Providers. The Smart Card KSP routes calls through the minidriver to either a physical card or a TPM VSC; the cryptographic operation is APDU-encoded and sent to the card. The Platform Crypto Provider routes calls directly to the TPM via TPM Base Services; there is no card abstraction in the path. Windows Hello for Business uses the Platform Crypto Provider for TPM-bound key operations [@cng-ksp-list] [@whfb-how-it-works]. The card was always a metaphor. The cryptographic primitive at its centre -- a non-exportable asymmetric key, bound to a tamper-resistant element, gated by a local gesture -- is the longest-lived object in this lineage. Every generation transition (PC/SC -> CryptoAPI/CNG -> inbox PIV/GIDS -> Virtual Smart Card -> WHfB -> FIDO2) was a transition of the *interface around* that primitive, not of the primitive itself. The May 2014 contractor whose CAC signed the right blob and lost her account anyway was the canary; the fix she needed was not on her card but in a decade-long programme to remove the OS-minted secondary credentials that lived outside the card's authority. Windows is most of the way through that programme now. The card that wasn't a card outgrew its metaphor -- and the protection it always promised is, finally, arriving at the authentication outcome.