MDM Best Practices: 10 Rules for Managing Mobile Devices Without Losing Your Mind

You bought an MDM platform. You enrolled 50 devices in a pilot. And now the real questions start: What policies do you actually enforce?

How aggressive should the passcode requirement be? Do you let employees use personal phones? What happens when someone leaves the company with a corporate iPad?

The technology is the easy part. The hard part is designing policies that are strict enough to satisfy your security team and loose enough that employees do not revolt. Get this wrong and you end up with one of two outcomes: a fleet of unmanaged devices pretending to be managed, or a policy so restrictive that people find workarounds.

This guide covers the 10 MDM best practices that separate functional mobile device programs from the ones that quietly fail. Everything here applies whether you are using Hexnode, Jamf Pro, Microsoft Intune, Kandji, or Miradore. The principles are vendor-agnostic. The implementation details are not.

A quick note: mobile device management, not master data management

The acronym MDM means two completely different things depending on your industry. In IT operations, MDM is Mobile Device Management — the software and policies used to enroll, configure, and secure smartphones, tablets, and laptops. In data engineering, MDM is Master Data Management — the discipline of maintaining a single source of truth for business-critical data like customer records and product catalogs.

This article is entirely about mobile device management. If you searched for "MDM best practices" expecting guidance on master data governance, data stewardship, or the "4 styles of MDM" (registry, consolidation, coexistence, and centralized — those are master data implementation styles), you are in the wrong place. The same goes for the "7 building blocks of MDM" and the "5 C's of data governance" — those belong to the data management world, not IT operations.

Everything below is about managing phones, tablets, and laptops at scale.

Enrollment best practices

Enrollment is the foundation of every MDM program. If devices are not enrolled correctly — or not enrolled at all — every policy you write is meaningless. These three practices ensure your fleet is actually under management.

1. Use zero-touch enrollment for every corporate-owned device

Zero-touch enrollment means a device connects to your MDM platform automatically the first time it powers on, without anyone from IT physically touching it. Apple Business Manager, Android Enterprise zero-touch, and Windows Autopilot all support this.

This is not optional for organizations deploying more than 50 devices. Manual enrollment — handing someone a URL or QR code and hoping they complete the steps — has a dropout rate north of 30% in most organizations. Zero-touch enrollment eliminates that entirely. The device arrives at the employee's desk, they turn it on, and it configures itself.

• Register all corporate Apple devices in Apple Business Manager before distributing them
• Enroll Android devices through your reseller's zero-touch portal or Samsung Knox Mobile Enrollment
• Configure Windows Autopilot profiles in Intune or your MDM before shipping hardware
• Test the zero-touch flow end-to-end before rolling out to the first batch of users
• Ensure your MDM supports DEP token renewal so Apple enrollment does not silently break

Every major MDM vendor supports zero-touch enrollment: Hexnode ($2.20/device/month), Jamf Pro ($3.67/device/month), Intune ($8/user/month), and Kandji all handle it. Miradore supports it in their paid tiers. If your current MDM does not support zero-touch for all three platforms, that alone is reason to switch.

2. Create distinct enrollment profiles for each device ownership model

Not all devices get the same policies. A corporate-owned iPad locked to a single app in a retail store needs a fundamentally different enrollment profile than an employee's personal iPhone with a work container.

Build separate enrollment workflows for each ownership model before you enroll your first device. Trying to retrofit this later means re-enrolling hundreds of devices — and re-enrollment on iOS requires a factory reset.

This matrix should be your starting point. Adjust the specifics for your industry — healthcare will need stricter camera and screenshot controls, retail will lean heavily on kiosk mode, and professional services firms will deal mostly with BYOD.

Security policy design

Security policies are where MDM programs either protect the organization or create a false sense of security. The goal is not to check every box in the MDM console. The goal is to enforce the controls that actually reduce risk without creating so much friction that users find workarounds.

3. Enforce encryption and passcodes at the OS level — not the app level

Device-level encryption is the single most important MDM security control. If a device is lost or stolen, encryption is the difference between a security incident and a data breach.

iOS devices are encrypted by default when a passcode is set. Android devices running Android 10+ are encrypted by default on most hardware. Windows devices need BitLocker enabled via policy. macOS needs FileVault. Your MDM should enforce all of these — not rely on users to enable them.

• Require a minimum 6-character passcode on all managed devices
• Enable biometric authentication (Face ID, fingerprint) as a convenience layer — not a replacement for a passcode
• Set a maximum of 10 failed attempts before wipe on corporate-owned devices
• Enforce BitLocker on Windows and FileVault on macOS through MDM compliance policies
• Block access to corporate resources from devices that report encryption as disabled
• Set auto-lock to 5 minutes maximum on all device types

