Who should be accountable for identity governance in a Zero Trust model?

Accountability should sit with the teams that own identity, access policy, and operational response together, not with infrastructure teams alone. IAM, PAM, NHI owners, and security operations all need defined responsibilities because Zero Trust fails when discovery, enforcement, and remediation are split across unrelated silos. Governance must be shared, but ownership cannot be vague.

Why This Matters for Security Teams

zero trust only works when identity governance is treated as an operating model, not a tool assignment. If accountability is unclear, policy decisions get separated from remediation, and teams can end up enforcing least privilege on paper while leaving real access paths untouched. That gap is especially dangerous for NHIs, where service accounts, API keys, and automation tokens often outlive the workflows they were created for. NIST’s Cybersecurity Framework 2.0 and SP 800-207 Zero Trust Architecture both point toward continuous verification and shared responsibility, but they do not remove the need for a named owner.

NHI Management Group’s Ultimate Guide to NHIs shows why this matters: NHIs outnumber human identities by 25x to 50x in modern enterprises, and 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation. In practice, many security teams encounter identity failures only after a secrets leak, privilege sprawl, or service outage has already exposed the weak handoff between ownership, policy, and response.

How It Works in Practice

Accountability in a Zero Trust model should be split by function but anchored by a single governance owner. Identity engineering usually owns lifecycle controls such as provisioning, rotation, and deprovisioning. Security architecture owns policy design, including how access is evaluated at request time. Operations or incident response owns rapid revocation, containment, and evidence handling when access is abused. Business system owners should still be accountable for approving the access their applications genuinely need.

This is where the difference between ownership and enforcement matters. Zero Trust is not just a network stance; it is an identity decision model. For NHIs, the strongest pattern is to pair policy-as-code with runtime enforcement, then bind each workload to a verifiable identity primitive. NHI Management Group’s lifecycle guidance for NHIs and the standards overview both reinforce the same practical point: discovery, rotation, and offboarding must be owned as a continuous process, not a periodic audit task.

• Define a primary owner for each identity class: human, service account, API key, certificate, and agent workload.
• Require a secondary owner for revocation and incident response so access can be removed without waiting on a ticket queue.
• Map policy decisions to named approvers and named remediators, not shared mailboxes or generic platform groups.
• Review who can create, extend, or exempt NHIs, because exceptions are where Zero Trust usually erodes.

For workload identity implementation, many organisations are moving toward short-lived credentials and cryptographic proof of workload identity through approaches such as SPIFFE and SPIRE, but current guidance suggests that tooling alone is not enough without accountable ownership. These controls tend to break down when legacy automation depends on long-lived shared secrets because the blast radius becomes too broad and revocation becomes operationally risky.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, requiring organisations to balance stronger control against deployment speed and service reliability. That tradeoff is real, especially in platform engineering, CI/CD, and agentic AI environments where systems may need frequent credential renewal and rapid policy changes.

There is no universal standard for this yet, but current guidance suggests that accountability becomes more important, not less, as environments become more autonomous. In agentic or high-automation settings, ownership should extend beyond static IAM administration to include runtime policy evaluation, JIT credential issuance, and revocation triggers when behaviour changes unexpectedly. The problem is not only who approves access, but who is accountable when an agent later chains tools, escalates privilege, or uses a previously legitimate path in an unsafe way.

NHIMG research also shows how governance fails when access is not tightly scoped: the Top 10 NHI Issues and broader Ultimate Guide to NHIs both highlight excessive privileges, poor rotation, and weak offboarding as recurring patterns. The edge case that often gets missed is outsourced or federated operations: if a third-party platform runs the identity plane, internal teams still need explicit accountability for policy approval, monitoring, and emergency cut-off. Otherwise, Zero Trust becomes an architectural label rather than an enforceable control model.

Related resources from NHI Mgmt Group

• Why is it important to integrate identity and data governance?
• How does the consumer-secret-entitlement model help with governance at scale?
• What do security teams get wrong about Zero Trust and identity governance?
• How should security teams choose between Zero Trust and Defense in Depth for identity governance?