The Post-Quantum Deadlines That Now Bind Federal Contractors and Vendors

Summary

Between November 2025 and October 2026 the federal post-quantum cryptography (PQC) requirements turned from targets into dated obligations with gates. The Department of War (DoW) CIO memorandum of 18 November 2025 made DoW approval a precondition for any component testing, piloting or buying PQC technology, and ended pre-shared-key and symmetric "quantum resistance" on 31 December 2030. Executive Order 14412 (22 June 2026) set 31 December 2030 and 2031 deadlines for the government's most sensitive systems and ordered the FAR Council to propose a rule requiring "covered contractors" to comply with the PQC FIPS by 31 December 2030. OMB M-26-15 (24 June 2026) told civilian agencies to keep an automated cryptographic inventory and to write PQC readiness into vendor requirements. CNSA 2.0 requires new national security system acquisitions to be compliant from 1 January 2027. NIST finalized IR 8547 on 27 October 2026: quantum-vulnerable public-key algorithms are deprecated after 2030 and disallowed after 2035.

This advisory lays those instruments out as one timeline, quotes the operative language, and states what each asks of a contractor and of a vendor selling into DoW. The inventory that NIST SP 800-171 control 3.13.11 and PCI DSS 12.3.3 already require is the inventory every deadline builds on, and the first contractual date, the FAR proposal, is weeks away.

1. One timeline

Dates marked derived are computed from the instrument's own clock and do not appear in its text. (S) marks figures taken from secondary coverage.

2. DoW CIO memorandum, 18 November 2025

The memorandum is posted at dowcio.war.gov and dodcio.defense.gov [1]. Both hosts refused automated retrieval for this advisory (HTTP 403), so the language below is as reported by secondary coverage [2][3] and should be checked against the memo before use in a proposal.

• Two gates. Components must obtain "cryptographic intake approval" from the DoW CIO PQC Directorate before testing, evaluating, piloting, investing in, using or acquiring PQC-enabling or PQC-related technology, and "cryptographic deployment approval" before deployment. One summary states the intake scope includes "discovery, inventory, migration, and enablement activities." If the Directorate finds security issues, tests and pilots stop.
• Inventory and leads. Components inventory "any type of cryptography used" across NSS, business and weapons systems, cloud, mobile, physical access control, IoT, unmanned systems and operational technology, "regardless of classification, location, connection, type, purpose, or use." PQC migration leads are named within 20 days, refreshed each 30 September.
• Bars. Quantum key distribution and related quantum keying, and non-FIPS random number generation, are barred for confidentiality, authenticity or integrity absent an exception. New commercial pre-shared-key (PSK) "quantum resistance" pilots and acquisitions are barred immediately.
• Dates. PSK solutions not provisioned through NSA's Key Management Infrastructure move to asymmetric PQC key establishment by 31 December 2030. Symmetric key establishment, agreement and distribution used for quantum resistance sunsets 31 December 2030, extended to 31 December 2031 for solutions registered with NSA's Commercial Solutions for Classified (CSfC) program.

Practical obligation. The memo binds DoW Components, not contractors. It reaches a contractor building or operating a DoW system through the Component's inventory and approval process, and a vendor through a buyer that cannot test, pilot or buy without intake approval (Section 8).

3. CNSA 2.0 (NSA)

NSA's advisory Announcing the Commercial National Security Algorithm Suite 2.0 (September 2022) and its FAQ v2.1 (December 2024) are posted on media.defense.gov [14]. Both refused automated retrieval (HTTP 403); figures below are from secondary coverage [15].

Algorithms as reported: AES-256; ML-KEM-1024 (FIPS 203) for key establishment; ML-DSA-87 (FIPS 204) for signatures; SHA-384 or SHA-512; LMS and XMSS (SP 800-208) for software and firmware signing. SLH-DSA and the smaller ML-KEM and ML-DSA parameter sets are not CNSA 2.0. Transition dates as reported (support and prefer / exclusive use): software and firmware signing 2025 / 2030; web browsers, servers and cloud 2025 / 2033; traditional networking equipment 2026 / 2030; operating systems 2027 / 2033; niche equipment 2030 / 2033; custom and legacy equipment, update or replace by 2033. From 1 January 2027, new NSS acquisitions must be CNSA 2.0 compliant unless an exception is noted.

Practical obligation. A contractor supplying or operating NSS, or a vendor whose product will be bought for NSS after 1 January 2027, needs the CNSA 2.0 parameter sets, not "FIPS 203 support." ML-KEM-768 is NIST-approved and not CNSA 2.0.

