The CA/Browser Forum Mandate: The End of Dual-EKU Certificates

CA/Browser Forum Ballot SC-081v3, passed unanimously in April 2025 with support from all four major Forum members, including Google, Apple, Microsoft, and Mozilla, and 25 voting Certificate Authorities. This ballot introduced a sweeping set of changes to the TLS Baseline Requirements (TBRs), with the Client Extended Key Usage (EKU) separation among the most structurally significant.

The Chrome Root Program Policy v1.8, which operates as the enforcement mechanism for Google Chrome’s root store, goes further. It mandates not just that leaf certificates be free of clientAuth, but that entire PKI hierarchies be reorganized, including intermediate CAs that chain to roots in the Chrome Root Store, must no longer carry dual EKU values. The separation must occur at the CA level, not just the certificate level.

Before diving into the mandate, it is worth grounding the conversation in the technical fundamentals. Extended Key Usage (EKU) is a field within an X.509 digital certificate that defines the specific purposes for which a certificate’s public key may be used. Systems that validate certificates check EKU values to determine whether a presented certificate is authorized for the operation being attempted.

There are two EKU values at the center of this mandate:

• Server Authentication (OID 1.3.6.1.5.5.7.3.1): Signals that the certificate is valid for authenticating a server to a client. This is what your HTTPS website uses. Browsers check for this EKU when establishing a TLS connection.
• Client Authentication (OID 1.3.6.1.5.5.7.3.2): Signals that the certificate is valid for authenticating a client to a server. This is used in mTLS, device authentication, and scenarios where the client must prove its identity rather than just the server.

Public Certificate Authorities issued TLS certificates that contained dual EKU values. The certificate looks like:

A single certificate would carry both serverAuth and clientAuth. This dual-EKU practice was convenient; one certificate could serve double duty, but it was architecturally unsound, and the CA/Browser Forum has now formally eliminated it from public PKI.

Quick Answer: What Is the Dual-EKU Certificate Mandate?

The dual-EKU certificate mandate from CA/Browser Forum SC-081v3 (April 2025) and Chrome Root Program Policy v1.8 eliminates clientAuth from publicly trusted TLS certificates. From June 15, 2026, no new intermediate CA may carry dual EKU values. From March 15, 2027, every newly issued publicly trusted TLS leaf certificate must contain only serverAuth. Client authentication must move to a dedicated private PKI hierarchy.

Key Takeaways

• CA/Browser Forum Ballot SC-081v3 passed unanimously in April 2025 with support from Google, Apple, Microsoft, Mozilla, and 25 voting CAs. Chrome Root Program Policy v1.8 enforces the separation at the CA hierarchy level, not just the leaf certificate level. From June 15, 2026, no new intermediate CA disclosed to the CCADB may carry both serverAuth and clientAuth. From March 15, 2027, every newly issued publicly trusted TLS leaf certificate must contain only the serverAuth EKU.
• The DigiCert Trust Pulse Survey (July 2, 2025) found that 45 percent of organizations experienced certificate-related downtime in the prior year, and 37.5 percent traced an outage to an expired certificate. The dual-EKU mandate introduces a new and harder-to-diagnose failure mode: a certificate renewed without clientAuth is valid, unexpired, and trusted, but silently fails all client authentication use cases with generic errors (TLS handshake failure, access denied, peer verification failure) that do not identify the missing EKU as the cause.
• CA/Browser Forum SC-081v3 also phases down maximum TLS validity from 200 days (March 2026) to 100 days (March 2027) to 47 days (March 2029). At 47-day validity, a certificate is renewed approximately eight times per year. Every renewal of a dual-EKU certificate that has not been migrated to a private PKI is a potential silent authentication outage. The mandate and the validity reduction are on the same schedule, compounding the risk for organizations that delay discovery and migration.
• Eight use-case categories face disruption: mutual TLS (mTLS), RADIUS and IEEE 802.1X network authentication, certificate-based VPN (OpenVPN, Cisco Secure Client, Fortinet), Microsoft Exchange server-to-server communication, Remote Desktop and RDP Gateway, IoT and device identity, API and server-to-server authentication, and CI/CD and DevOps workloads. The most dangerous dependencies are the undocumented ones: systems that rely on clientAuth because public certificates historically included it by default, without that dependency being formally recorded.
• NIST FIPS 203, 204, and 205 (finalized August 13, 2024) require replacing RSA and elliptic-curve algorithms across all PKI hierarchies on the NIST IR 8547 deprecation timeline. Private CA hierarchies built to satisfy the dual-EKU mandate must also include post-quantum migration planning for private CA key algorithms. Track private CA key algorithm migration requirements through the PQC Center of Excellence.

Who Should Care About the Dual-EKU Mandate

The dual-EKU mandate is not a certificate template change. It is a PKI architecture change that requires coordinated action from PKI teams, security architects, platform engineers, compliance teams, and CISOs. Each team owns a distinct part of the transition, and gaps in any area produce the silent authentication failures that are the mandate’s primary operational risk.

