In August 2024, NIST published the three final post-quantum cryptography standards:

  • FIPS 203 (ML-KEM, based on CRYSTALS-Kyber)

  • FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium)

  • FIPS 205 (SLH-DSA, based on SPHINCS+)

Six months on, the headline is no longer news, and it’s time to turn it into a plan. This post collects what I’ve seen work and not work in teams starting the transition.

Key takeaways

  • There isn’t yet a quantum computer capable of breaking RSA-2048. The real risk today is "harvest now, decrypt later": adversaries capture encrypted data today to decrypt later.

  • The first step is the most ignored: honest crypto inventory in layers (external communications, internal PKI, data at rest, vendors).

  • The most frequent mistake is swapping algorithms one-by-one instead of building crypto-agility: architectures that let you change the algorithm without rewriting the application.

  • The tactic that has settled in serious deployments: hybrid algorithms (ECDHE + ML-KEM) for external communications, classical cryptography elsewhere for now.

  • PQC signatures (ML-DSA, SLH-DSA) are larger than ECDSA: an X.509 certificate with ML-DSA grows from 1-2 KB to 4-6 KB.

The scale of the problem first

There isn’t yet a quantum computer capable of breaking RSA-2048 or ECDSA P-256. Serious estimates of when there will be range from a decade to never. But patient adversaries can capture data today and decrypt it tomorrow: that is "harvest now, decrypt later." For data with long-term value, the transition isn’t optional.

The inventory almost nobody has

The first step is the most boring and ignored: knowing where cryptography lives in your organization. Not just TLS on public websites. It includes: VPN between offices, client certificates on IoT machines, firmware update signatures, JWT in internal APIs, at-rest encryption in databases, SSH keys on admin servers, S/MIME signed mail, audit log integrity.

The sensible approach is to tackle it in layers: external communications first, then internal infrastructure, then at-rest data with long retention, then vendor integrations.

A useful tool to start: CBOMkit[1], IBM Research’s open-source toolkit that generates and analyzes crypto inventories (CycloneDX format) for Java and Python applications. Alongside it, the community scripts published for analyzing X.509 certificates.

Crypto-agility before crypto-correct

The most frequent mistake is wanting to swap algorithms one by one. Patch an application with ML-KEM and leave the rest. It produces a tick on a report, but it’s the wrong move when the rest of the stack stays unchanged.

The more productive conversation is about crypto-agility. Instead of asking "which algorithm do we use?", ask "how do we change the algorithm without rewriting the application?" That forces reviewing where the crypto provider is instantiated and whether configuration is externalized. It also forces checking whether on-disk and on-wire formats carry algorithm identifiers, and whether there are compatibility chains for reading old ciphertext while writing new.

A well-designed crypto-agile system today absorbs the first PQC transition without drama, and will also absorb a second when current algorithms show weaknesses.

Hybrids outside, classical inside

The tactic that has settled in serious deployments is using hybrid algorithms in key-exchange for communications, and leaving the rest on classical cryptography for now. A hybrid combines classical ECDHE with ML-KEM in the same negotiation, so an attacker needs to break both.

Cloudflare, Google, and AWS already support hybrids on their TLS edges: by October 2025, more than half of human-initiated TLS traffic on Cloudflare’s network[2] already used the X25519MLKEM768 hybrid exchange. And OpenSSH 9.9[3] added the ML-KEM hybrid (mlkem768x25519-sha256) in 2024, alongside the NTRU Prime hybrid (sntrup761x25519) it already had.

For at-rest symmetric encryption, no urgency: AES-256 remains secure against quantum adversaries under Grover’s algorithm, which reduces effective security to 128 bits: still reasonable.

Sizes, latencies, budgets

PQC standards aren’t drop-in. Signature and key sizes are twenty to a hundred times larger than classical algorithms.

An X.509 certificate with ML-DSA grows from 1-2 KB to 4-6 KB. A full TLS chain with three post-quantum certificates approaches 20 KB. On slow links (cellular IoT, satellite) this shows.

