Who is accountable for access reviews when users exist in multiple identity systems?

Why This Matters for Security Teams

When a person appears in multiple identity systems, access review becomes an ownership problem, not a directory problem. The risk is that one team signs off on a combined list while another team owns the entitlement, creating gaps in offboarding, remediation, and audit evidence. That matters even more for NHIs, where the blast radius is often larger and lifecycle events are less visible than with human accounts.

NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, and that lack of visibility directly undermines review accountability. The problem is not solved by a single spreadsheet or an annual attestation if the source system that granted access is hidden. The OWASP Non-Human Identity Top 10 also reinforces that identity sprawl and weak lifecycle control are central NHI risks. In practice, many security teams discover review ownership failures only after an offboarding miss or privilege abuse has already occurred, rather than through intentional governance.

How It Works in Practice

Accountability should follow the entitlement source and the lifecycle owner, while the review itself can be unified across directories. That means the team responsible for the application, platform, or resource that issued access must remain visible in the review record. The reviewer can approve or reject in one workflow, but each access item should preserve where it came from, who can revoke it, and what downstream system will be affected.

This model is usually implemented with identity reconciliation, entitlement cataloguing, and review routing rules. A practical workflow looks like this:

• Match the person across directories using a stable enterprise identity key, not just display name or email.
• Attach each entitlement to its source system, business owner, and technical owner.
• Route exceptions and removals back to the system that granted the access.
• Record evidence showing who reviewed, who approved, and who executed the revocation.

For NHI and agentic workloads, the same principle applies, but the source may be a secrets vault, CI/CD pipeline, or workload identity service rather than an HR-linked directory. The NHI Lifecycle Management Guide is useful here because it frames access as a lifecycle event, not a static permission set. Where organisations are maturing toward automation, the best practice is evolving toward policy-driven reviews that integrate with systems such as SPIFFE for workload identity and align with least-privilege controls in the NIST Zero Trust Architecture guidance. These controls tend to break down when identity joins are inconsistent across systems because the reviewer cannot reliably tell which system is authoritative for revocation.

Common Variations and Edge Cases

Tighter review ownership often increases operational overhead, requiring organisations to balance audit precision against workflow complexity. That tradeoff becomes visible in mergers, outsourced operations, and shared platforms where one person may legitimately hold entitlements in several systems for different reasons.

Current guidance suggests treating each entitlement independently even when the underlying person is the same. If one system feeds another through provisioning, the authoritative owner is usually the system that can remove access without waiting for manual follow-up. If two systems jointly govern access, document a primary owner and a secondary approver so accountability is not diluted.

There is no universal standard for this yet, but the direction of travel is clear: shared reviews are acceptable only when source ownership remains explicit. That is especially important for sensitive access and secrets. NHI Mgmt Group’s research shows that 79% of organisations have experienced secrets leaks, which makes traceable ownership more than a compliance preference. The Top 10 NHI Issues page also highlights how quickly review processes fail when governance is split across tools. In complex environments, the model breaks down when entitlements are mirrored across directories but revocation still depends on manual coordination between teams.

Related resources from NHI Mgmt Group

• Who is accountable when access is decided in real time across multiple identity types?
• Who is accountable when DNS weaknesses disrupt access to identity services?
• Who should be accountable for DNS access reviews?
• Why do runtime identity controls matter more than periodic access reviews?