When should organisations stop supporting older devices and browsers?

When device and browser retirement becomes a security decision

The cutoff point is usually when the risk profile of older platforms outweighs the business value of keeping them alive. At that stage, support is no longer just a compatibility choice, it becomes a control decision about exposure, maintenance burden, and how much legacy access the organisation is willing to tolerate.

Legacy operating systems and browsers are harder to secure because they lose vendor fixes, fall behind modern hardening features, and often force exceptions in policy, telemetry, or application design. That is why retirement planning should be tied to measurable usage, not sentiment or habit.

Older platforms also tend to accumulate exploitability over time. As modern browsers and devices add sandboxing, stronger isolation, safer defaults, and better update mechanisms, unsupported or outdated platforms remain stuck with weaker assumptions and a larger set of known attack paths.

What signals say support should end sooner rather than later

The most practical trigger is not age alone, but evidence that the platform is creating a distinct security burden. If it needs custom exceptions, manual patching workarounds, or prolonged vendor deferral just to keep services stable, the residual risk is usually rising faster than the user value.

Retirement should accelerate when telemetry shows the platform is disproportionately represented in risky activity, such as abuse, malware delivery, fraud, or repeated security incidents. At that point, continuing support preserves a weak edge of the environment for an increasingly small audience.

Support should also end sooner when the platform cannot meet current authentication, encryption, or browser security expectations required by internal policy or external regulation. If a device or browser cannot participate safely in the organisation’s baseline, it is already outside the intended control model.

How to phase out support without creating avoidable disruption

Good retirement programs use a staged approach: inventory the affected population, announce the deadline early, provide a clear upgrade path, and define a narrow exception process for genuinely critical cases. The point is to shrink legacy exposure predictably, not to surprise users into noncompliance.

Teams should separate business-critical legacy dependencies from convenience-based resistance. If an application only works on an old browser because it was never modernised, that is an application remediation problem as much as a device lifecycle issue. If a niche workflow truly needs temporary support, constrain it tightly rather than letting the exception become the default.

Browser and device retirement is easiest when it is linked to standard operating controls, not ad hoc enforcement. Organisations should align rollout timing with patching windows, asset refresh cycles, and access policy changes so that the change is absorbed as part of normal governance rather than treated as an emergency.

Risk and Threat Considerations

Continuing to support old devices and browsers extends the life of weak security assumptions. Unsupported platforms often sit closer to known exploit chains, and they are harder to monitor, harder to harden, and more likely to be targeted when attackers know they can rely on unpatched behaviour.

Failure mechanism: Legacy platforms retain exploitable software defects, weaker browser isolation, and outdated security controls, while exception handling creates policy drift and expands the number of trusted-but-unsafe access paths.

Impact: The organisation absorbs greater compromise risk, larger support overhead, and more operational complexity, especially when the same old platform is used to reach high-value internal systems or sensitive web applications.

Practitioner Guidance

What to prioritise: Use usage and exposure together. A small but high-risk cohort may justify forced retirement sooner than a larger low-risk cohort, especially if the older platform is used for privileged or externally exposed workflows.

What to verify: Confirm that retirement decisions are based on real telemetry, not only product age. The key question is whether the platform still contributes meaningfully to business value without forcing security exceptions that would be unacceptable on current platforms.

Common mistake: Treating “still works” as a support criterion. If continued support depends on compensating controls, exceptions, or degraded protection, the organisation is already paying a security tax that should be made explicit.

Practitioner takeaway: The right cutoff is when the old platform can no longer justify the risk it adds relative to the users it still serves, and the exception process should be treated as temporary unless there is a strong, measurable business reason.

Related resources from NHI Mgmt Group

• How can organisations reduce the risk of stale API keys and machine tokens?
• What breaks when organisations cannot see AI agents across devices and browsers?
• What happens when browsers stop supporting a legacy TLS cipher like RC4?
• Why do older devices and browsers increase application abuse risk?