Security · 2026-03-08

Post-Quantum Identity: NIST FIPS 204 and Your Auth Stack

By J. W. Bouckaert

The standard is final. The clock is running.

On August 13, 2024, NIST published FIPS 204: the Module-Lattice-Based Digital Signature Standard, which standardizes ML-DSA (formerly CRYSTALS-Dilithium) as the primary post-quantum signature algorithm for federal systems. FIPS 203 (ML-KEM, for key encapsulation) and FIPS 205 (SLH-DSA, hash-based signatures) were published the same day.

FIPS 204 is a binding federal standard, no longer a draft, a candidate, or a recommendation, and every system that touches US government data, or that enterprise customers expect to remain compliant, now operates under a countdown.

The question is no longer "should we prepare for post-quantum cryptography?" The question is: how much of your identity infrastructure needs to be rebuilt, and how quickly can you do it?

ML-DSA-65

ML-DSA is a lattice-based digital signature scheme. "Lattice-based" means the mathematical hardness assumption is the Module Learning With Errors (MLWE) problem, not integer factorization (RSA) or discrete logarithms (ECC). No known quantum algorithm solves MLWE efficiently.

FIPS 204 defines three parameter sets, each claimed to meet one of NIST's security strength categories:

• ML-DSA-44: category 2 (at least as hard to break as finding a SHA-256 collision)
• ML-DSA-65: category 3 (at least as hard as a key search on AES-192)
• ML-DSA-87: category 5 (at least as hard as a key search on AES-256)

PasskeyBridge signs with ML-DSA-65 by default and offers ML-DSA-87 as an Enterprise option. The sizes below are the ones FIPS 204 sets:

CNSA 2.0 specifies ML-DSA-87 for national security systems at every classification level. An ML-DSA-65 signature is about 3.3 KB and its public key about 1.9 KB. Both are much larger than ECDSA's, which is manageable for identity attestation where signatures are verified server-side and never embedded in QR codes.

For context on why identity specifically needs this level of protection, see Identity is a Physics Problem, Not a Math Problem.

Assumptions your auth stack makes

Most authentication platforms were designed around two assumptions:

1. RSA-2048 or ECC P-256 will remain secure for the foreseeable future
2. Key and signature sizes will remain small

Both assumptions are now wrong.

The CRQC timeline

No one has built a Cryptographically Relevant Quantum Computer (CRQC) capable of breaking RSA-2048, and published estimates of when one could exist differ widely. NIST's draft transition plan, IR 8547 (November 2024), proposes deprecating quantum-vulnerable signature and key-establishment algorithms after 2030 and disallowing them after 2035. The risk to data starts earlier: an adversary can record encrypted traffic today and decrypt it once quantum hardware exists, which is why "harvest now, decrypt later" drives the timeline for confidentiality.

For identity systems, this means:

• Signed credentials issued today can be forged retroactively once classical signatures are broken
• Session tokens signed with ECDSA or EdDSA lose their non-repudiation guarantees
• Audit trail integrity depends on signatures that a CRQC could forge

Migration

Swapping RSA or ECC for ML-DSA is not a library upgrade. It requires:

1. New key management: ML-DSA public keys are 20 to 40 times the size of a P-256 public key. Key storage, rotation, and distribution infrastructure must account for that.
2. Signature format changes: Every system that parses, stores, or transmits signatures must handle 3KB+ payloads instead of 64 bytes.
3. Protocol updates: JWT headers, VC proof formats, and WebAuthn attestation structures all assume compact signatures.
4. Performance revalidation: any service that signs on the request path needs its latency measured again with ML-DSA in place, on its own runtime.

The hybrid signature architecture

PasskeyBridge does not wait for a full PQC migration. It uses a hybrid dual-signature architecture: a hybrid-signed attestation carries both a classical signature and a post-quantum signature.

┌─────────────────────────────────────────────┐
│            Hybrid Signature Envelope        │
├─────────────────────────────────────────────┤
│  Classical Layer:  ES256/ES384 or HMAC      │
│  PQC Layer:        ML-DSA-65 or ML-DSA-87   │
│  Nonce:            QRNG-seeded (256-bit)    │
│  Fingerprint:      SHA-256(domain)          │
└─────────────────────────────────────────────┘

Reasons for hybrid

The hybrid approach provides defense-in-depth against two failure modes:

1. If PQC is broken (a new attack on MLWE is discovered): the classical signature still holds. The attestation remains valid.
2. If a CRQC breaks classical crypto (Shor's algorithm on a production quantum computer): the PQC signature still holds.

Neither failure mode alone compromises the system. Both must fail simultaneously for an attestation to be forgeable.

NIST IR 8547 discusses hybrid schemes as one way to run classical and post-quantum algorithms side by side during the transition.

For how this integrates with the broader trust chain, see Why SIM-Swap Detection Is Not Enough and our three-pillar architecture overview.

PQC signature points

PasskeyBridge applies ML-DSA signatures at these points in the identity lifecycle:

1. Verifiable credential issuance

Every credential issued through the native VC engine carries an ML-DSA signature at the tenant's level (ML-DSA-65 by default). By default the credential is a compact ES256 or ES384 JWS, and the ML-DSA signature travels beside it as a detached proof that verifies against the ML-DSA public key published in the issuer's DID document.

2. Cross-reference binding

When a deterministic cross-reference binds a carrier signal digest to a VC subject digest, the binding record is hybrid-signed (HMAC-SHA-256 and ML-DSA-65) if the tenant has turned on PQC signing. Cross-references are an Enterprise feature.

3. Cached trust proofs

Cached proofs, which stand in for identity assurance while network signaling is unavailable, are hybrid-signed at the tenant's ML-DSA level when PQC signing is on. They are also an Enterprise feature.

4. Agent-to-agent negotiation and audit checkpoints

Each step of an A2A negotiation is hybrid-signed with ML-DSA-65, and every five minutes the heads of the audit and event hash chains are signed the same way.

NF-08 spatial bindings are not signed by the server. A capture may carry the client's own ML-DSA signature, which is stored with the binding.

Entropy

ML-DSA key generation starts from a 32-byte seed, and a predictable seed gives away the key. Signing is different: FIPS 204 defines a hedged variant that mixes fresh randomness into each signature and also permits a deterministic variant, so a signature's security does not depend on per-signature randomness.

PasskeyBridge derives each ML-DSA key deterministically from a server-held master key with domain-separated HMAC-SHA-256. The ML-DSA library signs in hedged mode with randomness from the runtime's CSPRNG (crypto.getRandomValues). Separately, every hybrid signature mixes a 32-byte nonce into the signed payload, and that nonce comes from a QRNG-seeded generator under the Seed-and-Stretch architecture (filed, NF-07):

The entropy pipeline

Outshift QRNG ─┐
QCi uQRNG ─────┼─▶ first draw that passes ──▶ XOR with ──▶ AES-256-CTR ──▶ Nonces
ANU QRNG ──────┤   SP 800-90B health tests     local CSPRNG
CSPRNG ────────┘   (emergency fallback)

1. Seed acquisition: a 256-bit seed is drawn from the first provider that answers: Outshift, then QCi, then ANU, with the runtime's CSPRNG as the emergency fallback
2. Health tests: each draw runs the Repetition Count and Adaptive Proportion tests from NIST SP 800-90B section 4.4; a draw that fails is rejected and the next provider is tried
3. XOR mixing: the accepted seed is XORed with local CSPRNG output, so the mixed seed is at least as unpredictable as the local CSPRNG even if a provider is compromised
4. Stretching: the mixed seed keys AES-256 in counter mode, which produces the nonces. A background reseed starts when the seed is 60 seconds old or has served 1,000 requests, and that seed keeps serving while the refresh runs. When the seed is 5 minutes old or has served 5,000 requests, whichever comes first, the next call waits for a new seed and returns no bytes until that reseed succeeds

The generator borrows the reseed idea from NIST SP 800-90A but is not a validated SP 800-90A CTR_DRBG. Each seed's SHA-384 digest, provider and health-test result are recorded, so a signed artifact can be traced to the seed its nonce came from.

For the full QRNG architecture, see the technical whitepaper.

A checklist for identity teams

If you are evaluating identity infrastructure for 2026 deployment, ask each vendor:

• Which signatures carry ML-DSA today, and at which FIPS 204 parameter set?
• Is the post-quantum signature paired with a classical one, and can a standard verifier check each layer?
• Where do signing keys and nonces come from, and is that recorded?
• Which identifiers are stored, and in what form?

For the compliance perspective, see Reg S-ID Compliance Without Storing a Single Phone Number and SOC 2 Readiness for Identity Startups.

The transition path

A workable order is to inventory every cryptographic dependency in the identity stack, run hybrid classical and post-quantum signatures side by side, and retire the classical layer when policy and tooling allow. The dates in NIST IR 8547's draft (deprecation after 2030, disallowance after 2035) set the outer bound for federal systems.

PasskeyBridge runs hybrid signatures today. Credentials always carry an ML-DSA proof. Enterprise tenants turn on hybrid signing for cross-references and cached proofs with the pqc_enabled flag on their VC provider configuration, and existing verification flows keep working because the classical layer is still there.

Summary

FIPS 204 is a current standard, and identity teams buying in 2026 can ask for ML-DSA in production now.

PasskeyBridge ships hybrid signatures with ML-DSA-65 and ML-DSA-87 on verifiable credentials, cross-references, cached proofs, A2A negotiations and audit chain checkpoints, with a QRNG-seeded nonce recorded against each signature.

Read the technical whitepaper → | Explore the patent portfolio → | Start building →

Start free · Test the API