The clearest sign is when row-and-column reports hide relationships that matter for security decisions. If teams cannot quickly see indirect access paths, unexpected privilege chains, or cross-application dependencies, tabular reporting is no longer sufficient. Graph-based visibility helps expose those relationships and makes anomalous access patterns easier to spot before they become incidents.
How to tell when reporting has stopped being decision-useful
Security teams usually outgrow row-and-column access reporting when the report still answers “who has access?” but no longer answers “what exposure does that access create?” The practical failure mode is not missing data alone, it is missing relationships. If a report cannot show how one entitlement leads to another, or how access spans systems that should be judged together, it is giving inventory, not risk visibility.
At that point, the limitation is structural. Access risk often sits in the path between identities, privileges and applications, so a flat report can look complete while still hiding the chain that matters. A usable view should make indirect access paths, privilege concentration and cross-application dependencies visible enough for a reviewer to judge whether the access pattern is normal, excessive or compounding.
The clearest signal is that reviewers need to manually stitch together multiple exports, screenshots or ownership lists before they can answer a basic security question. When the investigation begins outside the report, the reporting model has already failed its purpose. Graph-based views are valuable here because they let teams inspect relationships directly instead of inferring them from separate tables.
One useful benchmark is visibility into the actual population and shape of access, not just the existence of records. NHIMG research notes that only 5.7% of organisations have full visibility into their service accounts, which is a strong reminder that many teams are still operating with partial, fragmented access data rather than a defensible risk view.
What breaks when access data stays flat
Flat reporting tends to break in predictable ways. It is weak at showing inherited access, delegated administration, nested group effects and shared pathways across applications. It also struggles when one identity has access that is harmless in isolation but risky in combination, such as a role that is acceptable in one system but escalates meaningfully when paired with another entitlement elsewhere.
This is why “number of accounts” or “number of privileges” can be misleading as stand-alone indicators. Security decisions depend on context: who can reach what, through which path, under which dependency, and whether that path crosses a boundary that changes the security meaning of the access. If the report cannot express those dependencies, it cannot reliably support prioritisation, recertification or exception review.
Graph models improve this because they preserve relationships as first-class objects. That makes unusual paths, privilege chains and shared dependencies easier to spot, especially when the question is not simply whether access exists, but whether the access structure creates a wider blast radius than the raw entitlements suggest.
For teams mapping this back to identity risk, NHIMG’s Ultimate Guide to NHIs is useful because it frames visibility, lifecycle and excessive privilege as connected problems rather than separate hygiene tasks. The same guide’s section on key challenges and risks is a good reference point when access reporting needs to move from list-based reporting to relationship-based analysis.
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 NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Visibility and Discovery | Access reporting must expose who has what across relationships and chains. |
| NHI-07 — Overprivilege and Least Privilege | The question centers on when reporting can no longer reveal excessive or compounding access. | |
| NHI-10 — Governance and Lifecycle | Reporting becomes unusable when lifecycle and cross-application access changes are no longer visible. | |
| Recommendation — Use relationship-based discovery to surface indirect paths and privilege chains. Review effective privilege, not just assigned entitlements, before approving access. Recertify access using lifecycle-aware views that connect identities, systems and dependencies. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Security reporting must support the decisions the organisation actually needs to make about exposure. |
| DE.CM-08 — Monitoring for anomalies | Graph-based visibility helps analysts spot anomalous access patterns that flat reports hide. | |
| Recommendation — Align access reporting to the decisions and risk questions it must answer. Monitor access relationships for unusual patterns, not just static entitlement counts. | ||
| CIS Controls v8 | 6.3 — Use an Access Management System | Access reporting should come from a system that can model effective access and review it meaningfully. |
| 5.4 — Establish and Maintain an Audit Log Management Process | Usable access visibility depends on reviewable evidence of changes and access relationships. | |
| Recommendation — Centralize access review so effective permissions are visible in one control plane. Retain access-change evidence that can be correlated back to the relationship graph. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | The underlying issue is whether identity data is trustworthy enough to support security decisions. |
| Recommendation — Require sufficient identity assurance before relying on access data for risk judgments. | ||
| MITRE ATT&CK | T1069 — Permission Groups Discovery | Hidden group membership and nested access are exactly the kind of relationship flat reporting can miss. |
| Recommendation — Hunt for group and entitlement discovery to understand how access expands. | ||
Practitioner Guidance
What to verify: Check whether the reporting system can show indirect access paths, transitive privilege, and cross-system dependency without manual reconciliation. If a reviewer must join three reports to understand one risk, the reporting layer is no longer fit for security review.
Decision rule: If a flat report still works for headcount, inventory, or ownership checks but fails for exposure analysis, keep it as a management artefact and move security review to relationship-based views. The reporting format should match the decision being made, not the easiest export available.
What good looks like: A useful access report lets analysts move from an identity to its effective reach in a few steps, with obvious outliers, inherited privileges, and unusual chains standing out immediately. The goal is not more rows, it is faster judgement.
Practitioner takeaway: When access data cannot explain how privilege connects across systems, you no longer have reporting for risk decisions, only reporting for recordkeeping.
Related resources from NHI Mgmt Group
- What are the signs that external attack surface management is not giving security teams usable risk insight?
- How should security teams automate low-risk access approvals without creating hidden approval gaps?
- Why do coarse-grained access reviews create risk for audit and security teams?
- Why does standing database access increase security and operational risk for engineering teams?
