The set of network paths through which an identity can interact with a service. In identity security, reachability matters as much as authentication because a valid credential is still dangerous if the service is broadly exposed and not limited by task, host, or time.
Expanded Definition
Protocol reachability describes the specific network paths, ports, protocols, and trust boundaries through which a non-human identity can actually contact a service. In NHI security, the question is not only whether an identity is valid, but whether it can reach the target at all, under the right conditions, from the right source, and for the right purpose. That makes reachability a practical control surface for service accounts, API keys, workload identities, and agentic AI systems.
Definitions vary across vendors on whether reachability includes only network exposure or also identity-aware routes such as mutual TLS, service mesh policy, and conditional gateway access. NHI Management Group treats it as the effective path to execution, which is broader than open ingress and narrower than general connectivity. The concept aligns well with least privilege and Zero Trust guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially when access must be constrained by source, function, and environment.
The most common misapplication is assuming authentication alone is sufficient, which occurs when teams allow a valid credential to operate across all reachable network paths.
Examples and Use Cases
Implementing protocol reachability rigorously often introduces routing and policy complexity, requiring organisations to weigh narrower attack surface against more operational overhead in service discovery and incident response.
- A CI/CD pipeline can authenticate to deployment APIs, but only from a hardened build subnet and only over mutually authenticated TLS.
- An agentic AI tool caller may hold a valid token, yet be blocked from production databases unless it reaches them through a controlled broker or gateway.
- A service account used for backups may be limited to a single storage endpoint rather than the broader internal network, reducing lateral movement potential.
- In a breach review, investigators may find that the credential itself was not stolen first, but that the service was reachable from too many hosts, echoing the patterns discussed in the Schneider Electric credentials breach.
- Cloud-native teams often pair protocol reachability controls with Zero Trust policy so that an identity can use an API only when the request originates from approved workload context and not from a generic internet path.
In practice, this means mapping each NHI to its allowed protocols, source networks, and brokered routes, then testing that those paths are enforced rather than merely documented.
Why It Matters in NHI Security
Protocol reachability is critical because excessive exposure turns a single credential into a broadly reusable attack path. NHIMG research shows that 97% of NHIs carry excessive privileges and 90% of IT leaders say proper NHI management is essential for zero-trust implementation, which makes network exposure and identity exposure inseparable governance concerns. When an identity can reach more services than its task requires, compromise scales quickly into lateral movement, data access, or command execution.
This is where standards guidance becomes operational: NIST SP 800-53 Rev 5 Security and Privacy Controls supports access restriction, while NHI-specific research in the Ultimate Guide to NHIs shows how often service accounts remain overexposed in real environments. Reachability also matters in post-incident containment, because broad network paths can keep abused identities viable even after secrets are rotated if the surrounding routes are unchanged.
Organisations typically encounter the full cost of protocol reachability only after a lateral movement event or production misuse, 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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) 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-01 | Protocol exposure is a core NHI attack surface addressed by this guidance. |
| NIST CSF 2.0 | PR.AC-3 | Access enforcement depends on restricting which paths can be used to reach services. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires reducing implicit network reachability between identities and services. |
| CSA MAESTRO | Agentic systems need constrained routes to tools and data sources. | |
| NIST SP 800-63 | AAL2 | Assurance is weakened when a valid identity can operate across overly broad paths. |
Pair credential assurance with network restrictions that limit where the identity can authenticate.
