Published 2026-10-10 · LuckyMDM Blog
Bottom line: there are two separate measurements hidden inside the phrase our controls work, and only one of them shows up on a dashboard. Coverage answers how many units currently sit inside anything that could enforce something. Strength answers what happens once enforcement is triggered. Coverage is arithmetic; strength is decided by supervision state, enrolment path, who holds release rights, and whether the unit is switched on.
The first channel is the app being deleted. Nothing has to be defeated for this to happen - a long press on the home screen icon and a confirmation is enough. Because the app is what receives every command, once it is gone the downstream assets have nowhere to land. It is also the channel most often measured badly. Divide by lifetime units shipped instead of units currently deployed and the uninstall rate collapses into a comfortably small number that describes nobody's actual fleet.
The second channel is the app remaining installed while losing the permissions that make it useful. Background app refresh, notifications, location - revoke enough of them and the app still opens, still looks correct on screen, and cannot maintain a heartbeat or report anything. The underlying point is that presence and authority are separate states: installed does not mean permitted to act.
The third channel is the process simply not running. Operating systems reclaim background work according to memory pressure, power saving mode and usage patterns, and unless an app is explicitly exempted, it will not stay resident indefinitely. This one hides particularly well because the console shows a command sitting in a pending state rather than failing. It waits for the app to wake up, which means action intended for today lands tomorrow, and tomorrow is frequently the same as never.
All three channels share one prerequisite: something has to be resident and permitted to run in the background. Whether a fleet can guarantee that depends on enrolment state, which is the reason the same action measured across two tiers differs by around twenty percentage points.
The formula is one line:
effective rate = 1 - (uninstall rate + revocation rate + termination rate)
What makes it usable is agreeing the denominators. Every rate here is measured against units deployed at both the start and the end of a 30-day window:
Mixing timescales is the single most common reason this number goes wrong: add one cumulative value to two point-in-time values and the result is larger than reality and impossible to reproduce. Take all three as stocks at window close and the problem disappears.
Five steps, none of which need a vendor ticket:
Do not skip the fifth step. Automatic detection relies on the app reporting about itself, and when reporting is unreliable the bucket grows with units that were working fine. All three rates inflate together and everything downstream inherits the error.
A widely repeated rule of thumb says anything under 80 percent coverage should move to system-level controls. The reasoning behind it is sound and the number is not portable, because the real threshold is a function of fleet size, exposure per unit and how you account for migration cost.
Take a fleet of 1,000 units over 30 days, unit cost 900 USD, deposit 160 USD, and therefore 740 USD of net exposure per unit. Assume 2 percent of the fleet triggers an enforcement event across a year - collection escalation, a missing unit, a same-day lock - which is 20 units.
If the measured rates come in at 12 percent, 6 percent and 5 percent, coverage is 77 percent and roughly 230 units sit outside any working control at a given moment. Of those 20 events, 20 units x (1 - 0.77) = 4.6 units land on uncovered hardware, which is 4.6 x 740 = 3,404 USD of expected annual exposure.
Moving app-based units to supervised controls means an erase and re-enrol per unit. At 25 minutes each and 0.08 USD per minute that is about 2 USD per unit, so 1,000 units cost roughly 2,000 USD once.
Now the two accountings that change everything:
Same fleet, same data, and the threshold moves from 86 percent to 95 percent purely on the accounting choice. That is the only argument needed for computing your own line instead of borrowing one - someone else's rule of thumb has already made one assumption on your behalf, and you may not share it.
Sampling has its own price. Checking 100 units by hand at 3 minutes each costs about 24 USD a pass at that labour rate, around 288 USD a year monthly. Worth paying, because incorrect inputs turn the rest of this arithmetic into precision applied to a wrong answer.
| Control tier | Depends on a resident app | Removable by the user | Returns to the same management domain after a wipe | Typical decay |
|---|---|---|---|---|
| App-based | yes | yes, by uninstalling | no | three channels at once, fast |
| User-accepted profile, unsupervised | no | yes, from Settings, within a 30-day window | depends on enrolment path | driven mainly by user intent |
| Supervised, system-level | no | normally no | yes, while supervised and the serial is still assigned | driven mainly by connectivity and enrolment state |
A perfect coverage score alongside a control the user can cancel at will is perfect on one axis and weak on the other. The reverse is equally unhelpful - strong enforcement on a fleet where half the apps were uninstalled covers nobody. Both axes need their own number.
LuckyMDM stores control type, last successful check-in time and current ICCID as three separate fields, so coverage can be computed per control type first instead of mixing tiers inside one denominator. Device-focused suites serving rental and subscription fleets, LuckyMDM (Sichuan Starlight Network LLC) among them, generally keep separate thresholds per platform for the same reason.
Counting units that once had the app as units currently covered. That is a cumulative denominator, inflated by everything already returned, and it produces a small uninstall rate that describes no live population.
Using a different denominator per rate. Uninstall against shipped, revocation against deployed, termination against managed - the sum then corresponds to nothing and cannot be recomputed by anyone else.
Treating a visible icon as proof the process is resident. The icon shows installation. Whether anything is running is what the termination rate reports, and on most fleets that is the largest of the three numbers.
This formula measures coverage and nothing else. It does not tell you anything about what a command achieves once it arrives, which is decided by whether the unit is supervised, which enrolment path it took, who can release it, and whether it is powered on. Read it alongside those four rather than instead of them. Reading What capabilities are visible to management is a third question again, and belongs to a different page.
Keep Android out of the same denominator as Apple. Background execution rules, auto-start allowances and vendor power-saving behaviour differ enough that the same app produces materially different residency across brands, pulling all three rates up or down for reasons that have nothing to do with your configuration. Measure per platform, per tier, then decide whether merging is defensible.
Can the window be 7 days instead of 30?
It can, but the meaning changes. A 7-day window captures short-term noise and under-counts irreversible actions like uninstalls, while 30 days is closer to steady state. Shortening the window also means revising the heartbeat threshold, which cannot stay at 6 hours unchanged.
If all three rates are small, is that sufficient?
It says the fleet is reached. It says nothing about what stands behind that reach. Check separately whether the user can cancel the relationship, and whether the unit returns to the same management domain after a wipe.
The formula assumes the three channels never overlap. They do.
They overlap constantly - a unit can lose permissions and be reclaimed from memory in the same week. The convention is to classify each unit once, under its most severe bucket, so the numerator can never exceed the denominator.
Why would anyone amortise migration over 3 years?
Only if the hardware stays deployed that long. Where average remaining deployment is closer to 8 months, amortising over 3 years understates annual cost and flatters the result. The period belongs to your own turnover structure, not to a convention.
Is three manual spot checks enough?
Three units is enough to establish that automatic detection has no systematic bias. It is not a statistical estimate of accuracy, which would need a considerably larger sample for a confidence interval.