Device Enrollment State and Device Application Inventory Are Two Different Datasets.

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.