4. Executive Order 14412, 22 June 2026

Signed 22 June 2026, published at 91 FR 38483 on 25 June 2026 [8]. The operative text:

• Policy: "executing the transition of Federal information systems to National Institute of Standards and Technology (NIST)-approved Federal Information Processing Standards (FIPS) for Post-Quantum Cryptography (PQC), and to assist critical infrastructure owners and operators with their transitions." (§1)
• Agencies: OMB guidance requiring each agency to "transition all HVAs and high impact systems to use PQC for key establishment by December 31, 2030" and "to use PQC for digital signatures by December 31, 2031," excluding national security systems. (§4(b))
• Contractors: "Within 180 days of the date of this order, the Federal Acquisition Regulatory Council (FAR Council) ... shall publish a proposed rule amending the Federal Acquisition Regulation (FAR) to require covered contractors to comply by December 31, 2030, with NIST's FIPS, including all applicable FIPS incorporating PQC compliant algorithms." (§6(c))
• Vulnerability disclosure: within 270 days, a proposed rule so that covered contractors' VDPs "incorporate reports of cryptographic vulnerabilities, including testing for lack of encryption and the use of non-FIPS approved algorithms." (§6(d))
• CBOM: within 270 days, CISA and NIST publish "the minimum elements for a cryptographic bill of materials," which "shall enable the automated assessment of the cryptographic assets utilized by a hardware or software element." (§5(d)) Within 180 days, NIST revises CMVP processes "to accelerate validations of cryptographic modules." (§6(b))

Practical obligation. The order does not define "covered contractors"; the proposed rule, due 19 December 2026 (derived), will. The obligation is "NIST's FIPS," which includes FIPS 140-3 validation, not PQC alone: a contractor on unvalidated cryptography has the same gap under this rule as under 3.13.11. No proposed rule had been published at this advisory's date.

5. OMB M-26-15, 24 June 2026

M-26-15, Execution of the Migration to Post-Quantum Cryptography, is the §4(b) guidance. It "does not apply to national security systems." [9] The operative text:

• "Agencies must execute a prioritized migration of cryptographic systems used in information systems that they own or operate with the objective of mitigating as much quantum risk as feasible by December 31, 2030."
• Plans to OMB and ONCD "no later than 120 days from the date of this memorandum" (22 October 2026, derived), containing "The methodologies and automated tools used for the cryptographic inventory" and "A third-party coordination plan."
• "The foundation of the migration plan is a dynamic, continuously updated inventory of all cryptographic assets. This inventory should be created and maintained through automated tools wherever possible ... This data should populate a central Cryptographic Bill of Materials (CBOM)."
• Vendors: agencies "should ensure that any requirements for products used by the agency in those categories include PQC integration" (the CISA categories [12]); the program office "Ensures vendor requirements include PQC-readiness and cryptographic agility provisions."
• Phases: discovery 2026–2027; pilots 2027–2028; key-establishment migration 2028–2030; signatures 2031; full migration 2035. TLS 1.3 "not later than January 2, 2030." Plans "must align" with NIST IR 8547. Appendix A: "Symmetric-key-based protocols should also be avoided."

Practical obligation. The inventory covers systems the agency owns "or operate[s]," including contractor-operated systems, and each plan now at OMB contains a third-party coordination plan. Expect the program office to ask for the contractor's inventory and migration dates, and PQC readiness and agility language in new solicitations.

6. NIST: standards, schedule, validated modules

• FIPS 203 (ML-KEM), 204 (ML-DSA) and 205 (SLH-DSA), published 13 August 2024, are the "FIPS incorporating PQC compliant algorithms" that EO 14412 names [5][6][7].
• NIST IR 8547 was finalized 27 October 2026, obsoleting the November 2024 draft [13]: "NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035." Its tables list ECDSA, EdDSA and RSA signatures, and finite-field DH/MQV, elliptic-curve DH/MQV and RSA key establishment, each "Deprecated after 2030" and "Disallowed after 2035." The window "does not alter the earlier deadlines that apply to high value assets, high impact systems, and other high-sensitivity federal systems under EO 14412 and OMB M-26-15." SHA-1 "will be disallowed for use in FIPS-validated cryptographic modules after 2030."
• CMVP: AWS-LC 3 Cryptographic Module (static), certificate #5314, validated 5 June 2026, Active, lists ML-KEM KeyGen and EncapDecap as approved [10]. CryptoComply Native Go Module, #5349, validated 23 June 2026, Active, lists the same [11]. Neither lists ML-DSA; a validated PQC signature path is a separate check.

