How should security teams extend Zero Trust segmentation into OT environments without changing fragile devices?

Why Zero Trust for OT Must Stop at the Boundary of the Device

Extending segmentation into OT is not the same as treating OT like IT. Industrial controllers, safety systems, and embedded devices often have fixed operating profiles, long maintenance cycles, and vendor support limits that make endpoint agents, frequent change, or invasive inspection unrealistic. zero trust in this setting is therefore a placement problem as much as a policy problem: controls have to protect the environment without altering the device.

That is why the discipline is to enforce policy at the network and access layers around the asset, not inside it, while still maintaining enough visibility to understand what normal traffic looks like. The operating risk is simple: if the segmentation design assumes modern host controls that the plant cannot support, the result is either unmanaged exceptions or broken production. In practice, many security teams discover this only after a fragile device has already failed a compatibility test or an outage has exposed an overreliance on passive trust.

For a baseline reference on the broader model, NIST’s Zero Trust Architecture guidance is useful, but OT teams have to adapt it to physical-process constraints rather than copy IT deployment patterns.

How Segmentation Works When the Asset Cannot Be Touched

The practical pattern is to start with discovery, then define the smallest set of communication paths the OT asset truly needs, and then enforce those paths at a switch, firewall, remote access gateway, or other control point that sits outside the device. That keeps the device untouched while still shrinking the reachable surface. Where possible, teams should segment by function and trust zone rather than by flat plant-wide VLANs, because broad zones tend to preserve hidden lateral movement even after a Zero Trust project is declared complete.

In OT, the policy is often built from observed traffic rather than from software agents or endpoint telemetry. Passive monitoring, flow analysis, and engineering knowledge of which protocols and peers are expected become the basis for the allow list. The control objective is not perfect inspection everywhere. It is to make unauthorised east-west movement materially harder and to make abnormal connections visibly exceptional.

• Map each asset to its required peers, protocols, and management dependencies before writing policy.
• Place enforcement at a choke point that can be changed safely without altering the device.
• Prefer narrow, explicit allow lists over broad subnet trust or generic “OT business need” exceptions.
• Test policy changes in maintenance windows, because a technically correct rule can still disrupt safety, timing, or vendor support workflows.

This approach breaks down when the organisation cannot reliably identify legitimate industrial traffic, when undocumented dependencies exist between systems, or when network enforcement points are too coarse to separate critical functions from noisy but tolerated communications.

Where OT Segmentation Gets Harder Than IT Segmentation

Tighter segmentation often increases operational friction, requiring organisations to balance security gain against engineering stability, vendor constraints, and plant uptime. In OT, that trade-off is sharper than in standard enterprise networks because some traffic is intermittent, some protocols are fragile, and some assets cannot tolerate deep packet handling or frequent rule churn.

The biggest edge case is legacy equipment that only behaves correctly when it can talk broadly within a segment. Another is remote maintenance, where a third party may need limited access but the access path is also a common source of over-privilege. There is also a genuine consensus gap in the industry about how much protocol-level inspection should be used in safety-adjacent environments. The safe position is to treat inspection depth as a constrained design choice, not a default requirement, and to favour segregation, strong access paths, and monitored exceptions when the device class cannot support more intrusive controls.

Zero Trust also becomes less effective when it is applied only at the perimeter of the plant and not between cells, lines, or critical zones. That leaves an attacker or a misrouted connection with too much freedom once inside. The better pattern is progressive containment: isolate by function, validate dependencies, and accept that some OT devices will remain operationally “untouched” while the surrounding network architecture carries the burden of control.

Risk and Threat Considerations

The material risk in OT segmentation projects is that the control design either weakens the process environment or fails to contain lateral movement. Fragile devices often cannot host agents, tolerate aggressive inspection, or absorb frequent policy changes, so misplaced trust in device-based controls can create both availability risk and security blind spots.

Failure mechanism: Weak segmentation usually appears when teams rely on broad exceptions, static flat-network habits, or unsupported endpoint controls that never truly reach the industrial asset. Attackers and malware then exploit shared trust zones, remote access paths, or overly permissive allow lists to move between systems after the first foothold.

Impact: The consequence is wider operational exposure, harder containment during an incident, and higher odds that a compromise of one workstation, jump host, or vendor path can affect multiple OT assets or disrupt production.

Practitioner Guidance

What to prioritise: Start with the assets whose compromise or outage would create the largest operational consequence, then build segmentation around those dependencies first. In OT, broad “cover the whole plant” projects often leave the most critical pathways least understood.

What to verify: Confirm that every allow rule maps to an observed or explicitly engineered dependency, not to an assumption about how the environment should behave. If a connection cannot be justified, it should be treated as a candidate exception, not as inherited trust.

What practitioners underestimate: The hardest part is usually not writing the policy but proving that it will remain stable across vendor service, maintenance, and recovery scenarios. The practical test is whether the segment can survive change without creating a hidden bypass.

Practitioner takeaway: In OT, Zero Trust segmentation succeeds when control is moved around the device, not forced onto it, because containment is only useful if the plant can still run safely after the change.

Related resources from NHI Mgmt Group

• How should security teams extend Zero Trust to unmanaged devices and shadow IT without slowing employees down?
• How should security teams extend Zero Trust across hybrid and offline Microsoft environments without weakening phishing resistance or MFA resilience?
• How should security teams apply zero trust to OT without disrupting operations?
• How should security teams roll out Zero Trust segmentation without disrupting the business?