Executive Order 14412 sets a timeline for federal agencies to adopt post-quantum cryptography. If you're a risk officer in a regulated sector or a government contractor, you're next. The order doesn't just demand new algorithms; it asks a fundamental question many organizations can't answer: what cryptographic systems are you running, where, and what data do they protect?
This checklist guides you through the steps to assess your cryptographic risk posture and build a defensible post-quantum roadmap. Each item is a deliverable your risk management program should produce before transitioning to quantum-resistant systems.
Prerequisites
Before starting, confirm you have:
- Executive sponsorship for cryptographic inventory work. This is a risk assessment affecting every system handling sensitive data.
- Access to network diagrams, data flow maps, and asset inventories. Trace where cryptographic operations occur across your infrastructure.
- A defined classification scheme for sensitive data. Know what qualifies as "long-lived sensitive information" in your context (customer PII, intellectual property, health records, financial data with regulatory retention requirements).
Cryptographic Readiness Checklist
1. Identify all cryptographic systems protecting data at rest and in transit
Done when: You've documented every system, application, and service that performs encryption, key exchange, digital signatures, or certificate validation. This includes TLS implementations, VPN concentrators, database encryption, file-level encryption, and API authentication mechanisms.
What good looks like: A spreadsheet or asset register listing each cryptographic system, its location (cloud/on-premises), the algorithm suite it uses (RSA-2048, ECDSA P-256, AES-256), and the business function it supports. No "we think we're using X" entries.
2. Map cryptographic systems to data classification levels
Done when: For each system identified in Step 1, you've tagged it with the highest classification level of data it processes or protects.
What good looks like: You can answer "which systems protect data subject to Harvest Now, Decrypt Later risk?" by filtering your inventory. Long-lived sensitive data includes anything with retention periods exceeding ten years or regulatory obligations that outlast current cryptographic strength estimates.
3. Document key lifecycle management practices for each system
Done when: You've recorded how keys are generated, stored, rotated, and destroyed for every cryptographic system in scope. Include whether you're using hardware security modules (HSMs), cloud key management services, or software-based key storage.
What good looks like: You know which systems use FIPS-Validated Cryptography for key operations and which don't. You can identify systems where keys haven't been rotated in over a year or where key material exists in multiple locations without documented custodianship.
4. Assess vendor dependencies for cryptographic implementations
Done when: You've identified which cryptographic functions are delivered by third-party vendors, SaaS platforms, or managed service providers. Document whether you control the cryptographic configuration or inherit it from the vendor.
What good looks like: A risk register entry for each vendor-controlled cryptographic system, noting whether the vendor has published a post-quantum transition roadmap and whether your contract allows you to specify algorithm requirements.
5. Identify systems with hard-coded or embedded cryptographic dependencies
Done when: You've flagged applications, firmware, or embedded systems where cryptographic algorithms are compiled into the code or burned into hardware.
What good looks like: You know which systems can't be patched remotely and require hardware replacement or complete application rewrites to transition to quantum-resistant algorithms. Industrial control systems, medical devices, and legacy middleware typically fall here.
6. Evaluate current cryptographic strength against NIST post-quantum standards
Done when: You've compared your current algorithm inventory (from Step 1) against NIST's finalized post-quantum cryptographic standards: ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), ML-DSA (Module-Lattice-Based Digital Signature Algorithm), and SLH-DSA (Stateless Hash-Based Digital Signature Algorithm).
What good looks like: A gap analysis showing which systems use algorithms NIST has designated for eventual deprecation (RSA, ECDH, ECDSA) and which systems can adopt NIST-approved quantum-resistant algorithms through software updates versus those requiring architecture changes.
7. Prioritize systems based on exposure and transition complexity
Done when: You've ranked your cryptographic systems using at least two dimensions: data sensitivity/longevity and ease of cryptographic migration.
What good looks like: A risk-weighted priority matrix. High-priority items protect long-lived sensitive data AND require complex transitions (custom applications, vendor dependencies, hardware constraints). These need roadmap attention now, even if quantum threats remain theoretical.
8. Define ownership and accountability for each cryptographic system
Done when: You've assigned a named system owner responsible for cryptographic decisions and a business stakeholder who accepts the risk if that system can't transition on timeline.
What good looks like: No orphaned systems. Every entry in your cryptographic inventory has an email address next to it. If a vendor controls the system, you've documented the escalation path and contract clauses that govern algorithm updates.
9. Document data retention policies that create Harvest Now, Decrypt Later risk
Done when: You've identified datasets where regulatory, legal, or business requirements mandate retention beyond the expected useful life of current cryptographic protections.
What good looks like: You can produce a list of data stores where adversaries harvesting encrypted data today could decrypt it within the data's retention period once quantum computers reach cryptanalytic relevance. This drives your migration timeline more than EO 14412 deadlines.
10. Establish a cryptographic agility test for new systems
Done when: You've created procurement and architecture review criteria that require new systems to support algorithm substitution without application-level changes.
What good looks like: Your secure development lifecycle or vendor assessment checklist includes a question: "Can this system swap cryptographic algorithms through configuration changes only?" Systems that fail this test require architectural justification and compensating controls.
Common Mistakes
Treating this as a one-time compliance exercise. Cryptographic inventories decay the moment you finish them. New systems deploy, vendors change implementations, and keys proliferate. Build this into your ongoing risk assessment cycle, not a project with an end date.
Waiting for quantum computers to become practical before acting. Harvest Now, Decrypt Later isn't theoretical. If your encrypted data has value in ten years, assume adversaries are collecting it today. Your migration timeline should reflect data longevity, not threat imminence.
Assuming vendors will handle post-quantum transitions automatically. Many SaaS platforms and infrastructure providers will eventually support quantum-resistant algorithms, but "eventually" might not align with your risk tolerance or regulatory deadlines. Verify vendor roadmaps and contractual obligations now.
Ignoring cryptographic systems outside IT's direct control. Operational technology, IoT devices, and business applications often implement their own cryptography. If IT doesn't know it exists, it won't appear in your transition plan.
Next Steps
Once you've completed this checklist, you'll have the foundational inventory needed to build a post-quantum cryptographic roadmap. Your next actions:
- Quantify the gap between your current state and NIST post-quantum standards. How many systems need algorithm updates? How many need architectural changes?
- Develop transition timelines based on data sensitivity, not just technical feasibility. Systems protecting long-lived sensitive data move first, regardless of how hard the migration is.
- Integrate cryptographic risk into your enterprise risk register. Harvest Now, Decrypt Later exposure is a present risk, not a future one. Treat it accordingly in your risk treatment planning.
- Engage vendors on their post-quantum roadmaps. If you depend on third-party cryptographic implementations, their timeline becomes your constraint.
EO 14412 establishes federal timelines, but your organization's exposure to cryptographic risk predates any executive order. Use this checklist to move from "we should probably think about quantum" to "we know what we're protecting, how, and what needs to change."
