IT/OT Convergence: Where Identity Gets Caught in the Middle

IT/OT convergence is the steady joining of operational technology (the systems that run physical processes) with the business networks, applications and cloud services that IT runs. It happens because connected plants are cheaper to run and easier to improve, and it leaves identity caught in the middle: the same accounts, trusts and remote access paths that make convergence work are the ones attackers use to cross from one world into the other.

I spend a lot of time at that seam. This is less a primer and more a field note on what convergence does to access, why IT security and engineering keep talking past each other about it, and what I think converging safely actually looks like.

What does IT/OT convergence actually mean?

Ask five people and you’ll get five definitions. In practice it’s not one project. It’s an accumulation of reasonable decisions, each of which adds a connection between the plant and everything else:

• Connected plants. Historians replicate process data to the business so planners, quality teams and finance can see it without walking to the control room.
• Remote operations. Engineers support several sites from one place, and OEM vendors troubleshoot their equipment without getting on a plane.
• Cloud analytics. Process data flows to cloud platforms for predictive maintenance, energy optimization and reporting.
• IIoT. New sensors and gateways are installed with a cloud connection built in, sometimes skipping the plant network entirely.
• Shared infrastructure. OT systems start using IT’s directory, IT’s patch servers, IT’s backup tooling and IT’s help desk, because running two of everything is expensive.

None of these is a bad idea. Most of them are good ideas. The problem is that they tend to arrive one at a time, approved by different people for different reasons, and nobody steps back to look at the access model they’ve collectively built.

Why organizations converge IT and OT

It’s worth being fair about the benefits, because security teams that only talk about risk lose this argument.

Driver	What the business gets	What it usually requires
Visibility	Production, quality and energy data in business systems	Data flows from Level 3 up to the enterprise or cloud
Remote support	Faster fixes, fewer site visits, smaller on-site teams	Inbound remote access for engineers and vendors
Predictive maintenance	Fewer unplanned outages, longer asset life	Sensor and historian data in analytics platforms
Standardization	One set of tools, one support model, lower cost	Shared directories, management tools and service accounts
Faster change	New products and process tweaks without long projects	More frequent connections and more people with access

Look at the right-hand column. Almost every benefit comes with either a new data path or a new access path. Data paths can be made mostly one-directional. Access paths, by definition, let someone in.

The security and identity consequences of IT/OT convergence

The breach stories everyone cites in OT, from the 2015 Ukrainian grid attack onward, share a pattern I covered in what OT security is: attackers got credentials on the IT side and used legitimate access paths to reach the control side. Convergence multiplies those paths. Four consequences show up again and again.

Shared accounts follow the systems that use them

OT has always had shared accounts, and some are operationally necessary. Convergence makes them travel. The shared engineering login that used to work only at a console in the plant now works through a remote access tool from anywhere. The integration account that feeds the historian replica now authenticates across a boundary. Same credential, much bigger blast radius.

Vendor access becomes permanent by accident

Remote vendor support is one of the clearest convergence wins, and one of the clearest risks. A VPN account created for a single job, a remote desktop tool left running after commissioning, a cellular modem in a cabinet so the OEM can dial in: each is temporary until nobody remembers it exists. Vendor access is privileged access in every meaningful sense, but it’s rarely managed like it.

What this usually looks like: The classic find is a cellular router in a control cabinet, installed by an OEM so they can support a skid without waiting on the customer’s VPN process. It’s not on any IT asset list, it never touches the corporate firewall, and the credentials are often still the vendor’s defaults. Passive monitoring or a walkdown will find it. Asking maintenance “how does the vendor connect when something breaks?” often finds it faster.

Active Directory trust bleeds into OT

This is the one I’d lose the most sleep over. When OT systems join the corporate domain, or an OT forest trusts the corporate forest without tight scoping, the plant’s security becomes a function of the corporate directory’s security. If an attacker gets domain admin on the IT side, they may already have the keys to engineering workstations and historians. That’s not convergence, that’s merging, and it ties plant availability to the health of a directory that was never designed with a control room in mind.

Flat networks meet new neighbors

Many plant networks were built flat because they were assumed to be isolated. Convergence removes the isolation without adding the segmentation. A single compromised laptop on a plant VLAN that also reaches the corporate network, a cloud gateway that sits on the same subnet as the PLCs, a “temporary” firewall rule that allows RDP from the whole office: each one turns a network diagram into a wish.

Why IT security and engineering keep talking past each other

The technical problems are solvable. The organizational friction is harder, and I’d argue it causes more of the risk.

