Post-Quantum Encryption: Why the US Is Racing Against a Clock It Can’t See

The encryption protecting your HTTPS connection right now was designed in a world where no computer could factor a 2048-bit number in under a trillion years. That assumption held for decades. It’s about to stop holding and the US government is scrambling to fix it before the window closes.

What follows is a deep technical dive into post-quantum cryptography: what it is, why classical encryption breaks in a quantum world, what the three new NIST-finalized standards actually do under the hood, and why American intelligence agencies are treating this as a national security emergency rather than a future research problem.

What Encryption Rests On

Before any of this makes sense, you need to understand the mathematical promises that classical cryptography is built on.

RSA – the algorithm sitting underneath most HTTPS connections, signed software, and digital certificates are secure because multiplying two large prime numbers is easy, but going in reverse is hard. Given a 2048-bit number that is the product of two primes, no known classical algorithm can factor it in practical time. On a classical computer, this computation would take longer than the age of the universe. That’s the guarantee. That’s the entire security model.

Elliptic Curve Cryptography (ECC), which powers ECDH key exchange and ECDSA signatures in TLS 1.3, mobile banking apps, and most modern systems, is built on a different hard problem: the Elliptic Curve Discrete Logarithm Problem. Given a point on an elliptic curve derived from scalar multiplication, finding the original scalar is computationally infeasible for any classical computer at the key sizes in use today.

Diffie-Hellman key exchange has a similar structure. Its security rests on the discrete logarithm problem in finite fields.

All three of these – RSA, ECC, Diffie-Hellman are built on problems that are genuinely hard for classical computers. The catch is that they’re all instances of the same abstract mathematical framework, the Hidden Subgroup Problem, and a quantum computer running the right algorithm can solve every one of them.

That algorithm is Shor’s algorithm. And this is where things get uncomfortable.

Shor’s Algorithm: The Actual Threat

Peter Shor published his algorithm in 1994. At the time, no quantum computer existed that could run it. That’s still largely true in 2026 but the gap between “can’t run it” and “can run it” has been narrowing faster than most people expected.

Shor’s algorithm uses quantum Fourier transforms and quantum superposition to factor large integers and solve discrete logarithm problems in polynomial time. On a classical computer, factoring a 2048-bit number is exponential in the number of bits. On a quantum computer running Shor’s algorithm, that computation becomes polynomial. Not faster. Categorically different in complexity class. The security guarantee evaporates.

The full technical breakdown: for an n-bit RSA modulus, Shor’s algorithm runs in O(n² log n log log n) time using a quantum circuit with O(n) qubits. This is polynomial in n. Classical factoring algorithms run in sub-exponential but super-polynomial time. The switch from sub-exponential to polynomial is the catastrophic part.

ECC is actually worse news. Shor’s algorithm breaks elliptic curve discrete logs more efficiently than it breaks RSA, requiring fewer qubits for equivalent key sizes. The P-256 curve, used in the majority of TLS connections today, requires roughly 1,193 logical qubits to break, according to an analysis presented at EUROCRYPT 2026.

The obvious question: do quantum computers that can run this exist yet? No. Not yet.

The less obvious question: what’s the timeline?

In 2021, the best published resource estimate (Gidney and Ekerå) put the qubit count for breaking RSA-2048 at approximately 20 million physical qubits. In May 2025, Gidney published an updated analysis bringing that estimate below one million physical qubits. The requirement keeps dropping as error-correction research improves. Most credible estimates now place the arrival of a “Cryptographically Relevant Quantum Computer” (CRQC), a machine capable of running Shor’s algorithm on real-world key sizes somewhere between 2030 and 2040.

That timeline matters for reasons that go beyond when Q-Day arrives. It matters because of a threat that’s already active today.

Harvest Now, Decrypt Later: The Attack Already in Motion

Nation-state adversaries don’t need a quantum computer today to benefit from one in 2032. They only need to record your encrypted traffic now.

This is Harvest Now, Decrypt Later, also called HNDL or Store Now, Decrypt Later. The concept is straightforward: intercept encrypted communications at scale, store them, and wait. When a CRQC becomes available, run Shor’s algorithm against the stored ciphertext and recover the original plaintext. The breach doesn’t surface until years after the data was taken.

The attack has three phases. The first two don’t require quantum hardware at all. Phase one is bulk collection – intercepting TLS sessions, VPN tunnels, SSH connections, or any ciphertext at the network level. Phase two is storage. Phase three is decryption, the only phase that needs a CRQC. And since phases one and two leave zero detectable signature in conventional security tooling, there’s no way for a defender to know this is happening.

