How should a hospital review a medical device maker's SBOM?

A hospital should review a medical device maker's SBOM as a buyer, not as a patcher: write SBOM and vulnerability duties into the purchase contract, check the file against the FDA and CISA minimum fields, flag unsupported and unidentified components, and match every component to CISA's Known Exploited Vulnerabilities catalog. When a match lands, ask the maker for a written status, isolate the device if needed, record the compensating control, and repeat the review for every software release.

You cannot patch an infusion pump, an imaging console or a bedside monitor yourself. The manufacturer owns the software and its validation. So the SBOM is worth most at two moments: at purchase, when you can still demand transparency and support dates, and on the day a new exploited vulnerability is announced, when you need to know within hours which devices on your floor carry it and what to isolate.

This guide is for CISOs, clinical engineering leads and third-party risk teams at US hospitals. Most of it is a method you can run with any tooling; the last part shows how Safeguard handles the request, validation and monitoring work, and what it does not do. This is not legal or regulatory advice.

Key takeaways

• The device maker owes FDA an SBOM. Section 524B(b)(3) of the FD&C Act requires sponsors of cyber devices to give FDA a software bill of materials covering commercial, open source and off-the-shelf components. FDA's 3 February 2026 premarket guidance also tells manufacturers to give users SBOM information in labeling, machine-readable and on a continuous basis.
• FDA asks for two fields the general minimum elements do not: each component's level of support and its end-of-support date. Ask for both, in the SBOM or in an addendum.
• The general bar moved in 2026. CISA's "2026 Minimum Elements for a Software Bill of Materials," published 29 July 2026 with NSA, FBI and international partners, replaces the 2021 NTIA minimum elements. Supplier Name became Component Producer, and hashes, licenses and an SBOM Author Signature were added.
• Put it in the contract. The Health Sector Coordinating Council's Model Contract-Language for Medtech Cybersecurity (MC2, March 2022) has clauses for a complete SBOM, operating system support windows, vulnerability notice and compensating controls you can adapt.
• KEV is your trigger list. FDA says vulnerabilities in CISA's KEV catalog should be designed out of the device. When one appears in a device SBOM, ask for a written status and isolate first if exposure is plausible.
• Record the compensating control with an owner, a review date and a clinical sign-off. FDA defines a compensating control as one deployed by the user in place of controls designed in by the manufacturer.
• Safeguard capabilities in this post and their labels: TPRM, the Third-Party Risk Manager (GA), covering vendor management, SBOM requests with status tracking and automated follow-ups, the 0 to 100 vendor risk score (higher is better) using EPSS and KEV, and continuous monitoring alerts; Portal Find & Review SBOMs (GA); CSAF and VEX upload (GA); the Safeguard MCP server (GA); the desktop app; autonomous remediation (GA, ships switched off with every category set to Manual); Gold Open Source and Gold Registry (GA); fork and patch (GA).
• Safeguard does not touch the device. It cannot patch or reconfigure a device, it only knows what the maker's SBOM declares, it does not discover devices on your network, and its vendor score is a prioritisation aid, not a clinical risk assessment.

Why a hospital reviews a device SBOM differently

Most SBOM advice is written for the team that builds the software and can upgrade, rebuild and ship. A hospital cannot. A regulated medical device runs software the manufacturer validated, and changing it outside the maker's process can affect safety, effectiveness and the device's regulatory status.

That changes what the SBOM is for. For a hospital, the file answers four practical questions:

1. Before purchase: is this maker transparent, and how long will the software inside this device be supported?
2. At go-live: what software am I putting on my clinical network, and which parts are already out of support?
3. On disclosure day: when a new vulnerability is announced or added to the KEV catalog, which of my devices carry the affected component and version?
4. Over the device's life: is the maker keeping the SBOM current, and are its answers to my questions arriving on time?

Exposure also depends on deployment: a vulnerable component can be harmless with networking disabled and urgent on a flat clinical VLAN. The SBOM tells you what is inside; your inventory and network design tell you whether it can be reached.

What rules shape a medical device SBOM?

Knowing what the maker already owes FDA tells you what is reasonable to ask for.

