Client Authentication Exposure Assessment

Tim McAllister, Regional Field CTO, DigiCert · last verified 2026-07-25

Public certificate authorities are removing client authentication from public TLS certificates on a fixed, already-moving schedule. Most organizations cannot currently answer a basic question about their own environment: which systems authenticate a client using a certificate that will stop working. This is the full assessment, background through deliverable, for answering it before an outage does.

1. Background: why this is happening now

Two standards bodies govern what a browser will trust, and they are not the same body, which is the single most common point of confusion in this space.

The CA/Browser Forum sets the Baseline Requirements: the minimum rules every public certificate authority must follow to issue a trusted certificate. The Baseline Requirements still permit the client authentication extended key usage today. Nothing in the Forum's rules bans it.

The Chrome Root Program is a separate instrument. It is Google's own policy for which certificate authorities and root hierarchies Chrome will trust, and it can be stricter than the Baseline Requirements without any Forum vote. Chrome Root Program Policy, section 1.3.2, requires that public TLS root and intermediate hierarchies be dedicated to a single purpose. The policy phases Chrome-trusted hierarchies toward dedicated server authentication, with separate dates for newly disclosed subordinate CAs and newly issued subscriber certificates.

That single policy decision is what is closing the client authentication EKU out of public certificates. It did not require a change to the Baseline Requirements, and it does not appear in the CA/Browser Forum ballot history, which is exactly why it catches teams who are only watching the Forum.

The mechanism, precisely

These are issuance cutoffs, not revocations. These EKU issuance cutoffs do not, by themselves, revoke or retroactively distrust certificates issued earlier; normal expiry, revocation and relying-party policy still apply. What closes is the ability to get a new certificate with the clientAuth EKU from a publicly trusted hierarchy, going forward.

One root fact underlies all of it: a root program deciding what it will trust is a different instrument from the Forum deciding what may be issued. These Chrome public TLS requirements do not apply to private PKI; applications still enforce their own trust requirements.

2. The convergence most teams are missing

The EKU change would be a manageable, scheduled cutover if it arrived alone. It does not. It lands on top of a second, independent change: how long a public TLS certificate is allowed to live.

DigiCert issues one day under each industry cap: 199, 99, and 46 days. Its own domain-validation reuse change begins Feb 24, 2026.

Put the two schedules next to each other. New public TLS certificates currently have a 200-day maximum validity, but certificates issued before March 15, 2026 can retain their original validity. Whether the next renewal falls before or after an EKU cutoff depends on the certificate and issuer. Identify that renewal date for every client-authentication dependency, and test its replacement before the existing credential expires.

3. Why this is an assessment, not a renewal task

Swapping a single certificate is trivial, and any team can do it once it knows which certificate to swap. The actual obstacle is that almost nobody has a reliable list of which certificates are doing client authentication in the first place.

DigiCert's 2026 Global PKI Research Report, based on 423 security leaders at organizations of 1,000 or more employees, found that only 34% have a complete certificate inventory. An inventory that tracks issuer and expiry but not extended key usage will not answer this question, and most inventories stop at expiry.

That is why the failure mode here is not a missed deadline. It is discovery by outage, arriving staggered across the estate as each certificate hits its own renewal, without warning, and without looking like a certificate problem when it happens:

• A VPN concentrator that stops authenticating client certificates on the next renewal.
• An 802.1X or EAP-TLS wireless profile that silently drops devices off the corporate network.
• A service mesh or API gateway where mutual TLS was quietly running on a public certificate, because that was the one somebody could get issued fastest.
• A partner integration that returns a handshake failure on the far side, with neither party sure which end changed.

Each of those presents as a network incident, a help desk ticket, or a partner escalation, at whatever hour the renewal happened to land, to whoever is on call and has no reason to suspect an EKU changed. An assessment converts that pattern from unpredictable incident response into a known, prioritized backlog.

4. Assessment scope: systems to evaluate

Client-authentication certificates concentrate in specific categories of infrastructure, and they concentrate in exactly the places a general-purpose certificate management platform is least likely to see. An assessment needs to reach all of them, not just the ones a CMDB already tracks.

4.1 Remote access and network admission

What to look for: VPN concentrators (IPsec and SSL-VPN) authenticating client certificates instead of, or alongside, passwords; 802.1X wired and EAP-TLS wireless authentication issuing device or user certificates for network admission; NAC (network access control) platforms validating a device certificate before granting a network segment.

Why it matters: this is usually the highest-volume category, because certificate-based network admission scales better than password rotation, and it is also usually the least visible to a certificate management platform, because the certificates are issued and consumed entirely inside network infrastructure.

4.2 API, gateway, and service-to-service infrastructure

What to look for: API gateways and WAFs (F5, NGINX, Apigee, Kong, and equivalents) configured to require mutual TLS from calling clients; service mesh sidecars issuing workload identity certificates; load balancers terminating and re-establishing mTLS to backend services.

Why it matters: mTLS between services is frequently built once, during an initial integration project, and never revisited. The certificate that made that integration possible is often still a public certificate years later, because nobody circled back once the private-PKI alternative existed.