HNDL is not theoretical. Intelligence assessments from NSA, CISA, NIST, the UK’s NCSC, EU’s ENISA, and Australia’s ACSC all treat it as an active, ongoing threat. The US Office of Management and Budget explicitly cited HNDL as the primary justification for federal post-quantum migration strategy in July 2024.

The data categories targeted follow a consistent pattern: government and military communications (classified intelligence, diplomatic cables), financial records with multi-decade retention requirements, healthcare data (genomic profiles, long-lived patient records), critical infrastructure schematics, and defense intellectual property tied to weapons programs. The common thread is information that stays sensitive for years or decades.

The Mosca inequality formalizes the risk: if x is the number of years your data must remain secret, y is the time needed to complete a cryptographic migration, and z is the time until a CRQC exists, then migrating is urgent when x + y > z. For classified government records with 30-year sensitivity windows and 5-to-10-year migration timelines, x + y already exceeds even the most optimistic CRQC estimates.

Booz Allen Hamilton’s threat assessment explicitly states that Chinese threat groups are likely already collecting encrypted data with long-term utility, expecting to eventually decrypt it. The 2015 OPM breach which exposed personnel records for 21.5 million federal employees demonstrated bulk collection capability at state scale. The concern isn’t that China might develop this capability. The concern is that they almost certainly already have it.

A 2020 incident saw traffic from Google, Amazon, Facebook, and over 200 other networks redirected through Russia – consistent with large-scale HNDL collection behavior. There’s no log entry for any of this. No IOC. No breach notification. The data is gone the moment it crosses the wire.

Why Symmetric Encryption Isn’t Dead (Yet)

One clarification before going further, because this gets misunderstood constantly: Shor’s algorithm only threatens asymmetric, public-key cryptography. AES, ChaCha20, and other symmetric algorithms face a different quantum threat: Grover’s algorithm.

Grover’s algorithm, published in 1996, provides a quadratic speedup for unstructured search problems. Applied to symmetric encryption, it effectively halves the key strength – AES-128 becomes AES-64 in terms of quantum security, and AES-256 becomes AES-128. The mitigation is simple: use 256-bit keys. AES-256 remains secure against quantum attacks, which is why it’s included in the NSA’s post-quantum algorithm suite without modification.

A May 2026 analysis by researcher Filippo Valsorda put this in concrete terms: attacking AES-128 with Grover’s algorithm would be roughly 2^78.5 times more expensive than breaking an equivalent elliptic curve cryptographic system using Shor’s. Quantum computers are going to threaten public-key systems long before they threaten symmetric encryption. That makes asymmetric crypto the fire that needs putting out first.

Hash functions (SHA-256, SHA-3) are in a similar position – Grover’s halves their security output, but SHA-384 and SHA-512 retain adequate security margins under quantum attack, which is why they appear in CNSA 2.0 without replacement.

The problem isn’t symmetric encryption. The problem is everything that uses asymmetric crypto: TLS handshakes, digital certificates, code signing, SSH host keys, SSH authentication, PGP, S/MIME, VPN key exchange, and the certificate authority infrastructure that the entire internet’s trust model rests on. That’s the system that needs to be rebuilt.

The NIST Standardization Process: Eight Years to Three Algorithms

NIST launched its Post-Quantum Cryptography Standardization project in 2016, putting out a global call for algorithm submissions. The competition ran from 2017 through 2024 across four rounds of analysis, public scrutiny, cryptanalytic attacks from researchers worldwide, and implementation benchmarking. Sixty-nine complete submissions entered round one.

On August 13, 2024, NIST published the finalized versions of the first three post-quantum standards: FIPS 203, FIPS 204, and FIPS 205. In March 2025, a fourth algorithm, HQC (Hamming Quasi-Cyclic), was selected from the code-based candidates to serve as a backup KEM. A fifth standard, FIPS 206 (FN-DSA, based on FALCON), was finalized around the same time for use cases requiring smaller signatures than ML-DSA.

The three primary standards cover the two critical operations: key establishment and digital signatures. Here’s what each one actually does.

FIPS 203 – ML-KEM: Replacing Key Exchange

Formerly known as: CRYSTALS-Kyber What it replaces: RSA key encapsulation, ECDH key agreement Mathematical foundation: Module Learning With Errors (MLWE)

