Devices rarely fall out of policy all at once. They drift one exception at a time, and in a fleet spread across stores, depots, or provinces, those exceptions add up faster than anyone can see them.
If you’re responsible for hundreds of store or driver devices and you can’t say with confidence how many meet your security policy today, you’re not alone. The cause is usually how devices are enrolled, set up, and watched, not a lack of effort from your team.
This post covers what policy drift looks like, why it happens in multi-site fleets, and the practical steps that keep devices consistent without adding headcount.
Definition
Device policy drift is the gap between the security and configuration policy you set in your mobile device management (MDM) platform and what’s actually running on each device. It shows up as devices that aren’t enrolled, are missing updates, have settings changed locally, or haven’t checked in for weeks.
What device policy drift looks like in a multi-site fleet
Drift is easy to miss because the MDM console only reports on devices it can see. A device that was never enrolled, or that stopped checking in a month ago, doesn’t show up as non-compliant. It just doesn’t show up.
In stores, drift often looks like devices set up differently from one location to the next. One store’s handhelds have a newer app version, another’s have the camera unlocked, and a third has devices that were reset and never re-enrolled.
In driver fleets, it looks like devices that spend days out of coverage, miss updates, and come back running an older configuration. Across several provinces, it can also mean policy settings that were adjusted for one region and never documented.
Why devices drift out of policy
Most drift traces back to a handful of causes. Each one is ordinary on its own, which is why it’s easy to overlook.
Manual enrolment. When devices are enrolled by hand at each site, steps get skipped or done differently. Devices that are reset in the field are often never enrolled again.
Shared devices set up as personal ones. Store and warehouse devices are usually shared between shifts. If they’re set up as if one person owns them, sign-ins, apps, and data pile up in ways the policy never anticipated.
Local workarounds. When a policy blocks something a site needs, someone finds a way around it. The workaround solves the shift’s problem and creates a permanent exception.
Devices that stay offline. Devices that spend long periods out of coverage, or sit in a drawer as unofficial spares, miss updates and policy changes.
No one watching the exceptions. Many teams set policy carefully and then only look at compliance when an audit or incident forces it. By then the drift is months old.
Here’s what actually happens in many fleets. The console shows a high compliance rate, everyone relaxes, and nobody asks how many devices the console can’t see. The audit finding that follows is usually about those missing devices, not the ones on the report.
How to keep devices consistent across sites
Consistency comes from taking the manual steps out of setup and making exceptions visible every week. These are the practices that make the biggest difference.
- Enrol devices automatically. Zero-touch enrolment lets company devices arrive with your apps and security settings applied when they’re first turned on, so a reset device re-enrols itself instead of waiting for someone at the site.
- Set up single-purpose devices as dedicated devices. Google defines a dedicated device as a company-owned device locked down to a limited set of apps for one purpose. Scanners, kiosks, and driver devices usually belong in this mode.
- Use shared-device setups for shift work. Devices passed between workers should sign each person in and out cleanly, so nothing from one shift carries into the next.
- Build one policy baseline per role. A store associate, a driver, and a supervisor need different settings. Define each once and apply it everywhere, rather than adjusting site by site.
- Review exceptions weekly. Report on devices out of policy, devices behind on updates, and devices that haven’t checked in, with a named owner for each list.
The zero-touch provisioning FAQ explains how automatic enrolment works for Canadian fleets and what it needs from your device supplier.
What’s different for fleets across provinces
A single national policy is the right starting point, but it isn’t always the whole answer. Provincial privacy and employment rules can affect what you monitor on employee devices and what you need to tell staff about it.
Federally, PIPEDA makes you accountable for personal information on devices you control. Quebec’s Law 25 adds obligations of its own, including a privacy impact assessment before personal information is transferred outside Quebec, and Bill 96 affects the language of interfaces and instructions for Quebec staff. Just know that these rules shape policy settings such as location tracking, so confirm the details with your legal team rather than copying another province’s setup.
For driver fleets, the transportation and logistics overview covers the device types and conditions that make consistent policy harder on the road.
Who should own device policy compliance?
Policy compliance needs a named owner, not a shared assumption. In many organizations, IT sets the policy, operations runs the sites, and nobody is accountable for the gap between them.
The owner doesn’t have to fix every device personally. They need the weekly exceptions report, the authority to chase sites, and a clear path for devices that need re-enrolment or replacement. The endpoint management strategy guide covers how compliance fits into a wider security program, and NIST’s guidelines for managing mobile device security are a useful external reference for the controls themselves.
If key settings and enrolment steps live in one administrator’s head, drift accelerates the moment that person is away. The post on what happens when your MDM admin quits covers that risk.
Where outside help fits
Keeping a large fleet in policy is steady, detailed work. It’s manageable in-house when the fleet is small, sits in one region, and someone has time every week to work the exceptions.
As the fleet spreads across sites and provinces, many organizations hand the day-to-day administration to a managed service. Through MDM as a Service, our certified Canadian technicians administer your MDM platform, keep policy baselines current, and work the exceptions with your team, while you keep ownership of the policy itself. The MDM as a Service guide explains how that model works.
Just know that it fits best for fleets of several hundred devices or more across multiple sites. A small fleet in one location can often stay consistent with good enrolment habits and a monthly review.
Questions we hear about MDM policy drift
Why do mobile devices drift out of MDM policy?
Usually because of manual enrolment, shared devices set up as personal ones, local workarounds, devices that stay offline, and nobody reviewing exceptions regularly. Each cause is small, but across hundreds of devices and many sites they add up to a large share of the fleet running outside your intended policy.
How do you enforce consistent MDM policies across many locations?
Remove manual setup and make exceptions visible. Use zero-touch enrolment, set single-purpose devices up as dedicated devices, use shared-device setups for shift work, and apply one policy baseline per role. Then review out-of-policy and missing devices weekly, with a named owner for each list.
How do I find devices that aren’t reporting to our MDM?
Compare your MDM device list with purchase records, carrier lines, and site counts. Devices that appear in those records but not in the MDM, or that haven’t checked in for weeks, are your blind spots. Locate them, then re-enrol, replace, or retire each one.
Where to start
Pull a list of every device that hasn’t checked in to your MDM in the last 30 days, and compare your MDM count with your purchase and carrier records. The gap between those numbers is the real size of your drift problem. Fix enrolment for that group first, then start the weekly exceptions review.
References
- Android Enterprise, Zero-touch enrollment. Devices configured with apps and security settings out of the box.
- Google for Developers, Android Enterprise terminology. Definition of a dedicated device.
- NIST, SP 800-124 Rev. 2, Guidelines for Managing the Security of Mobile Devices in the Enterprise (2023). Reference for centralized device management controls.