Harvest-now-decrypt-later is not a thought experiment any more. Adversaries with the budget to store ciphertext for a decade are doing exactly that, and the federal response — NSM-10, OMB M-23-02, CNSA 2.0, and the FIPS 203/204/205 finalization in August 2024 — has moved post-quantum cryptography from a research conversation into an active compliance obligation. By 2026, an ISSO who cannot produce a current cryptographic inventory and a defensible migration plan is going to have a very uncomfortable ATO conversation. The teams that get through this cleanly are the ones treating PQC as a configuration management and supply chain problem, not a math problem.
The standards that actually matter
NIST closed out the first round of PQC standardization in August 2024. Three FIPS publications are now binding references for federal procurement and system design:
| FIPS | Algorithm | Purpose | Based on |
|---|---|---|---|
| 203 | ML-KEM (Kyber) | Key encapsulation | Module-LWE |
| 204 | ML-DSA (Dilithium) | Digital signatures | Module-LWE/SIS |
| 205 | SLH-DSA (SPHINCS+) | Stateless hash-based signatures | Hash functions only |
FIPS 206 (FN-DSA, derived from Falcon) is still in draft as of this writing and is the one most teams should plan to wait on rather than design around. SLH-DSA is the conservative fallback when you want signature security that does not depend on lattice assumptions, at the cost of much larger signatures and slower signing. ML-KEM and ML-DSA are the workhorses; treat them as the defaults.
NIST also picked HQC in March 2025 as a code-based KEM backup to ML-KEM, with a draft standard expected in 2026. That is a hedge against a future break in lattice assumptions, not a reason to delay ML-KEM deployment.
The federal timeline, stripped of ceremony
NSM-10 (May 2022) set the strategic posture: migrate NSS and federal systems to quantum-resistant cryptography, with the bulk of the work scheduled before 2035.
OMB M-23-02 required agencies to submit prioritized cryptographic inventories of systems using quantum-vulnerable cryptography, with annual updates. The initial inventories were due in 2023 and most were, charitably, incomplete. The 2025 and 2026 updates are where ONCD and CISA are pushing for actual fidelity — not just “this system uses TLS” but algorithm, key size, key lifetime, and replacement plan per protocol per system.
CNSA 2.0 (NSA, updated 2022 and refined since) is the binding schedule for National Security Systems. The headline milestones compliance teams should have memorized:
- Software/firmware signing: PQC preferred from 2025, required by 2030.
- Web browsers, servers, and cloud services: PQC support by 2025, exclusive use by 2033.
- Traditional networking equipment: PQC by 2026, exclusive by 2030.
- Operating systems: PQC by 2027.
- Niche/constrained devices: PQC by 2030, exclusive by 2033.
- All NSS: fully transitioned by 2035.
Non-NSS federal systems are tracking these dates loosely under OMB direction. The 2035 horizon sounds far away until you remember it covers every embedded HSM firmware update cycle, every long-lived CA hierarchy, and every protocol stack baked into appliances you bought in 2022.
What 2026 actually demands
Three things land squarely on compliance teams in calendar year 2026.
A cryptographic inventory that holds up to scrutiny. The M-23-02 inventory is no longer a spreadsheet exercise. Expect assessors to ask for the discovery method (static analysis, network observation, SBOM-derived, vendor attestation), the freshness of the data, and coverage gaps. If your inventory was produced by asking system owners to self-report, plan to redo it with tooling. This maps to CM-8 (system component inventory), SA-9 (external system services), SR-3/SR-4 (supply chain controls and provenance), and RA-3 (risk assessment) — the inventory feeds the risk register, not a binder.
Vendor attestations and procurement language. Any acquisition touching cryptography in 2026 should require the vendor to state, in writing, their PQC roadmap, which FIPS 203/204/205 implementations they support or plan to support, and how hybrid modes (classical + PQC) are configured. SA-4 acquisition language and SR-5 supply chain controls are where this lives. Boilerplate FIPS 140-3 references are not sufficient any more; the validated module list now includes PQC algorithms and you should be naming them.
A migration plan with prioritization logic. CISA’s prioritization guidance is straightforward: rank systems by data sensitivity, data lifetime, and exposure. Anything protecting data with a confidentiality requirement extending past 2035 — long-lived PII, classified material, IP, health records, biometric templates — gets migrated first regardless of system age. Public-facing TLS termination and code signing infrastructure follow. Internal east-west traffic with short-lived data is last. Document the logic; assessors will ask why system X is scheduled for 2029 and system Y for 2026.
The pitfalls that will eat your schedule
Hybrid is the default, not a compromise. TLS 1.3 deployments should be moving to hybrid key exchange (X25519MLKEM768 and similar) before pure-PQC. IETF has settled on the hybrid approach, browsers are shipping it, and it lets you fail safe while implementations mature. Pure ML-KEM-only deployments in 2026 are premature outside specific NSS contexts.
Signature size will break things. ML-DSA signatures are roughly 2.4–4.6 KB depending on parameter set. SLH-DSA is far worse. Embedded systems, DNSSEC zones, certificate chains, and any protocol with tight MTU assumptions will need testing, not just config changes. SC-12 and SC-13 controls are the cryptographic key establishment and use anchors here, but the real work is protocol-level regression testing.
PKI hierarchies have multi-year lead times. If you operate an internal CA that issues certificates with 5–10 year validity, the root and intermediate keys need to be PQC-capable before you can issue PQC end-entity certs. Cross-signing strategies and dual-stack hierarchies are the realistic path. Start the design now if you have not.
Crypto-agility is the actual deliverable. The systems that survive this migration cleanly are the ones where algorithm choice is a configuration parameter, not a hardcoded library call. Bake agility requirements into PL-2 system security plans and SA-8 security engineering principles. The next algorithm transition — when HQC ships, or when a lattice break forces a pivot — should not require another five-year program.
Where to spend your 2026 budget
Discovery tooling, vendor pressure, and PKI redesign. In that order. The inventory is the artifact every other workstream depends on, vendor attestations are how you avoid being the integration point of last resort, and PKI is the one piece of infrastructure that will absolutely block you if you start late. Everything else — protocol upgrades, library swaps, HSM firmware — is downstream of those three.
The 2035 deadline is not the one to plan against. The 2026 inventory update and the 2027–2030 CNSA milestones are. Teams that treat this as a configuration management program with a long tail will finish on time. Teams that treat it as a cryptography research project will not.