Category: Mobile Device Management (MDM)

Your MDM platform reports device location. What it does not tell you is how much of the shift that location data actually covers.

Android distinguishes between foreground location and background location at the API level. Foreground location APIs deliver updates while the requesting application is the active process on the device screen. The moment the user switches to another application, the MDM app moves to the background and foreground location updates stop. For a field employee who opens the MDM app once at the start of their shift and then works through a delivery app, a warehouse management system, or a customer service application for the rest of the day, the MDM platform’s location data ends shortly after the shift begins.

This is not a configuration gap or a connectivity issue. It is an architectural characteristic of how Android manages location access for applications that are not in the foreground. The distinction between foreground and background location access is enforced at the operating system level through Android’s permission model and process lifecycle management. 

The consequence for IT teams managing field device fleets is that the location compliance picture the MDM dashboard presents is accurate for the brief window when the MDM app is actively in use and incomplete for the majority of the working shift. For organisations where device location data underpins workforce compliance, client contractual obligations, or regulatory requirements around where corporate data is being accessed, the gap is operational rather than theoretical.

This blog covers how Android’s location API architecture creates this gap, what foreground-only location tracking produces as a dataset versus what background location tracking produces, and how Akku MDM’s background location tracking capability closes the gap with configurable reporting intervals across the full shift.

How Android Location APIs Work: The Foreground and Background Distinction 

Android’s location subsystem is built around two distinct access modes that carry different permission requirements and different OS-enforced behaviours. 

Foreground Location Access

An application that holds the ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION permission can request location updates while it is the active foreground application. Android delivers these updates at the requested interval as long as the app remains in the foreground. When the user navigates away from the app, the process moves to the background and the OS restricts or suspends the location update stream. Applications that declare a foreground service can maintain location access while backgrounded, but the foreground service notification is visible to the user and the service consumes battery proportionally to the update frequency.

Standard MDM clients that use foreground location access without a persistent foreground service produce location data only during active app use. For device management workflows where administrators periodically open the MDM app to check in, this means location data is available at the moment of each check-in and absent between them. The result is a sparse dataset of point-in-time locations rather than a continuous track of device position throughout the shift.

Background Location Access

ACCESS_BACKGROUND_LOCATION is a separate, more restrictive Android permission that allows an application to receive location updates even when it is not in the foreground. Android 10 introduced this as a distinct permission requiring explicit user grant. Android 11 and later further restricted background location access: it cannot be requested at the same time as foreground location. The user must first grant foreground location, then separately grant background access through the system settings, where the option reads explicitly as ‘Allow all the time’ rather than ‘While using the app.’

Applications with background location access can use Android’s WorkManager, AlarmManager, or a persistent background service to request location updates at configurable intervals throughout the device’s operational period, regardless of which application the user has open. The location data produced is a continuous track rather than a sparse set of check-in points. Battery consumption is proportional to the reporting interval and can be managed by configuring a longer interval for non-time-sensitive use cases.

What Foreground-Only Location Tracking Produces as a Dataset

For a field employee running an eight-hour shift, a foreground-only MDM location implementation produces a dataset that looks like this: location recorded at app open at shift start, location recorded at any subsequent manual check-in or app interaction, location recorded at shift end. The hours between those interactions produce no location data.

The dashboard shows the device as compliant because the enrollment state is active and the last known location is within an expected range. What the dashboard does not show is that the last known location is two hours old and the device may have been anywhere in the interim. For organisations managing field employees who handle sensitive physical assets, access restricted customer locations, or operate in environments where real-time device location is a contractual or regulatory requirement, a two-hour-old location data point is not location tracking. It is a check-in log.

The gap matters differently depending on the use case. For healthcare organisations where clinical staff carry devices with access to patient data, a foreground-only location implementation cannot verify that the device remained within the permitted care environment throughout the shift. For ITeS and BPO organisations with client data handling obligations that include location-based access restrictions, a sparse location dataset does not satisfy the continuous compliance requirement. For logistics and field operations where route adherence and location verification are operational requirements, foreground-only tracking produces data too sparse to be operationally useful.

What Akku MDM’s Background Location Tracking Delivers

