VEX Document Guide for FDA Medical Device Compliance

An SBOM tells the FDA what is in your device. It says nothing about whether the vulnerabilities in those components matter. A component can appear in a public CVE feed with a critical CVSS score and still be irrelevant to your product because the vulnerable function is never called, the affected module was compiled out, or a compensating control blocks the attack path. VEX is the artifact that captures that judgment in a structured, machine-readable, auditable form.

What a VEX document actually is

VEX is a data format, not a single document type. It is a statement, tied to a specific product version and a specific vulnerability identifier (CVE or GHSA), asserting one of four status values:

• Not Affected - the vulnerability exists in the component but does not affect the product.
• Affected - the vulnerability affects the product and requires action.
• Fixed - the product has been updated to remove the vulnerability.
• Under Investigation - the manufacturer has not yet completed analysis.

Each statement can carry a justification, remediation guidance, and a timestamp. A VEX feed for a device with a 400-component SBOM might contain thousands of these statements over its lifetime, most of them "not affected" because the vast majority of vulnerabilities disclosed against common libraries never touch the code path a given product uses.

Why the FDA cares about VEX

The February 3, 2026 premarket cybersecurity guidance does not mandate a document literally called "VEX," but it does require, under Section 524B, a postmarket vulnerability management plan and evidence of a monitoring process that can identify, assess, and address vulnerabilities in a cyber device's software components. In practice, reviewers expect to see:

• A described process for matching SBOM components against vulnerability feeds.
• A triage methodology (commonly CVSS v3.1 or v4.0, adjusted for exploitability in context).
• Evidence that identified vulnerabilities were assessed, not just logged.

VEX is the artifact that produces that evidence. When a submission includes an SBOM with 200+ matched CVEs and no exploitability assessment, reviewers reasonably read that as an unmanaged risk queue. When the same SBOM is accompanied by VEX statements showing the CVEs were triaged, with a documented rationale for each "not affected" call, the same finding reads as a mature program instead of a red flag.

The four VEX statuses, and what evidence each one requires

"Not affected" is where teams get sloppy and where reviewers push back hardest. A one-line justification of "not exploitable" with no supporting analysis is functionally equivalent to not having done the analysis at all. For a component embedded in a device's core communication stack, a reviewer will expect to see why the vulnerable function is unreachable, not just an assertion that it is.

VEX formats: CSAF, CycloneDX, and SPDX

VEX statements can be delivered in three common ways:

• CSAF (Common Security Advisory Framework) is the OASIS standard purpose-built for security advisories, including VEX profiles. It is the format most security researchers and CERTs expect and is common for standalone VEX publication independent of a specific SBOM.
• CycloneDX supports VEX natively in the same schema used for the SBOM itself, or as a linked companion document. This is the most efficient path for teams already producing CycloneDX SBOMs, since the same identifiers (PURLs) used for component matching carry directly into the VEX statements. See our CycloneDX vs. SPDX comparison for how the two SBOM formats handle this differently.
• SPDX does not embed VEX in the same document; teams publishing SPDX SBOMs typically pair them with a separate CSAF VEX feed.

None of the three formats confers a compliance advantage with the FDA on its own. What matters is that the VEX statements are machine-readable, tied to specific product versions, and consistent with the SBOM they reference.

Building a VEX process that survives review

1. Automate the match, not the judgment. Tooling should automatically surface every CVE matched against your SBOM's component-version pairs. The exploitability call itself should involve a human who understands the product's architecture, at least for anything above low severity.
2. Write justifications, not conclusions. "Not affected - vulnerable function is in an unused code path (verified via static analysis, ticket SEC-4471)" survives scrutiny. "Not affected" alone does not.
3. Version-lock every statement. A VEX statement is only valid for the firmware version it was issued against. Devices with long field lives need a VEX history, not a single current snapshot.
4. Set an SLA for "under investigation." Define, in your postmarket vulnerability management procedure, how long a CVE can sit in that status before it must resolve to "affected" or "not affected," and tie that SLA to severity.
5. Feed VEX from the same pipeline as your SBOM. If your SBOM is generated per build in CI, the VEX matching should run against that same build artifact, not a stale inventory.
6. Connect VEX to your CVD intake. Vulnerabilities reported through your coordinated vulnerability disclosure process should enter the same triage pipeline and produce the same VEX statement types as vulnerabilities found through automated scanning.
7. Retain the full history. Auditors and reviewers may ask why a status changed between two dates; keep the prior statements, not just the current one.

