· Eduardo Vieira · Critical · 5 min read
Zero Trust & IEC 62443: The New Rules of Engagement for OT Security
Translate Zero Trust decisions into OT zones, conduits, asset and identity policy without making plant control depend on external identity services.
Zero Trust can improve operational technology (OT), but not as the slogan “never trust.” A control architecture needs explicit, repeatable decisions about which subject may use which resource, for what purpose, and under what conditions. IEC 62443-style zones and conduits provide a practical place to enforce those decisions while preserving safety and availability.
This is not another Purdue Model checklist. Purdue describes functional hierarchy; our separate Purdue guide covers levels, segmentation, and asset hardening. Here the search intent is different: translate Zero Trust policy into communication paths, identities, evidence, exceptions, and lifecycle ownership. This is an engineering method, not a certification or compliance claim.
Translate principles into enforceable paths
NIST SP 800-207 defines Zero Trust around protecting resources rather than network segments and granting access through dynamic policy. In OT, “resource” can mean an engineering workstation session, a historian query, or a permitted protocol operation. Location alone does not establish trust, but location remains useful as one policy signal and as a containment boundary.
Start with flows, not products. Record the source subject, destination asset, allowed service or operation, operational purpose, approval owner, time condition, and evidence to retain. Then group assets with compatible security requirements into zones. Every allowed cross-zone flow becomes a conduit with a deny-by-default rule set. A VLAN is not the policy; it is one possible enforcement mechanism.
Do not put real-time control behind a direct dependency on cloud identity, DNS, or an enterprise directory that can halt control when unavailable. Controllers must retain their validated local control behavior during identity-service loss. Place human administration through bounded access services, while autonomous safety and control traffic follows prevalidated local conduits.
A deterministic policy matrix
The following fixture uses synthetic identities and assets only. It is deliberately small enough to review as policy-as-data before translating it into firewall, jump-host, or application rules.
| rule | synthetic subject | source zone | synthetic resource | destination zone | allowed action | condition | evidence | fallback |
|---|---|---|---|---|---|---|---|---|
| ZT-01 | operator.alex | Operations | hmi.sim-01 | Cell-A | view, acknowledge | assigned shift | session log | local HMI remains available |
| ZT-02 | vendor.north | Vendor Access | engws.sim-01 | Engineering | interactive maintenance | approved ticket, MFA, 60 min | recording, commands | deny when broker unavailable |
| ZT-03 | historian.sim | OT Services | plc.sim-01 | Cell-A | read approved tags | fixed service identity | flow log | buffer locally; no control impact |
The matrix separates identity from authority. vendor.north being authenticated does not authorize arbitrary subnet access; rule ZT-02 grants one resource, one purpose, and a short condition. Likewise, the historian’s service identity cannot write control values. Test both allowed and denied paths using synthetic assets before deployment.
Bound remote and vendor access
Remote access is a conduit, not a flat VPN entitlement. Terminate it in a controlled access zone, require an individually attributable account, phishing-resistant MFA where supported, an approved work order, a defined window, and explicit destination allowlists. Route the session through a managed jump service; do not expose HMIs, PLCs, or engineering protocols directly to the public Internet.
For vendors, separate authentication, authorization, and supervision. Disable standing accounts when practical, prohibit shared identities, record administrative sessions where policy and law permit, and provide a plant-side way to terminate access. Emergency access needs a documented local procedure, limited credentials, after-the-fact review, and drills. It must not silently become the normal route.
Monitor decisions without disturbing control
Collect evidence at policy enforcement points: connection outcome, rule identifier, subject, destination, requested service, time, and reason for denial. Add passive network monitoring where it can observe without introducing inline failure. Baseline expected conduits and alert on new source-destination pairs, engineering activity outside approved windows, repeated denials, or policy drift.
Monitoring is not automatic proof of compromise. OT protocols, maintenance, failover, and startup sequences create legitimate changes. Send alerts to people who understand the process context, define escalation, synchronize time where safe, and protect logs from alteration. Avoid active scanning or response automation that could disrupt fragile devices unless validated with the asset owner.
Handle legacy assets with compensating controls
Some PLCs cannot support modern identity, encryption, or detailed audit logs. Do not pretend a passwordless device has become Zero Trust. Narrow its conduit to known peers and required operations, place administration behind a hardened intermediary, restrict physical access, retain configuration backups, monitor passively, and document the residual risk and control owner.
Compensating controls are bounded exceptions, not permanent invisibility. State the unsupported capability, threat reduced, remaining exposure, validation method, expiration or review date, and replacement trigger. NIST SP 800-82 Rev. 3 emphasizes tailoring safeguards to OT performance, reliability, and safety requirements; a security control that interrupts a validated control loop can create a different hazard.
Govern the lifecycle
Assign owners for assets, zones, conduits, identities, and exceptions. Review policy when equipment, firmware, integrators, recipes, remote-support contracts, or network paths change. Revoke access promptly when roles or contracts end. Test restoration of local administration and control after identity, jump-service, or logging outages.
Track a small set of useful measures: unknown assets investigated, stale accounts removed, temporary rules expired, denied paths tested, exceptions overdue, and recovery drills completed. Changes should pass engineering review, safety review where applicable, staged validation, rollback planning, and an approved maintenance window. Certification may impose additional requirements, but this article neither evaluates nor promises certification or compliance.
Official sources
Accessed 2026-07-24:
- ISA, ISA/IEC 62443 Series of Standards.
- ISA99 committee, Industrial Automation and Control Systems Security.
- NIST, SP 800-207: Zero Trust Architecture.
- NIST, SP 800-82 Rev. 3: Guide to Operational Technology Security.
- CISA, Principles of Operational Technology Cyber Security.
- CISA, Guide to Securing Remote Access Software.
The result is not “trust nobody.” It is a reviewable set of least-privilege decisions, enforced at bounded conduits, observed through useful evidence, and designed so loss of enterprise identity does not stop the process.
