An experienced IT security team turned loose on a control network with their usual toolkit can cause an outage before lunch. The methods are sound; the assumptions behind them do not hold. Understanding which assumptions break is what separates a useful OT assessment from a dangerous one.
The Priorities Are Inverted
IT security is generally taught confidentiality first, then integrity, then availability. In an operational environment the order reverses. A process that stops has immediate physical and financial consequences — and in some settings, safety consequences. A control that improves confidentiality at any risk to availability will be rejected by the plant, correctly.
Active Scanning Can Take Devices Down
Many controllers and field devices have small network stacks that were never designed to tolerate aggressive probing. A standard port scan can be enough to make one stop responding. This is not hypothetical — it is the reason OT assessments lean on passive traffic monitoring, configuration review and interviews, and treat any active testing as something scheduled, agreed, and ideally performed on a maintenance window or a test bench.
Patching Is Governed by the Vendor and the Calendar
“Patch promptly” assumes you may patch. In OT, applying an update can void a vendor support agreement or invalidate a validated configuration, and the only opportunity to touch the system may be an annual shutdown. Recommendations that ignore this get filed and forgotten. Realistic OT findings prioritize compensating controls — segmentation, access restriction, monitoring — for the long stretches when patching is not available.
The Equipment Outlives the Software Support
Industrial assets are bought on twenty- and thirty-year horizons. Operating systems and controller firmware reach end of support long before the equipment reaches end of life, and replacement is a capital project rather than a maintenance task. “Upgrade it” is not a finding; it is a budget cycle.
What a Good OT Assessment Actually Produces
- An accurate asset inventory. Most sites do not have one, and nothing else can be prioritized without it.
- A real network picture — including the connections nobody documented: a vendor modem, an engineering laptop that moves between networks, a temporary link that became permanent.
- Segmentation findings. Whether the boundary between business and control networks is what people believe it is, and what actually traverses it.
- Remote access review. Vendor and contractor access is one of the most common serious findings, and one of the most fixable.
- Recommendations that survive contact with operations — sequenced, costed, and compatible with the shutdown calendar.
Bring Operations With You
The plant engineers know things no scan will reveal: which device is unreliable, which link was temporary three years ago, which cabinet has a laptop permanently plugged in. Assessments run without them find less and are trusted less. The people who will implement the recommendations should be in the room when they are formed.
The Short Version
OT security is not IT security with different acronyms. Availability comes first, active testing is a scheduled and negotiated activity rather than a default, and any recommendation that ignores the patch and shutdown reality will not be implemented. Assessments are performed only on systems whose owner has authorized the work in writing.
Related service: OT and ICS security assessment
The Protocols Have No Way to Say No
The reason a scan can knock a controller offline and the reason a stolen password is not the central threat are the same reason: the protocols carrying process data were designed for a wire nobody else could reach. A Modbus/TCP request carries a unit identifier, a function code and a register address, and nothing else. There is no authentication field, no session, and no concept of a caller with rights. A frame carrying function code 6, write single register, is a valid instruction to change a setpoint, and the device executes it because the frame arrived, not because anyone proved a right to send it.
That changes what a control can even be. Least privilege, multi-factor authentication, credential rotation and conditional access all attach to an authenticated principal. Where the protocol has no principal, the only enforceable boundary is reachability: what is able to send a frame to that port at all. This is why segmentation carries so much of the weight in OT and comparatively less on an office network where identity does most of the work, and why a finding that reads "enforce least privilege on the PLC" cannot be implemented, because there is no privilege model inside the device to enforce.
It also changes what monitoring is worth. Alerting on failed logons gives nothing where there are no logons; the useful signal is semantic, meaning which function codes are used, against which register ranges, from which source, and whether a write appeared on a link that has only ever carried reads. A baseline of who talks to whom, using which function codes, at what interval, stays stable because polling is cyclic and the set of talkers is close to fixed. Several protocols still in daily service carry no identity at all in their base specification, and the security options added later are version dependent or missing from installed firmware:
- Modbus/TCP, TCP port 502. The application data unit is a unit identifier, a function code and data. No authentication field exists in the specification and none was retrofitted into it.
- DNP3, TCP and UDP port 20000. Secure Authentication was standardized in IEEE 1815-2012, but it is an option, it is off in most installations, and it requires key management that the site has to operate.
- EtherNet/IP with CIP, TCP 44818 for explicit messaging and UDP 2222 for implicit I/O. CIP Security is a later addition that depends on device firmware; older adapters, drives and I/O blocks cannot be updated to it.
- BACnet/IP, UDP 47808. The base protocol has no authentication. BACnet/SC was added by addendum and needs a hub and certificates, which makes it a design change rather than a setting.
- SNMP v1 and v2c, UDP 161. The community string travels in cleartext and is the entire access control mechanism. Version 3 adds user-based authentication and privacy, but it has to be configured device by device.
The Tools Assume a Managed Endpoint
Most of the IT security stack presumes an endpoint you can install software on, join to a directory, patch on a schedule and reimage when it misbehaves. In a control environment that presumption fails in three distinct ways, and they call for different answers. Controllers, drives and field devices are not endpoints at all: they run firmware with no path for third-party code, so nothing can be installed on them by anyone. HMIs and panel PCs are computers, but they are usually sized for exactly one application, and an agent that competes for CPU and disk I/O with the runtime shows up as a stalled graphic in front of an operator. Engineering workstations are the closest thing to a normal machine, and they are also where the project files and the vendor software licenses live, which makes them the highest-value target on the network and the one most worth treating with IT rigor.
Network access control runs into the same wall from a different side. A PLC has no 802.1X supplicant, so the fallback is MAC authentication bypass, which means access control reduces to a MAC address that anyone with a capture can read and reproduce. The failure mode matters more than the weakness: an enforcing NAC that drops an unrecognized device into a quarantine VLAN removes that device from the process, so the control designed to contain an intruder is also a mechanism for causing an outage during a routine spare swap. Enforcement is often left off for that reason and the same deployment is used as an inventory source instead, which is a smaller claim than the product makes but a true one.
There is a usable test for whether an IT tool belongs in the control network. Ask whether it requires code running on the asset, whether it requires the asset to initiate anything, and what it does when it fails. Reading a switch's MAC address table, pulling a firewall rule set, or parsing a controller backup touches nothing in the process path and can be done at any time. A tool that installs an agent, or that sits inline and can fail closed, belongs in a conversation with operations and the system vendor before it belongs in a proposal.
Zones Are Drawn Around Flows, Not Around Diagrams
The Purdue reference model gives levels 0 through 3 with a DMZ between the control network and the business network, and IEC 62443-3-2 turns that into zones and conduits: a zone is a set of assets sharing a security requirement, and a conduit is the defined communication path between zones, which is where the controls actually go. The model is sound. What breaks is that a zone boundary is only meaningful if every flow crossing it is known, and the first firewall rule set at most sites is written from a drawing that predates several of the flows.
The traffic that defeats a naive rule set is specific and predictable. OPC Classic over DCOM is the classic example: the client reaches the endpoint mapper on TCP 135, and the server answers with a dynamically assigned port from the ephemeral range, 49152 to 65535 on current Windows, so permitting 135 accomplishes nothing and permitting the whole range is not segmentation. The repair is either constraining the DCOM port range in the registry on both sides or moving to OPC UA, which uses one TCP port, 4840 by default, and can be tunneled through a single conduit. Active Directory membership across a boundary is the other one: an HMI authenticating to a domain controller on the business side pulls in Kerberos on 88, LDAP on 389 and 636, DNS on 53, SMB on 445 and the same RPC range, at which point the boundary exists on the drawing only.
Before a zone boundary is drawn, the flow inventory has to be real rather than assumed. These are the crossings most often absent from the drawing and most often found in a capture:
- Historian collection and replication from the process network to a business-side mirror, frequently over a vendor-specific port rather than a standard one.
- Time synchronization. NTP on UDP 123 routes and can be permitted explicitly; PTP under IEEE 1588 operates at layer 2, so a new boundary can break clock distribution without anything appearing in a firewall log.
- License servers and hardware key services for engineering software, which usually sit on the IT side and are reached from the OT side.
- Vendor remote access: a cellular router in a cabinet, a jump host, or an outbound tunnel established by a vendor appliance, which no inbound rule ever had to permit because it dials out.
- Antivirus definition updates, WSUS, and backup agents reaching from the control network into the business network on a schedule nobody watches.
- File and print traffic from HMIs to office servers, typically SMB on 445, added years ago so a shift report could be printed upstairs.
Where the IT Method Is Right, and How to Tell
The inversion is not a blanket exemption, and treating everything behind the plant firewall as untouchable is the mirror image of the error it corrects. The upper layers of a control architecture are ordinary computers: DMZ servers, historians, jump hosts, virtualized SCADA and batch servers, patch and antivirus infrastructure, reporting databases. Standard IT practice applies to those with standard IT tooling, and declining to patch a Windows server in the DMZ because it is "OT" leaves an easy target in the one place that touches both networks.
Three questions sort an asset onto one side or the other. Is it in the process path, meaning does its loss stop production or remove a view the operator needs to act. Is its configuration constrained by a support agreement or a qualified state that a change would disturb. Can it be taken out of service independently of the process, because it is redundant, standalone, or used only during engineering work. An asset that answers no to all three is an IT asset that happens to live in a plant, and maintaining it as anything else is a choice to carry risk for no operational reason.
Two cases run the other way. Safety instrumented systems are not simply more critical controls; they are separate logic solvers with their own approvals under IEC 61511, and changes to them pass through a functional safety change process that no security finding overrides, so a recommendation touching an SIS has to be written for that process or it will not move. The second is scheduling: a batch, seasonal, or single-shift operation has genuine idle time, and where the process is genuinely down the constraints that make active work difficult elsewhere do not apply. The question is whether this process is idle and this device is spare, not whether the site is labeled OT.
Detection Works, Response Is the Harder Half
The standard incident response reflex, isolate the host, is the outage the whole program exists to prevent. Quarantining an engineering workstation partway through a firmware download, killing a process on an HMI, or blocking a conduit can produce exactly the effect an attacker was working toward, achieved by the defender at speed. OT response plans are therefore written with operations in the room and organized by who is permitted to authorize each action, and a large share of the effective actions are physical rather than digital: put the loop in manual, transfer to the redundant path, station an operator at the panel, pull the cellular router's antenna. A playbook that lists only network and endpoint actions has not been written for this environment.
Evidence has its own constraint. Many controllers keep no security-relevant log at all, and those that do overwrite quickly and expose the record only through the vendor's engineering software rather than syslog, so the network capture is the log. That has a direct consequence: with no capture running, an incident discovered three weeks later cannot be reconstructed from the devices, and retention on the capture, not on the endpoints, sets how far back an investigation can reach. The process historian is the source most often overlooked, because it holds years of values at high resolution, and a value that moved with no corresponding operator action or scheduled step is evidence in a form the plant already trusts.
Frequently Asked Questions
Is an OT security assessment the same as a penetration test?
No. A penetration test is scoped and contracted as its own activity, with its own rules of engagement, target list, and abort criteria, rather than folded into an assessment as one of its phases. The practical consequence is whose signature is required: an assessment is often approved by an IT or security manager, while exploitation attempts against production control equipment need the process owner or plant manager, and at regulated sites the change management function as well. Where those approvals are not available, the honest scoping answer is that the engagement is an assessment and the test is a separate decision to be made later.
What does passive monitoring physically connect to?
A SPAN or mirror port on a managed switch, or a network tap placed on a link, feeding a collector that only receives. A tap is preferable where the switch already carries heavy traffic, because a SPAN session is serviced by the switch's own forwarding resources and silently drops mirrored frames under load. The real limit is that many control cabinets contain unmanaged switches with no mirroring capability, so the capture point moves upstream and traffic between devices inside that cabinet is never seen. That blind spot belongs in the report, because a picture drawn from an upstream capture will otherwise read as complete.
What has to exist before the work can start?
Exports save the most time: the current firewall rule set, switch configurations and MAC address tables, controller and HMI project backups, the list of vendors and integrators holding remote access, and the maintenance calendar. Network diagrams are worth handing over even when they are years out of date, because a stale diagram is still evidence of what people believe the network to be, and the gap between that belief and the capture is frequently the finding itself. None of it has to be complete or current. An asset spreadsheet with holes in it is a better starting point than a delay while somebody tries to build a perfect one.
Does anything get installed on the control system?
An OT assessment does not require agents on controllers, HMIs, or engineering workstations. Collection is off-path: switch mirror ports, configuration exports from switches and firewalls, and copies of project files reviewed away from the live system. Where a tool has to run somewhere, it runs on hardware brought for the purpose or on a machine the site owns and can restore. The constraint behind that is practical as much as procedural, since a panel PC sized for one application has no headroom for scanning software, and an agent competing with the HMI runtime is visible to the operator as a stalled screen.
Which standard should the findings be written against?
That is a customer decision and it changes the shape of the report. IEC 62443 is a series: 62443-2-1 addresses the asset owner's security program, 62443-3-2 covers risk assessment and partitioning a system into zones and conduits, and 62443-3-3 defines system security requirements and security levels 1 through 4 across seven foundational requirements. NIST SP 800-82 is a guide to OT security that maps the environment onto the SP 800-53 control catalog, which fits organizations already reporting against 800-53 elsewhere. Sites under a sector regulator, such as electric utilities subject to NERC CIP, generally need findings expressed in the regulator's language regardless of which framework organizes the work underneath.
What does the customer actually have to decide?
The scope boundary and the tolerance for anything active. Scope means naming the line, cell, or site and stating explicitly whether the business-side interface, the DMZ servers, and vendor remote access paths are inside it, since ownership of those is often split between the plant and a central IT group and each assumes the other has it. Tolerance means deciding in advance whether any active work is on the table and against which assets, because that decision sets the limit on what can be concluded about devices nothing is allowed to touch. The third decision is who receives the findings and owns remediation, since a report delivered only to IT tends to stall on every item requiring plant time.
When is this not the right work?
When the control network is a single skid: one controller, one HMI, one unmanaged switch, no route off the panel, and no vendor connection. Walking the cabinet and writing down the handful of connections produces the same answer, and a formal assessment adds process rather than information. It is also poorly sequenced when the control system is already inside a capital project for replacement, because findings against equipment on its way out compete for budget with the replacement design. In that case the useful work sits in the procurement requirements, where segmentation, remote access, logging, and patchability can be specified before purchase instead of retrofitted afterward.