IT/OT convergence is one of those phrases that gets used without anyone agreeing what it means. For some, it’s a vendor pitch. For others, it’s a Wednesday morning meeting where one team explains for the fifth time why the engineering workstation on a plant floor cannot just join Entra ID. After running a few of these design conversations recently, I wanted to put down how I actually think about it, and where the Microsoft platform pieces fit into the picture.
The two worlds, briefly
IT and OT have spent twenty years drifting apart for good reasons. IT optimises for change, patches, identities, telemetry, centralised everything. OT optimises for stability, a pump running for fifteen years on a controller no one has logged into since 2014. The Purdue model exists precisely because someone needed to draw the line between moves fast and must not break.
The five or six layers depending on who’s drawing it:
- L4 Enterprise IT:what you’d recognise as a normal corporate environment
- L3.5 Industrial DMZ: domain controllers, jump hosts, reverse proxies, brokers, patch management
- L3 Site Operations : MES, historians, engineering workstations, OT data services
- L2 Supervisory: HMIs, SCADA, alarm management
- L1/L0 Basic Control and Process: PLCs, RTUs, sensors, actuators
You cannot apply uniform security policy across those layers. An EDR agent that’s fine at L4 will not run on a PLC at L1. Trying to force it is how you break a production line.
Where Azure Local actually changes things
Azure Local is one of the most strategically important Microsoft products of the last few years for OT-heavy customers, not because of the hardware, but because of where it sits.
In the architectures I’ve been drawing recently, Azure Local lives at L3 Site Operations. That’s deliberate. It runs the workloads that need on-site availability and low latency, but that benefit from cloud control: MES platforms, historians, engineering workstations, OT data services.
What changes when you put Azure Local at L3 is the control plane question. Workloads now live behind a familiar set of Microsoft surfaces, Azure portal, Azure Arc, Azure Resource Manager. You can apply the same governance pattern as you would in Azure proper: policy, RBAC, tagging, compliance evaluation. Without exposing the OT workloads themselves to the internet.
That’s the part most IT/OT convergence pitches skip. Convergence is not getting OT onto IT’s network. It’s getting IT’s governance language onto OT’s workloads, while leaving the network boundary intact.
Arc as the lingua franca
Azure Arc is what makes that possible. The Defender for Servers and Defender for Cloud story for L3 only works because the workloads can be Arc-onboarded, they show up as Azure resources, they emit telemetry to Log Analytics, they participate in policy evaluation, they’re visible in Sentinel.
The same pattern holds at L3.5. At L2, it depends, HMIs and SCADA servers running Windows can carry MDE; legacy supervisory systems often cannot, and Defender for IoT picks up the slack with passive network monitoring. At L0/L1 there is no agent, ever. Defender for IoT, passive only, is the only signal source you’ll get.
The discipline is matching the right sensor to the right layer, and being honest about coverage gaps where they exist.
Identity is the plane that crosses both
The diagram I keep coming back to in design workshops is the Access Plane, the layer above the cloud platform that governs how administrative access reaches the environment.
What sits in the Access Plane: Conditional Access, Identity Protection, Identity Governance, Privileged Identity Management, Microsoft Defender, Intune Endpoint Compliance, Global Secure Access. This plane is the only part of the architecture that should be uniform across IT and OT.
Whether the admin is connecting to a tenant at L4, an Azure Local cluster at L3, or jumping into a hardened VDI to reach L3.5, the identity story should not change. Same Conditional Access. Same MFA. Same PIM activation. Same just-in-time governance.
If your IT and OT environments use different identity systems, different MFA stories, different admin accounts, different governance, you do not have a converged environment. You have two environments sharing a network.
EDR coexistence is the part nobody plans for
In greenfield slides, every endpoint runs MDE, every server reports to Defender for Cloud, and Sentinel sees everything. In real OT environments you walk into Cortex XDR on some hosts, CrowdStrike on others, Qualys agents quietly running compliance scans, and a Defender for IoT pilot from two years ago that never got decommissioned.
A useful design principle: Microsoft EDR on the new estate, primary-EDR decision per workload on the legacy estate, and Sentinel as the universal correlation point. You do not need to win the EDR religious war on day one. You need a single SOC view.
Local autonomy with central oversight
The other pattern I see repeating: a parent company with a central SOC, and subsidiaries with their own Azure tenants and operational autonomy. The temptation is to centralise everything into one tenant. The mistake is the same temptation taken too far.
A more durable pattern:
- Each subsidiary keeps its own tenant, its own Sentinel workspace, its own incident response
- Central SOC connects via Azure Lighthouse + Workspace Manager, read access for content distribution and oversight, no operational ownership
- Third-party tooling (CNAPP, vulnerability scanning) connects read-only via service principal with Reader + Security Reader
Local autonomy means the subsidiary’s IT/OT teams can act fast on their own incidents. Central oversight means group security still gets a unified view. Both win, neither pretends to own what it does not.
Closing thought
The hardest conversations in IT/OT modernisation aren’t about technology. They’re about who decides. Who owns the policy that lands on the L3 workload? Who owns the identity that activates the privileged role? Who sees the Sentinel incident first?
The Microsoft platform, Azure Local, Arc, Defender XDR, Sentinel, Entra, gives you the technical fabric to answer those questions. It does not answer them for you. That is still the consulting work.
