Skip to content
The Cyber Security Place

Industry and utilities

Where the ordinary rules invert

A water plant cannot be disconnected to be safe, cannot be patched this afternoon, and is run by people who also do the billing. Advice written elsewhere does not survive that.

Last reviewed August 30, 2026

Office computing ranks confidentiality first and treats downtime as a fair price for containment. Process control ranks availability first, because what it controls is physical — so quarantine can be the incident, patching waits for amaintenance window measured in months, and hardware specified for 20 to 30 years outlives every assumption made about it. Through July 2026 alone, activity was seen against over 100 internet-exposed systems in the water sector across at least seven states, degrading some operations. The method was not an exploit: a controller on a cellular modem, a known port, a default password, and a login. What needs fixing is exposure, not sophistication — and the operators concerned are frequently small utilities with no security staff at all.

What must never fail?

Three properties, six possible orderings, and every one of them describes a real place. Put them in the order your own organisation uses and the consequences follow.

Confidentiality, then integrity, then availability· the office default

Where it rules:
Office IT, and almost every security course.
What follows:
A suspected compromise is contained by disconnecting. Downtime is a cost worth paying to stop a leak, and encryption everywhere is an easy yes.
Where it collides:
Pulling a machine off the network to be safe. On a plant floor that same action can be the incident.

Availability, then integrity, then confidentiality· the plant default

Where it rules:
Process control: water, power, manufacturing, rail.
What follows:
The process must not stop, so patching waits for a maintenance window that may be annual, and anything that could interrupt the loop is refused by default.
Where it collides:
Automatic quarantine of an infected device, a standard response in an office, which here can shut a line or open a valve.

Integrity, then availability, then confidentiality

Where it rules:
Safety instrumented systems, medical devices, metering and billing.
What follows:
A wrong reading is worse than no reading, so the system is designed to fail into a known safe state rather than keep going on doubtful data.
Where it collides:
Keeping a sensor in service because the process needs it, when the sensor may be lying.

Availability, then confidentiality, then integrity

Where it rules:
Consumer services and public-facing platforms with little sensitive data.
What follows:
Being up is the product. Degraded but serving beats correct but dark, and correctness is repaired afterwards.
Where it collides:
Halting to investigate an anomaly, which is the right move where the numbers must be exact.

Confidentiality, then availability, then integrity

Where it rules:
Intelligence work, legal practice, anything where disclosure is the catastrophe.
What follows:
Secrecy first and continuity second, so systems are built to be shut and to leave little behind.
Where it collides:
Preserving evidence and logs, which conflicts with keeping as little as possible.

Integrity, then confidentiality, then availability

Where it rules:
Financial ledgers, elections, scientific record.
What follows:
The record must be right and demonstrably right, so nothing is accepted without a way to verify it later.
Where it collides:
Moving fast during an incident, since every correction must itself be auditable.

The office ordering and the plant ordering are exact reverses, and that single fact generates most of the friction between the two disciplines. A security team arriving from an office background proposes automatic isolation of anything suspicious and cannot understand the resistance; the engineers hear a proposal to stop a process on the word of a detection rule, which is a request they would refuse from anybody. Neither party is being unreasonable. They have different answers to what happens when something goes wrong.

What actually happened to the water utilities

Through July 2026 the American cyber defence agency recorded malicious activity against more than a hundred internet-exposed systems belonging to water and wastewater operators. Utilities in at least seven states reported incidents, some of which degraded operations, and a joint alert at the end of the month urged owners to take exposed controllers off the public internet without delay.

The mechanism deserves stating plainly, because it is so much duller than the subject usually sounds. A programmable controller or an operator screen is placed where it can be reached from outside, commonly through a cellular modem, so that a small team or a distant integrator can look after it. It answers on a recognisable port. Its password is the one it shipped with, or one chosen years ago. An attacker scanning for that combination finds it, signs in, and is then talking to the process itself: reading the screen an operator would read, altering a setpoint, changing the password so nobody else can get in, or simply switching the device off.

There is no exploit anywhere in that description. No memory corruption, no malware, no supply chain. It is a search and a login, which places these incidents at the opposite end of the spectrum from the state-level intrusions the sector's coverage usually concerns itself with — and makes them far more numerous.

