Postmarket SBOM Maintenance for Medical Devices

Talk to a MedTech cybersecurity expert

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?

How often must we send updated SBOMs to FDA?

How often must we share SBOMs with hospital customers?

What is the right vulnerability triage SLA?

What if a patch breaks regulated functionality?

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

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

What is the most common postmarket SBOM mistake?

How do we close the loop with our CVD program?

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

Fleet reality: many versions, one program

Postmarket SBOM maintenance gets hard when the field is heterogeneous. A device cleared three years ago is running four firmware versions across hospitals with different update policies, and each version has a different component set. The mistake is maintaining "the SBOM" as though there is one. There is one per released build, and the monitoring program has to match CVEs against all versions still in service.

That implies three things about your data model:

• Every SBOM is keyed by build ID and firmware version, archived at release, and never edited afterward.
• A deployment inventory maps versions to units in the field, even if the resolution is coarse (customer, region, install count). Without it you cannot answer "how many patients are exposed" when a CVE lands, and that is the first question in every escalation.
• A retired-version policy exists. Versions you no longer monitor must correspond to devices no longer supported, and the end-of-support communication must have gone out. Quietly dropping a version from monitoring while devices are still in service is the failure that becomes a recall conversation.

Sizing the workload before it surprises you

A typical connected device with an embedded Linux base, a mobile app, and a cloud service carries 400 to 1,200 components across all three tiers. Against public feeds that yields, in our experience, somewhere between 30 and 120 new CVE matches per month, and roughly 90 percent are not exploitable in the device's configuration.

The number that matters is not matches, it is the fraction that requires human judgment. With good identifier hygiene, reachability filtering, and VEX reuse from prior triage, a mature program reduces manual review to a handful of items per week. Without those, the same fleet generates a queue nobody can clear, and the program silently degrades into ignoring the feed. Reviewers and auditors detect that by asking for the triage record for a specific month and finding a gap.

Evidence an auditor or reviewer will ask for

Keep these retrievable within a working day:

• The SBOM for a named firmware version, with the build ID and generation timestamp.
• The vulnerability triage log for a named month, showing dispositions and the reasoning behind them.
• The VEX statements currently published, with their justifications and their review dates.
• The timeline for one closed vulnerability, from detection to field remediation, including the safety assessment.
• The end-of-support register with dates and migration status for components approaching end of life.

If any of these takes a week to assemble, the process exists on paper only. The premarket expectations behind this loop are covered in the postmarket cybersecurity readiness plan.

Where to go next

Postmarket SBOM maintenance fails for an unglamorous reason: nobody scheduled it. The submission SBOM gets built under deadline pressure, the device clears, the team moves to the next program, and eighteen months later a customer asks whether a headline CVE affects the device and there is no answer within reach. Everything below is designed to prevent that specific conversation.

Begin with cadence, not tooling. Write down who looks at new vulnerability data, how often, and what triggers an out-of-cycle look. A weekly automated scan with a monthly human review is defensible for most Class II devices. A daily feed with same-day triage is appropriate for a life-sustaining device with network exposure. Whatever you choose, the cadence has to appear in a procedure and the procedure has to produce records, because the records are the evidence an auditor asks for.

Next, fix your fleet mapping. Vulnerability triage is meaningless if you cannot answer which software versions are in the field and on which hardware revisions. Build the version-to-SBOM index once, keep it in the same system that holds your device history records, and make the release process refuse to ship without adding a row. Teams that skip this end up re-deriving the mapping under pressure during an actual incident.

Third, adopt VEX as the default output of triage rather than an occasional artifact. Every CVE that touches a listed component should end in one of four states with a written justification: affected, not affected, fixed, or under investigation. The value is not the file format. It is that "not affected because the vulnerable function is never reached in our configuration" is a defensible answer, while silence is not.

Fourth, connect triage to your patch governance and your coordinated vulnerability disclosure intake, so a finding from a researcher and a finding from your own scan enter the same queue with the same clock.

If you can only do one thing this quarter, build the fleet version index. Every other postmarket activity depends on it.

• FDA-Compliant SBOM Service - generation, gap-filling, and the tooling that keeps the file regenerating on every release.
• FDA Postmarket Cybersecurity Service - the running program: monitoring, triage, VEX, disclosure intake, and patch governance under Section 524B obligations.
• FDA SBOM requirements - the premarket baseline your postmarket program inherits, including the NTIA elements and support status expectations.