Cloudflare's post-quantum CA has issued nothing yet, and it targets authentication, not recorded traffic

Three test issuers, and Cloudflare is not one of them

At 15:44 GMT on Monday 5 October 2026, the file Chrome publishes to list the Merkle Tree Certificate (MTC) issuers and mirrors it knows about held three issuers and three mirrors. All six carried the realm label UNTRUSTED_VALIDATION_ONLY, which Chrome's testing page says keeps test keys to "validation testing only". Cloudflare was not on the list. That is six days after Cloudflare announced, on 29 September, that it will become a public certificate authority (CA), and it matches what Cloudflare's own post says in plainer words: "We are not issuing certificates yet, and it will be a little while before we do."

Every date in the announcement is still ahead. Cloudflare's first MTCs are targeted for the first quarter of 2027, which starts 94 days after the announcement. Chrome's own FAQ places the launch of the root store that would trust MTC issuers by default in a third phase, with a target of the third quarter of 2027, which starts 275 days after it. Both counts are ours: 29 September 2026 to 1 January 2027 is 94 days, and to 1 July 2027 is 275.

What that does not establish. It does not show that Cloudflare will be refused, delayed or untrustworthy. Nothing here is overdue, and no root programme has ruled. It does not show that the plan is poor. It shows the state on 5 October 2026: a plan with dates on it, applications that Cloudflare says are pending, a standard that is still a draft, and no certificate. The phrase in some coverage, "quantum-safe certificates", describes a product nobody can yet inspect. It also hides that the announcement concerns one of two separate quantum risks, and not the one that decides whether recorded traffic can be read later.

What Cloudflare committed to, and what it only plans

Cloudflare published three documents on 29 September: a press release, a blog post on the CA, and a blog post on MTCs. The Hacker News bulletin of 1 October is a pointer to them, not a source. The table sorts the statements by how firm they are. Wording in quotation marks is Cloudflare's own.

Cloudflare's statements of 29 September 2026, from its press release and its two blog posts, sorted by firmness.

1. Item

   Becoming a public CA

   How Cloudflare states it

   "our intent to become a public certificate authority"

   Firmness

   Intent

2. Item

   Root programme applications

   How Cloudflare states it

   "We have applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs"

   Firmness

   Made, outcome pending

3. Item

   GlobalSign root

   How Cloudflare states it

   "signed a definitive agreement to acquire an established, broadly trusted root"; closing "expected to close in the next two months", "subject to customary closing conditions"

   Firmness

   Signed, not closed

4. Item

   Classical certificates

   How Cloudflare states it

   begin "following completion of browser root program application and acceptance process"

   Firmness

   Conditional, no date

5. Item

   Merkle Tree Certificates

   How Cloudflare states it

   "with the first certificates issued in the first quarter of 2027"

   Firmness

   Plan, dated target

6. Item

   Chrome's MTC root store

   How Cloudflare states it

   "we will need to apply to Chrome's Quantum Resistant root store"

   Firmness

   Not yet applied

7. Item

   Price

   How Cloudflare states it

   "we will provide standard MTC issuance at no cost"

   Firmness

   Plan

8. Item

   Renewal rule

   How Cloudflare states it

   "We will only issue to clients that support ACME Renewal Information (ARI)"

   Firmness

   Plan

Item	How Cloudflare states it	Firmness
Becoming a public CA	"our intent to become a public certificate authority"	Intent
Root programme applications	"We have applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs"	Made, outcome pending
GlobalSign root	"signed a definitive agreement to acquire an established, broadly trusted root"; closing "expected to close in the next two months", "subject to customary closing conditions"	Signed, not closed
Classical certificates	begin "following completion of browser root program application and acceptance process"	Conditional, no date
Merkle Tree Certificates	"with the first certificates issued in the first quarter of 2027"	Plan, dated target
Chrome's MTC root store	"we will need to apply to Chrome's Quantum Resistant root store"	Not yet applied
Price	"we will provide standard MTC issuance at no cost"	Plan
Renewal rule	"We will only issue to clients that support ACME Renewal Information (ARI)"	Plan

