Executive Summary

Zero Trust has become the dominant cybersecurity narrative of the past several years, and is now being aggressively marketed for operational technology environments. Vendor presentations describe Zero Trust architectures applied to industrial control systems with the same enthusiasm previously reserved for digital twins, predictive maintenance, and the broader IIoT story. The marketing produces, predictably, two equal and opposite reactions: uncritical adoption by operators eager to demonstrate modern thinking, and reflexive dismissal by operators who recognise that not every IT concept transfers cleanly to OT. Both reactions are wrong.

The honest analysis sits between them. Zero Trust as a coherent set of principles is mostly correct for OT environments, with several principles fitting cleanly, several requiring careful adaptation, and at least one breaking entirely at the lower levels of the Purdue model. The defender who recognises which principle falls into which category is meaningfully ahead of the defender who treats Zero Trust as either a turnkey solution or a passing fad.

This whitepaper walks through the principles defined in NIST Special Publication 800-207 and the CISA Zero Trust Maturity Model, evaluates each one against the operational realities of industrial control systems, and identifies specifically where each principle translates well, where it requires adaptation, and where it does not work at all. It then presents an architectural translation framework that operators can apply to their own environments, and a phased implementation roadmap that sequences Zero Trust capability against the operational constraints that matter.

The argument running through this document is that Zero Trust is best understood not as a product or an architecture but as a set of design principles. Some of those principles are genuinely transformative when applied to OT (least privilege, default deny, assume breach). Some require thoughtful adaptation to the structural realities of industrial environments (verify explicitly, microsegmentation). One principle in its purest form is operationally infeasible at the control loop layer (continuous verification), and the responsible response is to acknowledge this rather than pretend otherwise.

This paper is a companion to the IT/OT Cybersecurity in Heavy Engineering and the Anatomy of an OT Incident whitepapers earlier in this series. The architecture paper described what to defend; the incident paper described what defenders actually face; this paper addresses how to think about a specific architectural philosophy that is currently being applied across the field.

The document concludes with two appendices: a glossary of the acronyms used throughout the text, and a Zero Trust translation self-assessment checklist that operators can apply to their own programmes.

Zero Trust for OT is a mostly-correct programme that requires sober translation, not wholesale adoption or wholesale rejection. The defender who recognises which principles fit, which adapt, and which break is well-positioned to extract the value from the concept while avoiding the failure modes.

Key Takeaways

•       Of the eight principles examined, five fit OT cleanly or with adaptation (least privilege, assume breach, default deny, identity-as-perimeter at the human layer, microsegmentation as zone-and-conduit). Two require adaptation to the boundary or upper layers (verify explicitly, encrypt all traffic). One breaks for L0–L2 control loops (continuous verification).

•       The OT translation of microsegmentation is the IEC 62443 zone-and-conduit model. These are not separate concepts; they are the same architectural principle applied in different domains. Operators that already have a mature 62443 implementation have already implemented OT microsegmentation, regardless of what their vendor calls it.

•       Identity-centric Zero Trust translates strongly at the human and administrator layer in OT, where the failure modes of weak identity are well-documented. It translates poorly at the machine-to-machine layer at the lower Purdue levels, where deterministic timing and brownfield protocols constrain what is possible.

•       “Continuous verification” in its IT formulation — re-evaluating trust on every transaction — is operationally infeasible on a PLC control loop. The honest architectural response is to apply continuous verification at the human/admin boundary and to constrain the consequence of trust at the machine layer through other controls.

•       Most vendor “Zero Trust for OT” offerings deliver a subset of the principles applied to a subset of the environment. The honest evaluation requires understanding which subset, applied where, with what gaps remaining. The marketing typically does not make this disclosure on the buyer’s behalf.

1. The Zero Trust Story, Honestly Told

Before evaluating Zero Trust for OT, it is worth being precise about what Zero Trust actually is and is not. The term has been used so loosely in vendor marketing that its technical meaning has, in some quarters, become difficult to recover. The remainder of this whitepaper depends on a precise understanding, so this section establishes one.

