Over 60% of human-generated TLS traffic to Cloudflare’s network is already protected by hybrid post-quantum encryption. That shift happened without a single public announcement and without most organisations doing anything at all. Platform-level deployments — operating systems, CDN infrastructure, VPN clients — moved the industry to a majority quantum-resistant network while most CTOs were focused elsewhere.
The question is not whether this transition is happening. It already is. The question is whether the rest of your stack is along for the ride — or whether it is sitting in an adversary’s archive, queued for decryption by a harvest-now-decrypt-later attack the moment the right machine exists to run it.
Post-quantum cryptography (PQC) is already an active operational concern because the harvest-now-decrypt-later threat requires no quantum hardware to cause damage. This article is the starting point for a five-part series. Read this to understand the landscape, then follow the links to the article that matches your immediate question.
In this series:
- What the NIST Post-Quantum Standards Actually Mean — algorithm foundations and the August 2024 finalisation
- PQC Is Already Running in Production — what is deployed today, and what gaps remain
- The Post-Quantum Migration Roadmap — the phased programme for 50–500 employee companies
- How Hybrid Post-Quantum Cryptography Works — the technical architecture behind the transition
- PQC Compliance Deadlines — what regulators in the US, UK, EU, and beyond require
What Is Post-Quantum Cryptography and Why Does It Matter Right Now?
Post-quantum cryptography is a class of cryptographic algorithms designed to resist attacks from quantum computers running Shor’s algorithm. It matters right now because the harvest-now-decrypt-later (HNDL) threat model means adversaries can capture your encrypted data today and hold it until a cryptographically relevant quantum computer (CRQC) exists to break it. The data at risk is already in transit.
Classical public-key cryptography — RSA, ECC, ECDSA, ECDHE — derives its security from mathematical problems that classical computers cannot solve in practical time. Shor’s algorithm reduces both integer factorisation and the discrete logarithm problem to polynomial time on a fault-tolerant quantum computer. When that machine exists, every intercepted RSA or ECC-encrypted transmission becomes retroactively readable.
AES-256 and SHA-384/512 are already quantum-resistant at their current key lengths. The migration challenge is specific to public-key cryptography — a significant undertaking given how deeply RSA and ECC are embedded in TLS, certificate chains, code signing, and identity systems, but a bounded one.
For the mathematical foundation of the new algorithms and why lattice-based problems resist quantum attacks, including detailed algorithm comparison tables: the NIST standards and algorithm tradeoffs explained.
What Is the Harvest Now, Decrypt Later Threat and How Does It Affect Your Organisation Today?
Harvest-now-decrypt-later (also called store-now-decrypt-later, or SNDL) is a threat model in which adversaries — particularly nation-state actors — intercept and archive encrypted traffic today with the intention of decrypting it once a CRQC exists. HNDL attacks require no quantum computer — a well-resourced adversary needs only the ability to intercept and store encrypted traffic, and state-sponsored groups are already doing this on the assumption that a CRQC will be available to decrypt the harvest in the coming years.
The data categories most exposed are those with long confidentiality lifetimes: financial records, health data, legal and intellectual property documents, government communications, long-term authentication credentials, and proprietary trade secrets. SaaS companies handling regulated data for enterprise or government customers are in scope even if they are not themselves government entities.
The practical framing: the question for your organisation is not “when will Q-Day arrive?” but “how long does the data I am encrypting today need to remain confidential?” Any answer longer than five to seven years means the migration clock is already running.
For a migration programme structured around data confidentiality requirements and risk prioritisation: The Post-Quantum Migration Roadmap.
When Will a Cryptographically Relevant Quantum Computer Actually Exist?
A CRQC — a fault-tolerant quantum computer capable of running Shor’s algorithm against RSA-2048 or ECC at practical scale — is estimated to emerge between 2028 and 2033 based on current hardware roadmaps. No consensus exists on a precise date. But the exact timeline matters less than understanding that enterprise migration programmes take years, which means the window to start has already opened.
The 2028–2033 range comes from extrapolating hardware milestones across IBM, Google, and Microsoft. The industry’s focus has shifted from headline qubit numbers to control and error correction — the step that turns laboratory experiments into systems that cannot be ignored. This range has moved earlier over the past three years and could move earlier again.
The key strategic insight: a company starting its cryptographic inventory in 2026 and taking five to seven years to complete migration finishes in 2031–2033 — precisely when CRQC emergence estimates begin clustering. There is no margin for deferral.
What NIST Standards Have Been Finalised and What Do They Replace?
NIST finalised three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM) for key encapsulation; FIPS 204 (ML-DSA) for digital signatures; and FIPS 205 (SLH-DSA) for stateless hash-based signatures. These replace RSA and ECC for key exchange and digital signatures respectively. NIST has set 2030 as the deadline for deprecating RSA and ECC in non-National Security System contexts.
ML-KEM (FIPS 203) is the first and most urgent migration target because it is the algorithm that stops HNDL attacks. Deploying hybrid ML-KEM for key establishment eliminates the current data-collection window — adversaries harvesting your traffic today cannot decrypt it later if the session keys were established using ML-KEM.
ML-DSA (FIPS 204) replaces classical ECDSA and RSA signatures in certificates, code signing, and identity systems. This migration is less immediately urgent because ML-DSA only matters once an adversary has an active CRQC capable of forging signatures in real time — not for the retrospective HNDL threat. The urgency order matters for planning: start with key establishment, then signature migration follows.
NIST’s 2030 deprecation deadline applies to non-National Security System contexts. NSA’s CNSA 2.0, which governs National Security Systems and flows into commercial supply chains, has a January 1, 2027 procurement deadline — three years earlier.
For the full algorithm analysis and performance tradeoffs across ML-KEM, ML-DSA, and SLH-DSA: What the NIST Post-Quantum Standards Actually Mean.
Is Post-Quantum Cryptography Already Deployed at Scale, or Is This Still Theoretical?
PQC is already running at significant scale in production. Over 60% of human-generated TLS traffic to Cloudflare now uses hybrid ML-KEM, up from 29% at the start of 2025. Microsoft shipped ML-KEM and ML-DSA as generally available APIs in Windows Server 2025 and .NET 10. The deployment wave is not approaching — it has started.
The 60% figure does not mean 60% of organisations have deliberately migrated. Platform-level deployments — operating system TLS stacks, CDN infrastructure, VPN clients — have pushed hybrid PQC adoption to a majority of human web traffic without any organisational policy decision. Cloudflare One became the first full post-quantum SASE platform in February 2026, and the open-source file encryption tool age v1.3.0 now supports hybrid ML-KEM for developer use cases.
The distinction that matters for planning: network-layer TLS encryption for web traffic may already be partially protected if your stack uses Cloudflare or a modern OS TLS implementation. Application-layer encryption, PKI, code signing, and identity systems require your deliberate action.
For a complete map of what is deployed, what is available, and what gaps remain in your stack today: PQC Is Already Running in Production — and What That Means for Your Infrastructure.
What Does a PQC Migration Actually Involve for a Company With 50–500 Employees?
For a company of 50–500 employees, published research estimates a migration programme spanning five to seven years from start to full quantum resistance (Campbell, MDPI Computers, December 2025). The programme begins with a cryptographic inventory — a systematic audit of every certificate, protocol, library, device, and third-party dependency using public-key cryptography. Discovery alone typically takes one to three years.
Many organisations discover far more cryptographic dependencies than anticipated. Embedded firmware, third-party SaaS APIs, IoT devices, and legacy authentication systems are common hidden sources. The cryptographic inventory is the foundational first dependency of the entire programme — you cannot protect what you cannot see.
There is some good news: the phases do not all require simultaneous effort. Key establishment migration — deploying hybrid ML-KEM for TLS to stop HNDL — can be done within months for web-facing systems and provides immediate risk reduction. Digital signature migration follows in later phases. Starting now means finishing right at the CRQC emergence window — there is no slack in that schedule.
For the complete phased migration programme calibrated to SMB resource constraints: The Post-Quantum Migration Roadmap. For the architectural approach to hybrid deployment: How Hybrid Post-Quantum Cryptography Works.
Why Is Hybrid Post-Quantum Cryptography the Dominant Deployment Method?
Hybrid post-quantum cryptography runs a post-quantum algorithm (ML-KEM) in parallel with a classical algorithm (ECDHE) so that the resulting session key is secure as long as at least one algorithm remains unbroken. This is the dominant pattern in production deployments because it provides immediate HNDL protection while maintaining backward compatibility. It is the transitional architecture endorsed by IETF, NIST, UK NCSC, Germany’s BSI, and France’s ANSSI.
The security property of hybrid is that it degrades gracefully in either direction. If a vulnerability is found in ML-KEM, the classical component still provides security. If ECDHE is broken by a CRQC, the ML-KEM component provides quantum resistance. This conservative security property is why every major production deployment uses hybrid rather than pure PQC — Cloudflare, Microsoft, and Apple’s TLS stack all use hybrid.
Crypto-agility — abstracting algorithm selection to a configuration layer rather than hardcoding it into application logic — makes future migrations faster and cheaper. MD5 continued causing security problems twenty years after it was deprecated; building crypto-agility into new systems now avoids that outcome for PQC.
For the full technical architecture of hybrid key encapsulation and why it is the correct transitional approach: How Hybrid Post-Quantum Cryptography Works.
What Regulatory Pressure Is Building Around Post-Quantum Migration?
The clearest near-term regulatory forcing function is NSA’s CNSA 2.0, which sets January 1, 2027 as the hard procurement deadline for National Security Systems to require PQC-capable products. The CNSA 2.0 cascade is a significant urgency driver for commercial SaaS and FinTech companies that is often overlooked: if your software is used by any US federal agency, defence contractor, or company supplying National Security Systems, your product must support CNSA 2.0 algorithms in new deployments by 2027. Major defence acquisition programmes take eighteen to thirty-six months from planning to delivery — RFPs being written today must include these requirements.
The NIST 2030 deadline applies more broadly to commercial software, consumer products, and enterprise applications not part of National Security Systems. Waiting until 2029 to begin compliance work is not a viable plan.
International regulatory bodies are moving in parallel. The UK NCSC has published staged milestones with a 2035 full-migration target. The EU Commission has a 2030 harmonised PQC adoption target supported by ENISA. Australia’s ASD prefers pure PQC by 2030 — more aggressive than the EU’s hybrid-tolerant approach — meaning Australian companies serving government customers face the same compressed timeline as US-facing vendors, with ASD guidance effectively setting the benchmark for government procurement eligibility. OMB Memorandum M-23-02 requires all US federal agencies to maintain a prioritised cryptographic inventory; for SaaS vendors selling to federal agencies, demonstrating cryptographic inventory capability is becoming a procurement evaluation criterion.
For the full regulatory landscape across all jurisdictions, with compliance deadlines by sector and geography: PQC Compliance Deadlines and the Global Regulatory Mandates.
Where to Go Next: Your Navigation Guide to This Series
If you want to understand the NIST standards and algorithm choices:
What the NIST Post-Quantum Standards Actually Mean — Covers ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205), algorithm comparison tables, and the mathematical intuition behind why lattice problems resist quantum attacks. Start here before committing to a migration approach.
If you want to know what is already deployed and what you can use today:
PQC Is Already Running in Production — Maps the current PQC ecosystem: platform-level adoption across operating systems, Microsoft CNG and .NET 10, and consumer deployments. Identifies what has already been handled at the platform level versus what requires your deliberate action. Start here if you want to understand what the current deployment landscape looks like.
If you want a structured migration roadmap for your organisation:
The Post-Quantum Migration Roadmap — A practical four-phase migration programme designed for 50–500 employee tech companies: cryptographic inventory, hybrid TLS deployment, authentication migration, and full cryptographic agility. Start here if you are ready to build a plan.
If you want to understand the technical architecture behind hybrid PQC:
How Hybrid Post-Quantum Cryptography Works — Technical deep-dive on why hybrid provides stronger security than either algorithm alone, how ML-DSA replaces ECDSA in certificate chains, and how cipher translation enables legacy systems to participate in quantum-safe networks. Start here before briefing your engineering team.
If you need to understand your compliance obligations and regulatory deadlines:
PQC Compliance Deadlines — Comparative regulatory analysis covering CNSA 2.0, UK NCSC staged milestones, EU Commission 2030 target, ASD, ANSSI, BSI, UAE, and Malaysia. Includes compliance implications for FinTech, HealthTech, and SaaS-to-enterprise companies. Start here if regulatory deadlines are your primary planning driver.
FAQ Section
What is the difference between post-quantum cryptography and quantum key distribution?
Post-quantum cryptography uses classical computers running new mathematical algorithms that quantum computers cannot break efficiently. Quantum key distribution (QKD) uses quantum physics to detect eavesdroppers during key exchange. The NSA, UK NCSC, and Germany’s BSI have all explicitly stated that QKD is not a practical alternative to PQC for general internet use — it requires dedicated hardware and physical connectivity. PQC runs on your existing infrastructure and is the mainstream solution.
Is post-quantum cryptography the same as quantum computing?
No. Post-quantum cryptography is classical cryptography — software algorithms running on ordinary computers — designed to resist attacks from quantum computers. Quantum computing is the hardware and software platform that could eventually run Shor’s algorithm to break classical public-key cryptography. You do not need to invest in quantum computing to adopt post-quantum cryptography. PQC runs on your existing infrastructure.
What data is most at risk from harvest-now-decrypt-later attacks?
Data with long confidentiality requirements: financial transaction records, patient health records, intellectual property, long-term authentication credentials, and government communications. The question to ask for each data category: how long does this need to remain confidential, and would it be valuable to an adversary in 2030?
Has anyone actually deployed post-quantum cryptography in production yet?
Yes, extensively. Over 60% of human-generated TLS traffic to Cloudflare now uses hybrid ML-KEM. Microsoft has shipped ML-KEM and ML-DSA as generally available APIs in Windows Server 2025 and .NET 10. Cloudflare One is the first full post-quantum SASE platform. NordVPN, Proton VPN, and consumer VPN services have deployed PQC for subscriber traffic. age v1.3.0 supports hybrid ML-KEM for open-source file encryption. PQC deployment is no longer theoretical.
Do I need to replace all my encryption or just some of it?
Primarily key exchange and digital signatures — the public-key cryptography used in TLS, IPsec, SSH, and PKI. Symmetric encryption (AES-256) and hash functions (SHA-384, SHA-512) are already quantum-resistant. The migration is specifically about replacing RSA and ECC, which is still a significant undertaking given how deeply they are embedded in certificates, code signing, and identity systems.
What is crypto-agility and why is it the recommended approach?
Crypto-agility is the design property of a system that allows cryptographic algorithms to be swapped or updated without rewriting application logic. It is the recommended long-term strategy because it transforms what would be a painful, all-at-once migration into an incremental, manageable programme. Organisations that have hardcoded RSA key sizes or algorithm identifiers into their application code face the most expensive migration path. Building crypto-agility into new systems now — even before full PQC deployment — significantly reduces future migration cost and risk.
What is the NIST 2030 deadline and what does it mean for my organisation?
NIST has set 2030 as the target for deprecating RSA and ECC in non-National Security System contexts. For organisations selling software to US government agencies or regulated industries with FIPS compliance requirements, this is a hard procurement planning constraint. For commercial organisations not subject to FIPS, 2030 is the point at which classical-only cryptographic systems begin to become liabilities in enterprise sales conversations.
