IT/OT Convergence

What convergence means

For decades, operational technology (OT) lived apart from the office network: its own cables, its own vendors, its own engineers. IT/OT convergence is the process by which the two worlds grow together, in two directions:

• Data flows out. Measurements, alarms and equipment status leave the plant to feed planning, maintenance, billing, energy trading, regulators and analytics in the cloud. A grid operator wants to know the loading of every transformer; a factory wants to know why one line produces more scrap than another.
• Technology flows in. Controllers speak Ethernet and TCP/IP, supervisory systems run on Windows and virtual machines, field devices connect over cellular networks, and engineering uses the same software tools as IT.

Both directions bring real benefits — better maintenance, less waste, faster fault-finding, fewer site visits — and both widen the attack surface. Much of the rest of this topic, from the Purdue model to remote access, is about managing that trade-off. This page looks at the technologies that drive it.

The Industrial Internet of Things

The Industrial Internet of Things (IIoT) is the use of networked sensors, devices and gateways in industry that send their data directly to central platforms, often in the cloud, instead of only through the traditional control hierarchy. Examples: wireless vibration sensors on pumps, temperature sensors in cable joints, smart meters, and condition monitors on transformers.

IIoT devices are cheap and numerous, which changes the security picture. They are often installed by maintenance contractors rather than control engineers, may use default passwords, are rarely patched and are easy to forget in an inventory. And they tend to talk directly to a cloud service, which skips the layers that the Purdue model assumes. Standards bodies are catching up: IEC PAS 62443-1-6:2025 describes how to apply IEC 62443 to IIoT, and the draft Revision 4 of NIST SP 800-82 (September 2026) adds IIoT and cloud convergence to the scope of the US government's OT security guide.

Edge computing

Edge computing in OT means processing data close to where it is produced — in the substation, on the factory floor, at the pumping station — on small industrial computers or gateways, instead of sending every raw measurement to a central data center or the cloud. This is a different idea from a cloud provider's edge location, which is a point of presence that brings cloud content closer to users.

Edge computing exists in OT for four reasons:

• Latency. Decisions that take milliseconds cannot wait for a round trip to a distant data center.
• Autonomy. The site keeps working when the wide area link or the cloud service is down.
• Bandwidth. A vibration sensor sampling thousands of times per second produces far more data than is worth sending; the edge sends features and alarms instead.
• Control of the boundary. One well-managed edge gateway that collects data from many devices and sends it out through one connection is easier to secure than many devices that each talk to the internet.

Edge devices are computers in exposed places, so they need the same care as servers: hardening, patching, secure boot where available, and central management. A compromised edge gateway sits right next to the controllers.

Cloud for OT data

The most common cloud use in OT is a copy of the historian: process data is replicated from the plant historian, through the industrial DMZ, to a cloud data platform, where analysts and engineers can work with years of data without touching the plant. Vendors also offer remote condition monitoring of their equipment as a cloud service.

Things get riskier when the cloud reaches back in. Cloud-connected controllers and cloud-hosted supervisory control are offered for small sites such as pumping stations, solar parks and building systems. They are convenient, but they create a path from the internet to the process, make control depend on internet and provider availability, and put part of your security in the hands of the provider. Questions to ask before connecting:

• Does data only flow out, or can anything flow back in? If only out, can that be enforced in hardware, for example with a data diode (see Industrial Networks)?
• Does the process stay safe and controllable when the cloud or the link is unavailable for a day?
• Who at the provider can reach your data or your devices, and how is that logged?
• Where is the data stored, and may it leave the country or region (for example the EU or the UK) under your contracts and regulators' expectations?

Joint guidance on secure connectivity for OT, published in January 2026 by the UK National Cyber Security Centre with partner agencies including NCSC-NL, gives principles that apply directly: limit exposure, centralize and standardize connections, use secure standard protocols, harden the OT boundary, limit the impact of a compromise, log and monitor all connectivity, and have an isolation plan.

