Complete Separation of IT and OT Networks Using Firewalls and Layer 3 Switching

Designing Secure Industrial Networks for Cybersecurity and Regulatory Compliance

Modern utility, manufacturing, and critical infrastructure environments are under constant pressure from cyber threats, regulatory requirements, ransomware campaigns, and operational uptime demands. One of the most important architectural decisions an organization can make is the complete separation of Information Technology (IT) and Operational Technology (OT) environments.

For years, many organizations operated with “soft separation” between business systems and industrial control systems. Flat networks, permissive routing, and legacy trust assumptions were common. Today, those designs are no longer acceptable for organizations responsible for electric, gas, water, wastewater, manufacturing, transportation, or other critical services.

Complete IT/OT separation using firewalls, Layer 3 segmentation, and strict access control has become a foundational requirement for both cybersecurity and regulatory compliance.

Why IT and OT Must Be Separated

IT and OT environments have fundamentally different priorities.

IT Environment	OT Environment
Confidentiality	Availability
Frequent patching	Controlled change windows
Rapid innovation	Stability and uptime
Internet connectivity	Isolation
User productivity	Process continuity

An infected workstation in accounting is an inconvenience.

An infected OT engineering workstation can shut down:

Substations
Water treatment
Pumping stations
Manufacturing lines
PLC communications
SCADA visibility

The operational consequences are dramatically different.

The Biggest Mistake: “Connected but Restricted”

Many organizations believe they have segmentation because:

VLANs exist
ACLs exist
Different IP ranges exist

But if unrestricted routing still exists between IT and OT, then true separation does not exist.

A ransomware infection that reaches:

Engineering workstations
Historian servers
SCADA databases
PLC management systems

can create catastrophic operational outages.

Real separation means:

No direct trust
No unrestricted routing
No flat Layer 2 adjacency
No uncontrolled east-west movement

Understanding the Purdue Model

One of the most widely adopted industrial security frameworks is the Purdue Enterprise Reference Architecture.

The Purdue Model organizes industrial systems into security and operational layers.

Purdue Level	Function
Level 0	Physical Process
Level 1	Sensors and PLCs
Level 2	HMIs and Local Control
Level 3	Site Operations / SCADA
Level 3.5	Industrial DMZ
Level 4	Enterprise IT
Level 5	Internet / External Networks

A properly segmented architecture limits communications between levels and strictly controls data flows.

One of the most important concepts is that:

Level 4 business systems should never directly communicate with Level 1 or Level 2 industrial devices.

The Industrial DMZ at Level 3.5 acts as the security buffer between enterprise and industrial environments.

Recommended Architecture

A properly segmented architecture typically includes:

Corporate IT Network
        |
   Enterprise Firewall
        |
      DMZ Zone
        |
Industrial Firewall
        |
   OT Core Switch
        |
 OT VLAN Segmentation

A mature design typically includes:

Dedicated firewall zones
Isolated management interfaces
Restricted inter-VLAN routing
Logging at every trust boundary
Monitoring sensors in strategic locations
No direct internet access from OT

Layer 3 Switching in OT

Layer 3 switches are critical because they:

Eliminate unnecessary Layer 2 exposure
Reduce broadcast domains
Enforce VLAN boundaries
Support ACL enforcement
Improve routing visibility
Simplify segmentation

Typical OT VLAN examples:

VLAN	Purpose
VLAN 10	SCADA Servers
VLAN 20	PLC Networks
VLAN 30	HMI Systems
VLAN 40	Engineering Workstations
VLAN 50	Historian Servers
VLAN 60	Security Cameras
VLAN 70	OT Wireless
VLAN 80	Vendor Access

Each VLAN should have:

Isolated routing policies
Restricted ACLs
Minimal communication paths
Logging enabled

Firewalls Are the Enforcement Point

Layer 3 switches provide segmentation.

Firewalls provide enforcement.

A properly designed OT firewall should:

Inspect traffic between IT and OT
Restrict protocols
Block unnecessary lateral movement
Log all inter-zone traffic
Support IPS/IDS functions
Provide visibility into industrial protocols

Common firewall rules include:

Historian replication only
Domain authentication only
Patch management only
Approved jump server access only
Vendor VPN restrictions
Deny all other traffic

The most important rule:

Default deny.

If traffic is not explicitly required for operations, it should not exist.

The Importance of the Industrial DMZ

The Industrial DMZ (IDMZ) acts as the buffer between enterprise IT and OT.

This is one of the most overlooked but critical design elements.

