Pillar Guide · Updated 2026 · 15 min read

Maintain SBOMs for Medical Device Postmarket

Talk to a MedTech cybersecurity expert

TL;DR

• SBOM is a living document. Section 524B(b)(2) requires postmarket monitoring; reviewers expect SBOM regeneration on every build and continuous vulnerability re-scan.
• VEX (Vulnerability Exploitability eXchange) is what prevents 1,000-CVE noise from drowning real risk. Treat it as a required companion to SBOM.
• End-of-support (EOS) tracking belongs in the SBOM workflow, not a side spreadsheet.
• Patch deployment cadence and triage SLAs live in the postmarket cybersecurity management plan, referenced from the SBOM process.

What postmarket SBOM maintenance actually requires

The 2026 final premarket cybersecurity guidance and the 2017 postmarket guidance together expect a continuous loop: regenerate SBOM on every build, scan it against fresh vulnerability data continuously, triage exploitable vulnerabilities against patient-safety risk, deploy patches per the postmarket plan, document it all.

The maintenance loop

1. Build - SBOM generated automatically in CI/CD on every release candidate.
2. Diff - new SBOM compared against last released SBOM; new components flagged for supplier evaluation.
3. Scan - SBOM scanned against NVD, OSV, GitHub Security Advisories, and supplier feeds at least daily.
4. Triage - each finding evaluated for exploitability in your specific configuration. VEX statement produced.
5. Decide - exploitable findings enter the patch deployment queue; non-exploitable findings get a documented VEX rationale.
6. Deploy - patches released per postmarket cadence; SBOM regenerated post-patch.
7. Communicate - hospital customers and FDA notified per CVD policy and reporting obligations.

Cadence expectations

• SBOM regeneration: every build (typically nightly + on every release).
• Vulnerability scan: at least daily; ideally continuous via webhook from CVE feeds.
• Triage: within 5 business days for any new finding above informational severity.
• Critical-severity patch deployment: within 30 days of triage decision (more aggressive if patient-safety-impacting).
• End-of-support review: quarterly across all SBOM components.

VEX in detail

VEX (Vulnerability Exploitability eXchange) annotates each CVE affecting your SBOM with one of four statuses: not_affected, affected, fixed, or under_investigation. For not_affected, you state a justification (e.g., vulnerable function not invoked, configuration prevents exploitation). VEX is the artifact that turns a 1,000-CVE noise stream into a 50-CVE actionable queue. Reviewers and hospital customers both increasingly expect it.

VEX justification examples

• vulnerable_code_not_present - the affected function is not compiled into our binary.
• vulnerable_code_not_in_execute_path - the function exists but is unreachable from any input we accept.
• vulnerable_code_cannot_be_controlled_by_adversary - the function executes but inputs are constrained by a control we own.
• inline_mitigations_already_exist - a higher-layer control (WAF, kernel hardening) blocks the path.

End-of-support tracking

Every component in the SBOM should carry an end-of-support date. When a component approaches EOS (typically within 12 months), a migration plan enters the engineering backlog. End-of-support is a frequent reviewer question for postmarket follow-up: "what is your plan for [component X] when [supplier Y] stops patching it?" The answer needs to be documented before they ask.

Tooling stack we recommend

• SBOM generation: Syft, cdxgen, or language-native CycloneDX plugins.
• SBOM management: Dependency-Track or similar for storage, diff, and continuous scan.
• Vulnerability data: OSV, NVD, GitHub Security Advisories, supplier feeds.
• VEX format: OpenVEX or CycloneDX VEX.
• Hospital exchange: SBOM exchange via secure portal with versioning.

Reporting obligations

Section 524B(b)(2) and the postmarket guidance create reporting expectations for vulnerabilities that affect device safety or essential performance. The MAUDE / MDR pathway applies for vulnerabilities meeting the reportable-event threshold. Coordinated vulnerability disclosure (CVD) program intake is the entry point for many vulnerabilities reported by external researchers; CISA Coordinated Vulnerability Disclosure is the typical coordination partner for medical devices.

Frequently asked questions

Is VEX strictly required by FDA?

Not strictly named in the guidance, but reviewers and hospital customers increasingly expect it because without VEX the SBOM produces unmanageable CVE noise. Treat it as effectively required.

How often must we send updated SBOMs to FDA?

There is no rolling submission requirement to FDA after clearance for the SBOM itself. The postmarket cybersecurity management plan documents your process. FDA may request the current SBOM during postmarket inquiries.

How often must we share SBOMs with hospital customers?

Per your contracts and per HHS 405(d) practices. Many hospital procurement contracts now require SBOM-on-request and updated SBOMs at every release. Plan for self-service exchange.

What is the right vulnerability triage SLA?

5 business days for triage of any new finding above informational severity is the typical reviewer-acceptable benchmark. Critical-severity findings often have a 24-48 hour internal triage clock and a 30-day external patch target.

What if a patch breaks regulated functionality?

Triage records the conflict, your change-control process evaluates the patch in your QMS, and you document the controlled rollout. The postmarket plan should anticipate this scenario and define the decision pathway.

How do we handle vulnerabilities in a third-party cloud service we depend on?

The cloud service operator owns the patch; you own the response - configuration changes, rate limiting, additional monitoring. Document the dependency in the SBOM and the response in your CVD records.

Do we need to track AI/ML components in the postmarket SBOM?

Yes. ML-BOM extension entries for foundation models and inference runtimes follow the same regeneration and monitoring loop. AI-specific vulnerability sources (HuggingFace advisories, model-zoo CVEs, prompt-injection bulletins) should be wired into the scan.

What is the most common postmarket SBOM mistake?

SBOM generated at clearance and never regenerated. Reviewers spot this immediately during postmarket inquiry by asking for the current SBOM and seeing the same hash as the submission SBOM.

How do we close the loop with our CVD program?

Vulnerabilities reported through CVD intake feed into the same triage queue as scan-discovered vulnerabilities. One queue, one SLA, one set of reporting documents. Splitting them creates inconsistencies reviewers will catch.

What does end-of-support actually mean for a medical device?

Two senses. (1) Component EOS - the upstream supplier stops issuing security patches; you need a migration plan. (2) Device EOS - you stop supporting the device commercially; the postmarket plan defines how the device transitions out of support and what cybersecurity-relevant communications go to customers.

Where to go next

• FDA-Compliant SBOM Service
• FDA Postmarket Cybersecurity Service
• Medical Device SBOM Requirements Checklist