A Modbus write command fires on a PLC at 2 a.m. The SOC’s monitoring tool flags it as anomalous traffic. The on-call analyst, trained on Windows event logs and cloud IAM alerts, has never seen Modbus function codes before. She escalates it as a generic network anomaly, three severity levels below where it belongs. By the time the IR team reviews and checks in with an OT engineer the next day, the write command has already changed a setpoint on a piece of process equipment. Nothing catastrophic happened this time, but next time it could.

This is not a tooling failure. It is a design failure. Most SOCs are built IT-centric, and OT environments don’t fit into that model, yet.

The Problem with IT-First SOCs in OT Environments

IT-first SOCs bring three liabilities to OT environments:

1. Alert fatigue: OT monitoring tools generate noisy telemetry that IT-tuned detection logic was never built to parse. This causes analysts to drown in false positives within days of go-live.
2. Analysts misread OT protocol traffic: Modbus, DNP3, S7 and similar protocols look nothing like the traffic IT analysts are trained on, so legitimate but unfamiliar traffic gets waved through as noise, and genuinely abnormal traffic gets waved through right alongside it.
3. IT playbooks could cause an OT incident: IT security optimizes for confidentiality first. OT security optimizes for availability and safety first. A textbook IT response of isolate the host and kill the process, can shut down a production line or trip a safety system. The same action that contains an IT incident can cause the OT incident.

Now, I’d be remiss if I didn’t mention that none of it works without visibility. Most OT environments still lack a complete asset inventory and network visibility below the industry accepted Purdue Model Level 3. Analysts cannot triage what they cannot identify, and detection is only as good as the visibility and inventory contextualizing it.

What “OT-Aware” Actually Means

OT-aware is a specific, buildable capability, not just a mindset shift.

Building an OT-Aware SOC starts with analyst fluency. SOC analysts need the capability to understand and interpret OT protocols and process context. An analyst who understands what a Modbus write command does on the plant floor makes a different triage decision than one who only recognizes it as an unfamiliar alert.

An OT-aware SOC requires mapping alerts to physical consequence. Every OT alert should answer one question before anything else: what does this actually do downstream, on the equipment, in the process? Severity should be assigned based on physical impact, not how the traffic looks on a dashboard. This one is challenging to accomplish, and it relies on a clear asset inventory with impact and prioritization of assets, which takes more than just the security team’s knowledge.

An OT-aware team runs on OT-specific playbooks and escalation paths that name exactly who gets called and when, built before an incident, not improvised during one. And it puts the site or plant OT engineers inside the SOC workflow as embedded subject matter experts, not as a phone number the SOC calls after the fact. This requires building relationships with the business stakeholders and that’s easier said than done, but it’s important.

For now, let’s focus on analyst fluency as a way to kickstart the journey to an OT-aware SOC.

Lessons from the Field

We see two failure patterns for SOCs ingesting and actioning OT alerts:

Analysts don’t know enough about OT systems to act correctly or in time. They can tell that something fired. They cannot tell what a specific Modbus function code or DNP3 operation does to the physical process, so they either escalate everything or escalate nothing, and both outcomes cost time the plant does not have.

Analysts can’t find the right alerts to action. Tool sprawl gives them five partial views instead of one complete one. Asset inventories are incomplete. They don’t fully understand what the PLCs really do on the shop floor. The alert that matters is buried in the same queue as a hundred that don’t.

Where This Is Heading

Previously we would start addressing analyst fluency in OT by either cross training IT SOC analysts or hiring OT analysts. Some organizations even attempted to build out completely separated OT SOCs. Those may solve these problems, but are they feasible? If things were working, would we still be talking about it? It’s time for a new approach.

The short answer that may come as a surprise: use your AI. That’s what we’re doing, and it works. Build an AI agent that is OT-aware and teaches as it works. When it flags a Modbus or S7 anomaly, it explains what the protocol is doing and why the behavior is abnormal, in the moment. You do need OT knowledgeable SOC analysts, but in the challenging landscape of finding that talent, you can teach it to your current team.

Every alert becomes a training example instead of a black box, and analyst fluency compounds instead of relying on unicorn analysts who have that expertise.

Use an AI agent to baseline your OT traffic and alerts and surface anomalies fast, closing the second gap: finding the right thing to action. These agents catch Modbus and S7 discrepancies that an IT-trained analyst would miss entirely, and surface them to the analyst instead of leaving them buried in a queue. They can even read through old ticket closures and learn about your organization from the notes that the OT engineers shared last time the alert fired.

So now, let’s imagine again:

A Modbus write command fires on a PLC at 2 a.m. The SOC’s monitoring tool flags it as anomalous traffic. The on-call analyst, trained on Windows event logs and cloud IAM alerts, has never seen Modbus function codes before, but she has notes from her AI agent that highlights that this isn’t normal activity and shares a bit of detail around what Modbus is so she can learn. She then asks the AI agent to look back through other tickets and find out if we’ve had similar Modbus alerts and sees that last time the OT engineer called out that these types of activities should always be escalated. She escalates it as a critical and calls the OT engineer right away. He immediately jumps in and is able to revert the write command before it truly affects the process equipment and does so without shutting down the production line. Nothing catastrophic happened this time, and hopefully won’t next time either because you have built an OT-aware SOC.

The takeaway: An OT-aware SOC isn’t an IT SOC with an OT dashboard. It’s a different operating model, one built on several aspects including analyst fluency in OT protocols, and knowing what to investigate and how to act. There’s no single way to build it. You’re already using AI. Use it to augment your team and start to move the needle of protecting your organization’s OT.