Reachable is not exploitable: layering exposure so prioritization reflects real risk

The binary that misleads

Security teams face a prioritization problem that worsens with every new scanner deployment: findings accumulate faster than they can be remediated, and the signals used to sort them are frequently too coarse to be useful. Vulnerability scanners return findings. Asset inventories return hosts. Neither answer the question that matters operationally: can an adversary meaningfully reach this system and exploit it in a way that hurts the business?

The shortcut answer, "it's exposed to the internet, therefore it's a priority," collapses five distinct analytical questions into one and generates remediation backlogs that cannot be cleared at the rate new findings arrive. The consequence is queue saturation: teams patch low-consequence exposures at the same velocity as critical ones because the signal that separates them was never captured.

The alternative is not a scoring formula. It is a layered exposure model, five sequential questions, each narrowing the population of assets that carry real operational risk. A "yes" at an earlier layer does not imply a "yes" at the next one. That distinction is the entire thesis.

Critically, this model treats attacker vantage point as a variable rather than a fixed assumption. An adversary who is external and unauthenticated faces a different set of barriers than one who has already established a foothold inside the network. Most compromises begin with an external adversary gaining that initial foothold, but the layers following that point change substantially once internal access exists. The model should be applied with the attacker's current position made explicit, because a finding that stalls at Layer 2 for an external adversary may clear it entirely for an adversary already operating inside the perimeter.

Layer 1: discoverability

The first question is whether an adversary can find the asset at all. Discoverability includes DNS resolution, certificate transparency logs, and internet-wide scan data from platforms like Shodan or Censys, sources that are accessible through passive reconnaissance requiring no authentication and leaving no log entry on the target system.

An asset that appears in certificate transparency records or responds to unauthenticated probes is discoverable regardless of whether the organization knows the asset exists. This is precisely the class of finding where shadow IT and forgotten subdomains create gaps: the asset is in scope for an adversary before it appears in the organization's own inventory.

Note that identifying open ports requires active reconnaissance, sending probes and observing responses, which is distinct from the passive techniques listed above. Active scanning may leave traces and is a separate step from passive discoverability.

What discoverability does not tell you: whether the asset can be reached through the network paths an adversary would use, and certainly not whether any weakness on it is exploitable.

Decision question: Does your asset inventory process capture externally-observed hostnames, IPs, and certificates rather than just internally-provisioned assets? If not, your Layer 1 signal is incomplete before you reach Layer 2.

Layer 2: network reachability

Discoverability tells you an adversary can see the asset. Reachability tells you whether they can send traffic to the vulnerable service and receive a meaningful response through a path that delivers traffic to the application rather than merely to an intermediate control that absorbs or drops it.

Network reachability is a function of firewall rules, security group configurations, network access control lists, and routing policy. However, several controls are commonly mischaracterised at this layer:

The correct framing at this layer is: does a control make the vulnerable service unreachable due to network configuration, such as a firewall rule that drops all inbound traffic to the service from external sources? If the traffic arrives at the application regardless of intermediate controls, the service is reachable. Mark it accordingly.

Reachability is also not binary across all protocols. A host may be reachable over TCP/443 and unreachable over TCP/22 from the same source network. Treating "reachable" as an asset-level attribute rather than a service-and-path attribute produces inaccurate priority signals.

Attacker vantage point matters here: an adversary who has already established internal access may reach services that are blocked to external sources entirely. Assess reachability separately for external and post-foothold attacker positions, and document which position each assessment reflects.

Failure mode: Teams that rely solely on port scan results without validating firewall policy may incorrectly mark an asset as reachable when a mid-path control drops the traffic, or incorrectly mark it as unreachable because a proxy sits in front of an application that is still fully accessible through that proxy. Validating reachability from external vantage points equivalent to those an adversary would use can surface this gap.

Layer 3: accessibility and preconditions

Reachability gets traffic to the service. Accessibility determines whether an adversary can interact with the vulnerable component given the preconditions it requires.

The NVD records CVSS base metrics including Attack Vector (Network, Adjacent, Local, Physical) and Privileges Required, which describe preconditions for exploitation that are distinct from whether an asset is merely reachable over a network. (Source: NIST National Vulnerability Database (CVSS metrics))

