OT Network Segmentation for Automated Warehouses: Zones, Conduits and Operational Exceptions

Key takeaways #

• Zones and conduits are the core model: A zone is a grouping of assets with similar security requirements; a conduit is the controlled communication path between zones. This model, derived from NIST SP 800-82 Rev. 3 [S1], is the foundation for all warehouse OT segmentation decisions.
• Default-deny is the editorial baseline: For automated warehouses, Pearl Gateway recommends that all inter-zone traffic be denied by default, with explicit rules created only for flows that map to a documented operational function such as a sortation command or a status telemetry read.
• Map flows before you draw the firewall: The segmentation design must begin with a flow inventory—source asset, destination asset, protocol, port, and the operational purpose—not with the network diagram. This prevents the common error of creating zones that look clean but do not match the actual material flow.
• Monitoring is a zone requirement, not an optional add-on: Every conduit must have a defined monitoring capability—whether via SPAN port, TAP, or native device logs—so that the security team can detect a policy violation without relying on the device that is being protected.
• Exceptions are owned by operations, not security: An exception to a default-deny rule must be approved by the operational owner (e.g., the maintenance manager or controls engineer) and the security team jointly, with a documented expiry and a scheduled review. This dual ownership prevents security from becoming a bottleneck and prevents operations from bypassing policy.
• Protocol awareness matters: The segmentation rules must account for the protocol behavior of OPC UA [S3] and MQTT [S4], which are common in modern warehouse telemetry. These protocols have specific port and session characteristics that influence how conduits should be configured.

Scope and terminology for warehouse OT segmentation #

This article addresses the network segmentation of operational technology (OT) within automated warehouses, specifically the systems that control material flow: conveyor controllers, sortation devices, automated storage and retrieval systems (AS/RS), and the supervisory systems that coordinate them. The scope is limited to the network layer—the rules, zones, and conduits that govern communication—and does not cover physical safety systems (e.g., light curtains, e-stops) which are governed by separate safety standards and should never be routed through general-purpose IT networks.

The terminology used throughout this article follows the definitions established in NIST SP 800-82 Rev. 3 [S1]. A zone is a grouping of logical or physical assets that share a common security policy based on the criticality of the function they perform and the consequences of a security failure. A conduit is the communication path—or the set of communication paths—between two zones, and it is the point where security controls (such as firewalls, data diodes, or application-layer gateways) are applied. The conduit is not the cable; it is the logical path that the data takes, and it may traverse multiple physical switches or routers.

This article uses the term “asset” to refer to any device with an IP address that participates in the control or monitoring of the warehouse. This includes PLCs, HMIs, industrial PCs, robotic controllers, vision systems, and the servers that host the warehouse control system (WCS) or warehouse management system (WMS). The term “flow” refers to a unidirectional or bidirectional communication session between two assets, characterized by source IP, destination IP, source port, destination port, and protocol.

Zone model for automated warehouses: a five-zone editorial recommendation #

While NIST SP 800-82 Rev. 3 provides the general framework for OT zones [S1], it does not prescribe a specific zone count or naming convention for warehouses. The following five-zone model is a Pearl Gateway editorial recommendation, designed to balance security granularity with operational manageability for a typical automated distribution center.

The rationale for separating Zone 0 (safety) from Zone 1 (control) is that safety functions must remain operable even if the control network is compromised. A cyber incident that disrupts the control network should not be able to disable safety monitoring. This is an editorial recommendation based on the principle of defense-in-depth articulated in [S1], not a specific requirement of any cited standard. The separation between Zone 2 and Zone 3 is equally important: the WCS is the brain of the automated warehouse, and a compromise of the business network (e.g., via a phishing email) should not give an attacker direct access to the WCS.

Mapping required flows: the inventory-first method #

The most common failure in warehouse OT segmentation is designing the network topology before understanding the data flows. The editorial recommendation is to perform a flow inventory as the first step, before any firewall rule is written. This inventory must be conducted by a team that includes the controls engineer, the maintenance manager, and the IT security analyst, because each brings a different perspective on what “required” means.

