When a U.S. warehouse imports autonomous forklifts or AGVs from China, the cybersecurity review should cover more than the physical robots. The fleet control software, RCS, WCS, local server, industrial PCs, APIs, remote maintenance tools and network connections can all become part of the warehouse's IT/OT environment.
The important question is not simply where the software was developed. Your IT team should determine what the system does, what data it collects, where that data is stored, which systems it communicates with, and whether any external connections are required for normal operation.
For an imported Chinese AGV system, cybersecurity should therefore be treated as part of the technical acceptance process rather than as an issue to investigate after installation.
A useful audit starts with the complete software and network architecture. Ask the supplier to provide documentation showing how the AGVs, fleet manager, RCS, WCS, WMS and servers communicate.
The review should cover at least:
AGV-to-fleet-manager communication
Fleet-manager-to-WMS or WCS communication
Local server architecture
Cloud services
External IP addresses and domains
Remote maintenance connections
Software update mechanisms
Authentication and administrator accounts
Data storage and retention
API interfaces
Operating systems and databases
Third-party software components
System and security logs
The objective is to create a clear picture of the system before it is connected to the warehouse network.
There is no universal answer. It depends on the specific supplier, software architecture and deployment configuration.
Some fleet management systems can operate on a customer-controlled local server. Other systems may provide optional cloud monitoring, remote diagnostics, software updates or technical-support services.
Therefore, your IT team should not assume that a Chinese AGV is automatically cloud-connected or completely offline.
Ask the supplier for a communication matrix identifying every external connection. The matrix should specify:
| Item | Information to Request |
|---|---|
| Destination | Domain name or IP address |
| Protocol | TCP, UDP, HTTPS or other protocol |
| Port | Required network port |
| Purpose | Telemetry, updates, diagnostics, licensing or other function |
| Requirement | Mandatory or optional connection |
| Data | Type of information transmitted |
This gives the IT team something concrete to verify instead of relying on a general statement such as “the system does not upload customer data.”
Supplier documentation should be verified against actual system behavior.
During commissioning, the AGV system can be placed inside a controlled network segment. The IT team can then monitor DNS requests and network connections while the system performs normal operations.
Useful test scenarios include system startup, robot dispatch, fault reporting, map operations, software update checks and remote-support procedures.
The objective is to identify undocumented network behavior and determine whether the observed connections match the supplier's approved architecture.
A connection to an overseas IP address is not automatically evidence of a security problem. What matters is whether the connection is documented, authorized, necessary and appropriately protected.
Penetration testing should be performed only with appropriate authorization and a clearly defined scope. An AGV system is part of an operational environment, so uncontrolled testing against production robots can create operational and safety risks.
Whenever possible, use a dedicated test environment that reproduces the relevant server and software configuration.
The security team can then evaluate the local server using its normal security-testing methodology. The scope may include:
Network-service discovery
Configuration review
Vulnerability assessment
Web interface security
API security
Authentication controls
Authorization and privilege separation
Remote-access controls
Logging and monitoring
Network segmentation
The objective should be to identify security weaknesses without interfering with autonomous navigation, emergency-stop functions, fleet dispatching or other operational functions.
Both the software infrastructure and the devices should be considered, but they should not necessarily be tested in the same way.
The local server can be assessed as an IT system. AGV controllers, industrial PCs and network interfaces should be evaluated according to their role in the OT environment.
For example, aggressive network testing against a live vehicle could cause communication interruptions. A better approach is to understand the communication architecture first and perform intrusive testing in an approved test environment whenever possible.
This is particularly important for autonomous forklifts because cybersecurity testing should not create a physical safety incident.
Potential vulnerabilities should be evaluated at the level of the actual product and software components rather than by country of origin.
A useful vulnerability review starts by identifying exact versions of the operating system, database, web server, middleware, libraries, containers and other third-party components used by the AGV platform.
The IT team can then compare those components against appropriate vulnerability databases, vendor advisories and security notices.
This is why an SBOM, or Software Bill of Materials, can be valuable during procurement. It helps the customer understand which software components are actually present in the deployed system.
A supplier should also have a process for reporting, evaluating and patching newly discovered vulnerabilities.
Remote maintenance is one of the most important areas to investigate because it can create an external access path into an otherwise isolated warehouse system.
Ask whether the supplier uses VPN, remote desktop, cloud support software, proprietary remote-access tools or another mechanism.
The IT team should also determine whether remote access is permanently enabled.
For a security-sensitive deployment, a stronger model is to keep remote access disabled by default and enable it only when technical support is required. Access can then be authorized, time-limited and logged.
The supplier should also explain what permissions a remote engineer receives. Access to diagnostic information is very different from unrestricted administrator access to the fleet server.
It can be possible, but it must be confirmed for the exact AGV software architecture.
A local server does not automatically mean an air-gapped system. A locally installed fleet manager may still require Internet access for licensing, software updates, cloud diagnostics, time synchronization or other services.
If your IT policy requires an absolute air gap, ask the supplier to demonstrate that the complete operational workflow works without Internet connectivity.
That includes:
AGV fleet management
Task scheduling
Robot dispatching
Map management
WMS or WCS integration
User authentication
Alarm management
Database operation
System recovery
If any of these functions require an external connection, the system is not completely air-gapped in the strict sense.
An air-gapped network changes the maintenance process.
Software updates may need to be transferred into the environment through an approved offline process. The IT team should verify the source and integrity of the update package before installation.
The warehouse should also maintain backups and a rollback procedure. A software update that changes the fleet manager, database or robot communication protocol can affect the entire automation system.
Before accepting an air-gapped deployment, agree with the supplier on how security patches, bug fixes, diagnostics and software upgrades will be delivered without opening a permanent Internet connection.
The security audit should create a data inventory for the AGV system.
Depending on the system, this may include navigation maps, robot locations, task history, operational statistics, alarms, maintenance records, user accounts and system logs.
The warehouse should determine where each type of data is stored and whether it can be exported or transmitted outside the facility.
For enterprise customers, it is also useful to define data ownership, retention, deletion and export requirements before purchasing the system.
The AGV fleet should generally be treated as part of the warehouse's operational technology environment rather than simply adding every robot to the corporate LAN.
A segmented architecture can restrict communication between AGVs, the fleet manager, WMS and other corporate systems.
For example, the WMS may need to exchange specific task information with the fleet manager. That does not mean individual AGVs should have unrestricted access to corporate servers or the public Internet.
The exact architecture should be designed by the customer's IT/OT team according to its security policies and operational requirements.
Cybersecurity requirements are much easier to enforce when they are included in the technical specification and purchase agreement before the AGVs are manufactured.
For a security-sensitive warehouse, consider requiring the supplier to document:
Complete network architecture
All external communication endpoints
Data storage locations
Remote-access mechanisms
User roles and administrator permissions
Software versions
Third-party software components
SBOM availability where applicable
Security patch procedures
Vulnerability disclosure procedures
Backup and recovery procedures
Security logging
Software update procedures
Customer approval requirements for external connections
Cybersecurity should not be treated as completely separate from the AGV acceptance process.
During factory acceptance testing, the customer can review the software architecture, account permissions, network requirements and documented communication paths.
During site acceptance testing, the IT team can verify the actual deployment against the approved architecture. This can include checking network segmentation, firewall rules, external communication and remote-support controls.
If the customer requires an air-gapped system, the acceptance test should include a controlled Internet-disconnection test to confirm that the core fleet-management and dispatch functions continue to operate as specified.
Identify every software component. Record operating systems, databases, applications and major third-party components.
Document data flows. Identify what information is generated, stored and transmitted.
Document network connections. Record destinations, protocols, ports and purposes.
Review remote access. Determine how supplier engineers access the system.
Test the local deployment. Verify that the system works within the customer's network architecture.
Perform authorized security testing. Use a controlled environment whenever possible.
Check known vulnerabilities. Review the exact versions actually deployed.
Test offline operation. If required, disconnect Internet access and verify essential functions.
Establish update procedures. Define how patches and upgrades enter the environment.
Make requirements contractual. Put network, data and remote-access requirements into the purchase and acceptance documents.
For a U.S. warehouse purchasing autonomous forklifts from China, cybersecurity due diligence should focus on evidence rather than assumptions.
Ask the supplier to document the architecture, data flows, software components, external connections and remote-access methods. Then allow your IT/OT team to verify those claims through controlled network monitoring and authorized security testing.
If the warehouse requires an air-gapped environment, make that requirement explicit from the beginning. The supplier should demonstrate that fleet management, dispatching, WMS integration, maps, alarms and other required functions can operate without an Internet connection.
The strongest procurement approach is therefore not to ask whether Chinese AGV software is “safe.” Instead, require a transparent architecture, controlled network access, local data ownership, documented software components, manageable remote support and a security acceptance test before the fleet enters production.
FREE ENGINEERING SUPPORT Stop Gambling on Generic Platforms. Get an AGV/AMR Tailored to Your Warehouse.Buying automated guided vehicles involves complex safety standards (CE/ANSI), navigation setups (Laser SLAM), and ERP system integration. Don't risk your factory safety with middle-men. ✓ 100% Direct Factory: Customized payload up to 5 Tons. ✓ Free CAD Simulation: Send us your layout, and our engineers will simulate the optimal AGV routes. ✓ Global Support: Overseas installation guidance & local maintenance partners. |
Chinese
English
