Why Every Great Security Program Starts Messy (and That's Okay)
If you work in or around OT environments, you've probably lived this moment:
A cybersecurity initiative kicks off, leadership wants visibility, a vendor comes in with architecture diagrams and maturity models, and for a few weeks everything sounds clean and manageable. Then someone opens a cabinet on the plant floor, and the conversation changes entirely.
The network diagram doesn't match reality, there's a switch nobody knew existed, a contractor set up remote access years ago and nobody removed it because production depended on it. The PLC running a critical process hasn'tbeen touched in years, not out of negligence, but because everyone knows what happens if it goes down unexpectedly.
Then someone in the room finally says: “Alright… here’s how it actually works.”
But what this shows is that the team with ownership responsibility wasn’t part of the conversation to begin with. Operations teams, maintenance engineers, the people who actually run the plant, are frequently the last ones brought into a security initiative. When brought in, the conversation has already been framed by teams with minimal operational context, and that’s where most OT security programs go wrong before they’ve even started.
The Gap Between the Sales Pitch and the Plant Floor
OT security vendors and sales teams love clean stories: fully segmented networks, complete asset inventories, centralized visibility, Zero Trust, single panes of glass. The people responsible for keeping production running know the reality is rarely that neat, and they're right to be skeptical of anyone who pretends otherwise.
Industrial environments often evolve over decades. Systems are inherited through acquisitions, vendors leave behind temporary fixes that quietly become permanent, and operations teams make practical decisions under pressure because uptime matters. Maintenance teams build workarounds because production cannot wait for perfect governance processes. That isn't carelessness; that's the real world.
What makes it harder is that OT teams often carry genuine frustration, not from the complexity itself, but from being made to feel responsible for a situation they inherited, by people who have never actually stood on a plant floor trying to keep it running.
The Wrong Starting Point
Most security programs are designed around a version of the environment that doesn’t exist. They assume the site should already look mature, so when they encounter technical debt, flat networks, incomplete documentation, or pushback from operations, it gets treated as failure rather than as the starting point.
Teams that make real progress approach it differently; They treat the current state as information rather than a problem and use it to prioritize.
We worked with a manufacturer recently with multiple production sites, no centralized asset inventory, limited IT support on the ground, and maintenance windows twice a year, at best. Patching was nearly impossible, and the network was flatter than anyone was comfortable with. On top of this, remote access existed in more places than originally thought.
A program designed to fix all of that at once would have stalled. What actually moved things forward was a much simpler question: given everything we’re looking at, what would hurt this business most if it went wrong, and what can we realistically do about it right now?
The early work focused on building visibility into what was actually on the network, getting control over remote access, and establishing clear escalation paths for when something looked wrong. Not a transformation, but a foundation the team could build on and sustain.
That’s what a maturing OT security program actually looks like in practice: not a clean diagram, but a team that understands its environment well enough to know where to focus and has the confidence to act on it.
Why the People Side Is Non-Negotiable
There's one more thing that separates OT from IT security, and it's easy to underestimate. In IT you can often push updates, reboot systems, or enforce policy quickly. In OT, every change carries operational consequences. A poorly timed reboot can impact production, a blocked connection can interrupt maintenance, and a failed patch can create safety concerns that nobody in corporate security will be dealing with at 2am, but the plant team will.
Operations teams know this, engineers know this, and plant managers know this better than anyone.
OT security only works when the people designing the program are honest about those realities and build around them. The best environments we've seen aren't the ones with the most polished dashboards; they're the ones where operations, engineering, maintenance, and security trust each other to have honest conversations about risk. Most of the time, operators are the reason the environment still functions despite years of accumulated complexity. A good OT security program is built on that foundation rather than in spite of it.
You're Not Behind
If your OT environment feels messy right now, you are not behind. You're dealing with the same reality most industrial organizations face, whether they admit it publicly or not.
The goal isn't to wake up one day with a perfectly clean environment. The goal is to reach a place where the risks are understood, the priorities are clear, and the problems stop surprising you.
That's what real maturity looks like, and it almost always starts messy.
