The Visibility Gap Undermining OT and IOT Security

OT and IoT security breaks down when organizations cannot see what is happening inside their control networks. As connectivity expands beyond the perimeter, many teams lack visibility into devices, protocols, commands, and East-West (or lateral) traffic within operational technology (OT) and IoT environments. Without that visibility, security controls are based on assumptions rather than observed behavior, making it difficult to detect misuse, validate segmentation, or enforce Zero Trust principles without disrupting operations.

Operational technology environments were never designed with cybersecurity as the first-order concern. Their mission is simple and uncompromising: Keep physical processes running safely, reliably, and predictably.

For a long time, that design assumption held. OT systems were isolated, proprietary, and operated in tightly controlled environments. Connectivity was the exception, not the rule.

IoT Has Changed That Equation

Sensors, gateways, remote access technologies, and cloud-connected analytics have extended connectivity deep into industrial environments. What were once isolated OT systems are now increasingly intertwined with IoT devices, third-party services, and enterprise IT networks.

This convergence has delivered operational insight and efficiency gains—but it has also introduced a fundamental challenge:

Most organizations still have limited visibility into what is actually happening inside their OT and IoT-connected environments.

And without visibility, security quickly becomes a matter of faith, not fact.

Why Visibility Is Key to OT and IoT Security

Across both IT and OT, one principle is non-negotiable: You cannot protect what you cannot see.

In traditional IT environments, SecOps teams generally have strong visibility into users, endpoints, applications, and North-South traffic. They rely on logs, agents, and identity controls to understand who is doing what, from where, and when.

In OT and IoT-connected environments, that OT visibility often stops at the perimeter.

Once traffic crosses into the plant or facility, many teams struggle to answer basic questions:

Which devices are communicating with each other?

What industrial protocols and commands are in use?

Which systems are exposed to remote access, vendors, or integrators?

What has changed inside the control network in the last day, week, or month?

When those questions cannot be answered with evidence, security controls are forced to operate on assumptions:

We think this VLAN is isolated

We believe only approved vendors can reach this asset

We assume this remote access is locked down

Assumptions are not a control. Visibility is the prerequisite for every control you want to enforce.

Why OT and IoT Security Is Different

Trying to secure OT and IoT the same way you secure laptops and SaaS applications is a recipe for blind spots—and, in some cases, outages.

OT environments are built around two priorities:

Availability—Systems must stay online; downtime can halt production, disrupt services, or impact public safety

Integrity—Commands and readings must be correct; bad instructions or falsified data can cause physical damage or unsafe conditions

To protect those priorities, OT systems often:

Run for decades without patching or redesign

Depend on legacy operating systems and proprietary protocols

Have no tolerance for frequent restarts, agents, or intrusive scans

Layer in IoT connectivity and the complexity multiplies:

More devices, many with limited security controls

More data paths across plant, campus, cloud, and third parties

More integration points with IT systems and analytics platforms

More potential entry points for attackers who understand these gaps

If OT and IoT systems are treated like just another class of IT asset, controls are often applied that cannot be deployed, cannot be maintained, or disrupt operations. The result is the same: Critical parts of the environment remain unmonitored even as connectivity increases.

The Purdue Model and the Modern Visibility Gap

The Purdue Enterprise Reference Architecture has long provided a blueprint for structuring industrial control system networks. By segmenting environments into levels—from enterprise IT at the top to controllers and field devices at the bottom—it aims to isolate critical process control from less trusted networks.

Segmentation is essential. But segmentation alone is not security.

Without visibility inside and between Purdue levels, organizations cannot reliably:

Validate that segmentation rules are being enforced

Detect lateral movement as attackers pivot across levels

Identify unauthorized access, configuration drift, or command execution

Understand which IT identities and services are reaching into OT

This is especially true for East-West traffic within and between OT zones. Firewalls may show intended flows, but without traffic-based visibility, teams are still relying on design assumptions rather than observed behavior.

The Purdue model describes how the environment should look. Visibility shows how it actually behaves.

How Cyber Attacks Move From IT Networks Into OT Environments?

Most OT incidents do not begin with a PLC (Programmable Logic Controller) or RTU (Remote Terminal Unit). They typically start in familiar IT territory:

Phishing emails

Misused or stolen credentials

Exposed remote access portals

Vulnerable servers in the DMZ

From there, attackers pivot toward OT environments that trust IT-side connections, lack protocol-level monitoring, and cannot distinguish between valid and safe commands.

Once an adversary reaches a system that bridges IT and OT—such as a jump server, engineering workstation, historian, or remote access gateway—they can enumerate assets, replay commands, and move laterally between systems assumed to be isolated.

This is how a cyber incident becomes a physical one: Pumps operate outside tolerance, valves open at the wrong time, safety interlocks are bypassed, and production lines shut down. The systems are doing what they were told—the problem is that no one could see the malicious instructions in time.

Lessons From Stuxnet Still Apply

Stuxnet is often treated as a historical anomaly. In reality, it is a lesson in blind trust.

The attack delivered malicious logic to PLCs using commands that appeared legitimate. Operators saw normal readings because false telemetry was fed back into monitoring systems. The process continued until physical failure made the compromise visible.

The lesson remains unchanged:

If you cannot see and validate commands, protocol behavior, and data flows, OT systems are blindly trusting everything they receive.

That is the opposite of Zero Trust.

Why Zero Trust Starts With Visibility in OT and IoT

Zero Trust is often summarized as “never trust, always verify.” In OT and IoT environments, verification cannot rely on endpoint agents, frequent patching, or identity controls alone.

Zero Trust for OT and IoT needs to start with network-derived visibility:

Knowing what devices exist, including unmanaged and unknown assets

Understanding which protocols, messages, and command patterns are normal

Continuously monitoring behavior, not just connectivity

Detecting deviations before they translate into process impact

Without this visibility, Zero Trust controls are enforced based on policy assumptions rather than observed behavior.

Encrypted Traffic: A New Kind of Blind Spot

Historically, OT traffic was rarely encrypted. Physical separation was treated as the primary safeguard. That posture is changing rapidly.

As OT and IoT systems connect to corporate networks, cloud platforms, and vendor-managed services, encryption is becoming common and increasingly required by standards such as IEC 62443 and NIST SP 800-82.

Encryption improves confidentiality and integrity—but it can also recreate blind spots if teams lose insight into traffic behavior. Effective OT and IoT security requires visibility into encrypted communications without disrupting fragile systems.

From Blind Spots to Informed Control

Visibility is not about collecting more data. It is about understanding behavior.

With insight into OT and IoT traffic at the protocol, message, and command level, organizations can:

Detect malicious or malformed commands before damage occurs

Identify unauthorized or unmanaged devices and connections

Validate segmentation against real traffic

Correlate IT and OT activity within SecOps workflows

Support Zero Trust principles without installing software on every device

This is the pivot point where investigation gives way to prevention.

Visibility Is the Path to Zero Trust for OT and IoT

Zero Trust is not a product or a checkbox. It is an architectural and operational discipline—and in OT and IoT environments, it must be grounded in visibility.

Only when organizations can see devices, traffic, protocols, and behavior across all layers of their OT and IoT environments can they begin to verify trust, enforce meaningful policy, and protect the systems society depends on.

Visibility is not the end state. It is the foundation. Without it, Zero Trust for OT and IoT cannot stand.

Watch the Webinar On Demand

Learn more by viewing the recording of Investigating the Unknown Visibility Into IOT/OT Security. It’s loaded with information you won’t want to miss.

WATCH NOW

CONTINUE THE DISCUSSION

People are talking about this in the Gigamon Community’s Zero Trust group.

Share your thoughts today