Mobile OS Update Management Guide: Version Floors, Deferrals and Access Gating for iOS and Android

Most mobile fleets can tell you which devices are out of date, but few can make an out-of-date phone stop reaching corporate data within a set number of days. Phones and tablets receive security fixes every month, users can postpone them, manufacturers ship them on different schedules, and the controls to enforce them changed again in 2026 when Apple removed its legacy software update restrictions in the version 27 releases. This guide covers the update operating model for iOS, iPadOS and Android: how to set minimum version floors, how much deferral to allow and for which rings, and how to connect update state to access decisions so that the floor actually bites. It is written for endpoint, mobility and vulnerability management teams. General MDM design is in the Mobile Device Management Security Guide and wider mobile controls are in the Mobile Device Security Guide; this page goes deeper on updates only. Where MDM products are named as examples, they are listed alphabetically and the order is not a ranking.

Key takeaways

• Three controls, one policy. Deferral decides when devices see an update, enforcement decides when it must be installed, and compliance decides what happens to access if it is not. Design them together or one will undo the other.
• Apple's update controls are now declarative. The legacy forceDelayedSoftwareUpdates and enforcedSoftwareUpdateDelay restrictions were deprecated in iOS 26 and removed in iOS 27; deadlines and deferrals now come from the software update declarations.
• On Android, patch level beats version number. Monthly security bulletins and manufacturer schedules mean two phones on the same Android version can be months apart in fixes, so gate on the security patch level date.
• Deferral is a testing window, not a policy. Keep it short for most devices, use it only in rings, and always pair it with an enforcement deadline so a deferred update cannot become a skipped one.
• Gate in steps, not at a cliff. Warn, then grace, then block corporate access, with a faster lane for actively exploited flaws and a replacement plan for devices that can no longer update.

Why mobile updates need their own operating model

Mobile breaks the desktop assumption that the organisation controls when an update installs, in four ways.

• The user holds the restart: an update needs battery, storage, network and a restart. Apple's deployment documentation sets a 20 per cent battery minimum for user-initiated updates and 30 per cent for automatic updates, and devices need to be on power to download and prepare an automatic update. A deadline therefore has to allow for phones that are never left on charge at the right time.
• Supply is uneven on Android: Google publishes the Android Security Bulletin on the first Monday of each month, notifies partners at least a month before publication, and each manufacturer then ships fixes on its own timetable. Some components, such as Telephony and Wi-Fi in the October 2026 bulletin, arrive as Google Play system updates instead, which download automatically but only install at the next reboot.
• Ownership limits control: on a personally owned device enrolled with a work profile or user enrolment, the organisation can usually observe the OS version but cannot force the device to update. The only lever is access.
• Exploits target the OS directly: browser engine and kernel flaws on phones are used for drive-by and zero-click compromise. MITRE ATT&CK for Mobile tracks these as T1456 Drive-By Compromise, T1658 Exploitation for Client Execution and T1404 Exploitation for Privilege Escalation, and Apple products appear frequently in the CISA Known Exploited Vulnerabilities catalogue. See the CISA KEV Catalogue Guide.

NCSC device guidance sets the tone: install updates promptly, ideally within a few days, enforce automatic updates through MDM because users can often defer or decline them, monitor update state through MDM logs or compliance policies, and consider restricting access from out-of-date personal devices.

The update controls on each platform

The table lists the operating system mechanisms that every MDM product builds on. Your console will present them under its own names.

On Android, manufacturers or carriers may exempt important security updates from postponement, so a postpone policy does not guarantee nothing installs.

Setting the minimum version floor

A floor is the oldest state a device may be in and still reach corporate resources. Write it as a rule, not a number, so it moves on its own.

iOS and iPadOS

• Floor rule: for example, "the latest minor release of the current major version, with a grace period after release", plus a separate floor for the previous major version for devices you have chosen to hold back. Apple still ships updates for some older branches, but Background Security Improvements reach only the latest versions, so a held-back fleet receives fewer interim fixes.
• Updates versus upgrades: Apple calls 26.7 an update and 27 an upgrade. Floor on updates; upgrades can follow a slower compatibility plan.
• Supplemental builds: the enforcement declaration installs exactly the version set in TargetOSVersion and will not install a patch release if only a minor version is set. A supplemental build such as 16.1 (a) installs only on a device already on the base version, so moving from an older base needs two enforcement declarations in sequence.

Android

