EO 14409 and the DIB: Your Post-Quantum Migration Starts Now

Somewhere in a data center operated by a foreign intelligence service, encrypted traffic captured from a Defense Industrial Base contractor in 2022 sits on spinning disks, waiting. The traffic contains CUI --- technical drawings for a hypersonic glide vehicle component, procurement schedules for rare-earth materials, test results from a qualification program. Today, that traffic is protected by RSA-2048 and ECDHE key exchange. In ten years --- possibly fewer --- a cryptographically relevant quantum computer will factor those keys in hours. The intelligence service knows this. That is why they collected the traffic in the first place.

On June 22, 2026, Executive Order 14409 transformed this scenario from a theoretical risk briefing into a compliance obligation. The order directs federal agencies to complete migration to quantum-resistant cryptographic algorithms and establishes timelines that will cascade into every DoD contract, every FedRAMP authorization, and every supply chain that touches national security systems.

For the Defense Industrial Base, the message is unambiguous: your post-quantum cryptography migration starts now, not when NIST finalizes the next draft, not when your contract explicitly requires it, and not when a quantum computer is publicly demonstrated.

Why the DIB Cannot Wait for Contract Language

There is a pattern in federal cybersecurity compliance that has burned contractors repeatedly: the regulation arrives two years after the expectation. CMMC was discussed for five years before the 48 CFR rule made it contractually binding. DFARS 252.204-7012 required "adequate security" for CUI in 2017, but many contractors did not take it seriously until False Claims Act enforcement ramped up under DOJ's Civil Cyber-Fraud Initiative, launched in 2021.

EO 14409 will follow the same pattern in compressed timeframes. Here is why DIB organizations cannot afford to wait:

Harvest-now-decrypt-later is already happening. NSA has publicly confirmed that nation-state adversaries are collecting encrypted DIB traffic for future quantum decryption. Every day a contractor transmits CUI over RSA-2048 or ECDH is another day of captured data that will eventually be readable. The migration is not about a future threat --- it is about limiting the blast radius of an ongoing collection operation.

CNSA 2.0 timelines are not flexible. The NSA's Commercial National Security Algorithm Suite 2.0 establishes hard deadlines: by 2030, key categories like software/firmware signing and networking equipment must exclusively use quantum-resistant algorithms; by 2033, national security systems must complete the transition and fully deprecate quantum-vulnerable algorithms. DIB contractors handling classified or national security-adjacent information will be held to these timelines regardless of when DFARS language updates.

CMMC will incorporate PQC. The CMMC Level 2 framework maps to NIST 800-171, which maps to NIST 800-53, which will absorb FIPS 203/204/205 requirements. The control families for cryptographic protection (SC-12, SC-13) will be updated to require quantum-resistant algorithms. C3PAO assessors will begin asking about PQC migration readiness before the control language formally changes --- just as they asked about MFA before CMMC was final.

Supply chain pressure flows uphill. Prime contractors managing programs with 25-year operational lifetimes (ships, aircraft, satellites) are already asking subcontractors about cryptographic agility. A subcontractor that cannot demonstrate a PQC migration path represents a supply chain risk that primes will factor into teaming decisions.

The Three FIPS Standards You Must Know

EO 14409 references NIST's finalized post-quantum cryptography standards. These are not drafts. They are published, approved, and available for implementation today.

FIPS 203: ML-KEM (Key Encapsulation)

FIPS 203 defines the Module-Lattice-Based Key Encapsulation Mechanism, derived from the CRYSTALS-Kyber algorithm. This is the replacement for RSA key exchange and ECDH:

Purpose: Establishing shared secrets over untrusted channels (TLS handshakes, VPN key exchange, encrypted email key wrapping)
Security basis: Module Learning With Errors (MLWE) problem --- believed resistant to both classical and quantum attacks
Parameter sets: ML-KEM-512 (128-bit security), ML-KEM-768 (192-bit), ML-KEM-1024 (256-bit)
Performance: Key generation and encapsulation are faster than RSA-2048. Ciphertext sizes are larger (768 bytes for ML-KEM-512 vs. a 32-byte X25519 ECDH key share) but manageable for modern networks.
CNSA 2.0 requirement: ML-KEM-1024 for national security systems

For the DIB, FIPS 203 is the most immediately impactful standard. Every TLS connection, every VPN tunnel, every encrypted file transfer between contractor and government systems uses key exchange. ML-KEM replaces the quantum-vulnerable component.

FIPS 204: ML-DSA (Digital Signatures)

FIPS 204 defines the Module-Lattice-Based Digital Signature Algorithm, derived from CRYSTALS-Dilithium:

Purpose: Replacing RSA and ECDSA signatures in code signing, certificate chains, document signing, authentication protocols
Parameter sets: ML-DSA-44 (128-bit), ML-DSA-65 (192-bit), ML-DSA-87 (256-bit)
Signature sizes: Larger than ECDSA (2,420 bytes for ML-DSA-44 vs. 64 bytes for ECDSA-P256), but signing and verification are fast
CNSA 2.0 requirement: ML-DSA-87 for national security systems

