AI Didn't Break Defense in Depth. It Made It the Only Thing That Still Works.

There is a question we get asked often in every plant we walk into, usually somewhere between the coffee machine and the control room:

"If the attackers now have AI, does any of our old security still count for anything?"

It's a fair question, and the honest answer surprises people. Yes. More than ever. But not the way most people think.

AI hasn't invented new attack paths into industrial installations. The paths are the same ones we've been writing reports about for over a decade: the flat network, the unpatched HMI, the engineering laptop that goes home in the evening, the vendor with permanent remote access and a shared password. What AI has changed is speed. Reconnaissance that used to take an attacker two weeks now takes an afternoon. Phishing mail that used to be recognizable by its clumsy Dutch now arrives in fluent Dutch, French and English, in the writing style of your own plant manager, referencing a real project by name. The window between a vulnerability being published and an exploit being usable has been compressed.

So, the question is no longer "can they get in." Assume they can or already are... The question is: what happens next, and how long does it take?

That is a question about layers, and here’s why:

1. Layers buy you the one thing you cannot buy in a plant: time

In IT, patching is a Tuesday. In OT, patching is a tense negotiation.

You have a patch window twice a year if you're lucky. You have a vendor who will void support if you touch the system. You have a PLC that hasn't been rebooted since the previous decade and nobody is entirely sure what will happen when it is. Meanwhile, the CVE is public, and thanks to AI-assisted exploit development, weaponized code exists within days rather than weeks.

You are going to run that vulnerable system for another eleven months. That's not negligence; that's continuity, financial bottom line and contracts.

Layered security is what makes those eleven months survivable. The unpatched HMI sits behind a segmented zone. The zone is reachable only through a conduit with an inspecting firewall. The account that could reach it needs to go through a jump host with MFA. Nothing there fixes the vulnerability. All of it buys time.

Time is the currency of industrial defense. Every layer is a purchase order for more of it.

2. When one layer fails, it should be a bad day, not a bad year

Single-layer security fails like dropped glass: instantly and completely.

We’ve seen the flat-network version of this more times than not. A user clicks on an attachment, and because the office network and the production network are separated by nothing but optimism, the incident goes from "restage a laptop" to "we cannot ship product this week."

Assume the click will happen. With AI-generated lures that are contextually perfect, personalized, and grammatically flawless, "the user will click" is no longer a training failure. It is a design assumption. Build for it.

This is exactly what IEC 62443 zones and conduits are for, and why the standard has aged so well. The point of a zone isn't that it's impenetrable. The point is that when it falls, only it falls. Your blast radius becomes a design parameter instead of a surprise.

Ask yourself, honestly: if my most-clicked-on colleague is compromised at 09:00 on a Monday, what is physically unreachable by 09:05? If the answer is "nothing in particular," you don't have layers. You have one layer that you've been describing optimistically.

3. Use different technologies per layer, or you only have one layer wearing several hats

Here's the trap in buying a single vendor's stack from the perimeter to the PLC: a single flaw or a single set of stolen admin credentials can undo all of it at once. Three layers with a common failure mode are really just one layer with extra license costs.

Diversity is deliberately inefficient, and that is the point. Using a different vendor at the perimeter than in the cell zone. A different authentication path for engineering access than for office access. And detection that doesn't depend entirely on the same agent your prevention depends on.

This applies with force to AI-based tooling. AI-driven anomaly detection is genuinely useful in OT, because industrial traffic is repetitive and deviations stand out beautifully. But it also fails in ways that are hard to predict, hard to explain to an auditor, and easy to poison with slow-drift traffic that teaches the model that "abnormal" is the new normal.

Use it.

Do not make it your only witness. A model is just one layer, not a complete solution.

4. Monitor at every layer, because you don't get to choose where you'll spot it

Most organizations monitor where monitoring is easy: the perimeter, the domain controllers, the endpoints they own. Then the intrusion is found in the one place nobody was watching — usually because an operator noticed something that "just felt wrong" about a set point.

Every layer you build is also a sensor you can read. A firewall between zones is a control, and it's also a source of truth about who tried to cross and failed. A jump host is a gate and a logbook. The process layer itself is the most underused detector in the entire plant: a command can be perfectly valid protocol-wise, correctly authenticated, and still be operational nonsense. No IT security tool will ever flag it. A process historian and an engineer who knows the plant will flag it in seconds.

This is where AI genuinely helps the defender rather than the attacker. Correlating weak signals across many layers is precisely what machine learning is good at, and precisely what a tired analyst at 02:00 am is bad at. But correlation across layers requires that you are collecting from every layer.

Feed it perimeter logs only, and you have bought an expensive way to learn about perimeters.

5. Crown jewels first, and in a plant they are rarely data

In IT, crown jewels are usually data. In an industrial installation, they usually aren't. They are the ability to run safely, the ability to run at all, and the recipe or process know-how that took twenty years to tune.

That distinction changes where your layers go.

Protecting a database is a different exercise from protecting the physical integrity of a process. Your Safety Instrumented System deserves its own separated existence with the fewest possible paths to it, not shared infrastructure with the reporting network because it was cheaper at project time.

A simple exercise that consistently produces uncomfortable clarity: list your top five plant consequences in plain language.

People get hurt. We stop production for a week. We ruin a batch worth six figures. Our process IP leaks to a competitor. We breach our license to operate.

Then count the layers between an external attacker and each one. Not the layers you designed years ago. The layers that exist today, with today's remote access, today's vendor connections, today's cloud dashboards someone suggested last quarter.

Where the count is lowest, that's your next investment. Not where the newest product is.

The three-question layer test

If you take one practical thing from this, make it this one. For every control you have, ask three questions:

1. What does it stop?
2. What does it tell me when someone tries?
3. What is still true if it fails completely?

A control that answers all three is a layer. A control that answers only the first is a single point of failure that you're feeling good about. Run this across your architecture on a whiteboard, and the gaps will find you within the hour — no tooling, no budget and no consultant required.

Where this leaves us

AI has made attackers faster, cheaper and more convincing. It has not made them all-knowing or invincible, and it has not made defense in depth obsolete.

If anything, it has settled a long argument: prevention was never going to be perfect, and now the margin for pretending otherwise is gone. What remains is architecture — layers, separation, monitoring everywhere, and clarity about what actually must not fail.

The good news for industrial environments is that this was already the right answer. IEC 62443 has been saying it for years. AI just removed the option of ignoring it.

Over to you: if your most-clicked-on colleague were compromised tomorrow morning, how many layers stand between that laptop and your most critical process? Curious to hear where people land — the honest answers are usually lower than expected, and the conversation is worth having before someone else runs the test for you.