SSL/TLS certificate management failures are really identity governance failures

At a glance

What this is: This is a practical guide to SSL/TLS and mTLS certificate management, with Bazel’s certificate outage used to show how renewal, visibility, and ownership failures turn into downtime.

Why it matters: It matters because certificate lifecycle failures are identity failures in disguise, affecting NHI, infrastructure, and zero-trust programmes that depend on trusted machine identities.

By the numbers:

• The CA/Browser Forum is cutting the maximum public certificate lifetime from 398 days to 200 in March 2026, 100 in 2027, and 47 by 2029.

👉 Read Infisical's guide to SSL/TLS and mTLS certificate management

Context

SSL/TLS certificate management is the discipline of keeping certificates valid, trusted, and deployed where they belong. In practice, it is an identity governance problem for machine identities, because a certificate binds a public key to a domain, service, workload, or device and expires on a schedule that operational teams must govern.

The Bazel outage shows why this still breaks at scale. The failure was not just about one expired cert, but about missing visibility, unclear ownership, broken renewal notifications, and delayed propagation, all of which are familiar failure modes in NHI and workload identity programmes.

Key questions

Q: How should teams govern certificate expiry across large service estates?

A: Treat certificate expiry as an identity lifecycle control, not a calendar reminder. Maintain a central inventory, assign an owner to every certificate, and monitor renewal failures as actively as expiry dates. That approach reduces the chance that a valid certificate is quietly headed toward a hard outage.

Q: Why do certificate management failures matter to zero trust programmes?

A: Zero trust assumes that trust is explicit, limited, and continuously verified. If certificates expire unexpectedly or stay untracked, the programme loses its ability to prove machine identity reliably. That creates blind spots in workload access, service-to-service trust, and revocation response.

Q: What breaks when certificate ownership is distributed across teams?

A: Renewal and revocation become slower because no one has full visibility into what exists, where it is deployed, or who can change it. Distributed ownership also increases the chance that a certificate outlives the person who created it, which is how forgotten credentials become operational risk.

Q: When should organisations prioritise automation over manual certificate handling?

A: Automation should be the default once an organisation manages more than a small number of certificates, because scale makes manual renewal unreliable. The turning point is not a specific count, but the moment certificates span teams, tools, and infrastructure layers that no single person can track safely.

Technical breakdown

Certificate lifecycle management and expiry control

A TLS certificate is a signed X.509 object with a fixed validity window, which means it behaves like a credential with an expiration date rather than a permanent asset. The lifecycle runs from issuance to deployment, renewal, and revocation. At enterprise scale, the hard part is not the syntax of the certificate file but the operational control of when it is renewed, where it is installed, and who owns the outcome when it fails. In mTLS environments, each workload can have its own certificate, which multiplies the lifecycle burden across services, clusters, and device fleets.

Practical implication: Treat certificate expiry as an identity lifecycle event and assign an owner for every certificate class.

mTLS, workload identity, and zero trust

Mutual TLS extends standard TLS by requiring both sides of the connection to present certificates, so the server and client each prove identity during the handshake. This is why mTLS is commonly paired with service meshes and SPIFFE-style workload identity, where a workload receives a short-lived certificate tied to a stable identity string. The security value is strong authentication between machines, but mTLS does not decide authorisation. A valid certificate proves who is calling, not what that caller should be allowed to do, so policy still has to sit behind the handshake.

Practical implication: Separate authentication from authorisation when designing service-to-service trust.

Certificate discovery, ownership, and renewal alerts

Certificate management becomes fragile when inventories are incomplete and renewals are only watched by expiry date. A certificate can fail to renew silently while the old copy continues to work until the final expiry moment, which creates a false sense of safety. Distributed ownership makes this worse because no single team sees the full estate, especially when internal services, public endpoints, and infrastructure certificates are managed separately. Centralised certificate management exists to collapse those blind spots into one control surface.

Practical implication: Build detection on renewal failure and inventory drift, not only on days-to-expiry thresholds.

NHI Mgmt Group analysis

Certificate expiry is an identity control failure, not a maintenance issue. The Bazel incident shows that expired certificates create direct operational impact when ownership, discovery, and renewal governance are not unified. In NHI terms, a certificate is a machine credential with a lifecycle, and lifecycle failure is a governance failure. Practitioners should treat certificate estates as part of identity governance, not as a sidecar operational task.

mTLS expands the machine identity surface faster than most programmes can inventory it. Every service mesh sidecar, internal API, cluster node, and device certificate adds another trust object to govern. That makes central visibility and renewal automation prerequisites, not optimisations. The practical conclusion is that certificate sprawl must be managed as NHI sprawl, because the governance problem scales with every new workload.