Role	Why It Matters	Action Item
PKI and Certificate Teams	Own the private CA hierarchy design and the certificate template separation: the Chrome Root Program Policy v1.8 requires separation at the CA level, not just the leaf certificate level, meaning PKI teams must design and operate a private hierarchy with dedicated issuing CAs for client authentication (clientAuth EKU only, no serverAuth) separate from the public TLS hierarchy (serverAuth only); standard enterprise CA platforms require explicit template configuration to enforce EKU separation and prevent dual-EKU issuance; the March 15, 2027 deadline is absolute for newly issued certificates, with no extension possible for organizations that have not completed migration	Audit the full certificate inventory for any publicly trusted certificate carrying both serverAuth and clientAuth EKU values using CertSecure Manager; design the private CA hierarchy with dedicated issuing CAs for client authentication, user identity, device identity, and workload identity; configure certificate templates to enforce EKU separation (serverAuth-only public templates, clientAuth-only private templates) with no dual-EKU issuance possible; use CBOM Secure for full cryptographic estate discovery including all CA-issued certificates across cloud, on-premises, and multi-cloud environments; evaluate PKIaaS for the private CA hierarchy if internal PKI operations capacity is limited
Security Architects	Own the PKI architecture governance: the mandate requires not just a new certificate template but a new private CA hierarchy with its own root CA, issuing CAs, HSM-backed key protection, trust store distribution strategy, CRL/OCSP infrastructure, and enrollment protocol selection; security architects must also design the boundary between public TLS certificates (serverAuth only, browser-trusted) and private client certificates (clientAuth only, privately trusted) to ensure no system can use a public certificate for client authentication or vice versa; the post-quantum migration of private CA key algorithms (ECDSA to ML-DSA per NIST FIPS 204, finalized August 13, 2024) must also be planned at architecture design time	Design the private CA hierarchy architecture: offline root CA, separate issuing CAs for each client authentication use case (mTLS, device, user, workload, API), HSM-backed key protection meeting FIPS 140-3 Level 3 requirements, CRL and OCSP infrastructure, and trust store distribution plan; specify enrollment protocols for each use case (WSTEP for Windows AD-joined machines, ACME for cloud-native workloads, SCEP for mobile/IoT, EST for general-purpose enrollment); plan the post-quantum migration path for private CA key algorithms through the PQC Center of Excellence; define the policy boundary that prevents any system from using a public TLS certificate for client authentication after March 15, 2027
Platform and DevOps Teams	Own the application-level migration: every system that currently presents a public TLS certificate for client authentication must be reconfigured to present a private client certificate instead; this includes mTLS endpoints in microservice architectures, RADIUS servers and 802.1X authentication infrastructure, VPN gateways (OpenVPN, Cisco Secure Client, Fortinet), IoT platforms and device management systems, Kubernetes service mesh configurations, API gateways with certificate-based client authentication, and CI/CD pipelines that authenticate to registries, artifact repositories, and Kubernetes clusters; platform teams must also integrate private certificate enrollment (WSTEP, ACME, SCEP, EST) into infrastructure provisioning workflows so new systems receive private client certificates automatically	Map all mTLS configurations, RADIUS deployments, VPN gateways, Kubernetes service mesh policies, API gateway authentication configurations, and CI/CD pipeline certificate usage to identify which use cases present public certificates for client authentication; reconfigure each system to present a private clientAuth-only certificate from the new private PKI hierarchy; integrate private certificate enrollment into infrastructure provisioning pipelines (cert-manager for Kubernetes, ACME for cloud-native, WSTEP for Windows AD-joined); add authentication success rate monitoring for mTLS, RADIUS, and VPN use cases to detect clientAuth removal failures before they become customer-impacting outages
Compliance Teams	Must produce audit evidence that the organization has completed migration before the March 15, 2027 deadline: regulated industries deploying mTLS (PCI DSS 4.0 Requirement 4), certificate-based network authentication (HIPAA, DORA), or device identity (CMMC) face compliance exposure if client authentication certificates are renewed without clientAuth and authentication failures are traced to a non-compliant certificate issuance posture; the DigiCert Trust Pulse Survey (July 2, 2025) found 45 percent of enterprises experienced certificate-related downtime, and audit findings related to certificate governance failures are a direct consequence of undiscovered dual-EKU dependencies	Include dual-EKU migration status in the quarterly compliance evidence package: percentage of publicly trusted certificates still carrying clientAuth, percentage of client authentication use cases migrated to private certificates, and authentication outage incidents attributable to clientAuth removal; map the June 15, 2026 intermediate CA deadline and March 15, 2027 leaf certificate deadline to internal compliance milestones; confirm that the private PKI hierarchy produces audit-ready certificate governance reports on demand (issuing CA, EKU, expiry, owner, enrollment method) without manual assembly; verify private CA enrollment automation coverage so that 47-day validity from March 2029 does not introduce manual certificate renewal obligations
CISOs	The dual-EKU mandate is a board-level operational risk: authentication failures caused by clientAuth removal will not announce themselves as certificate errors but as TLS handshake failures, access denied messages, VPN connectivity loss, IoT device offline events, and CI/CD pipeline failures with no obvious cause; the DigiCert Trust Pulse Survey (July 2, 2025) found 37.5 percent of certificate-related outages were traced to expired certificates, but the dual-EKU failure mode is harder to diagnose than expiry because the certificate is valid; the compressed validity timeline (47 days by March 2029) means renewal events occur eight times per year, multiplying the exposure for undiscovered dependencies	Fund a certificate discovery and inventory program using CertSecure Manager as an immediate priority, completed before June 15, 2026; fund the private PKI hierarchy build or PKIaaS engagement before the intermediate CA deadline forces emergency action; require that dual-EKU migration status, private PKI enrollment automation coverage, and authentication outage metrics attributable to certificate purpose failures are reported as board-level KPIs; evaluate PKI as a Service for the private CA hierarchy to avoid building and operating HSM infrastructure under deadline pressure; mandate that private CA key algorithm post-quantum migration planning is included in the annual PKI program review

Dual-EKU Transition Checklist: Issue, Business Impact, Recommended Action, and Owner

Use this checklist before the June 15, 2026 intermediate CA deadline and the March 15, 2027 leaf certificate deadline to identify transition gaps, understand the business impact of each gap, and assign remediation ownership.

