The attacker's favorite moment
An attacker lands on an engineer's laptop through a phishing email. Standard stuff — malicious Excel macro, Mimikatz for credentials, a week of quiet reconnaissance. Nothing happens fast. The interesting moment comes later, when they pivot from the corporate VLAN onto the plant network through a dual-homed engineering workstation.
At that point something shifts. On the IT side, every session still had to prove something: SSO redirect to Okta, MFA prompt, device posture check, conditional access policy. On the OT side, none of that exists. The PLC at the end of the cable doesn't ask for a token. The Modbus TCP session on port 502 doesn't care about SAML. The HMI on the cell accepts any RDP session from the subnet because it was configured that way in 2014 and nobody has touched it since.
The attacker is now inside a network where every device trusts every other device by default. They have reached the part of the infrastructure that was never designed to answer the question who are you.
This is the moment OT security programs exist to prevent. It is also the moment they fail most often, because the underlying architecture makes identity almost impossible to enforce at the asset.
What "no identity layer" actually means
Three structural properties define an OT network without an identity layer. Each of them is a specific technical fact, not a vibe.
1. Flat at Layer 2
Most brownfield OT networks are one big broadcast domain or a handful of VLANs with permissive inter-VLAN routing. A PLC, an HMI, an engineering workstation, a historian, and a printer share the same Layer 2 segment. ARP resolves across the whole range. Anything on the wire can reach anything else on the wire.
You can look at the Purdue diagram on the wall and see hierarchical levels — Level 0 through Level 4 — neatly separated. Then you trace a cable and discover that Level 2 and Level 3 share a switch, that the iDMZ firewall has been 1:1 NAT'd to "just make it work," and that the vendor's remote-access jump host sits on the same VLAN as the PLCs. The Purdue model is what the documentation describes. The flat network is what the traffic actually sees.
Once an attacker is on that flat segment, lateral movement is not a technique — it is the default behavior.
2. Implicit trust at Layer 2 and 3
IT networks stopped trusting the LAN years ago. Zero-trust principles, endpoint agents, device posture signals, conditional access — the whole stack exists because "being inside the office" is no longer a sufficient claim to anything.
OT networks never left. The implicit contract is that every device on the segment is trusted because every device on the segment was authorized by the integrator when the plant was commissioned. If you can ARP for it, you can talk to it. If you can talk to it, whatever it offers, you are allowed to use.
This is what OT/IT convergence exposes. The moment there is a reachable path from the IT side — a dual-homed laptop, a historian that bridges Level 3 and Level 4, a cellular IIoT gateway that skips the hierarchy entirely — the implicit trust model becomes the attacker's operating assumption.
3. The PLC that cannot do MFA
This is the part nobody can patch. A Siemens S7-1500 runs proprietary firmware with a fixed feature set. A Rockwell ControlLogix accepts EtherNet/IP sessions that have no concept of a user. A CNC controller from 2008 exposes a plaintext FTP endpoint for program transfer because that is how programs were transferred in 2008.
You cannot install a PAM agent on a PLC. You cannot enable TLS on the Modbus stack. You cannot put a badge reader in front of an HMI and have the HMI check the badge. These devices were not designed for identity. Many of them cannot be modified without voiding certification. Most of them are ten-plus years into a twenty-year service life.
This is what CMMC calls a specialized asset. The asset cannot satisfy the requirement natively. The requirement does not go away. Something else has to enforce it.
The attacker's playbook, concretely
Put those three properties together and the attack path writes itself. A well-documented pattern, paraphrased from several publicly disclosed incidents:
- Initial access via IT (phishing, external RDP, compromised credential).
- Lateral movement across IT using AD credentials.
- Pivot to OT via a dual-homed engineering workstation, a historian, or a vendor VPN that terminates deeper than it should.
- Discovery on the flat OT segment — ARP scans, service enumeration, banner grabs. Nothing blocks this because nothing on the OT side is watching.
- Direct interaction with PLCs, HMIs, or safety controllers using the devices' own protocols. No exploits required. The protocols accept commands because that is what they are for.
The Oldsmar water-treatment incident in 2021 fit this shape, compressed. An attacker reached an HMI via TeamViewer and tried to change a chemical-feed setpoint. The HMI accepted the command. An operator happened to be watching the screen and reverted it manually. The only reason that incident is a near-miss rather than a headline is that a human intervened in real time.
This is what "no identity layer" costs. It is not that the controls are weak. There are no controls. The asset accepts any authenticated session because it has no way to authenticate at all.
The retroactive identity layer
You cannot add identity to the PLC. You can add identity to the network path in front of the PLC.
The pattern that works is a proxy — specifically, a non-inline proxy deployed in a lollipop architecture — that sits between the rest of the world and the specialized assets. Every session to a PLC, HMI, or SCADA server passes through the proxy first. The proxy terminates the transport, authenticates the human or service initiating the session, authorizes the specific action, and emits an audit event. Only then does the proxy re-emit traffic to the asset in whatever native protocol the asset speaks.
From the asset's perspective, nothing has changed. The PLC still sees Modbus TCP on port 502. The HMI still sees RDP on 3389. The CNC still sees FTP. From the attacker's perspective, a lot has changed. The flat network is not flat anymore. Reaching a PLC requires traversing the proxy. Traversing the proxy requires a valid identity. The identity the attacker used to land on the engineering workstation does not automatically produce a valid identity for the OT side.
Three properties make this work where a traditional firewall does not:
- The proxy binds rules to identity, not IP. An engineer's session is allowed because the engineer authenticated, not because their workstation's IP is in an allowlist. A phished credential does not become a routable path.
- The proxy understands the protocol. Modbus function code 03 (read) can be allowed while function code 06 (write) is denied for the same user on the same port. See protocol filtering for how this looks across Modbus, DNP3, EtherNet/IP, OPC UA, and the other common ICS protocols.
- The proxy is non-inline. Powering it off restores the network to its previous state. This matters because OT change control rarely permits inline devices that can fail closed. The lollipop topology is the reason the appliance can be deployed during a maintenance window without rewiring anything.
The result is a zero-trust overlay for OT — an identity layer the assets cannot host themselves, enforced at the network layer where the assets live.
What this means for CMMC and the CUI flow
This architecture is also what closes the CMMC gap for specialized assets. An OT asset that cannot do MFA invokes a CMMC Enduring Exception. The exception documents the asset's incapacity. It does not remove the requirement. A compensating control has to provide equivalent protection.
An identity-enforcing proxy is the compensating control. MFA is enforced at the proxy before any session reaches the PLC. Audit is captured at the proxy before any command is executed. Encryption is terminated at the proxy on CUI paths. The Affirming Official signs an SSP that points to the proxy's policy export, the session logs, and the network diagram. The C3PAO asks for evidence and the evidence exists, because the enforcement is running where the traffic runs.
This is the same architecture that solves lateral movement, solves CMMC specialized-asset coverage, and solves the OIV / OSE technical obligations under NIS2. It is not three different problems. It is one missing layer.
The retrofit is not a rewiring project
The usual objection to all of this is operational. We cannot take the plant down. We cannot rebuild the network. We cannot rip out the Purdue hierarchy and start over.
None of that is necessary. The lollipop architecture plugs into a single switch port, creates an identity-enforced overlay in the 100.64.0.0/16 CGNAT range, and does not touch the existing VLANs, IP addresses, or firewall rules. Enrolled devices communicate through the overlay. Non-enrolled devices are unaffected. If the appliance is disconnected, traffic falls back to the physical network exactly as it behaved before.
What changes is the identity posture. Every session that reaches a specialized asset through the overlay has been authenticated, authorized, and logged. Every session that tries to bypass the overlay and reach an asset across the flat network is either blocked by the default-deny policy on the overlay or, if the asset is not yet enrolled, visible as the kind of anomaly a SOC can actually act on.
The question to ask
The operational question is not "do we have a firewall at the IT/OT boundary" — most plants do, and the flat network behind it is what an attacker cares about. The question is: if an attacker reached any device inside the OT segment right now, what would stop them from reaching a PLC?
If the honest answer is "the attacker hasn't figured out our VLAN layout yet," there is no identity layer. And the attacker always figures out the VLAN layout.
Adding identity to the OT network does not mean replacing the assets. It means putting identity where the assets can't put it themselves. That retrofit is mechanical, non-disruptive, and the only answer the compliance frameworks will accept for specialized assets going forward.
Trout Access Gate is the proxy appliance that implements this pattern — non-inline, protocol-aware, identity-bound — deployed in a lollipop topology without touching the existing OT network. See the Zero Trust Access Control for OT solution page, or talk to an engineer about what the retrofit looks like in your plant.
