Post-Quantum Cryptography: What It Is and Migration

Post-quantum cryptography (PQC) is the set of algorithms designed to withstand both a classical computer and a quantum computer capable of breaking RSA and elliptic-curve cryptography. This is not a lab curiosity or a twenty-years-away concern: the data an attacker captures and stores encrypted today can be decrypted the day a large enough quantum computer exists. That threat, known as harvest-now-decrypt-later, forces the migration to start now, before the quantum hardware arrives. This guide explains exactly what a quantum computer breaks, which standards NIST published in 2024 (ML-KEM, ML-DSA and SLH-DSA), and how to draw up a crypto-agility migration roadmap for an enterprise.

Post-quantum cryptography at a glance

• Shor's algorithm breaks RSA, Diffie-Hellman and elliptic-curve cryptography (ECC): all of today's asymmetric public-key crypto.
• The immediate threat is harvest-now-decrypt-later: the attacker stores encrypted traffic today to decrypt it once they have a quantum computer.
• NIST standardised the first algorithms in 2024: FIPS 203 (ML-KEM/Kyber), FIPS 204 (ML-DSA/Dilithium) and FIPS 205 (SLH-DSA/SPHINCS+).
• Symmetric cryptography (AES-256, SHA-384) survives: you only need larger key sizes because of Grover's algorithm.
• Migration rests on crypto-agility: inventory, prioritise by long-term confidentiality and deploy in hybrid mode.

What post-quantum cryptography is

Post-quantum cryptography groups public-key schemes whose security rests on mathematical problems that neither a classical nor a quantum computer can solve efficiently. Do not confuse it with quantum cryptography or quantum key distribution (QKD): PQC is classical software that runs on the hardware you already own (servers, phones, HSMs), with no need for dedicated fibre or photons.

The families that have survived scrutiny are mainly four: lattices, error-correcting codes, hash functions and multivariate equations. The NIST standards lean above all on lattices, thanks to their good balance between key size and performance.

The problem: Shor and Grover

Two quantum algorithms set the clock. Shor's algorithm factors large integers and solves the discrete logarithm in polynomial time, which instantly sinks RSA, Diffie-Hellman (DH) and elliptic-curve cryptography (ECC, ECDSA, ECDH). It does not weaken them: it makes them completely useless once a quantum computer with enough stable logical qubits exists.

Grover's algorithm is gentler: it speeds up brute-force search quadratically, so it halves the effective security of symmetric cryptography. The practical consequence is that AES-128 drops to an uncomfortable margin, but AES-256 and hashes such as SHA-384 remain secure simply by doubling the key or digest size. That is why the migration focus is on public-key crypto, not on the symmetric encryption of your disks.

The harvest-now-decrypt-later threat

The most common mistake is to assume there is no urgency because the quantum computer does not exist yet. The harvest-now-decrypt-later threat (also store-now-decrypt-later) breaks that reasoning: a resourced adversary, typically a nation-state actor, intercepts and stores TLS, VPN or encrypted email traffic today even though it cannot read it. The day they have a cryptographically relevant quantum computer, they decrypt the entire archive retroactively.

This turns the exposure window into a countdown that is already running for any data with a long shelf life: medical records, industrial secrets, signing keys, classified information or personal data under retention obligations. Mosca's inequality captures it well: if the time a piece of data must stay secret (X) plus the time it takes you to migrate (Y) exceeds the time until the quantum computer exists (Z), you already have a problem. With X measured in decades for many sectors, the arithmetic does not add up if you wait.

Recent history also counsels caution with the post-quantum candidates themselves. SIKE/SIDH, a NIST finalist, was broken in 2022 with a classical computer (the Castryck-Decru attack) in a matter of hours, and the multivariate scheme Rainbow fell the same year. In addition, 2024 saw KyberSlash, a timing leak documented in several ML-KEM implementations. The lesson is not to distrust the standard but to deploy audited implementations and, during the transition, hybrid modes that combine the classical with the post-quantum.

The NIST PQC standards

After almost eight years of a public competition, NIST published the first three federal post-quantum cryptography standards in August 2024. They are the reference regulators and auditors now cite, and the foundation on which today's libraries are built. This public-key ground is the same terrain as a classical PKI, only with new primitives.

ML-KEM (FIPS 203)

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), derived from CRYSTALS-Kyber, is the key-encapsulation mechanism meant to replace RSA and ECDH key exchange. It is the piece that protects the confidentiality of TLS, VPN and email sessions, exactly the target of harvest-now-decrypt-later. It offers three levels: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. The most used in practice is ML-KEM-768, with a public key of about 1,184 bytes and a ciphertext of 1,088 bytes: larger than ECDH, but perfectly manageable in TLS.

ML-DSA and SLH-DSA (FIPS 204 and 205)

For digital signatures (authentication, certificates, code signing) there are two complementary standards:

• ML-DSA (FIPS 204), derived from CRYSTALS-Dilithium, is the general-purpose lattice-based signature. ML-DSA-65 produces signatures of about 3.3 KB, considerably heavier than ECDSA, which impacts certificate and handshake sizes.
• SLH-DSA (FIPS 205), derived from SPHINCS+, is a signature based only on hash functions. It is slower and its signatures are large, but its security rests on a very conservative assumption, which makes it attractive as a backup when very long-term trust is the priority.

NIST is also preparing FN-DSA (based on FALCON, the future FIPS 206) for cases that need compact signatures, and in 2025 it selected HQC, a code-based KEM, as a backup alternative to ML-KEM for mathematical diversity. For firmware and software signing there is a dedicated path already available: the stateful hash-based signatures LMS and XMSS from NIST SP 800-208.

A crypto-agility migration roadmap

