Every Public CA Must Support Certificate Automation by March 2027

What changes on March 15, 2027

From that date, every unexpired and unrevoked subordinate CA signed by a root in the Chrome Root Store must be integrated with an automation solution. The policy states the practical effect directly: every TLS server authentication certificate profile offered by a subordinate CA trusted in Chrome must be capable of being issued and renewed using automation. Not the popular profiles, not the cheap ones — every profile the CA sells.

Around that core requirement sit three disclosure obligations that make it enforceable rather than aspirational. A CA has to attest in the CCADB, on the root certificate record, that the requirement is met for each Baseline Requirements certificate policy OID its hierarchy issues. It has to disclose at least one automation solution for each of those OIDs where unexpired subscriber certificates exist. And for each OID it has to issue what the policy calls Automation Test Certificates, using a disclosed automation solution, to demonstrate the capability actually functions.

Those test certificates are the part that turns an attestation into evidence. They must be renewed at least once every 30 calendar days, and the Chrome Root Program reserves the right to demand more frequent renewal at any point. At least one valid test certificate per certificate policy OID has to be served by a publicly accessible website whose URL is disclosed in the CCADB on the corresponding intermediate record. In other words, anyone can go and look at whether a CA’s automation is alive.

March 15, 2027 is a busy date because two separate rule-making bodies picked it. The 100-day maximum lifetime comes from CA/Browser Forum Ballot SC-081v3, the same schedule that cut lifetimes in March 2026 and lands on 47 days in March 2029. The automation requirement comes from Chrome. They are independent documents that happen to converge, and the effect is coherent whether or not it was coordinated: shrinking lifetimes without guaranteeing automation would have pushed the whole cost onto subscribers.

The third item in that 2027 row is a separate change worth knowing about on its own terms: from the same date, subscriber certificates must carry the extended key usage extension and assert only server authentication. The clientAuth EKU removal covers what that does to mutual TLS setups relying on public certificates.

Does this mean you have to automate?

No. The requirement binds certificate authorities, not the people who buy certificates. The policy is unusually explicit about it, spelling out that the rules neither prohibit hierarchies from also supporting non-automated issuance and renewal, nor require website operators to rely on the automation solution for issuance and renewal. Your manual workflow remains valid on March 16, 2027.

What changes is that the excuse disappears. Until now, a perfectly reasonable answer to “why do you still renew that certificate by hand?” was that the CA offered no API for that product, or offered one only for DV, or offered one that needed a support ticket to enable. From March 2027 a publicly trusted CA cannot give that answer and stay in the Chrome Root Store.

Whether you take up the offer is a scheduling question, and the shrinking lifetimes answer it for most estates. A 100-day certificate needs replacing roughly four times a year; planning for shorter certificate lifetimes walks through what that does to a renewal calendar and where manual processes tend to break first.

What a compliant ACME endpoint must support

If a CA meets the requirement with ACME, the policy names exactly what the endpoint has to do. It must disclose at least one directory URL to the Chrome Root Program for each Baseline Requirements certificate policy the hierarchy issues — IV, DV, OV and EV — and each endpoint must support five RFC 8555 operations: newAccount, newNonce, newOrder, keyChange and revokeCert.

Two further standards come with it. The issuing CAs behind each endpoint must support the CAA record extensions in RFC 8657, which let a domain owner pin issuance to a specific ACME account and restrict which validation methods are acceptable. And any hierarchy supporting ACME must support ACME Renewal Information, RFC 9773, so the CA can tell clients when to renew rather than leaving each client to invent its own schedule.

One precision that is easy to lose: ACME itself is a SHOULD, not a MUST. The policy says PKI hierarchies should support ACME, then makes the list above mandatory for any hierarchy that does. What is genuinely mandatory is automation — the protocol used to deliver it is where the flexibility lives. A couple of items stay recommendations, including support for the emerging ACME Profiles extension and keeping endpoints publicly accessible on a 24x7 basis.

If you already run ACME against a free CA, none of this changes your tooling. Certbot and ACME in production covers the client side, and the same client speaks to a commercial directory once you have account credentials for it.

What if your CA does not use ACME?

The policy allows other automation solutions, but sets the bar high enough that the result has to behave like an ACME client. A non-ACME solution is defined as the combination of the CA’s issuance interface and client software the CA itself provides and maintains. That client must generate a new key pair for every request by default, generate and submit the CSR, complete domain validation with no hands-on input, and retrieve the issued certificate automatically.

