
For years, production networks were built as broad, flat environments based on the assumption that anything inside was trusted. An engineering workstation, operator panel, historian server that archives process data, programmable logic controller, and vendor maintenance device may all operate on the same network. Although this structure simplifies operations, it also makes it easier for a compromised endpoint to reach critical processes.
Operational technology (OT) covers systems that monitor or control physical processes. OT security must protect more than data. Safety, continuity, product quality, and correct equipment behavior all matter. Microsegmentation is therefore not an enterprise IT template copied into a factory. It is a risk-reduction effort designed with knowledge of the physical process.
What microsegmentation is and is not
Microsegmentation divides assets into smaller security zones according to function, criticality, and communication requirements. Traffic between zones passes through defined control points, and only necessary flows are permitted. The goal is to limit an attacker’s progression from one system to another, known as lateral movement, if a breach occurs.
Every device does not need to be placed on a separate network. Zone size depends on risk and operational requirements. Microsegmentation also means more than creating many virtual local area networks (VLANs). VLANs can separate traffic domains, but if traffic moves between zones, a VLAN alone is not an adequate security boundary unless security policies govern those flows. Success depends on knowing the permitted flows and enforcing that policy technically.
Start with an inventory and data-flow map
The first step is a current OT asset inventory that includes hardware, software, communication protocol, firmware version, physical location, process role, and business owner. NIST’s security-segmentation approach for small manufacturing environments is likewise based on grouping assets according to their communication and security requirements.
Next, map normal data flows. Identify which devices communicate, through which protocol and port, in which direction, and how often. Uncontrolled active scanning can interrupt legacy or sensitive devices, so it is safer to begin with passive network visibility and existing switch records. Confirm unknown traffic with the process engineer before blocking it.

Designing zones and conduits
Under the ISA/IEC 62443 approach, assets with similar security requirements are grouped into a zone, while controlled communication paths between zones are called conduits. Enterprise IT, an industrial demilitarized zone (DMZ), manufacturing operations, cell or area control, and the safety system can be separate zones within a facility. Safety-critical systems may require physical separation.
An industrial DMZ is an intermediary zone that prevents direct, uncontrolled communication between the enterprise network and OT. A replicated historian, file-transfer gateway, remote-access jump server, and update repository can be placed there. This allows business data to be shared without permitting an enterprise endpoint to sign in directly to the control network.

Policy: Deny by default and permit only what is required
NIST SP 800-82 Rev. 3 recommends configuring network isolation devices according to mapped data flows and, where possible, using a “deny all, permit by exception” policy. A rule should define not only source and destination Internet Protocol (IP) addresses, but also the protocol, port, direction, and, where needed, command type. Broad rules such as “allow everything into the OT network” or “any-any” make segmentation ineffective.
The enforcement point may be an industrial firewall, a router access list, a switch policy, or, in some scenarios, a unidirectional gateway. Product selection should not determine the architecture. Required communications and the risk model should be documented first. Rules should be version-controlled, and temporary exceptions without an owner or justification should expire automatically.
Continuity and safety matter as much as security
OT traffic can be sensitive to latency, and some devices have limited resources. Controls such as deep packet inspection, encryption, or frequent reauthentication may affect the process if they are not tested in the right place. Where possible, test policy in an environment separated from production, such as a laboratory, testbed, or validated digital twin. Prepare a maintenance window, rollback configuration, and offline backup for production changes.
The design must also define how the system enters a safe state if access is interrupted. The cybersecurity team, control engineer, safety officer, and production owner should approve the same change plan. The value of microsegmentation is not in stopping production. It lies in preserving necessary communication while reducing the potential impact of faults and attacks.

Address remote access and visibility together
When a maintenance provider connects to OT through a device exposed directly to the internet or a shared virtual private network (VPN) account, an invisible path crosses the zone boundary. Remote access should be restricted through multifactor authentication, individual accounts, time-limited authorization, an approved jump server, and session recording. A user should be able to reach only the asset and protocol needed for the maintenance task.
All connections between zones should be logged centrally, and failed attempts and unexpected protocols should be monitored. CISA likewise treats restricting and monitoring IT–OT connections and making unauthorized connections visible as core protection goals. An alert that lacks production context, however, will quickly become background noise for the team.
Common mistakes
The most common mistake is writing rules from an incomplete inventory. A forgotten engineering connection may be cut during production. The second is placing a firewall only between IT and OT while leaving the OT network flat. If a threat passes the intermediary zone, it can still move freely between production cells.
Other mistakes include treating a VLAN as a security control on its own, leaving vendor remote access out of scope, keeping temporary rules open for years, using shared administrator accounts, and failing to test rollback plans. Segmentation is not a one-time project. The flow map and rules must be updated whenever a new machine, recipe, software release, or integration is introduced.
Sector use cases
In automotive and general manufacturing, each production cell, quality system, and engineering workstation can be placed in a separate risk zone. In food and pharmaceutical production, separating recipe management from packaging lines can help protect quality and traceability processes. In energy and water facilities, controlled conduits can connect stations, field communications, and central control.
In logistics, flows between conveyors, warehouse automation, and enterprise planning systems can be restricted. In smart buildings, badge access, cameras, heating, ventilation, and air conditioning (HVAC) systems can be kept in zones separate from the office network. Every sector should ask the same question: What physical consequence would follow if this communication were interrupted or misused?
A phased implementation roadmap
In the first phase, create the asset inventory and build a passive view of flows across the organization’s normal operating cycles. In the second, design zones, permitted conduits, and target security levels according to process criticality. In the third, select one noncritical cell as a pilot and validate the rules in monitoring mode first.
In the fourth phase, enforce the policy during a maintenance window and complete production and safety tests. In the fifth, extend the architecture to other lines and integrate central logging, remote access, and change management into the process. Finally, make rule ownership, periodic review, exception duration, and incident exercises part of the permanent governance model.
Where to start: A short checklist
· Are the function, owner, version, and physical location of critical OT assets known?
· Are normal communication flows recorded with source, destination, protocol, direction, and frequency?
· Is there an industrial DMZ between IT and OT, and have direct connections been removed?
· Do policies between zones use default denial and documented exceptions?
· Is remote access individual, time-limited, multifactor-protected, and recorded?
· Is a production test and rollback plan ready for every policy change?
Sources
· NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security (https://csrc.nist.gov/pubs/sp/800/82/r3/final)
· NIST SP 1800-45 — Cybersecurity for the Water and Wastewater Sector: Build Architecture (Operational Technology Remote Access) (https://csrc.nist.gov/pubs/sp/1800/45/final)
· NIST CSWP 28 — Security Segmentation in a Small Manufacturing Environment (https://www.nist.gov/publications/security-segmentation-small-manufacturing-environment)
· ISA — ISA/IEC 62443 Series of Standards (https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards)
· CISA — Cross-Sector Cybersecurity Performance Goals (https://www.cisa.gov/cybersecurity-performance-goals)
· NIST SP 800-207 — Zero Trust Architecture (https://csrc.nist.gov/pubs/sp/800/207/final)