The flow inventory should be a table with the following columns: Flow ID, Source Asset, Source Zone, Destination Asset, Destination Zone, Protocol, Port(s), Direction, Operational Function, and Approval Status. The “Operational Function” column is the most important: it must describe the material-handling purpose of the flow, not just the technical purpose. For example, a flow from the WCS to a conveyor PLC might be described as “Send sortation command for parcel to lane 7” rather than “OPC UA read/write.” This description forces the operational owner to justify the flow in terms of the business function.

For each flow, the team must answer three questions:

1. Is this flow necessary for the warehouse to operate, or is it a convenience (e.g., a diagnostic read that could be performed on-demand)?
2. Could this flow be replaced by a less risky alternative, such as a one-way data historian read instead of a bidirectional write?
3. Who is the operational owner who will accept responsibility for the flow’s continued necessity?

This method is derived from the general risk management approach in NIST SP 800-82 Rev. 3 [S1], which emphasizes understanding the system before applying controls. The output of this inventory is the authoritative list of flows that the default-deny policy will explicitly permit. Any flow not on this list is, by definition, denied.

Default-deny boundaries: rule construction and placement #

The default-deny boundary is the enforcement point where the segmentation policy is applied. In a warehouse OT environment, this is typically a firewall (either a dedicated OT firewall appliance or a next-generation firewall with OT-specific protocol inspection) placed at the conduit between zones. The editorial recommendation is to apply the default-deny policy at every conduit, not just at the boundary between the IT and OT networks. This means that traffic between Zone 1 (Core Control) and Zone 2 (Supervisory) must be explicitly permitted, just as traffic between Zone 3 (Site IT) and Zone 2 must be.

The rule construction should follow a “least privilege” model, which is a core principle in [S1]. Each rule should specify the exact source IP, destination IP, protocol, and port. Using IP ranges or subnets in the rule is acceptable only if the zone is tightly defined and does not contain assets with differing security requirements. For example, a rule that allows “Zone 2 to Zone 1 on TCP 4840” is too broad if Zone 1 contains both a conveyor PLC and a robot controller, and the WCS only needs to talk to the conveyor PLC. The rule should be “WCS_Server_IP to Conveyor_PLC_IP on TCP 4840.”

Placement of the enforcement point is a critical decision. The firewall should be inline, meaning that all traffic between the zones must pass through it. A common mistake is to place the firewall in “shadow mode” (passive monitoring) and rely on it only for logging. This is not segmentation; it is observation. The firewall must be the only path between the zones. If there is a secondary path—for example, a maintenance laptop plugged directly into the control network—the segmentation is compromised.

For protocols that use dynamic ports, such as some OPC UA configurations, the rule must account for the session negotiation. The editorial recommendation is to use an application-layer gateway or a firewall with OPC UA inspection capability, rather than opening a wide port range. This is a practical consideration derived from the OPC UA specification [S3], which describes the session establishment and security model. The same applies to MQTT [S4], which typically uses TCP port 1883 (unencrypted) or 8883 (TLS). The firewall rule should specify the broker IP and the client IP, not just the port.

Conduit design: redundancy, bandwidth, and fail-open vs. fail-closed #

The conduit is the logical path between zones, and its design has direct implications for both security and operational reliability. The first consideration is redundancy. A warehouse that operates 24/7 cannot afford a single point of failure in the conduit. The editorial recommendation is to design the conduit with redundant firewalls in a high-availability pair, so that a firewall failure does not interrupt the flow. This is a standard high-availability architecture, and it is consistent with the operational reliability requirements of an automated warehouse.

The second consideration is bandwidth. The conduit must have sufficient capacity to carry the peak data load without introducing latency that affects control loops. For example, a conveyor PLC that sends a position update every 50 milliseconds (illustrative assumption) requires a certain bandwidth, and the conduit must be sized to handle the aggregate of all such flows. The bandwidth calculation should be performed during the flow inventory phase, not after the firewall is installed. The formula is straightforward: Total Bandwidth Required (bits per second) = Sum of (Message Size (bits) × Messages per Second) for all flows. This is a derived equation based on the stated assumption that bandwidth is the product of message rate and message size.

