Quantum computing is still developing, but organisations do not need to wait for a future machine to begin preparing. Data captured today may need to remain confidential for many years, and cryptographic migrations often take longer than expected because algorithms are embedded across applications, devices, certificates, and vendor products.
Build an inventory first
Start by mapping where public-key cryptography is used. Look beyond the main application and include APIs, VPNs, mobile apps, signing pipelines, backups, devices, and third-party integrations. Record the algorithm, key size, certificate authority, data lifetime, and owner for each dependency.
Prioritise long-lived information
Not every system needs to move at the same pace. Prioritise records that must stay private for years, systems that support essential services, and services that cannot be upgraded quickly. This approach turns a broad technology concern into a sequence of manageable migration decisions.
Plan for crypto-agility
Crypto-agility means an application can change algorithms without a complete rewrite. Keep cryptographic choices behind well-defined interfaces, centralise certificate management, and avoid hard-coding algorithm names into business logic. Test upgrades in staging and make rollback part of the deployment plan.
Use established standards
NIST has finalised the first set of post-quantum cryptography standards, including ML-KEM for general encryption and ML-DSA and SLH-DSA for digital signatures. Teams should review how those standards fit their platforms with their security architects and technology suppliers.
A migration checklist
- Inventory cryptographic dependencies and owners
- Classify information by confidentiality lifetime
- Ask vendors for their post-quantum roadmap
- Test certificate, key-exchange, and signing changes
- Track migration decisions in the architecture record
Post-quantum readiness is not a single upgrade day. It is an architecture practice that makes future security changes safer and less disruptive.
