Physical vs Virtual Smart Cards: Choosing Your Next Step Off Smart Cards

Organisations still running smart card logon face a three-way decision, keep physical cards, move to TPM virtual smart cards, or move to Windows Hello for Business and passkeys, and the wrong choice either breaks a PIV mandate or locks in a technology the platform vendor is steering customers away from. This guide compares the three on key protection, portability, attestation, PIN and lockout behaviour, administration and break-glass use, and sets out when each is the right answer. It is for identity architects and Windows platform teams who already run certificate-based logon. How PIV cards, readers and smart card logon work is covered in the Smart Card and PIV/CAC Authentication Guide and Windows Hello deployment in the Windows Hello for Business Guide; this page links to them rather than repeating them. Microsoft documentation was checked on 14 November 2026.

Key takeaways

• Short answer: keep physical cards where a PIV or CAC credential is mandated, for shared workstations and for privileged and break-glass accounts; treat virtual smart cards as a bridge at most; and plan new deployments on Windows Hello for Business or device-bound passkeys.
• Microsoft steers customers away from virtual smart cards. Its virtual smart card documentation encourages existing customers to move to Windows Hello for Business or FIDO2 and recommends those methods for new Windows installations. As of 14 November 2026 the feature does not appear on the Windows deprecated features list, so this is a direction of travel, not a published removal date.
• Both card types keep the private key non-exportable, but in different places. A physical card holds keys in the card's own secure memory; a virtual smart card stores keys encrypted on disk so they can only be used inside the device's TPM.
• Portability cuts both ways. A physical card moves between machines, so it suits shared and admin workstations; a virtual smart card is bound to one device, so each device needs its own credential and certificate.
• Attestation is where the modern options pull ahead. Windows Hello for Business can require a hardware TPM and use TPM attestation at provisioning, and device-bound passkeys can be restricted to attested authenticator models; a virtual smart card created by hand carries no proof of where its key lives.

The three options in plain terms

• Physical smart card: a card (or USB token with a smart card chip) that generates and holds private keys, performs signing internally and releases only results. For federal employees and contractors the card is the PIV Card defined by FIPS 201-3, published in January 2022; the Department of Defense equivalent is the CAC. A reader is required unless the token is USB.
• TPM virtual smart card (VSC): a Windows feature that lets the TPM mimic a permanently inserted smart card. Microsoft describes the TPM as becoming something the user has, still protected by a PIN. Applications and Windows logon see it as a smart card, so existing certificate templates, Kerberos PKINIT and smart card policies keep working.
• Windows Hello for Business (WHfB) and passkeys: an asymmetric key pair bound to the device, unlocked by a PIN or biometric, registered with the identity provider. WHfB can run with key trust, Kerberos cloud trust or certificate trust; device-bound passkeys on security keys or authenticator apps extend the same model to web and cloud sign-in. See the Windows Hello for Business Guide and the Passkeys vs Hardware Security Keys.

Side-by-side comparison

The physical and virtual rows draw on Microsoft's own comparison of the two card types; the third column reflects Windows Hello for Business documentation.

Key protection in depth

Physical card

The card generates keys on chip and performs private key operations internally. Its threat model is mostly about the card leaving the user's control and PIN capture: a keylogger can record the PIN, and malware on a machine with the card inserted can ask the card to sign while it is present (ATT&CK T1111 Multi-Factor Authentication Interception). The card's hard block after repeated wrong PINs stops guessing even when the card is stolen, at the cost of help desk resets.

Virtual smart card

Microsoft states that unencrypted copies of VSC private keys are loaded only within the TPM and never into memory the operating system can reach, and that a TPM key whose properties disallow export truly cannot leave the TPM. That gives strong protection against key theft from a compromised machine. Two differences matter:

• Delay, not block: Microsoft notes that a VSC sits on a computer that may be left unattended, giving an attacker the chance to hammer the TPM, and that its anti-hammering presents only a time delay rather than fully blocking. Delays are governed by the TPM's dictionary attack settings, which differ by TPM.
• Possession equals the device: the "something you have" is the laptop. Anyone with the laptop and the PIN has both factors, so full disk encryption and device lock matter more than with a card kept in a pocket.

Windows Hello for Business

