
On this page
Key Takeaways
- A Vulnerability Exploitability eXchange (VEX) document communicates which SBOM components are affected by a given vulnerability in the shipped configuration.
- VEX enables triage, many CVEs matched to SBOM components are not exploitable in the deployed context, and VEX makes that assessment machine-readable.
- Accepted formats include CycloneDX VEX and OASIS CSAF; both are supported by the FDA and by common healthcare CSIRT tooling.
- VEX is now a standard artifact in the postmarket cybersecurity management plan, reviewers expect a VEX generation process, not one-off statements.
- Publishing VEX to a well-known endpoint (security.txt-linked) shortens hospital CVD cycles significantly.
Learn how VEX documents complement SBOMs for FDA medical device compliance. Expert guidance on Vulnerability Exploitability eXchange for MedTech manufacturers.
This guide is written for medical device manufacturers navigating VEX document FDA medical device. It is built from real submissions, FDA correspondence, and the standards reviewers actually cite. Use it as a working reference: read straight through, jump to the section that matches your current gap, or hand it to your engineering and regulatory leads as a checklist.
What is a VEX Document in Medical Device Cybersecurity?
What is a VEX Document in Medical Device Cybersecurity? is one of the areas FDA reviewers probe hardest in modern submissions. The points below summarize what we ship in client packages and what we have seen FDA accept and reject across 250+ device submissions.
Defining Vulnerability Exploitability eXchange (VEX)
Defining Vulnerability Exploitability eXchange (VEX). Make sure your design history file documents the rationale, the standard you mapped to, and the objective evidence that closes the loop. Reviewers expect to trace the requirement, the test, and the residual risk in a single thread.
The Relationship Between SBOM and VEX
The Relationship Between SBOM and VEX. Make sure your design history file documents the rationale, the standard you mapped to, and the objective evidence that closes the loop. Reviewers expect to trace the requirement, the test, and the residual risk in a single thread.
Why the FDA Requires VEX for Medical Devices
Why the FDA Requires VEX for Medical Devices is one of the areas FDA reviewers probe hardest in modern submissions. The points below summarize what we ship in client packages and what we have seen FDA accept and reject across 250+ device submissions.
Postmarket Management and Section 524B Compliance
Postmarket Management and Section 524B Compliance. Make sure your design history file documents the rationale, the standard you mapped to, and the objective evidence that closes the loop. Reviewers expect to trace the requirement, the test, and the residual risk in a single thread.
Responding to FDA Deficiencies regarding SBOM Vulnerabilities
Responding to FDA Deficiencies regarding SBOM Vulnerabilities. Make sure your design history file documents the rationale, the standard you mapped to, and the objective evidence that closes the loop. Reviewers expect to trace the requirement, the test, and the residual risk in a single thread.
The Four VEX Status Labels for MedTech VMS
The Four VEX Status Labels for MedTech VMS is one of the areas FDA reviewers probe hardest in modern submissions. The points below summarize what we ship in client packages and what we have seen FDA accept and reject across 250+ device submissions.
Not Affected: When the Vulnerability Isn't Exploitable
Not Affected: When the Vulnerability Isn't Exploitable. Make sure your design history file documents the rationale, the standard you mapped to, and the objective evidence that closes the loop. Reviewers expect to trace the requirement, the test, and the residual risk in a single thread.
Affected: Acknowledging and Fixing the Risk
Affected: Acknowledging and Fixing the Risk. Make sure your design history file documents the rationale, the standard you mapped to, and the objective evidence that closes the loop. Reviewers expect to trace the requirement, the test, and the residual risk in a single thread.
Fixed: Confirming Resolution
Fixed: Confirming Resolution. Make sure your design history file documents the rationale, the standard you mapped to, and the objective evidence that closes the loop. Reviewers expect to trace the requirement, the test, and the residual risk in a single thread.
Under Investigation: Managing Real-Time Triage
Under Investigation: Managing Real-Time Triage. Make sure your design history file documents the rationale, the standard you mapped to, and the objective evidence that closes the loop. Reviewers expect to trace the requirement, the test, and the residual risk in a single thread.
VEX Implementation Formats: CSAF, CycloneDX, and SPDX
VEX Implementation Formats: CSAF, CycloneDX, and SPDX is one of the areas FDA reviewers probe hardest in modern submissions. The points below summarize what we ship in client packages and what we have seen FDA accept and reject across 250+ device submissions.
Best Practices for Generating and Maintaining VEX Data
Best Practices for Generating and Maintaining VEX Data is one of the areas FDA reviewers probe hardest in modern submissions. The points below summarize what we ship in client packages and what we have seen FDA accept and reject across 250+ device submissions.
Automation in Vulnerability Triage
Automation in Vulnerability Triage. Make sure your design history file documents the rationale, the standard you mapped to, and the objective evidence that closes the loop. Reviewers expect to trace the requirement, the test, and the residual risk in a single thread.
Linking VEX to your Coordinated Vulnerability Disclosure (CVD)
Linking VEX to your Coordinated Vulnerability Disclosure (CVD). Make sure your design history file documents the rationale, the standard you mapped to, and the objective evidence that closes the loop. Reviewers expect to trace the requirement, the test, and the residual risk in a single thread.
Conclusion: VEX as a Tool for Market Clearance and Safety
Conclusion: VEX as a Tool for Market Clearance and Safety is one of the areas FDA reviewers probe hardest in modern submissions. The points below summarize what we ship in client packages and what we have seen FDA accept and reject across 250+ device submissions.
How Blue Goat Cyber Approaches VEX document FDA medical device
We treat VEX document FDA medical device as a regulated engineering workstream, not a one-time document drop. Every engagement is led by senior medical-device security engineers who have shipped 250+ FDA cybersecurity submissions across 510(k), De Novo, PMA, and EU MDR pathways. Here is how we run it end to end:
- Scoping against your device profile. We baseline connectivity, interfaces, data flows, and intended use before we touch a template - because reviewer expectations for a Class II wearable are not the same as a networked hospital platform.
- Standards mapping in writing. Every deliverable is traced to the February 2026 FDA premarket cybersecurity guidance, AAMI SW96, AAMI TIR57 / TIR97, IEC 81001-5-1, and ISO 14971 - with the citation in the artifact itself so reviewers do not have to guess.
- Evidence generated inside your QMS. Threat models, SBOMs, security risk assessments, and test reports are versioned under design controls so the traceability from requirement → test → residual risk holds up under audit.
- Independent testing where it counts. Penetration testing and vulnerability analysis are executed by a testing team that does not also write the design - the separation FDA reviewers increasingly expect on cyber devices.
- Deficiency-ready posture. We anticipate the RTA, AI-letter, and Major deficiency patterns FDA has issued over the past 24 months and pre-empt them in the initial submission, cutting the odds of a second review cycle.
- Postmarket handoff, not abandonment. Every premarket package leaves you with a working postmarket monitoring plan, CVD process, and update cadence so the evidence you shipped stays defensible after clearance.
If you want that treatment applied to your VEX document FDA medical device package, our FDA Premarket Cybersecurity Services and FDA Cybersecurity Deficiency Response engagements are the two most common entry points.
Frequently asked questions
What is the difference between SBOM and VEX for medical devices?
Short answer: VEX document FDA medical device is a discrete deliverable inside the Secure Product Development Framework (SPDF). FDA expects it documented, traceable, and version-controlled inside your QMS. For the full context, work through the relevant section above and the linked services below. Every answer here is grounded in current FDA guidance and the standards your reviewer is using.
Does the FDA require VEX documents for 510(k) submissions?
Short answer: Yes. Under Section 524B and the February 2026 final guidance, every cyber device requires the artifact in question. Skipping it is the fastest way to an RTA hold. For the full context, work through the relevant section above and the linked services below. Every answer here is grounded in current FDA guidance and the standards your reviewer is using.
What are the approved formats for VEX documents in healthcare?
Short answer: VEX document FDA medical device is a discrete deliverable inside the Secure Product Development Framework (SPDF). FDA expects it documented, traceable, and version-controlled inside your QMS. For the full context, work through the relevant section above and the linked services below. Every answer here is grounded in current FDA guidance and the standards your reviewer is using.
How do I prove a vulnerability is 'not affected' in a medical device VEX?
Short answer: Treat it as a process, not a one-off document: own the requirement in design controls, map it to a current standard, generate evidence during V&V, and surface the residual risk in your postmarket plan. For the full context, work through the relevant section above and the linked services below. Every answer here is grounded in current FDA guidance and the standards your reviewer is using.
Who is responsible for maintaining VEX data postmarket?
Short answer: It depends on the device classification, intended use, and connectivity profile. But the controlling references are FDA's February 2026 premarket guidance, AAMI SW96, and IEC 81001-5-1. The sections above walk through how each applies. For the full context, work through the relevant section above and the linked services below. Every answer here is grounded in current FDA guidance and the standards your reviewer is using.
Where this fits in the cluster
This page sits downstream of our pillar resources on VEX document FDA medical device. If you arrived here from a different starting point, these are the most useful adjacent pages:
- FDA-Compliant SBOM Services
- FDA Postmarket Cybersecurity Services
- The Postmarket Cybersecurity Readiness Plan
- The MedTech Cybersecurity Standards Decoder
Related from Blue Goat Cyber
- FDA Premarket Cybersecurity Services
- FDA-Compliant SBOM Services
- FDA Cybersecurity Deficiency Response
- The SPDF Playbook for FDA-Ready Medical Devices
- Medical Device Threat Modeling
- Medical Device Penetration Testing
Sources & primary references
- Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions. FDA
- Vulnerability Exploitability eXchange (VEX) Overview. NIST
- Vulnerability Exploitability eXchange (VEX) Use Cases. CISA/NIST
- Implementation Guidance for SBOM of Medical Devices. AAMI/HSDP-12
Talk to a regulatory cybersecurity team
If you are working through VEX document FDA medical device and want a second pair of eyes on your submission package, we ship cybersecurity deliverables for medical device manufacturers across 510(k), De Novo, PMA, and EU MDR pathways. Book a discovery session and we will walk your evidence with you.
Sources & references
Primary sources cited in this article. Links open in a new tab.