Two things in that table are easy to miss. First, the applications named in the first post are to the four existing root programmes. The second post says Cloudflare still has to apply to Chrome's separate Quantum-resistant root store before browsers can trust its MTCs. Second, the documents use different words for the same quarter. The MTC post says Cloudflare is "targeting early 2027 for inclusion in Chrome's newly launched Quantum-resistant Root Store". Chrome's FAQ says that store's launch is Phase 3, target Q3 2027, and that Q1 2027 is Phase 2: "initial public MTC bootstrapping" by invited operators of Certificate Transparency (CT) logs. This briefing follows Chrome's page for Chrome's schedule.

The Hacker News bulletin compressed this into one sentence, "Production MTC issuance is scheduled for the first quarter of 2027", placed straight after a sentence about Google. The date is Cloudflare's. Google's Q1 2027 is the start of Chrome's Phase 2. Chrome's draft policy limits the first MTC operators to organisations that ran a "usable" CT log before 1 February 2026, and Chrome's log list (version 93.5, 5 October) shows Cloudflare's Nimbus2026 usable since 8 November 2024 and Nimbus2027 since 15 November 2025. On our reading Cloudflare is eligible. Eligible is not included.

One label, two different problems

A "quantum-safe certificate" sits across two risks, and the primary sources keep them apart. A reader who hears the label may conclude that recorded traffic is now protected. The sources say the protection for recorded traffic comes from a different mechanism, not from this announcement.

Recorded traffic: key exchange. Chrome's Root Program page states the first threat plainly: an adversary could "store encrypted traffic now" and decrypt it once a quantum computer exists. Its next sentence: "Chrome has mitigated this risk through the deployment of post-quantum key exchange." Cloudflare's April post says it "enabled post-quantum encryption for all websites and APIs in 2022, mitigating harvest-now/decrypt-later attacks", and that "over 65% of human traffic to Cloudflare is post-quantum encrypted". The October 2025 post gave about 50% of traffic to its edge network. The standards followed: NIST's ML-KEM, FIPS 203, has been final since 13 August 2024, and RFC 10024, hybrid ML-KEM key agreement for TLS 1.3, is a Proposed Standard dated August 2026.

Impersonation: certificate signatures. The second threat is a server being impersonated once a quantum computer can forge signatures. Let's Encrypt puts the difference this way: "A quantum computer needs to forge a signature in real time, not retroactively". Cloudflare's April post is blunter about timing: "If Q-Day is far off, authentication is not urgent: deploying PQ certificates and signatures does not add any value, only effort." The same post argues the date may be nearer and moves Cloudflare's own target for full post-quantum security, authentication included, to 2029. We have not assessed the quantum estimates behind that move. The NCSC, in its March 2025 timelines, orders the work the same way: "the services to protect confidentiality of your key assets will be available soonest; certificate-based PKI, and IoT and ICS protocols will follow more slowly."

A new CA does not close the second risk by itself. Chrome's post-quantum authentication roadmap, dated 27 February 2026, divides the move into four stages. Of the first, adding post-quantum options, it says: "without removing classical options, this does not protect connections from a cryptographically relevant quantum computer (CRQC)." The reason follows: "a CRQC can still compromise the key of any trusted classical CA, forge a certificate, and impersonate the site." The protection arrives only at Stage 3, when a browser accepts post-quantum CAs alone. The roadmap gives no dates for Stages 2, 3 or 4, and calls Stage 4 "far-future".

The label travelling. The words "quantum-safe" appear nowhere in Cloudflare's press release or in the body of either blog post, which say "post-quantum". They appear in the Hacker News bulletin ("quantum-safe digital certificates") and in the title of Google's February post. The words "harvest" and "decrypt later" appear in none of Cloudflare's three documents; we searched all three. The press release does say the CA will support "both traditional encryption and next-generation post-quantum Merkle Tree Certificates", which names a certificate service by the wrong layer. A trade report of 30 September, the Quantum Computing Report, goes further: it says the initiative is meant to "combat" "harvest now, decrypt later" adversary campaigns, and calls the new CA "globally trusted". Neither claim appears in what Cloudflare published. We do not suggest bad faith. The label invites the reading.

