Security teams should govern IT/OT convergence as a single identity problem across enterprise systems, plant systems and third-party support. That means mapping all access paths, eliminating unnecessary shared credentials, constraining vendor sessions to task scope and reviewing exceptions for legacy OT systems that cannot support modern controls.
Why This Matters for Security Teams
IT/OT convergence collapses boundaries that used to simplify identity governance. Once a maintenance vendor, plant operator, historian, PLC gateway and cloud analytics service all need access, identity stops being an IT-only issue and becomes an operational safety and resilience issue. The practical challenge is not just who can log in, but which machine accounts, service principals, API keys and shared OT credentials can move between trust zones. That is why NHI governance has to sit alongside segmentation, vendor access review and incident response, not after them. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it ties identity, access control and recovery into one risk model rather than treating them as separate checkboxes.
NHIs are especially hard to govern in convergence projects because they multiply quickly and are often invisible. NHI Mgmt Group research shows only 5.7% of organisations have full visibility into service accounts, and that visibility gap is exactly where shared credentials and unmanaged vendor tokens linger. The same pattern appears in incident research, where 52 NHI Breaches Analysis shows how identity weaknesses turn into lateral movement once one account is exposed. In practice, many security teams discover the problem only after a plant vendor session, jump host or engineering workstation has already been overused beyond its intended scope.
How It Works in Practice
Govern identity in convergence projects by treating every access path as a workload identity problem first and a user convenience problem second. Start with a complete map of identities across enterprise systems, OT platforms, remote support channels and service integrations. Then classify each one by owner, purpose, privilege level, authentication method, rotation requirement and break-glass status. Where possible, replace shared secrets with per-workload credentials, short-lived tokens and JIT approvals tied to a specific task. For autonomous or semi-autonomous tooling, intent-based authorisation is better than static RBAC because the allowed action should be evaluated at request time, not inferred from a job title or a maintenance calendar.
Practical controls usually include:
- Separate human, service and vendor access paths, with explicit approval for each trust zone.
- Use PAM for privileged sessions, but restrict session scope, time window and command set.
- Issue ephemeral secrets for vendors and automation, then revoke them automatically on task completion.
- Rotate and inventory machine identities as a lifecycle activity, not an occasional audit.
- Require logging for every identity action that touches OT assets, even when the asset itself cannot enforce modern controls.
The governance model should also reflect NIST Cybersecurity Framework 2.0 functions for Protect, Detect and Recover, because identity failure in OT often becomes an availability event before it becomes a confidentiality event. For broader NHI lifecycle guidance, the Ultimate Guide to NHIs and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs are the most practical references for ownership, rotation and offboarding discipline. These controls tend to break down when legacy OT vendors require persistent service accounts that cannot support rotation, session recording or per-task token issuance.
Common Variations and Edge Cases
Tighter identity control often increases operational overhead, requiring organisations to balance safety and traceability against uptime, vendor response time and plant-change windows. That tradeoff is real, especially where PLCs, historians and engineering tools were designed for always-on trust rather than dynamic authorisation. Current guidance suggests using compensating controls when legacy OT cannot support modern NHI safeguards, but there is no universal standard for this yet. The usual answer is to isolate those systems, minimize their blast radius and document exceptions with expiry dates rather than allowing permanent waivers.
Third-party support is the hardest edge case because access is legitimate, time-sensitive and frequently overbroad. The Top 10 NHI Issues resource highlights why over-privilege and poor visibility persist, while the Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps teams translate that into audit evidence. For vendor sessions, best practice is evolving toward task-scoped JIT access, session recording, and a clear sponsor inside the operating organisation. For machine-to-machine links, the safest pattern is workload identity plus short-lived credentials rather than embedded secrets in scripts or engineering workstations. Legacy OT environments that cannot log identities reliably, or that depend on static passwords shared across shifts, are where governance degrades fastest and exceptions become the main control.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Rotation and expiry are central to OT service and vendor secrets. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access applies directly to shared vendor and machine accounts. |
| NIST Zero Trust (SP 800-207) | Zero Trust fits converged networks with mixed trust zones and vendors. |
Inventory OT NHIs and enforce rotation or revocation whenever credentials are no longer task-bound.
Related resources from NHI Mgmt Group
- How should security teams govern app identity modernization across multi-cloud environments?
- How should security teams govern AI-generated identity workflows in application code?
- How should security teams govern agent-operated identity configuration from the terminal?
- How should security teams govern non-human identities at scale?
