The three kinds of problem that stop an OT/IT convergence programme

Convergence programmes rarely fail at the firewall. They fail at the organisation chart first, then at the equipment, then at the compliance review, roughly in that order and roughly in that order of difficulty.

This is part 2 of 9 of the “OT/IT convergence” series; it follows part 1, the air gap and continues with part 3, the implementation steps.

Part one: people and organisation

Governance. Bringing IT and OT together needs clear governance: who is responsible for what, through which processes, with explicit rules for data management, for security and for how the two teams work together. Without it, the first serious incident turns into an argument about jurisdiction, held while the line is down.

Two cultures, and blurred boundaries. IT and OT grew up separately, each with its own habits and methods. Convergence creates areas of overlap and real uncertainty about who owns what. Declaring one culture right gets nowhere; the work is to build mutual understanding and a shared culture that values what each side does well. An IT department that sees OT as badly run IT will make no progress, and neither will an OT team that sees IT as the obstacle between it and production.

Merging the expertise is harder than it sounds. Each side holds specialised skills, and working towards shared objectives requires some technical understanding in both directions, at a time when the two groups do not even define success the same way. Ask IT what a good week looks like and you hear “no incidents, all patches deployed”. Ask the production manager and you hear “we hit the plan”.

Skills. People who are comfortable in both worlds are hard to find, and demand for them keeps rising. In most organisations the realistic route is to train existing teams into hybrid profiles rather than hope to recruit them ready-made.

Group versus site. Convergence means managing resources and capabilities across several levels of the organisation. Decisions taken at group level have to be weighed against the reality of each site, which takes good communication and planning that respects local specifics while staying aligned with the corporate strategy. That balance is easy to describe and hard to hold, because group standardisation and site reality naturally pull in opposite directions.

Part two: technology

Networks that do not fit together. OT protocols are not always compatible with conventional IT networking. The interoperability gaps are bridged with gateways, protocol converters and industrial switches, and each one is another component to secure, patch and eventually replace.

Equipment limits. Industrial PCs, HMIs and PLCs are built for specific tasks and often have tight limits on processing power, memory and storage. Resource-hungry IT software runs into those limits quickly. An endpoint agent nobody notices on a corporate laptop can freeze an operator station in the middle of a batch.

Security tools built for IT. Endpoint protection platforms and intrusion detection systems designed for offices can misread OT software and traffic. In active mode they raise false positives or miss real threats, and they can end up harming the availability of the very systems they were installed to protect. Running them passively is not a compromise. For most of the industrial estate it is simply the right design.

Updates and patches. OT values stability and availability, so the frequent update cycles of IT do not transfer directly. Applying an update without first assessing its impact on the process is a real risk of unplanned downtime. The answer is a patch process with a qualification step in it, slower than in IT, and something to plan for rather than resent. “Never patch” is not an option either.

### Centralised user management, and why it usually ends in two domains

Connecting OT systems to the corporate Active Directory to centralise accounts and strengthen authentication is genuinely useful. It is also often difficult or impossible, for reasons that come up on almost every site. Password policies may be impossible for OT systems to meet, or may break unattended operation. Group policies written for office PCs do not suit industrial workstations. Old OT firmware cannot support current authentication methods. And some applications run on service accounts that predate any idea of central identity.

Some organisations have tried hybrid set-ups that replicate users between an IT domain and an OT domain. They bring their own problems, and those tend to surface at the worst possible moment. What we now see most often on site is two separate domains, one for OT and one for IT, with a controlled trust between them rather than a shared directory. It is the pragmatic answer, and it should be chosen deliberately as an architecture, not arrived at by default after a failed integration.

Part three: priorities and compliance

The priorities really are different. In IT, the priority is protecting data and keeping systems maintained. In OT, it is continuity of operation and reliability of the process. This is the well-known inversion of the confidentiality, integrity and availability triad, and it comes down to what a failure costs.

Lose availability on an industrial control system and the consequences go beyond lost revenue from the stoppage. Operators can be put at risk when control of the equipment is lost, and a failure in the control of a chemical process can become an environmental incident. That is the whole argument for treating OT availability as a safety parameter: a corporate IT outage costs money, while an OT outage can hurt someone.

Overlapping regulation. IT and OT regulation intersect in places, and the overlap creates friction. Data security requirements written for IT end up applied to OT systems that were never designed with them in mind.

Unclear boundaries. Where IT rules stop and OT rules start is often unclear, which makes a coherent compliance policy hard to build. Two teams reading two frameworks can reach two defensible and incompatible conclusions.

Too few people who can arbitrate. Few specialists understand the regulatory requirements of both domains well enough to settle those disagreements.

OT rules that age. Some OT systems are governed by standards that evolve slowly while the technology and the threats move fast. The organisation is left to manage the gap between what the standard asks and what the threat environment demands.

Across all three categories the pattern is the same. The technical problems have known solutions that cost money. The organisational ones have no solution you can buy, and that is why they decide the outcome.

Next: what a structured implementation looks like, and the eleven steps identified by Cigref, the French association of large-company IT directors, in its working group on IT/OT convergence.