Service Robot Fleet Cybersecurity and Data Privacy, The IT Review Checklist
At a glance: A service robot is a camera, a microphone, a network node and a database that moves through your building. Most procurement processes treat it as a piece of cleaning equipment and skip the IT review entirely. This guide gives you the sensor-to-data inventory, the four attack surfaces, a segmentation map, and the checklist your security team needs to sign off.
What a Service Robot Actually Collects
The first thing an IT reviewer asks is what data leaves the building, and most vendor datasheets do not answer it. A commercial delivery or cleaning robot typically carries a 3D LiDAR, two to four depth or RGB cameras, wheel encoders, an IMU, a battery management system, and often an RFID reader for asset tracking or a microphone array for voice interaction. Each of those is a data source with a different privacy profile.
| Sensor | Data produced | Personal data? | Default retention | Where it lives |
|---|---|---|---|---|
| 3D LiDAR | Point cloud, geometric map | Usually no, but can capture silhouettes | Map persisted indefinitely | Robot local storage plus fleet cloud |
| RGB cameras | Color images and video | Yes, if any person is recognizable | Often 7-30 days rolling | Fleet cloud |
| Depth cameras | Depth frames, pose estimation | Yes, indirectly | Usually processed and discarded | Robot edge compute |
| Microphone array | Audio, wake-word events | Yes | Varies, frequently unspecified | Robot local, sometimes cloud |
| RFID reader | Tag identifiers and timestamps | Yes, if tags are issued to staff | Indefinite in logs | Fleet cloud |
| Battery and telemetry | Voltage, current, cycles, location | No, but location is sensitive | Years, for trend analysis | Fleet cloud |
Two rows in that table are usually the surprises. Camera retention defaults are frequently longer than the operator assumes, and microphone data is often not mentioned in the datasheet at all. Ask for the retention default per sensor, in writing, before you accept a pilot.
The Four Attack Surfaces
Service robot security is not exotic. The realistic attack surfaces are the same four you would find in any connected industrial device, and the incidents that do occur are overwhelmingly misconfiguration rather than sophisticated exploitation.
Fleet cloud API. The management platform is the highest-value target because it holds credentials, maps and telemetry for every robot. Attacks here are usually credential reuse or an integration token left in a public repository. Require per-tenant isolation, mandatory multi-factor authentication on admin accounts, and a documented token rotation policy.
Robot-to-robot and robot-to-infrastructure comms. Fleet coordination traffic and handover to elevators, doors or building management systems. The risk is an unauthenticated protocol on a flat network, which allows a rogue device to issue movement or door commands. Require mutual authentication and signed messages on these channels.
The update channel. Firmware is the most dangerous vector because it executes with full privilege. An unsigned update path is a remote code execution path. Require signed firmware images, integrity verification on the robot before applying, and the ability to roll back. Our separate guide on firmware and OTA lifecycle covers the rollout mechanics.
Teleoperation streams. Remote supervisors view live video and can drive the robot. This is a real-time, high-bandwidth channel carrying personal data, and it is frequently implemented with a shared session key and no session recording. Require per-session authentication, short-lived tokens, and an auditable record of who took control and when. See teleoperation and remote fleet supervision.
Network Segmentation for a Mixed Fleet
The single most effective control is also the cheapest: do not put the robots on the same network as anything that matters. A segmented deployment divides the estate into four logical zones, each with a defined purpose and an explicit flow policy.
| Zone | Contains | May reach | May not reach |
|---|---|---|---|
| Robot VLAN | Robots, charging docks | Fleet cloud endpoint, dock controller | Corporate LAN, internet at large, guest network |
| Teleoperation VLAN | Supervisor workstations, video relay | Robot VLAN, fleet cloud | Corporate LAN direct, guest network |
| Building systems VLAN | BMS, elevators, access control, doors | Robot VLAN via authenticated gateway only | Direct robot access, internet |
| Guest and corporate VLAN | Staff and visitor devices | Internet, corporate services | Robot VLAN, teleoperation VLAN |
Where robots must interact with building systems, put an authenticated gateway between the zones rather than allowing direct traversal. Elevator integration and door control are the two interfaces where this matters most, because a compromise there affects people rather than data. Our notes on building integration are in occupancy sensor and BMS integration.
Two practical notes from deployments we have supported. First, robots with cellular modems bypass your segmentation entirely, so decide deliberately whether the modem is allowed and, if so, restrict its destination to the fleet cloud endpoint. Second, guest Wi-Fi is often the leak: if the robot's configuration interface responds on the guest network, your segmentation is decorative.
GDPR Roles, Are You Controller or Processor?
This question decides who carries the liability and what paperwork you need, and it is answered by who determines the purpose of processing, not by who owns the hardware.
For a guest-facing robot that films a lobby or a retail floor, you are almost always the controller. You chose to deploy a camera-bearing device in a space where people are present, and you determine the purpose. The vendor supplying the robot and its cloud is your processor, which means you need a data processing agreement under Article 28, you need a lawful basis for the camera processing, and you need to answer subject access requests from footage you hold.
Where the vendor processes telemetry for its own product improvement, warranty administration or model training, the vendor becomes a controller for that specific activity. That is a separate processing purpose and it needs its own lawful basis and its own disclosure. Ask the vendor directly: do you use my fleet's operational data to train models or improve your product, and can I opt out? A vendor who cannot answer that question has not thought about it.
Three practical obligations follow for most EU deployments. Display a clear notice where the robot operates, covering what is captured and the retention period. Keep camera retention as short as the operational purpose allows, 7 days is common and usually defensible for cleaning quality review. And include robot-generated personal data in your records of processing activities and in your retention schedule, because they are frequently omitted there. Our broader treatment of the privacy framework sits in service robot security and privacy data.
This section is operational guidance, not legal advice. Confirm your role with your data protection officer or counsel before a pilot, particularly for guest-facing deployments and for any deployment where a robot operates in a space where employees are continuously monitored.
The IT Review Checklist
Before you approve a service robot deployment, require nine artefacts from the vendor: a per-sensor data inventory with retention defaults, the data residency and hosting location of the fleet cloud, an Article 28 processing agreement where you are the controller, signed-firmware and secure-boot confirmation, a documented patch cadence, per-tenant isolation and MFA confirmation on the management platform, mutual authentication for robot-to-infrastructure protocols, teleoperation session logging, and a written statement on whether your operational data is used for model training. Those nine items are what a security reviewer can actually evaluate in a week, and every one of them should be contractually committed rather than answered verbally.
- Data inventory. Per sensor: what is captured, retention default, where it is stored, and whether it is encrypted at rest.
- Hosting and residency. Which region hosts the fleet cloud, and which subprocessors are involved. This determines whether a transfer mechanism is needed.
- Article 28 agreement. Required where you are the controller and the vendor is the processor. Get it signed before the pilot, not at contract close.
- Signed firmware and secure boot. Confirms that a compromised update path cannot run arbitrary code on the robot.
- Patch cadence. A stated maximum time to remediate critical vulnerabilities, with a history you can verify.
- Tenant isolation and MFA. Per-customer data separation on the platform, and no admin access without multi-factor.
- Protocol authentication. Mutual authentication and message signing for robot-to-elevator, robot-to-door and robot-to-BMS traffic.
- Teleoperation logging. Who connected, when, and what they could see and control, retained for audit.
- Model-training statement. Written confirmation of whether your data is used for product improvement, and an opt-out path.
If your vendor cannot supply these for a pilot fleet, that is itself the finding. The platform-side view of the same fleet is covered in fleet management systems, and the safety framework that a security review sits alongside in safety standards and compliance. Send us your site profile and we will return the security documentation pack for the platform you are evaluating, including the data inventory and segmentation guidance for your building.
