Future-Proofing Digital Security Against the Quantum Computing Threat

Posted 2026-03-27 20:24:01

16 minutes

Abstract

The advent of large-scale, fault-tolerant quantum computers poses an existential threat to the cryptographic foundations that underpin global digital infrastructure. Algorithms such as RSA, Elliptic Curve Cryptography (ECC), and Diffie-Hellman—which currently protect trillions of dollars in transactions, classified communications, and critical infrastructure—are mathematically breakable by quantum machines running Shor's algorithm. This paper provides a deep technical analysis of the quantum threat landscape, post-quantum cryptographic (PQC) algorithm families standardised by NIST, enterprise migration strategies, attack scenario modelling, and developer-level implementation guidance. We argue that organisations must begin cryptographic inventory and migration planning immediately, as adversaries are already executing "Harvest Now, Decrypt Later" (HNDL) attacks against high-value encrypted traffic. The window for proactive transition is rapidly closing.

Keywords: post-quantum cryptography, lattice-based cryptography, CRYSTALS-Kyber, CRYSTALS-Dilithium, quantum key distribution, HNDL, crypto agility, NIST PQC, Shor's algorithm, Grover's algorithm, quantum threat, TLS migration, ML-KEM, ML-DSA, SLH-DSA

1. Introduction: The Quantum Threat to Classical Cryptography

Modern digital security rests on a single mathematical assumption: that certain computational problems—factoring large integers, solving discrete logarithms, computing elliptic curve discrete logs—are computationally infeasible for classical computers to solve within any practical timeframe. A 2048-bit RSA key, for example, would take a classical computer longer than the current age of the universe to factor using the best-known algorithms. This hardness assumption is the bedrock of virtually every secure communication protocol in use today: HTTPS, SSH, VPNs, code signing, digital certificates, email encryption, and blockchain transactions.

Quantum computers shatter this assumption. In 1994, mathematician Peter Shor published a polynomial-time quantum algorithm capable of factoring integers and computing discrete logarithms exponentially faster than any known classical algorithm. A sufficiently powerful quantum computer running Shor's algorithm could factor a 2048-bit RSA modulus in hours or even minutes. In 1996, Lov Grover published a quantum search algorithm providing a quadratic speedup over classical brute-force search, effectively halving the security level of symmetric algorithms.

As of 2024–2025, quantum hardware is advancing rapidly. IBM's Condor processor exceeded 1,000 physical qubits, and companies including Google, IonQ, and Quantinuum are demonstrating increasingly sophisticated error-corrected systems. While cryptographically relevant quantum computers (CRQCs)—machines with millions of high-fidelity logical qubits needed to break RSA-2048—remain years away, expert consensus from NIST, CISA, NSA, and ENISA is unambiguous: migration to quantum-resistant cryptography must begin now, not when a CRQC is publicly demonstrated.

1.1 Why the Urgency Is Real: The Harvest-Now-Decrypt-Later Threat

The most immediate and underappreciated threat does not require a quantum computer to exist yet. Nation-state adversaries and sophisticated threat actors are already intercepting and archiving encrypted network traffic today—banking records, government communications, health data, intellectual property—with the explicit intent to decrypt it once capable quantum hardware becomes available. This attack model, formally termed Harvest Now, Decrypt Later (HNDL), transforms today's strong encryption into tomorrow's plaintext. Data that must remain secret for 10, 20, or 30 years is therefore already compromised if it has been captured in transit.

1.2 Scope of This Document

This document serves as both a research reference and a practical operational guide. It covers the quantum threat landscape, post-quantum algorithm families, key distribution technologies, enterprise readiness frameworks, specific attack scenario analysis, defensive architecture patterns, developer implementation guidance, and forward-looking research directions. All algorithm recommendations align with the NIST Post-Quantum Cryptography Standardisation Project, which released its first finalized PQC standards in August 2024 (FIPS 203, 204, 205).

2. Quantum Threat Landscape

2.1 How Quantum Algorithms Break Classical Cryptography

2.1.1 Shor's Algorithm and Public-Key Cryptography

Shor's algorithm exploits quantum parallelism and the quantum Fourier transform to find the period of a function in polynomial time. For RSA, this means efficiently factoring the public modulus N = p × q to recover the private key. For ECC and Diffie-Hellman, it solves the discrete logarithm problem. The implications are total: any system relying on RSA, DSA, DH, ECDH, or ECDSA is completely broken by a CRQC.

To understand the magnitude: breaking RSA-2048 classically requires approximately 2¹¹² operations. Shor's algorithm reduces this to roughly O((log N)³) quantum operations. The table below summarises the impact across common algorithms:

Figure 1: Classical Algorithm Vulnerability to Quantum Attack

Algorithm	Type	Classical Security	Quantum Attack	Post-Quantum Security	Action Required
RSA-2048	Asymmetric (Encryption/Sig)	112-bit	Shor's Algorithm	0 bits (broken)	Replace immediately
RSA-4096	Asymmetric	140-bit	Shor's Algorithm	0 bits (broken)	Replace immediately
ECDSA P-256	Digital Signature	128-bit	Shor's Algorithm	0 bits (broken)	Replace immediately
ECDH P-256	Key Exchange	128-bit	Shor's Algorithm	0 bits (broken)	Replace immediately
DH-2048	Key Exchange	112-bit	Shor's Algorithm	0 bits (broken)	Replace immediately
AES-128	Symmetric	128-bit	Grover's Algorithm	~64-bit (weakened)	Upgrade to AES-256
AES-256	Symmetric	256-bit	Grover's Algorithm	~128-bit (adequate)	Retain; verify implementation
SHA-256	Hash Function	256-bit	Grover's Algorithm	~128-bit collision resistance	Consider SHA-384/512
ChaCha20-Poly1305	Symmetric AEAD	256-bit	Grover's Algorithm	~128-bit (adequate)	Retain

2.1.2 Grover's Algorithm and Symmetric Cryptography

Grover's algorithm provides a quadratic speedup for unstructured search. Applied to symmetric key search, it effectively halves bit-security: a 128-bit key becomes equivalent to 64-bit security against a quantum attacker. This falls below acceptable thresholds (NIST requires ≥128 bits for long-term security). The recommended mitigation is straightforward: double key lengths. AES-256 retains ~128 bits of post-quantum security and is considered quantum-safe. AES-128 should be deprecated.

2.2 The HNDL Attack Model: A Present-Day Crisis

The Harvest Now, Decrypt Later (HNDL) attack is not theoretical. Documented evidence suggests that nation-state intelligence agencies have been conducting mass interception and archival of encrypted traffic for years. The 2013 Snowden disclosures revealed large-scale traffic capture programs. More recently, CISA and NSA advisories have explicitly warned that adversaries are archiving TLS-encrypted traffic today.

Figure 2: HNDL Attack Timeline

