Context is the Missing Layer in OT Security

A CVSS score can tell you how severe a vulnerability looks on paper. It cannot tell you whether that vulnerability is reachable in your environment, whether the asset can be patched, or whether the affected system touches a process that matters.

An AI tool can surface more findings. It cannot decide which ones your team can act on this week, which ones require a vendor conversation, and which ones belong on a watchlist until the next outage window.

A compliance requirement can drive more monitoring. It cannot guarantee that operators, engineers, and analysts can see what is happening where the process actually runs. That’s where OT security context matters.

In operational technology, technical facts only become useful when they’re tied to the environment around them. Where does the asset sit? What does it control? Who owns it? Can anyone reach it? Is it segmented? Is there a maintenance contract? Would changing it create more risk than leaving it alone for now? Those details change the decision.

OT security teams typically don’t have a shortage of information. They have advisories, asset lists, risk scores, alerts, regulatory language, vendor recommendations, and now AI-generated findings arriving faster than most organizations can sort them.

The teams that make progress are the ones that can turn that information into an environment-specific decision.

Start by Separating Severity from Priority

CVSS has value. It gives teams a shared way to describe the theoretical severity of a vulnerability. In OT, that should be the start of the conversation, not the end of it.

Severity asks how bad a vulnerability could be. Priority asks what your team should do first. Those answers can be very different.

A 9.8 may look urgent until you learn that the affected system is at a physically secured site, has no remote access, is segmented from the rest of the environment, and requires local user interaction to exploit. The finding still matters, but it may not deserve the next emergency maintenance window.

A lower-scored issue on a reachable controller tied directly to a safety or reliability function may need attention first.

A practical prioritization review should answer five questions before a finding moves to the top of the queue:

1. Is there evidence this vulnerability is being exploited in the wild?
2. Is the affected asset reachable through a realistic path?
3. What process, safety, reliability, or operational function does the asset support?
4. Can the team patch it without violating vendor guidance, maintenance contracts, or uptime requirements?
5. If patching has to wait, what compensating controls can reduce risk now?

That review doesn’t need to be complicated. For many teams, a simple now, next, later, watch, or accept decision is enough as long as the reasoning is documented.

The important part is that the decision reflects the environment, not just the score.

Validate Whether the Finding Applies

One common vulnerability-management mistake is treating technical presence as practical risk. A software component may exist on a system without being used in the way a vulnerability requires. A library may be present but unreachable. A feature may be included but disabled. A tool may have created files used by an application without the tool itself being accessible to an operator or attacker. That distinction shows up constantly in OT.

Industrial environments are full of long-lived systems, vendor-managed stacks, specialized firmware, legacy operating systems, and configurations that don’t behave like standard IT assets. Teams don’t always choose the operating system. They don’t always get to install endpoint tooling. They don’t always get to inspect every component whenever they want.

Before treating a finding as actionable, ask:

• Is the affected component actually used?
• Is the vulnerable function enabled?
• Can the vulnerable service be reached from any realistic path?
• Does exploitation require local access, credentials, user interaction, or a specific configuration?
• Can the vendor confirm whether the advisory applies to this deployment?
• Is there network evidence that the affected protocol, service, or behavior is present?

Sometimes the answer requires a maintenance window, a vendor conversation, or a careful on-site assessment. That’s still better than sending a team after a patch that cannot be deployed or a vulnerability that’s technically present but not practically reachable.

Context turns “this exists” into “this matters because.”

Treat Vendor Constraints as Part of the Risk Model

In IT, the organization usually owns the endpoint, the operating system, and the patching decision. OT is often different.

A utility, manufacturer, or industrial operator may own the facility but not have full control over every system inside it. OEM support agreements, integrator relationships, warranty language, validation requirements, and safety certifications can all shape what the team is allowed to change. That means patchability is an ownership and operations question, not just a technical question.

For each high-priority finding, document:

• Who owns the asset?
• Who is allowed to modify it?
• Who must approve a patch or configuration change?
• What support agreement or warranty language applies?
• When is the next realistic maintenance window?
• What is the rollback plan if the change causes issues?
• What can be monitored or restricted while the fix waits?

This is where many OT remediation plans stall. The security team identifies the issue, but operations, engineering, or the vendor carries the cost and risk of changing the system. If that handoff isn’t planned, the finding sits.

A useful remediation plan includes the technical fix, the operational constraint, the responsible party, and the interim control. Without all four, it’s not really a plan yet.

Use Segmentation as Evidence, Not a Slogan

Segmentation is one of the most important controls in OT, but it only helps prioritization when teams can prove what it actually blocks. A network diagram is a starting point. What matters is whether the path required for exploitation exists.

For a vulnerability that requires network access, teams should be able to answer:

• Which zones can initiate traffic to the affected asset?
• Which protocols and ports are allowed?
• Are those flows expected for the process?
• Are there jump hosts, remote-access paths, vendor VPNs, or shared services that bypass the intended boundary?
• Can the affected asset communicate laterally with other operational systems?
• Is there monitoring at the boundary and near the asset?

If segmentation blocks the required path, that should lower the priority or change the response. If segmentation looks good on paper but remote access, shared credentials, flat switching, or unmanaged maintenance paths bypass it, the risk may be higher than the diagram suggests.

The same finding can carry different priority in two environments because the path is different. That’s the point of OT security context.

Turn Compliance Monitoring Into Operational Visibility

Compliance can push organizations in a useful direction. NERC CIP-015, for example, has brought more attention to internal network security monitoring in electric utility environments.

That’s overall a good thing. It’s also possible to satisfy a requirement and still leave operators, engineers, and analysts without the visibility they need day-to-day. The practical question isn’t just “Do we monitor?” but “Can we make decisions from what we see?”

