.png)
Google releases Android security patches every month. Each bulletin fixes anywhere from a dozen to forty vulnerabilities — remote code execution, privilege escalation, information disclosure. The patches exist. The question is whether they actually reach your devices. Android patch management through an Android MDM platform gives IT control over when and how updates are applied across a fleet, visibility into which devices are current and which are behind, and the ability to enforce compliance baselines so no device falls too far behind.
This is one of the harder problems in Android device management. Not because patching is conceptually difficult, but because Android's update chain introduces delays and inconsistencies that don't exist on iOS. Understanding the chain — and managing around its limitations — is the core of Android patch management.
The Android Update Chain
When Google releases a monthly security patch, it doesn't go directly to devices. It goes through a chain.
Google publishes the Android Security Bulletin and releases source code patches to the Android Open Source Project (AOSP). Device manufacturers — Samsung, Google, Motorola, Zebra, Lenovo, and dozens of others — take those patches, adapt them for their specific hardware and software modifications, test them, and build firmware updates for each device model. For carrier-sold devices, the carrier then conducts its own testing and approval process. Only after all of this does the update reach the device.
The result: a Pixel phone gets Google's patches within days of the bulletin. Samsung flagship devices typically get patches within 3-4 weeks. Mid-range and budget devices from smaller manufacturers might be 2-3 months behind. Some devices stop receiving patches entirely after 2-3 years.
This means your fleet will always have devices at different security patch levels. Always. Even if every device is the same model, staggered purchase dates, user behavior around updates, and network connectivity differences create variation. The goal isn't to have every device on the same patch — it's to have every device within an acceptable window and to know immediately when one falls behind.
What MDM Controls
Android Enterprise gives MDM platforms several controls over the update process. These don't eliminate the update chain delays, but they give IT tools to manage what happens once an update is available.
System update policy sets how the device handles available OS updates. The options are: install automatically as soon as available, install during a specified maintenance window (for example, 2-5 AM), postpone for a defined period (up to 30 days), or freeze updates during a specified window. You push this policy through MDM, and the device follows it.
Automatic installation is the right default for most devices. Security patches should be applied as quickly as possible. The maintenance window option is useful for devices in active use during business hours — a POS terminal that restarts to apply an update at 2 PM during the lunch rush is a problem. Schedule it for overnight.
Postponement is useful for testing. When a major OS update drops (Android 14 to Android 15, for example), you might want to defer it for two weeks while you verify that your business apps work correctly on the new version. Push the deferral policy, test internally, then release.
Freeze periods prevent any updates during critical business windows — Black Friday week for retail, end of quarter for sales teams, patient care surge periods for healthcare. This ensures devices stay stable during periods where any disruption is unacceptable. Android Enterprise supports freeze periods up to 90 days.
Visibility and Compliance
The MDM console gives you fleet-wide visibility into patch levels. You see which Android version and security patch date each device is running. You can filter, sort, and group by patch level — show me every device more than 60 days behind on security patches, group by manufacturer, group by department.
Compliance policies turn visibility into enforcement. Set a rule: any device with a security patch older than 60 days is non-compliant. Non-compliant devices can be flagged in the dashboard, sent a notification telling the user to update, restricted from accessing sensitive corporate resources, or quarantined — cut off from corporate email and apps until the update is applied.
The compliance window you set depends on your risk tolerance and your fleet composition. If your fleet is all Pixels and Samsung flagships, a 45-day window is realistic — those devices get patches promptly. If your fleet includes budget devices from manufacturers with slower patch cadences, you might need a 90-day window to avoid flagging devices that simply can't update yet because the manufacturer hasn't released the patch.
This is where Android device security and patch management intersect. An unpatched device is a known vulnerability. MDM gives you the data to quantify the risk — not "we think our devices are patched" but "87% of our fleet is within 30 days, 11% is within 60 days, and 2% is more than 90 days behind." That's data you can act on, and data an auditor can verify.
App Updates vs. OS Updates
OS and security patches are system-level updates that come through the manufacturer's firmware update process. App updates are different — they come through Google Play and are handled by the Play Store's update mechanism.
For apps distributed through Managed Google Play, updates flow through the same channel as consumer Play Store updates. MDM can control whether apps update automatically or whether updates are deferred until IT approves them.
For most apps, auto-update is the right choice. Security patches, bug fixes, and compatibility updates should reach devices quickly. The risk of a broken update is lower for individual apps than for OS-level updates, and the risk of running an unpatched app is real.
For critical line-of-business apps — the POS app, the warehouse scanning app, the field service tool — some organizations prefer controlled rollouts. Push the update to a test group of devices, verify it works, then release fleet-wide. This is sometimes called staged deployment or canary deployment. If the update breaks something, the blast radius is limited to the test group.
Fleet Composition and Hardware Strategy
Patch management starts with hardware selection, not software policy. If you buy devices that stop receiving security patches after two years, no MDM policy can fix that. The device is unpatched because the manufacturer doesn't release patches for it anymore.
Android Enterprise Recommended (AER) certified devices commit to a minimum number of years of security updates. Google's own Pixel line guarantees 5-7 years of updates depending on the model. Samsung's flagship and enterprise devices typically guarantee 4-5 years. This matters when you're buying 500 devices for a three-year deployment — if the manufacturer stops patching after two years, you have a year of devices accumulating known vulnerabilities.
When evaluating devices for a fleet deployment, check the manufacturer's stated patch commitment for that specific model. Not the brand's general commitment — the specific model. A manufacturer might support their flagship for five years and their budget line for two.
For existing fleets with devices approaching end-of-patch-support, MDM compliance policies become even more important. Devices that can no longer receive patches should be flagged, restricted from accessing the most sensitive corporate resources, and prioritized for replacement. MDM data — device model, current patch level, days since last patch — gives you the information to make hardware refresh decisions based on actual security posture, not just age.
Practical Patch Management Process
A functional patch management process for Android doesn't need to be complicated, but it needs to be consistent.
Monitor: MDM dashboard shows fleet patch status. Review weekly. Know which devices are behind and why.
Set compliance baselines: define what "current" means for your organization. 30 days, 60 days, 90 days — pick a window that's realistic for your fleet composition and enforce it through MDM policy.
Test major updates: when a new Android version drops, defer it on production devices for 1-2 weeks. Test your managed apps on the new version. If everything works, release the deferral.
Enforce: non-compliant devices get progressively restricted. First a notification. Then restricted access to sensitive resources. Then quarantine. This creates user incentive to accept updates they've been deferring.
Report: compliance reports for auditors, security reviews, and management. MDM generates the data. You present it.
Replace: devices that can't be patched get replaced. MDM identifies them. You budget for it.
Google Play System Updates
Beyond monthly security patches, Google has introduced a second patching mechanism: Google Play System Updates (also called Project Mainline). These updates patch individual system components — media codecs, networking modules, permission controllers — through Google Play, bypassing the manufacturer firmware update chain entirely.
This is significant because it decouples some security fixes from the manufacturer's update cycle. A critical vulnerability in a media codec that would previously require a full firmware update from Samsung or Motorola can now be patched directly by Google through the Play Store. The update reaches the device without manufacturer involvement.
MDM visibility into Google Play System Updates is still evolving. Some MDM platforms report the Google Play System Update version alongside the security patch level. This gives you a more complete picture of the device's actual security posture — a device might be behind on the manufacturer's monthly patch but current on Google Play System Updates, meaning some critical components are still up to date.
For IT teams, the practical takeaway is that the Android patching landscape has two layers: manufacturer firmware updates (monthly security patches, major OS updates) and Google Play System Updates (component-level patches delivered directly). Both matter. MDM should give you visibility into both.
End-of-Life Planning
Every Android device eventually reaches end of support — the manufacturer stops releasing security patches for that model. When this happens, the device accumulates known vulnerabilities with no fix available. Your options are: accept the risk, restrict the device's access to sensitive resources, or replace the device.
MDM makes this decision data-driven. You can identify every device in your fleet that hasn't received a security patch in 90+ days and hasn't received a manufacturer OTA in 6+ months. Cross-reference with the manufacturer's support timeline for that model. If the model is end-of-life, the device goes on the replacement list.
Budget planning for hardware refresh should be informed by MDM data. Rather than replacing devices on a fixed schedule (every 3 years regardless of status), replace devices based on security posture. A three-year-old Pixel that's still receiving monthly patches stays in service. A two-year-old budget tablet that stopped receiving patches six months ago goes to the top of the replacement queue.
Some organizations create a tiered access model for aging devices. Devices current on patches get full access to corporate resources. Devices that are 60-90 days behind get access to non-sensitive resources only. Devices more than 90 days behind or at end-of-life get quarantined — they can only access the MDM portal and a notification telling the user to contact IT for a replacement.
This graduated approach keeps devices productive as long as they're secure and phases them out gracefully when they're not. MDM compliance policies automate the transitions — no manual device-by-device decisions required.
Android patch management isn't glamorous. But it's the single most impactful security control you can apply to an Android fleet. The vast majority of Android exploits target known vulnerabilities with available patches. Keeping devices patched eliminates those attack vectors. MDM is how you do it at scale.
.webp)
