A crypto-agility roadmap is the plan for discovering where cryptography is used, deciding what must change, replacing algorithms and implementations without losing security or operations, and proving that future transitions will be easier. Post-quantum cryptography makes this capability urgent, but crypto agility is broader than one migration. Protocol deprecation, certificate changes, library vulnerabilities, supplier changes and policy updates all require controlled replacement. The roadmap must therefore cover technology, procurement, data lifetime, ownership, testing and evidence rather than listing algorithms alone.
Use the crypto-agility implementation checklist to track execution, the business guide to establish governance, and the cryptographic inventory assessment to start discovery. The PQC migration planning guide goes deeper on the quantum transition. The answers below use NIST’s final December 2025 crypto-agility white paper and final PQC standards as the current baseline.
What does crypto agility mean in practice?
NIST CSWP 39 defines crypto agility as capabilities for replacing and adapting algorithms in protocols, applications, software, hardware, firmware and infrastructure while preserving security and operations. In practice, a team can identify an affected dependency, select an approved replacement, test interoperability and performance, deploy through a controlled transition, revoke old trust and retain evidence. A configuration flag is useful but insufficient if data formats, certificates, hardware modules, partners or signed artifacts remain coupled to the old choice.
| Dependency class | Inventory evidence | Migration concern |
|---|---|---|
| Transport and APIs | Protocol, library, certificate and peer | Interoperability and downgrade |
| Data at rest | Algorithm, key, store and retention | Re-encryption and long-lived confidentiality |
| Signatures | Signer, verifier, artifact lifetime and trust anchor | Larger keys, signatures and archival verification |
| Identity and PKI | CA, profile, hardware, renewal and relying parties | Dual trust and certificate lifecycle |
| Supplier product | Version, roadmap, contract and export | Unsupported component or locked configuration |
What belongs in a cryptographic inventory?
Record business service, owner, asset, use case, algorithm, parameters, protocol, library or module, key location, certificate profile, data classification, protection lifetime, external peers, environment and change path. Include code, configuration, hardware, firmware, mobile applications, backups, archives, signed software and vendor-managed services. Keep confidence and discovery source because scans are incomplete. Software composition data can reveal libraries but not every runtime choice; network scans reveal negotiated protocols but not dormant paths or offline signatures.
Prioritize inventory gaps where sensitive information must remain confidential for years, where signatures must verify for long periods, where hardware replacement is slow, or where supplier roadmaps are unclear. CISA, NSA and NIST quantum-readiness guidance recommends a roadmap and inventory that includes IT and operational technology. Do not wait for perfect completeness before piloting change. Start with critical services, record unknowns and establish a recurring discovery process tied to architecture review and procurement.
Which post-quantum standards are final?
NIST finalized FIPS 203, 204 and 205 in August 2024. FIPS 203 specifies ML-KEM for establishing shared keys. FIPS 204 specifies ML-DSA digital signatures. FIPS 205 specifies SLH-DSA, a stateless hash-based signature standard. These standards define different functions; a KEM is not a signature algorithm. Parameter and product choices must follow applicable policy, validated implementations and current errata. Organizations outside U.S. federal scope should still confirm sector, jurisdiction and partner requirements rather than treating one standard as a universal deployment mandate.
How should a PQC pilot be selected?
Choose a bounded but representative path with known peers, measurable traffic and reversible configuration. Good pilots expose certificate issuance, protocol negotiation, message sizes, latency, CPU, hardware support, logging and rollback without placing critical records at uncontrolled risk. Test hybrid or dual mechanisms only where standards and policy permit. Capture failure behavior when one peer lacks support. The objective is to learn about the organization’s replacement machinery, not merely to prove that a library function runs.
How should migration priorities be set?
Score business criticality, information lifetime, exposure, cryptographic function, replacement lead time, ecosystem readiness and ability to isolate failure. “Harvest now, decrypt later” risk raises priority for long-lived sensitive data protected by vulnerable public-key exchange. Long-lived signatures and embedded devices may require early planning because replacement and verification periods are lengthy. Keep urgency separate from immediate deployment readiness: a high-priority dependency may first need supplier commitments, protocol updates or architecture changes.
| Roadmap wave | Entry condition | Exit evidence |
|---|---|---|
| Discover | Critical services and owners identified | Inventory with gaps and confidence |
| Prepare | Priority and target policy agreed | Approved patterns, supplier plans and lab |
| Pilot | Bounded representative use case available | Interoperability, performance and rollback results |
| Transition | Products and peers support approved choice | Measured rollout and old-path use decline |
| Retire | Retention and verification obligations resolved | Old trust disabled, exceptions governed |
| Sustain | Inventory integrated with normal change | Replacement exercise and policy review |
What architecture improves future agility?
Centralize policy and approved implementation patterns while keeping enforcement close to the workload. Use well-maintained cryptographic libraries and provider interfaces instead of custom primitives. Separate algorithm identifiers from business data, version encrypted and signed formats, and retain metadata needed to decrypt or verify historical objects. Abstracting an API helps only if the underlying protocol and stored format can evolve. Avoid downgrade paths that silently select an obsolete option; negotiation must be authenticated, constrained and observable.
Design dual-read or dual-verify periods where historical data or signatures must remain usable. New writes can move first while a controlled reprocessing job handles existing objects. For PKI, plan issuance, trust distribution, renewal, revocation and relying-party compatibility together. Measure key and signature size effects on packets, certificates, firmware and constrained devices. Recovery must preserve access to legitimate historical data without keeping vulnerable trust active longer than necessary.
Who owns the roadmap and supplier decisions?
Create a cross-functional owner group spanning security architecture, platform, product engineering, infrastructure, risk, procurement and records management. Service owners remain accountable for migration evidence. Procurement should request supported algorithms, standards alignment, validation status, upgrade path, inventory export, performance data, end-of-support dates and contractual notification of cryptographic changes. A supplier saying “quantum safe” is not enough; require the exact function, standard, parameter, product version and deployment boundary.
- Establish policy, owners, decision rights and an authoritative inventory schema.
- Discover critical dependencies and score data lifetime, exposure and replacement lead time.
- Approve implementation patterns and supplier requirements for each cryptographic function.
- Pilot interoperability, performance, observability, rollback and historical verification.
- Migrate in waves with measured old-path use and governed exceptions.
- Retire obsolete trust, update records and exercise the replacement process again.
What evidence should each migration retain?
Retain the inventory snapshot, policy decision, approved algorithm and parameter, implementation and module version, peer matrix, test vectors, performance results, format changes, key lifecycle, rollout cohorts, fallback criteria and old-trust retirement. Record current NIST errata and product validation status at the decision date. Evidence must identify cryptographic function: “PQC enabled” does not show whether key establishment, signatures or both changed. Keep results with the service architecture and procurement record so future owners can reproduce the choice.
Test negative and transition cases, not only happy-path interoperability. Reject malformed and downgraded negotiation, verify behavior with an unsupported peer, exhaust certificate and message-size limits, restart during key transition and restore historical encrypted or signed data. Exercise monitoring for unexpected legacy algorithms. For signed software and documents, confirm long-term verification and timestamp behavior. For constrained devices, measure storage, memory, CPU, network and update mechanisms under representative conditions.
How should exceptions be governed?
An exception should name the dependency, owner, business need, prohibited target state, risk, compensating controls, supplier plan, review date and hard expiry. Isolate the old mechanism, minimize exposed data and monitor its use. Avoid granting a broad exception to an entire product when one embedded component is the blocker. Leadership should see aggregate exception age and concentration. An exception is a temporary migration state with funded work, not evidence that the inventory can be marked complete.
Key takeaways
- Treat crypto agility as an operating capability, not a PQC product purchase.
- Inventory functions, implementations, peers and data lifetimes, including suppliers.
- Distinguish key establishment from signatures and follow current standards and policy.
- Pilot the full transition path, including rollback and historical data.
- Integrate cryptographic evidence into architecture, procurement and normal change.
Frequently asked questions
Should organizations deploy PQC immediately?
Begin inventory, risk analysis, supplier engagement and controlled testing now. Production deployment should follow applicable standards, product maturity, validation and sector policy. Avoid proprietary algorithms and unsupported experiments. High-risk long-lived data may justify earlier mitigations, but the decision should be documented with cryptographic expertise and interoperability evidence.
Must all historical data be re-encrypted?
Not automatically. Evaluate sensitivity, remaining retention, exposure, current protection and reprocessing risk. Some data can expire before migration; some requires prioritized re-encryption; some signed records need long-term verification rather than confidentiality. Preserve provenance and keys needed for legitimate access while preventing new use of deprecated mechanisms.
Is a TLS configuration inventory enough?
No. TLS is important, but cryptography also appears in storage, databases, application tokens, code signing, document signatures, backups, firmware, identity, messaging and vendor systems. Inventory discovery should combine code, configuration, runtime, network, certificate, key-management and supplier evidence. Track uncertainty rather than claiming complete coverage from one scanner.
Conclusion
A useful crypto-agility roadmap turns cryptographic change into a repeatable, governed migration. Build the inventory, prioritize by protection lifetime and replacement difficulty, use final standards for the correct functions, and test real interoperability before broad rollout. The lasting outcome is not one post-quantum deployment. It is the ability to identify, replace, verify and retire cryptography again when the next transition arrives.