For asset owners preparing for internal network security monitoring requirements, the useful test is simple:

• Can we see traffic below Level 3.5, especially at Levels 1 and 2?
• Can we identify assets without relying only on manual spreadsheets?
• Can we recognize normal device-to-device communication?
• Can we detect new or unexpected paths?
• Can we retain enough evidence to evaluate an event after the fact?
• Can operations understand the alert without needing a packet-decoding expert?
• Can we tie monitoring back to response steps?

Many organizations have monitoring near the DMZ, control-room layer, or central aggregation points. Fewer have the same clarity around controllers, HMIs, RTUs, PLCs, and the paths that touch the physical process.

That lower-level visibility matters because it’s where small changes can have real operational meaning. Compliance should create the push. Visibility should be the outcome.

Use AI Where It Strengthens the Workflow

AI will be part of OT security, and in many places it already is. It can help summarize complex information, speed up research, support analysts, draft documentation, generate hypotheses, and reduce repetitive work. The risk is using AI where the team hasn’t defined the boundaries.

AI can make output look polished before the reasoning is sound. It can help a junior person produce a senior-looking answer without giving that person the judgment a senior practitioner would use to validate it. In OT, that gap matters.

A practical way to use AI in OT security is to place it around the decision, not inside the final authority for the decision.

Good uses include:

• Summarizing vendor advisories
• Drafting questions for OEMs or integrators
• Comparing a finding against known asset inventory
• Suggesting triage questions
• Generating a first-pass remediation note
• Organizing evidence for a risk acceptance record
• Translating a technical alert into plain language for operations

Riskier uses include:

• Automatically assigning operational priority without human review
• Recommending changes to safety or control logic
• Acting directly on process-adjacent systems
• Treating generated explanations as verified facts
• Sending sensitive process context into tools the team hasn’t yet assessed

The rule is straightforward: AI can help the team move faster through work they understand. It shouldn’t be used to hide gaps in understanding.

Decide What Context Can Leave the Site

Cloud platforms, AI tools, managed services, and centralized analytics can all create value. They can also concentrate information that used to be distributed across individual sites.

That matters because reconnaissance is a major part of OT attack planning. An adversary needs to understand what assets exist, how they communicate, where the control points are, and how the process behaves. Centralizing that information can make legitimate operations easier. It can also make the target cleaner if access is abused.

Before sending operational context off-site, asset owners should ask:

• What specific data leaves the environment?
• Does it include IP addresses, hostnames, asset roles, configurations, process context, or control relationships?
• Who can access it?
• How is access logged and reviewed?
• What happens if a user account is compromised?
• Can the tool operate locally or in a bounded deployment?
• What is the minimum data needed for the intended security outcome?
• Does the architecture align with regulatory obligations and internal risk tolerance?

This doesn’t mean cloud is automatically wrong for OT. It means the architecture deserves the same scrutiny as any other path into the environment. If the data would help an attacker map the process, treat it as sensitive.

Build a Context Record for Important Assets

A lot of OT security work gets harder because the information needed for decisions lives in different places. The asset inventory has one piece. The network diagram has another. The vendor contract has another. The operator has another. The vulnerability tool has another.

For critical assets, build a simple context record that brings those details together.

At minimum, include:

• Asset name, type, vendor, model, firmware, and location
• Purdue level or functional zone
• Process or operational function
• Safety, reliability, or production impact
• Normal communication partners
• Allowed protocols and remote-access paths
• Patch owner and vendor support contact
• Maintenance window constraints
• Known compensating controls
• Monitoring coverage
• Current high-priority vulnerabilities or accepted risks
• Last validation date

Don’t beat yourself up if things aren’t perfect on day one. Start with the assets that would cause the most operational pain if they failed, were misused, or became unavailable.

The goal is to reduce the time between a new finding and a defensible decision. When a new advisory lands, the team shouldn’t have to rediscover the environment from scratch.

A Practical Decision Flow

When a new vulnerability, alert, compliance requirement, or AI-generated finding lands, run it through a consistent sequence:

1. Identify the affected asset.
2. Confirm whether the finding applies to the actual deployment.
3. Check reachability and segmentation.
4. Determine operational criticality.
5. Identify ownership and patch constraints.
6. Review known exploitation or threat activity.
7. Choose the response: fix now, fix next, monitor, compensate, accept, or investigate.
8. Document the reason.
9. Set a review date.

That final step matters. OT environments change slowly, but they do change. A finding that’s acceptable today may become more serious after a remote-access change, a network redesign, a vendor upgrade, or a shift in threat activity. Context isn’t a one-time note, but rather something the team consistently maintains.

The Goal Is Fewer Better Decisions

Don’t shoot the messenger, but unfortunately, I’m pretty sure that the future of OT security will not be quieter. There will be more vulnerabilities, more AI-generated findings, more regulatory pressure, more vendor claims, more alerts, and more tools promising to simplify the work.

The teams that handle it well won’t be the ones that react to everything equally. They’ll be the ones that know their environment well enough to decide what matters first.

Know what assets you have. Know where they sit. Know what they do. Know how they communicate. Know which systems are reachable, which are critical, which are vendor-managed, which can be patched, which can’t, and which need to be monitored because replacement is unrealistic. Then use the scores, tools, regulations, and AI outputs as inputs.

That’s how an overwhelming vulnerability queue becomes a prioritized plan. That’s how compliance becomes operational visibility. That’s how AI becomes useful without becoming louder. That’s how defenders move from “we found something” to “we know what to do next.”

OT security context is the layer that makes every other layer useful.

No noise. Just signal.

~Jori 🤘🔥