PIV Smart Cards vs USB Tokens vs Embedded Secure Elements.
The decision matrix isn’t about which is most secure — all three are. It’s about lifecycle, convergence, and what happens at recovery time.
Three credential classes, one problem
The workforce identity decision matrix has narrowed to three real choices: a contact-or-contactless smart card running a PIV-compatible applet, a USB token speaking PKCS#11 to a desktop client, or an embedded secure element soldered into a managed device. All three are hardware-backed. All three store a private key that never leaves the chip. The differences are in lifecycle, in physical-vs-logical convergence, and in what happens when something goes wrong.
This post is for the engineer or architect doing the matrix. The question is not "which is most secure" — all three are. The question is which one matches your deployment realities.
The PIV smart card
A PIV smart card is the canonical workforce identity primitive: a contact (ISO/IEC 7816) and increasingly contactless (ISO/IEC 14443) credential carrying four standard certificate slots (PIV Authentication, Card Authentication, Digital Signature, Key Management) plus a CHUID and a facial-image container. The applet speaks the NIST SP 800-73 command set; middleware on the host (PIVKey, OpenSC, Microsoft BaseCSP, macOS CryptoTokenKit) translates that into the OS's native cryptographic API.
What the card brings that the other two do not:
- Physical-logical convergence. The same card is the building access badge. The PACS reader at the door reads the CHUID; the same card in a contact reader authenticates the user to the workstation. One credential, two surfaces.
- Identity-card semantics. The card is, in regulated identity programmes, a personnel record. The facial-image container, the printed surface, the embedded chip, and the attribute certificates all hang together as proof of identity. This is the model PIV was designed for and it is non-trivial to reproduce with a USB token.
- Issuance under formal authority. The card is issued through a personalisation line under the issuing authority's CA. The lifecycle (issue, suspend, revoke, reissue) is a workflow, not a help-desk script.
For workforce or government identity programmes that need the personnel-record properties, the PIV card is still the default. See OnePass Card for an example of this class.
The USB token
A USB token (think PKCS#11 signature token, FIDO security key, or the PKCS Signature Suite) is a card-shaped credential housed in a USB or USB+NFC plug. The cryptographic surface is the same as a smart card — ECC P-256 / RSA 2048 / 3072, on-token key generation, PIN policy — but the form factor is optimised for the laptop user who does not also need a badge.
What the token brings:
- No card reader needed. The USB port (or NFC on a modern phone) is the reader. For laptop-first workforces, this collapses the hardware stack from "card + reader" to "token."
- Lower issuance overhead. Tokens can ship pre-personalised. The user-attached step is configuring slots and importing certificates, which the operator can drive remotely.
- Cross-platform. PKCS#11 middleware runs on Windows, macOS, Linux. The same token signs PDFs in Acrobat, signs code with signtool, authenticates VPN clients, and authenticates email with S/MIME.
Where the token loses to the card: it is not a badge, the user has to carry it as a separate item, and it lacks the personnel-record semantics. For a workforce that already has badges for physical access, adding a separate USB token is two items where one would do. For a workforce that doesn't need badges at all, the token is the cleaner answer.
The embedded secure element
The third class is the most architecturally interesting and the least visible to the user: a secure element soldered into a managed device, holding the workforce credential as a platform authenticator. The credential never leaves the device. The user never sees it. The administrator manages it through the device's MDM channel.
Examples: a TPM holding a Windows Hello for Business credential; an Apple Secure Enclave holding a platform passkey; a custom embedded SE (or the PIV Nano-Card Applet in an eUICC configuration) carrying a workforce certificate inside a ruggedised industrial endpoint.
What the embedded SE brings:
- Zero per-user hardware. The credential rides on the device the user already has. No card, no token, no separate object.
- MDM-managed lifecycle. Issuance, rotation, and revocation all happen through the device-management channel. The user is never in the loop.
- Phishing-resistance through device binding. The credential is bound to a specific device. Even if the user is phished, the attacker still needs to compromise the device to use the credential.
Where the embedded SE loses: the credential dies with the device. A laptop refresh is a credential refresh. A lost phone is a lost credential. For high-mobility users or BYOD postures, this is a significant operational cost.
The decision matrix
Pick the credential class based on what is true about the user and the deployment:
- The user needs a badge for physical access → PIV smart card. One credential, two surfaces, identity-card semantics.
- The user is laptop-first, no badge needed, cross-OS signing required → USB token. Use the PKCS Signature Suite if signing applications matter; use a FIDO2 token if WebAuthn is the only requirement.
- The user is on a managed device, the operator owns the device-management channel, and the credential can die with the device → Embedded SE. TPM-backed passkey or PIV-on-eUICC.
- The user moves between devices and the operator wants the credential to outlive any single device → Roaming form factor. Either a smart card or a removable embedded secure-element FIDO2 applet.
The hybrid pattern that actually ships
In practice, most enterprise rollouts use two of the three. A common pattern:
- PIV smart card as the badge + workstation authenticator for users who need physical access (security operations, lab access, secure facility).
- FIDO2 token or embedded passkey on managed laptops for daily sign-in.
- A separate, higher-assurance authenticator (a dedicated security key) for admin escalation.
The FIDO Validation Server's per-tenant AAGUID policy is the place to express this hierarchy: low-tier paths accept the embedded passkey AAGUID; high-tier paths require the dedicated-key AAGUID; admin paths require both.
Certificate lifecycle, applied
All three classes share the same certificate lifecycle: issuance under a CA, periodic rotation, revocation through CRL or OCSP. What differs is where the lifecycle is operated:
- PIV cards. Issuance line under the operator's CA. Revocation reaches the user when the next OCSP/CRL pull happens at the relying party.
- USB tokens. Same as cards, but the issuance step is "configure slot at first use." Some operators ship pre-personalised; some defer slot population to a help-desk session.
- Embedded SEs. Issuance and revocation are wholly inside the MDM. The credential rotates on a schedule the operator sets; the user is invisible to the lifecycle.
For long-term auditability, the embedded SE path is the messiest: the credential's history lives inside the MDM, not in a CA audit log. For programmes that need an independently auditable credential trail, the card or token path is the right answer.
What none of these solve
Hardware-backed credentials retire phishing, replay, and credential-stuffing as attack classes. They do not solve enrolment fraud, social-engineered help-desk recovery, or compromised relying-party servers. A well-run programme pairs hardware credentials with:
- Strong identity proofing at enrolment (the credential is only as good as the binding to a verified person).
- A phishing-resistant help-desk recovery flow (proof-of-identity plus a separate hardware credential, not just "answer these security questions").
- Server-side credential governance (the relying party's audit of which credentials authenticated which actions).
Skipping any of these turns the hardware credential into a very expensive single point of failure.
The bottom line
PIV smart card for physical-logical convergence. USB token for laptop-first signing workflows. Embedded SE for managed-device, zero-hardware deployments. Roaming secure-element applets for the operator who already ships SIMs. The right answer for a workforce is usually two of these, not one — expressed in the validation server's AAGUID policy and in the issuance CA's certificate-class scope.