Notifications
Clear all
Topic starter
18/08/2026 3:00 pm
TL;DR: Medical device security now depends on governing open source components, SBOM accuracy, vulnerability response, and lifecycle monitoring, because FDA 524B, FDA premarket guidance, and EU CRA all push cybersecurity into the compliance core, according to Kusari. The compliance burden is no longer separable from software supply chain control, and device teams need traceable ownership, patch discipline, and evidence-ready monitoring.
NHIMG editorial — based on content published by Kusari: Medical Device Cybersecurity & FDA 524B Compliance
Questions worth separating out
Q: How should medical device teams govern open source components across the product lifecycle?
A: They should treat each component as a governed asset with ownership, approval history, version tracking, and retirement criteria.
Q: What breaks when SBOM data is incomplete in regulated devices?
A: Incomplete SBOM data breaks vulnerability assessment, patch prioritisation, and audit defensibility.
Q: Why do medical devices need continuous cybersecurity monitoring after launch?
A: Because new vulnerabilities, dependency changes, and license issues appear after deployment, while the device may stay in the field for years.
Practitioner guidance
- Create a governed SBOM source of truth Maintain a complete software bill of materials for each device build, including transitive dependencies, version history, and component ownership.
- Tie vulnerability triage to device lifecycle status Map each disclosed vulnerability to the specific device model, software version, deployment stage, and compensating control.
- Embed license and compliance checks into the SDLC Scan dependencies for security defects and license obligations before release gates approve firmware or software builds.
What's in the full article
Kusari's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step SBOM generation workflow for regulated device builds and submissions
- Automated vulnerability detection and remediation workflow details for device software components
- License compliance monitoring approach for reducing operational and legal exposure
- Continuous SDLC monitoring checks that support pre-market and postmarket evidence
👉 Read Kusari's guide on medical device cybersecurity and FDA 524B compliance →
Medical device cybersecurity and SBOM governance: what teams need?
Explore further
18/08/2026 3:40 pm
SBOM governance is now a compliance control, not a documentation exercise. Once medical devices rely on open source software, the inventory of embedded components becomes part of the control environment. If teams cannot prove what is inside the product, they cannot consistently prove whether a vulnerability or license issue has been contained. Practitioners should treat SBOM quality as evidence of governance maturity, not as a static artefact.
A question worth separating out:
Q: Who is accountable when a regulated product ships with weak security controls?
A: Accountability follows the role that places the product on the market, which can include manufacturers, importers, or distributors depending on the situation. Rebranding can shift legal responsibility downstream, so organisations should not assume vendor labels alone determine who answers to regulators.
👉 Read our full editorial: Medical device cybersecurity hinges on software supply chain governance
