Zero Trust in OT: Part 2: The Solution Architecture

IEC 62443: Zero Trust Principles Done Right For OT

Part 2: The Solution Architecture

Part 1 of this series explored why cloud-native Zero Trust Architecture enforcement patterns fail in operational technology environments. The core problem: implementation patterns designed for stateless IT services being forced onto deterministic industrial control systems.

But the principles of Zero Trust remain absolutely valid for OT: assume breach, least privilege, and continuous verification. The question is how to operationalize these principles using controls appropriate for industrial reality while maintaining operational autonomy.

The answer already exists: IEC 62443, the international standard for industrial automation and control systems security. It's Zero Trust principles translated into OT-compatible implementations that respect the fundamental requirement that operations must remain fully autonomous within its four walls.

IEC 62443: The Framework Practitioners Need

IEC 62443 (formerly ISA-99) is the comprehensive international standard for OT security. Unlike vendor-influenced frameworks, it provides structured approaches to implementing modern security principles while respecting operational constraints. The standard has been obscured by consulting complexity, but its core concepts are accessible to practitioners who understand operational reality.

The standard consists of four parts:

Part 1: General concepts, models, and terminology
Part 2: Policies and procedures (security programs, risk assessment, patch management for OT lifecycles)
Part 3: System security requirements (zones, conduits, security levels)
Part 4: Component security requirements (embedded devices, applications, secure development)

This creates a complete framework from organizational policy down to device-level security.

Security Levels Match Protection to Threat

The standard uses Security Levels to match protection requirements to threat sophistication:

SL 1: Protection against casual or coincidental violation
SL 2: Protection against intentional violation using simple means with low resources
SL 3: Protection against intentional violation using sophisticated means with moderate resources
SL 4: Protection against intentional violation using sophisticated means with extended resources (nation-state adversaries like TRITON, Industroyer)

Most critical infrastructure targets SL 2-3. This risk-based approach prevents both under-protection and over-engineering. Practitioners can assess appropriate security levels without vendor gatekeepers or expensive consultants.

Translating Zero Trust Principles to OT

Assume Breach: Zones and Conduits

Cloud-native Zero Trust treats the internal network as untrusted and verifies every connection continuously. IEC 62443 translates this into zones and conduits, implementing strong network segmentation based on operational boundaries to contain incidents within defined areas.

Zones are function-based groupings where assets share similar operational roles:

Safety Instrumented Systems (SIS)
Process control networks
SCADA/HMI operator interfaces
Engineering workstations
Historian and data collection systems

Security requirements align to operational function, not arbitrary network topology. This is architectural independence: operations defines zones based on operational reality, not IT convenience.

Conduits are security perimeters between zones requiring the same rigor as external interfaces. All traffic between zones flows through conduits where security controls enforce policy. Modern implementations include:

Unidirectional gateways (data diodes) for historian replication
Industrial DMZ (Level 3.5) with protocol-aware firewalls
Defense-in-depth between every Purdue level
Physical separation ensuring operations can function indefinitely without IT connectivity

This is assume breach architecture. When corporate networks are compromised, strong segmentation prevents lateral movement into control systems. The goal is containment and operational continuity, not perimeter defense.

Least Privilege: Network-Enforced Access Control

Cloud implementations use identity-based access control where users authenticate continuously for every resource. IEC 62443 enforces least privilege at network chokepoints rather than requiring device-level authentication that introduces latency.

Restrictive firewall rules at conduits implement the principle: Protocol X from HMI A to PLC B on Port Y only, deny everything else. A PLC configured to only accept Modbus commands from specific HMIs on specific function codes literally cannot respond to commands from any other source.

Remote access architecture:

All vendor access flows through jump boxes in the DMZ
MFA and device posture checks happen once at entry
Session recording for audit and forensics
Break-glass procedures with documented emergency access paths

For practitioners at small and medium manufacturers, enterprise jump box solutions are often cost-prohibitive. Open-source alternatives like properly configured Apache Guacamole with MFA or hardened Linux jump boxes provide the same security functionality. The principle matters more than the brand. Reject vendor lock-in and proprietary ecosystems.

Modern industrial firewalls provide protocol-aware deep packet inspection. Rules can specify engineering workstation A can upload ladder logic to PLC B using Modbus function code 16 (Write Multiple Registers) but not function code 08 (Diagnostics). This granular control happens at the network layer without touching operational devices.

Continuous Verification: Passive Monitoring

Cloud implementations authenticate every session continuously. IEC 62443 translates this to "always monitor" instead of "always verify" through network security monitoring that provides visibility without impacting operations.

Flow-based monitoring captures device-to-device communication without requiring expensive SPAN port or TAP infrastructure. Solutions like DYNICS ICS360.Defender make this accessible to organizations beyond Fortune 500 scale.

What monitoring detects:

Protocol-level anomalies (unexpected Modbus function codes, DNP3 point manipulation, unauthorized ladder logic uploads)
Behavioral deviations (PLCs connecting on new ports, engineering workstations accessing safety systems)
Lateral movement patterns between devices that normally don't communicate
Known adversary TTPs from TRITON, CRASHOVERRIDE, Industroyer2

Asset inventory automatically maintains from network flow analysis without touching devices. Firmware versions, vendor information, communication patterns, and configuration changes are tracked passively.

Critical distinction for operational autonomy: Monitoring systems consume copies of operational data. They are never required for production. If monitoring infrastructure fails, operations continues uninterrupted. This is Industrial Independence: operations remains fully autonomous while IT may leverage analytics and insights when available.

