Post-quantum authentication for the public web cannot be solved by replacing one signature algorithm inside today’s certificate chain. Cloudflare’s September 29 article, Building a post-quantum certificate authority with Merkle Tree Certificates, describes a different architecture: certificate issuance and transparency are combined so that compact inclusion proofs can replace repeated large signatures in common TLS handshakes.
The announcement is both significant and provisional. Merkle Tree Certificates (MTCs) remain an IETF work item, Cloudflare’s production issuance is targeted for 2027, and browser trust depends on root-program review. Organizations should not record MTCs as a broadly available production capability today. They should study the architecture because it changes what must be inventoried and governed in a post-quantum WebPKI.
Authentication has a scaling problem
Hybrid post-quantum key agreement is already reaching mainstream TLS traffic, but server authentication is harder. Classical WebPKI distributes trust through certificate chains, with certificate-transparency records, revocation mechanisms, and multiple signatures layered around them. Post-quantum signatures are much larger than common classical signatures. Replacing each classical signature one-for-one would increase handshake and logging costs throughout browsers, servers, certificate authorities, monitors, and network paths.
MTCs aim to change that scaling equation. A certificate authority batches certificate records into an append-only Merkle tree and signs a tree checkpoint. A client verifies that a server’s certificate information is included in the trusted tree using a compact sequence of hashes. In a landmark-based mode, clients receive authenticated tree information through an out-of-band update, allowing the live handshake to carry a lightweight proof.
This is more than certificate compression. It moves transparency into the trust path. Issuance, logging, mirroring, cosigning, client updates, inclusion proofs, and proof-of-possession all become interdependent controls.
A certificate inventory will need new relationships
Traditional certificate inventories focus on domain, issuer, serial number, public-key algorithm, validity period, chain, and expiration. Those fields remain useful, but an MTC-aware inventory would also need to identify the issuance log, checkpoint, cosigners, mirror state, landmark or standalone proof, client root-program policy, and fallback certificate.
That relationship model is essential for incident response. If a log presents inconsistent views, a cosigner becomes unavailable, a root policy changes, or a landmark update is stale, teams need to identify which domains, clients, and services depend on the affected path. Searching only for an algorithm name will not answer those questions.
The fallback path deserves equal attention. Cloudflare’s experiment used classical certificate chains when a client could not negotiate a landmark-relative MTC. Fallback preserves compatibility, but it can also preserve a quantum-vulnerable authentication path. A future policy must distinguish an authorized compatibility fallback from an unexpected downgrade.
Transparency monitoring becomes a migration control
Cloudflare notes that certificate transparency monitoring will matter during the transition because a domain owner that expects post-quantum authentication should detect unexpected legacy issuance. That is a concrete example of evaluation based on observed state rather than declared intent.
A useful control would compare approved domain policy with:
- the certificate or MTC actually presented to different client populations;
- the issuance records present in recognized logs;
- the negotiated authentication and key-establishment mechanisms;
- the root program and policy version applied by each client class;
- the fallback behavior observed during ordinary and degraded operation; and
- the owner and exception attached to any classical-only path.
That comparison should be continuous. Certificates renew, browser policies change, clients age, and services move between platforms. A migration plan based on a one-time spreadsheet will miss the very state changes that create downgrade exposure.
What organizations should do next
First, separate confidentiality from authentication in the TLS inventory. A service may negotiate hybrid ML-KEM for key establishment while still authenticating with RSA or ECC. Recording only “PQC enabled” obscures the remaining work.
Second, map the current WebPKI dependencies: certificate authorities, ACME accounts, validation methods, CT monitors, root stores, proxies, CDNs, load balancers, application servers, and client populations. Include unmanaged and embedded clients that may retain classical-only behavior for years.
Third, define evidence for any MTC pilot. Preserve the draft version, CA, browser build, root policy, log and cosigner identities, proof mode, fallback outcome, performance result, and test date. A successful experiment is evidence for that configuration, not proof of general readiness.
Finally, watch standards and root programs rather than relying on vendor timelines alone. Cloudflare’s article names unresolved ecosystem questions, including monitor scalability, diversity among CAs and cosigners, and how clients should balance compact landmarks with fallback availability.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—helps teams connect certificates, protocols, algorithms, assets, owners, policies, and migration evidence.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not issue MTCs, generate PQC keys, or perform every migration step. Selected-asset Active Scan is targeted rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and an incomplete discovery result is not proof that a fallback or certificate is absent.
See Vista’s post-quantum transition guidance for a broader view of migration planning.
Where uncertainty remains
MTCs are not yet a universal production replacement for classical certificates. The specification, root policies, issuer ecosystem, monitoring model, and client support can still evolve. Cloudflare’s own schedule is forward-looking. The useful action today is to prepare an inventory capable of expressing the new trust relationships and to require scoped evidence before treating any post-quantum authentication path as complete.
Source
- Building a post-quantum certificate authority with Merkle Tree Certificates, Cloudflare, September 29, 2026.