Skip to content
New CISA guidance outlines zero trust roadmap for OT environments facing legacy ...

New CISA guidance outlines zero trust roadmap for OT environments facing legacy ...

Industrialcyber.Co April 30, 2026

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and government partners have released a new guide to accelerate zero trust adoption in OT (operational technology) environments. Titled ‘Adapting Zero Trust Principles to Operational Technology,’ the guide outlines practical steps for applying zero trust in environments that often face constraints such as legacy systems, limited visibility, and uptime requirements. It emphasizes the need for comprehensive asset visibility, stronger identity and access controls, and more secure supply chains, while offering a framework to help organizations prioritize and implement zero trust strategies in complex OT settings.

As OT systems become increasingly interconnected, digitally monitored, and remotely operated, attack surfaces are expanding and cyber risks are multiplying. Improperly secured pathways give threat actors entry points into both IT and OT networks. Zero trust principles, adapted carefully to OT’s operational realities, can help owners and operators close these gaps, protecting the critical physical processes these systems control from compromise, manipulation, and disruption, without destabilizing the systems themselves.

Aligned with the NIST CSF 2.0 framework , the 28-page guide organizes cybersecurity outcomes around the core functions of Govern, Identify, Protect, Detect, Respond, and Recover. The document outlines key considerations to help organizations navigate OT constraints while safely applying Zero Trust across each NIST CSF category. Growing convergence of IT and OT has fundamentally changed the threat landscape. Systems once isolated or manually operated are now digitally integrated and remotely managed, making traditional perimeter-based defenses and implicit trust models inadequate for protecting the critical processes OT systems control.

Developed with the Departments of Defense, Energy, and State, and the FBI, the guidance applies to public- and private-sector organizations operating OT systems. It helps OT owners and operators navigate the complexities of adopting a zero trust architecture, accounting for legacy infrastructure gaps, operational constraints, and safety requirements. It covers asset visibility, supply chain risk management , and identity and access controls, while emphasizing layered defenses including network segmentation, secure communications, and vulnerability management .

Advances in connectivity are dissolving the traditional isolation of OT systems, linking them more closely with IT networks and significantly expanding the attack surface. This convergence introduces new entry points for threat actors, who can exploit weak pathways, compromised credentials, insecure remote access, and supply chain vulnerabilities to move from IT into OT environments. Campaigns such as Volt Typhoon illustrate how attackers establish persistence in IT systems before pivoting into operational networks.

At the same time, adversaries are developing more sophisticated capabilities to target OT directly, including tailored malware and “living off the land” techniques that evade detection. These risks are amplified by legacy OT systems with long lifecycles and limited security support. As OT systems control physical processes, successful attacks can lead to severe real-world consequences, including loss of control over critical infrastructure. As a result, traditional perimeter-based defenses are proving inadequate, underscoring the need for zero trust approaches tailored to the unique constraints of OT environments.

Applying Zero Trust in OT environments is constrained by fundamental differences from IT systems, particularly the need for continuous availability, the prevalence of legacy and insecure devices, and the complexity of operational priorities. OT systems are designed for real-time, uninterrupted operations, making them less tolerant of disruptions, frequent updates, or reconfiguration required by modern security practices.

Legacy infrastructure further complicates adoption, as many systems rely on outdated protocols, lack built-in security, and cannot be easily patched or tested without risking downtime. Limited logging and visibility reduce the effectiveness of traditional detection and response methods, while implementation of zero trust requires close collaboration between OT, IT, and cybersecurity teams to balance security with operational continuity.

Effective governance in OT environments starts with one simple truth: cybersecurity people and operational people need each other. Plant managers, engineers, system integrators, and security teams bring something different to the table, and zero trust only works when those worlds actually talk. Personnel who can speak both languages, understanding OT safety constraints and cybersecurity threat modeling at once, are rare but invaluable.

Remote access and break-glass scenarios are where things go wrong fastest, so that’s where cross-disciplinary thinking matters most. Risk tolerances need to be set clearly, with escalation paths ready for when zero trust controls bump up against system availability or safety. Sometimes the right answer is a compensating control, such as anomaly detection out-of-band, and network segmentation, not a perfect zero trust implementation. Siloed decision-making has no place here. Shared accountability does.

Procurement doesn’t sound exciting. It rarely does. But in OT environments still tangled up in legacy infrastructure, it might be the most strategic lever available. Newer components bring what legacy systems simply can’t offer, such as security logging, identity management, secure communication protocols, and that matters enormously for monitoring and enforcement without breaking operational continuity.

