Zero Trust OT Industrial Networks: How to Apply CISA's 2026 Framework Without Breaking Production

Q: We already segmented our OT network with IEC 62443 zones and conduits - do we still need Zero Trust?

Yes, and it's additive rather than a redo. Segmentation controls the network boundaries traffic has to cross; it doesn't verify individual requests once traffic is already inside an authorized zone. Zero Trust's identity and access management pillar closes that specific gap.

Diagram contrasting IEC 62443 zone-and-conduit segmentation, where devices inside a zone implicitly trust each other, with Zero Trust, where every connection inside the same zone is individually verified per request via identity and access checks.

Zero Trust in an OT/industrial network means every access request — from a device, a user, or an application — gets its identity, context, and risk checked before it's allowed, regardless of which network zone it originates from. It does not mean re-segmenting the network; that's a separate discipline (IEC 62443 zones and conduits) that decides where traffic-control boundaries sit. On April 29, 2026, CISA and four other U.S. federal agencies published the first comprehensive federal guidance mapping Zero Trust specifically onto OT/ICS environments, organized around three pillars: asset visibility, identity and access management, and supply chain risk management. It's non-binding guidance, not a regulation — and the passive-monitoring requirement in pillar one is the detail most likely to change how you roll it out.

By The Whitepaper Skeptic — OT reviews of unverified vendor remote access inside segmented zones

Quick Facts

Question	Answer
What is Zero Trust in OT?	Continuous identity, context, and risk verification for every access request inside an OT network — not a network topology or segmentation design
When was CISA's OT Zero Trust guidance published?	April 29, 2026
Who co-published it?	CISA, the U.S. Department of War (the current name of the former U.S. Department of Defense), the Department of Energy, the FBI, and the Department of State
What are the three pillars?	Asset visibility (passive monitoring), identity and access management, and supply chain risk management
Is it mandatory?	No — non-binding guidance, loosely aligned to NIST CSF 2.0, with no compliance deadline attached

Zero Trust vs. IEC 62443 Zones and Conduits: Why You Need Both

If you already read IEC 62443 Zones and Conduits Explained, you've seen this question coming: isn't Zero Trust just a rebrand of the segmentation work you already did? No — and that article actually forecasts the answer in its own "Purdue Model vs. Zones and Conduits in 2026" section, which quotes 2026 industry commentary concluding that the resolution to IIoT and cloud boundary-crossing concerns isn't "replace Purdue," it's "keep Purdue's layering logic for where zone boundaries sit, and layer zero-trust identity and access verification inside each zone." This article is the delivery on that forward reference.

Zones and conduits answer a topology question: which zone can talk to which zone, through which controlled, filtered path. Once a device is inside a zone, it's generally trusted to talk to other assets in that zone, subject only to the conduit's own filtering at the boundary. Zero Trust answers a different question entirely: should this specific identity, right now, in this context, be allowed to do this specific thing — regardless of whether the request originates from inside or outside a segmented zone. "Never trust, always verify" means no request gets a free pass on identity, context, and risk checks just because it's zone-internal.

