What is the difference between IT and OT cybersecurity?

IT cybersecurity protects information systems such as email, finance and booking platforms, where the main concerns are usually the confidentiality and integrity of data. OT cybersecurity protects operational technology: the controllers, sensors and supervisory software that run physical equipment such as air handling, lighting, lifts and door access. In OT, the first concern is that the equipment keeps operating safely and predictably.

The two disciplines share many techniques, which is precisely what makes the difference dangerous to ignore. Office IT practice applied to building plant without adjustment can cause the very outage it was meant to prevent. The sensible response is to agree in writing who does what across the boundary, before an incident forces the question.

How the two environments differ

NIST's guide to OT security, SP 800-82, sets out how OT differs from conventional IT. The table summarises the points that most often matter in buildings.

NIST adds two points that should shape every decision. Security measures must not impair safety. And some third-party security software cannot be installed on OT systems without the vendor's agreement, because doing so can affect support.

Four places the difference bites

Scanning and testing

Active network scanning is routine in IT. NIST cautions that the indiscriminate use of IT security practices in OT can disrupt availability and timing, particularly on resource-constrained devices. That is not an argument against assessing OT. It means agreeing the method, timing and scope with the controls engineer, testing on a sample first, and scheduling the work for a time when the plant can tolerate a problem.

Patching

The IT default is to patch quickly. In building OT, an update may change how a controller behaves or require re-commissioning, and NIST notes that OT owners often need to plan outages days or weeks ahead. The aim is still to keep systems supported; only the route differs. Each update is assessed, tested where possible and scheduled, and compensating measures are recorded when an update has to wait.

Accounts and authentication

IT identity systems can usually enforce strong authentication everywhere. Many building controllers cannot. A realistic design concentrates strong authentication at the points of entry, such as remote-access gateways and engineering workstations, and uses network segmentation to limit what an attacker could reach from a weak device.

Incident response

An IT response plan might isolate an infected laptop immediately. Isolating a building controller can stop the plant it runs. OT response plans therefore need operational input on which systems can be disconnected safely, what local or manual operation looks like, and who has the authority to decide.

What does not change

None of this exempts OT from good practice. The differences are about priorities and methods. Both environments need an asset inventory, controlled access, supported software, monitoring, backups and tested recovery, and the NIST Cybersecurity Framework 2.0 applies to both. Its Govern, Identify, Protect, Detect, Respond and Recover functions give the board, the IT team and the facilities team a common language.

The ISA/IEC 62443 series, developed specifically for industrial automation and control systems, explicitly includes building automation in its scope. It treats security as a responsibility shared between asset owners, product suppliers, integrators and service providers, which makes it a useful reference when deciding which party owns which part of the work.

Drawing the line between the teams

A building owner may well have an IT team that understands security and a facilities team or contractor that understands the plant. Neither can secure building OT alone. A short responsibility matrix settles the questions that otherwise fall between them:

NIST recommends a cross-functional team that includes IT staff, a control engineer, a system operator, a security specialist, management and physical security, with the control system vendor or integrator consulted. In a building, several of those roles may fall to the same few people, and the team may meet only monthly. What matters is that it exists and has authority.

Shared cables, shared consequences

New buildings often run their building systems over the same physical network infrastructure as IT, separated logically. That can be sensible and economical. It also means a configuration error made for IT reasons can affect plant. If the infrastructure converges, the change process should converge with it, so that a firewall rule or switch update touching a building zone is reviewed by someone who understands the consequences.