TLS client authentication and the trust gap in mTLS governance

At a glance

What this is: This comparison explains how self-signed and CA-signed TLS client authentication differ in trust model, operational scale, and certificate governance for mTLS.

Why it matters: IAM and NHI teams need to align certificate trust with lifecycle control, because manual trust lists and weak revocation handling can create hidden access risk.

By the numbers:

• More than 80% of organizations expose sensitive data through poorly secured APIs.

👉 Read Raidiam's comparison of self-signed and CA-signed mTLS client authentication

Context

TLS client authentication is a control for proving client identity during the TLS handshake, and it matters because certificates function as non-human credentials with their own issuance, trust, rotation, and revocation lifecycle. In practice, the governance challenge is not whether mTLS exists, but whether the organisation can prove who or what a certificate represents across internal services, partner APIs, and OAuth-linked environments.

For NHI practitioners, the key distinction is between manual trust and standards-based trust. Self-signed client certificates can work in tightly controlled environments, but they rely on explicit registration and small trust stores. CA-signed certificates scale better across federated ecosystems, which is why they align more naturally with Open Banking, OpenID Connect, and broader NHI lifecycle management.

This is a familiar pattern for teams that already use certificate-based workload identity. The topic maps closely to the discipline behind SPIFFE and SPIRE, where identity is bound to workloads and trust is automated rather than hand-maintained. The article’s starting position is typical for teams that already understand the difference between local convenience and production-grade trust governance.

Key questions

Q: When should organisations use self-signed TLS client authentication instead of CA-signed mTLS?

A: Use self-signed TLS client authentication only when both ends are under the same administrative control and the client population is small enough to trust manually. It is suitable for internal microservices, CI/CD tooling, or test environments. Once you need third-party onboarding, broad federation, or strong auditability, CA-signed mTLS is the safer operating model.

Q: How do security teams manage certificate lifecycle risk in mTLS?

A: Treat certificates as NHI credentials with explicit ownership, expiry, and revocation processes. Automate issuance and renewal where possible, monitor for stale trust entries, and keep trust stores small enough to audit regularly. The goal is to prevent valid certificates from outliving their intended access scope.

Q: What is the difference between self-signed and CA-signed client certificates?

A: Self-signed certificates rely on explicit server-side trust, usually through a local certificate or Distinguished Name match. CA-signed certificates are verified against a certificate chain anchored in a trusted authority, which makes them easier to scale, audit, and revoke across many clients.

Q: Why do mTLS deployments still need access governance after authentication succeeds?

A: Because successful authentication only proves possession of a valid certificate, not that the identity should still have access. If certificates are not rotated, scoped, and revoked on time, a technically valid client can keep working after the business reason for access has ended. That is a governance failure, not a cryptography failure.

Technical breakdown

How self-signed tls_client_auth works in controlled environments

Self-signed TLS client authentication works when the server explicitly trusts a certificate or a subject Distinguished Name that it has registered out of band. The client presents an X.509 certificate during the TLS handshake, proves possession of the private key, and the server checks that certificate against a local trust list. This removes dependence on an external Certificate Authority, but it also shifts trust administration into manual configuration. The result is workable for internal systems, CI/CD pipelines, or isolated test environments, provided the trust store stays small, auditable, and current.

Practical implication: Limit self-signed mTLS to tightly controlled environments where certificate enrollment and revocation can be manually verified.

Why CA-signed tls_client_auth scales better for NHI governance

CA-signed client authentication uses a trusted Certificate Authority to issue certificates, allowing the server to validate certificate chains automatically instead of maintaining per-client trust records. That architecture supports broader federation, intermediate CAs, renewal automation, and central revocation through mechanisms such as CRLs or OCSP. For NHI governance, this matters because certificates become manageable at population scale, not just for a handful of known systems. It also improves auditability, which is essential when external parties, regulated integrations, or rotating certificates are part of the trust boundary.

Practical implication: Use CA-signed mTLS when certificate trust must scale across multiple teams, partners, or production APIs.

Where mTLS still fails without certificate lifecycle control

mTLS is only as strong as the certificate lifecycle behind it. If certificates are not rotated, revoked, or scoped correctly, both self-signed and CA-signed models can leave standing access in place longer than intended. The practical failure mode is governance drift, where the handshake still succeeds even though the identity should no longer be trusted. That is why certificate binding, revocation hygiene, and access scoping matter as much as cryptographic validation. In NHI terms, the certificate is the credential, but the lifecycle determines whether it remains safe to use.

