Zero Trust Security for OT & Industrial Networks: A Practical Implementation Guide

Why Zero Trust for OT Networks in 2026?

Traditional OT (Operational Technology) networks were built on implicit trust — if a device was on the network, it was trusted. This "castle and moat" approach worked when OT networks were air-gapped. But today's reality is different:

• IT/OT convergence has connected formerly isolated systems to corporate networks and the internet
• Remote access for vendors and engineers is now standard practice
• IoT sensors are being added to legacy infrastructure that was never designed for network connectivity
• Transportation and manufacturing remain the #1 and #2 most targeted sectors for cyberattacks in 2026

Zero Trust flips the assumption: never trust, always verify — every user, device, and data flow must be authenticated and authorized, regardless of network location.

Zero Trust vs. Traditional OT Security

| Aspect | Traditional OT | Zero Trust OT | |--------|---------------|---------------| | Trust model | Trust everything inside the perimeter | Trust nothing, verify everything | | Network access | Flat network, open internal access | Micro-segmented, least-privilege | | Authentication | Network location = identity | Identity-based per device/user | | Monitoring | Perimeter-focused (firewall logs) | Continuous monitoring everywhere | | Lateral movement | Easy once inside | Blocked by micro-segmentation | | Remote access | VPN to flat network | Identity-aware, session-based | | Assumption | Breach won't happen | Assume breach has already occurred |

The 5 Pillars of Zero Trust for Industrial Networks

Step 1: Asset Discovery and Inventory

You can't protect what you don't know exists. Start with a complete inventory of every device on your OT network.

What to discover:

• PLCs, RTUs, HMIs, SCADA servers
• Industrial switches, routers, firewalls
• IoT sensors and gateways
• Engineering workstations
• Remote access points
• Legacy serial devices with protocol converters

Tools for OT asset discovery:

| Tool | Type | Best For | |------|------|----------| | Nmap (passive mode) | Open source | Initial network scanning | | Nozomi Networks Guardian | Commercial | OT-specific deep packet inspection | | Claroty xDome | Commercial | IT/OT asset visibility | | Microsoft Defender for IoT | Commercial | Agentless OT monitoring | | GRASSMARLIN | Open source (NSA) | ICS network mapping |

# Passive discovery using Nmap — safe for OT networks
# WARNING: Never use aggressive scans on production OT networks
nmap -sn -PE --max-rate 10 10.20.0.0/16 -oX ot_inventory.xml

# Identify OT protocols on discovered hosts
nmap -sV -p 502,102,2404,44818,47808,20000 10.20.0.0/16
# 502   = Modbus
# 102   = S7comm (Siemens)
# 2404  = IEC 60870-5-104
# 44818 = EtherNet/IP
# 47808 = BACnet
# 20000 = DNP3

Step 2: Network Micro-Segmentation

Break the flat OT network into security zones based on the Purdue Model and IEC 62443.

Purdue Model Zones:

┌─────────────────────────────────────────────┐
│ Level 5: Enterprise Network (IT)            │
│   Email, ERP, business applications         │
├─────────────────── DMZ ─────────────────────┤
│ Level 3.5: IT/OT DMZ                        │
│   Historian mirror, patch server, jump host │
├─────────────────────────────────────────────┤
│ Level 3: Site Operations                    │
│   SCADA server, engineering workstation     │
├─────────────────────────────────────────────┤
│ Level 2: Area Supervisory Control           │
│   HMI, area controller, local historian     │
├─────────────────────────────────────────────┤
│ Level 1: Basic Control                      │
│   PLC, RTU, DCS controller                  │
├─────────────────────────────────────────────┤
│ Level 0: Physical Process                   │
│   Sensors, actuators, drives, instruments   │
└─────────────────────────────────────────────┘

Implementation with VLANs and firewalls:

# VLAN assignment per Purdue level
VLAN 100: Level 3   — SCADA/Engineering (10.20.100.0/24)
VLAN 110: Level 2   — HMI/Supervisory   (10.20.110.0/24)
VLAN 120: Level 1   — PLC/RTU           (10.20.120.0/24)
VLAN 130: Level 0   — Field devices      (10.20.130.0/24)
VLAN 200: DMZ       — IT/OT boundary     (10.20.200.0/24)
VLAN 250: Management — SNMP/SSH access    (10.20.250.0/24)

Firewall rules (Zero Trust principle — deny all, allow specific):

# Allow SCADA server to query PLCs via Modbus TCP
ALLOW 10.20.100.10 → 10.20.120.0/24 : TCP/502

# Allow HMI to read PLC data
ALLOW 10.20.110.0/24 → 10.20.120.0/24 : TCP/502 (READ ONLY)

# Allow historian to collect data from SCADA
ALLOW 10.20.200.5 → 10.20.100.10 : TCP/1433

# DENY everything else by default
DENY ANY → ANY

Step 3: Identity-Based Access Control

