Robot IT security: the questions North American IT teams ask before a robot goes on their network

Short answer: When a robot is sold to a North American enterprise, hospital, university, hotel group or warehouse, the person who approves it for the network is not the operations manager who bought it. It is the customer's IT and security team, and to them a robot is first of all an unattended IoT device with cameras and microphones that wants to join the internal network. They ask nine kinds of question: how it authenticates (802.1X), which isolated segment it sits on, which outbound destinations it needs, whether it works through their proxy and TLS inspection, how the maker's engineers get in remotely, what data it collects and where that data is stored (and whether it leaves the country), how the firmware is updated, where vulnerabilities are reported, and whether the maker can complete a security questionnaire. Most of the answers sit with the robot maker. A ready-made English "IT pack" can turn weeks of back-and-forth into days; without one, the robot waits in a storeroom while answers trickle in by email.

This page is for robot makers, especially those based in China or elsewhere outside North America, preparing for their first North American customers. It explains why security teams ask what they ask, what to prepare for each question, which public guidance and laws sit behind the questions, and how the robot maker, a local field service partner and the customer's IT team usually split the work. KeepRobots is a robot field service company in Vancouver, not a law firm or a security certification body. The guidance and laws below come from official government and standards sources checked on 2026-10-29 and listed at the end. This is not legal advice. Have Canadian or US counsel review cross-border data flows and contract terms.

Why IT teams slow robots down

Two reasons. First, the baseline expectations for IoT devices are public, and security teams use them as checklists. The Canadian Centre for Cyber Security's IoT guidance for organizations (ITSAP.00.012) recommends changing default passwords on IoT devices, isolating IoT networks from systems that manage sensitive data, and keeping IoT devices patched. In the US, NIST's IoT device cybersecurity capability core baseline (NIST IR 8259A) groups what a device should be able to do into six capabilities: device identification, device configuration, data protection, logical access to interfaces, software update, and cybersecurity state awareness.

Second, robots have had real incidents. In September 2025, researchers published an exploit called UniPwn against Unitree's Go2 and B2 quadrupeds and G1 and H1 humanoids. The Bluetooth (BLE) interface used to set up Wi‑Fi relied on encryption keys that were hard-coded in the firmware and already public; commands hidden in the Wi‑Fi name and password fields ran as root, and an infected robot could scan for other Unitree robots in BLE range and infect them too (IEEE Spectrum, 2025-09-25; CVE-2025-35027, CVSS 3.1 score 7.3). According to IEEE Spectrum, Unitree said on LinkedIn on 2025-09-29 that it was aware of the issues and had completed the majority of the fixes. Until fixes arrived, the researchers advised keeping the robots on a private network and turning Bluetooth off. A paper by some of the same researchers also reports that a G1 sent telemetry every 300 seconds to two external servers, which they describe as Chinese infrastructure (arXiv 2509.14139).

North American security teams read these reports. The lesson for robot makers is not to stay away, but to document network behaviour, data flows, remote access and vulnerability handling before the customer asks.

Robot IT security requirements at a glance: the 9 questions

1. Network authentication: 802.1X is the first hurdle

Staff Wi‑Fi on North American enterprise networks is usually WPA2/WPA3-Enterprise, with IEEE 802.1X port-based authentication against a RADIUS server behind it. A robot that only supports a shared password (PSK) usually cannot join the staff network as is. The common options, roughly in order of how security teams like them:

• EAP-TLS (certificates): the favourite. The robot must accept a device certificate issued by the customer's CA, and you need a plan for certificate renewal. A fleet dropping offline a year after go-live because certificates expired is a common field failure.
• PEAP (username and password): simple to implement. Customers usually create a service account per device and may rotate passwords, so you need a way to change them remotely.
• A unique PSK per device: network vendors use different names for this (iPSK, MPSK, DPSK). The robot still enters a password, but each unit's is different and can be revoked on its own. For PSK-only robots this is often the fastest route to approval.
• MAC authentication bypass (MAB): for devices that cannot do 802.1X. MAC addresses can be spoofed, so customers put these devices on an isolated segment with minimal rights. The robot must be able to turn off MAC randomization, and you should send a MAC list by serial number in advance.