The third consideration is the fail-open vs. fail-closed behavior. A firewall that fails open (allowing all traffic) will keep the warehouse running but will expose the OT network to risk. A firewall that fails closed (denying all traffic) will protect the network but will likely stop the warehouse. The editorial recommendation is to design the firewall to fail closed, but to implement this with a redundant pair so that a single device failure does not trigger the fail-closed state. The fail-closed state should only occur if both firewalls fail simultaneously, which is an acceptable risk for most warehouse operations. This decision must be made jointly by the operations team (who will experience the downtime) and the security team (who will experience the risk).

Monitoring and visibility: what to watch on each conduit #

Segmentation without monitoring is a false sense of security. The default-deny policy will block unauthorized traffic, but the security team needs to know when a block occurs, and the operations team needs to know when a legitimate flow is being dropped due to a misconfiguration. The editorial recommendation is to implement monitoring on every conduit, with three specific data sources: firewall logs, flow records, and asset-level logs.

Firewall logs are the first line of defense. They should record every denied connection attempt, including the source IP, destination IP, protocol, port, and timestamp. The logs should be sent to a central SIEM (Security Information and Event Management) system, which should be configured to alert on patterns such as a single source IP attempting to connect to multiple destination IPs on the same port (a potential scan) or a source IP attempting to connect to a destination IP on a port that is not in the approved flow list.

Flow records (e.g., NetFlow or IPFIX) provide a higher-level view of the traffic that is being permitted. They show the volume of traffic between zones, which is useful for detecting anomalies such as a sudden increase in data transfer from a PLC to an unexpected destination. The flow records should be retained for at least 90 days (illustrative assumption) to support incident investigation.

Asset-level logs are the third source. The PLCs, HMIs, and servers should be configured to send their own logs (e.g., syslog) to the central logging system. These logs provide context that the firewall logs cannot, such as whether a specific engineering command was executed successfully. For OPC UA servers, the audit log should be enabled as described in the OPC UA security model [S3]. For MQTT brokers, the client connection and disconnection events should be logged [S4].

The monitoring infrastructure itself must be protected. The SIEM and log collector should be placed in a dedicated management zone, not in the general IT zone, to prevent an attacker from deleting logs after compromising the business network.

Exception ownership: the operational change process #

No segmentation policy can anticipate every future need. A new conveyor section may be added, a new sensor may be installed, or a vendor may need temporary access to troubleshoot a sorter. The exception process is the mechanism for handling these changes without weakening the overall security posture. The editorial recommendation is a formal exception process with three stages: request, approval, and review.

Request: The request must be submitted by the operational owner (e.g., the maintenance manager or the controls engineer) and must include the same information as the original flow inventory: source, destination, protocol, port, and operational function. The request must also include a proposed expiry date. The default expiry for a temporary exception should be 30 days (illustrative assumption). Permanent exceptions (e.g., a new flow that will be part of the standard operation) must go through the full flow inventory review, not the exception process.

Approval: The approval must be a joint decision between the operational owner and the security team. The security team verifies that the request does not conflict with existing rules and that the proposed monitoring will cover the new flow. The operational owner verifies that the flow is necessary and that there is no alternative. The approval must be documented, including the names of both approvers and the date of approval.

Review: The exception must be reviewed on a scheduled basis, at least monthly (illustrative assumption), to confirm that it is still needed. If the exception is no longer needed, it must be removed. If it is still needed, it can be renewed for another period. The review process should be automated as much as possible, with the SIEM generating a report of all active exceptions and their expiry dates.

This process is an editorial recommendation based on the general risk management principles in [S1], which emphasize the need for continuous monitoring and review. It is not a requirement of any cited standard, but it is a practical way to ensure that the segmentation policy remains aligned with the operational reality of the warehouse.

Protocol-specific segmentation: OPC UA and MQTT in the warehouse #