When assessing Privileges Required, the distinction between PR: High and PR: Low is operationally significant and should be recorded explicitly. A vulnerability requiring PR: High demands administrative or otherwise elevated credentials that an unauthenticated external adversary is unlikely to hold without a separate privilege escalation step. A vulnerability requiring PR: Low, meaning any valid authenticated user, represents a substantially lower barrier that a wider population of adversaries could satisfy, for example through phishing or credential stuffing. Treating both as simply "requires authentication" collapses a meaningful difference in precondition difficulty.

CVSS 4.0 introduces an Attack Requirements (AT) metric that captures additional conditions beyond privileges, such as race conditions or specific target configurations, that must be present for exploitation to succeed. Where CVSS 4.0 scores are available, AT should be incorporated into the accessibility assessment rather than relying solely on the 3.x Privileges Required field.

Accessibility questions include: Does the vulnerable endpoint require authentication? Does it require a specific user role or privilege level (PR: Low versus PR: High)? Does it require a particular client state, session token, or multi-step interaction before the vulnerable code path is reachable? Is the vulnerable component loaded only under specific configuration states? Does CVSS 4.0's Attack Requirements flag additional preconditions?

Vulnerability chaining also belongs at this layer. A finding with PR: High does not automatically carry lower urgency if a realistic path exists to satisfy that precondition, for instance, a separate unauthenticated vulnerability on the same or adjacent system that could provide the credential or session required. Chains should be assessed holistically, not vulnerability by vulnerability in isolation.

Implementation step: Map the precondition requirements for each high-severity finding explicitly. A field in your tracking system that records unauthenticated, PR: Low authenticated, PR: High authenticated, or local-only changes prioritization immediately without requiring additional tooling. Findings in the local-only category that lack a realistic lateral-movement path from an external entry point carry substantially different urgency than unauthenticated network-reachable findings on the same system, but carry full urgency for an adversary who has already achieved internal access.

Layer 4: exploitability

Accessibility means an adversary could reach the vulnerable code path. Exploitability means a functional technique to trigger the vulnerability exists and is reliable enough to weaponize.

Exploitability is not a static property. A vulnerability without a public exploit today may have a functional exploit available next quarter. The inverse is also true: a vulnerability with a theoretical proof-of-concept may have no reliable weaponised version due to environmental constraints such as memory randomization, sandboxing, or dependency requirements that vary across deployments.

CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities with reliable evidence of exploitation in the wild and is explicitly a subset of all vulnerabilities, so a vulnerability's absence from the KEV catalog does not establish that it cannot be exploited. (Source: CISA Known Exploited Vulnerabilities Catalog) Absence from KEV can also reflect that no CVE or vendor patch notice exists for the vulnerability at all; unpatched or undisclosed weaknesses will not appear in KEV regardless of whether they are being actively targeted.

EPSS (Exploit Prediction Scoring System) belongs at this layer alongside KEV. Where KEV reflects observed exploitation, EPSS provides a probability estimate that a given CVE will be exploited in the near term, based on threat intelligence and exploit-availability signals. Using KEV and EPSS together rather than either alone produces a more calibrated exploitability signal. Neither replaces review of public exploit availability in sources such as Metasploit modules or open proof-of-concept repositories, nor does either capture threat intelligence on whether a specific actor class has integrated a technique into active tooling.

That asymmetry is critical for prioritization: KEV membership is strong positive evidence of exploitability in real-world conditions. Non-membership is not evidence of safety.

For assets that are discoverable, network-reachable, and accessible without authentication, a finding with no public exploit and no KEV or EPSS signal still warrants active monitoring rather than deferral. This tier, unauthenticated and network-reachable with no confirmed exploit, should be treated as elevated watch status: not at the top of the emergency remediation sprint, but not in the deferred backlog either. Research published by Fortinet's FortiGuard Labs and others has documented cases where vulnerabilities were weaponized within days of public disclosure, meaning the window between "no known exploit" and "actively exploited" can be very short for high-visibility vulnerabilities.

