The question worth asking is not whether your organization will migrate to post-quantum cryptography. It is which of your systems will still be running RSA-2048 in 2032, and who signed off on that. Budget cycles, procurement lead times, and certificate lifetimes decide the answer far more than the maturity of the algorithms, and the algorithms have been settled since August 2024.
That framing matters because it changes what you fund first. Teams that start with a library upgrade usually discover, six months in, that they cannot say how many TLS endpoints they operate, let alone which ones terminate in firmware they cannot patch. The work that pays off is unglamorous: inventory, then key establishment, then signatures, in that order.
The date that matters is not the standard's publication date
NIST published the first three finalized post-quantum standards in August 2024. The migration clock, though, is set by two other things. The first is the lifetime of the data you protect. Anything with a confidentiality requirement stretching past the early 2030s is exposed to a harvest-now, decrypt-later strategy in which an adversary records ciphertext today and decrypts it once a cryptographically relevant quantum computer exists. The second is the deprecation guidance in NIST IR 8547, still a draft, which proposes deprecating RSA-2048 and the common elliptic-curve algorithms around 2030 and disallowing them after 2035.
Read those together and the practical deadline lands earlier than most roadmaps assume. If a system must be replaced by 2030 and your hardware refresh cycle is five years, the procurement decision is being made now.
What the three standards actually change
FIPS 203 specifies ML-KEM, a key-encapsulation mechanism derived from CRYSTALS-Kyber, used to establish a shared secret. FIPS 204 specifies ML-DSA, derived from CRYSTALS-Dilithium, for digital signatures. FIPS 205 specifies SLH-DSA, derived from SPHINCS+, a hash-based signature scheme that trades signature size and speed for conservative security assumptions. The split is the useful part: key establishment and signatures have different failure modes, different performance profiles, and very different migration paths.
Two practical consequences. ML-KEM keys and ciphertexts are larger than their elliptic-curve equivalents, which matters at connection volume and in constrained environments. ML-DSA public keys and signatures are also larger, which matters for certificate chains and for anything that stores signatures in a fixed-size field, including firmware and smart cards.
Harvest now, decrypt later: what is actually exposed
Not all traffic is equally urgent. Session keys for a request that completes in milliseconds are not the concern. The concern is long-lived confidential data crossing networks you do not control: backups replicated to object storage, database snapshots, API payloads containing identity or health data, and key material wrapped for transport. If an adversary records that traffic today, the protection has to outlive the recording.
A useful triage is to sort data stores by required confidentiality period rather than by system criticality. Anything with a ten-year or longer retention requirement belongs in the first migration wave regardless of how modern the surrounding stack looks. Data with a two-year retention requirement can follow the platform's default timeline.
Encryption at rest raises a second, costlier question. Ciphertext already written with a classical algorithm stays exposed for as long as it is stored, so the migration is not finished when the transport moves. Re-wrapping data encryption keys under a post-quantum-wrapped key hierarchy is usually cheaper than re-encrypting the data itself, and it is the step most programs forget to budget. Ask your storage and backup vendors whether key wrapping is post-quantum capable, and test the re-wrap path on a copy before you need it at scale.
Inventory first: you cannot migrate what you cannot enumerate
Cryptographic discovery has four layers, and most programs stop after the first. The transport layer is TLS endpoints, load balancers, API gateways, and service mesh certificates. The identity layer is certificate authorities, client certificates, and signing keys. The application layer is libraries, hard-coded algorithm choices, and third-party SDKs. The device layer is firmware, VPN concentrators, industrial controllers, and anything whose update path involves a truck.
The output should be a cryptography bill of materials attached to each service, in the same way software bills of materials now accompany releases. SBOM tooling increasingly emits a cryptography inventory alongside component lists, which gives you a starting point, but it will not find the appliance in a branch office. Assign an owner per endpoint, record whether it is patchable by you or by a vendor, and record the algorithm configuration. A spreadsheet with those fields beats a scanning tool nobody has time to interpret.
Hybrid TLS is the cheap first move
Hybrid key establishment combines a classical key exchange with a post-quantum one, so the session stays secure if either holds up. It is the migration most organizations can complete first because it changes a cipher suite preference, not an application. Browsers and major content delivery networks have been negotiating hybrid key agreement by default since 2024, and the current hybrid group is X25519MLKEM768. Cloudflare's measurement work shows that a large share of human traffic on its network is already protected this way, which means the client side of your external estate is largely ready.
Your side is the work. Inventory which terminators support hybrid groups, then enable them in preference order with a classical fallback for old clients. Test connection success rates and handshake latency before and after. Then write down the date by which the fallback is removed, because a hybrid-only policy never happens on its own.
Signatures are the hard half
Encryption migration is a configuration change. Signature migration is a trust-chain change, and trust chains move at the speed of the slowest participant. Certificates are issued by authorities whose roots are embedded in devices and operating systems you do not control. Code signing keys are often the most tightly held secrets in the company and the least documented. Firmware signatures may be verified by a bootloader that cannot be updated in the field.
Sequence the signature work by lifetime. Start with internal service-to-service certificates and internal PKI, where you control both ends and certificate lifetimes can be measured in days. Then code signing for internal artifacts. Then public TLS certificates, which depend on certificate authorities and client trust stores. Leave hardware roots of trust and firmware for last and start vendor conversations first, because those timelines are measured in years and your leverage shrinks as the deadline approaches.
The 2027-2032 roadmap
| Phase | Window | Scope | Exit criteria |
|---|---|---|---|
| 0. Inventory | 2027 | Endpoint discovery, CBOM per service, owners, patchability, data-retention triage | 90 percent of external endpoints enumerated with an owner and an algorithm record |
| 1. Key establishment | 2027-2028 | Hybrid TLS on all internet-facing terminators; internal mTLS pilots; HSM support check | Hybrid negotiated by default, fallback removal date scheduled |
| 2. Internal signatures | 2028-2030 | Internal CA to ML-DSA, short-lived service certificates, code signing pilots | New internal certificates are post-quantum by default |
| 3. External trust | 2030-2031 | Public certificate chains, vendor attestations, appliance replacement | No new RSA-2048 or ECC issuance without an approved exception |
| 4. Legacy closeout | 2031-2032 | Firmware and device roots, exception register burn-down | Every remaining classical dependency has a dated retirement plan |
Three traps that cost the most money
First, treating crypto agility as a future feature. If algorithm choice is compiled into a product, every future migration repeats this one. Ask vendors where the algorithm is selected at run time and get the answer in writing. Second, forgetting key management. Your hardware security modules need firmware that supports ML-KEM and ML-DSA, and that is a procurement lead time, not a software update. Third, signing multi-year vendor contracts without a post-quantum clause. The clause you want names a delivery date for post-quantum support, requires a cryptography inventory on request, and gives you termination rights if the date slips.
What to do next
- Name an owner for cryptographic inventory across infrastructure, applications, and devices, and give that person a budget line rather than a side project.
- Sort data stores by confidentiality lifetime and put everything above ten years in the first migration wave.
- Enable hybrid key agreement on internet-facing terminators this quarter, and record the date the classical fallback gets removed.
- Ask your five largest vendors for their post-quantum roadmap, their HSM support timeline, and a cryptography bill of materials. Put the answers in the contract file.
- Add a post-quantum clause to new contracts: delivery date, inventory on request, termination rights if the date slips.