What Is OT Security? An Identity-First Primer

OT security is the practice of protecting operational technology: the control systems, controllers and networks that run physical processes like power generation, water treatment, manufacturing lines and hospital building systems. Its first job is keeping those processes safe and available, which is why it can’t simply borrow the IT security playbook.

I came to OT from the identity side, and the lesson that keeps repeating is this one: the identity playbook that works in IT tends to fall apart below Purdue Level 3. Not because identity matters less down there. It matters more. It just has to be done differently, by people who understand that a control system outage is a safety event, not a ticket.

This primer covers what operational technology security actually is, how it differs from IT security, the terms you’ll hear, and why I think identity and access is the most practical place to start.

What is operational technology (OT)?

Operational technology is hardware and software that monitors or controls physical equipment. If IT moves data, OT moves things: valves, breakers, pumps, conveyors, robots, chillers, infusion systems.

You’ll hear a cluster of overlapping terms. Here’s how I keep them straight:

Term	What it means in practice
OT	The umbrella term for any technology that controls physical processes
ICS (industrial control system)	The control systems themselves, usually used interchangeably with OT in conversation
SCADA	Supervisory control and data acquisition: monitoring and control spread across a wide area, like a pipeline or an electric grid
DCS (distributed control system)	Process control within a single site, like a refinery or chemical plant
PLC	Programmable logic controller: the ruggedized computer that actually runs the logic on the plant floor
HMI	Human-machine interface: the screen an operator uses to watch and drive the process
SIS (safety instrumented system)	An independent system whose job is to bring the process to a safe state when something goes wrong
IIoT	Industrial IoT: newer connected sensors and devices, often talking to cloud services

So “ICS security” and “OT cybersecurity” are, for most purposes, the same conversation as OT security. The vocabulary shifts by industry. Utilities say SCADA, manufacturers say ICS or OT, and healthcare tends to say medical devices and building management systems. The underlying problem is the same.

OT security vs. IT security: what’s actually different

The short version: IT protects information, OT protects people and processes. That changes the priorities, the constraints and the tools.

	IT security	OT security
Top priority	Confidentiality of data	Safety, then availability and integrity of the process
Cost of downtime	Lost productivity, lost revenue	Possible physical damage, environmental harm, injury
Asset lifespan	3–5 years	Often 15–25 years or more
Patching	Monthly, often automated	Planned outages, vendor approval, sometimes never
Endpoint agents	Standard	Often unsupported or prohibited by the vendor
Protocols	Mostly authenticated and encrypted	Many legacy protocols (Modbus, older DNP3) with no authentication at all
Who has access	Employees, mostly through SSO	Operators, engineers, integrators and OEM vendors, often through shared accounts

A few of those rows deserve more than a table cell.

Availability isn’t a preference, it’s a safety property. In IT, if a server reboots to apply a patch, someone gets an annoying email. In OT, if an HMI reboots in the middle of a batch, an operator may lose visibility of a process that’s still running. Every control you add has to answer the question “what happens if this fails closed?”

The equipment outlives the people who installed it. Controllers commissioned decades ago are still running, sometimes on operating systems the vendor stopped supporting long ago. The vendor’s support contract may be the thing preventing you from installing anything on them at all.

Change is expensive and slow, on purpose. Plants run management-of-change processes for good reasons. A security control that needs weekly tuning will not survive contact with that process.

A common version of this: Picture a corporate policy that locks an account after five failed logins, pushed by group policy to a shared HMI account. A tired operator mistypes during an alarm and the console locks with the process still running. The usual resolution is to exempt operator consoles from lockout, alert on failed attempts instead, and keep lockout on remote access and engineering logins, where a locked account costs time rather than visibility.

Why identity is the place to start in OT security

When people picture OT attacks, they picture exotic malware written for a specific controller. Those exist. TRITON (also called TRISIS) went after a safety instrumented system in 2017, and it’s rightly a case study everywhere. But many of the incidents that actually reached control systems started in a much more ordinary way: somebody logged in.

The 2015 attack on Ukrainian power distribution companies is the textbook example. The attackers harvested credentials on the IT side, moved through VPN and remote access paths, and operated the utilities’ own SCADA tools to open breakers. Colonial Pipeline in 2021 was an IT-side ransomware incident, widely reported to have started with a compromised VPN account that didn’t have MFA, and the company shut down pipeline operations as a precaution. Different stories, same lesson: access paths are attack paths.

That’s why I’d start an OT security program with identity and access. In practice that means answering a few uncomfortable questions:

• Who can reach the control network at all? Including the integrator who set up a remote access tool five years ago and never took it out.
• Which accounts are shared? Operator logins on HMIs, engineering accounts on workstations, the vendor’s default credentials on a controller.
• What non-human identities exist? Service accounts on historians, OPC servers talking to each other, scripts with embedded passwords, certificates nobody has inventoried.
• How does a vendor get in when something breaks at 2 a.m.? And who approves it, watches it and ends it?

If you can’t answer those, network segmentation and threat detection will still help, but you’ll be defending a building where you don’t know who has keys.

This is the same principle behind the identity pillar of Zero Trust, adapted for an environment where you can’t always verify explicitly at every device. Where the device can’t do it, the access path has to.

What identity looks like on the plant floor

Here’s where the IT instincts need adjusting. A few patterns I see work, and a few I see fail.

