The SBOM Era for Medical Devices: Life After FDA's Refuse-to-Accept
Medical devices became the first industry in the world to make the SBOM a hard market-entry requirement. Since March 2023, under the new Section 524B of federal law, the FDA applies a refuse-to-accept policy to connected medical devices: premarket submissions without an SBOM and cybersecurity documentation are returned before substantive review even begins. Not a guideline, not a recommendation — a hard check at the intake window. Exporters felt the temperature first, and the same logic is becoming the common language of regulators worldwide.
The regulatory picture across three jurisdictions
US FDA: Section 524B requires "cyber devices" to provide an SBOM, operate vulnerability monitoring and disclosure processes, and maintain security-update capability across the device lifecycle. The premarket cybersecurity guidance refines this into threat modeling, security-architecture documentation and penetration-testing evidence. China NMPA: the Guiding Principles for Cybersecurity Registration Review require a cybersecurity description document at registration, including an inventory and maintenance plan for off-the-shelf software (open-source components included) — in substance, an SBOM requirement in Chinese regulatory language, with a defined change-management path for post-market security updates. EU: medical devices are covered by the MDR/IVDR regime (hence exempt from the CRA, though the requirements converge), and MDCG cybersecurity guidance likewise demands management of third-party software component risk.
The common denominator is clear: regulators are not reviewing whether you use open source, but whether you demonstrably know what you use and how you maintain it over time.
Three dilemmas unique to medical
Ultra-long lifecycles and fossil components. An imaging system serves ten years and up, while the OS, middleware and open-source libraries in its stack will stop being maintained mid-service — hospitals running devices on legacy systems remain common. In this industry, abandoned components are not tech debt; they are a patient-safety exposure that compounds over time.
The fear of patching. Software changes can trigger regulatory change procedures, so manufacturers lean toward touching nothing. But the regulators' position has long been clear: routine cybersecurity patches generally do not constitute major changes requiring re-registration, and both the FDA and NMPA keep fast lanes open for security updates. The real bottleneck is rarely the regulation — it is the manufacturer's inability to determine quickly which models a vulnerability affects and what a patch changes. That is precisely the problem a component ledger solves.
Heavy reliance on procured software. Device makers integrate commercial SDKs, algorithm libraries and purchased modules at scale, with no source access as the norm. SBOM completeness therefore depends on binary composition analysis for the procured portion; an inventory covering only in-house code will not survive an FDA deficiency letter.
What to implement
First, SBOM in the registration pipeline: use an SCA platform to generate machine-readable SBOMs (SPDX/CycloneDX) across all software assets — in-house, off-the-shelf and procured binaries — auto-refreshed with every software version and referenced directly in submissions and annual reports; see our complete SBOM guide for format and depth choices. Second, vulnerability monitoring aligned to regulatory expectations: new intelligence auto-matched to marketed models, producing the triple regulators look for — affected-model list, risk assessment, remediation plan. Third, make the off-the-shelf maintenance plan real: NMPA's maintenance plan is not template paperwork; the review trend is to check consistency between the plan and actual version status — ledger-versus-plan divergence is a frequent deficiency finding.
The industry spent decades learning to manage physical risk through quality systems. Regulators are now replicating that systemic demand onto the software supply chain. The SBOM is only the ticket; what gets examined is the organizational capability to manage software risk continuously.