Digital twins

A digital twin is a virtual model of a physical asset, process or network that is kept in step with the real thing by live data, so that people can simulate, predict and test without touching the real system. The model can be physics-based, data-driven or both.

Typical uses:

• What-if analysis. A grid operator's network model already answers questions such as "what happens if this line trips?"; a twin extends that to planning maintenance and new connections.
• Testing changes to control logic or settings before they reach the plant.
• Training operators on rare events, including incidents and manual operation.
• Condition monitoring, by comparing what the equipment does with what the model says it should do.

Two security points. A detailed twin is a blueprint of the plant and deserves the same protection as engineering drawings. And a twin that can write settings back to the real system is no longer just a model but part of the control path, with everything that implies for change control and access.

Private LTE and 5G

Field equipment spread over a large area — distribution substations, wind turbines, pumping stations, smart meters — needs communication where fiber is too expensive. Public mobile networks are one option, but they are shared with everyone and may be congested or down exactly when the grid has problems, for example during a power outage.

Private LTE is a cellular network built on Long Term Evolution (LTE, 4G) technology that is operated by or for one organization or sector, on dedicated spectrum, separate from the public mobile networks. The operator decides on coverage, priority, backup power and who may connect.

In the Netherlands, the license for part of the 450–470 MHz band went in April 2024 to Utility Connect, a joint venture of the distribution system operators Alliander and Stedin. The license runs until 2050 and requires at least 4G technology; it was awarded without an auction because the other applicant withdrew. The network is intended for smart meters and for measuring and controlling the grid. Low frequencies such as 450 MHz reach far and penetrate buildings well, which suits sparse, often underground or indoor equipment.

Private 5G plays a similar role in factories, ports and large industrial sites, where it can replace some wireless and wired links to moving or reconfigurable equipment. For security, a private cellular network is part of the OT network: its core, its SIM management and its connections to the rest of OT need the same zoning, monitoring and change control as any other conduit.

AI in OT

Two uses of AI are well established in OT, and both build on ordinary machine learning more than on large language models:

• Anomaly detection on process values and network traffic: learning what normal looks like and flagging what deviates (see anomaly detection and Asset Inventory and Monitoring).
• Predictive maintenance: estimating when equipment is likely to fail from trends in vibration, temperature, current or oil analysis, so that maintenance happens just before it is needed instead of on a fixed schedule or after a breakdown.

A simple predictive-maintenance signal

Real predictive maintenance uses richer models, but the core idea fits in a few lines: smooth the noisy daily readings with a moving average, raise a warning when the average crosses a threshold, and estimate from the trend how much time is left before the alarm level. The thresholds below are illustrative; real ones come from the manufacturer or the applicable standard for the machine type.

# Daily vibration readings of a cooling-water pump bearing (mm/s RMS).
readings = [2.1, 2.3, 2.0, 2.2, 2.4, 2.3, 2.6, 2.5, 2.9, 3.1,
            3.0, 3.4, 3.6, 3.5, 3.9, 4.2, 4.1, 4.6, 4.8, 5.1]

WINDOW = 5       # days in the moving average
WARNING = 4.0    # mm/s: plan maintenance (illustrative threshold)
ALARM = 7.0      # mm/s: the level at which the machine should not keep running

def moving_average(values, window):
    return [sum(values[i - window + 1:i + 1]) / window
            for i in range(window - 1, len(values))]

averages = moving_average(readings, WINDOW)
first_day = WINDOW  # the first average covers days 1-5

warned_on = None
for offset, avg in enumerate(averages):
    day = first_day + offset
    marker = ""
    if avg >= WARNING and warned_on is None:
        warned_on = day
        marker = "  <- crosses warning level"
    print(f"day {day:2}  avg {avg:.2f} mm/s{marker}")

