How to Build a Mobile Device Management Strategy

Your MDM strategy probably didn't start as a strategy. It started when Microsoft 365 came with Intune attached, so somebody enabled it. Then the design team bought Macs and the reseller threw in Jamf. Then Android showed up in the warehouse and nobody enrolled it, because there wasn't a plan for Android. Now you run three consoles, and the honest answer to "which one covers the laptop that just went missing" is: depends who bought it.

That's the gap between the guides and the job. Almost every article on mobile device management strategy assumes you're choosing a platform from a clean slate. Very few people are. In our recent industry research panel, 73% of IT buyers were already running Intune before they evaluated anything else, and roughly one in three organizations with an identifiable stack was running two or more device tools at once.

So the real question isn't "which MDM." It's what each tool controls, where the seams are, and who owns the devices that fall between them. This guide covers what every MDM strategy needs (assessment, policy, rollout, measurement) and then the part almost nobody writes about: making it work across tools you already bought.

What is an MDM strategy?

An MDM strategy is the plan that defines which devices your organization allows, what security they must carry, how they get enrolled and configured, and who can act on them remotely. It turns device management from a series of one-off decisions into a repeatable process, and it gives you a documented answer when an auditor asks how endpoints are controlled.

The distinction that matters operationally: the strategy is the decision layer, the software is the enforcement layer. You can buy excellent software and still have no strategy. That usually looks like a console nobody has opened in four months and a compliance policy never mapped to an actual setting. If you're still working out what mobile device management actually covers, start there.

Why your organization needs an MDM strategy

Ask an IT manager why they finally wrote one down and you rarely get a strategic answer. You get an incident. A laptop went missing with client data on it, or an auditor asked for an inventory export and the spreadsheet was seven months stale, or a departing employee kept a device and nobody could prove what was on it.

MDM isn't a set-it-and-forget-it purchase. It's an ongoing practice, and the difference shows up the day something breaks. What a working strategy buys you:

Benefits of an MDM strategy

1. Risk mitigation: Enforce encryption, remote wipe, and device authentication as standards, not as things you hope someone configured.
2. Lower IT workload: Automate provisioning and policy enforcement so your team isn't touching every device by hand.
3. Compliance evidence: Produce the audit-ready reporting HIPAA, GDPR, and ISO 27001 expect, without assembling it manually each time.
4. Operational consistency: Apply policies the same way across every device, instead of drifting per department.
5. Cost control: Cut the expenses tied to lost hardware, breach response, and licenses still billing for devices that never came back.
6. Remote and hybrid coverage: Give distributed employees secure access while keeping control over the devices they use. If most of your fleet is off-site, managing devices you never physically touch changes what the strategy has to account for.

How to create an MDM strategy

Building an MDM strategy takes four moves: assess what you actually have, define the policy that governs it, roll it out in a controlled pilot, and measure whether it stuck. Whether you land on BYOD or corporate-owned hardware, the sequence is the same. What changes is who owns the device and how much of it you're allowed to touch.

What should you assess before you start?

Before you evaluate a vendor, get an honest picture of the fleet. Teams skip this step, and it's why they overspend: you can't scope a solution against an unverified inventory.

Expect that inventory to be wrong. In Prey's demo data, 24% of organizations were tracking their fleet in a spreadsheet, and most knew it was stale when they said so. One consulting firm in Chile managed roughly 90 computers entirely through an Excel file. That's not negligence, it's what happens when the fleet grows faster than the process. But your starting number is a guess until an agent confirms it.

1. Inventory current devices: Catalog everything in use, company-owned and personal. This is where you find the OS nobody is managing.
2. Document security requirements: Define the protocols your data and regulations actually demand, so policy decisions have a reference point.
3. Survey employee preferences: Ask what people use and how they work. Strategies that ignore this get worked around.
4. Evaluate IT capacity: Be realistic about what your team can support. A platform nobody has time to administer is shelfware.
5. Review budget: Account for hardware, licensing, support, and training, not just the per-device line item.

Quick win: Export your current device list and compare it against what your identity provider shows as active users this week. The delta is your visibility gap, and it's usually bigger than expected.

Developing your policy framework

With the fleet mapped, write the policy. A good one protects the devices, the data, and the people using them, and it says out loud what IT will and won't do on a personal phone.

Allowed devices. List approved brands, models, and operating systems (Windows, macOS, Linux, Android, iOS, Chromebook), plus the minimum hardware and OS versions required to connect to your network.

Required security. Specify what every device must carry: disk encryption, endpoint protection, strong authentication with MFA where possible, and a patch cadence. Include remote lock and wipe capability as a requirement, not an optional extra.

Support boundaries. State what IT supports on corporate versus personal hardware, expected response times, and where self-service guides live. Ambiguity generates tickets.

Data ownership. Define who owns what data on a personal device, who can access it, and the procedure for retrieving or wiping company data when someone leaves. Offboarding is where most policies turn out to be incomplete.