Long-lived certificates create credential persistence that weakens zero trust assumptions. The longer a certificate remains valid, the longer a compromised key can stay trusted if it is never discovered and revoked. That is exactly why certificate lifecycle control belongs in the same conversation as secrets rotation and offboarding. The practitioner takeaway is to reduce credential persistence wherever trust is machine-issued.

Centralised certificate management is now a control-plane problem. The article makes clear that renewal tooling alone is insufficient if notifications fail, inventories are incomplete, or propagation lags behind expiry. That is a control-plane issue, because the organisation needs one source of truth for issuance policy, ownership, alerting, and distribution. Teams should therefore evaluate certificate management as governance infrastructure, not just automation.

Identity blast radius grows when certificate ownership is fragmented. When the person who created a certificate is no longer around, the next operator inherits both the technical task and the missing context. That is the hidden risk in certificate estates: the failure often occurs where the organisational memory has already decayed. The practitioner conclusion is simple, if uncomfortable, central ownership is part of resilience.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing how remediation lag keeps machine credentials usable long after exposure.
• NHI Lifecycle Management Guide shows how to govern provisioning, rotation, and offboarding together so certificate and secret lifecycles do not drift apart.

What this signals

Certificate programmes are converging with NHI governance programmes. Once certificates are treated as machine identities, the next question is not whether to automate rotation, but how to prove ownership, visibility, and exception handling across the full estate. That shift matters because certificate management failures now look like classic NHI lifecycle failures, especially where renewal and revocation are split across teams.

With 97% of NHIs carrying excessive privileges in our research, the problem is not just how many machine credentials exist, but how long they remain trusted after the organisation has lost track of them. Certificate management needs to be read through the same governance lens, because expired or forgotten credentials create identity debt that eventually turns into outage or exposure.

Identity blast radius: the hidden risk is not a single expired certificate, but the number of systems that fail when one control plane cannot see or renew the credential in time. That is why teams should align certificate management with the same operational discipline used for workload identity and secrets governance, including policy, inventory, and offboarding.

For practitioners

• Inventory all certificates as governed identity assets Create a single inventory across public edge, service-to-service, databases, Kubernetes, and device fleets. Record owner, issuer, validity window, deployment targets, and renewal method so no certificate lives outside governance.
• Alert on renewal failure before expiry becomes visible Monitor the renewal workflow itself, not only expiry dates. A certificate can remain valid while auto-renewal is already broken, so detect failed jobs, incomplete chains, and missing propagation as first-class events.
• Separate issuance policy from human approval bottlenecks Use certificate profiles to define who can issue what, which issuers are allowed, and which certificates require approval. Apply policy centrally so governance is enforced consistently across internal and public CAs.
• Shorten internal certificate lifetimes by design Do not let internal certificates drift into multi-year validity just because they are not browser-bound. Shorter lifetimes reduce the persistence of forgotten credentials and make rotation a routine control rather than an emergency.

Key takeaways

• SSL/TLS certificate management is an identity lifecycle discipline, and when ownership or visibility fails, outages follow.
• Bazel’s outage shows that auto-renewal alone is not enough if alerting, inventory, and propagation controls are weak.
• Teams should govern certificates centrally, shorten persistence, and treat renewal failure as a security signal rather than a housekeeping issue.

Key terms

• Certificate lifecycle management: Certificate lifecycle management is the process of issuing, deploying, renewing, tracking, and revoking certificates before they fail or become unsafe. For identity teams, it is governance over machine credentials that can break services when they expire and can widen attack surface when they are forgotten.
• Mutual TLS: Mutual TLS is a connection model where both the client and server prove identity with certificates during the handshake. It strengthens machine-to-machine trust, but it does not decide authorisation, so policy and access control still need to sit behind the handshake.
• X.509 certificate: An X.509 certificate is a signed data structure that binds a public key to an identity such as a domain, service, or workload. It is the standard format used by TLS and many internal PKI systems, and its validity window is what makes lifecycle governance mandatory.
• Certificate authority: A certificate authority is the trusted issuer that signs certificates and vouches for the identity they bind to a public key. In practice, CA governance determines who can issue credentials, how long they last, and what assurance a relying system should place in them.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step certificate lifecycle workflows for issuance, deployment, renewal, and revocation across public and private certificates.
• Operational examples of how renewal automation, alerting, and propagation behave when certificates are spread across Kubernetes, service meshes, and databases.
• A deeper explanation of X.509 fields, PEM structure, and the TLS and mTLS handshake mechanics behind certificate trust.
• Infisical's implementation approach for centralised certificate management, including policy controls and CA integration.

👉 Infisical's full post covers certificate anatomy, renewal automation, and centralised management details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance, it is worth exploring.