1.1 The Origin and the Authoritative Definition

Zero Trust as a coherent concept emerged from work at Forrester Research in the early 2010s, with the principal architect John Kindervag arguing that the implicit-trust model that underpinned conventional perimeter security was no longer defensible in the face of insider threats, cloud adoption, and adversaries who routinely operated inside corporate networks. The intuition was simple: stop assuming that anything inside the perimeter is trustworthy, and verify everything explicitly regardless of network location.

Over the following decade, the concept matured from a critique into an architectural framework. The most important codification is NIST Special Publication 800-207, Zero Trust Architecture, published in 2020. SP 800-207 defines Zero Trust not as a single technology or product but as a set of principles that can be implemented in multiple ways. The CISA Zero Trust Maturity Model, released in 2021 and updated since, provides a maturity framework against which organisations can assess and plan their progression. Several adjacent frameworks — the DoD Zero Trust Reference Architecture, vendor-specific architectures from major cloud and security providers — build on these foundations with varying degrees of fidelity.

1.2 The Principles, Briefly

The principles that recur across the authoritative frameworks can be summarised as eight tenets. They are not a perfectly orthogonal set; they overlap and reinforce each other. The point of listing them is to provide a basis for the principle-by-principle translation in Section 3.

•       Verify explicitly: authenticate and authorise every request based on all available information, not on network location alone.

•       Use least privileged access: grant the minimum access required for the task, just-in-time and just-enough.

•       Assume breach: design controls and architecture as if an adversary is already inside the environment.

•       Microsegmentation: enforce fine-grained network and workload isolation rather than relying on perimeter segmentation alone.

•       Continuous verification: re-evaluate trust continuously rather than at session start only.

•       Identity as the perimeter: treat identity as the primary access control, not network location or device location.

•       Encrypt all traffic: do not assume that traffic on the internal network is safe because it is internal.

•       Default deny: allow only what is explicitly permitted; deny everything else.

1.3 What Zero Trust Is Not

Several common misunderstandings should be dispelled before the OT translation can be evaluated honestly.

Zero Trust is not a product. No single product or platform implements Zero Trust; the principles must be implemented through a combination of identity, network, endpoint, and monitoring capabilities, typically integrated across multiple products. Vendor offerings that present themselves as “the” Zero Trust solution are misrepresenting the concept; they are, at best, an important component of a Zero Trust implementation.

Zero Trust is not the same as zero-trust networks or zero-trust network access (ZTNA). ZTNA is a specific category of remote access technology that implements some Zero Trust principles for remote user access. It is a useful component but it is not the whole programme. Operators that procure ZTNA and consider themselves to have implemented Zero Trust have implemented one part of one principle for one use case.

Zero Trust is not anti-perimeter. The principles do not require dismantling network perimeters; they require not relying on the perimeter as the primary or sole control. A Zero Trust architecture can include strong network segmentation; it just cannot depend on segmentation alone.

Zero Trust is not a binary state. The CISA Maturity Model recognises that organisations move through stages — traditional, initial, advanced, optimal — across multiple pillars (identity, devices, networks, applications, data). The honest characterisation of any organisation’s posture is in terms of where it sits across these stages, not whether it has “achieved Zero Trust”.

1.4 Why the Concept Is Useful for OT

The structural argument for considering Zero Trust principles in OT environments rests on three observations. First, the implicit-trust model that underpinned traditional OT security — air-gapped networks, perimeter-based defence, trust by network location — is broken for the same reasons it is broken in IT, only more consequentially. Second, the disclosed incident record (examined in detail in the companion whitepaper) shows repeatedly that the OT-impacting attacks of the past decade exploited exactly the assumptions Zero Trust principles directly contradict: credential reuse across trust tiers, implicit trust based on network location, missing east-west visibility, and absent assume-breach posture. Third, several of the Zero Trust principles — least privilege, default deny, assume breach — are not new ideas in OT cybersecurity; they have been advocated for years under different labels, and the Zero Trust framing offers a coherent vocabulary and authoritative reference for principles operators have already been moving toward.

