Apple Joins the Merkle Tree Certificate Consensus – and Raises the Bar

September 21, 2026 – The Apple Root Program has published its first post-quantum cryptography policy position, announcing two parallel changes to the way Apple’s operating systems will handle digital certificates. The first establishes a new policy for Merkle Tree Certificates (MTCs) in TLS server authentication. The second amends the existing Apple Root Program Policy to accept traditional X.509 root CA certificates with composite algorithms for S/MIME secure email.

The announcement, posted by Apple’s Dustin Hollenback to the Chromium Certificate Transparency policy mailing list, states that Apple expects to publish a draft MTC policy by the end of October 2026 in the Apple Root Program’s GitHub repository, followed by a public feedback survey.

TLS: Merkle Tree Certificates with three cosignatures. Apple frames the rationale in bandwidth terms. Post-quantum certificate chains are roughly an order of magnitude larger than the classical chains they replace, Apple states, because TLS handshakes typically contain five signatures and two public keys. The Root Program cites experiments with ML-DSA signatures in traditional X.509 hierarchies that showed “significant degradation of TLS handshakes in real-world deployments.”

The draft Apple Root Program MTC policy is expected to require:

• Three cosignatures per certificate: an ML-DSA cosignature (minimum ML-DSA-44) and a classical cosignature (minimum ECDSA-P256-SHA256), both from the issuing Operator, plus an ML-DSA cosignature (minimum ML-DSA-44) from a different Operator acting as a mirror.
• All cosigner keys in hardware security modules validated to FIPS 140-3 Level 3 or Common Criteria EAL 4+.
• Operators to register Private Enterprise Numbers (PENs) with IANA to serve as the basis for Trust Anchor Identifiers.
• Certificate validity capped at seven days.
• An annual audit.
• Operators to publish “far more non-private operational detail, including a record for every domain validation.”

Apple expects to begin accepting applications from MTC CA Operators by late summer 2027.

S/MIME: composite X.509 with classical and PQC algorithms. For secure email, Apple is taking a different path. Apple notes that S/MIME has lower certificate issuance volume and less latency sensitivity than TLS, so the increased certificate size from post-quantum signatures is “less disruptive to the existing X.509 ecosystem.” The policy amendment will allow signing traditional X.509 certificates with composite algorithms combining ML-DSA with ECDSA or RSA. Apple describes this as a dual-assurance model. ML-DSA provides security against quantum attacks, and the ECDSA or RSA component uses algorithms with decades of deployment experience.

My Analysis

Chrome, Let’s Encrypt and Now Apple

Until September 21, two institutions had backed Merkle Tree Certificates for the public web: Chrome, which proposed the architecture with Cloudflare in February 2026 and is building a Chrome Quantum-resistant Root Store targeted for Q3 2027, and Let’s Encrypt, which committed to MTCs in June 2026 with production issuance targeted for 2027. Apple’s announcement makes it three.

Apple’s root program controls the trust store on every Apple device in the world, including iPhone, iPad, and Mac. Chrome and Apple – the two root programs that cover the dominant share of consumer devices – plus Let’s Encrypt, the web’s largest certificate authority, have all committed to MTCs. The practical question for certificate authorities and organizations is no longer whether MTCs are the direction for public web PKI. Certificate authorities now have to build MTC infrastructure in time for Chrome’s quantum-resistant root store, targeted for Q3 2027, and for the operator applications Apple will begin accepting in late summer 2027. Mozilla, the fourth major browser root program, has not announced an MTC commitment as of September 2026.

The IETF PLANTS working group’s MTC specification reached revision 06 on September 21, 2026 – the same day as Apple’s announcement – and remains an Internet-Draft rather than an RFC. Apple is already a co-author on the PLANTS draft through Devon O’Brien, so the Root Program policy is a formal institutional commitment on the back of direct specification work. That gap between institutional commitment and standards finalization is now a first-order scheduling risk. Two root programs and the web’s largest certificate authority have committed to build against a specification that is not yet final.

Apple’s Requirements Go Beyond Chrome’s