The guest network is not the answer: a captive portal needs someone to click "accept" and asks again every few hours or days, so an unattended robot drops off on a schedule. A few more site details: robots roam between access points, and a full re-authentication on every roam can stall long enough to time out teleoperation and cloud heartbeats, so ask about fast roaming (802.11r) and WPA2/WPA3 transition settings and test on a demo unit. Many enterprise networks block outside NTP; a controller without an RTC battery that reboots with the wrong time will reject every certificate, which looks like a "network problem". Support the customer's internal NTP and DNS servers.

2. Network segmentation: the robot only reaches what it needs

The Canadian Centre for Cyber Security puts it plainly: isolate IoT networks from systems that manage sensitive data. For a robot, the customer will usually create a dedicated SSID or VLAN where the robot can only reach the cloud destinations you listed, and nothing on the point-of-sale, clinical or access-control networks. Be clear about three things: whether robots need to talk to each other (multi-robot scheduling often does); whether the robot needs to reach anything on the customer's network (elevator, door or nurse-call interfaces); and whether chargers, docks or a local fleet server are also networked. UniPwn is a good illustration of why segmentation matters: if one robot is compromised, the damage stays inside its own segment.

3. Outbound allow-list, proxies and TLS inspection

Customer firewalls default to "deny unless allowed". Send a table with the domain, port, protocol and purpose of every cloud service the robot uses (device management, telemetry, messaging, firmware updates, time sync). From experience:

• Give domain names, not IP ranges. Cloud IPs change, and every change would mean another firewall ticket.
• State that no inbound connections are needed. Anything that requires port forwarding rarely gets approved at a large organization.
• Use port 443 where you can. MQTT on 8883 is often blocked; MQTT over WebSockets on 443 is much easier to approve.
• Proxies and TLS inspection: many enterprises force outbound traffic through an explicit proxy or decrypt TLS at the firewall. If the firmware cannot be configured for an HTTP proxy, the robot cannot get out at all; if the customer's inspection CA is not in the robot's trust store, connections fail; with certificate pinning or mutual TLS, the only fix is an exemption. Send a list of domains that need a TLS-inspection exemption, with the reason. IT teams handle that kind of request routinely, and it is far easier to approve than "please allow our traffic".

Another option is a built-in LTE modem so the robot never touches the customer's network. Some IT teams prefer that. The modem needs FCC and ISED certification, and carrier requirements, data costs and coverage in basements and elevator shafts have to be checked in advance.

4. Remote access: how the factory team gets in

Remote troubleshooting by the factory team is essential, but "we'll install a remote desktop tool" is almost always refused at large organizations. What security teams usually accept:

1. The robot opens an encrypted outbound tunnel; no inbound ports;
2. Access is requested and granted per session, approved by the customer or the on-site contact, time-limited and closed automatically;
3. Named accounts with multi-factor authentication: no shared "support" account and no factory default passwords (changing default passwords is the first item in the CCCS guidance);
4. Session logging: who connected, when and what they ran, visible to the customer;
5. Least privilege: remote users reach the robot only, nothing else on the customer's network.

Expect one more question, increasingly common in the US: which country the remote engineers are in. That ties directly into the next section.

5. Where the data lives, and whether it leaves the country

Service robots carry cameras, depth cameras and lidar, sometimes microphones, and the map they build is effectively a floor plan of the customer's building. Security and privacy teams will ask what is collected, what stays on the robot and what is uploaded, to which cloud region, for how long, who can access it, whether it can be deleted on request, and what the factory team can see. One data-flow diagram is worth ten paragraphs. The rules behind the questions, limited to the parts that touch robot data:

On cameras specifically, the first recommendation in the OPC's 2008 guidelines for overt video surveillance in the private sector is to limit the use and viewing range of cameras as much as possible. The robot equivalents: no recording by default or only short on-device buffering, blurring before upload, and configurable cloud retention.

North American customers ask about cloud regions directly. The major cloud providers have Canadian and US regions (AWS, for example, lists ca-central-1 "Canada (Central)" and ca-west-1 "Canada West (Calgary)"). Keeping North American customers' data in a North American region, and explaining that the factory team cannot see raw data by default, makes this conversation much easier.

6. Firmware updates, vulnerability disclosure and SBOMs: the "two years from now" question

IT teams have seen too many devices that were never updated after installation, so they ask which OS and kernel the robot runs, how often security updates ship, when OTA updates are pushed, whether the robot reboots during business hours, whether the customer controls the update window, and how many years the product will be supported.

