Contrarian take: If your OT security plan looks like your IT plan (patch faster, add more agents, buy another SIEM), you’re probably increasing risk.

Critical infrastructure incidents rarely fail because of exotic malware.
They fail because IT-first controls don’t translate to OT realities: uptime constraints, legacy protocols, safety interlocks, and always-on vendor access.

Where most “enterprise security” programs still break in OT/ICS:

1) Asset visibility that stops at the switch
If you can’t answer “what is this PLC/HMI, what talks to it, and what would break if it changes,” you’re operating blind.

2) Remote access governance built for convenience, not safety
Shared vendor accounts, always-on VPNs, no session recording, no time bounds, no approvals. This is the common entry point.

3) Segmentation designed for org charts, not process safety
Flat networks and dual-homed boxes turn a small intrusion into plant-wide impact. Segment by function and consequence, then control the conduits.

4) Monitoring that can’t see OT protocols
If telemetry is only Windows logs and SIEM alerts, you’ll miss the real story on Modbus, DNP3, IEC 60870-5-104, OPC, and proprietary vendor traffic.

5) Patch expectations that ignore outage windows and certification
In OT, “just patch” can equal downtime. Compensating controls and risk-based maintenance matter.

If you lead security or build products for critical infrastructure: start with asset inventory, remote access, and safety-driven segmentation. Reduce risk without disrupting operations.

What OT/ICS gap do you see most often in the field?