Post-quantum migration starts with a cryptographic inventory

Choose the right cryptographic building block

NIST’s finalized standards distinguish ML-KEM for key encapsulation from ML-DSA and SLH-DSA for digital signatures. A KEM helps establish key material; it is not a bulk-data cipher or a signature scheme. Selecting a standardized primitive still requires a secure implementation and protocol integration. Avoid designing a proprietary hybrid by concatenating outputs without a reviewed construction. Algorithm names alone do not establish system security.

Match migration effort to the life of the data

Inventory where public-key cryptography appears: TLS endpoints, VPNs, device enrollment, firmware signing, code distribution, certificates and backups. Record data confidentiality lifetime and how long replacement takes.

In an illustrative case, data needing 15 years of confidentiality and a five-year migration lead time require a longer planning horizon than a short-lived public page. This prioritizes exposure and operational effort; it does not predict the arrival date of a cryptographically relevant quantum computer.

Practise replacement before it becomes urgent

Pilot supported implementations in noncritical environments. Measure handshake bytes, CPU use, signing and verification latency, certificate-chain limits and failure behavior on constrained devices. Plan compatibility transitions, downgrade resistance, rollback and long-term signature verification.

Protect keys, random generation and software supply chains throughout. More capable AI does not by itself prove that sound cryptographic algorithms are broken. Treat quantum readiness as disciplined crypto-agility with tested replacement paths, rather than a marketing claim that a system is permanently quantum-proof.