In September 2023, the FDA finalized guidance that changed how medical devices reach market: cybersecurity is no longer a nice-to-have appendix to a 510(k) or PMA submission, it is a gating requirement. Since October 1, 2023, the agency has been refusing to accept ("RTA") premarket submissions for "cyber devices" that omit a software bill of materials, a vulnerability management plan, and evidence of a secure software development lifecycle. This follows Section 524B of the Food, Drug, and Cosmetic Act, added by the Consolidated Appropriations Act of 2023. For manufacturers, this turned software supply chain security from an engineering concern into a regulatory one, with FDA reviewers now reading SBOMs the way they once read sterilization validation reports. Incumbent tools built for enterprise IT license compliance, like Black Duck, are increasingly being asked to do a job they weren't designed for: satisfying a regulator, not just a legal department. Here is what the requirements actually say, what's gone wrong in the field, and where the tooling gap sits.
What does the FDA actually require for medical device cybersecurity today?
The FDA requires four concrete things for any "cyber device" premarket submission: a plan to monitor, identify, and disclose vulnerabilities post-market; a process to provide reasonable assurance the device is cyber-secure; a software bill of materials including third-party and open-source components; and evidence the manufacturer will make updates and patches available. This comes from the final guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," which superseded the 2018 draft and 2022 update. A "cyber device" is defined broadly: any device with software, the ability to connect to the internet, and technological characteristics that could be vulnerable to cybersecurity threats — which captures most connected infusion pumps, imaging systems, continuous glucose monitors, and implantables sold today. The FDA has publicly stated it issued dozens of RTA holds in the first year alone for submissions with incomplete or missing cybersecurity documentation, and device makers report submission delays measured in months when SBOM data has to be reconstructed after the fact rather than generated during development.
Why does the SBOM requirement hit medical device makers harder than other software vendors?
It hits harder because medical device software has a much longer field life and a much slower patch cycle than typical enterprise software, often 10-15 years versus the 1-3 year refresh cycle common in IT. A component that was safe to ship in 2015 can carry a critical CVE discovered in 2024, and the manufacturer needs to know, without re-deriving it from source, exactly which devices in the field contain that component. This is precisely what happened with the Urgent/11 vulnerability set disclosed in 2019: a flaw in the IPnet TCP/IP stack bundled inside Wind River VxWorks affected an estimated 200 million devices worldwide, including infusion pumps and patient monitors, and manufacturers without accurate component inventories spent months just figuring out which of their products were exposed. NTIA's minimum elements for an SBOM, published in 2021 and referenced directly in FDA guidance, require component name, version, supplier, and dependency relationships — data that has to be generated at build time, not reconstructed later through binary scanning. Tools built primarily for open-source license auditing, Black Duck's original niche from its Protecode and Palamida lineage, capture component identity but were not built around the depth of transitive dependency and build-provenance data that a 15-year device lifecycle now demands.
What has actually gone wrong when device makers lacked this visibility?
The clearest example is the 2017 Abbott (formerly St. Jude Medical) pacemaker recall, where the FDA issued a firmware update for roughly 465,000 implanted cardiac devices after researchers demonstrated a remote attacker could deplete the battery or alter pacing. Around the same time, WannaCry disrupted the UK's National Health Service, taking an estimated 70,000 devices, including MRI scanners and blood-storage refrigerators, offline because they ran unpatched, unsupported Windows versions nobody had inventoried as a fleet-wide risk. More recently, in April 2023, CISA and the FDA jointly disclosed CVE-2023-1968 and CVE-2023-1966 in Illumina's iSeq, MiniSeq, NextSeq, and NovaSeq genomic sequencing instruments used in clinical diagnostics, vulnerabilities severe enough (CVSS 10.0 and 7.4) that the FDA issued an unusual public safety communication. In every one of these cases, the failure wasn't a lack of security testing on the device's own code, it was the absence of accurate, current knowledge of third-party and firmware-level components sitting inside a device that shipped years earlier.
Where does Black Duck fall short for medical device manufacturers specifically?
Black Duck's core strength, deep open-source license and component detection, was built for software companies auditing codebases for legal risk, not for regulated hardware manufacturers producing auditable evidence for the FDA. Its scanning architecture, inherited through the Coverity, Protecode, and Black Duck (Synopsys) acquisitions and now operating as an independent company since its 2024 spin-off and 2025 sale to a private equity buyer, splits SAST (Coverity) and SCA (Black Duck SCA) into separate products with separate workflows, which means device teams often stitch together two license agreements and two data models to answer one regulatory question: "what's in this device, and is any of it vulnerable?" Full codebase scans are frequently reported by users as slow enough to break CI feedback loops, pushing teams toward scheduled nightly scans rather than the build-time SBOM generation the FDA guidance implies. For embedded and firmware-heavy medical devices specifically, binary and firmware composition analysis has historically been a smaller, bolt-on capability rather than a first-class workflow, which matters because a huge share of real-world device vulnerabilities, including Urgent/11, live in firmware and RTOS layers, not application code.
What does IEC 62304 add on top of the FDA's premarket cybersecurity guidance?
IEC 62304 requires manufacturers to classify software by safety class (A, B, or C based on potential harm) and maintain full traceability from requirements through design, implementation, verification, and change control for the life of the product. This standard predates the FDA's 2023 cybersecurity guidance by nearly two decades (first published in 2006, amended in 2015) but the two now overlap: an SBOM generated for FDA premarket review has to line up with the same component and version records auditors expect under IEC 62304's configuration management clause, and a vulnerability found post-market has to run through the same change-control and risk-classification process, not a separate ad hoc patch process. Manufacturers audited by notified bodies in the EU under the Medical Device Regulation (MDR) face a similar dual requirement, since MDR's Annex I, Section 17.2 now explicitly references state-of-the-art cybersecurity practice. A tool that generates a component inventory for a legal or license report doesn't automatically produce the audit trail a Class III device needs to survive an IEC 62304 gap assessment; the data has to be structured for regulatory traceability from day one, not retrofitted.
How Safeguard Helps
Safeguard was built around the assumption that software supply chain data has to serve a compliance audit, not just a security dashboard. For medical device manufacturers, that means SBOM generation happens continuously as part of the build pipeline, producing NTIA-minimum-element, CycloneDX and SPDX-compatible output that stays current across a device's full field life, not a point-in-time scan that goes stale the moment a firmware update ships. Safeguard maps every third-party and open-source component, including firmware and RTOS-layer dependencies where risks like Urgent/11 actually live, directly against active CVE and KEV data, so a manufacturer can answer "which fielded devices contain this vulnerable component" in minutes rather than months. Because the same component and vulnerability data doubles as the evidentiary record for FDA premarket submissions and IEC 62304 traceability audits, teams stop maintaining separate spreadsheets for regulatory, security, and engineering audiences. Safeguard also generates attestations and provenance records aligned with the FDA's post-market monitoring and disclosure expectations, so when the next Illumina-style advisory drops, the question isn't "let's go find out if we're affected," it's already answered. For manufacturers evaluating a move off legacy SCA tooling, Safeguard's unified platform replaces the split SAST/SCA workflow with a single system built around the specific audit trail regulators, notified bodies, and hospital procurement teams are now asking for by name.