Where VEX shows up in a submission

VEX rarely appears as a single named exhibit in an eSTAR submission. It shows up as:

• Supporting evidence for the postmarket vulnerability management plan narrative.
• The underlying data behind a vulnerability impact assessment table, if your submission includes one.
• Justification for why a device with a large third-party software footprint has a manageable residual risk profile despite a long CVE list in its SBOM.

Reviewers responding to a deficiency letter that cites an unaddressed CVE in your SBOM will often accept a VEX statement with a documented justification as the resolution, provided the justification is specific to your architecture and not a generic disclaimer.

How Blue Goat Cyber approaches VEX

We build VEX generation into the same pipeline as SBOM generation so exploitability triage happens continuously rather than as a pre-submission scramble. For premarket work, we produce an initial VEX baseline tied to the submission's SBOM and write the justification language reviewers expect to see for high-severity "not affected" calls. For devices already in the field, VEX becomes an ongoing deliverable inside postmarket SBOM and VEX monitoring, where new CVEs are matched, triaged, and logged against your CVD and postmarket vulnerability management commitments on a defined cadence.

Where this fits in the cluster

• SBOM for Medical Devices
• CycloneDX vs. SPDX for Medical Devices
• SBOM Vulnerability Management for Medical Devices
• Coordinated Vulnerability Disclosure for Medical Devices

Related from Blue Goat Cyber

• Postmarket SBOM & VEX Monitoring
• FDA Premarket Cybersecurity Services
• FDA Cybersecurity Deficiency Response

FAQ

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

An SBOM is an inventory: it lists the software components in a device and enough identifying data (versions, PURLs or CPEs) to match those components against vulnerability feeds. A VEX document is a judgment layered on top of that inventory: for a given vulnerability affecting a given component, it states whether the product is actually affected. You need both. An SBOM without VEX produces an unmanaged list of theoretical vulnerabilities; VEX without an SBOM has nothing to reference.

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

The FDA does not name "VEX" as a required exhibit, but the February 3, 2026 premarket guidance expects a documented process for assessing vulnerabilities identified in your SBOM as part of the postmarket vulnerability management plan under Section 524B. VEX is the practical, industry-standard way to produce that documentation, and reviewers who see a large SBOM with no exploitability triage commonly issue a deficiency asking for exactly this kind of evidence.

What are the approved formats for VEX documents in healthcare?

There is no FDA-mandated format. CSAF (the OASIS standard) is the most widely recognized standalone VEX format and is common for public advisories. CycloneDX carries VEX natively alongside the SBOM. SPDX SBOMs are typically paired with a separate CSAF VEX feed. Any of the three is acceptable provided the statements are machine-readable and version-matched to the product.

How do I prove a vulnerability is "not affected" in a medical device VEX statement?

Use a specific justification, not a general disclaimer. Acceptable evidence includes confirmation that the vulnerable component or function is not present in the shipped build, that the vulnerable code path is unreachable given the product's configuration, or that a compensating control blocks the exploit vector, backed by a code review, static analysis result, or architecture diagram. Reviewers weigh the specificity of the justification, especially for high and critical CVSS scores.

How often should VEX statements be updated?

At minimum, every time a new CVE is published against a component in your current SBOM, and every time you ship a build that changes your software composition. Devices with long field lives should treat VEX as a continuous postmarket activity tied to the same vulnerability monitoring cadence as your Section 524B postmarket plan, not a one-time premarket exercise.

Sources & primary references

• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (FDA, February 3, 2026 final guidance)
• Common Security Advisory Framework (CSAF) Version 2.0, OASIS
• CycloneDX VEX Specification
• The Minimum Elements For a Software Bill of Materials (NTIA)