Reachable exploitability

Expanded Definition

Reachable exploitability is the practical test of whether a weakness can be used from an attacker’s current position to reach a target, pivot across trust boundaries, or influence a valuable asset. In NHI security, the term matters because exposed service accounts, API keys, tokens, and certificates often create paths that look minor in isolation but become high-impact once chained together.

Unlike raw vulnerability counts, reachable exploitability prioritises path-based risk. A finding is more urgent when it sits on a route that an adversary can actually traverse, such as an internet-facing workload, an over-permissioned secret, or a lateral movement path through a cloud control plane. This is consistent with the asset-focused logic in NIST Cybersecurity Framework 2.0, which pushes organisations to understand where exposure creates operational impact.

Definitions vary across vendors on how they score reachability, and no single standard governs this yet. Some tools emphasise network pathing, while others include identity graph relationships, privilege inheritance, and runtime exposure. The most common misapplication is treating every exploitable weakness as equally reachable, which occurs when teams ignore current access paths, credential scope, and whether the asset is actually within an attacker’s current blast radius.

Examples and Use Cases

Implementing reachable exploitability rigorously often introduces more analysis overhead, requiring organisations to weigh faster triage against the cost of modeling real attack paths instead of relying on simple severity labels.

• A leaked API key in a CI/CD variable is ranked higher when it can reach production deployment permissions, especially if it connects to the patterns described in 52 NHI Breaches Analysis.
• A misconfigured service account with broad cloud permissions is more exploitable than a low-privilege account because the attacker can pivot to storage, identity, or compute resources.
• A token stored in code is lower priority if it is already expired, but becomes reachable exploitability when the same token class is still valid and tied to a live workload.
• An exposed secret in a logging pipeline becomes urgent when it can be used to impersonate automation and move into privileged administrative workflows.
• An external vulnerability scan finding is deprioritised if there is no network path, no usable credential, and no identity relationship that lets an attacker reach the asset.

For identity-driven environments, reachability analysis often pairs with SPIFFE-style workload identity models, because the question is not just whether a flaw exists, but whether a valid identity can use it in production.

Why It Matters in NHI Security

Reachable exploitability matters because most NHI failures are not caused by one catastrophic flaw, but by chains of weak controls: overly broad privilege, leaked secrets, stale credentials, and poor visibility across workloads. NHIMG reports that 97% of NHIs carry excessive privileges, which means many weaknesses are not merely present but reachable in practice once an attacker gains a foothold.

This is why remediation priority should follow the paths an adversary can actually use. The same principle appears in attack-path governance guidance from CISA Zero Trust Maturity Model, where identity, device, and network trust are treated as conditions that must be continuously evaluated rather than assumed. In NHI environments, reachable exploitability also helps separate harmless exposure from identity material that can be used to impersonate automation, abuse cloud control planes, or trigger downstream privilege escalation.

Organisations typically encounter this consequence only after an incident reveals that a low-severity finding was part of a live attack path, at which point reachable exploitability becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between theoretical vulnerability and reachable risk?
• How should teams prioritise patching when exploitability assumptions are no longer stable?
• Why do backup tools create high-impact exposure when they are reachable from the network?
• Reachable risk