Notifications
Clear all
Topic starter
19/08/2026 3:40 pm
TL;DR: Medical device manufacturers are being pushed to treat SBOMs as a design-time security and compliance control, not a documentation afterthought, because about 96% of device software now depends on open source components and FDA requirements are tightening, according to Kusari. That shift makes software transparency, vulnerability correlation, and lifecycle accountability central to patient safety and regulatory readiness.
NHIMG editorial — based on content published by Kusari: SBOMs, medical device cybersecurity, and the move from static inventory to actionable intelligence
By the numbers:
- About 96% of medical device software leverages open source, creating a complex blend of proprietary and open source components.
Questions worth separating out
Q: How should medical device teams make SBOMs operational instead of treating them as paperwork?
A: SBOMs become operational when they are generated automatically, machine-readable, and continuously matched to vulnerability and exploitability data.
Q: Why do SBOMs matter so much for regulated medical devices?
A: They provide the evidence base for understanding what software is inside a device, which components are unsupported, and where known vulnerabilities may affect patient safety or product availability.
Q: What breaks when SBOMs are not kept current?
A: An outdated SBOM weakens vulnerability triage, supplier review, and incident response because it no longer reflects what is actually deployed.
Practitioner guidance
- Move SBOM review into premarket control gates Require SBOM completeness, component support status, and remediation evidence before design freeze or submission, not after release.
- Correlate SBOMs with CVE and VEX data continuously Automate matching so teams can distinguish theoretical exposure from confirmed exposure and prioritise devices with active exploitability or patient safety impact.
- Assign named owners for component risk decisions Make engineering, quality, regulatory, and security jointly accountable for each high-risk dependency so remediation timelines and mitigation choices are traceable.
What's in the full article
Kusari's full blog post covers the implementation detail this post intentionally leaves for the source:
- The FDA submission expectations for machine-readable SBOM content, including component origin, support status, and end-of-life data
- The practical workflow for correlating SBOMs with vulnerability databases and determining whether a device is actually exposed
- The cross-functional operating model that links engineering, quality, regulatory, and legal teams to software-risk decisions
- The process for sharing SBOM intelligence with hospitals and healthcare delivery organisations during vulnerability response
👉 Read Kusari's analysis of SBOM requirements for medtech cybersecurity and patient safety →
SBOMs in medical devices: what security teams need to do now?
Explore further
19/08/2026 4:19 pm
SBOMs are becoming a lifecycle governance control, not a compliance artifact. The article shows that component visibility only becomes meaningful when it is tied to ownership, exposure, and remediation. That is the same governance pattern identity teams know from credential and privilege lifecycle management, where inventory without action is not control. For medtech, the practitioner conclusion is simple: treat SBOMs as operational evidence, not filing material.
A question worth separating out:
Q: Who is accountable when a medical device cyber issue affects patient safety?
A: Accountability sits with the manufacturer for ensuring cybersecurity does not compromise clinical performance, but healthcare operators also need ownership for deployment, monitoring, and maintenance. The practical question is not who caused the weakness alone, but who controls the patch path, the risk decision, and the response when patient harm becomes plausible.
👉 Read our full editorial: SBOMs are becoming a design-time control for medtech cybersecurity
