From Automation Engineering to OT Security: Five Risks to Watch

At Tier16, we sit across the table from operators who are all wrestling with the same underlying problem: keeping systems running safely, continuously and securely, on technology that was often designed and installed long before today’s threat environment existed.

We tend to see both sides of this problem at once: the engineering reality of what a system can safely tolerate, and the security reality of what it actually needs. Most of the risk we find sits in the gap between those two views. Below are the five patterns we encounter most often, framed as the questions we’d want an operator to be able to answer.

1. Is your control system infrastructure quietly becoming obsolete?

We regularly walk into environments where PLCs, RTUs, SCADA systems, HMIs and industrial networking equipment have been in service for 10 to 30+ years. In our experience, age itself is rarely the real issue – it’s what age brings with it:

Manufacturers have withdrawn support for the platform
Replacement parts are scarce, slow, or expensive to source
The operating system or firmware is no longer supported
The hardware can’t support modern security controls even if you wanted to add them
Patching risks disrupting a live process
Deep knowledge of the system sits with one or two people, in or out of the business

The operator is left choosing between running something insecure or shutting down a critical process to fix it

What we typically find is a form of technology debt: the immediate operational risk of touching the system looks worse than the risk of leaving it alone, so replacement keeps getting pushed back, sometimes for years past the point it should have been addressed.

What we’d ask first: if we mapped every asset by age and support status today, how many would already be past end-of-life? This is usually one of the first things our team does on a new engagement, because it reframes the conversation from “is this urgent” to “how urgent, exactly.”

If you want a starting point, our PLC obsolescence check and SCADA upgrade check are built for exactly this question.

2. If your OT environment were attacked, what would actually happen?

We spend a lot of time explaining this distinction to clients moving from an IT security background: in IT, a breach usually means data loss or a ransom demand. In OT, the chain runs further – loss of control can flow directly into interrupted physical processes, with safety, environmental, financial or public-service consequences attached.

The attack surface we assess typically includes:

PLCs and SCADA servers
HMIs and engineering workstations
Remote-access systems and VPNs
Industrial networks and historians
Third-party and vendor connections
Poorly secured legacy devices

The part that catches teams out is that you can’t respond to an OT incident the way you’d respond to an IT one. You can’t take everything offline and patch it. Every response has to weigh security against availability, safety and production at the same time, which is why we design controls with operations engineers in the room, not just security staff.

What we’d ask first: do you currently know how a compromise in one part of the network could reach the plant floor, and who has the authority to isolate equipment if it does?

3. If your control system disappeared tomorrow, could you actually rebuild it?

This is one of the biggest gaps we find, and it’s rarely intentional – it’s usually the result of backups that were set up once and never revisited. The questions we ask on every engagement:

Are PLC programs, SCADA configurations and HMI configurations actually backed up?
Are engineering workstation images and network configurations captured?
Are firmware versions documented and software licences on hand?
Are backups isolated from ransomware, and have they ever been tested for a real restore?
How long would a full rebuild take, and who on your team actually knows how to do it?
What happens if the original engineering software is no longer supported or licensed?

We treat an untested backup as an assumption, not a recovery capability, until proven otherwise. The question we push clients toward isn’t “do you have a backup” – it’s whether the plant could genuinely be restored, and inside a timeframe the business can tolerate. That’s the shift from cybersecurity thinking to cyber resilience thinking, and it’s a distinction we build into every recovery plan we write.

What we’d ask first: when did you last test a full restore, and did it work?

4. Do you actually know what’s connected to your network right now?

Visibility is where we most often see well-intentioned programs quietly fail. The questions we help operators answer on an ongoing basis:

What assets genuinely exist, and what firmware are they running?
Which assets are obsolete or approaching failure?
What’s changed recently, and who accessed what?
Are unexpected devices appearing, or is traffic behaving differently?
Is anyone making unauthorised configuration changes?

In our experience, documented network diagrams are almost always out of date. They describe the network as it was designed, not as it exists after five or ten years of contractor changes, quick fixes and additions. We also consistently see a visibility gap between IT and OT – the IT security team has strong coverage of laptops, servers and cloud infrastructure, and comparatively little insight into the actual industrial control environment. Closing that gap is usually one of the highest-value, lowest-disruption things we do for a client.

What we’d ask first: does your current asset inventory reflect what’s actually on the network, or what was documented when it was first built?

5. What happens when the people who understand your systems leave?

This is the risk we find most often overlooked, and the one that tends to surprise clients most when we point it out. Industrial infrastructure runs on accumulated, undocumented knowledge held by specific individuals:

We’ve seen organisations discover – at the worst possible moment – that the knowledge needed to operate or recover critical infrastructure existed only in someone’s head. When that person retires, moves on, or is simply unavailable, the gap shows up immediately.

Combine legacy technology, undocumented configuration, a shrinking specialist skills base and cyber risk, and you have a single point of failure that no amount of technology spend on its own will fix. Documentation and knowledge transfer are as much a part of our SOCI and resilience work as any technical control.

What we’d ask first: if your most experienced OT person left tomorrow, what would you lose that isn’t written down anywhere?

How we bring this together

In our experience, these five risks are never really isolated – they reinforce each other. Obsolete equipment is harder to secure, poor visibility makes it harder to track, undocumented knowledge slows recovery, and weak recovery raises the stakes of every other gap.

None of these questions has a quick answer, and that’s the point. Fixing one gap tends to help another. View our services to see how we help you work through these questions in practice.