5 VEX Mistakes That Trigger FDA Findings

Part of our FDA cybersecurity deficiency, RTA, and hold-letter response series. For the full overview, start with FDA Deficiency Letter vs RTA vs Hold.

A VEX document is supposed to make your SBOM easier for FDA reviewers to read. Done wrong, it does the opposite - it gives the reviewer a stack of unanswered CVEs and a reason to issue a deficiency letter. Here are the five mistakes we see most often, and exactly how to avoid each one.

If you're preparing a 510(k), De Novo, or PMA submission under the February 2026 final FDA premarket cybersecurity guidance, your SBOM will travel with a Vulnerability Exploitability eXchange (VEX) document. The VEX is what tells the reviewer "we know about CVE X - here's why it doesn't affect this device." Get it right and the reviewer moves on. Get it wrong and you'll be answering questions for the next 180 days.

Across 275+ devices, the same five VEX mistakes account for the majority of cybersecurity deficiency findings tied to vulnerability management. Fix these before you submit.

New to VEX? Read the VEX document guide for medical devices first, then come back here for the failure modes.

For data on how often each cybersecurity deficiency actually appears, see 8 FDA cybersecurity deficiencies, ranked from real letters.

Why this matters

VEX (Vulnerability Exploitability eXchange) documents are critical for demonstrating software transparency and safety to the FDA. Mishandling your VEX can lead to significant delays in product approval, as the FDA requires thorough cybersecurity documentation in premarket submissions. Without an accurate and well-maintained VEX, reviewers may interpret unaddressed vulnerabilities as potential risks to device safety and effectiveness. This often results in a deficiency letter, requiring device manufacturers to expend additional time and resources to revise and resubmit documentation. The FDA's 'Cybersecurity in Medical Devices' Final Guidance, dated February 3, 2026, explicitly outlines expectations for SBOMs and associated vulnerability information, including the need to explain the exploitability status of identified CVEs. Failing to meet these requirements can stall market access and impact revenue projections. Adhering to standards like IEC 81001-5-1, ISO/IEC 27034, and ANSI/AAMI SW96 is essential for developing VEX documents that satisfy regulatory scrutiny and ensure patient safety. A flawed VEX not only delays approval but also reflects poorly on a manufacturer’s commitment to cybersecurity hygiene, potentially inviting greater scrutiny on future submissions.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA, Postmarket Management of Cybersecurity in Medical Devices (2016); CISA Known Exploited Vulnerabilities Catalog; FDA eSTAR Program.

Mistake 1: Treating VEX as a one-time deliverable

The single biggest mistake is generating a VEX once - at submission - and never updating it. A VEX is a living artifact. Between the day you generate it and the day a reviewer reads it, new CVEs in your dependencies will land. If your SBOM lists openssl 3.0.7 and three CVEs were published against that version after you submitted, the reviewer sees three unanswered vulnerabilities. That's a deficiency every time.

How to fix it:

• Regenerate the VEX on the same cadence as your SBOM - minimum monthly during active review.
• Include a "VEX generation date" and "SBOM correlation hash" in the cover letter so the reviewer can confirm they're paired.
• Build VEX regeneration into your secure development framework (SPDF) as a documented process, not an ad-hoc task.

The fix is operational, not technical. Teams that automate VEX generation in CI never see this finding.

Mistake 2: "Not affected" with no justification

Every VEX statement carries a status: not_affected, affected, fixed, or under_investigation. The trap is not_affected - it requires a justification field, and reviewers read every one. Common bad justifications:

• "Not exploitable in our use case." (why?)
• "Code is not executed in production." (prove it)
• "Mitigated by network controls." (which controls? where documented?)

Vague justifications don't close the loop. The CISA-defined justification codes (component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, inline_mitigations_already_exist) exist for a reason - use them by name and include an impact_statement field that points to the specific design control, configuration, or test result that backs the claim.

Good example:

{
  "status": "not_affected",
  "justification": "vulnerable_code_not_in_execute_path",
  "impact_statement": "The vulnerable parser in libxml2 is only invoked by the optional config-import feature, which is disabled at compile time in the production firmware build (see build flag CONFIG_NO_IMPORT in /firmware/build.config, line 142). Verified by static analysis report DEV-SAST-2026-04-12, finding ID SAST-114."
}

That kind of specificity is what closes a deficiency. "Not exploitable" alone does not.

Mistake 3: Mismatch between SBOM and VEX components

A VEX statement references components by PURL (pkg:npm/lodash@4.17.21) or CPE. Reviewers cross-check every reference against your SBOM. Common mismatches that trigger findings:

• VEX references pkg:npm/lodash@4.17.21 but your SBOM lists pkg:npm/lodash@4.17.20.
• VEX uses CPE format; your SBOM uses PURL.
• VEX names a component the SBOM doesn't include at all (often a transitive dependency that was filtered out).
• Version strings don't match because one document was generated against the dev build and the other against the release build.

Reviewers don't reconcile these for you. They flag the mismatch and ask which document is authoritative.

How to fix it:

• Generate the SBOM and VEX from the same build artifact in the same CI run.
• Standardize on PURL for both documents (PURL is the FDA-friendly default for software; CPE is fine for OS and firmware components).
• Validate the SBOM ↔ VEX pairing programmatically before submission - every component referenced in the VEX must exist in the SBOM at the same version.

Mistake 4: Missing VEX for high-CVSS CVEs

See also: 8 FDA Cybersecurity Deficiencies, Ranked From Real Letters, FDA IDE Cybersecurity Requirements: 2026, and PMA Supplement Cybersecurity Changes.

