Hospital robots: what defenders should inspect first

Defenders should inspect five things first on hospital and surgical robots: what exists and where, how each unit reaches the network, who can connect remotely, how software gets updated, and what evidence the vendor will share. Start with those before any scanning, and involve clinical engineering from the first meeting.

Clinical safety comes before security testing. Never run active scans or change settings on a device in clinical use without clinical engineering approval. This post is a planning order, not a test procedure, and it names no incident.

1. What exists and where?

Build the asset list with biomedical or clinical engineering, since they usually know equipment better than IT does. Record model, location, software versions, owner, and the date support ends. A robot not on the list cannot be patched, segmented or monitored.

NIST SP 800-82 Revision 3 defines operational technology as programmable systems that monitor or control physical processes and equipment, and treats safety and reliability as constraints on security work. Use that frame: the device has a job, and your controls must not break it.

2. How does it reach the network?

For each unit, note wired and wireless links, the segment it sits on, and what it can talk to. A robot that only needs to reach its own console and a vendor service should not reach the guest wireless or the file server. Write down intended paths, then compare with firewall rules and observed traffic from passive monitoring.

3. Who can connect remotely?

Vendor support often means remote access. List every such path: VPN, remote desktop, a modem, a cloud service. For each, record who approves a session, whether it is logged, and whether credentials are shared. Shared vendor accounts with no logging are worth checking first.

4. How do updates arrive?

Ask how the device gets software changes, who tests them, and who installs them. Find out whether updates are signed and whether the hospital or the vendor controls timing. If a component flaw is announced tomorrow, you want to know the path from fix to device and the number of days it usually takes.

5. What will the vendor show you?

Ask for a software bill of materials, a vulnerability disclosure contact, a statement of the support period, and a description of how the vendor handles component flaws. CISA describes an SBOM as a list of the ingredients that make up software components. The FDA's final premarket cybersecurity guidance, which the FDA page dates February 2026, covers what manufacturers document for devices with cybersecurity risk, so vendors in scope of it should have material to share. We did not read the full text, so confirm what applies.

What do you do with the answers?

Rank findings by two questions: how bad would it be for a patient if this failed, and how easy is the path. A remote access path with no logging on a surgical unit ranks above a stale document on a rarely used device.

Software you build, such as integration code or hospital apps, can be scanned with normal application security tools. Safeguard can generate SBOMs and findings for that code. It cannot inspect vendor firmware you do not have, so the vendor request in step five matters.

What to do

1. Build the asset list with clinical engineering and record support end dates.
2. Map network paths and compare them with firewall rules.
3. List and log every remote access path, and end shared accounts.
4. Document the update path for each device family.
5. Send each vendor a standard request for an SBOM and disclosure process.
6. Agree safe testing rules with clinical engineering before any technical checks.

Quick check

Sources

• NIST SP 800-82 Revision 3
• CISA: Software Bill of Materials
• FDA: Cybersecurity in Medical Devices, premarket submissions guidance

Last reviewed: 18 October 2026.