Modern automated warehouses increasingly rely on OPC UA for supervisory control and MQTT for telemetry and condition monitoring. These protocols have specific characteristics that must be considered when designing segmentation rules.

OPC UA is defined by the OPC Foundation in a multi-part specification [S3]. The default port for OPC UA is TCP 4840, but the specification allows for the use of other ports. OPC UA supports a client-server model, where the client (e.g., the WCS) connects to the server (e.g., the PLC). The security model in OPC UA Part 2 [S3] defines application authentication, user authentication, and message signing/encryption. For segmentation, the key point is that the firewall rule must be specific to the OPC UA server and client IP addresses, and the rule should be configured to allow only the OPC UA protocol, not all TCP traffic on port 4840. If the firewall supports deep packet inspection for OPC UA, it should be enabled to validate that the traffic conforms to the OPC UA specification.

MQTT is a publish-subscribe protocol defined by OASIS [S4]. It uses a central broker, and clients (publishers and subscribers) connect to the broker. The default ports are 1883 (unencrypted) and 8883 (TLS). For segmentation, the broker is a critical asset and should be placed in its own zone or in the supervisory zone (Zone 2). The firewall rules should allow clients in Zone 1 (e.g., PLCs publishing telemetry) to connect to the broker on port 8883, and should allow subscribers in Zone 2 or Zone 3 (e.g., a condition monitoring dashboard) to connect to the broker. The broker should be configured to require TLS, and the firewall should be configured to block plaintext MQTT (port 1883) to prevent credential or data exposure.

The editorial recommendation is to treat OPC UA and MQTT as high-value protocols that require application-layer inspection, not just port-based rules. This is a practical application of the security principles in [S1], which recommend that organizations understand the protocols used in their OT environment and apply controls accordingly.

Remote access zone: vendor support and engineering access #

Remote access is one of the highest-risk activities in a warehouse OT environment. Vendors need to access PLCs and robot controllers for troubleshooting, and engineers need to access the system from home or from a central engineering office. The editorial recommendation is to create a dedicated remote access zone (Zone 4) that is separate from both the control zones and the IT zone.

The remote access zone should contain a jump host (also known as a bastion host) that is the only entry point into the control zones. The jump host is a hardened server that the remote user must first connect to, and then from the jump host, the user can initiate a session to the target PLC or HMI. This design ensures that the remote user never has direct network access to the control zone; they only have access to the jump host, which is heavily monitored.

The remote access flow is as follows: Remote user → VPN → Remote Access Zone (Zone 4) → Jump Host → Target PLC (Zone 1). The firewall between Zone 4 and Zone 1 should only allow traffic from the jump host IP to the specific target PLC IPs, on the specific engineering protocol ports (e.g., TCP 44818 for EtherNet/IP, or the OPC UA port). The firewall should not allow traffic from the VPN client IP directly to the PLC IP.

All remote access sessions must be recorded. The jump host should have screen recording software installed, and the recordings should be retained for at least 180 days (illustrative assumption) for audit purposes. The session recording is a critical control for detecting malicious activity or accidental misconfiguration by a vendor. The remote access policy should require that all sessions are scheduled in advance, and that the operational owner is notified when a session begins and ends.

Worked example #

This example demonstrates the flow inventory and rule construction process for a hypothetical automated warehouse with a single conveyor line and a WCS. All numbers are illustrative assumptions.

Inputs:

• WCS server IP: 192.168.20.10 (Zone 2)
• Conveyor PLC IP: 192.168.10.20 (Zone 1)
• HMI IP: 192.168.10.30 (Zone 1)
• Protocol: OPC UA (TCP port 4840) [S3]
• Message size: 1,024 bytes (illustrative assumption)
• Message rate: 10 messages per second (illustrative assumption)

Intermediate calculations:

• Message size in bits: 1,024 bytes × 8 bits/byte = 8,192 bits
• Bandwidth per flow: 8,192 bits × 10 messages/second = 81,920 bits/second (approximately 82 kbps)
• Total bandwidth for the WCS-to-PLC flow: 82 kbps (assuming a single flow)

