intellimetrics Learning
Zero Trust Implementation Module 3 · Devices and Networks

OT: Can't Patch It, Fence It

Last reviewed · content updated

Advanced

What you'll learn

~18 min
  • Adapt - not copy - Zero Trust principles to operational technology, availability first
  • Design the OT enclave: protocol-aware segmentation, brokered access, one-way data paths
  • Put identity and logging at the IT/OT boundary when the devices themselves can't participate

The estate this training kept walking past

Meridian is a utility. Somewhere past the corporate network sit the systems that actually move water and electricity: SCADA servers, PLCs, RTUs at substations, a historian collecting telemetry, engineering workstations running vendor software from 2013. If this training ended without touching them, its credibility with you should end too — so here is the honest lesson, aligned with the first joint federal guidance on exactly this question (2026, CISA with the defense, energy, FBI and State agencies): Zero Trust principles apply to OT; Zero Trust implementations from IT mostly don’t.

Why the IT playbook breaks on contact:

IT assumption                     OT reality
Confidentiality first             AVAILABILITY first - the pump must run;
                                  a blocked packet can be a physical event
Patch the vulnerable thing        The PLC is validated as-is; patching may
                                  void certification; the window is the
                                  annual outage, maybe
Devices authenticate              The protocol (Modbus, DNP3 serial) has
                                  no concept of identity, and the device
                                  predates the concept
Fail closed (Lesson 4.1's rule)   Fail OPERATIONAL - security controls
                                  must never be the thing that trips a unit
Asset lifetime ~4 years           Asset lifetime ~25 years

Read the last table row twice: the controller installed this year outlives every policy you will ever write for it.

What transfers: the principles, relocated to the boundary

The tenets survive; their enforcement points move to places that can bear them. The devices can’t participate in Zero Trust — so the architecture participates on their behalf:

1. The enclave is the unit of trust. Segment the OT estate into zones by function and consequence (control zone, safety zone, historian/DMZ), with protocol-aware boundaries between zones — firewalls that speak the industrial protocols and can enforce “reads only, from these function codes, between these hours,” not just ports. Inside a zone, legacy chatter flows; between zones, everything is inspected policy. This is Lesson 3.3’s two-step with a twist: in OT you often already have the flow documentation (control loops are engineered artifacts) — the mapping step is verifying reality still matches the drawings.

2. Nothing crosses the IT/OT boundary as a network. People cross as sessions; data crosses one-way.

  • People: no VPN into the control network, ever. Engineering access goes through a brokered, recorded session — a privileged-access gateway in the DMZ where the engineer (or the vendor tech, the scariest identity in the building) authenticates with the full Module 2 treatment: phishing-resistant, JIT-activated, per-session, recorded. The vendor’s “we just TeamViewer in” contract clause is the first thing this program renegotiates.
  • Data: telemetry leaves the control zone through a one-way path — a data diode or strictly-enforced unidirectional replication into the historian DMZ, where IT and analytics consume the copy. The pattern is directional enforcement by construction: the ingest side can write only outward, the consumers can never reach inward. (The same directional-identity idea returns as software in Lesson 4.1 — the file pipeline whose one-way property is enforced by identity, not code order.)

3. Identity attaches where it can. The PLC won’t do MFA — but the engineering workstation is a device in Lesson 3.1’s loop, the broker session is an identity event in the CA baseline, and the historian’s consumers authenticate like any workload (Module 2.4). Score the pillar honestly on the ZTMM: “identity at every OT boundary crossing” is achievable; “identity on every OT device” is a slide from a vendor deck.

4. Visibility is passive. Active scanning that would be routine in IT can knock a fragile controller over. OT monitoring taps traffic passively, baselines the (blessedly regular) industrial conversation, and alerts on novelty — a new talker on the control network is a five-alarm signal precisely because the population is supposed to be static. That feed lands in Lesson 5.1’s pipeline with everything else.

⚠The failure mode with a body count of pumps

The IT-led ZT program that “just extends the agent and the default-deny to OT” is how security causes the outage it exists to prevent — an endpoint agent bricking an HMI mid-shift, a deny rule interrupting a control loop, a scan freezing a PLC. Every OT control gets engineered WITH operations, tested against the fail-operational requirement, and deployed in the maintenance window. In OT, the security team earns access to the estate by proving it won’t trip a unit; availability is not negotiable and the program that forgets it gets escorted out of the plant, deservedly.

Design the OT segmentation and access architecture for this estate:
zones by function/consequence with protocol-aware boundary rules; the
brokered-access path for staff AND vendors (auth strength, JIT, recording,
approval); the one-way telemetry path to the historian DMZ and what
enforces its directionality; passive monitoring placement and its
new-talker alert; and the exception register for everything that cannot
meet policy - each entry with compensating control, owner, and review date.
Constraint: every control must state its failure behavior, and none may
fail in a way that interrupts operations.
KNOWLEDGE CHECK

A vulnerability scan (run from IT, over the weekend, 'to complete the asset inventory') causes three RTUs to stop responding until power-cycled. The security lead proposes adding the OT ranges to the weekly authenticated scan schedule 'now that we know they're fragile.' What does this lesson say?

Key takeaway

Principles transfer; implementations don’t. Availability outranks everything, so trust moves to the boundaries the devices can’t defend: consequence-based enclaves with protocol-aware rules, humans crossing only as brokered recorded sessions, data crossing only one-way, identity and passive visibility attached at every crossing — and every control engineered to fail operational. Devices and networks are done; Module 4 turns to what those networks carry.

Search lessons