Exclusive: Google plans to relax security update requirements for Android Enterprise Recommended
While Android is the overall dominant smartphone operating system according to data from IDC, Apple’s iOS is the OS of choice for most enterprises. It’s easy to see why: Apple updates its iOS devices generally far longer and more consistently than most Android device makers update their smartphones, iPhones are simple to configure and manage, and there are far fewer SKUs to support if a company picks Apple. But there are also reasons for enterprises to pick an Android device, including reduced cost and more flexibility in hardware. To make Android even more enticing for the workplace, Google launched “Android for Work” in early 2015 (later rebranded as “Android Enterprise” in late 2016). Then in early 2018, Google launched the Android Enterprise Recommended (AER) program to certify devices for business use. Google codified a set of requirements that devices must meet to be “Android Enterprise Recommended,” including minimum hardware specifications, support for bulk deployment, availability of unlocked devices, consistency of app behavior running in managed profiles, and delivery of Android security updates within 90 days of release for a minimum of three years.
However, documents uncovered by Android developer @deletescape that were reviewed by XDA-Developers reveal that Google is planning to loosen security update requirements for Android Enterprise Recommended devices. Instead, Google is pushing for vendors to be more transparent about how they handle security updates. According to @deletescape, these documents were shared with vendors within the last 15 days. Thus, while we can’t guarantee that these proposed changes to Android Enterprise Recommended will make their way into the final list of requirements, we can at least confirm that Google has very recently considered these changes.
There are currently 170 different Android devices that are Android Enterprise Recommended. HMD Global, Sony, Motorola, OPPO, and of course, Google, offer devices that are AER. Even OnePlus is considering having its devices certified under the program. Well-known consumer smartphone brands aren’t the only companies selling Android Enterprise Recommended devices, though. Rugged smartphones from companies like Zebra, Honeywell, Sonim, and others are included in the program, and now even carriers can sell AER devices directly to businesses, provided they rapidly approve security maintenance releases.
The device provisioning flow in Android 10. Source: Jason Bayton
The list of requirements needed for entry into AER is not that extensive—many more Android devices could have made the list given the low base hardware requirements. Even AER’s software requirements don’t require many changes from vendors, as outlined by several internal Google documents. One of the documents outlines how vendors have to design icon badges for apps in the work profile, add a dedicated tab for work profile apps in the launcher, separate share targets for apps in the personal and work profile, preload certain Google applications, and manage cross-profile data communication. Another document outlines the UX requirements for the work profile launcher tab, work profile Quick Setting tile, work profile dialogs, launcher education messages, context switching, and other system design elements. These requirements are aimed at promoting a minimum standard of acceptable hardware as well as software UX consistency between Android Enterprise Recommended devices.
However, it seems that the requirement for devices to quickly get security patch updates after each monthly Android Security Bulletin (ASB) has proven to be too high a barrier for many vendors.
Google Pushes for Update Transparency for Android Enterprise Recommended
Android developer @deletescape, who recently shared a leaked draft of Google’s Compatibility Definition Document for Android 11, obtained a leaked draft of the new Android Enterprise Recommended requirements for devices running Android 11. Under the “Device Security” section, which we’ve reproduced below, Google is proposing the removal of a number of requirements for the AER program. Under these new proposed rules, AER devices will no longer be guaranteed to receive security patch updates within 90 days of an ASB. Interestingly, one of the rows in the chart suggests that Google actually tightened this requirement from 90 days to 30 days with the move to Android 10, but Google has still not updated the public list of requirements to reflect this change. Nonetheless, under the proposed changes, this requirement will no longer apply for Android Enterprise Recommended devices running Android 11. Furthermore, vendors will also no longer be required to provide 3 years of regular security updates for AER devices. They will, however, still be required to provide “Emergency Security Maintenance Release” (ESMR) updates, which presumably means they only have to roll out updates containing fixes for critical security vulnerabilities.
Android 10 versus Android 11 - Device Security Requirements for Android Enterprise Recommended
MUST / MAY
|Attribute and Implementation|
|Q (Android 10)||R (Android 11)|
|Device Security||1||MAY||Operate an OEM Vulnerability Rewards Program (VRP)||Operate an OEM Vulnerability Rewards Program (VRP)|
|2||MAY||StrongBox support||StrongBox support|
|3||MAY||Hardware backed Keystore support||Hardware backed Keystore support|
|4||MAY||Device ID attestation support||Device ID attestation support|
|5||MAY||Key attestation support||Key attestation support|
|6||30-day security updates||Requirement removed||Replaced with Security transparency requirement|
|7||MUST||3 yr support for Emergency Security Maintenance Release (ESMR)||3 yr support for Emergency Security Maintenance Release (ESMR)||Replaced with Security transparency requirement|
|8||File-based encryption – on by default. Uses AOSP implementation.||Requirement removed||This is a GMS requirement enforced for all devices|
|9||90-day security updates||Requirement removed||Replaced with Security transparency requirement|
|10||3 year security update support (may sub 3rd year ESMR)||Requirement removed||Replaced with Security transparency requirement|
|11||Publish latest security patch level||Requirement removed||Replaced with Security transparency requirement|
As mentioned in the chart, Google is proposing replacing a lot of these requirements with new “transparency” requirements. Indeed, Google is proposing the addition of a new section titled “Security/OS Updates transparency.” The new requirements detail how vendors will be required to publish information such as the end-of-life date for security maintenance releases, the latest security patch that’s available, how frequently the device will receive updates, what fixes are contained in each update, the shipping and planned software updates of the device, and more. Interestingly, Google is also requiring that Android 11 devices undergo certification testing by the ioXt Alliance before they can become Android Enterprise Recommended. The ioXt Alliance is an alliance of companies whose goal is to improve the security of IoT products. Its members include Amazon, Facebook, Google, NXP, and more. Google says that having this certification will add to transparency, presumably since it will give enterprises an independent metric of how secure a particular device is rather than just Google’s assurance.
Security/OS Updates Transparency (New) Requirements for Android Enterprise Recommended
MUST / MAY
|Attribute and Implementation|
|Q (Android 10)||R (Android 11)|
|Security/OS Updates transparency||1||MUST||MUST publish following updates information on OEM website|
– SMR support end-date (last date when the device will receive SMR)
– Latest security patch available
– Frequency of updates the device will receive
– Fixes contained in security patch, including any OEM-specific fixes
|Changing the requirement from SMR support to SMR/patches/updates transparency|
|2||MUST||MUST publish following OS information on OEM website|
– OS that the device is shipped with
– Current major OS ver
– All major OS version update that the device will receive
|Changing the requirement from support to transparency|
eg: Pixel 3
– Shipped ver – Android 9
– Current Ver – Android 10
– Expected major ver – Android 11
|3||MUST||Submit the device to IoXT certification||IoXT scoring adds to transparency|
It’s no secret that vendors have trouble keeping up with rolling out monthly security patch updates. There are many, many reasons why that’s the case: carrier certification delays, waiting for patches from chipset and other vendors, the difficulty of applying patches to heavily modified Android framework builds and out-of-tree Linux kernels, and more. Some Android users have even taken notice of how some vendors fail to meet AER requirements. While Google’s development efforts and license agreements have helped improve how quickly security updates roll out for many devices, they clearly haven’t been able to sustain the current security patch requirements for the Android Enterprise Recommended program. Loosening these requirements in favor of more transparency will both help make the program more accessible to vendors and also give enterprises more confidence in the particular device they choose for their workers.
The proposed relaxation of security patch updates isn’t the only change that could be coming to the Android Enterprise Recommended program for Android 11, of course. Google also plans to increase the minimum hardware requirements from 2GB of RAM to 3GB of RAM, tighten training requirements, and implement a new set of requirements for the work profile UX. Most of these changes won’t impact knowledge workers, though. Android in the enterprise has grown a lot since its early days. If you’re interested in learning more about its history, I recommend reading this excellent article from Jason Bayton.