Apple did not simply adopt the Chrome model. Reading Apple’s expected requirements against Chrome’s CQRP v0.3.0 (dated August 14, 2026) shows where the two root programs align and where Apple goes further.

Three cosignatures, and an ECDSA attestation Chrome does not require. CQRP v0.3.0 requires a minimum of two cosignatures per certificate – one from the issuing operator and one from an independent mirroring cosigner. Apple expects to require three: an ML-DSA cosignature (minimum ML-DSA-44) and a classical cosignature (minimum ECDSA-P256-SHA256), both from the issuing Operator, plus an ML-DSA cosignature (minimum ML-DSA-44) from a different Operator acting as a mirror. Chrome’s CQRP requires all cosigner keys to be ML-DSA-44. Apple’s addition of an ECDSA cosignature from the issuing operator means every MTC carries both a post-quantum and a classical attestation at the operator level – hybrid assurance applied to issuance infrastructure, not to the certificate itself. TrustAsia filed the first visible Chrome test-operator application on July 24, publicly reported in early August. Apple’s three-cosignature requirement will demand a deeper pool of qualified mirror operators than Chrome’s minimum of two.

Seven-day certificate validity, uniform. Chrome already sets seven-day maximum validity on its required ML-DSA-44 CA cosigner key, though it permits up to 47 days on optional additional keys. Apple’s draft caps all MTC certificates at seven days and makes no allowance for longer validity. The operational implication is the same for both root programs: MTC infrastructure must function as a near-continuous issuance and distribution pipeline. Any disruption longer than seven days breaks certificate validation for MTC-dependent sites. For comparison, the CA/Browser Forum’s Ballot SC-081v3 reduces maximum traditional TLS certificate validity to 47 days by March 2029.

FIPS 140-3 Level 3 for all cosigner keys, with no grace period. Both Apple and Chrome require CA cosigner keys in hardware security modules validated to FIPS 140-3 Level 3 or Common Criteria EAL 4+. Chrome makes HSMs optional for mirroring cosigner keys; Apple’s announcement applies the Level 3 requirement to all cosigner keys, including mirrors. Chrome’s CQRP also provides a CAVP bridge: HSMs with Level 3 hardware validation and CAVP-certified ML-DSA may be used until January 1, 2029, when full CMVP certification becomes mandatory. Apple’s announcement does not mention a comparable grace period. Early software modules like CMVP #5247 (Go Cryptographic Module, Level 1) have achieved FIPS 140-3 validation for ML-KEM, and a small number of hardware vendors began completing Level 3 PQC validations in mid-2026 – Thales TCT’s Luna T7 (CMVP #5450, announced July 29) and Crypto4A’s QASM (CMVP #5497, announced August 20) are the first Level 3 HSMs with ML-DSA as an approved service. That supply is still thin relative to the number of CAs that will need to equip for Apple’s and Chrome’s operator requirements.

Annual audit required. Chrome’s CQRP v0.3.0 exempts MTC CAs from annual third-party audits, on the grounds that current audit criteria are designed for X.509 architectures. Apple requires an annual audit. CAs that intend to operate as MTC operators under both root programs will have to undergo that audit.

IANA PEN registration for Trust Anchor Identifiers. This is an identity mechanism for MTC operators, tying each operator to a publicly registered identifier rather than relying on X.509 naming conventions. Chrome’s CQRP does not include this requirement. It is a transparency measure: anyone can look up the PEN registry and confirm which organization stands behind a given trust anchor.

Domain validation records published. Apple’s requirement that operators publish “a record for every domain validation” goes further than both current Certificate Transparency and Chrome’s CQRP, which tightens domain validation methods and caps reuse at 10 days but does not require publishing the validation records themselves. If implemented as described, MTC issuance would be more transparent than any certificate system I know of at this scale.

Separate Paths for TLS and S/MIME

Apple’s announcement is the clearest statement yet that the post-quantum PKI fork I have been tracking splits not only by estate (public web versus internal) but by protocol.