Supply chain risk is part of this picture, too. Not every vendor provides SBOMs, especially for older control systems, so organizations have to dig deeper, reviewing vulnerability management practices, checking CVE authority status, and assessing how a vendor’s security posture matches actual connectivity risks involved. Third-party access is another pressure point. Authorization and oversight aren’t optional. Technical controls are preferred, but at a minimum, some method must exist to limit and monitor who gets in because supply chain risk doesn’t always announce itself at the front door.

Before any Zero Trust architecture can take shape in an OT environment, organizations need to know what they actually have. This calls for a comprehensive asset inventory — hardware, software, systems, communications — is the starting point, and in OT, building one is messier than it looks. Passive monitoring is the safer route, especially around legacy components that active scanning can knock offline without warning. Some vendors run proprietary protocols that standard tools can’t parse. Air-gapped or heavily segmented networks may only return partial results. Deploying inventory tools across every subnet can get expensive fast.

None of that makes the effort optional. It just means planning carefully, placing sensors thoughtfully, and accepting that the picture will be incomplete at first. Once assets are mapped, change management takes over and in OT, that’s a slow, deliberate process by design. Every change touches physical processes. Safety and engineering reviews, operational impact assessments, backups before and after, the Management of Change process exists because a misconfigured system here isn’t just a technical problem. It can shut down a facility, or worse.

Risk in OT environments has a dimension that IT simply doesn’t carry: physical consequence. A compromised system can disrupt power grids, damage industrial equipment, harm personnel, and contaminate water supplies. The stakes shape everything how threat modeling gets done here. Threat actors, such as nation-states, criminal groups, and insiders, need to be mapped against realistic attack paths, not theoretical ones.

The guide also addresses that risk assessments in OT should blend automated data with expert judgment, prioritizing safety and operational continuity above everything else. The goal isn’t perfect security. It’s making sure zero trust decisions are grounded in the real-world consequences of getting it wrong.

Monitoring in OT environments isn’t just a technical requirement, but it’s where zero trust either proves itself or falls apart. The highest-risk junctions are where OT connects to IT or external systems, and that’s where monitoring priority should be concentrated. Excessive inbound traffic and unexpected external commands are often symptoms of poor segmentation, not just anomalies to log and move on from. CISA’s open-source SIEM tool, Malcolm, offers Zeek parsers built for common OT protocols and supports deep traffic analysis, a practical starting point for organizations without purpose-built solutions.

Passive monitoring through SPAN ports or network TAPs keeps observation load-free, without reconfiguring switch infrastructure. The relatively static nature of OT environments is actually an advantage here.

Behavior doesn’t change much. That makes deviations easier to spot and two approaches do this well. Baseline-based detection uses statistical models to flag deviations from normal, though learning windows need to be carefully defined to account for all operational modes. Specification-based detection defines the range of valid behaviors outright, capturing known failure states and viable conditions within the control system. Operator collaboration is essential for reducing false positives and building shared utility between cybersecurity and engineering teams. Timing interval metadata detection flagging when one system is communicating too frequently can catch spoofing without requiring extensive proprietary field documentation.

Endpoint detection in OT is a different problem than in IT, and treating it the same way causes real damage. Legacy components below the HMI or engineering workstation level often can’t support standard EDR agents without performance degradation. Some embedded systems tie the application and operating system so tightly that deploying any additional software isn’t just difficult, but is prohibited under warranty.

Cloud-connected EDR products, increasingly the norm, create another friction point in air-gapped or isolated networks where vendor server connections are impractical or outright blocked. A staging server in the DMZ that pushes updates without bidirectional agent communication is the recommended workaround where possible.

When it comes to Living off the Land ( LOTL ), hackers use legitimate tools already present in the environment, such as PowerShell, WMI, and vendor programming software, to carry out malicious activity without triggering detection.

In OT, where legacy and unauthenticated protocols are common, this technique is particularly effective. Attackers can mimic normal operations entirely. EDR in this context has to go beyond access controls, relying on behavioral and heuristic detection to catch subtle pattern deviations. But precision matters enormously. Blocking capabilities scoped too broadly will disrupt operator workflows or, worse, interfere with safety-critical processes, outcomes that no detection win is worth.

The guide identified that zero trust operates on an uncomfortable assumption that the breach has already happened. Initial defenses failed. Someone is already inside. That premise shapes everything how incident response gets built in OT environments, and it demands plans that go well beyond generic IT playbooks. IR strategies here need to be tailored, tested, and deeply specific. Isolation procedures should clearly define when and where disconnection happens, and who is pre-authorized to execute it, because in a crisis, nobody has time to find out.