The point is not that Zero Trust is a novel revelation for OT. The point is that the principles are sound, the framing is useful, and the translation from IT formulations is non-trivial in ways that warrant careful attention. The remainder of this whitepaper provides that translation.

2. The Translation Matrix

Figure 1 presents the principle-by-principle translation summary. Each row identifies a Zero Trust principle, its typical IT implementation, the practical OT translation, and a colour-coded indicator of whether the principle fits cleanly, requires adaptation, or breaks in the OT context.

2.1 Reading the Matrix

Three distinctions matter for interpreting the matrix. The first is between principles that translate cleanly and principles that require adaptation. The cleanly-translating principles can be applied in OT with essentially the same intent and substantially similar implementation as in IT, although the technology choices may differ. The adaptation-requiring principles need to be reformulated for the OT context; the underlying intent applies but the IT implementation does not.

The second distinction is among the layers at which a principle applies. Several principles — identity-as-perimeter is the clearest example — translate well at the human and administrator layer but require fundamentally different thinking at the machine-to-machine layer at the lower Purdue levels. The matrix indicates this layered applicability where it matters.

The third distinction is between brownfield and greenfield implementations. Greenfield OT environments — new facilities, major modifications, recently commissioned units — can implement Zero Trust principles substantially more directly than brownfield environments built around equipment vintage and protocols that predate the principles. The roadmap in Section 6 addresses this distinction explicitly.

2.2 The Bottom-Line Pattern

The pattern visible in Figure 1 is that the majority of Zero Trust principles translate to OT either cleanly or with sober adaptation. One principle in its purest form does not translate, and this should be acknowledged plainly rather than rationalised away. Several principles require careful thinking about the layer at which they apply. The honest characterisation of “Zero Trust for OT” is therefore: a programme of substantial relevance and substantial adaptation, not a wholesale port of IT practice and not an inapplicable IT concept.

Sections 3 through 5 walk through the principles in groups: those that fit cleanly (Section 3), those that require adaptation (Section 4), and the principle that breaks at the lower levels and the architectural response to that break (Section 5).

3. Principles That Fit Cleanly

Three Zero Trust principles translate to OT environments with essentially their original intent and substantially similar implementation, although the specific technology choices differ from IT. They are presented here in the order in which they typically deliver the most defensive value in OT environments.

3.1 Assume Breach

“Assume breach” is the principle that asks defenders to design controls and architecture as if an adversary is already inside the environment. In IT, this principle drives investment in continuous monitoring, behavioural detection, and minimisation of blast radius from any single compromise. In OT, the principle translates directly and is arguably even more important than in IT, for two reasons.

First, the consequences of compromise in OT include not just data loss and operational disruption but potential physical harm and safety incidents. The cost of treating a breach as unthinkable is asymmetrically higher in OT than in IT. Second, the constraints on patching in OT environments mean that vulnerable assets remain in production for longer periods than is acceptable in IT, increasing the operational case that some adversary will eventually exploit some vulnerability somewhere in the environment. The assume-breach posture is the realistic response to this constraint.

The OT implementation of assume-breach centres on three architectural choices. First, blast-radius minimisation: rigorous zone-and-conduit segmentation, tiered administration, separated identity services, and dedicated SIS environments collectively limit the consequences of any single compromise. Second, behavioural monitoring: continuous baselining of normal device-to-device communications, with alerts on anomalies that signal the kind of activity an adversary in the environment would generate. Third, recovery capability: backup and recovery designed for the assumption that a substantial fraction of OT-adjacent systems may need to be reconstructed, not just the assumption that occasional file restoration will suffice.

Operators that have internalised assume-breach as a design posture make different architectural decisions than operators that have not. The differences are visible in the disclosed incident record: the operators that survived recent ransomware events with limited operational consequence are, almost without exception, operators who designed for the assumption that the adversary would eventually be in the environment.

3.2 Least Privileged Access

