Security · 2026-03-17

Harvest Now, Decrypt Later: Your 2026 Identity Data Is Already at Risk

By J. W. Bouckaert

The threat model that operates on a decade-long timeline

Most threat models assume an adversary with current capabilities. The Harvest Now, Decrypt Later (HNDL) model operates on a fundamentally different assumption: that the adversary's capabilities will improve over time, and that data intercepted today will become readable in the future.

The mechanism is straightforward. A state-level adversary with access to network infrastructure—through lawful interception, compromised backbone routers, or submarine cable tapping—captures encrypted traffic in bulk and stores it indefinitely. The adversary cannot decrypt this traffic today. They do not need to. They are betting that a cryptographically relevant quantum computer (CRQC) will eventually exist, at which point traffic protected by RSA-2048 or ECC P-256 key exchange becomes readable in polynomial time via Shor's algorithm.

Governments treat this as a real risk. The U.S. National Security Agency's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), published in September 2022, sets dates for national security systems to move to quantum-resistant algorithms.

Identity data as an HNDL target

Not all encrypted traffic carries equal HNDL value. Financial transactions have limited shelf life: the account numbers change, the funds settle, the window for exploitation closes. Communications intercepts have intelligence value but degrade as context becomes stale. Identity data is different.

Identity data is a high-value target for HNDL collection because identity is persistent. Credential bindings, authentication ceremony transcripts, device attestation chains and identifiers such as phone numbers form an identity graph that stays useful for years. Passkey biometrics never leave the device, so they are not in the traffic. Consider what an adversary gains by decrypting a five-year archive of identity traffic:

Authentication ceremony transcripts. Every passkey registration, every FIDO2 assertion, every challenge-response exchange. If the cryptographic binding between the credential and the relying party is broken, the adversary can forge authentication assertions for any user whose ceremony they captured.

Credential issuance records. Every verifiable credential issued, every presentation exchange, every status list query. The adversary gains the ability to forge credentials or impersonate issuers within any credential ecosystem whose cryptographic foundations relied on classical algorithms.

Session establishment data. Every TLS handshake, every key exchange, every session token derivation. The adversary can reconstruct session keys and decrypt the entire payload of every captured session, including API requests carrying bearer tokens, OAuth authorization codes, and refresh tokens.

Device attestation chains. Every WebAuthn attestation, every TPM endorsement key exchange, every device binding ceremony. The adversary gains the ability to forge device attestations, undermining the entire device-bound credential model that the industry has spent a decade building.

The critical insight is that HNDL does not require the adversary to attack the identity system in real time. They attack it retroactively, at a time of their choosing, after their quantum capabilities mature. The identity system's security posture at the moment of interception is irrelevant. What matters is whether the cryptographic primitives used at that moment will withstand quantum cryptanalysis in the future.

The CRQC timeline

No one has built a cryptographically relevant quantum computer. The open questions are when one could exist and how many qubits, at what error rates, specific attacks would need.

Published resource estimates give a sense of scale:

In 2023 IBM announced a goal of a 100,000-qubit system by 2033. Google's Willow chip, announced in December 2024, demonstrated error correction below threshold, meaning that adding physical qubits improved rather than degraded logical qubit performance.

Policy dates are firmer than hardware forecasts. National Security Memorandum 10 (May 2022) sets 2035 as the goal for mitigating quantum risk in U.S. federal systems, and NIST's draft IR 8547 proposes deprecating quantum-vulnerable algorithms after 2030 and disallowing them after 2035. Records kept for regulatory reasons can still exist by then: broker-dealers keep many records for three or six years under SEC Rule 17a-4, HIPAA requires security documentation to be kept for six years, and some government records are permanent. Traffic captured today, and stored data protected only by RSA or ECC, can still matter when those dates arrive.

Post-quantum readiness, defined

The industry has adopted "post-quantum readiness" as a marketing phrase. Vendors append it to roadmaps, whitepapers and RFP responses without saying what it covers.

Post-quantum readiness for an identity platform requires four specific properties:

1. Signature algorithm migration. Every digital signature in the system (credential issuance, session binding, attestation verification, audit log integrity) must eventually use an algorithm that resists quantum cryptanalysis. NIST standardized three post-quantum algorithms in August 2024: ML-KEM (FIPS 203, key encapsulation), ML-DSA (FIPS 204, digital signatures), and SLH-DSA (FIPS 205, stateless hash-based signatures). ML-DSA-65 is in NIST security strength category 3, and CNSA 2.0 specifies ML-DSA-87 (category 5) for national security systems.

2. Key exchange migration. Every key agreement protocol in the system (TLS session establishment, encrypted tunnel negotiation, credential exchange) must use a quantum-resistant key encapsulation mechanism. FIPS 203 recommends ML-KEM-768 as the default parameter set. This is the step that protects confidentiality against harvest now, decrypt later.

3. Entropy source integrity. Key generation needs an unpredictable seed. A properly seeded CSPRNG built on symmetric primitives stays secure against known quantum attacks, because Grover's algorithm gives at most a square-root speedup. A QRNG adds a physical source of randomness and, if seeds are logged, a record of where each one came from.

4. Retroactive protection. Data captured today is protected only by the algorithms used today. A system that moves key exchange to ML-KEM next year still leaves this year's recorded traffic exposed if it was protected by classical key exchange alone.

HNDL mitigation at PasskeyBridge

