What should organisations do first when building OT zero trust controls?

Why This Matters for Security Teams

OT zero trust starts with trust boundaries because industrial environments mix legacy controllers, vendor remote access, engineering workstations, and safety-sensitive processes that do not behave like normal IT. If those boundaries are vague, segmentation and least privilege become aspirational instead of enforceable. NIST SP 800-207 Zero Trust Architecture frames the core issue well: access must be continuously evaluated, not assumed from network location.

This matters even more for NHIs and machine-to-machine paths, where service accounts, API keys, and remote sessions can outlive the change window they were created for. NHI Management Group notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation in the Ultimate Guide to NHIs — Standards, which is a strong signal that identity scope is part of the OT problem, not a separate admin detail. In practice, many security teams encounter overly broad OT trust assumptions only after a vendor session, jump host, or shared account has already crossed into a higher-value zone.

How It Works in Practice

The first practical step is to inventory and classify the communication paths that actually exist, then define which of them are legitimate. For OT, that means identifying devices, human operators, engineering tools, remote vendors, historians, jump servers, and any workload or service account that interacts with control systems. The boundary should be expressed in terms of asset relationships and allowed flows, not just IP ranges.

From there, organisations should map each trust boundary to an explicit policy decision: who or what can initiate a session, what protocol is allowed, under what conditions, and for how long. NIST SP 800-207 supports this model by treating policy enforcement as a runtime decision rather than a one-time network trust choice. In OT, this often means starting with a small set of high-risk pathways and making them observable before expanding coverage.

Useful first actions include:

• Define zones around control systems, engineering workstations, safety systems, and vendor access points.
• Document approved paths for remote maintenance, patching, monitoring, and backup traffic.
• Separate human access from machine access so service accounts are not treated like operator accounts.
• Apply least privilege to each path, then test whether the workflow still functions under segmentation.
• Use strong workload identity and short-lived credentials where OT tooling supports it, especially for remote support and automation.

This approach is easier to sustain when paired with identity discipline. NHIMG’s Guide to SPIFFE and SPIRE is useful here because it shows how workload identity can replace vague trust with cryptographic proof of what a workload is. That becomes especially important when remote access is needed for third-party support, since vendor credentials and shared sessions often blur the boundary you are trying to make explicit. These controls tend to break down in flat OT networks with unmanaged legacy devices because the environment cannot reliably distinguish authorised machine traffic from lateral movement.

Common Variations and Edge Cases

Tighter segmentation often increases operational friction, requiring organisations to balance availability and maintenance speed against reduced attack surface. That tradeoff is real in OT, where downtime can affect safety or production, so the first boundary design should be narrow enough to reduce risk but broad enough to preserve essential operations.

There is no universal standard for this yet, especially in plants with mixed-vendor systems, serial protocols, or long-lived controllers that cannot support modern identity features. In those environments, current guidance suggests starting with compensating controls: jump hosts, session recording, protocol allowlisting, and time-bound access approvals. The aim is still to define trust boundaries explicitly, even if enforcement is partial at first.

For organisations exposed to vendor service access, the lessons from the Schneider Electric credentials breach underline why remote pathways deserve first-class boundary treatment. In OT, the most dangerous assumption is that a maintenance path is “temporary” when it has become a standing exception. Best practice is evolving toward continuous validation of every access path, but many sites still rely on inherited trust from network position alone.

Related resources from NHI Mgmt Group

• Should organisations prioritise external exposure or internal credential governance first?
• Should organisations prioritise Zero Trust or least privilege first for NHI risk?
• When should teams move from target-phase controls to advanced OT Zero Trust controls?
• Should organisations prioritise zero trust or NHI governance first?