Akku MDM’s background location tracking for Android uses the ACCESS_BACKGROUND_LOCATION permission combined with a configurable periodic location worker. The worker runs at an administrator-defined interval throughout the device’s operational period, independent of which application is active on the device screen. Location updates are reported to the Akku MDM console in real time and stored with device identifier, timestamp, latitude and longitude coordinates, and accuracy radius.

The administrator console displays the continuous location track for each enrolled device, showing position at each reporting interval throughout the shift rather than at manual check-in points. For a device running a thirty-minute reporting interval over an eight-hour shift, the administrator receives sixteen location data points covering the full operational period. For environments requiring tighter tracking, shorter intervals are configurable.

The background location capability integrates with Akku MDM’s existing compliance monitoring and group-based policy framework. Administrators can apply background location tracking as a policy to specific device groups, specific user groups within the organisation, or the full enrolled device fleet. Devices that do not grant the background location permission can be flagged as non-compliant in the Akku MDM compliance dashboard, triggering the existing non-compliance workflow. 

The location data produced by background tracking feeds into the same centralised reporting that Akku MDM uses for audit readiness. For compliance exercises requiring evidence that corporate devices remained within permitted locations throughout a defined period, the background location track provides the continuous timestamped dataset that foreground-only check-in logs cannot.

The Permission Grant Process and User Experience

Because Android requires background location to be granted through a separate, explicit user action, the enrollment and permission grant workflow requires specific handling. Akku MDM’s Android enrollment flow presents the foreground location permission request as part of initial device enrollment. After the foreground permission is granted, the enrollment flow directs the user to the system settings to grant the ‘Allow all the time’ background location permission.

The user-facing explanation presented at this step is configurable by the administrator. For corporate-owned devices where the organisation controls the device use policy, the background location requirement can be stated as a condition of device enrollment. For BYOD devices, the permission grant remains subject to the user’s acceptance, and the MDM can be configured to flag devices where background location permission has not been granted as having a policy exception rather than as enrollment-blocked.

This distinction between corporate-owned and BYOD handling reflects the broader Akku MDM architecture, which maintains work profile isolation on Android to separate corporate data from personal data. Background location tracking applies to the device as a whole rather than to the work profile, which means the permission grant and the privacy disclosure to the user need to be consistent with the organisation’s BYOD policy.

The Compliance Context

For healthcare organisations managing Android devices that carry access to patient data, continuous location tracking supports the requirement to demonstrate that protected health information was accessed only from permitted locations. HIPAA does not specify a location tracking requirement for devices, but organisations that use location-based access controls as a technical safeguard under HIPAA Section 164.312(a)(1) need the location data to be continuous rather than sparse to satisfy the control.

For ITeS and BPO organisations with client contractual requirements around where data can be accessed, background location tracking provides the continuous location evidence that spot-check foreground logs cannot. For field operations and logistics environments where device location tracking is an operational requirement tied to route compliance and asset tracking, background location data at configurable intervals produces the operational dataset the use case requires.

Under DPDPA Rules 2025, the collection of background location data from employee devices constitutes processing of personal data. Organisations implementing background location tracking are required to ensure that the processing is based on a legitimate purpose, that employees are informed of the tracking, and that the data is retained only for the period necessary for the stated purpose. Akku MDM’s group-based policy model supports scoping background location tracking to specific device groups, allowing organisations to apply tracking only to the roles and use cases where it is operationally justified rather than to the entire enrolled fleet. 

What to Check in Your Current MDM Location Configuration

Open your MDM console and pull the location history for three enrolled Android devices used by field employees. Count the number of location data points recorded during a standard eight-hour shift. If the count is in single digits, the MDM is using foreground-only location access. The location compliance dashboard is showing you check-in points, not continuous shift coverage.

Check the Android permission state for the MDM app on those devices. If the location permission shows as ‘While using the app’ rather than ‘Allow all the time’, background location access has not been granted. The MDM platform is architecturally limited to foreground-only reporting. For environments where continuous location coverage is operationally or contractually required, Akku MDM’s background location tracking capability closes the gap without requiring a change to the device management model.

Explore Akku MDM Capabilities  |  Talk to the Akku Team 

Questions IT and Security Teams Ask About Android MDM Background Location Tracking

Q: What is the technical difference between ACCESS_FINE_LOCATION and ACCESS_BACKGROUND_LOCATION on Android?