Result: The firewall rule for this flow should be: Allow 192.168.20.10 (WCS) to 192.168.20.20 (PLC) on TCP 4840. The rule should be placed on the conduit between Zone 2 and Zone 1. The bandwidth requirement for this flow is approximately 82 kbps, which is well within the capacity of a standard 1 Gbps firewall interface.

Sensitivity: If the message rate increases to 100 messages per second (illustrative assumption), the bandwidth requirement increases to 820 kbps. If the message size increases to 4,096 bytes (illustrative assumption), the bandwidth requirement increases to 328 kbps at the original rate, or 3.28 Mbps at the higher rate. The firewall must be sized to handle the peak load, which in this case is 3.28 Mbps.

Limitations: This calculation does not account for protocol overhead (e.g., TCP headers, OPC UA session management), which can add 10-20% to the bandwidth requirement. It also does not account for bursty traffic, where the message rate may spike for short periods. The firewall should be sized with a headroom factor of at least 2x the calculated peak load (illustrative assumption). This example only covers a single flow; a real warehouse will have dozens or hundreds of flows, and the aggregate bandwidth must be calculated.

Segmentation and material flow: aligning network zones with physical zones #

The network segmentation should reflect the physical layout and material flow of the warehouse. A conveyor system that moves parcels from receiving to shipping has a logical flow, and the control system that manages this flow has a corresponding data flow. The editorial recommendation is to align the network zones with the physical zones of the warehouse, where practical.

For example, a warehouse with a receiving area, a main sortation loop, and a shipping area might have three separate control zones, each with its own PLCs and HMIs. The WCS in the supervisory zone communicates with each of these control zones. The benefit of this alignment is that a failure or compromise in one physical zone (e.g., the sortation loop) does not directly affect the control of another zone (e.g., receiving). This is a form of fault isolation that is consistent with the security principle of least privilege [S1].

However, this alignment is not always practical. A single PLC may control multiple physical zones, or the material flow may be so tightly coupled that separating the control zones would introduce unacceptable latency. The editorial recommendation is to perform a trade-off analysis: the security benefit of smaller zones (reduced blast radius) versus the operational cost of more conduits and more complex routing. This analysis should be documented and reviewed by both the operations and security teams.

For specific material handling equipment, the segmentation should consider the control architecture. For example, a bomb-bay sorter has a specific control sequence for releasing parcels, and the PLC that controls this sequence should be in a zone with strict access controls. Similarly, a tilt-tray sorter has a high-speed control loop that should not be subject to network latency from unrelated traffic. The segmentation design should reference the specific operational documentation for these systems, such as the commissioning checklists and capacity planning guides available from Pearl Gateway.

Monitoring for operational anomalies: using segmentation data for maintenance #

The data collected from the segmentation monitoring infrastructure is not only useful for security; it can also be used for operational maintenance and condition monitoring. The flow records and firewall logs can reveal patterns that indicate equipment degradation or misconfiguration.

For example, a conveyor PLC that suddenly starts sending a higher volume of data to the WCS may be experiencing a fault that causes it to retransmit status messages. An MQTT telemetry stream that shows a gradual increase in message rate from a vertical lift module may indicate that the module is struggling to keep up with demand. The editorial recommendation is to integrate the segmentation monitoring data with the existing condition monitoring systems, such as those described in the Pearl Gateway documentation for zero-pressure accumulation and vertical lift modules.

This integration requires a clear data flow: the firewall and flow logs must be sent to the SIEM, and the SIEM must be configured to correlate the network data with the equipment telemetry. For example, a rule could be created that alerts when a specific PLC’s network traffic exceeds a threshold for more than 5 minutes (illustrative assumption). This alert would be sent to both the security team and the maintenance team, allowing them to investigate the cause.

This approach is an editorial recommendation that extends the security monitoring to serve a dual purpose. It is consistent with the NIST CSF 2.0 [S2] function of “Detect,” which includes the need to detect anomalies and events. By using the segmentation data for both security and operational purposes, the warehouse can maximize the value of its monitoring investment.