Formalizing the IT/OT Boundary

The most effective security posture for OT is deliberate, managed separation from untrusted networks, especially enterprise IT. While data must flow from OT to business systems, bidirectional network integration creates unacceptable risk.

Every data exchange between OT and IT requires formal agreements:

Data Exchange Agreements (DEA) define:

What data flows (specific tags, historians, asset information)
In what format (protocols, data structures)
At what frequency (real-time, batch, on-demand)
What happens when data is unavailable (IT systems degrade gracefully, operations continues)

Service Level Agreements (SLA) establish:

Responsibilities for each domain
Availability requirements (IT systems have IT availability expectations, not OT requirements)
Escalation procedures and change control authority

RACI matrices clarify:

Who owns conduits between zones
Who monitors security perimeters
Who approves changes to data flows

These agreements transform vague IT requests for "visibility" into concrete, limited, and manageable data flows with clear boundaries. Informal convergence that bypasses this governance is an attack on architecture, whether intentional or not.

The principle: IT may consume operational data when available. IT must never be required for operations. Cloud services and remote analytics are tools IT leverages for insight. Operations remains fully autonomous within its four walls.

What Good Looks Like: Reference Architecture

A mid-sized manufacturer implementing IEC 62443 principles with formal IT/OT governance demonstrates how these concepts work in practice. This describes capabilities and principles, not vendor requirements.

Network architecture for operational autonomy:

Industrial DMZ between corporate IT and control systems
Unidirectional gateways ensuring data flows OT to IT only, with physical guarantee no commands flow back
Protocol-aware firewalls at every zone boundary enforcing function-based access control
Physical separation ensuring operations functions indefinitely without IT connectivity

Access control without vendor lock-in:

Jump boxes with MFA and session recording (Apache Guacamole or similar accessible solutions)
Break-glass procedures requiring manager callback, automated logging, time-limited access
Emergency access that works at 3 AM without compromising security

Monitoring that serves operations:

Flow-based monitoring (DYNICS ICS360.Defender) capturing device-to-device patterns
Asset inventory from passive analysis
Basic log aggregation (Graylog, ELK stack) providing unified visibility
Monitoring infrastructure failures never impact production

Formal governance:

DEAs defining every data flow from OT to IT
SLAs establishing IT system availability expectations (not OT requirements)
RACI matrices clarifying ownership and change authority
IT consumes copies of data when required - never required for operations

Results:

Vendor access works during emergencies without cellular modem backdoors. Flow-based monitoring detects lateral movement. Strong segmentation contains incidents. Operations and IT collaborate as peers with formal agreements rather than informal convergence. Operations maintains autonomy. The architecture scales to any manufacturer size with principles remaining constant.

Key Differences from Cloud-Native ZTA

Enforcement location: Cloud ZTA enforces policy at endpoints. IEC 62443 enforces at network chokepoints (zone boundaries, DMZs).
Authentication model: Cloud ZTA requires continuous session verification. IEC 62443 uses network-based access control with authentication at entry points.
Monitoring approach: Cloud ZTA deploys endpoint agents providing telemetry. IEC 62443 uses passive monitoring that cannot disrupt operations.
Operational autonomy: Cloud ZTA assumes always-connected systems. IEC 62443 requires operations to function indefinitely without external connectivity.
IT/OT relationship: Cloud ZTA assumes convergence. IEC 62443 requires formal, limited integration with explicit agreements.

Both achieve assume breach, least privilege, and continuous verification. The implementation patterns differ because operational constraints and autonomy requirements differ fundamentally between IT and OT environments.

Practical Implementation Path

Implementation requires operational expertise and practitioner empowerment. Asset inventory through passive discovery, risk-based security level assessment, and incremental segmentation during planned maintenance windows form the foundation.

Critical principle: Deploy monitoring before enforcement to understand normal operations and build behavioral baselines. Operations leads implementation while security provides threat intelligence. Both sign off before deployment.

Standards belong to practitioners, not vendors. IEC 62443 is accessible to engineers who understand operational reality. Reject consulting complexity and vendor gatekeepers. The inter-zone conduits defined by these standards are critical security perimeters, not suggestions.

For organizations seeking guidance on IEC 62443 implementation and Industrial Independence methodology, practical training and consulting services are available at[River Risk Partners]

The goal is operational resilience with security visibility, not security compliance with operational disruption.

What Part 3 Covers

The technology exists. The standards are mature. The implementation patterns work. What's often missing is the organizational framework for selective integration where operations maintains architectural independence, IT provides valuable analytics as a service, and formal agreements govern every data flow.

Part 3 introduces Industrial Independence as a methodology for building these organizational capabilities. We'll explore how to structure formal IT/OT integration agreements, how to evaluate vendors pushing proprietary ecosystems, and how to build security programs that serve operational autonomy rather than subordinating it to IT convenience.

IEC 62443 provides the technical framework. Formal governance provides the boundary management. Industrial Independence provides the philosophical foundation: operations must remain fully autonomous, and security architectures must serve operational reality.

🌊

This is Part 2 of a 3-part series on implementing Zero Trust principles in operational technology environments. Part 1: "Why Cloud Zero Trust Fails In Industrial Control Systems." Coming next: "Industrial Independence: Building Security That Serves Operations."

About the author: 17+ years of industrial automation experience across power generation, manufacturing, and critical infrastructure, from field technician to architect. Advocate for Industrial Independence: OT-native security that serves operational integrity.