+--------------------+----------------------------------------------------------+ | TODAY (2024-2026) | Adversary intercepts & archives encrypted TLS, VPN, | | | email traffic. Targets: govt, finance, healthcare, | | | defense, biotech. Uses backbone taps, compromised | | | network equipment, internet exchange point capture. | +--------------------+----------------------------------------------------------+ | ~2028-2032 | Cryptographically Relevant Quantum Computer (CRQC) | | | emerges in classified national lab / state actor. | +--------------------+----------------------------------------------------------+ | POST-CRQC | Archived ciphertext from 2020-2030 is decrypted. | | | RSA/ECDH session keys extracted via Shor's algorithm. | | | Full plaintext of intercepted communications recovered. | +--------------------+----------------------------------------------------------+ Risk by data type: [CRITICAL] State secrets, M&A negotiations, military logistics [CRITICAL] Clinical trials, genomic databases, drug formulas [HIGH] Financial instruments, insurance data, legal contracts [HIGH] Corporate IP, product roadmaps, source repositories [MEDIUM] Personal identification, biometric records

Figure 2: HNDL attack lifecycle. Data encrypted today under classical cryptography is already being harvested for future quantum decryption.

2.3 Critical Infrastructure Risks

Quantum computing threats extend far beyond confidentiality. Digital signatures—authenticating software updates, command-and-control communications, and identity certificates—are equally broken. Critical scenarios include:

Power Grid (SCADA/ICS): Forged digital signatures on firmware updates could allow adversaries to push malicious code to grid control systems.
Financial Infrastructure: SWIFT inter-bank messaging and stock exchange APIs rely on RSA/ECDSA signatures. A CRQC could forge authorisation signatures on high-value transfers.
PKI and the CA Ecosystem: The entire web's trust model (HTTPS) relies on X.509 certificates signed with RSA or ECDSA. Quantum-forged root CA signatures could enable mass undetectable man-in-the-middle attacks.
Telecommunications (5G/BGP): BGP route authentication (RPKI) and 5G subscriber authentication use classical asymmetric keys. Compromise enables nationwide traffic hijacking.
Aviation and Maritime: Backend systems managing air traffic control and vessel tracking use classical cryptographic authentication for operator commands.
Pharmaceutical: Clinical trial data, drug formulas, and regulatory submissions stored under RSA/AES-128 are prime HNDL targets with decade-long sensitivity.

3. Post-Quantum Cryptography (PQC)

Post-quantum cryptography refers to classical algorithms—running on conventional hardware—whose underlying mathematical problems are believed to be hard for both classical and quantum computers. Unlike QKD (Section 4), PQC does not require quantum hardware and can be deployed as software updates on existing infrastructure. NIST completed its PQC standardisation process in August 2024, publishing three Federal Information Processing Standards (FIPS).

3.1 NIST PQC Standard Algorithms (2024)

Figure 3: NIST PQC Finalised Standards

FIPS	Algorithm Name	Type	Mathematical Basis	Primary Use Case	Security Levels
FIPS 203	ML-KEM (Kyber)	Key Encapsulation Mechanism	Module Learning With Errors (MLWE)	Key exchange, TLS, VPN, email	128 / 192 / 256-bit (3 variants)
FIPS 204	ML-DSA (Dilithium)	Digital Signature	Module LWE + Short Integer Solution	Code signing, X.509 certs, auth tokens	128 / 192 / 256-bit (3 variants)
FIPS 205	SLH-DSA (SPHINCS+)	Digital Signature (hash-based)	Hash functions (SHA-256 / SHAKE)	High-assurance signing, PKI roots	128 / 192 / 256-bit
FIPS 206 (draft)	FN-DSA (FALCON)	Digital Signature	NTRU Lattice / Fast Fourier Lattice	IoT, constrained devices, TLS certs	128 / 256-bit

3.2 Algorithm Families: Technical Deep Dive

3.2.1 Lattice-Based Cryptography (Primary Recommendation)

Lattice-based schemes derive security from the hardness of problems in high-dimensional geometric lattices, most importantly the Learning With Errors (LWE) problem and its variants. Given many noisy linear equations over integers modulo q, recover the secret vector—no known classical or quantum algorithm does this efficiently.

ML-KEM (Kyber) is the primary key encapsulation mechanism. ML-KEM-768 targets NIST security level 3 (~192-bit classical, ~128-bit quantum), offers small key sizes relative to other PQC families, and has excellent performance. ML-DSA (Dilithium) is the primary signature algorithm using the "Fiat-Shamir with Aborts" technique—signatures are ~2.4–4.6 KB depending on security level.

Figure 4: Key, Ciphertext, and Signature Size Comparison

KEY & SIGNATURE SIZE COMPARISON (bytes) ==================================================================== Algorithm Public Key Private Key Signature / CT -------------------------------------------------------------------- RSA-2048 256 2,350 256 ECDSA P-256 64 32 64 -------------------------------------------------------------------- ML-KEM-512 800 1,632 768 (CT) ML-KEM-768 1,184 2,400 1,088 (CT) ML-KEM-1024 1,568 3,168 1,568 (CT) -------------------------------------------------------------------- ML-DSA-44 1,312 2,528 2,420 (sig) ML-DSA-65 1,952 4,000 3,293 (sig) ML-DSA-87 2,592 4,864 4,595 (sig) -------------------------------------------------------------------- SLH-DSA-128s 32 64 7,856 (sig) SLH-DSA-128f 32 64 17,088 (sig) -------------------------------------------------------------------- FALCON-512 897 1,281 666 (sig) FALCON-1024 1,793 2,305 1,280 (sig) ==================================================================== CT = ciphertext (KEM encapsulation) | sig = digital signature Source: NIST FIPS 203/204/205 specifications

Figure 4: PQC data size implications. Note the significant increase vs. classical algorithms — plan for this in TLS handshake budgets, certificate storage, and bandwidth-constrained environments.

3.2.2 Hash-Based Signatures (Highest Assurance)

Hash-based signature schemes like SPHINCS+ (SLH-DSA) derive security solely from the collision resistance and preimage resistance of hash functions (SHA-256, SHAKE-256). They have the longest cryptanalytic track record of any PQC family—hash functions have been studied for 40+ years. There are no algebraic assumptions to break; an attacker must find hash collisions.

The trade-off is signature size: SLH-DSA-128f produces ~17 KB signatures. This makes it unsuitable for high-frequency signing but ideal for root CA certificates, firmware signing, and code signing where verification is infrequent and long-term trust is paramount. The -s (small) variants reduce signatures at the cost of slower generation.

3.2.3 Code-Based Cryptography

Code-based cryptography, originating with McEliece (1978), relies on the hardness of decoding random linear error-correcting codes—believed NP-hard classically with no quantum speedup. McEliece has resisted cryptanalysis for over 45 years. The primary drawback is enormous public keys (~261 KB for Classic McEliece-348864). Important as a backup algorithm if lattice-based schemes are ever broken.

3.2.4 Multivariate Quadratic (MQ) Systems

MQ cryptography is based on solving systems of multivariate quadratic equations over finite fields (NP-hard in general). RAINBOW, a NIST candidate, was broken in 2022 by Ward Beullens using a classical attack, illustrating the risk of less-studied structures. No MQ scheme is among NIST's finalized standards. Not recommended for primary deployment.

