There’s a real tension in keeping devices updated, and pretending it doesn’t exist helps no one. Updates fix security holes, which means applying them protects you. Updates also occasionally break things, which means applying them carries a risk of its own. For an individual that risk is usually trivial, but for an organization running many devices, or anyone depending on a device that absolutely cannot fail, the update dilemma is genuine. Here’s how to think about it without landing on the dangerous answer.

Why updates are not optional

Start with the part that isn’t actually negotiable. The overwhelming majority of real-world compromises exploit known vulnerabilities that already have patches available. The hole was found, the fix was shipped, and the victim simply hadn’t applied it. That means a device running old software isn’t in a neutral, steady state. It’s accumulating known, published weaknesses that attackers can look up. Deferring an update isn’t staying still, it’s falling behind a clock that attackers are watching.

Why the dilemma is real anyway

So why hesitate at all? Because updates are software changes, and software changes sometimes break compatibility, change behavior, or introduce new bugs. An organization that pushes an update fleet-wide and discovers it breaks a critical workflow has a real problem, and the operator of a system that must not go down has a legitimate reason to be cautious about any change. The instinct to not touch a working system isn’t stupid. It’s just dangerous when applied to security, because the working system is quietly becoming vulnerable while you protect its stability.

How to resolve it

The resolution isn’t to choose stability over security, it’s to manage the risk so you can have both. For organizations, that means testing updates on a small set of devices before rolling them out widely, so compatibility problems surface in a controlled way rather than across the whole fleet. It means having a path to apply security updates promptly even when larger feature updates are staged more cautiously, because not all updates carry the same urgency. And it means a hard rule that updates can be delayed for testing but not deferred indefinitely, because indefinite deferral is just being unpatched with extra steps.

The end-of-life trap

The dilemma has a final form that isn’t really a dilemma at all: the device that has stopped receiving updates entirely. Once a phone is past its support window, there are no more patches coming, and every new vulnerability discovered after that date is permanent. This is the dangerous state, and it sneaks up on organizations and individuals alike because the device still works. A phone that still turns on but no longer gets security updates isn’t a working phone in any sense that matters for security. It’s a known-vulnerable device on a countdown, and the only fix is to replace it. This is one reason the length of a device’s update commitment is worth checking before you buy, not after.

What it comes down to

For almost everyone, almost always, the security risk of not updating dwarfs the stability risk of updating, so the default should be to update promptly and only deviate for a specific, considered reason. Manage the dilemma where it’s real, in fleets and critical systems, with testing and staging rather than avoidance. And treat an end-of-support device as the actual emergency, because the dilemma between security and stability at least has two live options. A phone that can no longer be patched has only one.

Related reading

• Secure Phone Maintenance: What Not to Do
• Buying Hardened Phones at Scale: A Procurement Guide
• Secure Boot: What It Does and Doesn’t Guarantee