ML-DSA affects every certificate in your PKI, every signed software package, every code-signing workflow, and every authentication token that relies on digital signatures. The migration surface area is enormous.

FIPS 205: SLH-DSA (Hash-Based Signatures)

FIPS 205 defines the Stateless Hash-Based Digital Signature Algorithm, derived from SPHINCS+:

Purpose: A conservative alternative to ML-DSA based on hash functions rather than lattice mathematics. Used where maximum confidence in long-term security is required.
Security basis: Security relies only on the security of the underlying hash function --- the most conservative and well-understood cryptographic primitive
Trade-off: Significantly larger signatures (7,856 bytes minimum) and slower signing. Suitable for high-assurance applications like root CA certificates, firmware signing, and long-lived trust anchors.
CNSA 2.0 use case: Root certificates and high-assurance signing where performance is secondary to confidence

For most DIB applications, ML-DSA (FIPS 204) will be the workhorse. SLH-DSA (FIPS 205) is the insurance policy for your most sensitive trust anchors.

The CNSA 2.0 Timeline: What "By 2030" Actually Means

NSA's CNSA 2.0 provides specific milestones that EO 14409 now makes directive:

Milestone	Deadline	What It Means for DIB
Prefer quantum-resistant algorithms for new systems	Immediate (now)	New procurement should specify PQC-capable solutions
Software/firmware signing: transition to ML-DSA or SLH-DSA	2025-2030	Code signing pipelines need migration
Web/cloud services: transition to ML-KEM + ML-DSA	2025-2033	TLS configurations, API gateways, cloud integrations
VPN/IPsec: transition to ML-KEM	2026-2030	Site-to-site tunnels, remote access VPN
Legacy systems: full deprecation of RSA/ECC	By 2033	Even systems with long upgrade cycles must complete migration

The "2030" dates are not aspirational. For organizations handling national security information, these are hard compliance boundaries. For CMMC-assessed organizations handling CUI, the timelines will be slightly later but not significantly --- expect 2030-2032 as the enforcement window.

The Crypto Inventory: Your First and Hardest Step

Here is the contrarian opinion that will generate pushback: most DIB organizations cannot even begin PQC migration because they do not know where their cryptography lives. They have no cryptographic inventory. They cannot answer the question "What algorithms are we using, where, and for what purpose?"

A software bill of materials tells you what packages are in your software. A cryptographic bill of materials (CBOM) tells you what cryptographic algorithms, key sizes, protocols, and libraries are in use across your environment. Without a CBOM, PQC migration is guesswork.

The crypto inventory must catalog:

Protocol-level cryptography: TLS versions and cipher suites on every service. IPsec configurations on every VPN. SSH key types on every server. SFTP configurations on every file transfer. Email encryption (S/MIME, PGP) across the organization.

Application-level cryptography: How your applications generate, store, and use keys. Database encryption (TDE algorithms). File encryption. API authentication tokens. JWT signing algorithms. Password hashing (not quantum-vulnerable, but often co-located with vulnerable key material).

Infrastructure cryptography: Certificate authorities and their signing algorithms. Hardware security module (HSM) configurations. Key management system (KMS) algorithms. Disk encryption. Backup encryption.

Third-party cryptography: What algorithms your SaaS vendors use. What your cloud provider uses for data-at-rest and data-in-transit. What your managed service providers use for remote access.

This inventory is the prerequisite for everything else. EO 14409 explicitly requires agencies to complete cryptographic inventories, and that requirement will cascade to the DIB through CMMC and DFARS updates.

Migration Sequencing: What to Transition First

Not all cryptographic uses carry equal risk. The migration sequence should follow a risk-prioritized approach:

Phase 1: Highest-Priority (Start Immediately)

Long-lived secrets transmitted over untrusted networks. Any CUI transmitted over the internet using RSA or ECDH key exchange is vulnerable to harvest-now-decrypt-later today. Transitioning TLS to hybrid key exchange (ML-KEM + ECDH) stops the bleeding without requiring full migration.

New system procurement. Every new system purchased from today forward should support PQC algorithms. Bake FIPS 203/204/205 support into procurement requirements now.

Phase 2: High-Priority (Complete by 2028)

VPN and site-to-site tunnels. These carry the bulk of CUI between contractor facilities and government networks. IPsec configurations should migrate to ML-KEM key exchange.

Code signing and software supply chain. Transition to ML-DSA for firmware updates, software releases, and package signing. This protects against future key compromise enabling supply chain attacks.

PKI and certificate infrastructure. Begin issuing certificates with quantum-resistant algorithms. Plan for hybrid certificates during the transition period.

Phase 3: Managed Migration (Complete by 2033)

Legacy systems with long upgrade cycles. Industrial control systems, embedded devices, and fielded platforms that cannot accept rapid updates. These need compensating controls (network isolation, gateway-level PQC) during extended migration timelines.

Internal-only systems. Systems that do not transmit data over untrusted networks face lower HNDL risk. They still need migration but can follow managed timelines.

