Five Post-Quantum Dates Arrive Before the Federal Plans Are Due
Two calendars now run over the same estate. The first was written in Washington and sets destinations. Executive Order 14412, signed on 22 June 2026, fixes post-quantum key establishment on federal high-value assets and high-impact systems by 31 December 2030, and digital signatures by 31 December 2031. Two days later, OMB Memorandum M-26-15 asked every agency for a migration plan within 120 days, which lands on 22 October 2026. Under both sits NIST's transition draft, IR 8547 (initial public draft), which deprecates 112-bit quantum-vulnerable public-key algorithms after 2030 and disallows them after 2035.
The second calendar is written by vendors, one certification program and one European regulator, and it moves the estate itself rather than the plan for it. Five of its dates fall before 22 October. Each changes something a supplier or a customer can check on the day it happens. Here they are in order, with the plan deadline last, and the one artifact each of them makes worth asking for.
Practical takeaway. Between 11 September and 19 October 2026 a reporting duty starts in Europe, a mainstream runtime changes its default TLS key exchange, every FIPS 140-2 certificate changes status, a defense specification names a larger ML-KEM parameter set, and a Windows signing certificate expires. A supplier whose product sits in an agency's prioritized inventory or a covered category will be asked for the matching artifact on or shortly after each of those days.
11 September: Cyber Resilience Act Article 14 starts a 24-hour reporting clock
Article 14 of the EU Cyber Resilience Act applies from 11 September 2026. From that day a manufacturer of a product with digital elements must report an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report no later than 14 days after a corrective measure is available, filed through the single reporting platform to the coordinating CSIRT and ENISA. The rest of the Regulation applies from 11 December 2027; the reporting clock does not wait for it.
The artifact: a reporting playbook that includes a cryptographic-vulnerability category and names the CSIRT endpoint it will be filed to.
15 September: JDK 27 ships JEP 527 and puts X25519MLKEM768 first in the default list
JDK 27 is scheduled to reach general availability on 15 September 2026. It delivers
JEP 527, hybrid post-quantum key exchange for TLS 1.3, inside the standard
javax.net.ssl implementation, with X25519MLKEM768 first in the
default preference list so that applications benefit without a code change. Once that release ships,
a service left on the default TLS 1.3 configuration will offer ML-KEM-768 hybrid key exchange from
its next deployment, whether or not anyone decided that it should.
On schedule, that brings hybrid post-quantum key exchange into a mainstream runtime five weeks before the planning deadline. It is also a configuration change worth testing. Whether each TLS-inspecting device, pinned client and older peer in the path completes the handshake on the larger key share, negotiates another supported group, or fails outright is a test outcome, and the test costs less before 15 September than after.
The artifact: the runtime inventory, plus a test result for every TLS-inspecting device and pinned configuration in the path.
21 September: the CMVP moves every FIPS 140-2 certificate to the Historical List
The NIST Cryptographic Module Validation Program has said that on 21 September 2026 it will place all FIPS 140-2 validated modules on the Historical List, allowing agencies to continue using them for existing systems only. The program's standing description of that status is that federal agencies should not include such modules in new systems, though they can be procured for legacy systems.
Nothing happens to the module itself on 21 September. What changes is the standing of a certificate number that appears in proposals, security questionnaires, contract schedules and representations to regulators and insurers. A proposal for a new system written in August that points at a 140-2 certificate is, from 21 September, pointing at a Historical entry. Quentir looked at how that shift is already reshaping supplier paperwork in this week's read on what buyers now accept as proof.
The artifact: a certificate register carrying, for every 140-2 number in your paper, either a 140-3 successor, a validation-queue position, or an explicit legacy-system entry — and contract language that states the standard, the number and the status together.
27 September: a Department of War request for information asks for ML-KEM-1024
The Department of War's request for information on commercially available software-only encryption closes on 27 September 2026. As reported from the SAM.gov notice, it specifies ML-KEM-1024 key transport, deployment without replacing, modifying or adding hardware, integration with public-key infrastructure, and a compliance target of 31 December 2029.
Set that beside the platform default. JEP 527 puts X25519MLKEM768 first, and Cisco's IOS XE 26.x supports an ML-KEM-768 hybrid for IKEv2 when configured. All of these sit inside FIPS 203. A peer offering ML-KEM-768 and a specification requiring ML-KEM-1024 do not meet by accident. Whether a given product bridges them depends on its supported groups, preference order and configuration, verified end to end. M-26-15 leaves hybrid architectures to each agency's own risk assessment and technical requirements, so this question gets answered counterparty by counterparty, in procurement language.
The artifact: a one-paragraph parameter-set position, and an end-to-end test result for the 1024 configuration.
19 October: the Windows Production PCA 2011 signing certificate expires
Microsoft published its code-signing roadmap on 20 August 2026. The Windows Production PCA 2011 expires on 19 October 2026 and Microsoft will transition Windows signing to a replacement certificate authority with the same security properties in the coming weeks. Windows is, in Microsoft's wording, moving toward stronger configurations, including RSA-3072 and SHA-384, by the end of 2026, and Windows signing will transition to post-quantum signing in 2027. Microsoft also named five practices that can make an application fail even when Windows considers the signed file valid: comparing certificate chains between signed binaries; pinning Microsoft certificate subjects, issuers, thumbprints or serial numbers; requiring SHA-256 or RSA-2048 specifically; parsing Authenticode chains directly instead of through the Windows trust APIs; and running a private trust store that is not updated for Microsoft rotations.
Microsoft's own five actions for developers make a usable checklist: validate trust rather than certificate identity, use supported Windows trust APIs such as WinVerifyTrust instead of custom Authenticode validation, stay algorithm-agnostic rather than assuming a fixed RSA-2048 and SHA-256 pairing, test the application against replacement Microsoft certificate hierarchies and stronger signing configurations, and review any private trust store so it has a process for recognizing legitimate Microsoft certificate rotations.
The artifact: those five actions answered for every signed component you ship or run, before 19 October.
22 October: every agency plan is due, and each supplier is a line in one
Every agency's post-quantum migration plan is due to OMB and the Office of the National Cyber Director 120 days after 24 June 2026. M-26-15 requires the plan to include, among other things, a cryptographically agile architecture and a third-party coordination plan, and it assigns program offices responsibility for ensuring that vendor requirements include post-quantum readiness and cryptographic-agility provisions. The federal buying side has been moving toward that posture for months, as Quentir traced when the General Services Administration took the lead on migration. A supplier whose products appear in an agency's inventory of prioritized systems, or in a covered product category, is a line in that plan.
The artifact: a short, checkable package for each federal customer, stating which products implement which algorithms at which parameter sets, from which dates, with which certificates at which status, and how the customer switches.
How Quentir Reads It
Laid on one page, the six dates show a commercial and certification calendar running ahead of the policy calendar, and the two disagreeing in at least one place that matters: the ML-KEM parameter set. A migration plan describes where an estate will be in 2030. The platform calendar describes what that estate will actually be doing on 15 September, on 21 September and on 19 October. A board reading only the first will be surprised by the second, on days it could have read months in advance.
The seam is worth stating plainly, because it is the kind of gap that becomes a contract dispute rather than an engineering ticket. Java's default and Cisco's supported hybrid land on ML-KEM-768. A defense specification asks for ML-KEM-1024. Both are FIPS 203. The question of which one a supplier ships, and whether the two interoperate on a given path, belongs in the procurement language now, while it is still cheap to answer.
Quentir's September Signature Brief, October 19 Comes Before 2030, works these six dates into a calendar-to-estate map, a certificate re-basing, a parameter-set policy and a reporting rehearsal, with seven board questions and the answer each should produce — the fixed scope, checklists and refresh triggers this post does not carry. It is available as a single edition at quentir.ai/products, and to All-access members in the Quentir Library, where every edition this post draws on sits behind one subscription.
Published intelligence, built to inform your own decisions. Published: 4 September 2026.
Sources: Regulation (EU) 2024/2847, Cyber Resilience Act, Articles 14 and 71 (published 20 November 2024), and the European Commission's CRA reporting obligations page (updated 31 July 2026), for the 11 September 2026 start and the 24-hour / 72-hour / 14-day sequence. OpenJDK, JDK 27 project schedule and JEP 527: Hybrid Post-Quantum Key Exchange for TLS 1.3, for the 15 September 2026 general availability and the default preference order. National Institute of Standards and Technology, Cryptographic Module Validation Program (program page, "Applicability of Validated Modules", updated 21 August 2026) and the validated modules page, for the 21 September 2026 move to the Historical List and the meaning of that status. ExecutiveGov, "DOW Seeks Software-Based Post-Quantum Encryption Solutions" (1 September 2026), reporting the SAM.gov notice a36789b44e9941569c04d46314f15b15, for the 27 September 2026 response date and the ML-KEM-1024 specification; the SAM.gov notice is carried as the primary record and the details above are stated as reported. Microsoft, "Next generation code signing" (20 August 2026), for the 19 October 2026 Windows Production PCA 2011 expiry, the RSA-3072 / SHA-384 move, the five compatibility-risk practices and the five developer actions. Office of Management and Budget, Memorandum M-26-15 (24 June 2026), for the 120-day plan deadline, the cryptographic-agility architecture and third-party coordination requirements, and the hybrid architecture provision. Executive Order 14412 (signed 22 June 2026, Federal Register 25 June 2026), for the 2030 and 2031 dates. NIST IR 8547 (initial public draft), 12 November 2024, for the 2030 deprecation and 2035 disallowance of 112-bit quantum-vulnerable algorithms; it remains a draft. FIPS 203 for the ML-KEM parameter sets, and Cisco's post-quantum IKEv2 configuration guide for IOS XE 26.x hybrid support. Every page cited above was checked on 4 September 2026.
Published intelligence, built to inform your own decisions. Published: September 3, 2026.