CISA's Secure by Design principles (first published April 2023, revised October 2023) set out three principles: take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top. CISA's Secure by Design Pledge (May 2024) says outright that physical products such as IoT devices are not in its scope, but its goals are exactly what customer IT teams ask about: multi-factor authentication, eliminating default passwords, timely patching, a published vulnerability disclosure policy that authorizes testing by the public, and CVEs for vulnerabilities. For the development process, NIST's Secure Software Development Framework (SP 800-218, SSDF version 1.1, February 2022; version 1.2 was still a draft as of 2026-10-29) is a set of high-level secure development practices you can map your process to when asked "how do you keep your code secure?"

A software bill of materials (SBOM) lists every software component in the product. When a vulnerability hits a common open-source component, customers use it to work out whether their devices are affected. NTIA published the US minimum elements for an SBOM in 2021; on 2026-07-29 CISA published the "2026 Minimum Elements for a Software Bill of Materials", which replace them. Not every customer asks for an SBOM, but having one makes that part of the questionnaire easy.

UniPwn's lesson for every robot maker is concrete: treat provisioning and service interfaces (Bluetooth setup, USB, debug serial ports, factory Wi‑Fi hotspots) as attack surface. No keys shared across all units, no trusting outside input, and a way to switch them off after commissioning. When a customer asks whether your product has the same problem, showing your own review findings is far more convincing than "we're not that company".

A note on the FCC: the FCC's DA 26-786 of 2026-07-28 added certain foreign-produced robotic devices to the Covered List. That governs FCC equipment authorization and is separate from a customer's IT review. On the same day the FCC's Office of Engineering and Technology (DA 26-789) allowed software and firmware changes that mitigate harm to US consumers on devices authorized before July 28, with the waiver running to at least 2029-01-01; hardware changes remain restricted. Plan OTA and patching with both in mind. See FCC Covered List and robots: Canada vs the US.

7. Security questionnaires and attestations

At large organizations a security questionnaire is almost always part of procurement. Some customers use an industry-standard questionnaire; hospitals, universities and large companies often have their own. Some advice:

• Complete one standard questionnaire as your master copy and adapt it for each customer instead of starting from scratch;
• Attach a SOC 2 report or ISO/IEC 27001 certificate if you have one. If you don't, say so and describe the controls you actually run. Never claim conformance with a standard you have not been assessed against; questionnaire answers often end up in the contract;
• Don't pitch the FCC's U.S. Cyber Trust Mark. The program, adopted in March 2024 (FCC 24-26), covers consumer wireless IoT products only, not enterprise or industrial products, and excludes Covered List equipment. As of 2026-10-29 no product can carry the mark yet: the first Lead Administrator, UL Solutions, withdrew in December 2025, the ioXt Alliance was selected in April 2026, the technical requirements and testing procedures have not been released, and on October 27 the FCC was still asking for comment on label design and certification renewal (DA 26-1162). Commercial robots sold to businesses are outside its scope anyway.

8. Time zones: the firewall change happens while the factory sleeps

Beijing is 15 hours ahead of Vancouver all year: BC stays on UTC-7 and does not fall back on 2026-11-01 (Seattle does, so it is 16 hours behind Beijing in winter). Customer IT makes network changes during local business hours or maintenance windows, so the firewall is changed while the factory engineers are asleep, and by the time they read the logs the customer's IT team has gone home. What works: write the verification steps before the change (does DNS resolve, is the port open, has the certificate issuer been replaced by an inspection CA, is the clock right, does the proxy work), have someone on site run them on the robot or a laptop on the same segment, and paste the results into the ticket. When booking the change window, book someone on site who can read network logs, not just someone to "restart it".

Who does what: robot maker, local service partner, customer IT

Keep the boundary clear: security design, questionnaire answers, vulnerability fixes and data architecture belong to the robot maker. A local partner handles on-site execution and communication, and should not be signing your questionnaire.

The IT pack: a one-page checklist

Have it ready before the robot ships and send it at the first meeting with customer IT:

1. Network description: Wi‑Fi bands and channels, supported authentication methods, whether MAC randomization can be disabled, 802.11r support, whether robots must talk to each other;
2. MAC addresses by serial number;
3. Outbound list: domain, port, protocol, purpose; "no inbound" statement;
4. Proxy support, whether a customer CA can be installed, domains that need a TLS-inspection exemption and why;
5. NTP and DNS requirements;
6. Data-flow diagram: what is collected, on-device vs cloud, cloud region, retention, deletion, what the factory team can access;
7. Remote access description: architecture, approval process, accounts and MFA, logs, where remote staff are located;
8. Updates and support: OS version, update cadence, customer control of update windows, support period;
9. Vulnerability disclosure policy and contact; SBOM if available;
10. A completed standard security questionnaire; any SOC 2 or ISO/IEC 27001 reports;
11. On-site contacts and escalation path, with everyone's time zone.

