OT Cybersecurity Fundamentals

In OT environments, cybersecurity is often decided well before any tools are introduced.

On the one hand, there is the reality that most industrial systems can't be patched frequently, and many can't support endpoint agents that would help scale the process without impacting critical operations. On the other, there are production expectations that limit how many changes and updates can be introduced into a system without disrupting day-to-day operations. These forces mean that the cybersecurity controls that hold up over time, they're built into how the network itself is structured.

How systems are segmented, how communication is allowed to move, and how access is handled all play a much bigger role than any single security product. When those elements are designed intentionally, they reduce exposure in a way that doesn’t depend on constant updates or intervention.

This is what OT cybersecurity looks like in practice: not something layered on top of the network, but something that comes from how the network is built in the first place.

The Core Idea: Reduce Exposure By Design

In industrial environments, the goal isn’t to block every possible threat—it’s to limit what’s possible to begin with.

Because OT systems tend to have long lifecycles, limited patch windows, and a mix of vendors and legacy equipment, it’s not realistic to rely on reactive controls alone. Instead, the focus shifts to reducing exposure through structure.

That means designing the network so that critical systems aren’t easily reachable, communication behaves in predictable ways, and problems stay contained to where they originate.

When that’s done well, the outcomes are straightforward:

• access is controlled
• traffic is easier to understand
• recovery is faster because issues don’t spread as easily across unrelated systems

This is why architecture plays such a central role in OT cybersecurity: it defines the boundaries that everything else depends on.

Segmentation: The Backbone of OT Security

Segmentation is what turns a planned architecture into something reliable and scalable.

The Purdue Model (PERA) is often used as a reference point, not because it needs to be followed rigidly, but because it gives teams a shared way to think about separation. Control systems, supervisory systems, and business systems each operate differently, and grouping them into distinct layers helps reinforce those differences.

One of the most important parts of that structure is the Plant DMZ, which sits between OT and IT as a controlled boundary. Systems that need to exchange data across that boundary (historians, data brokers, jump hosts, update services) are placed there so communication can be monitored and managed without creating direct pathways into control environments.

The key idea is that business systems shouldn’t have direct access to production systems. Instead, communication is routed through controlled points where it can be understood and limited.

Segmentation, in that sense, is less about organizing the network and more about defining where communication is allowed to happen—and, arguably more importantly, where it isn’t.

Boundaries and Pathways: What’s Allowed to Talk

Once those boundaries exist, the next step is defining how systems are allowed to communicate across them.

In OT environments, communication is usually very specific. Devices talk to known systems, using known protocols, for defined purposes. That makes it possible to move away from the idea of “connected networks” and instead focus on clearly defined pathways.

Each pathway answers a simple set of questions: what needs to communicate, where it needs to go, and which ports or protocols are required. From there, controls like firewalls and ACLs are used to enforce those rules.

The goal here is to make sure that only the necessary communication is allowed, and that it happens in a way that can be understood and maintained over time. Without that structure, it’s easy for convenience to take over, and for systems to begin communicating simply because they can—not because they should.

VLANs and Segmentation Done Correctly

VLANs are often used to organize OT networks, but they don’t create meaningful segmentation on their own. It’s common to see environments where VLANs are in place, but there are no controls limiting how traffic moves between them. From a diagram perspective, the network looks segmented, but from a behavior perspective, it still functions as flat.

This is where “VLAN theater” shows up.

Over time, segments get added without a clear purpose, temporary rules remain in place, and broad access permissions start to override the original design. The result is a network that appears structured but doesn’t actually limit exposure.

Real segmentation requires enforcement. Systems are grouped based on function and criticality, and communication between those groups is explicitly controlled. Without that, VLANs become labels rather than controls.

Traffic Management Is Security…Because It Protects Availability

In OT environments, availability is a core part of security.

If communication becomes unpredictable, production is affected, and that impact is often more immediate than any external threat. Because of that, managing how traffic behaves across the network is just as important as controlling access.

Broadcast and multicast traffic, in particular, need to be handled intentionally. Without limits, they can expand in ways that affect large portions of the network, especially in environments where segmentation isn’t enforced. A single misbehaving device can introduce enough noise to impact systems well beyond where the issue started.

Keeping traffic predictable means constraining where that communication is allowed to occur and making sure it stays within defined boundaries.

Visibility supports this as well. Being able to observe traffic through diagnostics like port mirroring or other monitoring approaches makes it possible to confirm that the network is behaving as expected, rather than relying on assumptions.

Secure Remote Access: Design, Don’t Accumulate

Remote access is one of the most common ways exposure is introduced into OT environments.

In many cases, access has been added over time to support vendors, integrators, and internal teams. Each addition solves a problem, but over time, those pathways accumulate, and it becomes harder to track who can access what and how.

The issue isn’t remote access itself, it’s the lack of structure around it.

When remote access is treated as part of the architecture, those pathways can be defined and controlled. Entry points are centralized, access is routed through known systems (often within the DMZ), and communication is limited to what’s required. This makes access easier to understand, easier to audit, and easier to manage without slowing down operations.

Monitoring and Management Without Overreach

Monitoring in OT doesn’t need to be complex to be effective. The goal is to understand how the network is behaving and to catch changes that don’t align with expectations.

That includes:

• Unexpected communication between systems
• Changes in traffic patterns
• New or unknown devices
• Management access

The focus isn’t on adding layers. It’s on making sure the structure that’s in place can be observed and maintained.

FAQs

Is OT cybersecurity mostly a network problem?

In many cases, OT cybersecurity is mostly a network problem—because the network is where access is controlled and communication is defined, especially in environments where endpoint controls are limited.

Do we need new tools to improve OT security?

Not necessarily. Improving structure, segmentation, and visibility often has a greater impact than introducing additional tools.

Where should the Plant DMZ live and what goes in it?

It sits between OT and IT, and it’s where systems that need to move data between those environments are placed rather than direct access into control systems.

What’s the difference between VLANs and true segmentation?

VLANs organize traffic, while segmentation controls how that traffic moves. Without enforcement, VLANs don’t reduce exposure.

How do we secure vendor access without slowing operations?

By structuring it through defined pathways, limiting access to what’s needed, and making it visible and auditable.

When an OT Network Assessment Is the Right Next Step

If the questions to the right are difficult to answer with confidence, that’s usually a sign that the current architecture isn’t fully understood. In many environments, documentation doesn’t reflect reality, traffic flows aren’t clearly defined, and segmentation exists in theory but not in enforcement. Vendor access may have grown over time without a clear structure, and when issues arise, it isn’t always obvious where they started or how they spread. In those cases, the next step isn’t to apply fixes blindly, but to understand how the network is actually built and how it behaves under real conditions.

INS approaches OT network assessments by mapping the environment, validating communication patterns, and identifying where structure can be improved while working to minimize disruption to production. From there, changes can be prioritized in a way that strengthens reliability while reducing exposure.

Request an OT Network Assessment from INS