CA/Browser Forum Retires 11 Legacy Domain Validation Methods by 2028

A TLS certificate is only as trustworthy as the domain control validation (DCV) that preceded it. The Chrome Root Program and the CA/Browser Forum have now formalized a multi-year plan to retire the weakest DCV methods still permitted under the Baseline Requirements, via three linked ballots: SC-080, SC-090, and SC-091.

What's being retired

Collectively, the ballots sunset 11 legacy methods spanning three categories: email-based validation (including communication to a domain contact via email, fax, SMS, or postal mail; email to an IP address contact; constructed email to a domain contact; and email via DNS CAA or DNS TXT contact records), phone-based validation (calls to a domain contact, and phone contact via DNS TXT, DNS CAA, or IP address records), and two lookup-based methods — IP address verification and reverse address lookup.

SC-091 specifically targets reverse address lookup validation, proposing a DNS-based replacement using a persistent DCV TXT record for IP addresses, according to the ballot text published by the CA/Browser Forum. SC-090 covers the broader sunset of remaining email-, phone-, and "crossover" validation methods.

Why these methods are weak

Google's post frames the risk plainly: these methods lean on signals that are easy for an attacker to influence or that have simply rotted over time — outdated WHOIS data, fragile phone and email ecosystems, and validation paths tied to inherited or misconfigured infrastructure. If an attacker can intercept a validation email, control a stale WHOIS contact, or manipulate reverse DNS, they can potentially convince a CA they control a domain they don't — and walk away with a valid certificate for it.

This is not a theoretical worry. Weak DCV has been the root cause behind real unauthorized-issuance incidents in the Web PKI over the years, which is part of why the Chrome Root Program has pushed this as a continuation of its 2022 "Moving Forward, Together" roadmap.

Timeline and what changes operationally

The retirement is phased, with full sunset targeted for March 2028 — giving CAs and their customers a multi-year runway rather than a hard cutover. In practice, that pushes issuance further toward DNS-01 and HTTP-01 style validation: proving control by publishing a DNS TXT record or a file at a well-known HTTP path, which are also the methods automated issuance (ACME, short-lived certs) already depends on.

Why this matters for your team

Most security teams treat certificate issuance as a solved, invisible problem — until a validation gap gets exploited to mint a fraudulent cert for a domain they own. If your organization or any downstream vendor still relies on manual, email-based, or phone-based validation workflows with a CA, this is the moment to confirm your renewal process is moving to DNS- or file-based automation before those paths are switched off. It's also a good prompt to check whether WHOIS/registrant contact records on your domains are current — a detail that's easy to let drift and, until 2028, still occasionally load-bearing.

FAQ