“Least privilege” is the principle that access should be granted at the minimum level required for the task, just-in-time and just-enough. In IT, this drives implementations including role-based access control, ephemeral credentials, just-in-time privileged access, and scoped tokens. In OT, the principle translates directly, and the implementation aligns closely with the tiered administration model that IEC 62443 already advocates.

The principal OT-specific applications of least privilege are at three layers. First, separated identity services: the OT directory should be logically separate from corporate Active Directory so that compromise of corporate identity does not yield administrative access to control systems. Second, tiered administration: privileged accounts should be tiered such that compromise of one tier does not yield access to another, with separate workstations, separate credentials, and separate trust boundaries for each tier. Third, role-based access at the operator and engineer layer: shared accounts on HMIs and engineering workstations are operationally common but architecturally indefensible; the migration to per-individual accounts integrated with the OT directory is the long-term direction.

The case for least privilege in OT is made conclusively by the disclosed incident record. The Norsk Hydro LockerGoga incident, examined in the companion whitepaper, was enabled directly by the absence of identity tiering: domain administrator credentials valid across all sites and all systems were the architectural failure that allowed the attack to propagate to 22,000 endpoints. The principle is not theoretical; the absence of it has been observably catastrophic.

3.3 Default Deny

“Default deny” is the principle that traffic, access, and execution should be permitted only by explicit allow, with everything else denied. In IT, this drives allowlisting at firewalls, application allowlisting on endpoints, and service-to-service policy enforcement. In OT, the principle translates directly and aligns with mature firewall and endpoint protection practices.

The principal OT-specific applications are at the network and endpoint layers. At the network layer, modern OT-aware next-generation firewalls support default-deny policies with allowlists at the protocol and function-code level. A default-deny policy at the L3.5 DMZ that allows only specifically named services, with named source and destination zones, is the architectural baseline; anything more permissive concedes the ground that Zero Trust principles seek to defend. At the endpoint layer, application allowlisting on engineering workstations, HMIs, and historians — only explicitly permitted executables can run, everything else is denied — is the OT implementation of default-deny that the disclosed incident record (particularly the EKANS / Snake ransomware family) has made unambiguously necessary.

The principal cultural challenge in implementing default-deny in OT environments is that operations and engineering staff have, historically, sometimes treated permissive defaults as a feature rather than a bug. The migration to default-deny requires investment in the exception process: legitimate engineering work must be able to add specific allowlist entries through a documented process that is fast enough not to impede operations. Programmes that implement default-deny without the exception process create operational friction that erodes the policy over time; programmes that get the exception process right sustain the discipline.

The principles that fit OT cleanly — assume breach, least privilege, default deny — are not novel insights from Zero Trust. They are principles the OT cybersecurity community has advocated for years. What Zero Trust offers is a coherent framework, an authoritative reference, and a vocabulary that crosses the IT/OT boundary.

4. Principles That Require Adaptation

Four Zero Trust principles translate to OT with substantial value but require careful adaptation from their IT formulations. The intent of each principle remains valid; the implementation that works in IT either does not transfer directly or requires modification for OT realities.

4.1 Verify Explicitly — At the Right Layer

“Verify explicitly” in IT formulations typically describes per-request authentication, continuous re-evaluation of authentication state, and the use of all available signals (user identity, device posture, location, behaviour) to make access decisions. The IT implementation centres on identity providers, conditional access policies, and adaptive authentication.

In OT, the principle applies at the human and administrator boundary but cannot be applied directly at the machine layer at the lower Purdue levels. A control loop running between a sensor, a PLC, and an actuator cannot pause for re-authentication mid-loop; the deterministic timing requirements that the safety case depends on do not permit it. The adaptation is to apply verify-explicitly rigorously at the boundaries where it is feasible — human access to engineering workstations, administrator access to controllers, vendor remote access — and to constrain the consequence of trust at the machine layer through other architectural controls.

This is not a weakening of the principle; it is a translation of it. The intent of verify-explicitly — not to grant trust based on network location alone — is fully respected when the verification happens at the human boundary and the machine layer is constrained by zoning, allowlisting, and behavioural monitoring. The implementation is just different.