Issue	Business Impact	Recommended Action	Owner
No inventory of certificates carrying both serverAuth and clientAuth EKU values	Organizations cannot identify which certificates will silently lose clientAuth on renewal; discovery after the deadline means remediation under outage pressure rather than planned migration; the DigiCert Trust Pulse Survey (July 2025) found 45 percent of enterprises experienced certificate-related downtime, and undiscovered dual-EKU dependencies are the primary source of that downtime for this mandate	Deploy CertSecure Manager for full certificate discovery across all CA sources including public CAs, AWS Private CA, Azure Key Vault, HashiCorp Vault PKI, and on-premises AD CS; filter inventory for certificates carrying both OID 1.3.6.1.5.5.7.3.1 and OID 1.3.6.1.5.5.7.3.2; map each dual-EKU certificate to the system presenting it and the system relying on it for client authentication; produce a risk-ranked migration timeline based on expiry dates	PKI Team + CISO
No private PKI hierarchy for client authentication certificates	Without a private CA, there is no compliant source for clientAuth-only certificates; organizations face a hard deadline (March 15, 2027) with no fallback: public CAs cannot issue clientAuth certificates after that date, and there is no grace period for organizations that have not built a private CA	Design and deploy a private CA hierarchy with dedicated issuing CAs for client authentication use cases; protect CA private keys with FIPS 140-3 Level 3 HSM; configure certificate templates with clientAuth EKU only and no serverAuth; alternatively, engage Encryption Consulting’s PKIaaS for a fully managed private CA built, operated, and kept compliant under tight deadlines	PKI Team + Security Architect
Private root CA not distributed to all relying party systems	Client certificates issued by the private PKI are rejected by systems that have not installed the private root CA; authentication failures occur even though the certificate is correctly configured with clientAuth, because the receiving system does not trust the issuing CA chain	Distribute the private root CA to all Windows domain-joined systems via Group Policy (Trusted Root Certification Authorities store); distribute to Linux systems via update-ca-certificates through Ansible, Chef, or Puppet; distribute to mobile and IoT systems through MDM; test authentication success from representative systems before migrating production workloads; document the trust distribution plan and confirm coverage before each migration phase	Platform Team + PKI Team
Client authentication use cases on manual certificate renewal	At 47-day maximum TLS validity from March 2029, manual renewal of client certificates produces eight renewal events per year per certificate; manual processes at that frequency are operationally unsustainable and introduce eight outage opportunities per certificate per year if any renewal is missed or delayed	Enroll all private client certificates in automated renewal using the appropriate enrollment protocol: WSTEP for Windows AD-joined machines (zero-touch via GPO), ACME for cloud-native and containerized workloads, SCEP for mobile and IoT devices, EST for general-purpose enrollment; integrate enrollment into infrastructure provisioning pipelines so new systems receive private client certificates automatically without manual PKI team intervention	Platform Team + PKI Team
No authentication success rate monitoring for mTLS, RADIUS, and VPN	ClientAuth removal failures present as generic errors (TLS handshake failure, access denied, peer verification failure, authentication timeout) that are easy to misdiagnose as network, cipher suite, or application configuration problems; without specific authentication success rate monitoring, the root cause is identified only after extended downtime	Add authentication success rate monitoring for all mTLS endpoints, RADIUS authentication events, VPN connection attempts, and IoT device check-ins; configure alerting on authentication failure rate changes that correlate with certificate renewal events; include EKU validation in certificate health checks so that a renewed certificate missing clientAuth is flagged before it causes an authentication failure in production	Platform Team + Security Architect
Private CA key algorithms not included in post-quantum migration plan	NIST FIPS 203/204/205 (finalized August 13, 2024) require replacing RSA and ECC across all PKI hierarchies on the NIST IR 8547 deprecation timeline; a private CA hierarchy built under the dual-EKU deadline without post-quantum algorithm planning must be rebuilt or re-keyed before the deprecation deadline, compounding the migration burden	Classify private CA key algorithms (RSA, ECDSA P-256/P-384) against NIST IR 8547 deprecation milestones at architecture design time; plan migration to ML-DSA (FIPS 204) for CA signing keys; use CBOM Secure to discover all cryptographic assets in the private PKI hierarchy; track migration requirements through the PQC Center of Excellence; evaluate PQC Readiness services for a structured migration assessment	Security Architect + PKI Team

The Mandate: What SC-081 and Chrome Root Program Require

Public Certificate Authorities may no longer issue TLS server certificates that include the clientAuth Extended Key Usage. Intermediate CA certificates that support both serverAuth and clientAuth and chain to a publicly trusted root must be retired.

Any organization that needs client authentication certificates must obtain them from a dedicated, purpose-built PKI hierarchy that, by definition, cannot be a public CA hierarchy trusted in browser root stores.

The most critical date for organizations is June 15, 2026, SUBORDINATE/intermediate CA certificates: any new intermediate disclosed to CCADB on or after that date must assert serverAuth only, and no new dual-EKU intermediates may be added to Chrome-trusted hierarchies.

From March 15, 2027, every newly issued leaf certificate that chains to a Chrome-trusted root must also be serverAuth-only; from this point Chrome will reject public TLS leaf certificates that still carry the clientAuth EKU, and the affected handshakes will fail. Certificates issued before the applicable cutoff remain valid until expiry, but on renewal they are reissued without clientAuth.

To qualify as a dedicated TLS server authentication PKI hierarchy under this policy:

1. All corresponding unexpired and unrevoked subordinate CA certificates operated beneath an existing root included in the Chrome Root Store MUST:
   • if disclosed to the CCADB before June 15, 2026: include the extendedKeyUsage extension and (a) only assert an extendedKeyUsage purpose of id-kp-serverAuth or (b) only assert extendedKeyUsage purposes of id-kp-serverAuth and id-kp-clientAuth.
   • if disclosed to the CCADB on or after June 15, 2026: include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.
   • NOT contain a public key corresponding to any other unexpired or unrevoked certificate that asserts different extendedKeyUsage values.
