Exclusive: Google plans to relax security update requirements for Android Enterprise Recommended

Exclusive: Google plans to relax security update requirements for Android Enterprise Recommended

We may earn a commission for purchases made using our links.

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.

Work profile UX changes in Android 11. Left: Personal tab and work tab in Settings > App info. Right: Work app icons grayed out when the work profile is paused. Source: Google.

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

Category
Serial Number
MUST / MAY
Attribute and Implementation
Comments
Q (Android 10)R (Android 11)
Device Security1MAYOperate an OEM Vulnerability Rewards Program (VRP)Operate an OEM Vulnerability Rewards Program (VRP)
2MAYStrongBox supportStrongBox support
3MAYHardware backed Keystore supportHardware backed Keystore support
4MAYDevice ID attestation supportDevice ID attestation support
5MAYKey attestation supportKey attestation support
630-day security updatesRequirement removedReplaced with Security transparency requirement
7MUST3 yr support for Emergency Security Maintenance Release (ESMR)3 yr support for Emergency Security Maintenance Release (ESMR)Replaced with Security transparency requirement
8File-based encryption – on by default. Uses AOSP implementation.Requirement removedThis is a GMS requirement enforced for all devices
990-day security updatesRequirement removedReplaced with Security transparency requirement
103 year security update support (may sub 3rd year ESMR)Requirement removedReplaced with Security transparency requirement
11Publish latest security patch levelRequirement removedReplaced 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

Category
Serial Number
MUST / MAY
Attribute and Implementation
Comments
Q (Android 10)R (Android 11)
Security/OS Updates transparency1MUSTMUST 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
2MUSTMUST 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
3MUSTSubmit the device to IoXT certificationIoXT 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.