Privacy commitments. Say plainly what is monitored, what isn't, and why. IT leaders repeatedly flag that staff already feel watched, and a tracking rollout with no privacy statement generates resistance you'll spend months undoing. Containerization keeps personal and work data separate and makes the commitment credible.

Acceptable use. Define appropriate work use, limits on personal use, and prohibited actions such as jailbreaking, credential sharing, or installing unvetted apps.

Ownership model. Pick one or mix, and write down which applies to whom. The four standard models are BYOD (personal devices for work), CYOD (employee picks from an approved list), COBO (corporate-owned, business only), and COPE (corporate-owned with limited personal use). The tradeoffs between BYOD and CYOD shape almost every downstream decision, and managing BYOD through MDM carries constraints the other models don't.

Implementation planning

Rollout is where good strategies die quietly. The plan has to fit your budget, your team's bandwidth, and the patience of the people whose devices you're changing.

Start with a pilot. Pick a representative group (mixed OS, mixed roles, at least one remote worker) and enroll them first. A school district running a 1:1 program learned this the hard way: enrolling a whole grade level in one afternoon meant every failure hit the helpdesk at once, and the rollout stalled for a week. Thirty devices first would have surfaced the same problems quietly.

Then handle training, support, and success criteria before you scale. Tell people what's changing on their device and what isn't, set up the helpdesk path in advance, and define success numerically (enrollment rate, compliance percentage, incident reduction) so the post-rollout review isn't a matter of opinion.

Quick win: Before the pilot, write down the three failure modes you expect. If enrollment breaks the way you predicted, you have a runbook. If it breaks another way, that's the finding worth having.

Choosing MDM software

Once the policy exists, evaluation gets simpler: you're matching capabilities to decisions already made. Prioritize four areas:

• Device tracking: Always-on location, geofencing, connection logs, and location history. This is what turns a missing device from a write-off into a recovery.
• Remote security actions: The ability to lock, wipe, or verify encryption remotely, and to confirm the action completed.
• Inventory management: A live list with model, OS version, and ownership, which doubles as your audit export.
• Management tooling: Streamlined enrollment, fast policy updates, and application control.

Depending on your environment, enterprise mobility management (EMM) or unified endpoint management (UEM) may fit better than classic MDM. Endpoint detection solves a different problem entirely, so understand how MDM and EDR divide the work before buying either expecting it to do both.

Related reading: MDM solutions built for smaller teams

How do I measure it?

Measure an MDM strategy on four indicators: device compliance rate, how many devices have reported in recently, employee enrollment and adoption, and response time on lost or stolen hardware. Reviewed on a fixed cadence, these four show whether the policy is holding or quietly drifting. A strategy you don't measure becomes a document.

• Device compliance: The percentage of devices meeting your security and configuration policy. Anything trending down is drift, and drift compounds.
• Device reachability: How many devices have reported in recently. A device silent for 30+ days is a blind spot your incident response plan doesn't account for.
• Employee adoption: Enrollment and policy compliance rates. Low adoption usually means the policy conflicts with how people actually work.
• Security response metrics: Incident response time, policy violation rate, and recovery rate on lost devices.

Where MDM strategies break: the multi-tool stack

Most MDM strategies don't fail inside a tool. They fail between tools. When an organization runs two or three device platforms, each one is configured correctly on its own terms, and the gaps live in the space nobody owns: an operating system outside every console, a capability each vendor assumed the other covered, a device class that was never assigned.

This is the normal condition, not the edge case. Alongside the 73% Intune figure, roughly a quarter of recent Prey demos opened with buyers describing exactly this: not shopping for a replacement, just looking to fill one specific hole. An IT services firm in Panama put it plainly: "Nuestro MDM actual no permite un rastreo continuo; buscamos un complemento, no un reemplazo."

Three stacking patterns show up repeatedly:

• OS split. Intune for Windows, Jamf for Mac, nothing formal for Android. A head of IT infrastructure at a UK hospitality group with 300 devices described the seam directly: Jamf works for iOS, but it doesn't give them the visibility to track a lost or stolen MacBook.
• Function split. One platform enrolls and configures, another is supposed to handle security response. Both assume the other owns recovery, so nobody does.
• Consolidation fatigue. A migration started, got 60% done, and stopped. Two consoles now hold overlapping partial truth about the same fleet.

The seams stay invisible until an incident forces the question. Consider a 300-device organization: Windows laptops under Intune, 40 Macs under Jamf, 40 Android tablets in the warehouse under nothing. One tablet goes missing on a Friday. There's no console to open, no last-known location, no way to confirm what was on it. The strategy wasn't wrong on paper. It just never assigned that device class to anyone.

Speed is the other seam, and teams discover it mid-incident. An MSP serving legal, investment, and healthcare clients tested Intune's remote wipe and measured it: 34 minutes to initiate. For a device holding regulated client data, the gap between issuing the command and the command starting is the window that matters. Most teams have never timed their own.

