The federal migration architecture you're not in — yet
The federal timeline is worth understanding precisely because it creates the downstream pressure state agencies will eventually face.
EO 14412, "Securing the Nation Against Advanced Cryptographic Attacks," requires federal agencies to migrate High Value Assets (HVAs) and high impact systems — excluding National Security Systems — to post-quantum key establishment by December 31, 2030, and to post-quantum digital signatures by December 31, 2031. The EO operates through OMB guidance; the broader federal inventory has a later horizon tied to M-26-15's Phase 5 (2035). OMB M-26-15 operationalized this with a five-phase framework:
- Phase 1: Strategy, Planning, and Discovery (2026–2027) — Agency-wide cryptographic inventory: systems, algorithms, certificates, key exchange protocols; migration strategy development
- Phase 2: Pilots and Early Migration (2027–2028) — Pilot PQC deployments; early migration of less complex systems
- Phase 3: Prioritized Migration — Key Establishment (2028–2030) — PQC key establishment for HVAs, high impact systems, and systems with highly sensitive data or elevated vulnerability
- Phase 4: Signature Migration (2031) — Migrate digital signatures to post-quantum algorithms
- Phase 5: Full Migration (2035) — Remaining systems, based on risk and commercial availability
Federal agency plans under OMB M-26-15 were due on October 22, 2026 (120 days after the memo). M-26-15 places 2026–2027 in Phase 1 — the discovery and planning phase is running now across the federal civilian workforce.
NIST IR 8547, published October 2026, is the companion technical guidance. It formalizes the deprecation and disallowance schedule for quantum-vulnerable asymmetric algorithms — RSA, elliptic curve Diffie-Hellman, and similar schemes: deprecated after 2030, disallowed after 2035. NIST has finalized the first three post-quantum algorithm standards — ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) — and organizations should be using them in new deployments now. IR 8547 also specifically flags that application-specific guidance may require earlier migration of key establishment because of the HNDL risk.
State agencies sit outside this formal compliance architecture. The practical question is how long outside it they will remain.
Why "harvest now, decrypt later" threatens state data specifically
The cryptographic risk that motivates this migration timeline is taken seriously at the highest levels of federal policy. EO 14412 and NIST IR 8547 both flag the concern that nation-state adversaries may be conducting what security researchers call "harvest now, decrypt later" (HNDL) operations: systematically collecting encrypted government data today with the intent to decrypt it once a CRQC becomes operational. The timing of CRQC development is genuinely uncertain; primary sources describe the threat as a risk to plan against rather than a confirmed operational fact.
For state agencies, the HNDL risk is particularly relevant because of how long state records are retained.
State vital records — birth, death, marriage, and divorce registrations — are retained on long-term or permanent schedules under state law. Benefits case records, Medicaid eligibility determinations, and unemployment insurance files typically carry multi-year retention requirements. State court records are often retained for very long periods or permanently. Retention schedules vary by state and program, but the pattern is consistent: state agencies manage archives of sensitive personal data that will remain sensitive for decades.
Data potentially collected today and decrypted after a future CRQC is built remains sensitive at the moment of decryption. A resident's Medicaid eligibility record — including household composition, income documentation, and health conditions — is actionable personal information years or decades after the original determination. State vital records carry persistent identity value. State tax data supports fraud operations long after collection. The HNDL risk is worth factoring into state CIO planning even where the specific threat timeline remains uncertain.
State agencies are not protecting data with a short useful life. They are protecting archives. The exposure is accumulating now, against data their agencies are actively collecting and storing.
How federal program requirements will reach state CIOs
Even setting aside the HNDL risk, state agency CIOs should anticipate compliance obligations arriving through federal program requirements rather than through direct application of EO 14412 or OMB M-26-15.
CJIS Security Policy. The FBI's Criminal Justice Information Services Security Policy (v6.0) governs access to criminal justice information across the law enforcement and justice system, including state and local agencies. Security Controls SC-13 and SC-28 require FIPS 140-3 validated cryptographic modules to protect CJI. FIPS 140-3 sets security requirements for cryptographic modules, and SC-13 is already in force on a concrete timeline: CJIS SC-13 states that FIPS 140-2 certificates became "not acceptable" after September 21, 2026. That date has passed. State CJI systems still relying on FIPS 140-2 validated modules that have not moved to FIPS 140-3 validated modules, modules under active FIPS 140-3 review (permitted in the interim under SC-13), or the FIPS 197 AES alternative accepted under SC-13 should review their current compliance posture.
The PQC path forward runs through FIPS 140-3 module validation of ML-KEM, ML-DSA, and SLH-DSA implementations. When validated module implementations become widely available and when NIST's pre-quantum algorithm deprecation schedule takes effect, the existing CJIS requirement for FIPS 140-3 certified modules will incorporate the new standards. State CIOs responsible for criminal justice information systems should expect PQC compliance to follow that path.
IRS Publication 1075. State agencies that receive or access Federal Tax Information (FTI) are governed by IRS Publication 1075, which requires the latest FIPS 140 validated cryptographic modules for FTI in transit, at rest, and in email. The analytical expectation is that NIST's deprecation and disallowance schedule for pre-quantum algorithms — and the resulting maturation of FIPS 140-3 validated PQC module implementations — will cascade into Pub 1075 requirements for FTI safeguarding. Agencies administering state income tax programs, Medicaid enrollment systems that use FTI for income verification, and child support enforcement programs are within scope.
HIPAA. The HIPAA Security Rule does not mandate specific cryptographic algorithms — it requires that covered entities and business associates implement "reasonable and appropriate" safeguards, with encryption as an addressable implementation specification for ePHI. HHS guidance on protecting PHI references NIST publications as the basis for what constitutes adequate cryptographic practice. As NIST formally deprecates pre-quantum algorithms, the practical floor for HIPAA-compliant encryption is expected to shift accordingly. State Medicaid agencies, state health departments, and behavioral health systems that handle ePHI should track that shift.
None of these cascades require PQC deployment today. What they establish is that the analytical expectation — that PQC requirements will flow through CJIS, Pub 1075, and HIPAA — is grounded in how these standards currently operate and in NIST's published deprecation schedule. The timeline runs off that schedule.
What the discovery phase actually requires
The hardest part of post-quantum migration is not algorithm replacement. It is finding everything that needs to be replaced.
OMB M-26-15 Phase 1 is called "Strategy, Planning, and Discovery" for a reason. Modern IT environments have cryptographic dependencies that most agency IT teams have never comprehensively mapped: TLS certificates protecting web services and APIs; cryptographic algorithms embedded in vendor software and SaaS platforms; key exchange mechanisms in VPN configurations; signing keys for software supply chain components; legacy application-layer encryption built directly into benefits platforms, eligibility systems, and case management software from the 2000s and 2010s.
State IT environments compound this challenge. Legacy benefits platforms — mainframe-based eligibility and case management systems that survived modernization cycles — may have cryptographic implementations that predate the current standards conversation entirely. COBOL-era systems did not anticipate cryptographic agility. A PQC migration in those environments is not a configuration change; it may require vendor engagement, platform modernization, or middleware solutions.
NIST IR 8547 is explicit that organizations should begin their cryptographic inventories immediately. The practical scope of a Phase 1 equivalent for a state agency includes:
- Systems inventory cross-referenced against cryptographic use. Which systems encrypt data at rest, in transit, or at the application layer? Which rely on PKI certificates, and when do those certificates expire?
- Third-party and vendor dependency mapping. Which vendor platforms, cloud services, and SaaS tools handle encrypted state data, and what cryptographic commitments have vendors made for PQC migration?
- Certificate authority inventory. State IT organizations that operate their own certificate authorities need to understand the PQC migration path for their root and intermediate CA infrastructure.
- API and integration surface mapping. State data exchanges — including federal-state data connections under CMS, ACF, and SSA program requirements — involve point-to-point cryptographic dependencies that require bilateral coordination to migrate.
This inventory takes time and typically surfaces systems and dependencies the agency did not know it had. NIST's deprecation schedule (deprecated after 2030, disallowed after 2035) means that discovery needs to complete well before 2030 for the systems with the most compliance exposure. M-26-15 runs Phase 1 through 2027. That window is now.
The decision the state CIO needs to make
No federal regulation requires a state CIO to have a post-quantum migration plan today. The compliance cascade through CJIS, Pub 1075, and HIPAA is a well-grounded analytical expectation, but it tracks NIST's algorithm deprecation and module validation schedule, which proceeds on a multi-year timeline.
There is a credible case for a measured approach: state agencies that run predominantly vendor-managed and cloud-hosted infrastructure can reasonably rely on vendor PQC migration roadmaps for commodity TLS and cloud services, while concentrating internal inventory effort on custom application-layer encryption and legacy on-premises systems where vendor migration roadmaps may not exist. That is a defensible prioritization. The risk is in not knowing which category applies to which systems. Without the inventory, that prioritization decision cannot be made.
What is not deferred is the discovery work, because discovery is the prerequisite for everything else — planning, budgeting, vendor negotiation, and prioritization of the highest-risk systems first.
A state CIO that waits for a formal compliance directive to begin the cryptographic inventory will face a compressed timeline when the directive arrives. Federal agencies received OMB M-26-15 guidance in June 2026, with plan submissions required by October 22, 2026 — 120 days covering strategy and initial scoping. Discovery itself runs through 2027. State agencies that begin the inventory now will have the most important input — a full picture of their cryptographic exposure — when the planning conversation begins.
One compliance matter that is not a forecast: CJIS SC-13 states that FIPS 140-2 certificates became "not acceptable" after September 21, 2026. State CJI systems that have not moved to FIPS 140-3 validated modules, modules under active FIPS 140-3 review (permitted in the interim), or the FIPS 197 AES alternative should review their current standing.
Practical first steps for state CIOs that have not yet engaged this topic:
- Assign a lead. Post-quantum migration sits at the intersection of enterprise architecture, security operations, and procurement. Designate a lead or team responsible for the inventory and assign them explicit authority to engage vendors and program offices.
- Scope the inventory around compliance-exposed systems. Start with criminal justice information systems, Medicaid eligibility platforms, and any system that handles FTI. These carry the most immediate compliance exposure.
- Engage key vendors. Most enterprise software and cloud providers have PQC roadmaps — or should. Issue questionnaires asking for PQC migration commitments and timelines. The answers determine whether migration runs through vendor upgrades or requires platform changes.
- Build the cryptographic inventory. Automated scanning tools exist to map TLS certificate inventory, algorithm usage, and certificate expiration schedules. This is the most actionable immediate step and produces the evidence base for everything that follows.
The 2035 disallowance date is nine years away. The 2030 key establishment deadline — the near-term pressure point that drives urgency for state agencies through the compliance cascade described above — is roughly four years away. The cryptographic discovery, vendor engagement, platform planning, budgeting cycle, and actual migration execution collectively consume most of that runway.
Sources and further reading
- NIST IR 8547, Transition to Post-Quantum Cryptography Standards, October 2026
- NIST CSRC News: Transition to PQC Standards — NIST IR 8547
- OMB M-26-15, Execution of the Migration to Post-Quantum Cryptography, June 24, 2026
- Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks, June 22, 2026
- FBI CJIS Security Policy Resource Center
- IRS Publication 1075 — Encryption Requirements
Spartan X's cybersecurity and enterprise architecture work for state government clients addresses the operational layer where post-quantum migration becomes a program execution problem: systems inventory, vendor dependency mapping, and architecture decisions that connect compliance obligations to what a state IT environment can actually deliver in a given procurement and budget cycle.
