Postmarket SBOM Maintenance for Medical Devices

Talk to a MedTech cybersecurity expert

What postmarket SBOM maintenance actually requires

The February 3, 2026 FDA guidance, §V.A.4(b), p. 17 and the December 28, 2016 postmarket guidance support lifecycle vulnerability management. We propose the following internal workflow: 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 assessed using device-specific evidence; optionally communicate the assessment in a VEX statement.
5. Decide - the manufacturer documents risk disposition and remediation priorities. VEX can communicate the rationale but does not replace risk assessment.
6. Deploy - patches released per postmarket cadence; SBOM regenerated post-patch.
7. Communicate - hospital customers and the FDA notified per CVD policy and reporting obligations.

Cadence expectations

These are proposed internal targets, not FDA numeric SLAs. Section 524B(b)(2) calls for a reasonably justified regular patch cycle and patches for critical vulnerabilities presenting uncontrolled risk as soon as possible out of cycle. Do not delay urgent action to meet a target below.

• 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.
• Patch deployment planning: a proposed 30-day internal target where risk justifies it; critical uncontrolled-risk vulnerabilities require action as soon as possible out of cycle.
• 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. It can help communicate documented exploitability assessments.

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

Record component support level and end-of-support date in the SBOM or a separate addendum, as recommended by the FDA. 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

Reporting duties arise under 21 CFR Parts 803 and 806 when their respective event or correction/removal criteria are met, not under Section 524B(b)(2). The December 28, 2016 postmarket guidance describes a conditional Part 806 enforcement-discretion policy with 30/60-day provisions measured from awareness, not universal patch deadlines. 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.

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

Workload varies with component count, deployment configuration, advisory coverage, and reachability. Measure actual match and triage volumes for each supported device family.

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. Weekly scans or daily feeds with same-day triage are illustrative internal options, not risk-class-based regulatory safe harbors. Justify the cadence against device risk and provide urgent escalation. 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, document triage outcomes with device-specific evidence. If you choose VEX as the company communication format, use its affected, not affected, fixed, or under investigation statuses according to the selected specification. Equivalent documented assessments are also acceptable; VEX is optional. 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.
• SBOM Readiness Checker - check an SBOM against the FDA's expected fields before you submit it.
• SBOM Diff & VEX Drafter - diff two SBOM versions and draft the VEX statements for the delta.