Quantum-Safe by Contract: A Practical Path to NIST PQC for the Defense Industrial Base

In most industries, the case for post-quantum cryptography still has to be argued on risk: long-lived data, “harvest now, decrypt later,” the uncertain arrival date of a cryptographically relevant quantum computer. In the Defense Industrial Base, the argument is already made for you. It is written into the DoW PQC Strategy, the November 2025 CIO memo, Executive Order 14412, OMB M-26-15, and NSA’s CNSA 2.0. The question for a DIB contractor is no longer whether; it is how to get there without blowing up the program schedule or the IT budget.

Here is how we would do it.

1. Anchor to the deadlines that actually bind you

Don’t build the program around “2035.” Build it around the dates that show up in your contracts and your customers’ acquisition rules:

Date	Requirement	Who it hits
Sept 21, 2026	FIPS 140-2 certificates go Historical; new procurement must be FIPS 140-3	Everyone buying crypto modules
~Dec 2026	FAR Council proposed rule (EO 14412 §6(c)) requiring covered contractors to comply with NIST FIPS, including PQC algorithms, by Dec 31, 2030	Every federal contractor, including the DIB
Jan 1, 2027	CNSA 2.0: new NSS acquisitions must support quantum-resistant algorithms	Anyone shipping into National Security Systems
~Mar 2027	CISA/NIST publish CBOM minimum elements; FAR rule on contractor vulnerability disclosure programs covering cryptographic weaknesses (EO 14412 §5(d), §6(d))	Every federal contractor
2025–2027	CNSA 2.0 support-and-prefer dates by category: browsers, servers, cloud (2025); VPNs, routers, networking gear (2026); operating systems (2027)	Vendors in those categories
End of 2030	Contractor FIPS/PQC compliance (EO 14412); DoW systems must support PQC; civilian HVAs and high-impact systems on PQC key establishment (M-26-15); NIST IR 8547 deprecates RSA-2048 / P-256; CNSA 2.0 software & firmware signing PQC-only	DoW, civilian agencies, and every contractor
End of 2031	DoW systems must employ PQC; civilian HVAs and high-impact systems on PQC signatures (M-26-15)	DoW and civilian agencies; expect mirrored CMMC language
2033	CNSA 2.0 exclusive use across all NSS categories	Anyone shipping into NSS
2035	Quantum-vulnerable public-key algorithms disallowed (IR 8547, NSM-10, M-26-15)	Everyone

A note on “Historical.” FIPS 140 is the NIST standard for validating the modules that actually perform cryptography (HSMs, smart cards, VPN appliances, the FIPS provider in a crypto library), and NIST SP 800-171 requirement 3.13.11 obliges a DIB contractor to use validated modules for CUI. On September 21, 2026, every remaining FIPS 140-2 certificate moves to the CMVP’s Historical list. That status means the certificate no longer counts for new procurement or new deployment: standing up a new server or enclave, racking a new appliance, shipping a new product version to DoW, or applying an upgrade that changes the crypto module itself all require a FIPS 140-3 certificate from that date. Systems already in service under a 140-2 certificate can keep running within their validated configuration, since the cryptography did not get weaker overnight, but a CMMC assessor will expect new deployments to cite 140-3. Because no ML-KEM or ML-DSA implementation was ever validated under 140-2, the 140-3 refresh and the PQC migration are the same refresh, and every entry in the inventory should be tagged with whether it will be replaced, expanded, or materially upgraded before 2030.

Two of those rows deserve emphasis because they bind contractors directly rather than through DoW. EO 14412 §6(c) orders the FAR Council to publish, within 180 days of June 22, 2026, a proposed rule requiring covered contractors to comply with NIST’s FIPS, including the PQC standards, by December 31, 2030. §6(d) adds a rule requiring contractor vulnerability disclosure programs to cover cryptographic weaknesses, including use of non-FIPS algorithms. Those clauses will land in contracts regardless of what CMMC does. The DoW strategy separately states that it will update CMMC with PQC-based requirements and that it intends to ensure the DIB migrates enterprise-wide. CMMC details are thin and Phase 2 enforcement has been a moving target this summer, but with a FAR rule in draft the direction is no longer in doubt. A contractor that waits for final contract language will be starting a three-year program with eighteen months left.

