Key takeaways
- 1You cannot migrate what you cannot see: start with a cryptographic inventory, ideally as a CycloneDX cryptographic bill of materials (CBOM).
- 2Prioritise by data shelf life and exposure, not by system size. Payment links, backups and long-lived archives usually come first.
- 3Build crypto-agility as you go, so the next algorithm change is a configuration change rather than another programme.
1. Discover
Cryptography hides in code, libraries, TLS endpoints, certificates, hardware security modules, key management systems, cloud services, databases, firmware and vendor products. Discovery combines automated scanning (source code, binaries, network traffic, certificate stores, cloud configuration) with interviews, because the riskiest cryptography is often in systems nobody owns any more.
Record the result as a cryptographic bill of materials. The CycloneDX standard (version 1.6 onwards) has a CBOM format that lists each algorithm, key, certificate and protocol, where it is used and what depends on it, and that can be compared over time.
2. Prioritise
Score every use of cryptography on what it protects and how long it must stay protected. Mosca's inequality (shelf life plus migration time against the threat horizon) gives a defensible first cut. Then weigh business criticality, external exposure, and how hard the system is to change.
- Usually first: payment and messaging links, backups and key-wrapping of long-lived archives, internal PKI and roots of trust, VPNs between sites and clouds.
- Usually later: short-lived session data, internal analytics, systems due for replacement anyway.
3. Migrate
Work from the outside in and from protocols down to hardware.
- Transport: enable hybrid X25519 + ML-KEM key exchange on TLS 1.3 endpoints, load balancers and CDNs. Most modern libraries already support it.
- PKI: plan new post-quantum or hybrid certificate hierarchies, starting with internal PKI where you control both ends. Watch certificate sizes in constrained protocols.
- Keys and HSMs: confirm vendor roadmaps and FIPS 140-3 validations for ML-KEM and ML-DSA; re-wrap stored keys under AES-256.
- Code and firmware signing: move to LMS, XMSS or ML-DSA, so devices shipped now can still verify updates in the 2030s.
- Applications: replace hard-coded algorithms with calls through a central cryptography layer.
4. Assure
Migration is not a one-off project. Keep the CBOM current, alert on drift (a new service shipping RSA-only, a certificate issued from the old hierarchy), and report progress to the board and regulators in terms of data classes protected, not tickets closed.
Crypto-agility
Crypto-agility is the ability to change algorithms, key sizes and providers without rewriting applications. In practice it means central policy for which algorithms are allowed, cryptography reached through shared services or libraries rather than embedded in every application, an up-to-date inventory, and tested procedures for rotation. It turns this migration into the last big one.
Questions to put to every vendor
- Which post-quantum algorithms do you support today, in which products and versions, and is hybrid mode the default?
- What is your roadmap against the 2030 and 2035 dates, in writing?
- Are your cryptographic modules FIPS 140-3 validated with the new algorithms?
- Can you supply a CBOM for your product?
- How do you sign your software and firmware updates, and when will that be quantum-safe?
Sources
- CycloneDX: Cryptographic bill of materials (CBOM) (opens in a new tab)
- NIST CSWP 39: Considerations for achieving cryptographic agility (opens in a new tab)
- NIST SP 1800-38: Migration to post-quantum cryptography (NCCoE) (opens in a new tab)
- CISA: Post-quantum cryptography initiative (opens in a new tab)
General information, not legal or regulatory advice. Standards and deadlines move; check the primary source before relying on a date.