What should organisations do when identity and operational technology both share the same network

Why shared OT and identity networks need containment, not just connectivity controls

When identity services and operational technology sit on the same network, the main design error is assuming ordinary segmentation rules are enough. OT environments often include fragile controllers, legacy protocols, and devices that cannot tolerate aggressive scanning or frequent change. The governance goal is to preserve operations while limiting how far trust, credentials, and administrative pathways can travel.

That means the boundary should be defined around function and trust zone, not around the convenience of a flat internal network. Shared routing may be unavoidable in some plants or clinical environments, but shared trust is not. A workable design separates identity infrastructure, operator access, vendor access, and OT control paths so a compromise in one area does not automatically expose the others.

For OT-specific segmentation and control expectations, NIST SP 800-82 Rev 3 remains the clearest baseline for understanding how industrial networks should be isolated and monitored without breaking process availability.

Where identity creates the biggest blast-radius problem

The risk is rarely the network share itself, but the way identity systems can become a bridge across it. If directory services, admin consoles, service credentials, or remote support paths are reachable from OT-facing segments, then compromise of one side can rapidly become privilege abuse on the other. In practice, shared network space turns access management into a blast-radius problem.

Identity controls should therefore be aligned to the smallest operational unit that actually needs trust. Shared accounts, long-lived secrets, and broad admin roles are especially dangerous in mixed OT environments because they bypass the natural safety limits that physical systems once provided. OT and ICS Identity and Access Guide covers the specific patterns that create that exposure, including vendor remote access, shared accounts, and zones-and-conduits thinking.

For teams already dealing with machine or service credentials across mixed environments, the lifecycle of those credentials matters as much as the network topology. NHI Lifecycle Management Guide is useful here because offboarding, rotation, and discovery are the difference between bounded access and lingering reachability.

How to separate operations without breaking them

The practical answer is to isolate by workflow. Keep identity administration, operator access, remote maintenance, and process control on distinct paths with explicit allow rules between them. Where shared infrastructure is unavoidable, use choke points such as jump hosts, brokered access, strong logging, and tightly scoped credentials so the OT side only sees the minimum necessary dependency.

That separation should be governed as an operational constraint, not a theoretical ideal. If a control would interrupt plant uptime or clinical availability, replace it with a compensating boundary that still narrows trust, such as segmented management planes, constrained remote sessions, or separate credential domains. Ultimate Guide to NHIs, What are Non-Human Identities is useful for understanding why service and workload access need different handling from human access, even when both traverse the same network.

When the environment includes third-party support or regulated operational resilience requirements, the design has to account for governance as well as topology. Ultimate Guide to NHIs, Regulatory and Audit Perspectives helps frame why access review, traceability, and accountable boundaries matter even in operationally constrained networks.

Practitioner Guidance

What to prioritise: Start with the trust paths that can cross the boundary, not with the number of VLANs. The highest-value control is usually reducing who can administer identity, who can reach OT management planes, and which credentials can authenticate across zones.

What to verify: Confirm that remote support, directory integration, backup tooling, and monitoring cannot silently become lateral-movement paths. If a credential, token, or admin session can move from identity services into process control, the segmentation model is too weak.

Common mistake: Treating “same network” as the problem and “more firewall rules” as the whole fix. The harder issue is authority leakage, so the access model must be made smaller than the network footprint.

Practitioner takeaway: In mixed IT, identity, and OT environments, the right question is not whether the systems can reach each other, but how much authority each path carries if one side is compromised.

Related resources from NHI Mgmt Group

• Why do organisations use multiple meshes when services may already share the same network zone?
• What should organisations do when student-facing portals and admin tools share the same identity controls?
• When does a machine identity become a compliance problem?
• Why is it important to integrate identity and data governance?