Key Takeaways:

• The FDA is asking medical device manufacturers to submit VEX (Vulnerability Exploitability eXchange) files alongside SBOMs in some premarket cybersecurity submissions.
• VEX artifacts document whether known vulnerabilities in SBOM-listed components are exploitable in a specific device, giving reviewers risk context, not just a raw CVE list.
• Under Section 524B, incomplete cybersecurity documentation can trigger deficiency letters or Refuse to Accept (RTA) holds.
• RunSafe Security automatically generates VEX files as part of its SBOM output, giving manufacturers a ready-to-submit SBOM + VEX package without additional tooling or manual analysis.
• Medical device manufacturers should implement VEX generation now—before it becomes an explicit written requirement—not only to reduce FDA review delays but also to support the ongoing vulnerability monitoring and remediation expected under postmarket cybersecurity requirements.

 

The FDA’s cybersecurity bar for medical device submissions keeps climbing. For some premarket submissions, FDA reviewers are beginning to ask medical device manufacturers for VEX-style information that explains which medical device vulnerabilities actually matter in their products. 

For teams already scrambling to meet Section 524B cybersecurity expectations, this can feel like yet another requirement. But if you handle it correctly, it becomes an opportunity to streamline reviews and prove you’re ahead of the curve.

The FDA Isn’t Coasting on SBOM Requirements Anymore

Industry observers, including regulatory expert Naomi Schwartz, have flagged that FDA reviewers are requesting additional cybersecurity documentation in some submissions beyond a plain Software Bill of Materials (SBOM). This tracks closely with the broader tightening of FDA expectations under Section 524B of the FD&C Act and the agency’s 2025+ cybersecurity guidance, which makes SBOMs a mandatory component of cyber device premarket submissions and ties cybersecurity completeness directly to market authorization decisions.

The practical implication is that submissions with gaps in cybersecurity documentation, including missing or insufficient vulnerability context, can trigger deficiency letters, Refuse to Accept (RTA) holds, or review delays. 

The logical next step after mandating SBOMs was always this: requiring manufacturers to explain what those SBOMs mean from a risk perspective. VEX is that explanation.

An SBOM Without Exploitability Context Is Just a Vulnerability Firehose

The practical problem is that a medical device SBOM might list dozens or hundreds of third-party components. Many of those components will have associated CVEs. But raw CVE counts tell FDA reviewers and software manufacturers almost nothing about actual risk.

Is a given vulnerability reachable in the device’s execution environment? Is it already mitigated in code? Does the device architecture eliminate the attack surface entirely? Without answers to those questions, a reviewer is left guessing which CVEs matter and which don’t. That’s not a posture FDA wants to be in, and it’s not a posture manufacturers should want either.

By asking for VEX documentation, FDA reviewers are looking to understand what known vulnerabilities are in a device and how they affect said device.

VEX in the Medical Device Context: What It Is and Why It Matters Now

A VEX artifact states, for each SBOM-listed component with known vulnerabilities, whether those vulnerabilities are exploitable in the specific product and what the status or mitigation is. The documentation that lets a reviewer quickly assess a device’s risk posture rather than running their own ad hoc analysis.

VEX aligns with the FDA’s broader push toward continuous vulnerability management and transparency, not just one-time SBOM submissions. The agency has signaled that it wants cybersecurity to be treated as a lifecycle obligation, and VEX is how that obligation gets operationalized at the component level.

The benefits flow in both directions. Manufacturers who provide VEX reduce the back-and-forth that typically accompanies deficiency questions. Reviewers can quickly assess whether a manufacturer has done the analytical work.

RunSafe: VEX Files Are Already Built In

RunSafe’s SBOM generation does more than produce a component list. It associates known vulnerabilities with each component and generates VEX files and exploitability context as part of the output.

Our SBOMs already contain the core elements required for VEX reporting, and our platform automatically updates the VEX documentation nightly with new vulnerabilities as they become known.

This means RunSafe customers can maintain a continuously updated record of vulnerability status tied to their SBOM, supporting both FDA premarket submissions and ongoing postmarket vulnerability management.

A few of the practical benefits this unlocks:

Ready-to-submit SBOM and VEX files with vulnerability status for submission packages: RunSafe delivers the cybersecurity documentation package reviewers increasingly expect, reducing the risk of deficiency letters or RTA holds. The RunSafe Security Platform surfaces Known Exploited Vulnerabilities (KEVs) and critical and high vulnerabilities in one place—organized and reviewable, exactly as a submission package should be. SBOM reports that flag vulnerabilities from CISA’s Known Exploited Vulnerabilities catalog give reviewers immediate, defensible prioritization context without requiring manufacturers to manually cross-reference external sources.

Faster responses to ad hoc vulnerability inquiries: When a reviewer or customer asks, “Are you affected by CVE-XXXX-XXXXX?” the exploitability reasoning is already captured—no scrambling. RunSafe’s vulnerability triage syncing ensures that disposition decisions carry forward automatically across all future scans of the same SBOM, so the reasoning stays consistent and auditable rather than having to be reconstructed from scratch each time someone asks.

A single pipeline from build to regulatory submission: Generate your SBOM, generate your VEX artifact, and feed both into your secure development lifecycle and submission templates from one workflow, no separate tooling, no manual gap analysis. RunSafe also provides historical SBOM reports, backed by automatic nightly scans, to document how your security posture has evolved over time and to surface newly disclosed vulnerabilities, which supports the continuous vulnerability management lifecycle FDA expects, not just a point-in-time snapshot at submission.

Why Acting Now Beats Waiting for a Formal Requirement

FDA submissions that lack the required cybersecurity content, including SBOMs and related documentation, can be paused or rejected under current guidance.

Importantly, these expectations do not stop once a device is cleared. FDA guidance requires manufacturers to monitor for newly disclosed vulnerabilities and manage them throughout the device lifecycle. As new CVEs are published that affect software components in a device, manufacturers must assess exploitability, determine whether the device is affected, and document remediation plans or compensating controls.

This is where VEX becomes especially powerful. Rather than performing manual CVE triage every time a vulnerability database updates, manufacturers can maintain continuously updated vulnerability disposition records tied directly to their SBOM.

RunSafe’s platform supports this lifecycle approach automatically. The system continuously monitors vulnerability feeds and updates the vulnerability status associated with SBOM components as new CVEs are disclosed. As a result, VEX documentation tied to a device’s SBOM cis refreshed automatically—ensuring manufacturers always have an up-to-date record of:

• Newly disclosed vulnerabilities
• Exploitability status
• Mitigation or remediation actions

In practice, this means manufacturers can maintain living SBOM and VEX documentation that supports both regulatory submissions and postmarket cybersecurity obligations.

Waiting for a formal, explicit “VEX requirement” in updated guidance is a losing strategy. By the time that language appears in a final guidance document, early adopters will have already built the workflow, demonstrated maturity to reviewers, and shortened their review cycles. Manufacturers who wait will be scrambling to retrofit a VEX process into their existing SBOM infrastructure under deadline pressure.

The better approach is to build the capability now or select a tool that supports VEX submissions.

If you’re working on a current or upcoming FDA submission, we’d like to show you what this looks like in practice. Get in touch with our team, and we’ll walk through how RunSafe generates an SBOM plus VEX artifact that FDA reviewers can actually use, aligned to the latest cybersecurity guidance.