OS Version Is Not a Support Status

Google updated its Android 17 security release notes yesterday. Android 17 devices at security patch level 2026-07-01 or later are protected against the issues listed in that release. That sounds like ordinary patch administration until you compare it with the population enterprises actually have to govern.

Google's last public Android distribution snapshot, dated December 1, 2025, shows 42.1 percent of active Android devices on Android 12 or older. That number describes OS age, but it does not establish that 42.1 percent of Android devices are unsupported, because the security-maintenance window depends on the manufacturer and model.

That distinction is easy to lose in an enterprise inventory.

Your console may know the model, Android version, and the security patch level, and it may even call the device compliant. None of those fields necessarily answers whether the manufacturer has committed to delivering the next critical security fix to that exact device.

So this is the question I would put to a mobile program this week:

How many devices that touched company data are past manufacturer support, below your written OS floor, or sitting in a support state nobody has verified?

Signals & Moves You Shouldn't Ignore

1. Android 17's security notes were updated September 3, and the patch level is part of the claim

Google's Android 17 security release notes were updated September 3. Google states that Android 17 devices with a security patch level of 2026-07-01 or later are protected against the issues covered in the release.

This is a useful distinction for enterprise reporting. "Android 17" identifies the platform release while the security patch level identifies a different state of the device.

A device inventory that records only the first cannot establish the second.

SOURCE: Android Open Source Project, Android 17 Security Release Notes, updated September 3, 2026

2. Google's last public distribution snapshot puts 42.1 percent of active Android devices on Android 12 or older

Google's distribution metadata reports Android 12 at 11.4 percent, Android 11 at 13.7 percent and Android 10 at 7.8 percent. Releases older than Android 10 account for another 9.2 percent. Together, Android 12 and older represent 42.1 percent of the measured population.

The file is dated December 1, 2025, so I would not present 42.1 percent as a September 2026 market-share measurement. I also would not call that entire population unsupported.

The useful signal is narrower: a substantial portion of the Android population represented in Google's most recent public distribution file is running older releases, and OS version alone does not tell an enterprise which of those devices can still receive manufacturer security fixes.

That answer has to come from the device model and its support commitment.

SOURCE: Google Android Studio distribution metadata, last updated December 1, 2025

3. Google already defines the support field most enterprise inventories omit

Android Enterprise Recommended requires participating manufacturers to publish an SMR support end date, defined as the last month and year the device is guaranteed to receive security updates. Manufacturers also publish the frequency of those security updates.

That is much closer to the field an enterprise needs. The reason is visible in Google's own 2026 Android bulletins. In March, Google said there were indications that CVE-2026-21385 might be under limited, targeted exploitation. The March 5 patch level addresses the issues in that bulletin. In June, Google said CVE-2025-48595 might be under limited, targeted exploitation, and the June bulletin states that user interaction was not required for exploitation of the most severe Framework issue.

Those are March and June events, not September incidents. I am carrying them forward because they expose the operational dependency: once a vulnerability requires a platform or component fix, the enterprise needs to know whether that fix can still reach the device.

An employee cannot click more carefully and manufacture a security update the OEM no longer provides.

SOURCE: Android Enterprise Recommended requirements; Android Security Bulletin, March 2026; Android Security Bulletin, June 2026

The Control Gap

Most mobile inventories describe current state better than future supportability.

OS version tells you which platform release is installed.

Security patch level tells you which security patch set the device reports.

Your enterprise floor tells you which versions or patch states the organization currently permits.

The manufacturer's support end date tells you something different: whether the vendor is still committed to delivering future security fixes to that model.

Those fields should not be collapsed into one green compliance state.

A device can remain enrolled, authenticate normally and satisfy the policy currently configured in MDM while approaching the end of its manufacturer's security-maintenance window. Once support ends, the next significant vulnerability changes the remediation options available to the security team.

Patching may no longer be one of them.

The decision then becomes upgrade, replacement, access restriction, temporary exception or continued exposure without an explicit decision.

That last category is the one worth eliminating.

My Take

We've gotten very good at producing mobile compliance dashboards. I'm less interested in another green device count than I am in knowing what the green state actually proves.

Give me the model, the OS version, the installed patch level, the manufacturer's support end date, and show me the last time the device reached company data. Then show me who owns the decision when those facts stop satisfying policy.

Then you will have a much more useful security record than "compliant."

Some devices will stay connected after crossing a preferred floor but operations do not stop because security found an uncomfortable field in an inventory. A warehouse application may depend on older hardware while a contractor owns the device that procurement is staged to replace. Those can all be defensible operating decisions while an executive is traveling.

The weak position is allowing the device to remain because nobody converted the exception into an owned decision with conditions attached to it.

That is where I would focus.

— William

One Thing Worth Doing This Week

Run a Mobile Support-State Census.

Use one table with these fields:

Pull the population from your management console. Compare it with recent device and access signals from your identity layer where those records are available.

Include corporate-owned devices.

Include BYOD that reaches company data.

Include third-party devices where your access architecture exposes enough information to identify them.

Use Unknown when manufacturer support status has not been established. Do not turn the absence of evidence into a green cell.

When the census is complete, separate the population into four groups:

• Supported and policy compliant
• Supported but policy noncompliant
• Support status unknown
• OEM support ended

The last three groups need an owner and a disposition.

A supported device below your enterprise floor may need an update.

An unknown device needs investigation.

A device past manufacturer support may need replacement, restriction or an explicit exception.

The completed artifact should leave you with a count in every category and a named owner for every population outside the first one.

Field Notes

The census creates another problem because some devices in the last three groups will have legitimate reasons to remain connected.

That is the point where patch management turns into approval governance.

A scanner may depend on an application that has not been migrated. A contractor may control the equipment. Replacement hardware may already be ordered. A business owner may accept reduced access for thirty days rather than interrupt an operation today.

The decision itself is not unusual. Losing the conditions attached to it is.

An exception gets approved in a ticket. The business dependency changes. The expiration date passes. The device keeps connecting because the technical access outlived the reason that justified it.

I built Conditions of Approval to work that specific problem.

Take one device or cohort from the census that cannot be remediated immediately and document the operating decision: what is being approved, who owns the exception, which conditions justify continued access, what evidence has to remain true, and what change should force the decision back into review.

The support-state census identifies the exception.

Conditions of Approval keeps the exception from quietly becoming permanent architecture.

Run one real case: conditions.buildinhouse.com