Test question: For each finding in your top-twenty remediation queue, can you state whether a functional exploit exists, where it was observed, and by what actor class? If the answer is "CVSS score is 9.8," you have a severity rating, not an exploitability assessment.

Layer 5: likely impact

An exploitable vulnerability on a reachable, accessible system still requires a consequence assessment before prioritization is complete. Impact is a function of the data the system stores or processes, the business functions it supports, the downstream systems it can reach post-compromise, and the recovery complexity if it is taken offline or corrupted.

Two systems can share identical vulnerabilities, identical reachability profiles, and identical exploitability ratings while carrying radically different impact potential: one because it stores regulated personal data and connects to core identity infrastructure, the other because it hosts a static internal wiki with no downstream trust relationships.

Implementation step: Maintain or reference a system-criticality register that records data classification, downstream trust relationships, blast radius estimates, and recovery time objectives. When a vulnerability finding is linked to a system in this register, impact scoring becomes a lookup rather than a judgment call made under time pressure.

In environments where a formal criticality register does not yet exist, using identity and access management context- specifically, which systems are trusted by your identity provider, which systems issue or validate tokens, and which systems have privileged service accounts, can provide a workable approximation of blast radius until a fuller register is built.

Why no known exploitation is not safety

A finding that clears Layers 1 through 4 but lacks a known exploit record is not low priority by default. Threat actor reconnaissance and weaponization timelines are not synchronized with vendor patch cycles or public disclosure dates. Research from FortiGuard Labs and similar threat intelligence teams has documented cases where vulnerabilities moved from disclosure to active weaponization within days for high-profile weaknesses, with the lag between exploitation and CISA's KEV evidence collection meaning absence from the catalog at disclosure time is not confirmation that exploitation is not occurring.

For assets that are discoverable, network-reachable, and accessible without authentication, treating "no known exploit" as a deferral rationale introduces meaningful risk, particularly if the asset supports authentication flows, handles credentials, or sits in a network segment with trust relationships to higher-value systems. The appropriate question is not "has this been exploited?" but "what would exploitation cost us, and how quickly could an adversary acquire the capability?"

One practical constraint on deferral decisions: compliance frameworks, including PCI DSS, impose defined remediation timeframes tied to vulnerability severity. Deferring a finding to a monitored backlog does not pause those clocks. Remediation timelines should be checked against applicable policy or regulatory requirements before a finding is formally deferred, and backlog reviews should be scheduled accordingly.

Using the layers to prioritize

The layered model produces a filtering funnel, not a score. Each layer reduces the population of findings that carry the combined properties - discoverable, reachable, accessible, exploitable, and high-impact - that define genuine operational urgency. The layers play a role in prioritization decisions rather than producing a composite numeric output, and their value lies in the structured reasoning they enforce, not a weighted sum.

Verification checklist — apply per finding, with attacker vantage point specified:

Findings that reach Layer 5 with affirmative answers at every layer form the true critical tier. Findings that stall at Layer 2 or 3 belong in a monitored backlog, not an emergency remediation sprint. Documenting the layer at which each finding stalls gives teams an audit trail for deferral decisions and a trigger condition: if a network rule changes and a stalled-at-Layer-2 finding becomes reachable, the finding automatically re-enters the active queue without requiring a full re-assessment. Before formally deferring any finding, verify that the planned timeline complies with applicable regulatory or policy remediation windows, including PCI DSS requirements.

The remediation backlog problem that opens this article does not resolve itself through more scanning or faster patching alone. It resolves when teams can draw a principled line between findings that carry genuine operational urgency and findings that do not, defend that line to auditors and leadership, and update it automatically when the underlying conditions change. The five layers described here provide that structure. Apply them consistently, document where each finding stalls, and the queue becomes manageable not because there is less work, but because the work is ordered correctly.

Exposure layering table

A "yes" at any single layer does not imply a "yes" at the next. The table should be read left to right as a narrowing filter, not as independent scoring dimensions. All assessments should note the attacker's vantage point - external unauthenticated, post-foothold internal, or other - to which the finding applies.

Sources