A building can lose access control, HVAC visibility, camera monitoring, or critical process control without a single piece of equipment failing. One compromised workstation, an unmanaged vendor connection, or a flat network can give an ordinary IT incident a path into operational technology. An OT network segmentation strategy is how owners stop that path before it becomes downtime, a safety issue, or a tenant-facing failure.
Segmentation is often reduced to a diagram with a few virtual LANs and a firewall between IT and OT. That is not enough. Real segmentation defines which systems may communicate, why they need to communicate, who approves the connection, and how that rule is tested and maintained after the project team leaves.
For commercial properties and enterprise facilities, the challenge is rarely a lack of products. It is fragmented ownership. The building controls contractor, cabling installer, network team, security provider, facilities department, and remote support vendor may each touch the environment, yet nobody owns the operating model as a whole. Segmentation only works when one standard governs the full environment.
What Segmentation Must Protect
OT includes the systems that observe or control physical operations: building automation, electrical monitoring, generators, lighting controls, elevator interfaces, access control, video systems, environmental sensors, industrial equipment, and related supervisory platforms. These systems have different failure consequences than business applications.
A finance application can often tolerate a short interruption while a team restores service. A control network may support occupied spaces, equipment protection, life-safety-adjacent functions, or a process that cannot be casually restarted. Some OT devices also have long lifecycles, limited processing capacity, and patching constraints. That changes the security approach.
The goal is not to isolate every device from every other device. That can create its own operational failures. The goal is to limit unnecessary pathways so a compromise, configuration error, or malfunction remains contained within the smallest practical area. This is blast-radius control, not network decoration.
A sound design starts by separating business IT, OT supervisory systems, field controllers, physical security platforms, guest or tenant networks, and third-party access. Within those areas, further separation may be necessary for buildings, floors, critical equipment groups, or systems with different risk profiles. The right boundary depends on operational dependencies, not an arbitrary network template.
Build the OT Network Segmentation Strategy Around Flows
Do not begin with firewall rules. Begin with an accurate picture of the equipment and communications that already exist or will exist at turnover.
For every OT asset group, identify the system owner, physical location, function, network address, operating system or firmware where available, support status, and upstream dependency. Then document the allowed communications: source, destination, protocol, port, direction, purpose, and business owner. If a connection cannot be explained in plain language, it should not be assumed to be permanent.
For example, a building automation server may need scheduled, restricted communication to its field controllers and a defined route to a reporting platform. It does not need open access to user workstations, tenant networks, or every device in the corporate environment. A camera management platform may need video traffic from designated camera segments and tightly controlled access from approved operator workstations. It does not need a broad path to unrelated building controls.
This exercise exposes common ownership gaps. A remote technician may have been given broad access years ago because the project schedule was tight. A controller may sit on the same subnet as office devices because the original installer needed a quick commissioning path. A new cloud service may have been added without confirming whether its outbound traffic crosses the intended OT boundary. These are not just technical defects. They are unmanaged operational decisions.
Separate zones by consequence, not convenience
A practical zone model typically includes an enterprise IT zone, an OT supervisory zone, dedicated field-device zones, a security systems zone, and a controlled remote-access zone. A demilitarized zone may be appropriate where data must move between IT and OT, especially for reporting, analytics, historian functions, or vendor-managed services.
The exact model depends on the facility. A single office building with limited controls will not need the same structure as a multi-site portfolio, data environment, healthcare-adjacent facility, or industrial operation. But the design principle is consistent: communications between zones should be explicit, narrowly allowed, logged where practical, and accountable to an owner.
Avoid treating a virtual LAN as a security boundary by itself. VLANs help organize traffic, but they do not prevent inappropriate communication unless routing and firewall policy enforce the intended separation. Likewise, a firewall with broad “allow any” rules may create the appearance of control while preserving the risk of a flat network.
Design for the Built Environment
Network segmentation decisions are shaped by physical infrastructure. Telecom room locations, fiber pathways, power resilience, switch capacity, cabinet access, labeling, and the placement of controllers all affect whether the intended architecture can actually be operated.
If OT switches share an unsecured closet with general-purpose network equipment, physical access can bypass carefully written policy. If field controllers are connected through undocumented switches above ceilings or in electrical rooms, the asset inventory is already incomplete. If a construction team substitutes equipment without updating drawings, port maps, and configuration standards, final acceptance becomes guesswork.
This is why segmentation belongs in design reviews, not only cybersecurity meetings. The network design, structured cabling plan, electrical coordination, equipment schedule, and commissioning process need to agree on where each system lives and who has authority to change it.
At turnover, require more than an as-built diagram. The operating team needs current switch configurations, firewall policy documentation, IP address records, controller inventories, admin account ownership, backup procedures, remote-access procedures, and a clear escalation path. Documentation that cannot support a troubleshooting event at 2:00 a.m. is not operational documentation.
Control Vendor Access Without Stopping Support
Third-party support is necessary in many OT environments. It is also one of the most common routes around segmentation. Permanent remote connections, shared credentials, and vendor accounts with broad network access turn a manageable support arrangement into a standing exposure.
Vendor access should enter through a controlled remote-access zone, not directly into an OT subnet. Access should be tied to a named individual, protected by multifactor authentication, limited to approved systems, and available only when the support task requires it. Sessions should be logged, and the responsible internal owner should know what access exists.
There is a trade-off. Tighter controls can add time when a vendor needs urgent access. The answer is not to leave an unrestricted path open forever. Establish an emergency process in advance, including who can authorize access, how the session is monitored, and how permissions return to their normal state afterward. Fast response and disciplined control can coexist when the process is designed before an incident.
Test the Architecture Like an Operating Control
A segmentation project is not complete when configuration is loaded. It is complete when the organization can prove that permitted functions work and prohibited paths fail.
Validation should include functional testing of building and security workflows, verification of firewall rules against the approved communications matrix, checks that remote access reaches only approved targets, and confirmation that logging and alerting are visible to the right team. Test failure scenarios as well. Can an office workstation reach a field controller when it should not? Can a compromised camera segment reach the building automation server? Does loss of a reporting connection interrupt local control?
Record the results, exceptions, and remediation owner. Exceptions may be justified, particularly with legacy equipment or proprietary protocols, but each one needs a documented reason, compensating control, expiry date where applicable, and accountable approver. “The vendor requires it” is not a complete risk decision.
Keep Segmentation From Decaying
Networks drift. A controller is replaced. A vendor changes its support method. A new tenant system is connected. An emergency rule is added and never removed. Without governance, a carefully designed segmented environment gradually becomes flat again.
Treat segmentation as a lifecycle control. Review asset inventories and firewall rules on a set schedule and after any material project, incident, or vendor change. Include OT network review in change management, contractor turnover, vulnerability review, and business continuity exercises. Facilities, IT, security, and service providers should work from the same records and the same acceptance standard.
The strongest segmentation programs do not depend on one engineer remembering why a rule exists. They make the decision visible, testable, and owned. When every connection has a purpose and every exception has an accountable owner, the building is far less likely to inherit risk from the gaps between vendors.