Section 524B of the FD&C Act

Section 524B, codified at 21 U.S.C. 360n-2, was added by the Consolidated Appropriations Act, 2023 (Pub. L. 117-328, division FF, title III, section 3305) on 29 December 2022 and took effect 90 days later. It applies to a "cyber device," which the statute defines as a device that includes software validated, installed or authorized by the sponsor, can connect to the internet, and has characteristics that could be vulnerable to cybersecurity threats.

For those devices, the sponsor of a premarket submission must:

• submit a plan to monitor, identify and address postmarket vulnerabilities and exploits, including coordinated vulnerability disclosure (524B(b)(1));
• maintain processes that give reasonable assurance the device and related systems are cybersecure, and make postmarket updates and patches available, on a reasonably justified regular cycle for known unacceptable vulnerabilities and as soon as possible out of cycle for critical vulnerabilities that could cause uncontrolled risks (524B(b)(2));
• provide FDA a software bill of materials "including commercial, open-source, and off-the-shelf software components" (524B(b)(3)).

Note what the statute says and does not say. It obliges the manufacturer to give the SBOM to FDA. It does not, on its own, oblige the manufacturer to give it to you. That is what FDA's labeling recommendations and your contract are for.

FDA's premarket cybersecurity guidance (February 2026)

The current guidance is "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," issued 3 February 2026. It supersedes the version issued 27 June 2025. It contains nonbinding recommendations, but it is the clearest statement of what FDA expects manufacturers to produce, and a hospital can reasonably ask for the same evidence.

Three parts matter for a hospital reviewer:

• SBOM content. Manufacturers should provide machine-readable SBOMs consistent with the minimum elements, which the guidance also calls baseline attributes, citing the October 2021 NTIA document "Framing Software Component Transparency." In addition, for each component, FDA asks for the software level of support from the component's maker (for example actively maintained, no longer maintained, abandoned) and the component's end-of-support date. The manufacturer may put these in the SBOM or in a separate addendum.
• Known vulnerabilities. Manufacturers should identify all known vulnerabilities associated with the device and its components, including those in CISA's KEV catalog, with a safety and security risk assessment of each. Elsewhere the guidance says KEV vulnerabilities "should be designed out of the device."
• Labeling for users. Section VI.A lists information that may go into labeling, including an SBOM "to effectively manage their assets," made available "on a continuous basis," in a machine-readable format, with up-to-date links if an online portal is used. The same list includes network ports and interfaces, recommended security controls, end of support and end of life information, and a pre-communicated process for transferring risk if a device stays in service past end of support.

That labeling list is a ready-made checklist for a hospital: if the maker followed it, most of what you need already exists.

FDA's postmarket guidance (2016)

FDA's "Postmarket Management of Cybersecurity in Medical Devices," issued 28 December 2016, defines two ideas you will use constantly. A compensating control is a safeguard deployed by a user in place of, or in the absence of, controls designed in by the manufacturer; FDA's own example is configuring the hospital network to remove unauthorized access to a device that can operate safely without it. An uncontrolled risk is unacceptable residual risk of patient harm.

For vulnerabilities with uncontrolled risk, the guidance describes the conditions under which FDA does not intend to enforce certain reporting requirements, including that the manufacturer communicates with customers, identifies interim compensating controls and develops a remediation plan no later than 30 days after learning of the vulnerability, and fixes, validates and distributes a fix no later than 60 days after learning of it. Those are manufacturer timelines tied to an FDA enforcement policy, not promises to you, but they are a useful reference when you negotiate notice terms. The maker's side of this is covered in medical device postmarket vulnerability management under FDA.

CISA's 2026 SBOM minimum elements

On 29 July 2026 CISA, NSA, FBI and international partners published "2026 Minimum Elements for a Software Bill of Materials (SBOM)." CISA says it updates and replaces the minimum elements NTIA published in 2021.

The 2021 NTIA report listed seven data fields: Supplier Name, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data and Timestamp. The 2026 document splits data fields into SBOM metadata and component data:

