What breaks when security teams rely on access reports instead of an identity graph?

Why Access Reports Miss the Real Exposure Path

Access reports are snapshots of recorded entitlements, not a full model of how access can actually be exercised. That matters because identity risk often emerges through indirect relationships: nested groups, inherited roles, delegated administration, application trust, and stale transitive permissions. In practice, a team can remove the obvious grant and still leave a usable path in place. For identity-heavy environments, that gap turns remediation into guesswork rather than evidence-based control.

When organisations rely on the report alone, they also lose the ability to explain why access exists and which upstream relationship created it. That makes review work slower, increases the chance of removing the wrong grant, and leaves residual exposure undocumented. The problem is not just visibility; it is decision quality. An access report may show who has something, but not whether that access is reachable, inherited, or still active after a change. NHI guidance consistently points to this visibility gap as a core weakness, especially where machine and delegated identities proliferate. In practice, many teams discover the hidden path only after an access review has already been signed off.

How an Identity Graph Changes the Investigation

An identity graph connects users, service accounts, groups, roles, applications, trusts, and delegation edges into a relationship model. Instead of asking only whether an entitlement exists, security teams can ask how the entitlement is reached, whether it is direct or indirect, and what other identities inherit the same path. That is the practical difference between recording access and understanding exposure.

In a mature workflow, the graph supports three kinds of questions. First, it shows reachability: can this identity actually get to the target system, token, or role? Second, it shows dependency: if one group, parent role, or app trust is changed, what else breaks? Third, it shows blast radius: if the account is compromised, what linked permissions become available through chained relationships?

• Nested groups reveal privileges that flat exports usually flatten away.
• Inherited roles expose where review evidence is incomplete even though access is still effective.
• Delegation and app trust show why a removed direct grant may not remove operational access.
• Relationship paths help teams prioritise the exposures most likely to matter in an incident.

The operational payoff is clearer remediation. Instead of revoking one entitlement at a time and hoping the path collapses, teams can identify the upstream link that actually controls the access route. That is especially important for service accounts, federated apps, and privileged workflows where direct and indirect permissions coexist. The OWASP Non-Human Identity Top 10 is useful here because it frames identity sprawl, excessive privilege, and poor lifecycle visibility as recurring failure modes rather than isolated exceptions. NHIMG’s Ultimate Guide to NHIs is equally relevant for understanding why machine identities amplify this gap at scale. These controls tend to break down when the environment depends on layered inheritance across multiple directories and apps because no single report captures the full effective access path.

Where Reports Are Still Useful, and Where They Mislead

More structured reporting can still be valuable for certification, audit evidence, and spot checks, but it introduces a tradeoff: simplicity versus fidelity. A report is easier to export, review, and sign off, yet that same simplicity hides the exact relationship logic that determines whether access is truly removable. Best practice is evolving toward graph-backed review rather than abandoning reports entirely.

The biggest edge case is environments with multiple identity systems stitched together through federation or automation. In those settings, access may be technically valid in one system but operationally enforced by another, so a report from either side alone gives a partial answer. Teams should also be cautious with temporary elevation, delegated admin, and app-to-app trust because these paths can reconstitute access even after a direct grant is removed. The most common mistake is treating the access review as the end state rather than as evidence that still needs path validation.

For high-risk identities, especially privileged and non-human ones, the useful question is not “does a grant appear?” but “can this identity still reach the target after the reported grant is removed?” If the answer depends on inherited or delegated paths, the report is descriptive, not authoritative. That distinction matters most in environments where access changes frequently and where compromise would immediately expand into additional systems or secrets.

Risk and Threat Considerations

Relying on access reports creates residual exposure because hidden relationship paths can preserve effective access after a visible entitlement is removed. That is a material governance and security risk, particularly where nested privilege or application trust can be abused to maintain unauthorized reach.

Failure mechanism: The weakness appears when defenders review direct grants but do not model inherited, delegated, or transitive access. Attackers or careless insiders benefit from the same gap because a compromised account may still activate privileges through upstream group membership, federated trust, or role chaining even after remediation of the obvious permission.

Impact: Organisations can believe access has been revoked while the identity still reaches sensitive systems, tokens, or data. That increases the chance of lateral movement, failed offboarding, incomplete incident containment, and overconfident certification decisions.

Practitioner Guidance

What to prioritise: Treat identities with delegated, inherited, or cross-application access as the first candidates for graph-based review. Those are the accounts most likely to appear clean in a report while still retaining effective access through another path.

What to verify: Before trusting a report, verify that it answers both “who has the entitlement” and “what path makes the entitlement effective.” If the report cannot show the upstream source of access, it is not sufficient for revocation decisions.

Decision rule: If removing a direct grant does not eliminate reachability in a test or query, escalate the issue as a path-remediation problem, not a permissions cleanup task. The control objective is to remove the route, not just one visible edge.

Practitioner takeaway: Reports are good for inventory; graphs are needed for truth. The important judgement is whether access is merely recorded or actually reachable, because remediation only works when the effective path is understood.

Related resources from NHI Mgmt Group

• What breaks when identity teams rely on one-off access reviews instead of scheduled reporting?
• What breaks when security teams rely on keys and passwords instead of continuous cloud access controls?
• What breaks when security teams rely on isolated scanners and dashboards instead of a connected asset graph?
• What breaks when identity security teams rely on review scores instead of operational evidence?