4.3 Partner, B2B, and regulated exchange

What to look for: portal login flows that authenticate a partner organization by client certificate rather than credentials; EDI/AS2 and SFTP-over-TLS exchanges using client certificates for counterparty identity; any integration where a certificate proves which organization, not which person, is on the other end.

Why it matters: this is the category where a private PKI genuinely cannot substitute, because the relying party is outside your organization and will not trust a root it has never heard of. This is precisely the trust-crosses-organizations case that a federated, industry-governed root exists to solve.

4.4 Device and IoT fleets

What to look for: field devices, gateways, or embedded systems authenticating to a cloud backend or management platform using a client certificate provisioned at manufacture or first boot.

Why it matters: device fleets often have the longest replacement cycles of anything in this list, sometimes measured in years rather than months, which means a certificate issued today under the wrong assumption can outlive several rounds of this policy change before anyone notices.

4.5 Enterprise applications and legacy middleware

What to look for: internal applications using client-certificate authentication as an SSO alternative or supplement; mainframe gateways, EDI translators, and other long-lived middleware that predates modern identity platforms and was configured once by someone no longer at the organization.

Why it matters: this is where institutional knowledge is thinnest. The system works, nobody has touched the certificate configuration since it was set up, and the person who set it up is the only one who could explain why it uses a public certificate rather than the internal PKI that existed even then.

4.6 Cloud and container platforms

What to look for: Kubernetes ingress controllers and service mesh configurations requiring client certificates; cloud-native API gateways with mTLS enabled; certificates stored as Kubernetes secrets or in a cloud secrets manager rather than a certificate lifecycle platform.

Why it matters: these certificates are frequently provisioned through infrastructure-as-code, which means the same public-certificate assumption can be replicated across dozens of environments by one Terraform module, invisible to any inventory that only looks at a certificate authority's own issuance logs.

4.7 The certificate management system of record itself

What to look for: whatever platform is supposed to be the source of truth for certificate issuance and renewal, queried specifically for extended key usage, not just for issuer and expiry.

Why it matters: this is the cross-check step. If the system of record and the field-level discovery in sections 4.1 through 4.6 do not agree, the gap between them is itself the finding, and it usually means shadow issuance is happening somewhere the platform cannot see.

5. Discovery methodology

The query is the same regardless of which system category is being searched. What differs is where it gets run.

certificate.type           = X.509
extension.oid              = 2.5.29.37                       EKU extension
extension.extendedKeyUsage CONTAINS 1.3.6.1.5.5.7.3.2         id-kp-clientAuth
basicConstraints.ca        = false                            leaf certificates

5.1 Contains, never equals

A filter for "EKU equals clientAuth" returns only single-purpose client certificates and silently drops every dual-purpose one. Dual purpose is most of what is actually deployed, because serverAuth plus clientAuth was the ordinary default until issuance defaults changed on October 1, 2025.

No certificate authority issues dual EKU going forward. That fact does not make this query less important, it makes it more important: the assessment is not searching for future risk, it is searching for an existing population that already exists in the estate. An equals filter will run cleanly, return almost nothing, and report the organization as unaffected when the actual answer is that the query missed its target.

5.2 Classify what comes back

5.3 Leaf and intermediate are separate questions

Leaf / end-entity        basicConstraints.ca = false  AND  EKU contains 1.3.6.1.5.5.7.3.2
Intermediate CA          basicConstraints.ca = true   AND  EKU contains 1.3.6.1.5.5.7.3.2

The intermediate query matters independently: since June 15, 2026, any new intermediate disclosed to CCADB must assert serverAuth only, so a dual-use intermediate cannot fill that newly disclosed role. If the organization operates or depends on a private intermediate hierarchy, this query identifies whether that hierarchy itself needs restructuring, separate from any question about the leaf certificates it issues.

5.4 Do not scope to unexpired certificates

Pull valid, expired, revoked, and disabled records in the same first pass, then classify afterward. An expired certificate is frequently the only surviving evidence of a workload configuration that nobody currently at the organization remembers setting up, and that evidence disappears the moment a query filters it out at collection time.

6. Sources to search

The single largest failure mode in an assessment like this is scope: query the certificate management platform, find little, and conclude the organization is unaffected. Client-authentication certificates concentrate in exactly the places a certificate manager does not see.

• OS trust and personal stores, Windows certificate stores, macOS keychains, Linux /etc/ssl and /etc/pki paths.
• Files on disk and in configuration management, loose PEM, DER, PFX, and PKCS#12 files, wherever configuration management or deployment scripts stage them.
• Java keystores and truststores, JKS and PKCS#12 stores backing application servers and middleware.
• Kubernetes and service mesh, TLS secrets, mesh-issued workload identities, ingress controller certificate references.
• Cloud certificate managers and secrets stores, provider-native certificate services and general-purpose secrets managers used to hold a certificate and key pair.
• HSMs and smartcard or token-backed credentials, hardware-protected keys often outlive several software migrations and are easy to forget precisely because they are hard to touch.
• MDM and device enrollment platforms, device management systems that provision a client certificate as part of enrollment.
• VPN concentrators, RADIUS/EAP-TLS servers, proxies, API gateways, and WAFs, the category that most often holds the certificates that matter most, and the one general inventory tooling is least likely to reach.
• Application-managed stores, anywhere a certificate is a configuration value inside an application rather than something a dedicated certificate platform tracks.

