When Public CAs Started Recommending Private CAs

The sentence that buyers will quote in 18 months

Tucked into Sectigo's customer FAQ this week, in the same tone of voice you'd use to explain a billing policy, is the following sentence:

It's an unremarkable sentence on first read. It only becomes interesting when you notice that Sectigo is one of the largest public TLS issuers in the world and the recommendation in that sentence is, in effect, "do not buy this category of certificate from us anymore." Most companies do not write FAQs like that.

It also turns out Sectigo isn't alone this week. The same phrasing, or something very close to it, now appears in Cisco's field notice FN74392 (for Identity Services Engine), in the companion advisory for Secure Firewall, in field notice FN74404 (for Secure Network Analytics), in DigiCert's blog about combined-EKU certificates, and in the operator-voice essay Sreehari J published on Medium that's been doing the rounds among ISE admins. The verbatim recommendation, across five different documents from five different organisations, is some variation on "transition to private PKI."

That is the moment worth noting. Not the May 15 cutoff itself, which has been on the calendar since last summer. The category shift is in what the vendor copy now says.

Reading the Sectigo FAQ carefully

Take the Sectigo FAQ as the canonical document. There are three lines worth pulling out, because each one closes a door that's been open for a long time.

Read those in order. The first kills the procurement workaround (you can't pay Sectigo to give you a custom profile). The second kills the future-restoration hope (the EKU isn't coming back if Chrome changes its mind in 2028). The third closes the loop by naming what customers should do instead. Notice the word "should," not "could." Sectigo's lawyers wrote that sentence with care.

A document like this is what the Sectigo sales team will send when a customer opens a ticket on Monday morning asking why their mTLS broke. It's the same document that gets quoted, six months from now, in a board memo about the trust-architecture migration the company "had to do." The FAQ is a record of how the vendor publicly framed the situation when the deadline landed.

Cisco's three field notices in fourteen days

Cisco issues field notices for things that will reliably generate inbound support tickets at scale. Three in two weeks, all tied to the same root cause, is unusual. Worth a tabular look:

All three documents use the same long-term recommendation: transition to private PKI. None of them name a preferred vendor. None of them say "buy this from Cisco." The recommendation is architectural, which is the right move for Cisco (they don't want to be on the hook for sourcing your CA) and also the right read of the situation (the issue isn't a procurement problem; it's a control-plane problem).

The thing operators tend to miss on a first read is that the failure mode in each document is identical, and it's a quiet one. The certificate currently in use keeps its clientAuth EKU until it expires. The next renewal, served from a post-cutoff Sectigo profile, doesn't include the EKU. The cert deploys cleanly. Server TLS works. Validation passes. Then the next mTLS handshake fails, and nothing in the renewal pipeline emitted a warning, because from the renewal pipeline's perspective everything went fine.

Sreehari J called this "the renewal cliff" in his Medium piece and the metaphor is right. A normal expiration cliff is loud. The cert visibly turns red in your monitoring. This one is silent until something tries to use the capability that's no longer there. The first time you find out is probably an end-user ticket.

The DigiCert hedge, and why it's a deferral

Cisco's advisories list one workaround for customers who can't migrate to a private CA in time. The wording (paraphrasing here): you can continue to use a public CA that still issues combined Server+Client EKU certificates from select root hierarchies, such as DigiCert or IdenTrust. That's accurate. It's also worth reading DigiCert's own roadmap before deciding to depend on it.

DigiCert's blog this month, titled with the lovely euphemism "How the ClientAuth Crackdown is Pushing Finance Toward X9-PKI," includes the operational footnote that combined-EKU public certificates from DigiCert's general TLS roots are themselves ending on February 10, 2027. After that date, DigiCert continues to offer combined-EKU certs only from purpose-specific hierarchies (X9, ATIS, financial-sector roots), which are not the certificates most Cisco operators have today.

So the "stay on public a little longer" path is real, but the runway is nine months. For a typical Cisco operator the choice is whether to do the private-CA migration once, in the next 90 days, or to do it twice (first onto DigiCert's combined-EKU path, then onto a private CA before February 2027). The math here is not subtle.

Let's Encrypt got there first, and nobody noticed

Worth being honest about something: this convergence has been building for months. Let's Encrypt silently removed the TLS Client Authentication EKU from its default profile back in February. There was no email blast, no big announcement, no opt-in dialog. The behaviour change landed in the ACME staging environment, then in prod, and unless you were diffing your certificate profiles you wouldn't have caught it. The "tlsclient" profile is on a sunset path with the deadline at July 8.

A lot of teams found out in the worst way. Renewals ran clean, monitoring stayed green, and then a service-to-service handshake somewhere in the mesh started failing. The post-mortems on those incidents are mostly internal docs, but the shape of them is consistent. The team had treated certificate renewal as a solved problem. The automation worked. The certificate that came out the other end no longer did what the old one did. ACME was never going to tell you that, because ACME doesn't have an opinion about your use case.

The Apache Software Foundation issued a deployer alert this week pointing operators at the same set of facts: if you're using Let's Encrypt or any other public CA for inter-service authentication anywhere in your stack, plan the migration now. The ASF alert is unusual; they don't typically wade into PKI policy. They did this time because the question kept coming up.

The question the vendor docs all dodge

Every one of these documents recommends private PKI and then stops. The Sectigo FAQ doesn't name a product. The Cisco field notices don't name a product. The DigiCert blog gestures at "your preferred private CA solution." This is fine if you have a PKI team. It is not fine if you don't.

The orgs being told to migrate this week mostly do not have a PKI team. They have one or two platform engineers who handle the whole identity stack alongside everything else, a couple of Cisco firewalls, an ISE instance, some service-mesh mTLS, maybe a Vault deployment that someone set up two years ago. The phrase "stand up a private CA" implies a project, a hire, an HSM purchase, a key-ceremony policy, an intermediate-issuance plan, a CRL strategy, a posture audit. For a 200-person company that just opened a Sectigo ticket on May 16, that's the wrong shape of project.

This is the gap. The vendor copy has correctly identified the architectural answer and has stopped short of the operational answer. Sectigo isn't going to tell you how to run a private CA, because that's not what Sectigo sells. Cisco isn't either; they want to keep selling firewalls, not become a PKI vendor by accident. DigiCert wants you on their enterprise PKI suite if you have enterprise budget, and elsewhere if you don't.

The mid-market gap isn't a product gap; it's a posture gap. The right answer for an organisation without a PKI team is not "buy step-ca" or "buy AD CS." It's a managed surface that runs the CA, handles the key material, automates issuance and renewal against the systems you already have, and reports posture in a way that someone who is not a PKI engineer can read. That's what "Accessible Trust Infrastructure" means in 2026, and it's the work most of the vendor copy this week has skipped over.

What buyers should do with this

If you're a CISO or platform owner watching this unfold, a few practical reads. First, the Sectigo FAQ is the document your team will be quoting in conversations with leadership for the next year. Print it. Save the URL. The "should migrate to a Private PKI solution" sentence is the citation that makes the budget request easy.

Second, the migration is not a one-time event. The architectural read of the converged vendor copy is that public TLS is being narrowed to one specific use case: short-lived, narrow-purpose, fully automated server-side certificates for things browsers connect to. Everything else (mTLS, EAP-TLS, device identity, internal services, AI agent identity, IoT bootstrapping) is moving to private CAs. Plan for the split as a permanent feature of your trust architecture, not a temporary workaround.

Third, don't take the combined-EKU lifeline. It is a real option for a short window and it will cost you a second migration in 2027. The buyer who does this once, this year, ends up in a better posture than the buyer who tries to defer.

Fourth, do the inventory first. The migration plan is much shorter when you actually know which systems are using TLS for client authentication versus server authentication. Most teams discover during this exercise that the answer is "more places than we thought," which is itself useful information.

The shift, in one paragraph

For decades, the answer to "where do I get a certificate" was "buy one from a public CA." That sentence is still correct for browser-facing TLS. For everything else, the public CAs themselves have started telling customers to look somewhere else. The week of May 11-15, 2026 will end up being the week the vendor copy converged on that answer. The operational work that follows, building, running, and managing a CA you control without having to become a PKI shop to do it, is the next chapter.

If you're staring down a Sectigo renewal that fires this weekend and wondering what private PKI is supposed to look like for a team that doesn't have one, that's the conversation worth having. The architectural answer is in the vendor docs. The operational answer is in what you build next.