Crypto-agility is the ability to swap algorithms without redesigning the application. That is the underlying goal: it is not just about installing Kyber, but about making the next cryptographic change (because there will be one) a configuration update rather than a two-year project. Migration is tackled in phases.

1. Cryptographic inventory. You cannot protect what you cannot see. Produce a CBOM (Cryptographic Bill of Materials) that locates where RSA, ECC and DH are used: TLS certificates, VPN tunnels, code signing, JWTs, encrypted databases, HSMs and third-party dependencies. Cryptographic discovery scanners and traffic analysis help map what is often hidden inside embedded libraries.
2. Prioritise by data shelf life. Sort by the harvest-now-decrypt-later criterion: first what must stay secret for decades and what travels over hostile networks. A long-confidentiality channel outweighs a token that expires in five minutes.
3. Deploy in hybrid mode. The current consensus (NIST, BSI, ANSSI) is to combine a classical algorithm with a post-quantum one, so that breaking the session requires breaking both. In TLS 1.3 this materialises as groups such as X25519MLKEM768, already enabled by default in browsers like Chrome and in providers like Cloudflare.
4. Test and measure the impact. Larger keys and signatures affect packet size, fragmentation and low-memory devices. Validate performance on handshakes, certificates and embedded systems before rolling out broadly.

The regulatory deadlines are already on the table. The NSA's CNSA 2.0 suite mandates ML-KEM-1024 and ML-DSA-87 and sets exclusive use toward the 2030-2035 range depending on the system category. The NIST IR 8547 draft marks the deprecation of RSA-2048 and 112-bit ECC from 2030 and their disallowance after 2035. In Europe, BSI and ANSSI push the hybrid approach, and frameworks such as NIS2 and DORA will eventually fold cryptographic resilience into their requirements. The same agility logic underpins any serious Zero Trust architecture.

Tooling and deployment in practice

The good news is that PQC is already usable with standard software. OpenSSL 3.5 (2025) adds native support for ML-KEM, ML-DSA and SLH-DSA, and the Open Quantum Safe project offers the liboqs library and the oqs-provider for earlier versions. AWS KMS, Cloudflare and the major cloud providers already expose hybrid key exchange.

Generating a post-quantum key pair is as simple as this:

# Key encapsulation (KEM) with ML-KEM-768
openssl genpkey -algorithm ML-KEM-768 -out mlkem768.key

# Signature with ML-DSA-65
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key

# List the available key-exchange groups
openssl list -kem-algorithms

And to check whether a server already negotiates hybrid key exchange in TLS 1.3:

openssl s_client -connect example.com:443 -groups X25519MLKEM768

Firmware signing deserves separate attention: because of its very long life cycle it is one of the first candidates to migrate, and there LMS/XMSS (SP 800-208) are usually the practical choice. Just as with DNSSEC in DNS security, signing is the part that takes longest to propagate across an entire chain of trust, so it pays to start early. And although phishing-resistant user authentication such as FIDO2 and passkeys or phishing-resistant MFA uses classical curves today, the FIDO Alliance is already working on post-quantum variants, one more piece of the same inventory to watch.

Frequently asked questions

When will the quantum computer that breaks RSA arrive?

No one has a reliable date, and that is precisely the problem. Serious estimates point to the 2030s or beyond, but the uncertainty is no excuse to wait: because of harvest-now-decrypt-later, any data that must stay secret for more than ten years is already exposed today if it travels without post-quantum protection. The decision does not hinge on the hardware date, but on the shelf life of your data.

Do I also have to change AES and hashes?

Not in the same way. Symmetric cryptography is only affected by Grover's algorithm, which halves effective security. It is enough to use AES-256 instead of AES-128 and hashes of at least 384 bits (SHA-384, SHA-512) to keep the margin. The bulk of the migration concentrates on public-key crypto: RSA, DH and ECC.

What is the difference between Kyber and ML-KEM?

They are essentially the same algorithm at different moments. Kyber (or CRYSTALS-Kyber) is the name of the candidate that won the NIST competition; ML-KEM is the name of the final standard published in FIPS 203, with minor adjustments to the original Kyber. The same applies to Dilithium and ML-DSA (FIPS 204). In recent documentation it is best to use the standardised names.

Why is hybrid mode recommended rather than the post-quantum algorithm alone?

Because post-quantum schemes are young, and recent history (the fall of SIKE and Rainbow in 2022) shows a candidate can break unexpectedly. Hybrid mode combines a well-tested classical algorithm with a post-quantum one, so an attacker would have to defeat both. It offers protection against the quantum computer without betting everything on a still-unproven primitive.

Where do I start the migration in my company?

With the cryptographic inventory (CBOM). Before choosing algorithms you need to know where asymmetric cryptography is used: certificates, VPNs, code signing, JWTs, HSMs and external dependencies. With that map you prioritise by data shelf life and deploy in hybrid mode starting with the long-confidentiality channels. Without an inventory, any migration plan is flying blind.

Related resources

• What Is PKI (Public Key Infrastructure)
• What Is FIDO2: phishing-resistant MFA and passkeys
• Phishing-Resistant MFA: FIDO2, passkeys and CISA
• DNS security: DNSSEC, DoH and DoT
• What Is Zero Trust: architecture, principles and implementation

Post-quantum cryptography with Secra

At Secra we help B2B organisations prepare the post-quantum transition without slowing operations. We build the cryptographic inventory (CBOM), prioritise by harvest-now-decrypt-later risk, design the hybrid rollout across TLS and code signing, and align everything with your regulatory framework (NIS2, DORA, ENS, ISO 27001). If you want to know which part of your cryptography would fall to a quantum computer and in what order to migrate it, review our GRC consulting services or contact Secra for an initial no-commitment session.