Who is accountable when zero trust controls fail to stop unauthorised access?

Why This Matters for Security Teams

When zero trust controls fail, the issue is rarely the slogan itself. The failure is usually in ownership: who defines the trust boundary, who can revoke access, and who validates that policies still match how systems actually behave. NIST’s NIST SP 800-207 Zero Trust Architecture makes clear that trust decisions must be continuous and contextual, not assumed once at onboarding. That matters even more for NHIs, where credentials, tokens, and certificates often outlive the operational need that created them. NHIMG’s 52 NHI Breaches Analysis shows that identity failures are not edge cases, but recurring patterns tied to weak lifecycle control and fragmented accountability. The practical risk is that teams treat zero trust as a network design choice while the real exposure sits in entitlements, secrets, and machine-to-machine trust paths. In practice, many security teams discover that zero trust failed only after an identity was already used for lateral movement, rather than through intentional validation of revocation and policy enforcement.

For non-human identities, accountability has to be operational, not symbolic. The identity owner, platform owner, and application owner all need named responsibility for issuance, review, and revocation. Without that, zero trust becomes a statement of intent rather than a control that can be tested under load and failure conditions.

How It Works in Practice

Accountability for a zero trust miss should be traced to the control owner responsible for the failed decision point, not simply to the incident responder. In a mature model, that means mapping each NHI to a system owner, defining its intended scope, and making revocation a measurable part of the lifecycle. The security team may set policy, but the platform and application owners must ensure the policy is enforceable in production. A workable operating model usually includes:

• Named ownership for each workload identity, secret, and trust relationship.
• Policy checks at request time, rather than only at deployment time.
• Short-lived credentials and immediate revocation paths for compromised NHIs.
• Logging that ties every access decision back to an owner and a control.
• Periodic testing of trust boundaries against real failure scenarios.

This is where identity-specific guidance becomes useful. The OWASP Non-Human Identity Top 10 focuses attention on weak lifecycle management, overprivileged service accounts, and missing inventory, while NHIMG’s Ultimate Guide to NHIs frames the standards and control surface practitioners should use to reduce ambiguity. If the organisation uses workload identity, Guide to SPIFFE and SPIRE is especially relevant because it shifts accountability toward cryptographic proof of workload identity and automated trust issuance. In practice, ownership fails when a service account is reused across teams, revocation is manual, or no one can prove which system approved access in the first place. These controls tend to break down in distributed, multi-team environments because the trust boundary is shared but the revocation authority is not.

Common Variations and Edge Cases

Tighter zero trust controls often increase operational overhead, so organisations have to balance stronger assurance against friction in delivery and incident response. That tradeoff becomes sharper when NHIs are embedded in CI/CD pipelines, ephemeral containers, or cross-cloud integrations where ownership changes faster than policy review cycles. There is no universal standard for accountability assignment in every environment, but current guidance suggests a few consistent patterns. If a platform team defines the policy engine, it owns policy correctness. If an application team requests the access, it owns the business justification. If a security team approves the control design, it owns governance and validation. In regulated environments, those roles may be documented separately for auditability, but the principle remains the same: the team closest to the failure point must be able to change it. The hardest edge case is shadow NHIs, where credentials exist without a clear business owner. Those situations often defeat zero trust because no one is empowered to revoke access quickly enough. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it highlights the control gaps that appear when inventories, ownership, and lifecycle management diverge. For AI-driven or highly automated systems, the same issue is amplified because the access pattern can change at runtime, so a static owner list is not enough without continuous policy review.

Related resources from NHI Mgmt Group

• Who is accountable when zero trust controls fail in SaaS governance?
• Who is accountable when zero-trust controls fail to reduce access over time?
• Who is accountable when access controls fail in SOX-scoped systems?
• Who is accountable when zero trust controls exist but access remains over-provisioned?