Introduction: PLCs in Everyday Automation
When people consider robots, many think of the humanoid replacements seen on TV, with digitized faces, and funny walking gates. Most don’t consider how robotics are already part of nearly every aspect of our current everyday life. The backbone for many controls for infrastructure, including critical such as water systems, transportation, turbines, and also non critical systems such as automated warehouses and similar robotics applications is the humble Programming Logic Controller (PLC).
To illustrate this, consider something as simple as buying a bottle of water at your local market. That bottle has traveled through multiple automated networks before reaching the shelf. It was likely stored in an automated warehouse, where PLCs controlled its journey from storage to a truck, merging with other soda co-products into a perfectly stacked, mixed pallet. This entire process is orchestrated by a network of PLCs ensuring seamless movement.
PLCs are the backbone of millions of automation services, and to explore it’s ubiquitous, and importance, we will explore the PLC in an Automated Warehouse to understand how something so common, can be so critical.
What does a PLC do
As mentioned above, a PLC is a Programming Logic Controller, but that isn’t enough for the lay person to understand what a PLC does. A PLC is in fact, a computer used for industrial automation.

It is designed to replicate a set operation or process over, and over again- while collecting vital information from connected systems such as sensors, SCADA (Supervisory Control and Data Acquisition) systems, and HMIs (Human Machine Interfaces)—to collect and process data.
Based on this input, the PLC determines the appropriate response, such as activating motors for conveyors, lifts, and other components within an automated warehouse. The PLC itself operates by: detecting the state of all things it’s connected to, following its repeatable logic for action, and output communication back to what it is connected to; in our example it will be turning on or off the motors for conveyors, lifts, and other parts of an Automated Warehouse system, while also broadcasting status the the larger system.1[1]
PLC in its “Natural Environment”
Before diving into how PLCs identify and communicate, let’s explore an environment in which they operate. Consider an automated warehouse, like an amusement park ride for your bottle of water. Products start at different bays, and ride conveyors, that climb, twist, merge, and more, all to end at the the loading dock; PLCs manage every transition.
Automated warehouses function as massive logistical hubs, moving thousands of products daily through an intricate system of conveyors, sorters, and palletizers. These warehouses are structured into zones, each managed by dedicated PLCs that control specific identified (NHI) conveyor types, motors, actuators, etc. Here I provide some human readable examples of identifiers:
- PLC: (PLC001, PLC002, etc.) – Each PLC must be identified and identifiable for communication and controls to happen.
- BAY: (B001, B002, etc.) – where the product is waiting to be “picked” and have the PLC release onto a conveyor.
- Release Conveyor: (RC001, RC002, etc.) move products from storage.
- Merge Conveyor: (MC001, MC002, etc.) Multiple conveyors merge into a single conveyor monitored by sensor controllers (e.g., Raspberry Pi devices).
- Divert Conveyor: (D001, D002, etc.) When the boxes on the conveyor are splitting onto two or more conveyors.
- Sequence Check: (SC001, SC001, etc.) found at intersections to proper order.
- Palletizer Merge: till it reaches the Palletizer zone we will call the conveyor that delivers to the palletizer “PM”. Within the Palletizer there are multiple zones:
- Palletization & Patterns – Different automated systems have different palletization or loading patterns. (We will not go into the specifics of any individual warehouse pattern systems.)

At each stage, PLCs ensure that products follow the correct path, communicating with sensors using their programmed logic to maintain order. At many PLC locations, there may be another controller working in tandem, a sensor controller, often a Raspberry Pi. This little card sized controller is used specifically to capture data on sensors, lasers, and similar; used to identify a container as it rolls through a sequence check, this device must have its own identification, and be able to communicate to and be recognized by the PLC. Now that we have a high-level overview the warehouse flow, we can explore how PLCs identify and communicate with each other within this environment.