3.3 Hybrid PQC Approach (Recommended Transition Strategy)

A hybrid approach combines a classical algorithm (e.g., ECDH X25519) with a post-quantum algorithm (e.g., ML-KEM-768). The combined shared secret provides security if either algorithm remains unbroken—critical during transition because PQC algorithms are newer and less battle-tested. Google Chrome, Cloudflare, and AWS have already deployed ECDH+ML-KEM hybrid in production TLS.

Figure 5: Hybrid TLS 1.3 Key Exchange Diagram

HYBRID TLS 1.3 KEY EXCHANGE (X25519 + ML-KEM-768) ==================================================================== Client Server | | |--- ClientHello ----------------------------------->| | key_share: [x25519_kyber768 hybrid group] | | (Classical ECDH share || ML-KEM public key) | | | |<-- ServerHello ------------------------------------| | key_share: [X25519 response || ML-KEM CT] | | | +-- Classical: ECDH(sk_client, pk_server) ----------+ +-- PQ: ML-KEM.Decaps(sk_client, CT) ---------------+ | | | Combined key: | | session_key = KDF(ECDH_secret || ML-KEM_secret) | | | |<-- CertificateVerify (ML-DSA-65 signature) --------| |<-- Finished ----------------------------------------| |--- Finished ---------------------------------------->| | | |<========== AES-256-GCM Encrypted Data ============>| SECURITY GUARANTEE: Broken ONLY if BOTH X25519 AND ML-KEM-768 are simultaneously compromised. Quantum-safe during transition.

Figure 5: Hybrid TLS 1.3 handshake. This is the recommended architecture for all external-facing services during the transition period.

3.4 PQC Migration Steps

Step 1: Cryptographic Inventory

Scan TLS endpoints: testssl.sh --full or sslyze --regular
Audit source code for crypto API calls: Semgrep rules for RSA, ECDSA, Cipher.getInstance("AES/CBC")
Enumerate certificates in all trust stores: keytool -list -keystore cacerts (Java), Windows Certificate Manager, macOS Keychain
Map HSMs and TPMs — many do not support PQC and require hardware replacement
Identify API token signing keys (OAuth/JWT), code signing keys, and SSH host keys

Step 2: Classify by Sensitivity and Longevity

Immediate priority: Data requiring confidentiality >5 years currently in transit over classical-encrypted channels
High priority: Authentication infrastructure (CA certs, code signing, PKI roots)
Medium priority: Internal service-to-service comms, VPN tunnels
Lower priority: Short-lived transactional data with no long-term sensitivity

Step 3: Pilot Hybrid Deployments

Deploy X25519+ML-KEM-768 on the highest-priority TLS endpoints as a canary. Monitor for performance regressions (larger key sizes add latency and handshake bytes) and interoperability issues with older clients.

Step 4: Update Certificate Lifecycle

Issue dual-algorithm certificates (classical + PQC) during transition. Update CA infrastructure to support PQC algorithm OIDs (ML-DSA, FALCON).

4. Quantum Key Distribution (QKD)

4.1 The Physics of QKD

Quantum Key Distribution is fundamentally different from PQC. Rather than relying on computational hardness, QKD derives security from the laws of quantum physics: the no-cloning theorem (a quantum state cannot be copied without disturbing it) and the Heisenberg uncertainty principle (measuring a quantum system inevitably disturbs it). This provides information-theoretic security—a QKD-derived key is secure regardless of an adversary's computational power, including unlimited quantum computing.

Figure 6: BB84 QKD Protocol Flow

BB84 QKD PROTOCOL — SIMPLIFIED FLOW ==================================================================== ALICE QUANTUM CHANNEL (fibre) BOB | | | Prepare photons in random polarisation basis: | | Basis: {+ (rectilinear), x (diagonal)} | | Bits: {0, 1} encoded as polarisation angle | | ------ individual photons --------------------------> | | | Bob measures | | in random basis | | |<---------- classical channel: compare bases --------->| | Discard mismatched-basis bits (~50% sifted out) | | | | Error rate check on random sample subset: | | QBER < 11%? --> No eavesdropper detected | | QBER > 11%? --> Key discarded; eavesdropping alert | | | | Error correction (CASCADE / LDPC protocol) | | Privacy amplification (universal hash compression) | | | +------------- Shared OTP / Session Key ----------------+ PRACTICAL KEY RATES (optical fibre): <= 100 km : 10 – 100 Kbps 100-200 km: 1 – 10 Kbps > 200 km : Requires quantum repeaters (not commercially available) ==================================================================== QBER = Quantum Bit Error Rate

Figure 6: The BB84 protocol. Security is information-theoretic. Any eavesdropping attempt introduces measurable statistical anomalies in the QBER, allowing detection.

4.2 Current QKD Limitations

Distance: Photon loss in optical fibre limits QKD to ~200 km without quantum repeaters (a research frontier with no commercial product as of 2025)
Key rate: QKD generates keys at kilobits per second—insufficient for direct encryption of high-bandwidth streams. QKD is used to exchange symmetric keys, not bulk data
Infrastructure cost: Requires dedicated quantum channels (dark fibre or free-space optical links), costing significantly more than standard internet infrastructure
Authentication dependency: QKD still requires a classically (or PQC) authenticated channel to prevent MITM attacks on the sifting phase
Side-channel attacks on hardware: Physical QKD devices have been attacked via detector blinding, time-shift attacks, and trojan-horse attacks. Device-Independent QKD (DI-QKD) addresses this but is not yet commercial

4.3 Practical QKD Deployment Scenarios

Banking: Toshiba, ID Quantique, and QuantumCTek have deployed QKD links between central banks and clearing houses in Tokyo, Geneva, and Beijing
Government/Defence: EU Quantum Flagship funds QKD networks between government ministries. China's Beijing-Shanghai QKD backbone (2,000 km via trusted nodes) carries government traffic
Cloud Data Centres: Feasible for securing metro-area inter-data-centre links. AWS and Azure have expressed interest
Satellite QKD: China's Micius satellite demonstrated satellite-to-ground QKD at 1,200 km (2017) and intercontinental QKD (China-Austria, 7,600 km) via trusted satellite node (2018). ESA's Eagle-1 satellite QKD mission targets ~2027-2028

4.4 QKD vs PQC: Complementary, Not Competing

QKD and PQC serve different roles. QKD provides information-theoretically secure key exchange for high-security fixed links. PQC provides computationally secure cryptography for the general internet. Recommended long-term architecture: QKD for high-value fixed links + PQC for general communications + AES-256 for bulk data encryption.

5. Data Protection Beyond Encryption

5.1 Data Classification for Quantum Risk