Aspect	IEC 62443 Zones & Conduits (Segmentation)	Zero Trust (CISA's April 2026 guidance)
Core question	Which zone can talk to which zone?	Should this identity be allowed to do this, right now?
Trust model	Implicit trust within a zone once you're inside it	No implicit trust — every request verified regardless of network location
What it controls	Traffic-control points between network boundaries (conduits, DMZs, firewalls)	Per-request identity, device posture, and access context
Defends against	Lateral spread across zone boundaries via unfiltered network paths	Valid-credential abuse using legitimate protocols and authorized pathways already inside a zone
Governing reference	IEC 62443-3-2 (zone/conduit partitioning) and 3-3 (security levels)	CISA's April 2026 joint OT Zero Trust guidance (non-binding)
Relationship to the other	Foundational — Zero Trust doesn't replace this	Layers on top of segmentation, not instead of it

The "implicit trust within a zone" row is the one I've had to argue about in a live review. The pushback was reasonable on its face — the conduit firewall logged every session crossing the boundary, and the team read that logging as coverage — but those logs answer the left-hand column's question (which zone may talk to which) and not the right-hand column's (should this identity be allowed to do this, right now). A vendor account reusing an already-authorized path produces clean conduit logs the entire way through. The segmentation there was genuinely well built, which is exactly why that gap was so hard to get anyone to look at.

The practical implication: an organization that already invested in zone/conduit segmentation hasn't wasted that work, and doesn't need to redraw its network diagram to adopt Zero Trust. It needs to add per-request verification inside the zones it already built.

What CISA's April 2026 Joint Guidance Actually Says

"Adapting Zero Trust Principles to Operational Technology" was jointly published on April 29, 2026 by CISA, the U.S. Department of War (the current operating name of the former U.S. Department of Defense, following its 2025 rebrand — worth flagging for an international audience unfamiliar with the change), the Department of Energy, the FBI, and the Department of State. It's the first comprehensive federal guidance that maps Zero Trust principles specifically onto OT/ICS environments rather than treating OT as a subset of IT security.

The guidance is explicit that a direct port of IT-style Zero Trust into OT doesn't work: the joint guide states plainly that "the blanket application of traditional information technology (IT)-focused ZT capabilities to OT is neither reasonable nor feasible." Instead, the recommendations are loosely aligned to NIST CSF 2.0 and organized around the three pillars covered below.

It's guidance, not a binding regulation, and it doesn't carry a compliance deadline. That said, industry security analysis published in the weeks after release already frames it as likely to become the reference point auditors and assessors check OT implementations against under frameworks that do carry compliance force — CMMC and the EU's NIS2 among them — even though the guidance itself imposes no legal mandate.

The Three Pillars, One at a Time

Pillar 1: Asset Visibility — Passive, Not Active

You can't verify the identity of a device you don't know exists. That's why asset visibility is the guidance's first pillar, and why it specifically calls for passive monitoring rather than active scanning as the default discovery method in OT — the same distinction covered in more depth in OT Asset Management: How to Build an Industrial Asset Inventory. Active scans send probes directly to devices; legacy PLCs and RTUs that were never built to handle unexpected traffic can crash or hang when scanned. Passive monitoring reads a copy of network traffic off a mirrored port or tap instead, which is why it's the industry-standard default for live production OT networks rather than an optional preference.

This pillar isn't new territory that segmentation work already covers — the zones-and-conduits design process assumes an asset inventory as an input, but it doesn't specify a discovery methodology. Zero Trust's guidance is explicit that the method matters as much as the outcome.

Pillar 2: Identity and Access Management

Once you know what's on the network, the second pillar is verifying who and what is allowed to access it — and re-verifying continuously, not just at initial connection. In practice this covers device identity (not just user identity), least-privilege access scoped to what a specific role or device actually needs, and re-authentication or re-authorization tied to context changes rather than a one-time login. This is the pillar that does the actual "never trust, always verify" work inside a zone that segmentation alone leaves untouched.

Pillar 3: Supply Chain Risk Management

This pillar has no overlap with the segmentation spoke at all — it's the cleanest differentiation point in the whole guidance. It covers the risk that a compromised vendor, integrator, or component introduces a foothold that no amount of network topology design would catch, because the access or the code shipped in through an already-trusted channel. That includes vendor remote-access credentials, firmware and software provenance for OT-specific hardware, and contractor access scoped and time-limited rather than standing. None of this is a network-diagram problem; it's an identity-and-provenance problem, which is exactly why it sits inside a Zero Trust framework rather than a segmentation one.

Why Segmentation Alone Isn't Enough: The Volt Typhoon Problem

The clearest real-world justification for adding Zero Trust on top of good segmentation is the threat pattern associated with nation-state actors like Volt Typhoon — and CISA drew that connection itself at release. Chris Butera, CISA's Acting Executive Assistant Director for Cybersecurity, said at the guidance's announcement that "CISA has observed threat actors like Volt Typhoon targeting OT systems to compromise, escalate, and maintain access within operational environments." Volt Typhoon-style intrusions don't rely primarily on exploiting software vulnerabilities to breach a conduit's filtering rules. They compromise through legitimate protocols, authorized administrative tools, and valid credentials — the kind of activity that, once inside a zone, a conduit filter was never designed to catch, because the traffic looks like normal, authorized zone-internal communication.

That's the scenario a well-designed zone/conduit architecture doesn't stop on its own: an attacker doesn't need to breach a conduit filter at all if they can obtain valid credentials that go unverified once they're already inside a zone. Zero Trust's identity and access pillar is the control that closes that specific gap — continuous, per-request verification that doesn't assume a credential is legitimate just because it originated from inside a trusted zone.

How to Roll Out Zero Trust in OT Without Breaking Production

The sequencing the three pillars imply also happens to be the safest rollout order for a live production network:

Start with asset visibility, using passive monitoring. This is non-negotiable groundwork — you cannot scope identity and access controls around devices you can't see, and active scanning risks the exact production disruption this whole exercise is trying to avoid.
Layer in identity and access management next. Start with the highest-risk access paths first — remote vendor access and administrative credentials with broad reach — rather than attempting a blanket rollout across every device at once. This is where the reconciliation with existing IEC 62443 segmentation work happens: your zone/conduit boundaries already tell you which zones carry the highest-consequence assets, so that's where IAM controls go first.
Address supply chain risk management last, but not as an afterthought. Vendor and integrator access reviews, firmware/software provenance checks, and time-limited contractor credentials can run in parallel with pillar 2 once the highest-priority access paths are under identity controls.

If your organization already invested in IEC 62443 zone/conduit segmentation, this rollout doesn't ask you to undo that work. It asks a narrower, additive question at each zone boundary you've already drawn: now that traffic can only reach this zone through a controlled conduit, is every request that reaches an asset inside that zone actually being verified — or is anything that gets past the conduit filter implicitly trusted from there on? For most segmented-but-not-Zero-Trust networks, the honest answer is the latter, and that's the gap this guidance is aimed at closing.

FAQ

Q: Is Zero Trust the same thing as network segmentation in OT?
A: No. Segmentation (IEC 62443 zones and conduits) controls where traffic can flow between network boundaries, and generally trusts a device once it's inside an authorized zone. Zero Trust controls whether a specific request — from a specific identity, in a specific context — should be allowed at all, regardless of which zone it originates from. They're complementary, not competing: Zero Trust adds per-request verification inside the zones segmentation already defines.

Q: What did CISA's 2026 Zero Trust guidance for OT actually require?
A: "Adapting Zero Trust Principles to Operational Technology," published April 29, 2026 by CISA, the U.S. Department of War, the Department of Energy, the FBI, and the Department of State, is non-binding guidance — not a regulation — organized around three pillars: asset visibility via passive monitoring, identity and access management, and supply chain risk management. There's no compliance deadline attached.

Q: How do I implement Zero Trust in OT without disrupting production?
A: Start with passive asset-visibility monitoring rather than active scanning, since active scans can crash legacy PLCs and RTUs. Once visibility is established, roll out identity and access controls starting with the highest-risk access paths (vendor remote access, broad administrative credentials) rather than attempting a blanket rollout across every device simultaneously.

Q: What's the difference between passive monitoring and active scanning in OT security?
A: Passive monitoring reads a copy of network traffic off a mirrored port or network tap without interacting with devices directly, which makes it safe for fragile legacy equipment. Active scanning sends probes or queries directly to devices, which can crash or hang PLCs and RTUs that were never designed to handle unexpected requests — CISA's guidance specifically calls for passive monitoring as the default discovery method for the asset-visibility pillar.

Q: We already segmented our OT network with IEC 62443 zones and conduits — do we still need Zero Trust?
A: Yes, and it's an additive investment rather than a redo. Zone/conduit segmentation controls the network boundaries traffic has to cross; it doesn't verify individual requests once traffic is already inside an authorized zone. Nation-state threat actors that use legitimate protocols and valid credentials — rather than exploits — can move inside a zone without ever triggering a conduit's filtering rules, which is the specific gap Zero Trust's identity and access management pillar is designed to close.

Sources

Author Bio

The Whitepaper Skeptic has direct experience with OT cybersecurity in industrial and smart-factory environments, including customer-facing security architecture reviews where segmentation was already in place — zones and conduits were correctly drawn — and the review's most contested finding was that zone-internal traffic and vendor remote-access credentials still weren't being verified request-by-request. That's the exact gap this guidance's identity and access management pillar targets, not a theoretical one.

Search This Blog

Beyond the Whitepaper