Exposure management is quickly becoming a buzzword, a product category, and a strategic objective. As an evolution of vulnerability management, that makes sense. When an enterprise has thousands of vulnerabilities to address, we have to start prioritizing somewhere. Exposure is a reasonable place to begin.

Often, the first question is whether the affected system is facing the public internet. In a vulnerability review, the word “internal” can have a calming effect. A critical flaw has been found in an application. Someone asks whether it is exposed to the internet. It is not. The meeting moves on.

There are practical reasons for this. One reason we prioritize vulnerabilities so ruthlessly is that patching creates risk of its own. It can mean downtime, problems with dependencies, or an unforeseen change that leaves the IT team spending its weekend putting everything back together.

From a business perspective, there is also an understandable argument for leaving well enough alone. If the system is working and an attacker apparently cannot reach the vulnerability, why risk disrupting it? As time goes on without an incident, we may become more comfortable with that decision. We apply the same reasoning the next time and expect a similar result.

But the absence of an incident tells us only so much about the quality of the reasoning.

What is the Reachability Discount?

When we lower a vulnerability’s priority because it is internal, we are applying what we might call a “reachability discount.” This is no official scoring formula. It is simply a name for a familiar judgment: the obstacles between an attacker and a vulnerable system give us some room to breathe.

But that discount depends on how difficult those obstacles are to overcome. As the time, effort, or expertise needed to reach a vulnerability decreases, the justification for giving it a lower priority weakens. The vulnerability does not have to change. Its public exposure does not have to change. A change in the attacker’s ability to reach it can be enough.

This is where the pace of AI innovation deserves attention. If we have deferred remediation partly because discovering and navigating an attack path would require considerable skill and patience, increasingly capable AI could erode that protection. A path that once seemed impractical may become feasible. The discount should shrink accordingly.

“Can it be reached?” sounds straightforward. But reached by whom? Starting where? With which identity? Through which controls? And within what time? Those answers can change after we have made our initial assessment.

If we answer only from a network perspective, we may overlook routes through permissions, vendor connections, deployment workflows, or application behavior. An AI agent with internal tools adds another question: could material it encounters influence how it uses the access we have given it?

None of this means that AI makes every internal system reachable. Verified access controls still provide meaningful protection. But where our discount depends on an attacker struggling to discover or connect the steps, we should expect improvements in attacker capability to reduce the credit we give that difficulty.

When the Assumptions Behind the Discount Erode

Security teams already recognize much of this. Attack-path analysis is well established, and FIRST’s CVSS guidance encourages consideration of deployment context and compensating controls. What deserves renewed attention is whether the assumptions supporting our decisions continue to hold.

Consider an internal application with a serious vulnerability. A modest information leak elsewhere reveals details of its deployment process. An overprivileged service identity can access the deployment system, which in turn can reach the application. An attacker would still need to compromise that identity or obtain another foothold, but there is a possible path worth examining.

The information leak might occupy one backlog, the excessive permissions another, and the application vulnerability a third. Each has an owner. Each may have a reasonable priority. Who is responsible for looking at how they work together?

Fifty minor findings do not necessarily form a serious attack path. A handful of connected weaknesses might. Some steps may involve legitimate functionality doing exactly what it was designed to do. Restricting the service identity could therefore deserve more immediate attention than its individual finding would suggest.

AI gives us another reason to examine these connections. In a controlled evaluation, the UK AI Security Institute reported a model completing a 32-step corporate attack simulation in three of ten attempts. These were attack steps, not thirty-two vulnerabilities. The environment also lacked active defenders and defensive tooling, limitations the evaluators explicitly acknowledged.

That result does not tell us how much to reduce a particular reachability discount. It does give us a reason to examine the estimates behind it.

For organizations using quantitative risk analysis, the implication is straightforward. If we estimated a lower probability of compromise because reaching an internal application required an unusually capable attacker, what happens when that capability becomes more widely available? Holding other factors constant, a higher probability of compromise raises expected loss. The vulnerability and its business impact may be unchanged, yet its remediation priority may need to rise.

There is no universal percentage by which AI reduces the discount. Any adjustment should reflect evidence about the particular attack path and its controls. Defenders can also use AI to test those paths and strengthen protection. The task is to determine whether the obstacles still justify the credit we give them.

Those estimates deserve review as attacker capabilities, access paths, and controls change. Evidence of a compromised identity may require immediate reassessment. For a CISO, the practical test is whether we can explain what earned the discount and recognize when that explanation no longer holds.

What Other Security Assumptions Should We Revisit?

Reachability may be only the first discount worth revisiting. We also make security decisions on the assumption that an attack offers too little return to justify the effort, or that we will have enough time to detect and contain it. As AI changes the economics and pace of some attacks, those estimates may become outdated even though the systems themselves have not changed.

Security leaders should be able to identify these assumptions, explain how they affect risk estimates, and establish what evidence would trigger a review.

What matters most to you?

Is your biggest challenge seeing the vulnerabilities, understanding how they work together, or deciding what to address first? During an investigation, can you revise those priorities quickly enough to guide containment? And if you have adopted continuous threat exposure management (CTEM), is it helping you make those decisions?

Please share your perspective in the comments or reach out to me directly. I would welcome hearing what works, what is missing, and where you think this argument falls short.