Tier 1 — Long-lived Crown Jewels (>10 years): State secrets, M&A strategies, genomic databases, treaty documents. Action: Encrypt with AES-256 today. Plan immediate PQC-protected re-encryption. Consider QKD for transmission.
Tier 2 — Medium-lived Sensitive (5-10 years): Financial records, health records, personnel files, IP. Action: Migrate to PQC-hybrid encryption within 2-3 years.
Tier 3 — Short-lived Transactional (<5 years): Session data, transient tokens. Action: Migrate as part of normal TLS/protocol upgrades.
Tier 4 — Public Data: Published content. Action: Use PQC for integrity/authentication even if confidentiality is less critical.

5.2 Forward Secrecy

Perfect Forward Secrecy (PFS) ensures that compromise of a long-term private key does not compromise past session keys. This is critical for quantum resilience: under HNDL attack, captured TLS sessions can only be decrypted if the session key exchange used static RSA (no forward secrecy) or classical ECDHE (ephemeral but Shor-vulnerable).

Action: Ensure all TLS deployments use ephemeral key exchange. Never use static RSA key exchange (TLS_RSA_* cipher suites). Verify with:

testssl.sh --forward-secrecy

All negotiated cipher suites must include DHE or ECDHE. For full quantum protection, they must include ML-KEM.

5.3 Secure Storage of Long-Term Data

Minimise long-term storage of sensitive data. Data you don't have can't be harvested.
Encrypt at rest with AES-256-GCM. Keep keys separate from data (HSM or cloud KMS).
Implement crypto-shredding: securely delete encryption keys when data must be destroyed. Without the key, the ciphertext is irrecoverable.
Re-encrypt archived data under AES-256 (if currently AES-128 or 3DES) as an immediate measure. Schedule PQC-protected key wrapping.

5.4 Network Segmentation and Data Minimisation

Micro-segmentation, zero-trust network access (ZTNA), and data residency policies that keep high-sensitivity data on isolated network segments reduce HNDL exposure. Air-gapped systems for the most sensitive classified data should remain air-gapped under all circumstances.

6. Enterprise-Level Preparedness

6.1 Quantum Risk Assessment Framework

Cryptographic asset inventory: All algorithms, key lengths, certificates, and protocols in use across the organisation
Data sensitivity mapping: Which assets require long-term confidentiality (Tier 1-4 classification)
Vendor and supply chain assessment: Do third-party systems (SaaS, IaaS, hardware) support PQC? Request roadmaps.
Regulatory compliance mapping: NIST SP 800-208, FIPS 203/204/205, BSI TR-02102, ANSSI guidance, NIS2 implications, NSA CNSA 2.0
Dependency mapping: Cryptographic dependencies between systems, APIs, and protocols (identify circular dependencies)

6.2 Migration Roadmap

Figure 7: Enterprise Quantum Migration Roadmap

Phase	Timeline	Key Actions	Success Metrics
Phase 0: Inventory & Awareness	Now — 6 months	Complete cryptographic inventory Conduct Quantum Risk Assessment Classify data by sensitivity/longevity Assign ownership and budget Train security team on PQC fundamentals	100% asset coverage; QRA report delivered to board
Phase 1: Immediate Hardening	6 — 18 months	Disable static RSA key exchange everywhere Upgrade all AES-128 to AES-256 Deploy hybrid PQC on highest-risk external TLS endpoints Implement crypto agility framework Begin CA infrastructure PQC planning	Zero static RSA TLS sessions; AES-256 universally deployed
Phase 2: PQC Transition	18 months — 3 years	Deploy hybrid ML-KEM + X25519 for all external TLS Issue dual-algorithm certificates (classical + ML-DSA) Migrate VPN gateways to PQC-hybrid IKEv2/IPSec Update SSH to post-quantum KEX (sntrup761x25519) Migrate code signing to ML-DSA or SPHINCS+ Re-encrypt Tier 1 archived data under AES-256 with PQC key wrapping	90% of external TLS using hybrid PQC; code signing migrated
Phase 3: Full PQC Deployment	3 — 5 years	Deprecate classical-only key exchange across all systems Complete internal service-to-service PQC migration Migrate PKI roots to SLH-DSA (SPHINCS+) Evaluate QKD for highest-value fixed links Update identity systems (MFA tokens, hardware keys) to PQC	100% PQC-hybrid or pure PQC; classical asymmetric deprecated
Phase 4: Quantum-Native	5 — 10 years	Remove classical asymmetric algorithms entirely Evaluate pure PQC (non-hybrid) based on cryptanalytic maturity Deploy QKD for government/defence fixed links Continuous monitoring for new cryptanalytic results	Fully quantum-resistant posture; classical asymmetric absent

6.3 Governance Updates

Update Cryptography Policy to deprecate RSA <4096, ECDHE P-224/P-256 for long-lived contexts, AES-128, MD5, SHA-1, 3DES
Publish a Quantum Migration Policy with timelines, owners, and compliance checkpoints
Include quantum risk in the enterprise risk register with quantified likelihood and impact
Assign a Quantum Security Owner under the CISO
Update vendor contracts to require PQC roadmap commitments from critical technology suppliers
Align with NSA CNSA 2.0 for national security systems

7. Quantum-Era Attack Scenarios: Detailed Models

7.1 TLS/HTTPS Traffic Decryption (HNDL)

Scenario: A nation-state adversary (APT-Q) has been passively intercepting and archiving TLS 1.2 sessions protected by ECDHE-RSA cipher suites at major internet exchange points since 2021. In 2031, APT-Q gains CRQC access.

Figure 8: Post-Quantum TLS Decryption Attack Model

TLS 1.2 ECDHE-RSA POST-QUANTUM DECRYPTION ATTACK ==================================================================== CAPTURED PACKET (2023): ClientHello: cipher = TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ServerHello: server_cert (RSA-2048, signed by public CA) ServerKeyExch: ECDHE params + RSA signature over them ClientKeyExch: ECDH ephemeral public key (32 bytes, P-256) ATTACK STEPS (2031, CRQC available): 1. Extract server RSA-2048 public key from archived certificate 2. Run Shor's algorithm on RSA modulus --> Recover RSA-2048 private key [est. 8 hours on CRQC] 3. Use recovered RSA key to verify/extract ECDHE server parameters 4. Extract client ephemeral ECDH public key from ClientKeyExchange 5. Run Shor's algorithm on P-256 elliptic curve discrete log --> Recover ephemeral ECDH private key [est. 1 hour per session] 6. Compute shared ECDH secret --> Derive master secret --> Derive session keys (AES-128-GCM) 7. Decrypt all captured application data for this TLS session RESULT: Full plaintext recovery of 2023 HTTPS sessions at scale. ==================================================================== COUNTERMEASURE: Deploy TLS 1.3 with X25519Kyber768 hybrid key exchange. Even if Shor breaks X25519, ML-KEM-768 session key remains secure.

7.2 Digital Signature Forgery

Scenario: An adversary uses a CRQC to derive the ECDSA private signing key from a software vendor's public code signing certificate, then forges signatures on malicious update packages.

