Turning SBOMs into Real Risk Reduction in Healthcare

Webinar Summary

SBOM readiness in healthcare isn't just a compliance exercise, it's a patient safety issue. This webinar opens with the scale of the problem: 99% of hospitals are running at least one connected device with a known, actively exploited vulnerability today, and healthcare has held the highest average data breach cost of any industry for fourteen consecutive years. More than 75% of the software inside a typical medical device is third-party or open-source, and the manufacturer carries the risk for all of it. Without an SBOM, identifying which deployed devices are affected by a newly published vulnerability can take weeks instead of hours. The session speaks to two audiences directly: medical device manufacturers responsible for generating and maintaining SBOMs, and hospital and healthcare delivery teams receiving them and deciding what to do next.

It then separates binding law from guidance across major markets. In the US, Section 524B of the FD&C Act makes SBOM generation, coordinated vulnerability disclosure, and post-market monitoring statutory requirements for connected devices, reinforced by the FDA's February 2026 guidance. In the EU, the Cyber Resilience Act currently exempts medical devices under MDR and IVDR, with the narrow exception of wearable and body-worn devices, while NIS2 already requires hospitals to assess supplier cybersecurity. Japan, the UK, Australia, and Canada each add their own requirements or guidance, and IMDRF N73 is presented as the common thread nearly every major regulator has adopted, building to it alongside the FDA's guidance is framed as one workflow that covers most of what any market expects. The webinar's central argument is that the SBOM lifecycle between manufacturers and hospitals is broken today: manufacturers typically file an SBOM once for a regulatory submission, and hospitals receive it, if at all, as an unusable PDF. Both FDA guidance and EU NIS2 are now pushing both sides to fix that handoff at the same time. From there it walks through a five-step process for turning a published vulnerability into a patient safety decision, a full phased compliance roadmap for each audience, sixteen documented pitfalls, and how Keysight SBOM Manager's three modules, Generator, Studio, and Consumer, close those gaps.

Key Highlights from the Webinar

• Why this is a patient safety issue, not just a compliance exercise: Understand the scale of the problem: hospitals running devices with known exploited vulnerabilities, average breach costs, and why over 75% of typical device software is third-party or open-source.
• What's actually required versus recommended, and the one global baseline: See which obligations are statutory law today, led by the US FDA, versus guidance or still-proposed, across the US, EU, UK, Japan, Australia, and Canada, and why IMDRF N73 plus FDA guidance is presented as the closest thing to a single global baseline.
• Why the manufacturer-to-hospital handoff is broken today, and what's forcing a fix: Understand the typical failure point, an SBOM filed once with a regulator and never usably shared with hospitals, and why FDA guidance and EU NIS2 are now pushing both sides to close that gap at the same time.
• A five-step process from a published CVE to a patient safety decision: Walk through generating a complete SBOM, cross-referencing CISA KEV, assessing exploitability with VEX, triaging by clinical impact rather than CVSS score alone, and remediating through a coordinated disclosure process.
• A phased compliance roadmap, for manufacturers and for hospitals: Five ordered phases on each side: for manufacturers, from initial inventory through QMS integration to continuous SBOM sharing; for hospitals, from procurement contract terms through independent verification to continuous monitoring.
• Sixteen documented pitfalls, eight per side, that trigger deficiency letters or expose patients: See the specific, recurring mistakes on both sides, from stale or PDF-only SBOMs to annual-only vendor reviews and diffuse ownership.
• Binary-based SBOM generation for legacy and acquired devices: Learn how analyzing the actual shipped firmware, rather than relying on source code or build manifests, closes the completeness gap and can determine directly whether a vulnerability is even present in a specific build.
• Continuous monitoring, noise reduction, and operational agility tracking for manufacturers: See how prioritizing authoritative sources over the NVD, excluding already-patched CVEs, tracking CISA KEV due dates, and rating every component's operational agility cuts noises and manual effort.
• Turning inconsistent vendor SBOMs into ward-level risk intelligence for hospitals: Understand how automatically scoring, validating, and mapping incoming SBOMs down to a specific ward, floor, or room replaces the shared-drive-and-annual-questionnaire model.
• Concrete actions for this week: Get the specific first steps recommended for both manufacturer and hospital teams.

Download the SBOMs in Healthcare webinar slides.

Frequently Asked Questions

1. What is an SBOM, and why does it matter specifically for medical devices?