The practices changed too. "Depth" became Coverage: all components including transitive dependencies, so a recipient can conclude a vulnerability does not affect them if the component is not listed. "Known Unknowns" became Explicitly Identifying Unknown Information, which asks the author to say whether missing data is unknown or withheld. Frequency says each software version or update should have an SBOM. The Access Control element was removed and folded into Distribution and Delivery, and SWID tags were dropped from the formats list, leaving SPDX and CycloneDX as the two widely used formats.

FDA's guidance still cites the 2021 NTIA framing. A practical reading for a hospital: accept the NTIA baseline as the floor the maker plans against for FDA, and use the 2026 CISA fields as the better bar to ask for, especially producer, identifiers, hashes and SBOM version. Ask; do not assume a 2024 device SBOM was built to a 2026 document.

HHS cybersecurity performance goals for the sector

HHS publishes voluntary Healthcare and Public Health (HPH) Cybersecurity Performance Goals aimed at healthcare delivery organizations. Several map directly onto device SBOM work. Among the Essential Goals are Mitigate Known Vulnerabilities and Vendor/Supplier Cybersecurity Requirements, the latter described as identifying, assessing and mitigating risks from third party products and services. Among the Enhanced Goals are Asset Inventory, Third Party Vulnerability Disclosure, Third Party Incident Reporting and Network Segmentation.

What can a hospital ask a device maker for?

The best time to get SBOM rights is before the purchase order. After installation, a manufacturer has little reason to change how it shares information with one customer.

What the HSCC model contract language suggests

The Health Sector Coordinating Council's Cybersecurity Working Group published the Model Contract-Language for Medtech Cybersecurity (MC2) in March 2022 as a reference for cooperation between healthcare delivery organizations and medical device manufacturers. It is a model, not a mandate: each clause comes with a revision history box so the parties can propose changes. The clauses most relevant to SBOM review are these.

A request list you can attach to the RFP

Turn the regulations and the model language into a short, specific request. Vague asks ("provide an SBOM") get vague files. A workable list:

1. A machine-readable SBOM in SPDX or CycloneDX for the exact software version you are buying, including firmware and the embedded operating system, with transitive dependencies.
2. For each component, the level of support and the end-of-support date, in the SBOM or in a dated addendum, as FDA's premarket guidance recommends.
3. A statement of which minimum elements the SBOM meets (NTIA 2021 at least; CISA 2026 where possible), and where data is unknown or withheld, an explicit marker saying which.
4. The list of known vulnerabilities at delivery, with the maker's assessment of each, and VEX or CSAF statements for any it considers not exploitable in the device.
5. A new SBOM with every software update or patch, and a revised SBOM when the maker corrects an error, consistent with the CISA Frequency practice.
6. Notice terms for new vulnerabilities, including KEV entries, with a timeframe and the content you expect (risk impact, plan, compensating controls), drawing on MC2 clauses 23 and 33.
7. The manufacturer's security contact and coordinated vulnerability disclosure policy.
8. The current MDS2 form for the device, revision-controlled to match the software version.
9. Network ports, protocols and required services, so you can design segmentation before go-live.
10. The end-of-support date for the device itself and the maker's process for transferring risk if you keep it in service after that date.

Put the list in the RFP so it scores and in the contract so it binds. If a maker cannot meet an item, get the gap in writing for your risk register.

How do you check a device SBOM for completeness?

When the file arrives, check four things in order: that it parses, that it carries the minimum fields, that it has FDA's two extra fields, and that it covers the device.

Step 1: Does it parse, and what is it?

Open the file with a JSON tool before any SBOM tool. A file that does not parse cleanly is a finding in itself. Then read the header. For CycloneDX JSON:

jq '{format: .bomFormat, spec: .specVersion, serial: .serialNumber, sbom_version: .version, timestamp: .metadata.timestamp, authors: .metadata.authors, tools: .metadata.tools, target: .metadata.component.name, target_version: .metadata.component.version}' device-sbom.cdx.json

For SPDX 2.3 JSON:

jq '{spec: .spdxVersion, name: .name, created: .creationInfo.created, creators: .creationInfo.creators, packages: (.packages | length), relationships: (.relationships | length)}' device-sbom.spdx.json