A: ACCESS_FINE_LOCATION grants an application the ability to receive precise location updates from GPS and network sources. It is classified as a foreground permission on Android 10 and later, meaning it allows location access only while the app is in the foreground or while a foreground service is running with the location foreground service type declared. ACCESS_BACKGROUND_LOCATION is a separate permission that extends location access to background operation, allowing the app to receive location updates regardless of whether it is the active foreground application. Android 11 and later require this permission to be granted separately through system settings, where the user explicitly selects ‘Allow all the time’ rather than ‘While using the app.’ The two permissions have different grant flows and different battery impact profiles.

Q: How does Akku MDM implement background location reporting without draining the device battery?

A: Akku MDM’s background location worker uses Android’s WorkManager with a configurable periodic task interval. WorkManager is battery-optimised by design: it batches work requests with other background operations and respects Android’s Doze and App Standby restrictions while still delivering location updates at the configured interval. Administrators set the reporting interval based on operational requirements. A thirty-minute interval produces sixteen data points over an eight-hour shift with minimal battery impact. Shorter intervals are available for environments requiring tighter tracking, with the understanding that battery consumption scales with reporting frequency.

Q: What happens to the background location track if the device loses connectivity mid-shift?

A: Akku MDM’s location worker stores location events locally on the device when the MDM platform is not reachable. On connectivity restoration, the stored events are uploaded to the Akku console with their original timestamps. The location track in the admin console reflects the full shift coverage, including the offline period, not just the connected periods. This is relevant for field environments where network connectivity is intermittent, such as warehouses with coverage gaps or field sites outside urban areas.

Q: How does DPDPA apply to background location tracking of employee devices?

A: Under DPDPA Rules 2025, background location tracking of an employee’s Android device constitutes processing of personal data. The data fiduciary, which is the employing organisation, is required to ensure the processing is based on a legitimate purpose, that the employee is informed of the tracking, and that the data is not retained beyond the period necessary for the stated purpose. For corporate-owned devices, the employment agreement and device use policy can establish the legitimate purpose and notification requirement. For BYOD devices, the explicit permission grant required by Android for background location access serves as part of the user notification, but the organisation should ensure the permission request is accompanied by a clear explanation of what data is collected, how it is used, and how long it is retained.

Q: Can background location tracking be applied to specific device groups rather than the entire enrolled fleet?

A: Yes. Akku MDM’s group-based policy assignment allows background location tracking to be applied at the organisational unit or user group level. An administrator can enable background location for field operations devices while leaving office-based devices on foreground-only location or no location tracking. This allows the organisation to scope continuous location tracking to the roles and use cases where it is operationally justified and to maintain a clear, defensible basis for the processing under DPDPA and similar data protection requirements.

Q: How does background location tracking interact with Akku MDM’s work profile isolation on BYOD devices?

A: Work profile isolation on Android separates corporate applications and data from personal applications and data within the same device. The work profile runs as a separate user space, but location services operate at the device level rather than at the profile level. Background location tracking granted to the Akku MDM app applies to the device as a whole, not only to the work profile. This means background location data is collected from the full device, not only from work profile activity. For BYOD deployments, this distinction should be addressed explicitly in the device use policy and the permission grant flow, so that employees understand the scope of location data being collected before granting the permission.

When did your MDM platform last produce a complete list of every application installed on every enrolled device?

Not the applications you deployed through the MDM. Every application currently installed on each managed device, including what was installed after enrollment, outside the managed profile, or through channels your deployment policy did not account for.

For most organisations the honest answer is: it has not. MDM enrollment applies policies and configurations at the point of registration. It does not run a continuous inventory of what is installed on each device and surface that data in a queryable form. The policy says no unauthorised applications. Whether any unauthorised applications are actually present on enrolled devices is a question the platform is not answering. 

This gap has three specific consequences. An unauthorised application installed after enrollment is invisible until someone manually checks. A CVE-affected package version that was not updated when the disclosure was published sits on managed devices without the security team knowing which devices are affected. A shadow IT tool installed to handle a workflow that approved applications do not support creates a data handling exposure that nobody detected because nobody was looking.

This blog covers why MDM enrollment and MDM inventory are two different capabilities, what per-device application inventory changes at the operational level, and how package-level visibility connects to vulnerability management and compliance. 