The fix is a coverage grid, not another platform. List your operating systems down one axis and four capabilities across the other: enroll, configure, locate, wipe. Fill in which tool owns each cell. The empty cells are your roadmap, usually concentrated in the location tracking most MDMs handle poorly.

Quick win: Build the grid this week, then time one real remote wipe end to end on a test device. Two numbers come out of it: how many cells are empty, and how long your fastest remote action actually takes. Both are answers you'll need before an incident, not during one.

How to keep an MDM strategy from drifting

Implementation isn't the finish line. Fleets change, people leave, threats shift, and a policy written eighteen months ago quietly stops describing reality. Drift is the default state, and the only reliable counter is a review cadence somebody owns.

Run a policy and security review on a set schedule, quarterly for most teams. Check whether the policies still solve what you wrote them to solve, whether the security requirements match current threats, and whether your compliance obligations have changed. Pull employee feedback too: the friction people report is usually where the policy is being worked around, which makes it a security finding, not a satisfaction metric.

Between reviews, the work is steady rather than dramatic. Devices move through their lifecycle from purchase to retirement. People join and leave, and each departure needs the device side closed, not just the account disabled. One MSP described the failure mode exactly: even after disabling a user's account, employees could still delete locally stored data because of cached credentials. Patches need deploying, and license costs need watching.

Then close the loop. Review your KPIs against what you set at rollout. Analyze incidents for the gap that let them happen rather than the individual who tripped it. Feed both back into the policy, and budget time to train the team on what changed: a policy nobody was briefed on gets enforced inconsistently, which looks identical to a policy that doesn't work.

Quick win: Put a recurring 90-minute block on the quarter for the review, with the compliance report and last quarter's incidents attached. The calendar entry is what makes it happen; good intentions between fire drills don't.

Closing the gaps between your tools

Once the coverage grid exists, the empty cells tend to cluster in the same places: locating a device off the corporate network, acting on it quickly, and proving afterward what happened. Those capabilities fall between platforms because enrollment-focused tools treat them as secondary.

Filling a gap is a different purchase from replacing a platform. It requires a layer that runs across every operating system you have, reports location always-on rather than on a polling schedule, executes lock and wipe on demand, and leaves an audit trail you can hand to a compliance officer.

Prey fits this pattern for teams who already run an MDM and need tracking and recovery covered across mixed fleets. Take the warehouse tablet: the ops lead who reported it missing on Friday doesn't need to know which console owns Android. The device shows up alongside every Windows and Mac endpoint, with a last-known location, a history of where it's been, and remote lock and wipe available without waiting on the platform that never enrolled it. For loaner and shared-device programs, the same layer handles the other common failure: hardware that leaves and doesn't come back.

Where this leaves you

An MDM strategy is less about choosing the right platform than about answering, for any device you own, who controls it and what you can do to it remotely. Most teams answer that for their primary OS and go quiet on the rest. That silence is the strategy gap, and it's rarely a budget problem. It's an assignment problem.

You don't need a migration to start. Build the coverage grid, find the empty cells, time one remote action end to end. That's a two-hour exercise, and it tells you more than any vendor comparison.

Frequently asked questions

How long does it take to build and roll out an MDM strategy?

Assessment and policy design usually take a few weeks. The pilot adds two to four weeks depending on fleet size and OS mix, and a full rollout across a mid-sized fleet typically runs one to three months, with measurement ongoing after that. The slow part is rarely the tooling. It is reconciling the inventory and getting sign-off on the policy.

What's the difference between an MDM strategy and an MDM policy?

The strategy is the plan: which devices you allow, what tools enforce it, how you roll it out, and how you measure it. The policy is one output of that plan, the written rules governing device use and security requirements. A policy with no strategy behind it shows up as rules nobody enforces, because no tool was ever configured to.

Do I need to replace my current MDM to fix gaps in my strategy?

Usually not. Most gaps sit between platforms rather than inside one: an unmanaged OS, slow remote actions, or missing location data. Mapping coverage as a grid of operating systems against capabilities (enroll, configure, locate, wipe) shows whether you need a replacement or a complementary layer over what you already run. Replacement is the expensive answer to a question most teams haven't scoped yet.

What are some examples of mobile device management in practice?

Common examples: enrolling a laptop with encryption and endpoint protection applied automatically, pushing an OS update to a whole department, locking a stolen phone and wiping its corporate data, tracking loaner devices in a school or hotel program, and exporting an encryption-status report for an audit.

How do I know if my MDM strategy is working?

Track four numbers: device compliance rate, how many devices have reported in recently, employee enrollment and adoption, and incident response time on lost or stolen hardware. If compliance is drifting down or a meaningful share of devices have been silent for 30+ days, the strategy is degrading regardless of what the policy document says.

See what your current MDM can't see

If your coverage grid has empty cells, the fastest way to understand what's missing is to look at your own fleet through a tool built for the tracking and recovery layer. Get started with Prey and see which devices your current setup can't locate.