The reason it keeps happening is not carelessness, and treating it as such guarantees no progress. Most community water systems are small operations without dedicated security staff, run by a handful of people who also handle treatment, compliance and the accounts. The controller is on a modem because that is how the site gets maintained at all by an integrator two hundred miles away. The exposure is a consequence of how the sector is staffed and funded, and any advice that does not start from that fact is addressed to somebody else.

Why does the standard advice not apply?

Patch promptly. Isolate anything suspicious. Replace unsupported equipment. Three pieces of advice that are correct almost everywhere and each of which collides with a physical constraint here.

Applying an update means restarting something that is currently doing a job, and the job is a treatment stage, a furnace or a press. Windows for that work are scheduled quarterly or annually and compete with production. Vendor approval is frequently required, because an unapproved change can void a warranty or invalidate a safety certification, and some equipment offers no update path whatsoever — the firmware is the firmware.

Isolation runs into worse trouble. Pulling a controller off the network mid-process can leave physical equipment in an undefined state, which is precisely the outcome the plant is engineered to avoid. Response procedures written in an office and handed to a plant tend to contain at least one instruction the engineers will refuse, and they are right to refuse it. Procedures that work are written with them, and they usually specify who has authority to stop a process rather than assuming the security team does.

Replacement is a capital project. Industrial hardware is specified for twenty to thirty years because the plant around it is, and a controller installed when the threat model was a locked door and a fence is now sitting on a network. Nobody chose that; the network arrived afterwards. Telling an operator to replace it is telling them to find several years and a budget they do not have, which is why the controls that actually get adopted are the ones that leave the device untouched.

When did the plant become reachable?

160 entries in this archive concern industrial and infrastructure security, distributed by year.

4201420201513201692017322018312019222020272021

The rise does not follow one famous incident. It tracks the years in which plant networks were joined to business networks so that production figures could reach a dashboard and a vendor could dial in — the change that turned a self-contained control problem into a reachable one. What the chart records is exposure growing, not adversaries improving, and that distinction is worth holding because exposure is the half an operator can still act on. The earliest piece here to name the convergence directly, Oil and gas cyber security upstream operational technology security, was already describing it as a business-critical problem rather than a technical curiosity.

What works when nothing can be touched

The constraint that defines this field — the equipment cannot change — also points at the answer. Every control that gets adopted in practice works by altering what surrounds the device rather than the device itself.

Removing direct exposure is first and it addresses the 2026 pattern exactly. An operator can find out today what of theirs answers from outside, because that is a question an outsider can already answer about them, and the tools to check are free. Where remote access is genuinely needed — and it usually is — it goes behind something that authenticates properly and records who connected, rather than being the controller's own login exposed to the world.

Segmentation is second and it is why the word appears in every document on this subject. Keeping the process network reachable only through few, controlled and watched paths does not require the controller to support anything, understand anything or be restarted. It is the one measure that respects the constraint completely, which is why it is worth more here than a dozen sophisticated controls that assume a modern operating system underneath.

Watching the process is third, and it is the one the field is least good at. A control system that is behaving oddly usually shows it in the process values before it shows it anywhere a security tool is looking: a setpoint that moved when nobody was scheduled to move it, a pump cycling at a rhythm it has not used before. That signal belongs to the engineers, who already know what normal looks like, and the useful arrangement is one where they have somebody to tell rather than one where a security team tries to learn the plant.

The company that built your plant still has a key

Almost nobody in this sector maintains their own control equipment. It was specified, installed and commissioned by an integrator, and that firm keeps a way in — because the warranty depends on them being able to diagnose faults, and because the alternative is a site visit for every alarm.

That relationship concentrates risk in a way the individual operator cannot see. An integrator serving fifty water systems across a region holds remote access to fifty plants, frequently through the same tooling and sometimes with the same credentials. Nothing about that is negligent; it is how a small firm supports customers who each need an engineer for two days a year. It does mean the interesting target is not the utility at all.

Operators can ask three questions that integrators are generally willing to answer, and that almost nobody asks. How does your engineer reach my equipment, and can I see a record of when they did. Is the credential they use shared with your other customers. And if you were compromised tomorrow, what would you be able to tell me about whether my site was touched. The answers are informative whichever way they come out.

