Zero Trust for OT. What it actually means inside the boundary.
"Zero Trust" is the most overused term in OT cybersecurity. Every vendor claims it. Most product literature describing it would fail a five-question quiz. This article is the operator-and-architect version: what zero trust actually requires, why applying it to OT is harder than applying it to IT, and how it intersects with the architectural-safety patterns federal evaluators are now asking about.
The 30-second version
Zero trust is the security model that never implicitly trusts a principal because of where it sits on the network. Every access request — human, machine, or service — must be authenticated, authorized, and continuously validated against the requestor's identity, device posture, and the sensitivity of the resource.
The principle is straight from NIST SP 800-207 (the canonical zero-trust spec): "Never trust, always verify." The old security model — "we trust the corporate network, we distrust the internet" — collapses the moment an attacker gets inside the corporate network (which, in practice, they always do). Zero trust assumes the network is already compromised and treats every access decision as if there's no perimeter to defend.
Why it matters in OT: the air-gap is dead. Every operational network now has cloud connections, vendor remote-access tunnels, mobile-engineering laptops, and AI-augmented analytics platforms. The traditional "trust the OT network, distrust the IT network" model is exactly the architecture that gets exploited in every published ICS incident.
The five zero-trust principles
NIST SP 800-207 lays out the canonical principles. Applied to OT, they read like this:
Why zero trust is harder in OT than in IT
Modern enterprise IT environments are mostly user-driven systems on commodity OS with modern identity providers (Okta, Azure AD, Google), MDM-managed laptops, and SaaS apps that all speak OIDC/SAML. Zero trust there is conceptually clean if operationally painful.
OT has none of those things. Five specific challenges:
1. Legacy field devices can't authenticate
A 2008 Modbus PLC has no concept of identity. It responds to any request that arrives with a valid CRC. There's no "user" — just a wire. You can't put a zero-trust agent on it; you can't even reliably patch it. The realistic zero-trust posture is to enforce identity at the gateway that sits in front of it, not on the device itself.
2. Operators don't have time for friction
An operator responding to an alarm at 2 a.m. cannot tolerate MFA prompts every 8 minutes. Continuous-verification policies that work fine for an office worker break operations. Zero-trust-for-OT has to be invisible during normal work and resistant during anomalous behavior — the policy engine has to know the difference.
3. The "blast radius" of a bad decision is physical
An incorrectly denied access in IT means an annoyed user. An incorrectly denied access in OT could mean a compressor doesn't shut down when it needs to. Step-up authentication during an emergency is a liability, not a feature. The default-deny rules have to be paired with bypass-with-audit affordances for safety-critical actions.
4. The change-management discipline is rigid
Industrial sites change policies on quarterly maintenance schedules, not weekly sprint cycles. Zero-trust deployments that require ongoing rule tuning fight the operational culture of OT. The policies have to be relatively static and the analytics have to do the dynamic work.
5. The asset inventory is a swamp
You cannot zero-trust what you cannot enumerate. Most OT environments have incomplete asset inventories — devices added in the 2000s that no one currently working at the site can identify, vendor remote-access boxes installed during a project and forgotten, development PLCs that ended up in production. Zero trust on incomplete inventory is security theater. Asset discovery is the actual first step.
Zero trust vs IEC 62443 — same goal, different language
Industrial cybersecurity has its own canonical standard family — IEC 62443 — which predates the modern zero-trust vocabulary but converges on the same principles. The mapping is direct enough that most evaluators use them interchangeably; the differences matter when you have to demonstrate compliance to a specific framework.
| Concept | NIST SP 800-207 (Zero Trust) | IEC 62443 (OT Security) |
|---|---|---|
| Segmentation | Microsegmentation per resource | Zones and conduits per process function |
| Boundary enforcement | Policy Enforcement Point (PEP) | Security gateway between zones |
| Policy | Policy Decision Point (PDP) | Security Requirements per zone (SR/CR) |
| Identity | Per-session per-resource | SR 1.1-1.13 (Identification & Authentication) |
| Least privilege | Per-session | SR 2.1-2.4 (Use Control) |
| Logging | All access decisions | SR 6.1-6.2 (Timely Response to Events) |
| Assume breach | Explicit design principle | SL-T (Security Level Target) + recovery requirements |
Practical answer to "are we zero trust or IEC 62443": aim at IEC 62443 Security Level 2 minimum (most regulated OT environments) and document the zero-trust mapping as needed for federal RFPs. The IEC 62443 framework is more prescriptive about what to do; NIST SP 800-207 is more prescriptive about how to think.
What "zero trust OT" actually looks like in practice
A concrete zero-trust-aligned OT architecture, end-to-end:
- Asset discovery and identity assignment. Every device gets a cryptographic identity (X.509 certificate, hardware-bound where possible). Legacy devices that can't hold an identity get one at the gateway that talks to them.
- Microsegmentation at the protocol layer. Zones and conduits per IEC 62443. Traffic between zones flows through security gateways that authenticate both endpoints and enforce protocol-aware policy (e.g., "this OPC UA session may read these nodes, may not write any node").
- Identity-aware remote access. No flat VPNs into the OT network. Engineer access goes through a brokered, MFA-required, session-recorded, time-limited channel — typically a privileged-access management (PAM) gateway with OT-aware policy.
- Continuous monitoring with OT-native tooling. Dragos, Claroty, Nozomi, or equivalent providing protocol-aware anomaly detection. SIEM/SOAR integration so suspicious activity triggers policy enforcement (session termination, alert escalation), not just dashboards.
- Software-defined zone enforcement at the cloud boundary. Any cloud-touching workload (analytics, remote operations, AI augmentation) sits in a cloud account whose service-control policies — enforced at the cloud-org level, not by application — make certain actions architecturally impossible. This is where Aevus's IL-9000 pattern lives.
- Audit-everything posture. CloudTrail-equivalent for cloud, syslog-everything for on-prem, with retention policies that survive compromise of the OT environment (immutable logs, off-site copy).
The federal angle — why zero trust for OT is suddenly mandatory
Three federal forcing functions, in chronological order of how-hard they hit:
EO 14028 (Executive Order on Improving the Nation's Cybersecurity, 2021)
Mandated zero-trust adoption across federal agencies. CISA followed with the Zero Trust Maturity Model (current v2.0, 2023). Every federal civilian agency is somewhere on the adoption curve. RFPs increasingly require zero-trust-aligned solutions.
CMMC 2.0 (Cybersecurity Maturity Model Certification)
Required for any contractor handling Controlled Unclassified Information (CUI) for DoD. CMMC Level 2 maps closely to NIST SP 800-171; CMMC Level 3 incorporates zero-trust principles directly. If you sell to DoD, this is mandatory and rolling out through 2026-2027.
FERC Order 850-style mandates for critical infrastructure
NERC CIP for bulk electric system. PHMSA for pipelines. EPA cybersecurity rulemaking for water utilities (still in development). Each sector regulator is bolting zero-trust-shaped requirements onto existing OT cybersecurity rules. The aggregate effect: zero-trust posture is no longer optional for any operator selling to or regulated by the federal government.
How IL-9000 is a zero-trust pattern
IL-9000 — Aevus's architectural safety mechanism for AI-augmented SCADA — is, in zero-trust terms, a cloud-org-level Policy Enforcement Point that denies a specific class of actions to a specific principal even when the principal is fully authenticated and inside the boundary.
Specifically: the Aevus AI runs inside the Aevus cloud boundary. Its IAM principal is fully authenticated, has all the privileges Aevus's application code needs to do its job, and is "trusted" in every conventional sense. But the AWS Organization Service Control Policy that governs the Aevus account denies the write-to-customer-field API category entirely. The denial is enforced one layer above the Aevus account boundary, by a principal Aevus does not hold.
That's the zero-trust principle in its purest form: even an authenticated, trusted principal cannot perform actions outside the explicit grant of the policy. And the policy lives where the principal cannot edit it.
The federal-evaluator framing: "Aevus's AI is a least-privilege principal whose write-to-field capability is denied at the cloud-org PEP, enforced by a separate authority above the application boundary." That sentence checks every zero-trust box federal procurement asks about — and Aevus is the only vendor that can claim it architecturally rather than via policy that could be modified.
Full technical brief: IL-9000 Technical Brief.
What "we're zero trust" really means — and what it doesn't
"We're zero trust" is the most overpromised claim in OT cybersecurity. Three honest framings to use:
- "Zero-trust-aligned" — we follow the principles, we have most of the controls, we're on the maturity curve. Honest, defensible.
- "Zero-trust ready" — our architecture supports zero-trust enforcement when the customer's identity and policy infrastructure are in place. Vendor honesty.
- "Zero-trust enforced at the cloud-org boundary" — for a specific class of actions, our architecture makes the denial structural, not procedural. Only valid if true. Aevus's IL-9000 is one of the few claims of this kind that survives technical scrutiny.
What's not honest: "We're zero trust because we have MFA." MFA is one control of many. Calling a product zero-trust because it supports MFA is exactly the marketing confusion that has made the term suspect.
That's zero trust for OT.
If your organization is implementing zero-trust posture for OT — or being asked to demonstrate it for federal procurement — Aevus's architecture is built around the principle that even authenticated, trusted principals cannot perform out-of-policy actions. It's the zero-trust pattern, enforced architecturally.
Related Articles
The OT security controls that actually move the needle.
Site-to-site, remote access, and why flat VPNs fail in OT.
The 5 compute tiers and the cloud-vs-edge decision framework.
Ready to see how this applies to your operation? Start a pilot conversation — no commitment, no field changes.