Zero Trust for Operational Technology: What CISA’s New Joint Guide Means for Critical Infrastructure

A wave of high-impact attacks on industrial control systems has pushed operational technology from the plant floor to the boardroom. Now, U.S. federal agencies led by the Cybersecurity and Infrastructure Security Agency (CISA) have published a joint guide to help operators apply zero trust principles to operational technology (OT)—the programmable logic controllers (PLCs), human-machine interfaces (HMIs), safety instrumented systems (SIS), and supervisory control and data acquisition (SCADA) components that keep critical services running.

Zero trust is not a product. It’s a strategy: never implicitly trust; always verify. Translating that strategy into OT is hard. Legacy protocols lack authentication, uptime trumps everything, and change windows can be measured in quarters, not hours. That’s exactly why the new federal guidance matters: it offers a pragmatic path to improve resilience without breaking safety or availability.

This article unpacks the implications of the joint guide for OT leaders, architects, and security teams. You’ll learn where zero trust differs in OT, how to align with established frameworks, a practical 12–18 month roadmap, proven design patterns, sector-specific considerations, and metrics that demonstrate progress.

Why Zero Trust Looks Different in OT

Zero trust started in IT, where identity-aware proxies, endpoint agents, and cloud-native controls are common. In OT, the same tactics can introduce risk. Consider these differences:

Safety and availability first. Process safety and physical reliability outrank almost every other objective. Any control that could inhibit or delay safety functions must be tested thoughtfully or avoided.
Legacy and proprietary protocols. Protocols like Modbus, DNP3, and older OPC variants often don’t support modern encryption or authentication. “Wrap and broker” patterns, not rip-and-replace, are necessary.
Determinism and latency. OT networks rely on predictable timing. Inline inspection, TLS interception, or deep packet modification can break deterministic behavior.
Constrained, vendor-managed assets. PLCs and HMIs may not support agents, frequent patching, or custom hardening. Vendor warranties and validation rules limit change.
Long equipment lifecycles. An HMI might live 10–20 years. Architectural compensating controls often outlast software-era point fixes.

Zero trust in OT therefore emphasizes architectural controls at network boundaries, identity and role governance for humans and services, and continuous monitoring with read-only data capture. The goal is containment, least privilege, and verifiable trust signals without jeopardizing operations.

For foundational references, see the NIST SP 800-207 Zero Trust Architecture and the OT-specific NIST SP 800-82 Rev. 3 Guide to ICS Security, which together provide the conceptual baseline and industrial context.

What the Joint Federal Guide Signals

The release of a joint guide focused on zero trust in OT underscores a maturing consensus: industrial environments can and should adopt zero trust, but with OT-aware patterns. It also signals alignment across agencies on several priorities:

Identity-first access to critical systems, including robust controls for third-party vendor access
Risk-based segmentation and microsegmentation aligned to process-critical zones and conduits
Continuous verification using telemetry that’s safe to collect in OT
Pragmatic compensating controls for legacy and safety-critical devices
Integration with established industrial standards and maturity models

CISA’s Zero Trust Maturity Model and Cross-Sector Cybersecurity Performance Goals provide a federal blueprint. Pair those with MITRE’s adversary tradecraft for ICS (ATT&CK for ICS) and recognized industrial security standards such as ISA/IEC 62443, and you have a cohesive vocabulary for decisions, controls, and measurements.

Healthcare organizations tracking the guidance can also find sector-aligned resources via the American Hospital Association’s cybersecurity center.

Mapping Zero Trust to OT: Concepts to Controls

Zero trust revolves around verifying every access decision across five pillars: identity, device, network/environment, application/workload, and data. In OT, map those pillars into controls that preserve safety and uptime:

Identity. Strong MFA and least-privilege roles for humans (operators, engineers, vendors). Service accounts with scoped privileges and time-bound credentials. Identity-aware jump servers for any interactive access.
Device. Inventory, trustworthy firmware baselines, and compensating controls when agents aren’t possible. Vendor attestations, signed firmware, and maintenance logs.
Network/environment. Segmentation by function and criticality (building on Purdue levels), microsegmentation for east-west control, and brokered conduits with protocol-aware inspection.
Application/workload. Golden images for HMIs, application whitelisting, signed code, and strong change control with offline validation before deployment.
Data. Tagging of sensitive recipes and configurations, restricted egress, and secure logs/forensics pipelines.

