Who should own access request governance across human and non-human identities?

Why This Matters for Security Teams

Access request governance breaks down when human approvals and machine approvals are forced through the same process. Human identities can be reviewed against job role, manager, and business need, but NHIs are created for software, pipelines, and integrations that need ownership tied to runtime responsibility and offboarding. That distinction is central to the OWASP Non-Human Identity Top 10 and to NHIMG’s lifecycle guidance in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

The practical risk is not just delayed approvals. Generic workflows often hide who is accountable when a service account is over-privileged, when an automation changes scope, or when an application is retired without revoking access. That leaves gaps in ownership, auditability, and incident response. NHI Management Group’s research on the State of Non-Human Identity Security shows why this matters: credential rotation failures, weak monitoring, and over-privilege remain common drivers of NHI exposure. In practice, many security teams encounter accountability failures only after an automation has already outlived the application it was meant to support.

How It Works in Practice

The cleanest operating model is to separate approval ownership by identity class. Human access requests usually belong in a business-led workflow with IT or IAM enforcement, because the approval is about role, employment status, and segregation of duties. NHI access requests should be owned by the application, product, or platform team that actually depends on the identity, because that team understands what the service does, what systems it touches, and when it should be removed. The governance layer should still centralize policy so the request path is consistent, but the accountable approver should not be generic.

For NHIs, the request should include the workload, environment, purpose, scope, and expiration. That makes it possible to enforce least privilege and time-bound access instead of issuing broad standing permissions. The strongest pattern is to pair ownership with lifecycle controls: creation, approval, review, rotation, and offboarding. NHIMG’s Top 10 NHI Issues and the Ultimate Guide to NHIs both emphasize that ownership without lifecycle accountability does not prevent sprawl.

• Assign business ownership for human access and technical ownership for NHI access.
• Require a named offboarding owner for every service account, token, or integration.
• Set approval rules based on identity type, environment, and privilege level.
• Review access on a schedule that reflects workload change, not just employee change.

Policy should be aligned to current guidance from the NIST Cybersecurity Framework 2.0, but there is no universal standard for this yet, so most organisations define the control split themselves. These controls tend to break down when platform ownership is unclear across shared services, because no single team can credibly approve or revoke the access.

Common Variations and Edge Cases

Tighter ownership controls often increase workflow overhead, requiring organisations to balance speed against accountability. That tradeoff is real, especially in DevOps environments where service accounts are created and retired quickly. The best practice is evolving, not settled: some organisations use central IAM as the gatekeeper, while the approval decision remains with the application owner; others route low-risk NHI requests through automated policy with exception handling for high-risk access.

Edge cases appear when one identity supports multiple services, when ownership crosses business units, or when a vendor-managed integration is involved. In those cases, request governance should explicitly name the operational owner, the security reviewer, and the offboarding owner. If no one can answer who disables the identity when the workload ends, the process is incomplete. For more detailed lifecycle and audit framing, NHIMG’s Ultimate Guide to NHIs is the right reference point.

Human and non-human requests should not be merged just because both involve “access.” Where systems support both, separate queues or conditional routing are preferable. That split preserves clear accountability while still giving security teams one consistent policy standard.

Related resources from NHI Mgmt Group

• How can organisations reduce standing access across human and non-human identities?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• Who should own lifecycle governance across IAM and access controls?