4.2 Microsegmentation — As Zone-and-Conduit

Microsegmentation in IT formulations describes fine-grained network and workload isolation, often implemented through software-defined microperimeters, per-workload policy enforcement, and east-west traffic inspection. The IT vision is of a network with no implicit trust between workloads, with every flow inspected and policy-controlled.

The direct translation to OT — per-workload policy at the L1 PLC layer — is operationally infeasible in most current environments. The architectural alternative is the IEC 62443 zone-and-conduit model, which applies essentially the same principle (no implicit trust between groups of assets, all flows controlled and policy-governed) at a coarser granularity that aligns with the operational realities of OT environments. Each major process unit is a zone; cross-zone communications are explicit conduits with documented policy; SIS environments are zones of their own with the most restrictive controls in the facility.

This is not a compromise of the microsegmentation principle; it is the appropriate granularity for the OT context. Operators that have implemented IEC 62443 zone-and-conduit architectures have, in effect, implemented OT microsegmentation. The vendor positioning that presents these as separate concepts — with new “Zero Trust microsegmentation” products required to overlay an existing 62443 implementation — is generally not consistent with a careful reading of the underlying principles.

4.3 Identity as the Perimeter — At the Human Layer

“Identity as the perimeter” is the principle that access decisions should be driven by identity (of the user, the device, the workload) rather than by network location. In IT, this principle drives implementations centred on centralised identity providers, single sign-on, conditional access policies, and the gradual de-emphasis of network-based access controls.

In OT, the principle translates strongly at the human and administrator layer. Operator and engineer access to control systems, vendor remote access, and administrative access to OT infrastructure all benefit from identity-driven access controls implemented through an OT-specific directory service. This implementation closes failure modes documented repeatedly in the incident record (shared accounts, perimeter-based trust on privileged access, missing MFA on remote paths) and aligns with the architecture paper’s recommendations on identity tiering.

At the machine-to-machine layer at the lower Purdue levels, the translation is more difficult. PLCs, sensors, and actuators do not have machine identities in the sense an IT workload does. Modern OPC UA implementations support certificate-based device authentication, which is the most direct OT analogue, but the brownfield reality is that most operating environments include substantial L0–L1 estate that does not support modern identity. The honest position is that identity-as-perimeter applies cleanly at the human/admin layer in OT, applies with adaptation at the modern machine layer where supported, and does not currently apply at the brownfield L0–L1 layer where most operating assets sit.

4.4 Encrypt All Traffic — Where Viable

“Encrypt all traffic” in IT formulations is increasingly straightforward: TLS for HTTP traffic, mutual TLS for service-to-service communications, end-to-end encryption for sensitive data flows, and the broader assumption that traffic on the internal network is no safer than traffic on the external network.

In OT, the translation is genuinely constrained. Many native OT protocols — Modbus TCP, the older OPC variants, EtherNet/IP, PROFINET in their original forms, CIP — are unencrypted by design and were specified before encryption was a baseline expectation. Modern variants address this: OPC UA includes built-in security with certificate-based authentication and message encryption; PROFINET Security is in development; secure variants of other protocols are emerging. But the brownfield reality is that the L0–L1 estate at most operating facilities communicates over unencrypted protocols and will continue to do so for the foreseeable future.

The adaptation is to apply encryption where it is viable and to compensate where it is not. Encryption at the L3 to L4 boundary, on remote access conduits, on supervisory traffic between sites, and on cloud-bound telemetry is now baseline practice. Encryption at the L0–L1 layer is, for brownfield equipment, generally not achievable without equipment refresh; the architectural compensation is rigorous physical and logical isolation of those segments such that the absence of encryption does not equate to exposure to network-resident adversaries.

Operators evaluating Zero Trust offerings that promise to encrypt all OT traffic should ask carefully what is meant. Encryption of L3-and-above traffic is achievable and valuable; promises of encryption at the L0–L1 layer for brownfield protocols typically describe overlay tunnels (which add latency and complexity) or future-state architectures dependent on equipment refresh that may never happen.

