Push a policy to 3,000 scanners. The console says every one applied. Then a store starts kicking bad data downstream, and you find the scanner was quietly reading the wrong symbology the whole time. The policy was sent. The device acknowledged it. The scanner never actually changed.

That gap between "sent" and "applied" is sharpest on rugged and scanner hardware, and it's the part no console fully answers for you. The authoritative way to confirm a policy applied is to read the device's actual state directly, through on-device inspection or command-line tools like ADB. Every server-side "applied" report is inferred until you do. For some configurations, especially DataWedge and scanner settings, no reliable readback exists, and the honest answer is "you can't fully."

TL;DR

• "Sent" and "applied" are different states. Your console can confirm a policy was delivered and acknowledged. It cannot always confirm the policy took effect on the device.
• Verifying application today is a patchwork of on-device checks, command-line inspection, OEM tooling, and log analysis. The methods available vary by platform and OEM.
• For some configurations, especially rugged and scanner hardware, there is no reliable way to read applied state back off the device. No platform changes that. It's an OEM and OS observability limit.
• The operators who don't get burned are the ones who know exactly which of their verification checks are authoritative and which are inferred.
• Use this as a pre-reliance checklist: verify before you depend on a policy across the fleet. For Android command-level verification syntax, defer to Android's ADB documentation; for OEM-specific configs, defer to your OEM's developer resources.

"Sent" vs. "applied": what your console can and can't confirm

Every MDM policy moves through three states: sent, acknowledged, and applied. Most consoles report the first two reliably. The third is where the gap lives.

"Sent" means the MDM server dispatched the policy payload to the device. "Acknowledged" means the device received the payload and responded to the server. "Applied" means the device actually changed its configuration to match what the policy specified. These are three distinct states, and conflating them is how fleet-wide misconfigurations go undetected.

A fleet-wide policy pushed to 10,000 devices and applied on 9,400 looks identical in any console that stops reporting at "sent" or "acknowledged." The 600 devices that received the payload but didn't apply the configuration don't raise alerts, don't generate tickets, and don't show up in any standard report. They sit in the fleet as silent exceptions until something downstream breaks.

On a scanner fleet, those silent exceptions don't just sit there. A scanner running the wrong DataWedge profile scans the wrong barcode format, fires the wrong intent, or parses data the receiving app can't use, and it does all of it while reporting healthy. The 600 silent devices in a phone fleet are a compliance problem. In a warehouse or at a checkout line, they're bad data flowing into systems that trust it. 

The reason this gap exists is architectural: the MDM protocol was designed for policy delivery, not for bidirectional state verification. The server pushes, the device acknowledges, and the server records the acknowledgment. Reading back the actual device state to confirm the configuration matches the policy is a separate operation that depends on what the OS and the OEM expose. Some configurations expose full readback. Others expose partial readback. Some expose nothing at all.

How to verify a policy applied: methods ranked by how much you can trust them

No single verification method covers every configuration type on every device. What follows is a breakdown of the methods that exist, labeled by how authoritative each one is.

