Who should own access governance when identity spans human and machine accounts?

Why Access Governance Must Have a Clear Owner

When identity spans people, service accounts, API keys, and automation, access governance fails fastest in the gaps between teams. The business owner understands why access exists, while IAM and security operations understand how it is granted, reviewed, and revoked. That split matters because NHIs scale faster than human identities and often persist after the original use case is gone, a pattern NHI Management Group highlights in its Ultimate Guide to NHIs.

NIST CSF 2.0 treats access governance as an accountability problem, not just a tooling problem, and OWASP’s OWASP Non-Human Identity Top 10 similarly emphasises lifecycle and privilege control. The operational risk is simple: if no one owns the entitlement, no one owns the cleanup, and stale access becomes normalised. In practice, many security teams discover this only after an unused service account, token, or shared machine identity has already been exploited rather than through a deliberate review cycle.

How Access Ownership Should Work in Practice

Best practice is to assign a single business or application owner for each access path, then require IAM or security operations to enforce the mechanics. The owner should approve why access is needed, confirm the data or system being touched, and sign off when the business purpose changes. IAM then translates that decision into policy, provisioning, and periodic recertification.

For mixed human and machine environments, the same ownership model should cover both identity types, but the controls differ. Human access usually maps to RBAC or PAM workflows. Machine access needs secrets hygiene, workload identity, and time-bound issuance. Current guidance suggests aligning this with the Ultimate Guide to NHIs, especially for lifecycle review and offboarding. The owner should be able to answer three questions at any time: who needs the access, what exact system or secret it reaches, and when it should be removed.

• Use one accountable owner per application or service, even if multiple teams consume the identity.
• Separate approval from enforcement: business owners approve, IAM provisions, and security validates exceptions.
• Review service accounts and API keys on a fixed cadence, not only during incidents or audits.
• Prefer short-lived credentials and workload identity over long-lived shared secrets.

Where this guidance breaks down is in highly federated platforms with shared platform teams and no application-level ownership, because entitlement reviews then become political rather than operational.

Common Ownership Failures and Edge Cases

Tighter ownership improves accountability, but it also adds review overhead, so organisations must balance speed against control. That tradeoff becomes visible in shared platforms, DevOps pipelines, and vendor-integrated systems where one identity may support many consumers. In those cases, the best practice is evolving toward a named primary owner plus delegated technical stewards, rather than ambiguous committee ownership.

Exceptions should be documented, not informal. For example, a break-glass account, CI/CD service principal, or integration token may need different review timing than a standard employee account, but it still needs an owner and an expiry decision. The NHI Management Group research on breach prevalence shows why this matters: the 2024 ESG Report: Managing Non-Human Identities found that 72% of organisations have experienced or suspect an NHI breach, which reinforces the need for explicit accountability.

There is no universal standard for exactly how often every mixed identity should be recertified, but current guidance favours shorter cycles for machine identities with broad privileges and longer cycles only where the risk is demonstrably low. The safest pattern is to make the owner responsible for the decision, then make IAM and security responsible for proving it was enforced.

Related resources from NHI Mgmt Group

• Who should own password governance when identity spans humans and non-human identities?
• Why do machine identities complicate identity governance more than human accounts?
• Who should own identity security when access spans users and machine identities?
• Who should own governance when access spans humans, service accounts, and AI agents?