The adaptations required for Zero Trust in OT are not failures of the framework. They are the recognition that OT environments have structural constraints — deterministic timing, brownfield protocols, equipment vintage — that any honest architectural translation must respect.

5. The Principle That Breaks: Continuous Verification at L0–L2

Of the eight Zero Trust principles examined in this whitepaper, one breaks at the lower Purdue levels in a way that no architectural adaptation can fully resolve. The honest acknowledgement of this break, rather than its rationalisation away, is part of what distinguishes a credible Zero Trust for OT programme from a marketing artefact.

5.1 What Continuous Verification Means

In IT formulations, continuous verification is the principle that trust should be re-evaluated continuously rather than at session start only. Implementations include adaptive authentication that triggers additional verification based on changes in user behaviour, device posture, location, or risk signal; session re-evaluation policies that terminate or downgrade sessions when conditions change; token refresh patterns that limit the validity of any single authentication assertion; and the broader posture that trust is provisional and subject to continuous review.

5.2 Why It Breaks at L0–L2

Control loops at the lower Purdue levels operate on deterministic timing budgets that were established as part of the engineered control design and validated as part of the safety case. A typical fast control loop — a refrigeration compressor surge protection loop, a turbine speed control loop, a safety instrumented function — operates on cycle times measured in tens of milliseconds. The loop must read sensor inputs, compute control output, and command actuators within budget on every cycle, every cycle, indefinitely.

Continuous verification in any meaningful sense — re-authenticating the sensor to the controller, re-evaluating the trust posture of the actuator, refreshing tokens between control elements — is not consistent with these timing constraints. The latency budgets do not include time for cryptographic re-evaluation. The control architectures are not designed for trust state that can change mid-loop. The safety cases are not built on the assumption that the control loop can be interrupted by trust re-evaluation. The break is not a matter of implementation difficulty; it is a matter of the principle being incompatible with the engineering reality of the control layer.

This should be acknowledged plainly. Vendor offerings that describe continuous verification as a feature applicable to industrial control systems generally do not mean what the IT formulation of the principle means. They mean continuous verification at some other layer — the human access path, the engineering workstation, the L3.5 DMZ — where the principle applies. The defender evaluating such offerings should ask carefully which layer is being addressed.

5.3 The Architectural Response

The architectural response to the break is not to abandon the underlying intent of continuous verification. The intent — not to grant unbounded trust based on a single authentication event — remains valid and important. The response is to implement continuous verification rigorously at the layers where it is feasible, and to constrain the consequence of trust at the layer where it is not.

At the human and administrator layer, continuous verification can and should be applied. Vendor remote access sessions should be subject to continuous re-evaluation, with session termination on changes in risk signal. Administrator access to engineering workstations should require additional verification on sensitive operations (e.g., entering programming mode on a controller). Operator access to HMIs should be re-verified on session timeout, on shift change, and on access to high-consequence functions.

At the L3 and L3.5 layer, continuous monitoring of conduit traffic with anomaly detection serves a function adjacent to continuous verification: rather than re-evaluating trust per packet, the monitoring evaluates whether the trust granted is being abused. Behavioural baselines on device-to-device communications, alerts on protocol misuse, and detection of unauthorised programming sessions all serve this function.

At the L0–L2 layer, the response is to constrain the consequence of trust through architectural controls: rigorous zone isolation, application allowlisting on engineering workstations and HMIs, physical key-switch enforcement on SIS programming mode, and behavioural monitoring at the segment level. These controls do not implement continuous verification in any direct sense, but they limit what an adversary who has obtained trust at this layer can do with it. The architectural intent is preserved even where the specific implementation is not transferable.

5.4 Why This Matters for Honest Discourse

The reason this break deserves explicit acknowledgement is that the alternative — pretending the principle applies cleanly at all layers — produces marketing claims that defenders cannot evaluate properly and architectures that do not deliver what they promise. Operators sold a “Zero Trust for OT” platform on the strength of continuous verification capabilities are owed the disclosure that the capability does not extend to the L0–L2 layer. Operators who internalise the honest position can make better decisions about where to invest their cybersecurity budget and what to expect from each component of the architecture.

