There is a system in your estate that nobody changes. It works, it is important, the person who built it has left, and the last deployment was two years ago. Everyone has agreed, without discussing it, that touching it is riskier than leaving it.
That agreement has a cost, and the cost compounds. It is not running unpatched because anyone decided to accept the risk. It is running unpatched because deciding would require someone to own it.
This post is how to handle the system nobody touches. For whoever will eventually have to.
Why the freeze is rational and still wrong
The reasoning is sound in isolation. Nobody understands it, there are no tests, the build may not reproduce, and a failed change is an outage in something important. Under those conditions, not touching it genuinely is the lower-variance choice this quarter.
The problem is that the risk of not touching it grows monotonically. Every month adds advisories to components you cannot update, widens the gap between the running version and anything supported, and removes another person who remembers how it works. The variance is lower each quarter and the expected cost keeps rising.
At some point it is forced: an advisory too serious to ignore, a compliance requirement, a dependency that stops resolving, or a hardware or platform migration. The forced version is always more expensive than the chosen one, and it arrives on someone else's schedule.
Establish what it actually is
Before any decision, four facts. None require changing anything.
What it does, and what depends on it. Derive it from traffic and logs rather than from documentation. The list of consumers is usually shorter than feared and contains one surprise.
What it is made of. Operating system, runtime, libraries, with versions. Generate an inventory from the running artefact, because the repository may not describe what is deployed.
How it is reached. Is it internet-facing, internal-only, or reachable from a network segment nobody has audited. This single answer changes the urgency more than anything else on the list.
What it holds. Data classification, credentials, and what its identity can reach.
Four facts, a couple of days, and no risk of breaking anything. Most estates have never assembled them for their oldest system, which is why the conversation about it goes in circles.
Contain before you modernise
Rewriting is a project. Containment is a fortnight and it buys most of the reduction.
Reduce reachability. If it does not need to be internet-facing, put it behind something that is maintained. A maintained reverse proxy in front of an unmaintained application means the exposed parsing surface is the proxy's, which changes the picture substantially.
Narrow its credentials. An old system frequently runs with permissions granted when everything ran with everything. Removing what it demonstrably does not use is testable by observation and is usually the highest-value change available.
Watch it properly. It may be the system with the least monitoring and the highest risk. Authentication events, outbound connections, unusual process activity. If you cannot patch it, detection is what you have.
Back it up and rehearse the restore. If the plan when it breaks is to restore it, that plan needs to have been tried, because an unrehearsed restore of a system nobody understands is not a plan.
That sequence does not touch the application at all, which is what makes it possible to agree to.
Then pick an honest strategy
Four options, and the mistake is not choosing:
Maintain it. Assign an owner, get the build reproducing, add tests around the interfaces, patch on a schedule. Viable when the system is genuinely stable and someone can be found to own it.
Wrap and shrink. Put an interface in front, move functionality out piece by piece, let the old system shrink. Slow, low-risk, and the usual answer for something large.
Replace. A real project with a real budget, justified when the system blocks something the business wants.
Retire. Sometimes the consumers have gone and nobody checked. This is the outcome the traffic analysis occasionally hands you, and it is the best one available.
Write the choice down with an owner and a date, because the failure mode is not choosing badly, it is leaving it implicit and calling that stability.
Record the acceptance
If the decision is to run it as it is for now, that is a risk acceptance and it should look like one: what the exposure is, what compensating controls exist, who accepted it, and when it will be reviewed.
An undocumented freeze is indistinguishable from nobody having noticed, and after an incident the difference between those two matters enormously, to your customers and to anyone assessing you.
The concession
Sometimes the right answer genuinely is to leave it alone for another year. A system with no network exposure, no sensitive data, narrow credentials and a working restore path is not where your attention should go, and modernising it because it is old is effort spent on tidiness rather than risk.
That is a defensible position and it is a different thing from the default. The difference is whether someone looked, and whether the answer is written down with a date on it.
The implication
The oldest system in most estates is unpatched not because anyone judged the risk acceptable, but because judging it would require ownership that nobody has.
Assembling the four facts costs a few days and converts a standing unexamined exposure into a decision. The decision may well be to wait, and that is fine, as long as it is one.