ML-KEM is a Key Encapsulation Mechanism. It solves the same problem that RSA and ECDH solve allowing two parties to establish a shared secret over an untrusted channel but using a completely different mathematical primitive that no known quantum algorithm can efficiently solve.

The Module Learning With Errors problem works like this: you’re given a system of linear equations over a polynomial ring, but with small errors intentionally introduced into the results. The challenge is to recover the original solution (the secret key) despite those errors. For a classical computer or a quantum computer, there’s no known algorithm that does this efficiently at the parameter sizes NIST specified.

The KEM structure is different from a key exchange. Rather than two parties interactively negotiating a secret, ML-KEM uses three operations:

Key generation: The recipient generates a public/private key pair. The public key is a structured matrix derived from the MLWE problem.

Encapsulation: The sender uses the recipient’s public key to encapsulate a randomly chosen shared secret, producing a ciphertext. The shared secret and ciphertext are mathematically linked to the recipient’s key in a way that’s computationally infeasible to reverse without the private key.

Decapsulation: The recipient uses their private key to decapsulate the ciphertext and recover the shared secret. Both parties now hold the same value without it ever being transmitted.

FIPS 203 specifies three parameter sets – ML-KEM-512, ML-KEM-768, and ML-KEM-1024 – corresponding roughly to NIST security levels 1, 3, and 5, which map to AES-128, AES-192, and AES-256 equivalent classical security. The NSA’s CNSA 2.0 mandates ML-KEM-1024 for national security systems. For most commercial applications, ML-KEM-768 is the recommended default.

In TLS 1.3, ML-KEM replaces the ECDHE step in the handshake. Google Chrome enabled hybrid X25519+ML-KEM key exchange for a subset of users in 2023 and has expanded that deployment since. Cloudflare had enabled hybrid PQC tunnels between its edge and origin servers by early 2025, covering billions of connections. The mechanism is hybrid combining classical X25519 with ML-KEM-768 so both must be broken for the handshake to be compromised. When the migration is complete, the classical component gets removed.

FIPS 204 – ML-DSA: Replacing Digital Signatures

Formerly known as: CRYSTALS-Dilithium What it replaces: RSA-PSS signatures, ECDSA signatures Mathematical foundation: Module Learning With Errors and Module Short Integer Solution (MLWE/MSIS)

Digital signatures are what allow you to verify that a piece of software was actually signed by the developer who claims to have signed it, that a TLS certificate genuinely came from a trusted CA, that a firmware update is legitimate, that a code commit wasn’t tampered with. Without quantum-resistant signatures, code signing collapses, certificate authorities become untrustworthy, and the entire software supply chain is at risk.

ML-DSA uses lattice-based mathematics to generate and verify signatures, with three parameter sets:

ML-DSA-44 at security level 2 – public key of 1,312 bytes, signature of 2,420 bytes.

ML-DSA-65 at security level 3 – public key of 1,952 bytes, signature of 3,293 bytes.

ML-DSA-87 at security level 5 – public key of 2,592 bytes, signature of 4,595 bytes.

Those numbers require a reality check against what they replace. A P-256 ECDSA signature is 64 bytes. An RSA-2048 signature is 256 bytes. An ML-DSA-65 signature is 3,293 bytes – roughly 51 times larger than ECDSA. This is not a trivial implementation detail. It has concrete consequences for TLS certificate chains, signed software manifests, and any protocol that passes signatures over constrained bandwidth. Certificate chains in TLS, which often include a leaf certificate plus one or two intermediate CA certificates, grow substantially when each certificate carries an ML-DSA signature. Protocol testing for ML-DSA in certificate infrastructure isn’t optional; it’s load-bearing work.

One important architectural note: ML-KEM and ML-DSA are both based on MLWE lattice problems. This means a breakthrough against the MLWE hardness assumption would compromise both simultaneously. That’s why SLH-DSA exists.

FIPS 205 – SLH-DSA: The Insurance Policy

Formerly known as: SPHINCS+ What it replaces: RSA-PSS signatures, ECDSA signatures (as an alternative to ML-DSA) Mathematical foundation: Cryptographic hash functions (SHA-256, SHAKE-256)

SLH-DSA is not a primary replacement for ECDSA in the sense that ML-DSA is. It’s a backup – a signature algorithm built entirely from hash function security rather than lattice math. If someone finds a practical attack against MLWE that breaks both ML-KEM and ML-DSA, SLH-DSA remains intact because it doesn’t share any of the same mathematical assumptions.

