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 making a bet that a cryptographically relevant quantum computer (CRQC) will become available within 5 to 15 years, at which point every RSA-2048 and ECC P-256 ciphertext in their archive becomes readable in polynomial time via Shor's algorithm.

This is documented intelligence strategy. The U.S. National Security Agency's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) timeline, published in September 2022 and updated through 2025, mandates transition to quantum-resistant algorithms precisely because of this threat model. The NSA does not issue algorithm transition mandates for theoretical risks. It issues them for risks it has assessed as operationally credible.

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 the highest-value target for HNDL collection because identity is persistent. A person's biometric templates, credential bindings, authentication ceremony transcripts, and device attestation chains represent a durable identity graph that retains exploitation value for decades. 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

The question is no longer whether a cryptographically relevant quantum computer will exist. The question is when, and how many qubits at what error rates will be required to break specific classical algorithms.

Current estimates from leading quantum computing research programs converge on the following:

IBM's roadmap targets 100,000+ qubits by 2033. Google's Willow chip, announced in December 2024, demonstrated error correction below threshold for the first time, meaning that adding more physical qubits now improves rather than degrades logical qubit performance.

These are moving targets. Error rates are improving. Qubit counts are scaling. The timeline is compressing. The responsible assumption for any CISO managing identity infrastructure in 2026 is that data encrypted with classical algorithms today will be decryptable within a window of 7 to 12 years. For organizations subject to data retention requirements—financial services (7 years), healthcare (6 to 10 years), government (permanent record)—this window overlaps directly with regulatory retention periods.

This means identity data captured today, encrypted with RSA or ECC, and subject to regulatory retention, will be both stored and decryptable within the same compliance lifecycle.

Post-quantum readiness, defined

The industry has adopted "post-quantum readiness" as a marketing phrase. Vendors append it to roadmaps, sprinkle it into whitepapers, and reference it in RFP responses. The phrase, as commonly used, means almost nothing.

Genuine 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 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 (formerly CRYSTALS-Dilithium Level 3) is the minimum threshold for identity systems requiring 128-bit post-quantum security.

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. ML-KEM-768 is the NIST-recommended KEM for general use.

3. Entropy source integrity. Post-quantum algorithms are only as strong as the entropy that seeds their key generation. A quantum-resistant signature computed with a predictable nonce is trivially forgeable. The entropy source must itself be resistant to quantum prediction. Classical pseudo-random number generators (PRNGs) seeded from deterministic sources do not meet this bar. Quantum random number generators (QRNG) that derive entropy from quantum mechanical phenomena provide entropy that is physically unpredictable, not merely computationally unpredictable.

4. Retroactive protection. Perhaps most critically, the system must ensure that data generated today cannot be retroactively compromised. This means that key material, session transcripts, and credential exchanges must be protected by algorithms and entropy sources that will resist quantum cryptanalysis for the full lifecycle of the data. A system that migrates to post-quantum algorithms next year still leaves this year's data vulnerable if it was produced with classical primitives.

HNDL mitigation at PasskeyBridge

Post-quantum cryptography at PasskeyBridge is a production capability rather than a roadmap item: it is deployed across the platform's three-pillar architecture and has been since the platform's launch.

ML-DSA-65 signatures in production

Every cryptographic signature generated by the PasskeyBridge platform uses a hybrid construction: a classical signature (ES256/ES384 for credentials, HMAC-SHA-256 for internal proofs), plus ML-DSA-65 (NIST FIPS 204) for post-quantum resistance. This includes:

• Cross-reference bindings. When a carrier signal hash is bound to a verifiable credential subject hash, the binding carries a hybrid PQC signature. An adversary who intercepts this binding cannot forge it, even with a CRQC.
• Cached proof attestations. Every cached proof in the system is signed with ML-DSA-65, ensuring that offline-verified identity proofs remain tamper-evident against quantum adversaries.
• A2A negotiation handshakes. Agent-to-agent trust negotiations use lattice-based signatures for mutual attestation, preventing a quantum-equipped adversary from retroactively compromising inter-agent trust chains.
• Audit log integrity. Every entry in the zero-PII audit trail is hash-chained and signed with hybrid PQC signatures, ensuring forensic integrity survives the quantum transition.

The ML-DSA-65 implementation uses the NIST-compliant mldsa-wasm library, producing genuine ~3,309-byte lattice-based signatures. The ML-DSA signing and verification operations each complete in under a millisecond on a warm isolate; a cold invocation that must instantiate the WebAssembly module and acquire a fresh quantum-entropy seed is dominated by that setup cost. These are real signatures, not HMAC placeholders labeled as post-quantum.

