The starting point is exposure, not algorithms
Post-quantum planning often begins with a debate about algorithms. The more useful first question is where cryptography protects business-critical data and services today. That includes TLS, code signing, document signing, VPNs, identity systems, embedded devices, archives and third-party connections.
Discovery should capture purpose, owner, data sensitivity, required confidentiality lifetime, implementation, dependency and replacement constraints. A list of certificates alone is not a cryptographic inventory.
Prioritise harvest-now-decrypt-later risk
Attackers can collect encrypted information now and attempt to decrypt it later. Data that must remain confidential for many years therefore deserves attention before systems whose information loses value quickly.
Combine data longevity with external exposure, business criticality and change lead time. This creates an explainable priority model for executives and avoids treating every cryptographic dependency as equally urgent.
Design for crypto-agility
Crypto-agility is the ability to identify, replace and govern cryptographic mechanisms without redesigning the whole service. It requires ownership, inventories, configurable implementations, supplier commitments, testing patterns and controlled lifecycle processes.
The target state should support hybrid approaches where appropriate, algorithm change, dependency visibility and measurable migration status. Procurement and architecture standards need to reinforce that state.
Move through controlled waves
Start with representative pilots rather than the easiest systems only. Use them to test performance, interoperability, certificate and key handling, rollback and operational support. Then sequence migration waves around business services and shared dependencies.
A credible programme reports coverage, unresolved ownership, supplier readiness, pilot evidence, migrated critical services and exceptions—not simply how many assets appear in a tool.