2. Inventory first, and make it a CBOM, not a spreadsheet

Every mandate in this space (M-23-02, the CIO memo, the EO) starts with the same instruction: know where your cryptography is. The DoW memo is explicit that its inventory covers business systems, cloud, mobile, physical access control, IoT, OT, and weapons systems “regardless of classification, location, connection, type, purpose, or use.” Assume your customer will ask you the same question about the systems that touch their data.

Scope it to the CUI boundary you already defined for NIST SP 800-171. That boundary is your PQC boundary, at least for Phase 1. Inside it, capture:

• Data in transit: TLS endpoints, VPN concentrators, SSH, IPsec tunnels, MACsec on the network fabric.
• Data at rest: disk and database encryption, backup encryption, HSM-wrapped keys, S3/Blob KMS configurations.
• Identity and PKI: every CA, every certificate lifetime, every code-signing key, every PIV/CAC-derived credential, every SAML/OIDC signing key.
• Software supply chain: firmware signing, container image signing, SBOM attestations, update mechanisms.
• Embedded and OT: anything you ship to the government with crypto baked into silicon or firmware.

Use automated discovery at four layers (source and binary scanning, network and protocol scanning, runtime instrumentation, and certificate/key/HSM exports) and produce a Cryptographic Bill of Materials in a machine-readable format. Insist on CycloneDX 1.6 or later, which models cryptographic assets natively: EO 14412 directs CISA and NIST to publish the minimum elements for a CBOM within 270 days, so expect federal guidance around March 2027, and a standards-based inventory will map onto it while a proprietary one will have to be rebuilt. OMB M-26-15 already tells civilian agencies to feed SCA, SAST/DAST, and network-scanner output into a central CBOM and to name the automated inventory tools in their migration plans; assume your customer will ask you the same. You will be asked for it, and a CBOM that updates from CI/CD beats a document that goes stale the day it is published.

Figure 1. Building the CBOM: four discovery layers feeding one CycloneDX inventory.

Tag every entry with three things: algorithm and key size, data lifetime it protects, and whether you control it or a vendor does. That last tag drives the next two steps.

3. Prioritize by data lifetime and control, not by ease

Rank the inventory on two axes:

• Harvest-now-decrypt-later exposure. CUI, export-controlled technical data, and anything under ITAR has a shelf life measured in decades. Key exchange protecting that traffic is your top priority. Signatures on ephemeral sessions are not, since they can’t be forged retroactively.
• Who has to fix it. Systems you build are on your schedule. Systems you buy are on the vendor’s schedule, and the vendor’s schedule is the long pole.

That ordering produces a consistent Phase 1 for almost every DIB customer we see:

1. External TLS and VPN termination for CUI enclaves (you control it, and the crypto is mature).
2. RSA- or ECC-wrapped keys protecting backups and archives (the AES itself is fine; the key wrapping is the exposure, and it is usually a KMS policy change).
3. Code and firmware signing for anything delivered to DoW (CNSA 2.0’s 2030 hard stop).
4. Internal PKI redesign (longest lead time, so start it now even though it finishes last).

4. Use the algorithms and profiles the customer already accepts

Don’t get creative. Align to CNSA 2.0 and the FIPS standards, because that is what the evaluators and the DoW PKI office will accept.