Build it once and reuse it for every North American customer. It is written for a security team that has never seen your product and only wants to know it won't cause trouble.

Common mistakes

• Finding out on site that the robot only does PSK and the customer only has 802.1X networks;
• Giving IP ranges instead of domains, then losing the whole fleet when the cloud provider changes IPs;
• Pinned certificates behind a TLS-inspecting firewall: every connection fails and days go into chasing a "Wi‑Fi problem";
• Remote access through a shared account or a third-party remote desktop tool, vetoed by security;
• Writing "data stays in the country" in the questionnaire while logs upload to servers abroad by default;
• Bluetooth provisioning or a debug hotspot left on after go-live;
• No vulnerability disclosure contact, so nobody can be reached when a customer or researcher finds a problem.

What KeepRobots can do

KeepRobots is a robot field service company in Vancouver, serving Greater Vancouver first and travelling to the rest of Canada and the US. For the IT review we can do the on-site half: a pre-shipment Wi‑Fi survey along the robot's route (including elevator lobbies, back corridors and elevator cars), joining the meeting with the customer's IT team to walk through your IT pack, connecting the robot and running verification tests during the change window, running firmware upgrades on site in the agreed window following your instructions, acting as the on-site contact for remote sessions, and logging everything in the ticket the same day. We work in English and Chinese, read Chinese technical documents and can work with your factory's hours. Security design, questionnaire answers and data architecture stay with you; we don't answer on your behalf.

Current rates, before tax: diagnostic CAD 200 per robot, per visit in Canada and USD 200 per robot, per visit in the US (credited against an approved repair); CAD 100 call-out in the Greater Vancouver core area; on-site labour CAD 150 per hour in Canada and USD 150 per hour in the US; travel outside the core area and for US projects quoted per project. The rest of site readiness (elevators, doors, charging, acceptance) is in the robot commissioning checklist for Canadian sites, and our deployment service is at robot deployment services in Canada and the USA. To talk through your IT pack, email partners@keeprobots.com or use the contact page.

FAQ

What do North American IT teams ask before a robot goes on their network?

Usually nine things: how it authenticates (802.1X, a per-device PSK or MAC authentication), which isolated segment it sits on, which outbound domains and ports it needs, whether it works through their proxy and TLS inspection, how the maker's engineers get in remotely, what data it collects and where it is stored, how the firmware is updated, where vulnerabilities are reported and whether there is an SBOM, and whether the maker can complete a security questionnaire. Most answers sit with the robot maker, so prepare an IT pack before the robot ships.

Can a robot that only supports a Wi-Fi password (PSK) join an enterprise network?

Usually not the staff network, which is typically WPA2/WPA3-Enterprise with 802.1X. Common workarounds are a unique PSK per device (iPSK, MPSK or DPSK depending on the network vendor) or MAC authentication on an isolated segment, provided the robot can turn off MAC randomization. Guest networks with captive portals need someone to click accept and re-authenticate periodically, so they don't suit unattended robots.

Can robot camera footage and logs be sent to servers abroad from Canada?

Footage, voice and logs that identify people are personal information. Under PIPEDA the organization stays responsible for information transferred to a third party for processing and must use contractual or other means to provide a comparable level of protection; the OPC's cross-border guidelines say people must be told their information may be processed in another country and accessed by its authorities; in Quebec a privacy impact assessment and written agreement come first. Ask Canadian counsel about your specific case.

How does 28 CFR Part 202 affect robots sold in the US?

The DOJ rule, in effect since April 8, 2025, bars US persons from giving countries of concern such as China, or covered persons, access to bulk US sensitive personal data through vendor, employment or investment agreements unless CISA's security requirements are met. Thresholds relevant to robots are over 1,000 US persons for biometric identifiers enrolled in a biometric system (such as facial images, voice prints or gait) and over 1,000 US devices for precise geolocation, over the preceding 12 months. The obligation is the US customer's, which is why it shows up in their security questionnaire. Ask US counsel.

Can robots carry the FCC U.S. Cyber Trust Mark?

