How to Choose Between Smart Cards, FIDO Tokens and Passkeys
Three credential classes that look adjacent on a slide and behave very differently in production. This is the comparison the procurement spreadsheet keeps trying not to draw — what each one actually is, where each fits, and what breaks when you pick the wrong one.
If you read enough analyst reports, you will see "smart cards", "security keys", and "passkeys" listed as roughly interchangeable strong-authentication options. They are not. They have different threat models, different recovery stories, different operational costs, and different things they refuse to do. This post is the cornerstone comparison; the rest of our FIDO and smart-card cluster builds on it.
Definitions first
The terms are abused in marketing material, so let’s lock them down.
- Smart card. An ISO/IEC 7810 ID-1 form-factor card containing a secure-element chip. The chip runs an applet (often JavaCard) that exposes a contact (ISO/IEC 7816) or contactless (ISO/IEC 14443) interface. A smart card might host FIDO2, PIV, eIDAS, transit fare, or proprietary applets — one card, several applets, AID-selectable.
- FIDO security key (token). A dedicated hardware device implementing the FIDO2 / CTAP2 authenticator protocol. Usually a USB key with optional NFC. Single-purpose authenticator; no other applets, no smart-card APDU surface.
- Passkey. A FIDO2 credential where the private key is stored by a platform credential manager (Apple, Google, Microsoft, 1Password, etc.). May be synced across the user’s devices through an account-bound cloud, or device-bound to a single hardware unit.
All three implement WebAuthn at the relying-party (RP) layer, so from a website’s point of view they look identical when registered. The deployment differences are below the RP API.
Threat-model differences
The single most important table in this post:
| Threat | Smart card | FIDO key | Synced passkey |
|---|---|---|---|
| Phishing-resistant primary auth | Yes (FIDO2 origin binding) | Yes (FIDO2 origin binding) | Yes (FIDO2 origin binding) |
| Private key extractable from device | No (secure element + CC EAL5+ typical) | No (secure element) | Depends — cloud-side at the credential manager |
| Loss of physical device = loss of credential | Yes (until re-issuance) | Yes (until re-issuance) | No (sync recovers) |
| Compromised cloud account = compromised credential | No | No | Yes (this is the design tradeoff) |
| Attestation-pinnable to certified hardware | Yes | Yes | Limited — platform AAGUIDs only |
| Survives MITM with credential-stealing proxy | Yes (origin-binding) | Yes (origin-binding) | Yes (origin-binding) |
| Survives a stolen unlocked phone | N/A (card not on phone) | N/A (key not on phone) | Risk — depends on platform UV policy |
The interesting cells are the recovery / loss cells. Smart cards and dedicated FIDO keys are device-bound: lose the physical thing, lose the credential, re-issue. Synced passkeys are account-bound: lose the physical thing, recover from the platform account, keep working.
Whether that is a feature or a bug depends entirely on what you’re defending against.
When a smart card is the right choice
Smart cards are the choice when one of these is true:
1. You want one credential to cover badge + authenticator + (optionally) transit / payment
A smart card can host a FIDO2 applet, a PIV applet for SSH and code-signing, a closed-loop transit applet, and a building-access applet on the same chip with separate AIDs. One card replaces three things to lose.
2. You need device-bound credentials for compliance reasons
Some regulatory frameworks — NIST 800-63B AAL3, eIDAS QSCD, certain national-ID schemes — require that the authenticator be a single physical device that cannot be cloned to a second device. A synced passkey does not meet that bar by definition. A smart card or a device-bound FIDO key does.
3. You already issue badges
If your facilities team prints employee photo ID on a card, the marginal cost of adding a FIDO applet to that card is small. The marginal cost of issuing a separate hardware key is the full BOM of the key plus the issuance time. Bundling pays back fast.
4. You need attestation to a chip you control
Smart cards from a known issuer expose attestation that traces back to your personalisation line. You can verify at registration that the credential really came off your issuance pipeline. That’s harder with consumer-bought security keys and impossible with passkeys synced from an arbitrary platform account.
When a dedicated FIDO security key is the right choice
1. You have shared workstations
Field-service tablets, manufacturing-floor kiosks, retail point-of-sale. A USB key in a lanyard moves between users in a way a card-shaped credential doesn’t fit. The user experience is "tap to log in, walk away, next user".
2. You need to authenticate to laptops without NFC
Many corporate laptops still ship without NFC. A USB-A or USB-C FIDO key works on every laptop you have. A smart card without NFC needs a reader; a smart card with NFC needs a laptop with NFC; a USB key needs neither.
3. You want a backup authenticator
Even in a smart-card deployment, privileged users typically also get a backup USB key, sealed and locked in a safe, with its private key registered as a second authenticator. When the primary card is lost, the backup unblocks the user before re-issuance.
4. You don’t need badge functionality
If your workforce already has its physical-access story figured out separately, the smart-card form factor adds cost for nothing. A FIDO key is the cheapest hardware-rooted credential per seat.
When passkeys are the right choice
1. Consumer-facing accounts
If you operate a consumer service — a bank, an airline, a retailer — passkeys are the right primary authenticator. The recoverability of the synced-passkey design matches the recoverability the consumer expects. You will not solve the "I lost my key in a taxi" support call with hardware keys at consumer scale.
2. Workforce, second-factor for low/medium privilege accounts
For accounts that do not need AAL3 device-bound assurance, platform passkeys are excellent. They’re free to deploy, they’re phishing-resistant by construction, and they kill SMS and TOTP as second factors.
3. You can’t physically distribute hardware
Globally distributed contractors, freelancers, partner-org employees. Shipping hardware to them is operationally painful. A platform passkey on the laptop they already own is the realistic answer.
When each one is the wrong choice
| Situation | Wrong choice | Why |
|---|---|---|
| AAL3 privileged-account requirement | Synced passkey | Synced passkeys are explicitly not AAL3. |
| Recovery-friendly consumer service | Smart card | Re-issuance is operationally too slow for consumer scale. |
| Field workers using shared tablets | Smart card (badge-printed) | The badge is the wrong shape for shared-device workflows. |
| Tiny org, no badge programme | Smart card | The card adds cost vs. just buying everyone a USB key. |
| Laptop without NFC and a smart-card programme | Smart card alone | Pair with a USB form factor or NFC reader. |
| Internal high-privilege admin | Synced passkey alone | Pair with a device-bound credential (USB key or smart card). |
The realistic mix
Most enterprises end up with all three, in well-defined zones:
- Privileged accounts (root, admin, infrastructure access): smart card or device-bound FIDO key. Pin the AAGUID. No passkeys.
- Knowledge workers (general workforce SSO): smart card (if you have a badge programme) or device-bound FIDO key. Backup credential mandatory.
- Field and shift workers (shared kiosks, mobile devices): FIDO USB key on a lanyard, NFC card if your kiosks support it.
- Low-privilege / external contributors: synced passkey is acceptable, paired with sensible conditional-access policy.
This is what a real passwordless enterprise rollout looks like — not "everyone gets a key" but "every account class gets the right credential class".
The attestation distinction
FIDO2’s WebAuthn API exposes attestation at registration: the credential can prove to the relying party which authenticator model it is. Attestation is the difference between "we have a FIDO programme" and "we have a FIDO programme that only accepts our hardware".
- Smart cards from your own issuer: attestation traces to the personalisation line. High confidence.
- Branded FIDO keys from a known vendor: attestation traces to the vendor’s manufacturing root. High confidence.
- Synced passkeys: attestation, if present at all, identifies the platform credential manager. Not the user’s hardware.
If your security policy says "credentials must live on certified hardware we’ve approved", attestation against FIDO Metadata Service (MDS) is how you enforce it. (See Understanding WebAuthn Attestation Objects for the byte-level mechanics.)
Recovery is the real design problem
The fundamental difference between the three credential classes is what happens when a user no longer has the credential they registered with. Picking your authenticator class is mostly picking your recovery story.
| Authenticator class | Recovery story | SLA realism |
|---|---|---|
| Smart card | Re-issue at IT desk. New card, new credentials. | Same-day in office; multi-day for remote staff. Plan for both. |
| FIDO USB key | Hand a backup key from stores; revoke the lost one. | Same-day if backup-key inventory is local; up to several days for shipping. |
| Synced passkey | Sign in to the platform account on a new device; passkey syncs. | Minutes if the user remembers their platform password and 2FA. |
Notice the difference. Smart cards and USB keys give you assurance at the cost of recovery latency. Synced passkeys give you recovery at the cost of platform-account dependence. Both tradeoffs are legitimate; only one fits each account class.
Cost realism
Per-seat BoM (rough order of magnitude, depending on volume and certification level):
- Synced passkey: free.
- Device-bound FIDO USB key: USD 25-60 per unit at volume.
- Smart card with FIDO + badge artwork: USD 8-25 per unit at volume, plus your personalisation line.
- Smart card with biometric (bio card): USD 60-120 per unit at volume.
The total cost-of-ownership story is dominated by issuance, helpdesk, and recovery, not by the unit BOM. A USD 30 USB key with bad issuance hygiene is more expensive than a USD 15 smart card with a five-minute IT-desk-issued flow.
A decision matrix
| Property | Smart card | FIDO USB key | Synced passkey |
|---|---|---|---|
| Form factor | ID-1 card | USB + NFC dongle | None — uses existing device |
| Carries badge artwork | Yes | No | No |
| Multi-applet capable | Yes (FIDO + PIV + transit + ...) | No (FIDO only) | No |
| Works on laptops without NFC | Only with reader | Yes (USB) | Yes |
| Works on phones | Yes via NFC | Yes via NFC / USB-C | Yes (native) |
| Device-bound | Yes | Yes | No (synced) |
| AAL3-capable | Yes | Yes | No |
| Recovery model | Re-issue | Re-issue / backup key | Sync from platform |
| Typical TCO driver | Issuance line + helpdesk | Helpdesk + key inventory | Conditional-access policy |
How to actually decide
Three questions in this order:
- What assurance level does the account need? AAL3 / eIDAS-QSCD / national-ID-grade ? device-bound only. Below that, synced passkey is on the table.
- Do you already issue physical badges? Yes ? smart card is essentially free at the margin. No ? a separate badge programme just to add FIDO is probably overkill; pick USB keys.
- What is the realistic recovery latency you can sustain? Hours ? smart card or USB key with backup. Minutes ? synced passkey or platform credential.
Answer those three, and the credential class drops out. Build the rest of the rollout around the credential class, not the other way around.
Related reading
- Passkeys vs Traditional MFA — deeper on the passkey side.
- Platform vs Roaming Authenticators — the WebAuthn-level dimension.
- Understanding WebAuthn Attestation Objects — the attestation mechanics referenced throughout this post.
- Implementing FIDO2: A Complete Developer Guide — the RP side.
- Designing Enterprise Passwordless Systems — the rollout-architecture side.
- Designing Secure Credential Lifecycle Management — cornerstone on lifecycle.
- Case study: Passwordless workforce
- OnePass Platform
- OnePass Card
- OnePass USB Key
Companion tools
- AAGUID lookup — identify any authenticator from an attestation.
- COSE key viewer — decode the public key inside an attestation.
- Attestation decoder — full attestation-object view.