What breaks when IT and OT teams do not align on access policy?

When IT and OT access policy diverge, what actually breaks?

What breaks first is consistency. IT teams usually optimise for least privilege, central approval, and rapid revocation, while OT teams optimise for uptime, safe maintenance, and vendor support. When those goals are not reconciled, access decisions become inconsistent by site, by shift, or by engineer, and the policy stops behaving like a control.

The practical failure is that exceptions become the operating model. Teams start bypassing standard approvals to keep production running, and the organisation loses a single defensible rule for who may access plant systems, when, and under what supervision.

Why misaligned policy drives privilege creep and exception debt

Misalignment usually pushes organisations toward broader standing access, shared accounts, and manual overrides because the fastest path through a production issue is often the least governed one. That creates privilege creep across engineers, contractors, and support staff, especially when access is granted for one urgent task and never meaningfully reduced afterward.

Once exception handling becomes normal, the policy layer and the operational layer drift apart. The written rule may still say "approve and review", but the lived process becomes "grant now, reconcile later", which is how unmanaged access accumulates.

In OT environments, this drift is especially costly because access often touches systems that cannot tolerate frequent disruption. Guidance such as NIST SP 800-82 Rev 3 and CISA Industrial Control Systems both reinforce that operational segmentation, controlled access, and change discipline are foundational in industrial settings.

Where alignment fails in day-to-day operations

The breakage usually appears in four places: maintenance windows, vendor remote access, emergency access, and service account governance. IT may insist on time-bound approval and strong authentication, while OT may need faster access for troubleshooting or safety interventions. If no common policy exists, each team invents its own workaround, and those workarounds multiply.

Another common failure is poor role design. When access is built around individual exceptions instead of stable job functions, people inherit more permission than they need, and no one can explain why the access still exists. That is a governance failure as much as an access-control failure.

This is where a clearer authorisation model matters. A structured approach to roles, attributes, and policy decisions helps teams separate routine operations from exceptional access and keep production tasks from becoming permanent entitlements, as set out in the Authorisation Models Guide. In OT specifically, the OT and ICS Identity and Access Guide is useful because it shows how shared accounts, vendor access, and segmentation interact in industrial environments.

Risk and Threat Considerations

When access policy is not aligned, the risk is not only overpermission, it is also loss of control over who can reach production assets and how quickly that access can be revoked. Exception-driven access tends to hide in plain sight, making misuse, account sharing, and contractor overreach harder to detect before they become an incident.

Failure mechanism: The organisation substitutes convenience for governance, so production access is granted through ad hoc approvals, shared credentials, or persistent exceptions that outlive the task they were meant to support.

Impact: Privilege creep expands blast radius, incident response slows because ownership is unclear, and a compromised or overprivileged account can reach systems that should have been isolated or tightly mediated.

That pattern is not hypothetical in practice. The Azure Key Vault Contributor escalation 2024 example shows how excessive access can turn a nominally limited role into broad secret exposure, which is the same control failure class that appears when access policy is weakened for operational convenience.

Practitioner Guidance

What to prioritise: Start by agreeing which access decisions are truly operational emergencies and which are just slow approvals. If a task is routine, it should be modelled as a standard role or policy path, not an exception.

What to verify: Check whether every standing exception has an owner, an expiry, and a documented operational reason. If any of those three are missing, the access is already drifting into privilege creep.

Decision rule: If the access is needed to keep production safe or running, design for fast granting with tight scope and fast expiry, rather than permanent broad access. If the access is only needed for convenience, do not encode it into the production baseline.

Practitioner takeaway: The real control objective is not maximum restriction or maximum uptime, it is a policy that can be followed during live operations without turning exceptions into a shadow access model.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• What breaks when teams rely on routing instead of policy enforcement for AI tool access?