SBOM vs VEX: What's the Difference?

An SBOM lists what's in your software. A VEX explains which of those things actually matter from a security standpoint. Both are required for a modern FDA submission - but they answer different questions, and confusing them is the fastest way to a cybersecurity deficiency.

If you've spent any time reading the FDA's February 2026 premarket cybersecurity guidance, you've seen "SBOM" and "VEX" used together so often that they blur. They are not the same document and they don't serve the same purpose. This guide breaks down the difference in plain English, with the level of detail an FDA reviewer actually uses when reading your package.

Why the SBOM vs VEX distinction matters

Section 524B(b)(3) of the FD&C Act requires a Software Bill of Materials for every cyber device, and the FDA's Cybersecurity in Medical Devices final guidance dated February 3, 2026 expects the SBOM to be paired with a Vulnerability Exploitability eXchange (VEX) document that states, per CVE, whether the device is actually affected. Without VEX, every transitive CVE in your SBOM looks unpatched to a reviewer or hospital procurement team, even when the vulnerable function is not reachable in your build. VEX adoption still lags SBOM adoption across the industry, which is why HSCC procurement guidance and AAMI TIR97:2019 both treat VEX-with-SBOM as the minimum viable disclosure. NTIA's The Minimum Elements for a Software Bill of Materials (July 2021), replaced by CISA's 2026 Minimum Elements published July 29, 2026, defines what an SBOM is; CISA's VEX Use Cases (April 2022) defines what VEX adds. They are complements, not substitutes.

TL;DR - at a glance

What an SBOM actually is

An SBOM is an inventory. For every piece of software shipping on or with your medical device - firmware libraries, OS packages, application dependencies, container images - the SBOM records:

• Component name and version (openssl 3.0.7)
• A globally unique identifier (PURL or CPE)
• License
• Supplier
• Cryptographic hash
• Dependency relationships (what depends on what)

That's it. An SBOM is a list. It does not say anything about whether any of those components have known vulnerabilities. That's the next step. For the four elements FDA reviewers actually verify on the SBOM itself, see our Medical Device SBOM: FDA requirements and submission guide.

The FDA expects the SBOM to be machine-readable - either SPDX or CycloneDX - so a reviewer can run automated tools against it. If you're choosing between the two, our CycloneDX vs SPDX comparison covers the tradeoffs.

What a VEX actually is

A VEX is an assessment. It takes the list of CVEs that fall out of running a vulnerability scanner against your SBOM and tells the reviewer, for each CVE:

• Are we affected by this CVE?
• Are we not affected? If so, why? (Vulnerable code not present? Not in the execute path? Mitigated by configuration?)
• Has it been fixed? (In which version, by what means?)
• Is it under investigation? (Who owns it, when's the close date?)

A VEX is the document that turns a noisy CVE list into a reviewer-readable narrative. Without one, the FDA sees 47 open CVEs in your dependencies and has no way to know which ones you've already addressed.

For the full mechanics - fields, formats, justification codes - read our VEX document guide for medical devices.

How they work together

If you want this done for your device, see our FDA-compliant SBOM services.

Think of it as a two-step pipeline the FDA reviewer mentally runs:

  SBOM ──▶ Vulnerability scan ──▶ CVE list ──▶ VEX ──▶ "Closed for review"

1. Your SBOM lists every component.
2. A vulnerability scanner (NVD, OSV, Snyk, etc.) maps each component to known CVEs.
3. The VEX answers, for each CVE, whether your device is actually affected.
4. The reviewer marks the cybersecurity section as adequately addressed.

If any step in that chain breaks, the reviewer writes a deficiency. The most common break point is step 3 - the VEX is missing, stale, or vague. We covered the failure modes in detail in 5 VEX mistakes that trigger FDA deficiencies.

Why you can't substitute one for the other

The single most common misconception we see: "We have an SBOM, so we don't need a VEX."

That is the same as saying "we have a parts list, so we don't need a safety analysis." The SBOM is raw material. The VEX is the reasoning the reviewer needs. A submission with only an SBOM forces the reviewer to do the VEX work themselves - and they won't. They'll issue a deficiency and hand it back.

The reverse mistake - submitting a VEX without an SBOM - never happens because the VEX references SBOM components by PURL or CPE. Without the SBOM as ground truth, the VEX has nothing to reference.

How the FDA actually reads your SBOM and VEX

See also: What Is MedTech? MedTech vs Medical Device vs Life Sciences, 8 FDA Cybersecurity Deficiencies, Ranked From Real Letters, and CVSS Scoring for Medical Devices: A Complete Walkthrough.

A reviewer's workflow is roughly this:

1. Open the SBOM. Confirm it's machine-readable, has the minimum SBOM elements defined in CISA's 2026 Minimum Elements for a Software Bill of Materials, published July 29, 2026 (supplier, component, version, unique identifier, dependency relationship, author, timestamp), and matches the device's stated software architecture.
2. Run a CVE scan against the SBOM's components.
3. Open the VEX. Cross-reference every CVE the scan produced against the VEX entries. Sort by CVSS, highest first.
4. Read every not_affected justification - especially on CVSS ≥ 7.0 entries.
5. Check for SBOM/VEX drift - component versions, generation dates, build hashes.

Anywhere this workflow stalls (missing entry, stale timestamp, vague justification, format mismatch), you get a finding. Anywhere it flows cleanly, the reviewer moves on.

Refresh cadence - the silent killer

Sponsors often treat SBOM and VEX as deliverables they generate once at submission. Both should regenerate continuously:

• SBOM: every build. Tie it into CI so it's never more than one commit out of date.
• VEX: monthly minimum during active FDA review, plus immediately when a new high-CVSS CVE drops against any component in your SBOM.

Why? Because the FDA reviewer reads the document on the day they pick up the file, not the day you submitted it. A VEX generated five months before review is almost certainly out of sync with the current CVE landscape, and reviewers know it.

The three SBOM formats and the three VEX formats

You'll see a lot of acronyms. Here's the practical map:

The FDA accepts all combinations. The deciding factor is operational fit with your build pipeline, not the FDA's preference.

Decision aid - which document fixes which problem?

If a reviewer's question maps to the wrong column in your response, that's a sign your team is still treating these two documents as one.

How Blue Goat approaches this

Blue Goat Cyber helps medical device manufacturers work through FDA cybersecurity requirements, distinguishing between essential documentation like SBOMs and VEX. Our team, comprised of CISSP and OSCP certified experts, including ex-military red team personnel, specializes in generating precise, compliant documentation. We focus on creating actionable VEX files that accurately reflect the exploitability of vulnerabilities within your device's specific operational context.

We don't just provide documents; we implement a structured methodology to analyze, assess, and articulate your device's security posture. This includes automating SBOM generation and linking it to a diligently prepared VEX to address potential cybersecurity deficiencies efficiently. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Learn more about our FDA premarket cybersecurity services.

To keep your SBOM and vulnerability records current after clearance, GoatWatch matches components to new CVEs and tracks VEX decisions.

FAQ

Do I need both an SBOM and a VEX for the FDA?

Effectively yes. Section 524B(b)(3) requires an SBOM. The February 2026 final premarket guidance requires you to assess every component for known vulnerabilities - and a VEX is the only practical way to deliver that assessment in machine-readable form. Submissions that include only an SBOM are routinely flagged with cybersecurity deficiencies.

Can VEX statements live inside my SBOM?

CycloneDX supports embedding VEX statements directly in the SBOM. That's allowed and convenient. But reviewers also want a standalone, schema-valid VEX file for independent parsing - so ship both. SPDX SBOMs cannot embed VEX statements; you pair them with a separate CSAF or OpenVEX file.

Is a vulnerability scan report the same as a VEX?

No. A scan report is the raw output - every CVE matched against your SBOM. A VEX is the curated assessment of those CVEs that tells the reviewer which ones matter and which ones don't, with justifications. The scan is input; the VEX is output.

What happens if a new CVE lands after I submit?

It depends on severity and timing. For a high-CVSS CVE landing during FDA review, the right move is to regenerate the VEX, add the new entry with affected or not_affected status and a justification, and send an unsolicited amendment to the reviewer. Doing nothing and hoping is how you end up with a hold letter - see our breakdown of deficiency vs RTA vs hold letters.

Does this apply to non-FDA submissions like EU MDR?

The same logic applies. EU MDR Annex I requires evidence of cybersecurity risk management, and a current SBOM + VEX is the cleanest way to provide it. The format expectations are similar - CycloneDX or SPDX for SBOM, any major VEX format for the assessment.

Need help building this?

If you're standing up SBOM and VEX from scratch - or your current pair just got flagged in an FDA deficiency letter - we can help. We've shipped clean SBOM + VEX pairs on 275+ devices and can triage your current package under NDA in 24 hours.

• Read the VEX document guide for the full format reference
• Read 5 VEX mistakes that trigger FDA deficiencies for the failure modes to avoid
• Choosing between SBOM formats? See CycloneDX vs SPDX for medical devices
• Already received an FDA cybersecurity letter? Start with which letter you got, then book a response call