This is, more broadly, the case for honest engagement with Zero Trust in OT. The principles are powerful when applied where they apply. Pretending they apply everywhere they do not is a form of vendor capture that erodes the discipline’s credibility and produces architectures that disappoint.

The honest architectural response to the principle that does not translate is to apply it where it does, constrain consequence where it does not, and disclose the boundary clearly. The marketing alternative — pretending the boundary does not exist — is what produces disappointed operators and discredited frameworks.

6. Implementation Roadmap

Zero Trust for OT is, like the broader OT cybersecurity programme it is part of, a multi-year journey rather than a single procurement event. The roadmap below presents a three-phase sequence calibrated to the operational realities of heavy engineering environments. The phases are cumulative, not exclusive.

6.1 Phase 1: Foundation (Months 0–12)

The foundation phase implements the Zero Trust principles that fit cleanly and that deliver visible defensive value within the first budget cycle. It is intentionally bounded; the temptation to attempt the full Zero Trust translation in the first year produces predictable disappointment.

6.2 Phase 2: Adaptation (Months 12–24)

The adaptation phase extends the principles requiring adaptation into the OT environment, deploys the enabling technology, and matures the operations capability that sustains the programme.

6.3 Phase 3: Maturity (Months 24–36+)

The maturity phase moves the programme from defensive baseline to continuous improvement, integrating Zero Trust principles into capital planning and demonstrating maturity progression through objective measurement.

Operators frequently underestimate the foundation phase and overestimate the speed at which subsequent phases can be reached. A realistic Zero Trust programme accepts that identity tiering alone may take the full first year, and that the visible benefits of Phase 3 depend heavily on the discipline established in Phase 1.

7. Where Zero Trust Goes Wrong in OT

Several patterns recur across Zero Trust for OT programmes that produce credible-looking documentation and limited defensive impact. They are presented bluntly because the lessons are easier to apply when stated plainly.

7.1 Treating Zero Trust as a Product

The single most common failure mode is the procurement of a vendor offering described as “Zero Trust for OT” and the assumption that the procurement substantially implements the principles. No single product does. The principles span identity, network, endpoint, monitoring, and governance; any single vendor offering addresses some of these and not others, and the gaps must be addressed through other procurements or internal capability. Operators that procure a Zero Trust product without an architecture that integrates it into the broader programme have purchased a component, not a programme.

7.2 Skipping the Translation

Programmes that import IT Zero Trust playbooks directly into OT environments without the translation work described in Sections 3 through 5 produce architectures that fail predictably. Continuous verification implemented at the L1 layer disrupts control loops; encryption mandates applied to L0–L1 brownfield protocols cannot be met without equipment refresh; per-workload microsegmentation at L1 is not achievable. The translation is the work; programmes that skip it discover the constraints in execution rather than design.

7.3 Ignoring the Greenfield-Brownfield Distinction

Brownfield environments cannot implement Zero Trust to the same depth or on the same timeline as greenfield environments. A programme that applies a single roadmap across all environments either undershoots in greenfield or overshoots in brownfield. The mature pattern is to set Zero Trust as the default architecture for new builds and capital projects, while accepting a longer migration timeline for the brownfield estate that aligns with equipment refresh cycles.

7.4 Treating Zero Trust as Independent of OT Cybersecurity

Zero Trust is a set of principles within OT cybersecurity, not a parallel programme. Programmes that treat the two as separate workstreams — with separate teams, separate budgets, and separate reporting — produce duplication, conflict, and confused stakeholders. The mature pattern is to integrate Zero Trust principles into the existing OT cybersecurity programme, governed by the same accountable executive and reported through the same channels.

7.5 Mistaking Maturity Models for Maturity

Self-assessment against the CISA Zero Trust Maturity Model produces a report. The report is useful as a planning input; it is not a substitute for the maturity itself. Operators that report high maturity scores against the CISA model on the basis of self-assessment, without the operational evidence to support the scores (working tooling, documented procedures, exercised playbooks, measured outcomes), have produced a report. Year-on-year movement in objective measures — detection rates, incident frequency, recovery time, audit findings — is the more useful programme metric.