Segmentation and remote support: enabling safe vendor access #

Remote support is a critical requirement for automated warehouses, as vendors need to diagnose and fix issues quickly to minimize downtime. However, remote access is also a primary attack vector. The segmentation design must enable remote support while mitigating the risk.

The editorial recommendation is to use a “two-person rule” for remote support sessions. The vendor connects to the jump host in the remote access zone, and a member of the on-site operations team must be present to observe the session and approve each action. This is a procedural control that complements the technical controls of the segmentation architecture. The two-person rule is an editorial recommendation, not a requirement of any cited standard, but it is a widely accepted practice for high-risk OT environments.

The segmentation architecture should also support “break-glass” access for emergency situations. If a vendor needs immediate access to a PLC to prevent a catastrophic failure, the on-site team should have a pre-authorized procedure to temporarily open a specific firewall rule. This procedure must be documented, and the temporary rule must have an automatic expiry (e.g., 4 hours, illustrative assumption). The break-glass procedure should be tested regularly to ensure it works when needed.

The remote support session should be monitored using the same tools as any other OT traffic. The firewall logs should record the session, the jump host should record the screen, and the SIEM should generate an alert when a break-glass rule is activated. This ensures that the remote support activity is fully auditable.

Segmentation lifecycle: from design to decommissioning #

Segmentation is not a one-time project; it is a lifecycle that must be managed continuously. The lifecycle has five phases: design, implementation, operation, review, and decommissioning.

Design: The design phase produces the zone model, the flow inventory, and the firewall rule set. This phase should be documented in a detailed design document that is reviewed by both the operations and security teams.

Implementation: The implementation phase involves configuring the firewalls, switches, and monitoring tools. This phase should include a testing plan that verifies that the allowed flows work correctly and that the denied flows are blocked.

Operation: The operation phase is the day-to-day running of the segmentation architecture. This includes monitoring the logs, responding to alerts, and managing exceptions.

Review: The review phase is a scheduled assessment of the segmentation architecture. This should occur at least annually (illustrative assumption), and should include a review of the flow inventory, the exception list, and the firewall rule set. The review should also include a penetration test or a tabletop exercise to validate the effectiveness of the controls.

Decommissioning: When a piece of equipment is removed from the warehouse, the corresponding firewall rules and flow inventory entries must be removed. This is often overlooked, leading to a buildup of stale rules that increase the attack surface. The decommissioning process should be triggered by the operational team when they remove the equipment, and the security team should verify that the rules are removed.

This lifecycle is an editorial recommendation based on the continuous improvement principles in NIST CSF 2.0 [S2], which emphasize the need to “Govern,” “Identify,” “Protect,” “Detect,” “Respond,” and “Recover” as ongoing functions.

Common pitfalls in warehouse OT segmentation #

Several pitfalls are commonly observed when warehouses implement OT segmentation. The first is the “flat network” assumption, where all OT devices are placed in a single VLAN with no internal segmentation. This is often done for simplicity, but it means that a compromise of one device (e.g., an HMI) gives the attacker access to all other devices in the VLAN. The editorial recommendation is to avoid flat networks and implement at least the five-zone model described earlier.

The second pitfall is the “firewall as a silver bullet” assumption, where the organization believes that installing a firewall between IT and OT is sufficient. This ignores the need for internal segmentation, monitoring, and exception management. The firewall is a necessary control, but it is not sufficient on its own.

The third pitfall is the “static rule set” problem, where the firewall rules are set once and never reviewed. This leads to a buildup of stale rules and a gradual drift from the intended security posture. The lifecycle review phase is essential to prevent this.

The fourth pitfall is the “security vs. operations” conflict, where the security team implements strict controls that hinder operations, and the operations team bypasses the controls to get their work done. This conflict is best resolved by the joint exception ownership process described earlier, where both teams have a formal role in decision-making.

The fifth pitfall is the “unmonitored conduit” problem, where the firewall is installed but the logs are not reviewed. This is equivalent to having no firewall, as the organization will not detect a breach until it is too late. The monitoring requirements must be defined in the design phase, not after the firewall is installed.