The "traditional" half is classical by rule. The new CA will issue both kinds. The classical certificates are RSA or ECDSA because the CA/Browser Forum Baseline Requirements, version 2.3.1 of 4 October 2026, say of key pairs: "No other algorithms or key sizes are permitted." Chrome's February post says it has "no immediate plan" to add post-quantum X.509 certificates to its Root Store. Only the MTC half is post-quantum, and under Chrome's draft policy its signatures are ML-DSA, which NIST's FIPS 204 page says "is believed to be secure, even against adversaries in possession of a large-scale quantum computer". Believed, not proved. NIST's FIPS 204 page also carries a 31 July 2026 note listing minor errata for a future revision.

What the real-traffic evidence covered. Cloudflare's experiment with Chrome served "billions of MTCs" to 50% of Chrome Beta 146, and Cloudflare began winding it down in August 2026. Three details matter. The certificates came from what Cloudflare calls "a fake CA that stubbed the issuance pipeline". Cloudflare says "we tested MTCs with classical signatures", so the post-quantum signature case was not what ran at scale. And Chrome says every MTC connection in the experiment was "backed by a traditional, trusted X.509 certificate". Cloudflare reports MTCs were 9% faster at the median, and adds that "most of this performance benefit is due to intermediate elision". That is encouraging evidence for the design. It is not evidence about post-quantum signatures at Internet scale.

Stated and not stated

The table puts the primary statements beside what none of them says. Where we found nothing, it says "not found" and not "no".

What the primary sources state about Cloudflare's CA, and what they leave out. Read 5 October 2026.

1. Question

   Is the CA issuing?

   Stated on the record

   Cloudflare: "not issuing certificates yet"

   Not stated

   A date for classical certificates; only "following completion" of the programme process

2. Question

   When are MTCs due?

   Stated on the record

   First certificates in Q1 2027 (Cloudflare)

   Not stated

   That any browser trusts them then; Chrome's launch target is Q3 2027

3. Question

   What does GlobalSign hand over?

   Stated on the record

   "Root CA key material" (press release); "an established, broadly trusted root" (blog)

   Not stated

   Which root, the price, whether GlobalSign's business changes; GlobalSign's own account (not found)

4. Question

   Have programmes approved it?

   Stated on the record

   Applications to four programmes, pending

   Not stated

   Any decision; Chrome's separate MTC application

5. Question

   Is MTC a standard?

   Stated on the record

   Internet-Draft 06, 21 September 2026

   Not stated

   An RFC, or a date for one

6. Question

   Do browsers accept MTCs?

   Stated on the record

   Chrome: plan and draft policy. Apple: draft policy due by end of October

   Not stated

   Mozilla: not found. Microsoft: its pilot is not public trust

7. Question

   Does it protect recorded traffic?

   Stated on the record

   Chrome and Cloudflare: key exchange does that, and it is deployed

   Not stated

   Any statement that this CA changes it

8. Question

   Will every client trust the CA?

   Stated on the record

   The acquired root is meant to reach older devices

   Not stated

   Which devices, or any coverage figure

Question	Stated on the record	Not stated
Is the CA issuing?	Cloudflare: "not issuing certificates yet"	A date for classical certificates; only "following completion" of the programme process
When are MTCs due?	First certificates in Q1 2027 (Cloudflare)	That any browser trusts them then; Chrome's launch target is Q3 2027
What does GlobalSign hand over?	"Root CA key material" (press release); "an established, broadly trusted root" (blog)	Which root, the price, whether GlobalSign's business changes; GlobalSign's own account (not found)
Have programmes approved it?	Applications to four programmes, pending	Any decision; Chrome's separate MTC application
Is MTC a standard?	Internet-Draft 06, 21 September 2026	An RFC, or a date for one
Do browsers accept MTCs?	Chrome: plan and draft policy. Apple: draft policy due by end of October	Mozilla: not found. Microsoft: its pilot is not public trust
Does it protect recorded traffic?	Chrome and Cloudflare: key exchange does that, and it is deployed	Any statement that this CA changes it
Will every client trust the CA?	The acquired root is meant to reach older devices	Which devices, or any coverage figure

What the GlobalSign agreement covers, and what trust rules say about it

Cloudflare's press release says it "has agreed to acquire established, publicly trusted Root CA key material from GlobalSign". The blog says "an established, broadly trusted root". Both describe a root and its key, not GlobalSign's business. Neither names the root or gives a price. The blog says the root "has been trusted across browsers, operating systems, and devices since 2012". We found no GlobalSign announcement: its blog, its root pages and the EDGAR feed we read show nothing on the deal, and that feed listed no filing after 23 September, so it cannot tell us whether one exists. The transaction therefore rests on Cloudflare's account. GlobalSign publishes many roots, among them R1, R3, R5, R6, R46 and E46, so the sale could cover any of several. That is a reading, not a statement.

