Who is accountable when identity and trust gaps disrupt security in IT and OT convergence projects?

Why This Matters for Security Teams

IT and OT convergence fails when identity and trust decisions are treated as a side issue instead of a core design constraint. In these projects, credentials, certificates, service accounts, and machine identities often cross boundaries faster than governance can follow. That creates blind spots in authentication, privilege assignment, and revocation, especially when industrial uptime pressures override security controls. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, which makes accountability harder to prove and easier to avoid.

Current guidance suggests that accountability should be explicit across industrial security architecture, identity governance, and operational resilience. The risk is not only unauthorised access, but also delayed recovery when certificates expire, secrets are not rotated, or access policy is inconsistently applied across plant systems and enterprise tooling. The issue is visible in incidents described in the Ultimate Guide to NHIs and the 52 NHI Breaches Analysis, where weak lifecycle discipline and poor ownership repeatedly appear as root causes. In practice, many security teams encounter these failures only after an outage, lateral movement event, or vendor access dispute has already forced the question of who owned the gap.

How Accountability Should Work in Practice

Accountability in convergence projects should be assigned by control domain, not by organisational convenience. Industrial security architecture should own the trust model for plant and edge systems. Identity governance should own lifecycle rules for service accounts, certificates, API keys, and privileged access. Operational resilience should own recovery expectations, including rollback, emergency revocation, and continuity when trust anchors fail.

Practically, that means each control must have a named owner, a review cadence, and an escalation path. Teams should define who approves issuance, who monitors use, who rotates secrets, and who revokes access when a device, workload, or supplier relationship changes. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls remains useful here because it helps translate accountability into control families for access control, audit, and configuration management. For industrial environments, that control mapping should be supplemented by asset-level inventory and a clear trust boundary diagram.

• Assign one owner for identity policy, one for technical enforcement, and one for operational response.
• Link certificate and secret lifecycle tasks to change management, not ad hoc ticket queues.
• Require evidence of rotation, revocation, and logging before systems move into production.
• Review third-party and vendor identities separately, because their failure modes often cross IT and OT boundaries.

Where possible, use shared governance boards to resolve disputes, but do not let shared governance replace named accountability. These controls tend to break down in brownfield OT environments where legacy devices cannot support modern rotation or centralized authentication, because teams then leave exceptions in place indefinitely.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance resilience against uptime, maintenance windows, and vendor support constraints. That tradeoff becomes most visible in OT segments with legacy protocols, unmanaged assets, or safety-critical processes. Best practice is evolving, but there is no universal standard for every plant topology, so accountability models must be adapted to the environment rather than copied from enterprise IT.

One common edge case is shared responsibility with external integrators or managed service providers. In those scenarios, the vendor may operate the system, but the asset owner still owns risk acceptance, access approval, and revocation authority. Another edge case is emergency access during outages, where just-in-time exceptions may be required, but they still need a post-event review and full logging. The State of Non-Human Identity Security is relevant here because it shows that credential rotation and excessive privilege remain persistent issues across organisations, which is exactly where accountability gaps become visible. The practical test is simple: if no team can prove who approved access, who can revoke it, and who verifies the revocation, accountability has not been assigned, only assumed.

Related resources from NHI Mgmt Group

• Who is accountable when layered identity security leaves gaps between Microsoft and non-Microsoft environments?
• How should security teams govern identity in IT/OT convergence projects?
• Why do separate onboarding, login, and recovery flows create security gaps in identity programmes?
• Who is accountable for partner enablement when identity security programs expand across regions and industries?