What Is Post-Quantum Cryptography (and Why It Matters Now)
Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to remain secure against attacks from both classical computers and future quantum computers. It is entirely distinct from quantum cryptography — a point worth clarifying immediately, because the two are routinely conflated. Quantum cryptography (most commonly quantum key distribution, or QKD) uses the physical properties of photons to exchange keys; post-quantum cryptography is ordinary software-based mathematics that simply uses hard problems a quantum computer cannot efficiently solve.
The threat: how quantum computers break current encryption
Most of the public-key infrastructure on the internet — TLS certificates, code-signing, email encryption, VPNs — relies on the difficulty of factoring large integers (RSA) or solving the discrete logarithm problem on elliptic curves (ECC). In 1994, mathematician Peter Shor demonstrated that a sufficiently powerful quantum computer could solve both problems in polynomial time using Shor’s algorithm. A cryptographically relevant quantum computer (CRQC) — one with enough stable, error-corrected qubits to run Shor’s algorithm against real-world key sizes — would render RSA-2048 and standard ECC effectively broken.
Symmetric algorithms such as AES are also affected, but far less severely. Grover’s algorithm offers a quadratic speedup for brute-force search, halving the effective security level — meaning AES-128 drops to roughly 64-bit equivalent security under quantum attack, while AES-256 retains approximately 128-bit security. For most threat models, AES-256 is considered quantum-safe with no algorithm change required.
Harvest Now, Decrypt Later attacks explained
A harvest now, decrypt later (HNDL) attack is straightforward in concept and deeply unsettling in practice. An adversary intercepts and stores encrypted traffic today — TLS sessions, VPN tunnels, secure file transfers — with no ability to read it. Once a CRQC becomes available, they decrypt the archive retroactively. This threat is not speculative: intelligence agencies and nation-state actors with the resources to store petabytes of traffic have a clear incentive to do so right now.
The practical consequence is that data with a long sensitivity lifetime — medical records, intellectual property, legal communications, government secrets — is already at risk even though no CRQC yet exists. If that data must remain confidential for ten or fifteen years, it needs quantum-safe protection today, not when a CRQC appears.
Why 2026 is the critical planning window
Estimates for when a CRQC will exist range from five to fifteen years, and credible researchers disagree significantly (IBM, Google, and academic groups publish widely varying projections — treat any single date with caution). What is not in dispute is that migration projects for large enterprises, critical national infrastructure, and financial institutions take three to seven years to complete when PKI, legacy systems, and supply chains are involved. NIST finalised its first three post-quantum standards in August 2024. The planning window is now. Organisations that begin in 2026 can realistically reach a defensible posture before the most aggressive quantum timelines materialise; organisations that wait until a CRQC is announced will not.
NIST’s Finalised Post-Quantum Standards: What You Need to Know
In August 2024, the US National Institute of Standards and Technology (NIST) published three finalised post-quantum cryptographic standards. These are no longer drafts — they are production-ready specifications that vendors, browsers, and operating systems are actively implementing. Any guide still referencing NIST round numbers or draft designations is out of date.
FIPS 203 (ML-KEM / Kyber): key encapsulation
FIPS 203 standardises ML-KEM (Module Lattice-Based Key Encapsulation Mechanism), derived from the Kyber algorithm. It is a key encapsulation mechanism (KEM) — the replacement for RSA and ECDH in protocols that need to establish a shared secret, most importantly TLS. ML-KEM is based on lattice-based cryptography, specifically the hardness of the Module Learning With Errors (MLWE) problem. It offers three security levels (ML-KEM-512, ML-KEM-768, ML-KEM-1024) roughly analogous to AES-128, AES-192, and AES-256 equivalent security. Key generation and encapsulation are fast — benchmarks from the Open Quantum Safe project show ML-KEM-768 key generation completing in under 0.1 ms on modern server hardware, compared to several milliseconds for RSA-2048.
FIPS 204 (ML-DSA / Dilithium): digital signatures
FIPS 204 standardises ML-DSA (Module Lattice-Based Digital Signature Algorithm), derived from Dilithium. This is the primary replacement for RSA and ECDSA signatures — for code signing, certificate authorities, document signing, and authentication tokens. Like ML-KEM, it is lattice-based. Signature sizes are larger than ECDSA (roughly 2–3 KB for ML-DSA-65 versus 64 bytes for a P-256 ECDSA signature), which has implications for certificate chain sizes and bandwidth in constrained environments.
FIPS 205 (SLH-DSA / SPHINCS+): stateless hash-based signatures
FIPS 205 standardises SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), derived from SPHINCS+. Unlike ML-DSA, SLH-DSA relies solely on the security of hash functions rather than lattice problems — making it a conservative backup with entirely different mathematical foundations. Its security assumptions are among the best-understood in post-quantum cryptography, but it produces significantly larger signatures (8–50 KB depending on parameter set) and is slower to sign. It is best suited for use cases where conservative security is prioritised over performance, and where signatures are infrequent — firmware signing and root CA certificates, for example.
What happened to FALCON (FN-DSA) and the draft FIPS 206
FALCON, a lattice-based signature scheme based on NTRU lattices, is being standardised as FN-DSA under draft FIPS 206. As of early 2026, FIPS 206 has not yet been finalised. FALCON offers smaller signatures than ML-DSA (comparable to ECDSA in size), which makes it attractive for bandwidth-constrained scenarios such as embedded systems and IoT. However, its implementation complexity — particularly the need for high-quality Gaussian sampling — introduces side-channel risks that require careful engineering. Monitor NIST’s publication schedule, but do not delay your migration planning waiting for FIPS 206; the three finalised standards are sufficient to begin.
Step 1 — Cryptographic Inventory: Discover Where You Use Classical Cryptography
You cannot migrate what you cannot see. Before any technical work begins, you need a complete picture of where cryptography is used across your estate.
What a cryptographic bill of materials (CBOM) is
A cryptographic bill of materials (CBOM) is an inventory of every cryptographic asset in your environment: algorithms in use, key sizes, certificate lifetimes, protocol versions, and the systems and data those assets protect. Think of it as the security equivalent of a software bill of materials (SBOM). A CBOM should record not just what algorithm is used, but where it is used (which application, service, or device), by whom, and what the data sensitivity and longevity of the protected asset is. Without this, migration prioritisation is guesswork.
Tools and methods for automated cryptography discovery
Manual audits of large estates are impractical. Several tooling approaches exist. Network scanning tools (such as nmap with TLS scripts, or commercial equivalents) can enumerate TLS cipher suites and certificate algorithms across services. Static analysis tools can scan codebases for hardcoded algorithm references — searching for strings like RSA, EC_KEY, or SHA1 in application source. Certificate transparency logs and internal PKI dashboards surface certificate inventory. For deeper code-level discovery, IBM’s Cryptography Bill of Materials tooling and similar open-source projects provide structured output compatible with emerging CBOM schemas. The goal is a machine-readable inventory, not a spreadsheet.
In your key management infrastructure, document which HSMs (hardware security modules) support which algorithms — many older HSMs do not yet have firmware supporting ML-KEM or ML-DSA, and lead times for upgrades or replacements can be long.
Prioritising assets by data sensitivity and longevity
Not all cryptographic assets carry the same risk. Prioritise using two axes: data sensitivity (how damaging would exposure be?) and data longevity (how long must it remain confidential?). A TLS session for a marketing website that expires in seconds is very low priority. Encrypted medical records retained for thirty years, or long-term contractual documents, are high priority because HNDL attacks are already a realistic threat. Apply data classification labels from your existing information governance framework to this matrix. Assets in the top-right quadrant — sensitive and long-lived — are your first migration targets.
Step 2 — Risk Assessment: Identifying Your Quantum-Vulnerable Systems
With a CBOM in hand, you can construct a risk picture. The key insight is that quantum exposure is not uniform: the type of algorithm matters as much as the key size.
Classifying systems by algorithm type (symmetric vs asymmetric exposure)
Asymmetric cryptography — RSA, ECDH, ECDSA, DH — is fully broken by Shor’s algorithm on a CRQC. Every system using these algorithms for key exchange or digital signatures is quantum-vulnerable and requires migration to post-quantum equivalents. Symmetric cryptography — AES, ChaCha20, HMAC-SHA-256 — is affected only by Grover’s algorithm, which provides a quadratic (not exponential) speedup. AES-256 retains around 128-bit equivalent security against a quantum adversary and is considered acceptable by NIST, NCSC, and CISA. Systems using AES-128 should be upgraded to AES-256, but the algorithm itself does not need replacement. Build your risk matrix accordingly: asymmetric exposure is urgent; symmetric key size uplift is important but less critical.
Long-lived data and long-lived systems: the double risk
Two categories require extra attention. First, long-lived data: any encrypted data that needs to remain confidential beyond the likely emergence of a CRQC is already at risk from HNDL attacks. Second, long-lived systems: industrial control systems, embedded devices, medical equipment, and critical infrastructure often have operational lifetimes of ten to twenty years and update cycles measured in years, not months. A system deployed today with RSA-2048 may still be in service when a CRQC exists. Factor replacement and upgrade cycles into your compliance planning.
NCSC and CISA guidance for UK organisations
The UK’s National Cyber Security Centre (NCSC) has published dedicated Preparing for Post-Quantum Cryptography guidance, which is the authoritative reference for UK organisations. The NCSC recommends that organisations begin discovery and planning immediately and aligns broadly with NIST’s migration timelines. The US Cybersecurity and Infrastructure Security Agency (CISA), alongside the NSA, has published complementary PQC cybersecurity resources that are widely cited and useful for organisations with US connections or supply chains. Both agencies emphasise starting the inventory process now rather than waiting for perfect tooling or final standards.
“Organisations should start planning their migration to post-quantum cryptography now… the migration will take time, and organisations that leave it too late risk being unable to protect their data.” — NCSC, Preparing for Post-Quantum Cryptography
Step 3 — Building Your PQC Migration Roadmap
A PQC migration is not a single deployment event — it is a multi-year programme. The organisations that manage it successfully treat it as a phased project with clear gates, not a big-bang cutover.
Phased approach: hybrid cryptography as an interim bridge
Hybrid cryptography — combining a classical algorithm with a post-quantum algorithm such that security holds unless both are simultaneously broken — is the recommended transition mechanism from both NIST and NCSC. In a hybrid TLS handshake, for example, the key exchange combines X25519 (classical ECDH) with ML-KEM-768, producing a shared secret that is secure against quantum attackers (ML-KEM) and against any unexpected flaw in the new PQC algorithm (X25519). Hybrid schemes let you deploy PQC incrementally without abandoning classical security as a fallback, which matters because PQC algorithms, being newer, have a shorter track record of cryptanalysis.
A practical phased structure looks like this:
- Phase 1 (now – 2027): Complete cryptographic inventory; establish CBOM; identify high-priority assets; assess vendor and supply-chain readiness.
- Phase 2 (2027 – 2028): Deploy hybrid PQC for highest-risk systems (long-lived data, external-facing TLS, PKI roots); begin internal PKI migration.
- Phase 3 (2028 – 2030): Migrate remaining systems to pure PQC where standards and implementations are mature; retire classical-only configurations.
- Phase 4 (ongoing): Monitor algorithm health; maintain crypto-agility for rapid response to any cryptanalytic advances.
Setting migration timelines aligned with NIST and NCSC recommendations
NIST’s published guidance sets a 2030 deadline for deprecating RSA and ECC in US federal systems, with a hard cutoff around 2035. The NCSC has not published a mandatory UK deadline for private-sector organisations as of early 2026, but its guidance makes clear that critical national infrastructure and government suppliers should treat 2030 as a planning horizon. Build your internal migration roadmap working backwards from 2030, accounting for procurement cycles, staff training, testing periods, and third-party dependencies.
Vendor and supply-chain dependencies to resolve
Your migration speed is constrained by your slowest dependency. Audit your supply chain: which SaaS platforms, cloud providers, hardware vendors, and software libraries handle cryptographic operations on your behalf? Certificate authorities must issue PQC-capable certificates; HSM vendors must ship firmware updates; cloud load balancers must support PQC cipher suites. Ask vendors directly for their PQC roadmaps and contractually require timelines where possible. Vendor readiness varies enormously — major cloud providers (AWS, Azure, GCP) have active PQC programmes, while niche industrial vendors may have no public timeline at all.
Step 4 — Implementation: Integrating PQC Algorithms into Your Stack
Moving from planning to implementation requires choosing the right libraries, understanding current protocol support, and managing your PKI transition carefully.
TLS 1.3 and PQC: current browser and server support
TLS 1.3 is the foundation for PQC deployment on the web. The IETF has standardised hybrid key exchange groups (combining X25519 with ML-KEM) in RFC 8446 extensions, and as of early 2026, major browsers including Chrome and Firefox support hybrid PQC key exchange in TLS 1.3 by default or via configuration flags. Cloudflare, AWS, and Google have deployed hybrid TLS in production. Server-side, OpenSSL 3.3+ includes experimental PQC support via provider plugins, and full ML-KEM integration is progressing through the OpenSSL 3.x roadmap. Check your web server and load balancer versions before planning TLS migration — nginx and Apache both depend on the underlying OpenSSL version.
Code and library considerations (liboqs, BouncyCastle, OpenSSL 3.x)
Three libraries are the most relevant starting points for most teams:
- liboqs (Open Quantum Safe project, openquantumsafe.org): A C library implementing all finalised NIST PQC algorithms, with language bindings for Python, Go, Java, and others. It integrates with a patched version of OpenSSL (OQS-Provider) enabling drop-in PQC support for OpenSSL-based applications. Actively maintained and the most widely used open-source PQC implementation.
- BouncyCastle 1.8x: The Java and C# cryptography library has added ML-KEM and ML-DSA support in recent releases. For Java-based enterprise applications and Android, BouncyCastle is typically the most practical path to PQC without replacing the entire cryptographic stack.
- OpenSSL 3.x with OQS-Provider: For C/C++ applications and servers already using OpenSSL, the OQS-Provider plugin architecture allows PQC algorithms to be loaded as providers. Production use requires careful review of provider stability and your OpenSSL version compatibility.
None of these libraries should be deployed in production without a security review specific to your use case. PQC implementations, particularly those involving Gaussian sampling (relevant to FN-DSA / FALCON), can introduce side-channel vulnerabilities if not carefully hardened.
Certificate lifecycle and PKI updates
Your internal PKI migration is likely the most complex and time-consuming element. Root CAs and intermediate CAs must issue X.509 certificates containing PQC public keys (ML-DSA or SLH-DSA) before any downstream system can use them. Hybrid certificates — containing both a classical and a PQC public key — are supported by draft IETF specifications and allow graceful rollover without requiring all relying parties to upgrade simultaneously. Plan certificate lifetimes carefully: issuing classical certificates with long validity periods now will create migration debt. Short-lived certificates (90 days or less, in line with the direction of travel from Let’s Encrypt and the CA/Browser Forum) reduce this problem by limiting how long legacy material remains in circulation.
Step 5 — Testing, Validation, and Crypto-Agility
Implementation without thorough testing introduces new vulnerabilities while supposedly removing old ones. Equally important is building the organisational and technical capability to change algorithms quickly in future.
How to test PQC implementations safely in staging
Stand up a dedicated staging environment that mirrors your production cryptographic configuration. Test the full cryptographic lifecycle: key generation, encapsulation/decapsulation (for KEMs), signing and verification, certificate issuance and validation, and protocol negotiation. Run regression testing against all applications that depend on the cryptographic stack — PQC key and signature sizes differ significantly from their classical equivalents and will expose hardcoded buffer sizes, length assumptions in parsers, and similar bugs. Use network traffic analysis to validate that hybrid TLS handshakes complete correctly and fall back gracefully when one peer does not support PQC.
Building crypto-agility so you can swap algorithms without re-architecting
Crypto-agility — the ability to swap cryptographic algorithms without significant re-engineering of the systems that use them — is the architectural property that protects you against future cryptanalytic advances. An ML-KEM algorithm that appears secure today may be weakened by a future mathematical breakthrough; an organisation with crypto-agile systems can respond in weeks rather than years. Practically, this means abstracting cryptographic operations behind well-defined interfaces, externalising algorithm configuration from application code, and using a centralised key management service that supports algorithm negotiation. TLS already does this to a degree — cipher suite negotiation is inherently crypto-agile — but application-level cryptography (encrypted database fields, signed tokens, encrypted file stores) often is not.
Performance benchmarks: PQC overhead on latency and bandwidth
PQC algorithms carry real performance costs that vary significantly by algorithm and use case. Based on benchmarks published by the Open Quantum Safe project and NIST:
- ML-KEM-768 key generation takes approximately 0.06 ms on a modern x86 server — significantly faster than RSA-2048 key generation (~1–2 ms). Encapsulation and decapsulation are similarly fast. The main overhead is bandwidth: an ML-KEM-768 public key is ~1,184 bytes versus 256 bytes for a P-256 ECDH public key.
- ML-DSA-65 signatures are ~2,420 bytes versus 64 bytes for P-256 ECDSA. This meaningfully increases TLS certificate chain sizes and has implications for protocols with strict message size limits (DNSSEC, for example).
- SLH-DSA is substantially slower to sign (10–100 ms depending on parameter set) and produces signatures up to 50 KB. It should not be used in high-frequency signing scenarios.
Measure latency overhead in your specific environment rather than relying on lab benchmarks — hardware acceleration, network conditions, and application architecture all affect real-world numbers. The bandwidth increase for hybrid TLS is measurable but, for most web applications, falls within acceptable margins on modern networks.
Compliance, Regulation, and UK-Specific Considerations
For UK organisations, PQC migration sits at the intersection of cybersecurity best practice and emerging regulatory expectation. Getting ahead of the compliance curve is easier than retrofitting security after a regulatory requirement lands.
NCSC’s post-quantum migration guidance for critical national infrastructure
The NCSC has published specific guidance for operators of critical national infrastructure (CNI) — energy, water, transport, finance, health, and telecommunications — urging them to treat PQC migration as a strategic programme, not a technical upgrade cycle. CNI operators should engage directly with the NCSC’s sector teams and review the NCSC’s Preparing for Post-Quantum Cryptography document alongside the broader Cyber Assessment Framework. Government suppliers under the Cyber Essentials Plus scheme should monitor updated requirements, which are expected to address PQC over the coming years.
GDPR and data protection implications of long-lived encrypted data
Under the UK GDPR and the Data Protection Act 2018, organisations are required to implement appropriate technical measures to protect personal data. The Information Commissioner’s Office (ICO) has not yet issued specific guidance on PQC, but the HNDL threat creates a plausible argument that relying on classically-encrypted personal data with long retention periods may, in time, fail the ‘appropriate technical measures’ test. Organisations in sectors with long data retention obligations — healthcare, legal, financial services — should document their quantum risk assessment and migration plan as part of their data protection impact assessments (DPIAs) now. This demonstrates accountability under data protection principles even before specific PQC regulatory compliance requirements are mandated.
Financial services: FCA and PRA expectations
The Financial Conduct Authority (FCA) and Prudential Regulation Authority (PRA) have not, as of early 2026, issued mandatory PQC requirements. However, operational resilience rules (PS21/3) and the FCA’s systemic risk framework create indirect pressure: firms must demonstrate that their technology risk management processes account for emerging threats. Several large UK banks and insurers have already begun PQC programmes in response to internal board-level risk reviews rather than regulatory mandates. Given the FCA’s track record of following NIST and NCSC guidance in technology risk expectations, a formal regulatory signal is more likely a matter of when than whether.
Common PQC Migration Mistakes to Avoid
Most migration failures are not technical — they are organisational and strategic. These are the patterns that consistently derail PQC programmes.
Waiting for a ‘perfect’ standard before acting
The single most common mistake is treating NIST’s August 2024 publications as the beginning of a waiting period rather than the end of one. Three finalised FIPS standards exist today. FIPS 206 (FN-DSA) is still in draft, but the finalised trio covers the use cases relevant to the vast majority of organisations. The procrastination risk is concrete: every year spent waiting is a year of additional HNDL exposure for long-lived data and a year less runway before regulatory deadlines. Start with what is finalised; update when additional standards arrive.
Ignoring symmetric key sizes
Symmetric cryptography is not immune to quantum risk — it is just less urgently affected. Grover’s algorithm halves the effective key size of symmetric ciphers. AES-128 provides approximately 64-bit quantum security, which is insufficient for data requiring long-term confidentiality. Audit your use of AES-128, 3DES, and other sub-256-bit symmetric algorithms as part of your CBOM work and upgrade them. This is typically a low-effort change with high impact on long-term data security.
Underestimating migration time for embedded and IoT systems
Embedded systems and IoT devices present the hardest migration challenge. They frequently use hardware-accelerated RSA or ECC that cannot be updated via firmware — the algorithm is baked into a dedicated crypto chip. PQC algorithms have larger key and signature sizes that may exceed the memory and bandwidth constraints of low-power devices. Update cycles for legacy systems in industrial and healthcare environments are measured in years or decades. These systems require the earliest attention in your migration planning precisely because they cannot be rapidly updated when a CRQC emerges.
Frequently Asked Questions About PQC Migration
Is AES-256 quantum-safe?
Yes, for practical purposes. Grover’s algorithm reduces AES-256’s effective security from 256 bits to approximately 128 bits against a quantum adversary. NIST, NCSC, and CISA all consider AES-256 acceptable for post-quantum use without algorithm replacement. AES-128 should be upgraded to AES-256, but the underlying AES algorithm does not need to change.
When will quantum computers break RSA?
No one can give a reliable date. Credible estimates from academic and industry researchers range from roughly five to fifteen or more years. IBM, Google, and government research programmes are all investing heavily, but the engineering challenges of building a fault-tolerant CRQC at the scale needed to attack RSA-2048 remain substantial. Rather than planning against a specific date, plan against a probability: the longer your data needs to remain confidential and the longer your migration will take, the sooner you need to start.
What is the difference between quantum cryptography and post-quantum cryptography?
Quantum cryptography (most commonly quantum key distribution, QKD) uses the physical properties of quantum mechanics — specifically photon polarisation — to transmit cryptographic keys in a way that is theoretically detectable if intercepted. It requires specialised hardware (quantum channels, single-photon detectors) and is limited in range and scalability. Post-quantum cryptography is software-based mathematics — ordinary algorithms running on classical computers — designed to be resistant to attacks from quantum computers. PQC is deployable today on existing infrastructure via software updates; QKD requires purpose-built optical networks. They solve related but distinct problems and should not be conflated.
Does PQC migration affect VPNs and SSH?
Yes. VPN protocols (IKEv2/IPsec in particular) and SSH both rely on asymmetric key exchange (typically ECDH or RSA) and digital signatures for authentication — both are broken by a CRQC. OpenSSH 9.0 (released April 2022) introduced hybrid post-quantum key exchange using NTRU Prime combined with X25519, and later versions have expanded PQC support. For VPNs, support depends heavily on the vendor: check whether your VPN gateway firmware supports hybrid IKEv2 key exchange with ML-KEM. Both SSH and VPN sessions are targets for HNDL attacks, so migrating long-lived infrastructure credentials and session key exchange should be a priority in your roadmap.