Why does OT security need different severity logic than enterprise IT security?

Why OT Severity Cannot Copy Enterprise IT Logic

OT severity is not just a stronger version of IT severity. In operational environments, the alert has to be judged against process state, safety exposure, and how much the asset matters to live production. A low-significance IT finding can become high impact if it touches a controller, safety-related function, or a system that operators depend on to keep a plant stable.

The key difference is context. In IT, a compromise usually maps to confidentiality, integrity, or availability of information services. In OT, the same event can interrupt a physical process, force manual operation, or create a safety condition. Severity logic therefore has to reflect not only whether something is vulnerable, but whether it can disrupt plant operation or reduce control over the process.

That is why OT teams often separate assets that are actively controlling equipment from assets that are present but not currently in the control path. An alert on a live operator workstation, PLC, or engineering station carries a different operational meaning than the same alert on an inactive or isolated device. The right severity model follows process criticality, not generic enterprise asset class.

What OT Severity Has to Weight That IT Often Does Not

OT scoring should weigh safety, uptime, and dependency on the affected asset. If a control or monitoring function is essential to running the process, even a modest technical issue can deserve a higher priority because the operational consequence is larger than the event itself.

It also has to account for maintenance windows and abnormal operating modes. A finding that is tolerable during a planned outage may be unacceptable during production, while an alert on a dormant system may deserve investigation but not an urgent response. This is why severity in OT is often tied to process role, location in the control hierarchy, and whether fallback procedures exist.

Another important factor is blast radius. In enterprise IT, one compromised host may be handled as an endpoint problem. In OT, a single asset may have a role in command issuance, historian feeds, alarm handling, or safety logic visibility, so the downstream consequence can spread beyond the host itself. A good OT severity model measures that dependency chain explicitly rather than assuming all assets are interchangeable.

How OT Teams Should Translate Alerts Into Operational Meaning

Severity should answer a practical question: what changes in the plant if this event is real? If the answer is “nothing material,” the alert can often be downgraded even if the technical signal looks alarming. If the answer is “operators may lose confidence in control or have to switch to manual handling,” the same technical issue becomes more urgent.

That logic also helps reduce noise. OT environments often contain legacy devices, brittle protocols, and long-lived assets that generate conditions enterprise tools would flag constantly. A process-aware severity model avoids over-rotating on issues that are technically messy but operationally contained, while still elevating anything that could stop production, degrade safety, or impair visibility into the process.

In practice, teams should align severity with process criticality tiers, maintenance state, and recovery difficulty. If a problem affects a device with no direct operational role, the response may be scheduled. If it affects a device that can influence process control or safety margins, the response should be immediate and coordinated with operations.

Risk and Threat Considerations

OT severity mistakes create two opposite failure modes. Over-severity drives alert fatigue, unnecessary shutdown decisions, and wasted operator attention. Under-severity is more dangerous because it can let a condition that affects a live process linger until it creates downtime, unsafe conditions, or a broader control failure.

Failure mechanism: The security team scores events as if every asset had equal business meaning, so process-critical systems, maintenance-state systems, and passive assets all get the same response path. That breaks the link between technical detection and operational consequence.

Impact: Events that can disrupt control, degrade safety margins, or interrupt production are either treated too lightly or escalated too aggressively, both of which reduce resilience and trust in the alerting model.

Practitioner Guidance

What to prioritise: Build severity around process role first, then technical exploitability. For OT, the most important question is whether the affected asset can influence production, safety, or operator decision-making right now.

What to verify: Before trusting an alert score, verify the asset’s live function, maintenance state, and fallback options. The same indicator deserves a different rating if the device is in the control loop, in a standby role, or only present for inventory or monitoring purposes.

Decision rule: If an event touches an asset that can change process behaviour, operator visibility, or safe shutdown capability, treat process impact as the primary severity driver. If it only affects a non-critical or disconnected asset, keep the response proportionate and avoid importing IT-style urgency by default.

Practitioner takeaway: OT severity works when it measures operational consequence, not just technical weakness, because plant context determines whether an alert is a nuisance, a disruption, or a safety issue.

Related resources from NHI Mgmt Group

• Why do real-time onchain controls create a different governance burden for security teams?
• How should security teams govern unagentable devices in OT and healthcare environments?
• How should critical infrastructure teams maintain access control when OT sites are isolated from enterprise systems?
• Why do different AI security tools find different bugs in the same codebase?