Why Robots Trip Security Review
An autonomous mobile robot is an unusual device from a security perspective. It is a networked computer with cameras and microphones that moves under its own control through clinical space, holds a persistent connection to a vendor cloud, and receives software updates from outside the organisation. Almost every element of that description raises a legitimate question, and most hospital security teams have no prior template for answering them.
The result is that robot projects stall in review, often for months, not because the answers are bad but because nobody assembled them in advance. This guide is the set of questions we have seen asked most often, and what a satisfactory answer looks like.
What a Service Robot Actually Collects
Be precise here, because vague answers create suspicion that specific answers dispel. A transport or service robot typically generates four kinds of data.
- Navigation data. Maps of the environment, position history, and route logs. This describes your building, not your patients, but it is genuinely sensitive in its own right and should be treated that way.
- Sensor data. Depth camera and lidar streams used for obstacle avoidance. The important question is whether these are processed on the device and discarded, or transmitted and retained.
- Operational telemetry. Battery state, fault codes, task completion, utilisation. Low sensitivity, high value for service.
- Task metadata. What was moved, from where, to where, and when. This is where the risk of incidental protected health information lives, particularly if task names carry patient or room identifiers.
That last category deserves attention in the design of the deployment rather than in the security questionnaire. Task naming conventions that avoid patient identifiers remove an entire class of problem before it exists.
Remote Access and Who Holds the Keys
Nearly every service robot supports some form of vendor remote access, for diagnostics, teleoperation, or support. This is the question that most often decides whether a deployment is approved.
Good answers share several properties. Access is explicitly granted rather than always on. Sessions are logged, attributable to a named individual, and visible to the customer. Teleoperation, if supported, requires local acknowledgement. There is a documented way for the customer to revoke access unilaterally and immediately.
The question behind the question is jurisdictional: can any party outside the United States reach this machine or its data? For healthcare systems this is increasingly a governance requirement rather than a preference, and it has moved from a nice-to-have to a procurement condition over the past year as regulatory attention on connected device supply chains has intensified.
Ask it directly: who can push code to this robot, who can view its camera feed, where are those people located, and what log will show me that they did?
Firmware, Signing, and the Update Chain
A robot that accepts unsigned firmware from an unauthenticated source is an unacceptable device on a clinical network, and there is no configuration that fixes it. The update chain should be described concretely: builds are cryptographically signed, the device validates the signature before applying, signing keys are held by an identified party under stated controls, and update delivery uses authenticated transport.
Two further points matter operationally. Updates should be schedulable rather than arriving unannounced during a busy service period. And there should be a documented rollback path, because the update that breaks something at 2am is the one you will remember.
Where the signing authority sits is a question worth asking separately from where the robot was built. A machine assembled domestically whose firmware is signed and delivered from elsewhere has not resolved the concern that the question was designed to address.
Segmentation and Least Privilege
Robots belong on a dedicated device VLAN with an explicit egress allow-list rather than on a general IoT segment with permissive rules. Ask the vendor for the exact hostnames and ports required and give that list to your network team before installation rather than during it.
Least privilege applies inside the building too. A transport robot that integrates with elevators and doors needs access to those controllers and nothing else. If integration is achieved by placing the robot on a flat network with clinical systems, that is a design decision worth challenging.
Where clinical system integration is genuinely required, prefer a brokered pattern in which the robot talks to a local integration service that talks to the clinical system, rather than direct robot-to-EHR connectivity. It gives you a single auditable point of control and a much simpler story for review.
The Security Questionnaire That Works
If you take one thing from this guide, take this list and send it to the vendor before the demo rather than after the decision.
- What data does the robot collect, what is retained, for how long, and where is it stored?
- Is any of it capable of containing protected health information, and what controls prevent that?
- Who can access the robot remotely, from what locations, and how is that logged and revoked?
- Is firmware signed, who holds the signing keys, and can updates be scheduled and rolled back?
- What outbound network access is required, expressed as hostnames and ports?
- What happens to the robot and its data if the contract ends?
- Has the platform been assessed against a recognised framework, and can you share the result?
A vendor who answers these crisply has thought about the problem. A vendor who deflects has told you something useful about how the product was built.