The IT/OT boundary: what identity governance in Entra ID can and cannot do for the operational control system

Start by rejecting the premise

Any vendor who tells you their identity product "secures the OT environment" is selling something they don't have. An operational control system or process control system has its own user database, its own local accounts, its own authentication mechanism — often several, often vendor-specific, often with no connection to any directory service at all. § 7-6 of the Power Supply Preparedness Regulations (kraftberedskapsforskriften, FOR-2012-12-07-1157) even prohibits personally owned equipment in the operational control system and requires wired data communication in the control centre and data room. These are deliberately isolated environments.

Entra Logic governs Microsoft Entra ID. That's it. It has no function inside a SCADA system, no agent on a PLC, no role in a safety system.

So why is identity governance in the IT domain nonetheless one of the most cost-effective measures an energy company can take for its OT security?

Because no one attacks the OT environment directly. They attack the way in.

The way in is always an identity in the IT domain

Look at how an OT compromise actually unfolds in practice, not in threat models.

An engineer has a workstation in the office domain, authenticated against Entra ID. From that workstation, they sign in to a jump host in the DMZ between IT and OT. From there, a session is opened to the engineering workstation in the process control network. The turbine control vendor has remote access through the same path, often via a VPN or ZTNA solution that authenticates against — again — Entra ID, or against an identity provider that federates with it.

Every single one of these transitions starts with an identity that lives in the IT domain. Colonial Pipeline in May 2021 is the textbook example: an old VPN profile with a password from a leaked list, with no multi-factor authentication. The attackers never touched the OT systems — the company shut the pipeline down itself because it couldn't establish how far the compromise had spread. The operational consequence was total, and the entry point was one account nobody had cleaned up.

Norsk Hydro in March 2019 follows the same pattern at a different level: the entry point was an email attachment, but what made the attack catastrophic was the escalation to administrative privileges and control over the domain controllers. The cost is estimated at around NOK 800 million.

The point isn't that IT identity governance protects OT directly. The point is that the quality of IT identity governance determines how easy it is to reach the zone where OT access is granted.

What the standards actually say about identity in OT

IEC 62443-3-3 defines seven foundational requirements for system security in industrial automation and control systems. The first two concern identity:

• FR 1 – Identification and Authentication Control (IAC): «Control access to the IACS by identifying and authenticating all users (humans, processes, and devices).»
• FR 2 – Use Control (UC): «Enforce the privileges of authenticated users to perform actions on the IACS.»

Note that FR 1 covers humans, processes and devices. These are three populations that in practice are handled by three entirely different mechanisms, and where the latter two rarely have an owner in the organisation.

IEC 62443-2-1:2024 covers security programme requirements for asset owners — that is, the management-system side. For Norwegian petroleum operations, the industry anchor is Offshore Norway (Offshore Norge) guideline 104, formerly known as NOG 104, now ON 104, which in revision 7 (2026) carries the title Recommended guidelines on cyber security baseline requirements for Operational Technology systems. The guidance to § 34a of the Facilities Regulations, on control and monitoring systems, points to precisely this guideline.

None of these standards say that OT identities should live in a cloud directory. They say there must be control over who is authenticated and what they're allowed to do. It's a governance challenge before it's a technology challenge.

The four links between Entra ID and OT risk

Concretely, there are four places where the state of Entra ID directly affects OT risk:

1. The account belonging to the person with OT access. Everyone with user access in the operational control system also has an ordinary employee identity. If that's compromised, the starting point for lateral movement toward OT is compromised. § 7-4 of the Preparedness Regulations requires control arrangements for granting, modifying and deleting user access to the operational control system — but the signal that a person has left or changed role originates in HR and only materialises in the IT identity platform.

2. The group membership that grants remote access. In modern architectures, access to the jump host or to the ZTNA service is controlled by a security group in Entra ID and a Conditional Access policy. Who is a member of that group is therefore who can reach the OT zone. An error in group membership isn't administrative sloppiness — it's a barrier failure in the sense of the Management Regulations.

3. The supplier identity. The equipment vendor troubleshooting a converter at two in the morning is typically given a guest account or a contractor account. § 7-10 of the Preparedness Regulations requires an up-to-date list of approved users for external connections. That list and the actual guest population in Entra ID are, in most organisations, two different things.

4. The device. The engineering workstation and the laptop used to reach the OT zone are typically managed through Intune and registered in Entra ID. An orphaned device with no owner, or an Autopilot registration no one can account for, is a device that can still satisfy a Conditional Access policy requiring a "compliant device".

What can actually be done — and what can't

Achievable with Entra Logic:

• Maintain a continuously updated, searchable overview of which identities, groups and devices exist, across tenants — and thereby be able to answer precisely who is currently a member of the groups that control OT remote access.
• Ensure that changes to these groups can only happen through an approved, logged order, so that no one can add themselves or others to an OT access group without a decision that has a name attached to it.
• Remove standing administrator privileges from the people in the IT organisation, so that a compromised IT account isn't a shortcut to manipulating the access foundation.
• Catch orphaned devices and unowned registrations continuously instead of as a quarterly cleanup job.
• Deliver the structured, timestamped data foundation that an annual review under § 7-4 and a barrier assessment under § 5 of the Management Regulations actually need.

Not achievable — neither with Entra Logic nor with any other identity product in the IT domain:

• Control local accounts in SCADA, DCS or safety systems.
• Replace segmentation, zones and conduits under IEC 62443.
• Manage machine or process identities in the OT network.
• Provide any form of control over equipment or systems not represented in Entra ID.

A vendor who isn't clear about the second list hasn't thought through the first one either.

The practical recommendation

Treat the IT identity platform as a barrier in the sense of the Management Regulations — that is, as something to be identified, assigned a performance requirement and verified — rather than as an administrative service. Concretely:

1. Map which Entra groups and Conditional Access policies actually control paths into the OT zone. In most organisations this is between three and ten objects, and they're rarely documented as critical.

2. Ensure that changes to precisely these objects can never happen without approval and a log entry.

3. Establish a process where a termination of employment or a role change in the IT identity platform generates a traceable signal to those who manage OT access — and where the signal can be verified.

4. Stop giving "we have MFA" as the answer to the question of OT access control. The question is who's in the group.

Sources

• The Power Supply Preparedness Regulations (FOR-2012-12-07-1157), §§ 7-4, 7-6, 7-10 — https://lovdata.no/dokument/SF/forskrift/2012-12-07-1157
• Havtil, the Facilities Regulations § 34a (control and monitoring systems) — https://www.havtil.no/en/regulations/all-acts/the-facilities-regulations3/V/34a/
• Havtil, the Management Regulations (§ 5 barriers, § 6 governance) — https://www.havtil.no/globalassets/regelverk/gjeldende-regelverk-2022/styringsforskriften_n.pdf
• Offshore Norway (Offshore Norge), guideline overview (ON 104) — https://www.offshorenorge.no/en/faginnhold/guidelines/guidelines/
• IEC 62443-2-1:2024, Security program requirements for IACS asset owners — https://webstore.iec.ch/en/publication/62883
• Bloomberg on Colonial Pipeline — https://www.bloomberg.com/news/articles/2021-06-04/hackers-breached-colonial-pipeline-using-compromised-password
• Norsk Hydro on the cyberattack — https://www.hydro.com/en/global/media/on-the-agenda/cyber-attack/