Windows note

The friendly display name is Client Authentication, but match the OID, not the label. Friendly names are localized and vary by tool, and a query built against a display string will silently miss non-English locales and third-party certificate viewers.

7. Data model: fields to capture

The two fields that carry the assessment's actual value are owning system and service binding. A fingerprint with no owner is not a completed inventory row. It is a future outage with a reference number attached to it.

8. Risk classification

Not every certificate that surfaces in the discovery phase carries the same urgency. A four-tier classification, built from three inputs, turns the raw inventory into a prioritized backlog.

Inputs: (1) EKU classification from section 5.2, (2) whether the relying party is internal or crosses an organizational boundary, (3) days remaining until the next renewal forces the issue.

9. Migration destinations

The decision is not which vendor to use. It is who has to validate whom, and that question has three distinct answers.

• Private PKI, when the enterprise owns both ends. Service mesh, workforce applications, server-to-server authentication inside one organization. Entirely outside root program policy, because no browser is ever in that trust path, and it is where most internal mTLS belonged before a public certificate became the faster thing to requisition.
• A dedicated non-browser bridge, when existing chains already depend on one. DigiCert's Assured ID G2 and G3 root hierarchies are a concrete example: both were removed from Chrome's trust store, which is exactly what makes them usable for non-browser client authentication today. They are useful for stabilizing an existing chain, inventorying what expires when, and buying design time. This is a bridge to a forward architecture, not the forward architecture itself, and treating it as a permanent destination just relocates the same problem.
• An industry-governed root, when trust crosses organizational boundaries. ASC X9 launched exactly this for financial services in 2025: a common root, governed by the ASC X9 Policy Committee rather than the CA/Browser Forum, with DigiCert as the operating certificate authority, carrying both client and server authentication EKUs. It is deliberately not browser-compatible, because no browser is validating a partner's API client, and that is a feature of the design rather than a gap in it. DigiCert's own guidance extends the use case past pure financial services, naming manufacturing, healthcare networks, and connected infrastructure operators explicitly, under the same X9 Certificate Policy framework.
• Federating trust this way takes an explicit step on both sides, not just a certificate. Each relying party needs its own X9-issued certificate, and each party has to add the X9 root to its own system trust store, since no operating system or browser ships with it by default. Skip either half and one side of the handshake fails silently, which is the most common way an X9 pilot stalls.

One planning detail worth building into the migration business case: a governed root outside the public WebPKI is also outside its lifetime compression schedule. Current industry-governed order documentation for this kind of root commonly shows a one-year default and longer maximum validity, against a public TLS trajectory heading from 199 days down to 99 and then 46. That is potentially far fewer replacement cycles for the certificates that move. It is not zero validation work. Domain validation reuse windows are tightening industry-wide, including for some non-browser paths, so prevalidation and automation still belong in the plan, and any projection of savings should say potentially rather than promise a guaranteed reduction.

10. The assessment deliverable

A completed assessment should produce four things, in this order, because each depends on the one before it:

1. An executive summary stating the total count of client-authentication certificates found, how many are Tier 1, and the single nearest date at which something breaks if nothing changes.
2. The full inventory, every field from section 7, searchable and exportable, organized by the system categories in section 4 rather than by certificate authority.
3. Risk-tiered findings, per section 8, with an assigned owner on every Tier 1 and Tier 2 row before the report is considered complete.
4. A migration roadmap mapping each finding to one of the three destinations in section 9, sequenced against each certificate's actual renewal date rather than against the 2027 deadline, because the renewal date is what actually forces the decision.

A report that stops at item 2 is an inventory, not an assessment. The tiering and the roadmap are what make it something an organization can act on rather than something it has to interpret.

11. Timeline reference

12. Running this assessment

Nothing in sections 1 through 11 requires a specific vendor or platform. The predicate, the scope list, and the risk tiering are system-agnostic by design, and any team with query access to the sources in section 6 can run this internally.

Where it tends to bog down is not the technical query. It is the scope discipline in section 4 and the ownership assignment in section 8: knowing which system categories to chase down, and getting a name attached to every Tier 1 finding before the report ships. Those are organizational problems as much as technical ones, and they are usually where an outside set of eyes earns its place, less for the query itself than for making sure nothing in section 4 gets skipped because nobody thought to ask the team that owns it.

Updated September 5, 2026: corrected the Chrome issuance scope and current validity timeline. References: Chrome Root Program §1.3.2; CA/Browser Forum §6.3.2; DigiCert clientAuth transition.

Sources: Chrome Root Program Policy; CA/Browser Forum Baseline Requirements and ballot SC-081v3; DigiCert public alerts on clientAuth EKU removal, public TLS validity changes, and DCV reuse changes; publicly available ASC X9 PKI for TLS documentation; DigiCert 2026 Global PKI Research Report (Omdia, n=423).

← timmcallister.io