TL;DR: As infrastructure becomes more automated and distributed, certificates now sit at the centre of machine identity trust, but most organisations still manage them as static plumbing, leaving hidden access paths and outage risk, according to Hush Security. Runtime visibility is the difference between certificate inventory and certificate governance: without it, trust can persist long after the workload, service, or control plane should have changed.
At a glance
What this is: This is an analysis of why certificate governance fails when teams only track issuance and expiry instead of runtime usage and trust context.
Why it matters: It matters because IAM, PAM, and NHI programmes cannot control machine-to-machine trust, orphaned access paths, or outage risk without knowing which certificates are actually in use.
Context
Machine identity governance breaks when certificates are treated as static artefacts instead of live trust relationships. In modern environments, certificates authenticate services, encrypt traffic, and anchor machine-to-machine access, so visibility into their runtime use is part of identity governance rather than a separate inventory task.
The core problem is not issuance alone. It is that cloud platforms, CI/CD pipelines, and developers can create large certificate estates faster than teams can answer whether a certificate is still in use, copied elsewhere, or tied to a deleted workload.
That makes certificate sprawl an identity problem with operational consequences. Expired or orphaned certificates can break services, but the deeper governance failure is that no one can prove whether trust is still valid.
Key questions
Q: What fails when teams manage certificates only as inventory and expiry dates?
A: They lose sight of whether a certificate still binds a live workload to a valid trust relationship. That creates orphaned access paths, duplicated use, and services that keep trusting identities long after the underlying state has changed. Static certificate records cannot prove runtime legitimacy, so governance becomes reactive instead of continuous.
Q: Why do certificate migrations create governance risk for machine identities?
A: Because certificates are operational credentials, and migrations often create overlapping trust states where old and new certificates coexist. That overlap complicates ownership, replacement timing, and incident response. When organisations lack a complete inventory, they cannot tell which credentials are still active or which services will fail when trust changes.
Q: How do security teams know whether certificate-based access is actually working?
A: They test the failure path, not just the happy path. A valid control should deny access when the revocation responder is unavailable, the certificate is revoked, or the listener is misconfigured. If those cases still permit access, the boundary is not enforcing policy reliably.
Q: How should organisations respond when a certificate is still trusted after the workload changes?
A: They should treat that as a governance failure, not just a cleanup task. The right response is to revoke or replace the certificate, reconcile dependent services, and update lifecycle controls so trust cannot remain attached to deleted or repurposed workloads.
Technical breakdown
Why certificate inventory is not certificate governance
Certificate tools often stop at metadata such as issuer, expiry date, and key size. That is useful for hygiene, but it does not answer the identity question practitioners actually need: is the certificate still binding a live workload to a live trust relationship? In machine identity terms, a certificate is only safe when its usage context is known. Without that context, a certificate may remain accepted by a service long after the workload changed, was cloned, or was deleted. Governance therefore depends on runtime evidence, not just static records.
Practical implication: treat issuance data as a starting point and require runtime usage visibility before certs are considered governed.
How runtime visibility exposes hidden trust paths
Runtime visibility adds the missing control plane for machine identity. It shows which identities are using which certificates, where they are used, and whether the behaviour matches expected service patterns. That lets teams detect anomalies such as duplicate use, unexpected persistence, or certificates still being provisioned after the associated workload has changed. In practice, this turns certificate management from a periodic audit exercise into continuous identity observation. For NHI governance, that is the difference between knowing a certificate exists and knowing whether it still deserves trust.
Practical implication: monitor certificate usage in production so orphaned and duplicated trust relationships are visible before they become incidents.
Why post-quantum readiness belongs in certificate governance
Certificate governance now has a forward-looking cryptographic dimension. If teams cannot continuously assess whether certificates remain compliant with current cryptographic expectations, they risk carrying weak or soon-to-be-obsolete trust into production. That matters because machine identities often outlive the change cycles that govern applications and infrastructure. Runtime assessment of cryptographic strength therefore supports both compliance and resilience. It also aligns certificate management with Zero Trust, where trust must be continuously validated instead of assumed after issuance.
Practical implication: include cryptographic strength and compliance checks in the same workflow that governs certificate lifecycle and removal.
Threat narrative
Attacker objective: The objective is to preserve or exploit machine trust through a certificate that remains accepted after its operational context has changed.
- Entry begins when certificates are issued broadly across cloud, automation, and development workflows, creating a large pool of trusted artefacts that may not be centrally understood.
- Credential access occurs when a certificate is copied, reused, or left active after the associated workload changes, giving an actor or process a valid trust token outside intended scope.
- Escalation follows when the certificate continues to authorize machine-to-machine communication, preserve access to dependent services, or hide an orphaned trust path from traditional tooling.
- Impact is service disruption, shadow access, or prolonged trust in a certificate that no longer reflects the current state of the workload or control plane.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Certificate runtime visibility is now a machine identity control, not a monitoring nicety. Traditional certificate management assumes issuance, expiry, and key length are enough to establish trust. That assumption fails when certificates are copied, reused, or left behind after workloads change, because the binding between identity and trust can no longer be inferred from static metadata alone. The implication is that machine identity governance has to prove live usage, not just catalogue assets.
Certificate sprawl creates an identity blast radius that most governance teams underestimate. Cloud platforms, automation pipelines, and developers can all mint certificates, but none of those issuers by themselves explain who still depends on them. When thousands of certificates exist across hybrid estates, orphaned trust paths become operationally normal rather than exceptional. Practitioners need to treat certificate sprawl as a governance boundary problem, not an inventory hygiene issue.
Static certificate tooling breaks the least-privilege expectation for machine-to-machine trust. If a certificate can continue authorizing access after the workload that requested it has changed, the trust model has outlived its design assumptions. That is not merely a visibility gap; it is a governance failure that leaves effective privilege broader and longer-lived than intended. The practical conclusion is that certificate oversight must be tied to current runtime state.
Post-quantum readiness belongs in the same governance conversation as certificate lifecycle and revocation. The article correctly links runtime intelligence with cryptographic strength checks because machine identities are long-lived enough for cryptographic assumptions to age out before the workload does. That makes certificate management a lifecycle discipline, not a one-time configuration task. Practitioners should now think in terms of continuously validated trust rather than issued trust.
Machine identity programmes will increasingly be judged by their ability to remove trust that is no longer earned. The article reflects a broader shift in the market from certificate visibility as reporting to certificate visibility as enforcement. That shift matters because modern identity control is less about knowing what exists and more about proving what should still be trusted. Teams that cannot do that will accumulate hidden access and avoidable outages.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Certificate governance now needs runtime evidence. Teams that only track issuance and expiry will keep missing the difference between a certificate that exists and a certificate that is still trusted. The operational shift is to govern certificates as live machine identities, not as static records.
Runtime visibility changes the control objective. Instead of asking whether a certificate was issued correctly, practitioners should ask whether it is still bound to the right workload and whether its trust should continue. That is the practical path to reducing shadow access paths and service surprises.
Machine identity programmes should absorb certificate lifecycle into Zero Trust thinking. Trust that cannot be observed, explained, and revoked on current state is trust that no longer fits modern infrastructure.
For practitioners
- Implement runtime certificate discovery Map certificates to the workloads, services, and pipelines that actively use them so inventory includes live trust relationships, not just issued objects.
- Flag orphaned and duplicated certificates Look for certificates still being provisioned after resource deletion, reused across unexpected hosts, or copied outside their intended service boundary.
- Tie certificate review to workload state Reconcile certificates against current application, container, and API client status so trust is revoked when the underlying identity changes.
- Add cryptographic strength checks to lifecycle workflows Continuously evaluate certificate key strength and compliance posture alongside expiry and rotation so weak trust is retired before it becomes a production dependency.
Key takeaways
- Certificates become a governance problem when teams cannot see how they are used at runtime.
- Certificate sprawl creates hidden trust paths, orphaned dependencies, and avoidable service failures.
- Runtime visibility turns certificate management into continuous machine identity control rather than static inventory.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 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-02 — Secret Leakage | Certificates and copied keys become risky when their live use cannot be observed. |
| NHI-05 — Overprivileged NHI | Orphaned certificates can preserve access beyond the intended machine identity scope. | |
| NHI-07 — Long-Lived Secrets | Certificates often remain valid long after the workload or trust need has changed. | |
| Recommendation — Scan for exposed or duplicated certificates and revoke any trust objects that cannot be accounted for in runtime. Constrain certificate scope to the minimum service boundary and retire trust when workloads change. Shorten certificate lifetime and pair renewal with runtime verification of current workload need. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Certificates are authenticators whose lifecycle and revocation must be governed. |
| Recommendation — Apply IA-5 to manage certificate issuance, renewal, and revocation as a live control process. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Runtime trust decisions map to whether machine identities remain authorised. |
| Recommendation — Continuously validate that certificates still map to authorised workloads and services. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Duplicated or orphaned certificates can enable credential access and movement across services. |
| Recommendation — Hunt for reused certificates and map them to potential credential-access and lateral-movement paths. | ||
Key terms
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.
- Certificate Sprawl: Certificate sprawl is the uncontrolled growth of certificates across systems, services, and environments. It creates operational risk because each certificate becomes another trust object that can expire, duplicate, or remain unowned, making outages and governance failures more likely.
- Machine-to-Machine Trust: Machine-to-machine trust is the mechanism that lets systems verify each other without human intervention. It depends on cryptographic identities such as certificates, workload identities, and signing keys, which means lifecycle management and visibility are essential to keep the trust boundary reliable.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or NHI programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org