Target: Software vendor using ECDSA P-256 for Authenticode / codesign
Attack: Apply Shor's algorithm to vendor's public ECDSA key → recover private signing key in hours
Exploitation: Sign malicious DLL/EXE with recovered key → passes OS signature verification → auto-deployed via update infrastructure to millions of endpoints
Scale: One recovered private key compromises the entire installed base of that vendor's software
Mitigation: Migrate code signing to ML-DSA-65 or SLH-DSA-128s. Use HSMs storing post-quantum signing keys to prevent key extraction.

7.3 API Token and JWT Hijacking

Modern OAuth 2.0 / OpenID Connect flows use RS256 (RSA-PKCS1v1.5-SHA256) or ES256 (ECDSA-P256-SHA256) to sign JWTs. An adversary who archives JWTs and recovers the signing key via CRQC can forge arbitrary tokens with elevated privileges.

Figure 9: JWT Forgery Attack Flow

JWT FORGERY ATTACK ==================================================================== 1. HARVEST PHASE (Today): Adversary captures OAuth JWTs from intercepted API traffic: Header: { "alg": "RS256", "kid": "auth-key-2023-01" } Payload: { "sub": "user_12345", "roles": ["user"], "exp": 1704067200 } Signature: [RSA-SHA256 over header.payload] 2. KEY RECOVERY PHASE (Post-CRQC): a. Fetch auth server JWKS endpoint (public key is public!) GET https://auth.example.com/.well-known/jwks.json b. Extract RSA-2048 public key "n" and "e" parameters c. Apply Shor's algorithm --> recover RSA private signing key 3. FORGERY PHASE: Forge new JWT with elevated privileges: { "sub": "system_admin", "roles": ["superadmin", "billing"], "exp": 9999999999 } Sign with recovered RSA private key --> valid RS256 signature Use forged token to access any API endpoint indefinitely COUNTERMEASURES: - Migrate JWT signing to ML-DSA-44 or Ed25519+ML-DSA hybrid - Short token lifetimes (<15 minutes) reduce harvest value - Token binding to client TLS certificate (RFC 8705) - JWK rotation with crypto agility (support algorithm transitions)

7.4 VPN Breaches

Enterprise VPNs using IKEv1 or IKEv2 with classical ECDH/DH key exchange and RSA authentication are identically vulnerable to HNDL. An adversary archiving IKE handshakes and ESP-encrypted payloads today can decrypt all captured VPN traffic post-CRQC, exposing internal network communications, database queries, file transfers, jump server sessions, and internal application traffic.

Mitigation: RFC 9370 (Multiple Key Exchanges in IKEv2) defines hybrid PQC extensions. StrongSwan and OpenVPN have experimental ML-KEM support. Prioritise migration for VPNs protecting the most sensitive internal communications.

7.5 Blockchain and Cryptocurrency Wallet Attacks

Blockchain networks (Bitcoin, Ethereum) use ECDSA secp256k1 for transaction signing. Quantum attacks threaten these in two phases:

Exposed public key attack: For addresses where the public key has been revealed (all P2PK outputs; P2PKH outputs that have made at least one spend), a CRQC can recover the private key and drain the wallet. Bitcoin holdings in exposed-public-key addresses are estimated at 5-10% of total supply.
Address pre-image attack: For unspent P2PKH outputs (public key not yet revealed), Grover's algorithm could attack the hash—computationally harder and less immediate, but a long-term risk.

No major blockchain has deployed quantum-resistant signatures as of 2025. BIP-360 (P2QRH) proposes SPHINCS+ or FALCON for Bitcoin. The Ethereum community has EIP proposals for PQC address migration.

7.6 Research-Based Attack Models

7.6.1 Side-Channel + Quantum Hybrid Attacks

Even PQC algorithms can be vulnerable to side-channel attacks if poorly implemented. Research by Ravi et al. (2020) demonstrated power analysis attacks against CRYSTALS-Kyber implementations on ARM Cortex-M4, recovering secret keys from physical power traces. Hybrid attacks—using classical side-channel techniques (timing, power, electromagnetic) to extract partial information, then quantum computation to complete key recovery—could be devastating against poorly protected PQC implementations. Countermeasure: Constant-time implementations; PQC deployed in certified HSMs with physical side-channel countermeasures.

7.6.2 Supply Chain HNDL via Network Implants

Nation-states may gain CRQC access significantly before public knowledge. Supply chain implants in network equipment—routers, switches, TAP devices—could silently forward encrypted traffic to state collection infrastructure. The 2023 Cisco IOS XE zero-day (CVE-2023-20198) and historical Juniper backdoor incidents illustrate that network infrastructure is a viable supply chain attack vector. Countermeasure: Network device firmware integrity verification; hardware attestation (TPM 2.0); anomaly detection for unexpected data exfiltration.

7.6.3 Quantum Oracle Attacks on PQC

Some PQC schemes are vulnerable to chosen-ciphertext attacks if their decryption oracle can be accessed in quantum superposition (quantum chosen-ciphertext attacks, qCCA). NIST's PQC selection process required IND-CCA2 security. Organisations should monitor IACR ePrint archives for new cryptanalytic results against deployed PQC algorithms as the field matures.

8. Defensive Architecture for the Quantum Era

8.1 Crypto Agility: The Most Critical Architectural Property

Crypto agility is the ability to rapidly switch cryptographic algorithms without significant re-engineering. The history of cryptography is filled with algorithms that seemed secure and were later broken (MD5, SHA-1, DES, RC4, WEP). Organisations with crypto-agile systems can respond to a broken algorithm within hours. Those who hardcoded their crypto cannot.

Design patterns for crypto agility:

Algorithm abstraction layers: All cryptographic operations go through a centralised crypto API that maps algorithm identifiers to implementations. Changing the mapping requires no application code changes.
Negotiated algorithm suites: TLS, IKE, and SSH already support algorithm negotiation. Ensure configurations enable multiple algorithm options and that compromised ones can be rapidly disabled.
Algorithm OID registries: Maintain an internal registry of all algorithm OIDs in use across certificates, JWTs, and protocols. Enables rapid audit and replacement.
Configuration-driven key sizes: Key sizes, hash algorithms, and signature algorithms should be read from configuration, not compiled into application binaries.

8.2 Hybrid TLS Configuration (Production Example)

Figure 10: Nginx Hybrid TLS 1.3 Configuration with PQC

# Nginx configuration: Hybrid Post-Quantum TLS 1.3 # Requirements: OpenSSL 3.x compiled with OQS provider (liboqs) http { server { listen 443 ssl; # ML-DSA-65 certificate and key (replaces ECDSA cert) ssl_certificate /etc/ssl/certs/server-mldsa.crt; ssl_certificate_key /etc/ssl/private/server-mldsa.key; # TLS 1.3 ONLY -- older versions are quantum-vulnerable ssl_protocols TLSv1.3; # Hybrid key exchange groups ordered by preference: # x25519_kyber768 = X25519 + ML-KEM-768 hybrid (RECOMMENDED) # kyber1024 = pure ML-KEM-1024 (higher assurance) # x25519 = fallback for incompatible clients ssl_ecdh_curve x25519_kyber768:kyber1024:x25519:secp384r1; # AES-256-GCM and ChaCha20 only (256-bit symmetric, quantum-safe) ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256; # Disable session tickets (prevents session key caching) ssl_session_tickets off; # Short session cache timeout ssl_session_timeout 1m; # OCSP stapling ssl_stapling on; ssl_stapling_verify on; # HSTS: 2 years, all subdomains add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; } } # VERIFICATION: # Test hybrid key exchange is negotiated: # openssl s_client -connect yourhost:443 -groups x25519_kyber768 # Expected output: "Server Temp Key: X25519Kyber768, ..." # # Test with testssl.sh: # testssl.sh --pfs --cipher-per-proto yourhost:443

