What breaks when certificate-based controls do not include workload identity?

Why This Matters for Security Teams

Certificate-based controls are only as strong as the identity they bind to. If a certificate proves possession of a key but does not prove which workload is using it, security teams lose the ability to separate a live, intended process from a stale secret that still works. That gap creates hidden standing privilege in pipelines, service accounts, and automation, where access can persist long after business need has ended. Current guidance increasingly treats that as an identity problem, not just a cryptography problem.

NHIMG research shows how common the operational fallout is: the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, while 91.6% of secrets remain valid five days after notification. When certificates are managed without workload identity, revocation, rotation, and auditability all become weaker than they appear on paper. The result is a control that looks compliant but still allows an attacker to reuse exposed credentials. In practice, many security teams encounter this only after a build agent, service account, or integration has already outlived its intended access window.

How It Works in Practice

Workload identity changes the meaning of a certificate. Instead of treating the certificate as a generic pass, the system binds it to a specific workload, process, or runtime context so that authorisation can be evaluated against what is actually making the request. The SPIFFE workload identity specification is a common example of this model: the workload receives a cryptographic identity that represents what it is, not just what secret it possesses.

In practice, that means certificate-based controls need three things to be useful:

• A unique workload identity that survives rescheduling, scaling, and redeployment.
• Short-lived credentials or certificates issued per workload or task, not long-lived shared secrets.
• Policy checks at request time, so access is based on runtime context, not on a static role assigned months ago.

This approach is especially important in CI/CD, Kubernetes, and service-to-service communication, where jobs, pods, and agents are ephemeral. If a certificate is only tied to a service account name, then any process that inherits that account can reuse the same access path. If the certificate is tied to workload identity, the security boundary becomes the running unit of work, which is far harder to reuse after termination. NHIMG’s Guide to SPIFFE and SPIRE is useful here because it shows how identity can be issued and verified without depending on static, manually tracked secrets.

That model also supports better auditing. Teams can answer which workload accessed which resource, under what trust conditions, and for how long. These controls tend to break down in legacy environments where certificates are reused across multiple hosts, tied to shared service accounts, or issued without runtime attestation.

Common Variations and Edge Cases

Tighter certificate controls often increase operational overhead, requiring organisations to balance stronger binding against deployment complexity. Not every environment can move to workload identity immediately, and best practice is evolving for hybrid estates that mix legacy VMs, containers, and external SaaS integrations.

The main edge case is a certificate that is technically short-lived but still issued to a broadly shared identity. In that scenario, expiry helps, but it does not solve attribution or reduce blast radius. Another common gap appears in edge and embedded systems where attestation is weak or absent, making it difficult to prove the workload behind the certificate. Current guidance suggests treating those environments as higher risk until identity binding is improved.

For teams evaluating maturity, NHIMG’s 52 NHI Breaches Analysis shows how often non-human credentials are abused after they are no longer supposed to be active. That pattern is why certificate lifecycle alone is not enough. The control must also answer who or what is using the certificate, and whether that usage still matches the intended workload. Where ephemeral compute and shared identities collide, certificate-based controls without workload identity usually fail first in CI/CD runners, autoscaled services, and third-party integrations that outlive their original trust assumptions.

Related resources from NHI Mgmt Group

• What breaks when SOX controls do not include identity governance?
• What breaks when healthcare remote access is not tied to certificate and identity lifecycle controls?
• What is the difference between OAuth 2.1 and workload identity controls?
• What is the difference between workload identity and secret-based access?