VEX Document Guide for Medical Devices: Statuses and Mistakes

An SBOM inventories software components. VEX communicates vulnerability status. A vulnerability in an upstream library may not affect a particular product because the component or vulnerable code is absent, or exploitation is otherwise prevented. That conclusion needs product-specific analysis, not just a scanner result.

For the statutory SBOM obligation and the FDA's separate documentation recommendations, read FDA SBOM Requirements for Medical Devices. It covers applicability, component fields, support information, and submission evidence without treating optional VEX as a required deliverable.

Why this matters

Confusing optional VEX communication with regulatory obligations can distract from the underlying vulnerability assessment. Assess all known vulnerabilities, including those in CISA's Known Exploited Vulnerabilities (KEV) Catalog, and document risk and controls regardless of whether you publish VEX.

What a VEX document actually is

A VEX statement identifies a product, a vulnerability, an author, and an assessment status. Authors may be manufacturers or third parties. VEX does not require an SBOM, although consistent identifiers make the two easier to use together.

The four CISA statuses are not_affected, affected, fixed, and under_investigation. Format-specific representations may differ, so validate against the selected schema.

FDA vulnerability assessment recommendations and optional VEX

The February 3, 2026 premarket cybersecurity guidance never mentions VEX. It recommends a machine-readable SBOM, software support and end-of-support information, identification of all known vulnerabilities including KEV entries, and risk assessment and controls for those vulnerabilities.

Section 524B requires an SBOM for cyber devices, a postmarket monitoring and vulnerability management plan, and processes and procedures for cybersecurity, including updates and patches. It does not require VEX. VEX may supplement the assessment, but a status label alone is not a safety or residual-risk decision.

The four VEX statuses, and what evidence each one requires

The following distinguishes CISA's status-specific requirements from recommended supporting records. It is not the complete document schema.

CISA identifies five not_affected justifications:

1. component_not_present: the vulnerable component is not included in the product.
2. vulnerable_code_not_present: the component is included, but the vulnerable code is absent, for example, compiled out.
3. vulnerable_code_not_in_execute_path: the vulnerable code cannot execute in the way the product uses it.
4. vulnerable_code_cannot_be_controlled_by_adversary: an adversary cannot control the code in a way that exploits the vulnerability.
5. inline_mitigations_already_exist: built-in protections fully prevent exploitation through known attack vectors, cannot be subverted by an attacker, and cannot be configured or disabled by users. An ordinary compensating control does not automatically qualify.

VEX formats: CSAF 2.0, OpenVEX, CycloneDX, and SPDX

• CSAF 2.0 VEX profile: a structured security advisory format.
• OpenVEX: a focused format for communicating VEX statements.
• CycloneDX VEX: supports vulnerability analysis alongside an SBOM or in a separate document.
• SPDX 3.0 Security profile: supports vulnerability and assessment information. SPDX 2.x lacks native VEX support and can be paired with a separate VEX document.

Choose based on recipients and tooling, not a claimed FDA format preference. Neither embedded-plus-standalone delivery nor a particular SBOM/VEX format pairing is an FDA VEX requirement.

Building a VEX process that survives review

1. Match software inventory against vulnerability sources, while recognizing scanner coverage limitations.
2. Assess all known vulnerabilities, including KEV entries, rather than filtering solely by CVSS.
3. Identify the precise product versions covered by each statement.
4. Record the justification or impact statement for not_affected, and an action statement for affected.
5. Keep risk assessment and supporting evidence alongside status records.
6. Review statements when product composition, vulnerability knowledge, or mitigation effectiveness changes.
7. Retain statement history and connect it to your coordinated vulnerability disclosure process.

CISA's When to Issue VEX Information (November 2023) describes whether and when to publish as a business decision. A monthly review can be an internal practice, not a CISA or FDA VEX deadline.

Common VEX assessment mistakes

These are documentation review checks, not evidence that a VEX omission causes an FDA deficiency. VEX is optional. The underlying vulnerability assessment, risk analysis, and controls remain separate.

Treating VEX as a one-time deliverable

A status can become stale when product composition, vulnerability knowledge, or controls change. Retain statement history tied to the covered versions. Record assessment dates and responsibility for reassessment. CISA describes issuance timing as a business decision; there is no universal monthly VEX deadline.

Unsupported not_affected statements

Use the CISA justification or impact-statement rule described above, backed by product-specific analysis. Code compiled out belongs under vulnerable_code_not_present; code present but unable to execute through the product's use belongs under vulnerable_code_not_in_execute_path.

Retain actual build, binary-inspection, reachability, or test evidence as appropriate. A configurable firewall is not automatically an inline_mitigations_already_exist justification. Do not label a vulnerability not_affected merely because the manufacturer accepts its residual risk.