Check that the target name and version match the software on your purchase order, not a different release or the companion workstation application. For a fuller intake routine, see the first 30 minutes with a new supplier SBOM and how to check a supplier SBOM against the minimum elements.

Step 2: Are the minimum fields filled in?

Count the gaps rather than eyeballing them. For CycloneDX:

# Components missing a version, a producer or supplier, a package URL or CPE, or a hash
jq '[.components[] | select((.version // "") == "")] | length' device-sbom.cdx.json
jq '[.components[] | select(.supplier == null and .manufacturer == null and .publisher == null)] | length' device-sbom.cdx.json
jq '[.components[] | select(.purl == null and .cpe == null)] | length' device-sbom.cdx.json
jq '[.components[] | select((.hashes // []) | length == 0)] | length' device-sbom.cdx.json
jq '.components | length' device-sbom.cdx.json
jq '.dependencies | length' device-sbom.cdx.json

For SPDX:

jq '[.packages[] | select((.versionInfo // "") == "")] | length' device-sbom.spdx.json
jq '[.packages[] | select((.supplier // "NOASSERTION") == "NOASSERTION")] | length' device-sbom.spdx.json
jq '[.packages[] | select([(.externalRefs // [])[] | select(.referenceType == "purl" or (.referenceType | startswith("cpe")))] | length == 0)] | length' device-sbom.spdx.json

Read the counts against the total. A few internal modules without a producer is normal. Half the file without identifiers means you cannot match it to advisories. An SBOM with hundreds of components and no relationships is a flat list that will not tell you which top-level item pulled in a vulnerable library.

Step 3: Does it carry FDA's two extra fields?

Neither SPDX nor CycloneDX has one universal field that every manufacturer uses for level of support and end-of-support date, and FDA allows the manufacturer to provide them in an addendum. So ask where they are, then check every component has both. If the maker uses CycloneDX properties, a quick listing shows which property names are in use:

jq '[.components[] | (.properties // [])[] | .name] | unique' device-sbom.cdx.json

If the answer is an addendum, check it names the same SBOM version and covers every component.

Step 4: Does it cover the whole device?

Coverage is the hardest check, because you are looking for what is missing. Ask:

• Is the embedded operating system listed, with its exact version? CycloneDX has an operating-system component type; SPDX packages will usually name the distribution and kernel.
• Is firmware listed separately from application software?
• Are the libraries inside the application listed, or only the application itself?
• Are third-party commercial components (databases, runtimes, imaging toolkits) listed, even if the maker cannot share their internals?
• Does the file mark unknown or withheld information explicitly, as the CISA 2026 practice asks?

jq -r '.components[] | select(.type == "operating-system" or .type == "firmware") | [.type, .name, .version] | @tsv' device-sbom.cdx.json

Compare the SBOM with the maker's MDS2 form and port list. If the MDS2 says the device runs a web server and the SBOM lists none, ask. When the maker corrects errors, how to handle mistakes in a supplier SBOM covers telling good faith from obfuscation.

Which components should trigger questions?

End of support or no longer maintained

Any component whose level of support is "no longer maintained" or "abandoned," or whose end-of-support date has passed or will pass during your expected service life, deserves a written answer. MC2 clause 44 asks the supplier to notify you and either replace the component or take over its maintenance. FDA's labeling list asks the maker to describe end of support and a risk transfer process. Your question is simple: what is the plan, and by when?

No producer or unknown provenance

The CISA 2026 document says that when there is no clear component producer, the SBOM author should say the component is of unknown provenance. A component with no producer, no identifier and no hash is a component nobody can track. Ask the maker how they monitor it for vulnerabilities, because the SBOM alone gives them no way to.

The embedded operating system

The operating system usually carries the largest share of vulnerabilities and the hardest upgrade path. MC2 clause 40 sets a two-year buffer before the OS's own end of support at the time of delivery. Compare the OS version and its vendor's published end-of-support date against the device's expected life on your floor. A device bought in 2026 with an OS that loses support in 2027 is a predictable problem.

Components that face the network

Cross-reference the SBOM with the port list. A vulnerable TLS library, web server, remote access agent or file transfer service matters more than a vulnerable image codec that only processes local files, because exposure is what turns a vulnerability into risk.