7.6 Underinvesting in the Operations Capability

Zero Trust principles produce a substantially larger volume of trust-related decisions than the perimeter model they replace. Continuous verification, behavioural detection, and assume-breach posture all generate alerts, exceptions, and decisions that someone must handle. Programmes that deploy the technology without the operations capability to handle the resulting workload generate alert fatigue, ignored signals, and a degradation of the programme back to perimeter-style defence. The operations investment is part of the architecture, not separate from it.

The failure mode of Zero Trust in OT is rarely that the principles are wrong. It is that the principles were applied without the translation, the integration, or the operations capability they require.

8. Conclusion and Recommendations

Zero Trust as a coherent set of principles is mostly correct for OT environments, with several principles fitting cleanly, several requiring careful adaptation, and one breaking at the lower Purdue levels in a way that no architectural translation can fully resolve. The defender who recognises which principle falls into which category is meaningfully ahead of the defender who treats Zero Trust as either a turnkey solution or a passing fad.

8.1 Where the Industry Stands

Heavy engineering operators in 2026 are at varying stages of Zero Trust adoption. Leading operators have implemented identity tiering, separated OT directories, default-deny at perimeters, and assume-breach postures as part of broader OT cybersecurity programmes that align naturally with Zero Trust principles. Mid-tier operators have begun the work but face the gap between aspirational architecture and operating reality. Lagging operators have either bought “Zero Trust for OT” products and considered the matter closed, or have dismissed Zero Trust as inapplicable to OT and continued with perimeter-based architectures that the disclosed incident record has shown to be inadequate.

The defensive value of the Zero Trust framing for OT is real. It provides a coherent vocabulary, an authoritative reference framework, and a maturity model against which programmes can be assessed and planned. It also provides cover for advocating, inside the organisation, for principles that OT cybersecurity practitioners have advocated for years under different labels. Operators that engage with the framework honestly extract this value; operators that engage with it superficially do not.

8.2 Final Recommendations

•       Engage with Zero Trust as a set of principles, not a product. The procurement of any single vendor offering implements some part of some principles for some part of the environment. The architecture must integrate these into a coherent programme.

•       Apply the principle-by-principle translation honestly. Acknowledge which principles fit cleanly, which require adaptation, and which break at the lower Purdue levels. The honest disclosure of the boundary is part of what distinguishes a credible programme from a marketing artefact.

•       Sequence the implementation against operational realities. Identity tiering, default-deny perimeters, and assume-breach posture in Phase 1; microsegmentation as zone-and-conduit, encryption where viable, application allowlisting in Phase 2; greenfield Zero Trust by design and brownfield refresh integration in Phase 3.

•       Integrate Zero Trust into the OT cybersecurity programme, not parallel to it. The same accountable executive, the same governance, the same reporting. Parallel programmes produce duplication and conflict.

•       Invest in the operations capability commensurate with the architecture. Continuous verification, behavioural detection, and assume-breach posture generate decisions that someone must handle. The operations investment is part of the architecture.

•       Be precise with stakeholders about what Zero Trust delivers and what it does not. The principles are powerful where they apply; pretending they apply everywhere they do not is a form of vendor capture that ultimately damages the programme’s credibility.

•       Distinguish maturity model assessment from maturity. Self-assessment is a planning input; demonstrated operational outcomes are the maturity itself.

Selected References for Further Reading

•       NIST Special Publication 800-207 — Zero Trust Architecture

•       CISA Zero Trust Maturity Model (current version)

•       US Department of Defense — Zero Trust Reference Architecture

•       IEC 62443 Series — Industrial Communication Networks: IT Security for Networks and Systems

•       CISA / NSA — ICS Cybersecurity Performance Goals and supporting publications

•       Companion whitepapers in this series: IT/OT Cybersecurity in Heavy Engineering and Anatomy of an OT Incident