IT OT Convergence: What Breaks and Who Owns the Fix

IT OT convergence is the thing your manufacturing clients have already done without ever deciding to do it. Ask whether the plant network is air gapped and most of them will tell you yes. Then you find the cellular modem in the panel. The historian replicating to a cloud analytics platform. The OEM support tunnel that shipped with the machine.

Nobody approved it as a project. It accumulated.

The hard part isn't the firewall. It's that the plant engineer and your IT team are measured on opposite outcomes, and neither of them is wrong. MSP Pentesting tests that boundary channel only, under your brand. The report carries your logo, and you stay the only vendor your client deals with.

Solve that and the technical work gets easy.

Convergence isn't a decision, it's an accumulation

No client ever schedules IT/OT convergence. They approve six sensible things over four years, and you're the one who inherits the result.

• A cloud historian, so the business can see production data without walking to the floor.
• MES or ERP integration, so orders and output reconcile without a spreadsheet.
• Remote support from the equipment OEM, written into the maintenance contract years before you met the client.
• Predictive maintenance sensors, often shipped with their own cellular connection.
• Remote engineering access, because the person who understands that line lives three states away.
• An acquisition, after which corporate IT inherits a plant nobody documented.

Each one is defensible on its own. Stacked, they turn an assumed air gap into a story people tell each other. If a site describes itself as air gapped, there's usually a cellular modem, a USB update workflow and a contractor laptop that say otherwise.

What breaks when the networks merge

The DMZ that's really a router

The Purdue reference model puts a DMZ at Level 3.5, between site operations and the enterprise. Most plants have one. Fewer have one that does anything, because every project that needed data added a permit rule and nobody ever took one away.

Open a converged client's firewall config and count the any to any rules. Then count the rules with a ticket number attached.

That gap is your boundary.

One identity plane for two different worlds

Convergence usually means the plant joins the corporate domain. Now a compromise of corporate Active Directory is a compromise of the HMIs. Domain admin reaches the engineering workstation, the engineering workstation reaches the controllers, and the controllers don't authenticate anything at all.

Then add the details nobody ever cleans up. Shared operator logins, because people are wearing gloves. Service accounts in the SCADA application with passwords set at commissioning. No MFA on the jump host, because it broke a vendor tool once in 2021.

Protocols that assume a closed network

Modbus TCP, DNP3 without its secure authentication option, EtherNet/IP and PROFINET were built for a wire where everyone present was trusted. There's no authentication in the base protocol. Anyone with a route and a socket can write a value.

That was a reasonable design when the network was physically separate. Convergence removes the separation and leaves the assumption sitting there.

Remote access nobody owns

Every OEM has its own remote support method, and it usually arrived with the machine. A cellular modem in the panel, a vendor VPN client, a remote desktop tool a technician installed years ago. The maintenance contract requires it. Your client's IT team hasn't seen most of them.

It's the most common way into a converged environment. It's also the easiest thing on this list to fix.

Start there.

Security tools that break production

An active scan can fault a PLC. That isn't folklore, it's why NIST SP 800-82 leans on passive techniques for the process network. Endpoint agents are frequently unsupported on HMI images, and installing one anyway can void vendor support. Automatic patching during a batch run costs a shift of product.

The IT playbook isn't wrong. It was written for equipment you're allowed to reboot.

The cultural clash, stated honestly

IT thinks the plant is careless. Engineering thinks IT is reckless. Both sides have receipts.

The controls engineer is accountable for safety and uptime. A wrong move hurts somebody or scraps a run, and there's a formal management of change process built specifically to stop people doing clever things quickly. Your IT admin is accountable for patch compliance, ticket response and keeping the company out of the news. Speed is a virtue on one side and a hazard on the other.

Here's the whole disagreement in one table. Nearly every argument you'll referee between those two teams is a row in it.

Read it as a negotiation, not a scoreboard. Show up telling engineers their twenty year old DCS is unacceptable and you'll get politely ignored for the rest of the contract.

The architecture both sides can sign

Skip the greenfield reference diagram. Here's the set of changes that gets accepted in a real plant, roughly in the order they get accepted.