The security of SLH-DSA rests on hash function collision resistance and preimage resistance – properties that have been studied for decades and have no known quantum vulnerability beyond the manageable Grover’s speedup. If SHA-256 and SHAKE-256 hold (which all current evidence suggests they will), SLH-DSA holds.

The trade-offs are real. SLH-DSA produces signatures in the range of 7,856 to 49,856 bytes depending on parameter set. Signing is slower. Verification is relatively fast. This makes it unsuitable for high-throughput authentication, TLS certificate chains, or document signing pipelines where bandwidth matters. What it’s actually good for: root certificate authority key operations, firmware signing on long-lifetime devices (think medical devices, industrial controllers, aircraft avionics – systems with 15-to-30-year operational lifespans), and code signing infrastructure where the signature size doesn’t hit bandwidth limits. The principle is defense in depth: if your lattice-based KEM and signature scheme share a common assumption, your hash-based backup should not.

FIPS 203, 204, and 205 are the three finalized primary standards. They are not experimental. They are not a future roadmap item. They are final FIPS publications, mandatory for US federal systems under FISMA, and the reference point for every major regulatory framework globally.

ALSO READ: History of Encryption: From Ancient Codes to Quantum

The US Government’s Response: Not Optional, Not Slow

The US government’s response to the quantum threat has been coordinated across at least five major policy instruments, each escalating the urgency of PQC migration.

National Security Memorandum 10 (NSM-10, May 2022): The White House directive that set 2035 as the hard deadline for all National Security Systems to be quantum-resistant. NSM-10 also mandated that agencies prioritize migration of the highest-value systems first and required annual cryptographic inventories.

OMB M-23-02: Requires all federal agencies to maintain annual inventories of quantum-vulnerable cryptographic systems through 2035, prioritized by High-Value Asset designation.

NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0, September 2022, updated December 2024 and May 2025): The most operationally specific of the federal mandates. CNSA 2.0 defines exact timelines:

• By January 1, 2027: All new NSS acquisitions must be CNSA 2.0 compliant. The NSA stops approving new systems using RSA, DH, or ECC for key establishment.
• By December 31, 2030: All network equipment (VPNs, routers) unable to support CNSA 2.0 must be phased out. Software and firmware signing transitions to exclusive use of quantum-safe algorithms.
• By December 31, 2031: CNSA 2.0 use becomes mandatory across covered system categories.
• By December 31, 2033: Operating systems, custom applications, and cloud services reach exclusive use of CNSA 2.0.
• By December 31, 2035: Full quantum resistance across all National Security Systems, in alignment with NSM-10.

CNSA 2.0 mandates ML-KEM-1024 for key establishment and ML-DSA-87 for digital signatures in national security systems. No classical asymmetric algorithms appear in the suite for any new system, period. The compliance requirements extend through the defense industrial base – contractors and vendors supplying NSS are in scope.

Executive Order 14144 (January 2025): Issued under the Trump administration, this EO maintains PQC urgency while streamlining the roadmap. It removes some prescriptive agency-specific mandates and delegates oversight to NSA and OMB. It requires TLS 1.3 (or successor) adoption across all federal systems by January 2, 2030. CISA and NSA were required to publish a list of quantum-safe product categories by December 1, 2025.

Quantum Cybersecurity Preparedness Act: Legislative requirement for federal agencies to inventory quantum-vulnerable systems and prepare PQC migration plans. OMB must issue implementation guidance within one year of NIST final standards – those were released August 2024, which means OMB guidance was due August 2025.

The combined effect: any organization supplying the federal government, operating NSS infrastructure, or handling controlled unclassified information is on a mandatory migration clock. The realistic enterprise migration timeline from start to compliance is 42 to 54 months, according to AxelSpire’s analysis published in 2026. If an organization hasn’t started, the 2030 network equipment deadline is already inside that window.

What Is Driving the Panic: China, Q-Day, and the Race Nobody Talks About

The geopolitical subtext of PQC migration is China. And it’s worth being direct about it rather than burying it in passive-voice risk assessments.

The US-China Economic and Security Review Commission’s 2025 report stated that the Commission “assumes China is aggressively pursuing cryptographically relevant quantum computing and deliberately obscuring where its most sophisticated programs are located and how far they have progressed.” That’s a careful way of saying: we think they’re ahead of what they’re showing.

