Post-Quantum Cryptography: An Inventory-First Migration Plan

What has NIST standardised so far?

When do RSA and elliptic-curve cryptography have to go?

NIST IR 8547, still an initial public draft, proposes the transition timeline. For digital signatures (RSA, ECDSA, EdDSA) and for key establishment (finite-field and elliptic-curve Diffie-Hellman and MQV, and RSA):

• At 112 bits of security strength: deprecated after 2030, disallowed after 2035.
• At 128 bits or more: disallowed after 2035.

Symmetric algorithms with at least 128-bit security, such as AES-128 and above, remain approved. The pressure is on public-key cryptography.

US federal buying is moving too. In January 2026, CISA published a list of product categories (including cloud services, web software, networking, and endpoint security) where organisations should acquire only products capable of post-quantum cryptography.

Is post-quantum cryptography already in production?

Yes, for key exchange on the web. Chrome 131 moved from the pre-standard Kyber hybrid to X25519MLKEM768, a hybrid of classical X25519 and ML-KEM-768. In April 2026, Cloudflare reported that more than 65% of human traffic to its network was post-quantum encrypted. Your users' browsers are likely negotiating post-quantum key exchange with any server or CDN that supports it.

Signatures and certificates are further behind, which is why authentication is the longer project.

Where should a migration start?

1. Inventory where public-key cryptography is used

• Network: TLS on public and internal endpoints, VPNs, SSH, service mesh, and message brokers.
• Code and dependencies: calls to RSA, ECDSA, ECDH, and DH through crypto libraries, JWT signing, and custom protocols.
• Identity: certificate authorities, code signing, SAML and OIDC signing keys, and hardware security modules.
• Data at rest: anything encrypted with keys that are wrapped or exchanged using RSA or elliptic curves, especially backups and archives.
• Vendors: SaaS, cloud KMS, network appliances, and firmware. Ask each for their roadmap.

A quick check of what a TLS endpoint negotiates, using OpenSSL 3.5 or later, which includes ML-KEM:

openssl s_client -connect api.example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
  | grep -i "group"

# Code search starting points for an inventory
rg -n -i "rsa|ecdsa|ecdh|secp256r1|prime256v1|rs256|es256" src/ config/ infra/

2. Prioritise by how long the protection must last

Rank each use by how long its data or signatures must stay trustworthy. Key exchange protecting data that must stay confidential for years is exposed to "harvest now, decrypt later" and comes first. Long-lived signatures, such as firmware, device identity, and document signing, come next, because keys and devices in the field are hard to replace.

3. Build crypto agility, then switch

• Centralise cryptography behind a small number of libraries or services rather than calls scattered through the code.
• Prefer hybrid key exchange (classical plus ML-KEM) during the transition, as browsers do.
• Make algorithms configurable, with tests that exercise both classical and post-quantum paths.
• Watch for larger keys and signatures breaking assumptions: packet sizes, header limits, database columns, and hardware constraints.

What does a cryptography review actually check?

Beyond algorithm choice, a review looks for the failures that break migrations: hardcoded algorithms, keys that never rotate, certificates with unknown owners, libraries too old to support ML-KEM, and protocols that silently downgrade. It produces a cryptographic bill of materials and a prioritised migration backlog, so the work can be planned instead of rushed.