Securing Things That Can Crush You: Notes From the Factory Floor

For most of my career, the worst case for a breach was data — records stolen, systems down, a bad week and a hard quarter. Then I spent a couple of years securing heavy connected machinery, and the worst case changed. When your “endpoint” weighs several tons and can be operated remotely, the CIA triad stops being an abstraction on a certification slide. Integrity means the machine does what the operator intended. Availability means it stops when it’s supposed to. Confidentiality — the thing IT security obsesses over — drops to third place, because a stolen file doesn’t break a bone.

That reframes everything. In the office world, the question behind every control is “could someone see or take our data?” On the factory floor, the question becomes “could someone make this machine do something its operator didn’t command — or stop it from doing something they did?” Once that’s the question, a lot of comfortable IT habits fall apart.

IT security assumes you can patch. OT doesn’t.

In an office, if a laptop needs an update I push it and someone reboots at lunch. On the industrial side, “reboot” might mean halting a production line that costs five figures an hour, or pulling a machine out of service in the field where a technician has to physically drive to it. You can’t just apply a patch on Tuesday. You earn every single change through a maintenance window that people fight over months in advance, because downtime is measured in real money and sometimes in missed commitments to customers who don’t care about your CVE.

So the model inverts. In IT, patching is the front line — you fix the flaw and move on. In OT, patching is slow, expensive, and sometimes flatly impossible, so I lean far harder on the controls that don’t require touching the machine: segmentation, monitoring, and making sure the vulnerable thing simply can’t be reached in the first place. If I can’t fix it, I make it unreachable and I watch it like a hawk. That’s the trade.

The safety case outranks the security case

Here’s a mental shift that took me a while. In IT, security is usually the top priority in its own domain. In OT, security serves something higher: safety. The entire point is that people don’t get hurt. A control that makes the system more “secure” but interferes with an operator’s ability to safely shut a machine down in an emergency isn’t a good control — it’s a hazard. I had to learn to design with that hierarchy in mind, and to defer to the safety engineers on where that line sat, because they’d been living with the consequences a lot longer than I had.

Nobody drew the map

The other lesson: the network diagram is fiction. On one program I ran an automated discovery across the environment and turned up thousands of internet-facing applications and devices nobody had a current record of. Not a handful — thousands. That’s the norm, not the exception. Industrial environments grow by accretion over decades: a vendor adds a remote-monitoring box here, a contractor stands up a gateway there, a “temporary” connection from 2014 is still carrying traffic. The official diagram describes a system that stopped existing years ago.

You cannot secure what you don’t know exists, and in OT and IoT environments the gap between what the diagram claims and what’s actually plugged in is enormous. So before any clever controls, the unglamorous work is inventory. Find the things. All of them. Every time I’ve done this, the discovery phase alone changed the risk conversation more than any tool I bought, because you cannot manage a risk you didn’t know you were carrying.

Segmentation is the whole game

When you can’t patch and you can’t easily replace, isolation becomes your primary control. The industrial world has a language for this — zones and conduits, levels that separate the enterprise network from the control network from the actual machines — and the goal of all of it is the same: shrink what an attacker can reach if they land somewhere they shouldn’t. The internet does not need a path to a turbine. The billing system does not need a route to a programmable controller. Most of the catastrophic OT scenarios I’ve war-gamed came down to a flat network where something that should have been three hops from the machinery was, in reality, one.

Segmentation is unglamorous and politically annoying — it breaks convenient connections people quietly relied on — but it’s the control that keeps a compromise in one corner from becoming a compromise of the whole plant. I’ll take strong segmentation over a fancy detection tool in an OT environment every single time.

Monitoring what you’re not allowed to touch

Since fixing the machine after the fact is slow and expensive, seeing a problem early is worth a great deal. But you can’t always drop an agent on a decades-old controller, so the monitoring has to be passive — watching the traffic to and from these devices rather than living on them. The good news is that industrial systems are often beautifully predictable. A machine that talks to the same three systems in the same pattern every day makes anomalies stand out. When it suddenly reaches for something new, that’s not background noise the way it would be in a chaotic office network. That’s a signal worth chasing.

Safety and security finally shook hands

My favorite part of that world: the safety engineers already thought in failure modes and worst cases. They’d been doing threat modeling for decades — they just called it something else, and they did it with a rigor most cybersecurity teams would envy. What could go wrong, how badly, how do we prevent it, how do we fail safely when prevention doesn’t hold. That’s our discipline too; they just applied it to physics instead of packets.

The real win was getting security and safety in the same room, because a remotely exploitable machine isn’t a data problem or a safety problem — it’s both, and pretending otherwise is how people get hurt. When those two groups finally shared a threat model, we caught scenarios neither would have seen alone: the safety team understood how the machine could hurt someone, the security team understood how an attacker could trigger it, and only together could we see the whole path. That collaboration, more than any product, is what made the environment genuinely safer. It’s the lesson I carried out of the factory and never let go of.