On-device confirmation (authoritative, doesn't scale)

Physically inspecting the device is the gold standard. Open settings, check the configuration, confirm it matches the policy. This is authoritative because you're looking at the actual device state, not a server-side report of what was sent. The obvious limitation: it doesn't scale beyond a handful of devices. For fleet verification, this method works only as a spot-check to validate that other methods are returning accurate results.

Command-line and ADB inspection (authoritative for supported configs)

For Android devices, ADB (Android Debug Bridge) provides direct access to device state for many configuration types. You can query installed packages, check system properties, read configuration files, and verify that specific settings match the policy. The output comes from the device itself, not from a server-side record, which makes it authoritative for the configurations it can read.

The limitation is coverage. ADB can verify system-level settings, installed applications, and many device restrictions. It cannot verify every possible configuration type, especially OEM-specific settings that live outside standard Android APIs. For exact commands and syntax, defer to Android platform documentation and your OEM's developer resources.

OEM tooling readback (partial, not authoritative)

Some OEMs provide proprietary tools or APIs that report configuration state. These are useful but require a critical distinction: apply-feedback is not the same as state readback.

Apply-feedback tells you the device attempted to apply a configuration and reported success or failure. State readback tells you the device's current configuration matches what the policy specified. The difference matters because a device can report "applied successfully" and still be in a different state than expected. Firmware updates, user interaction on non-locked-down devices, and OEM-specific behaviors can change configurations after an "applied" signal was sent. Treat OEM apply-feedback as a useful signal, not as authoritative verification.

Log inspection (inferential, useful for troubleshooting)

Device logs and MDM server logs capture a record of policy delivery, processing, and errors. Log inspection is inferential rather than authoritative: the logs tell you what the device attempted to do, not necessarily what state the device is in right now. Logs are most valuable for diagnosing why a policy didn't apply, not for confirming that it did. For log format, location, and filtering syntax, defer to your platform's documentation.

Sampling strategy for representative device subsets

For fleet-wide verification, combine methods. Use authoritative checks (on-device or ADB) on a representative sample, then compare those results against the server-side reports and OEM feedback for the same devices. If the authoritative checks match the server reports, you have higher confidence that the server reports are accurate across the rest of the fleet.

Build your sample to cover the variables that matter: device model, OS version, network conditions, and the specific configuration types you're verifying. A 50-device sample from a homogeneous fleet tells you more than a 200-device sample from a mixed fleet where you didn't control for the variables that cause divergence.

Execution-result reporting, where available, adds another layer. Platforms that surface per-device success, failure, and skipped status for each policy action give you a structured signal to work from. This isn't the same as reading applied state off the device. It's the system telling you what it attempted and what it observed. Combined with authoritative spot-checks, execution results close most of the verification gap for configurations that support them.

Where verification is impossible (and what to do instead)

For event-based pushes like DataWedge profiles, scanner configurations, and OEM-specific AIDC settings, there is no reliable way to confirm applied state off the device. This isn't a platform limitation or a product gap. It's an OEM and OS observability limit. The configuration was designed to be pushed, not read back.

No MDM platform, including Esper, can read applied DataWedge or scanner configuration state back off the device and report it in a console. The data path doesn't exist. The OEM didn't build a readback API for those configurations, and the OS doesn't expose them through standard management APIs. Anyone claiming otherwise is either confused about the difference between apply-feedback and state readback, or selling you a capability that doesn't exist.

The honest move when verification is impossible: rely on execution-result signals rather than assuming a state readback exists. "Completed," "failed," and "skipped" statuses tell you whether the device attempted the configuration and what the system observed during that attempt. Combined with targeted on-device spot-checks on a representative sample from your fleet, these signals are the best available approximation.

Build your verification workflow around the distinction between authoritative checks and inferred checks. Know which of your configuration types support full readback, which support partial readback, and which support none. Document the verification method for each configuration type in your fleet. When someone asks "did this policy apply?", the answer should never be "yes" without specifying the method and its authority level.

How each major MDM platform handles this gap on Zebra hardware, and which ones surface execution results versus burying them, is its own comparison: see the platform breakdown for Zebra and rugged scanner fleets. The point for this checklist is method, not vendor: the teams that run resilient fleets at scale are the ones that don't treat "sent" as "applied." They verify what's verifiable, acknowledge what isn't, and build their operational processes around knowing the difference.

The bottom line

You can almost always confirm a policy was sent and acknowledged. Confirming it applied depends on what the OS and OEM expose. The operators who don't get burned are the ones who know exactly which of their checks are authoritative and which are inferred.

Book a Demo

Frequently Asked Questions

How do I check if an MDM policy applied to a device?

The most authoritative method is direct on-device inspection or command-line verification using tools like ADB. These read actual device state rather than relying on server-side delivery reports. For fleet-scale verification, combine authoritative spot-checks on a device sample with execution-result reporting from your MDM platform. The right method depends on the configuration type and what the OS and OEM expose.

What's the difference between a policy being sent and applied?

"Sent" means the MDM server dispatched the policy to the device. "Applied" means the device actually changed its configuration to match the policy. Between those two states sits "acknowledged," where the device confirms receipt. Most consoles report sent and acknowledged reliably. Confirming applied requires separate verification because the MDM protocol was designed for delivery, not bidirectional state confirmation.

Can you verify a DataWedge or scanner config applied remotely?

No. DataWedge profiles and scanner configurations are event-based pushes with no readback API. No MDM platform can read the applied state of these configurations back off the device. The best available signal is execution-result status (completed, failed, skipped) combined with targeted on-device spot-checks on a representative sample.

How do I confirm a policy applied across a whole fleet?

Use a sampling strategy. Run authoritative checks (on-device or ADB) on a representative subset, then compare those results against server-side reports for the same devices. If the authoritative checks match, you have higher confidence in the server reports across the rest of the fleet. Build your sample to cover device model, OS version, and network condition variables.

Why doesn't my MDM confirm a config actually took effect?

The MDM protocol was architecturally designed for policy delivery and acknowledgment, not for bidirectional state verification. Reading back actual device state is a separate operation that depends on OS and OEM support. Some configuration types expose full readback, others expose partial readback, and some expose no readback at all. This is an industry-wide architectural limit, not a vendor-specific gap.

What is apply-feedback vs. state readback?

Apply-feedback is a signal from the device that it attempted to apply a configuration and reported success or failure at the time of application. State readback is a query that returns the device's current configuration state. The difference matters because configurations can change after an "applied" signal was sent. Apply-feedback tells you what happened at one point in time. State readback tells you what's true right now. Treat apply-feedback as a useful signal, not as authoritative verification of current state.