Shared access paths increase risk because they connect business systems to process and safety environments through the same trust relationship. If an attacker takes over a privileged account or remote access channel, the breach can cross from corporate IT into control systems. In OT, that can become a production or safety incident, not just an IT problem.
Why This Matters for Security Teams
Shared IT and OT access paths are risky because they collapse two very different security assumptions into one control plane. IT environments are designed for confidentiality and rapid change; OT environments prioritise availability, deterministic operations, and safety. When the same remote access tool, privileged account, jump host, or service credential reaches both, compromise in one domain can become a path into the other.
Security teams often miss that the issue is not only authentication, but also trust propagation. A credential that is acceptable for business IT may be far too broad for a plant network, especially if it can be reused, cached, delegated, or embedded in automation. The NIST Cybersecurity Framework 2.0 is useful here because it treats access control, segmentation, and resilience as linked outcomes rather than separate projects. In OT, that distinction matters because a single identity or access failure can affect production, safety, and recovery all at once. In practice, many security teams encounter the true cost of shared access only after a remote support session or privileged credential has already crossed into the control environment.
How It Works in Practice
In real environments, shared access paths usually appear as convenience layers: a VPN into corporate IT, a jump server into plant systems, a remote admin tool used by both engineers and vendors, or a service account that supports engineering workstations and OT applications. Each layer reduces friction for operations, but it also creates a larger blast radius if the account, device, or session is compromised.
The operational risk increases when identity controls are inconsistent across domains. IT may support MFA, conditional access, and rapid password rotation, while OT assets still rely on long-lived credentials, shared local accounts, or exception-based remote access. If those paths converge, an attacker can exploit the weaker control point and move laterally. That is why practitioners should treat access path design as a security architecture problem, not just an admin task. The OWASP guidance on OWASP Non-Human Identity Top 10 is relevant because many shared OT access paths depend on non-human accounts, machine credentials, and embedded secrets that are often overlooked.
- Separate IT and OT trust zones where possible, and restrict cross-zone access to narrowly defined workflows.
- Use unique privileged identities for operators, engineers, vendors, and automation rather than shared accounts.
- Apply strong session controls to remote access, including logging, time bounds, and approval for sensitive changes.
- Inventory all service accounts, API keys, certificates, and device credentials that can reach OT assets.
- Monitor for path reuse, privilege escalation, and unexpected lateral movement between business and control networks.
The control intent maps well to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access enforcement, least privilege, and session protection need to be demonstrated across mixed environments. These controls tend to break down when legacy OT vendors require persistent remote connectivity because exceptions become normalised and no one can prove which identity actually used the path.
Common Variations and Edge Cases
Tighter separation often increases operational overhead, requiring organisations to balance resilience against maintenance, vendor support, and recovery speed. That tradeoff is real in OT, where patch windows are limited and remote engineering support may be essential to uptime.
Best practice is evolving on how much convergence is acceptable. In highly regulated or safety-critical environments, the safer pattern is to make IT and OT access paths distinct, then broker only the minimum required interaction through monitored gateways or mediated workflows. In less mature environments, current guidance suggests at least compensating controls: unique credentials, step-up authentication, time-bound access, approval workflows, and full session recording for cross-domain use. Where non-human identities are involved, the risk can be higher than with human users because service accounts and automation often outlive the team that created them, and the actual access path becomes hard to audit.
Edge cases include emergency response, third-party maintenance, and remote diagnostics during outages. Those scenarios do not remove the risk; they simply justify temporary exceptions that must be controlled, logged, and reviewed. The key question is whether the shared path is a deliberate, governed bridge or an inherited convenience layer. If it is the latter, the organisation may believe it has one access control policy when it actually has several weakly connected ones.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Shared access paths are primarily an access control and segmentation issue. |
| NIST SP 800-53 Rev 5 | AC-2 | Account lifecycle control is critical when one identity can reach both IT and OT. |
| OWASP Non-Human Identity Top 10 | Non-human credentials often underpin shared access paths into OT environments. |
Define and enforce separate trust zones, least privilege, and monitored access paths across IT and OT.