Algorithm	Standard	Role	Math family	Status (Sept 2026)	CNSA 2.0
ML-KEM (Kyber)	FIPS 203	Key establishment	Lattice	Final (Aug 2024)	Yes, ML-KEM-1024
ML-DSA (Dilithium)	FIPS 204	General signatures	Lattice	Final (Aug 2024)	Yes, ML-DSA-87 (no pre-hash variant)
SLH-DSA (SPHINCS+)	FIPS 205	Backup signatures	Hash-based	Final (Aug 2024)	Not listed
LMS / XMSS	SP 800-208	Firmware and software signing	Hash-based, stateful	Final (2020)	Yes
FN-DSA (Falcon)	FIPS 206	Compact signatures	Lattice (NTRU)	Draft; final expected late 2026 or 2027	Not yet
HQC	FIPS number not yet assigned	Backup key establishment	Code-based	Draft 2026; final expected 2027	Not yet

Where that leaves you in practice:

• Key establishment: ML-KEM-1024 (FIPS 203). ML-KEM-768 is fine for general commercial use but pick 1024 for anything CNSA-scoped so you don’t do it twice.
• General signatures: ML-DSA-87 (FIPS 204). Note CNSA 2.0 excludes the pre-hash HashML-DSA variant.
• Firmware and software signing: LMS or XMSS (SP 800-208) where the signing environment is controlled and stateful, or ML-DSA where it isn’t.
• Symmetric: AES-256 and SHA-384/512 are already quantum-resistant and are what CNSA 2.0 requires. NIST still treats AES-128 and SHA-256 as quantum-safe for general use, so retire them only where CNSA 2.0 applies. Separately, the DoW memo orders pre-shared-key schemes (outside NSA KMI) and symmetric key-establishment protocols used for quantum resistance phased out by Dec 31, 2030 (Dec 31, 2031 for solutions registered with NSA CSfC), and bars new procurement of them immediately.
• Not acceptable: QKD, quantum-based randomness, and non-FIPS random number generation. The DoW CIO memo bars all of them for confidentiality, authenticity, integrity, or key distribution absent an exception. If a vendor pitches QKD, that is a signal about the vendor.
• Expect a gate. The same memo requires DoW Components to obtain intake approval from the CIO PQC Directorate before testing or acquiring any PQC-related technology, and deployment approval before fielding it. If you sell PQC-enabled products into DoW, your test results, interoperability evidence, and certification path are what clear that gate.

Hybrid or pure? For TLS and VPN, deploy hybrid (X25519 + ML-KEM, per the IETF drafts most browsers and load balancers now implement). It protects against both a quantum break and an undiscovered PQC flaw, and it interoperates today. Be clear-eyed about what federal guidance says, though: M-26-15 calls hybrid an intricate and resource-intensive stopgap that agencies may adopt on their own risk assessment, and CNSA 2.0 does not require it. Hybrid is the right choice where the browser and load-balancer ecosystem already speaks it; it is not a requirement, and it adds work. Design the hybrid so the PQC half carries the security on its own. NIST SP 800-227 permits hybrid key establishment, but IR 8547 puts the classical algorithms on a 2030–2035 deprecation path as standalone protection, and you want to be able to drop the classical half by configuration when that day comes. For signing into NSS, go straight to CNSA 2.0 algorithms.

5. Engineer for crypto-agility, then swap algorithms by policy

The lasting lesson from every prior cryptographic migration (DES→AES, SHA-1→SHA-2, TLS 1.0→1.2) is that the organizations that suffered were the ones with algorithms hard-coded in application logic. PQC will not be the last change; FN-DSA (FIPS 206) and HQC are still coming.

Concrete engineering moves:

• Route all crypto through a small number of centrally managed libraries or services (a KMS, an HSM, a service mesh, a TLS-terminating proxy). Applications ask for “sign this” and “protect this,” never “use RSA-2048.”
• Choose libraries that already ship FIPS 203/204/205 with a FIPS 140-3 validation in progress or complete. OpenSSL 3.5+, BoringSSL, BouncyCastle, and the major HSM vendors are there or close. Verify the CMVP certificate, not the press release; validation queues have historically run a year or more, so a module “in the queue” today may not be usable for procurement until 2028.
• Make algorithm selection a configuration item under change control, and prove it: run a tabletop where you switch an environment from hybrid to pure ML-KEM and back. If that takes a code release, you are not agile yet.
• Budget for size. ML-DSA-87 signatures are ~4.6 KB against ~96 bytes for ECDSA P-384. A three-tier certificate chain multiplies that on every handshake. Test MTU, TLS record limits, HSM throughput, and embedded flash before the pilot, not after.