Why MDM Enrollment Is Not the Same as MDM Inventory 

MDM enrollment is a point-in-time configuration event. When a device enrolls, the MDM platform pushes the defined policy set: password requirements, screen lock settings, work profile configuration, approved application list, network access rules. The device is now managed. The configuration baseline is applied.

What happens after enrollment is outside the scope of most MDM policy enforcement mechanisms unless the platform is specifically configured to continuously monitor device state. Applications installed from the personal profile on a work profile device, applications sideloaded outside the managed play store channel, and applications present on the device before enrollment on a BYOD deployment are not automatically surfaced in the MDM admin console as policy violations.

The result is a managed device estate where compliance is declared at enrollment and assumed continuously, rather than verified continuously. The policy exists. The enforcement evidence does not.

What the Gap Costs Operationally

Unauthorised Application Detection 

An employee installs a personal file-sharing application on their enrolled work profile device. The MDM policy prohibits unauthorised applications. The application is present. The MDM admin console shows the device as compliant because it has not run an inventory check against the approved application list since enrollment.

For ITeS and BPO organisations where employees access client systems from managed devices, an unauthorised application capable of handling clipboard data or capturing screen content creates a direct client data exposure risk. The contractual obligation to maintain secure managed devices is not satisfied by a policy that is never verified.

CVE-Affected Version Detection

A vulnerability disclosure identifies a specific version of a widely-used Android application as affected. The CVE is published with the affected package identifier and version range. Without per-device application inventory, the answer requires manually checking representative devices or waiting for the next managed application update cycle. With inventory data that includes package identifiers and version numbers for every installed application on every enrolled device, the query is immediate: return all devices where package identifier X is installed at version Y or below. 

Shadow IT Discovery

Shadow IT on managed devices is a data governance problem that most organisations discover reactively. An employee uses an unapproved note-taking application to capture meeting minutes containing client information. A developer uses a personal SSH client on their managed device. All of these create data handling exposures the organisation did not authorise and cannot manage without knowing the applications exist. Per-device inventory makes them visible.

What Per-Device Application Inventory Captures

Akku MDM’s per-device application inventory collects the installed application list from each enrolled Android device on a regular automated schedule. For each installed application, the inventory captures the application name, the package identifier in reverse domain notation, the installed version number, and the install date where available from the device.

The package identifier is the technically precise field that matters for security and compliance workflows. CVE databases reference affected software by package identifier. Vulnerability management tools query by package identifier. The inventory output uses the same identifier format, making cross-referencing against CVE feeds a direct comparison rather than a fuzzy name-matching exercise.

The inventory covers applications installed in the managed work profile and, where the device configuration and Android version permit, applications visible in the personal profile. The visibility scope in the personal profile is governed by Android’s enterprise privacy framework. Akku MDM operates within these framework boundaries.

How This Connects to App Whitelisting and Policy Enforcement

Akku MDM‘s app whitelisting and blacklisting capability is the enforcement layer. Per-device inventory is the visibility layer. Used together, the inventory identifies what is present and the policy defines what is permitted. The gap between the two is the enforcement finding.

For organisations managing compliance under DPDPA Rules 2025, the ability to demonstrate that enrolled devices carry only approved applications is part of the technical evidence that the device security standard is being maintained. A policy document is not sufficient. Inventory evidence that the policy is being met is what the compliance record requires.

The Three Questions Worth Asking About Your Current MDM Deployment

Navigate to your MDM admin console right now and open the record for any enrolled device that has been active for more than six months. Can you see a complete list of every application currently installed on that device? If the answer is no or partial, the inventory visibility gap is confirmed.

If a CVE disclosure was published today for a specific Android application package, how long would it take your security team to produce a list of every affected enrolled device? If the answer requires anything beyond a query against an inventory database, the data is not available in the form that vulnerability management requires.

For any enrolled device in your estate, can you confirm that the applications present today match the approved application list without physically inspecting the device or asking the user? If not, the compliance posture that Akku MDM is designed to maintain is being declared rather than demonstrated.

Explore Akku MDM Capabilities |  Talk to the Akku Team 

Questions IT Security and MDM Administrators Ask About Per-Device Application Inventory

Q: Does per-device inventory cover applications installed in the personal profile on a BYOD work profile device?

