Exclusive: Google wants to make Android phones safer by switching to ‘risk-based’ security updates

For the past decade, Google has consistently published an Android Security Bulletin every month, even if the company wasn’t ready to roll out a security update to its own Pixel devices. These bulletins detail the vulnerabilities that have been fixed in that month’s security release, with issues ranging from low to critical in severity. Given how large and complex the Android operating system and its underlying components are, it’s not unusual to see a dozen or more vulnerabilities documented in a bulletin. However, the July 2025 bulletin broke this decade-long trend: out of the 120 bulletins published up to that point, it was the first ever to not list a single vulnerability.

In contrast, the latest September 2025 bulletin listed a whopping 119 vulnerabilities. This disparity doesn’t mean Google had nothing to disclose in July; rather, it reflects strategic changes the company made to its Android security update process. These changes aim to help device manufacturers (OEMs) address high-risk issues more quickly and better protect users from active exploitation. Here’s what’s changing.

You’re reading the Authority Insights Newsletter, a weekly newsletter that reveals some new facet of Android that hasn’t been reported on anywhere else. If you’re looking for the latest scoops, the hottest leaks, and breaking news on Google’s Android operating system and other mobile tech topics, then we’ve got you covered.

Subscribe here to get this post delivered to your email inbox every Saturday.

The life of a security patch: How Android security updates used to work

Google has done a lot of work over the years to proactively protect Android from vulnerabilities. For example, it writes new code in memory-safe languages like Rust and implements anti-exploitation protections such as hardware-backed control flow integrity (CFI) and memory tagging (MTE). These security improvements, coupled with Google’s efforts to speed up Android updates and modularize the OS through initiatives like Project Mainline, have made it difficult for bad actors to find and abuse critical security vulnerabilities. But with such a large, complex, and constantly updating codebase, some vulnerabilities are always waiting to be found.

While anyone can find Android security vulnerabilities, bad actors aren’t going to report them to Google. Instead, the vulnerabilities that get patched are privately reported by responsible researchers who work independently, for firms that partner with Google, or for Google itself. The Android security team then triages these reports to verify a vulnerability’s existence, assess its potential impact, and assign a severity rating (e.g., Moderate, High, or Critical). Once validated, the vulnerability receives a unique Common Vulnerabilities and Exposures (CVE) identifier to make it easier to track. Finally, Google’s engineers, often in collaboration with the original reporter, develop and test a patch to fix the issue.

Once Google has finalized a security patch, the company doesn’t immediately release it. This is because it has no way of rolling out a security update to all Android devices over-the-air. The only exception is when the impacted component is part of a Project Mainline module, in which case Google itself can distribute a fix to all devices through a Google Play System Update. While Google could submit the patch to the Android Open Source Project (AOSP) as soon as it’s ready, doing so would immediately publicize the vulnerability. The company refrains from this approach because it would leave partners scrambling to merge, test, and roll out an update.

This is why Google created the Android Security Bulletin (ASB). The ASB coordinates the disclosure of numerous security patches, grouping them into a single monthly release cycle so partners aren’t overwhelmed. There are two versions of the ASB: a public and a private one. The public ASB has been published every month since August 2015 and generally goes live on the first Monday of the month. The private ASB, on the other hand, is distributed to OEMs and chipset vendors approximately 30 days in advance, providing them with essential lead time to merge and test the patches before they’re publicly disclosed.

Here’s a timeline showing how a hypothetical vulnerability is handled, from its discovery to its inclusion in a public ASB. Keep in mind that the time it takes to triage and patch a vulnerability is highly variable. The timeline also illustrates a key delay: since the patch was finalized after the private ASB for September 2025 had already been sent to partners, it had to be included in the next one.

Even with this lead time, some OEMs struggle to roll out security updates for all their devices each month. In fact, many don’t even commit to monthly security updates for their entire lineup; their update policies often stipulate that budget and mid-range devices only qualify for bi-monthly or quarterly patches. This is a common challenge for manufacturers managing heavily customized versions of Android across massive device portfolios. On top of that, they often need carrier approval to release updates in some regions. As a consequence, many Android devices are left without the latest security patches and are vulnerable to exploitation.