A timeline that makes sense

  • First quarter: honest crypto inventory.

  • Second quarter: enable hybrids on TLS at every balancer and outgoing mail when the partner supports it.

  • Second half: review internal PKI and plan a post-quantum hierarchy for 2026-2027, without rushing.

  • In parallel: adopt crypto-agility as a requirement in all new code.

Mid-term, regulators will push. Germany’s BSI has had recommendations since 2020[4] and France’s ANSSI moved in 2022[5] with a three-phase roadmap. The US NSA’s CNSA 2.0[6] sets staged milestones through full compliance in 2035, and ENISA published a 2024 integration study[7] several governments now use as a reference.

The map of the standards themselves (what ML-KEM, ML-DSA, SLH-DSA and HQC are, and what each one is for) is in NIST PQC: the post-quantum cryptography standards.

How to think about the decision

The most valuable thing I’ve learned is that the post-quantum transition is a perfect excuse to do something you already needed: clean up your organization’s cryptography. In the inventories I have seen, forgotten RSA-1024 keys, SHA-1 certificates, outdated libraries, or hardcoded secrets turn up. PQC comes after; the prior cleanup is what actually raises security.

Treating it as a compliance project with a date and a tick works but is expensive and fragile. Treating it as an opportunity to invest in crypto-agility, crypto hygiene, and documentation pays off more.

And if your reaction is "we’ll leave it for when a quantum computer appears," remember harvest now, decrypt later. For legal acts, medical records, trade secrets, or diplomatic communications, the transition isn’t optional. It’s a matter of dates.

This article is also available in Spanish: Estándares NIST PQC finales: qué hacer con ellos ahora.

Sources:

  1. Federal Register: Announcing Issuance of FIPS 203, 204 and 205[8]
  2. IBM Research: Managing cryptography with CBOMkit[1]
  3. Cloudflare: The state of the post-quantum Internet in 2025[2]
  4. OpenSSH 9.9 release notes[3]
  5. BSI: Migration to Post-Quantum Cryptography (recommendations for action)[4]
  6. ANSSI: views on the Post-Quantum Cryptography transition[5]
  7. NSA: Announcing CNSA 2.0 quantum-resistant algorithm requirements[6]
  8. ENISA: Post-Quantum Cryptography, Integration study[7]

Frequently asked questions

Do I need to migrate to post-quantum cryptography if no quantum computer can break RSA-2048 yet?

Yes, for data with long-term value. There is not yet a quantum computer capable of breaking RSA-2048 or ECDSA P-256, and serious estimates of when there will be range from a decade to never. The real risk today is "harvest now, decrypt later": patient adversaries capture encrypted traffic now to decrypt it tomorrow. For legal acts, medical records, trade secrets, or diplomatic communications the transition is a matter of dates, not optional.

Do I also have to change the AES encryption on data at rest?

There is no urgency. AES-256 remains secure against quantum adversaries: Grover's algorithm reduces its effective security to 128 bits, which is still reasonable. The tactic that has settled in serious deployments is using hybrids such as ECDHE plus ML-KEM for key exchange in external communications and leaving the rest on classical cryptography for now. PQC signatures with ML-DSA or SLH-DSA are worth waiting on because sizes are large and PKI is not ready.

How much bigger do certificates get with post-quantum signatures?

An X.509 certificate with ML-DSA grows from 1-2 KB to 4-6 KB, and a full TLS chain with three post-quantum certificates approaches 20 KB. PQC signature and key sizes are twenty to a hundred times larger than classical algorithms such as ECDSA, so the standards are not drop-in. On slow links such as cellular IoT or satellite the difference shows, which is why hybrids are recommended for key exchange first and signatures later.

Sources

  1. CBOMkit
  2. more than half of human-initiated TLS traffic on Cloudflare’s network
  3. OpenSSH 9.9
  4. BSI has had recommendations since 2020
  5. ANSSI moved in 2022
  6. NSA’s CNSA 2.0
  7. ENISA published a 2024 integration study
  8. Federal Register: Announcing Issuance of FIPS 203, 204 and 205