Attack Feasibility

What attack feasibility measures

Attack feasibility is not the same as theoretical weakness. It asks whether an attacker can actually succeed in the real environment, given the target’s exposure, the controls in place, the skill or tooling required, and the effort needed to get from access to impact. That makes it a practical measure of exploitable opportunity, not just vulnerability presence.

Because feasibility is grounded in real-world conditions, it often changes faster than static documentation. A system can remain technically vulnerable while becoming less feasible to attack after segmentation, hardening, stronger authentication, or reduced internet exposure. Conversely, weak exposure management or missed compensating controls can make a previously low-probability issue practical.

How feasibility is assessed

Feasibility is usually judged by combining several questions: how much attacker capability is needed, what access or proximity is required, whether the target is reachable, and how much time or coordination is needed to complete the attack. In practice, analysts also look at whether the path is noisy or stealthy, whether preconditions are rare, and whether the attack depends on a chain of steps that may fail before impact.

This assessment is inherently contextual. The same technique can be highly feasible against one environment and unrealistic against another because of differences in identity controls, segmentation, patching, monitoring, or asset exposure. That is why feasibility is often more useful than a generic severity label when teams need to prioritise remediation.

Why attack feasibility matters for prioritisation

Feasibility helps separate “possible in principle” from “likely in practice.” That distinction is essential for triage, because security teams have limited time and should focus first on attack paths that combine reachable exposure, low attacker effort, and meaningful downstream impact. A low-feasibility issue may still deserve attention, but it usually competes differently for resources than an issue that is easy to exploit immediately.

It also helps connect vulnerability management to defensive reality. If a flaw is only exploitable with unusual access, specialised tooling, or a long multi-stage chain, the near-term priority may be different from a flaw that is exposed directly to the internet or can be abused with common techniques. Feasibility therefore sits between abstract weakness and operational risk.

For a structured treatment of the engineering factors that feed this kind of judgement, the ISO/SAE 21434 Automotive Cybersecurity Engineering Guide is a useful reference point because it ties attack feasibility rating to threat analysis and risk assessment work.

Controls and evidence that change feasibility

Controls change feasibility when they alter the attacker’s cost, access, or success rate. Strong authentication, tighter privilege, network segmentation, reduced attack surface, secure defaults, and better logging can all make exploitation materially harder. Exposure reviews, asset inventory, and vendor advisories are equally important because they tell you whether a weakness is actually reachable in your environment.

Feasibility should also be revisited after changes to the environment. New integrations, new externally exposed services, weak administrative paths, or a control that is present but poorly enforced can all raise feasibility without changing the underlying flaw itself. The practical question is always: what would have to be true for an attacker to succeed here, and is that still true today?

Risk and Threat Considerations

Attack feasibility matters because attackers do not need every weakness, only the ones they can actually use. A low-effort, reachable path is more likely to be exploited, repeated, and chained into broader compromise than a weakness that requires rare access or excessive skill. Feasibility also changes as defenders alter exposure, so an issue can move from theoretical to urgent when controls weaken or assets become more visible.

Failure mechanism: The attacker benefits when access is reachable, defensive barriers are sparse, and the exploit path requires little skill, time, or coordination. That combination reduces friction and makes exploitation practical rather than merely possible.

Impact: Once a feasible path exists, compromise can lead to credential theft, persistence, lateral movement, service disruption, or broader trust abuse, depending on what the exposed target can reach.

Practitioner Guidance

What to watch for: Treat feasibility as a living judgement, not a one-time label. Reassess when exposure changes, when a control is bypassed or misconfigured, or when advisory information shows that an attack path is easier than originally assumed.

Governance implication: Teams should record why a path is considered feasible or infeasible, because that rationale is what makes prioritisation defensible. The most useful decisions are the ones that connect observed exposure, control strength, and expected attacker effort to a clear remediation order.

Related resources from NHI Mgmt Group

• Attack Path Feasibility
• Targeted Attack Feasibility
• Why does Agentic AI make NHI attack surface expand so significantly?
• What is the difference between attack surface management and NHI governance?