6. Rebuild PKI as its own project

PKI is the critical path for nearly every DIB migration, and DoW’s own PKI modernization is the dependency your interoperability testing will wait on. Treat it as a separate workstream with its own budget:

• Stand up a parallel PQC-capable CA hierarchy rather than trying to upgrade the existing one in place. Issue composite or dual certificates during the overlap window so relying parties can migrate independently.
• Shorten certificate lifetimes now. A 90-day certificate is a forcing function for automation, and automation is what makes the eventual cutover survivable.
• Plan for the DoW External Certificate Authority program to move to PQC; your interoperability with DoW PKI is not something you can test in isolation, so get into the DISA and NSA pilot conversations early.
• Don’t forget the small stuff that breaks first: OCSP responders, CRL sizes, smart-card middleware, and legacy SAML IdPs that choke on large signatures.

7. Flow it down: your supply chain is your attack surface

DFARS flow-down already makes you responsible for your subcontractors’ handling of CUI; PQC will ride the same clause. Add five questions to every supplier security questionnaire and every new contract:

1. Do you have a cryptographic inventory / CBOM for the product or service you deliver to us?
2. Which FIPS 203/204/205 algorithms does the product support today, and under what FIPS 140-3 certificate?
3. What is your CNSA 2.0 transition date for this product category?
4. Can algorithm selection be changed by configuration without a firmware or code release?
5. What is your end-of-support date for RSA/ECC-only versions?

Score the answers, put the laggards on a remediation plan, and be willing to walk away from a component that cannot get to ML-KEM by 2029. Your customer will not accept “our vendor wasn’t ready” as a corrective-action response.

8. Run it as a program, and document like an assessor is watching

Because one will be. Structure it the way DoW structured its own:

• Executive sponsor and a named PQC migration lead. DoW required a roster of leads within 20 days of its memo; mirror that.
• Governance tied to the existing 800-171 / CMMC program, so PQC evidence lands in the same System Security Plan and POA&M the assessor already reads. Frame PQC controls as extensions of the 800-171 requirements you already evidence: 3.13.8 (CUI in transit), 3.13.10 (key management), 3.13.11 (FIPS-validated cryptography), and 3.13.16 (CUI at rest), which map to SC-8, SC-12, SC-13, and SC-28 in SP 800-53. Not a new framework.
• A 90-day inventory sprint, a 6-month pilot on one CUI enclave, then annual waves ordered by the priority list in Section 3. Each wave has an entry gate (CBOM complete, vendor answers in hand) and an exit gate (hybrid or CNSA 2.0 enabled, monitoring confirming no classical-only fallback).
• Instrument TLS and VPN terminations to report negotiated key-exchange groups. The single most useful dashboard in the program is the percentage of CUI-bearing sessions negotiating ML-KEM. It is also the artifact a CMMC assessor or a prime’s security team will want to see.
• Risk acceptance for what you can’t fix. Legacy OT or a government-furnished system that cannot be upgraded gets an explicit risk decision, compensating controls (segmentation, PQC-wrapped tunnels around it), and a retirement date, which is exactly what CNSA 2.0 requires for systems that cannot transition.

The bottom line

For a DIB customer, PQC migration is a procurement and compliance program with an engineering core, not a research project. The path that works is unglamorous: inventory to a CBOM, prioritize by data lifetime and vendor dependency, pick CNSA 2.0 algorithms, build crypto-agility once, treat PKI as its own project, and push the same requirements down the supply chain. Start now. The 2027 acquisition deadline is less than four months away, the 2030 signing deadline is one PKI rebuild away, and every quarter of delay is a quarter of CUI an adversary may already be storing.