Reachable risk is a weakness that can be exercised in a live environment, not just detected in source code or configuration files. It is the practical threshold that separates low-value noise from issues that can lead to exploitation, data exposure, or service disruption.
Expanded Definition
Reachable risk describes a weakness that is not just present, but actually exercisable in the runtime path of an application, API, agent, or workload. In NHI security, that distinction matters because a secret, token, or permission only becomes operationally dangerous when an attacker or misconfigured process can reach it through a live trust path.
Definitions vary across vendors, especially in agentic systems where a reachable issue may involve an exposed credential, an over-permissive service account, a callable tool, or an abused workflow step. For practical governance, reachable risk is best treated as a triage concept that helps teams separate theoretical findings from issues that can lead to exploitation. That aligns with the risk-based focus of NIST Cybersecurity Framework 2.0, which emphasizes identifying and managing the assets and pathways that matter most.
The most common misapplication is treating any scanner alert as reachable risk, which occurs when teams ignore whether the vulnerable component is actually exposed to a live identity, network, or tool execution path.
Examples and Use Cases
Implementing reachable-risk analysis rigorously often introduces extra validation work, requiring organisations to weigh faster vulnerability closure against the cost of tracing real execution paths and identity permissions.
- A CI/CD pipeline flags a hardcoded API key, but the key only becomes reachable if a build agent can access a specific repository and secret store. The finding is low priority until the access path is confirmed. The broader problem pattern appears frequently in the Ultimate Guide to NHIs — Key Challenges and Risks.
- An internal service account has a dangerous permission, yet no production workload can invoke the function that uses it. That is a configuration concern, not a reachable risk, until a deployment path or agent gains the needed route.
- An AI agent with tool access can call a database connector and a file export workflow. If the agent is allowed to reach a sensitive table, the privilege is exploitable even if the connector itself appears safe in code review. This is closely related to the attack paths covered in OWASP NHI Top 10.
- A vault contains valid secrets, but the vault is isolated behind network controls and no workload can query it. The secrets are still risky, but the reachable exposure is lower than a broadly accessible vault described in Top 10 NHI Issues.
- A mis-scoped webhook endpoint accepts signed requests from a partner system. If that partner NHI is compromised, the reachable path turns a single credential issue into an execution opportunity.
For implementation guidance, teams usually pair reachability checks with policy models such as NIST Cybersecurity Framework 2.0 and identity controls that verify whether an action is actually permissible in production.
Why It Matters in NHI Security
Reachable risk is critical because NHI environments are full of dormant exposure that only becomes urgent when a live identity can exercise it. In the 2024 ESG Report: Managing Non-Human Identities from Oasis Security & ESG, 72% of organisations reported they have experienced or suspect a breach of non-human identities. That makes runtime reachability a practical way to prioritise what can actually be exploited, not just what looks wrong on paper.
Experienced operators use reachable-risk analysis to decide whether a secret leak, over-privileged service account, or exposed agent tool should trigger immediate containment, rotation, or access removal. This is especially important in zero trust programs, where every reachable path should be assumed to have value to an attacker until proven otherwise. The governance logic is reinforced by the Ultimate Guide to NHIs — Why NHI Security Matters Now, which shows why identity sprawl turns small mistakes into enterprise-wide exposure.
Organisations typically encounter reachable risk only after a secret is abused, a service is invoked unexpectedly, or an agent executes a tool it should never have reached, at which point the term becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Reachable secrets and exposed paths map to improper secret management risks. |
| NIST CSF 2.0 | PR.AC-4 | Reachability depends on whether access paths and permissions are truly active. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires validating every reachable path before allowing execution. |
Verify live access paths before escalating findings and tighten permissions on exposed NHI routes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
