Where AMR fleets are exposed
| Component | Common weakness | What can go wrong |
|---|---|---|
| Fleet manager | Web console with default or shared admin logins, reachable from the office network | Missions, maps and speed zones changed. Robots sent to the wrong places or stopped. |
| Wi-Fi | Robots on the same network as handhelds or guests, with a shared key that's never changed | Anyone with the key can reach the robots and the fleet manager |
| APIs and integrations | Long-lived API tokens stored in WMS, MES or door and elevator controllers | A stolen token lets an attacker create or cancel missions |
| Maps and zones | Editable by any logged-in user | Removing a restricted zone sends robots through areas they should avoid |
| Vendor cloud and remote support | Always-on support tunnels and telemetry to the vendor's cloud | An outside path into the fleet that you don't control |
| Robot onboard computer | Outdated operating system, open SSH or web services | A foothold for moving deeper into the plant network |
Safety-rated laser scanners and stop functions on AMRs usually run on separate safety hardware. They limit physical harm, but they don't stop an attacker from halting your operation or rerouting the fleet.
AMR fleet security checklist
- Separate the network. Put robots and the fleet manager on their own segment and Wi-Fi network, away from handhelds, guests and office devices.
- Strengthen Wi-Fi. Use WPA3-Enterprise or WPA2-Enterprise with certificates where the robots support it. If they need a shared key, make it long and unique, and change it on a schedule.
- Name every account. Give each fleet manager user a named account with only the rights they need. Remove default and shared logins, and turn on MFA where available.
- Lock down maps and missions. Limit who can edit maps, zones and missions, and review the audit log every week.
- Scope API tokens. Replace long-lived tokens with scoped ones, store them in the integrating system's secret store and rotate them.
- Restrict the API. Allow only the WMS, MES and door controller addresses to reach the fleet manager API.
- Broker vendor support. Put vendor remote support behind approval, MFA and session recording, and switch off always-on tunnels.
- Patch. Track fleet manager and robot software versions against vendor advisories, and update in planned windows.
- Back up. Back up the fleet configuration and maps, with versions.
- Plan for an outage. Decide how picking continues manually, who can stop the fleet and who to call.
Common questions
Can someone take control of an AMR remotely?
If they can reach the fleet manager or a robot's own interfaces with valid credentials, or through a vulnerability, they can usually change missions or stop robots. Network separation and strong access control make that much harder.
Is the AMR vendor responsible for security?
The vendor is responsible for the product's software and security updates. You're responsible for how it's deployed: the network, accounts, integrations and remote access.
Should AMRs share Wi-Fi with handheld scanners?
No. Put robots and the fleet manager on their own Wi-Fi network and VLAN, so a lost scanner or a leaked key doesn't give access to the fleet.
Robot cell acting up?
24/7 robot incident line: 646-560-5083. Not urgent? Book an exposure assessment and an engineer replies within one business day.