Opening Position

Operational technology security does not fail because operators lack awareness. It fails because the control layer enforces no identity boundary at runtime.

IT/OT convergence has been treated as a networking problem — segment the traffic, firewall the boundary, monitor the flows. This assumes the protocols behind the boundary enforce their own trust. They do not. OPC UA, Modbus TCP, DNP3 over IP, and BACnet all permit command execution without runtime identity validation in their default or most commonly deployed configurations. The attack surface is not the network perimeter. It is the protocol execution layer.

This absence permits lateral movement between IT and OT domains. The control layer has no independent identity boundary. Every authenticated IT identity that bridges into OT — via VPN, cloud HMI, vendor remote access, or compromised jump host — inherits full command authority over any reachable endpoint. The protocol does not distinguish between an operator and an adversary. It executes what it receives.

What Actually Failed

The protocols in widespread OT deployment were not designed to authenticate command execution at runtime. Each fails differently. Treating them as equivalent misrepresents the threat surface.

Modbus TCP has no authentication mechanism. It is a 1979 serial protocol wrapped in TCP. Any client that can reach the port can read coils, write registers, and execute function codes — read holding registers (0x03), write single coil (0x05), write multiple registers (0x10) — without presenting any identity. There is no identity field in the protocol. There is no session concept. There is no command authorization. A malicious write-register command is byte-identical to a legitimate one. The wire-level difference between an operator adjusting a setpoint and an attacker manipulating a process variable is the source IP. Nothing else.

OPC UA defines a security framework — Security Policies, X.509 certificates, encrypted channels, role-based access. It is the only protocol in this set that has an authentication architecture. In practice, deployments routinely use SecurityPolicy#None, accept anonymous connections via the Anonymous identity token, or deploy self-signed certificates without chain validation. The OPC Foundation has disclosed vulnerabilities in the stack itself: CVE-2022-29862 (infinite loop DoS in .NET implementation via deeply nested variant structures) and CVE-2022-29863 (stack overflow via recursive type definitions). The security model exists. Enforcement in production is the exception, not the norm. The authentication handshake permits a client to request SecurityPolicy#None during the OpenSecureChannel exchange, and if the server accepts it — as most default configurations do — the entire session proceeds without encryption, signing, or identity verification.

DNP3 introduced Secure Authentication (SA) in IEEE 1815-2012. SA uses HMAC-based challenge-response to validate critical commands before execution. Adoption remains minimal. The majority of deployed DNP3 outstations operate over TCP without SA enabled. Without SA, an attacker with network access to a DNP3 outstation can issue control commands — direct operate (function code 0x03), select-before-operate (function codes 0x03/0x04) — without any identity challenge. The outstation processes the command if the data link layer frame is well-formed. That is the only validation.

BACnet has no native authentication. The protocol relies entirely on network-layer trust. Any device on the BACnet network can issue ReadProperty, WriteProperty, and command requests to any other device. The BACnet/IP broadcast management device (BBMD) architecture routes traffic across subnets by design. Building automation systems using BACnet/IP with routable addresses expose every object and property to any client that reaches the network. CISA has issued repeated advisories on exposed BACnet endpoints in building automation systems, and the protocol specification provides no mechanism to restrict command execution to authorized identities.

In each case, the failure mechanism is the implicit trust model — but the depth of the failure varies. Modbus has nothing. BACnet has nothing. DNP3 has an optional extension that is rarely enabled. OPC UA has a complete framework that is routinely disabled. The convergence point: if you can speak the protocol and reach the endpoint, you can act.

Why It Failed

Access decisions in these architectures are made on static attributes: source IP, VLAN membership, VPN session state, or SSO login status. No runtime evaluation occurs between identity and action at the point of command execution.

This is not a monitoring failure. The traffic IS legitimate protocol behavior. A Modbus write-register command from an authorized VPN session is byte-identical on the wire whether the operator is performing maintenance or an attacker is manipulating a process variable. An OPC UA Write service call over a SecurityPolicy#None channel carries no identity metadata to evaluate. A DNP3 direct-operate command without SA contains no authentication field to inspect. There is nothing to detect because the protocol does not distinguish between authorized and unauthorized intent. No IDS signature resolves this. The traffic is not anomalous. It is normal protocol operation.

The root cause is absent enforcement logic at execution context:

• No device attestation occurs before a control signal is processed. The PLC, RTU, or controller validates frame structure, not origin identity.
• No session trust score is evaluated against the command being issued. A bulk register write at 03:00 from a contractor VPN is processed identically to a scheduled operator action during a maintenance window.
• No policy engine validates whether the requesting identity’s role permits the specific action on the specific device at the current time. The concept of role does not exist at the protocol layer for Modbus, BACnet, or non-SA DNP3.
• No behavioral baseline flags anomalous command sequences. The protocol endpoint has no model of expected behavior — it executes valid frames.

Network segmentation reduces reachability. It does not introduce identity. Once an actor is inside the segment — through a compromised credential, a vendor session, a misconfigured cloud connector, or a pivot from a compromised engineering workstation — the protocol layer offers no second line of defense. The segment boundary was the only boundary.

What This Exposes

This is the default condition of deployed OT infrastructure, not an isolated deficiency.

Water and wastewater: EPA and CISA have issued repeated advisories on exposed HMI and control interfaces. Water sector systems disproportionately rely on Modbus TCP for SCADA communication and remote access via VPN to HMI endpoints. The protocol provides zero authentication. The attack requires only reachability.

Building automation: Unauthenticated BACnet endpoints operate on enterprise-routable networks. CISA BACnet advisories document exposed building controllers accessible from corporate LAN segments. The protocol’s BBMD architecture actively routes control traffic across subnets. Network segmentation failures directly expose physical building systems — HVAC, access control, fire suppression — to any client on the routable network.

Energy distribution: NERC CIP establishes compliance requirements for bulk electric system cyber assets. CIP-005 mandates electronic security perimeters. CIP-007 mandates system security management. Neither mandates protocol-layer authentication for all control traffic within the security perimeter. A compliant network can still run Modbus TCP and non-SA DNP3 endpoints internally. Compliance and security are not equivalent conditions.

The attack primitive across all three sectors is not exploitation. It is normal use of a protocol that was never designed to distinguish between operators and adversaries.

Operator Position

Four enforcement requirements must be met before any OT network can claim a defensible identity boundary:

1. Device attestation at the protocol boundary. No control command is processed unless the originating device presents a verified identity — hardware-rooted where possible (TPM-backed device certificates), X.509 certificate-based at minimum. Network reachability is not identity. An authentication proxy or protocol gateway must sit in front of every endpoint that cannot perform native identity verification.

2. Session-bound trust evaluation. Every command session is scored against context: originating device, user identity, time window, command type, target device, command frequency. Commands that fall outside established behavioral baselines are held for validation, not executed and logged after the fact. Trust is continuous, not established once at session creation.

3. Policy-engine integration at the SCADA/HMI boundary. A policy decision point evaluates every command against role-based and context-based rules BEFORE the command reaches the protocol layer. The PLC or RTU should never be the first point of access control. The policy engine must enforce least-privilege: specific identities authorized for specific commands on specific devices within specific time windows.

4. Deprecation of unauthenticated protocol endpoints. Any OPC UA endpoint running SecurityPolicy#None, any Modbus TCP port without an authentication proxy, any DNP3 outstation without Secure Authentication enabled, and any BACnet interface on a routable network without enforced access controls must be classified as an uncontrolled attack surface. Remediate, isolate with compensating controls, or decommission. There is no fourth option.

The protocol layer is the last point of enforcement before a physical process is altered. If identity is not validated there, it is not validated where it matters.