The fastest way to fail a plant is to arrive with an IT security playbook and apply it literally. The controls are not wrong. The assumptions underneath them are.
The priority order is inverted
IT security ranks confidentiality first: the worst outcome is data leaving. In operational technology the worst outcome is usually the line stopping, or a safety function not acting when it should. Availability and integrity come first, and confidentiality — while it matters — is rarely the thing that ends up in the incident report.
That single inversion explains most of the friction. An endpoint agent that quarantines a suspicious binary is doing its job in an office. On an engineering workstation mid-batch, it is an unplanned outage caused by the security control rather than the attacker.
The assets outlive the people who installed them
A laptop refresh cycle is three years. A PLC installed in 2009 may still be running the process, with firmware whose vendor was acquired twice since, on a network segment nobody has drawn accurately since commissioning. “Upgrade it” is a capital project with a production outage attached, not a maintenance window.
So the honest question is rarely “how do we patch this?” It is “what compensating controls make this acceptable until the next planned shutdown, and who signed off on that?”
The protocols were designed for trust
Modbus, DNP3, EtherNet/IP, PROFINET and their relatives were built when the network was a locked cabinet. Many carry no authentication and no integrity protection by design. A well-formed command from anywhere on the reachable network is, to the device, indistinguishable from one issued by the operator.
Which is why architecture does more work here than any product does. If the protocol cannot tell friend from foe, the network has to.
Consequences are physical
The blast radius of an IT compromise is measured in records and downtime. In OT it can be measured in product batches, environmental release, equipment damage or injury. That changes who has to be in the room. Safety, operations and engineering are not stakeholders to consult after the security design — they hold the constraints the design has to survive.
What actually transfers
Plenty. Asset inventory, least privilege, segmentation, logging, backup and recovery, supplier assurance — all valid. What changes is the implementation and the order:
- Inventory first, always. You cannot protect what nobody has listed. Passive discovery before active scanning, because active scanning has knocked over more than one legacy device.
- Segment before you patch. Reducing what can reach the vulnerable device is usually faster and safer than changing the device.
- Design for degraded operation. The plant must run when the security infrastructure is unavailable, not the other way round.
- Test in a way that cannot hurt production. The most useful OT security assessments are staged against a representative rig, not the live process.
Where the standard comes in
IEC 62443 exists precisely because this domain needed its own frame. It separates the obligations of the asset owner, the service provider and the product supplier, and it makes the architecture question — zones and conduits — the centre of the method rather than an afterthought. If your programme is currently a set of IT controls applied downward, that structure is the change worth making first.
We assess OT environments against 62443, and we do it without touching the live process. If you want to know where you stand before someone else tells you, that is the conversation to have.