Without strong identity controls, converged OT and IT environments can create blind spots around who or what is sending commands, moving data, or changing systems. That increases the chance of unauthorized access, missed anomalies, and unsafe changes reaching critical equipment. In practice, the biggest failure is losing confidence that machine-to-machine communication is limited to trusted identities and approved actions.
Identity Boundaries Are What Keep OT Change Safe
When OT and IT are connected, the security question is no longer only whether the network is segmented. It becomes whether every command, session, API call, and automated workflow can be tied to a trusted identity with a known scope. Without that, operators may still have connectivity, but they lose reliable attribution and enforcement. The result is not just broader exposure; it is weaker control over who can issue a change, what that change can touch, and whether it should have been allowed at all.
That matters because OT environments are designed around safety, availability, and deterministic behaviour, not around frequent identity churn or loosely governed automation. If identity is vague, over-permissive, or inconsistently managed, the environment can accept traffic that appears legitimate while bypassing the checks that should prevent unsafe actions. Guidance on non-human identity governance from the OWASP Non-Human Identity Top 10 is useful here because it highlights the trust problems that appear when machine actors are left unmanaged. In practice, many security teams discover the identity gap only after an integration starts behaving like a trusted operator instead of a narrowly bounded service.
How OT-IT Integration Fails in Day-to-Day Operations
The failure is usually not a dramatic collapse. It begins when an integration is created to move telemetry, trigger maintenance actions, or coordinate production systems, and the new path is given more access than its narrow use case requires. If the request is authenticated only at the application layer, or if shared accounts and static secrets are reused, the environment cannot reliably distinguish a legitimate control action from a compromised or misrouted one. That is especially dangerous in OT, where a command may be valid syntactically but unsafe operationally.
Strong identity controls in this context usually mean more than a username and password. They include unique machine identities, scoped credentials, short-lived trust where possible, explicit authorization boundaries, and logging that makes the origin of a control action provable after the fact. They also require clear separation between read-only telemetry flows and write-capable control paths, because the security expectation for those two channels is not the same. If a monitoring integration can later be repurposed to issue commands, the identity model has already failed.
- Use distinct identities for operators, applications, and automation so access can be limited by role and purpose.
- Restrict write access to the smallest possible set of authenticated services and devices.
- Bind critical actions to approval, change control, or step-up validation when the action affects safety or availability.
- Log identity, source, and action together so investigators can tell what happened without relying on network assumptions.
The guidance starts to break down when legacy OT equipment cannot support modern authentication, or when operational pressure leads teams to accept shared access as a permanent shortcut.
Shared Access, Legacy Devices, and Other Edge Cases
Tighter identity control often increases integration effort and operational friction, so organisations have to balance safety and traceability against the realities of old equipment, vendor tooling, and uptime constraints. That tradeoff is real, but it does not justify treating every integration as equally trusted.
One common edge case is a vendor remote-support channel that must reach OT assets through IT-managed infrastructure. Another is a historian or middleware platform that aggregates data from many sources and can become a high-value pivot point if its identity is overbroad. In both cases, the problem is not simply that the component exists, but that its authority may be broader than its task. A narrowly defined service identity is preferable to one shared account that can read, write, and administer across multiple zones.
There is also disagreement in the field about how much segmentation alone can compensate for weak identity. The practical answer is that segmentation helps contain blast radius, but it does not solve attribution, approval, or command-level trust. If identity is weak, a permitted path can still become a dangerous path. Conversely, even well-designed identity controls need to be paired with OT-aware change governance, because a perfectly authenticated command can still be the wrong command. The most common failure is assuming that connectivity control and identity control are interchangeable when they solve different problems.
Risk and Threat Considerations
Weak identity controls in converged OT and IT environments create a trust problem that can turn routine integration paths into unsafe control paths. The main risk is that systems will accept commands, data transfers, or admin actions without reliable proof of who or what initiated them, which makes misuse harder to detect and contain.
Failure mechanism: Shared accounts, static credentials, excessive service permissions, or poorly separated machine-to-machine trust let a compromised IT-side system, integration broker, or automation account act with OT-relevant authority. Attackers and insiders both benefit from that ambiguity because it reduces visibility, weakens authorization boundaries, and makes malicious or accidental actions look legitimate.
Impact: The practical consequence is unsafe change propagation into critical equipment, loss of command attribution, delayed incident response, and a wider blast radius if one connected identity is abused. In the worst case, the organisation can no longer prove which actor issued a control action or whether it should have been allowed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 5 — Account Management | OT-IT integration fails when shared or excessive accounts blur command authority. |
| 6 — Access Control Management | The question is about limiting which identities can send commands or change systems. | |
| 8 — Audit Log Management | Loss of identity attribution is a core failure when OT and IT are connected loosely. | |
| Recommendation — Enforce unique, least-privilege accounts for every operator, service, and integration path. Restrict write access to only the identities that must issue approved OT actions. Log identity, source, and action together so control changes can be traced and reviewed. | ||
| NIST CSF 2.0 | PR.AC — Access Control Management | Connected OT-IT environments need strong authentication and authorization boundaries. |
| DE.AE — Anomalies and Events | Weak identity makes suspicious commands harder to distinguish from legitimate operations. | |
| Recommendation — Apply access control rules that separate trusted control paths from ordinary IT connectivity. Correlate identity and command telemetry to detect abnormal OT actions faster. | ||
| MITRE ATT&CK | T0859 — Valid Accounts | Abuse of legitimate credentials is a direct way to hide malicious OT or IT activity. |
| T1078 — Valid Accounts | Shared or overbroad credentials let attackers appear as trusted operators or services. | |
| Recommendation — Hunt for legitimate account abuse on control paths and revoke access that is broader than role. Detect and remove overused credentials that grant trusted access to OT-connected systems. | ||
Practitioner Guidance
What to prioritise: Treat identity scoping as part of OT safety architecture, not as a general IT hygiene task. The first control question should be whether any connected service can issue a write action, and if so, whether that authority is both necessary and provable.
What to verify: Confirm that each integration has a unique identity, a documented purpose, and a clear boundary between read-only and control-capable access. Verify that shared accounts, hard-coded secrets, and blanket administrative permissions are not being used as convenience fixes.
Decision rule: If a connected system can change OT state, it should be treated as a high-consequence identity, with tighter approval, logging, and review than a normal enterprise application. If it only observes or reports, its access model should still be bounded so it cannot quietly become a control channel later.
Practitioner takeaway: The critical judgement is not whether OT and IT can be connected, but whether every connected path has an identity model precise enough to stop a trusted integration from becoming an uncontrolled operator.
Related resources from NHI Mgmt Group
- What breaks when OT networks are segmented without strong identity controls?
- What breaks when blockchain platforms scale to mainstream events without strong identity and source-of-funds controls?
- What breaks when organisations decentralise identity without strong verification and recovery controls?
- What breaks when organisations put sensitive identity data on a public blockchain without strong governance controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