The permitted validation methods are named rather than left open: DNS Change, or Agreed-Upon Change to Website v2, from the Baseline Requirements. The solution also has to support features comparable to RFC 8657 for restricting issuance to specific accounts and validation methods, support or request revocation, and provide something comparable to ARI. Automated deployment of the issued certificate is encouraged but not required.

The real cost of this route is procedural. A CA taking it has to describe its solution publicly in the CCADB for every certificate policy OID it issues, explaining how a subscriber can actually use it, and complete an Automation Solution Assessment form obtained from the Chrome Root Program. Pointing at a published RFC is cheaper than documenting and defending bespoke client software, which is a reasonable guess at why most CAs are converging on ACME.

Can OV and EV certificates really be automated?

Yes, with one carve-out the policy states explicitly. Routine issuance and renewal should not involve human input except as needed for identity or business document verification related to IV, OV or EV issuance. The organisation vetting stays a human process; the certificate operations wrapped around it do not. That single sentence is what makes an automation requirement covering EV coherent at all.

Mechanically it works because the two halves are separated in time. A CA validates your organisation once, stores that validation for as long as the reuse rules permit, and the automated endpoint then issues against the stored validation without anyone re-reading your incorporation documents. On the ACME side, the link between your paid, vetted order and the ACME account is made with External Account Binding — the CA hands you a key identifier and an HMAC key, and your client signs its registration with them.

This is where the requirement bites hardest in practice, because it is exactly the case that has historically been unavailable. Plenty of buyers of organisation validated certificates have ended up back in a web portal because the CA’s ACME endpoint only handled DV. From March 2027 that gap is a compliance problem for the CA rather than a fact of life for the customer.

One caveat worth carrying into any pilot: the identity validation you are reusing does not last forever, and SC-081v3 shortens reuse periods for subject identity information alongside everything else. Automation removes the per-issuance paperwork, not the periodic re-vetting. Running cert-manager against a commercial CA shows the External Account Binding configuration end to end, including what happens when an organisation has not been pre-validated.

How Chrome enforces it

Chrome enforces this the same way it handles every other phase-out: with an SCTNotAfter constraint on the root. Beginning March 15, 2027, a hierarchy found issuing new certificates under a Baseline Requirements certificate policy OID that lacks an automation attestation in the CCADB gets phased out, and the phase-out date is set to 90 calendar days after the violation is detected.

The mechanism is gentler than the word “distrust” suggests, and understanding it is the difference between calm and panic if your CA ever lands on the wrong side of it. A phase-out sets a date and time. TLS server authentication certificates issued on or before that moment stay trusted in Chrome until they expire. Certificates issued after it are not trusted by default. The root itself is removed from the Chrome Root Store only once no unexpired, unrevoked certificates issued before the phase-out date remain.

So a compliance failure at your certificate authority is not a cliff your live certificate falls off. It is a wall you hit at your next issuance — which, at 100-day lifetimes, arrives within about three months. That is the practical reason to know your CA’s position ahead of the date rather than after it.

What to do before March 2027

Nothing in this policy obliges you to act, but two checks are worth making this year. First, ask your certificate authority which of its certificate profiles already have an automated path, and whether that path is ACME or proprietary client software. Second, confirm your own side can consume it — an ACME directory is only useful if something in your estate speaks RFC 8555.

• Ask for the ACME directory URL for the certificate type you actually buy, not just the DV one, and whether External Account Binding credentials come with the order.
• Check whether your ACME client supports ARI. Most maintained clients now do, and it is the feature that makes short lifetimes manageable.
• If you publish CAA records, look at the accounturi and validationmethods parameters — automation is the point at which pinning issuance to one account stops being theoretical.
• Pilot on a low-stakes hostname first. An automated renewal that fails quietly is worse than a calendar reminder that fires.
• Keep a documented manual fallback. The policy guarantees the automated path exists; it does not guarantee your pipeline never breaks.

If that audit turns up a CA with no automated path for the product you buy, you have roughly a year and a half of notice to move, which is more warning than most PKI changes offer. Our certificate range is issued from a hierarchy that already exposes a public ACME directory for paid certificates, so a migration there is a configuration change rather than a wait.