A: The scope depends on enrollment type, work profile configuration, and Android version. For fully managed corporate-owned devices, inventory covers all installed applications. For work profile deployments on personally-owned devices, managed work profile applications are always visible. Personal profile visibility depends on what Android’s enterprise privacy framework permits under the organisation’s MDM policy configuration. Akku MDM operates within these framework-defined boundaries.

Q: How does the package identifier field support vulnerability management workflows?

A: CVE databases reference affected software by package identifier, the reverse domain notation string that uniquely identifies an Android application. When a CVE disclosure identifies an affected package, the query against the Akku MDM inventory uses the package identifier directly: return all devices where this identifier is present at a version within the affected range. This produces a targeted list of affected devices without name-matching ambiguity. 

Q: How frequently does the inventory update?

A: The inventory updates on a regular automated schedule. The specific interval depends on MDM policy configuration and device connectivity state. Devices in active use with network connectivity update more frequently. The admin console displays the timestamp of the most recent inventory collection for each device.

Q: How does per-device inventory connect to DPDPA Rules 2025 device security requirements?

A: DPDPA requires data fiduciaries to implement technical measures to protect personal data, including ensuring access to personal data systems comes from devices meeting a defined security standard. Per-device application inventory provides the continuous verification evidence that policy enforcement alone cannot produce. The inventory record shows what was present on each device at a given point in time, which is the evidentiary basis for demonstrating that device security standards were being maintained continuously rather than declared at enrollment.

Q: What is the difference between app whitelisting and per-device inventory and why are both needed?

A: App whitelisting is a policy control defining which applications are permitted. Per-device inventory is a visibility control showing which applications are actually present. Policy without inventory means you have declared what should be present but have no mechanism to verify it. Inventory without policy means you can see what is present but have no standard to compare it against. The combination produces enforcement evidence rather than policy documentation.

Q: Can the inventory data be accessed programmatically for integration with vulnerability management or SIEM tools?

A: Yes. Inventory data is accessible through the Akku admin console and the Akku API. The API allows programmatic retrieval per device or across the full enrolled device estate. The package identifier field enables direct comparison between enrolled device inventory and CVE feed data without requiring custom field mapping or name-matching logic.

When businesses move to remote operations, teams tend to prioritize fast internet and collaboration tools. However, problems arise when sensitive data ends up on the personal smartphones of employees. This is where MDM becomes critical. 

MDM is a system that helps organizations manage and secure the mobile devices their teams use for work. It sets rules for apps and access and ensures that devices follow company standards. Choosing the right MDM software is often the first step toward making mobile work safe and predictable.

What is MDM and Why It Matters

MDM Full Form

MDM stands for Mobile Device Management. MDM helps you make each mobile device in your organization into a managed endpoint. IT teams can set rules, add or restrict apps, and push updates. It can also erase data if a device is lost, and also keeps work and personal information separate on the same device. If you have a checklist like inventory, policy, and onboarding, then you have the start of a solid MDM solution strategy.

Core Features of a Mobile Device Management System

A strong mobile device management system feels invisible. Any IT team can manage hundreds of devices without strain. The real power of MDM lies in its simplicity. It turns complex tasks into everyday routines that anyone can handle. Here are the features no mobile device management software should ever be without.

• Remote setup and configuration. A new hire unboxes a mobile device, and it arrives with the right apps and security settings. No on-site handover is needed. This is often the first reason companies adopt remote device management software.

• App control. Organizations use app whitelisting to allow only approved applications and app blacklisting to block those considered risky. This ensures that every device runs only trusted software.

• Security enforcement. Policies for security parameters such as passwords and automatic updates help address core mobile device management security priorities.

• Remote lock and wipe. Admins can lock or erase devices quickly using remote device management software features.

• Inventory and reporting. IT can see what devices exist in the system, who uses them, and whether they meet compliance rules. Visibility is the foundation of any reliable MDM software deployment.

• Platform support. The best MDM solutions work across operating systems such as iOS, Android and Windows, ensuring every mobile device follows the same security and management policies.

These capabilities don’t just reduce risk – they cut the time IT spends on routine tasks. For small and medium businesses, that saves money and reduces outages. This is why adopting MDM tools is less about cost and more about predictable operations.

