Your organization will migrate to post-quantum cryptography whether you're ready or not. NIST finalized its first three post-quantum cryptography standards in 2024, with quantum-vulnerable algorithms scheduled for deprecation by 2035. Google set a 2029 target for its own PQC migration. The question isn't whether you'll transition, it's whether you'll do it on your timeline or someone else's.
This checklist helps compliance officers and security leads build the foundational capacity to change cryptographic implementations safely. Use it to assess your current state and identify gaps before regulatory deadlines force rushed decisions.
Checklist Overview
This checklist addresses the organizational capabilities required for crypto agility: inventory management, prioritization frameworks, change execution capacity, and vendor accountability. It doesn't cover specific algorithm selection or cryptographic protocol implementation, those decisions depend on your system architecture and threat model.
The focus is on building "muscle memory" for cryptographic change. You're establishing processes that will serve you through multiple transitions, not just the immediate post-quantum migration.
Prerequisites
Before starting this checklist:
- Identify an executive sponsor with budget authority and cross-functional influence. Crypto agility touches procurement, engineering, application teams, and compliance simultaneously.
- Establish a working group that includes architects, network engineers, platform engineers, application owners, and program managers. One person can't execute this work alone.
- Secure initial funding for discovery tools and staff time. You'll need resources before you can accurately scope the full program cost.
Readiness Checklist
Discovery and Inventory
1. You have selected a bounded initial scope for cryptographic discovery.
Don't attempt a comprehensive enterprise-wide scan as your first step. Choose one business-critical service or one certificate type (such as public-facing TLS certificates) as your starting point.
Good looks like: A written scope document identifying the specific systems, certificate types, or application tier you'll inventory first, with clear boundaries and a completion timeline.
2. Your cryptographic inventory captures metadata beyond asset names.
For each cryptographic component, document: protocol and version, cipher suite, certificate chain, key usage, signature algorithm, the business service it supports, and how it integrates with applications and the security stack.
Good looks like: Inventory records that answer "What business function breaks if this certificate expires?" and "Which applications depend on this key?", not just "Where is this certificate installed?"
3. You have identified certificate ownership and established renewal accountability.
Every certificate in your initial scope has a documented owner responsible for renewal, rotation, and replacement decisions.
Good looks like: No certificates expire due to lack of awareness. Ownership is recorded in your configuration management database or asset inventory system with contact information.
4. You have mapped how cryptographic components connect across system boundaries.
You know which systems expose cryptography to public endpoints, third parties, cloud environments, and supply chain partners.
Good looks like: Network diagrams or data flow maps showing where encrypted channels cross trust boundaries, with annotations identifying the cryptographic protocols in use at each boundary.
Prioritization and Risk Assessment
5. You have classified data by required confidentiality period.
Your inventory includes retention requirements and sensitivity classifications. You've identified data that must remain confidential beyond ten years, the threshold where "harvest now, decrypt later" attacks become relevant.
Good looks like: A data classification matrix showing asset categories, retention periods, and sensitivity levels. High-value targets (biometric records, intellectual property, identity documents) are flagged for priority migration.
6. You have ranked systems by business criticality and revenue impact.
Your migration priority list starts with systems that generate revenue or support essential services, not with systems that happen to be easiest to change.
Good looks like: A written prioritization framework approved by business leadership, with specific services ranked in order of migration urgency based on business impact, not technical convenience.
7. You have established measurable program outcomes.
You've set specific targets with completion dates, for example, bringing a defined percentage of public certificates under automated management by a specific year.
Good looks like: Written objectives with completion criteria that can be tracked over time. Example: "Achieve automated certificate lifecycle management for 80% of public-facing certificates by Q4 2028."
Execution Capacity
8. You have documented the approval and testing process for cryptographic changes.
You know which governance bodies, architectural review boards, and compliance checkpoints must approve algorithm changes before deployment.
Good looks like: A written change control procedure identifying required approvals, testing requirements, rollback procedures, and timeline expectations for cryptographic updates.
9. You have built or acquired automation for certificate lifecycle management.
You can provision, renew, and revoke certificates without manual intervention for your initial scope.
Good looks like: Demonstrated automated certificate renewal for at least one certificate type, with monitoring that alerts owners before expiration.
10. You have tested a rollback procedure for a cryptographic change.
You've validated that you can revert a cryptographic update without service disruption.
Good looks like: Documentation of a test rollback in a non-production environment, including the time required to execute the rollback and the teams involved.
Vendor and Supply Chain Management
11. Your procurement documents include cryptographic agility requirements.
New vendor contracts specify response timelines for cryptographic updates when standards change.
Good looks like: Contract language requiring vendors to deliver patches or updates within a defined period (such as six months) after NIST publishes new cryptographic standards, with penalties for non-compliance.
12. You have assessed existing vendors' cryptographic update capabilities.
You've asked critical vendors how they will support post-quantum algorithms and what their update timeline looks like.
Good looks like: Documented vendor responses to a standard questionnaire covering PQC roadmap, supported algorithms, update delivery mechanisms, and backward compatibility plans.
13. You have identified which vendors control cryptography you cannot change independently.
You know which systems depend on vendor-managed cryptographic implementations where you must wait for the vendor to act.
Good looks like: A risk register listing vendor-dependent cryptographic components, the vendor's stated update timeline, and your contingency plan if the vendor misses deadlines.
Common Mistakes
Treating discovery as a one-time event. Your cryptographic inventory becomes outdated the moment new applications deploy or certificates renew. Build continuous discovery into your change management process.
Waiting for a complete inventory before taking action. You'll never have perfect visibility. Start building change capacity with the systems you've already identified while discovery continues.
Outsourcing core competency. External specialists can accelerate specific tasks, but you must retain the internal capability to execute cryptographic changes. If your team can't explain how your systems implement cryptography, you're not crypto-agile.
Assuming a single vendor provides end-to-end crypto agility. No product delivers complete visibility and control. You'll need cryptographic discovery tools, network monitoring for traffic inspection, and policy enforcement mechanisms, often from different vendors.
Focusing only on algorithm replacement. Crypto agility includes the governance, testing, approval, and rollback procedures that let you change cryptography safely. The algorithm is just one component.
Next Steps
If you've completed fewer than eight items on this checklist, your organization isn't prepared for mandated cryptographic transitions. Start with items 1 through 4 to establish basic inventory capability.
If you've completed eight or more items, focus on expanding your scope. Apply the processes you've built for your initial bounded problem to additional certificate types or business services.
Schedule quarterly reviews of your progress against measurable outcomes. Crypto agility is an ongoing capability, not a project with a fixed end date. The organizations that start building this capacity now will transition on their own terms. The ones that wait will transition on someone else's schedule.
