Who is accountable when identity-based access fails in a Zero Trust programme?

Accountability sits with the identity, security, and platform owners who control entitlement design, lifecycle governance, and response automation. If service accounts, tokens, or human credentials are outside a clear ownership model, the programme cannot enforce revocation or prove that least privilege is being maintained.

Why This Matters for Security Teams

Identity-based access failures in a Zero Trust programme are rarely just an authentication problem. They usually expose a governance gap: no one can prove who owns a service account, token, or API key, who approved the entitlement, and who must revoke it when risk changes. Zero Trust only works when identity decisions are continuously enforced, not assumed once at onboarding, as described in NIST SP 800-207 Zero Trust Architecture.

The practical risk is that failures spread across identity engineering, platform operations, and application teams. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, while 97% of NHIs carry excessive privileges, which makes accountability hard to assign after the fact in Ultimate Guide to NHIs. In practice, many security teams discover the ownership problem only after an exposed token or over-privileged account has already been used to move laterally.

How It Works in Practice

Accountability in a mature Zero Trust programme should be explicit and operational, not symbolic. The identity owner is usually accountable for the entitlement model, assurance level, and revocation rules. The security owner is accountable for policy, monitoring, and exception handling. The platform owner is accountable for how identities are issued, bound to workloads, and rotated across infrastructure and pipelines. That split aligns with the direction of the OWASP Non-Human Identity Top 10, which treats unmanaged NHI lifecycle and privilege creep as primary failure modes.

In practice, teams should define ownership at three layers:

• Entitlement ownership: who approves what the identity can access, and under what conditions.

• Lifecycle ownership: who rotates, revokes, and reviews credentials, secrets, certificates, and tokens.

• Detection ownership: who investigates abnormal use, missed revocation, and policy drift.

For workloads, the most resilient pattern is to treat workload identity as the control point and then bind short-lived credentials to that identity. The Ultimate Guide to NHIs — What are Non-Human Identities and Guide to SPIFFE and SPIRE both reinforce the need for cryptographic workload identity, because that gives policy engines something stronger than a shared secret or a manually managed account. Current guidance suggests pairing that with just-in-time access, automated revocation, and policy-as-code so that access decisions are evaluated at request time, not left to static group membership.

That model works best when each identity has a named business or platform owner, a documented service purpose, and an expiry or rotation schedule. These controls tend to break down when identities are shared across teams, embedded in CI/CD templates, or inherited from legacy applications that cannot be individually attributed.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance clear ownership against delivery speed and legacy constraints. In well-run cloud environments, this is manageable; in older estates, it can be disruptive if service accounts are embedded in application code or shared across many jobs.

There is no universal standard for assigning accountability to machine identities yet, but current guidance suggests that the operational owner should not be the same as the approver unless the programme includes independent review. That separation matters most where secrets live in code, configuration, or CI/CD tooling, because the person who deploys the workload may not be the person who can safely revoke it. NHI Management Group notes that 96% of organisations store secrets outside secrets managers in vulnerable locations in the Ultimate Guide to NHIs, which makes post-incident attribution especially difficult.

Edge cases also arise in third-party integrations, shared platform identities, and emergency break-glass access. In those scenarios, accountability should be documented before the exception is granted, not after the incident review. Where agentic automation is involved, the same principle applies, but the account owner must also understand what the system is allowed to do at runtime and how fast revocation propagates.

Related resources from NHI Mgmt Group

• What is the difference between JIT access and Zero Trust for NHIs?
• Who is accountable when zero trust fails because access was never removed?
• Who should be accountable for identity intelligence in a Zero Trust programme?
• How should security teams reduce blast radius in identity-first Zero Trust programmes?