Mobile device management (MDM) is the software that controls your enterprise devices—but for most Canadian organisations, the MDM licence is the easiest part. The hard part is running it. This post explains what MDM actually does, where it stops, and why the gap between owning an MDM platform and operating an MDM environment is where most enterprise fleets lose control. If you are evaluating how MDM fits within a broader operational strategy, our managed mobility services guide frames MDM as one pillar within a complete device lifecycle.
MDM software controls the device—it does not manage your fleet
A Director of IT at a Canadian logistics company opens their SOTI console on a Monday morning. Dashboard is green. Every device shows compliant. Then a warehouse supervisor calls: half the scanners on the floor are running an outdated WMS app version that crashes every 30 minutes.
The console says compliant. The floor says broken.
That gap—between what MDM reports and what workers experience—is where fleet operations actually live. And it is a gap that no software licence, regardless of vendor, is designed to close on its own.
MDM software is a control plane. It enforces policies, pushes configurations, and reports compliance status back to a dashboard. What it does not do is interpret that data, act on anomalies, or manage the physical and operational reality of devices in the field.
The distinction matters because IT teams are already stretched thin. According to Vanson Bourne research cited by Tangoe, IT teams spend an average of 34% of their time on mobile device management tasks. For a 10-person IT department, that is 3.4 FTEs absorbed by device logistics—the equivalent of a senior infrastructure architect and two technicians doing nothing but MDM operations. And that time investment still does not guarantee operational consistency on the floor.
Even the Government of Canada frames MDM as a tool requiring operational process around it. The Canadian Centre for Cyber Security’s ITSB-64 guidance on MDM defines it as a provisioning, control, and audit framework—not a managed service. The guidance is explicit: MDM is a technical capability that requires organisational processes to deliver outcomes.
Here is what actually happens when we audit a new fleet: the MDM console shows 95%+ compliance, but a physical device check reveals 10–20% of devices have stale app versions, expired certificates, or cached data from previous users. The console measures what the policy says. The device reflects what actually happened. Those are not the same thing.
What MDM software actually does well
MDM platforms are genuinely effective at what they were designed for: centralised policy enforcement, security controls, and remote management capabilities.
A properly configured MDM environment delivers real value. It enforces encryption and passcode requirements across every enrolled device. It enables remote lock and wipe when devices are lost or stolen—essential for any organisation handling sensitive data. It pushes app installations and updates from a central console rather than requiring physical access to each device. It monitors compliance status against your defined policies and flags deviations.
These are not trivial capabilities. For organisations managing distributed workforces, MDM provides a security and control layer that would be impossible to replicate manually.
The problem is not that MDM software is inadequate. The problem is that organisations expect it to do things it was never designed to do.
Where MDM software stops and operations begin
MDM cannot ship a replacement device when a scanner breaks on a Friday night in a distribution centre 400 kilometres from your IT team.
- It cannot repair a cracked screen or replace a battery that no longer holds a charge through a shift.
- It cannot negotiate your carrier contract, identify zero-use lines you are still paying for, or optimise rate plans across a fleet of 3,000 devices.
- It cannot track the stylus that went missing or the charging cradle that was borrowed and never returned.
- It cannot stage a new device with the 12 configuration steps required before it is actually ready for a frontline worker—OEMConfig profiles, app installations, peripheral pairing, network credentials, and the device-specific settings that make a generic Android handheld into a functional warehouse tool.
- And it cannot document chain-of-custody when that device reaches end-of-life, prove data erasure to a compliance auditor, or certify that no personal health information crossed the border during a repair.
MDM is one layer in a stack. When organisations treat it as the entire stack, gaps emerge—and those gaps show up as inconsistent worker experience, extended downtime, compliance exposure, and costs that never appear on the MDM dashboard.
The operational reality of MDM administration at enterprise scale
Administering an MDM environment for 500 devices is a part-time job. Administering it for 5,000 devices across multiple provinces, device types, and OS versions is a full-time operational discipline that most IT teams are not staffed for.
This is not a criticism of IT teams. It is a structural observation about how MDM administration scales—or fails to.
SOTI’s own definition of MDM emphasises that it “manages and secures mobile devices” as an ongoing operational function, not a one-time deployment. The vendor that sells you the licence is telling you it requires ongoing operational investment to deliver value. That message tends to get lost somewhere between the sales cycle and the renewal invoice.
We have taken over MDM environments where the previous administrator left the organisation six months earlier. The policies were still technically active, but nobody had updated the app whitelist, nobody had reviewed the compliance reports, and 300 devices had quietly fallen out of enrolment. The MDM was running. Nobody was driving.
The symptoms of an under-administered MDM environment are predictable:
- Devices showing compliant in the console but running outdated app versions in the field
- Security policies that were correct 18 months ago but have not been updated for new OS versions or threat vectors
- Enrolment gaps where devices were replaced but never properly re-enrolled
- Inconsistent configurations across locations because policies were applied ad hoc rather than systematically
- No clear audit trail of who changed what configuration and when
- Compliance reports that nobody reviews until an auditor asks
If three or more of these sound familiar, the issue is not your MDM software. It is the operational model around it.
Policy configuration drift across distributed fleets
MDM policies that were correct at deployment gradually drift as your fleet evolves.
Devices get replaced—but the replacement device runs a newer OS version that interprets the existing policy differently. Apps get updated by the vendor—but the new version requires permissions the old policy did not anticipate. Workers move between locations—but the location-based policy assignments were never updated when the Winnipeg depot expanded.
This is not negligence. It is the natural entropy of any fleet that is not actively administered.
In a homogeneous environment—200 identical iPhones in a single office building—drift is manageable. A generalist IT administrator can keep the policies current and the fleet consistent.
In a heterogeneous environment—Zebra scanners in warehouses, Honeywell handhelds in delivery vehicles, Samsung tablets in retail stores, iPhones for sales teams—drift compounds. Each device type has its own OS update cycle, its own configuration parameters, its own failure modes. Multiply that by 40 locations across four provinces, and you have a combinatorial problem that exceeds what any part-time administrator can track.
The MDM console does not flag drift. It flags non-compliance with the current policy. If the policy itself is stale, the console happily reports green while the fleet diverges from operational requirements.
App version consistency—the problem MDM creates when nobody is watching
Here is a scenario that plays out in nearly every distributed fleet we encounter.
An MDM pushes an app update to the entire fleet on a Tuesday evening. The policy is configured correctly. The deployment is scheduled for the maintenance window. Everything looks right in the console.
Wednesday morning, half the devices are running the new app version. The other half failed—some because they were powered off during the window, some because they were in areas with poor cellular connectivity, some because the device storage was too full to download the update, and a handful because the new app version is incompatible with the older OS version running on devices that were deployed 18 months ago.
The MDM console shows the deployment as “completed with errors.” The percentage looks acceptable—maybe 85% success. But on the warehouse floor, you now have two populations of workers running different app versions. The workflow that depends on a new feature in the updated app breaks for the workers still on the old version. The workers with the old version call the supervisor. The supervisor calls IT. IT opens a ticket.
Multiply this by every app update, every OS patch, every configuration change across a fleet of thousands of devices, and you understand why app version inconsistency is one of the most common operational complaints we hear—even from organisations with well-configured MDM environments.
The MDM pushed the update. Nobody followed up on the 15% that failed. Nobody reconciled the device OS versions against the app compatibility matrix before scheduling the deployment. Nobody checked whether the remote sites had reliable connectivity during the maintenance window.
The software worked. The operation did not.
This pattern—software working while operations fail—extends beyond app management into how MDM interacts with the physical devices themselves, particularly when those devices are not the smartphones and tablets that most MDM platforms were designed around.
MDM for rugged enterprise devices is not the same as MDM for smartphones
Every MDM vendor’s marketing shows a person holding a smartphone. Most of the devices we manage do not look like that.
They look like a Zebra TC58 with a pistol grip, a cracked screen protector, and a Bluetooth ring scanner paired to it. Or a Honeywell CK65 that has been dropped on a warehouse floor twice this month. Or a vehicle-mounted computer bolted into a delivery truck cab that experiences temperature swings from -20°C to +30°C depending on the season.
The MDM configuration for these devices is not the same as configuring an iPhone—and the operational support they need is not even close.
Rugged enterprise devices require specialised MDM configuration that standard smartphone profiles do not address. Zebra Technologies’ OEMConfig framework provides over 1,700 device-specific configuration parameters—settings for scanner beam width, display brightness curves, Bluetooth peripheral pairing behaviour, battery management, and dozens of hardware-specific options that simply do not exist in generic MDM policies.
Configuring a Zebra scanner through MDM is not “enrol and push a policy.” It is a 12-step process involving OEMConfig profiles, DataWedge scanning configurations, and peripheral pairing sequences that require device-specific expertise.
We stage Zebra devices with OEMConfig profiles that configure everything from the scanner beam width to the screen timeout to the Bluetooth pairing sequence for ring scanners. If you enrol that same device through a generic MDM policy, the scanner works—but the beam width is wrong for the barcode density in the warehouse, the screen times out too fast for the worker’s workflow, and the ring scanner drops its pairing every shift change.
The device is “managed.” It is not operational.
OEMConfig and device-specific MDM profiles
OEMConfig is Android’s framework for exposing manufacturer-specific device settings to MDM platforms. For Zebra and Honeywell devices—the two dominant brands in Canadian warehouse, logistics, and field service environments—OEMConfig is what makes the difference between a device that technically works and a device that actually fits the worker’s job.
Standard MDM profiles handle the basics: Wi-Fi credentials, security policies, app installations. OEMConfig handles everything else: how the scanner interprets damaged barcodes, how the screen behaves in direct sunlight, how the device manages battery draw during extended shifts, which Bluetooth peripherals are allowed to pair and how they reconnect after going out of range.
For a CIO or Director of IT evaluating their MDM environment, the question is straightforward: does your MDM administrator know how to configure OEMConfig profiles for your specific device models? If the answer is “I’m not sure” or “we use the default settings,” your devices are being managed—but not optimised for operational performance.
How mobile device management fits within managed mobility services
MDM is the fourth of five stages in a managed mobility lifecycle. It is essential. It is also insufficient on its own.
Treating MDM as your entire mobility strategy is like treating accounting software as your entire finance department—the tool works, but someone still needs to run the operation.
The managed mobility services market exists because MDM alone does not cover the full device lifecycle. Organisations are not investing in managed services because MDM software is inadequate. They are investing because the operational layer around MDM—sourcing, staging, repair, telecom expense management, and secure decommissioning—requires a dedicated capability that most IT teams cannot build internally.
The five pillars of a managed mobility operation are:
- Strategic Sourcing — Procuring devices, negotiating volume pricing, managing OEM relationships
- Staging & Deployment — Configuring devices to operational readiness before they reach workers
- Lifecycle Management — Break/fix repair, accessory tracking, hot spare pools, service desk support
- MDM Administration — The ongoing operational management of your MDM environment
- Secure Decommissioning — Certified data erasure and chain-of-custody documentation at end-of-life
MDM administration is one pillar. When it operates in isolation—without the staging that ensures devices are configured correctly from day one, without the lifecycle management that handles repairs and replacements, without the decommissioning that closes the compliance loop—gaps emerge.
The most common pattern we see: an organisation buys SOTI or 42Gears, assigns MDM administration to a network engineer who also manages firewalls and VPNs, and wonders why their device fleet is inconsistent 18 months later. The MDM software is fine. The operational model around it was never designed for scale.
MDM administration as a managed service
MDM as a Service (MDMaaS) transfers the day-to-day operational administration of your existing MDM platform to certified specialists—while you retain control of the platform, the policies, and the strategic direction.
This is not replacing your MDM software. It is staffing the operation properly.
Under an MDMaaS model, certified administrators handle policy configuration and updates, app deployment and version management, compliance monitoring and remediation, security incident response, enrolment and offboarding, and the ongoing tuning that keeps an MDM environment healthy at scale.
Your IT team sets the requirements. The MDMaaS provider executes the operations. You get consistent fleet performance without absorbing the headcount or building the specialised expertise internally.
For organisations already stretched thin—where the person managing MDM also manages network infrastructure, help desk escalations, and three other systems—MDMaaS removes a persistent operational burden without requiring a platform migration or a capital investment in new software.
The MDMaaS guide explains the model in detail, including what to look for in a provider and how the service integrates with broader lifecycle management.
What Canadian enterprises need to know about MDM compliance
A hospital in Ontario uses Intune to manage clinical tablets. A tablet breaks. It gets shipped to a repair depot. The MDM profile is wiped, but cached patient data remains in the app sandbox.
If that depot is in the United States, the hospital has a cross-border transfer of personal health information—regardless of what the MDM console shows.
Under PHIPA (Personal Health Information Protection Act), the hospital remains accountable for that data. The MDM vendor’s remote wipe capability does not discharge that obligation. The physical device—and what happens to it—matters.
This scenario is not theoretical. We have had procurement teams at Ontario hospitals ask us to prove, with chain-of-custody documentation, that no device containing cached patient data leaves Canada during the repair process. Not the MDM data. The physical device. That requirement eliminates most US-based MDM and managed mobility providers from consideration.
PIPEDA’s accountability principle is explicit: organisations remain responsible for personal information transferred to third parties for processing. Your MDM vendor’s data centre location matters. Your repair depot’s location matters. Your decommissioning partner’s data erasure certification matters.
Canadian privacy law holds the data controller accountable even when third parties handle the devices.
PIPEDA, PHIPA, and the MDM data chain
Every MDM environment processes personal information.
Device enrolment captures employee names, email addresses, and device identifiers. Location services—often enabled for lost device tracking—generate ongoing location data. App usage analytics reveal work patterns. In healthcare and government environments, the data passing through MDM-managed devices includes information subject to sector-specific privacy rules.
Under PIPEDA, this data processing creates accountability obligations that flow through to any third party involved in the MDM operation—the software vendor, the managed service provider, the repair depot, the decommissioning partner.
For Ontario healthcare organisations, PHIPA extends these obligations to any service provider handling devices that may contain personal health information. For Quebec-based operations, Law 25 (An Act respecting the protection of personal information in the private sector) imposes additional requirements on cross-border data transfers.
The compliance question for MDM is not just “Is my data encrypted?” It is “Who handles my devices, where are they located, and can I document the chain-of-custody if an auditor asks?”
Choosing between self-managed MDM and outsourced MDM administration
If your fleet is 200 iPhones in one office and you have a dedicated mobile administrator, self-managed MDM works.
If your fleet is 3,000 Zebra scanners across 40 distribution centres and your MDM administrator also manages your firewall, you have an operational model problem that no software upgrade will fix.
The decision between self-managed and outsourced MDM administration is not about software capability. It is about operational capacity.
Self-managed MDM makes sense when:
- Your fleet is relatively small (under 500 devices)
- Your devices are homogeneous (one or two device types, single OS)
- You have dedicated IT staff whose primary responsibility is mobile device administration
- Your compliance requirements are straightforward
- Your organisation operates from a single location or a small number of sites
Outsourced MDM administration makes sense when:
- Your fleet exceeds 500 devices or spans three or more device types
- Your MDM administrator has other primary responsibilities
- You operate across multiple provinces or distributed locations
- You manage rugged devices requiring OEMConfig expertise
- Your compliance requirements include Canadian data residency or sector-specific privacy rules
- You need bilingual (English/French) support for Quebec operations
The inflection point we see most often is around 500 devices or three device types—whichever comes first. Below that threshold, a competent generalist can keep the MDM environment healthy. Above it, the combinatorial complexity of OS versions, app versions, OEM configurations, and carrier plans exceeds what a part-time administrator can track.
The organisations that get MDM right at scale are not the ones with the best software. They are the ones that treat MDM administration as a dedicated operational function—either by staffing it internally with full-time specialists or by partnering with a managed mobility provider whose certified administrators operate as an extension of their IT team.
If your fleet has crossed that threshold and your MDM environment is showing symptoms of under-administration—inconsistent app versions, policy drift, compliance gaps surfacing during audits—a conversation with a managed mobility specialist can help you map the gap between where you are and where you need to be. Talk to a PiiComm MDM specialist about your fleet.
Frequently asked questions about mobile device management
What is mobile device management (MDM)?
MDM is security software that enables IT departments to monitor, manage, and enforce policies on enterprise mobile devices from a centralised dashboard. It controls the device through remote configuration, app deployment, and compliance monitoring—but it does not manage the broader fleet operation around it, including sourcing, repair, or decommissioning.
What is the difference between MDM and managed mobility services?
MDM is software that controls device settings and security policies. Managed mobility services (MMS) is an operational service that includes MDM administration plus strategic sourcing, staging, lifecycle management, telecom expense management, and secure decommissioning. MDM is one pillar within MMS—not a substitute for it.
Can MDM software manage rugged enterprise devices like Zebra scanners?
Yes, but rugged devices require OEMConfig profiles and device-specific configurations that go far beyond standard MDM policies. Generic enrolment misses scanner beam width settings, peripheral pairing sequences, and hardware-specific parameters. Proper rugged device MDM requires expertise in Zebra’s OEMConfig framework and device-specific staging procedures.
Does MDM address PIPEDA compliance for Canadian organisations?
MDM provides technical controls—encryption enforcement, remote wipe, access policies—but does not discharge PIPEDA’s accountability obligations. Organisations remain responsible for personal information on devices even when third parties handle MDM administration, repair, or decommissioning. Data residency and chain-of-custody documentation matter.
When should an organisation outsource MDM administration?
The inflection point is typically around 500 devices or three device types—whichever comes first. Above that threshold, the complexity of OS versions, app versions, OEM configurations, and distributed locations exceeds what a part-time administrator can manage consistently. Outsourcing also makes sense when compliance requirements demand Canadian data residency or bilingual support.
What is MDM as a Service (MDMaaS)?
MDMaaS transfers day-to-day operational administration of your existing MDM platform—policy configuration, app deployment, compliance monitoring, incident response—to certified specialists. You retain control of the platform and policies while eliminating the operational burden on your internal IT team. The MDM software stays the same; the staffing model changes.
Is mobile device management an invasion of employee privacy?
On corporate-owned devices, MDM manages work-related settings and security policies—the organisation owns the device and sets the rules. On BYOD devices, containerisation separates work and personal data so MDM controls only the work profile. Transparent policies and clear employee communication about what MDM can and cannot see are essential for trust.
The gap between the console and the floor
The MDM licence was never the hard part. The hard part is the thousand operational decisions that happen after the licence is signed—who configures the policies, who monitors compliance, who updates the app whitelist, who notices when 300 devices quietly drop out of enrolment because nobody was watching.
MDM software is a tool. A good tool. But the gap between owning that tool and operating it at scale is where most enterprise fleets lose consistency, lose compliance visibility, and lose the productivity gains that justified the investment in the first place.
For Canadian organisations managing rugged device fleets across distributed operations, the question is not whether MDM is necessary—it is. The question is whether your operational model matches the complexity of your fleet. If your MDM administrator also manages your firewall, your VPN, and your help desk escalations, the answer is probably no.
The console will keep showing green. The floor will keep telling you something different.