The new guide emphasizes prioritizing high-value conduits, remote access paths, and systems with direct safety or process impact. This aligns with CISA’s Cybersecurity Performance Goals, which advocate risk-based control adoption tailored to critical services.

A Practical 12–18 Month Roadmap for OT Zero Trust Adoption

The fastest way to stall zero trust is to declare “everything must be zero trust now.” OT thrives on incremental, well-planned change. Use this staged, realistic approach.

Phase 0: Executive Alignment and Risk Framing (0–2 months)

Define “zero trust for OT” in your context: safety-first, incremental, architecture-led.
Identify top critical functions and unacceptable outcomes (e.g., unplanned downtime on a turbine, altered dosage in a medical device, water treatment bypass).
Select 2–3 high-value use cases to start (e.g., vendor remote access, engineering workstation hardening, HMI jump server mediation).
Agree on decision frameworks: NIST 800-207 and 800-82, ISA/IEC 62443, MITRE ATT&CK for ICS.

Deliverable: A scoped charter linking zero trust objectives to process safety and business risk.

Phase 1: Visibility and Segmentation (2–6 months)

Build a living OT asset inventory: device type, firmware, vendor, location, process role, network segment, dependencies. Leverage passive discovery to avoid disruption.
Map zones and conduits by function and criticality; align to Purdue model where applicable.
Implement macro-segmentation with firewalls or layer-3 boundaries between enterprise IT, DMZs, and OT zones. Enforce default-deny between zones.
Identify “crown jewel” conduits (engineering workstation to PLC, vendor VPN to maintenance subnet) and instrument them first.

Deliverable: Current-state map, prioritized segmentation plan, and enforcement policies for top conduits.

Phase 2: Identity and Access for OT (4–10 months)

Stand up an identity-aware jump server for all interactive access into OT. Enforce MFA, role-based access control (RBAC), session recording, and just-in-time approvals.
Replace vendor VPN tunnels with brokered remote access that terminates in a DMZ or jump host, not directly inside OT zones. Require per-session authorization.
Implement privileged access management (PAM) for shared OT accounts; eliminate static credentials wherever possible.
For machine/service accounts, rotate credentials and scope permissions narrowly (per line, per zone, per function).

Deliverable: Vendor and engineer access flows redesigned to least privilege with continuous verification.

Phase 3: Monitoring, Detection, and Response (6–12 months)

Deploy out-of-band network sensors on SPAN/TAP to collect OT protocol telemetry safely. Focus first on high-value zones and conduits.
Baseline normal communications (e.g., HMI-to-PLC read/write patterns) to detect anomalies without deep payload inspection if not feasible.
Integrate OT telemetry with your SOC, enriching alerts with asset and process context. Establish playbooks that coordinate with operations and safety teams.
Use MITRE ATT&CK for ICS to structure detections and tabletop exercises.

Deliverable: OT-aware detection with defined escalation paths that respect safety procedures.

Phase 4: Hardening and Resilience (9–18 months)

Apply application whitelisting and golden images to HMIs and engineering workstations. Validate changes offline when possible.
Introduce protocol-aware proxies or data diodes where one-way flows suffice (e.g., historian to enterprise reporting).
Enforce microsegmentation for lateral movement control inside OT zones—start with vulnerable assets that don’t require deterministic timing.
Establish tamper-proof, frequent backups of PLC logic, recipes, and configurations; test restoration with vendor involvement.
Roll out signed firmware, SBOMs (where supported by vendors), and controlled update processes.
Build and exercise an OT-specific incident response plan and recovery runbooks.

Deliverable: Reduced attack surface, faster recovery, and measurable containment of lateral movement.

Proven Design Patterns That Respect OT Realities

Brokered Remote Access for Vendors

Terminate external sessions in a demilitarized zone (DMZ) or jump host.
Require per-session approval, MFA, least-privilege profiles, and time-bound access.
Monitor and record sessions. Disallow direct RDP/SSH into OT from the internet or enterprise network.

Identity-Aware Jump Servers

Make them the only way into sensitive OT subnets for interactive work.
Integrate with corporate identity providers for centralized policy and auditing.
Gate access by role, time, and task, with break-glass controlled and logged.

Microsegmentation with Protocol Awareness

Use firewalls or software-defined segmentation that can permit specific OT protocol transactions (e.g., read-only Modbus, OPC UA endpoints).
Prefer rule sets defined by asset criticality and process function over generic “IT microsegmentation” templates.

Read-Only Network Monitoring

