The Card That Wasn't a Card: How Windows Authentication Outgrew the Smart Card Metaphor

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 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 ^{[1] [2]}.

How is that even possible? Hold that question. The answer is the spine of this article.

The protocol that ran when she logged in is PKINIT, defined by RFC 4556 ^[3] and profiled for Windows in [MS-PKCA] ^[4]. 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 ^{[3] [4]}.

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 ^{[2] [5]}.

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.

Three hours later, an attacker who has phished a privileged helpdesk account runs sekurlsa::logonpasswords from a copy of mimikatz ^[6] 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 ^[7] 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" ^[2]; the Microsoft Security Response Center followed with a blog overview of the threat model and the defence-in-depth response ^[5]. 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 ^[1].

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 ^{[8] [9]}.

That property is the entire story.

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 ^{[10] [11]}. 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 ^[9]: physical characteristics, electrical and transmission protocols, and -- the part that would matter most for Windows -- the command set.

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 ^[12]: 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 ^{[13] [14]}.

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 ^[14]. A personal computer talks to a smart card by speaking PC/SC, in user-mode, through whatever service the OS provides.

Microsoft answered the implementation question in February 2000 with SCardSvr.exe, the Smart Cards for Windows service that shipped in Windows 2000 ^[14]. 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 ^[15]. WinSCard is the C-level entry into PC/SC; an application that wants to send raw APDUs to a card uses WinSCard directly ^[14].

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) 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.

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" ^{[16] [17]}.

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 ^[18]. The Smart Card KSP supports DH 512-4096, ECDH P256/P384/P521, ECDSA P256/P384/P521, and RSA 512-16384 ^[19]. 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.

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" ^[20]. 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 ^{[21] [22]}. 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 ^[12].

The numbers are striking. NIST reports "close to five million PIV Cards today provide multifactor authentication to federal IT resources and facilities" ^[23]. 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 ^[24].

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 ^[25]. 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 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" ^[26]. 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 ^[26]. The effect: any PIV-compliant card (CAC, Yubico YubiKey 5 ^[27], 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.

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.

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

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 ^[6]. 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" ^{[7] [1]}.

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.

privilege::debug
sekurlsa::logonpasswords

sekurlsa::pth /user:JaneDoe /domain:CONTOSO /ntlm:a1b2c3...

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 ^[2]. The June 2014 MSRC blog added more context, especially around a new security group called Protected Users ^[5].

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 ^[28]. 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, 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 ^[29].

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

The pitch is mechanical. Every Windows 8+ device with a Trusted Platform Module 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 ^{[33] [34]}?

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 ^{[33] [34]}.

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

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

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 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" ^[36]. 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 ^{[37] [38]}. 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 ^[38]. WHfB ships in three deployment models -- cloud-only, hybrid, on-premises -- and two trust types: key-trust and cert-trust ^[39].

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

So far the lineage has been Windows-specific. FIDO2 is not. WebAuthn 2 is a W3C Recommendation; CTAP 2.1 is a FIDO Alliance specification ^{[40] [41]}. 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.

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 ^[27]) 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 ^{[42] [43]}. 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 ^[44]. 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" ^[33]. 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 ^[34]: "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 ^[32], 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.

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) ^{[3] [45]}. 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 ^[40]. 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) ^{[2] [5] [28] [29]}; the structural close had to wait for the 2024-2026 NTLM removal programme ^[31]. 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 ^[4]. 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 ^[46]. 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 ^[46].

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 ^[34]. Synced passkeys recover this property by giving up attestation; you cannot have both.

"Non-exportability is the property. It is also the bound."

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.

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 ^[31]; NTLMv2 is on the deprecation track ^[47]. 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 ^{[29] [28]}.

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 ^[32], and the Entra passkey enrolment flow supports attestation-required policies ^[42], 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 ^[46]. 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) ^[46]. 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 ^[45]; 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 ^{[12] [21]}. A future revision will have to accommodate them, and the existing population of $\approx$ five million PIV cards ^[23] 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.

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#

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.