You Can’t Secure What You’re Not Allowed to Touch

Every glossy security strategy assumes you get to make changes. Real environments aren’t like that. Somewhere in your company is a system that’s ancient, critical, and completely off-limits — the one the whole business runs on, that nobody fully understands anymore, that will absolutely break if you touch it. The person who wrote it retired years ago. The documentation is a myth. And it processes something that would stop the company cold if it went down for a day. I’ve spent a lot of my career securing exactly those systems, and they taught me a kind of security that the modern-stack crowd never has to learn.

The stuff you can’t patch

Early on I worked with mainframe and midrange platforms — genuinely important, genuinely old, and not remotely interested in your modern tooling. You can’t just push an agent to them. You can’t take them down for a maintenance window without a small war, because “down” means the business stops. The vendor may not even issue patches anymore, and if they do, applying one is a project with its own risk of breaking the thing you were trying to protect. The playbook that works for a fleet of cloud servers — scan, patch, redeploy, repeat — is useless here, and pretending otherwise just makes you look naive to the people who keep the thing alive.

And those people matter enormously. There’s almost always a small group who understand the old system in their bones, who’ve kept it running for a decade, and who have watched a parade of confident newcomers propose changes that would have taken it down. If you walk in treating their system as a problem to be modernized away, you lose them — and you need them, because they’re the only ones who actually know what’s safe to touch.

Wrap what you can’t change

When you can’t secure the system itself, you secure everything around it. If the box is a fortress you’re not allowed to renovate, you build a wall around the fortress and control every door. Tight control over who and what can reach it — because the fewer paths in, the fewer ways it can be attacked. Heavy monitoring on the traffic in and out, because if you can’t fix the box you’d better watch it like a hawk and know instantly when something talks to it that shouldn’t. Segmentation, so a problem next door can’t wander over and reach it.

It’s not elegant. It’s the security equivalent of building a fence around something you’re not allowed to renovate — compensating controls, in the language of frameworks. But done seriously, that ring of controls can bring the real risk of an unpatchable system way down, sometimes lower than a “modern” system that’s patched but wide open on the network. The control you can’t apply to the box, you apply to its surroundings.

Know exactly what it touches

The most dangerous thing about these old systems usually isn’t the system itself — it’s the tangle of connections that grew around it over the decades. The forgotten integration. The flat network segment where it sits next to things it should never be able to reach. The credentials shared with it in 2009 that still work. So a huge part of securing legacy is mapping reality: what actually connects to this thing, what can reach it, what does it reach. Every time I’ve done that inventory honestly, I’ve found paths nobody knew were there — and closing those quiet paths often reduced risk more than anything I could have done to the box itself.

Plan for the day it finally has to move

Wrapping a legacy system buys you safety, but it doesn’t buy you forever. These systems don’t get less risky with age, and one day the business will have to modernize or replace it — usually under pressure, sometimes after a scare. Part of mature legacy security is being honest that the fence is a holding action, not a permanent answer, and quietly making the case for eventual modernization before it becomes an emergency. I’ve learned to protect the old thing well and keep gently reminding leadership that “well-protected” isn’t the same as “solved.”

Mature security isn’t about the environment you wish you had — the clean, modern, fully patchable one from the vendor slides. It’s about protecting the one you’ve actually got: legacy, constraints, tribal knowledge, and all. The teams that do this well aren’t the ones with the newest stack. They’re the ones who can look at a forty-year-old system that can’t be touched and calmly build the safety around it that it can’t provide for itself. That’s not a lesser kind of security. Some days it’s the hardest kind there is.