Trust does not travel with the key. All four programmes say so in their own policies.

What the four root programmes' current policies say about a change of ownership or control. Quotation marks are the policy's own words.

1. Programme and policy

   Chrome Root Program Policy 1.8 (5 Feb 2026), 1.6.2

   What it says

   Participants "MUST NOT assume trust is transferable"; the programme "reserves the right to require re-application"

   Notice or approval

   At least 30 calendar days before a sale or change of ownership or operating control

2. Programme and policy

   Mozilla Root Store Policy 3.1 (effective 1 Jul 2026), 8 and 8.1

   What it says

   Operators "SHALL NOT assume that trust is transferable"; a transfer of custody or control of a root's private key triggers a risk evaluation

   Notice or approval

   Notify first. While concerns are unresolved, "MUST NOT issue new subordinate or end-entity certificates"

3. Programme and policy

   Apple Root Program Policy 2.0 (effective 1 Aug 2026)

   What it says

   "Continued inclusion requires Apple approval and is not transferable"

   Notice or approval

   Approval; the acquirer discloses ownership, audit continuity and "plans for managing legacy roots and key material"

4. Programme and policy

   Microsoft Root Program Requirements, 2.1.6

   What it says

   Participants must "inform Microsoft via email at least 120 days before transferring ownership of enrolled root"

   Notice or approval

   120 days' notice

Programme and policy	What it says	Notice or approval
Chrome Root Program Policy 1.8 (5 Feb 2026), 1.6.2	Participants "MUST NOT assume trust is transferable"; the programme "reserves the right to require re-application"	At least 30 calendar days before a sale or change of ownership or operating control
Mozilla Root Store Policy 3.1 (effective 1 Jul 2026), 8 and 8.1	Operators "SHALL NOT assume that trust is transferable"; a transfer of custody or control of a root's private key triggers a risk evaluation	Notify first. While concerns are unresolved, "MUST NOT issue new subordinate or end-entity certificates"
Apple Root Program Policy 2.0 (effective 1 Aug 2026)	"Continued inclusion requires Apple approval and is not transferable"	Approval; the acquirer discloses ownership, audit continuity and "plans for managing legacy roots and key material"
Microsoft Root Program Requirements, 2.1.6	Participants must "inform Microsoft via email at least 120 days before transferring ownership of enrolled root"	120 days' notice

Chrome's draft MTC policy says the same of its new store: "trust in the new operator is not automatically transferred".

The clocks do not line up, and nothing says they must. Notice is 30 days for Chrome and 120 days for Microsoft. Cloudflare's closing window is about two months, roughly 61 days from 29 September. The sources do not say when notice was given, or whether closing is the moment key custody moves. Nothing here shows a breach. It shows that the closing date and the date a browser accepts Cloudflare as the holder of the key are two different dates, and only the second one matters to a relying party.

Root age is the part a reader cannot compute. Chrome removes roots whose key material is more than 15 years old, on a schedule. Mozilla removes the websites trust bit at 15 years from key generation. For key material from 2012 onwards the Chrome dates are these:

Chrome Root Program Policy 1.8, section 1.3.1.2: approximate removal date by when the root's key material was created. Earlier rows are omitted because their dates have passed.

1. Key material created

   1 January 2008 to 31 December 2009

   Approximate removal from the Chrome Root Store

   15 April 2027

2. Key material created

   1 January 2010 to 31 December 2011

   Approximate removal from the Chrome Root Store

   15 April 2028

3. Key material created

   1 January 2012 to 14 April 2014

   Approximate removal from the Chrome Root Store

   15 April 2029

4. Key material created

   After 15 April 2014

   Approximate removal from the Chrome Root Store

   15 years from generation

Key material created	Approximate removal from the Chrome Root Store
1 January 2008 to 31 December 2009	15 April 2027
1 January 2010 to 31 December 2011	15 April 2028
1 January 2012 to 14 April 2014	15 April 2029
After 15 April 2014	15 years from generation