2. All corresponding subscriber certificates issued on or after March 15, 2027, MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth.

From March 15, 2027 onward, every newly issued publicly trusted TLS certificate must serve a single purpose: server authentication. It must contain only the serverAuth EKU, with the clientAuth OID completely removed. The Public CA certificate should look like:

The following table specifies the required and permitted fields for Subscriber (leaf) TLS Server Certificates issued by publicly trusted CAs as per CA/Browser Forum mandate, 7.1.2.7 Subscriber (Server) Certificate Profile:

Field / Extension	Presence	Permitted Values and Requirements
version	MUST	v3 (integer value 2)
serialNumber	MUST	Positive integer, at least 64 bits of output from a CSPRNG.
subjectAltName	MUST	This extension MUST contain at least one entry. Each entry MUST be either a dNSName or iPAddress as described in Section 7.1.4.2.
basicConstraints	MUST	For a subscriber (leaf) certificate, the cA field MUST be set to FALSE. pathLenConstraint MUST NOT be present.
keyUsage	MUST	It’s a critical attribute. The acceptable Key Usage values vary based on whether the Certificate’s subjectPublicKeyInfo identifies an RSA public key or an ECC public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key. The permitted key usages are digitalSignature + keyEncipherment for RSA, and digitalSignature only for ECDSA
extendedKeyUsage	MUST	The following value MUST be present: • id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) The following value SHALL NOT be present: • id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2) – Prohibited for newly issued leaf certificates from March 15, 2027 under Chrome Root Program Policy v1.8, Section 1.3.2
certificatePolicies	MUST	If present, the Certificate Policies extension MUST contain at least one PolicyInformation.
authorityInformationAccess	MUST	It is not critical Field. • keyIdentifier- MUST be present. MUST be identical to the subjectKeyIdentifier field of the Issuing CA. • authorityCertIssuer- MUST NOT be present • authorityCertSerialNumber- MUST NOT be present
subjectKeyIdentifier	MUST	The CA MUST generate a subjectKeyIdentifier that is unique within the scope of all Certificates it has issued for each unique public key
cRLDistributionPoints	MUST	This extension MUST be present and MUST NOT be marked critical. The CRL Distribution Points extension MUST be present in: • Subordinate CA Certificates; and • Subscriber Certificates that 1) do not qualify as “Short-lived Subscriber Certificates” and 2) do not include an Authority Information Access extension with an id-ad-ocsp accessMethod.

Note on extendedKeyUsage: The CA/Browser Forum TLS Baseline Requirements v2.2.8, Section 7.1.2.7.10, still lists id-kp-clientAuth as MAY, permitted but not required at the BRs level. The hard prohibition comes from the Chrome Root Program Policy v1.8, Section 1.3.2, which requires that all subscriber certificates issued on or after March 15, 2027 include only id-kp-serverAuth. CAs must comply with this policy to remain in the Chrome Root Store, making the restriction practically universal.

Ballot SC-081 also introduces a phased reduction in the maximum validity period for publicly trusted TLS certificates. Validity reduces to 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. Shorter-lived certificates make automated enrollment via ACME, WSTEP, SCEP, and EST, a requirement rather than a convenience. Any organization relying on manual certificate renewal will face an unsustainable operational burden as validity windows shrink. This reinforces the case for a managed private PKI with fully automated lifecycle management built in from day one.

The Public CA Timeline

The most critical date for organizations is June 15, 2026, when Chrome will actively reject public TLS certificates containing the clientAuth EKU from this point. Any new Subordinate CA (Intermediate CA) disclosed to the Common CA Database (CCADB) on or after this date must carry only id-kp-serverAuth. No new mixed-EKU intermediate CAs can be added to Chrome-trusted hierarchies from this date. Any system presenting such a certificate in a Chrome-validated TLS handshake will fail. Existing certificates issued before this date remain valid until expiry, but once they renew, they will be issued without clientAuth.

CAs have not waited for the hard deadline of March 2027. Most major CAs began removing clientAuth well ahead of it, driven by Chrome’s June 2026 intermediate CA deadline, and following is the complete timeline as of June 2026:

Date	CA / Program	Milestone	Status
Sept 15, 2025	SSL.com	Stops issuing clientAuth by default	PASSED
Oct 1, 2025	DigiCert	Stops issuing clientAuth by default	PASSED
Oct 14, 2025	Sectigo	Stops issuing clientAuth by default	PASSED
Feb 11, 2026	Let’s Encrypt	Default ACME profile removes clientAuth	PASSED
June 15, 2026	Google Chrome	Rejects public TLS certs with clientAuth EKU	CRITICAL
July 8, 2026	Let’s Encrypt	tlsclient profile permanently discontinued	UPCOMING
Feb 10, 2027	Sectigo	Hard deadline, no exceptions	UPCOMING
Mar 1, 2027	DigiCert	Full removal, no exceptions	UPCOMING
Mar 15, 2027	Chrome Root Program	Final industry deadline	DEADLINE

Why Is Client Authentication EKU Being Removed?

It is tempting to frame this mandate purely as a compliance burden. In reality, it closes a genuine and underappreciated security gap. Understanding the following security rationale helps organizations appreciate why this change is being enforced:

• The Public Web PKI Was Built for Authenticating Servers to Browsers: The Domain Validation (DV) and Organization Validation (OV) processes used by public CAs are designed to verify domain ownership and organizational identity for the purpose of server authentication. They are not designed to establish that a given system is authorized to act as a client in a specific authentication context. Including clientAuth EKU in a publicly issued certificate implies a validation standard that was never performed.
• Private Key Compromise Has Amplified Consequences: When a TLS server certificate carries both serverAuth and clientAuth, a compromised private key does double damage. An attacker who exfiltrates a server’s private key can not only impersonate that server to clients but also present that certificate as a valid client credential to any system that trusts the issuing CA and checks for the clientAuth EKU. A single compromise becomes lateral movement capability. Removing clientAuth from server certificates eliminates this second attack vector entirely.
• Separation Enables Proper Lifecycle Management: Server certificates and client certificates have fundamentally different lifecycle requirements. Server certificates are tied to domain names, renewed on public infrastructure, and managed by web operations teams. Client certificates are tied to system identities and require revocation capabilities that are enforced at the application level. Collapsing them into a single certificate makes both harder to manage correctly. Separation restores clear ownership and accountability.

The Impact of Removing the Client Authentication EKU

The removal of the clientAuth EKU affects organizations that currently use a publicly trusted TLS server certificate for client authentication.

Organizations that use public certificates solely for standard HTTPS server authentication are generally unaffected. Their websites, portals, and public-facing applications can continue using certificates containing only the serverAuth EKU.

The impact arises when the same public certificate is also used to authenticate a user, device, server, application, or workload to another system. When that certificate is renewed or reissued without the clientAuth EKU, the receiving system may no longer accept it as a valid client credential.

Importantly, the certificate may still be valid, unexpired, and trusted. The failure occurs because the certificate is no longer authorized for client authentication.

To help you identify what could break and why, the following table highlights the potential areas of impact across your organization.

Use Case	Potential Impact
Mutual TLS (mTLS)	During an mTLS connection, the receiving system may verify that the client’s certificate includes the clientAuth EKU. If that EKU is missing, the certificate may be rejected and the TLS handshake will fail. This can affect microservices, API gateways, service meshes, business-to-business integrations, and custom application-to-application authentication. The error may appear as a generic TLS handshake or certificate validation failure rather than an expiration issue.
RADIUS, IEEE 802.1X, and EAP-TLS	In certificate-based network authentication, users or devices present a client certificate to prove their identity. If the authentication server requires the clientAuth EKU and the renewed certificate does not contain it, the authentication request will fail. As a result, affected devices may be unable to connect to enterprise Wi-Fi, wired networks, or VPN services.
OpenVPN, Cisco Secure Client, and Fortinet VPN	Many certificate-based VPN deployments require the connecting user or device certificate to contain the clientAuth EKU. If a public certificate previously used for VPN authentication is renewed without that EKU, the VPN gateway may reject it. Users may then be unable to establish a secure remote-access connection.
Microsoft Exchange and Server-to-Server Communication	SMTP connector, EWS, and partner communication configurations use certificates for mutual or server-to-server authentication. Where the connecting server’s certificate is expected to support client authentication, removing the clientAuth EKU may disrupt authentication or mail flow. The actual impact depends on the Exchange version, connector configuration, and certificate-validation requirements.
Remote Desktop and RDP Gateway Environments	Remote Desktop Gateway typically uses a server certificate to authenticate itself to connecting clients. However, environments that also use certificate-based client authentication, smart-card authentication, or custom mutual-authentication controls may depend on dedicated client certificates. Reusing a public server certificate for such a purpose may cause authentication failures after renewal.
IoT and Device Identity	IoT, industrial, and embedded devices may use certificates to authenticate to cloud services, management platforms, or device gateways. If a device certificate is renewed without the required clientAuth EKU, the platform may reject the device identity. This can prevent device check-in, telemetry submission, remote management, software updates, or command execution.
API and Server-to-Server Authentication	Applications and servers frequently act as TLS clients when calling internal or external APIs. If they present a public TLS certificate as their client identity, the receiving API may reject the certificate once clientAuth is removed. This can interrupt integrations even though the same certificate continues to work normally for incoming HTTPS connections.
CI/CD and DevOps Workloads	Build servers, deployment agents, containers, and automation platforms may use certificates to authenticate to registries, Kubernetes clusters, artifact repositories, or internal APIs. When a renewed certificate no longer supports client authentication, automated pipelines may fail without an immediately obvious certificate-related cause.

Why These Failures Can Be Difficult to Diagnose

The removal of clientAuth does not necessarily produce a clear message stating that the EKU is missing. Depending on the application, operating system, or TLS library, the failure may be reported as:

• TLS handshake failure
• Certificate purpose not permitted
• Unsupported certificate
• Bad certificate
• Access denied
• Client identity rejected
• Peer verification failure
• Authentication timeout

This makes the issue easy to misdiagnose as a trust chain, expiration, network, cipher suite, or application configuration problem.

The most significant risk is not limited to certificates already known to support mutual TLS. It includes undocumented systems that have been relying on the clientAuth EKU because public TLS certificates historically included it by default.

Organizations should identify these dependencies before the affected certificates are renewed or reissued. Waiting until renewal may turn a routine certificate replacement into an unexpected outage affecting application connectivity, network access, remote access, or device authentication.

The Solution: Transition to a Private CA

Publicly trusted Certificate Authorities are being restricted from issuing TLS certificates for client authentication (i.e., certificates that include the clientAuth EKU). As a result, organizations can no longer rely on public TLS certificates for internal client authentication use cases such as mutual TLS, device authentication, workload identity, API authentication, and server-to-server communication.

A private PKI solves this challenge because it operates outside the browser-trusted public PKI ecosystem. Its root CA is trusted only by the users, devices, applications, and systems selected by the organization. Therefore, the organization can issue dedicated client certificates that include the clientAuth EKU without affecting or relying on public browser trust.