Practical implication: Treat certificate rotation and revocation as first-class control points, not as back-office PKI chores.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Manual trust is a governance liability once certificate populations grow. Self-signed mTLS can be defensible in isolated systems, but it creates trust debt as soon as more than a few clients are involved. Each manually registered certificate becomes another point where access can drift, remain stale, or be forgotten. For NHI programmes, that is not a certificate problem alone, it is an identity inventory problem that must be owned explicitly.

CA-signed authentication is the better fit when identity must scale across ecosystems. The value is not cryptographic novelty, but operational consistency. CA-backed trust supports central issuance, renewal, revocation, and audit, which are all core requirements when services, partners, and workloads behave like non-human identities at enterprise scale. Practitioners should treat CA-signed mTLS as the default for external and regulated trust boundaries.

mTLS does not replace lifecycle governance, it depends on it. A certificate that is technically valid may still be operationally unsafe if it outlives its intended use or remains trusted after role changes. This is the core NHI lesson: authentication strength and access governance are separate controls, and both must be enforced. Teams should map certificates to ownership, expiry, and revocation obligations the same way they map any other NHI credential.

Identity blast radius is the right concept for deciding between the two models. A self-signed trust list can be acceptable when blast radius is tightly bounded and change is infrequent. Once the client population expands, the risk shifts from weak crypto to weak control-plane hygiene. That means the deciding factor is not which method is simpler, but which one keeps the trust boundary measurable and the blast radius contained.

Open Banking-style environments validate the case for standards-based trust. Where third parties must onboard, rotate, and prove identity at scale, manual trust handling becomes a bottleneck and a control gap. The practitioner conclusion is straightforward: if the ecosystem is federated, regulated, or fast-changing, design for automated trust validation from the start.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That gap makes certificate and secret lifecycle control the next governance layer to mature, as shown in Guide to SPIFFE and SPIRE.

What this signals

Identity blast radius is the operational metric that matters here: once certificate trust is managed manually, the risk is not only compromise, but uncontrolled persistence. A small self-signed deployment can be governable, but the same pattern becomes brittle when access counts rise or partner onboarding accelerates.

As NHI populations grow, teams need controls that reduce human dependency in issuance, renewal, and revocation. The NIST Cybersecurity Framework 2.0 remains a useful mapping layer for tying certificate governance to access control, resilience, and recovery.

Certificate-based workload identity is increasingly a lifecycle problem, not a pure authentication problem. The teams that treat certificates like ordinary secrets will keep carrying manual trust debt; the teams that model them as governed NHI credentials will have a cleaner path to scale.

For practitioners

• Classify mTLS clients by trust boundary Separate internal-only workloads, partner integrations, and production-facing APIs into distinct certificate governance paths so manual trust does not bleed into federated environments.
• Automate certificate issuance and renewal Use automated issuance, renewal, and expiry monitoring for CA-signed certificates so certificate lifecycle state is visible before access breaks or lingers past intended use.
• Constrain self-signed trust stores Keep self-signed certificate trust lists small, current, and auditable, and require explicit review when a certificate is added, rotated, or removed.
• Bind certificates to ownership and revocation rules Record the client owner, business purpose, expiry date, and revocation path for every certificate so mTLS credentials are managed like other NHI assets.

Key takeaways

• Self-signed mTLS can work, but only where manual trust management stays small and tightly controlled.
• CA-signed mTLS is the better default for production and federated use because it supports scalable trust, revocation, and auditability.
• The real governance issue is certificate lifecycle control, because authentication without rotation and revocation still leaves access risk in place.

Key terms

• Tls Client Authentication: A certificate-based method for proving client identity during the TLS handshake. The server validates an X.509 certificate and the client proves possession of the private key, creating a machine-to-machine trust signal that can be governed like any other non-human credential.
• Self-Signed Client Certificate: A client certificate created and trusted without an external Certificate Authority. It can be secure in small, controlled environments, but the server must explicitly register or match it, which makes trust management manual and increases the chance of drift if lifecycle controls are weak.
• Ca-Signed Client Certificate: A client certificate issued by a trusted Certificate Authority and validated through a certificate chain. This model scales better across organisations because trust, renewal, and revocation can be managed centrally rather than maintained as individual server-side exceptions.
• Certificate Lifecycle: The governed sequence of issuing, using, rotating, revoking, and retiring a certificate. For NHI programmes, lifecycle management is what keeps a valid certificate aligned with actual business need, rather than allowing access to persist after its intended purpose ends.

Deepen your knowledge

TLS client authentication and certificate lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building policy for mTLS, it is a practical place to start.

This post draws on content published by Raidiam: TLS client authentication and the trust gap in mTLS governance. Read the original.