Do not make passcodes so complex that people write them on sticky notes. A 6-character alphanumeric passcode with biometric unlock is more secure in practice than a 12-character requirement that gets taped to the back of the phone.

4. Use conditional access to block non-compliant devices

Enrolling a device is step one. Continuously verifying that it meets your security requirements is step two. Conditional access policies check device compliance status before granting access to corporate resources like email, SharePoint, or internal apps.

Microsoft Intune does this natively with Azure AD conditional access. Hexnode integrates with identity providers to achieve similar results. Jamf Pro connects through Jamf Connect or Azure AD integration. The specific implementation varies by vendor, but the principle is the same: if a device falls out of compliance — jailbroken, encryption disabled, OS version outdated — it loses access to corporate data automatically.

This is the control that turns your MDM from a configuration tool into a security tool. Without conditional access, a non-compliant device still reaches your data. With it, the device is quarantined until the user fixes the issue.

5. Patch mobile OS versions within 30 days of release

Mobile OS updates patch known vulnerabilities. Every month a device runs an outdated OS is a month that known exploits remain open. Your MDM should enforce a maximum OS version lag.

The practical approach: give users a 14-day grace period after a new OS version is released, then start sending nudge notifications through the MDM. At 30 days, mark the device non-compliant. At 45 days, block access to corporate resources via conditional access. This gives users time to update on their schedule while establishing a hard deadline.

For corporate-owned devices, you can push OS updates silently during off-hours. For BYOD, you can only notify and restrict — you cannot force an OS update on a personal device. Plan for both scenarios in your compliance policy.

App management

App management is where MDM delivers daily operational value beyond security. Pushing the right apps to the right devices, keeping them updated, and preventing unauthorized apps from accessing corporate data — this is the workflow your helpdesk will use every week.

6. Build an app catalog with silent deployment

Create a curated app catalog in your MDM that includes every app your organization requires or approves. Required apps should deploy silently — the user opens the device and the apps are already there. Optional apps should be available in a self-service portal where users can install them without opening a helpdesk ticket.

• Categorize apps as Required (auto-install), Optional (self-service), or Blocked
• Use managed app configurations to pre-configure work apps (Outlook, Teams, Slack) with the correct server settings
• Deploy apps through Apple VPP (Volume Purchase Program) or managed Google Play for license management
• Set apps to auto-update silently so users are never running outdated versions
• Block sideloading on corporate-owned devices — apps should only come through the MDM or managed app store
• For BYOD, restrict managed apps from sharing data with unmanaged personal apps (managed open-in policy)

Silent app deployment eliminates one of the biggest sources of helpdesk tickets in mobile-heavy organizations. When done correctly, a user receives a new device, powers it on, and every app they need is installed and configured within 15 minutes — no instructions, no tickets, no friction.

7. Separate work data from personal data on every device

Data separation is the policy that makes everything else work — especially for BYOD. Without it, you cannot selectively wipe corporate data when an employee leaves, and you cannot prevent work documents from leaking into personal cloud storage.

On Android, the work profile creates a separate encrypted container for work apps and data. On iOS, managed apps and accounts are logically separated from personal ones. On Windows, Windows Information Protection (WIP) or Intune's app protection policies create a similar boundary.

The critical policies: prevent copy-paste from work apps to personal apps. Prevent work files from being saved to personal cloud storage. Prevent work contacts from syncing to the personal address book. These sound aggressive, but they are the minimum necessary to protect corporate data on a device you do not own.

BYOD handling

BYOD is where MDM programs get politically complicated. Employees do not want IT controlling their personal phones. IT cannot afford to leave personal phones unmanaged when they access company email. The solution is a clear BYOD policy that employees understand and consent to before enrollment.

8. Write a BYOD policy before you touch a single personal device

The biggest BYOD mistake is enrolling devices before the policy exists. Employees will ask: Can IT see my personal photos? Can IT wipe my phone? Can IT track my location? If you do not have clear answers documented before enrollment day, you will face resistance, rumors, and refusals.

Your BYOD policy should explicitly state what IT can and cannot see on a personal device. With a work profile or managed container approach, the honest answer is: IT can see work apps and work data inside the container. IT cannot see personal apps, photos, browsing history, or personal messages. IT can wipe the work container — not the entire device.

• Document what IT can and cannot access on enrolled personal devices — be specific
• Require written employee consent before BYOD enrollment
• Clarify that personal data is not touched during selective wipe (and demonstrate this in onboarding)
• Define minimum device requirements (OS version, no jailbreak/root)
• Specify which apps are required in the work container
• State what happens if the device falls out of compliance (work data removed, not personal)
• Address what happens at offboarding: work profile removed, personal data untouched, device stays with employee