Hybrid Mode: The Transition Strategy

No organization will flip from RSA/ECC to PQC overnight. The industry consensus is hybrid cryptography during the transition period:

Hybrid key exchange combines ML-KEM with ECDH. Both algorithms contribute to the shared secret. If ML-KEM is somehow broken (unlikely but not impossible for a new algorithm), ECDH still protects the session against classical attacks. If ECDH is broken by a quantum computer, ML-KEM still protects the session.

Hybrid signatures combine ML-DSA with ECDSA. A signature is valid only if both signature schemes verify. This provides defense-in-depth during the transition period when confidence in new algorithms is still being established.

Most major TLS libraries already support hybrid key exchange. The performance overhead is measurable but modest: TLS handshakes increase by approximately 1-2 KB of data and sub-millisecond additional computation. For most applications, this is invisible.

What "Cryptographic Agility" Actually Means

EO 14409 repeatedly references "cryptographic agility" --- the ability to swap algorithms without re-architecting systems. For the DIB, this is both a directive and a lesson:

Organizations that hardcoded RSA-2048 throughout their stack now face a massive retrofit. Organizations that abstracted their cryptographic operations behind configurable interfaces can swap algorithms with configuration changes.

Cryptographic agility means:

Protocol negotiations support algorithm upgrades without code changes
Key management systems are algorithm-agnostic
Certificate management can handle multiple algorithm types simultaneously
Application code does not reference specific algorithms directly
Configuration management can push algorithm policy changes across the fleet

If your systems lack cryptographic agility today, gaining it IS the first phase of your PQC migration --- because you will need to swap algorithms again when the next generation of standards arrives.

Key Takeaways

EO 14409 makes post-quantum cryptography migration a federal directive, not a recommendation. Timelines will cascade to the DIB through CMMC, DFARS, and supply chain flow-down.
Harvest-now-decrypt-later operations are already occurring against DIB traffic. Every day without PQC-capable key exchange is another day of future-readable data captured by adversaries.
FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) are published and implementation-ready today. These are not drafts.
CNSA 2.0 establishes hard deadlines: prefer PQC for new systems now, complete transition by 2030 for signing and networking equipment, fully deprecate RSA/ECC by 2033.
A cryptographic inventory (CBOM) is the non-negotiable first step. You cannot migrate what you cannot find.
Hybrid cryptography (ML-KEM + ECDH, ML-DSA + ECDSA) is the transition strategy. It is available in major libraries today.
Cryptographic agility --- the ability to swap algorithms without re-architecting --- should be treated as a security requirement, not a convenience.

Frequently Asked Questions

When will CMMC assessments include PQC requirements?

CMMC maps to NIST 800-171, which references NIST 800-53 cryptographic controls (SC-12, SC-13). NIST will update these controls to require FIPS 203/204/205 compliance, likely between 2027-2029. However, C3PAO assessors are already asking about PQC migration planning as a maturity indicator during assessments. Organizations that demonstrate awareness and a migration roadmap will be viewed more favorably even before formal control language changes.

Is RSA-4096 sufficient as an interim measure?

No. Doubling the RSA key size from 2048 to 4096 provides marginal additional security against quantum attack --- Shor's algorithm breaks both in polynomial time; the larger key only modestly increases the number of qubits required. RSA-4096 is not a substitute for post-quantum algorithms. It increases current classical security margin but does nothing to address the quantum threat.

What about symmetric cryptography --- is AES vulnerable?

AES and other symmetric algorithms face reduced security from Grover's algorithm (effectively halving key strength), but AES-256 retains 128-bit security against quantum attack --- still considered adequate. The urgent migration is for public-key cryptography: key exchange, digital signatures, and asymmetric encryption. Your AES-256 data-at-rest encryption is not the immediate concern.

How do we handle PQC migration for systems connected to government networks?

Government networks (NIPRNet, SIPRNet, DISA enclaves) will publish their own PQC migration schedules for boundary protection devices and connection standards. DIB contractors should prepare for changes to STIG requirements for boundary devices, TLS configurations, and VPN concentrators. Monitor DISA STIGsfor updates to Network Infrastructure and Application Security requirements.

What is the cost of PQC migration for a typical DIB contractor?

Cost depends entirely on the size and complexity of your cryptographic surface area. A small contractor with 50 systems, standard TLS configurations, and modern software may spend $50K-$150K on assessment and migration. A mid-tier contractor with legacy systems, custom PKI, embedded platforms, and classified enclaves could face $500K-$2M+ over three years. The cost of not migrating --- contract loss, compliance failure, data compromise --- dwarfs either figure.

How Advisedly Helps

Advisedly's platform automates the cryptographic inventory that EO 14409 demands as step one, scanning your environment to catalog algorithms, key sizes, and protocol configurations across infrastructure, applications, and third-party connections. The platform maps findings to CNSA 2.0 timelines, generates prioritized migration roadmaps, and tracks remediation progress against the FIPS 203/204/205 standards --- giving your team a defensible compliance posture before the contract language catches up to the executive order. begin@advisedly.ai