"Zero trust" has been stretched by marketing until it can mean anything - which is a shame, because the underlying idea is exactly what industrial operations need. The old OT security model trusted the network: if you were on the plant LAN, you were assumed legitimate. Every major industrial intrusion of the past decade abused precisely that assumption. This guide strips zero trust back to its engineering content - identity-first access, least privilege, verified devices and data, microsegmentation, continuous monitoring - and shows how to apply each pillar to a working SCADA environment without breaking the Purdue model or taking the plant down to do it.
Explore the full security & certification article series - 60+ practitioner guides.
Zero trust, formalized in NIST SP 800-207, Zero Trust Architecture, is a single architectural decision applied everywhere: no actor is trusted because of where it sits on the network. Every access request - human or machine - is authenticated, authorized against least-privilege policy, and evaluated in context, every time. Trust is never inherited from an IP range, a VLAN, or a VPN session established hours ago.
That is the whole idea. It is not a product you buy, and it is not synonymous with "cloud." The practical pillars that fall out of it are: strong identity for every user; verified identity for every device; least privilege enforced at the level of individual actions, not network reachability; segmentation that assumes breach and limits blast radius; and continuous verification - logging, monitoring, and revocation that operate all the time rather than at login only.
Why does this matter for SCADA specifically? Because the historical OT security model is the purest example of its opposite. A traditional plant network extends trust generously: the HMI trusts the network, the PLC trusts anything that speaks Modbus to it, the historian trusts the polling service, and remote access arrives through a VPN that turns an external laptop into an internal machine. One phished credential or one compromised vendor laptop inherits all of that trust at once. The incidents that made headlines - from the Ukrainian grid attacks to plain commodity ransomware wandering from IT into OT - were failures of inherited trust, not failures of firewalls.
OT engineers sometimes hear zero trust pitched as "the perimeter is dead" and reasonably bristle - nobody responsible is going to flatten the network between the internet and a safety system. The correct reading is different: segmentation stays; blind trust inside segments goes. The Purdue model and IEC 62443 zones and conduits remain the containment structure - the defense-in-depth segmentation that NIST SP 800-82 Rev. 3's OT security guidance also prescribes. Zero trust changes what happens within and across that structure - a workstation on Level 3 no longer gets to talk to a controller merely because it is on Level 3.
| Dimension | Perimeter-Era OT Model | Zero-Trust OT Model |
|---|---|---|
| Basis of trust | Network location - inside the plant LAN means trusted | Verified identity of the user, device, and request |
| Authentication | Shared operator logins; auto-logged-in HMIs; VPN once, trusted all day | Named accounts, MFA and passkeys, session expiry, step-up auth for critical actions |
| Authorization | Reachability equals permission - if you can route to it, you can write to it | Per-action policy: role, site, and tag-level checks with bounds on every write |
| Device trust | Any device speaking the protocol is believed | Registered devices with unique credentials; telemetry signed and verified |
| Remote access | Inbound VPN or port forwarding into the OT zone | Outbound-only connectivity; no inbound listening surface at all |
| Failure assumption | Breach is prevented at the boundary | Breach is assumed; blast radius limited, everything audited |
| Monitoring | Perimeter alerts; interior mostly dark | Continuous - auth failures, privilege probes, anomalous control activity all surfaced |
Keep both columns in mind as a buyer: a vendor should strengthen your segmentation story (by not demanding inbound holes through it) while giving you the identity, authorization, and monitoring machinery the right-hand column requires. The OT network security guide covers the zones-and-conduits side in depth; this post covers the trust side.
Identity is where zero trust starts, and where most OT environments have the furthest to go. Shared "operator" accounts, passwords taped to consoles, and contractors who keep working credentials for years are still common - and every one of them makes per-request verification impossible, because the system cannot know who is asking.
The implementable baseline, in rough order of effort:
This is the pillar Merobix ships most completely today: TOTP and FIDO2 passkeys, six-tier roles with site-level authorization, session expiry and revocation with concurrent-session limits, persistent lockout on brute-force patterns, and step-up authentication on high-risk workflows such as permit signing. When you evaluate any platform, ask for a demonstration of each item on the list above - our SCADA authentication guide gives you the full question set.
Zero trust applies to machines as much as people. In a perimeter-era SCADA system, the platform believes whatever arrives on the right port in the right protocol - which means anyone who can reach the network can inject fabricated process values or replay yesterday's traffic. If operators and algorithms act on data, the data's provenance is a security boundary.
A zero-trust data path looks like this: every gateway and device is individually registered with unique credentials - never a fleet-wide shared secret. Devices hold their own cryptographic signing identities (Merobix gateways generate Ed25519 keys) and sign the telemetry they emit, with envelopes carrying sequence numbers, timestamps, sample IDs, and payload digests so the platform can verify origin and integrity and detect replays. Transport is TLS everywhere - cloud, MQTT, and industrial connections - and gateway software updates are signed artifacts, verified before activation, so the device fleet itself cannot be quietly repurposed. Merobix is extending this by making signed telemetry mandatory across all ingestion paths, including migrating legacy gateway traffic to signing - a useful benchmark question for any vendor: "is signed data optional in your architecture, and if so, why?" The mechanics are covered in our telemetry integrity deep dive.
Nowhere does least privilege matter more than where software meets physical process. Zero trust demands that the ability to reach a controller never implies the ability to command it. Concretely:
Merobix implements this control-path model end to end, and every command and acknowledgement lands in the audit record. The full pattern - and what to demand from any vendor - is in the remote control security guide.
On the network layer, zero trust means assuming the breach and engineering the blast radius. Microsegmentation - shrinking zones until a compromised machine can reach almost nothing - is the IT playbook, and it applies in OT with a caveat: you segment around process cells and safety boundaries, guided by engineering reality, not just by VLAN convenience.
The cleanest zero-trust move available to a SCADA buyer, though, is at the OT boundary itself: outbound-only connectivity. A gateway that initiates all connections outward over TLS, authenticated with its own device identity, gives the internet-facing attack surface a value of zero - nothing is listening, so there is nothing to scan, exploit, or brute-force. Contrast that with the VPN pattern, which is perimeter-era thinking wearing a zero-trust costume: the concentrator is an internet-exposed, CVE-prone inbound door, and a stolen VPN credential typically inherits broad network reach. The Merobix gateway requires no inbound firewall rules and no VPN; access to the process flows only through the platform, where every request hits the identity and authorization machinery from Pillars 1–3. Multi-tenant isolation continues the same principle inside the cloud: tenant-aware authorization backed by PostgreSQL row-level security and signed database request context, with cross-tenant denials logged and alerted - detailed in our multi-tenant security guide.
Zero trust is not a login policy; it is a standing posture. Verification continues after authentication: sessions expire and can be revoked centrally, privileges are re-checked per action, and the system watches for the patterns that precede incidents - repeated authentication failures, privilege probes, cross-tenant denial attempts, suspicious control activity. Detections must reach humans reliably: security notifications should flow through a durable delivery pipeline (with retries and dead-letter handling, not fire-and-forget email) to on-call staff and to your SIEM, so OT events appear in the same console your security team already watches. Merobix runs this detection-and-delivery stack in production; the buyer's view of it is covered in the threat detection and SIEM guide. Close the loop with immutable audit records - continuous verification you cannot prove afterward is continuous hoping.
You cannot deploy all five pillars in a quarter, and you should not try. The sequence below orders work by risk reduction per unit of process disruption - the early phases touch no control logic at all:
Key takeaway: Zero trust for SCADA is not a product and not the death of the Purdue model - it is the removal of inherited trust. Keep your zones and conduits, then make every human authenticate strongly, give every device its own verified identity, authorize every control action individually with bounds, connect outbound-only so nothing listens at the boundary, and monitor continuously. Buy platforms that ship these behaviors by default; see how Merobix implements each pillar on the security architecture page.
A platform either carries its share of your zero-trust architecture or quietly undermines it. In evaluations, require demonstrations - not slideware - of: MFA with phishing-resistant options and step-up authentication; granular roles with site-level scoping; per-device registration with signed telemetry; explicit writable-tag control with bounds checking; outbound-only connectivity with zero inbound rules; tenant isolation enforced in the database layer; and audit plus SIEM export for everything above. Score each as shipped and shown, roadmap, or absent - and treat "we can configure that" as roadmap. The cloud SCADA security checklist turns this into a full evaluation scorecard, and a Merobix demo is a fair place to hold us to the same standard.
Zero trust means no user, device, or connection is trusted because of where it sits on the network. Applied to SCADA, every operator authenticates with MFA and gets a named account with least-privilege permissions, every gateway and field device has its own cryptographic identity, telemetry is verified rather than assumed authentic, control actions are authorized per tag with bounds checking, and everything is logged and monitored continuously. It replaces the old model - hard perimeter, trusted plant LAN - with per-request verification, which matters because most real OT incidents start with a legitimate credential or a trusted network path being abused.
No - they complement each other. The Purdue model and IEC 62443 zones and conduits still provide the network structure: safety systems and controllers stay segmented, and traffic between levels remains controlled. Zero trust adds identity-based verification inside and across that structure, so a device on Level 3 is no longer trusted just for being on Level 3. In practice, mature OT programs keep segmentation as containment (limiting blast radius) and layer zero-trust controls (per-user MFA, per-device identity, per-action authorization) on top. Removing segmentation in the name of zero trust is a misreading of the concept.
Outbound-only gateways are one of the cleanest zero-trust patterns available to OT. Instead of exposing inbound ports or VPN concentrators that implicitly trust whoever connects, the gateway initiates all connections outward over TLS, authenticates with its own device credentials, and signs the data it sends. Nothing on the internet can initiate a connection into the OT network because nothing is listening. Access to the process then flows through the platform, where every request is authenticated, authorized per role and site, and audited - identity-based access instead of network-based access, which is the core of zero trust.
Phase it, starting with controls that do not touch the process. First fix identity: named accounts, MFA, role-based least privilege, and session controls - no process interruption at all. Second, establish device identity and outbound-only connectivity at the gateway layer, which can be deployed alongside existing paths and cut over during a maintenance window. Third, tighten the control path with writable-tag allowlists, setpoint bounds, and step-up authentication. Fourth, add continuous monitoring and audit review. Full network microsegmentation comes last, because it is the most invasive; interim wins like isolating the SCADA conduit deliver most of the benefit early.
Demand five things. Identity: MFA including phishing-resistant options like passkeys, granular roles, session expiry and revocation, and step-up authentication for high-risk actions. Device identity: unique per-device registration and credentials, with signed telemetry so data provenance is verifiable. Least privilege on the control path: explicit writable-tag configuration, setpoint bounds checking, and per-site authorization. Network fit: outbound-only connectivity that requires no inbound firewall rules. And verification: audit records for every action plus runtime detection of anomalies such as repeated authentication failures or suspicious control activity. A vendor missing several of these is selling perimeter-era architecture.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Passkeys and step-up auth, per-device signed telemetry, writable-tag allowlists with bounds checking, and an outbound-only gateway with zero inbound rules - see every pillar running live.