Private PKI also enables proper separation between the two certificate purposes:

• Public or private server certificates containing only the serverAuth EKU
• Dedicated private client certificates containing only the clientAuth EKU (OID 1.3.6.1.5.5.7.3.2), with no serverAuth OID present, as shown in the screenshot below:

This separation ensures that a server certificate is used only to authenticate a server, while a client certificate is used only to authenticate a user, device, application, or workstation. It reduces the impact of private-key compromise and provides clearer control over certificate issuance, ownership, renewal, and revocation.

With a private PKI, organizations can also define certificate policies to meet their specific security requirements, including identity validation procedures, certificate validity periods, naming conventions, approved algorithms, key protection requirements, and enrollment methods. Certificates can be automatically issued and renewed using protocols such as ACME, SCEP, EST, CMP, WSTEP, or Microsoft Auto-Enrollment.

This shift empowers organizations to design authentication workflows tailored to their specific needs, without being constrained by public CA limitations. The following section describes what the PKI hierarchy should look like.

How the PKI Hierarchy Must Change

Removing the clientAuth EKU from publicly trusted TLS certificates is not simply a certificate template change. It requires organizations to separate public server authentication from internal client authentication at the PKI architecture level.

Under the new model, publicly trusted certificates should be used only for authenticating servers to external clients, such as browsers connecting to websites and public-facing applications. These certificates contain only the serverAuth EKU and continue to chain to a publicly trusted root CA.

Client authentication must move to a separate private PKI hierarchy. This private hierarchy issues purpose-specific certificates to users, devices, applications, workloads, and servers that need to authenticate as clients.

The target architecture should therefore include:

• A public TLS PKI hierarchy for internet-facing server certificates containing only serverAuth
• A private offline, non-domain-joined root CA secured with a FIPS 140-3 Level 3 compliant Hardware Security Module
• One or more private issuing CAs dedicated to client authentication. HSM-backed protection for Issuing CA private keys
• Client certificate profiles scoped to the clientAuth EKU only (no serverAuth OID present), with Key Usage set to digitalSignature, so the certificate cannot be used for server authentication under any circumstances.

  

• Separate certificate profiles for devices, users, workloads, APIs, and other identities
• CRL or OCSP services for certificate revocation, with CDP endpoints configured as public or private based on the use case and the organization’s accessibility requirements
• Automated certificate enrollment, renewal, and revocation
• Distribution of the private root CA to systems that must trust the client certificates

Under this architecture, a server that performs both roles may need two separate certificates:

1. A server certificate containing serverAuth for accepting inbound TLS connections
2. A client certificate containing clientAuth for authenticating when connecting to another system

This separation ensures that each certificate and private key has one clearly defined purpose. It also enables organizations to apply different identity-validation, lifecycle, revocation, and key-protection policies to server and client identities.

Designing, deploying, and continuously operating this private hierarchy requires specialized PKI expertise, secure HSM infrastructure, certificate lifecycle automation, revocation services, monitoring, disaster recovery, and ongoing policy management. The following section of this blog walks through exactly how Encryption Consulting’s PKIaaS delivers a fully managed private CA built, operated, and kept compliant on your behalf.

PKIaaS by Encryption Consulting

Building and operating a private PKI hierarchy is not technically complex in concept, but it is demanding in execution, including the procurement of HSMs, offline root CA ceremonies, CDP/AIA accessibility, certificate lifecycle automation, policy documentation, and enrollment operations.

Encryption Consulting’s PKI-as-a-Service (PKIaaS) can meet tight deadlines and deliver a complete private PKI as a managed service. Encryption Consulting builds it, runs it, and keeps it compliant, while full ownership remains yours.

No Vendor Lock-In: Your private keys, CA hierarchy, and certificates remain entirely yours. Should you decide to migrate the PKI to your on-premises environment, Encryption Consulting will conduct a formal, documented key-transfer ceremony. The CA private key material will be securely transferred to your HSM using authenticated, dual-controlled export procedures.

Your existing certificates will remain valid, with no need for reissuance. The entire transfer process will be fully documented and auditable, ensuring operational continuity and complete ownership.

You own the PKI. We build, manage, and operate it on your behalf. Here is exactly how the engagement works.

Phase 1: Discovery and Certificate Inventory

Before designing the new PKI, Encryption Consulting develops a complete view of the customer’s current certificate environment. This is critical because many systems rely on clientAuth without that dependency being formally discovered.

We support multiple certificate discovery methods, including network scanning, agentless scanning, and integration-based discovery.

Integration-based discovery provides a real-time, authoritative view of certificate data by connecting directly with Certificate Authorities and cloud platforms such as AWS, Microsoft Azure, and Google Cloud. It can also examine application configurations, including mTLS settings, and integrate with Kubernetes clusters, secrets-management platforms such as HashiCorp Vault and CyberArk Conjur, and CI/CD pipelines, including GitHub Actions, Jenkins, and GitLab.

Additional discovery capabilities include passive monitoring through proxies, firewalls, and network taps; directory scanning across LDAP and Active Directory; and discovery through configuration-management tools such as Ansible, Chef, and Puppet.

The output is a complete certificate inventory containing certificate subjects, SANs, EKUs, issuers, and expiration dates. Each certificate that carries clientAuth is mapped to both the system that presents it and the system that relies on it for authentication.

The findings are then organized into a risk-ranked migration timeline. The customer receives a clear view of which systems may fail, when they are at risk, and the potential business impact if a certificate is renewed without clientAuth.

Phase 2: PKI Architecture Design

Nothing is built until the architecture is reviewed and signed off. Every CA, every certificate template, and every revocation endpoint is specified on paper before any key is generated.

