Why do OT and IT integrations increase NHI risk?

Why This Matters for Security Teams

OT and IT integrations widen NHI risk because they collapse two operating models that were never designed to share trust. IT systems often tolerate faster change, broader connectivity, and frequent credential use, while OT environments prioritise safety, uptime, and tightly bounded access. When a service account, API key, or device certificate crosses that boundary, it can inherit trust that exceeds its original scope. That is how a credential meant for controlled automation becomes a pathway into critical systems.

This is not a hypothetical concern. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, and 71% are not rotated within recommended time frames. In integrated environments, those weaknesses compound because OT connectivity is often added through gateways, brokers, historians, and remote support tools that extend the blast radius of one compromised identity. Security teams also need to treat identity sprawl as a governance issue, not just a technical one, which is why current guidance in the NIST Cybersecurity Framework 2.0 remains useful for mapping control ownership across environments.

In practice, many security teams discover over-trusted machine accounts only after an IT-to-OT pathway has already been used for lateral movement.

How It Works in Practice

The risk increases at the points where integrations rely on standing access, shared secrets, or long-lived tokens to keep systems talking. OT telemetry collectors, engineering workstations, jump servers, MES connectors, and cloud brokers commonly require machine identities to authenticate across multiple trust zones. If the same secret is reused across sites or vendors, a compromise in one domain can be replayed in another. That is why NHI hygiene matters as much as network segmentation.

A practical control model starts with identity inventory, secret location, and privilege scope. Teams should identify every machine identity involved in an OT and IT link, determine where its secret lives, and ask whether the credential can be replaced with short-lived issuance. The Top 10 NHI Issues and 52 NHI Breaches Analysis both show a consistent pattern: poor visibility, excessive privilege, and weak rotation are common precursors to compromise. Where possible, align access to zero standing privilege and issue credentials just in time for a task, then revoke them automatically when the workflow completes.

• Prefer workload-scoped identities over shared operator accounts.
• Use vaulting, rotation, and expiry for secrets that must exist.
• Separate OT break-glass paths from routine IT integrations.
• Log credential use and authorisation decisions at the integration boundary.
• Review vendor and remote-support access as part of the same trust chain.

For policy framing, NIST Cybersecurity Framework 2.0 helps structure governance, while NHI breach research such as the Ultimate Guide to NHIs — Key Challenges and Risks reinforces why secret sprawl and privilege creep are operationally dangerous. These controls tend to break down when legacy OT devices cannot support modern auth or rotation because operators then preserve availability by leaving static credentials in place.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance resilience against maintenance complexity. That tradeoff is especially sharp in brownfield OT, where protocol constraints, vendor warranties, and uptime requirements can limit how aggressively secrets are rotated or how quickly standing access can be eliminated. There is no universal standard for this yet, so best practice is evolving around compensating controls rather than assuming every environment can adopt the same pattern.

One common exception is remote support for specialist equipment. In those cases, current guidance suggests isolating the path, time-boxing access, and monitoring every action, rather than granting broad shared credentials. Another edge case is mixed cloud and plant-floor automation, where a modern IT side may support federated workload identity but the OT side still relies on certificates embedded in appliances. The safest design is to reduce the trust lifetime at every seam, even if the final device cannot yet support full JIT issuance. The Cisco DevHub NHI breach and the Schneider Electric credentials breach illustrate how exposed credentials and weak boundary control can turn an integration into an access path. In integrated OT and IT estates, the failure is rarely a single control gap; it is the accumulation of shared trust, delayed rotation, and weak ownership across systems that were never meant to share the same identity model.

Related resources from NHI Mgmt Group

• Why do non-human identities increase zero trust risk?
• Why do secrets create disproportionate risk in NHI environments?
• Why do Salesforce integrations increase NHI risk?
• How should teams reduce the risk from exposed NHI secrets?