PIV's Post-Quantum Problem

Why credentials are different

A server gets PQC through a software update; a PIV card gets it only by being replaced. That single fact sets the pace of federal identity migration.

• The hardware is fixed. A PIV card or YubiKey runs a validated chip and applet. Agencies do not update either in the field, and YubiKey firmware cannot be updated at all. New algorithms mean new credentials.
• Every holder must be reissued. Reissuance means identity proofing, an issuance appointment or shipment, and card management system capacity for each employee and contractor.
• Validation gates supply. A new card or token must pass FIPS 140-3 validation and be listed on the FIPS 201 APL before an agency can buy it for PIV use.
• Credentials live for years. A card issued this year stays in use for its full validity period, well past the federal PQC dates.

Network migration can move system by system as software allows. Credential migration moves at the speed of hardware supply and reissuance.

What NIST has proposed

NIST's June 2026 working drafts keep the four classical PIV keys and add ML-DSA and ML-KEM keys beside them, so a new card works with today's readers from the first day.

• The drafts update SP 800-73 Parts 1 and 2 (data model and card commands) and SP 800-78 (algorithms), with a PQC overview and gap analysis.
• New key references, certificate containers and data objects are added; existing ones stay unchanged.
• Signed objects such as the CHUID (Card Holder Unique Identifier) and the Security Object move to ML-DSA signatures.
• Still open: key reference values, parameter sets, whether card authentication gets a PQC key, and secure messaging.
• NIST calls these preliminary working materials, not formal public drafts. It is taking feedback through GitHub and a mailing list and has published no timeline.

Four places the card breaks

A PQC certificate is roughly 13 times larger than its ECDSA equivalent, and that growth breaks the card in four places.

The size growth also reaches the network. In a test TLS handshake with a three-tier PKI, a fully post-quantum server handshake received 17,125 bytes, against 2,318 bytes for the same handshake with ECDSA certificates. With mutual TLS, the card-backed client sends a similar certificate chain and signature of its own.

External mu keeps hash-then-sign working

External mu lets a card produce a standard pure ML-DSA signature while the host does the hashing, so the PIV signing model survives the move to PQC.

Today a PIV card never sees the document it signs. The host hashes it with SHA-256 and the card signs the 32-byte hash. Pure ML-DSA appears to break this, because the algorithm is defined over the whole message. The way through is in the algorithm's own structure:

1. ML-DSA first fingerprints the signer's public key into a value called tr.
2. It then hashes tr together with the message into a 64-byte value called mu.
3. Every later step, the only steps that use the secret key, works on mu alone. The message is never read again.

FIPS 204 allows the mu calculation to be done outside the signing operation. The host computes mu from the document and the public key in the certificate, both public. It sends the 64 bytes to the card, which fit in one short APDU, and the card finishes the signature with a key that never leaves it. The result is a standard pure ML-DSA signature, indistinguishable from one the card produced on its own, so every RFC 9881 verifier accepts it. One condition applies: NIST expects mu to be computed inside a validated cryptographic module, so the host component that computes it needs validation too.

The alternative, pre-hash ML-DSA (HashML-DSA), produces a different kind of signature with its own algorithm identifier, which verifiers expecting pure ML-DSA reject.

External mu needs changes on both sides:

• On the card: a signing mode that accepts a 64-byte mu instead of a message.
• In host middleware: the Windows minidriver, PKCS#11 libraries and similar components compute mu instead of SHA-256 before calling the card.

A lighter option for card authentication: KEM-based authentication

Card authentication may not need a signature at all. Researchers at IDEMIA Secure Transactions have shown a PIV card that proves it holds its key with ML-KEM instead of ML-DSA, cutting the data exchanged by about a third and the card's computation several-fold.

In their peer-reviewed SECRYPT 2026 paper, the signature in PIV's challenge-response authentication is replaced with a key encapsulation exchange:

1. The reader validates the card's certificate, which the issuing CA still signs with ML-DSA.
2. The reader encapsulates to the card's ML-KEM public key, producing a ciphertext and a shared secret.
3. The card decapsulates the ciphertext and returns a MAC over it, keyed with the shared secret.
4. The reader checks the MAC. A correct MAC proves the card holds the private key.

The computation gap matters most where time is tight, such as contactless door readers. ML-DSA signing time also varies from run to run because the algorithm retries internally; in the paper's tests, 1% of runs took 8.5 to 15 times longer than the fastest. ML-KEM decapsulation has no retry loop, so its time is predictable.

The approach has real limits:

• No transferable proof. A KEM exchange proves the card is present to the reader, but it produces nothing a third party can verify later. Document signing keeps its ML-DSA key.
• Relying parties must change. TLS client authentication and Windows smart card logon expect a signature today. The near-term fit is physical access and card authentication, not logon to systems.
• Certificates still carry PQC signatures, so the certificate size problem described above remains.
• It is a proposal, not yet a standard. NIST's SP 800-73 Part 2 working draft says an ML-KEM-based protocol "should be considered as an alternative" for the card authentication key, but whether that key gets a PQC version at all is still open. It needs final standards and validated products before agencies can use it.

For agencies, the action is to ask PACS and card vendors whether KEM-based card authentication is on their roadmaps, and to support it in feedback on NIST's PIV drafts.

The key management slot comes first

Of the four standard PIV keys, only the 9D key management key protects confidentiality, so it is the only one exposed to harvest-now-decrypt-later.

Authentication, digital signature and card authentication keys must resist forgery only while they are in use. A signature forged in 2040 cannot reach back and impersonate a user in 2026. Encryption is different. An adversary who records S/MIME email or encrypted files today, protected by an RSA or ECDH key management key, can decrypt them once a cryptographically relevant quantum computer exists. For records that must stay confidential for decades, that exposure has already begun.

The technical fit is good. Today the key management key either decrypts an RSA-wrapped key or performs an ECDH computation with a sender's ephemeral key. With ML-KEM, the sender encapsulates to the card's ML-KEM public key, and the card decapsulates the ciphertext to recover a shared secret through the existing GENERAL AUTHENTICATE command. The Cryptographic Message Syntax already defines the matching structure, KEMRecipientInfo, in RFC 9629.

Two consequences follow:

• Sequence key management first in credential planning, even though PIV authentication gets most of the attention.
• Keep retired key history. Mail encrypted to classical keys must stay readable, so retired RSA and ECDH keys must stay retrievable alongside new ML-KEM keys. NIST's draft notes that retired keys may include a mix of RSA, ECDH and ML-KEM.

The 2031 card cohort

A PIV card issued today, with the 6-year maximum life set in FIPS 201, stays in use until late 2032, about ten months past the December 31, 2031 signature deadline.

If validated PQC cards and tokens reach the APL around 2028 to 2029, every classical credential issued until then stays in circulation into the early 2030s. That is roughly three years of issuance across the federal workforce.

Whether user authentication to high-value and high-impact systems counts toward EO 14412's signature requirement is not yet settled. If it does, agencies need one of three answers for this cohort: an accelerated refresh once PQC cards exist, documented risk acceptance, or compensating controls such as moving those users to PQC-capable derived credentials.

What agencies should start now

Most credential work can begin before PQC cards exist, and starting it now is what makes the 2031 date reachable.

Derived PIV credentials, held in a phone's secure hardware or a computer's TPM, may gain PQC sooner than cards, because some platforms can add algorithms through validated software or firmware updates. Hardware support and FIPS 140-3 validation still gate deployment, but they are worth evaluating as a bridge for some users.