China has built the world’s largest operational quantum key distribution network, over 10,000 kilometers of fiber spanning 17 provinces and 80 cities, with satellite uplinks. In late 2023, China and Russia demonstrated a “secure quantum link” between Chinese satellites and Russian ground stations 2,400 miles apart. In early 2025, China ran a similar demonstration with South Africa across 8,000 miles. China’s 15th Five-Year Plan (2026-2030) explicitly names quantum technology as a strategic priority alongside AI.

On hardware: China’s Zuchongzhi 3.2 superconducting quantum processor runs at 107 qubits as of 2025. Origin Wukong is at 72 qubits. Tianyan-504 reached 504 qubits. None of these are CRQC-class machines – the physical qubit counts are nowhere near the error-corrected logical qubit requirements for Shor’s algorithm. But the trajectory is consistent, the funding is massive (a planned 1 trillion renminbi state-backed fund was reported by Nikkei Asia in December 2025), and the military motivation is clear.

A May 2025 US Defense Intelligence Agency report assessed that quantum-enabled advances “will improve targeting and long-range precision fires, potentially giving early adopters a decisive edge” and that “quantum computing, sensing and communications will probably provide militaries with more advanced capabilities in decryption.” The DIA also noted that while a true quantum breakthrough is unlikely within the next decade, “the technology is nearing real-world application.”

The October 2024 demonstration by Shanghai University researchers, who cracked a 22-bit encryption key using a quantum computer, put this in perspective. A 22-bit key is nowhere near RSA-2048. But it was the first publicly confirmed instance of a quantum computer breaking a real (if trivially small) encryption key. The direction of travel is unmistakable.

Salt Typhoon, the PRC-linked threat group that maintained persistent access inside major US telecommunications providers for months in 2024, operated exactly the kind of infrastructure useful for HNDL collection at scale. Three Chinese technology companies were named by US intelligence agencies as directly enabling those operations. The attack pattern – gaining administrative access to supervisory systems, establishing long-term persistence, remaining dormant is precisely what you’d build if your goal was bulk collection of encrypted traffic for later decryption.

What Industry Has Done

The good news: the algorithms exist and are finalized. The less good news: adoption at the enterprise level is still nascent.

At the protocol and infrastructure level, movement has been rapid. Google Chrome has been running hybrid X25519+ML-KEM key exchange for a growing share of users since late 2023 and expanded it substantially through 2024 and 2025. Apple deployed PQ3 for iMessage in February 2024, starting with iOS 17.4, a hybrid protocol combining existing algorithms with a post-quantum component to protect against HNDL. Signal added PQXDH (post-quantum extended Diffie-Hellman) in fall 2023, making it the first large-scale messenger to adopt post-quantum key establishment. Cloudflare has been progressively enabling PQC tunnels between its edge and origin servers across its customer base.

OpenSSL 3.5 (released 2025) includes native ML-KEM and ML-DSA support. BoringSSL, used by Chrome and Cloudflare, ships production hybrid implementations. AWS, Google Cloud, and Microsoft Azure all support PQC-enabled TLS endpoints.

The Open Quantum Safe project’s liboqs library provides reference implementations of all three standards with C, Python, Go, Java, and .NET bindings. OQS-OpenSSH supports post-quantum key exchange in SSH.

What isn’t done: certificate authorities have not yet issued ML-DSA leaf certificates at scale. Most enterprise applications haven’t been updated. Most VPN appliances are not CNSA 2.0 compliant. The FIPS 140-3 validation process for PQC modules is still running, which is the remaining blocker for regulated industries that require validated cryptographic modules rather than reference implementations.

Industry analysts project the PQC market will exceed $15 billion by 2030. Boston Consulting Group, in a February 2026 assessment, warned that organizations starting migration in 2030 will already be too late for data with long confidentiality requirements. The 42-to-54-month migration window means starting now to hit 2030 compliance deadlines requires action today, not next year.

What is Crypto-Agility and Why It Matters

One concept that keeps coming up in PQC migration guidance is crypto-agility, and it deserves a direct explanation rather than the usual vague gesture toward “flexibility.”

Crypto-agility means building systems so that the cryptographic algorithm is a replaceable module rather than a hardcoded assumption baked into the protocol implementation. A crypto-agile TLS library can switch from X25519+ECDSA to X25519+ML-KEM+ML-DSA by updating a configuration parameter, not by rebuilding the stack. A crypto-agile HSM can load new algorithm firmware. A crypto-agile certificate authority can issue certificates using ML-DSA or RSA depending on what the subscriber’s infrastructure supports.