Separate OT identity from IT identity

Joining OT systems to the corporate Active Directory domain is convenient, and it means a compromised IT domain is a compromised plant. The more common and defensible pattern is a dedicated OT directory (often its own AD forest) in the site operations layer, with no trust relationship to IT, or a tightly controlled one. People who need both get two identities. Yes, that’s friction. It’s friction that buys you a firebreak.

Put strong authentication at the boundary, not at every device

MFA prompts on a shared HMI in a control room are a bad idea. An operator responding to an alarm shouldn’t be waiting for a push notification, and lockouts after failed attempts can lock the wrong person out at the worst moment. Instead, enforce MFA where people cross into the OT environment: the remote access gateway, the jump host, the engineering workstation login. Inside the control room, lean on physical security, role-based HMI accounts and good logging.

Treat vendor and engineer remote access as privileged access

Most OT environments have more third-party access than anyone thinks. OEMs, integrators, maintenance contractors, each with their own preferred remote tool. This is a privileged access management problem, and the controls are familiar: brokered sessions through a single path, credentials injected rather than handed over, approvals tied to a work order, session recording, and access that expires when the job does.

Where it tends to go wrong: The typical pattern is a remote desktop tool an integrator installed during commissioning, set to unattended access with a password their whole support desk knows, and never removed. Nobody on site thinks of it as a connection because it dials out. Cleaning it up usually means finding it with passive monitoring, moving that vendor onto the brokered path, and uninstalling the tool with the vendor on the phone so the next support call doesn’t quietly reinstall it.

Don’t forget the non-human identities

Historians, OPC servers, data diodes, patch servers and integration accounts that feed OT data up to the business all authenticate somehow. Often with a service account whose password hasn’t changed since commissioning, because nobody’s sure what breaks if it does. Inventory them, tie each one to an owner, and rotate where the vendor supports it. Where they don’t, compensate with tighter network rules and monitoring.

Segment around identity, not just around subnets

Segmentation is the other half of this. Zones and conduits (the IEC 62443 language for grouping assets by risk and controlling the paths between them) only work if you also control who and what is allowed through each conduit. A firewall rule that allows RDP from “the engineering VLAN” is an identity decision made by an IP address.

OT cybersecurity standards and frameworks to know

You don’t need to memorize these, but you’ll keep running into them:

• ISA/IEC 62443: the series of standards for industrial automation and control system security, covering asset owners, integrators and product suppliers. It’s the closest thing OT has to a common language, and its first foundational requirement is identification and authentication control. Developed by the ISA99 committee and published through the IEC.
• NIST SP 800-82: NIST’s guide to operational technology security. A good, free, readable starting point, available from NIST.
• NERC CIP: mandatory reliability standards for the North American bulk electric system, with specific requirements for access management, interactive remote access and account management. See NERC.
• UK NIS Regulations and the NCSC Cyber Assessment Framework (CAF): the UK’s regime for operators of essential services, with the CAF as the outcome-based framework regulators use to assess them.
• NIS2: the EU directive that broadened the sectors and organizations covered by cybersecurity obligations.
• CISA guidance: CISA publishes ICS advisories and practical guidance for critical infrastructure operators in the US.

In practice: NIST SP 800-82 and IEC 62443 are the two most teams actually keep open: 800-82 for the plain-language explanation, 62443 for the requirements and the zones-and-conduits vocabulary. Regulated operators prioritize whatever their regulator audits, whether that’s NERC CIP, the CAF or national NIS2 rules. In an assessment I’d structure findings against 62443 and map them to the regulatory framework, so one set of evidence serves both.

Common OT security mistakes I’d avoid

A few patterns show up often enough to call out:

1. Running an IT vulnerability scanner against the control network. Active scans have knocked over fragile controllers. Use passive discovery first, and talk to operations before anything touches a production network.
2. Assuming the air gap is real. Ask about the vendor’s cellular modem, the USB drive used for updates, and the “temporary” remote access tool. The gap usually has a door in it.
3. Copying IT account policies verbatim. Aggressive lockout, forced password changes mid-shift and session timeouts on operator consoles can create safety problems. Adapt the intent, not the setting.
4. Leaving shared accounts unaccounted for. Some shared accounts are operationally necessary. Fine. Know which ones exist, who uses them, and pair them with physical controls and logging so you can reconstruct who was at the console.
5. Treating OT security as an IT project. If operations and engineering aren’t in the room, the controls won’t survive the first outage. They know the process, and they’re the ones who will be called at 2 a.m.

Insider threats deserve a mention here too. In OT, the line between an insider and a trusted third party is blurry, and a well-meaning engineer with too much standing access can cause as much harm as a malicious one.

The short answer

OT security is about keeping physical processes safe and running, and that’s a different job from protecting data. The controls look familiar, but the order of priorities changes, and so does the cost of getting it wrong.

If I were starting an OT security program tomorrow, I’d start with access. Map every path into the control network, especially vendor and remote paths. Separate OT identity from IT identity. Put strong authentication and session control at the boundary rather than on the HMI. Then inventory the shared and non-human accounts nobody wants to talk about. It’s not the most exciting part of OT security, but it’s the part attackers keep using.

For more on this area, the OT security hub collects everything I write about identity in critical infrastructure, and what is identity and access management covers the IT-side fundamentals this builds on.