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 communicates product-specific status assessments; it does not prescribe a reduction in finding counts. 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 - built-in protections fully prevent exploitation through known attack vectors and cannot be subverted, configured, or disabled. A configurable firewall does not automatically qualify.

Component support lifecycle: EOS, EOL, and level of support

Supplier terminology varies. Record the actual support terms rather than assuming an acronym has a universal meaning.

Section 524B(b)(3) requires an SBOM for covered cyber-device submissions. It does not enumerate EOS or LoS fields. The February 3, 2026 FDA guidance recommends supporting information on each component's level of support and end-of-support date. That information can accompany the SBOM separately.

Support register and unknown dates

Tie each support record to a component identifier, version, supplier, evidence source, verification date, and responsible owner. Distinguish a public support date from a negotiated extension. If a supplier date is unknown, record that uncertainty and the outstanding supplier request. Do not invent a date or infer a security-fix commitment from community activity.

Compare component support commitments with the device's supported lifetime. Review changes when supplier terms, component versions, or vulnerability information change. The manufacturer sets a risk-based review cadence; there is no universal quarterly review or twelve-month migration deadline in Section 524B.

Recording support information in CycloneDX or SPDX

CycloneDX lifecycle phases describe stages such as build or operations, not supplier support status. Documented custom properties or notes can communicate support information. SPDX annotations can carry a documented convention. SPDX is Blue Goat's default delivery format, not an FDA mandate.

The following is a blank field convention, not a complete or schema-valid document:

component.identifier = <identifier for the assessed component version>
support.level = <verified supplier support terms>
support.end_date = <verified date, or unknown pending supplier response>
support.evidence = <supplier policy or contract reference>
support.checked_at = <actual verification date>

Map these fields to the chosen specification and recipient tooling. Validate the complete file and explain any convention in an accompanying record. Neither format has an FDA-mandated custom EOS property.

Decide what to do when support ends

Options to assess include replacing or upgrading the component, arranging extended support, maintaining a fork with assigned security responsibilities, and applying controls that reduce exposure. Record the feasibility and limitations of each option. None automatically establishes an acceptable device risk or submission outcome.

Connect the decision to updateability and patchability documentation, relevant security use cases, vulnerability assessment, the postmarket plan, and customer communications. The manufacturer supplies clinical severity evidence, decides residual-risk acceptance, and reviews release and regulatory consequences.

EOS does not determine VEX status

End of support describes support availability. VEX describes a specific vulnerability's applicability to a product version. An unsupported component is not automatically affected, not_affected, or under_investigation.

If the identified version is affected, provide an action statement under the selected VEX specification. Describe real remediation or mitigation options and their limitations. A fix in another version does not make the deployed vulnerable version fixed. Compensating controls do not automatically support not_affected.

See VEX Document Guide for Medical Devices: Statuses and Mistakes for status evidence and common assessment errors. Keep component support history separate from the vulnerability assessment history, with traceable links between them.

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.

Frequently asked questions

Is VEX strictly required by the FDA?▾

No. VEX is an optional way to communicate exploitability analysis; equivalent documented reasoning can also support triage.

How often must we send updated SBOMs to the FDA?▾

There is no rolling submission requirement to the FDA after clearance for the SBOM itself. The postmarket cybersecurity management plan documents your process. The 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?▾

A 5-business-day triage target is an illustrative internal choice, not an FDA benchmark. Set risk-based targets and escalation rules; critical uncontrolled-risk patches are due as soon as possible out of cycle, not on a universal 30-day clock.

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?▾

Include applicable software components, such as inference runtimes and frameworks, in the SBOM. A separate AI inventory can help track models, weights, datasets, and hosted services where relevant; the February 2026 cybersecurity guidance does not prescribe an ML-BOM extension or these specific sources.

What is the most common postmarket SBOM mistake?▾

An inventory not updated when shipped components change can become stale. An unchanged SBOM hash alone does not prove neglect: the component inventory may legitimately be unchanged.

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.

Fleet reality: many versions, one program

Postmarket SBOM maintenance gets hard when the field is heterogeneous. Different deployed firmware versions can contain different components and operate under different customer update policies. 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. Document any monitoring-scope change and assess its implications for devices still in service.

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.

• SBOM Service for FDA Premarket Submissions - 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 for Medical Devices - 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.