• Define zones by consequence. IEC 62443-3-2 asks you to group assets into zones based on the impact of a compromise, then define the conduits between them. Do that before you touch a VLAN. A zone drawn around a process is defensible to an engineer. A VLAN isn't.
• Make Level 3.5 real. No direct traffic from the enterprise to the control layer. Replicate the historian into the DMZ and let the business read the copy. No dual homed hosts, and that includes the engineer's laptop.
• Split identity. Separate the OT administrative tier from the corporate one. Different accounts, different credentials, MFA at the jump host. If corporate AD falls, reaching the plant should still cost an attacker a second compromise.
• Broker every remote path. One way in, through a jump host, time boxed, approved by the plant, session recorded. Then go find the modems and pull them. This one change closes more risk than most of the rest combined.
• Monitor passively. A tap or span port with protocol aware analysis gives you an inventory and a traffic baseline without sending a single packet at a controller.
• Back up the controllers. Program logic, configurations, and the version of the engineering software that will still open them. Then test a restore. Plenty of sites can rebuild a server and not a production line.

One governance rule holds it together. Every conduit gets a named owner, a written purpose and a review date. Rules without those three things are how the boundary rotted the first time.

The organizational fix, which is the real work

Architecture is the easy half. This part decides whether any of it survives the next project.

• Name who owns the boundary. One person owns the firewall between site operations and the enterprise. If IT and engineering both own it, nobody does, and rules get added by whoever's in a hurry.
• Run security changes through management of change. Don't build a parallel process. Engineering already has one, it's auditable, and using it buys you credibility you can't get any other way.
• Give each side a veto in its own domain. Engineering vetoes anything that raises process risk. IT vetoes anything that adds an unmanaged path to the outside. Written down, that ends most arguments before they start.
• Decide the 2 a.m. answer now. If the HMIs get encrypted overnight, who declares the incident, who's allowed to authorize a controlled shutdown, and who calls the OEM. Run it as a tabletop once a year with both teams in the room.
• Learn what an outage costs. Before you recommend a patch, find out what a maintenance window costs at that site. Engineers start listening the moment they hear you understand the constraint.

Your role here is narrow, and that's what makes it sellable. You own the boundary and the identity path across it. You don't own the process. Say that out loud in the first meeting and the controls team stops treating you as a threat to their uptime.

Testing a converged environment without stopping production

The instinct is to leave OT untested because it's fragile. That leaves the most consequential part of your client's business unexamined, and it isn't necessary.

Test the boundary, not the controllers. The questions worth answering are boring, and every one of them is answerable.

Can a phished office user reach the DMZ. Can a DMZ host reach Level 2. Does the vendor remote path bypass the jump host. Does corporate domain admin turn into control of an HMI.

That's an assume breach exercise starting on the enterprise side, running against IT systems.

For the deeper layers, use configuration review and passive capture instead of active tools. Save active testing for a lab or an approved outage with the OEM in the room. Define the zones and their consequences first, which is what a proper risk assessment produces, then test the ones that matter.

Most MSPs have no OT tester on staff and don't need one. Deliver it through white labeled pentesting so the report carries your logo and your client keeps seeing one provider.

Frequently asked questions

What is IT OT convergence?

It's the merging of operational technology networks, the systems that run physical processes, with corporate IT and cloud services. It happens gradually through data integration and remote support rather than as a planned migration, which is why the security model rarely keeps up.

Is an air gap still a realistic control?

Rarely, and usually not the one people think they have. Between vendor modems, USB based updates and contractor laptops, most air gaps have holes nobody wrote down. A defended and monitored boundary is more honest, and it's far easier to maintain than an air gap that only exists on a diagram.

Who should own OT security, IT or engineering?

Split it by domain. IT owns the boundary, identity and monitoring. Engineering owns process risk and signs off on any change touching the control layer. Put it in writing with names attached, because shared ownership without named roles is the same as no ownership.

Is penetration testing safe in a converged OT environment?

With the right scope, yes. Focus on the enterprise side, the DMZ, identity and the remote access paths, all of which behave like normal IT. Keep active techniques away from controllers unless you're in a lab or an approved outage window. Scope and rules of engagement do the safety work here, not luck.

The short version

IT OT convergence already happened at most of your manufacturing clients. It arrived one approved integration at a time, and the security model never caught up.

What breaks is predictable. A boundary that permits too much. One identity plane covering two different worlds. Protocols that trust anything on the wire. Remote access that belongs to somebody else.

Half architecture, half diplomacy.

Draw the zones, make the DMZ real, broker the remote paths, and get the ownership split written down before an incident settles it for you.

If you want to know how far a compromised office account gets toward the plant floor, that's a scoped test rather than a guess. Get a pentest quote and find out before somebody else does.