Cloudflare says the root has been trusted "since 2012". That does not give the date its key was generated, which neither company has published, so a reader cannot tell which row applies. Cloudflare's own post names the pressure: the new roots are for "the programs that are starting to cap how old a trusted root may be". Its summary of the design: "The established root gives us reach across the devices of the past. The new roots give us standing under the policies of the future." Chrome, and Mozilla since 1 July 2026, accept new root applications only for keys generated within five years, That is why Cloudflare says it needs both an old root and new ones.

Who has said what about Merkle Tree Certificates

Cloudflare's post says MTCs gained "broad support across the industry". The programme statements we could read show support from Chrome and a draft from Apple. They show nothing from Mozilla, and the only Microsoft post-quantum document we found says its pilot is not for public trust.

What each root programme has published about MTCs, as read on 5 October 2026.

1. Programme

   Chrome (Google)

   What it has said, and when

   27 Feb 2026: "no immediate plan" to add post-quantum X.509 to its Root Store; MTCs instead. FAQ: Phase 2 target Q1 2027 (invited CT log operators), Phase 3 target Q3 2027 (root store launch). Draft policy 0.3.0 of 14 Aug 2026: at least two cosignatures; 7 days maximum for the required issuing key

   Not said

   A decision on Cloudflare; any date to stop trusting classical CAs

2. Programme

   Apple

   What it has said, and when

   21 Sep 2026: draft MTC policy "by the end of October 2026"; applications "by late Summer 2027". Draft expected to require three cosignatures including an ECDSA one, a 7-day validity cap and an annual audit. Policy 2.0 has no MTC text

   Not said

   Any date when MTCs are trusted; a test phase is only a possibility

3. Programme

   Microsoft

   What it has said, and when

   Pilot V1.0, updated 28 Aug 2026: pilot certificates "NOT publicly trusted" and "Will NOT be considered for public trust inclusion by Microsoft"; ML-DSA support "may be unstable"

   Not said

   Any MTC policy; its requirements text does not mention Merkle

4. Programme

   Mozilla

   What it has said, and when

   Root Store Policy 3.1 (1 Jul 2026) mentions neither Merkle nor quantum. We found no statement on MTCs

   Not said

   Anything. Silence is not refusal

Programme	What it has said, and when	Not said
Chrome (Google)	27 Feb 2026: "no immediate plan" to add post-quantum X.509 to its Root Store; MTCs instead. FAQ: Phase 2 target Q1 2027 (invited CT log operators), Phase 3 target Q3 2027 (root store launch). Draft policy 0.3.0 of 14 Aug 2026: at least two cosignatures; 7 days maximum for the required issuing key	A decision on Cloudflare; any date to stop trusting classical CAs
Apple	21 Sep 2026: draft MTC policy "by the end of October 2026"; applications "by late Summer 2027". Draft expected to require three cosignatures including an ECDSA one, a 7-day validity cap and an annual audit. Policy 2.0 has no MTC text	Any date when MTCs are trusted; a test phase is only a possibility
Microsoft	Pilot V1.0, updated 28 Aug 2026: pilot certificates "NOT publicly trusted" and "Will NOT be considered for public trust inclusion by Microsoft"; ML-DSA support "may be unstable"	Any MTC policy; its requirements text does not mention Merkle
Mozilla	Root Store Policy 3.1 (1 Jul 2026) mentions neither Merkle nor quantum. We found no statement on MTCs	Anything. Silence is not refusal

Two features of the picture stand out. The two drafts differ: Chrome's v0.3.0 says MTC CAs are exempt from the Baseline Requirements' annual audit "at this time", while Apple's expected draft would require "An annual audit", and Chrome asks for two cosignatures where Apple expects three. A CA aiming at both must meet both, which is our inference. And Chrome's draft policy says it includes or removes MTC operators "at its sole discretion", and: "Inclusion in the Chrome Root Store does not guarantee admission into the CQRS", nor is it "a prerequisite". The old root helps classical certificates reach old devices. It does nothing for MTC trust.

Cloudflare is not alone. Let's Encrypt wrote on 3 June 2026 that it is "targeting late 2026 for a staging environment that issues MTCs, and 2027 for a production-ready environment". Chrome's test list already shows two other organisations, TrustAsia and Geomys, as test operators.

Draft, not standard: what is final and what is not

We do not claim a standard where there is a draft. The status of each piece on 5 October 2026:

