The Cyber Resilience Act never uses the word VEX. A machine-readable exploitability statement is still the practical way to meet Annex I Part II(6), because the Regulation makes exploitability the legal test for placing a product on the market.
A modern product carries hundreds of components a scanner will flag. The gap between what the law says and what the law needs is where most manufacturers get stuck. The obligation is written in outcome terms. The tooling to meet it is written in three competing formats, none of which the Regulation mentions.
Key takeaways
- CISA published Minimum Requirements for Vulnerability Exploitability eXchange on 19 April 2023, fixing four status values and five machine-readable justification labels for the not_affected case.
- CRA Annex I Part I(2)(a) bars placing a product on the market with known exploitable vulnerabilities, which makes exploitability the test that decides compliance.
- ENISA surveyed 334 organisations at the end of 2025 and found that 76 percent rate receiving vulnerability status or exploitability claims from suppliers as critical or important.
- The same ENISA report measures SBOM format adoption at 44 percent CycloneDX and 29 percent SPDX, and never once names VEX. Demand for the output is measured. Supply of the format is not.
- Three implementations compete. CSAF 2.0 and OpenVEX both use CISA's four statuses and five justifications. CycloneDX uses six states and nine justifications of its own.
What is a VEX document?
A VEX document is a machine-readable statement from a manufacturer saying whether a specific vulnerability is exploitable in a specific product version. It answers one question per statement and it is designed to be consumed by software rather than read by a person.
The problem it solves is arithmetic. An SBOM lists what is inside the product, and an SBOM is the foundation the rest of this rests on. A scanner matches those components against a vulnerability database and returns every CVE ever recorded against any of them. For a firmware image with 400 open-source components, that list runs to hundreds of entries, and the large majority describe code paths the product never reaches, build flags that exclude the vulnerable function, or attack surfaces the architecture does not expose.
Without VEX, every one of those entries becomes a support ticket, a procurement question, or a customer demanding a patch for a vulnerability that cannot be triggered. VEX lets the manufacturer answer once, in a form that a downstream tool can process automatically.
Does the CRA require VEX?
No. Regulation (EU) 2024/2847 contains no reference to VEX, to CSAF, or to any named advisory format. It states obligations in outcome terms and leaves the mechanism open.
Four of those obligations point straight at what VEX does.
| CRA provision | What it says | What VEX contributes |
|---|---|---|
| Annex I Part I(2)(a) | Products shall be made available on the market without known exploitable vulnerabilities | Records the exploitability determination that decides whether a known CVE blocks placing on the market |
| Annex I Part II(1) | Identify and document vulnerabilities and components, including by drawing up an SBOM covering at the very least top-level dependencies | Attaches a status to each component-vulnerability pair the SBOM exposes |
| Annex I Part II(2) | Address and remediate vulnerabilities without delay, in relation to the risks posed | Documents the risk determination behind a decision not to patch |
| Annex I Part II(6) | Take measures to facilitate the sharing of information about potential vulnerabilities in the product and in third-party components contained in it | Provides the standardised carrier for that information |
Part I(2)(a) is the sharpest of the four, and it sits next to a distinction we have covered separately, exploitable against actively exploited. The wording is "known exploitable vulnerabilities". A component with a published CVE that the product cannot execute is a known vulnerability. Whether it is a known exploitable vulnerability is a determination the manufacturer has to make, document, and stand behind. VEX is the notation for writing that determination down.
Part II(6) is the one that most obviously needs a machine-readable format. A manufacturer with 50 products and a few hundred components each cannot facilitate information sharing through PDFs and email.
What are the four VEX statuses?
CISA's Minimum Requirements for Vulnerability Exploitability eXchange (VEX), published 19 April 2023, defines exactly four.
| Status | Meaning | Extra requirement |
|---|---|---|
not_affected | No remediation or mitigation is required | Must carry a justification label or a free-text impact statement |
affected | Actions are recommended to remediate or address the vulnerability | Must carry an action statement |
fixed | These product versions contain a fix | None |
under_investigation | Whether these versions are affected is not yet known | Expected to change once the investigation concludes |
The not_affected case carries the weight, and it is the one manufacturers get wrong. CISA specifies that a statement SHOULD provide a machine-readable justification, and that where no justification is given an impact statement MUST be provided instead. A bare not_affected with neither is not a valid VEX statement.
Five justification labels are allowed.
| Justification | When it applies |
|---|---|
component_not_present | The vulnerable subcomponent is not included in the product at all |
vulnerable_code_not_present | The component ships but the vulnerable code is excluded, typically by build configuration |
vulnerable_code_not_in_execute_path | The vulnerable code is present but no control flow reaches it |
vulnerable_code_cannot_be_controlled_by_adversary | The code runs but an attacker cannot supply the input that triggers the flaw |
inline_mitigations_already_exist | Built-in protections prevent exploitation and cannot be disabled or subverted |
CISA marks the last two as difficult to prove conclusively. That warning is worth taking seriously in a regulatory setting, because a justification a market surveillance authority rejects converts a documented decision into an undocumented one.
Which VEX format should you pick?
Three implementations exist. They agree on the concept and disagree on the vocabulary.
| CSAF 2.0 VEX profile | CycloneDX VEX | OpenVEX | |
|---|---|---|---|
| Custodian | OASIS | OWASP | OpenSSF |
| Current version | CSAF 2.0 | CycloneDX 1.6 | v0.2.0 |
| Status vocabulary | 8 product_status branches, 5 flag labels matching CISA | 6 analysis states, 9 justifications of its own | CISA's 4 statuses and 5 justifications exactly |
| Carries a full advisory | Yes | No, it references the SBOM | No, statements only |
| Best fit | Manufacturers who also publish security advisories | Teams whose SBOM is already CycloneDX | Lightweight automated pipelines |
CycloneDX is the one to watch for surprises. Its analysis.state values are resolved, resolved_with_pedigree, exploitable, in_triage, false_positive and not_affected, and its nine justifications include requires_configuration, protected_at_runtime and protected_by_mitigating_control. Those are useful distinctions and they do not map cleanly onto CISA's five. A consumer translating between the two loses information.
For an EU manufacturer under the CRA, CSAF 2.0 with the csaf_vex profile is usually the right default, for one structural reason. Annex I Part II(4) requires public disclosure of fixed vulnerabilities including the affected product, the impact, the severity, and remediation information. A CSAF document carries all of that alongside the VEX statement. One artifact discharges the disclosure duty and the exploitability claim together. CycloneDX VEX and OpenVEX both need a separate advisory next to them. For the advisory format itself, see CSAF 2.0 advisories explained.
What does the evidence say about demand?
ENISA published SBOM Adoption State of Play – 2026 in June 2026. The survey ran at the end of 2025 and drew 334 responses, of which roughly 65 percent came from EU-based organisations and more than 80 percent from companies directly impacted by the CRA.
Three findings matter here.
Receiving vulnerability status or exploitability claims from suppliers was rated critical by 39 percent of respondents and important by another 37 percent. That is 76 percent of a CRA-exposed sample asking for exactly what VEX carries.
Their preferred delivery methods were automatic (44 percent) or through a standardised API (40 percent). Both answers rule out a human reading a PDF.
Vulnerability matching, described in the report as CPE and PURL alignment and false positives, was the second most common barrier to SBOM adoption, with almost two thirds of organisations affected extremely or quite a lot. False positives are the specific problem VEX was designed to remove.
Set against that, the report measures SBOM formats at 44 percent CycloneDX and 29 percent SPDX, with 11 percent using no standard format and 17 percent still on a proprietary one. It does not name VEX anywhere. The demand side of this market has been measured. The supply side has not caught up.
Four ways VEX goes wrong
Publishing not_affected with no justification. The most common defect, and the one that makes a document formally invalid. Downstream tooling reads an unjustified claim as an assertion with no basis and many consumers discard it.
Letting VEX and SBOM drift apart. An SBOM is a snapshot of one build. A VEX statement is a claim about a product version that may need revising the day after a researcher publishes a new attack path. Tying VEX regeneration to the build pipeline alone leaves stale statements in the field.
Treating VEX as a substitute for triage. VEX records a decision. Someone still has to make it. A pipeline that emits not_affected by default for anything a reachability tool cannot trace is manufacturing evidence rather than producing it, and under CRA Annex I Part I(2)(a) that evidence is what a market surveillance authority will read.
Publishing without a discovery path. A VEX document nobody can find has done nothing. CSAF solves this with provider-metadata.json and the .well-known/csaf/ directory structure, which lets a consumer's tooling locate a manufacturer's whole advisory feed from the domain name alone.
How CVD Portal handles VEX
Every advisory published through a CVD Portal tenant is generated as a CSAF 2.0 document with document.category set to csaf_vex, distributed as TLP:WHITE, and served from the tenant's own portal host so that the publisher namespace matches the provider-metadata.json that CSAF section 7.1.7 requires. The advisory feed sits under .well-known/csaf/white/ in the structure a CSAF-aware consumer expects to find.
The supply chain module carries a per-component status for exchanged component data, using the four CISA statuses plus an explicit unknown, with a free-text note against each. Component notes are free text today rather than the five machine-readable justification labels.
You can check any CSAF or VEX document, from this platform or another, against the specification with the free CSAF validator.
Sources
- Regulation (EU) 2024/2847, the Cyber Resilience Act. Annex I Part I(2)(a), Annex I Part II(1), (2), (4) and (6).
- CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX), 19 April 2023.
- OASIS, Common Security Advisory Framework Version 2.0, profile 5 (VEX).
- OWASP, CycloneDX 1.6 JSON schema,
vulnerabilities.analysis. - OpenSSF, OpenVEX specification v0.2.0.
- ENISA, SBOM Adoption State of Play – 2026, June 2026. DOI 10.2824/0741767, CC BY 4.0.
Frequently asked questions
Does the Cyber Resilience Act require VEX documents?
No. The Cyber Resilience Act never names VEX. Annex I Part II(6) requires manufacturers to facilitate the sharing of information about potential vulnerabilities in their product and in third-party components it contains, and VEX is the only standardised machine-readable way to carry that information at portfolio scale. The obligation is real. The format choice is yours.
What are the four VEX status values?
Not affected, affected, fixed, and under investigation. CISA fixed these four in Minimum Requirements for Vulnerability Exploitability eXchange, published on 19 April 2023. A not_affected status must carry either one of five machine-readable justification labels or a free-text impact statement explaining why the product cannot be exploited.
Which VEX format should an EU manufacturer use?
CSAF 2.0 with the csaf_vex profile, in most cases. CSAF carries a full advisory and a VEX statement in one document, which means one artifact serves both the Annex I Part II(4) disclosure duty and the exploitability claim. CycloneDX VEX suits teams whose SBOM is already CycloneDX. OpenVEX suits lightweight automated pipelines.
Can a VEX not_affected statement replace patching?
Yes, where the justification holds. CRA Annex I Part II(2) requires manufacturers to address and remediate vulnerabilities in relation to the risks posed by the product. A documented and defensible not_affected statement records that the risk posed is nil, which is a valid basis for not shipping a patch. The justification has to survive a market surveillance authority reading it.