In a surgical or hospital robot, software supply chain risk becomes physical safety risk because the software is part of how the machine senses, decides and moves. A vulnerable library, a tampered update or an unmaintained component can affect device behavior, which is why regulators now ask manufacturers about cybersecurity.
This post describes a general reasoning chain. We do not cite any incident, and we make no claim about any named device or manufacturer.
Why is this different from ordinary IT?
In an office system a flaw usually means data exposure or downtime. In a clinical device, availability and correct behavior are safety properties. A robot that freezes mid-procedure or behaves unpredictably is a clinical problem, not just an IT one.
Devices also live long. Hospital equipment may run for many years, and the software inside is a stack of components from different suppliers: an operating system, a real-time layer, communication libraries, imaging code, vendor drivers. The stack ages while new flaws keep arriving in its parts.
What do regulators say?
The US Food and Drug Administration publishes final guidance titled Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. The FDA page lists it as dated February 2026 and replacing the June 2025 version. It gives recommendations on device design, labeling and documentation for devices with cybersecurity risk, and covers the agency's recommendations on section 524B of the Federal Food, Drug, and Cosmetic Act for cyber devices.
We did not read the full document for this post. For what it asks of manufacturers on components and bills of materials, read the guidance itself. CISA describes a software bill of materials as a nested inventory, a list of the ingredients that make up software components, and treats it as a building block for supply chain risk management.
For the operating side, NIST SP 800-82 Revision 3 covers operational technology security with attention to safety and reliability, which applies in spirit to connected clinical equipment.
How does a supply chain flaw reach a patient?
Think of it as a chain with questions at each link.
- A component has a flaw. Someone publishes a vulnerability in a library the device includes.
- Nobody knows the device includes it. Without a bill of materials, the manufacturer and the hospital cannot tell quickly.
- No fix reaches the device. Updates in clinical settings need testing and scheduling, and some devices cannot be updated while in use.
- An attacker or a fault reaches the flaw. Network exposure, a maintenance laptop or a removable drive can be the path.
- Behavior changes. The result depends on the flaw, from nothing to a loss of function.
A break anywhere in this chain protects the patient. Visibility is the most common missing link.
What does Safeguard have to do with it?
Safeguard works on software you build or buy: SBOM generation and dependency inventory, vulnerability findings with reachability analysis so teams can tell which flaws their code can actually trigger, and policy gates in the pipeline. Manufacturers building device software can use that on their own code. Hospitals do not run Safeguard on a vendor's device firmware, but they can ask for the output.
What to do
- If you build devices, generate an SBOM for each release and keep it with the release record.
- If you buy devices, ask suppliers for an SBOM and a description of their update process.
- Keep an inventory of connected clinical equipment with software versions and support end dates.
- Separate clinical networks from general ones and limit remote access paths.
- Read the FDA guidance in full with your regulatory and engineering leads.
- Agree who is notified, and how fast, when a component flaw affects a device.
Quick check
Does an SBOM make a device safe?
No. It tells you what is inside so you can respond faster. Safety also needs secure design, testing and updates.
Does the FDA cover every market?
No. Other regions have their own rules. This post covers the FDA guidance we checked.
Sources
- FDA: Cybersecurity in Medical Devices, premarket submissions guidance
- CISA: Software Bill of Materials
- NIST SP 800-82 Revision 3
Last reviewed: 18 October 2026.
