TL;DR
- Automated warehouses are complex OT environments with many interdependent systems from multiple third-parties
- A failure or compromise in one system can cascade rapidly, halting the entire operation within minutes
- The multi-party model means these environments are built with security gaps baked in from day one
- Nobody owns the security of the whole warehouse, and that is unlikely to change without deliberate effort
Introduction
We spend a lot of time in industrial environments. Power stations, water treatment works, gas distribution networks, ships. One type of environment that gets far less attention from a security perspective is the automated warehouse.
These are not simple buildings with shelves and forklifts. A modern automated fulfilment centre is a dense, tightly coupled OT environment. Tens of systems from many third-parties, stitched together by a systems integrator, all communicating over shared networks, all dependent on each other to keep goods moving. They are some of the most complex and fragile operational environments we walk into, and they are almost entirely absent from the OT security conversation. Unlike power, water, or transport, warehouses do not fall neatly within a dedicated sector-specific cyber security regime.
We think that needs to change. Here’s why.
What is actually inside an automated warehouse?
From the outside, an automated warehouse does one thing: goods come in, orders go out. The reality underneath is significantly more complex.
At the top sits the Warehouse Management System (WMS). This is the brains of the operation. It knows what stock is where, what orders need picking, and what needs shipping. The WMS is typically an enterprise IT system. SAP, Manhattan Associates, Blue Yonder, or something bespoke. It lives on the IT network or in the cloud, talks to the ERP, and is managed by the IT team.
Below the WMS sits a Warehouse Execution System (WES), sometimes called a Warehouse Control System (WCS). This is the layer that translates the WMS’s instructions into physical actions. It decides which crane removes the pallet from racking, which route to use, which robot picks up the pallet, and how to sequence orders to keep everything flowing. The WES is the bridge between the IT world and the physical world.
Below the WES, things get physical. Conveyor systems move totes, cartons, and pallets between zones. These are controlled by PLCs, with their own control networks. Sortation systems divert items to the right destination using high-speed diverters, tilt trays, or crossbelt sorters, again PLC-controlled.
Automated Storage and Retrieval Systems (AS/RS) store and fetch goods. These range from simple crane-based systems to the kind of grid-based robotic systems that Ocado uses, where hundreds of robots navigate a dense grid above stacked bins, communicating wirelessly with a central controller.
Autonomous Mobile Robots (AMRs) or Automated Guided Vehicles (AGVs) move goods between zones. They navigate using a combination of lidar, cameras, floor markers, or magnetic tape, and they all report to a fleet management system that coordinates their movements to avoid collisions and optimise throughput.
Robotic picking and packing cells use industrial robot arms to pick items from bins or place them into cartons. These cells have their own safety systems, including light curtains, safety PLCs, and emergency stops, to protect human workers nearby. Safety systems are not limited to the robotic cells. Conveyors, sortation systems, AS/RS cranes, and AMRs all have safety controllers and sensors. In a large warehouse, the safety system can be almost as complex and interconnected as the operational control system itself.
Then there is the supporting infrastructure. Label printers, barcode and RFID scanners, weigh stations, vision systems for quality checks, charge stations for the robots, and environmental control for perishables.
Every one of these systems has its own controller, its own network requirements, and often its own third-party supplier. They all need to talk to each other. And they all need to work simultaneously for the warehouse to function.
How tightly coupled is all of this?
Very. That is the problem.
In many industrial environments, individual systems can operate somewhat independently. A pumping station can run even if the SCADA system loses connectivity for a while. Protection relays in a substation will continue to operate if the network goes down, because they are designed to function autonomously.
Automated warehouses are different. The systems are not just connected. They are dependent on each other in real time.
Consider what happens when the conveyor system stops. It doesn’t matter why. A PLC fault, a network issue, a misconfigured firewall rule, or a deliberate attack. The effect is the same.
The AS/RS cannot deliver goods if there is no conveyor to receive them. So it backs up. The robotic picking cells finish their current picks and then have nowhere to put the completed orders. So they stop. The AGVs are still running, bringing goods to stations that can no longer process them. The fleet controller starts queuing them, and eventually the queue overflows and the AMRs start stopping in the aisles because there is nowhere to go. Within minutes, you have a warehouse full of stationary robots. No trucks can leave, no trucks can arrive.
We have seen this happen without any attacker involvement. At one facility, the label printers responsible for outbound goods stopped working. No labels meant no cartons could leave the packing stations. Within minutes, the packing stations backed up, the conveyors feeding them backed up, and the picking systems had nowhere to send completed orders. The entire warehouse ground to a halt because of label printers.
This is the cascading failure problem. You did not attack the WMS. You did not attack the robots. You did not attack the picking cells. You stopped the conveyors, and everything else fell over because everything depends on everything else.
Beyond downtime: poisoning the map
Stopping a warehouse is disruptive. But there is a subtler and potentially more damaging attack: making the warehouse lose track of its own stock.
Most modern automated warehouses use chaotic storage. Items are not stored in fixed, predictable locations. Instead, the WES places goods in whatever slot is most efficient at the time, and the system tracks where everything is. A single bin might contain toothpaste, phone chargers, and dog food. The only thing that knows where any given item is located is the WES database. There are no aisle labels a human can read. Without the WES, you have a building full of thousands of identical bins with no way to find anything.
Now consider what happens if an attacker manipulates the AS/RS to move bins without updating the WES. The physical location of stock no longer matches what the system believes. The WES sends a picker to slot 4,217 for a customer’s order. The bin that arrives is not the one the system expected. The pick fails. The order is delayed. Multiply this across hundreds or thousands of bins and picking operations start failing at scale.
This is not the same as shutting the warehouse down. The systems are all running. The conveyors are moving. The robots are fetching bins. But the right goods are not arriving at the right places, and the warehouse cannot fulfil orders correctly.
Recovery from this kind of desync is painful. You can’t simply reboot the WES because the database is wrong. The data says bins are in locations they are not. The only reliable fix is a physical stock check: stopping operations, scanning every bin, and rebuilding the inventory map from scratch. For a large fulfilment centre with tens of thousands of storage locations, this can take days.
Every hour spent reconciling is an hour where orders are not shipping. For a grocery retailer, that is fresh food not reaching stores. For a pharmaceutical distributor, that is medicines not reaching hospitals. For a parcel carrier during peak season, that is tens of thousands of parcels missing their delivery windows. The business impact is immediate and measurable.
So how does a warehouse end up like this?
Here is where the third-party problem comes in. And it is worth understanding not just why these environments are hard to secure, but why the problems get there in the first place.
An automated warehouse is built as a single project, but it is not built by a single team. The client appoints a main contractor or systems integrator, but the actual systems come from specialist third-parties. One company supplies the conveyor system. Another supplies the AS/RS. Another supplies the AMR fleet. Another supplies the robotic picking cells. The WMS might come from yet another supplier, or it might be the client’s existing system being extended. The WES that ties it all together might be from the main integrator, or it might be a separate product entirely.
All of these third-parties are working to the same deadline. The warehouse needs to go live on a specific date because the lease is signed, the old facility is closing, or the peak season is approaching. The priority is making it work. Getting goods moving. Hitting throughput targets. What goes live is often the minimum viable product.
Each third-party designs their system to function correctly and to integrate with the systems either side of it. They are not asked to design for the security of the whole warehouse. They are asked to make their bit work.
So the conveyor integrator puts in their own managed switches and configures a network that works for their PLCs. The AMR supplier installs their own wireless access points. The AS/RS supplier needs their controller to talk to the WES, so they agree on an integration protocol. The robotic cell supplier needs access to the same network to receive pick instructions.
There is no unified network architecture. There is often a networks team, but they are buried under hundreds of firewall rule requests from different third-parties, for protocols they have never seen before, with no context on what the traffic is or why it is needed. The path of least resistance is to open the rules and move on. Nobody reviews whether the conveyor PLCs and the AMR fleet controller really need to talk directly to each other. The answer to every integration question is whatever gets it working before go-live.
Then there is remote access. Most third-parties ask for ongoing access to their systems for support, diagnostics, and software updates. The conveyor supplier installs a VPN appliance. The AMR supplier wants a cellular gateway. The AS/RS supplier has their own remote monitoring platform. Each of these is set up independently, often by the third-party themselves, with credentials and access policies that the warehouse operator has no visibility into.
By the time the warehouse goes live, you have a network with poorly understood segmentation, multiple remote access paths, systems from perhaps eight third-parties all able to reach each other, and no single party with a complete picture of what is connected to what.
None of this happened because anyone was negligent. It happened because the project was optimised for operational readiness, not security. Everyone did their job. Nobody’s job was the overall security architecture.
Why it stays that way
Once the warehouse is running, fixing these problems becomes much harder.
Segmenting the network means coordinating with every third-party to understand exactly what traffic flows are required between their system and everything else. Most third-parties cannot tell you this with any confidence. They know their system works on the current network. They don’t know what will break if you put a firewall between them and the WES.
Patching is the same story. The conveyor PLCs are running firmware from three years ago. The supplier says updating would require a maintenance window and they cannot guarantee everything will work the same after the update. The AMR fleet controller runs on a Linux box that has not been patched since installation. The support contract says they will maintain it, but only the hardware, not the software.
The warehouse operator, meanwhile, does not have the expertise or the contractual leverage to force these changes. They bought a working warehouse. They did not buy a security architecture. And taking the warehouse offline to implement security improvements means orders do not ship, which means the business says no.
So the firewall rules remain permissive. The remote access paths stay open. The unpatched systems stay unpatched. And the whole environment remains as fragile as the day it went live.
What does this mean in practice?
We are not aware of a publicly reported cyberattack that has taken down an automated warehouse. But the ingredients are all there. Poorly segmented networks, unpatched systems, multiple remote access paths, third-party credentials that nobody rotates, and a tightly coupled physical process where disrupting one system cascades into everything else.
Regulation is beginning to catch up, but the position is fragmented. The UK NIS Regulations apply where systems support defined essential services, so a warehouse is relevant only where it is critical to an in-scope sector. EU NIS2 goes further by covering areas including food production and distribution and parts of pharmaceutical manufacturing, subject to its entity and size criteria.
The UK Cyber Security and Resilience Bill sharpens the focus on resilience and critical suppliers, while the EU Cyber Resilience Act and the UK PSTI regime address certain connected products rather than the warehouse operation as a whole.
For operators, the practical point is simple: regulatory scope may vary, but the resilience problem already exists.
For organisations operating these facilities, the question is not whether they can afford to do an assessment. It is whether they can afford a week of manual warehouse operations whilst they figure out what happened.
Takeaways
Automated warehouses deserve the same security attention as any other critical OT environment. The combination of tight coupling between systems, multi-party integration with no single owner, direct business impact from downtime, and no sector-specific regulation pushing operators to act makes them a significant and largely unmanaged risk.
If you operate one of these environments, start with understanding what you actually have. A proper network survey that maps every system, every integration point, and every remote access path. Most warehouse operators we speak to are surprised by what they find. If you need help doing this, we can help.
From there, the fundamentals apply. Segmentation between systems. Controlled and monitored remote access. Tested recovery procedures. And contractual requirements that make security part of every third-party’s scope, not an afterthought.
The warehouse was built to move goods. Making sure it keeps moving goods when someone is trying to stop it is a problem worth solving.
