The Password Is Dead. Is Your Network Ready for Its Replacement?
Your organization has spent years locking down the front door: firewalls, VPNs, multi-factor authentication, endpoint protection. But there’s a quieter question that many IT teams haven’t fully answered yet: when a device, a server, or a service tries to prove it is who it says it is, what’s actually backing that claim?
For many organizations, the honest answer is “a password” or “an API key.” And both of those can be stolen, phished, or replayed by anyone who gets their hands on them.
There’s a better answer, and it’s one that browsers and root programs are now effectively requiring: a dedicated Client Authentication Certificate.
Explore Client Authentication Certificate Options
Why This Is Suddenly Urgent
Here’s the change that forced the issue. Since June 15, 2026, Chrome’s Root Program requires newly issued publicly trusted TLS server certificates to include only the serverAuth EKU. Mozilla, Apple, and Microsoft have adopted compatible root program policies, ending the use of clientAuth EKUs in publicly trusted TLS server certificates.
If your organization was reusing a standard TLS certificate to also handle client authentication or mutual TLS (mTLS), that shortcut no longer works. Any dual-purpose certificate that served as both a server and a client identity is no longer valid for client authentication and must be replaced with a certificate built specifically for that purpose, which SSL provides.
Any organization still relying on an old dual-purpose certificate is already out of compliance today, and the exposure only grows the longer it goes unaddressed. It affects anyone using certificate-based authentication for mTLS, Zero Trust access, VPNs, Wi-Fi network access, IoT devices, industrial control systems, or energy market platforms.
What a Client Authentication Certificate Actually Does
Think of your regular TLS certificate as your server’s ID badge. It proves the server is who it claims to be when your browser connects to it. A Client Authentication Certificate flips that conversation around. It lets a device, user, server, or service prove its own identity back to whatever it’s connecting to.
The mechanics matter here, but only because of what they mean for your business. The private key is generated on the device itself and never leaves it. A publicly trusted Certificate Authority (such as SSL) only ever signs the public key, binding it to a verified identity. That means there’s no password sitting in a database somewhere waiting to be phished, no shared secret that leaks in a breach, and no API key copied into a script that someone forgot to rotate.
Revocation also works per certificate, not per fleet. If a laptop is lost, a contractor’s access ends, or a device is compromised, you revoke that one certificate and every other endpoint keeps running without interruption.
The Key Benefits, at a Glance
Here’s what switching to a dedicated Client Authentication Certificate actually gets you:
- Phishing-resistant identity. The private key never leaves the device, so there’s no password to steal, replay, or phish.
- Chrome and root program compliant. A dedicated clientAuth EKU that meets CA/Browser Forum and root store requirements, so you’re not caught out by the policy change that started all of this.
- Publicly trusted hierarchy. Issued from SSL’s WebTrust-audited public PKI, with no need to distribute a private root across your relying-party stack.
- Three validation levels. IV, OV, and IV+OV (Sponsor), so the credential matches your identity policy and any regulatory requirements you’re working under.
- Granular revocation. Revoke a single certificate the moment a device is lost, decommissioned, or compromised, without touching the rest of your fleet.
- API-first issuance. Issue at scale today through SSL’s REST API, with ACME and SCEP/EST automation on the way.
Matching the Credential to the Use Case
Individual Validation (IV) confirms the real identity of a named person, which makes it a natural fit for employee devices, BYOD policies, and individual endpoint access. Organization Validation (OV) confirms the legal existence of a company, which is what you want for servers, virtual machines, service accounts, and API clients. And for situations where you need both, such as privileged users, contractors, or regulated industries, there’s IV+OV (Sponsor Validation), which binds an individual’s identity to the sponsoring organization at the same time.
That flexibility matters because client authentication shows up in more places than most people realize:
|
Use Case |
Cert Level |
Compatible With |
Notes |
|
mTLS / Zero Trust |
OV / IV+OV |
Nginx, Envoy, Istio, Kong, AWS API GW |
Mutual TLS; both peers authenticate with X.509 |
|
VPN (Certificate-Based) |
IV / OV / IV+OV |
Cisco ASA/FTD, Palo Alto, Fortinet, Juniper SRX |
Eliminates password-based VPN; phishing-resistant |
|
Wi-Fi (802.1X / EAP-TLS) |
IV / OV |
Cisco ISE, Aruba ClearPass, Microsoft NPS |
NAC enforcement; credential on device, not in a password |
|
IoT / Device Identity |
OV |
AWS IoT Core, Azure IoT Hub, custom brokers |
Per-device cert; individual revocation without re-flashing fleet |
|
OT / SCADA / ICS |
OV |
Claroty, Nozomi, Dragos; IEC 62443-aware stacks |
Authenticates PLCs, HMIs, historian nodes on OT networks |
|
NAESB Energy Markets |
IV+OV |
NAESB WEQ-12 compliant platforms |
Required credential for OATI, PowerSecure, and other EIS platforms |
|
API Gateway Auth |
OV / IV+OV |
Apigee, Kong, AWS API GW, Azure APIM |
Replaces API keys and JWTs with cert-bound service identity |
On top of those specific use cases, the certificates work broadly across the infrastructure your team already runs:
- TLS stacks: OpenSSL, BoringSSL, NSS, SChannel, SecureTransport, wolfSSL, and mbedTLS.
- VPN and remote access: Cisco AnyConnect/SecureClient, Palo Alto GlobalProtect, Fortinet FortiClient, OpenVPN, and WireGuard (via external auth).
- NAC and 802.1X: Cisco ISE, Aruba ClearPass, Microsoft NPS/RADIUS, FreeRADIUS, and Juniper Access Control.
- API gateways: Kong, Nginx, Envoy, Istio, AWS API Gateway (mTLS), Azure API Management, and Apigee.
- ICS and OT: IEC 62443-aware platforms, including the asset discovery and authentication layers in Claroty, Nozomi Networks, and Dragos.
Getting Certificates Out the Door
However your organization prefers to issue certificates, SSL has a path that fits:
|
Method |
Who It Is For |
How It Works |
|
Web UI (ssl.com Dashboard) |
IT admins, smaller deployments, one-off issuance |
Log in to ssl.com, select Client Authentication, choose validation level, complete verification, generate and download certificate. No coding required. |
|
REST API |
DevOps, CI/CD pipelines, large-scale fleet provisioning |
Programmatic certificate ordering, CSR submission, and download via SSL’s documented REST API. Supports bulk issuance and integration with orchestration platforms. |
|
ACME / SCEP / EST |
Enterprise MDM, IETF-standard automation (planned) |
Protocol-based lifecycle automation via ACME (RFC 8555), SCEP, and EST (RFC 7030). In development — contact sales for timeline and early-access details. |
How to Buy
Client Authentication Certificates are available directly from SSL with no minimum commitment:
- Self-service. Configure and purchase online.
- Enterprise and volume. Contact the SSL sales team for volume pricing, dedicated account management, and NAESB-specific onboarding.
- Private hierarchy or dual-EKU needs. If you need a private hierarchy, a custom certificate profile, or a dual-EKU certificate, SSL’s Private PKI products (High Assurance Private Certificates, Dedicated PKI, and Enterprise PKI) are the correct path. Contact sales for a referral.
The Bottom Line
The clientAuth EKU change wasn’t just a technical footnote. It was a forcing function that’s pushing organizations to finally separate server identity from client identity, and to replace passwords and API keys with something that can’t be phished or replayed.
SSL has been operating a WebTrust-audited public Certificate Authority for over 20 years, and the Client Authentication Certificate is the direct, compliant path forward for any organization that needs dedicated client identity at scale, whether that’s securing a Zero Trust network, a fleet of IoT devices, or a NAESB-regulated trading platform.
If you’re not sure whether your current setup still relies on a dual-purpose certificate, now is the time to check. The enforcement date has already passed, so closing that gap is no longer optional, but we’re ready to help.
Is your mTLS affected by the clientAuth EKU removal? Audit your certificates for the clientAuth EKU, then talk to SSL about migrating to dedicated Client Authentication Certificates (or Private PKI for internal-only / dual-EKU needs) before your current certificates expire:
