The Branch That Waits
After 2030, NIST’s roadmap leaves each data owner a decision on whether to continue. On the public web, the alternative depends on rules and root programmes the owner does not control.
A deprecation date switches nothing off. It hands the data owner a decision with two unequal branches. Continuing requires no change from anyone. Replacing the signature with a post-quantum one that browsers trust requires others to move first. On the public web, the others include a rule-making forum and the browsers’ root programmes. On 22 October, that forum’s minutes said its draft to allow a post-quantum signature would come off a tracking list. Five days later, NIST published the roadmap that makes continuing a decision after 2030.
This week’s anchor edition read the roadmap’s two names for who decides. In the roadmap’s body, the data owner decides. In its glossary, the user accepts the risk. The edition also separated a layer operator’s technical choice from the decision addressed to each owner. This piece follows the other branch. The piece was developed with AI writing assistance under human verification and editorial control.
One disclosure before the argument. Several sources cited below come from a browser made by the group that makes the image tool named in the method note. They are a position its root programme posted on the forum’s list, its plan for a new certificate format and its draft policy for that format. I read them in the original and use only what they state.
What the rules permit
The CA/Browser Forum is where certificate authorities and the makers of browsers agree the rules for publicly trusted website certificates. Each browser also runs a root programme, the policy by which it decides which certificate authorities to trust. The forum’s Baseline Requirements, in the version dated 4 October, admit RSA keys and elliptic-curve keys on three named curves. Then section 6.1.5 closes the list: “No other algorithms or key sizes are permitted.”
There is a ballot to change that. SC-106, listed in the minutes as “Allow ML-DSA”, would admit ML-DSA, a post-quantum signature scheme that NIST standardised in FIPS 204. Its own summary said that passing it “does not compel any Root Store Operator to accept ML-DSA”. In May, two draft proposals to allow ML-DSA were compared on the forum’s list. The root programme of one browser replied that it “cannot support either of these proposals”. Allowing ML-DSA, it wrote, “introduces a large increase in certificate size”. It added that the public logs that record certificates would be “forced to ingest, store, and serve” them. Another root programme described its own limits on key algorithms as “simply present policy requirements”. A representative of a certificate authority saw no reason not to “plan for both”. Nothing here faults the forum. The objections on record are technical: certificate size and the load on public logs.
At the forum’s meeting in Vienna on 23 September, the chair listed an ML-DSA ballot as one “on which no progress has been made recently”. On 22 October, the working group’s minutes recorded, per its proposer, that the draft “will be removed from the SCWG tracking list”. Discussion might move to what the minutes call “the upcoming Client Authentication Working Group”. In the minutes I read, the ballot never left draft status. I found nothing in those records that closes the path. They show a path that several parties must agree to open.
A second path
The browser that objected in May has its own path. In February, it said it had “no immediate plan” to add traditional certificates carrying post-quantum cryptography. It is developing Merkle Tree Certificates, a format meant to keep post-quantum authentication small. It dates later phases to the first and third quarters of 2027, the first of them to begin “once the core technology is validated”. On 28 October, the day after NIST’s final roadmap, it updated a draft policy for the authorities that would issue that format. The draft calls itself a release candidate. That path also runs through parties a website owner does not control.
What the roadmap expects
The roadmap describes this dependency in general terms. One section runs from protocol standards and software libraries to hardware, public key infrastructure and the applications and services on top. Applications may rely on public key infrastructures “that would need to be updated” before “the applications themselves can migrate”. Hardware vendors are asked to start “immediately”, because research, design and fabrication have long lead times. For signatures, the roadmap gives a reason for urgency that does not depend on stored traffic being decrypted later. Signatures are not vulnerable to that attack. Their transition is urgent because it takes longer, is more complex and needs “a greater number of parties to coordinate”.
The roadmap will deprecate quantum-vulnerable signatures after 2030. Organisations, it says, “may continue using these algorithms and parameter sets as they migrate” to the post-quantum signatures it lists. The data owner “must examine this risk potential and decide whether to continue”.
Get André Afonso Silva’s stories in your inbox
Join Medium for free to get updates from this writer.
Two branches, one owner
Read the roadmap and the forum’s records together. The roadmap gives the decision to the data owner. For a public website, one branch is open by default: keep the kind of certificate the rules already permit. The other branch is the migration the roadmap points to. On the traditional path, the forum’s rules and each browser’s root programme both have to move. A change to the rules would not oblige any browser to trust the result. On the second path, a browser writes its own policy for a new format. No website owner can open either path alone.
This series has a cold test for arrangements like this one. Is there a locus de autoridade atribuível (LAA), a point where one can say who decided? Here the roadmap names one. The data owner decides. But the authority it names covers a decision whose second branch the owner cannot yet execute. The owner can decide to migrate. It cannot set the date on which browsers will trust the replacement. That date has no single author. It is spread across a forum of certificate issuers and certificate consumers, each root programme’s policy and the work on a new format. The forum is one part of that arrangement, not its only gate.
What arrives together
This arc’s thesis is that shared substrate produces correlated failure. The anchor edition tested it on the decision side, where a date is not a failure. It named what may arrive together: continued use without each owner’s decision. The public web adds a shared constraint. Owners depend on rules they do not write and on root programmes they do not run. Those dependencies are shared but not identical. One browser may accept a new format before another does. In the documents I read, no path was yet open to website owners in general. The case documents a common dependency. It does not document a simultaneous migration or a failure.
Three limits
Nothing here concerns key establishment, where the roadmap’s reasoning differs. Nothing here predicts 2030. The forum may yet admit ML-DSA in traditional certificates. A browser is developing a different format on its own timetable. The two paths need not open together. Organisations that run their own certificate infrastructure fall outside these rules. Their replacement depends on other layers, such as their software and suppliers.
The next layer down
Next week goes one layer further down. On 26 October, the PHP project rebuilt its Windows packages around a patched compression library. The PHP source and version stayed the same. What changed sat beneath the version number.
The roadmap names who decides whether to continue after 2030. The rules for publicly trusted web certificates, in the version dated 4 October, admit RSA and three elliptic curves. “No other algorithms or key sizes are permitted.” The new format has phases dated in 2027 and a draft policy. None of those dates is set by a website owner.
References
CA/Browser Forum. (2026, October 4). Baseline requirements for the issuance and management of publicly-trusted TLS server certificates (Version 2.3.1). https://cabforum.org/working-groups/server/baseline-requirements/requirements/
CA/Browser Forum Server Certificate Working Group. (2026). SC-106: Enable post-quantum cryptography (PQ) key pairs in TLS server certificates [Pull request #679]. GitHub, cabforum/servercert. https://github.com/cabforum/servercert/pull/679
Server Certificate Working Group mailing list, CA/Browser Forum. (2026, May 5). Differences between the two ML-DSA ballot proposals [Discussion thread]. https://groups.google.com/a/groups.cabforum.org/g/servercert/c/tCCFCVb-im8
CA/Browser Forum. (2026, September 23). Minutes of the F2F 68 meeting in Vienna, Austria — SCWG, September 23, 2026. https://cabforum.org/2026/09/23/minutes-of-the-f2f-68-meeting-in-vienna-austria-scwg-september-23-2026/
CA/Browser Forum. (2026, October 22). 2026–10–22 minutes of the Server Certificate Working Group. https://cabforum.org/2026/10/22/2026-10-22-minutes-of-the-server-certificate-working-group/
Chrome Security. (2026, February 27). Cultivating a robust and efficient quantum-safe HTTPS. Google Security Blog. https://security.googleblog.com/2026/02/cultivating-robust-and-efficient.html
Chrome Root Program. (2026, October 28). [Draft] Chrome Quantum-resistant Root Program Policy, Version 0.4.0 (RC 1.0.0). https://googlechrome.github.io/chromerootprogram/cqrp/draft-policy/
Moody, D., Perlner, R., Regenscheid, A., Robinson, A., & Cooper, D. (2026, October). Transition to post-quantum cryptography standards (NIST IR 8547). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.IR.8547
PHP. (2026, October 26). Updated PHP Windows builds for Brotli security fix. php.net. https://www.php.net/archive/2026.php#2026-10-26-1
On method
Written with the support of Claude (Anthropic) and ChatGPT (OpenAI) for text and Gemini (Google) for the image. The full cognitive signature (intent, constraints, judgment under uncertainty, veto and responsibility) is mine, and so are the errors. Facts are verified against primary sources before they enter, and where verification was not possible the text says so.
I publish this note every week because this series argues that a document produced because someone asked for it is worth less than a record produced in the ordinary course of work. Nobody asked me for this note.
Essência AI Insights is a weekly series on governance, systemic risk and institutional infrastructure for emerging technologies. Written by André A. Silva
Tags: Artificial Intelligence, AI Governance, Post Quantum Cryptography, Public Key Infrastructure, Systemic Risk
