Every infrastructure estate has systems that are difficult to restart: a database with a long recovery, an appliance with no cluster partner, a controller that everything depends on, a legacy application whose startup sequence is documented by one person.
These systems fall behind on patching, and the reason is never that nobody wants to patch them. It is that patching means rebooting and rebooting means an outage nobody will approve.
Name the constraint accurately
The problem is not the patch. It is the restart, and it is worth being precise about which restart:
Does the service need restarting, or the operating system? Many patches only require the former, and the distinction is frequently not checked.
Is there a live patching capability for the kernel? Several distributions offer it. It does not cover everything and it covers the frequent critical cases.
Is the restart itself the problem, or the recovery time after it? A system that restarts in ten seconds and then spends forty minutes warming a cache has a forty-minute outage, and that is what needs fixing.
Answering these turns “we cannot patch this” into a smaller, more specific problem.
The strategies
Build the redundancy you should have. Most of these systems are single points of failure that patching merely exposed. A cluster partner solves the patching problem and the availability problem together, and the availability argument usually gets funded more easily.
Live patching for the kernel, where the platform supports it and the vendor supports your configuration. Buys you months between reboots.
Blue-green at the system level. Build the replacement patched, switch, keep the old one until confident. Expensive in capacity and it removes the outage entirely. Best fit for things that are already virtual.
Compensating controls where nothing else is possible. If a system genuinely cannot be patched, reduce its exposure: network isolation, restricted access paths, tighter monitoring. Document this as a decision with a review date, not as a permanent state.
The register
Keep an explicit list: systems that cannot be patched on the normal cadence, the reason, the compensating controls, the owner, and the date this will be revisited.
This does three useful things. It converts a hidden risk into a visible one. It gives the owner a reason to fund the fix, because their name is on it. And it means that when an advisory lands on one of these, you already know which systems are affected instead of discovering it during an incident.
Systems drop off this list over time when the register is reviewed. Systems never drop off a list that does not exist.
The honest framing for the business
The conversation is usually presented as security versus availability, which invites a stalemate. It is more accurate to present it as availability versus availability.
An unpatched system is not stable, it is un-restarted. Its accumulated risk includes both a security exposure and a growing uncertainty about whether it would come back if it ever went down unexpectedly. A system that has not rebooted in three years is a system where nobody knows whether the startup configuration is still correct.
That framing tends to move things, because the fear of an unplanned restart is exactly what has prevented the planned one, and pointing out that the unplanned restart is getting more likely and more dangerous is the argument that lands.
The practice worth adopting
Reboot things on purpose, on a schedule, when nothing is wrong. A quarterly restart of systems that would otherwise never restart is a test of your recovery and a guarantee that the maintenance procedure is current.
It feels unnecessary right up until the day it is the only reason a system came back.