TroutTrout
Back to Blog
Zero TrustOT SecurityAgentless

Agent-Free Zero Trust: Why OT Environments Can't Use Endpoint Software

Trout Team3 min read

IT Zero Trust works by installing agents on endpoints. The agent verifies device health, enforces policies, and reports telemetry. This model breaks in OT. PLCs run proprietary firmware. CNCs run embedded operating systems from 2005. HMIs run Windows XP Embedded with no update path. You cannot install an agent on any of these. You need a different approach.

Why Agents Do Not Work in OT

Proprietary Operating Systems

Most PLCs and industrial controllers run proprietary real-time operating systems. Allen-Bradley uses ControlLogix OS. Siemens uses Step 7 runtime. Fanuc CNC controllers run their own firmware. None of these support third-party software installation.

Real-Time Constraints

Industrial controllers operate on deterministic cycles measured in milliseconds. A PLC scanning I/O every 10ms cannot tolerate the CPU overhead or timing jitter that a security agent introduces. Even a momentary delay can cause a safety fault or production stop.

No Update Path

Many OT devices have been running the same firmware for 10 or 20 years. The manufacturer may no longer exist. Even when updates are available, applying them requires production downtime and requalification. The cost of patching often exceeds the value of the device.

Certification and Warranty

Industrial equipment is often certified for specific configurations. Installing unauthorized software voids the warranty and may invalidate safety certifications. In regulated industries, this is a non-starter.

The Network-Layer Alternative

Instead of securing the device, secure the path to the device. An identity-aware proxy sits between the user and the OT asset. Every connection passes through the proxy, which:

  1. Authenticates the user with MFA before the session is established
  2. Authorizes the session based on role, asset, protocol, and time window
  3. Logs the session with user identity, timestamp, and payload
  4. Encrypts the connection between the user and the proxy
  5. Isolates the asset in a microsegment with deny-by-default rules

The OT device continues operating exactly as it always has. It sees the same protocol, the same traffic patterns, the same timing. The enforcement happens at the proxy, not on the device.

What You Get Without Agents

CapabilityAgent-BasedNetwork-Layer
Identity verificationYesYes (at proxy)
MFA enforcementYesYes (at proxy)
Session loggingYesYes (at proxy)
Protocol inspectionLimitedYes (deep packet)
Device health checkYesNo
Works on legacy OTNoYes
Production impactRisk of disruptionNone

The one capability you lose is device health attestation. You cannot verify the internal state of a PLC from the network. But you can verify and control every connection to and from it, which is what CMMC, NIS2, and IEC 62443 actually require.

The Overlay Architecture

Access Gate deploys as a physical appliance or VM adjacent to your existing network. It creates an overlay network using the 100.64.0.0/16 address space. Each OT asset gets a proxy endpoint. The overlay handles identity, access control, logging, and encryption. The underlay (your existing switches, VLANs, and cabling) remains untouched.

This is sometimes called the "lollipop architecture" because each asset has a single enforced path (the stick) to its proxy (the candy). No lateral movement between assets. No unauthenticated connections. No unlogged sessions.


For more Zero Trust OT resources, architecture guides, and comparisons, visit the Zero Trust for OT Networks hub.

FAQ

Frequently Asked Questions

Can any agent run on a PLC?
In practice, no. Some newer industrial controllers support limited extensions, but these are manufacturer-specific and do not provide the security capabilities needed for Zero Trust (MFA, session logging, encryption).
Does network-layer enforcement provide equivalent protection to agents?
For access control, session logging, MFA, and encryption, yes. The main capability gap is device health attestation, which is not required by most compliance frameworks for OT assets.
What about containerized agents or lightweight shims?
These require a compatible operating system on the device. Most OT equipment does not have one. Even when technically possible, the real-time constraints and certification requirements make it impractical.
How does Access Gate handle proprietary OT protocols?
Access Gate operates at the network layer and supports any IP-based protocol. For protocols like Modbus TCP, EtherNet/IP, and OPC UA, it provides protocol-aware inspection and per-command access control.
Does this approach satisfy NIS2 and IEC 62443?
Yes. Both frameworks require network segmentation, access control, and monitoring. Neither requires endpoint agents on OT devices. Network-layer enforcement satisfies the control intent.