Every user and device must prove its identity before accessing any resource.

For users (engineers, operators, vendors):

• Multi-factor authentication (MFA) for all remote access
• Role-based access control (RBAC) — operators can monitor, engineers can configure
• Time-limited access for vendor maintenance
• Session recording for audit trails

For devices:

• 802.1X port-based authentication on managed switches
• Certificate-based device identity (X.509)
• MAC address allowlisting as a secondary control
• SNMPv3 with authentication and encryption

# Example: 802.1X configuration on Cisco industrial switch
interface GigabitEthernet0/1
  description PLC_Zone_A
  switchport mode access
  switchport access vlan 120
  dot1x port-control auto
  authentication host-mode multi-auth
  authentication order dot1x mab
  authentication priority dot1x mab

Step 4: Continuous Monitoring and Anomaly Detection

Zero Trust requires continuous verification — not just at login time.

What to monitor:

• Network traffic patterns (baseline normal OT behavior)
• Protocol anomalies (unexpected Modbus write commands)
• New devices appearing on the network
• Firmware changes on PLCs/RTUs
• User login patterns and access anomalies
• SNMP traps for device health changes

Detection rules example:

ALERT: Modbus write command from unexpected source
  IF source_ip NOT IN [10.20.100.10, 10.20.110.5]
  AND modbus_function IN [5, 6, 15, 16]  # Write functions
  THEN severity=CRITICAL, notify=SOC

ALERT: New device on OT network
  IF mac_address NOT IN approved_inventory
  AND vlan IN [120, 130]  # PLC or field device zones
  THEN severity=HIGH, notify=OT_security

ALERT: Engineering workstation access outside hours
  IF user_role = "engineer"
  AND access_time NOT BETWEEN 07:00-19:00
  AND NOT maintenance_window_active
  THEN severity=MEDIUM, notify=OT_manager

Step 5: Secure Remote Access

Replace traditional VPNs with Zero Trust Network Access (ZTNA):

Traditional VPN problems:

• Grants broad network access once connected
• No granular control over what resources are accessible
• VPN credentials can be stolen and reused
• No visibility into what users do after connecting

ZTNA approach:

• Authenticate user and device before granting access
• Only expose specific applications/systems needed
• Continuous posture assessment during session
• Full session logging and recording

┌──────────┐     ┌──────────────┐     ┌──────────────┐
│ Engineer  │────→│ ZTNA Broker  │────→│ Specific PLC │
│ (Remote)  │     │              │     │ (Authorised) │
│           │     │ • MFA check  │     │              │
│           │     │ • Device     │     └──────────────┘
│           │     │   posture    │
│           │     │ • Role check │     ┌──────────────┐
│           │     │ • Time check │──X──│ Other PLCs   │
│           │     │ • Logging    │     │ (Blocked)    │
└──────────┘     └──────────────┘     └──────────────┘

Compliance Alignment

Zero Trust aligns with major OT security standards:

| Standard | Relevant Requirements | |----------|----------------------| | IEC 62443 | Zones/conduits, security levels, access control | | NIST 800-82 | Network segmentation, access management, monitoring | | NERC CIP | Electronic security perimeters, access management | | NIS2 Directive | Risk management, incident handling, supply chain | | ISO 27001 | Access control, network security, monitoring |

Common Mistakes to Avoid

1. Trying to implement everything at once — Start with asset discovery and segmentation, then layer on identity and monitoring
2. Ignoring legacy devices — Many OT devices can't support modern authentication. Use compensating controls (network segmentation, protocol filtering)
3. Breaking OT processes — Always test in a staging environment. Safety-critical systems must not be disrupted by security controls
4. Forgetting about safety systems — SIS (Safety Instrumented Systems) require special handling. Never put security controls in the path of safety shutdown signals
5. No OT team involvement — Security teams must work WITH operations teams, not impose controls unilaterally

Frequently Asked Questions

Can legacy PLCs support Zero Trust?

Legacy PLCs (Allen-Bradley PLC-5, Siemens S5, etc.) don't support modern authentication. Use compensating controls: place them behind an industrial firewall with strict allowlisting, monitor all traffic to and from the device, and use a secure protocol gateway if the PLC uses insecure protocols.

How long does Zero Trust take to implement in an OT environment?

Expect 12-24 months for a full implementation across a large facility. Start with asset discovery (1-2 months), then segmentation (3-6 months), then identity and monitoring (6-12 months). The key is incremental progress without disrupting operations.

Does Zero Trust replace firewalls?

No. Firewalls remain essential for network segmentation. Zero Trust adds layers on top — identity verification, continuous monitoring, least-privilege access, and micro-segmentation that goes beyond what traditional firewalls provide.

What about air-gapped OT networks?

True air gaps are increasingly rare. Even "air-gapped" networks often have USB transfers, maintenance laptops, or cellular connections. Zero Trust principles still apply — verify every device and user, monitor for anomalies, and segment the network to limit blast radius.