Google’s solution to this problem is to change the security update process. The company is adopting a new release strategy it calls the “Risk-Based Update System” (RBUS), which is designed to improve the security patching process for OEMs without sacrificing user security.

How Android’s new risk-based update process works

Instead of bundling all available security patches into the next ASB, Google now prioritizes shipping only “high-risk” vulnerabilities in its monthly releases. The majority of security fixes, meanwhile, will be shipped in quarterly ASBs. Google defines “high-risk” vulnerabilities as issues that are crucial to address immediately, such as those under active exploitation or that are part of a known exploit chain. This designation is based on real-world threat level and is distinct from a vulnerability’s formal “critical” or “high” severity rating.

This new approach has several key benefits for OEMs:

• OEMs have fewer patches to merge, test, and ship each month. This reduces the difficulty of shipping monthly updates and may result in some OEMs shipping them more frequently for more devices.
• OEMs have more flexibility in deciding how quickly they want to release security updates. Most can focus their efforts on larger quarterly releases, while others can optionally update monthly to meet specific compliance targets.

Because Google’s monthly bulletins now only include vulnerabilities it deems “high-risk,” some ASBs may list zero fixes. This is exactly what happened with the July 2025 ASB. That doesn’t mean there were no Android vulnerabilities to address; Samsung and Qualcomm, for instance, each listed multiple CVEs in their own July 2025 bulletins. However, since Google’s bulletin no longer lists most vulnerabilities, OEMs can choose whether to release security updates even when the official ASB is empty. For those that do, like Samsung, Google’s only stipulation is that they don’t publicly publish any details about the CVEs they patched.

A direct consequence of this change is that the March, June, September, and December ASBs will be substantially larger, as they align with Android’s new quarterly release schedule. This explains why the September 2025 ASB listed a staggering 119 vulnerabilities, compared to the zero and six listed in the July and August 2025 bulletins, respectively. Since most security fixes will now arrive in these quarterly releases, OEMs are encouraged to adopt at least a quarterly update schedule for their devices to maximize user protection.

Here’s a timeline showing how a hypothetical low-risk vulnerability would be handled under the new Risk-Based Update System. Again, the time it takes to triage and patch a vulnerability will differ depending on the issue in question. Compare this to the previous timeline I showed, which now applies to high-risk vulnerabilities.

Google hasn’t publicly announced its shift in release strategies for Android security updates, but Android Authority has spoken to multiple sources who confirmed the change. When we reached out to Google for comment, a spokesperson had the following to say:

“Android and Pixel security bulletins are published monthly. To keep users safe, we build powerful security deep into Android’s foundation. Android stops most vulnerability exploitation at the source with extensive platform hardening, like our use of the memory-safe language Rust and advanced anti-exploitation protections. Android and Pixel continuously address known security vulnerabilities and prioritize fixing and patching the highest-risk ones first.” – A Google spokesperson

For most users, this new security release approach won’t change much. If you already receive monthly security updates, you’ll continue to get them. If you don’t, this change may help your device’s manufacturer deliver them more consistently. At the very least, it should make it easier for all OEMs to push out the quarterly updates, which are now far more impactful.

There is one potential downside to the Risk-Based Update System, as highlighted by the folks behind GrapheneOS, a privacy and security-oriented fork of AOSP. In the past, Google gave OEMs a one-month heads-up. Now, they receive several months of advance notice for the larger quarterly updates. This longer window could be problematic, as it gives bad actors more time to potentially find leaked vulnerability details and develop exploits before patches are widely available. While the private ASB is shared securely, it’s accessible to tens of thousands of engineers across dozens of companies, making it conceivable that details could leak to malicious third parties. This remains a hypothetical risk, though, as it would require bad actors to leverage the right exploit on the right devices before they’re patched.

Another downside is that Google is no longer releasing the source code for monthly security updates, only for quarterly ones. This, in conjunction with other delays in OS source code, means most custom ROMs can’t ship monthly updates anymore. Add this to the pile of other things that make it harder to mod your Android phone in 2025.

Want more?

Authority Insights is more than a newsletter — it’s the hub for all our best content. If you care about Android, you won’t want to miss any of our other exclusive reports.

Don’t have time to read them all? Subscribe to our Authority Insights Podcast to hear me and my co-host, C. Scott Brown, break down our top stories of the week.