A theoretical vulnerability exists in code or configuration, but reachable risk exists when the vulnerable path is active in production and can be exercised by an attacker. The distinction matters because remediation capacity is limited. Security teams should treat reachability as the threshold for urgent response and exploitability as the basis for prioritization.
Why This Matters for Security Teams
The distinction between theoretical vulnerability and reachable risk is where prioritisation becomes operational. A flaw may exist in a library, service account, API, or agent workflow, but if that path is not exposed in production, it is not an immediate attack surface. Security teams get into trouble when they spend scarce remediation capacity on issues that cannot be exercised, while missing the smaller set of issues that can actually be chained into compromise.
This is especially important in NHI environments because secrets, tokens, and service accounts often persist far longer than intended. NHIMG research shows that 91.6% of secrets remain valid five days after notification, and only 20% of organisations have formal offboarding and revocation processes for API keys. That gap means a weakness is not just a code defect, it may be a live path for abuse. The governance lens in Top 10 NHI Issues and the broader lifecycle guidance in Ultimate Guide to NHIs — Key Challenges and Risks both reinforce the same practical rule: reachability is the threshold that changes a finding from abstract to urgent.
Security leaders should treat theoretical vulnerability as a signal for inventory and validation, not automatic emergency response. Current guidance from NIST Cybersecurity Framework 2.0 supports this kind of risk-based prioritisation across identify, protect, detect, respond, and recover. In practice, many security teams encounter the real problem only after an attacker has already followed a reachable path through a neglected secret or exposed service account, rather than through intentional discovery.
How It Works in Practice
Reachability analysis asks a simple question: can the vulnerable condition be exercised from a real production path, by a real actor, under current controls? That usually means checking whether the service is deployed, whether the route is exposed, whether authentication is bypassable, whether a secret is live, and whether the vulnerable component can be reached through tooling, CI/CD, or an agent workflow. A flaw inside dormant code is not zero risk, but it is usually lower priority than a flaw behind an active identity path.
For NHI security, this distinction is critical because machine identities often have broad, persistent access. NHIMG notes that 97% of NHIs carry excessive privileges and 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, which means a weakness can quickly become reachable. The practical test is not just “does the issue exist?” but “can it be exercised through a valid token, active integration, or reachable endpoint?” That is why the OWASP NHI Top 10 remains useful for mapping exposure paths, while CISA cyber threat advisories help teams validate whether a class of weakness is being actively exploited in the wild.
- Confirm the vulnerable asset is deployed, reachable, and in use.
- Check whether the path requires a valid NHI secret, token, or service account.
- Determine whether compensating controls actually block execution, not just report it.
- Prioritise issues that can be chained into privilege escalation, lateral movement, or data access.
That approach is most effective when asset inventory, secret visibility, and runtime telemetry are current. These controls tend to break down when production visibility is incomplete and teams cannot prove whether a path is truly active.
Common Variations and Edge Cases
Tighter reachability analysis often increases operational overhead, requiring organisations to balance precision against speed. Not every environment can support full runtime testing, and there is no universal standard for this yet, so teams should label some findings as “theoretically present but not currently reachable” rather than forcing binary decisions.
Edge cases usually appear in environments with ephemeral infrastructure, branch-specific CI/CD pipelines, or external integrations that only activate under certain events. A flaw may look dormant in one environment and reachable in another because a secret is reused, a webhook is exposed, or an NHI has broader privileges than intended. That is why guidance in Ultimate Guide to NHIs — Why NHI Security Matters Now matters for operational triage, not just strategy: live identity paths create real exposure even when the code defect seems minor.
For agentic systems and automated workflows, the boundary can shift quickly. An AI agent, build bot, or orchestration tool may turn an otherwise theoretical weakness into reachable risk by chaining tools, retrieving secrets, or triggering unintended actions. In those cases, JetBrains GitHub plugin token exposure is a useful reminder that exposed developer tooling can become an execution path, not just a configuration mistake. The right response is to reassess reachability whenever credentials rotate slowly, permissions expand, or an integration changes behaviour.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Reachability depends on exposed NHI secrets and active identity paths. |
| NIST CSF 2.0 | ID.RA-1 | Risk analysis requires distinguishing theoretical flaws from exploitable exposure. |
| NIST AI RMF | GOVERN | Risk governance should account for dynamic exposure in automated and AI-driven systems. |
Validate which NHIs are live, reachable, and overprivileged before assigning remediation priority.