Status of the standards and policies behind the announcement, as read on 5 October 2026.

1. Item

   ML-KEM, FIPS 203

   Status

   Final, 13 August 2024. A planning note of 17 November 2025 says an issue will be corrected in a future revision

   Source and date

   NIST CSRC

2. Item

   ML-DSA, FIPS 204

   Status

   Final, 13 August 2024. Errata note of 31 July 2026

   Source and date

   NIST CSRC

3. Item

   SLH-DSA, FIPS 205

   Status

   Final, 13 August 2024

   Source and date

   NIST CSRC

4. Item

   Hybrid ML-KEM key agreement for TLS 1.3

   Status

   RFC 10024, Proposed Standard, August 2026

   Source and date

   RFC Editor

5. Item

   ML-DSA in X.509 and in TLS 1.3

   Status

   RFC 9881 (Standards Track, October 2025) for X.509. For TLS 1.3, draft-ietf-tls-mldsa-06 is in the RFC Editor queue

   Source and date

   RFC Editor; IETF datatracker

6. Item

   Merkle Tree Certificates

   Status

   Internet-Draft 06 of 21 September 2026, intended status Standards Track. Datatracker: working group document; IESG state "I-D Exists"; expires 25 March 2027

   Source and date

   IETF datatracker

7. Item

   PLANTS working group charter

   Status

   Milestone 30 November 2026: submit a standards document. No submission to the IESG "before demonstrating two interoperable implementations"

   Source and date

   IETF datatracker

8. Item

   Baseline Requirements 2.3.1

   Status

   Key pairs: RSA and ECDSA only; no post-quantum algorithm

   Source and date

   CA/Browser Forum, 4 October 2026

9. Item

   Chrome Quantum-resistant Root Program policy

   Status

   Draft 0.3.0 of 14 August 2026; 22 TODO markers, 20 of them "point to final/latest spec"

   Source and date

   Chrome Root Programs site

10. Item

    Apple MTC policy

    Status

    Not yet published; draft expected by end of October 2026

    Source and date

    Apple Root Program, 21 September 2026

Item	Status	Source and date
ML-KEM, FIPS 203	Final, 13 August 2024. A planning note of 17 November 2025 says an issue will be corrected in a future revision	NIST CSRC
ML-DSA, FIPS 204	Final, 13 August 2024. Errata note of 31 July 2026	NIST CSRC
SLH-DSA, FIPS 205	Final, 13 August 2024	NIST CSRC
Hybrid ML-KEM key agreement for TLS 1.3	RFC 10024, Proposed Standard, August 2026	RFC Editor
ML-DSA in X.509 and in TLS 1.3	RFC 9881 (Standards Track, October 2025) for X.509. For TLS 1.3, draft-ietf-tls-mldsa-06 is in the RFC Editor queue	RFC Editor; IETF datatracker
Merkle Tree Certificates	Internet-Draft 06 of 21 September 2026, intended status Standards Track. Datatracker: working group document; IESG state "I-D Exists"; expires 25 March 2027	IETF datatracker
PLANTS working group charter	Milestone 30 November 2026: submit a standards document. No submission to the IESG "before demonstrating two interoperable implementations"	IETF datatracker
Baseline Requirements 2.3.1	Key pairs: RSA and ECDSA only; no post-quantum algorithm	CA/Browser Forum, 4 October 2026
Chrome Quantum-resistant Root Program policy	Draft 0.3.0 of 14 August 2026; 22 TODO markers, 20 of them "point to final/latest spec"	Chrome Root Programs site
Apple MTC policy	Not yet published; draft expected by end of October 2026	Apple Root Program, 21 September 2026

Two derived points. The charter milestone of 30 November falls 32 days before Q1 2027 begins, so Cloudflare's first MTCs are targeted for a period that opens a month after a standards document is due to be submitted, not published. And the draft's author list names affiliations at Google, Apple, Cloudflare and Geomys. That is how drafts are made, and Cloudflare's press release says it is "Co-authored by Cloudflare". It does mean that agreement among the authors' firms is not agreement among every root programme.

The NCSC expected, in March 2025, that final standards for post-quantum cryptography in TLS were "likely around 2027". Parts have come early: RFC 9881 for ML-DSA in X.509 in October 2025 and RFC 10024 for key exchange in August 2026. ML-DSA in TLS 1.3 is queued at the RFC Editor. The piece Cloudflare is building on, the MTC draft, has not reached the IESG.

