SC-098v2: CAs must honor CAA accounturi and validationmethods

SC-098v2 makes the fine-grained part of CAA enforceable. From 2027-03-15, every publicly trusted CA must honor the RFC 8657 parameters accounturi and validationmethods, so a CAA record can name one account at a CA and require DNS validation, rather than only naming the CA.

What changed

SC-098v2 makes CAs process the two RFC 8657 parameters from 2027-03-15. RFC 8657 (2019) added them to CAA, but the Baseline Requirements only said CAs should process them. The ballot text explains that their value is only realized if CAs process them rather than ignore them. CAs that don't identify subscriber accounts by an ACME account URL must define the accounturi format they support in their CP/CPS. Validation methods outside the IANA ACME registry are named ca-tbr- plus the BR 3.2.2.4 subsection number, for example ca-tbr-7 for method 3.2.2.4.7. ACME CAs may let a "parent" account authorize several subordinate accounts. The ballot also consolidated the CAA rules in §4.2.

Effective dates

The ballot passed on 2026-05-13 and the BR text took effect on 2026-06-16. The processing requirement applies from 2027-03-15.

Who is affected

SC-098v2 matters to domain owners who want stronger protection than a plain issue record, and anyone who already publishes these parameters: a record like the one below will start blocking every other account and method at that CA.

example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456; validationmethods=dns-01"

What to do

Before 2027-03-15, audit your CAA records. If you add accounturi, use the exact account URL of every ACME client that renews for the domain, or renewals from other servers will fail. Build and check records with the CAA generator and CAA checker; the basics are in Ballot 187.