A cryptographically relevant quantum computer does not yet exist in public, and that fact lulls a lot of organisations into deferring post-quantum cryptography (PQC) to some vague future budget. That is the wrong read. The data you transmit today, if it has a confidentiality lifetime measured in years, is already exposed to an attack that does not need a quantum computer until later. The migration is also the largest cryptographic transition most organisations have ever attempted, and it is gated by inventory work that takes far longer than the actual algorithm swap. The time to start is now.
Harvest now, decrypt later
The threat that makes PQC urgent is not future. It is harvest now, decrypt later. An adversary records encrypted traffic or exfiltrates encrypted data stores today, stores them cheaply, and waits. When a quantum computer capable of running Shor's algorithm at scale becomes available, the public-key cryptography protecting that captured data (RSA, elliptic-curve Diffie-Hellman, ECDSA) falls. The symmetric and hashing primitives are less affected: AES-256 and SHA-384 remain broadly safe, with Grover's algorithm only halving effective strength.
The practical question is the Mosca inequality: if the time your data must stay confidential, plus the time it takes you to migrate, exceeds the time until a capable quantum computer arrives, you are already late. For health records, legal files, intellectual property, government data, and long-lived credentials, the confidentiality lifetime alone can be a decade or more. That is why long-life secrets are the first thing to move.
The NIST standards are finalised
The waiting period is over. NIST published the first finalised PQC standards in 2024, which removes the main excuse for delay.
- FIPS 203, ML-KEM (derived from CRYSTALS-Kyber): the module-lattice key encapsulation mechanism. This is the workhorse for establishing shared keys, the replacement for RSA and ECDH key exchange in TLS and similar protocols.
- FIPS 204, ML-DSA (derived from CRYSTALS-Dilithium): the primary module-lattice digital signature algorithm, replacing RSA and ECDSA signatures for most use cases.
- FIPS 205, SLH-DSA (derived from SPHINCS+): a stateless hash-based signature scheme. It is larger and slower but rests on well-understood hash assumptions, making it a conservative backup for signatures where you want diversity of mathematical foundation.
The expected default for most deployments is hybrid: combine a classical algorithm (such as X25519) with ML-KEM so the connection stays at least as strong as the classical scheme during the transition, while gaining quantum resistance. Major browsers, TLS libraries, and cloud providers already support hybrid key exchange.
You cannot migrate what you have not inventoried
The single biggest predictor of a smooth PQC migration is a cryptographic inventory, and almost nobody has one. You need to know where cryptography is used, what algorithms and key sizes are in play, what the data protected by each is worth, and how long it must stay confidential. This is harder than it sounds because cryptography is buried in TLS configurations, VPNs, code-signing pipelines, hardware security modules, embedded devices, database encryption, certificate authorities, and third-party dependencies.
Build the inventory across several lenses:
- Network: TLS versions and cipher suites on every endpoint, VPN tunnels, internal service-to-service encryption.
- Data at rest: database and disk encryption, backups, object storage, and the key hierarchies behind them.
- Identity and signing: certificate authorities, code signing, document signing, and authentication tokens.
- Embedded and operational technology: devices with long field lifetimes and firmware that may never be updated.
- Supply chain: which of your vendors and libraries hold cryptographic responsibility, and what their PQC roadmap is.
This inventory work overlaps heavily with a thorough code security audit and architecture review, because cryptographic misuse and hardcoded algorithm choices surface in the same pass.
Crypto-agility is the real deliverable
The standards will evolve, attacks on lattice schemes will be researched, and you may need to swap algorithms again. The strategic goal is not to bolt ML-KEM into every system once. It is crypto-agility: the ability to change algorithms without re-architecting. In practice that means abstracting cryptographic operations behind interfaces rather than calling primitives directly, centralising algorithm selection in configuration or a key management service, and avoiding hardcoded key sizes and curve names scattered through application code.
Systems built for agility will absorb the next transition cheaply. Systems with cryptography welded into business logic will face the same painful project all over again. Treat agility as the durable investment and the specific algorithm as a current setting.
A prioritised migration plan
Sequence the work by risk, not by ease.
- Phase one, discover. Build the cryptographic inventory and classify data by confidentiality lifetime. Identify the long-life secrets exposed to harvest now, decrypt later.
- Phase two, protect long-life data first. Move the data with the longest confidentiality requirement to hybrid key exchange and consider re-encrypting stored data that an adversary may already have captured.
- Phase three, signatures and identity. Plan ML-DSA adoption for code signing and certificates, accounting for larger key and signature sizes that can break size assumptions in protocols and storage.
- Phase four, broad rollout. Enable hybrid PQC across TLS and VPNs, working with vendors on their timelines and testing for performance and interoperability.
- Phase five, govern. Bake crypto-agility into procurement and architecture standards so new systems are PQC-ready by default.
Frequently asked questions
Do I need to replace AES?
No. Symmetric encryption with AES-256 and hashing with SHA-384 or stronger remain appropriate. The urgent replacements are public-key algorithms used for key exchange and signatures.
Is it safe to deploy ML-KEM alone?
Hybrid deployment combining a classical algorithm with ML-KEM is the recommended default during the transition, so a flaw in either scheme does not weaken the connection below the classical baseline.
When should we start?
Now. The inventory and crypto-agility work takes far longer than the algorithm swap, and the harvest-now threat already applies to data you send today.
If you want a cryptographic inventory and a phased PQC roadmap tailored to your environment, get in touch with Basalt Cyber.