Figure 10: Production Nginx configuration for hybrid PQC TLS. The x25519_kyber768 group provides quantum-resistant key exchange while maintaining interoperability.

8.3 Secure Key Management: HSMs and Rotation

HSMs: Use FIPS 140-3 Level 3+ certified HSMs for all long-lived private keys. Thales Luna, Entrust nShield, AWS CloudHSM, and Azure Dedicated HSM are evaluating PQC algorithm support. Verify PQC support before procurement.
Key rotation schedules: CA intermediate certs: 2-3 years; leaf certs: 90 days; session keys: per-connection. Shorter rotation windows limit HNDL exposure window.
Key escrow: Do not escrow ML-KEM-1024 keys under RSA-2048 wrapping — this negates the quantum protection.
Threshold cryptography: For high-value key material, use threshold schemes (Shamir Secret Sharing, MPC) so no single compromise yields a usable key.

8.4 Zero Trust Architecture with PQC

Zero Trust (NIST SP 800-207) assumes no implicit trust and verifies every request. Under quantum threat, ZTA's cryptographic foundations (mTLS, JWT/OIDC, PKI device certificates) must be quantum-hardened:

Device certificates: All 802.1X and mTLS client certificates must migrate to ML-DSA or FALCON
Policy enforcement: Update policy engine to deny connections using classical-only key exchange. Log and alert on downgrade attempts
Short-lived credentials: SPIFFE/SVID certificates rotating every hour dramatically reduce HNDL value even before full PQC migration
Identity provider migration: Evaluate PQC roadmaps for Okta, Entra ID, Ping Identity — require ML-DSA support for OIDC signing keys

9. Developer-Level Implementation Guide

9.1 PQC Libraries: Practical Choices

Figure 11: Post-Quantum Cryptography Libraries (2025)

Library	Language	Algorithms	Maturity	Notes
liboqs (Open Quantum Safe)	C + bindings: Python, Go, Java, .NET, Rust	ML-KEM, ML-DSA, SLH-DSA, FALCON, HQC, McEliece	Experimental/Research	Reference implementation; not FIPS certified. Excellent for prototyping and integration testing.
OpenSSL 3.x + OQS Provider	C + all OpenSSL language bindings	All NIST PQC finalists via provider plugin	Experimental	Drop-in PQC support for existing OpenSSL applications. Hybrid TLS groups (X25519Kyber768) supported.
BouncyCastle PQC module	Java, C#	ML-KEM, ML-DSA, SLH-DSA, FALCON, NTRU	Production-ready	Well-tested, widely used in enterprise Java. FIPS mode available.
PQClean	C	All NIST candidates, clean portable implementations	Reference	Focus on clean, auditable code. Not optimised for performance. Good for security review.
AWS-LC (aws-lc)	C	ML-KEM, ML-DSA, hybrid TLS groups	Production	AWS's fork of BoringSSL with PQC support. Used in AWS services production.
wolfSSL / wolfCrypt	C (embedded focus)	ML-KEM, ML-DSA, FALCON	Production (IoT)	FIPS 140-3 certified. Ideal for constrained devices, RTOS, automotive.

9.2 Code Examples

Example 1: ML-KEM-768 Key Encapsulation (Python / liboqs)

# Install: pip install liboqs-python # Requires: liboqs compiled and on PATH (https://github.com/open-quantum-safe/liboqs) import oqs from cryptography.hazmat.primitives.kdf.hkdf import HKDF from cryptography.hazmat.primitives import hashes KEM_ALG = "Kyber768" # NIST standardised as ML-KEM-768 (FIPS 203) # ─── KEY GENERATION (Alice / Server) ──────────────────────────── with oqs.KeyEncapsulation(KEM_ALG) as alice: public_key = alice.generate_keypair() print(f"Public key : {len(public_key)} bytes") # → 1,184 bytes # ─── ENCAPSULATION (Bob / Client) ─────────────────────────── # Bob uses Alice's public key to encapsulate a shared secret with oqs.KeyEncapsulation(KEM_ALG) as bob: ciphertext, shared_secret_bob = bob.encap_secret(public_key) print(f"Ciphertext : {len(ciphertext)} bytes") # → 1,088 bytes print(f"Shared secret: {len(shared_secret_bob)} bytes") # → 32 bytes # ─── DECAPSULATION (Alice) ──────────────────────────────────── shared_secret_alice = alice.decap_secret(ciphertext) assert shared_secret_alice == shared_secret_bob print("Shared secrets match ✓") # ─── DERIVE SESSION KEY VIA HKDF ──────────────────────────────── session_key = HKDF( algorithm=hashes.SHA384(), length=32, salt=None, info=b"app-session-v1" ).derive(shared_secret_alice) print(f"AES-256 session key: {session_key.hex()}") # Use this key with AES-256-GCM for all subsequent symmetric encryption

Example 2: ML-DSA-65 Digital Signature (Python / liboqs)

import oqs SIG_ALG = "Dilithium3" # NIST standardised as ML-DSA-65 (FIPS 204) # ─── SIGNING ───────────────────────────────────────────────────── with oqs.Signature(SIG_ALG) as signer: public_key = signer.generate_keypair() print(f"Public key : {len(public_key)} bytes") # → 1,952 bytes message = b"Firmware v3.1.0 — authorised release — SHA384: abc123..." signature = signer.sign(message) print(f"Signature : {len(signature)} bytes") # → 3,293 bytes # Persist public key to certificate / trust store with open("signing_pubkey_mldsa65.bin", "wb") as f: f.write(public_key) # ─── VERIFICATION ──────────────────────────────────────────────── with oqs.Signature(SIG_ALG) as verifier: with open("signing_pubkey_mldsa65.bin", "rb") as f: pub = f.read() is_valid = verifier.verify(message, signature, pub) print(f"Valid : {is_valid}") # → True # Tamper test tampered = message + b"INJECTED_PAYLOAD" print(f"Tampered: {verifier.verify(tampered, signature, pub)}") # → False

Example 3: Hybrid X25519 + ML-KEM-768 Key Exchange (Production Pattern)