Mismatches and duplicates

A component version that contradicts the release notes, or an SBOM timestamp older than the build, suggests the SBOM came from the wrong artifact. The CISA 2026 Generation Context field exists to tell you which artifact it came from.

What do you do when a device SBOM component shows up in CISA's KEV catalog?

CISA adds a vulnerability to the KEV catalog when it has a CVE ID, there is reliable evidence of active exploitation in the wild, and there is a clear remediation action such as a vendor update. Its catalog version released 23 October 2026 listed 1,756 entries. CISA publishes it as a web page, a CSV file and a JSON feed with a schema, and each entry carries fields such as cveID, vendorProject, product, dateAdded, dueDate, requiredAction and knownRansomwareCampaignUse.

The federal rule behind those dates is BOD 26-04, "Prioritizing Security Updates Based on Risk," issued by CISA on 10 June 2026. It revoked and superseded BOD 22-01, the 2021 directive that set fixed two-week KEV deadlines. BOD 26-04 sets each timeline from four factors: public exposure of the asset, KEV status, whether exploitation can be automated, and whether an attacker gains partial or total control. The clock starts when CISA adds the CVE to KEV, and the timeline moves as facts change; taking a system off the internet can lengthen it. Our post on BOD 26-04's four factors has the detail.

BOD 26-04 applies to federal agency information systems, not private hospitals. Its four factors still fit a device review, and many hospitals use the KEV dueDate as an internal yardstick.

A KEV match triggers a fixed sequence, not a panic.

1. Confirm the match. Check the component's identifier and exact version against the advisory. KEV names products by vendor, which may not map one to one to the package in the SBOM.
2. Find every affected device. Use your device inventory to list every installed unit running the software version whose SBOM contains the component. This is where an SBOM that names the exact release pays off.
3. Assess exposure. Is the vulnerable service reachable from the device's segment, or from the internet? Note what only the maker can know, such as whether the vulnerable function is used.
4. Ask the maker for a written status. Ask whether the device is affected, under investigation, fixed in a later release or not affected, and why. The CISA minimum requirements for VEX define exactly those four statuses (not_affected, affected, fixed, under_investigation) and say a not_affected statement should give a justification. Point to your contract's notice clause if you have one.
5. Isolate if exposure is plausible. Do not wait for the maker's answer if the service is reachable and the component is confirmed. Tighten network access first; you can relax it later.
6. Record the decision. Write down the compensating control, who approved it, the clinical impact and the review date (see the next section).
7. Track the fix. When the maker releases a validated update, schedule it with clinical engineering, then request the new SBOM and confirm the component changed.

FDA's premarket guidance asks manufacturers to address KEV entries in their cybersecurity management plans. A maker that cannot answer within days has told you something about its program; note it in your vendor assessment.

How do you record compensating controls when the maker has not released a fix?

FDA's postmarket guidance describes compensating controls as external to the device design, configurable in the field and employed by the user. In practice, for hospitals, that usually means:

• Segmentation: moving the device to a dedicated VLAN or network segment with only the flows it needs, which is also an HPH Enhanced Goal.
• Access control lists: blocking the vulnerable port or service at the switch or firewall, or allowing it only from named management hosts.
• Disabling a feature: turning off a service the device does not need for clinical use, where the maker's documentation says this is safe.
• Removing connectivity: taking a device off the network entirely if it can operate safely without it, which is FDA's own example.
• Monitoring: watching the device's traffic for unexpected connections while the exposure lasts.

Each carries clinical consequences. Blocking a port can stop results reaching the record system, so the decision needs a clinical owner as well as a security owner.

A record that holds up in an audit or an incident review contains:

Keep the record with the device in your asset system, not in a ticket that closes.

How do you keep monitoring device SBOMs after purchase?

An SBOM is a snapshot of one software release. Two things make it go stale: the device software changes, and the world's knowledge of vulnerabilities changes. Monitoring has to cover both.

How often should the maker send updates?