The NCSC dates against today

The NCSC's migration timelines give three milestones: by 2028, define goals, "carry out a full discovery exercise" and build an initial plan; by 2031, carry out the "early, highest-priority PQC migration activities" and refine the plan; by 2035, "complete migration to PQC of all your systems, services and products". From 2026, those are two, five and nine calendar years away. Every MTC date in this briefing falls in 2026 or 2027, before the first milestone. A UK organisation finishing its discovery by 2028 will do it after the first MTC issuers exist, if the plans hold. No browser has yet said when it will stop accepting classical certificates.

What the NCSC says about certificates. Its timelines page states: "In general, your system will not provide quantum-secure authentication until migration of your PKI is complete, and traditional certificates have expired or been revoked." That is the same point as Chrome's roadmap, from the UK side: a post-quantum certificate does not protect a connection while a classical one can still be accepted in its place. It adds: "You will be fully secure against the quantum computing threat once you no longer have any sole dependence on traditional PKC."

How current that guidance is. The timelines page was published and reviewed on 20 March 2025, which is 564 days before 5 October 2026. Its sentence on the Web PKI, "There is not yet agreement on how to incorporate post-quantum signatures into WebPKI certificates while maintaining compatibility with traditional WebPKI components", predates Chrome's February 2026 plan and the programme drafts. We found no later NCSC statement on MTCs. The NCSC's TLS guidance, reviewed on 10 December 2025, still lists classical profiles (ECDHE on P-256 for key exchange, ECDSA or RSA-2048 for authentication) and says it will add post-quantum profiles "as the RFCs reach maturity and there is broad enough support". On our reading, a public body following the NCSC's profiles today uses classical certificates. We found no separate government standard for post-quantum certificates in the public sector.

A CDN that is also a CA

A content delivery network becoming a public CA is a commercial and trust-structure change. This section sets down what the sources say, and no more.

Cloudflare's stated reason is concentration at the CA end. The press release says trust "is concentrated in a small number of dominant issuers, creating systemic risk". The blog cites Let's Encrypt as issuing "on the order of ten million certificates a day" and says that if "the dominant free certificate authority had a bad week, much of the web would have no comparable free, automated alternative". Cloudflare says it uses 16 partner CAs today and that the new CA "will add an independent, high-scale issuer".

The same company would hold several roles. Cloudflare says it "sits in front of more than 20 percent of global Internet request traffic and terminates TLS for millions of domains". It already operates CT logs, says it will run mirrors for other pilot CAs, co-authored the MTC draft and ran the experiment with Chrome, and would add a CA. It will be "Customer Zero" of its own CA. It also sells CDN and security services, and its April post tells businesses it recommends "making post-quantum support a requirement for any procurement". We note that without suggesting it is wrong: a vendor's interest and a sound recommendation can coincide.

What the browser rules say. Chrome's draft policy requires every operator to be "completely distinct" from the others, and says an MTC CA operator "MUST NOT condition the acceptance of a certificate request" on the subscriber using the operator's other products, while allowing account requirements for authentication, quotas or abuse prevention if they are open to the public. Cloudflare says it will be ACME-first and that anyone using another free CA "can move to us by changing a directory URL". The sources do not say whether a customer behind Cloudflare will be able to choose another CA for the certificate Cloudflare presents. On the browser side, Chrome decides inclusion "at its sole discretion" and Apple's draft differs from Chrome's, so MTC trust will be set by programmes whose requirements are not yet the same.

A checklist for UK organisations, in the order worth doing

This is our judgement, built from the NCSC's milestones and the vendors' own statements. Items marked NCSC rest on its guidance; the ordering and the rest are ours. The order puts the problem that already has a deployed fix first, because that is where a recorded session is at risk now.

What we could not verify

The question this leaves

The announcement says certificates. The protection that decides whether a recorded session can be read in 2035 is key exchange, and that is already deployed where both ends support it. The protection a certificate gives arrives only when a client stops accepting the old ones, and no one has dated that. For each system you run, can you say today which of those two problems it has, what date you have given each, and who at your CDN, your CA or your vendor has committed to that date in writing?

Key facts