Post-quantum cryptography, answered

Post-quantum cryptography (PQC) is a family of public-key algorithms designed to resist attacks from both today's computers and future large-scale quantum computers.

PQC runs on ordinary hardware and software. It is a software and protocol upgrade, not a new kind of network or quantum device.

Nobody knows. A 'cryptographically relevant quantum computer' (CRQC) does not exist yet, and expert estimates of when one might arrive vary widely.

What matters is that migration takes years. Governments have therefore set dates now: the UK NCSC and the EU both aim for full migration by 2035, with the highest-priority systems done earlier, and NIST will deprecate RSA and elliptic-curve algorithms after 2030.

An attacker records encrypted traffic or steals encrypted data today, stores it, and decrypts it once a quantum computer is available.

This means data that must stay confidential for many years — health records, financial data, intellectual property, state secrets — is already at risk, even though the quantum computer does not exist yet.

Public-key algorithms based on factoring or discrete logarithms are broken outright by Shor's algorithm. That covers RSA, Diffie-Hellman, and all elliptic-curve schemes (ECDH, X25519, ECDSA, EdDSA). These protect almost every TLS connection, VPN, SSH session, certificate and code signature today.

Symmetric encryption and hash functions are not seriously affected. NIST and the NCSC both say AES with keys of 128 bits or more, SHA-2 and SHA-3 can continue to be used. AES-256 is only required in some high-assurance settings, such as US national security systems under CNSA 2.0.

NIST published three final standards in August 2024: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for general-purpose signatures, and FIPS 205 (SLH-DSA), a conservative hash-based signature. For firmware and code signing, the stateful hash-based schemes LMS and XMSS (NIST SP 800-208) are also approved.

For most uses, NIST recommends ML-KEM-768 as the default, and the NCSC recommends ML-KEM-768 and ML-DSA-65.

Two more standards are in progress but not yet final: FIPS 206 (FN-DSA, based on Falcon), which offers smaller signatures, and a standard for HQC, a code-based backup to ML-KEM that NIST selected in March 2025. Don't deploy either in production until they are published as final standards.

The NCSC's guidance sets three milestones. By 2028: define your migration goals, complete discovery and build an initial plan. By 2031: complete your highest-priority migrations and refine the plan. By 2035: complete migration across all systems, services and products.

These are targets rather than law, but they are already shaping regulator and procurement expectations, especially in government and regulated sectors. In October 2026 the NCSC also updated its TLS guidance to recommend post-quantum key exchange, noting that protecting data in transit will often be a 2031 priority.

In the US, NIST published the final version of IR 8547 on 27 October 2026. It deprecates RSA, ECDSA, EdDSA and (EC)Diffie-Hellman at all key sizes after 2030 and disallows them after 2035. The 2024 draft had only deprecated the weakest key sizes in 2030; the final version brings everything forward. 'Deprecated' means still allowed, but only if the data owner accepts the risk.

US federal high-value and high-impact systems must use post-quantum key establishment by 31 December 2030 and post-quantum signatures by 31 December 2031. For national security systems, the NSA's CNSA 2.0 requires its algorithms in new products from 1 January 2027.

The EU's coordinated roadmap asks member states to start by the end of 2026, migrate high-risk and critical-infrastructure use cases by the end of 2030, and finish by the end of 2035.

Almost every organisation uses quantum-vulnerable cryptography: in websites, APIs, VPNs, email, identity providers, databases, devices and third-party software. The question is where it is and what it protects.

Start with a cryptographic inventory: find where public-key crypto is used, which algorithms and key sizes, which systems own it, and how long the data it protects must stay secret.

A simple rule of thumb from researcher Michele Mosca. Let X be how long your data must stay secure, Y how long migration will take, and Z how long until a quantum computer can break your crypto.

If X + Y is greater than Z, you are already too late for that data. For example, records kept for 10 years with a 3-year migration are at risk if a quantum computer arrives within 13 years.

A Cryptographic Bill of Materials lists the cryptographic assets in a system — algorithms, keys, certificates, protocols and libraries — and where they are used.

The CycloneDX standard (version 1.6 onwards) defines a CBOM format, so inventories can move between tools and be shared with auditors and customers.

Start with two groups. First, internet-facing key exchange that protects long-lived confidential data, because that is exposed to 'harvest now, decrypt later' today. Second, things that are slow to replace: root certificate authorities, firmware and code signing, hardware security modules, and devices that stay in the field for many years.

Signatures cannot be harvested in the same way, but they still need early planning: NIST's final IR 8547 treats signature migration as urgent because roots of trust take so long to change. Short-lived, internal-only, low-sensitivity systems can usually follow later.

The NCSC says discovery, prioritisation and planning should be happening now. In practice:

1. Get a senior sponsor, treat PQC as a business risk, and set migration goals.
2. Build a cryptographic inventory.
3. Rank systems by risk and by how long they will take to change.
4. Ask suppliers for their PQC roadmaps and add requirements to contracts.
5. Move to TLS 1.3 and turn on post-quantum key exchange where your platforms support it.
6. Build crypto-agility into anything you are building or buying now.

A hybrid scheme combines a classical algorithm with a post-quantum one, so the connection stays secure as long as either one holds. The most common example is the TLS key-exchange group X25519MLKEM768.

Hybrid is the most widely deployed option today and a sensible first step, especially for interoperability. But both the NCSC and NIST treat it as an interim measure: it adds complexity, and you should plan to move to post-quantum-only later. The NCSC's latest TLS guidance recommends both hybrid and pure post-quantum options.

Usually, yes — if you are on TLS 1.3, the only version that supports post-quantum key exchange. The hybrid groups (X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024) were standardised in RFC 10024 in August 2026.

Chrome and Firefox have used X25519MLKEM768 by default since late 2024, and Apple added it in iOS 26 and macOS Tahoe. On servers, OpenSSL 3.5 and later, BoringSSL, AWS-LC and Go support it, and many CDNs and load balancers offer it as a setting. OpenSSH 10.0 and later use post-quantum key exchange by default.

Post-quantum certificates for the public web are not available yet. Chrome prefers an approach called Merkle Tree Certificates, and Let's Encrypt is aiming for production support in 2027. Plan for certificate changes, but don't wait for them before moving key exchange.

Keys and signatures are larger. An ML-KEM-768 public key is 1,184 bytes versus 32 bytes for X25519, and an ML-DSA-65 signature is 3,309 bytes versus about 64 bytes for ECDSA P-256.

Computation is usually fast, but the extra size can break things that assume small messages: packet sizes, certificate chains, constrained devices, older middleboxes and hardware security modules. Test before you roll out.

Crypto-agility means you can change algorithms through configuration rather than rewriting code. In practice: route cryptography through one shared library or service, avoid hard-coded algorithm choices, and keep an up-to-date inventory.

It makes this migration cheaper, and the next one — there will be one — much cheaper still.

For most organisations, no. QKD needs specialised hardware and dedicated links, and it does not provide authentication on its own. The NCSC does not endorse QKD for government or military use, cautions against relying on it alone for business-critical networks, and advises that post-quantum cryptography is the best mitigation.

Ask which public-key algorithms their product uses, when it will support ML-KEM and ML-DSA (or other NIST standards), whether algorithms are configurable, and how they will deliver updates to products already deployed. Add PQC readiness to new contracts and renewals.