A 42-hotel group in Europe put its service robot pilot through the corporate security review before signing, and the review surfaced the question that decides most enterprise robot deals: where does the data go? The robot fleet carried RGB-D cameras, microphone arrays, LiDAR point clouds and an always-on cloud connection into lobbies, corridors and guest floors, and the group's security office wanted a data map, an encryption standard, an access-control model and a vendor questionnaire before the first unit shipped. Their caution was justified: the average cost of a data breach reached $4.88 million in 2024 (IBM), 68% of breaches involve the human factor, and connected devices remain the least-patched category on most facility networks. Robot security is a procurement problem, not an engineering footnote, and the safety standards guide covers the physical-safety half of the compliance picture; this guide covers the data half — what a service robot collects, the four attack surfaces on a deployment, the network and encryption rules, and the 12-point vendor security questionnaire that fits any budget.
What a Service Robot Actually Collects
A modern service robot is a sensor platform on wheels. A typical CRUZR reception unit carries an RGB-D camera array for face recognition and gesture interaction, microphone arrays for voice interaction in 50+ languages, LiDAR and IMU sensors that build a continuous map of the floor plan, and telemetry that logs every movement, interaction and error. The CADEBOT L100 delivery robot adds the same sensor stack to a different job: its cameras read room numbers and obstacles, its mapping data records corridor geometry, and its fleet dashboard logs every delivery run. None of this data is malicious by default — the risk is in how it is stored, transmitted, retained and accessed. The procurement discipline that starts with the vendor evaluation framework continues here: before deployment, produce a data map that lists each sensor, what it captures, where the data is processed (on-device vs cloud), how long it is retained, and who can access it.
The Four Attack Surfaces on a Robot Deployment
Security reviews of robot fleets keep finding the same four entry points. Surface 1 — the device: the robot's OS, USB ports, debug interfaces and physical access ports; a robot parked in a public lobby is an exposed endpoint that needs a locked OS, disabled debug ports and tamper detection. Surface 2 — the wireless network: robots join Wi-Fi for mapping updates and cloud sync, and an unsegmented network gives a compromised robot lateral movement into business systems. Surface 3 — the cloud dashboard: the fleet management platform (the operational layer the fleet management guide documents) holds delivery logs, maps and user records, and its login, API and backup practices determine how much damage a leaked credential does. Surface 4 — the supply chain: firmware updates, mobile apps and third-party components are all vectors, which is why the vendor questionnaire below asks about signed updates, SBOMs and penetration testing. The data centers guide applies the same threat model to server-room robots; the lobby version of the problem simply adds people and guest data to the mix.
Network Segmentation & Encryption: The Non-Negotiable Rules
The single highest-impact control is network segmentation: robots live on a dedicated IoT VLAN, firewalled from the business network, with no inbound access from the guest Wi-Fi. Every link in the chain uses current encryption — WPA3-Enterprise on the wireless side, TLS 1.3 for all robot-to-cloud and dashboard traffic, AES-256 for data at rest on the robot and in the cloud database. Each robot gets a unique device certificate; credentials are rotated on a schedule; the dashboard enforces role-based access control so the front-desk operator sees delivery logs but not camera footage, and the security team sees everything. Logs are exported to the facility's SIEM so robot events land in the same monitoring pipeline as the rest of the estate. The banking guide documents this exact pattern for branch deployments; the discipline is the same whether the robot works in a branch, a lobby or a data center.
Camera & Biometric Data Rules Under GDPR, CCPA and PIPL
Face recognition is the feature that triggers the most regulatory attention, and it is worth remembering the deployment is only legal if the data rules are engineered in. Under GDPR, biometric data is special-category data: it requires a lawful basis, a privacy impact assessment, and typically explicit consent or a legitimate-interest assessment documented in advance. CCPA adds California-specific disclosure and opt-out obligations; PIPL adds China's rules for cross-border transfer — relevant for any vendor processing data outside the facility's jurisdiction. The practical pattern used by enterprise deployments: on-device face matching with a hash or template rather than raw images, retention limits measured in seconds for recognition events and days for audit logs, face blurring in any camera feed stored beyond the live session, and a privacy notice at the reception desk that tells visitors the robot sees them. The telepresence buyers guide covers the remote-visit variant of the same camera-data question.
The 12-Point Vendor Security Questionnaire
Procurement teams should hand every robot vendor the same 12 questions: (1) Where is data processed — on-device or cloud, and in which region? (2) What encryption is used in transit and at rest? (3) Who can access camera and biometric data, and under what approval? (4) What is the data retention schedule per data type? (5) Is the robot OS locked down — debug ports, USB, sideloading? (6) Are firmware updates signed and can they be rolled back? (7) Is there a published SBOM (software bill of materials)? (8) Has the product had independent penetration testing, and can the report be shared? (9) What access does the vendor's support staff have to the fleet dashboard? (10) Is there a documented breach-notification SLA? (11) Does the platform support single sign-on and role-based access control? (12) Is the service agreement backed by a security addendum with liability terms? Vendors that answer all twelve with documents, not promises, are the ones the vendor evaluation framework scores highest — and the same questionnaire is the fastest filter for the reception robots guide audience, where the robot is literally the first thing a visitor's face is scanned by.
Security-Tier Deployment Table
| Deployment | Network | Access control | Camera data | Monthly security cost (est.) |
|---|---|---|---|---|
| Single site, 1–3 robots | Dedicated IoT VLAN, WPA3, TLS 1.3 | Role-based dashboard accounts | On-device matching, 24h log retention | $150–400 |
| Multi-site, 4–20 robots | VLAN + site-to-site VPN, device certificates | SSO + RBAC + MFA, SIEM export | Blurred cloud previews, 7d retention | $600–1,800 |
| Enterprise fleet, 20+ robots | Zero-trust segmentation, per-device certs, API audit | Full RBAC, segregated admin tiers, quarterly reviews | Template-only storage, 30d audit logs | $2,500–6,000 |
Security is not a feature add-on; it is a deployment parameter priced like any other. A robot fleet that maps the lobby, recognizes faces and talks to the cloud is a data system first and a machine second — and buying it with the security questions already answered is cheaper than retrofitting them after an incident. The checklist above turns the conversation from "what does the robot record?" into "here is the data map, the network design and the vendor's signed commitments," which is the version of the conversation that actually closes enterprise deals.