PLC Identity and Non-Human Identity (NHI)
For PLCs to function in an automated system, they must be able to recognize and communicate with all the devices around them – motors, actuators, and even secondary controllers like the Raspberry Pi. To do this, they rely on a set of unique identifiers known as Non-Human Identity (NHI). These identifiers allow PLCs to track and communicate with every connected device in real time, enabling the automation of operations.
Some of the key NHI mechanisms used in Industrial Automation include:
- IP or MAC Addresses – Common in modern Ethernet-based networks.
- Industrial Protocols – Such as Ethernet/IP, Modbus TCP/IP, and Profinet.
- Legacy Network Identifiers – Older systems use Profibus, CANopen, and DeviceNet, which assign Node IDs instead of IP addresses enabling PLC to communicate to different machines.
- Memory Addresses & Tags – PLCs store references to connected devices, ensuring recognition even after hardware replacements.
- Routing Tables & Network Maps – Define communication pathways in complex systems.
- Raspberry Pi Running Node-RED – fetches data from Allen-Bradley PLC using Modbus TCP/IP, a quick SCADA alternative, and can in some instances be a sub network within a PLC network.
In the warehouse, these identifiers allow different zones to work in tandem. When a product is released from storage, the release conveyor’s PLC communicates with merge and divert PLCs, ensuring proper sequencing for palletization. If anything goes wrong – like a PLC not recognizing a product assigned path, it will trigger a fault, forcing human workers to intercept and correct. Even a single miscommunication can create delays that ripple through the entire warehouse.
Mixed-Age Systems and Heartbeat Identification
Industrial automation systems change, adapt, and evolve over time. As facilities upgrade, they often end up with mixed-age systems, where legacy PLCs must coexist with modern networked controllers and machines2. In such environments, older PLCs often rely on heartbeat signals—simple, periodic pings that confirm a device is online If a heartbeat is lost, the system assumes failure and may trigger emergency shutdowns.
While this mechanism ensures safety, it also presents a risk: heartbeat ID spoofing could allow an unauthorized device to mimic a PLC’s presence, potentially disrupting warehouse operations. (We’ll discuss more in depth to come.)
Multiple PLC Networks and Leader-Follower Configurations
In automated warehouses, PLCs do not operate in isolation, they are part of segmented networks. To manage complexity, PLCs are often grouped into leader-follower configurations, where a leader PLC oversees several subordinate controllers. This structure:
- Reduces network congestion by centralizing decision-making.
- Ensures coordinated actions across multiple warehouse zones.
- Helps isolate faults—if a follower PLC fails, the leader can reroute operations or trigger alerts.
When a PLC broadcasts an error, it’s effects ripple through the system. The Leader PLC broadcasts the error, and upstream PLCs must determine whether it will impact their operations. If an issue is detected, they halt to prevent further errors. Meanwhile, downstream PLCs continue running until a sequence check further along the process detects a missing product. At that point, the downstream PLC registers the failure and alerts its own upstream systems, trigging a secondary shutdown.
This cascading effect can halt sections of the warehouse or, in extreme cases, bring the entire facility to a standstill if warehouse staff and Controls Engineers do not quickly identify and resolve the originating PLC failure.
For example, consider merge zone PLC detecting a sequencing error. The PLC immediately notifies its leader PLC, which then signals upstream systems to pause product flow. By stopping movement before the issue spreads further, the system minimizes disruption and reduces downtime.
The Interconnected Nature of PLCs
The ability of PLCs to recognize and communicate with each other and partner systems is what keeps an automated system running smoothly. But as warehouses grow more complex, integrating mixed age networks, external controllers, and industrial IoT devices, the question of identity becomes just as important as function. Without strong Non-Human Identity (NHI) mechanisms, PLCs cannot securely authenticate the machines they interact with, leaving gaps for errors and exploitation.
In the next section, we will explore some mechanisms PLCs use to establish identity. From IP/MAC addressing to legacy network identifiers, each method plays a role in ensuring that every PLC, sensor, and actuator knows it’s place in the system. These identities and identity methods allow PLCs to interact reliably, but come with limitation and challenges.
Key Non-Human Identity Methods in Automated Warehouses
We continue to explore some of the top uses and vulnerabilities of the Non-Human Identity of Automated Warehouses, and how they relate specifically with regards to the PLC.
IP or MAC Address-Based Identification
When properly set up, PLCs rely on IP or MAC addresses for network communication and identification. In most warehouse environments, leader PLCs may use multiple identifiers for redundancy and protection, while subordinate PLCs may be identified by their MAC address for simplicity.
While MAC spoofing doesn’t have much news coverage, it does happen. There was a 2016 MAC Spoofing attack that cost millions of dollars3. In an industrial setting, even if the malicious actor is successfully blocked through traveling latterly or upstream through network segmentation, we have seen how a single PLC error can cascade and effect the whole system. Strong segmentation may not be enough to prevent disruptions.
And recall, the PLC is not only communicating with other PLCs, but actuators, and other devices such as sensors, and interfaces. If there isn’t a good and regular inventory of all connected devices, the impact of an identity failure can cascade across the entire system.
Industry Protocols (Ethernet/IP, Modbus TCP/IP, Profinet, etc)
Industrial control systems were originally designed with isolation in mind, and isolation was considered secure when Operational Technology (OT) networks were separate from IT infrastructure. However, as automation environments have become more interconnected, these once-closed networks are now discoverable on the network, and face security risks.
Many industry-standard protocols, including Ethernet/IP, Modbus TCP/IP , and Profinet, were developed assuming that the network was closed and secure. These protocols were designed without encryption or authentication mechanisms4,5, making them inherently insecure for communication over modern networks.
This introduces a path to access and capture MAC addresses, verification protocols, or other operational information, widening the door for attack. There are add-ons for security, however the core issue remains; these protocols were not designed with cybersecurity in mind, leaving critical systems vulnerable.
Legacy Network Identifiers
Recall discussing “mixed age systems” above? Older PLCs may not be fully compatible with newer PLC’s, even when using the same brand. When a facility upgrades, it is very unlikely to transition all existing hardware and components; instead, legacy products that are still working remain, sometimes segmenting by network, or even using “heart beat” protocols, where an older PLC broadcasts a heartbeat (ping) as “proof of life”.
The problem; this heartbeat/follower PLC protocol lacks any NHI identifiers at all, and opens another avenue for entry and disruption. When combined with a non-encrypted network protocol, and a threat actor may be able to map older network segments, identify vulnerable devices, and then make plans accordingly.
Claroty TEAM82 has demonstrated the risk in multiple ways, one of the most interesting involves leveraging a legacy PLC to access the SCADA systems. The fastest way to achieve this? Trigger a fault in a legacy PLC, and then the Engineer may use SCADA or HMI to review (and thus attacker gains access to engineer SCADA and more)6. If we have older devices that are using heartbeat as it’s identifier, the bar to access that is pretty low .
Protect the Non-Human Identity – Protect the System
By now, it should be clear just how deeply PLCs are embedded in modern life. They don’t just move your bottle of water from storage to shipment, they quietly control much of the world’s infrastructure, from manufacturing and logistics to water plants and critical utilities.
A warehouse shutdown is inconvenient, but what happens when a PLC error does more than stop operations? What if instead of halting a system, it mistakenly activates equipment? What if a disrupted PLC logic sequence sends the wrong command at the wrong time?
Can you imagine an entire pallet of water falling from 7 stories of a warehouse bay? Who was working there at the time, how were they affected? Now, take that same failure, and apply it to a water treatment plant. What happens when a gate controlling chemical flow opens too early or too late?
Non-Human Identity in industrial automation is established through control systems, MAC and IP addresses, industrial protocols, and authentication mechanisms that help machines communicate with their intended counterparts. As automation networks grow more complex and interconnected, protecting these identity structures becomes critical. If a PLC’s identity is spoofed, or compromised, the consequences could ripple far beyond a single warehouse, impacting safety, security, and infrastructure at a much larger scale.
- DO Supply, Explaining HMI, SCADA, and PLCs, What They Do, and How They Work Together ↩︎
- [1] POR Automated Wherehouse, Overcoming Common Software Implementation Challenges(p8) ↩︎
- Secure W2, MAC Spoofing Attacks Explained: A Technical Overview ↩︎
- Veridify Security, OT Security: Cybersecurity for Modbus ↩︎
- ODVA, Overview of CIP Security ↩︎
- Claroty Team82, Evil PLC Attack: Using a Controller as Predator Rather than Prey ↩︎
References
Allen-Bradley. (2005). Rockwell Automation | Literature | Documents | ag-um008. Retrieved from Rockwell Automation: https://literature.rockwellautomation.com/idc/groups/literature/documents/um/ag-um008_-en-p.pdf
DO Supply. (2019, February 4). Explaining HMI, SCADA, and PLCs, What They Do, and How They Work Together. Retrieved from DO Supply: https://www.dosupply.com/tech/2019/02/04/explaining-hmi-scada-and-plcs-what-they-do-and-how-they-work-together/
Huges, C. (2025, February 20). Understanding OWASP’s Top 10 List of non-human identity criticlal risks. Retrieved from CSO: https://www.csoonline.com/article/3828216/understanding-owasps-top-10-list-of-non-human-identity-critical-risks.html
ODVA. (n.d.). ODVA | Technology Standards | Distincht CIP Services. Retrieved from ODVA: https://www.odva.org/wp-content/uploads/2023/07/PUB00319R2_CIP-Security-At-a-Glance.pdf
Panduit. (2022, October). Panduit | Markets | Documents | Infrastructure Warehouse Automation. Retrieved from Panduit: https://www.panduit.com/content/dam/panduit/en/website/solutions/markets/documents/infrastructure-warehouse-automation-cpcb261.pdf
Project, O. W. (2025). OWASP Non-Human Identities Top10. Retrieved from OWASP: https://owasp.org/www-project-non-human-identities-top-10/2025/
Rockwell Automation. (2024, June). Rockwell Automation | Literature | PlantPAx Distributed Control System Configuration and Implementation. Retrieved from Rockwell Automation: https://literature.rockwellautomation.com/idc/groups/literature/documents/um/proces-um100_-en-p.pdf
Secure W2. (2025). MAC Spoofing Attacks Explained: A Technical Overview. Retrieved from Secure W2: https://www.securew2.com/blog/how-do-mac-spoofing-attacks-work
Sharon Brizinov, M. S. (2022, August 13). Claroty | Team82 | Evil PLC Attack: Using a Controller as Predator Rather than Prey. Retrieved from Claroty: https://claroty.com/team82/research/evil-plc-attack-using-a-controller-as-predator-rather-than-prey
Tecsys. (2024). infohub Tecsys | Resources | e-book | Improving Warehouse Operations with Low Code Application Platforms. Retrieved from Tecsys: https://infohub.tecsys.com/resources/e-book/improving-warehouse-operations-with-low-code-application-platforms
The Robot Report. (2024). Automated Warehouse | Overcoming Common Software Implementation Challenges. WTWH Media LLC.
Veridify Security. (n.d.). OT Security: Cybersecurity for Modbus. Retrieved from Veridify Security: https://www.veridify.com/ot-security-cybersecurity-for-modbus/