The CISA 2026 Frequency practice says each software version or update should have an SBOM, and a revised SBOM should be issued when the author discovers new details or corrects an error. FDA's labeling recommendations say manufacturers should make SBOM information available on a continuous basis and keep portal links current. So the right answer to "how often" is "every time the software changes, and whenever the SBOM is corrected," not a calendar date.

Add a calendar backstop: if a critical device has produced no new SBOM in a set period, ask whether the software changed. A device with no updates for years is itself a risk signal.

How often should you re-check an unchanged SBOM?

Continuously, if you can. The SBOM does not have to change for your risk to change; new CVEs and KEV entries arrive constantly. At minimum, re-match every device SBOM when KEV adds an entry, and re-analyse on a schedule that fits the device's criticality.

What should trigger an out-of-cycle review?

• A KEV addition that matches a component name in any device SBOM.
• A maker's security advisory or field notice.
• A software update installed by clinical engineering or the maker's field service.
• A component reaching its end-of-support date.
• A change in how the device is networked, for example a move to a new building or a new integration.
• Contract renewal, your next chance to change terms.

How Safeguard does this job

Safeguard covers the request, validation, matching and monitoring parts of this method. It does not cover the device, the network or the clinical decision. The steps below follow Safeguard's documentation for TPRM (GA) and Portal Find & Review SBOMs (GA). Where the docs do not show a screen, the step describes the outcome only.

Requesting and validating device SBOMs in TPRM

1. Add the manufacturer as a vendor. TPRM's vendor directory holds contacts, contract and SLA tracking and risk categorisation. Add each device maker and the device products you buy from it.
2. Set a risk tier. The docs describe four tiers. Critical vendors have an SBOM requirement of "Required, quarterly updates," High vendors "Required, annual updates," Medium "Recommended" and Low "Optional." Devices on the clinical network usually belong in Critical or High; treat the docs' cadence as a default and set your own from the contract.
3. Write a device request template. Under Settings › Request Templates, click Create Template. The standard template asks for SPDX or CycloneDX, the EO 14028 required fields, submission instructions and a deadline. Add your contract asks: exact software version, embedded OS, level of support and end-of-support date per component, and known vulnerabilities with VEX statements. The template carries the request; it does not make the platform check FDA's two extra fields.
4. Send the request. Open the vendor, click Request SBOM, select the product, choose the template, adjust the message, set a deadline and click Send. For several makers at once, select them under Vendors and click Bulk Request.
5. Track status and follow-ups. Requests move through Sent, Viewed, In Progress, Submitted, then Validated or Rejected. The docs describe reminders 7 days before the deadline and at the deadline, and an escalation 7 days after it.
6. Let validation run. Makers can submit by email attachment or a secure upload portal, among other routes. On receipt, the docs say Safeguard validates the format, checks completeness for required fields, verifies EO 14028 compliance, runs an automatic vulnerability scan and notifies the requester.
7. Request a revision when it falls short. Review the validation failures, click Request Revision and specify the corrections. Use it for SBOMs of the wrong release, missing operating systems or flat lists without relationships.

Reviewing the file in Portal Find & Review

8. Open the SBOM. Find & Review lets you search by product, supplier, component or version. An SBOM's overview shows compliance status (EO 14028 status and NTIA elements), components by type, a vulnerability summary and licenses.
9. Read the detail tabs. Components lists versions, package URLs and supplier data. Vulnerabilities shows CVEs with severity, CVSS, fix availability and exploitation status. Quality shows a completeness score, missing fields and data quality issues, which is the quickest way to write a precise revision request.
10. Compare versions when an update arrives. Click Compare Versions to see added and removed components, version changes, new CVEs and fixed CVEs. This is how you confirm an update really removed the component behind a KEV entry.
11. Link and subscribe. Link to TPRM associates an SBOM found in Portal with the vendor profile. Subscribe notifies you of new versions, vulnerability updates and compliance changes.

Scoring and accepting risk

