Quantum computers capable of running Shor's algorithm at scale would break the public-key cryptography that underpins virtually all current secure communications: RSA, Elliptic Curve Cryptography (ECC), and Diffie-Hellman key exchange would all become insecure. For defence systems, this is not a hypothetical future problem to be addressed eventually — it is a known threat with a credible timeline that requires active preparation now.

The "harvest now, decrypt later" (HNDL) attack strategy means that adversaries are already collecting encrypted defence communications today, storing them for decryption once a sufficiently capable quantum computer becomes available. Long-lived classified information — strategic plans, intelligence sources and methods, capability assessments — is particularly at risk: if it is encrypted today with algorithms that will be broken by 2035, its secrecy has an effective expiration date.

The Quantum Threat: Timeline Estimates

Shor's algorithm, developed in 1994, provides a polynomial-time method for factoring large integers — the mathematical foundation of RSA security — when run on a sufficiently large quantum computer. Shor's algorithm also solves the discrete logarithm problem underlying ECC and Diffie-Hellman. A quantum computer large enough to run Shor's algorithm against current key sizes (2048-bit RSA, 256-bit ECC) requires millions of logical qubits with very low error rates — well beyond current hardware capability.

The most credible public estimates for a "cryptographically relevant quantum computer" (CRQC) — one large enough to break currently deployed public-key cryptography — range from 2030 to 2035, with significant uncertainty in both directions. NSA's 2022 CNSA 2.0 advisory does not endorse a specific timeline but uses 2035 as the planning horizon for systems that need post-quantum protection. Some intelligence assessments are more aggressive. The appropriate posture for defence programs is to prepare for CRQC availability by 2030 — the conservative end of the range — rather than the midpoint or optimistic end.

NSA CNSA 2.0: Mandated Algorithms and Transition Requirements

The Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), published by NSA's Cybersecurity Directorate in September 2022, specifies the cryptographic algorithms approved for protecting National Security Systems (NSS) in the post-quantum era. CNSA 2.0 replaces CNSA 1.0 and mandates the following post-quantum algorithms:

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), standardized as FIPS 203 and based on the CRYSTALS-Kyber algorithm, is the approved key establishment algorithm. ML-KEM replaces RSA and ECDH for key exchange in protocols such as TLS. Three parameter sets are defined: ML-KEM-512 (security level equivalent to AES-128), ML-KEM-768 (AES-192), and ML-KEM-1024 (AES-256). CNSA 2.0 specifies ML-KEM-1024 for NSS applications.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardized as FIPS 204 and based on CRYSTALS-Dilithium, is the approved digital signature algorithm for most applications, replacing RSA-PSS and ECDSA. ML-DSA provides signature security with smaller key sizes than hash-based alternatives and relatively fast signing and verification operations.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), standardized as FIPS 205 and based on SPHINCS+, is an alternative digital signature algorithm with security based on hash functions rather than lattice mathematics — providing security diversity in case lattice-based cryptography is weakened by future mathematical advances. SLH-DSA has significantly larger signature sizes and slower operations than ML-DSA but is appropriate for applications where lattice-based algorithms are not permitted or where additional security diversity is required.

CNSA 2.0 transition timeline: NSA requires that new National Security Systems deployed from 2025 onward must support CNSA 2.0 algorithms. Existing systems have a phased migration timeline with intermediate milestones and a hard deadline of 2030 for completing the transition. Systems that cannot be migrated by 2030 must have approved exception or replacement plans.

Impact on Defence Software: TLS, Firmware, and PKI

TLS 1.3 with post-quantum KEM. The most immediately impactful change is the replacement of TLS key exchange algorithms. TLS 1.3, the current standard for encrypted web and API communications, uses ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for key establishment. Under CNSA 2.0, this must be replaced with or augmented by ML-KEM. The IETF has published RFC 9180 and related drafts for PQC key encapsulation in TLS. Major TLS libraries (OpenSSL, BoringSSL) have implemented experimental PQC cipher suite support; production-grade support is maturing rapidly.

Digital signatures on firmware. Weapon systems and military hardware platforms use digital signatures to verify firmware integrity — the cryptographic assurance that firmware has not been tampered with between manufacture and deployment. These signatures are long-lived (the signing key may be used for the entire production life of a platform, 10–20 years) and are therefore at higher risk from HNDL attacks. CNSA 2.0 specifies that firmware signing for NSS hardware should transition to ML-DSA or SLH-DSA.

PKI migration. Defence PKI infrastructure — certificate authorities, certificate revocation infrastructure, certificate management for users, devices, and services — uses RSA or ECC keys throughout. Migrating the PKI means not only issuing new post-quantum certificates but retiring old certificates, distributing new trust anchors to all relying systems, and ensuring that all software that validates certificates can process post-quantum certificate formats. This is a complex, multi-year infrastructure migration that must begin now to meet the 2030 deadline.

Hybrid Approach During Transition

During the transition period, when systems are partly migrated and must interoperate with both CNSA 1.0 and CNSA 2.0 counterparts, a hybrid cryptography approach combines classical and post-quantum algorithms in the same protocol exchange. In a hybrid TLS connection, both an ECDHE key share and an ML-KEM key share are included; the final session key is derived from both. This provides security against both classical adversaries (if PQC has unforeseen weaknesses) and quantum adversaries (if classical cryptography is broken).

The hybrid approach is endorsed by NSA for the transition period as a "belt and suspenders" strategy: it does not weaken classical security while adding quantum resistance. NIST SP 800-227 (IPD) provides guidance on hybrid key establishment mechanisms. Defence programs should implement hybrid cipher suites now — this reduces the quantum risk of HNDL attacks on current communications while the full PQC-only transition proceeds.

Key insight: Defence software vendors often assume that post-quantum migration is a future concern for system owners rather than a current development obligation. This is incorrect. CNSA 2.0's requirement that new NSS systems support post-quantum algorithms from 2025 means that software delivered to DoD customers from 2025 onward must include post-quantum capable cryptographic implementations. Products built today with only classical cryptographic libraries will fail compliance assessment when deployed against CNSA 2.0-compliant infrastructure.