For TLS, the bandwidth and latency constraints make traditional X.509 chains with ML-DSA signatures impractical at internet scale. Google and Cloudflare measured authentication overhead at roughly 15 KB in a naive post-quantum handshake; Apple’s own experiments confirmed the degradation in real-world deployments. MTCs solve this by amortizing a single post-quantum signature across thousands of certificates and delivering compact inclusion proofs instead of full signature chains.

For S/MIME, none of those constraints apply with the same force. Email certificates are issued in lower volumes and are not exchanged in latency-sensitive handshakes, and the recipient verifies a signature at their own pace, not under a TCP timeout. Apple’s decision to use composite algorithms – ML-DSA plus ECDSA or RSA in a single certificate – is the straightforward X.509 path that hybrid cryptography advocates have been recommending. The composite model gives post-quantum security and classical fallback in one object, with no new infrastructure required beyond algorithm support in the issuing CA and the verifying client.

This split matches the planning model in my PQC Migration Framework: public-facing web infrastructure tracks MTC on the root programs’ timelines, while non-web PKI (including S/MIME, internal mTLS, and code and document signing) proceeds on X.509 with post-quantum or composite algorithms now. Apple’s policy draws the line in the same place.

What This Means for Organizations

The planning fork is settled. Act on it. Chrome and Apple – the root programs behind the dominant share of consumer browsers and devices – have committed to MTCs for TLS, and Let’s Encrypt, the web’s largest certificate authority, has chosen the same path. No major root program has announced plans to add traditional X.509 certificates with post-quantum algorithms to its public TLS trust store. The direction is decided. Organizations that planned their public web PKI migration as a straightforward algorithm swap inside X.509 need to revisit that plan.

Certificate automation is now non-negotiable. Seven-day MTC validity on Apple platforms, 47-day maximum traditional certificate validity under SC-081v3 by 2029, and the probability that Chrome’s MTC requirements will converge on similarly short validity periods mean that manual certificate management cannot keep up for public-facing infrastructure. ACME-based automation is the minimum investment. Organizations that have not begun automating their certificate lifecycle are already behind.

Ask your CA about its Apple MTC roadmap. In late summer 2027, Apple will begin accepting operator applications. The CAs that serve your public web infrastructure need to be ready. Add “Apple MTC Operator application status” to the vendor questionnaire alongside the Chrome CQRP questions. Any CA that cannot answer both is not planning for the web your browsers will run.

HSM procurement must account for ML-DSA validation. Apple’s FIPS 140-3 Level 3 requirement for cosigner keys, combined with the current validation gap, means that the HSM procurement cycle and the MTC operator application cycle are now coupled. Start the HSM conversation with your vendor now, not when Apple publishes the draft policy in October.

S/MIME and email security teams have a clearer, shorter path. Apple’s composite-algorithm position for S/MIME means organizations can begin planning post-quantum email security using existing X.509 infrastructure, pending CA and client support for composite profiles. The IETF profiles for pure ML-DSA in X.509 (RFC 9881) and CMS (RFC 9882) are published. The composite ML-DSA profiles Apple’s S/MIME policy will require – combining ML-DSA with ECDSA or RSA in a single cryptographic structure – are nearing completion as IETF LAMPS working-group drafts. Issuing-CA and email-client support for those composite profiles is the remaining dependency.

The MTC Timeline Through 2028

Six months ago, Merkle Tree Certificates were a promising architecture with Chrome and Cloudflare testing it against real-world traffic. Three months ago, Let’s Encrypt committed, and TrustAsia filed the first Chrome test-operator application. On September 21, Apple announced its own MTC policy that aligns with Chrome on the core architecture while going further on cosignature count, HSM scope, audit, and transparency. The Google Cloud PQC Roadmap published in August marks Google Trust Services’ MTC support for 2028.

The institutions are lining up. The timelines are converging on 2027 for initial operator acceptance and 2028 for meaningful production deployment. The MTC specification is still an Internet-Draft at revision 06. Few Level 3 HSMs offer ML-DSA as an approved service, and CAs are just beginning to file test applications. Organizations with public web infrastructure need to track each of those gaps as a scheduling constraint and plan around it.

The post-quantum PKI transition for the public web runs on the root programs’ schedule. Apple just made that schedule more concrete and more demanding.