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.
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:
- 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.
- 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. 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:
- A server certificate containing serverAuth for accepting inbound TLS connections
- 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.