Avoid inline sensors in deterministic networks unless validated. Passive taps reduce risk of process disruption.
Collect enough metadata for analytics (source/destination, commands, frequencies) without breaking fragile devices.

Unidirectional Gateways and Data Diodes

Where feasible, export data (e.g., to enterprise historians or analytics) via one-way hardware to eliminate backflow risk.
Use parallel channels for management that are tightly controlled and separated from one-way telemetry flows.

Secure Engineering Workstations

Harden with application control, least privilege, and secure baselines.
Isolate from general-purpose IT networks; restrict USB/media and require signed artifacts.
Require offline testing of ladder logic and configuration updates before production deployment.

Common Mistakes to Avoid

Copy-pasting IT zero trust patterns into OT without adaptation. Inline TLS interception or frequent reauth on HMIs can cause instability.
Skipping the asset inventory. You can’t enforce least privilege or segmentation without knowing what exists and how it communicates.
Leaving vendor VPNs as backdoors. Broker and mediate all third-party access with per-session controls.
Over-segmenting too fast. Excessive changes in legacy networks can cause outages. Prioritize by risk and phase carefully.
Ignoring operations. Zero trust that surprises operators will be bypassed. Co-design with control engineers and maintenance leads.
Forgetting recovery. Backups, golden images, and restoration drills are essential compensating controls in OT.

How This Aligns with Standards and Maturity Models

NIST SP 800-207 defines the architectural principles. Apply them with OT-aware enforcement points and compensating controls.
NIST SP 800-82 maps security controls to ICS risk profiles and Purdue-like architectures; use it to justify segmentation and safe monitoring.
ISA/IEC 62443 provides requirements for zones, conduits, and component security. Align procurement and acceptance testing to 62443-3-3 and -4-1/-4-2 where feasible.
CISA’s Zero Trust Maturity Model helps measure progress across identity, device, network, application, and data pillars—adapted for OT.
The Department of Energy’s C2M2 offers a cross-sector maturity lens; use it to baseline and plan investments.
NSA’s guidance on zero trust strategy underscores a risk-based, incremental approach; see “Embracing a Zero Trust Security Model” from the NSA Cybersecurity directorate.

Sector Notes: Applying OT Zero Trust by Industry

Healthcare (Clinical OT, BME, Facilities)

Assets: building automation, pneumatic tube systems, sterilizers, imaging modalities, lab automation.
Risks: patient safety, treatment delays, privacy-adjacent exposure via clinical interfaces.
Priorities: vendor-mediated access to imaging/therapy equipment, network isolation of life-critical systems, change control with biomedical engineering. Sector resources via the AHA cybersecurity center.

Energy and Utilities (Generation, Transmission, Distribution)

Assets: DCS/SCADA, protective relays, substation automation, turbines.
Risks: grid stability, physical damage, regulatory penalties.
Priorities: unidirectional telemetry to enterprise, microsegmentation within substations, vendor access brokering, rigorous firmware governance, and alignment with C2M2.

Water and Wastewater

Assets: PLCs for pumps/valves, chemical dosing controllers, RTUs over radio/serial.
Risks: unauthorized dosing changes, service outages, environmental impact.
Priorities: protocol-aware segmentation of dosing controls, secure remote maintenance pathways for geographically distributed assets, passive monitoring to establish baselines.

Manufacturing

Assets: robotics, CNC machines, MES/SCADA, quality control sensors.
Risks: production downtime, IP theft (recipes, tolerances), safety incidents.
Priorities: engineering workstation hardening, segmentation by line/cell, brokered OEM support access, rapid restoration playbooks to minimize MTTR.

Governance, Procurement, and Workforce Considerations

Policy and governance. Codify “no direct vendor access” and “all interactive OT access via jump servers” as policy. Require MFA and just-in-time approvals for privileged OT sessions.
Procurement and vendor management. Bake zero trust requirements into contracts: session recording acceptance, signed firmware, vulnerability disclosure timelines, and 62443 conformance where applicable.
Change management. Establish OT-specific change windows, validation labs, and rollback procedures. Tie zero trust changes to those rhythms.
Training and culture. Cross-train security analysts on ICS fundamentals; cross-train control engineers on identity and segmentation basics. Practice joint tabletops using MITRE ATT&CK for ICS.
Funding and prioritization. Map investments to CISA CPGs and C2M2 target levels to show regulators and boards a structured plan and measurable outcomes.

Tools and Technology Selection Tips