Decision matrices, flowcharts, and MITRE ATT&CK -informed playbooks give teams a path to follow when pressure is high and clarity is scarce. lists stay current. Communication protocols exist before they’re needed. The hard calls need to be made in advance, too. A compromise detected on a safety network may warrant proactively shutting down operations entirely, as financial loss is recoverable and safety incidents often aren’t.

However, a compromise on a disconnected engineering workstation might warrant the opposite. These aren’t decisions to make in the moment. Plans should be reviewed at least quarterly, tested annually at a minimum, and revisited immediately after any event such as geopolitical tension, a spike in criminal activity, or a natural disaster that raises the threat environment.

Containment in OT is not the same problem as containment in IT. The systems were built for reliability, not security. Rapid changes carry real risk. Aggressive network isolation can disrupt critical processes, trigger safety incidents, or force production shutdowns, typically outcomes that sometimes rival the compromise itself. Security teams can’t make those calls alone. Coordination with process engineers and operations staff isn’t optional, but foundational.

Physical access controls limit who can interact with affected systems. Least privilege principles and just-in-time access reduce the threat surface before an incident even begins.

The guide addressed ‘soft segmentation,’ a carefully defined demarcation point rather than a hard cut, which is sometimes the more appropriate first move. Throughout all of it, documentation matters. Every action taken, every consequence considered. Recovery starts with knowing exactly what happened, and in OT environments, that record is often the difference between a contained incident and a prolonged crisis. Coordination with government agencies, including sector risk management bodies and intelligence community, accelerates that recovery and strengthens collective defense across critical infrastructure.

Recovery in OT environments doesn’t happen by improvisation. It gets built in advance, tested before it’s needed, and revisited regularly, or it fails when it matters most. Comprehensive backups are the foundation with OS configurations, application software and licenses, engineering logic, I/O lists, startup values, and configuration details. But OT backup capabilities vary wildly across devices. Some support only offline backups, some require manual downloads, some offer incomplete options, and some have no backup functionality at all.

The guide said that vendor documentation isn’t optional reading here, but it is the baseline. Standby systems kept current and ready for hot swap deployment can dramatically cut recovery time during outages. Engineering documentation, covering cause-and-effect matrices, control narratives, logic printouts, and specification sheets, are equally critical and often undervalued until something breaks. Restoration requires licensed engineering software specific to the equipment, kept onsite and current, and backup files should be tested regularly on development systems using file hashing or checksum validation to confirm integrity before a crisis forces the question.

Business continuity plans tie it all together. Organizations running industrial control systems likely already have a BCP, but cyber incident scenarios need to be explicitly integrated into it, not treated as an IT annex. Critical processes identified, recovery time objectives defined, procedures established for maintaining essential services under disruption. Cyber resilience in OT isn’t a separate workstream. It’s woven into every layer of how recovery gets planned, tested, and executed.

The CISA guide makes clear that implementing Zero Trust in OT environments is both complex and essential. It goes beyond a mere technological upgrade, representing a fundamental shift in security philosophy, one that assumes adversaries may already be present in the network. Unlike traditional IT security models, ZT in OT must balance the imperatives of safety, reliability, and continuous operation.

“Successfully navigating this journey requires a holistic approach that includes comprehensive asset visibility, robust identity and access management, and proactive supply chain risk management,” the document mentioned. “Layered security controls—such as network segmentation, secure communication protocols, and rigorous vulnerability management—serve as foundational building blocks. However, tools and technologies alone are insufficient to achieve ZT.”

It added that strong collaboration between IT, OT, and cybersecurity teams is critical to achieving effective and sustainable implementation of technology and processes. This collaboration requires breaking down organizational silos, fostering mutual understanding, and tailoring ZT principles to the unique characteristics and operational requirements of each OT environment. Ultimately, ZT in OT is not achieving perfection or zero risk, but making informed, deliberate decisions that reduce exposure and improve resilience without compromising mission-critical operations.

In February, the National Security Agency (NSA) published two Phases of the Zero Trust Implementation Guidelines (ZIGs) to outline the activities needed to achieve the Department of War (DoW)-defined Target-level Zero Trust (ZT) maturity. Leveraging NIST and DoW published guidance, the ZIGs are intended to assist the DoW, Defense Industrial Base (DIB), NSS, and affiliated organizations with incorporating ZT principles into their processes, enabling them to achieve Target-level ZT.

Extracted Entities

APT Groups (1)

Attack Types (1)

Platforms (2)

Tools (1)