VEX Document Guide for FDA Medical Device Compliance

Direct Answer

What is a VEX document for medical devices?

VEX (Vulnerability Exploitability eXchange) is an optional structured way to communicate a statement author's assessment of whether a vulnerability affects a specific product version. The FDA's February 3, 2026 premarket cybersecurity guidance does not mention VEX. It recommends vulnerability identification, risk assessment, and controls, which VEX can help communicate but cannot replace.

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.

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.

Why the FDA cares about 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.

Status	Meaning	CISA minimum requirement	Recommended supporting records
`not_affected`	The vulnerability does not affect the identified product	A justification SHOULD be given; if none is given, an impact statement MUST be provided	Build records, reachability analysis, or tests explaining the conclusion
`affected`	The vulnerability affects the identified product	An action statement MUST be provided	Risk assessment, remediation owner, timeline, and interim controls
`fixed`	The identified product versions contain the fix	The status describes versions containing a fix; no additional status-specific statement is mandated	Fixed-version identification and verification results
`under_investigation`	A final assessment has not been made	No additional status-specific statement is mandated	Investigation owner and target reassessment date

CISA identifies five not_affected justifications:

component_not_present: the vulnerable component is not included in the product.
vulnerable_code_not_present: the component is included, but the vulnerable code is absent, for example, compiled out.
vulnerable_code_not_in_execute_path: the vulnerable code cannot execute in the way the product uses it.
vulnerable_code_cannot_be_controlled_by_adversary: an adversary cannot control the code in a way that exploits the vulnerability.
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

Match software inventory against vulnerability sources, while recognizing scanner coverage limitations.
Assess all known vulnerabilities, including KEV entries, rather than filtering solely by CVSS.
Identify the precise product versions covered by each statement.
Record the justification or impact statement for not_affected, and an action statement for affected.
Keep risk assessment and supporting evidence alongside status records.
Review statements when product composition, vulnerability knowledge, or mitigation effectiveness changes.
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.

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 Cyber 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

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.

Sources & primary references

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.