The CA/Browser Forum in 2026: How Browser Root Programs Actually Set TLS Certificate Policy

Browser root programs at Chrome, Apple, and Mozilla set public TLS certificate policy. The CA/Browser Forum codifies their decisions. CAs get one vote each, browser root programs get one vote each, but if Chrome or Apple drops your root from their store, your business stops working that quarter regardless of any ballot. According to ballot history from 2019-2025, every major policy change started as a unilateral browser announcement before the forum ratified it.

This piece walks through how we got here, what it means for engineers managing certificate fleets, and what to read instead of the baseline requirements if you actually want to predict the next eighteen months.

The Polite Fiction of the CA/Browser Forum

The CA/Browser Forum is a voluntary consortium where CAs and browser root programs co-author the baseline requirements governing publicly trusted TLS issuance. On paper it's two chambers voting in parallel. In practice browsers hold veto power because they own distribution.

Ballot mechanics from the last five years show the pattern:

• SC-063 (max validity to 398 days, passed 2020 after Apple's unilateral move): CAs largely abstained or voted no, browsers carried it.
• SC-067 (precertificate linting, 2022): broad CA support because Chrome would have enforced linting unilaterally otherwise.
• SC-081v3 (staged reduction to 47-day max validity by March 2029): passed April 2025 with every browser voting yes and a meaningful chunk of the CA bloc abstaining.

According to ballot records, browsers signal, CAs comply or face distrust risk, and the ballot codifies the result. The captured-regulator framing fits better than the balanced industry body framing in the bylaws. We covered the operational fallout in the 47-day certificate timeline and the SC-081v3 field guide.

Key takeaway: when CA/Browser Forum ballots pass, they reflect a decision the browser root programs already made. Reading the ballot is backwards-looking. Reading the root program roadmaps is forward-looking.

Five Years of Browsers Tightening the Screws

Browser root programs have driven every major TLS policy change since 2019 through a unilateral-then-ratified pattern. Each move started with a browser announcement, triggered a CA scramble, and ended with the CA/Browser Forum publishing what the browser had already decided. Treat this as enforcement history, not standards work.

Condensed timeline of browser-driven moves:

Date	Browser action	Outcome
2017-2018	Mozilla and Google distrusted Symantec's PKI	Affected ~30% of public web certificates
June 2019	Chrome removed the EV UI (green address bar)	Validity-tier marketing collapsed within a year
February 2020	Apple announced 398-day max validity at the Bratislava F2F	Ratified as SC-063 a year later
September 2021	Apple's CT log policy rejected non-compliant logs in Safari	Forced log operators into stricter availability
June 2024	Chrome announced distrust of Entrust roots after Nov 11, 2024	Apple followed in December 2024
April 2025	SC-081v3 passed, locking 47-day floor by March 2029	Apple proposed the floor

Every one of these started outside the CA/Browser Forum. The forum codified the outcome. CAs who pushed back publicly (Entrust on misissuance threads, multiple CAs on the original 398-day proposal) found that pushback didn't change the outcome and may have damaged their root program standing.

The throughline: browsers can and will move alone. Root store policy moves faster than baseline requirements. If you build automation around the floor instead of the trajectory, you'll re-architect on someone else's schedule.

What CAs Actually Compete On Now

CAs compete on API quality, ACME completeness, enterprise contract terms, and compliance hygiene. Validity periods, validation methods, OCSP behavior, and revocation timelines are dictated by root programs, so the CA product surface has shrunk dramatically. Pricing alone won't save a CA whose root program standing is shaky.

The market has split into two viable shapes:

• Cheap, automated, ACME-native: Let's Encrypt, ZeroSSL, Google Trust Services, Buypass. Free or near-free. ACME or nothing. No human support. Let's Encrypt issues north of 60% of publicly trusted certificates by volume in 2025 by most measurements.
• Expensive, enterprise-supported: DigiCert, Sectigo, GlobalSign, IdenTrust. Account managers, custom validation workflows, compliance attestations, private PKI offerings. EV certificates sold as a SOC 2 line item, not a browser UI feature.

The middle ground (paid commodity DV with light support) got squeezed out. Browsers killed the differentiators that justified the markup. Let's Encrypt's dominance isn't a story about price — it's a story about ACME being the only API worth integrating against when the product is a commodity.

EV certificates are a compliance artifact. The browser UI is gone, so the user-facing value is gone. But certain compliance frameworks (PCI scoping for some banks, government procurement clauses, contractual security requirements) still call out EV by name. CAs sell them as a documentation requirement, not a security feature. More CAs should adopt that framing publicly.

For practical context, the ACME protocol guide covers what good API quality looks like in production, including the rate limits and challenge edge cases that separate a well-run CA from a frustrating one.

The Entrust Case Study: What Happens When a CA Loses the Room

The Chrome Root Program distrusted Entrust roots for certificates issued after November 11, 2024, announced on June 27, 2024. Apple followed in early December 2024. Entrust subsequently partnered with SSL.com to keep serving its enterprise customers via SSL.com's roots. This is the cleanest 2020s example of root program power being exercised.

The technical trigger was a sequence of compliance failures documented in Mozilla's Bugzilla. According to the Chrome Root Program's June 2024 announcement, each item alone wouldn't have been fatal:

• Multiple misissuances of EV certificates with incorrect organization validation, including domain controls that failed CA/Browser Forum baseline requirements.
• Delayed revocations past the five-day window mandated for material misissuance, including some past 30 days.
• An incident report cycle the Chrome Root Program described as "frequent disregard for the responsibilities laid out in the Chrome Root Program policy."
• Pushback on remediation suggestions during public Bugzilla threads, including arguments about whether certain certificates needed revocation at all.

Read the Chrome Root Program's announcement closely. The language emphasizes pattern and posture: "patterns of concerning behaviors," "failure to follow through," "perceived inability or unwillingness to embrace the changes." Root programs explicitly weigh CA behavior in incident response, not only the underlying errors.

The lesson for any CA: how you respond on Bugzilla matters as much as the technical correction. Slow responses, defensive posture, or arguments against revocation accumulate. When the root program writes the distrust announcement, those threads become the evidence. The Entrust distrust was a process outcome, not a single incident.

For engineers, the operational implication is simpler: if your CA gets distrusted, you have weeks to migrate, not months. Building a CA-agnostic certificate automation pipeline is the only way to absorb a distrust event without an outage.

What This Means for Engineers Managing Certs

Track the Chrome Root Program roadmap, the Mozilla CA policy mailing list, and Apple's Platform Security guides — not the CA/Browser Forum baseline requirements. These root program sources publish intent months before any ballot. If browsers are the regulator, baseline requirements are the wrong document for forward planning.

Practical reading list, ranked by signal-to-noise:

• Chrome Root Program policy (g.co/chrome/root-policy): the moving roadmap. Updates announce direction before ballots are drafted.
• Mozilla dev-security-policy (mailing list and Bugzilla CA Program component): public CA incident discussion. Distrust precursors show up here first.
• Apple Platform Security guide and CT log policy pages: Apple publishes less often but moves first when it does.
• CCADB (Common CA Database) public reports: the authoritative source for which roots are in which programs.
• CA/Browser Forum ballots: useful for historical record. Almost never useful for predicting the next move.

Concrete operational guidance:

• Validity caps will keep dropping. Build renewal automation that works at the lowest published cap minus a safety margin. With SC-081v3 codified, that's 47 days by March 2029, with intermediate cuts to 200 days in March 2026 and 100 days in March 2027.
• Validation will keep tightening. Multi-perspective issuance corroboration is mandatory for CAs as of March 2025. Expect more.
• Revocation timelines will keep shrinking. The five-day revocation window for material misissuance is already short; ballots in the next two years are likely to address shorter windows for certain failure types.
• Maintain CA portability. If migrating off your current CA would take more than two weeks, you're carrying CA-specific risk you don't need.

Renewal cadence: if you're still renewing at 30 days remaining, move it to 14 days remaining and run the change through staging at 7. At 47-day lifetimes, the 30-day mark is two-thirds of the certificate's life. That's not a renewal trigger, it's an early reissue. Pair this with proper certificate monitoring that catches deployment gaps, not just expiry.

Where This Goes Next

Three changes are close to locked in for 2026-2029: validity continues dropping on the SC-081v3 schedule, post-quantum signature algorithms become mandatory once FIPS 203/204/205 are stable in browser code, and multi-perspective validation tightens further. Industry data indicates a major CA distrust between now and 2028 is more likely than not.

Specific predictions with reasoning:

• 47-day max by March 15, 2029: locked. SC-081v3 staged the reductions — 200 days in March 2026, 100 days in March 2027, 47 days in March 2029. No realistic path to delay short of a coordinated CA challenge that hasn't materialized.
• Post-quantum certificate mandates between 2027 and 2028: NIST finalized FIPS 203 (ML-KEM), 204 (ML-DSA), and 205 (SLH-DSA) in August 2024. Chrome and Cloudflare have shipped hybrid key exchange for TLS handshakes. Certificate signing follows once browser code paths and CA HSMs catch up. Expect a Chrome Root Program proposal first.
• Multi-perspective domain validation as a hard floor: already in effect for CAs since March 2025. Expect refinement to the number of perspectives and geographic distribution requirements by 2027.
• Tighter CT log policy: one Apple-qualified log and one Google-qualified log is the current floor. The number could rise, and the log operator certification bar will keep climbing.
• At least one major CA distrust by 2028: the CAs to watch are those with growing issuance volume and thin compliance orgs. Misissuance incidents scale with issuance volume; compliance maturity does not.

The forcing function is automation maturity. Browser root programs have stated explicitly that shorter lifetimes are intended to compress the impact of misissuance and force automation. Once 47-day lifetimes are the floor, manual renewal isn't viable for anyone running more than a handful of certificates. That's the point.

FAQ

Who really controls public TLS certificate policy? Browser root programs control TLS certificate policy — primarily Chrome, Mozilla, and Apple. The CA/Browser Forum codifies decisions, but the substantive policy direction is set in the root program roadmaps. CAs participate in the forum but have limited ability to block browser-driven changes.

What happened with Entrust in 2024? The Chrome Root Program announced on June 27, 2024 that it would distrust Entrust roots for certificates issued after November 11, 2024. Apple followed in December. The cause was a pattern of misissuances, late revocations, and a Bugzilla response posture the root program judged inadequate. Entrust partnered with SSL.com to continue serving customers.

What is SC-081v3 and when does it take effect? SC-081v3 is the CA/Browser Forum ballot that staged a reduction in maximum TLS certificate validity from 398 days to 47 days. The schedule is 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029. It passed in April 2025 with all browsers voting yes.

Why does Let's Encrypt have so much market share? ACME automation. When browsers commoditized DV certificates by killing UI differentiation and capping validity, the API became the product. Let's Encrypt shipped a clean ACME implementation, kept the price at zero, and didn't try to sell support. As of 2025 it issues north of 60% of publicly trusted certificates by volume.

Should I still buy EV certificates? Only if a compliance framework or contract specifically requires them. Browsers stopped displaying EV identity in the UI in 2019. The technical security difference is negligible. If your auditor or customer contract names EV explicitly, buy them. Otherwise the money is better spent on automation.