Look for complete inventory coverage, named ownership, timely renewal, documented revocation, and evidence that expired or unused certificates are removed quickly. If teams cannot answer where a certificate lives or who uses it, governance is not working, even if the platform reports that encryption is enabled.
Why This Matters for Security Teams
Certificate governance is only meaningful when security teams can prove that certificates are owned, inventoried, renewed on time, and revoked when no longer needed. A platform showing encryption enabled does not tell you whether stale certificates still exist, whether private keys are exposed, or whether a certificate is tied to an abandoned workload. NIST’s Cybersecurity Framework 2.0 puts this in operational terms: outcomes matter more than status flags, and governance has to be measurable.
For NHI-specific context, the lifecycle expectations in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs align with the same principle. If teams cannot trace a certificate back to a system owner, a workload, and a renewal process, then the control is not functioning as governance, only as inventory noise. That distinction is important because certificates fail quietly until expiry, mis-issuance, or orphaning creates an outage or an exposure. In practice, many security teams discover certificate governance failures only after an expired certificate has already broken a production path or a forgotten one has been abused by an attacker, rather than through intentional control testing.
How It Works in Practice
Working certificate governance starts with a complete inventory and then adds control points that answer four questions: what is it, who owns it, where is it used, and when does it expire. Mature programs treat certificates as governed NHI assets, not just technical artifacts. The most useful evidence is a closed loop from discovery to disposition, with ownership, renewal, and revocation recorded in a way auditors and operators can verify.
A practical operating model usually includes:
- automated discovery across servers, containers, service meshes, CI/CD systems, and third-party integrations
- named business or technical owners for each certificate or certificate group
- clear TTL and renewal rules, with short-lived certificates where possible
- revocation workflows that remove access quickly when workloads retire or keys are suspected compromised
- monitoring that flags certificates nearing expiry, unused certificates, and duplicate issuance
This is also where the broader NHI lifecycle matters. The State of Non-Human Identity Security notes that only 1.5 out of 10 organisations are highly confident in securing NHIs, which is consistent with certificate programs that lack complete visibility or ownership. External guidance from CISA on automation and orchestration reinforces the practical point: manual renewal and revocation do not scale well enough for modern environments.
The best test is not whether certificates exist, but whether the organisation can produce evidence that expired certificates are removed quickly, unused certificates are retired, and renewal exceptions are approved, time-bound, and tracked. These controls tend to break down in environments with high certificate churn, ephemeral workloads, or unmanaged third-party integrations because ownership and revocation paths become ambiguous.
Common Variations and Edge Cases
Tighter certificate control often increases operational overhead, requiring organisations to balance shorter lifetimes and faster revocation against service reliability and support burden. That tradeoff is real, especially where legacy applications cannot tolerate frequent renewal or where embedded devices and partner systems still depend on manual certificate handling.
Current guidance suggests different treatment by certificate type. Public-facing TLS certificates, internal service certificates, code-signing certificates, and device certificates do not all need identical controls. For example, short-lived service certificates may be the right answer for cloud-native systems, while regulated or legacy environments may need compensating controls such as enhanced monitoring, segmented trust chains, and stricter approval workflows.
A common failure mode is assuming that certificate monitoring alone proves governance. It does not. Monitoring can tell teams that a certificate is nearing expiry, but it cannot prove ownership, remove orphaned assets, or confirm that a retired workload no longer has an active trust path. That is why the Top 10 NHI Issues remain relevant here: unmanaged lifecycle, poor visibility, and weak revocation are still the core issues behind failed control outcomes. In environments with third-party-managed certificates, multi-cloud sprawl, or heavy use of automation, governance breaks down when no single team can answer who can issue, rotate, or revoke the certificate without delaying production.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Certificate renewal and rotation are core NHI lifecycle controls. |
| NIST CSF 2.0 | PR.DS-2 | Protecting data in transit depends on managed certificate trust and renewal. |
| NIST CSF 2.0 | PR.AC-1 | Ownership and access governance are required to validate certificate accountability. |
Track certificate TTLs, automate rotation, and remove expired or orphaned certificates on a fixed schedule.
Related resources from NHI Mgmt Group
- How do organisations know whether secure access management is actually working in manufacturing?
- How should security teams measure whether certificate governance is actually working?
- How do organisations know whether federated governance is actually working?
- How do organisations know whether AI governance is actually working?