• Floor on patch level: set a minimum security patch level as a date in YYYY-MM-DD form; MDM compliance policies offer this for fully managed, dedicated, corporate-owned work profile and personally owned work profile devices. The bulletin states that a device at a given patch level or later addresses all issues for that level and for earlier bulletins.
• Two strings per bulletin: a monthly bulletin can carry two patch level strings (a -01 and a -05 level) so partners can ship a common subset of fixes sooner. Base your floor on the date, not on a specific string, and expect devices to report either.
• Version floor as well: keep a minimum Android version too, because an old major version can have a recent patch date while missing platform protections introduced in later releases. See the Android Enterprise Security Guide for the bulletin model and management modes.

Maximum versions block devices that move ahead of what your apps support. Use one only for a few days around a major release, then remove it.

Deferral and rollout rings

Deferral exists so you can test a release before it reaches everyone. On iOS, supervised devices can hide new major and minor releases for 1 to 90 days through CombinedPeriodInDays; Background Security Improvements are not affected by that deferral. On Android, a fully managed device can postpone a given update once for 30 days. Neither control stops the release forever, and both should be used per ring.

These timings are a starting point to agree with risk owners, not a standard; NCSC's "within a few days" is the benchmark for urgent fixes. For major version upgrades, use the full deferral to test apps and VPN, certificate and single sign-on profiles, but set the enforcement deadline in the same change ticket so the upgrade has an end date. The Patch Management Guide covers how to set and justify remediation windows across the estate.

• Freeze periods with care: a freeze suspends all OS updates and manual checks, so a 90-day freeze holds back three monthly bulletins.
• Notifications: Apple's Notifications key, when false, shows only the notification one hour before the enforcement deadline and the restart countdown. Consider false only for shared or kiosk devices. See the Kiosk and Shared Device Security Guide.

Compliance-to-access gating

Enforcement fails silently on devices that are off, out of battery or personally owned. Compliance is the backstop: a device below the floor loses access to corporate resources until it updates. It only works if the identity provider actually requires a compliant device for those resources. See the Conditional Access Guide.

• Grace per signal: grace for update floors, none for integrity failures or detected threats.
• App-level checks for BYOD: where personal devices are not enrolled, app protection policies can check minimum OS version and, on Android, minimum patch version at app launch, and warn, block or wipe app data. This is the only gate available for unenrolled devices.
• Attestation strengthens the signal: reported OS versions come from the device. On Android, Play Integrity verdicts add a check, and the strong verdict uses hardware-backed signals that not every device can return, so test before requiring it. On Apple devices, managed device attestation and the declarative status channel give fresher state. See the Apple Declarative Device Management and Managed Device Attestation Guide.
• Keep the fix path open: exclude update help, enrolment and support endpoints from the block.

Implementing on Apple devices after the version 27 change

Apple's device management schema marks the restrictions forceDelayedSoftwareUpdates and enforcedSoftwareUpdateDelay as deprecated in iOS 26.0 and removed in iOS 27.0, with the instruction to use the declarative com.apple.configuration.softwareupdate.settings configuration instead. Jamf's documentation states that Apple removed support for software update commands in version 27 of iOS, iPadOS, macOS and tvOS, and recommends its declarative blueprints. Microsoft's Intune documentation describes the older MDM-based update policies as deprecated and points to Settings catalog declarative policies. The iOS and iPadOS Enterprise Security Guide covers the wider device baseline.

1. Inventory legacy objects: list restrictions profiles using the two deprecated keys and scheduled update command workflows; on version 27 devices they do nothing.
2. Create a settings declaration per ring: deferral period, automatic actions, Background Security Improvements left enabled, and notification behaviour.
3. Create enforcement declarations per release: TargetOSVersion, TargetLocalDateTime (local time, format yyyy-mm-ddThh:mm:ss) and a DetailsURL that explains the deadline. Apple's notes say a declaration only enforces versions that Apple's GDMF service lists as available, and that a device off at the deadline enforces one hour after restart or when conditions such as battery are met.
4. Read the right report: in most consoles a policy showing success means the declaration reached the device, not that the OS was updated (Microsoft's documentation says this explicitly). Measure the OS version and the softwareupdate.install-state and failure-reason status items instead.
5. Retire stale declarations: devices above the target report a downgrade error, so remove old enforcement declarations once a ring has passed them.
6. Check the network path: Apple services fail any connection that uses HTTPS interception, so exclude Apple update hosts from TLS inspection on corporate Wi-Fi and VPN.

Implementing on Android

1. Map management modes: fully managed and dedicated devices take a system update policy; a work profile owner can only report update state, so personal devices are gated through compliance and app checks.
2. Set the system update policy: windowed (for example 02:00 to 05:00 local) for most company-owned devices, automatic for ring 0 and 1, and postpone only for the testing ring and only for single releases.
3. Define freeze periods sparingly: if business peaks require one, keep it well under the 90-day maximum and remember the 60-day gap rule.
4. Set compliance: minimum Android version, minimum security patch level as a rolling date (for example no older than 60 to 90 days, tightened as manufacturer support allows), and a Play Integrity requirement.
5. Force a reboot cycle: Google Play system updates install only at the next reboot, so a scheduled restart on dedicated devices completes them.
6. Track manufacturer support: record each model's update support end date at purchase, and plan replacement before it passes.

Devices that can no longer update

A device that has reached the end of its manufacturer's update support will never meet a rolling floor. Treat it as a planned exit, not a recurring exception.

• Corporate devices: buy models with a published support period that covers the intended service life, and budget replacement for the end of support. NCSC advises replacing unsupported devices and software as soon as you are able.
• Personal devices: state the minimum supported OS in the BYOD policy and give users notice before a floor change will exclude their phone. See the Mobile Device Management Policy Template.
• Exceptions: a device that must stay on an old release for a certified app gets that app only, no email or files, and an owner and expiry date.

Where identity fits

The update pipeline relies on non-human identities that are easy to forget: the MDM's connection to Apple's and Google's management services, enrolment tokens, and API apps or service accounts that read device compliance into the identity provider or write update policies. Whoever controls them can relax a floor or mark stale devices compliant, so give each an owner, least privilege and a renewal date, as covered in the Mobile Device Management Security Guide.

Detection and measurement

Report update state per platform, ring and ownership type. See the Vulnerability Management Guide.

• Watch for: repeated update failures, devices not checking in, floor or compliance changes outside change windows, and new exceptions.

Choosing for your size

• Small organisations: two rings (IT, then everyone), automatic installation, a 14-day deadline and gating on OS version and Android patch level. Skip freeze periods.
• Large or regulated organisations: four rings, model-level support tracking, freezes only by approved exception and update metrics in the risk register.
• BYOD-heavy organisations: you cannot force updates, so invest in compliance and app-launch gates, clear communication and a short grace period.

Common failure patterns

• Deferral without a deadline: devices hide a release for 90 days for testing, nobody sets enforcement, and the fleet sits on exploited versions for a quarter.
• Legacy restrictions left in place: teams believe updates are deferred or enforced through the old restrictions profile, but devices on version 27 ignore it.
• Version-only gating on Android: the floor checks Android 15 or later, while devices months behind on patch level stay compliant.
• Treating success as installed: the report is green while devices stay on the old version.
• Blocking the fix path: noncompliant devices cannot reach the help page or the MDM, so exceptions are granted wholesale.
• Permanent maximum versions or freezes: a temporary block is never removed and becomes a standing barrier to security updates.

Framework mapping

Practitioner checklist

• Write the floor as a rule per platform: latest minor release on iOS with grace, rolling patch level date plus minimum version on Android.
• Remove profiles that rely on the deprecated Apple restrictions and replace them with software update settings and enforcement declarations.
• Define three or four rings with a deferral and an enforcement deadline for each, and an emergency lane of 48 to 72 hours.
• Set windowed or automatic system update policies on fully managed and dedicated Android devices.
• Require a compliant device in the identity provider for corporate apps, with warn, grace, block and remove stages.
• Keep update help, enrolment and support endpoints reachable from noncompliant devices.
• Use app-launch OS and patch checks for unenrolled personal devices.
• Measure installed versions, not policy delivery status, and report time to 90 per cent per ring.
• Track manufacturer support end dates per model and plan replacements before them.
• Give every exception an owner and expiry, and review freezes and maximum versions monthly.

Standards and references

• NIST: SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise
• NCSC: Keeping devices and software up to date
• Apple: About software updates for Apple devices
• Apple: Device management schema (software update declarations and restrictions)
• Android Developers: Manage system updates
• Android: Android Security Bulletins
• Jamf: Managed Software Updates
• Microsoft: Manage software updates for Apple devices with declarative device management

Related NHI Mgmt Group resources: Mobile Device Management Security Guide · Patch Management Guide · iOS and iPadOS Enterprise Security Guide · Android Enterprise Security Guide