Standards status — no movement this week. FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) are final and unchanged since August 13, 2024. FIPS 206 (FN-DSA, Falcon-based) remains in development. HQC (selected March 2025 as backup code-based KEM) continues through the standardization process with no publication date announced. Nothing from NIST's PQC project page or pqc-forum represents new information this week.
The relevant deadline this week is FIPS 140-2 → Historical. This is not a PQC standard per se, but it is the most concrete and time-bound cryptographic compliance event on the calendar for most organizations. The mechanics are precise and worth stating plainly:
| Date | Event | Operational Impact |
|---|---|---|
| Sep 21, 2026 | FIPS 140-2 → Historical (12 Days) | All active FIPS 140-2 certificates move to CMVP Historical list. FIPS 140-2 can no longer satisfy new federal procurement requirements. Existing deployments continue to function — this is a procurement and compliance gate, not a runtime change. |
| Sep 22, 2026 | FIPS 140-3 becomes the only active standard | New hardware/software procurements for regulated environments must reference FIPS 140-3 validated modules. Contracts and audit frameworks referencing "FIPS 140-2 compliance" without specifying status may require review — consult legal and compliance teams. |
| 2027 | CNSA 2.0 acquisition gate for NSS products | Products procured for National Security Systems must be CNSA 2.0 capable at point of procurement. PQC readiness becomes a supply chain gate, not just a roadmap commitment. |
| 2030 | Classical 112-bit algorithm deprecation (NIST SP 800-131A) | RSA-2048, ECDSA P-256, ECDH P-256 deprecated for new use. Federal civilian systems: key establishment must use PQC (per June 2026 Executive Order). |
| 2031 | Federal digital signature deadline | Digital signatures for federal civilian high-value systems must use PQC algorithms per June 2026 EO. |
| 2035 | Classical 112-bit algorithms disallowed (NIST) | RSA and ECC disallowed for any use in regulated environments. |
One clarification worth repeating because it is frequently misunderstood: FIPS 140-2 Historical does not mean existing deployments stop working on September 22. Cryptographic modules currently running in production continue to function. What changes is the procurement and compliance reference: a Historical-status certificate can no longer be cited to satisfy a "FIPS validated" requirement in a new procurement, a FedRAMP authorization, or a HIPAA/PCI audit that specifically requires active validation status. The distinction matters for how organizations communicate the deadline internally — this is a sourcing and audit gate, not an emergency shutdown.
Google Cloud — PQC default for load balancers coming October 2026. Google Cloud's documentation, updated within the past two weeks, confirms that post-quantum key exchange (X25519MLKEM768 — the hybrid combining X25519 Diffie-Hellman with ML-KEM-768) will become the default for Cloud Load Balancing starting October 2026. Load balancers without an SSL policy attached, or using an SSL policy with no post-quantum key exchange setting, will automatically enable it. Google Cloud explicitly positions this against harvest-now-decrypt-later risk: "We recommend that you enable post-quantum key exchange now, as it provides immediate protection against harvest now, decrypt later attacks." Organizations that need more time can defer to October 2027 using a DEFERRED policy setting — but the default-on change means the burden shifts from opt-in to opt-out. This is a meaningful signal: cloud providers making PQC the default rather than a feature flag is how hybrid key exchange moves from "early adopter" to "industry standard."
Browsers: Chrome, Firefox, and Safari continue shipping X25519MLKEM768 hybrid key exchange in TLS by default — no new significant version changes this week. The browser-side TLS migration is effectively complete for most user-facing web traffic — hybrid ML-KEM key exchange is now the default in all major browsers. The remaining work is the non-browser surface: server-to-server connections, VPN, SSH, and PKI/certificate replacement.
No new HNDL incident reporting this week. NSA, CISA, NCSC, ENISA, and ACSC continue to confirm HNDL collection as active — this is standing intelligence, not new reporting. The most-exposed sectors remain defense contractors, pharmaceutical R&D, financial institutions, energy infrastructure operators, and any organization holding long-lived proprietary or classified data.
A clarification worth amplifying, from MatrixGard's analysis this week: post-quantum conversations tend to fixate on TLS because that is where the visible action is. But HNDL is fundamentally about stored ciphertext — and much of an organization's sensitive ciphertext was never captured over a network in the first place. This matters because it changes where organizations should be spending their HNDL defense budget.
The actual HNDL risk profile breaks down like this: asymmetric key exchange and public-key-encrypted data are the genuine HNDL exposure (RSA-encrypted data, ECDH session key material, ECDSA-signed communications). Symmetric encryption is not in the same danger — Grover's algorithm gives a quadratic speedup against AES, not the exponential break Shor's gives against RSA/ECC. AES-256 remains comfortable; AES-128 is weakened but not broken. If your disk encryption, snapshots, and object storage use AES-256 through your provider's KMS, the bulk encryption side is fine. The HNDL urgency concentrates on: long-lived TLS sessions whose key exchange used RSA or ECDH, long-lived API credentials and tokens protected by public-key cryptography, encrypted email and document stores where the envelope encryption used RSA or ECC, and VPN/SSH sessions using classical key exchange. These are where HNDL collection is operationally useful to an adversary — not everything encrypted.
A standing reminder for Block 4: the absence of a new weekly milestone is the expected state. Verified, independently confirmed quantum hardware progress happens on a timescale of months, not days. A "no movement" entry here is the honest result, not an editorial gap to fill with speculative or vendor-sourced material.
Previous week's focus (Edition #5): PKI migration planning — root-first certificate sequencing, HSM readiness, hybrid certificate deployment.
This week: FIPS 140-2 Historical transition — concrete actions for the next 12 days. This is not theoretical PQC planning; it is an immediate procurement and compliance action with a hard calendar date. If your organization holds US federal contracts, operates under FedRAMP, HIPAA, PCI DSS, DFARS, or CMMC Level 2, the following steps apply.
// FIPS 140-2 Historical Transition — 12-Day Action Checklist
- Run the CMVP module inventory. Go to csrc.nist.gov → CMVP Validated Modules. Filter by your vendor(s) and check the Standard column (FIPS 140-2 vs 140-3) and Status (Active vs Historical). Document every FIPS 140-2 validated module in your environment — hardware (HSMs, smart cards, TPMs) and software (cryptographic libraries embedded in your products or infrastructure).
- Classify your FIPS 140-2 dependencies by use type. Two distinct situations require different responses: (a) existing deployments — modules already running in production are not invalidated by Historical status; assess whether your contracts and audit frameworks require active validation status or merely "FIPS validated" generically. (b) new procurements — any hardware, software, or service you plan to procure after September 21 that will need to cite FIPS validation must specify FIPS 140-3. Document this distinction clearly for your compliance and legal teams.
- Check your contractual language. Many contracts and audit frameworks reference "FIPS 140-2 compliance" without specifying active vs. Historical status. Review your specific contract language and consult legal counsel if needed. FedRAMP authorizations, DoD contracts under DFARS, and CMMC Level 2 (enforcement began November 2026 and directly references FIPS-validated modules under NIST SP 800-171 control 3.13.11) all have specific requirements that may or may not be satisfied by Historical-status modules.
- Initiate FIPS 140-3 procurement planning for any new hardware. If you have pending HSM, smart card, or cryptographic appliance purchases — particularly if planned for next quarter — specify FIPS 140-3 in the procurement requirements now. FIPS 140-3 validation takes 18 to 30 months; vendors that have not yet completed validation are at high risk. When reviewing vendor FIPS 140-3 status, favor vendors whose validation also supports PQC algorithms (ML-KEM, ML-DSA, SLH-DSA per CNSA 2.0) so you are not repeating this exercise in 2029–2030.
- Communicate the distinction internally. The most common internal confusion is "FIPS 140-2 is expiring, does our crypto stop working?" — the answer is no, and that needs to be said clearly. Brief your security, compliance, legal, and procurement teams on what actually changes on September 22: (a) existing validated modules in production continue to function, (b) new procurement requirements shift to FIPS 140-3, (c) audit and contractual obligations depend on specific language. A clear internal communication prevents both over-reaction (emergency remediation of working production systems) and under-reaction (ignoring the procurement implications).
One forward-looking note: FIPS 140-3 is the bridge between the FIPS 140-2 transition and the 2030 PQC mandate. Modules validated under FIPS 140-3 are the platform for PQC algorithm support — FIPS 140-3 validation is required before a module can be certified for the PQC algorithms in FIPS 203/204/205. Organizations replacing FIPS 140-2 modules now should treat FIPS 140-3 as the minimum bar, with PQC algorithm support treated as a selection criterion rather than a bonus feature.
quantum-safe library paper (Shaw, May 2026) and an LLM-assisted static analysis approach for finding classical cryptography in codebases (Quantum-Safe Code Auditing, 2026). The latter is directly actionable for crypto inventory work. Research output on migration tooling is accelerating — the algorithm questions are settled, the engineering questions are now the research frontier.