The IDMZ commonly hosts:

Patch repositories
Historian replication servers
Antivirus update systems
Remote access gateways
Jump servers
Monitoring tools
Backup relays

Without an IDMZ:

IT systems gain excessive proximity to OT
Firewall rules become overly permissive
Attack surfaces increase significantly

The IDMZ prevents direct trust relationships between enterprise and industrial environments.

Data Diodes and One-Way Traffic

Some highly secure environments implement unidirectional gateways or data diodes.

These systems allow:

OT-to-IT data transfer
Monitoring replication
Historian exports

while physically preventing inbound communications into OT.

This architecture is increasingly common in:

Electric utilities
Nuclear environments
Defense manufacturing
Critical water infrastructure

One-way communication dramatically reduces the ability of malware or ransomware to propagate into industrial environments.

Regulatory Compliance Drivers

Separation is no longer simply “best practice.”

Many regulatory frameworks either require or strongly expect segmentation.

Examples include:

NERC CIP
CISA guidance
NIST SP 800-82
ISA/IEC 62443
TSA pipeline directives
State utility cybersecurity regulations

Common audit expectations include:

Documented segmentation
Controlled access paths
Firewall rule reviews
Least privilege communications
Logging and monitoring
MFA for remote access
Vendor access controls

Auditors increasingly expect evidence that:

a compromise in IT cannot freely propagate into OT.

Real-World Attack Examples

Several major cybersecurity incidents have demonstrated the importance of IT/OT separation.

Examples include:

Ransomware spreading through flat enterprise environments
Compromised VPN access leading to OT exposure
Vendor remote access abuse
Shared credential compromise
Unpatched engineering workstations used for lateral movement

In many incidents, attackers initially compromised:

Phishing targets
VPN credentials
IT endpoints
Active Directory systems

before pivoting into operational environments.

Strong segmentation significantly limits this attack path.

Common Real-World Problems

1. “Temporary” Firewall Rules

The biggest long-term risk is temporary access becoming permanent.

Examples:

ANY/ANY rules during outages
Emergency vendor access
Unrestricted RDP
Broad subnet allowances

Six months later, nobody remembers why the rule exists.

Periodic rule review is mandatory.

2. Shared Active Directory Dependencies

Many OT environments rely heavily on enterprise Active Directory.

This creates a major risk because:

OT authentication may fail during IT outages
Ransomware may propagate through trust relationships
Domain compromise affects operations

Better approaches include:

Isolated OT domains
One-way trusts
Read-only replication
Carefully controlled authentication flows

3. Flat OT Networks

Legacy industrial environments often evolved organically.

Common findings:

PLCs on the same subnet as HMIs
Cameras mixed with SCADA
Vendor laptops everywhere
Unmanaged switches
No ACL enforcement

This dramatically increases lateral movement risk.

4. Vendor Remote Access

Vendor connectivity is one of the largest OT attack vectors.

Best practices include:

VPN with MFA
Time-restricted access
Jump servers
Session recording
Firewall restrictions
Approval workflows
No direct PLC access from internet-connected devices

Monitoring and Logging

Segmentation without monitoring is incomplete.

Organizations should log:

Inter-VLAN traffic
Denied firewall connections
Remote access sessions
Authentication attempts
Configuration changes
Industrial protocol anomalies

Useful platforms include:

SIEM systems
NetFlow collectors
IDS/IPS platforms
OT network monitoring tools

The goal is visibility into:

East-west movement
Unauthorized access
Abnormal communications
Policy violations

Incident Response in OT Environments

Traditional IT incident response procedures often do not work well in OT.

In many industrial environments:

Systems cannot be rebooted freely
Patches require maintenance windows
Operations may be safety-critical
Downtime may impact public services

OT incident response plans should include:

Operational coordination
Engineering involvement
Emergency communication paths
Backup operational procedures
Network isolation strategies
Vendor escalation procedures

The ability to isolate OT quickly using firewalls and Layer 3 segmentation can dramatically reduce operational impact during a cyber incident.

The Operational Challenge

The hardest part of IT/OT separation is not technology.

It is operations.

Common resistance includes:

“This system always worked before.”
“The vendor requires full access.”
“We can’t risk downtime.”
“The firewall slows troubleshooting.”
“Nobody knows what ports the application needs.”

Successful projects require:

Asset inventory
Traffic baselining
Phased enforcement
Testing windows
Executive support
Documentation discipline

What Mature Environments Look Like

A mature IT/OT segmented environment typically includes:

Dedicated OT firewalls
Industrial DMZ architecture
Layer 3 segmentation
Deny-by-default ACLs
MFA for remote access
Isolated management networks
Centralized logging
Vendor access controls
Configuration backups
Regular firewall audits
Documented data flows
Change management enforcement

Most importantly:

OT operations can survive independently from enterprise IT disruptions.

Zero Trust Principles in OT

Modern industrial cybersecurity increasingly applies Zero Trust concepts to OT environments.

Traditional industrial environments operated on implicit trust:

Trusted internal networks
Broad communication paths
Unrestricted east-west traffic
Shared credentials
Minimal authentication requirements

That model no longer works against modern threats.

Zero Trust in OT means:

Verify every connection
Authenticate every user
Inspect every protocol
Segment every zone
Log every action
Deny unnecessary communications

Practical Zero Trust controls include:

MFA for all remote access
Privileged access management
Role-based firewall rules
Isolated admin workstations
Jump server enforcement
Microsegmentation
Continuous monitoring

Zero Trust does not mean making OT unusable.

It means reducing implicit trust assumptions that attackers exploit.

Example Segmentation Policy Model

One of the most effective approaches to OT security is creating explicit communication matrices.

Example:

Source	Destination	Protocol	Purpose	Allowed
Historian	SCADA Server	OPC	Data Collection	Yes
Enterprise IT	PLC VLAN	Any	Direct Access	No
Engineering Workstation	PLC Network	Vendor Protocol	Maintenance	Restricted
Vendor VPN	HMI Systems	RDP	Support	Time Limited
Internet	OT Network	Any	Any	Deny

This approach:

Simplifies audits
Improves visibility
Reduces rule sprawl
Supports incident response
Documents operational dependencies

Many organizations discover undocumented dependencies during this process.

Backup and Recovery Considerations

Segmentation alone is not enough.

Organizations must also prepare for recovery.

Critical OT backup considerations include:

PLC configurations
Switch configurations
Firewall configurations
HMI applications
Historian databases
Engineering workstation images
SCADA application backups
Offline recovery media

One of the biggest lessons from ransomware incidents is:

organizations often discover too late that OT backups were incomplete or untested.

Recovery testing should include:

Restoration validation
Isolated recovery environments
Failover testing
Firmware availability verification
Vendor support coordination

Asset Inventory and Visibility

You cannot secure what you cannot identify.

Many organizations still lack complete visibility into:

Unmanaged switches
Legacy PLCs
Serial converters
Engineering laptops
Vendor-installed systems
Wireless bridges
Embedded industrial devices

A mature OT security program begins with:

Asset discovery
Network mapping
Traffic analysis
Communication baselining
Firmware identification
Unsupported system identification

This visibility becomes critical during:

Audits
Incident response
Vulnerability management
Disaster recovery
Lifecycle planning

Lifecycle Management and Technical Debt

Many OT environments contain systems that were designed decades ago.

Common challenges include:

Unsupported operating systems
Obsolete firmware
Vendor lock-in
Unpatchable devices
Unsupported protocols
Aging infrastructure

Examples still commonly found in industrial environments include:

Windows XP systems
Windows 7 HMIs
Unmanaged industrial switches
Serial-based controllers
Unsupported SCADA applications

Because replacement cycles are often measured in decades, segmentation becomes the primary compensating security control.

In many environments:

strong network segmentation is the only practical protection available for legacy OT systems.

Executive Leadership and Governance

Successful IT/OT separation projects require executive support.

Without leadership backing:

Firewall exceptions grow uncontrolled
Vendor access becomes excessive
Projects stall during operational resistance
Security enforcement weakens over time

Strong governance should include:

Formal security standards
Documented exception processes
Periodic firewall reviews
Change management enforcement
Executive risk reporting
Tabletop exercises
Cybersecurity ownership definition

Cybersecurity in OT is no longer purely an IT issue.

It is now an operational risk management issue.

Real-World Implementation Lessons

One of the biggest misconceptions about IT/OT separation is that it is purely a networking project.

In reality, most segmentation initiatives become:

Operational transformation projects
Cybersecurity modernization efforts
Governance improvement programs
Asset discovery exercises

Many organizations discover significant undocumented dependencies during implementation.

Common examples include:

Legacy applications using dynamic ports
Vendor software requiring broad access
Undocumented PLC communications
Hardcoded IP dependencies
Unsupported authentication methods
Obsolete industrial protocols

In many environments, the greatest challenge is not configuring firewalls.

