Securing Security Robots

Ask what the device does to protect itself

Start with the robot's own defences, because you cannot add them later. NIST IR 8259A, the IoT Device Cybersecurity Capability Core Baseline, sets out the cybersecurity capabilities a connected device should provide through its own hardware and software, and makes a useful frame for supplier questions. Ask how each robot, dock and controller is uniquely identified, who can change its configuration, how stored maps and footage are encrypted, which local ports and wireless interfaces are active, how software updates are signed and checked, and what security events the device logs. Ask the same of the drone, its remote controller and any operator tablet. Vague answers at this stage usually mean weak protection in service.

Secure by default at no extra cost

Security that depends on your team finding the right settings tends to be skipped. CISA's Secure by Design programme says products should be secure to use out of the box, with little to no configuration change and at no additional cost, and that makers should take ownership of their customers' security outcomes. Use that as a buying test. Ask whether every unit ships with a unique password, whether multi-factor sign-in is on for the operator portal, whether unused services are switched off, and whether audit logs and single sign-on are standard or sold as extras. Record the answers in the contract, so a later software release cannot quietly weaken them.

Keep robots on a separate network

Treat every robot, dock and drone as an untrusted device until shown otherwise. Put them on their own network segment, allow only the connections they need to the maker's cloud and your video management system, and block traffic to the rest of your business systems. Remote support should run through a channel you can switch on and off, with every session logged and the maker's support staff approved by name in advance. Rotate credentials when people leave, and watch for logins at odd hours or from unexpected places. A patrol robot's map shows the layout of your site and the timing of its rounds, so protect those files as carefully as your building plans.

Updates, vulnerabilities and the end of support

Every connected device will need patches, so make update support part of the purchase. Ask how long the maker commits to security updates, how it tells customers about vulnerabilities and how quickly it fixes serious ones. For products sold in the EU, Regulation (EU) 2024/2847, the Cyber Resilience Act, places cybersecurity duties on manufacturers of products with digital elements, including handling vulnerabilities and supplying security updates, so ask how each maker is preparing. Plan update windows that do not leave a site uncovered, and test each update on one unit first. When a robot is retired or sold, wipe its maps, credentials, keys and stored footage, and keep a record that you did.

Sources and further reading

• NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline — National Institute of Standards and Technology (NIST).
  NIST baseline of the cybersecurity capabilities a connected device should provide through its own hardware and software.
• Secure by Design — Cybersecurity and Infrastructure Security Agency (CISA).
  CISA's case for products that are secure out of the box, with makers owning their customers' security outcomes.
• Regulation (EU) 2024/2847 (Cyber Resilience Act) — European Union, EUR-Lex.
  EU law setting cybersecurity duties for makers of connected products, covering vulnerability handling and updates.

Common questions

Could a hacked security robot be used to spy on a site?

Yes. An attacker with control of a patrol robot could watch its cameras, read its maps and learn when rounds take place. Strong account security, a separate network segment and alerts on unusual logins make that much harder, as does switching off remote access when nobody needs it.

Should a security robot depend on the maker's cloud?

Many robots need the cloud for maps, updates and support. Ask what data leaves your site, where it is stored, which functions keep running if the connection drops and whether a local-only mode exists. A robot that stops patrolling during an internet outage is a weak link in a security plan.