Why Your IT Threat Intel Feed Won't Save Your OT Network
Here’s a scenario that plays out in OT security teams every quarter.
The SOC receives a threat intelligence report: a new APT group, tracked by three-letter designator, has been observed targeting energy-sector organisations. The report includes a list of indicators of compromise — IP addresses, domain names, file hashes, and a YARA rule for the malware dropper. The SOC ingests the IOCs, updates the SIEM correlation rules, and confirms that none of the indicators have been seen in the last 90 days. The report is filed. The quarterly review board is satisfied. Nobody notices that the substation engineering workstation — disconnected from the internet, air-gapped by policy if not by practice — received an unauthorised firmware upload from a maintenance laptop three weeks ago.
The IOC model, for all its value in IT, has a structural blind spot in OT. And understanding why that blind spot exists is the difference between monitoring for what might attack you and monitoring for what your network is actually doing.
How IT Threat Intelligence Works
In enterprise IT, threat intelligence follows a well-worn playbook. A threat actor compromises a target. Researchers reverse-engineer the malware, extract the command-and-control infrastructure, and publish indicators. Defenders ingest those indicators into detection tools — firewalls, EDR, SIEM — and block or alert on matches.
This model works because IT attacks share common infrastructure. Malware phones home to the same domains. Phishing campaigns originate from the same IP ranges. Ransomware binaries use the same packers, the same encryption routines, the same ransom note templates. When one victim is analysed, the indicators protect hundreds more.
The cycle time — from initial compromise to IOC publication to defender ingestion — is measured in hours or days. In IT, that’s usually fast enough. By the time the campaign reaches the next target, the indicators are already in the detection pipeline.
The Three Reasons IOCs Fail in OT
OT breaks this model at three structural levels.
First: OT attacks rarely use malware. When an adversary compromises an OT network, they don’t drop a custom binary and phone home to a command server. They use the engineering tools already installed — the engineering workstation software, the HMI application, the PLC programming environment. They issue valid Modbus writes. They upload legitimate firmware images. They modify setpoints from the same keyboard the operator uses.
This technique — living off the land — has no file hash. No process signature. No C2 beacon to detect. The commands are valid. The source is not. And the only way to distinguish the two is to know what normal looks like for that specific device, on that specific network, at that specific time of day.
Second: OT attacks don’t use shared infrastructure. An IT ransomware gang reuses the same bitcoin wallet, the same Tor hidden service, the same ransom note. An OT attack on a water treatment plant in Florida uses the plant’s own HMI. An attack on a Ukrainian substation uses the substation’s own relay configuration software. The infrastructure is the plant itself. There is no shared IOC to extract and distribute.
The 2015 and 2016 attacks on Ukraine’s power grid illustrate this perfectly. The adversary used the grid’s own SCADA software — no custom malware on the HMI, just mouse clicks from a remotely controlled desktop session. If you were monitoring for IOCs, you saw legitimate operator activity. If you were monitoring for behavioural anomalies, you saw an operator issuing commands from an unexpected source at an unexpected time. The same action, two completely different detection outcomes, depending on whether you’re looking for the indicator or the pattern.
Third: OT IOC sharing is dangerously slow. The IT threat intelligence ecosystem moves fast because the commercial incentive to share is strong — every victim that publishes indicators protects the rest. In OT, the incentive runs the other way. When a water utility or an electrical substation is compromised, the operator’s first call is to legal counsel, not to a threat intelligence platform. Incident reports are sanitised, delayed, and often never published at all. The Stuxnet post-mortem took years. The TRISIS/Triton analysis took months. The Colonial Pipeline IOCs were published after the pipeline was already back online.
By the time an OT IOC reaches a defender, the adversary has long since moved on — and the indicator was specific to the target’s environment anyway.
What OT Operators Should Be Monitoring Instead
If IOCs are the answer to a question OT doesn’t ask, what is the right question?
The right question is: what does normal look like, and what just changed?
Behavioural detection — monitoring the network for deviations from an established baseline — doesn’t depend on knowing what malware looks like. It depends on knowing what the plant looks like when it’s healthy. That means:
Protocol-level baselines. Which devices normally issue Modbus write commands? Which devices normally respond to DNP3 read requests? Which MAC addresses are expected to transmit GOOSE messages on which VLANs? A device that starts issuing commands it never issued before — even if those commands are individually valid — is a detection signal that no IOC can capture.
Connection patterns. Which engineering workstations connect to which PLCs during maintenance windows? Which vendor laptops appear on which subnets during commissioning? A laptop connecting to a PLC from a VLAN it has never touched before, at 3 AM on a Sunday, is not an IOC. It’s a deviation from normal. And it’s the kind of signal that catches insider threats, credential abuse, and supply chain compromise — none of which show up in a hash feed.
Engineering activity cadence. How often do firmware uploads happen? How often are protection relay settings modified? A substation that normally sees one firmware update per quarter suddenly logging three in a single week is not something a threat feed will flag. It’s something a baseline will.
Protocol misuse. A device that normally communicates via Modbus TCP on port 502 suddenly sending HTTP traffic. A PLC that normally only responds to read requests suddenly initiating write commands. These are protocol-level anomalies that no amount of IP reputation checking will catch — because the IP address is internal, the protocol is legitimate, and the only thing that’s wrong is who is doing what.
The Threat Intel That Actually Helps OT
This is not an argument against threat intelligence. It’s an argument for the right kind of threat intelligence for OT environments.
What helps: adversary TTPs (tactics, techniques, and procedures) mapped to MITRE ATT&CK for ICS. Knowing that a specific threat group targets engineering workstations via RDP rather than knowing their C2 domain helps you instrument the right detection surfaces. Understanding that a campaign uses valid credentials to move laterally rather than malware helps you focus on authentication anomalies rather than file scanning.
What helps: sector-specific threat profiles. A water utility faces different adversaries than an automotive manufacturer. A power grid operator faces different TTPs than a pharmaceutical plant. Generic IP reputation feeds treat all environments as identical — and OT environments are anything but.
What helps: engineering-informed detection rules. The person who knows that a specific PLC model should never initiate an outbound Modbus connection is the protection engineer, not the threat analyst. Marrying that engineering knowledge with network monitoring creates detection that is specific to the plant, not generic to the internet.
The Bottom Line
The IOC model made IT threat intelligence the backbone of enterprise defence. But it assumed something that doesn’t hold in OT: that attacks use shared, detectable infrastructure that can be extracted from one victim and applied to many.
OT attacks use the plant’s own tools against itself. They look like legitimate engineering activity because they are legitimate engineering activity — just issued by the wrong person at the wrong time. The signal isn’t in the indicator. It’s in the deviation.
For OT operators, the question isn’t “has anyone seen this hash before?” It’s “has this device ever done this before?” Answering the second question requires knowing your network’s normal — and that requires monitoring that doesn’t depend on yesterday’s threat report.
Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.