An SBOM (Software Bill of Materials) is a machine-readable inventory of every software component inside a product, comparable to an ingredient label for software. The most widely adopted baseline, the NTIA Minimum Elements, expects a component name, version, supplier, a unique identifier (CPE or PURL), dependency relationships, and an author and timestamp. This matters more for medical devices than most product categories: more than 75% of the software inside a typical device is third-party or open-source, and the manufacturer carries the risk for all of it. Without an SBOM, identifying which devices are affected after a new vulnerability is published can take weeks instead of hours.

2. Does the EU Cyber Resilience Act (CRA) apply to medical devices?

Not yet, with one narrow exception. Medical devices regulated under the EU's MDR and IVDR are currently exempt from the CRA's product requirements, and wearable or body-worn devices are the one category that falls outside that exemption and must meet CRA requirements today. A proposed MDR/IVDR revision published in December 2025 would remove the broader exemption and add explicit SBOM and ENISA reporting obligations, but it is still working through the EU's ordinary legislative procedure and is not expected to take effect before 2027. In the meantime, EU NIS2 already applies: it doesn't mandate a product SBOM, but it does require device manufacturers to govern IT and OT security as an organization, and it requires hospitals, as essential entities, to assess the cybersecurity of their device suppliers.

3. What does the FDA actually require for medical device SBOMs?

Under Section 524B of the FD&C Act, a statutory requirement rather than guidance, manufacturers of connected cyber devices (Wi-Fi, Bluetooth, or any other connection) must provide a machine-readable SBOM, maintain a coordinated vulnerability disclosure process, and monitor for and address vulnerabilities post-market. The FDA's February 3, 2026 final guidance builds on the NTIA Minimum Elements and adds further recommendations: a documented support life declaration, end-of-support dates, and cross-referencing components against the CISA Known Exploited Vulnerabilities (KEV) catalog. A PDF does not satisfy this requirement. Only a structured, machine-readable format such as CycloneDX or SPDX can be ingested by monitoring tools and matched automatically against vulnerability databases.

4. What about other major markets, is there a common baseline to build to?

Beyond the US and EU, most major markets currently treat SBOMs as guidance rather than an explicit mandate, though the direction of travel is the same everywhere. Japan's JIS T 81001-5-1 has been mandatory for connected medical devices since April 2023, and IEC 62304 is required for software lifecycle management, but SBOM itself isn't an explicit PMDA submission element. The UK has no standalone SBOM mandate, but cyber-related patches go through a formal Field Safety Corrective Action process reviewed by MHRA, and serious cyber incidents must be reported within 15 days generally, 2 days for the most urgent threats, and 10 days where the incident results in death or serious deterioration. Australia's TGA states manufacturers "should" maintain an SBOM as guidance, and Canada's pre-market guidance dates from 2019, predating SBOMs entirely. The common thread across all of them, adopted by the FDA, EU MDR, MHRA, PMDA, TGA, Health Canada, and Singapore's HSA, is IMDRF N73. Building to IMDRF N73 alongside the FDA's February 2026 guidance is presented as covering the large majority of what any regulator in the world currently expects: one workflow across multiple markets.

5. What do CVSS, the NVD, CISA KEV, and VEX actually mean, and how do they differ?

CVSS is a 0 to 10 severity score, a rating of how bad a vulnerability could theoretically be, not evidence that it actually puts your device at risk (Log4Shell scored a 10, but a device that never uses the affected networking feature may not be exploitable at all). The NVD (National Vulnerability Database) is the US government's full catalog of more than 200,000 known CVEs, most of which are not being actively exploited, useful for awareness but not for prioritization on its own. CISA KEV (Known Exploited Vulnerabilities) is a much smaller, curated list of vulnerabilities being actively exploited right now; the FDA recommends cross-referencing every SBOM against it, and anything on that list is an immediate priority rather than something for the next review cycle. VEX (Vulnerability Exploitability eXchange) is the manufacturer's own document answering, for each vulnerability, whether it actually affects a specific device in deployment, with one of four statuses: Not Affected, Affected, Fixed, or Under Investigation. Together, these move a team from a raw CVE count to the small number of vulnerabilities that are both exploited in the wild and actually present in the product.

6. Why is the handoff between manufacturers and hospitals broken today, and what's changing?

