Why do user-based access reviews matter when access decisions need to follow the person, not the app?

Why This Matters for Security Teams

User-based access reviews matter because access risk follows the person across roles, systems, and approval paths, while app-by-app reviews only show fragments of that footprint. When teams look at one application at a time, they can miss shared groups, inherited entitlements, manual grants, and dormant access that still exists after a transfer or project ends. NHIMG’s Ultimate Guide to NHIs notes that 68% of organisations do not know how to fully address NHI risks, which is a useful reminder that fragmented visibility is the common failure mode across identity programs, human and non-human alike.

For security teams, the real issue is not only whether access is approved, but whether the review model can reconstruct the person’s full effective access without relying on manual detective work. That matters most in organisations with matrix reporting, contractors, temporary elevations, and business applications that were never fully mapped into a single identity catalog. A person-first review reduces the chance that one forgotten entitlement survives because it lives in a different system, under a different naming convention, or behind a group that no one re-evaluates. This is why current guidance in OWASP Non-Human Identity Top 10 and NIST control practice both favour complete visibility over partial, app-local checks. In practice, many security teams discover toxic combinations only after a transfer, audit, or incident has already exposed the gap.

How It Works in Practice

A person-first review starts by treating the individual as the unit of analysis, then aggregating every entitlement tied to that person across direct assignments, groups, inherited roles, privileged paths, and manual exceptions. The goal is to answer a simple question: what can this person actually do right now, regardless of which app granted it?

Operationally, that means pulling identity data from IAM, PAM, directory services, SaaS admin consoles, and any business systems with local permission stores. The review should separate ownership from access, so managers, app owners, and system custodians each validate the part they can see, while the identity team reconciles overlaps. NIST SP 800-53 Rev. 5 supports this approach through access review and least-privilege controls, while the NHI Lifecycle Management Guide shows why lifecycle state is the right lens for exposure and revocation decisions.

• Aggregate all entitlements by person, not by application.
• Include direct grants, nested groups, and delegated administration paths.
• Flag privileges that persist beyond role, project, or contract end dates.
• Require reviewers to confirm business need and not just system presence.
• Revoke or downgrade access in the same workflow that identifies excess.

Where possible, teams should automate identity-to-access correlation and use policy rules to highlight outliers, such as privileged access without a current job need or access to systems outside the person’s function. These controls tend to break down in environments with heavy shadow IT, poorly integrated SaaS tools, or business units that maintain separate admin domains because the full access footprint cannot be reconstructed reliably.

Common Variations and Edge Cases

Tighter person-based reviews often increase operational overhead, requiring organisations to balance completeness against review fatigue and data quality. That tradeoff becomes sharper in contractor-heavy environments, mergers, and shared-service models where the same person may legitimately hold multiple accounts or business roles. Best practice is evolving here: there is no universal standard for how much duplication is acceptable, but there is broad agreement that unexplained duplication should be investigated.

One common edge case is service-linked access that appears to belong to a person but actually supports a team-owned process. Another is emergency or JIT access, where the entitlement is valid for a short period and should be reviewed against the ticket or approval record, not treated as standing access. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it highlights how excessive privilege and poor visibility amplify review gaps. For teams comparing policy models, the OWASP Non-Human Identity Top 10 and NIST-based governance both point toward evidence-driven recertification rather than checkbox approvals.

Person-first reviews also need careful handling for federated identities, service accounts mapped to an operator, and shared admin accounts, because the named user may not equal the true risk owner. In those cases, the review should document both the operational custodian and the accountable approver.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• When do NHI access reviews create more value than a one-time cleanup?
• What is the difference between role-based access and API key governance for NHI security?
• Why do user access reviews matter so much in FedRAMP programmes?