WHfB generates a key pair bound to the TPM if available, or in software otherwise, and the private key cannot be exported. The PIN and private key are never sent to the identity provider. Microsoft's "Use a hardware security device" policy (CSP PassportForWork/{TenantId}/Policies/RequireSecurityDevice) limits provisioning to devices with a usable TPM 1.2 or 2.0; without it, devices can fall back to software keys. Microsoft recommends excluding TPM 1.2 (ExcludeSecurityDevices/TPM12), noting that it allows only RSA and SHA-1 and that lockout policies vary between implementations. For AAL3 in NIST SP 800-63B-4, the authenticator must have a non-exportable private key held in a hardware-protected, isolated environment and provide phishing resistance, and syncable authenticators must not be used; a software-fallback WHfB key or a synced passkey does not meet that bar.

Attestation: proving where the key lives

Attestation answers the question a relying party cannot answer from a signature alone: is this key really in a TPM or certified authenticator, or in malware pretending to be one?

• TPM endorsement and attestation identity keys: Microsoft explains that an endorsement key certificate, signed by the TPM manufacturer, lets solutions confirm a real TPM is involved, and that attestation identity keys, certified by an identity CA, let devices prove keys exist in a real TPM without exposing the endorsement key everywhere. For WHfB, Microsoft can act as that identity CA so identity providers can check device TPM requirements before provisioning.
• Virtual smart cards: the documented tpmvscmgr create parameters cover name, administrator key, PIN, PUK, file system generation and remote creation; none attests the key to the issuing CA. If you need proof that a certificate's key is TPM-protected, use certificate templates with TPM key attestation in your CA, or move to WHfB with hardware required.
• Passkeys: Microsoft Entra ID's Enforce attestation setting verifies authenticator make and model against trusted metadata at registration; with it off, Entra says it cannot guarantee whether a passkey is synced or device-bound. Attestation is checked only at registration, so users who registered earlier keep signing in after you turn it on. Key restrictions allow or block specific models by AAGUID. Synced passkeys do not support attestation.
• Physical cards: assurance comes from the issuance process (identity proofing, card management system, chip certification) more than a run-time attestation check. For PIV, FIPS 201-3 governs identity proofing and issuer accreditation.

See the TPM and device attestation for enterprise endpoints and Device-Bound Passkeys.

PIV and CAC requirements

Federal and defence environments are where the choice is least free.

• A VSC is not a PIV Card: a PIV credential is issued under FIPS 201-3 by an accredited issuer after identity proofing. A virtual smart card created on a laptop with an enterprise certificate is a useful smart card emulation but does not carry PIV status. NIST SP 800-53 Rev 5 control IA-2(12) Acceptance of PIV Credentials applies to systems that must accept PIV.
• The approved alternative to the card is a derived credential: where users need PIV-level authentication without a card reader, the route is a derived PIV credential under NIST SP 800-157. See Derived PIV Credentials.
• Check before retiring cards: agency and contract requirements decide which non-PIV phishing-resistant methods a system may accept; confirm them in writing before moving a PIV-bound population.

Administration, privileged access and break-glass

Accounts with "Smart card is required for interactive logon" set have a password hash that should be rotated periodically, since that hash still authenticates over NTLM. Smart card enforcement does not cover non-human accounts at all; machine and service credentials belong in a separate programme. See the Privileged Access Workstations Guide and the Break-Glass Account Guide.

Decision criteria

• Small organisations: card infrastructure is expensive to keep. If no mandate applies, moving straight to WHfB and security key passkeys usually removes a CA, a card management system and reader support in one step.
• Large or regulated organisations: expect a mixed estate for years: cards for PIV-bound and privileged users, WHfB for the general workforce, passkeys for cloud. Plan policy so each population has one primary method and one backup.

See Certificate-Based Authentication vs FIDO2 for the protocol-level comparison.

Worked scenario

A government contractor runs 3,000 users on PIV-I cards. 400 engineers complain about readers on thin laptops; 60 domain administrators use cards on PAWs; four break-glass accounts use cards in a safe.