IT security teams tend to arrive with policies, tools and timelines that work well on laptops and servers. Engineering and operations teams hear “agent,” “forced reboot” and “account lockout” and picture a process going dark mid-shift. Both sides are right about their own world. The identity playbook that works in IT tends to fall apart below Purdue Level 3, and engineers know it even if they don’t phrase it that way.

The friction shows up in predictable places:

• Ownership. Who owns the historian replica in the DMZ? The firewall between Levels 3 and 4? The service account that connects them? Often the honest answer is “both, so neither.”
• Change management. IT wants to patch monthly. Operations has a management-of-change process and an outage window twice a year.
• Language. IT says “endpoint” and “identity provider.” Engineering says “HMI,” “engineering station” and “the vendor’s laptop.”
• Risk framing. IT measures risk in data loss and downtime cost. Operations measures it in safety, environmental impact and production. A control system outage is a safety event, not a ticket, and controls that don’t respect that get quietly bypassed.

A common version of this: Picture IT announcing that every OT Windows host gets the corporate EDR agent and monthly patches by quarter end. Engineering points out that the control system vendor only supports certified patches, and an uncertified agent can void the support contract. The version both sides can usually live with: EDR where the vendor certifies it, passive network monitoring everywhere else, patches staged on a test system and applied in planned outage windows, and every exception written down with an owner.

The fix isn’t for one side to win. It’s to agree that convergence is a shared program with shared decisions, and to write those decisions down.

How to converge IT and OT safely

Here’s the order I’d work in. None of it is new, but the sequencing matters more than people expect.

1. Build an asset and access inventory first

You can’t decide which connections to keep until you know which exist. Inventory the assets, but also the access: every remote path, every account that crosses the boundary, every service account and integration credential, every certificate a gateway uses to talk to the cloud. Use passive discovery on control networks, and pair it with engineering drawings and walkdowns. The modem in the cabinet won’t show up on a scan.

2. Put an IDMZ between the worlds

The industrial DMZ is where convergence should happen on purpose. Nothing on the enterprise side talks directly to anything in operations. Data goes up through brokers or replicas. People come down through jump hosts or a remote access gateway. I walk through what belongs there in the Purdue model for identity post, so I won’t repeat it here, but the short version is that the IDMZ should be the single place where IT identity stops and OT identity starts.

3. Separate the OT identity domain, or scope trust carefully

My default recommendation is a dedicated OT directory with no trust to corporate IT, and separate admin identities for anyone who works in both. Some organizations have good reasons for a constrained trust, such as a small team that can’t run two directories. If that’s you, make the trust one-way, selective, and as narrow as you can get it, and treat any account that can administer OT from the IT side as the most sensitive account you have.

4. Broker all remote access

Every human crossing into operations, employee or vendor, goes through one brokered path: strong MFA at the boundary, approval tied to a reason or work order, credentials injected rather than handed over, sessions recorded, access that expires when the job does. Then go find the other paths and close them. This is also where convergence lines up with Zero Trust: verify the person and the session at the boundary, because the devices behind it often can’t verify anything.

5. Segment for the connections you chose

Once you know which data and access paths you’re keeping, build zones and conduits around them. Every conduit should have a named purpose, a named owner and a firewall rule that matches. Anything that doesn’t fit gets removed or gets a documented exception with an expiry date.

6. Set up joint governance

Create a small group with authority from both sides: IT security, OT engineering, operations, and someone who owns vendor relationships. Give it the decisions that fall between the cracks: new connections, new remote access requests, shared accounts, cloud data flows. Meet regularly and keep a record. It sounds bureaucratic. It’s the thing that stops the next “temporary” connection from becoming permanent.

What I’d look for: Groups that work tend to be small, with a named chair and real authority to say no. At minimum: the OT security lead, a site operations or engineering manager, the IT network owner and whoever manages vendor contracts. The standing agenda is new connections and remote access requests, exceptions coming up for expiry, and shared-account reviews. If the group can’t approve or reject a new vendor connection on its own, it’s a discussion forum, not governance.

The short answer

IT/OT convergence is happening whether security signs off or not, because the business benefits are real. The risk isn’t the connection itself. It’s the access model that builds up around it: shared accounts that travel, vendor access that never expires, directory trust that turns an IT compromise into an OT one, and flat networks that were only safe while they were isolated.

If you’re early in it, start with an inventory of access paths, make the IDMZ the only way between the worlds, keep OT identity separate or tightly scoped, broker every remote session, and give IT and engineering a shared place to make decisions. More on identity in industrial environments lives in the OT security hub.