An access report is an inventory of recorded permissions. An identity graph adds the relationships behind those permissions, including groups, roles, applications, owners, and trust paths. That extra context shows effective access, not just assigned access, so security teams can evaluate indirect reach, support access reviews, and investigate compromise with much more precision.
How Identity Graphs and Access Reports Differ in Security Operations
An access report tells you what access was recorded. An identity graph tells you how that access is connected, which is the difference between a snapshot and a map. For security teams, that matters because permissions are often inherited through groups, roles, apps, and delegated relationships rather than granted directly. When you are trying to understand exposure, indirect paths are usually where the real answer sits.
This distinction becomes especially important in NHI-heavy environments, where service accounts, API keys, and workload identities can accumulate privileges through hidden trust paths. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, which shows how easily a flat permission inventory can miss the underlying structure of access. Ultimate Guide to NHIs
In practice, teams often discover the gap only after an access review, incident, or audit has already exposed a privilege path they did not expect.
How the Two Views Work in Practice
An access report is useful when the question is narrow: who has a permission, which account can reach a system, or what was granted to a user or service. It is a control record. It works best for compliance checks, recertification, and basic entitlement cleanup because it lists the visible assignments that exist at a point in time.
An identity graph goes further by connecting identities to the entities that shape effective access. That can include group membership, application ownership, role nesting, federated trust, shared credentials, and the path from an initial identity to a downstream resource. In other words, it explains why the permission exists and whether the reach is direct or inherited. That extra layer is what helps analysts answer questions such as whether a dormant service account can still reach production through a group, or whether a third-party integration inherits broader access than the report suggests.
- Use access reports for inventories, approvals, and control attestations.
- Use identity graphs for blast-radius analysis, privilege path tracing, and compromise investigations.
- Use both together when reviewing sensitive access, because the report shows assignment while the graph shows effective reach.
For NHI governance, the graph is often the more operationally useful view because machine identities can be embedded in automation, CI/CD, and application chains where one credential opens many paths. The access report may be accurate and still incomplete in terms of risk, because it does not always reveal inherited trust or cross-system dependencies. The OWASP Non-Human Identity Top 10 is a useful companion reference for this kind of credential and privilege visibility problem. OWASP Non-Human Identity Top 10
These controls tend to break down in highly federated environments where ownership is split across teams and access is assembled dynamically at runtime, because the assigned permission and the usable permission are no longer the same thing.
Where the Distinction Matters Most
Stricter visibility often increases data integration effort, so organisations have to balance simplicity against accuracy. That tradeoff is real, because a graph is only as good as the identity sources, ownership metadata, and relationship mapping that feed it.
Current guidance suggests treating access reports as the minimum baseline and identity graphs as the higher-value layer when the question is exposure rather than mere entitlement. The difference matters most in access reviews, incident response, third-party trust analysis, and NHI lifecycle management. An access report can tell you that a token exists; an identity graph can tell you what that token can reach through inherited paths and shared dependencies.
That is also why teams should not confuse “no direct permission” with “no access.” In environments with nested roles, application-to-application trust, or delegated admin structures, the practical exposure can be wider than the report implies. The graph is what turns a static entitlement list into a usable security model, but it also demands better metadata discipline, because missing ownership or stale relationships can distort the result.
Practitioner takeaway: use access reports to prove what is assigned, and use identity graphs to decide what is actually exposed; if you only have the first, you are reviewing records, not risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Identity graphs depend on inventory and ownership of machine identities and their relationships. |
| NHI-03 — Privilege and Access Scope | The question is about assigned versus effective access and inherited privilege paths. | |
| NHI-06 — Visibility and Monitoring | Graphing relationships improves visibility into hidden trust paths and exposure. | |
| Recommendation — Map all machine identities and owners before relying on entitlement reporting. Trace effective privilege paths, not just direct grants, when reviewing access. Correlate identity relationships with access telemetry to reveal hidden reach. | ||
| CIS Controls v8 | 5 — Account Management | Access reports and graphs both support entitlement review and account governance. |
| 6 — Access Control Management | The distinction centers on how permissions are granted, inherited, and enforced. | |
| 8 — Audit Log Management | Graphs and reports are both strengthened when access evidence is tied to logs. | |
| Recommendation — Review and remove unnecessary account access using authoritative entitlement records. Enforce least privilege based on effective access, not only recorded assignments. Retain access evidence that can validate who actually used sensitive entitlements. | ||
| NIST CSF 2.0 | ID.AM — Asset Management | Identity graphs improve the asset and identity inventory needed to understand exposure. |
| PR.AC — Identity Management, Authentication and Access Control | The topic distinguishes assigned permissions from effective access under access control. | |
| Recommendation — Maintain an authoritative identity inventory with relationships and ownership metadata. Govern access by effective reach and trust paths, not only by direct permission lists. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Identity graphs help expose abuse of legitimate accounts and inherited access paths. |
| Recommendation — Hunt for abuse of valid accounts that gain broader reach through trusted relationships. | ||
Related resources from NHI Mgmt Group
- What is the difference between GitHub-hosted runners and CodeBuild-hosted runners for identity and access risk?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between patching a vulnerability and reducing identity blast radius?