The reason it matters: NIST’s post-quantum standards are explicitly not permanent. The MLWE-based algorithms are believed to be secure today, but belief isn’t proof. If researchers find a practical attack against lattice problems in 2028 and this has happened before, notably with SIKE/SIDH, which was broken in 2022 on a single CPU core in about an hour – any system that hardcoded ML-KEM assumptions will need emergency replacement. Crypto-agility is the difference between a controlled migration and a global fire drill.

This is also why NIST included SLH-DSA as a hash-based alternative. Algorithmic diversity reduces the blast radius of a future cryptanalytic breakthrough. If the lattice collapses, the hash-based fallback holds.

The practical advice from NIST IR 8547 and CISA guidance is consistent: start with a cryptographic inventory, map every system and protocol to the algorithm it uses, identify where RSA and ECC are embedded, build migration roadmaps prioritizing systems with the longest data sensitivity windows, and require crypto-agility from vendors in new procurement.

Timeline Summary: What’s Happening When

For clarity, here’s the migration picture from where things stand in mid-2026:

Already done (2024): NIST finalized FIPS 203, 204, and 205. Google Chrome, Apple iMessage, Signal, and Cloudflare deployed hybrid PQC in production. Shanghai University demonstrated quantum factoring of a 22-bit key.

Already past (December 2025): NSS systems previously validated against NIAP or CSfC profiles required to either complete CNSA 2.0 transition or file waivers. CISA/NSA required to publish list of quantum-safe product categories.

Imminent (January 2027): All new NSS acquisitions must be CNSA 2.0 compliant. NSA stops approving new systems using RSA, DH, or ECC. Software and firmware signing for NSS must use CNSA 2.0 algorithms exclusively.

Near-term (2027-2030): NIST deprecates RSA-2048 and ECC P-256 for new federal deployments. TLS 1.3 required across all federal systems by January 2030. All network equipment (VPNs, routers) unable to support CNSA 2.0 phased out.

Mid-term (2030-2033): RSA and ECC fully disallowed for all federal use. Operating systems, custom applications, and cloud services transition to exclusive CNSA 2.0.

Hard deadline (2035): All National Security Systems quantum-resistant. RSA and ECC disallowed including legacy interoperability.

Estimated enterprise migration: 42-54 months end-to-end. Starting in 2026 or 2027 is necessary to hit the 2030 network equipment deadline with any margin.

Practical Implications for Security Teams

For security practitioners, the PQC migration isn’t just a procurement conversation – it’s a discovery, risk assessment, and engineering effort that has to happen in parallel.

The starting point is a Cryptographic Bill of Materials (CBOM): a complete inventory of every algorithm, key size, protocol, and library in use across an environment. Without this, it’s not possible to prioritize migration, identify HNDL-risk data, or track progress against compliance deadlines.

After discovery, risk prioritization by data sensitivity and retention window. Genomic data, classified records, defense IP, and long-lived financial records carry the highest HNDL exposure. Web session tokens and short-lived authentication tokens are low priority.

After that, hybrid deployment: run ML-KEM alongside ECDH in TLS, run ML-DSA alongside ECDSA in certificate chains, ensure that breaking one component doesn’t compromise the connection. This is how Chrome and Cloudflare have handled it, and it’s the right operational approach during migration.

The hardest part isn’t the algorithm selection. It’s the certificate infrastructure – updating CA hierarchies to issue post-quantum certificates, managing the size increase in TLS handshakes, updating HSMs to support FIPS 140-3 validated PQC modules, and coordinating vendor timelines for network appliances that often have 5-to-7-year replacement cycles.

FAQs

Conclusion

Post-quantum cryptography has been framed as a future problem for long enough that it started to feel academic. It’s not. NIST finalized the standards. NSA published hard enforcement deadlines. HNDL collection is active. China’s quantum investment is state-directed, massive, and explicitly aimed at cryptographic relevance. The enterprise migration timeline is 42-54 months. The 2027 procurement deadline for national security systems is seven months away as of mid-2026.

The algorithms work. The standards are final. The mathematical foundations have been scrutinized by cryptographers across academic institutions and intelligence agencies worldwide for nearly a decade. What’s left is the operational grind: inventory, prioritization, hybrid deployment, certificate infrastructure updates, vendor negotiation, and compliance tracking.

That’s not a research problem anymore. That’s an engineering and program management problem. And the window for an orderly transition is measurably narrowing.