The clock is ticking on a quiet but consequential change in how the internet handles trust—and most organizations don’t know they’re affected.

A policy change with broad consequences.

Google’s Chrome Root Program is tightening how publicly trusted Certificate Authorities (CAs) are allowed to issue TLS certificates. The practical impact: publicly trusted server certificates are being limited to “Server Authentication” only, and the long-standing practice of issuing “dual‑use” certificates (serverAuth + clientAuth EKUs) is being phased out.

Chrome Root Program Policy updates (and corresponding CA rollout plans) point to mid‑2026 as the inflection point. New publicly trusted TLS certificates intended for web server authentication should not include the Client Authentication EKU. A later enforcement milestone closes remaining exceptions. The exact dates vary by CA and program updates, but the direction is consistent: public Web PKI is for server identity; client identity belongs in a separate trust model.

If your business uses public TLS certificates to authenticate machine‑to‑machine connections—APIs, gateways, partner integrations, devices, or service meshes—you need a replacement strategy. Many teams default to building or extending a private CA. Another path is to use a managed, policy‑governed PKI designed for cross‑organization mTLS. One example is DigiCert’s X9 PKI, created to support ecosystems that require a shared trust framework outside the traditional Web PKI. 

What’s changing—and why executives should care.

Mutual TLS (mTLS) is a common way to authenticate both sides of a connection, server and client, using certificates. It shows up in partner APIs, zero-trust service-to-service traffic, VPN and device onboarding, and regulated data exchanges.

Historically, many publicly trusted TLS certificates were issued with Extended Key Usages (EKUs) that allowed them to be used for both server authentication (serverAuth) and client authentication (clientAuth). Chrome’s Root Program policy direction is to end that “dual-use” pattern in the public Web PKI, narrowing publicly trusted TLS server certificates to serverAuth only.

This is good security hygiene, but it creates an operational gap for organizations that used public certificates for client identity in mTLS. The next step is choosing an appropriate trust model: private PKI, managed private PKI, or a purpose-built cross‑organization PKI where multiple parties can rely on shared governance.

The hidden cost of “just build your own CA”.

Standing up an internal CA can be the right solution for purely internal use cases. But using it to support business‑critical mTLS, especially with external parties, creates costs and risks that are often underestimated.

A credible private PKI is an operating model, not a one‑time project: strong key protection (often with HSMs), certificate lifecycle automation, revocation and auditing, separation of duties, incident response, and planned migrations for root and intermediate changes. When something goes wrong, the blast radius can be enterprise-wide.

Many enterprises already have Microsoft AD CS or other internal CA tooling. Those platforms can work well for internal identity, but scaling them to modern, heterogeneous environments (cloud, containers, multi‑tenant services) and to external counterparties typically requires additional architecture, governance, and specialized PKI expertise.

The hardest part is trust beyond your boundary. Partners and customers have no inherent reason to trust your internal root. Establishing bilateral trust: contracts, technical onboarding, audits, and ongoing governance, can become a recurring cost as ecosystems grow.

What X9 PKI is (in plain terms).

ASC X9 is an ANSI-accredited standards body best known for financial-services security and interoperability standards. In response to industry needs for a trusted, non‑browser PKI model for machine authentication, X9 established an X9 PKI trust framework that operates outside the public Web PKI.

Practically, this creates a shared root of trust and governance model that organizations can use for mTLS and other identity use cases where “publicly trusted web server certificates” are no longer the right fit.

DigiCert operates an X9 PKI offering as a managed service, pairing operational controls (issuance, lifecycle, auditing) with a policy framework intended for cross‑organization trust.

Why this matters beyond financial services.

While the original target for X9 PKI was finance, the pattern is common across industries: whenever you need machine identity that must be trusted by external parties, a purely internal CA is often insufficient.

Examples include partner API programs, B2B data exchanges, supply-chain integrations, and managed IoT ecosystems. In each case, you need a shared trust anchor and governance that counterparties can accept without one-off custom trust negotiations.

At an executive level, the potential advantages of a managed, policy-governed PKI model include:

• Reduced operational burden: lifecycle automation, renewal discipline, and centralized visibility to lower outage risk.

• Stronger governance: documented policies, auditing, and clearer separation between web server identity and client/machine identity.

• Interoperability for ecosystems: a trust framework that can be adopted by multiple organizations (rather than relying on a single enterprise’s internal root).

• Cryptographic agility: a platform path for algorithm transitions, including preparation for post‑quantum requirements.

The executive question (and what to do next).

The core decision is not whether mTLS is valuable, it is. The decision is whether your organization wants to operate a high-assurance PKI as critical infrastructure, or consume it as a governed service aligned to your risk and partner model.

If you are affected, the risk is straightforward: certificate renewals or new deployments may stop meeting browser-rooted requirements, creating unexpected authentication failures in critical integrations. The organizations that handle this well treat it as a planned identity modernization effort—not a late-stage scramble.

1. Inventory and classify: identify where certificates are used for client/machine identity (mTLS, VPN, API gateways, devices) and whether any depend on dual‑EKU public TLS certificates.

2. Validate timelines with your CA(s): confirm when your providers stop issuing clientAuth-enabled public TLS certificates and what reissue options exist during the transition.

3. Select a target trust model: private PKI for internal-only use cases; managed private PKI for scale; or a shared, policy-governed PKI when external counterparties must rely on the same trust framework.

4. Plan rollout and governance: automation (issuance/renewal), revocation strategy, monitoring, and partner onboarding processes. 

The organizations that act now will treat this transition as an opportunity to rationalize their PKI strategy. Those that wait will treat it as a crisis.

References (for further reading).

• Google Chrome Root Program Policy – Currently v1.8

• DigiCert Knowledge Base: “Removing the client authentication EKU from public TLS certificates” (timeline and customer impact guidance)

• CA/Browser Forum Baseline Requirements (background on public TLS certificate requirements)