The contractual version is duller and worth doing at renewal. Remote access granted for maintenance should be access that can be switched on for a job and off afterwards, rather than a standing connection nobody revisits, and the obligation to notify the customer of a compromise at the supplier should be written down rather than assumed. Neither costs the integrator anything they should object to.

Does it matter who is attacking?

Coverage of this sector divides its attackers into three groups, and the division is more useful to writers than to operators. There are state-aligned intrusions that establish access and wait, holding a position for years without doing anything visible. There is ransomware, which arrives through the business side and stops production because production depends on systems that are now encrypted. And there is opportunism: somebody scanning the whole internet who finds a controller answering and tries the obvious password.

The three demand very different responses from a national defence agency, and for a utility with four staff they collapse into one problem. Whether the person who signed into an exposed controller is a foreign service, a criminal crew or a curious teenager, the equipment was reachable and it accepted the credential. The measures that address that are identical in all three cases, which is worth saying because much of the sector's public discussion is framed around adversaries whose capabilities make the discussion feel hopeless.

Attribution does matter for one practical decision, and it is a legal one. Insurance policies commonly exclude acts attributed to a state, and the definitions are broad enough that attribution can be argued after the fact. An operator relying on a policy to fund recovery should read that clause before an incident rather than during one, because the same event may be covered or excluded depending on a determination made by somebody else entirely.

The other reason to keep the categories apart is timing. Opportunistic access gets used immediately, because its value is immediate. Access established for later is kept, which means an absence of visible damage is not evidence of absence. Utilities that have found long-dwelling intruders usually found them while looking for something else, and the intervals involved make the case for keeping logs that outlive a quarter.

What regulation can and cannot do here

Governments have responded to this sector the way they respond to most sectors: by writing obligations. European rules now reach a far wider set of operators than their predecessors and add management accountability with personal consequences; sector regulators in energy, water and transport publish their own requirements; and reporting deadlines for significant incidents are measured in hours.

For a large operator this works roughly as intended. There is somebody to receive the obligation, a budget line to fund it, and an audit that will notice if it is ignored. The rules move money toward work that would otherwise lose an internal argument, which is the mechanism this archive already shows working better than any demonstration of harm.

For the small operator the same instrument behaves differently. An obligation without funding is a document, and a community water system with four employees does not acquire an engineer by being told to. What tends to happen is that scarce time moves from the work to the evidence of the work, because the evidence is what gets inspected. That is not an argument against the obligations. It is an argument that obligations aimed at operators of that size need to arrive with something attached — shared services, funded assessments, or a regional body that does the work rather than checking it.

There is a related trap in how compliance frames the problem. A regime that asks whether controls exist rewards installing them, and nobody is asked whether the exposed controller was found, because that question does not appear on a form. The 2026 incidents happened at organisations that could largely have answered a questionnaire correctly, which is the recurring distance between conforming and being difficult to attack.

The objection from the safety engineers

There is a discipline older than this one that already owns the question of what happens when a plant misbehaves, and it does not use the word security. Functional safety concerns itself with preventing a machine from harming people, and its practitioners have spent decades building systems that fail into a known state and proving mathematically that they will.

Those proofs assume the equipment behaves as specified. That assumption holds against component wear, power loss and operator error, which is what it was built for, and it does not hold against an adversary who is choosing what the equipment does. A safety case demonstrating a one-in-a-million failure rate is describing chance, and an attacker is not chance. This is the genuine intellectual collision between the two fields, and neither side resolves it by conceding.

The practical friction is narrower and appears constantly. Equipment carrying a safety certification is certified in a specific configuration, so changing that configuration — including applying a security update — can invalidate the certificate until somebody reassesses it, at a cost and on a timescale nobody has budgeted. The engineer refusing the update is not being obstructive. They are defending a legal and moral position about the machine not hurting anybody, which outranks the concern being brought to them.

What resolves it in practice is the principle running through everything else here: leave the certified device alone and change its surroundings. Put protection in front of it, restrict what can reach it, and watch the process for signs that it is being told to do something nobody asked for. That approach concedes the engineer's point entirely, which is precisely why it is the one that gets adopted.