""" Hybrid key exchange: X25519 (classical) + ML-KEM-768 (PQC). Security holds if EITHER algorithm is unbroken. Mirrors the X25519Kyber768 hybrid used in Chrome/Cloudflare TLS. """ import oqs import os from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey from cryptography.hazmat.primitives.kdf.hkdf import HKDF from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.ciphers.aead import AESGCM KEM_ALG = "Kyber768" KDF_INFO = b"hybrid-x25519-kyber768-session-v1" # ─── ALICE: Generate hybrid key pair ───────────────────────────── alice_x25519_priv = X25519PrivateKey.generate() alice_x25519_pub = alice_x25519_priv.public_key() alice_kem = oqs.KeyEncapsulation(KEM_ALG) alice_kyber_pub = alice_kem.generate_keypair() # Alice broadcasts: alice_x25519_pub + alice_kyber_pub # ─── BOB: Encapsulate shared secrets ───────────────────────────── bob_x25519_priv = X25519PrivateKey.generate() bob_x25519_pub = bob_x25519_priv.public_key() # Classical ECDH ecdh_secret_bob = bob_x25519_priv.exchange(alice_x25519_pub) # PQC KEM with oqs.KeyEncapsulation(KEM_ALG) as bob_kem: kyber_ct, kyber_secret_bob = bob_kem.encap_secret(alice_kyber_pub) # Combine both secrets via HKDF-SHA384 combined_bob = ecdh_secret_bob + kyber_secret_bob session_key_bob = HKDF( algorithm=hashes.SHA384(), length=32, salt=None, info=KDF_INFO ).derive(combined_bob) # Bob sends: bob_x25519_pub + kyber_ct # ─── ALICE: Decapsulate to recover session key ──────────────────── ecdh_secret_alice = alice_x25519_priv.exchange(bob_x25519_pub) kyber_secret_alice = alice_kem.decap_secret(kyber_ct) combined_alice = ecdh_secret_alice + kyber_secret_alice session_key_alice = HKDF( algorithm=hashes.SHA384(), length=32, salt=None, info=KDF_INFO ).derive(combined_alice) assert session_key_alice == session_key_bob, "Key mismatch!" print("Hybrid session keys match ✓") # ─── USE SESSION KEY FOR AES-256-GCM ENCRYPTION ────────────────── aes = AESGCM(session_key_alice) nonce = os.urandom(12) # 96-bit random nonce payload = b"Quantum-resistant encrypted payload" ct = aes.encrypt(nonce, payload, None) pt = aes.decrypt(nonce, ct, None) assert pt == payload print(f"Encrypted: {ct.hex()[:48]}...") print("Decrypted successfully ✓") # IMPORTANT: Clean up KEM objects alice_kem.free()

Example 4: Checking TLS Forward Secrecy and PQC (bash / testssl)

#!/bin/bash # Audit TLS configuration for quantum readiness # Install: https://testssl.sh TARGET="yourdomain.com:443" echo "=== TLS Protocol Check ===" testssl.sh --protocols $TARGET echo "=== Forward Secrecy Check ===" testssl.sh --pfs $TARGET # LOOK FOR: cipher suites with DHE or ECDHE # AVOID: TLS_RSA_* (no forward secrecy — quantum-catastrophic) echo "=== PQC Key Exchange Check ===" # Test if server accepts X25519Kyber768 hybrid group openssl s_client -connect $TARGET \ -groups x25519_kyber768 \ -tls1_3 2>&1 | grep "Server Temp Key" # Expected: "Server Temp Key: X25519Kyber768, ..." echo "=== Cipher Suite Strength ===" testssl.sh --cipher-per-proto $TARGET # LOOK FOR: AES-256 or ChaCha20 in all negotiated suites # FLAG: any AES-128 cipher suite echo "=== Certificate Algorithm ===" echo | openssl s_client -connect $TARGET 2>/dev/null \ | openssl x509 -noout -text \ | grep -E "Public Key Algorithm|Signature Algorithm|Public-Key:" # Current: rsaEncryption (2048 bit) or id-ecPublicKey # Target: id-ML-DSA or id-FALCON (post-migration)

9.3 Algorithm Recommendations Summary

AES-256-GCM: Preferred AEAD cipher. 256-bit key = ~128-bit quantum security. Use random 96-bit nonces; never reuse nonces. Authenticate all associated data.
AES-128: Deprecated for data requiring >5-year confidentiality. Acceptable for short-lived session data today only; migrate on schedule.
SHA-384 / SHA-512: Preferred for all new hashing. SHA-256 retains ~128-bit quantum security but SHA-384 provides more margin.
SHA-3 family: SHA3-256/384/512 are quantum-resilient with different structural assumptions from SHA-2 (useful for defence-in-depth).
HMAC-SHA-384: Preferred for new applications. HMAC-SHA-256 provides ~128-bit quantum security (acceptable).
Argon2id: Password hashing is less impacted by quantum. Argon2id with 64MB+ memory and t=3 iterations remains appropriate.

9.4 Anti-Patterns to Avoid

❌ Long-lived encrypted blobs under single keys: Re-encryption on key rotation becomes operationally impossible at scale. Use key wrapping with short rotation.
❌ Hardcoded algorithm identifiers: if alg == "RSA": prevents rapid algorithm replacement. Use configurable algorithm registries.
❌ Logging encrypted payloads: Encrypted bodies in debug logs are harvestable. Minimise sensitive data in any log store.
❌ Static RSA-wrapped symmetric keys: A common file encryption pattern where a symmetric key is RSA-wrapped and stored alongside the file. A CRQC recovers the RSA private key, unwraps all symmetric keys, decrypts all files. Use ML-KEM wrapping instead.
❌ Long-lived JWTs with ECDSA signing: 24h+ expiry JWTs signed with ES256 are both a signature forgery risk (post-CRQC) and an HNDL exposure window. Use short-lived tokens (<15 min) and ML-DSA signing.
❌ P2PK address reuse in blockchain: Reusing addresses in Bitcoin/Ethereum exposes public keys, making private key recovery via Shor trivial on a CRQC.

10. Research Directions and Emerging Technologies

10.1 Post-Quantum TLS Standardisation

draft-ietf-tls-hybrid-design: Formalises hybrid key exchange in TLS 1.3. Google's X25519Kyber768 (IANA group 0x6399) deployed in Chrome and Cloudflare since 2023.
RFC 9420 (MLS): Messaging Layer Security uses X25519Kyber768 hybrid for scalable group messaging. Deployed in secure messaging applications.
Certificate size compression: RFC 8879 (TLS Certificate Compression) and research on certificate chain compression will be necessary to manage ML-DSA's larger signatures in TLS handshakes.
Post-quantum QUIC: HTTP/3 over QUIC will need PQC integration at the QUIC handshake level.

10.2 Quantum-Resistant Blockchains

Bitcoin BIP-360 (P2QRH): Proposes Taproot-compatible addresses using SPHINCS+ or FALCON. Not yet accepted by the Bitcoin Core community.
Ethereum PQC EIPs: Multiple EIP proposals discuss EVM changes for PQC signature verification. Migration is complicated by Ethereum's account model and account abstraction (ERC-4337).
IOTA: Uses Winternitz OTS, a hash-based scheme—one of the few production blockchains with quantum-resistant signatures (with address reuse limitations).
Post-quantum ZK proofs: STARKs (hash-based) are more quantum-resilient than pairing-based SNARKs. StarkNet and other STARK-based L2s have better quantum posture than zk-SNARK systems.