Prefer brokered remote access platforms that support per-session authorization, MFA, role scoping, and session recording—integrated with your IdP and PAM.
Choose OT network monitoring that uses passive collection and recognizes industrial protocols, with flexible deployment where SPAN/TAP is the norm.
Use firewalls and segmentation that can enforce policy at L3/L4 and, where safe, L7 for OT protocols; favor deterministic performance and clear rollback.
Adopt PAM that handles shared accounts and rotates credentials without breaking vendor workflows.
Standardize on jump servers hardened to “break-glass” tolerances, with clear operational ownership.

Avoid one-size-fits-all “zero trust in a box” claims. In OT, integration quality and change safety matter more than feature breadth.

KPIs and Metrics That Demonstrate Progress

Asset coverage: percentage of OT assets discovered and profiled
Segmentation efficacy: blocked unauthorized flows between zones; policy exceptions trending downward
Access control: percentage of vendor/privileged sessions mediated by jump servers with MFA
Credential hygiene: reduction in shared/static credentials; rotation cadence adherence
Detection quality: time to detect anomalous OT communications; false-positive rate acceptable to operations
Recovery readiness: frequency and success rate of restoration drills for PLC logic and HMI images
Maturity indices: movement against CISA’s Zero Trust Maturity Model and C2M2 targets

A Checklist to Start This Quarter

Inventory top 100 OT assets and map their critical conduits
Stand up an identity-aware jump server for any interactive OT access
Replace at least one vendor VPN with brokered, time-bound access
Implement deny-by-default between IT, DMZ, and OT zones
Place passive monitoring on one high-value conduit and route alerts to the SOC
Back up and validate restoration for one PLC family and one HMI baseline
Run a tabletop exercise using ATT&CK for ICS techniques

FAQ

Q: What is zero trust in OT, in plain terms? A: It’s a way to limit what users and systems can do inside industrial networks by default and to verify every action continuously—without trusting any connection simply because it’s “inside.” Controls are tuned to avoid disrupting safety or uptime.

Q: How is OT zero trust different from IT zero trust? A: OT zero trust relies more on network boundaries, brokered access, and passive monitoring because many industrial devices can’t run agents or tolerate inline inspection. It prioritizes safety and deterministic performance over rapid change.

Q: Do we need to replace legacy PLCs to adopt zero trust? A: No. Most progress comes from architectural controls—identity-aware jump servers, segmentation, brokered vendor access, and read-only monitoring. Device replacement can follow over time as part of lifecycle management.

Q: How do we handle vendors who need 24/7 remote access? A: Implement brokered, per-session access with MFA, approvals, and session recording. Keep access paths out of production networks until authorized; use time-bound credentials and least privilege to limit blast radius.

Q: What frameworks should we align to? A: Use NIST SP 800-207 for zero trust principles, NIST SP 800-82 and ISA/IEC 62443 for industrial context, CISA’s Zero Trust Maturity Model for measurement, and C2M2 for cross-sector maturity.

Q: How can we show ROI to leadership? A: Tie zero trust milestones to reduced risk of downtime, improved recovery time, compliance alignment, and insured/resilient operations. Use KPIs like mediated vendor sessions, blocked unauthorized flows, and successful restoration tests to show progress.

Conclusion: Zero Trust for OT Is a Safety Strategy

CISA’s joint guide brings long-needed clarity: zero trust is compatible with operational technology when implemented with OT-aware patterns. Start with high-value conduits and remote access, verify every session through identity-aware jump hosts, segment networks to contain lateral movement, and monitor safely with passive telemetry. Align your program to NIST 800-207, NIST 800-82, ISA/IEC 62443, and CISA’s Zero Trust Maturity Model, and measure progress with pragmatic KPIs.

The takeaway is simple: adopting zero trust in operational technology is not about perfection. It’s about making deliberate, safe, incremental changes that shrink blast radius, harden the most abused pathways, and speed recovery when—not if—something goes wrong. Prioritize your first three moves, secure executive backing, and begin. Your processes, people, and the communities you serve will be safer for it.

Discover more at InnoVirtuoso.com

I would love some feedback on my writing so if you have any, please don’t hesitate to leave a comment around here or in any platforms that is convenient for you.

For more on tech and other topics, explore InnoVirtuoso.com anytime. Subscribe to my newsletter and join our growing community—we’ll create something magical together. I promise, it’ll never be boring!

Stay updated with the latest news—subscribe to our newsletter today!

Thank you all—wishing you an amazing day ahead!