• Engineers: the team had planned virtual smart cards. Given Microsoft's direction, they deploy WHfB cloud Kerberos trust with "Use a hardware security device" on and TPM 1.2 excluded, for systems where the contract accepts it. Systems that require PIV keep accepting the card; engineers keep their cards for those.
• Administrators: stay on physical cards on PAWs, with removal policy set to lock. Password hashes on smart-card-required admin accounts are rotated on schedule.
• Break-glass: two cards and two FIDO2 security keys, stored in separate locations, tested quarterly.
• Existing VSCs: 120 VSCs created years ago with the documented default administrator key are found in inventory; they are reissued or retired as users move to WHfB.

Migration path from virtual smart cards

1. Inventory: find devices with VSCs (each appears as a smart card reader instance) and certificates issued from VSC templates; record which applications rely on them.
2. Classify by requirement: PIV-bound, privileged, shared workstation, general workforce.
3. Prepare the target: configure WHfB policy with hardware required, choose the trust type, and enable passkeys with attestation and key restrictions where cloud sign-in matters.
4. Pilot: one department, keeping the VSC as fallback so users can still sign in if WHfB provisioning fails.
5. Cut over by group: enrol WHfB, confirm sign-in and application access, then revoke the VSC certificate and remove the card.
6. Roll back: while the VSC certificate is valid the user can still sign in with it; do not revoke until WHfB is proven for that user.
7. Retire templates: once no valid VSC certificates remain, remove the template from issuance.

Detection and measurement

• Log: Kerberos authentication with certificate (event 4768 on domain controllers carries certificate fields), smart card logon failures, WHfB provisioning outcomes, IdP passkey registrations with attestation result, certificate issuance and revocation.
• Coverage: percentage of users on a phishing-resistant primary method (card, hardware WHfB or device-bound passkey).
• Hardware assurance: percentage of WHfB keys provisioned on hardware TPM 2.0 versus software.
• Retirement: count of valid VSC certificates, trending to zero.
• Privileged: percentage of tier 0 accounts with smart card or hardware key enforcement.
• Support load: PIN reset and card unblock tickets per 100 users per month.

Common failure patterns

• Default administrator keys and PINs: Microsoft documents a default administrator key, PIN and PUK for tpmvscmgr create. Cards created with DEFAULT values can be reset by anyone who knows them; use PROMPT or RANDOM and a card management system.
• Software fallback left on: WHfB provisioned without "Use a hardware security device" gives software keys on devices with a faulty TPM, which do not meet hardware-based assurance.
• Assuming a VSC satisfies PIV: auditors reject it where a PIV credential is required.
• Turning on attestation late: Entra checks attestation only at registration, so passkeys registered before enforcement remain usable until re-registered.
• Break-glass bound to one device: a VSC or single WHfB enrolment fails the moment that device does.
• Forgetting certificate abuse: whichever card type you run, the CA is the target; forged or stolen certificates bypass every card (ATT&CK T1649). Strong certificate mapping and CA hardening are part of the decision.

Framework mapping

Practitioner checklist

• Map every population to a requirement: PIV-mandated, privileged, shared workstation, general.
• Keep physical cards or security keys for break-glass, with at least two credentials stored separately.
• Do not start new virtual smart card deployments; set a retirement date for existing ones.
• Audit existing VSCs for default administrator keys, PINs and PUKs.
• Enable "Use a hardware security device" for WHfB and exclude TPM 1.2.
• Turn on passkey attestation and key restrictions before broad registration.
• Keep derived PIV as the route for PIV users who need a cardless option.
• Rotate password hashes on smart-card-required accounts.
• Track hardware assurance and VSC retirement metrics monthly.

Standards and references

• NIST: FIPS 201-3 Personal Identity Verification (PIV) of Federal Employees and Contractors
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• Microsoft Learn: Virtual Smart Card overview
• Microsoft Learn: Understand and evaluate virtual smart cards
• Microsoft Learn: tpmvscmgr
• Microsoft Learn: How Windows uses the TPM
• Microsoft Learn: Windows Hello for Business policy settings
• Microsoft Learn: Enable passkeys (FIDO2) in Microsoft Entra ID

Related NHI Mgmt Group resources: Smart Card and PIV/CAC Authentication Guide, Windows Hello for Business Guide, HSM vs TPM vs Secure Enclave, Phishing-Resistant MFA Guide.