What breaks when identity authority is split across IT, OT, and security?

When identity authority is split, what actually breaks?

The technical problem is not that IT, OT, and security each manage identities badly in isolation. The break happens at the seam: a password reset, access exception, vendor approval, or emergency override may be valid in one domain but invisible in another. That creates contradictory records, duplicated approvals, and delays that turn routine access decisions into cross-team negotiations.

Identity authority works only when one decision path can answer who may act, under what conditions, and who can revoke that access. If different teams own different parts of that path, the environment loses a single source of truth for access state, so normal operations become slower and recovery becomes harder to trust.

In practice, the split shows up as inconsistent joiner-mover-leaver handling, stale privileged access, and unclear exception ownership. A team may approve a vendor login for a plant system while another team still sees that access as unapproved, or a security team may flag a credential as high risk without being able to execute the operational change that disables it.

Why does split authority slow response before it damages accountability?

Response speed breaks first because incident handling depends on quick decisions about authentication, privilege, and suspension. If IT controls the directory, OT controls plant availability, and security controls the risk decision, no single owner can safely move from detection to containment without waiting for the other two.

That delay is especially damaging in industrial and hybrid environments because access changes often have production consequences. A well-timed block can prevent misuse, but a badly coordinated block can stall a line, interrupt remote support, or force operators to choose between continuity and control.

Accountability breaks next because each team can defend its own action while no one owns the full outcome. The organisation then gets local correctness without global responsibility, which is the worst possible state for access governance. The decision path becomes fragmented, and when something goes wrong, the question shifts from "who approved it?" to "who was supposed to reconcile it?"

What operating model problems does this create across IT, OT, and security?

Split authority usually produces three recurring failures: duplicated controls, gaps between controls, and exceptions that never expire. The more boundaries there are, the more likely a credential, role, or access path is managed in one system but not reflected in the others, especially where vendor access, shared workstations, or emergency accounts are involved.

It also creates a governance gap around ownership. If one team owns identity administration, another owns system uptime, and a third owns policy enforcement, then no team naturally owns access lifecycle, audit evidence, or revocation timing. That is where organisations lose confidence in their own records.

Industrial environments make this worse because availability pressure encourages informal workarounds. Operators and engineers often need fast access, but when authority is split, temporary access tends to become permanent because the team that granted it is not the team that can clean it up.

Risk and Threat Considerations

When identity authority is fragmented, the main risk is not just slower administration, it is uncontrolled exposure during compromise or operational change. Attackers and accidental misconfigurations both benefit when no one can rapidly confirm current privilege, revoke access, or validate that an emergency exception has been closed.

Failure mechanism: conflicting ownership lets access changes lag behind reality, so stale credentials, overbroad privileges, and untracked exceptions remain active long enough to be abused or to disrupt production when finally corrected.

Impact: the organisation gets longer dwell time, weaker auditability, and higher odds of either unauthorized access or a production outage caused by a late, uncoordinated remediation.

Practitioner Guidance

What to prioritise: establish one accountable owner for the end-to-end identity decision path, even if IT, OT, and security each retain execution tasks. The key test is whether a single person or function can answer who approved access, who can revoke it, and who must reconcile exceptions after the fact.

What to verify: confirm that emergency access, vendor access, and privileged changes have a documented handoff path from approval to implementation to review. If any of those steps can be completed without visible closure in the other domains, the model is still split in a way that will slow response and weaken evidence.

Decision rule: if an access change can affect production, treat speed and accountability as linked controls, not separate concerns. The right operating model is the one that can contain an incident without forcing operators to choose between waiting for consensus and acting without traceability.

Practitioner takeaway: the real failure is not decentralised administration, it is decentralised authority without a single decision owner. Once that happens, access stops being an operational control and becomes a coordination problem.

Related resources from NHI Mgmt Group

• What breaks when identity security capabilities are split across point products and loosely connected suites?
• How should security teams make NHI best practices usable across the business?
• What breaks when identity governance is split across vaults, IGA, and PAM tools?
• What breaks when identity governance is split across regions?