Practical obligation. "Deprecated" means the data owner examines the risk and decides; "Disallowed" means the algorithm may not be used for that purpose. From 2031 a validated module running RSA or ECDH is running a deprecated algorithm, and the system security plan has to say so.

7. What a contractor should have in hand, by when

Now: the inventory. SP 800-171 Rev. 2 requirement 3.13.11: "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI." [17] 32 CFR 170.24: "FIPS-validated encryption (CMMC Level 2 security requirement SC.L2-3.13.11) is required to protect the confidentiality of CUI," 3 points deducted if encryption is not validated, 5 if not employed [18]. PCI DSS v4.0.1 requirement 12.3.3, mandatory since 31 March 2025, requires cipher suites and protocols in use to be documented and reviewed at least every 12 months, including "an up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used" [19] (wording as reproduced by [20]; the standard sits behind a license acceptance). Every instrument above starts from that record: where cryptography protects data, which module and version, which algorithm and parameter set, which certificate and status. Add two columns: algorithm family, so RSA, ECDH and ECDSA uses can be listed, and the year the protected data stops mattering (M-26-15's "data expected to remain mission-sensitive in 2030").

By end of 2026: module status and gap list. For each module: 140-3 status, whether it carries ML-KEM or ML-DSA, and whether the parameter set meets the customer's bar (NIST-approved for civilian and CUI work; ML-KEM-1024 and ML-DSA-87 for NSS). List each quantum-vulnerable item with no validated PQC replacement.

By the FAR proposal (about 19 December 2026): the migration plan. Dated, mirroring M-26-15's phases, key establishment first and signatures second, in a form an agency can drop into its third-party coordination plan. Comment on the proposed rule: "covered contractors" and subcontractor flow-down will be settled there.

Procurement language. Solicitations and subcontracts should carry the algorithm and parameter-set requirement (NIST-approved PQC, or CNSA 2.0 for NSS work); CMVP validation with the PQC algorithm inside the boundary; a cryptographic-agility clause; and a right to the supplier's inventory or CBOM once the minimum elements are published (about 19 March 2027).

8. Vendors selling cryptographic or security products into DoW

Three things changed on 18 November 2025, as reported [2][3]:

1. The intake gate. A Component cannot test, pilot, invest in or acquire the product without intake approval from the DoW CIO PQC Directorate, or deploy it without deployment approval, and must submit test and acquisition artifacts for review. A vendor without a package that supports that submission (algorithms and parameter sets, module certificate numbers, interoperability evidence, agility design) is asking a Component to start a process it cannot finish.
2. The bars. Commercial PSK "quantum resistance" is barred for new pilots and acquisitions. QKD, quantum networking for keying, and random number generation that is not FIPS-approved are barred for confidentiality, authenticity or integrity absent an exception. A product that markets any of these as its quantum-resistance mechanism is, on the reported text, not buyable by a Component.
3. The sunset. Existing PSK and symmetric key-establishment "quantum resistance" ends 31 December 2030 (2031 for CSfC-registered solutions); M-26-15 adds that "Symmetric-key-based protocols should also be avoided." A roadmap that reaches 2030 on symmetric key distribution has no federal buyer at the end of it.

For NSS sales, CNSA 2.0 sits on top: from 1 January 2027, ML-KEM-1024 and ML-DSA-87, and LMS or XMSS for firmware signing (S) [15].

9. Questions

What this does not cover

The FAR CUI rule re-proposed 23 June 2026 (91 FR 37550), export classification of PQC products, the DoW strategy's High Assurance ECU track and NSA Type 1 certification, state and sector rules (NYDFS, CJIS, HIPAA), and the CMMC Phase 2 suspension, which HARDAC-ADV-2026-01 addresses. The DoW memorandum and the NSA CNSA 2.0 documents were not retrievable by automated means at publication; where quoted, the text is from labeled secondary coverage and should be confirmed against the primary before use.

About HARDAC

HARDAC Industries LLC is a managed security services provider and compliance consultancy, in business ten years, delivering ISO/IEC 27001 and NIST Risk Management Framework consulting and managed security operations to defense contractors and commercial clients. This advisory is general guidance, not legal advice or an assessment finding; contractors should confirm each instrument's current text and their own assessor's and contracting officer's expectations.