Operating System Versions and Compatibility

A managed fleet converges on a version. A BYOD population never does. Accepting that and deciding the acceptable range is more productive than pretending convergence is achievable.

The operational issue in “Operating System Versions and Compatibility” is easier to diagnose when device state and work evidence remain separate. A team reviewing visit the official site for time tracking with screenshots can make time and project context visible, while endpoint tools remain the source of truth for security, software and hardware condition.

The two separate questions

Is the version still receiving security updates? This is the one that matters for risk and it has a clear answer from the vendor's support schedule.

For an independent reference relevant to “Operating System Versions and Compatibility”, consult the CISA mobile-device security guidance; compare its principles with the proposed ownership model, access rules and real support process.

Does the company software work on it? This is about compatibility and it has a different and usually narrower answer.

Policies conflate them, which produces requirements that are either too loose on security or too strict on compatibility.

Where to set the floor

Tie the security requirement to vendor support status rather than to a version number. "A version still receiving security updates" updates itself annually and never becomes stale, which a hard-coded number does.

Set the compatibility floor separately, from testing, and publish it. People can act on a published floor; they cannot act on a requirement nobody stated until their access stopped.

The device that cannot reach the floor

Older hardware stops receiving new major versions while still working perfectly well for everything else.

This is the point at which a BYOD arrangement forces a purchase, and it should be acknowledged as such. The options are the employer contributing, the employer supplying a device, or moving that person to browser-only access which has far lower requirements.

What should not happen is the requirement being quietly waived, which is the common outcome and which means the standard binds only the people who follow rules.

The grace period

A new major version appears and a share of the population installs it within days.

A stated grace period — company applications will support the new version within a defined number of weeks, please delay until then if you can — is honest and manageable.

An unstated one produces a support surge every autumn that nobody planned for.

Measuring the spread

Access logs give you the version distribution across connecting devices. One query, and it tells you how far the tail stretches.

Most organisations have never looked and are surprised by the answer. The tail is longer than expected and it is concentrated among the people least able to replace hardware, which is a fairness finding as well as a technical one.

What to publish

The security floor, expressed as supported-by-vendor.

The compatibility floor, expressed as a version.

The grace period for new releases.

Three lines, reviewed annually, and they answer most of what both the service desk and the employee need to know.

Publishing the floor rather than enforcing it quietly

People discover an unpublished compatibility requirement when their access stops working, which produces a support call and a justified complaint. The same requirement published in advance produces a planned upgrade. The difference costs nothing and most organisations do the first, because the floor exists in a technical configuration rather than in anything anybody wrote.

The tail and who is in it

Version spread is not randomly distributed. The oldest devices belong to the people least able to replace them, which means a hard cutoff applied without support falls hardest on the lowest-paid part of the workforce. Looking at who is in the tail before setting a deadline is a five-minute check with a fairness consequence.

Two floors, not one

Security and compatibility are different requirements with different sources and different consequences. Publishing them separately prevents the common confusion where somebody on a supported but incompatible version is told their device is insecure, which is both wrong and unhelpful.

The version nobody can reach

Hardware eventually stops receiving major updates while working perfectly. At that point a version requirement becomes a purchase requirement, and it should be handled as one rather than as a security matter. Which route the organisation takes — contribute, supply, or move to browser access — should be decided before the first person is stranded. Check your version spread this week. The number at the bottom end tells you how much of this section applies to you.