Reviewers don't read every VEX entry. They sort the CVEs by CVSS score and read the high ones first. If a CVE in your SBOM has a CVSS of 9.8 and your VEX is silent on it, that's the first thing the reviewer sees - and the first thing they'll ask about.

The fix is procedural: never submit a package where any CVE with a CVSS ≥ 7.0 lacks a VEX entry. Status can be under_investigation if you genuinely don't know yet, but silence is not an option.

Pre-submission checklist:

1. Pull every CVE from the SBOM-driven vulnerability scan.
2. Filter to CVSS ≥ 7.0.
3. Confirm a VEX statement exists for every one.
4. For any under_investigation, document the investigation owner and target close date in the cover letter.

A single missing high-CVSS VEX entry is enough to trigger a deficiency. This is a 30-minute check that prevents weeks of back-and-forth.

Mistake 5: Wrong VEX format for the FDA pathway

The FDA accepts VEX in three formats: CSAF 2.0 VEX, CycloneDX VEX, and OpenVEX. They are not interchangeable for every reviewer. Common errors:

• Submitting a CycloneDX VEX with a SPDX SBOM and no mapping document.
• Embedding VEX statements inline in a CycloneDX SBOM and not providing a standalone VEX file. Reviewers want both - the embedded statements and a separate, machine-readable VEX document the reviewer can parse independently.
• Using OpenVEX without including the JSON Schema reference, so the reviewer's tooling can't validate it.

The rule of thumb: match your VEX format to your SBOM format (CycloneDX VEX with CycloneDX SBOM, CSAF VEX with SPDX SBOM), and always ship a standalone, schema-validated VEX file alongside any embedded statements.

If you're choosing between SBOM formats, our CycloneDX vs SPDX guide for medical devices covers the tradeoffs the FDA cares about.

A pre-submission VEX checklist

Before you ship a submission package, walk through this list:

• VEX generation date is within 30 days of submission
• VEX and SBOM share the same build artifact and hash
• Every not_affected entry uses a CISA-defined justification code
• Every not_affected entry has an impact_statement with a specific evidence reference
• Every CVE with CVSS ≥ 7.0 has an explicit VEX entry
• Component references (PURL/CPE) match exactly between SBOM and VEX
• VEX file is schema-valid and standalone (not only embedded)
• Cover letter explains the SBOM ↔ VEX correlation and the regeneration cadence

Teams that complete this checklist before submission don't get VEX-driven deficiencies. Teams that skip it usually find out which step they missed when the FDA letter arrives.

How Blue Goat approaches this

Our approach to VEX documentation focuses on accuracy and regulatory alignment, avoiding common pitfalls that lead to FDA deficiencies. We assist medical device manufacturers in generating, validating, and maintaining VEX documents that meet the specific requirements of the FDA's “Cybersecurity in Medical Devices” Final Guidance dated February 3, 2026. Our team, comprised of certified experts (CISSP, OSCP, ex-military red team), ensures each VEX clearly articulates the exploitability status of vulnerabilities for your device.

We specialize in careful review and alignment of SBOMs and VEX documents, ensuring consistency and proper justification for all vulnerability statuses. Our process identifies and rectifies common errors, such as outdated VEX information or insufficient 'not affected' justifications, before submission. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Learn more about our validation processes for submissions: FDA premarket cybersecurity services.

If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity submission support.

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

Related reading: Embedded Cybersecurity Challenges in Medical Devices, GMP Cybersecurity Compliance: A 2026 Medical Device Compliance Guide.

FAQ

Does the FDA require a VEX document?

The FDA's February 2026 final premarket cybersecurity guidance expects a vulnerability assessment that addresses every component in the SBOM. A VEX document is the most practical way to deliver that assessment in a machine-readable, reviewer-friendly format. While the guidance does not name VEX by name as mandatory, every modern submission ships one.

Can I use OpenVEX instead of CSAF or CycloneDX VEX?

Yes. OpenVEX is acceptable. Include the schema reference in the document header so the reviewer's validation tooling can parse it. The deciding factor is consistency with your SBOM format, not the VEX format itself.

How often should I regenerate VEX during FDA review?

Monthly at minimum during active review, and immediately if a high-CVSS CVE lands against a component in your SBOM. The FDA reviewer's lookup happens at read-time, not at submission-time - out-of-date VEX is the most common VEX-related deficiency.

What's the difference between VEX and a vulnerability scan report?

A vulnerability scan report tells you which CVEs were detected against your SBOM. A VEX document tells the reviewer what you did about each one - affected, not affected (and why), fixed, or under investigation. The scan is input, the VEX is output.

If a CVE is fixed in a later version, do I still need a VEX entry?

If your SBOM ships the patched version, no VEX entry is needed for that CVE - your SBOM already shows the fix. If your SBOM still ships an older version and the CVE is fixed upstream, mark it fixed in the VEX and explain why you can't yet upgrade, or not_affected if the vulnerable code path is not reachable in your build.

Want a second pair of eyes on your VEX?

If you're about to ship a 510(k), De Novo, or PMA package and want a senior reviewer to walk your SBOM and VEX before the FDA does, we triage submission packages under NDA in 24 hours. We've shipped clean VEX-backed responses on 275+ devices.

• See the full VEX document reference guide
• Read SBOM vs VEX: What's the difference? if your team is still unclear on the split
• If you already have an FDA letter in hand, see which letter you got and book a deficiency response call