The architecture typically includes an offline non-domain-joined Root CA and separate Issuing CAs for client authentication, internal TLS, and device identity authentication. This separation ensures that client certificates contain only clientAuth.

Certificate profiles are defined for each use case, including algorithms, validity periods, subject and SAN formats, Key Usage, EKU, policy OIDs, and revocation endpoints. CRL and OCSP locations are configured as public or private based on where the certificates will be used.

This creates a clear, purpose-driven hierarchy with no dual-EKU certificates and no ambiguity about what each certificate is authorized to do.

Phase 3: Root CA Ceremony and Infrastructure Build

The Root CA private key is generated and protected within a FIPS 140-3 Level 3-compliant Hardware Security Module (HSM). The Root CA remains securely hosted within the data center and is kept offline between authorized certificate-signing operations. For disaster recovery, an encrypted and access-controlled backup of the key material is maintained within a geographically separate HSM environment.

Encryption Consulting then builds the supporting PKI infrastructure, including hardened Issuing CAs, OCSP responders, CRL publication services, certificate management capabilities.

Phase 4: Trust Store Distribution

Certificates issued by a private PKI are trusted only when the private root CA is installed on every system that validates them. This phase distributes the new private root CA certificate to all relying party systems in scope.

Windows domain-joined systems receive the root CA via Group Policy, pushed to the Trusted Root Certification Authorities store. Linux systems are updated using update-ca-certificates, deployed through Ansible, Chef, or Puppet depending on the existing configuration management toolchain.

After distribution, representative systems are tested using newly issued client certificates. This phase is completed only after the customer confirms that certificate chains are trusted and authentication succeeds.

Phase 5: PKIaaS Gateway Deployment

This phase deploys the PKIaaS Gateway a set of enrollment and management components installed inside the client’s own infrastructure. The gateway bridges the client’s internal systems to Encryption Consulting’s hosted CA hierarchy. All certificate requests flow through it. The CA private keys remain in Encryption Consulting’s HSMs at all times the gateway handles enrollment protocol traffic only, never signing operations.

The gateway exposes a WS-Trust Enrollment Protocol (WSTEP) endpoint, enabling fully automated certificate enrollment for Windows machines without any user or administrator interaction. The Certificate Enrollment Policy service (CEP) is configured to discover which certificate templates it is eligible for based on its Active Directory identity and group policy membership.

The Certificate Enrollment Web Service validates the request against the enrollment policy, routes it through the PKIaaS Gateway to the issuing CA, and returns the signed certificate directly to the machine, which installs it into the correct certificate store automatically. From GPO configuration onward, the entire lifecycle, policy discovery, request, signing, installation, and renewal, requires zero manual intervention.

A web-based dashboard where authorized users can request certificates, submit CSRs, search the certificate inventory, renew certificates, revoke compromised or unused certificates, and review certificate status.

The dashboard includes role-based access control. Certificate managers may request or revoke certificates, auditors may review reports and activity logs, and administrators may manage approved profiles and enrollment policies.

Every enrollment, renewal, revocation, approval, configuration change, and administrative login is recorded in an auditable activity log.

Phase 6: Certificate Migration: System by System

Once trust and enrollment services are operational, Encryption Consulting begins replacing dual-EKU public certificates with dedicated private client certificates.

Migration starts with development and staging environments. Internal services and APIs are migrated next, followed by network infrastructure, including VPN, RADIUS, and 802.1X. Business-critical systems, including Exchange, core applications, and systems within the organization, are migrated only after testing and rollback procedures are confirmed.

Each certificate request is submitted using the appropriate enrollment method, such as WSTEP, ACME, SCEP, EST, or the management dashboard. The new certificate is issued with only the clientAuth EKU. The application is configured to present the new certificate, and an end-to-end authentication test confirms that the connection succeeds.

After successful validation, the old dual-EKU certificate is removed or revoked where appropriate, and the new certificate is enrolled in automated renewal.

Phase 7: Ongoing Operations and Compliance

This phase is where PKIaaS provides continuous value beyond the initial build.

Encryption Consulting’s CLM platform manages certificate issuance, renewal, revocation, CRL publication, OCSP availability, HSM monitoring, infrastructure maintenance, backup validation, and PKIaaS Gateway operations on an ongoing basis.

Enrollment services such as WSTEP, ACME, SCEP, and EST are continuously maintained so that certificates can be issued and renewed without manual intervention.

Encryption Consulting also monitors relevant organization’s security requirement, CA/Browser Forum developments, cryptographic standards, algorithm changes, and certificate-policy updates, such as Post Quantum Cryptography compatibility. Where a change affects the customer’s environment, the PKI configuration and certificate profiles are updated before the applicable deadline.

Conclusion

The removal of the clientAuth EKU from publicly trusted TLS certificates marks a fundamental shift in how organizations must manage certificate-based authentication. Public certificates will continue to secure websites and external services, but client authentication for users, devices, applications, and workloads must move to a purpose-built private PKI. Organizations that fail to identify hidden dual-EKU dependencies risk unexpected outages when certificates are renewed without clientAuth; failures that will not announce themselves as certificate errors but as authentication timeouts, TLS handshake failures, and access denied messages with no obvious cause.

Encryption Consulting’s PKIaaS provides a complete path through this transition. We assess the existing environment, identify affected systems, design and build the private PKI, protect CA keys within HSMs, deploy enrollment services, migrate certificates, and manage the environment on an ongoing basis. Automated enrollment through WSTEP, ACME, SCEP, and EST ensures that certificates are issued, renewed, and revoked without introducing additional operational burden.

To start with a complimentary PKI Readiness Assessment, contact us at [email protected] or visit encryptionconsulting.com/pkiaas.

