Microsoft's move to transition critical systems to post-quantum cryptography by 2029 is more than just a vendor update. It's a wake-up call for you to identify where cryptography exists in your infrastructure and plan for replacing it as current algorithms become obsolete.
This checklist will help you start that inventory and build the crypto-agility needed before quantum computing makes today's asymmetric encryption vulnerable. If you're waiting for quantum computers to arrive before acting, you're already behind.
What This Checklist Covers
This checklist outlines foundational steps for preparing your organization's cryptographic transition. You'll establish governance, discover where cryptography exists across your systems, assess your ability to update algorithms without service disruption, and adopt standards that support both current and post-quantum key exchange.
You won't deploy post-quantum algorithms today, as the standards are still stabilizing, but you'll build the visibility and flexibility needed to deploy them efficiently when they're ready. Each item results in a specific artifact or decision state you can verify.
Prerequisites
Before starting this checklist, ensure:
- Executive sponsorship: You have a named executive owner for cryptographic modernization with authority to allocate budget across IT, security, and application teams.
- Cross-functional access: Your team can audit configurations in application code, infrastructure components, network devices, and certificate stores without waiting for approval chains.
- Baseline knowledge: Your technical staff understands the difference between symmetric and asymmetric encryption, and why quantum computers threaten the latter but not the former.
If you lack any of these, address them first. Cryptographic discovery fails when teams can't access systems or when findings sit in a report with no one accountable for action.
Checklist Items
1. Assign Ownership and Define Scope
Done when: You have a named program owner, a written scope statement covering which systems are in-scope for Year 1 discovery, and a multi-year milestone plan with at least three checkpoints between now and 2029.
What good looks like: The scope statement explicitly includes or excludes categories like third-party SaaS integrations, legacy on-premises applications, mobile SDKs, and hardware security modules. The milestone plan identifies when you'll complete discovery (Year 1), when you'll pilot crypto-agility in non-production (Year 2), and when you'll begin production rollout of quantum-safe algorithms (Year 3+).
2. Establish a Cryptographic Inventory Repository
Done when: You have a living inventory system (a CMDB extension, a dedicated asset database, or a configuration management platform) that can track cryptographic dependencies by system, algorithm type, key length, certificate expiration, and update mechanism.
What good looks like: The repository supports tagging assets as "crypto-agile" or "hard-coded," records the last verification date for each entry, and integrates with your change management workflow so updates trigger re-verification. You can generate a report showing all systems using RSA-2048 or older algorithms within 15 minutes.
3. Conduct Application-Layer Cryptographic Discovery
Done when: You've scanned or manually reviewed in-scope applications to identify where cryptography is implemented, which libraries are used, whether algorithms are configurable via external settings (environment variables, key vaults, configuration files), and whether key rotation is automated or manual.
What good looks like: For each application, you have a record showing the cryptographic library (OpenSSL, BouncyCastle, platform crypto APIs), the algorithms in use (AES-256, RSA-2048, ECDSA P-256), and whether the algorithm selection is hard-coded in source or externalized. You've identified applications that will require code changes to adopt new algorithms.
4. Audit Network Cryptography and TLS Configurations
Done when: You've inventoried TLS versions across client and server endpoints, identified systems still using TLS 1.2 or older, and documented whether your infrastructure supports TLS 1.3 with hybrid key exchange.
What good looks like: You have a list of all public-facing and internal TLS endpoints, the minimum and maximum TLS version each supports, and a migration plan to enforce TLS 1.3 as the baseline. You've tested TLS 1.3 in a non-production environment and confirmed it doesn't break legacy clients you still need to support.
5. Map Certificate Lifecycles and Trust Chains
Done when: You've documented certificate issuance processes, identified trust anchors (root CAs), recorded certificate lifetimes, and confirmed whether certificate rotation is automated or requires manual intervention.
What good looks like: You know which certificates expire in the next 12 months, which systems will break if a root CA is replaced, and whether your certificate management platform supports automated renewal with configurable algorithm parameters. You've identified any certificates with lifetimes longer than two years that will need policy updates to align with post-quantum transition timelines.
6. Assess Data-at-Rest Encryption Configurability
Done when: You've reviewed encryption settings for databases, file systems, backup systems, and object storage to determine whether encryption algorithms are configurable without application downtime or data migration.
What good looks like: For each data store, you can answer: Is the encryption key managed externally (in a key vault or HSM)? Can you rotate the Key Wrapping key without re-encrypting the entire dataset? Can you update the algorithm (e.g., from AES-256-GCM to a post-quantum cipher) via configuration change, or does it require a full data migration?
7. Identify Long-Lived Sensitive Data at Risk from Harvest Now, Decrypt Later
Done when: You've classified datasets by retention period and sensitivity, and flagged any data that will remain encrypted for more than five years and contains information that would still be valuable to an attacker in 2030 or beyond (intellectual property, health records, financial data, authentication credentials).
What good looks like: You have a prioritized list of datasets that need quantum-safe encryption first, ranked by retention period and breach impact. You've confirmed that your data classification scheme includes a "quantum risk" flag for long-lived sensitive data.
8. Test Crypto-Agility in a Non-Production Environment
Done when: You've selected one application or service, updated its cryptographic configuration to use a different algorithm (e.g., switched from RSA-2048 to RSA-4096 or from one AES mode to another), and confirmed the change didn't require code deployment or service downtime.
What good looks like: The test proves you can update the algorithm via configuration file, environment variable, or key vault policy change. The application logs confirm it's using the new algorithm. The change took less than one hour from decision to verification. If the test failed, you've documented what blocked it (hard-coded algorithm, library limitation, key management gap).
9. Standardize Key Management and Rotation Processes
Done when: You've documented key rotation procedures for each cryptographic use case (TLS certificates, database encryption keys, signing keys), identified systems where rotation is manual, and established a timeline to automate rotation for high-priority systems.
What good looks like: You have a key rotation runbook for each system, a schedule that rotates keys at least annually (or more frequently for high-risk systems), and automated alerts when rotation fails or a key approaches expiration. You've eliminated any keys that have never been rotated since initial deployment.
10. Engage Third-Party Vendors on PQC Roadmaps
Done when: You've contacted vendors of critical SaaS platforms, security appliances, and infrastructure components to request their post-quantum cryptography roadmaps and timelines for supporting quantum-safe algorithms.
What good looks like: You have written responses from each vendor stating when they plan to support TLS 1.3, when they'll offer post-quantum key exchange, and whether they're building crypto-agility into their platforms. You've flagged any vendor who can't commit to quantum-safe support by 2030 as a transition risk.
Common Mistakes
Waiting for finalized standards before starting discovery. You don't need to know which post-quantum algorithm you'll deploy to start mapping where cryptography lives. Discovery and crypto-agility work can proceed now, independent of algorithm selection.
Treating this as an IT-only project. Cryptographic transitions affect application teams, security operations, compliance, and procurement. If your discovery team can't access source code or vendor contracts, your inventory will have gaps.
Focusing only on TLS and ignoring data at rest. Network cryptography is visible and easier to inventory, but encrypted databases and backups often use hard-coded algorithms that require significant re-engineering to update.
Assuming cloud providers will handle everything. Cloud platforms will offer post-quantum algorithms, but you still need to update your configurations to use them. If your application hard-codes an algorithm or your key management is manual, the cloud provider can't fix that for you.
Skipping the crypto-agility test. Until you've proven you can change an algorithm without downtime, you don't actually have crypto-agility. Run the test on a low-risk system and fix what breaks before you need to do it at scale.
Next Steps
Once you've completed this checklist, you should have a cryptographic inventory, a clear picture of which systems are crypto-agile and which aren't, and a prioritized list of systems that need modernization before you can deploy post-quantum algorithms.
Your next phase: remediate hard-coded cryptography in high-priority applications, automate key rotation for long-lived sensitive data, and establish a quarterly review cycle to keep your inventory current as new systems deploy.
The US and French governments have issued guidance to adopt quantum-safe cryptography by 2030. If you start discovery now, you'll have time to build crypto-agility before you need it. If you wait until quantum computers arrive, you'll be replacing cryptography under pressure with incomplete visibility.
