How to Enforce a Minimum iOS Version With MDM

To enforce a minimum iOS version, combine two MDM controls: a compliance policy that marks devices below your chosen version as noncompliant and cuts off corporate access, and an enforced software update with a deadline that installs the release for the user. The first protects your data from stale phones. The second shrinks the number of stale phones. Both matter after campaigns like Poisoned Source, which targeted iPhones that had skipped years of updates.

Why enforce a minimum iOS version?

Enforcing a minimum iOS version keeps devices with known, already patched vulnerabilities away from company email, files and SSO. Attackers keep using n-day exploits because many phones never install the fix.

In November 2026, CISA added Apple CVE-2024-27834 to its KEV catalog, more than two years after Apple patched it, because an APT29-linked campaign used it against iPhones on iOS 16. Sekoia, which documented the campaign, stated that devices on an up to date operating system were safe. See our news coverage of CVE-2024-27834 for the details.

How do you pick the minimum version?

Pick the oldest build that contains every fix you consider mandatory, and raise it after each Apple security release. Start from the newest supported major release, then set the floor at its latest patch, not at the major version number.

Practical rules for setting the floor:

• Read Apple's security release notes when a new update ships and check for "may have been exploited" language. Those releases justify a short deadline.
• Check the CISA KEV catalog for Apple entries. A KEV addition, even for an old bug, means attackers are using it now.
• Use the OS build number when Apple ships a fix without changing the version string. Microsoft's Intune documentation notes that security updates typically change the build number, not the OS version.
• Write the current floor and the date it changes into your mobile device policy, so help desk staff can answer "why am I blocked?" without escalating.

Set the compliance rule

The compliance rule is what blocks access. In Microsoft Intune, the iOS/iPadOS compliance policy has a Device Properties section with these settings:

• Minimum OS version: devices below it are marked noncompliant. Users see a link explaining how to upgrade and regain access once they do.
• Minimum OS build version: use this when Apple ships a security fix that only changes the build. Intune's documentation says to enter the supplemental build version for Rapid Security Response updates.
• Maximum OS version and Maximum OS build version: optional, used to hold back a release you have not tested.

Microsoft lists these settings as supported for iOS 17.0 and later. Check how your tenant reports devices older than that, because those are exactly the phones you most want to catch. If they show as compliant by default, block them some other way, such as a device filter or a report you review weekly.

Compliance only protects data when something acts on it. Pair the policy with a Conditional Access rule in Microsoft Entra ID (or your identity provider's equivalent) that requires a compliant device for email, file storage and SSO apps. Without that link, a noncompliant flag is just a report.

Other MDM platforms (Jamf, Kandji, Workspace ONE and others) offer similar minimum OS rules. The names differ, but the logic is the same: evaluate version, flag noncompliance, gate access.

Enforce the update itself

Blocking access gets the user's attention. Installing the update fixes the device. Apple's platform deployment guide describes enforced software updates through declarative device management:

• The administrator sets a target version and a date and time. Devices try to install the update at that time in their local time zone.
• The device downloads and prepares the update once the declaration arrives. Users see the deadline in Settings and in notifications that get more frequent as it approaches, and Do Not Disturb is ignored in the last 24 hours.
• On iOS 18 and iPadOS 18 or later, notifications can be limited to one hour before the deadline, with a restart countdown.
• If the deadline passes, the device tells the user the update is past due and tries to install within the next hour, retrying when it is powered on and online.
• Status reports show whether the device is waiting, downloading or installing, with error codes for problems such as low battery, low storage or no network.

Apple also documents enforcing a minimum OS version during Automated Device Enrollment, which requires iOS 17 or iPadOS 17 or later. New and reset devices below the floor are guided through an update before Setup Assistant finishes, so they never reach users stale.

How do you handle devices that cannot update?

Devices that cannot install your minimum version should lose corporate access and be scheduled for replacement. No setting makes an unsupported phone safe.

Steps that work in practice:

1. Export the noncompliant list after the first deadline and split it into "will update" and "cannot update".
2. Contact the "cannot update" owners with a replacement date, not an open-ended warning.
3. Allow web-only access through a browser on a managed laptop in the meantime, if the business needs it.
4. Remove the devices from MDM once they are replaced, so they do not linger as exceptions.

The budget and policy side of this is covered in why unsupported iPhones belong on a retirement schedule. For background on why old Apple patches keep mattering, read what Pointer Authentication is and what a PAC bypass does.

A rollout checklist

• Set the floor to the latest patch of your supported major release.
• Create the compliance policy with minimum OS version and, where needed, minimum build.
• Link it to Conditional Access for email, file storage and SSO.
• Declare an enforced update with a deadline a few days out, shorter when Apple flags active exploitation.
• Review the noncompliant report after the deadline and start replacements for devices that cannot update.
• Repeat for every Apple security release.