The SANS OT Skills Crisis — and the Detection Strategy That Closes the Gap
The SANS Institute’s 2026 ICS/OT cybersecurity report landed this month with a finding that will surprise approximately no one working in operational technology security: there is a measurable, consequential skills gap, and it is putting critical infrastructure at risk. The report flags a structural shortage of personnel who can triage OT-specific alerts, interpret industrial protocol telemetry, and distinguish a genuine process anomaly from a maintenance window doing what maintenance windows do.
It is easy to read that and think: we need more people. Budget for headcount. Accelerate hiring. Launch a training programme. And yes — those things matter. But there is a second data point that changes the arithmetic entirely. Dragos’s 2026 Year in Review reported that organisations with comprehensive OT visibility contained ransomware incidents in an average of five days, compared to an industry average of 42 days.
That is not an incremental improvement. It is nearly an order of magnitude. And it reframes the skills crisis not as a headcount problem, but as a detection-strategy problem. The question is not “how many analysts do you have.” It is “what are your alerts asking those analysts to do.”
What the Skills Gap Actually Costs
An understaffed OT security team is not simply doing the same work more slowly. It is doing qualitatively different work. A team that is underwater defaults to triage — scanning for the loudest signal, closing the most tickets, clearing the queue. The quiet anomalies — the ones that manifest as a single unexpected Modbus function code, or a firmware interaction from an unfamiliar workstation at an unusual hour — are the first to go unexamined.
This is not speculation. The same Dragos report found that 30% of its OT incident response engagements in 2025 began not as detected intrusions but as unexplained operational anomalies — things someone eventually decided were strange enough to escalate. In many of those cases, limited historical data collection prevented root cause analysis entirely. The team had no baseline to compare against. They could not answer the question “has this ever happened before?” because no one had been recording the answer.
That is the skills crisis in its operational form. Not a shortage of talent, but a shortage of signal. When every alert demands a skilled analyst to interpret it — when the detection system surfaces raw events without context — the team will always lose. There are only so many analyst-hours in a day. The math is unforgiving.
The False-Positive Multiplier in OT
This is where the conventional approach to OT detection compounds the problem. Signature-based detection — matching network traffic against known-bad patterns — produces alerts that require interpretation. A signature hit on an ICS protocol is not a smoking gun. It is a starting point. Someone has to look at the packet capture, map it to the Purdue level, identify the devices involved, determine whether the traffic pattern is routine or anomalous, and decide whether to escalate.
In an IT SOC, that workflow is supported by context: asset inventories, threat intelligence feeds, correlated logs. In OT environments, that context is often missing. The engineering workstation that triggered the alert may not be in the CMDB. The PLC it was talking to may have been commissioned during a turnaround three years ago by a contractor who has since left. The function code in question may be entirely normal — or it may be the first time that specific controller has ever received that specific command from that specific source.
The signature-based sensor cannot tell you which. It can only tell you that something matched a pattern. The rest is analyst work. And if the analyst-to-alert ratio is already broken — as the SANS report suggests it is — then the investigation never happens.
What Changes the Math
The organisations that contained ransomware in five days instead of 42 were not running bigger teams. They were running a different detection paradigm. They had visibility into what was normal — per-device, per-protocol, per-function-code — before the incident began. When an anomaly surfaced, it surfaced against a baseline. The alert did not say “signature matched.” It said “this device has never issued this function code to that controller at this hour in six months of observation.”
That changes the analyst’s job. Instead of starting every investigation with “is this normal?”, the analyst starts with “why is this different?” The difference is the difference between open-ended detective work and targeted investigation. It is the difference between 42 days and five.
This is not a point about technology for its own sake. It is a point about resource multiplication. A behavioural detection engine that learns what normal looks like for every device on the network — every Modbus poll interval, every S7comm job sequence, every DNP3 read/write pattern — does not replace analysts. It makes the analysts you have dramatically more effective. It filters the noise so they can focus on the signal. It gives them the context they would otherwise have to reconstruct from scratch.
What This Actually Requires
Building that behavioural model is not trivial. OT networks are deterministic — until they are not. A refinery that has run the same process for a decade may undergo a turnaround that rewires half its I/O in a single week. A water utility may commission a new RTU that changes the polling cadence of its SCADA master. A legitimate engineer may download controller logic at 03:00 because that is when the maintenance window opened.
A detection system that treats every deviation from a static baseline as an alert is worse than useless — it is actively harmful, because it trains the team to ignore alerts. A detection system that requires the team to manually define what “normal” means for every device will never be completed, because the team is already underwater.
The hard problem is building a statistical model of normality that learns continuously, adapts to legitimate operational change, and surfaces only meaningful deviation. This is an engineering problem, not a signature-writing problem. It requires unsupervised learning over protocol telemetry — not connection logs or packet counts, but the actual industrial conversation: which function codes are issued, by whom, against which controllers, at what frequency, and with what statistical properties.
The Skills Crisis Doesn’t Go Away — but the Math Does
The SANS report is correct. There are not enough skilled OT security people, and there will not be enough for the foreseeable future. The pipeline is too narrow. The domain knowledge — industrial protocols, process engineering, the physics of what a PLC actually controls — is too specialised. No amount of training budget changes that in the near term.
But the containment-time data tells a different story. The organisations that cut their response time from 42 days to five did not hire eight times the analysts. They deployed detection that made their existing analysts eight times more effective. They stopped asking their people to hunt for anomalies in raw traffic and started giving them anomalies surfaced against a learned baseline. They stopped treating every alert as a research project and started treating them as actionable intelligence.
The skills crisis is real. But the detection gap is what turns a staffing shortage into a national-security liability. Close the detection gap — with passive, protocol-level monitoring that learns normal and surfaces deviation — and you close the time gap. Not by adding people, but by giving the people you have the signal they need to move fast.
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.
Analysis informed by the SANS 2026 ICS/OT Cybersecurity Survey, the Dragos 9th Annual Year in Review OT/ICS Cybersecurity Report (2026), and Industrial Cyber reporting.