How should organisations govern segmentation across IT and OT boundaries?

How IT and OT segmentation should be governed

Segmentation across it and ot boundaries works best when it is treated as a controlled operating model, not a diagram or a firewall rule set. The governance question is who may request reachability, who approves it, how it is time-bounded, and how the decision is revalidated when systems, vendors or production processes change. That keeps segmentation aligned to business need instead of convenience.

In practice, the boundary should be defined by business function and safety impact, then translated into enforceable technical zones. The organisation should distinguish corporate IT traffic, supervisory access, engineering workstations, plant systems and any shared services that genuinely must cross the boundary. That is the point where governance becomes architectural: the allowed paths are designed deliberately, not discovered after the fact.

For OT environments, the governance model should be explicit about uptime and change control. A segmentation rule that is elegant on paper can still be unacceptable if it interrupts maintenance, telemetry, or recovery workflows. The governing principle is therefore least necessary reachability with operational accountability, which is why exceptions need ownership, expiry and review rather than permanent approval.

Zones, gateways and exception handling as operational controls

Good segmentation governance starts by making zones and conduits visible. Each gateway, jump path, data diode, remote access method or protocol translator should have a named owner, an approved purpose, and a documented dependency on a business service. If the organisation cannot explain why a connection exists, it should not remain a standing route.

Exceptions are the central governance object because they are where IT and OT risk converges. A permitted flow may be legitimate, but it should still be governed against OT security guidance and reviewed like any other operational risk acceptance. That means checking whether the exception still needs to exist, whether the scope is narrow enough, and whether monitoring is in place to detect misuse or drift.

The review process should also account for shared identity and access paths. When the same remote administration route, jump host or credential set is used across multiple zones, the segmentation boundary is weaker than it appears. A stronger model is to pair segmentation with Zero Trust Architecture, so connectivity is continuously justified and limited to the minimum necessary task rather than inherited from network location alone.

What good segmentation governance looks like over time

Segmentation governance should be run as a lifecycle process, not a one-off deployment. That means periodic review of allowed flows, asset inventory, remote access methods, and plant changes that alter the original risk decision. If the technical boundary is not revalidated after projects, outages or vendor changes, the organisation will accumulate silent exceptions until the network no longer matches the intended control model.

Ownership matters because IT and OT teams measure success differently. Security may optimise for containment, while operations may optimise for availability and maintenance efficiency. The right governance structure forces those priorities into the same decision record, so changes are judged against both security exposure and plant impact. CISA industrial control systems guidance is useful here because it reinforces that critical infrastructure segmentation must be operationally realistic, not just theoretically restrictive.

A mature programme also treats logging and validation as part of the boundary itself. If a permitted path is used, the organisation should know who used it, for what system, and under what change or ticket reference. That is the difference between a controlled exception and an invisible backdoor. It also aligns well with broader governance expectations in NIST Cybersecurity Framework 2.0, especially where governance, protect and recover activities need to remain coordinated.

Risk and Threat Considerations

IT and ot segmentation fails when exceptions become normalised and routes are left open for convenience. At that point, the organisation inherits a larger attack surface, weaker containment, and a higher chance that compromise in one environment can reach production or supervisory assets.

Failure mechanism: The boundary weakens when shared administration paths, long-lived exceptions, or poorly reviewed gateways create persistent cross-zone reachability. Attackers then look for the least defended bridge between IT and OT, often through remote access, credential compromise, or over-permissive conduits.

Impact: A single exposed path can convert a contained IT incident into OT disruption, safety exposure, or prolonged recovery effort. The practical consequence is not only more access, but more blast radius, slower containment, and greater pressure to choose between security controls and uptime.

Practitioner Guidance

What to prioritise: Govern the exceptions first. The most useful control is usually not another segmentation diagram, but a disciplined register of who approved each cross-boundary flow, why it exists, when it expires, and what compensating monitoring is attached.

What to verify: Confirm that every permitted IT-to-OT path has an owner in operations and an owner in security, because split accountability is what keeps uptime and containment decisions visible. If no one can defend a route as operationally necessary, it is probably legacy connectivity rather than governed access.

Decision rule: If a flow is needed for maintenance, telemetry or recovery, narrow it to the specific asset, protocol and time window required; if it is only there for convenience, remove it or redesign the process. The practitioner takeaway is that segmentation succeeds when reachability is treated as a managed business decision with expiry, evidence and ownership, not as a standing network entitlement.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?