Zero-Trust Architecture for SCADA — Securing IEC 60870-5-104 Systems

By | October 30, 2025

Modern SCADA systems are no longer isolated.

With the rise of remote substations, cloud monitoring, and IP-based protocols like IEC 60870-5-104, the traditional “trusted internal network” model is obsolete.

That’s where Zero-Trust Architecture (ZTA) comes in — a cybersecurity framework that assumes no device, user, or network is inherently trustworthy.
Instead, every connection must be verified, authenticated, and continuously monitored.

This guide explains how to apply Zero-Trust principles to industrial automation and SCADA networks using IEC 60870-5-104 as a real-world example.

What Is Zero-Trust Architecture (ZTA)?

Zero Trust is a cybersecurity philosophy that operates on the principle:

“Never trust, always verify.”

Originally popularized by NIST SP 800-207, Zero Trust eliminates implicit trust in network boundaries.
It relies on strong identity verification, least privilege access, and continuous inspection of data flows.

For SCADA systems, this means:

  • Every user, RTU, IED, and HMI must prove its identity.
  • All IEC 104 traffic must be inspected and authenticated.
  • No flat “trusted” network segments exist — only verified zones.

Why Traditional SCADA Security Fails

Traditional SCADA architectures rely on perimeter security — e.g., firewalls between corporate and control networks.
However, this model assumes the inside network is safe.

With modern connectivity (IoT sensors, remote VPNs, cloud analytics), threats now originate from inside the perimeter:

  • Compromised RTUs or PLCs
  • Remote maintenance access without MFA
  • Infected engineering laptops
  • Lateral movement after initial compromise

This makes Zero Trust not optional — but essential.

Core Principles of Zero-Trust for SCADA

PrincipleDescription in SCADA Context
1. Verify explicitlyAuthenticate every user, device, and service — even within the control network.
2. Least privilege accessGive users and applications only the minimum rights needed for operation.
3. Assume breachDesign every zone and asset as if an attacker is already inside.
4. Continuous monitoringLog, inspect, and analyze IEC 104 traffic and commands in real time.
5. Micro-segmentationBreak networks into small security zones — isolate substations and RTUs.

Applying Zero Trust to IEC 60870-5-104

IEC 104 operates over TCP/IP (port 2404) and provides no built-in encryption or authentication by default.

To integrate it into a Zero-Trust model, you must secure every layer:

1. Identity and Access Control

  • Use X.509 certificates or mutual TLS for IEC 104 sessions.
  • Integrate device identity into a central PKI infrastructure.
  • Enforce multi-factor authentication (MFA) for SCADA operators.

2. Network Segmentation

  • Place RTUs, IEDs, and control centers in isolated VLANs or subnets.
  • Use firewalls with IEC 104-aware filtering (inspect ASDUs, not just ports).
  • Block unnecessary east–west communication between substations.

3. Secure Communication Channels

  • Implement IEC 62351-5 or IEC 104 over TLS (TLS-104).
  • For remote RTUs, use VPNs with endpoint validation.
  • Require encryption for all data crossing untrusted networks.

4. Monitoring and Threat Detection

  • Deploy deep packet inspection (DPI) for IEC 104 traffic.
  • Correlate anomalies in timestamps (CP56Time2a), ASDU sequences, or command patterns.
  • Use SIEM tools to centralize and analyze security logs.

5. Policy Enforcement and Automation

  • Use firewall automation to dynamically block suspicious IEC 104 endpoints.
  • Integrate role-based access control (RBAC) with SCADA management tools.
  • Continuously evaluate device posture before allowing connections.

Architecture Overview

Zero-Trust Layers for SCADA Networks

  1. User/Device Identity Layer — verified by certificates or MFA.
  2. Network Control Layer — micro-segmented, encrypted communication paths.
  3. Application Layer — secure SCADA applications enforcing access control.
  4. Telemetry Layer (IEC 104) — protected with TLS or IEC 62351.
  5. Analytics and Monitoring Layer — real-time inspection, alerting, and audit.

Every layer verifies the one below it — ensuring defense in depth.

Integration with IEC 62351

The IEC 62351 standard family defines cybersecurity for power system protocols.
For IEC 60870-5-104, the relevant part is IEC 62351-5, which adds:

  • Authentication via digital signatures
  • Encryption using TLS
  • Role-based access and key management

Combining IEC 104 + IEC 62351-5 forms the foundation of a Zero-Trust SCADA system.

Conclusion — Building Trust by Removing It

The shift to Zero-Trust Architecture marks a turning point in how industrial and power automation systems are secured.
In a world where IEC 60870-5-104 and other IP-based protocols connect substations, control centers, and cloud analytics, perimeter security is no longer enough.

By adopting Zero Trust principles — verify every connection, authenticate every device, and continuously monitor every data flow — operators can protect critical infrastructure from both internal and external threats.

Implementing Zero Trust for SCADA isn’t about replacing existing tools; it’s about rethinking trust boundaries and making every access request prove its legitimacy.
When combined with IEC 62351 security extensions, TLS encryption, and deep packet inspection, IEC 104 becomes not only functional but resilient.

The result:

  • Stronger cybersecurity posture
  • Reduced attack surface
  • Reliable and compliant power automation networks

In short: Zero Trust doesn’t mean no trust — it means trust that’s earned, verified, and continuously enforced.

Author: Zakaria El Intissar

I'm an automation and industrial computing engineer with 12 years of experience in power system automation, SCADA communication protocols, and electrical protection. I build tools and write guides for Modbus, DNP3, IEC 101/104, and IEC 103 on ScadaProtocols.com to help engineers decode, analyze, and troubleshoot real industrial communication systems.

Leave a Reply

Your email address will not be published. Required fields are marked *