In principle, the SBOM lifecycle should be a continuous loop: manufacturers generate and monitor, hospitals receive and act, and both sides coordinate on response. In practice, it breaks at the same point almost every time, the handoff itself. The typical pattern is that a manufacturer generates an SBOM for an FDA submission, the regulator reviews it, and that's the last anyone sees of it; hospitals deploying the device never receive it. Even when an SBOM is shared, which is more common now but still far from universal, it usually arrives as a PDF attached to an email, gets forwarded to a shared drive, and is never touched again, a compliance posture, not a security posture. What makes this moment significant is that both sides are now being pushed to fix it at once: FDA guidance expects manufacturers to make SBOMs continuously available to their users rather than filing them once, and EU NIS2 requires hospitals, as essential entities, to continuously assess supplier cybersecurity. A compliance dependency is forming, manufacturers must publish and hospitals must use, and closing that gap is what the rest of the roadmap addresses.

7. What does the five-step process from a published CVE to a patient safety decision look like?

Step 1, generate a complete SBOM: automated scanning is the starting point, but completeness means the full dependency chain, including transitive dependencies, with any unresolvable gap formally documented (what was attempted, why it remains unresolved, the risk classification, and compensating controls) rather than left silent; a documented gap is an acceptable regulatory position, a silent one is not. Step 2, cross-reference known vulnerabilities: check every component against multiple sources, especially CISA KEV rather than the NVD alone, since a KEV hit needs attention today, not at the next monthly review. Step 3, assess exploitability and issue VEX: a high CVSS score doesn't mean a device is at risk, what matters is whether the vulnerable code is actually reachable in that specific deployment. Step 4, triage by patient safety impact, not CVSS alone: a CVSS 9.8 in a non-networked display is not the same risk as a CVSS 7.0 in an infusion pump's control software, and under QMSR, known vulnerabilities are treated as reasonably foreseeable failure modes, handled through the same ISO 13485 risk management process as any other design hazard. Step 5, remediate and disclose: this runs through the manufacturer's CVD process; because revalidation after a fix typically takes six to twelve months, compensating controls communicated to hospitals immediately are the practical protection in the meantime.

8. What must manufacturers do when a vulnerability is actively exploited?

Coordinated Vulnerability Disclosure (CVD), the formal process of receiving, triaging, fixing, and responsibly disclosing a vulnerability, is a statutory requirement for manufacturers under Section 524B(b)(1), not a recommendation. In practice that means having named owners, defined triage timelines, and a tested notification workflow in place before a vulnerability is found, not after. This is distinct from the Secure Product Development Framework (SPDF), an FDA-encouraged but not mandatory approach to building security in from the design stage onward: CVD is what happens after a vulnerability surfaces, SPDF is about reducing how often one does. Because device revalidation after a fix typically takes six to twelve months, manufacturers are also expected to communicate compensating controls to affected hospitals immediately, well before a patch is available.

9. Why does binary-based SBOM generation matter for medical devices specifically?

Standard software composition analysis tools need source code or build manifests to generate an SBOM, and for legacy devices, acquired codebases, and third-party compiled firmware, neither may exist. Binary analysis instead examines the actual firmware image or compiled binary that ships in the device, which is often not identical to what the build system recorded. This uncovers hidden or undeclared dependencies that source-based tools miss entirely, and because the analysis happens at the binary level, it can also determine directly whether a known vulnerability's code is actually reachable in that specific build. Take the Linux kernel: a single kernel version can carry hundreds of associated CVEs, but the large majority relate to subsystems or drivers that were never compiled into a given device's build, so the analysis can generate an accurate Not Affected VEX statement automatically, rather than through manual review of every CVE.

10. What should a hospital do when it receives an SBOM from a device vendor?

Treat it as a starting point to verify, not a document to file away. Vendor SBOMs arrive in inconsistent formats and quality, and even ones labeled SPDX or CycloneDX often don't fully comply with the standard or are missing fields needed to act on them, so the first step is scoring completeness against the NTIA Minimum Elements rather than accepting it as is, for example being told a submission scores 42 out of 100 with the specific gaps listed, which gives real leverage in the next vendor conversation. From there, the SBOM should feed continuous, automated monitoring against CISA KEV and other feeds, mapped down to specific deployed device instances, so that when a vulnerability is added to CISA KEV, it's possible to know within seconds that, for example, a specific MRI scanner on a specific floor is affected, rather than spending days cross-referencing manually. For hospitals in the EU, this isn't just good practice: NIS2 requires essential entities to continuously assess supplier cybersecurity, and an annual questionnaire does not meet that bar.

11. What are the most common SBOM mistakes manufacturers make?

