Agencies must submit post-quantum cryptography, or PQC, migration plans to OMB and the Office of the National Cyber Director by October 22, 2026. Those plans must cover the systems agencies own or operate, their cryptographic inventories, funding and staffing estimates, modernization schedules, vendor coordination, and the path to a cryptographically agile architecture. That creates a demand signal far more concrete than general interest in “quantum-safe” technology.
For organizations that sell into government, the question is no longer whether PQC belongs on a roadmap. It is whether a customer can obtain a defensible answer today about where classical public-key cryptography is used, which products can support NIST-approved replacements, and what will have to be upgraded or retired.
OMB has turned PQC into an operational plan requirement
OMB Memorandum M-26-15, issued June 24, gives agencies 120 days to provide their first migration plans. It divides the work into phases: inventory and planning through 2027; pilots and early migrations in 2027 and 2028; priority migrations through 2030; signature migration in 2031; and a broader risk-based transition for remaining systems by 2035.
The plan is not limited to a spreadsheet of certificates. OMB directs agencies to locate cryptographic assets, assess dependencies, prioritize high-value assets and high-impact systems, and identify systems too old or constrained to support PQC or hybrid cryptography. Those systems are to receive priority for replacement or decommissioning.
That language changes the procurement conversation. A product can meet a buyer’s current functional requirements and still become a poor fit if it embeds RSA, Diffie-Hellman, ECDH, or ECDSA in firmware, application code, device identities, management interfaces, update mechanisms, or a vendor-hosted control plane without a credible upgrade path. “PQC-ready” will increasingly need to mean more than support for one new algorithm in one protocol.
Federal News Network’s reporting correctly captures the pressure on agencies to involve suppliers, but OMB’s memo spells out why. It tells agencies to include PQC integration requirements for relevant product categories, engage FedRAMP-authorized cloud providers on shared-responsibility boundaries, and use automation where possible to maintain a continuously updated cryptographic inventory.
The deadlines separate key exchange from signatures
Executive Order 14412, signed June 22, sets two deadlines that administrators and vendors should keep distinct. Federal high-value assets and high-impact systems, excluding national security systems, must move to PQC for key establishment by December 31, 2030. They must move to PQC for digital signatures by December 31, 2031.
That one-year separation has practical consequences. Key establishment is the mechanism used to negotiate secrets for protected communications, including the public-key portion of TLS connections and many VPN arrangements. Digital signatures cover a different set of dependencies: code signing, document and transaction approval, device and user authentication, certificate chains, signed API tokens, firmware validation, and software-update trust.
NIST’s three initial PQC standards provide the baseline vocabulary for those plans. FIPS 203 defines ML-KEM for key establishment, while FIPS 204 and FIPS 205 define ML-DSA and SLH-DSA for digital signatures. NIST finalized all three standards on August 13, 2024; they are not experimental placeholders awaiting a future standardization process.
The implementation work is still substantial. Larger public keys and signatures can expose fragile assumptions in packet sizes, certificate handling, database fields, bandwidth budgets, embedded firmware, smart cards, hardware security modules, and authentication protocols. OMB explicitly notes that ML-DSA signatures can run to roughly one or two kilobytes, while SLH-DSA signatures can be much larger and slower. An organization that treats the project as a certificate-authority swap will discover its real compatibility problems late.
Procurement requirements are coming, but the FAR rule is not here yet
Manley’s comments, as reported by Federal News Network, pointed to cryptographic and software bills of materials as possible ways agencies can verify what they are buying. Executive Order 14412 provides the stronger evidence that this will move into contracting: it directs the Federal Acquisition Regulatory Council to publish a proposed Federal Acquisition Regulation rule within 180 days of the order.
That deadline falls on December 19, 2026. The proposed rule is supposed to require covered contractors to comply by December 31, 2030 with applicable NIST Federal Information Processing Standards, including PQC standards. The order also gives the FAR Council 270 days — until March 19, 2027 — to propose contract-language changes for vulnerability disclosure programs that include cryptographic weaknesses, such as missing encryption or use of non-FIPS algorithms.
The distinction matters. Agencies and suppliers should not claim that an enforceable governmentwide FAR PQC clause already exists; the executive order requires a proposed rule, and a proposal still must go through the rulemaking process. Nor has the administration publicly defined every covered contractor, product category, validation method, or contract clause that will emerge.
But waiting for final FAR text would miss the immediate procurement reality. Agency migration plans are due in October, and those plans must include third-party coordination, budget estimates, and schedules. Program offices will need to ask suppliers about PQC support before a final governmentwide clause appears because replacement decisions, cloud renewals, hardware refreshes, and multiyear software contracts cannot be safely deferred until 2030.
Cryptographic agility is the product requirement underneath PQC
OMB’s most consequential instruction may be its emphasis on cryptographic agility: the ability to replace or configure cryptographic algorithms with minimal disruption. The memo says this involves more than avoiding hard-coded algorithm names. It points to configurable cryptographic libraries, protocol negotiation, and key-management infrastructure that can generate, store, and manage both conventional and PQC keys.
For Windows-centric enterprise estates, that calls for an inventory wider than a server certificate scan. Administrators should identify TLS terminators, VPN concentrators, remote-access gateways, public key infrastructure, certificate enrollment systems, code-signing services, endpoint-management tools, firmware-update chains, HSMs, key-management systems, identity providers, smart-card or badge systems, and applications that use signed tokens or mutual TLS.
The key operational test is simple: can the component’s cryptography be changed through a supported upgrade and managed configuration, or is it baked into a binary, protocol implementation, device firmware, or third-party service contract? OMB specifically says systems incapable of supporting PQC or hybrid cryptography must be flagged for priority replacement or retirement. A vendor promise that support is “planned” is not the same as a supported migration path for deployed versions.
Hybrid cryptography will likely be an important transition tool. OMB describes implementations that combine a conventional algorithm with PQC, requiring an attacker to defeat both when properly implemented. But it also warns that hybrid designs create added complexity and should be evaluated for their technical and operational tradeoffs. Hybrid support is useful only if certificate authorities, libraries, clients, proxies, inspection tools, hardware modules, and downstream applications all handle the chosen configuration correctly.
Cloud and physical access systems will be part of the first wave
The General Services Administration has already begun translating the memo into specific programs. In an August 24 post, GSA said it is modernizing the Federal Identity, Credential, and Access Management architecture for quantum-resistant algorithms and expanding its Physical Access Control System lab to test quantum-resistant building-access technology.
That is a useful warning against an overly narrow view of the transition. Federal identity is not limited to website logins. Credential issuance, employee badges, visitor systems, device attestation, certificate-based authentication, access readers, and physical-access control systems all depend on cryptographic trust relationships that may last for years.
GSA said its FICAM working group held its first meeting on August 12 with representatives from 17 agencies. OMB’s memo also assigns CISA, the Department of War, and GSA responsibility for PQC migration efforts involving FedRAMP-authorized cloud services and software, platform, and infrastructure services used by multiple agencies. Shared cloud services therefore face a harder problem than an isolated application: they must define which party inventories the cryptography, upgrades the service, changes customer configurations, validates interoperability, and absorbs the operational risk.
Treasury’s new Quantum-Readiness Task Force reinforces the same direction outside civilian agency IT. Treasury says its public-private effort will focus on sector transition, third-party and vendor readiness, and digital-assets and emerging-technology risk. Its financial-sector focus does not create a binding federal procurement standard by itself, but it expands the number of buyers likely to press suppliers for inventories, implementation plans, and evidence of cryptographic agility.
The immediate milestone is October 22. By then, agencies will be required to turn a quantum-security concern into funded, prioritized plans that name systems, dependencies, and supplier responsibilities. Vendors that cannot document their use of quantum-vulnerable public-key cryptography — and cannot show how deployed products will move beyond it — are likely to find that their next federal renewal asks a question their current product sheets do not answer.
