An introduction to Operational Technology cybersecurity risk

Most organizations running industrial or critical infrastructure operations have a cybersecurity program. It has an owner, a budget, a set of tools, and an annual review. It covers laptops, email, identity, cloud infrastructure, and the corporate network.

In a great many cases, it stops at the edge of the process.

The controllers, drives, sensors, and building systems that actually make the plant run tend to sit outside that program’s scope. Not because anyone decided they should. Usually because the people who own the enterprise security program and the people who own the process have never had a reason to draw a shared boundary — and because the OT environment predates most of the tooling that would have covered it.

If that describes your organization, you are in normal company. But it is worth understanding why the gap exists, because it does not close on its own.

Why operational technology is different

Enterprise IT security assumes a set of conditions that mostly do not hold on a plant floor.

Patching is not routine. An IT team patches on a schedule. A process controller cannot be patched without a maintenance window, and in regulated environments the change may require formal requalification. So updates wait for the next planned outage, which is frequently postponed. Systems accumulate years of unaddressed vulnerabilities while remaining, on paper, fully compliant.

The equipment lasts decades. A laptop is replaced every three or four years. A PLC installed in 2009 may still be in service, running firmware from a vendor who stopped issuing security updates for it long ago. Replacement is a capital project, not a refresh cycle.

Availability outranks confidentiality. In IT, the instinct during an incident is to isolate and shut down. In OT, shutting down may be the incident. That inversion changes what an acceptable response looks like, and most IT-trained responders have never had to work under it.

The consequences are physical. A compromised business system leaks data. A compromised control system affects a process — product quality, equipment integrity, service continuity, and in some environments, safety.

These are not arguments that OT teams have been careless. They are the operating conditions of the environment. Any security approach that ignores them will produce recommendations the plant cannot implement.

Where exposure actually accumulates

Across sectors, the same patterns turn up:

Flat networks, where the process network and the business network are separated by a rule that was correct when it was written and has not been reviewed since. Remote access paths commissioned by equipment vendors during a project, still active years after the contract closed, often undocumented in any asset inventory. Default and shared credentials on devices that were never expected to be reachable. Cellular and wireless connectivity at remote or unmanned sites that nobody has audited since installation. Firewall rule sets that accumulated across a decade of project work, where no one is quite sure which rules are still load-bearing.

And in most organizations, one or two people who genuinely understand how the whole environment fits together.

What this looks like depends on where you sit. In water and wastewater it is remote lift stations and SCADA. In life sciences it is validated systems and vendor support tunnels into production equipment. In data centers it is the BMS and electrical monitoring layer that nobody thinks of as an attack surface. In food and beverage it is line controls and a maintenance team already stretched thin.

Different environments, same underlying condition: the assets that matter most are the ones with the least visibility.

Three questions

You do not need an assessment to start. You need to know whether you can answer these three with evidence rather than assumption:

1. Can you produce a current inventory of every device on your OT network — including remote and unmanned sites — and identify which are reachable from outside your perimeter?
2. Do you know every active remote access path into your control systems, who owns each one, and whether any still use default or shared credentials?
3. If controller logic were modified at 2:00 a.m. on a Sunday, how long would it take you to know?

If any of those takes more than a day to answer, that is itself the finding. An organization that cannot answer them does not have a technology problem yet. It has a visibility problem — and visibility is the thing an assessment produces.

Start with CISA. It costs nothing.

Before spending money with anyone, including us, enroll in CISA’s Cyber Hygiene Services.

The service is free. It is open to U.S. governments and to public and private sector critical infrastructure organizations, which covers most industrial and regulated operators. It provides continuous automated scanning of your internet-facing assets, identifies known exploited vulnerabilities and the exposed services commonly used to gain initial access, and delivers recurring reports with mitigation recommendations.

There is no good reason not to be enrolled.

Where the free scan stops

Two limits matter, and both are easy to miss.

It is external only. By CISA’s own description, the scanning is a non-intrusive review of internet-accessible systems. It does not reach inside your private network and it cannot make changes. That means it sees nothing about segmentation between your business and process networks, nothing about credentials on a controller that is not internet-facing, and nothing about a vendor support tunnel into a production asset. A significant share of the findings that would matter most sit in exactly that blind spot.

It produces findings, not fixes. This is the more consequential limit. A report identifying an exposed service is worth precisely as much as the remediation it triggers. Closing a finding on a live process means a maintenance window, an impact assessment, and someone with the judgment to know what will and will not disturb operations. CISA does not do that work and does not claim to.

Scanning tells you where the unlocked doors are. It does not lock them.

What to do next

Enroll with CISA. Then work through the three questions honestly with your operations and engineering teams — not to produce a document, but to find out what you actually know.

If the exercise surfaces more uncertainty than you are comfortable with, that is worth acting on. Most organizations discover that the gap is not in their tooling. It is in the inventory, the access paths, and the ownership.

InflexionPoint conducts a cybersecurity exposure survey for industrial and regulated operators — a structured, vendor-neutral look at where your OT environment is actually exposed, aligned to IEC 62443. It is a starting point, not a commitment: we identify what is there, tell you what we would prioritize, and explain what remediation would realistically involve.

We are not reselling a security product, and we do not hand over a report and leave. Where clients want it, we stay in the environment — remediating findings, hardening access, and monitoring afterward.

If you would like to know what your exposure survey would cover, reach out to us today. And enroll with CISA either way.