OT to IT communication is the exchange of data or commands between operational technology and enterprise information systems. It creates a governance challenge because the two environments usually differ in uptime requirements, authentication maturity, patch cycles, and tolerance for security control latency.
Expanded Definition
OT to IT communication describes the controlled exchange of telemetry, events, commands, and orchestration signals between operational technology and enterprise IT systems. In NHI governance, the critical issue is not connectivity alone, but which non-human identities, credentials, and trust paths are allowed to bridge two environments with different risk models. Definitions vary across vendors, especially when the path includes historians, gateways, message brokers, or AI-enabled agents. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it frames secure communication as a governance and risk outcome, not just a transport problem.
OT systems often prioritise deterministic uptime and safety, while IT systems prioritise identity, logging, and change velocity. That mismatch creates edge cases: a service account that is acceptable in a flat IT network can become an unsafe bridge if it can issue commands into a plant environment, a building system, or a remote control network. In practice, OT to IT communication should be treated as a policy boundary that requires explicit identity, protocol filtering, and reviewed authorization. The most common misapplication is treating every telemetry path as “read only,” which occurs when operators overlook bidirectional command channels hidden inside middleware, agents, or vendor maintenance workflows.
Examples and Use Cases
Implementing OT to IT communication rigorously often introduces latency, protocol translation, and change-control overhead, requiring organisations to weigh operational visibility against the cost of tighter governance.
- Production telemetry flows from a PLC or SCADA gateway into an analytics platform, where the sending identity must be scoped to data export only and not command issuance.
- A maintenance platform pushes firmware or configuration updates from IT into OT, which demands stronger approval workflows, short-lived access, and tightly monitored NIST Cybersecurity Framework 2.0-aligned controls.
- A vendor remote support session crosses the boundary using a privileged service account, similar to patterns seen in the Schneider Electric credentials breach, where credential handling and access scope become decisive.
- An operations dashboard consumes OT events through an API gateway, and the gateway identity must be isolated from broader enterprise integrations to prevent lateral movement.
- An AI agent summarises plant status for business users, but the agent must not inherit command rights simply because it can read operational data.
These use cases differ in protocol, directionality, and blast radius, but all depend on clear identity boundaries and auditable authorization. The design pattern should be explicit, not assumed, because OT to IT communication often spans legacy systems that were never built with modern identity controls in mind. In incidents involving exposed maintenance paths, the weakness is frequently not the data stream itself but the over-privileged account behind it, a lesson reinforced by the Schneider Electric credentials breach.
Why It Matters in NHI Security
OT to IT communication matters because every bridge between environments creates an identity enforcement point, and those points are where service accounts, API keys, certificates, and agent credentials tend to accumulate. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which means a seemingly narrow telemetry integration can become a high-impact path if its credentials are reused or over-scoped. That risk is especially serious in converged environments where engineering teams, vendors, and automation platforms all touch the same data path.
Security teams often focus on the network segment and miss the identity layer. Yet compromised non-human identities are a major cause of identity-driven incidents, and OT to IT links can magnify the damage because the downstream systems may include safety monitoring, production scheduling, or remote administration tooling. Zero Trust Architecture is therefore not optional rhetoric here; it is the operational model that forces continuous verification, least privilege, and explicit trust evaluation across the boundary. The NIST Cybersecurity Framework 2.0 and Zero Trust thinking both support this approach, while the Schneider Electric credentials breach illustrates how exposed credentials can turn an operational linkage into an enterprise incident.
Organisations typically encounter the consequences only after a maintenance outage, a suspicious command, or an unexpected data exfiltration event, at which point OT to IT communication becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | OT to IT links depend on identity-based access control and continuous verification. |
| NIST Zero Trust (SP 800-207) | PDP/PEP | Zero Trust defines policy enforcement for every request crossing the OT/IT boundary. |
| OWASP Non-Human Identity Top 10 | NHI-02 | The term often involves secrets, service accounts, and over-privileged machine identities. |
Restrict cross-boundary service identities and review access paths under a least-privilege access program.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org