Eight recur often enough to be worth naming individually, since each is also a common trigger for an FDA deficiency letter: generating the SBOM once at submission time rather than maintaining it continuously, which makes it actively misleading as the product changes; missing transitive dependencies, where a large share of real-world vulnerabilities actually live; shipping PDF-only SBOMs that no monitoring tool can ingest; not cross-referencing against CISA KEV, which FDA explicitly recommends; keeping the SBOM outside the quality system when, post-QMSR, it should be ISO 13485 configuration management; having no documented CVD process, a statutory gap under Section 524B(b)(1), not just a best-practice one; skipping the Support Life declaration that FDA's guidance recommends in device labeling; and not sharing the SBOM with hospitals at all, when FDA guidance expects continuous availability to users, not a file that sits only with the regulator.

12. What are the most common SBOM mistakes hospitals make?

A matching eight on the receiving end: accepting a PDF SBOM from a vendor without pushing back, even though no tool can ingest it; letting SBOMs sit in a shared drive, where having the file isn't the same as monitoring it; relying on annual questionnaires as the primary assessment mechanism, which misses every vulnerability published in between; not requiring VEX update SLAs in vendor contracts, leaving vendors with no incentive to notify promptly; letting IT security and clinical engineering operate in silos, when the data usually sits with one team and the devices are managed by the other; skipping a Support Life check at procurement, which is how hospitals end up buying a device already approaching end-of-service; having no single named SBOM owner, so nobody's job is to act when an alert lands; and confusing which EU regulation applies, since the CRA currently exempts medical devices and NIS2 and MDR are the frameworks that actually govern hospitals today.

13. What does a full compliance roadmap look like for manufacturers and for hospitals?

Manufacturers: five ordered phases. Phase 1, inventory: run automated scanning across firmware, compiled code, and container images, then manually review what the tools missed (embedded binaries, custom integrations, third-party compiled libraries), documenting any unresolvable gaps with a formal risk rationale rather than leaving them undocumented. Phase 2, cross-reference and document: check every component against CISA KEV and the NVD, recording how each hit was found and the safety risk assessment applied, and begin drafting VEX statements for the highest-risk, most widely deployed products. Phase 3, quality system integration: under QMSR, the SBOM is ISO 13485 configuration management, so generation should happen automatically in CI/CD on every build, tied to design controls (Clause 7.3.7) and CAPA (Clause 8.5), not assembled manually before a submission deadline. Phase 4, coordinated vulnerability disclosure: establish a CVD process with defined triage timelines and response ownership, including the UK MHRA's 15-day serious incident trigger for global portfolios and a prepared ENISA workflow for the EU's proposed MDR obligation. Phase 5, transparency: add a Support Life declaration to device labeling and begin continuously publishing SBOMs to hospital customers, both expected under FDA guidance and increasingly needed for hospitals' own NIS2 obligations.

Hospitals: a matching five phases. Phase 1, procurement: update contract templates to require a machine-readable SBOM (CycloneDX or SPDX) and VEX update SLAs as contract conditions, which directly supports EU NIS2 supply-chain obligations. Phase 2, due diligence: check the Support Life label on every device before purchase. Phase 3, ownership: assign one named person, not a committee, as SBOM owner across IT security and clinical engineering. Phase 4, verification: ingest incoming SBOMs, score vendor SBOM quality, independently verify accuracy through binary analysis, and reject incomplete submissions rather than accepting them as filed. Phase 5, monitoring: set up continuous CVE and CISA KEV monitoring with automated alerts rather than annual reviews, mapping SBOMs to deployed device instances by risk and location.

14. What can manufacturers and hospitals do this week to get started?

For manufacturers: check whether existing SBOMs include transitive dependencies and proper component identifiers, since completeness is the foundation everything else depends on; cross-reference the component inventory against the CISA KEV catalog, which is public and free; and confirm a coordinated vulnerability disclosure process actually exists, with named owners and tested workflows, since this is a statutory obligation, not a future project. For hospitals: add a machine-readable SBOM (CycloneDX or SPDX) and VEX update service-level agreements to the procurement contract template; assign one named person, not a committee, as SBOM owner across IT security and clinical engineering; and move any SBOMs currently sitting in a shared drive into an active workflow. Even a manual cross-reference against CISA KEV is a meaningful first step.

15. Is there a way to try Keysight SBOM Manager before committing to anything?

Yes, in two ways. A live product demo shows binary analysis, continuous monitoring, VEX generation, SBOM quality scoring, and ward-level device mapping working together against a real device scenario. Alternatively, a free proof of concept allows sending in a firmware image, software image, or SBOM file: Keysight runs SBOM Manager against it and walks through a compliance-ready SBOM with full vulnerability intelligence. Fill out the free SBOM assessment form, and one of our experts will contact you.