Frequently Asked Questions

What is the main takeaway from The CA/Browser Forum Mandate: The End of Dual-EKU Certificates?

CA/Browser Forum Ballot SC-081v3 (April 2025) and Chrome Root Program Policy v1.8 eliminate clientAuth from publicly trusted TLS certificates on a firm schedule. From June 15, 2026, no new intermediate CA in a Chrome-trusted hierarchy may carry dual EKU values. From March 15, 2027, every newly issued publicly trusted TLS leaf certificate must contain only serverAuth. Organizations using public certificates for mTLS, RADIUS, VPN, IoT device identity, or server-to-server authentication must migrate those use cases to a dedicated private PKI hierarchy before these deadlines or face silent authentication failures when affected certificates are renewed.

Why does the dual-EKU mandate matter for enterprise PKI teams?

Enterprise PKI teams face two converging pressures from the same ballot. The DigiCert Trust Pulse Survey (July 2, 2025) found 45 percent of organizations experienced certificate-related downtime in the prior year; the dual-EKU mandate introduces exactly the silent failure mode that produces that downtime: a certificate renewed without clientAuth continues to work for HTTPS but fails all client authentication use cases with generic errors. Simultaneously, SC-081v3 reduces maximum TLS validity to 47 days by March 2029, meaning renewal events that expose dual-EKU dependencies occur up to eight times per year rather than once.

What risks increase if the dual-EKU transition is handled manually or reactively?

Four risk categories increase: silent authentication outages (generic error messages that are easy to misdiagnose); undiscovered dependencies (systems relying on clientAuth without formal documentation); compressed remediation time (at 47-day validity, the window between renewal and failure is six weeks rather than twelve months); and post-quantum migration gaps (private CA key algorithms must also migrate to ML-DSA per NIST FIPS 204, finalized August 13, 2024; an unplanned private PKI is harder to include in the migration roadmap).

Which teams should own the dual-EKU transition?

PKI and certificate teams own the private CA hierarchy design and certificate template separation. Security architects own the governance model: private root CA trust distribution, enrollment protocol selection, and post-quantum migration planning for private CA key algorithms. Platform and DevOps teams own the application-level migration: reconfiguring mTLS, RADIUS, VPN, IoT, and CI/CD systems. Compliance teams own the audit evidence confirming migration is complete before the March 15, 2027 deadline.

How does the dual-EKU mandate connect to certificate lifecycle management?

The mandate is a certificate lifecycle event: every public TLS certificate currently carrying clientAuth will lose that EKU on its next renewal. Certificate discovery and inventory are prerequisites for safe lifecycle management: organizations that do not know which certificates carry clientAuth cannot safely manage the renewal lifecycle without risk of causing authentication outages. CertSecure Manager provides the CLM layer: automated discovery of clientAuth dependencies, policy enforcement at issuance (EKU-separated profiles), automated renewal via WSTEP/ACME/SCEP/EST, revocation management, and audit-ready reporting.

How should organizations measure success in the dual-EKU transition?

Key metrics: zero publicly trusted certificates carrying both serverAuth and clientAuth; 100 percent of client authentication use cases migrated to private clientAuth-only certificates; zero authentication outages attributable to clientAuth removal on renewal; private PKI enrollment automation coverage (percentage of client certificates on automated renewal); and post-quantum readiness classification (private CA key algorithms classified against NIST IR 8547 deprecation milestones with migration timeline defined). Report these quarterly against the CA/Browser Forum deadline schedule.

What should be audited or monitored regularly?

Monitor continuously: certificate inventory for publicly trusted certificates carrying both serverAuth and clientAuth, with renewal alerts flagging dual-EKU certificates before renewal; mTLS, RADIUS, VPN, and IoT authentication success rates for early detection of clientAuth removal failures. Audit quarterly: percentage of client authentication use cases migrated to private certificates; private CA enrollment automation coverage; private CA key algorithm classification against NIST FIPS 203/204/205 (finalized August 13, 2024); compliance evidence completeness for the March 15, 2027 deadline.

How does the dual-EKU mandate affect cloud, hybrid, or multi-CA PKI environments?

Cloud and hybrid environments typically have the highest density of undiscovered dual-EKU dependencies: microservices using mTLS with public certificates, cloud-native workloads using certificate-based authentication to cloud APIs, Kubernetes clusters using certificates for service mesh identity, and CI/CD pipelines authenticating to registries. Multi-CA environments need a centralized CLM layer that discovers clientAuth dependencies across all CA sources, not just the public CA inventory, including AWS Private CA, HashiCorp Vault PKI, and Microsoft AD CS.

What common mistakes should teams avoid?

The most frequent mistakes: not discovering clientAuth dependencies before certificates are renewed; treating the mandate as a certificate template change only without separating the PKI hierarchy at the CA level (Chrome Root Program Policy requires CA-level separation); not distributing the private root CA to all relying party systems before migrating; building a private PKI under deadline pressure without planning for post-quantum migration of private CA key algorithms; and not enrolling migrated client certificates in automated renewal processes that can sustain 47-day validity from March 2029.

What should be refreshed quarterly?

Quarterly: audit the certificate inventory for publicly trusted certificates still carrying clientAuth; verify the private root CA has been distributed to all new systems added since the last audit; confirm private CA enrollment automation coverage for all client authentication use cases; classify private CA key algorithms against NIST post-quantum deprecation milestones (ML-DSA per FIPS 204, finalized August 13, 2024); verify no new dual-EKU intermediate CAs have been disclosed to CCADB in Chrome-trusted hierarchies (prohibited from June 15, 2026). For post-quantum private CA key algorithm migration planning, check the PQC Center of Excellence.