Who should own IAM accountability when critical infrastructure teams move to converged IT and OT operations?

IAM accountability should sit with the teams that control identity policy, access decisions, and operational enforcement, not with one environment alone. In converged IT and OT operations, governance must span infrastructure, security, and operations so access can be verified, monitored, and revoked quickly. Clear ownership matters because identity has become the new perimeter for critical services.

Who Should Own IAM Accountability in Converged IT and OT?

IAM accountability in converged IT and OT should be owned jointly, but not vaguely. The accountable owner needs authority over identity policy, approval criteria, enforcement points, and exception handling across both environments. In practice, that usually means security sets the control model, infrastructure or platform teams run the technical enforcement, and OT operations owns the safety and availability constraints that identity decisions must respect.

Converged environments fail when IAM is treated as an IT-only discipline with OT merely consulted after the fact. OT systems often have longer asset lifecycles, vendor-managed access paths, and stricter uptime dependencies, so access governance has to reflect operational reality rather than office-network assumptions. The ownership model should therefore be explicit: one accountable function, clear control operators, and documented escalation when identity decisions affect plant stability, remote maintenance, or emergency response.

That separation matters because critical infrastructure teams often discover identity drift only after privileged access has expanded, vendor access has gone stale, or a shared account is still active in a system that nobody thought was in scope. The right answer is not a single department acting alone, but a governance model that can enforce identity controls consistently across both domains.

How Converged IT and OT IAM Should Work in Practice

In converged operations, IAM accountability should be organised around the identity lifecycle, not around network boundaries. The accountable owner defines who may request access, what evidence is required, how approvals are granted, how privileged access is time-bounded, and who can revoke access immediately when conditions change. OT specialists then validate that those controls do not create unsafe shutdown risk, maintenance blockage, or vendor support gaps.

The practical model is to separate decision authority from execution. For example, policy may require privileged sessions to use just-in-time access, but the OT operations team may need an override path for urgent plant recovery. That override should still be governed, logged, and time-limited. Where access is shared across sites or vendors, the owner should insist on named identities, strong authentication, and traceable change records rather than inherited trust in a device, cabinet, or remote support channel. The general direction of travel is consistent with zero trust thinking: identity and context matter more than location, especially when converged systems blur old perimeter assumptions.

Security should own the policy standard, control testing, and audit evidence.
Infrastructure or IAM engineering should own provisioning, revocation, and automation.
OT operations should own operational exceptions, safety constraints, and maintenance windows.
Vendors should receive least-privilege access with explicit expiration and review.

There is also a measurement issue. If no team can answer how many active privileged accounts exist, which ones are shared, or which ones were last used during a maintenance event, ownership is already fragmented. That gap is especially common in critical infrastructure because asset inventories and access inventories are often maintained separately, even though the same identity now crosses both environments. Current guidance suggests that converged IAM only works when the owner can prove revocation speed, review cadence, and exception closure, not just write policy. Organisations managing infrastructure identity should also consider the NHI maturity gap highlighted in The 2024 Non-Human Identity Security Report, which shows how quickly access governance falls behind when machine and workload identities are not centrally controlled.

These controls tend to break down when OT remote access is still handled through ad hoc vendor credentials or when incident response needs to bypass normal approvals because the environment lacks a tested emergency identity path.

Common Ownership Failures and Boundary Cases

Tighter IAM control often increases coordination overhead, so organisations have to balance operational speed against assurance. The most common failure is assigning accountability to the team that owns the directory or tooling, while leaving actual access decisions dispersed across operations, engineering, and vendors. That creates clean charts but weak enforcement.

Another boundary case appears during emergency maintenance. Best practice is evolving, but the decision rule is simple: if a control would delay safe restoration, pre-approve a bounded exception path rather than bypassing governance informally. That exception path should be documented, monitored, and reviewed after use. Where shared services span cloud, plant systems, and remote vendor support, the accountable owner should also define which access reviews are mandatory and which can be risk-based, because not every account deserves the same review depth.

The hardest edge case is responsibility without authority. If OT is blamed for access risk but cannot change the identity platform, or if security is responsible for compliance but cannot force revocation in a plant system, accountability is performative. In mature converged environments, the owner is the function that can both decide and compel action, while the supporting teams provide operational constraints and technical execution. Governance fails fastest when no one owns the exception lifecycle, because temporary access has a way of becoming permanent.

Risk and Threat Considerations

Converged IT and OT increases identity risk because access paths multiply while operational tolerance for disruption stays low. The main exposure is not just excessive privilege, but the persistence of stale vendor, shared, or emergency access that remains valid long after the original need has passed.

Failure mechanism: Weak ownership allows inconsistent approval, delayed revocation, and incomplete logging across environments. That creates an attacker and abuse path through forgotten remote access, over-privileged service accounts, or maintenance credentials that are trusted in operational systems but reviewed like ordinary IT accounts.

Impact: The result can be unauthorised control of critical services, broader lateral movement across converged networks, loss of auditability, or a forced choice between preserving safety and containing compromise. In OT, that can turn an identity problem into an availability and resilience problem very quickly.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OV-01 — Organisational Context and Governance Oversight	IAM ownership in converged operations is a governance and accountability issue.
	PR.AA-01 — Identities and Credentials Are Managed and Verified	The core control concern is managing identities consistently across critical infrastructure.
Recommendation — Assign clear governance authority for identity decisions across IT and OT. Maintain verified identity records and lifecycle controls for all privileged access.
NIST Zero Trust (SP 800-207)	5.2 — Policy Engine and Access Decisions	Converged IAM needs context-aware access decisions instead of location-based trust.
Recommendation — Centralize policy decisions and evaluate access context before granting it.
CIS Controls v8	5.2 — Account Management	The question is about ownership of account lifecycle control across environments.
Recommendation — Define accountable owners for provisioning, review, and removal of access.
NIST SP 800-63	5.1.5 — Identity Proofing and Authentication Assurance	Converged IAM depends on trustworthy identity and strong authentication for operators and vendors.
Recommendation — Require strong authentication and assurance for privileged operational identities.

Practitioner Guidance

What to prioritise: Name one accountable owner for the identity policy and revocation standard, then document which operational team can approve exceptions only within defined safety bounds. If nobody can revoke access quickly during an incident, the model is not converged enough to be trusted.

What to verify: Check whether every privileged identity has a clear business owner, a technical owner, and a review date. Shared accounts, vendor backdoors, and permanent emergency access are the three signals that ownership is still unclear.

Decision rule: If a proposed IAM control improves compliance but cannot be executed during plant operations, redesign it so the control is enforceable before rollout. A control that cannot survive maintenance windows or incident response will be bypassed in practice.

Practitioner takeaway: In converged IT and OT, the right owner is the function that can set policy, force enforcement, and close exceptions, because accountability without operational authority does not reduce identity risk.