Transparency is the entire strategy. The moment employees believe IT can read their text messages — even if it is technically impossible — your BYOD enrollment rate drops to near zero.

Compliance and auditing

Compliance frameworks like HIPAA, SOC 2, PCI-DSS, and ISO 27001 increasingly require proof that mobile devices are managed. Your MDM is the evidence source. But only if you configure it to produce the right reports.

9. Generate compliance reports automatically — not manually

Your MDM should produce compliance reports that answer the questions auditors actually ask: How many devices are enrolled? What percentage meet your encryption and passcode requirements? How many are running outdated OS versions? When was the last compliance check for each device?

Set up automated compliance dashboards and scheduled reports in your MDM. Hexnode, Jamf Pro, Intune, and Kandji all support scheduled reports delivered via email. Do not wait until audit season to pull this data. Run weekly compliance reports so you catch drift early.

For SOC 2 specifically, you need evidence of: device inventory, encryption enforcement, access controls, and incident response (remote wipe capability). Your MDM generates all of this if you configure the reports. If your auditor asks for proof and you have to spend a week pulling data manually, your MDM is misconfigured.

Common MDM mistakes

These are the mistakes that show up in every MDM program that was set up in a rush. They are easy to prevent if you plan for them. They are expensive to fix after the fact.

10. Avoid these five MDM deployment mistakes

Mistake 1: Enrolling all devices under a single profile. Corporate-owned iPads and employee BYOD phones need different policies. One profile for everything means either too much control on personal devices or too little control on corporate ones.

Mistake 2: Not testing policies before broad rollout. A passcode policy that works fine on iOS can behave unexpectedly on certain Android manufacturers. A Wi-Fi profile that works on Android 13 might fail on Android 12. Always pilot with 10-20 devices across your most common hardware before deploying to the full fleet.

Mistake 3: Ignoring offboarding. When an employee leaves, what happens to the corporate data on their device? If you do not have an automated offboarding flow — triggered by HR or your identity provider — that data sits on an unmanaged device indefinitely. Integrate your MDM with your identity provider so disabling an account triggers a selective or full wipe automatically.

Mistake 4: Choosing a vendor based on one OS. You pick Jamf Pro because you are an Apple shop. Two years later, the sales team is on Android and the warehouse uses Windows tablets. Now you need a second MDM. If there is any chance your device mix will diversify, choose a cross-platform vendor (Hexnode, Intune, Mosyle Business) from the start.

Mistake 5: Treating MDM as set-and-forget. Device management needs ongoing attention. New OS versions break existing profiles. New apps need to be added to the catalog. Compliance policies need updating when frameworks change. Assign an owner to the MDM program — not just the initial deployment, but the ongoing operation.

MDM vendor comparison for best-practice implementation

Every best practice in this guide is implementable on any modern MDM platform. But the ease of implementation and the cost vary. Here is how the major vendors stack up on the capabilities that matter most for following these best practices.

If you are early-stage or budget-constrained, Miradore's free tier lets you enroll devices and enforce basic policies — a reasonable starting point. Hexnode hits the best balance of cross-platform support and price for mid-market teams. Jamf Pro and Kandji are the right choice if your fleet is exclusively Apple. Intune is the default if you are already on Microsoft 365 E3 or higher — you are paying for it whether you use it or not.

Compare all MDM vendors side by side — pricing, features, and real user reviews — on the MDM software category page at /categories/mdm-software.

MDM best practices checklist

Use this as a quick-reference checklist when rolling out or auditing your MDM program.

• Zero-touch enrollment configured for all corporate-owned devices (ABM, Android Enterprise, Autopilot)
• Separate enrollment profiles for BYOD, corporate-owned, and shared/kiosk devices
• Passcode and encryption policies enforced at the OS level on all managed devices
• Conditional access configured to block non-compliant devices from corporate resources
• OS update policy with 30-day maximum lag and automated nudge notifications
• App catalog with silent deployment for required apps and self-service portal for optional apps
• Data separation (work profile / managed container) on all BYOD devices
• Written BYOD policy with employee consent and clear privacy disclosures
• Automated compliance reports running weekly, not just at audit time
• Offboarding flow integrated with identity provider for automatic wipe on account disable

Compare MDM platforms with real pricing at /categories/mdm-software. For Apple-only fleets, start with the Jamf Pro review at /software/jamf-pro or Kandji at /software/kandji.

FAQ