Who is accountable when privileged access crosses IT, cloud and OT boundaries?

Why This Matters for Security Teams

When privileged access spans IT, cloud, and OT, the real problem is not just where the system sits but who can change, approve, and revoke the identity behind it. Shared access paths create ambiguity: platform teams may provision it, cloud teams may scope it, and OT teams may depend on it for uptime. That ambiguity is exactly where accountability fails. Current guidance suggests the control owner must be the team that owns the access lifecycle, even when multiple operations teams depend on it.

This becomes more urgent as organisations adopt agentic workflows and machine-driven administration. The 2026 Infrastructure Identity Survey found that 67% of organisations still rely heavily on static credentials, while 70% grant AI systems more access than they would give a human employee performing the same job. NHI governance breaks down fastest when privileged workflows move across boundaries without a single revocation path. NHI Management Group’s research on the Ultimate Guide to NHIs and the 52 NHI Breaches Analysis shows that inconsistent ownership and weak lifecycle control are recurring failure patterns. In practice, many security teams encounter the accountability gap only after an elevated secret has already been reused across domains, rather than through intentional governance design.

How It Works in Practice

Accountability should be built around the access lifecycle, not the technology silo. That means one named owner is responsible for who can request privileged access, who approves it, how it is issued, what logging is mandatory, and how it is revoked. In cross-domain environments, this is usually a shared operating model with clear RACI boundaries, but the control owner remains singular: the group that can actually remove access when conditions change.

Practically, that model needs runtime controls rather than static entitlements. For IT and cloud, that often means just-in-time elevation, short-lived secrets, and policy checks at the moment of access. For OT, where availability and safety matter, approval flows may need extra change windows, compensating controls, and break-glass procedures. The key is that the same identity record and audit trail must follow the privileged action across domains. The OWASP Non-Human Identity Top 10 highlights why secret sprawl and over-privilege are so persistent, while NHI Management Group’s Azure Key Vault privilege escalation exposure illustrates how boundary-crossing access can become a privilege escalation path when ownership is unclear.

• Define one lifecycle owner for provisioning, elevation, logging, and revocation.
• Use time-bound access and short-lived credentials instead of standing privilege.
• Require shared logging across IT, cloud, and OT so no domain controls the only audit trail.
• Document who can approve break-glass access and who must review it after use.

For implementation detail, the OWASP Non-Human Identity Top 10 is useful for identifying where lifecycle control fails, while NHI-specific breach analysis such as BeyondTrust API key breach reinforces why revocation must be operationally owned, not merely documented. These controls tend to break down when OT uptime rules force exception-based access and no team is accountable for closing the exception later.

Common Variations and Edge Cases

Tighter cross-domain control often increases coordination overhead, requiring organisations to balance stronger accountability against operational speed and plant availability. That tradeoff is real in OT, where maintenance windows are narrow and emergency access is sometimes unavoidable. Best practice is evolving, but there is no universal standard for how much authority should remain with central security versus domain engineering.

In some environments, a central identity team owns the platform while cloud or OT teams own policy exceptions. That can work if the exception owner is also accountable for revocation and review. In others, especially where AI agents or automation scripts can move between environments, the owner must also validate workload identity, not just human approvers. This is where identity primitives and policy matter as much as process. The 2026 Infrastructure Identity Survey shows organisations are already struggling with autonomous access decisions, and NHI Management Group’s Snowflake breach and 230M AWS environment compromise reinforce the cost of unclear ownership. The practical test is simple: if a privileged session spans multiple domains, the organisation must still be able to name one team that can prove who approved it, who watched it, and who removed it.

Related resources from NHI Mgmt Group

• Who is accountable when cloud access expires on paper but persists in practice?
• Who is accountable when privileged access controls do not meet Part 500 expectations?
• Who is accountable when privileged access causes a production incident?
• Who should be accountable for cloud PAM when human, machine, and AI identities all have access?