10.3 Satellite QKD Developments

Micius (China, 2016-present): Demonstrated 1,200 km satellite-to-ground QKD and 7,600 km intercontinental QKD (China-Austria) via trusted satellite node.
Eagle-1 (ESA/EU, ~2027-2028): European sovereign QKD satellite targeting secure links between EU member state capitals. Part of EuroQCI (European Quantum Communication Infrastructure).
SpeQtral (Singapore): Commercial QKD satellite startup targeting Asia-Pacific government and financial services customers.
Free-space QKD challenges: Atmospheric turbulence, daylight noise, and weather dependence limit availability. Adaptive optics and higher-altitude LEO orbits are active research areas. Day-time satellite QKD was first demonstrated by Micius in 2021.

10.4 Quantum-Safe Identity and Authentication

FIDO2/WebAuthn PQC: The FIDO Alliance is adding PQC algorithm support. Future YubiKey and Titan security keys will incorporate ML-DSA or FALCON for authentication signatures.
Post-quantum PKI: ISRG (Let's Encrypt) and DigiCert are evaluating ML-DSA for intermediate and leaf certificate signing. NIST has issued draft guidance on post-quantum X.509 profiles.
Post-quantum OPAQUE (PAKE): OPAQUE, an asymmetric PAKE resistant to server compromise, is being adapted for PQC. Classical DH-based PAKEs are fully quantum-vulnerable.
Decentralised Identity (DID): W3C DID specifications need PQC verification methods. Early proposals for DID Method with ML-DSA verification keys are circulating in standards bodies.
Quantum-safe biometric systems: Binding biometric authentication to PQC-signed credentials via secure enclaves (Intel TDX, AMD SEV-SNP) for quantum-safe biometric identity at the hardware level.

10.5 CRQC Development Timeline (Research Consensus)

Figure 15: Estimated Quantum Computing Threat Timeline

CRYPTOGRAPHICALLY RELEVANT QUANTUM COMPUTER (CRQC) TIMELINE (Research community consensus, 2024) ==================================================================== NISQ Era Noisy Intermediate-Scale Quantum (100–1,000 (Today, 2024-2026) physical qubits, high error rates). NOT a threat to cryptography. Use: chemistry simulation, optimisation research. -------------------------------------------------------------------- Early FTQC Era Early fault-tolerant quantum computers. (~2027-2030) Thousands of logical qubits. Possible: break small key sizes (512-bit RSA). Nation-state access may exist (classified). -------------------------------------------------------------------- CRQC Era Millions of high-fidelity logical qubits. (~2030-2035, Can break RSA-2048 and ECC-256 in hours/days. median estimate) Organisations without PQC migration are fully exposed to retroactive HNDL decryption. -------------------------------------------------------------------- Post-CRQC CRQC broadly accessible to well-funded actors. (2035+) Classical asymmetric cryptography effectively dead. Only PQC + symmetric cryptography remain viable. ==================================================================== KEY UNCERTAINTY: Timeline could be 2028 (optimistic) or 2040 (pessimistic). CRITICAL: HNDL attacks are INDEPENDENT of the CRQC timeline. They are happening RIGHT NOW. Sources: NIST IR 8413, GlobalRisk Institute Quantum Threat Timeline Report 2023, IBM Quantum Roadmap 2024, NSA CNSA 2.0.

11. Conclusion

11.1 The Case for Acting Now

The quantum computing threat to cryptography is not a hypothetical future risk—it is an active, present danger with one foot already through the door. Through Harvest Now, Decrypt Later attacks, adversaries are harvesting encrypted data today with the explicit intention of decrypting it when cryptographically relevant quantum computers become available. Every day that organisations delay PQC migration is another day of sensitive data exposure that cannot be retroactively fixed. There is no patch for data that has already been intercepted.

NIST has finalised its PQC standards (FIPS 203, 204, 205). The US federal government has mandated migration timelines under NSA CNSA 2.0. The EU's NIS2 Directive and forthcoming eIDAS 2.0 updates will require quantum-resistant cryptography for critical infrastructure. The standardisation work is done. The regulatory pressure is mounting. The cryptographic libraries are available. The only remaining question is whether your organisation will lead the migration—or be caught unprepared.

11.2 Immediate Actionable Steps

For organisations:

✅ This week: Brief your CISO and board on quantum risk using the HNDL threat model. Frame it as a present operational risk, not a future technology concern.
✅ This month: Launch a cryptographic inventory project. Use automated scanning tools to enumerate all asymmetric algorithm usage across your estate.
✅ This quarter: Disable all static RSA key exchange in TLS. Enforce PFS universally. Upgrade AES-128 to AES-256 everywhere.
✅ This year: Pilot hybrid X25519+ML-KEM-768 TLS on high-sensitivity endpoints. Evaluate HSM vendor PQC roadmaps. Publish internal quantum migration policy.
✅ 2-3 years: Full hybrid PQC deployment for TLS, VPN, code signing. CA infrastructure migration. Re-encryption of Tier 1 archived data.

For developers:

✅ Now: Implement crypto agility in all new code. Never hardcode algorithm identifiers.
✅ Now: Use AES-256-GCM and SHA-384/512 for all new development. Do not ship new code using AES-128.
✅ Now: Prototype with liboqs or BouncyCastle PQC to understand integration challenges before production urgency strikes.
✅ Now: Shorten JWT/token lifetimes to <15 minutes. Implement short-lived certificate rotation via ACME or SPIFFE/SVID.
✅ Soon: Add ML-KEM hybrid to your key exchange layer. Add ML-DSA to your signing infrastructure.
✅ Always: Monitor IACR ePrint and NIST PQC announcements for new cryptanalytic results that could affect your chosen algorithms.

11.3 Forward-Looking Statement

The quantum revolution in computing is not coming—it is already underway. Governments have classified programs. Companies are racing toward fault-tolerant systems. The mathematics is settled: classical public-key cryptography will not survive large-scale quantum computing. What separates organisations that will weather this transition from those that will suffer catastrophic breaches is not brilliance or luck—it is preparation, begun today.

Post-quantum cryptography gives us the tools. The NIST standards are published. The libraries are available. The migration patterns are understood. The only ingredient missing in most organisations is urgency. Those who treat quantum preparedness as a 2035 problem will find themselves in 2031 explaining to regulators, customers, and shareholders why years of their most sensitive communications were quietly harvested and are now being read in plaintext.

The quantum-safe future is not built in a single sprint or a single fiscal year. It is built through the accumulation of disciplined decisions: an inventory completed, a policy updated, a library migrated, a developer trained, a certificate reissued. Start today. The cryptographic infrastructure you leave unpatched is someone else's future plaintext.

"Organisations that have not yet started planning for post-quantum cryptography are already behind. The time to act is before the threat materialises—not after."

— CISA, NSA, NIST Joint Guidance on Quantum Readiness, 2023