Applications that depended on dual-purpose public certificates will lose a simple path for mTLS and client authentication. The main failure is not encryption, but trust semantics: one certificate can no longer safely represent both server identity and client identity in browser-trusted environments. Teams need a new certificate profile or a private PKI path.
Why This Matters for Security Teams
When public TLS certificates stop supporting client authentication, the breakage is not limited to certificate issuance. It cuts into trust design, automated onboarding, and the way teams distinguish server identity from workload identity. That matters because machine and workload identities already outnumber human identities in many environments, and lifecycle mistakes are common. NHI Management Group’s Ultimate Guide to NHIs shows how widely these identities are embedded across infrastructure, while the NIST Cybersecurity Framework 2.0 reinforces that identity, asset, and access governance must be intentional rather than implicit.
The key failure mode is that a single browser-trusted certificate can no longer do two jobs safely. Public trust anchors are optimized for server authentication, not for asserting a client’s right to present itself to another service. Teams that relied on dual-purpose public certs often discover that mTLS, service-to-service auth, and internal API access were coupled to an assumption that no longer holds. In practice, many security teams encounter this only after rollout pipelines, gateways, or production integrations have already been built around the old certificate semantics.
How It Works in Practice
The operational impact shows up in three places: certificate profile design, trust distribution, and automation. Public certificates can still encrypt traffic and authenticate servers, but if client authentication is removed, they can no longer serve as a shared identity primitive for both sides of the connection. That forces organisations to choose between a private PKI path, a separate client certificate profile, or a workload identity model that issues short-lived credentials based on cryptographic proof rather than browser trust.
Current guidance suggests separating concerns: use public TLS certificates for external server identity, and use a distinct mechanism for client identity such as private CA-issued certs, SPIFFE/SPIRE workload identities, or short-lived OIDC-based tokens where appropriate. The broader control objective is to move from static, dual-use credentials to explicit, task-specific trust. That includes automated issuance, renewal, revocation, and inventory tracking so certificates do not become hidden long-lived dependencies.
- Define one certificate profile for server authentication and a different one for client authentication.
- Use short TTLs and automation for issuance and renewal to reduce reliance on manual tracking.
- Map service-to-service trust to workload identity, not just certificate possession.
- Validate that gateways, service meshes, and legacy clients can enforce the new separation without breaking interoperability.
SailPoint’s research on The Critical Gaps in Machine Identity Management report notes that only 38% of organisations have automated certificate lifecycle management, which explains why this change often exposes hidden operational debt. These controls tend to break down when legacy applications require a single certificate object to satisfy both external trust and internal client authentication because the surrounding tooling cannot express separate identity roles.
Common Variations and Edge Cases
Tighter certificate separation often increases operational overhead, requiring organisations to balance security clarity against migration complexity. The hardest cases are older middleware stacks, appliance-based integrations, and service meshes that assumed a dual-purpose certificate forever. Best practice is evolving, and there is no universal standard for every environment yet.
One common variation is phased coexistence: public certificates remain in place for server trust while a private PKI or workload identity layer is introduced for client auth. Another is emergency compatibility, where short-lived internal client certs are issued only for the systems that cannot yet move to token-based or SPIFFE-style identity. Security teams should be careful not to recreate the same risk with long-lived private certs simply by changing issuers.
The practical edge case is identity sprawl. If every service, pipeline, and gateway gets its own cert policy without inventory and ownership discipline, the migration can create more exceptions than the old model had. That is why NHI governance guidance from NHI Management Group and the identity lifecycle principles in NIST Cybersecurity Framework 2.0 both point toward explicit ownership, rotation, and revocation. The transition breaks down most often in brownfield estates where certificate consumers cannot distinguish a server cert from a client cert without custom configuration.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Client-auth cert changes expose weak rotation and lifecycle handling for machine identities. |
| CSA MAESTRO | ID-1 | Agent and workload trust must be explicit when public certs no longer carry client identity. |
| NIST AI RMF | GOVERN | Identity changes for autonomous systems need clear governance and ownership. |
Adopt workload identity and short-lived credentials instead of relying on dual-use public certs.
