We’ve heard this question from our customers for years. Is there a way to stop users from updating their iOS devices? But until Apple recently announced the availability of deferred updates for iOS 11.3 (Beta) supervised devices, it hasn’t been possible. Now that the day is finally here, one question organizations should consider is, “should we delay an iOS update?”
On the one hand, we want to make sure that users are having the best possible experience they can on their device, which means they need the latest features Apple delivers in new releases of iOS. And people DO update their devices. As of January 18, 2018, 65% of iOS devices were running iOS 11,* and more than 50% of users upgraded to iOS 11 within the first three weeks after launch.** End users benefit from the latest consumer advancements, known bugs and security exploits are addressed, and the enterprise is able to deploy the newest EMM features. A win-win right? More on that later...
An evolutionary change
To be fair, there were some hints that Apple was thinking about changing the OS update process. Two years ago, with iOS 9, Apple allowed EMM’s to mandate iOS updates to the latest version for supervised devices, which are roughly equivalent to company-owned devices (bayton.org has an excellent article on supervision if you’d like to learn more). Still, if a company wanted to block an update for iOS, and barring difficult network side restrictions, the options were limited to compliance actions. For instance, an admin could withhold apps or configurations, block devices from accessing resources like email, or even enterprise-wipe a device.
With iOS 11.3, currently in Beta, Apple has changed the game, albeit only for supervised devices. Companies that wish to delay updates to the latest version of iOS will have the ability to deploy a restriction that allows them to defer the update for up to 90 days. For companies that would like to begin testing today, we’ve published instructions (requires customer credentials) on our community website on how to generate the restriction with Apple Configurator 2.7 and upload it as a custom profile to MobileIron Cloud or Core. The iOS 11.3 Beta is currently public, so if you want to try it on an iOS device, you can visit beta.apple.com to get started.
How do deferred updates work?
The iOS restriction for deferring an iOS update has a default value of 30 days, but can be configured anywhere up to 90 days. End users won’t be able to manually update their iOS devices over the air, but take note, users can still perform an upgrade by tethering their device to a computer and using Apple Configurator or iTunes. Once the deferral period expires, the device will update to the earliest version of iOS that was available at the time the deferral restriction was set on the device.
To bring this into focus, imagine devices are mostly running iOS 11.3 when iOS 11.3.1 is released by Apple. At that moment, your organization deploys a 90 day restriction. Even though 90 days later, when the deferral restriction expires, iOS 11.3.4 might be the current released version of iOS, the devices, when they update, should install iOS 11.3.1 (the earliest version that was available at the time the restriction was set.) Companies deferring updates should pay close attention to timing when configuring these deployments. If the desire is to standardize on an iOS version like 11.3.1, the deferral restriction should be deployed at or very soon after the release of the targeted iOS version.
What are the drivers for deferred updates?
There are a lot of good reasons to defer an update. Some companies have critical in-house apps that might break with an iOS update. Even though Apple runs an extended Beta, it may not be long enough for developers to update their apps in time. Other institutions may be cautious about new behavior in an iOS version, such as new OAuth 2.0 authentication behavior for O365 that first appeared in iOS 11. They might want some extra time to test and understand the behavior, or to mitigate risk using a technology like MobileIron Access. And some organizations are just risk averse; they want more time to test how the devices perform before they allow an update. They want to certify an iOS version before they deploy it. And sometimes, as with some recent Intel patches for Meltdown and Spectre, updates can be rushed, causing kernel panics and other unintended “side effects” on some operating systems.
The case for never deferring updates
There are more critical security CVE’s (Critical Vulnerabilities and Exposures) discovered today than ever before, including on iOS devices. For example, in 2017, there was an average of more than 30 CVE’s per month*** for the iPhone. Although not all CVEs pose significant risk, CVEs for mobile OSes are, on average, more severe.
While Google delivers security updates independently of OS updates every month, Apple CVE’s are addressed in OS updates. Companies that wish to mitigate risk may actually be exposing themselves to greater risk by allowing unpatched vulnerabilities to exist in their environment longer. Companies that do delay updates should consider deploying a solution like MobileIron Threat Defense, which can detect exploits as they are happening and provide on-device remediations. Still, a company that defers the latest version of iOS for 90 days could be allowing almost 100 published CVE’s to remain unpatched.
Can Android and Windows 10 defer updates too?
Windows 10 has very granular control over OS updates, and Android is gaining more controls every day. With the recent introduction of E-FOTA (Enterprise Firmware Over-The-Air) for Samsung on MobileIron Core, admins can now precisely control exactly which versions of Android can run on Samsung devices. For generic Android, we may also see a future capability for devices that run Android enterprise (formerly Android for Work) before long.
Weigh the risk
Organizations considering taking advantage of the restriction for deferring the newest version of iOS should conduct a risk benefit analysis. What is gained by delaying the upgrade? Are some of the devices you are managing unsupervised or BYOD devices that aren’t eligible for deferred updates? What new risk is introduced into the organization by skipping the new version, and which CVE’s have been addressed by Apple in the release? Would a Mobile Threat Defense solution help mitigate some of the risk introduced by forgoing security updates?
Modern Work
Organizations evaluating the new restriction should consider the shifting paradigm accelerated by the rapid evolution of what we once referred to simply as “MDM.” With the introduction of Windows 10 and macOS, management has expanded to include UEM (Unified Endpoint Management), encompassing both the desktop and mobile OS spheres.
Concurrently, companies are now deploying more public cloud services than ever before. They must choose a security strategy that works across every kind of device, keeping pace with continuous advances in cloud and app ecosystems while also taking advantage of incremental OS enhancements. On the other end of the spectrum, change is introduced cautiously, and only after exhaustive validation. Apple seems to understand this fundamental shift. By allowing companies to defer updates, but for only a short amount of time, companies can inhabit a middle ground, leveraging an adaptive security model. Companies may need to delay sometimes, but they shouldn’t always delay. If they wish to defer an update, they should undertake a risk vs. reward calculation.
Every organization has unique needs, and after carefully evaluating this important new feature, many will find value in further exploration. They should also take into consideration that the days of “imaging” devices and maintaining a heterogeneous environment are behind us. Security threats are real, and vulnerabilities are addressed in continuous updates. Recently we have seen software and service developers adapt to changing conditions by transitioning to systems like Agile and Devops. In this brave new world of constant and rapid change, it may also be time for the enterprise to adopt a new methodology for modern work.
*Source - https://developer.apple.com/support/app-store/
** Source - https://mixpanel.com/trends/#report/ios_11
*** Source - https://www.cvedetails.com/product/15556/Apple-Iphone-Os.html?vendor_id=49