When this guidance does not apply #

This guidance is specific to automated warehouses with networked OT systems, such as conveyor PLCs, sortation controllers, and robotic cells. It does not apply to the following scenarios:

• Standalone machines: If a machine is not networked and is controlled only by a local HMI, there is no network segmentation to perform. The security focus should be on physical access control.
• Safety systems: This guidance does not apply to safety-rated systems (e.g., safety PLCs, light curtains) that are governed by functional safety standards. These systems must not be routed through general-purpose networks, and the segmentation design must ensure that safety traffic is physically or logically isolated from all other traffic.
• Legacy systems without network capability: If a warehouse uses older equipment that communicates via serial links or proprietary fieldbuses without IP connectivity, the segmentation model described here does not directly apply. The security focus should be on the gateways that bridge these legacy systems to the IP network.
• Cloud-based WMS: If the WMS is hosted in the cloud, the segmentation boundary is the internet connection, and the controls must be applied at the cloud gateway and the on-premises edge. The zone model still applies, but the conduit is a WAN connection, not a local network link.
• Non-OT networks: This guidance does not apply to the general IT network (e.g., office PCs, printers, email servers). The IT network should be treated as a separate zone (Zone 3) and should be segmented from the OT zones, but the internal segmentation of the IT network is outside the scope of this article.

Revision and editorial note #

This article was prepared by the Pearl Gateway Editorial Team. It was reviewed against the listed sources [S1]–[S5] to ensure that all attributed facts are accurate and that the editorial recommendations are clearly distinguished from source-derived requirements. The article remains educational in nature and is intended to provide practical guidance for warehouse operators, controls engineers, and security professionals. It does not constitute a formal standard, nor does it replace the need for a site-specific risk assessment and design review. The editorial team welcomes feedback on this article and will consider it for future revisions.

Related Pearl Gateway guides #

• Conveyor Side Guides: Selection Criteria and Application Boundaries
• Zero-Pressure Accumulation: Data Signals and Condition Monitoring
• Curved Conveyor Sections: Capacity Planning and Bottleneck Analysis
• Bomb-Bay Sorters: Commissioning and Acceptance Checklist
• Tilt-Tray Sorters: Capacity Planning and Bottleneck Analysis

Implementation evidence matrix #

Sources and standards #

1. NIST — Guide to Operational Technology Security, SP 800-82 Rev. 3. In “OT Network Segmentation for Automated Warehouses: Zones, Conduits and Operational Exceptions”, source [S1] supports the attributed terminology or boundary; the warehouse-specific synthesis remains Pearl Gateway editorial analysis.
2. NIST — Cybersecurity Framework 2.0. In “OT Network Segmentation for Automated Warehouses: Zones, Conduits and Operational Exceptions”, source [S2] supports the attributed terminology or boundary; the warehouse-specific synthesis remains Pearl Gateway editorial analysis.
3. OPC Foundation — OPC UA Online Reference. In “OT Network Segmentation for Automated Warehouses: Zones, Conduits and Operational Exceptions”, source [S3] supports the attributed terminology or boundary; the warehouse-specific synthesis remains Pearl Gateway editorial analysis.
4. OASIS — MQTT Version 5.0 Specification. In “OT Network Segmentation for Automated Warehouses: Zones, Conduits and Operational Exceptions”, source [S4] supports the attributed terminology or boundary; the warehouse-specific synthesis remains Pearl Gateway editorial analysis.
5. W3C — Trace Context Recommendation. In “OT Network Segmentation for Automated Warehouses: Zones, Conduits and Operational Exceptions”, source [S5] supports the attributed terminology or boundary; the warehouse-specific synthesis remains Pearl Gateway editorial analysis.

Revision and editorial note #

The Pearl Gateway Editorial Team prepared “OT Network Segmentation for Automated Warehouses: Zones, Conduits and Operational Exceptions” from the five linked source records. The published guide remains educational and requires site evidence before application.