5 VEX Mistakes That Trigger FDA Cybersecurity Deficiencies

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 250+ FDA submissions, 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.

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/[email protected]) or CPE. Reviewers cross-check every reference against your SBOM. Common mismatches that trigger findings:

• VEX references pkg:npm/[email protected] but your SBOM lists pkg:npm/[email protected].
• 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

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.

Frequently asked questions

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 250+ submissions.

• 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