Should organisations treat TLS certificates as NHI assets?

Why TLS Certificates Belong in NHI Governance

TLS certificates are not just transport security artefacts. They are machine-held credentials that let one system prove its identity to another, which is exactly why they belong in the NHI inventory. Treating them as ordinary infrastructure clutter leads to blind spots in ownership, rotation, and retirement. That is the same pattern seen across machine identity failures, where SailPoint’s Critical Gaps in Machine Identity Management report found that 57% of organisations lack a complete inventory of their machine identities.

The practical risk is straightforward. A certificate can authenticate an API endpoint, a service mesh workload, a load balancer, or a user-facing application, and its compromise or expiry can interrupt trust at machine speed. NHI governance forces teams to ask who owns it, what it authenticates, where it is deployed, how long it is valid, and what happens when it is no longer needed. That maps cleanly to the identity lifecycle guidance in the Ultimate Guide to NHIs and the control expectations reflected in the NIST Cybersecurity Framework 2.0.

In practice, many security teams discover expired or misissued certificates only after service disruption has already exposed the governance gap.

How to Operationalise Certificate Identity Management

Operationally, the right model is to treat each TLS certificate as a managed NHI asset with a defined lifecycle. Start with inventory. A team cannot secure what it cannot enumerate, and certificate sprawl is often hidden across application servers, ingress controllers, CI/CD pipelines, service mesh sidecars, and third-party managed services. From there, assign ownership, document purpose, and tie each certificate to the workload or trust boundary it protects. This is where certificate management becomes identity management rather than pure PKI administration.

Good practice is to align certificate handling with the same controls used for other sensitive Secrets: issuance, distribution, rotation, revocation, and retirement. Short-lived certificates reduce exposure, but only if the surrounding automation is reliable. Manual renewal processes create the same failure modes seen in broader NHI programmes, especially when credentials outlive the workload or are embedded in code and configuration. The Top 10 NHI Issues page captures this broader operational risk, and the Ultimate Guide to NHIs — What are Non-Human Identities explains why machine identities need explicit lifecycle control.

• Inventory certificates with owner, workload, issuer, expiry, and revocation path.
• Use automated discovery to find orphaned or shadow certificates.
• Prefer short-lived issuance and scheduled rotation over long-lived static trust.
• Track certificate use in audits the same way teams track privileged credentials.

At the policy level, map certificate governance to the NIST CSF and the trust, identity, and access principles in Zero Trust programmes. That becomes especially important when certificates are used for workload-to-workload authentication, because a single weak certificate can become a lateral-movement path. These controls tend to break down in hybrid estates with multiple PKI stacks and unmanaged third-party endpoints because ownership and revocation are fragmented.

Common Variations and Edge Cases

Tighter certificate governance often increases operational overhead, requiring organisations to balance stronger trust hygiene against renewal complexity and release velocity. That tradeoff is real, especially in environments that still rely on legacy appliances, embedded systems, or vendor-managed services where certificate replacement is slow or partially outside local control. Current guidance suggests that these exceptions should be documented, not ignored, because undocumented exceptions become permanent risk.

There is no universal standard for every certificate use case yet. A public website certificate, an internal mTLS certificate, and a code-signing certificate do not carry identical operational requirements, even though all of them function as machine identity proof. Some environments also blur the line between certificate and secret management, particularly when private keys are stored alongside app secrets or injected into pipelines. In those cases, certificate governance should be integrated with the broader NHI programme rather than handled as a separate island of PKI work.

For organisations building toward stronger identity maturity, the simplest rule is this: if a certificate can authenticate a non-human system, it should be governed like one. That includes revocation when a service is retired, rapid replacement when compromise is suspected, and explicit review of where certificates are exposed to third parties or automation systems. The machine identity failure patterns documented in 52 NHI Breaches Analysis and the trust model described in the NIST Cybersecurity Framework 2.0 both point to the same conclusion: unmanaged certificates are unmanaged identities.

Related resources from NHI Mgmt Group

• What makes OAuth tokens risky in NHI environments?
• When should organisations treat an NHI as a high-priority risk?
• When should organisations treat an NHI like a privileged administrator?
• When should organisations treat NHI governance as part of ransomware defense?