What is the difference between data-centric security and an access graph in enterprise identity governance?

Why This Matters for Security Teams

Data-centric security and an access graph answer different questions, and confusing them leads to blind spots. Data-centric security asks where sensitive data lives, who touched it, and whether the exposure should be reduced at the file, message, or collaboration layer. An access graph asks what an identity can reach across systems, including inherited paths, delegated access, and privilege chaining. Enterprise teams need both because exposure does not always equal authorization, and authorization does not always show immediate data sensitivity. NIST’s Cybersecurity Framework 2.0 frames this as a governance problem that spans identification, protection, and continuous monitoring.

For NHI and identity governance teams, the distinction matters even more because non-human identities often outnumber humans by a wide margin and are frequently over-privileged. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which means an access graph can expose dangerous reach even when the underlying data set appears well protected. The operational mistake is assuming that data classification alone will reveal how a service account, API key, or agent can move laterally. In practice, many security teams discover that excess access and sensitive exposure were both present only after an investigation has already started.

How It Works in Practice

Data-centric security typically begins with discovery and classification. Teams identify regulated, confidential, or business-critical data, then apply controls such as access reviews, masking, DLP, retention limits, or automated remediation when sharing expands beyond policy. The control plane is the asset itself. By contrast, an access graph starts with identities, roles, groups, service accounts, and entitlements, then maps the paths that connect them to applications, files, infrastructure, and downstream permissions. The control plane is the relationship between identity and resource. OWASP’s Non-Human Identity Top 10 is useful here because many of the risks are not in the object being protected, but in the unchecked reach of the identity that can act on it.

• Use data-centric security to answer: what is sensitive, where is it stored, and where is it flowing?
• Use an access graph to answer: which identities can reach it, directly or through chained permissions?
• Use both to identify the mismatch between exposure and authorization, especially for NHIs, shared accounts, and automation workloads.
• Prioritise remediation when the graph shows privilege paths to sensitive repositories, admin APIs, or collaboration spaces.

NHIMG’s Top 10 NHI Issues is a practical reminder that secrets rotation, visibility, and excessive privilege are recurring failure modes, not edge cases. That is why an access graph is often the better tool for entitlement governance, while data-centric security is the better tool for exposure reduction. The two are complementary, not interchangeable. These controls tend to break down in highly federated environments with shadow IT, unmanaged collaboration tenants, and service-to-service sprawl because identity paths and data flows change faster than policy reviews can keep up.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance faster remediation against the risk of overcorrecting legitimate workflows. That tradeoff becomes obvious when teams manage both humans and NHIs, because a human user may need periodic review while an automation account may need task-scoped access that changes several times a day. There is no universal standard for this yet, but current guidance suggests treating data-centric controls and access graphs as separate layers of defence rather than forcing one model to do both jobs.

Edge cases appear when sensitive data is duplicated into caches, exports, tickets, analytics tools, or AI workflows. In those environments, the access graph may show no direct path to the original source, while the data has already been replicated into new systems with different permissions. That is why governance teams often pair an access graph with lifecycle controls described in NHIMG’s Lifecycle Processes for Managing NHIs. For audit and accountability questions, the Regulatory and Audit Perspectives section is also relevant because it highlights why evidence of access is not the same as evidence of safe handling. The practical rule is simple: use data-centric security to reduce where data can travel, and use access graphs to reduce who can travel with it.

Related resources from NHI Mgmt Group

• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between attack surface management and NHI governance?
• Why is it important to integrate identity and data governance?
• What is the difference between reviewing human access and reviewing NHIs?