Executive Order 14412 puts post-quantum cryptography on your compliance calendar with actual deadlines. But most organizations are tripping over the same preventable mistakes, not because the cryptography is too complex, but because they're treating this like a future IT project instead of a current risk management obligation.
Here's what's going wrong and how to fix it before your next audit cycle.
Why These Mistakes Keep Happening
Post-quantum cryptography sits in an uncomfortable gap. It's not yet mandatory for most compliance frameworks, but EO 14412 has established a timeline that will cascade into federal requirements. Your current cryptographic implementations probably meet today's FIPS 140-2 validation requirements. They just won't protect data that adversaries are harvesting now for decryption later.
The disconnect happens because compliance officers are waiting for explicit regulatory language while risk officers are watching sensitive data accumulate exposure. Neither group owns the cryptographic inventory, and IT teams don't have visibility into which data assets matter most from a compliance perspective.
Mistake 1: Treating This as an IT Modernization Project
You're approaching post-quantum readiness as a technology refresh cycle. Your IT team is evaluating quantum-resistant algorithms and planning infrastructure upgrades for some distant milestone.
Why it happens: Post-quantum cryptography sounds like a cryptography problem, so you assign it to the people who manage certificates and encryption. But EO 14412 explicitly frames this as organizational exposure to Harvest Now, Decrypt Later threats. That's a risk management and compliance question, not just a technical one.
Real consequence: You'll inventory your current cryptographic implementations without mapping them to sensitive data flows. When federal requirements land, you won't know which systems protect CUI, which handle long-lived sensitive information, or where your highest-exposure assets sit. You'll scramble to retrofit risk assessments into a technical roadmap that's already underway.
The fix: Start with a data-centric risk assessment. Identify which information assets carry long-lived sensitivity, CUI that remains classified for years, personally identifiable information with retention requirements, intellectual property with extended competitive value. Map your current cryptographic protections to those assets. Build your post-quantum roadmap around exposure windows, not algorithm availability.
Mistake 2: Ignoring Harvest Now, Decrypt Later in Your Current Risk Register
Your risk register doesn't include an entry for adversaries capturing encrypted data today for decryption when quantum computers mature. You're treating cryptographic compromise as a future threat that starts when quantum computers become practical.
Why it happens: Traditional risk frameworks focus on current vulnerabilities and current threat actor capabilities. Harvest Now, Decrypt Later requires you to assess risk based on future decryption capability against data you're protecting right now. That's an unfamiliar model for most compliance programs.
Real consequence: You're not prioritizing cryptographic upgrades for your most sensitive data flows. Consider a team managing ITAR-controlled technical data with a 20-year sensitivity window. If they're using RSA-2048 for data in transit and at rest, adversaries capturing that traffic today have two decades to develop decryption capability. Your current compliance posture looks fine, but your actual risk exposure is growing daily.
The fix: Add Harvest Now, Decrypt Later scenarios to your risk assessment methodology now. For each sensitive data category, document the sensitivity window, how long does this information need protection? Cross-reference that against your cryptographic controls. Flag any asset where the sensitivity window extends beyond the point when quantum decryption becomes feasible. Those are your priority migration targets, regardless of what federal requirements say.
Mistake 3: Waiting for Explicit Regulatory Language Before Acting
You're monitoring for updated NIST guidance, revised FIPS standards, and explicit post-quantum requirements in 32 CFR Part 170 or DFARS clauses. Until you see specific control language, you're treating this as optional.
Why it happens: Compliance officers operate on explicit obligations. You implement what the regulation requires, document what the framework mandates, and assess against published controls. EO 14412 establishes a timeline but doesn't specify which contractors must comply or what the audit criteria will be.
Real consequence: By the time post-quantum requirements appear in your governing frameworks, you'll be 18-24 months behind. Cryptographic transitions require vendor coordination, system testing, certificate authority updates, and integration work. If you wait until CMMC 2.0 assessment criteria include post-quantum readiness, you won't have time to implement before your assessment window.
The fix: Treat EO 14412 as a planning signal, not a wait-and-see milestone. Start building your cryptographic inventory now. Document which systems would require updates, which vendors support quantum-resistant algorithms, and where you have single points of cryptographic failure. When explicit requirements land, you'll have a head start instead of an emergency project.
Mistake 4: Assuming Your Vendors Will Handle This for You
You're relying on your cloud service providers, managed security vendors, and software suppliers to implement post-quantum cryptography when it becomes necessary. You haven't asked them about their roadmaps or tested whether their implementations will meet federal requirements.
Why it happens: Under the Shared Responsibility Model, cryptographic implementation often falls to the infrastructure provider. Your FedRAMP Moderate cloud provider handles encryption at rest and in transit. Your assumption is they'll upgrade to quantum-resistant algorithms on their own timeline.
Real consequence: Your vendors are making different risk calculations than you are. A commercial cloud provider might prioritize quantum-resistant algorithms for their highest-tier customers first. Your systems might not be on the early migration path. When federal requirements take effect, you'll discover gaps in your Customer Responsibility Matrix that you can't close without vendor action.
The fix: Survey your critical vendors now. Ask specifically about their post-quantum roadmap, their timeline for supporting NIST's selected quantum-resistant algorithms, and whether their implementation will meet federal validation requirements. Document any gaps in your risk register. For high-exposure systems, negotiate service level commitments or plan for alternative controls.
Mistake 5: Building a Roadmap Without Considering Your Supply Chain
Your post-quantum planning focuses on systems you directly control. You haven't extended that analysis to your subcontractors, your common control providers, or the third-party services that handle your sensitive data.
Why it happens: Flow-down requirements for post-quantum cryptography don't exist yet. You can't contractually require something that isn't in your own governing frameworks. So you're planning for your own infrastructure without considering the broader ecosystem.
Real consequence: You'll achieve post-quantum readiness in your own environment while your subcontractors continue using vulnerable cryptography for the CUI you share with them. When federal requirements include supply chain verification, and they will, given the pattern in CMMC and NIST SP 800-171, you'll face the same scramble you saw with DFARS 252.204-7012 flow-down.
The fix: Start the conversation now with your key subcontractors and service providers. Share your post-quantum roadmap and ask about theirs. Identify which relationships involve long-lived sensitive data and flag those for early coordination. When you draft new subcontracts or renew existing ones, include placeholder language about cryptographic modernization requirements. You won't have specific controls to cite yet, but you'll establish the expectation.
Prevention Checklist
Before your next compliance review cycle:
- Map your cryptographic controls to specific data assets, not just to systems or network segments
- Calculate sensitivity windows for your CUI, intellectual property, and personally identifiable information
- Add Harvest Now, Decrypt Later scenarios to your organizational risk register with specific exposure timelines
- Document which systems protect data with sensitivity windows extending beyond 10 years
- Survey critical vendors about their post-quantum roadmap and federal validation plans
- Review your Customer Responsibility Matrix for cryptographic gaps you can't close independently
- Inventory which subcontractors handle your sensitive data and what cryptographic protections they use
- Identify single points of cryptographic failure where one vulnerable system exposes multiple data assets
- Establish a cross-functional working group that includes compliance, risk, IT, and procurement stakeholders
- Set a review cadence for monitoring NIST post-quantum guidance and federal implementation timelines
The organizations that navigate post-quantum requirements successfully won't be the ones with the most advanced cryptographic implementations. They'll be the ones who connected their data sensitivity analysis to their cryptographic inventory early, before federal requirements forced a crisis response.