Not yet. As of 2026-10-29 no product can carry it: the program covers consumer wireless IoT products only, not enterprise or industrial products; the first Lead Administrator withdrew in December 2025, the ioXt Alliance was selected in April 2026, technical requirements and testing procedures have not been released, and the FCC was still seeking comment on October 27, 2026. Commercial robots sold to businesses are out of scope.

What can KeepRobots do during a customer's IT review, and what does it cost?

The on-site half: a pre-shipment Wi-Fi survey, joining the meeting with customer IT to walk through your IT pack, connecting the robot and running verification tests in the change window, running firmware upgrades on site following your instructions, and acting as the on-site contact for remote sessions. Security design, questionnaire answers and data architecture stay with the robot maker. Current rates, before tax: diagnostic CAD 200 per robot, per visit in Canada and USD 200 in the US (credited against an approved repair), CAD 100 call-out in the Greater Vancouver core area, on-site labour CAD 150 per hour in Canada and USD 150 per hour in the US; travel outside the core area and for US projects quoted per project.

Sources (checked 2026-10-29)

• Canadian Centre for Cyber Security, Internet of Things (IoT) Security, ITSAP.00.012 (July 2022): cyber.gc.ca
• NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline (May 2020): csrc.nist.gov
• IEEE Spectrum, UniPwn exploit of Unitree robots (2025-09-25, incl. Unitree's 2025-09-29 statement): spectrum.ieee.org
• IEEE RAS, Exploit allows for takeover of fleets of Unitree robots (2025-09-25): ieee-ras.org
• CVE-2025-35027: cve.org
• arXiv 2509.14139, Cybersecurity AI: Humanoid Robots as Attack Vectors: arxiv.org
• IEEE 802.1X, Port-Based Network Access Control: standards.ieee.org
• PIPEDA, S.C. 2000, c. 5, s. 10.1 and Schedule 1, 4.1.3: laws-lois.justice.gc.ca
• OPC, Guidelines for processing personal data across borders (2009): priv.gc.ca
• OPC, Guidelines for overt video surveillance in the private sector (2008): priv.gc.ca
• Commission d'accès à l'information du Québec, use and communication of personal information by enterprises: cai.gouv.qc.ca
• BC Freedom of Information and Protection of Privacy Act, RSBC 1996, c. 165, ss. 30.1 (repealed), 33.1: bclaws.gov.bc.ca
• BC Government, guidance on disclosures outside of Canada (PIA): www2.gov.bc.ca
• US Department of Justice, Data Security Program (28 CFR Part 202): justice.gov
• eCFR, 28 CFR Part 202, ss. 202.204, 202.205, 202.211, 202.242, 202.401, 202.601: ecfr.gov
• CISA, Security Requirements for Restricted Transactions (January 2025): cisa.gov
• eCFR, 45 CFR 160.103 (business associate): ecfr.gov
• eCFR, 45 CFR 164.502(e) and 164.504(e) (business associate contracts): ecfr.gov
• AWS Regions: docs.aws.amazon.com
• CISA, Secure by Design (revised October 2023): cisa.gov
• CISA, Secure by Design Pledge (May 2024; physical products such as IoT devices not in scope): cisa.gov
• NIST SP 800-218, Secure Software Development Framework v1.1 (February 2022): csrc.nist.gov
• NIST SP 800-218 Rev. 1 (SSDF v1.2), initial public draft (December 2025): csrc.nist.gov
• NTIA, The Minimum Elements for a Software Bill of Materials (July 2021): ntia.gov
• CISA, 2026 Minimum Elements for a Software Bill of Materials (2026-07-29): cisa.gov
• FCC 24-26, IoT cybersecurity labeling program Report and Order (March 2024): docs.fcc.gov
• FCC DA 26-1162, Cyber Trust Mark public notice seeking comment (2026-10-27): docs.fcc.gov
• FCC Commissioner Trusty statement on the Cyber Trust Mark (2026-10-28): docs.fcc.gov
• FCC DA 26-786 (Covered List, 2026-07-28): docs.fcc.gov
• FCC DA 26-789 (software and firmware update waiver for authorized devices, 2026-07-28): docs.fcc.gov

Chinese version: 北美客户的 IT 安全审批：机器人联网、远程运维和数据出境要准备什么

This page summarises public guidance and legal texts for orientation only, as of 2026-10-29. It is not legal advice. Unitree's 2025-09-29 statement is quoted as reported by IEEE Spectrum; we did not open the original post. The 802.1X, roaming, proxy, remote-access and time-zone points are our field experience, not statistics. Rates are KeepRobots' current published rates, before tax, and may change.