TL;DR: The DoW's Zero Trust for Operational Technology framework extends zero trust into environments where predictable communications, high availability, and machine-to-machine traffic force identity, segmentation, and continuous verification to carry the design load, according to Corsha analysis. For machine identity programmes, OT zero trust turns access scope, behavioural verification, and safe containment into core governance decisions, not IT overlays.
At a glance
What this is: This analysis explains how the DoW's Zero Trust for Operational Technology framework adapts zero trust to OT environments by elevating machine identity, continuous verification, and segmentation.
Why it matters: It matters because OT identity programmes cannot rely on enterprise IT assumptions, and IAM, PAM, and NHI teams need controls that preserve safety and availability while restricting machine-to-machine access.
By the numbers:
- The framework defines 105 total activities, including 84 Target activities and 21 Advanced activities.
Context
Zero Trust for Operational Technology is the application of zero trust principles to environments that run physical processes, not just digital services. In OT, access decisions have to respect predictable communications, safety, and availability, which means the identity model has to work differently than in enterprise IT.
Corsha's source article treats the DoW framework as the signal that machine identity is no longer a side issue in OT. The practical problem is not whether zero trust applies, but which controls can be enforced without disrupting operations or creating unsafe lateral movement.
That makes the article a machine identity and operational governance story rather than a general cybersecurity announcement. The central question is how to verify, scope, and contain machine-to-machine access when the environment cannot tolerate IT-style churn.
Key questions
Q: What breaks when Zero Trust is implemented without identity governance?
A: Zero Trust breaks when the policy engine is enforcing stale or incomplete identity data. If access approvals, ownership, and revocation are not governed, the organisation keeps validating entitlements that no longer match business intent. The result is technically strong enforcement built on weak identity records, which still leaves over-privileged accounts and hidden exceptions in place.
Q: Why do OT environments need different zero trust controls than enterprise IT?
A: OT systems protect physical processes, so availability and predictable communication matter as much as access restriction. Controls that are acceptable in office environments can disrupt plant operations, so identity, segmentation, and response have to be tuned to process criticality, device behaviour, and safety constraints rather than user convenience.
Q: How do teams know if OT segmentation is still working?
A: OT segmentation is working only if access decisions remain accurate when systems move, scale, or connect to new platforms. If the programme depends on frequent manual rule edits, exceptions, or subnet assumptions to keep traffic flowing, the control is already drifting away from the operational reality it is meant to protect.
Q: Who should own OT identity decisions when safety and security goals conflict?
A: Ownership has to be shared between security, operations, and system owners because the consequences are physical, not just digital. Security can define policy, but operations must validate what can be enforced safely, what needs approval, and what must be preserved during incident containment.
Technical breakdown
Why OT zero trust starts with machine identity
Operational technology differs from standard enterprise environments because devices, controllers, and workloads often communicate in fixed patterns that support physical processes. Zero trust in OT therefore cannot rely on user-centric assumptions alone. It has to establish identity for machines, services, and users, then bind access decisions to the operational context that governs safety and uptime. In practice, that means machine identity becomes the anchor for authentication, authorization, and segmentation across control and data flows. When machine-to-machine traffic is the norm, unnamed or unmanaged endpoints create blind spots that enterprise IT controls were never designed to cover.
Practical implication: treat machine identity as a first-class OT control surface, not a bolt-on to user access management.
How adaptive policy differs from static OT access control
The DoW framework distinguishes foundational target activities from more mature advanced activities, and that distinction matters technically. Target controls establish inventories, least privilege, monitoring, and segmentation. Advanced controls extend that model with continuous verification, adaptive policy enforcement, and real-time response based on observed behaviour. In OT, this is not just a maturity ladder. It is a mechanism for avoiding unsafe enforcement by moving from static allowlists to context-aware policy decisions that can react to device behaviour, command pathways, and mission state. The technical challenge is preserving deterministic operations while still rejecting abnormal connections and unsafe write activity.
Practical implication: map static OT allow rules to target controls first, then design adaptive policy only where safety and reliability can absorb it.
Why segmentation and continuous monitoring are inseparable in OT
Segmentation in OT is only effective when it is paired with telemetry that shows whether the expected traffic pattern is still holding. The framework's emphasis on plane, zone, and microsegmentation reflects a reality that lateral movement in OT often happens through legitimate pathways that have been over-broadened. Continuous monitoring, SIEM and SOAR correlation, and anomaly detection give the enforcement layer evidence about whether a connection is normal, unsafe, or unauthorized. Without that feedback loop, segmentation becomes a paper policy rather than an operational control. The point is to constrain motion across the environment before abnormal access reaches safety-critical assets.
Practical implication: pair every OT segmentation decision with monitoring that can validate whether traffic still matches the approved operating pattern.
Threat narrative
Attacker objective: The objective is to gain unauthorized operational reach into mission-critical systems without triggering controls that would interrupt the physical process.
- Entry begins when an unmanaged device or maintenance machine attempts to communicate with an OT asset through a path that lacks machine identity validation.
- Credential or identity abuse follows when the environment accepts machine-to-machine traffic without continuously verifying whether the requester is authorised for that control zone.
- Escalation occurs when the connection reaches a restricted control path or write-capable interface and the activity diverges from the normal operational pattern.
- Impact is the ability to move laterally or issue unsafe commands in a way that threatens process integrity, safety, or availability.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
OT zero trust is really machine identity governance under safety constraints. The DoW framework shows that OT cannot inherit enterprise IT assumptions about stable user sessions, casual re-authentication, or broad policy churn. In OT, identity has to be attached to machines, controllers, and workflows that keep physical processes alive. Practitioners should read this as a governance shift: the control problem is not just access, it is preserving operational determinism while constraining machine-to-machine trust.
Segmenting OT without continuous verification only pushes risk sideways. The framework's combination of zone design, telemetry, and behavioural policy reflects a simple truth: over-broad access in OT often looks legitimate until it reaches the wrong control path. A named concept here is identity blast radius, meaning the maximum process exposure that a single machine credential or connection can create. Practitioners should reduce that blast radius before they try to automate response.
Least privilege in OT is no longer a provisioning exercise. It has to account for the command path, the device state, and the process context at the moment of connection. That is why the framework pairs access control with environmental awareness and monitoring. The implication for practitioners is that machine identity governance in OT must be designed around the allowed operating envelope, not just account creation and revocation.
The practical frontier is not zero trust in general, but zero trust that survives plant-floor reality. OT environments cannot absorb the same policy volatility that office networks can, so the governance model has to be stricter at issuance time and more discriminating at enforcement time. That pushes identity teams to coordinate with operations, engineering, and safety owners rather than treating OT as a variant of standard IAM. The field is moving toward safety-aware identity governance, and OT programmes need to follow that lead.
This framework validates that NHI controls are now core to operational resilience. When machine identity, monitoring, and segmentation are the difference between safe containment and unsafe lateral movement, NHI governance stops being a niche control set. It becomes part of mission assurance. Practitioners should align OT identity work with formal lifecycle ownership, telemetry, and zone-based access decisions.
From our research library:
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
- By 2029, 40% of enterprises that successfully implement zero trust within cloud service provider environments will rely on the advanced visibility and control capabilities offered by CNAPP solutions.
- Read next: Zero Trust Identity Guide
What this signals
Identity blast radius: OT zero trust should be judged by how much process exposure a single machine credential can create. If a maintenance identity can still reach safety-critical assets, the programme has not reduced blast radius enough to matter.
Zero trust for OT changes the governance question from "who may log in" to "which machines may talk to which process at which time." That shift will pressure IAM, PAM, and NHI teams to coordinate around operational state, not only account state.
NIST SP 800-207 remains useful as a conceptual baseline, but OT programmes need to interpret it through safety, segmentation, and deterministic communications rather than office-network assumptions.
For practitioners
- Inventory OT machine identities and unmanaged endpoints Build a complete inventory of controllers, HMIs, service identities, and other non-person entities that initiate or receive OT traffic. Mark which identities can write, which can only read, and which have cross-zone reach.
- Bind access to operational context Apply attribute-based rules that consider zone, device state, maintenance window, and command type before permitting machine-to-machine communication. Do not let a single credential imply broad plant-floor reach.
- Segment by control path and process criticality Separate control, data, and management flows so that a compromised maintenance path cannot reach safety-critical assets. Validate each zone boundary with explicit policy and logging.
- Monitor anomalous write behaviour continuously Alert on unusual write commands, high-frequency polling, and new communication patterns from normally quiet devices. Tie detections to containment actions that preserve safety and availability.
- Align OT identity policy with safety owners Define who can approve emergency access, who owns revocation, and how changes are queued when automation would threaten reliability. OT zero trust needs operational sign-off, not just security approval.
Key takeaways
- OT zero trust elevates machine identity from a supporting control to the mechanism that makes access decisions safe in operational environments.
- The DoW framework formalises 105 activities across target and advanced phases, showing that OT zero trust requires both foundational control and adaptive enforcement.
- Practitioners should reduce identity blast radius, segment by process criticality, and validate policies against real OT telemetry before automating containment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | OT machine identities with broad zone reach create the overprivilege risk this article addresses. |
| NHI-08 — Environment Isolation | The framework centers on separating OT planes, zones, and management paths to preserve safety. | |
| Recommendation — Scope OT machine identities to the minimum control paths needed and remove cross-zone standing reach. Isolate OT control, data, and management environments so one compromised path cannot traverse the plant. | ||
| MITRE ATT&CK | TA0008 — Lateral Movement | The article repeatedly focuses on blocking unsafe movement across OT zones and control paths. |
| Recommendation — Map OT cross-zone exposure to lateral movement paths and monitor for abnormal traversal attempts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about authorising machine-to-machine access under OT constraints. |
| Recommendation — Apply PR.AA-05 to verify OT entitlements against device role, zone, and process criticality. | ||
| NIST Zero Trust (SP 800-207) | section 4.1 — Zero trust principles | The source article is a zero trust adaptation for OT and relies on continuous verification principles. |
| Recommendation — Translate zero trust principles into OT policies that verify every machine connection before trust is granted. | ||
Key terms
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Microsegmentation: A network control approach that divides environments into small security zones with explicit rules between them. Its purpose is to limit lateral movement and reduce blast radius when an identity, workload, or device is compromised.
- Adaptive Access: A risk-based access model that changes authentication requirements based on context such as device trust, location, behaviour, and session risk. It is most useful where users move between environments quickly, because the policy can stay strict without making every login equally heavy.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org