12. Read the vendor risk score. TPRM scores each vendor from 0 to 100, where higher is better: the docs band 0 to 25 as Critical, 26 to 50 High, 51 to 75 Medium and 76 to 100 Low risk. The score draws on vulnerability risk (critical and high counts, EPSS and known exploited vulnerabilities), compliance risk (EO 14028 compliance, missing fields, SBOM age, format validity), component risk (for example abandoned packages and license compliance) and operational risk (response time, update frequency, incident history, contract compliance). Use it to decide which maker to call first.
13. Generate an assessment report. Select vendors and click Generate Report for a summary, score breakdown, vulnerability details, compliance gaps and recommendations; comparative analysis puts makers side by side for renewal. To brief leadership, see a one-page summary of a supplier SBOM for an executive sponsor.
14. Document accepted risk. Review the finding, click Accept Risk, give the business justification, set a review date and obtain approvals. Put the compensating control and clinical sign-off in the justification. Remediation tracking holds requested fixes, maker commitments and verification status.
15. Bring in the maker's VEX. CSAF and VEX upload (GA) ingests the documents makers send. Safeguard does not write or sign VEX for the manufacturer.

Monitoring after go-live

16. Configure alerts. Under Settings › Monitoring the docs list Critical Vuln (new critical CVE), Exploited (CVE added to CISA KEV), Risk Change (score drops below a threshold) and SBOM Expiry (SBOM older than a threshold). SBOM Expiry is the calendar backstop described earlier.
17. Route alerts and set cadence. Alerts go to email, Slack, Microsoft Teams, PagerDuty or a custom webhook; send Exploited alerts to the people who can change network access. Re-analysis runs daily (for critical vendors), weekly, monthly or quarterly, with re-assessment on new disclosures, major version updates, contract renewals and incidents. Scheduled reports and PDF or Excel exports feed committee packs.

Which part of the job each side owns

What the hospital still owns

• The device inventory. Which devices are installed, where, at which software version and on which segment. The SBOM says what a release contains; the inventory says where it runs.
• Network controls. Segmentation, access lists, firewall rules and remote access paths.
• The clinical risk decision. Whether a device stays in service with a known vulnerability is a patient safety call for clinical leadership, informed by clinical engineering and security.
• Maintenance windows. Scheduling downtime for a validated fix and confirming the device works afterwards.
• The contract. No tool can create rights you did not negotiate.

What Safeguard does not do

• It cannot patch, update or reconfigure a medical device. Every change to device software comes from the manufacturer through its validated process. Safeguard's autonomous remediation and Gold apply to software you build, not to a maker's device image.
• It only knows what the maker's SBOM declares. Safeguard analyses the SBOM it receives. If the maker leaves out the operating system or a commercial runtime, Safeguard cannot see it. Coverage gaps need a conversation with the maker.
• It does not discover devices on your network. TPRM tracks vendors, products and SBOMs. It does not scan the clinical network, fingerprint devices or tell you which serial number runs which release. You need a device inventory for that.
• Its vendor score is a prioritisation aid, not a clinical risk assessment. The 0 to 100 score helps you decide which maker to chase first. It does not assess patient harm, and it should not decide whether a device stays in service.
• It does not check FDA's extra SBOM fields for you. The documented validation covers format, required fields and EO 14028. Level of support and end-of-support date need your own review.
• It does not write or sign VEX for a manufacturer. It ingests CSAF and VEX documents that makers send. A "not affected" claim is the maker's statement, and the evidence behind it stays with them.
• It does not give regulatory or legal advice. It does not file anything with FDA, interpret your contract or decide what your obligations are.

Common mistakes

• Accepting "SBOM available on request." Without format, version, field and update terms you will get a PDF table for the wrong release.
• Reviewing once, at purchase. Every update needs a new SBOM, and every KEV addition needs a re-match.
• Matching by name only. Match on identifiers and exact versions, then confirm with the maker.
• Ranking by CVSS alone. A critical score on an unreachable component can matter less than a medium one on an exposed service. Use KEV, exposure and EPSS together.
• Skipping the operating system. It is often the largest component and the likeliest to lose support during the device's life.
• Isolating without a clinical owner. A rule that blocks results reaching the record system is a patient safety issue of its own.
• Losing the compensating control. Controls recorded in a closed ticket disappear in the next network change.

FAQ

Is a medical device manufacturer required to give a hospital an SBOM?

