2026 Cybersecurity Policy and Compliance Deadline Guide: FIPS 140-3, PQC, AI Security, and More
2026 Cybersecurity Policy and Compliance Deadlines: FIPS 140-3, Post-Quantum, and AI Rules
Last Updated: October 6, 2026
Four different regulators now impose cryptography and data security deadlines on the same organizations but none of them publish a combined calendar. A federal contractor in 2026 may simultaneously face a cryptographic module validation cutoff, a post-quantum migration mandate, an incident reporting rule still in rulemaking, and a state AI law, each with its own effective date and its own enforcement body. The compliance work overlaps heavily but the deadlines do not. For this Defense Industrial Base especially, this complexity is made even harder given the typical long lead time of government acquisitions and cybersecurity budgeting. This guide puts all dates in one place for a comprehensive look at the existing policies, investment areas, and compliance deadlines the DIB faces in 2026 and beyond.
The pace itself is significant. In 2018, California enacted a comprehensive data privacy law. By the end of 2025, nineteen states were enforcing one, with additional statutes taking effect throughout 2026 (IAPP). Federal activity followed the same curve: 2022 brought a quantum preparedness act and a national security memorandum; 2024 brought the finalization of NIST's first three post-quantum encryption standards (FIPS 203, 204, 205); and 2025 brought two cybersecurity executive orders. The first half of 2026 alone produced two quantum-focused executive orders, a federal cryptographic validation deadline, and the first comprehensive state AI law to reach its effective date. In June 2026, OMB issued "Execution of the Migration to Post-Quantum Cryptography," calling for the accelerated quantum uplift of all federal systems. This year marks a spike regulatory activity across privacy, defense, healthcare, and finance that all convene on the same subjects at once: quantum encryption, data security, and artificial intelligence.
Which of These Deadlines Apply to You?
The sheer volume of news coverage and policy direction can be overwhelming, especially for small businesses in the government supply chain. Review the table below to assess which items in the timeline apply to your business and compliance needs.
Important note below, because organizations routinely assume they are out of scope:
The DOJ Data Security Program is not a defense rule. It applies to any U.S. person or entity engaging in covered data transactions with six designated countries of concern, and the bulk thresholds are lower than most teams expect: more than 1,000 U.S. persons for biometric identifiers, more than 10,000 for personal health or financial data, more than 100,000 for covered personal identifiers, and only 100 for human genomic data, measured across a rolling twelve months (Jackson Lewis). A vendor agreement, an employment agreement, or an investment agreement can each constitute a covered transaction. A mid-size company with an offshore development contractor can be in scope without ever having considered itself an exporter of data.
CIRCIA is not yet a requirement, and the delay is not a reprieve. CISA missed its statutory October 2025 deadline to complete the rulemaking, then missed an internal May 2026 target, and the 2026 Unified Agenda now points to a final rule in September 2026 (Hunton). The statutory clocks of 72 hours for a covered incident and 24 hours for a ransom payment do not change with the rulemaking timetable (CISA). What is still unsettled is the covered-entity definition, which is precisely the part organizations need in order to know whether they are in scope. Building the reporting capability now is cheaper than building it inside a 72-hour window later.
Look down that table and the overlap is the point. A defense contractor with an offshore subcontractor and a Colorado sales entity is subject to four of these regimes, enforced by four different bodies, with four different definitions of what counts as sensitive. What they share is a single underlying demand: know where your sensitive data is, and be able to demonstrate that it is protected wherever it goes. Every one of these rules is a different agency asking the same question.
September 21, 2026: the FIPS 140-2 Sunset
FIPS 140-2 certificates moved to the historical list on September 21, 2026. From that date, vendors without FIPS 140-3 validation can no longer use their certificates to support new federal acquisitions. Existing deployments are not immediately affected, but for new government business a historical certificate carries no weight.
FIPS 140-3 is a substantive revision rather than an administrative update. It introduces stricter lifecycle assurance, enforces stronger algorithm requirements, and aligns U.S. validation with the ISO/IEC 19790 framework used internationally. It is also the validation pathway for the NIST post-quantum algorithms that federal policy now requires: quantum-resistant cryptography satisfies federal mandates only when implemented in a validated module. With 140-3 reviews averaging well over a year, organizations beginning the process now should expect a meaningful gap in eligibility.
What Happens If Your FIPS 140-3 Module Is Not Yet Validated
This is the most common position to be in, and the most poorly served by available guidance.
FedRAMP is direct about it. Its published guidance on the sunset states that it defers to NIST and, in its own words, "cannot and will not help you make a decision here" (FedRAMP). The same guidance records that as of July 2026, 521 modules remained in the FIPS 140-3 testing pipeline while 614 vendors held full validation. The queue is roughly the size of the entire validated population, meaning this is a throughput constraint in the validation system itself, not a story about vendors who failed to plan. Any organization who treated the September date as a vendor-diligence question will find that the vendors who did plan are sitting in the same queue.
FedRAMP describes three permissible paths, and each one requires the provider to formally document the choice as a risk or a vulnerability in its authorization package:
- Move to a module that already holds FIPS 140-3 validation, through established change processes.
- Stay on the legacy FIPS 140-2 module past the sunset, tracked as an open vulnerability.
- Deploy the FIPS 140-3 version of the module before its validation completes, with the associated risk documented.
Each of these available path ends in a documented risk acceptance. There is no option that simply complies without an encryption transition in future plans.
The choice is architectural. When the cryptographic module is bound into the infrastructure that uses it, replacing the module means a change to the system boundary, a change request, and a re-authorization conversation. Cryptographic agility (being able to swap an algorithm or a module through configuration rather than redesign) is what turns this from a re-architecture into a change ticket. Organizations that built for agility before the deadline are choosing between options. Organizations that did not are choosing between risk write-ups.
What the FIPS 140-2 Sunset Means for CMMC and CUI
For defense contractors the sunset is not an abstract federal procurement matter. It reaches directly into CMMC Level 2. If you're not yet familiar with the CMMC practices, we recommend opening our practice map in a new tab to dive into this topic.
Practice SC.L2-3.13.11 requires FIPS-validated cryptography when cryptography is used to protect the confidentiality of CUI. The requirement is validation, not algorithm choice: using an approved algorithm is not sufficient, because the module implementing it must itself have been tested and validated (DIB SCC CyberAssist). Assessment guidance for the practice has historically referenced FIPS 140-2 validation, which is now historical.
The FIPS-validation requirement also attaches to CUI stored or transmitted outside the protected environment of covered systems. Encryption inside the boundary does not carry the same obligation.
That scoping rule is where Level 2 readiness often fails. It makes the boundary definition load-bearing, draw the boundary generously and the assessment surface expands to match. Draw it tightly and every path CUI takes outside it becomes a control you now have to evidence: the attachment sent to a subcontractor, the file synced to a personal device, the document shared with outside counsel, the record pulled into a vendor's system. Failure here is often not due to weak cryptography. Failure occurs because the CUI went somewhere the boundary did not follow, and the protection was a property of the environment rather than a property of the data.
CMMC readiness is a data architecture decision before it is a compliance project. When identity, policy, and encryption are bound to the data object itself, the object carries its own protection across the boundary, and the question of which side of the line it is sitting on stops determining whether it is protected. The same binding is what lets one control answer to several frameworks at once, because CMMC, HIPAA, GLBA, and ITAR are each specifying a floor for the same underlying property.
Compliance frameworks set minimums. Architecture is what makes the minimum a byproduct rather than a project.
What EO 14412 and EO 14413 Require
Two executive orders issued in June 2026 address the quantum transition from complementary directions.
Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks," establishes binding deadlines for federal post-quantum migration. High-value assets and high-impact systems must transition to post-quantum key establishment by December 31, 2030. Digital signatures follow by December 31, 2031. The order also extends beyond agencies themselves. It directs the Federal Acquisition Regulatory Council to propose rules requiring covered contractors to comply with FIPS standards incorporating post-quantum algorithms by the end of 2030, alongside vulnerability disclosure policies that cover cryptographic weaknesses.
Executive Order 14413, "Ushering in the Next Frontier of Quantum Innovation," addresses the other side of the same problem. It calls for a coordinated national effort to develop an operational quantum computer, expand the quantum workforce, and secure the supply chain supporting both. Taken together, the two orders reflect a settled position. The federal government is no longer debating whether large-scale quantum computing arrives; it is funding its development while requiring defenses against it in advance.
Which Post-Quantum Standards the Mandates Point To
The three standards finalized in 2024 are ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a signature alternative built on a different mathematical foundation. The split between key establishment and signatures is why EO 14412 carries two different deadlines: key establishment protects data in transit and is the more urgent of the two, while signature migration is a larger engineering effort with a longer runway.
When Do Post-Quantum Requirements Take Effect?
Public discussion of quantum risk tends to center on a single question: when will a quantum computer break current encryption? For planning purposes, a different question is more useful: when do the protection requirements take effect? Those dates are already published.
The NSA's CNSA 2.0 suite specifies the required quantum-resistant algorithms for national security systems and defines transition windows for each category, with full migration expected by the early 2030s. Defense department modernization strategy points in the same direction, treating quantum-resistant cryptography as a procurement requirement rather than an optional upgrade.
Behind these timelines is the harvest-now, decrypt-later problem. By the time a cryptographically relevant quantum computer is publicly demonstrated, data transmitted in prior years is already exposed. The published deadlines therefore reflect estimates of how long migration takes, not predictions of when the threat materializes.
Quantum Investment in 2025 and 2026
Capital markets point the same direction. Quantum startups raised a record $4.1 billion in 2025 (Crunchbase). Four publicly traded pure-play quantum companies now hold a combined market value near $36 billion, Xanadu completed a public listing in spring 2026 at an approximately $5 billion valuation, and Quantinuum has filed for a Nasdaq listing following a September 2025 raise at a $10 billion pre-money valuation. Consolidation has begun as well, with IonQ acquiring Oxford Ionics for roughly $1.08 billion and D-Wave acquiring Quantum Circuits for $550 million.
Parallel Developments in AI and Data Security
The quantum orders are the most prominent 2026 policy activity, but several parallel developments carry their own compliance dates. Colorado's Artificial Intelligence Act, the first comprehensive state AI law, took effect June 30, 2026, with related legislation advancing in California and other states. NIST released draft guidance for a Cybersecurity Framework profile addressing AI systems, with a final version expected in 2026. CISA's rule implementing CIRCIA remains in rulemaking, with a final rule expected in fall l2026 and reporting obligations beginning after that (Hunton). The Department of Justice's Data Security Program, fully enforceable since October 6, 2025, restricts bulk transfers of sensitive personal data to designated countries of concern. Though these rules differ in scope and sector, they share a common premise: organizations are expected to know where sensitive data resides and to demonstrate that it is protected.
How to Prepare for FIPS 140-3 and PQC Migration
Across all of these requirements, the practical work overlaps heavily. Organizations benefit from a complete inventory of where cryptography is used in their own systems and their vendors' systems, an assessment of which modules carry current FIPS 140-3 validation, and a clear picture of where sensitive data resides and how it moves.
Because algorithm standards will continue to evolve, cryptographic agility is increasingly treated as a baseline architectural property rather than a feature. In practice it means four things: no algorithm identifiers hardcoded into application logic, key wrapping indirection so that re-encryption does not require touching every record, negotiation at the protocol layer rather than fixed cipher selection, and centralized policy so that an algorithm change is a configuration change rather than a redesign. Migration efforts of this kind have historically taken years, which is the reasoning embedded in every deadline above. The organizations best positioned for the coming standards are those that begin the inventory work before the mandates require it.
Not sure where to start? Reach out, we specialize in API-first quantum uplift that meets the toughest regulatory requirements at a fraction of the time and cost.