# Trend: average rise per day over the last five averages.
recent = averages[-5:]
slope = (recent[-1] - recent[0]) / (len(recent) - 1)
days_left = (ALARM - averages[-1]) / slope
print(f"trend: +{slope:.2f} mm/s per day")
print(f"warning since day {warned_on}; alarm level in about {days_left:.0f} days")

day  5  avg 2.20 mm/s
day  6  avg 2.24 mm/s
day  7  avg 2.30 mm/s
day  8  avg 2.40 mm/s
day  9  avg 2.54 mm/s
day 10  avg 2.68 mm/s
day 11  avg 2.82 mm/s
day 12  avg 2.98 mm/s
day 13  avg 3.20 mm/s
day 14  avg 3.32 mm/s
day 15  avg 3.48 mm/s
day 16  avg 3.72 mm/s
day 17  avg 3.86 mm/s
day 18  avg 4.06 mm/s  <- crosses warning level
day 19  avg 4.32 mm/s
day 20  avg 4.56 mm/s
trend: +0.21 mm/s per day
warning since day 18; alarm level in about 12 days

The moving average hides single noisy readings (day 16's 4.2 does not trigger anything on its own) at the cost of reacting a few days later. The "12 days" is a straight-line guess: bearing damage often accelerates, so the estimate is a reason to plan maintenance soon, not a promise. The output is advice for a maintenance planner; the pump's own protection still trips it if vibration becomes dangerous.

Risks of AI in OT

• Wrong answers have physical effects. A model that misses a failure or raises false alarms costs money and trust; a model allowed to change setpoints can cause damage. Keep AI advisory, with a person deciding, unless a change has been engineered and approved like any other control function — and never let it bypass safety systems (see Safety and Reliability).
• Training data from a changing plant. After a modification, a new operating mode or a season change, "normal" looks different and the model must be checked again.
• A new attack surface. Models and their data pipelines can be poisoned or manipulated, and AI platforms add new connections out of OT (see AI Security).
• Generative AI and sensitive data. Pasting control logic, network diagrams or incident details into a public chatbot shares them with a third party. Use only tools your organization has approved.

Bringing IT and OT teams together

The hardest part of convergence is people. IT teams are used to frequent changes, quick patching and replacing hardware every few years. OT teams are used to stability, long testing, equipment that runs for decades and the rule that a working process is not touched without a good reason. Both are right for their world, and each tends to see the other as careless or slow.

What helps in practice:

• Shared vocabulary and site visits. IT staff who have stood in a substation or control room, and OT engineers who have seen a security operations center at work, make better decisions together.
• A shared security operations center with OT knowledge in it, rather than a separate OT team nobody else knows about (see the SOC). OT alerts need analysts who know what a strange IEC 60870-5-104 command means and whom to call in the control room.
• One change process with OT approval. Changes to the IT/OT boundary, the DMZ or shared infrastructure go through change enablement with an OT authority who can say no, and maintenance windows that operations plans.
• One asset and configuration picture. A shared inventory (see configuration and asset management), and network configurations kept under version control (see network automation with Git).
• Joint incident playbooks and exercises, so the first time IT security and the control room work together is not during a real incident (see Incident Response in OT).

What stays different

Convergence brings IT tools and methods into OT; it does not turn OT into IT. Some things do not change:

• Physics. A grid must balance generation and demand every second; a pressure vessel has a limit. Software cannot negotiate with either.
• Safety first. Availability and integrity of the process, and the safety of people, come before confidentiality (see OT Security Fundamentals).
• Real time and determinism. Protection and control need answers within milliseconds, every time.
• Long lifecycles. Equipment installed today will still run when today's cloud services have been renamed twice.
• Consequences. An outage of an IT service is measured in lost hours and money; an OT failure can be measured in damaged equipment, environmental harm or injury.

A good test for any convergence project: if the cloud, the corporate network and the AI model all disappeared tomorrow, would the process still be safe and controllable? If the answer is yes, the convergence was designed well.