REQUIREMENT ID: VER-EVA-ELX · CATEGORY: VULNERABILITY EVALUATION AND REPORTING (VER)
The requirement
Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are likely exploitable vulnerabilities. (force: MUST)
What does this mean?
When a vulnerability is found in your environment, this requirement asks you to look beyond the raw finding and decide whether it could realistically be exploited in your specific cloud service offering.
A vulnerability scanner or threat feed may flag many issues, but not all of them are reachable or meaningful in your actual architecture. This step is about applying context. FedRAMP’s definition is precise, and its own preamble says defined terms must be followed exactly, so it’s worth quoting rather than paraphrasing:
“A vulnerability that is not fully mitigated AND is reachable by a likely threat actor; AND a likely threat actor with knowledge of the vulnerability would likely gain unauthorized access, cause harm, disrupt operations, or otherwise have an undesired adverse impact within the cloud service offering by exploiting the vulnerability.”
That clause about knowledge of the vulnerability is not incidental language. It is the seed of the Detectability factor described below.
In short, you are asked to separate theoretical findings from those that present real risk in your environment.
This article is also a LinkedIn newsletter. If you would like to receive it straight to your inbox, subscribe here.
Why does this matter?
Treating every detected vulnerability as equally urgent can bury teams in noise and delay attention to the issues that genuinely put systems and data at risk. On the other hand, dismissing a finding without proper evaluation could leave a real path open to an attacker.
If exploitability is never assessed with context, remediation priorities may be driven by scanner severity scores alone rather than by actual risk to the offering. FedRAMP is direct about the stakes of getting this wrong:
“Providers who regularly evaluate vulnerabilities as not likely exploitable without careful consideration are more likely to suffer from an adverse impact… If done recklessly or deliberately, such actions will have a negative impact on a provider’s FedRAMP Certification.”
That can lead to wasted effort on findings that are already mitigated or unreachable, while a weakness that scored lower but remains reachable goes unaddressed. In the other direction, it can lead to downgrades that do not hold up to scrutiny.
What could implementation look like?
This requirement does not mandate a specific tool or scoring method, so there is room for different valid approaches. But it doesn’t leave you without guidance: VER-EVA-EFA (SHOULD) names eight evaluation factors, and a workflow built around them is on firm, citable ground. The eight factors are Criticality, Reachability, Exploitability, Detectability, Prevalence, Privilege, Proximate Vulnerabilities, and Known Threats.
A repeatable evaluation step, run after vulnerability detection, would work through these factors for each finding, then record the resulting exploitability conclusion so it can feed remediation prioritization. The goal is a consistent, documented judgment rather than an ad hoc decision.
Example scenario
A cloud provider runs a weekly scan that flags a critical library vulnerability in a container image. Before treating it as an emergency, the security team evaluates it in context, and documents the evidence behind each claim rather than just the conclusion. The team confirms, through analysis of the call graph rather than assumption, that the vulnerable code path is never invoked in their deployment. They verify against current network topology diagrams that the container is not internet facing. And they attach the current firewall and segmentation rules showing that access is restricted by strict network policies.
Under VER-EVA-AIA (MUST), providers are required to assume exploitation can be automated unless they hold evidence proving otherwise, so a “not likely exploitable” conclusion needs that evidence on file, not just contextual reasoning. With it documented, the team concludes this finding is not currently a likely exploitable vulnerability and schedules remediation on a normal cadence.
In a separate case, a misconfiguration with a medium severity score exposes an admin interface to a broad network range. Reachability and Detectability both score high, so the team classifies it as likely exploitable and escalates it.
What evidence could demonstrate implementation?
Examples may include the following. Documented exploitability assessments tied to specific detected vulnerabilities, referencing the EFA factors considered. Tickets or records showing why a finding was classified as likely exploitable or not, including the evidence supporting any “not exploitable” downgrade under VER-EVA-AIA. A procedure describing how context of the offering is factored into evaluation. And prioritization records that reference the exploitability determination and resulting N rating.
Common pitfall
A frequent weak pattern is relying only on a scanner’s severity score as the exploitability decision. Severity ratings reflect general risk, not whether the issue is reachable and unmitigated in your particular offering. Skipping the context step means the “likely exploitable” judgment is never actually made, and skipping the evidence step means a “not exploitable” judgment can’t survive an assessor’s questions.
Question for your team
When a vulnerability is detected today, who decides whether it is likely exploitable in our offering, what context and evidence do they consider, and where is that decision recorded?
Key takeaway
Detected vulnerabilities should be judged in the context of your own cloud service offering, against FedRAMP’s own evaluation factors, so that effort focuses on weaknesses a plausible attacker could actually exploit, with the reasoning on record.
Related requirements
The source data lists no cross references for this rule (only 21 of 328 rules carry any; empty is the norm, not a signal that a rule stands alone). VER-EVA-ELX nonetheless sits in a family of related requirements worth reading together.
- VER-EVA-AIA (MUST): assume exploitation can be automated unless you hold evidence proving otherwise.
- VER-EVA-EIR (MUST): the internet reachable determination.
- VER-EVA-EPA (MUST): the N1 through N5 Potential Agency Impact rating.
- VER-EVA-EFA (SHOULD): the eight evaluation factors above.
- VER-EVA-EFP (SHOULD): false positive determination.
- VER-EVA-GRV (SHOULD): grouping vulnerabilities.
FedRAMP’s own common definitions schema ties the isLikelyExploitable field to both VER-EVA-ELX and VER-EVA-AIA. Together they function as one judgment, not two independent steps.
The requirement text above is quoted from FedRAMP Consolidated Rules for 2026, release 2026.09.13.02, for VER-EVA-ELX. The list of EFA factors and the citations of related requirements are drawn directly from that same release. The example scenario and evidence examples are illustrative and should be validated against official FedRAMP guidance and your own assessor’s expectations.
Making this judgment repeatable
NorthWatch delivers intelligent vulnerability tuning through scoring that is customizable and based on risk. By factoring in asset location, internet exposure, the presence of multiple associated CVEs, and other critical signals, NorthWatch gives your team a repeatable, recorded exploitability evaluation. It scores each finding against the factors FedRAMP names in VER-EVA-EFA, including reachability, prevalence, privilege, proximate vulnerabilities, and known threats. That determination then carries into your N rating and remediation priority. The judgment stays yours. NorthWatch makes it consistent, evidenced, and auditable, so the vulnerabilities most likely to be exploited rise to the top, and your team can focus on what matters most, faster.
Have a question about putting this requirement into practice?
38North Security can help you turn the requirements into an operating model that works in practice. Talk to us →