QRNG-seeded entropy

Every nonce, session key, and cryptographic salt in the PasskeyBridge platform is seeded from a four-tier quantum 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 providing true quantum randomness derived from vacuum fluctuations.
3. Tier 3: ANU QRNG. Australian National University's quantum optics laboratory, the longest-running public QRNG service.
4. Tier 4: Local CSPRNG. Emergency fallback using the platform's cryptographically secure pseudo-random number generator, seeded from operating system entropy.

This hierarchy ensures that even if an adversary compromises one entropy source, the remaining tiers provide quantum-grade randomness. The entropy is physically unpredictable, derived from quantum mechanical phenomena that cannot be modeled or predicted by any computational process, classical or quantum.

The HNDL implication is direct: a nonce generated from QRNG-seeded entropy cannot be predicted by an adversary, even one operating a CRQC. This means that signatures computed with these nonces are not vulnerable to nonce-recovery attacks, which are among the most devastating quantum-enabled attack vectors against classical signature schemes.

Zero-PII architecture as HNDL mitigation

The PasskeyBridge zero-PII architecture provides a structural defense against HNDL that is independent of cryptographic algorithm strength. Because the platform stores low-entropy identifiers (phone numbers, emails, IPs) only as keyed HMAC-SHA-256 digests under a server-held pepper—not reversible by enumeration the way an unkeyed hash of a phone number would be—and operational PII only as AES-256-GCM ciphertext, there is no plaintext identity data to decrypt.

An adversary who captures and archives PasskeyBridge traffic faces a compounded problem:

1. The transport layer uses forward-secret key exchange (X25519 ECDH with quantum-seeded HKDF-SHA-256 salt via BLAST tunnels), meaning each session uses a unique ephemeral key that is discarded after use.
2. Even if the transport encryption is eventually broken by a CRQC, the payload contains hashes alone. SHA-256 is not vulnerable to Shor's algorithm. Grover's algorithm reduces the effective security of SHA-256 from 256 bits to 128 bits, which remains above the security threshold for all known threat models.
3. Signatures on the hashed data use ML-DSA-65, which is resistant to both Shor's and Grover's algorithms.

The result is a defense-in-depth posture against HNDL: quantum-resistant transport, quantum-resistant signatures, and no plaintext data to recover even if both layers are eventually compromised.

The cost of waiting

Every month that an identity platform continues to generate signatures with RSA or ECC, establish sessions with classical key exchange, and seed cryptographic operations with deterministic PRNGs, it adds another month of data to the adversary's HNDL archive. That is a present-tense data liability, and it compounds daily.

The migration cost is real. Post-quantum algorithms have larger key sizes (ML-DSA-65 public keys are 1,952 bytes versus 32 bytes for Ed25519), larger signatures (3,309 bytes versus 64 bytes), and higher computational overhead. These are engineering constraints. They require careful integration work: payload size budgets, latency optimization, key storage planning.

But the eventual migration effort is the smaller part of the cost of waiting. The larger part is the retroactive vulnerability of every piece of identity data generated between now and migration. That data cannot be re-encrypted after the fact. It cannot be re-signed with stronger algorithms. It exists in the adversary's archive, protected only by the algorithms that were in use at the time of capture.

For CISOs evaluating their quantum readiness posture, "when should we start planning for post-quantum migration?" is the wrong question. The one worth answering is: "How many months of our identity data are we willing to leave unprotected in adversary archives?"

The upgrade path

PasskeyBridge's current ML-DSA-65 deployment provides NIST Security Level 3 (128-bit post-quantum security). The defined upgrade path proceeds to ML-DSA-87, which provides Security Level 5 (192-bit post-quantum security) and aligns with the CNSA 2.0 requirements for national security systems.

The upgrade is architectural without being disruptive. Because the platform uses hybrid signatures (classical + PQC) throughout, the migration from ML-DSA-65 to ML-DSA-87 requires only an algorithm parameter change in the signing functions. All existing signatures remain valid under their original algorithm. New signatures are issued under the upgraded algorithm. The provenance chain maintains full integrity across the transition because each entry's signature covers the hash of the previous entry, creating continuity that is independent of the specific algorithm used at each step.

This is what production-grade post-quantum readiness looks like: a deployed, operating, quantum-hardened identity pipeline that protects every piece of data it generates today against adversaries who will attempt to decrypt it tomorrow. A roadmap slide with a 2028 target date does not qualify, and neither does a compliance checkbox with an asterisk pointing to "future release."

Start free · Test the API