Section 524B requires an SBOM for FDA, not for each customer. FDA's guidance recommends making SBOM information available to users, machine-readable and continuously. The reliable route for a hospital is the purchase contract.

What format should a medical device SBOM be in?

SPDX or CycloneDX, machine-readable, such as JSON. CISA's 2026 minimum elements name these two and dropped SWID tags. A PDF table cannot be matched automatically.

What is the difference between the NTIA minimum elements and CISA's 2026 minimum elements?

The 2026 document replaces the 2021 NTIA elements. It renames Supplier Name to Component Producer, adds hashes, licenses, an author signature and SBOM version, replaces Depth with Coverage, and asks authors to mark unknown or withheld data. FDA's guidance still cites the 2021 framing.

What extra SBOM fields does FDA ask device makers for?

For each component, the level of support from its maker (actively maintained, no longer maintained, abandoned) and the end-of-support date. FDA allows these in the SBOM or in a separate addendum.

What should a hospital do when a KEV vulnerability affects a medical device?

Confirm the match, find every installed unit, assess exposure, ask the maker for a written status, isolate if exposure is plausible, and record the compensating control with a clinical owner and review date.

Can a hospital patch a medical device itself?

Generally not without the manufacturer, because changes outside the maker's validated process can affect safety and regulatory status. MC2 clause 32 covers who patches when only the supplier can.

How often should a medical device SBOM be updated?

With every software version or update and every correction, per CISA's 2026 Frequency practice, plus a calendar backstop for critical devices.

What is a compensating control for a medical device?

FDA's 2016 postmarket guidance defines it as a safeguard or countermeasure deployed by the user in place of, or in the absence of, controls designed in by the manufacturer. Network segmentation and removing a device's network access are common examples.

Where open source fixes still apply

A hospital cannot fork a manufacturer's device firmware, so the options below do not apply to the devices themselves. They do apply to the open source in software your own teams build and run alongside those devices, such as integration engines, clinical apps and internal portals.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo connects Claude to the Safeguard MCP server (GA) with OAuth and shows how you choose which tools Claude can use. For device SBOM work, an analyst can ask plain-language questions about the components and vulnerabilities Safeguard holds while preparing questions for a maker.

Click through it at your own pace, or open it full screen.

The second demo is a real session in the Safeguard desktop app: you pick a folder, Approve or Deny each command and file edit, and it ends with a dependency upgrade done and tests passing. That flow applies to software your hospital builds, not to a maker's device.

Click through it at your own pace, or open it full screen.

To try it on your own estate, download Safeguard at safeguard.sh/download and read the TPRM and Portal guides at docs.safeguard.sh/docs.

Quick check

Sources

• 21 U.S.C. 360n-2, Ensuring cybersecurity of devices (FD&C Act section 524B), Legal Information Institute
• FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued 3 February 2026 (archived copy)
• FDA, Postmarket Management of Cybersecurity in Medical Devices, issued 28 December 2016 (archived copy)
• Health Sector Coordinating Council, Model Contract-Language for Medtech Cybersecurity (MC2)
• Health Sector Coordinating Council, MC2 full text, March 2022 (PDF)
• HHS, HPH Cybersecurity Performance Goals (archived December 2024)
• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM), 29 July 2026
• CISA, 2026 Minimum Elements for a Software Bill of Materials (PDF)
• CISA, Software Bill of Materials (SBOM) resources
• NTIA, The Minimum Elements For a Software Bill of Materials (SBOM), 12 July 2021
• CISA, Known Exploited Vulnerabilities Catalog
• CISA, Known Exploited Vulnerabilities Catalog JSON feed
• CISA, BOD 26-04: Prioritizing Security Updates Based on Risk, 10 June 2026
• CISA, BOD 22-01 (revoked)
• CISA, Minimum Requirements for Vulnerability Exploitability eXchange (VEX), April 2023
• Safeguard docs, Third Party Risk Manager
• Safeguard docs, SBOM Requests
• Safeguard docs, Risk Assessment
• Safeguard docs, Monitoring
• Safeguard docs, Find & Review SBOMs
• Safeguard docs home
• Safeguard download page

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.