Reach

Expanded Definition

Reach describes the actual blast radius of a user or NHI after permissions are resolved across direct grants, inherited roles, group nesting, service connections, and trust relationships. In NHI governance, reach is more useful than raw entitlement counts because it reflects what an identity can truly affect in production.

This matters because a low-friction permission model can still create high-risk exposure when the identity can touch sensitive data stores, deployment systems, or credential vaults. In practice, reach often spans identities, tools, and resources that appear separate in a directory view but are linked through automation, delegation, or shared infrastructure. The control question is not only “what was assigned?” but “what can be reached after all resolution paths are applied?” That distinction aligns with least privilege and access review concepts in NIST SP 800-53 Rev 5 Security and Privacy Controls and with NHI visibility guidance in Ultimate Guide to NHIs.

The most common misapplication is treating reach as a static role list, which occurs when teams ignore group nesting, token scopes, and hidden service-to-service paths.

Examples and Use Cases

Implementing reach analysis rigorously often introduces dependency mapping overhead, requiring organisations to weigh better risk visibility against the cost of resolving identity graph complexity.

• A CI/CD service account can deploy to production because its group membership inherits a broad deployment role, even though the direct assignment looks limited.
• An API key stored in a developer tool can reach a secrets manager, then a database, through chained service permissions that scanners do not fully enumerate.
• A support automation bot can access customer records indirectly because its workflow account inherits permissions from a shared operations group, as discussed in Ultimate Guide to NHIs.
• A human admin may appear low risk in a directory export, but effective reach expands after nested RBAC assignments and delegated approval paths are resolved under NIST SP 800-53 Rev 5 Security and Privacy Controls.
• A workload identity can touch multiple clusters through federated trust, creating a wider operational footprint than the original service definition suggests.

These examples show why reach analysis is a graph problem, not a spreadsheet problem.

Why It Matters in NHI Security

Reach is central to NHI security because compromise impact is determined by where an identity can move, not just how it authenticates. If an attacker steals a token or API key, the reachable systems define the immediate containment challenge. That makes reach a core input to privileged access review, blast-radius reduction, and Zero Trust planning.

The problem is amplified by poor visibility. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, and that lack of visibility makes reach estimation incomplete and often misleading. The same issue appears in access governance when teams review direct permissions but miss inherited paths, stale group membership, and shadow automation. This is why the broader NHI lifecycle guidance in Ultimate Guide to NHIs is so important, especially when paired with least-privilege controls from NIST SP 800-53 Rev 5 Security and Privacy Controls.

Organisations typically encounter the operational cost of reach only after a token is abused, at which point containment, revocation, and graph cleanup become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when AI systems can reach too many data sources?
• What breaks when a low-trust SaaS account can reach institutional data?
• What breaks when an agent can reach local files and network egress?
• What breaks when spreadsheet formulas can reach host execution?