Why Traditional IT Security Isn’t Enough Anymore

In a world of remote and hybrid operations, if your security model assumes a single office, you have a problem. Firewalls and office network controls work well when everyone logs in from the same place. Remote work breaks that assumption. Employees use home Wi-Fi, public hotspots, and cellular networks. They work from hotels, trains, and co-working spaces.

That dispersion changes the threat model. A firewall can no longer protect every entry point. An employee might download a file on a personal phone and then access the same file from a work laptop. Legacy tools were not designed to handle this level of complexity. With mobile device management, security shifts focus from the network to the device. It accepts that devices travel, and it protects them directly.

How MDM Solutions Enable Remote Device Management

Remote Device Management is the difference between a policy on paper and a policy in action.

Consider patching. In an office, IT schedules a maintenance window and updates machines. For distributed teams, coordinated patching is harder. Remote device management software can push updates automatically and verify installation. This cuts the window of vulnerability.

Think about access control. With MDM solutions, a machine that fails security checks can be quarantined. It can be prevented from reaching critical systems until it meets standards. That is a practical control that reduces exposure without blocking users entirely.

Finally, consider BYOD situations. Employees expect privacy. IT needs control. MDM tools provide profiles and containers. Work data stays inside the container. Personal data remains untouched. This balance keeps employees willing to use personal devices while protecting company assets.

If you are evaluating tools, a simple way to compare is to create an MDM tools list that includes onboarding time, reporting, encryption standards, and whether the vendor provides templates for compliance.

Specialized Use Cases of MDM in Remote Work

1. Managing devices across multiple locations

Work is no longer tied to one building. Employees check emails from home, sit in cafes, and travel between cities. Each mobile device carries access to sensitive information. MDM quietly ensures that every device follows the same rules. IT can trust that the network stays secure even when the team is scattered.

2. Onboarding remote teams instantly

New hires may never step foot in an office. A phone or tablet arrives at their doorstep. With MDM, the device can be set up remotely, so the right work apps are installed and work profile security settings are put in place. Work starts without delay, and IT is confident that every device is compliant.

3. Handling lost or stolen devices remotely

A phone left in a taxi or forgotten at a café can put company data at risk. With MDM, administrators can lock the device or erase company data from anywhere, mitigating the risk of potential breaches.

4. Ensuring compliance without physical checks

Clients and regulators want proof that security policies are followed. MDM makes it possible to gain comprehensive visibility from a single dashboard, with reports on which devices meet standards and which need attention.

5. Protecting data on personal devices

When employees use personal phones for work, MDM separates personal information from company data. Work stays secure on a dedicated work profile, while private data stays private. And that means employees can use their own devices without creating risk for the organization.

6. Responding to threats in real time

Remote work increases the number of points of vulnerability. MDM observes devices, and raises alerts when policies are violated. This means IT can step in before small issues turn into serious problems.

Future of Mobile Device Management in Remote-First Companies

Remote-first does not mean office-free. It means designing systems for flexibility. The future of Mobile Device Management (MDM) will reflect three trends.

First, automation will grow. Tools will detect anomalies and take remediation steps without human intervention. That reduces response time. Second, MDM software will integrate more tightly with collaboration platforms. Security will follow the conversation and the file, not only the device. Third, compliance capabilities will be built in. Companies will get pre-configured policies for popular regulations.

Expect MDM solutions to fold reporting, threat signals, and device posture into a single dashboard inside your mobile device management system. That will make it easier to answer a regulator or an affected customer quickly and with evidence.

For leaders, that future offers a choice. You can treat device security as a recurring cost. Or you can make it a strategic enabler. The latter choice makes remote work reliable. It turns flexibility into a competitive advantage.

Powering the Future of Remote Work with Akku’s MDM Solution

Remote work has transformed the office into a network of homes, cafes, and coworking spaces. This shift made mobile devices the heart of productivity and security. Without a system to manage them, businesses face risk and confusion.

Akku’s MDM solution puts control in the hands of IT teams without adding complexity.

Unlike many MDM platforms that are complex and expensive to deploy, Akku delivers the features you really need to get your mobile device management strategy off the ground quickly and efficiently. For your business, that means time and resources you can invest into innovation and growth.

Talk to us today to find out how Akku can help your business.