Common questions

Why is industrial equipment connected to the internet at all?

Because somebody needs to reach it and driving there costs a day. A small utility may be run by a handful of operators covering everything, with an integrator two hundred miles away, and a controller on a cellular modem is how the site gets looked after at all. The exposure is a consequence of a staffing reality rather than of carelessness.

What happened to water utilities in 2026?

Through July, CISA observed malicious activity against more than a hundred internet-exposed systems in the water and wastewater sector, most often programmable logic controllers reachable through a cellular modem. Utilities in at least seven states reported incidents, some of which degraded operations, and a joint alert followed at the end of the month urging owners to take exposed controllers off the internet.

How sophisticated are these attacks?

Mostly they are not. The controller answers on a known port, often with a default or unchanged password, and the attacker logs in and speaks to the process directly — reads the operator screen, changes a setpoint, changes the password, or takes the device offline. There is no exploit in that sequence. There is a search engine and a login form.

Why can't operational systems just be patched?

Because applying a patch means restarting something that is currently doing a job, and the job may be a water treatment stage or a furnace. Maintenance windows are scheduled quarterly or annually, vendor approval is often required to keep a warranty or a safety certification, and some equipment has no update mechanism at all.

What is the difference between IT and OT security?

The ordering of what matters. Office systems put confidentiality first and treat downtime as an acceptable cost of containment; control systems put availability first, because the thing they control is physical and stopping it has consequences a disconnection in an office does not. Nearly every practical disagreement between the two worlds follows from that reversal.

Is disconnecting a compromised system the right response?

In an office, almost always. On a plant, sometimes it is the incident. Isolating a controller mid-process can leave a valve, a heater or a press in an undefined state, which is why response plans in these environments are written with the process engineers rather than handed to them.

How old is the equipment in question?

Frequently older than the security profession's assumptions. Industrial hardware is specified for twenty to thirty years because the plant around it is, so a controller installed when the risk model was a locked door is now on a network. Replacement is a capital project measured in years, not a patch cycle.

Did Colonial Pipeline show that attackers can control physical systems?

No, and the distinction is the useful part. The incident hit business systems, and the operator halted distribution as a precaution — partly because billing was affected. The lesson is that the boundary between office and plant matters far less than organisations assume once the two are connected, which is a different and more common problem than direct manipulation of a process.

What is network segmentation and why does it come up constantly here?

It is the practice of keeping the plant network reachable only through controlled, few and monitored paths, rather than flat with the office. It dominates this subject because it is the one control that does not require touching the fragile equipment: it changes what can reach the controller instead of changing the controller.

Who is actually responsible for securing a small utility?

Often nobody whose job title says so. Most community water systems are small operations without dedicated security staff, where the same people handle treatment, compliance, billing and whatever the integrator left behind. Advice written for organisations with a security function does not survive contact with that reality.

Should a small utility buy specialist OT security products?

Usually not first. The equipment that monitors industrial protocols is genuinely capable and it assumes somebody will read what it produces, which is the resource the operator does not have. Removing internet exposure and arranging remote access properly costs nothing in licences and addresses the pattern behind the recent incidents; specialist monitoring earns its place once there is somebody whose job includes looking at it.

Does the integrator who built the plant still have access?

Almost certainly, because the warranty and the support arrangement depend on it. That concentrates risk in a way an individual operator cannot see: a firm serving fifty sites holds remote access to fifty sites, sometimes through shared credentials. It is worth asking how their engineers reach your equipment, whether the credential is shared, and what they could tell you if they were compromised.

What should an operator do first?

Find out what of theirs answers from the internet, which is a question an outsider can already answer about them. Removing direct exposure and putting remote access behind something that authenticates properly addresses the specific pattern behind the 2026 incidents, and it requires no change to the control equipment itself.

Does safety certification conflict with security updates?

Regularly. Equipment certified for a safety function is certified in a configuration, and changing that configuration can invalidate the certificate until reassessment. The result is a genuine standoff rather than an excuse, and it is resolved by compensating controls around the device rather than by arguing that the certificate should not matter.

Industry and utilities in the archive

160 entries, peaking in 2018 with 32.