PasskeyBridge runs post-quantum signatures in production today.

ML-DSA signatures in production

PasskeyBridge pairs a classical signature (ES256 or ES384 for credentials, HMAC-SHA-256 for internal proofs) with an ML-DSA signature (NIST FIPS 204) in these places:

• Verifiable credentials. Every credential carries an ML-DSA proof at the tenant's level, ML-DSA-65 by default or ML-DSA-87 on the Enterprise add-on.
• Cross-reference bindings. On the Enterprise plan, when the tenant has turned on PQC signing, the binding of a carrier signal digest to a credential subject digest is hybrid-signed with ML-DSA-65.
• Cached proofs. On the Enterprise plan, with PQC signing on, cached proofs are hybrid-signed at the tenant's level.
• A2A negotiation handshakes. Each step of an agent-to-agent negotiation is hybrid-signed with ML-DSA-65.
• Audit log integrity. Every row of the zero-PII audit trail is hash-chained, and the chain heads are signed every five minutes with HMAC-SHA-256 and ML-DSA-65.

The ML-DSA implementation is mldsa-wasm, a WebAssembly build of the mldsa-native implementation, pinned to an exact version. An ML-DSA-65 signature is 3,309 bytes. These are real lattice-based signatures, not HMAC placeholders labeled as post-quantum.

QRNG-seeded entropy

The nonces mixed into PasskeyBridge's hybrid signatures come from a four-tier entropy hierarchy:

1. Tier 1: Outshift (Cisco). Primary quantum random number generation via Cisco's quantum entropy service.
2. Tier 2: QCi uQRNG. Photonic quantum hardware.
3. Tier 3: ANU QRNG. The Australian National University's free public QRNG service, used as a prototyping fallback.
4. Tier 4: Local CSPRNG. Emergency fallback using the runtime's cryptographically secure generator.

Each draw must pass the NIST SP 800-90B Repetition Count and Adaptive Proportion tests, and the accepted seed is XORed with local CSPRNG output, so a compromised provider cannot make the result more predictable than the local generator. When every quantum provider fails, the seed is classical.

ML-DSA signing does not depend on these nonces for its security. Their purpose is provenance: each hybrid signature carries the digest of the seed its nonce came from, which matches a row in the entropy audit pool.

Zero-PII architecture as HNDL mitigation

The PasskeyBridge zero-PII architecture limits what an adversary can recover from stored data, independent of algorithm strength. The platform stores low-entropy identifiers (phone numbers, emails, IPs) only as keyed HMAC-SHA-256 digests under a server-held pepper, which cannot be reversed by enumeration the way an unkeyed hash of a phone number can, and operational PII only as AES-256-GCM ciphertext.

Captured traffic is a different matter:

1. Connections to PasskeyBridge use TLS. A client may send a raw identifier, such as a phone number, over TLS, and the server computes the keyed digest on arrival. If that TLS session used only classical key exchange, a future CRQC could recover the raw value from a recording. Forward secrecy does not prevent this: it protects past sessions from a later theft of a long-term key, and a CRQC can still attack each recorded handshake.
2. BLAST tunnels use X25519 key exchange, which is not quantum-resistant, and can add ML-KEM-768 when the client sends an encapsulation key. Only the hybrid form protects recorded traffic against a CRQC.
3. Stored digests stay protected: HMAC-SHA-256 is not vulnerable to Shor's algorithm, and Grover's algorithm at most halves its effective key strength.
4. Signatures over that data use ML-DSA, which resists both Shor's and Grover's algorithms.

The stored data and its signatures are protected against a future CRQC today. Recorded traffic is protected only where the key exchange includes ML-KEM, and clients that need that protection should send digests, or use hybrid key exchange, rather than raw identifiers.

The cost of waiting

Every month that an identity platform continues to sign with RSA or ECC and establish sessions with classical key exchange alone, it adds another month of data to an adversary's archive.

The migration cost is real. Post-quantum algorithms have larger keys (ML-DSA-65 public keys are 1,952 bytes versus 32 bytes for Ed25519), larger signatures (3,309 bytes versus 64 bytes), and different performance. These are engineering constraints that need payload size budgets, latency measurement and key storage planning.

But the larger cost of waiting is the data generated between now and migration. Recorded traffic cannot be re-encrypted after the fact. It stays in the adversary's archive, protected only by the algorithms in use when it was captured.

For CISOs, the useful question is how much of their identity traffic is still protected only by classical key exchange, and for how long they are willing to keep adding to it.

The upgrade path

PasskeyBridge signs with ML-DSA-65 (security category 3) by default and offers ML-DSA-87 (category 5, the parameter set CNSA 2.0 specifies) to Enterprise tenants.

Because signatures are hybrid, the classical layer stays in place while the post-quantum level changes. Moving an existing tenant from one ML-DSA level to another requires every earlier verification key to stay published so that older proofs still verify, so it is handled as a planned migration rather than a setting change. The audit hash chain does not depend on the signature level: each row is linked by hash, and the signed checkpoints cover the chain heads.

PasskeyBridge's post-quantum work today covers signatures across credentials, cross-references, cached proofs, A2A negotiations and audit checkpoints. Protecting recorded traffic depends on ML-KEM in the key exchange, which BLAST offers; for ordinary TLS connections it depends on the client and the hosting provider's TLS support.

Start free · Test the API