It is understanding:

What systems actually communicate
Why they communicate
Who owns the systems
What operational impact exists if communications fail

Traffic baselining before enforcement becomes critical.

Organizations that skip this step often experience:

Historian outages
Intermittent HMI failures
Broken vendor access
Failed polling systems
Authentication problems
Delayed operational alarms

Successful projects usually begin in monitor-only phases before moving into active enforcement.

Example Ransomware Containment Scenario

Consider a common enterprise ransomware attack path.

An accounts payable employee opens a malicious email attachment.

Attackers gain access to:

Enterprise endpoints
Active Directory
VPN systems
Internal file shares

In poorly segmented environments, attackers may then pivot into OT through:

Shared credentials
Unrestricted routing
Flat VLAN structures
Engineering workstations
Dual-homed systems
Unmanaged remote access tools

The result can include:

Encrypted historian systems
Unavailable SCADA visibility
Disabled engineering workstations
Operational downtime
Delayed field response
Public service disruptions

In a properly segmented architecture:

OT firewalls block lateral movement
IDMZ systems isolate communications
Engineering workstations cannot freely reach PLC networks
Vendor access remains restricted
Level 1 and Level 2 operations continue functioning

The business network may still experience disruption.

But operational systems remain functional.

This is the true objective of segmentation:

preventing business system compromise from becoming operational failure.

Example Operational Improvements After Segmentation

Mature segmentation projects often produce measurable operational and cybersecurity improvements.

Before Segmentation	After Segmentation
Flat OT Network	Segmented Security Zones
Shared Administrative Access	Role-Based Administration
Direct Vendor Connectivity	Controlled Jump Server Access
Minimal Logging	Full Inter-Zone Visibility
Broad Firewall Policies	Least-Privilege Rules
Unrestricted East-West Traffic	Controlled Communication Paths
Shared Authentication Dependencies	Isolated OT Identity Services

Common measurable improvements include:

Reduced attack surface
Improved audit readiness
Faster incident containment
Better traffic visibility
Reduced unauthorized access
Simplified troubleshooting
Stronger vendor accountability

Many organizations also discover operational benefits such as:

Cleaner network documentation
Improved change management
Better asset ownership visibility
Reduced configuration sprawl

Common Mistakes During OT Segmentation Projects

Several recurring mistakes appear in failed or delayed segmentation initiatives.

1. Trying to Segment Too Quickly

Aggressive enforcement without visibility often breaks industrial communications.

OT environments frequently contain:

undocumented protocols
legacy broadcast traffic
vendor-specific dependencies
unsupported applications

Segmentation should occur in phases:

discovery
monitoring
policy tuning
staged enforcement
validation

2. Treating OT Like Traditional IT

Traditional IT security approaches may create operational risk in industrial environments.

Examples include:

forced patch cycles
automated vulnerability remediation
uncontrolled endpoint enforcement
aggressive scanning
excessive reboot requirements

Operational stability must remain a primary design consideration.

3. Ignoring Operations Staff

Operations personnel often possess the most important institutional knowledge.

Ignoring operators, engineers, or field technicians commonly results in:

undocumented outages
delayed troubleshooting
operational resistance
firewall bypass requests
shadow IT solutions

Successful projects include operations teams early in design and testing.

4. Overcomplicated Firewall Policies

Overly complex rule sets become difficult to:

audit
troubleshoot
maintain
validate

The best OT firewall environments emphasize:

simplicity
documentation
explicit communication paths
periodic rule cleanup
standardized policy structures

What Auditors Actually Look For

Many organizations focus heavily on technology while underestimating documentation and governance requirements.

In practice, auditors frequently evaluate:

documented network diagrams
firewall rule review processes
access approval workflows
vendor access procedures
MFA enforcement
logging retention
incident response plans
backup validation evidence
change management records
recovery testing documentation

Organizations often discover that:

operational discipline matters just as much as technical controls.

The most successful environments combine:

strong segmentation
clear governance
repeatable procedures
operational accountability

Final Thoughts

Complete IT/OT separation is no longer optional for critical infrastructure organizations.

Modern threats have proven that:

Flat networks fail
Implicit trust fails
Convenience creates risk

Firewalls and Layer 3 segmentation provide the foundation for:

operational resilience
ransomware containment
regulatory compliance
secure remote access
long-term maintainability

The organizations that succeed are the ones that design OT environments assuming:

the IT network will eventually be compromised.

When that happens, segmentation becomes the difference between:

a business disruption
and
a critical infrastructure outage.