Mismatched product versions and identifiers

State the precise product versions covered. Where SBOM and VEX use different identifier schemes, maintain an explicit mapping. Use release evidence to check the relationship rather than assuming matching names prove matching components.

VEX can exist without an SBOM and can be authored by third parties. A valid component_not_present assessment can reference a component absent from that product. Do not require every VEX reference to appear in its SBOM.

Assessing only high-CVSS vulnerabilities

The FDA recommends identifying all known vulnerabilities, including KEV entries, and assessing risks and controls. A lower CVSS score is not an exemption. CVSS informs security assessment; it does not establish clinical harm or replace manufacturer-supplied safety evidence.

Keep investigation ownership and the assessment basis available. If communicating through VEX, choose the supported status and statements instead of treating a score threshold as a publication rule.

Choosing a format without validating it

There is no FDA-approved VEX format list or mandatory pairing with an SBOM format. Select a specification your recipients can use. Validate the complete document and test product identifiers and references. A JSON status fragment or printable worksheet is not a complete machine-readable VEX document.

VEX review checklist

• Covered product versions and statement author are identified.
• not_affected has a justification or, if absent, an impact statement.
• affected has an action statement.
• fixed identifies versions containing the fix, not vulnerable versions awaiting an upgrade.
• All known vulnerabilities are assessed without a CVSS-only cutoff.
• SBOM and VEX identifiers are mapped where the documents are used together.
• The chosen specification passes validation and references are checked.
• Supporting evidence, statement history, and reassessment responsibility are retained.

For support-date changes rather than VEX structure, read Postmarket SBOM Maintenance for Medical Devices.

Where VEX shows up in a submission

If used, VEX can supplement vulnerability assessment tables and postmarket monitoring documentation. Explain its scope and its relationship to product versions and other evidence. Do not assume a VEX statement will resolve a deficiency; the adequacy of the underlying assessment and controls matters.

How Blue Goat approaches VEX

We help connect component inventories, vulnerability analysis, and documented status decisions. When VEX is used, we focus on product-version traceability and supporting evidence within postmarket SBOM and VEX monitoring. VEX is not presented as a required FDA deliverable.

Where this fits in the cluster

• VEX to FDA guidance crosswalk: four statuses and supporting evidence
• SBOM for Medical Devices
• CycloneDX vs. SPDX for Medical Devices
• SBOM Vulnerability Management for Medical Devices
• SBOM vs VEX: What's the difference?

FAQ

What is the difference between an SBOM and a VEX document?

An SBOM inventories components. VEX communicates a vulnerability assessment status for identified products. VEX can exist without an SBOM and cannot replace a statutory SBOM obligation.

Does the FDA require VEX documents for 510(k) submissions?

No. The February 3, 2026 guidance does not mention VEX. It recommends identifying all known vulnerabilities and documenting risk assessment and controls.

What are the approved formats for VEX documents in healthcare?

There is no FDA-mandated VEX format. Options include CSAF 2.0 VEX, OpenVEX, CycloneDX VEX, and SPDX 3.0's Security profile. SPDX 2.x lacks native VEX support.

How do I support a not_affected statement?

CISA says a justification SHOULD be supplied; otherwise an impact statement MUST explain why the product is not affected. Supporting analysis is recommended. Do not treat a user-configurable network control as an inline mitigation that fully prevents exploitation.

How often should VEX statements be updated?

Publication timing is a business decision. Reassess when relevant product versions, vulnerability knowledge, or controls change, and align communication with your vulnerability management process.

Is VEX the same as a vulnerability scan report?

No. A scan identifies potential matches. VEX communicates an author's product-specific status assessment. Neither replaces the supporting risk assessment.

Can an upstream fix make an older deployed version fixed?

No. fixed applies to identified versions containing the fix. A vulnerable deployed version remains affected while awaiting its upgrade unless a separate, evidence-backed not_affected assessment genuinely applies. Provide an action statement for an affected version.

Sources & primary references

• FDA premarket cybersecurity guidance, February 3, 2026
• CISA Minimum Requirements for VEX, April 2023
• CISA When to Issue VEX Information, November 2023
• CISA VEX status justifications in the Minimum Requirements for VEX
• CSAF 2.0
• CycloneDX VEX
• OpenVEX
• SPDX specifications

Free tools for this

Use the VEX assessment worksheet to record a documented status assessment. It produces a printable worksheet, not a machine-readable VEX document.

Need help with vulnerability assessment?

Explore FDA premarket cybersecurity services or deficiency response support.

About the author

Christian Espinosa, Founder, Blue Goat Cyber. Christian leads a team focused on medical device cybersecurity. Read more about Christian.