Who is accountable when OT segmentation fails?

Why This Matters for Security Teams

ot segmentation is not just a network design choice. It is a control boundary that affects safety, availability, and recovery if an attacker moves from business systems into industrial environments. When segmentation fails, the real question is not whether a firewall rule existed, but whether the organisation assigned clear ownership for asset visibility, rule approval, exception handling, and operational change control. That is why accountability should be traced across engineering, security, and governance rather than pushed into a single team.

Security teams often misread segmentation as a point-in-time configuration task. In reality, it is a living control that depends on accurate asset inventories, traffic baselines, and disciplined maintenance of allowlists, zones, and conduits. Current guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that control effectiveness depends on implementation, monitoring, and review, not merely on design intent. In practice, many security teams encounter OT segmentation failure only after a maintenance exception, undocumented legacy connection, or remote vendor path has already been abused.

How It Works in Practice

Accountability for OT segmentation should be mapped to the control lifecycle, not to a single technical checkpoint. OT engineering typically owns the process impact of segmentation decisions because it understands what traffic is required for safety and operations. Security architecture owns the policy model, segmentation standards, and verification logic. Governance leaders own risk acceptance, exception approval, and evidence that the control is still fit for purpose.

A practical operating model usually includes:

• Defined asset ownership for every OT zone, cell, and critical connection.
• Documented segmentation standards that specify permitted protocols, peers, and trust boundaries.
• Formal change control for temporary access, remote support, and maintenance windows.
• Continuous validation using logs, network telemetry, and rule review against approved flows.
• Exception registers with expiry dates, business justification, and named approvers.

This is where the identity and access side becomes relevant. Many OT segmentation failures are enabled by overprivileged service accounts, shared vendor credentials, or unmanaged remote access paths. A Zero Trust style approach can help, but it only works when identity, device trust, and network enforcement are coordinated. The NIST Zero Trust Architecture guidance at NIST SP 800-207 Zero Trust Architecture is useful here because it treats access as continuously evaluated rather than permanently trusted.

For operational teams, the key evidence is simple: who approved the segmentation design, who owns the asset inventory, who can change the enforcement points, and who signs off when a deviation is introduced. Those four questions should produce four named accountabilities, even if the same executive sits above them. These controls tend to break down when legacy OT protocols, unmanaged vendor tunnels, and stale asset inventories collide in plants where maintenance access has become the de facto production access path.

Common Variations and Edge Cases

Tighter segmentation often increases operational overhead, requiring organisations to balance isolation against uptime, maintenance speed, and vendor support needs. That tradeoff becomes sharper in brownfield OT environments where legacy systems cannot easily support modern authentication, granular policy enforcement, or frequent configuration changes.

There is no universal standard for accountability mapping in OT, so best practice is evolving. In highly regulated sectors, governance may sit with a risk committee or plant leadership, while technical ownership remains distributed between control engineers and infrastructure teams. In outsourced environments, the service provider may operate the firewall or remote access gateway, but accountability for risk acceptance still stays with the asset owner. This is an important distinction: operational responsibility can be delegated, but risk ownership cannot.

Edge cases also arise when segmentation is implemented through a mixture of industrial firewalls, data diodes, jump hosts, and cloud-managed remote access. The more tools involved, the easier it is for gaps to appear between design, enforcement, and evidence collection. Where segmentation supports critical manufacturing or utility operations, practitioners should align control ownership to resilience goals and incident response requirements, not just to network diagrams. Guidance from CISA Defending ICS and OT is especially relevant when remote maintenance, legacy protocols, or third-party support pathways are part of the environment.

Related resources from NHI Mgmt Group

• Who should be accountable for IT/OT segmentation decisions?
• Who is accountable when a healthcare segmentation project fails to stop lateral movement?
• What is the difference between OT network segmentation and identity-based access control?
• Who is accountable when an identity governance programme fails?