Software-Defined Networking (SDN) has been one of the most talked-about concepts in enterprise networking over the past decade. Promising centralized control, automation, and increased visibility, SDN is often positioned as a modern alternative to traditional, device-by-device network management.
At its core, SDN separates the control plane from the forwarding plane. Instead of configuring policies individually on switches and routers, network behavior is defined and enforced through centralized software. In practical terms, access rules, segmentation, and traffic paths can be managed through policy rather than manual configuration.
This model offers clear benefits such as flexibility, automation, and improved visibility, but it also assumes a programmable infrastructure and predictable behavior. Those assumptions align well with enterprise IT environments, yet only partially with the operational realities of most OT networks.
As SDN matures in enterprise IT, and as organizations continue to converge IT and OT, the inevitable questions follow:
- Can SDN work in Operational Technology (OT) environments?
- Or is “OT SDN” merely an idea that looks good in whitepapers but collapses under real-world constraints?
The answer, like most things in OT, is nuanced.
Why SDN Is Attractive to OT in the First Place
OT networks have historically been static, flat, and manually managed. That model made sense when uptime and predictability mattered more than flexibility or cyber resilience. But OT environments are changing.
Today’s OT networks face:
- Increased remote access
- More vendors and third parties
- Converged IT/OT architectures
- Regulatory pressure (IEC 62443, NERC CIP, etc.)
- Growing cyber threat exposure
SDN promises:
- Centralized visibility and control
- Micro segmentation without massive VLAN sprawl
- Policy-driven access instead of box-by-box configuration
- Faster response to incidents and changes
From a cybersecurity perspective, SDN sounds almost tailor-made for OT.
So why isn’t everyone already doing it?
The Hard Reality of OT Networking
To determine whether SDN is realistic, you need to understand how OT networks are built and operated.
Determinism Beats Flexibility
OT networks are designed to behave consistently every time. Fixed paths, predictable latency, and known failure modes.
By design, SDN introduces abstraction and centralized decision-making. Even when tightly controlled, this clashes with environments where milliseconds matter and where engineers expect to observe and explain packet behavior.
A discrete manufacturing plant learned this the hard way when it tried to introduce SDN-capable switches into a Level 2 Ethernet/IP control network. The goal was micro-segmentation between machines and centralized policy enforcement. Instead, engineers encountered opaque traffic flows, latency jitter during controller updates, and troubleshooting scenarios where it was unclear whether failures originated in logic, the network, or controller behavior.
The result? The control network was reverted from SDN to static configurations. SDN survived only in the supporting infrastructure.
In OT, predictability often wins over elegance.
Legacy Devices Don’t Speak SDN
At its core, SDN assumes that networked devices can listen to, interpret, and respond to software-driven instructions. Policies are pushed through APIs. Traffic behavior is adjusted dynamically. Network elements are expected to engage in a conversation with a centralized controller.
Most legacy OT devices were never designed to have that conversation.
Traditional industrial systems were built for stability, determinism, and long service life, not for programmability. Many still communicate using:
- Serial protocols (RS-232, RS-485)
- Vendor-specific fieldbus technologies
- Fixed-function Ethernet implementations
- Configuration models intended to be set during commissioning and left untouched
These devices don’t expose APIs. They don’t understand policy abstractions. They don’t negotiate traffic behavior or accept dynamic updates from a controller. In many cases, the “interface” is a physical port, a fixed protocol stack, or a configuration file that changes only during a scheduled outage.
From the device’s perspective, nothing is missing; it is doing exactly what it was designed to do.
Figure 1-SDN vs Legacy OT
The mismatch arises because SDN expects network elements to be software participants, while legacy OT devices behave as deterministic endpoints. Attempting to impose SDN-style control on these systems often requires protocol gateways, overlays, or additional layers of abstraction, each of which introduces complexity, troubleshooting challenges, and new failure modes.
This is why SDN adoption in OT rarely occurs: the technology is not inherently immature. It fails because the underlying devices simply don’t speak the same language.
Most OT environments still rely on:
- Long-lifecycle industrial switches
- Proprietary or timing-sensitive protocols
- Devices that predate APIs, overlays, or controllers
Replacing proven, certified hardware simply to support SDN is rarely defensible.
Electric utilities face this reality every day. In protection and control networks that carry IEC 61850 GOOSE traffic, several utilities have explicitly rejected SDN. Latency guarantees, certification costs, and operational trust outweigh any theoretical benefits of abstraction. In these environments, the most realistic SDN decision is not to deploy it at all.
Change Control Is Slow by Design
In IT, automation is efficiency.
In OT, automation without guardrails is a risk.
Network changes often require management of change reviews, safety validation, downtime planning, and regulatory documentation. The idea of dynamic flow updates, even correct ones, makes many OT teams uncomfortable for good reason.
This resistance isn’t cultural inertia. It’s operational maturity.
Where OT SDN Actually Works in Practice
Despite these constraints, SDN is not a fantasy in OT. It appears in places vendors don’t always highlight.
At the IT/OT Boundary
A regional water utility operating more than 30 remote sites deployed SDN not in the control network, but in the industrial DMZ. The utility struggled with flat architectures, vendor access that never expired, and firewall rules that no one wanted to touch.
By applying SDN-based segmentation at the boundary:
- Vendor access became role-based and time-limited
- Policies aligned to function, not IP address
- Auditability improved without touching PLC traffic
OT engineers accepted the solution because it didn’t interfere with determinism or field operations. SDN worked precisely because it stayed in its lane.
For Secure Remote Access and Cellular OT
Upstream oil and gas operations provide another realistic SDN use case. Remote well pads connected via cellular backhaul often rely on VPN sprawl, shared credentials, and minimal segmentation.
In one deployment, SDN was used at aggregation points to enforce:
- Vendor-specific access zones
- Time-bounded permissions
- Read-only versus control access
Field networks remained static and simple. SDN operated above them, reducing the attack surface without introducing operational risk.
In Virtualized OT Infrastructure
SDN aligns naturally with OT, which already behaves like IT.
Large manufacturers that operate centralized virtual historians and analytics platforms have successfully deployed SDN within virtualized OT data layers. Policy-based segmentation simplified deployments, improved consistency across sites, and accelerated analytics onboarding, all without touching real-time control paths.
Here, SDN acted as a force multiplier rather than a disruption.
The Security Angle: SDN Is an Enabler, not a Savior
SDN does not:
- Fix poor asset inventory
- Replace protocol awareness
- Eliminate zoning and conduits
- Automatically create resilience
What it does do is amplify good architecture.
Used well, SDN:
- Reduces configuration error
- Improves policy consistency
- Speeds containment during incidents
- Makes segmentation manageable at scale
Used poorly, it obscures failure modes and erodes trust.
Figure 2 – Enabler not a Savior
So… Is OT SDN a Pipe Dream?
No, but it’s also not the future many marketing decks promise.
OT SDN today is:
- Incremental
- Hybrid
- Boundary-focused
- Highly constrained
It is not a wholesale replacement for industrial networking, nor is it suited for safety-critical or time-sensitive control paths.
The organizations succeeding with SDN in OT are not chasing trends. They are solving specific problems, keeping physical networks boring, and applying abstraction only where it improves clarity rather than complexity.
The Bottom Line
OT SDN isn’t a pipe dream, but it isn’t inevitable either.
It will continue to appear:
- At IT/OT boundaries
- In virtualized environments
- In secure remote access architectures
The real question isn’t “Can SDN work in OT?” It’s “Where does abstraction improve security and operations without introducing unacceptable risk?”
In OT, realism always wins.
At Enaxy, we help organizations apply SDN in OT environments pragmatically, not ideologically. We work with engineering, operations, and security teams to identify where abstraction adds real value and where traditional industrial networking should remain untouched.
From evaluating SDN use cases at IT/OT boundaries to designing secure hybrid architectures that respect safety and determinism, Enaxy helps ensure SDN is used as a tool, not a liability.
If you’re considering SDN in OT and want a grounded, risk-aware approach, contact Enaxy at info@enaxy.com.