MDM Best Practices: A Checklist

Get enrolment right or nothing else matters

The single strongest enrolment practice is a hard gate: no enrolment, no access to company data. Every policy further down this list assumes the device is actually managed, and voluntary enrolment programmes reliably stall at partial coverage — the unmanaged remainder is precisely the set of devices you most need visibility into. Tie the gate to something users need daily (email, VPN, SSO) so enrolment is the path of least resistance rather than a request IT has to chase.

Second, remove humans from the happy path. Zero-touch programmes — Apple Business Manager (now Apple Business) for Mac, Android zero-touch for company Android, Windows Autopilot for Windows — bind a device to your tenant at first boot, so a laptop shipped straight to a remote joiner arrives already enrolled and configured. Manual enrolment should be the exception you use for legacy stock, not the default process.

Third, choose the Android enrolment mode deliberately. Device Owner mode — required for silent app installation, kiosk mode and strong restrictions — can only be set during initial device setup; applying it later means a factory reset. Decide per device class before rollout: company-owned devices get Device Owner, personally-owned devices get a work profile. What is MDM explains what each mode can and cannot enforce.

• Make enrolment mandatory before a device can access company data — optional enrolment always ends at partial coverage
• Use zero-touch enrolment (Apple Business Manager, Android zero-touch, Windows Autopilot) so devices arrive managed
• For Android, use Device Owner mode for company-owned devices; personally-enrolled devices cannot enforce the same controls
• Reconcile devices bought vs devices enrolled monthly, and chase the gap — that gap is your unmanaged attack surface

Define one security baseline and apply it everywhere

A baseline is one written set of minimum controls that every managed device must satisfy, regardless of who uses it. The discipline matters more than the exact contents: one baseline, written down, enforced by the MDM rather than by memos, with exceptions documented and time-boxed. An unwritten baseline cannot be audited, and a baseline with silent exceptions is not a baseline — it is a suggestion. If you pursue ISO 27001 or SOC 2, this document plus the MDM's compliance reporting becomes your core evidence.

Start small and enforce completely rather than drafting fifty controls you monitor loosely. The set below is achievable on Windows, macOS, Linux and Android from day one, and each item should be verified by the MDM's compliance engine — encryption 'enabled at imaging time' is not the same as encryption verified on every heartbeat.

• Screen lock with a timeout, and a password or biometric requirement
• Full-disk encryption enforced and its status monitored, not assumed
• Host firewall on, with a documented exception process
• Local administrator rights removed by default
• Automatic OS updates enabled with a controlled deferral window
• Legacy protocols and unused services disabled
• Document the baseline in writing — an unwritten baseline cannot be audited or defended

Patch on a schedule with rings

Deploy updates in rings so a bad patch burns a handful of machines, not the fleet. A practical structure is four rings: IT's own devices first (hours after release), a pilot group of tolerant users across departments and hardware models (days), the general fleet (the following week), and servers last, inside a maintenance window with a tested rollback. Each ring only promotes when the previous one shows no regressions — automatic promotion with a health check beats a human remembering to click.

Set SLAs by severity rather than patching everything at one speed: critical or actively exploited vulnerabilities within 24–72 hours, high within 7–14 days, medium within 30 days. CISA's Known Exploited Vulnerabilities catalog is the practical trigger list for the 'actively exploited' lane, and NIST SP 800-40 is the reference framework if you need to defend the whole programme to an auditor.

Finally, verify outcomes, not intentions. A patch job that ran is not a patch that applied: check installation results, chase pending reboots to completion, and treat 'reboot pending for 14 days' as a compliance failure. Third-party applications — browsers, PDF readers, collaboration tools — need the same treatment as the OS, and are the half of patching most MDM deployments quietly skip. What is patch management covers the full discipline.

Control what runs and what leaves

Application control is a lifecycle, not a list. Applications should enter the fleet through the MDM's catalogue or silent push — so IT knows version and origin — get updated through the same patching rings as everything else, and leave cleanly when deprecated, uninstalled by policy rather than lingering unpatched on machines that still have them. The moment users hunt for installers on the open web, you inherit whatever they find.

Enforcement direction depends on risk: an allow-list (only approved software runs) suits kiosks, frontline devices and high-risk roles; a block-list (known-bad categories barred) is the workable minimum for general knowledge-worker fleets. Pair app control with exfiltration control on the same policy: USB storage restricted where the role does not need it, and data-loss rules on devices handling regulated data.

• Maintain an allow-list or at minimum a block-list for high-risk applications
• Distribute business apps through the MDM rather than letting users hunt for installers
• Update apps through the same rings as OS patches, and uninstall deprecated apps by policy
• Restrict removable storage where the role does not require it — USB is still a common exfiltration path
• Apply data-loss rules on devices handling regulated data
• Separate work and personal profiles on BYOD devices

The step almost everyone gets wrong

Offboarding fails because it depends on somebody remembering. Fix that structurally: make device offboarding a mandatory step in the HR leaver workflow, so the ticket that ends payroll also triggers the device action, on the same day. The order of operations matters — revoke accounts and sessions first so the person no longer has access, then wipe or unenrol the device so the data no longer exists on it. Reversing the order leaves a live session on a device you have just stopped managing.

Choose the wipe scope by ownership: company devices get a full wipe or a lock-and-reimage; BYOD devices get a work-profile wipe only, because destroying someone's personal photos creates legal exposure that outlives the employment relationship. And confirm completion — a wipe command sent to a powered-off laptop has not wiped anything. Track the command until the device acknowledges it, and keep lost-device commands pending so they execute the moment the machine comes online. Close the loop in the asset register: the device returns to stock, and the record stays truthful.

• Tie device offboarding to the HR leaver process, not to someone remembering
• Revoke access first, then wipe or unenrol the device — in that order
• For BYOD, wipe only the work profile; wiping personal data creates legal exposure
• Confirm the device actually reported the wipe or unenrolment; a device that is offline has not been offboarded
• Return the asset record to stock so the asset register stays truthful

Be explicit about what IT can and cannot see

Publish exactly what the MDM collects — device model, OS version, encryption status, installed applications, compliance state — and what it does not, such as personal messages, photos or browsing on a personal profile. Write it in plain language, include it in onboarding, and keep it current when policies change: the document is as much for IT's protection as the employee's.

On BYOD, make the boundary technical, not just written: work data lives in a managed work profile or container, IT's visibility and wipe authority stop at that boundary, and the personal side stays personal. This is not only good practice — under India's DPDP framework (MeitY), GDPR and similar regimes, employee monitoring requires transparency and proportionality. Teams that publish their collection scope get measurably less enrolment resistance, which loops back to practice one: coverage.

Conclusion

A checklist only helps if the platform can enforce it. Infronest's device management applies these baselines across Windows, macOS, Linux and Android, verifies compliance per device on every heartbeat, and keeps a full audit trail — in the same workspace as your asset register and helpdesk, so an out-of-policy device raises a ticket against its real owner automatically. If you are still choosing a platform, our best MDM software guide applies these same practices as buying criteria.

Start a 7-day free trial at infronest.com — no credit card required.

Explore MDM software →

Sources

The standards, official guidance and vendor documentation below back the product, method and pricing-model claims in this article. We link them so you can check the claims rather than take them on trust.

• NIST SP 800-124 Rev. 2 — Guidelines for Managing the Security of Mobile Devices in the Enterprise: mobile security for organisation-supplied and personally owned devices, from deployment to disposal.
• NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology
• CISA — Known Exploited Vulnerabilities Catalog: vulnerabilities exploited in the wild, intended as an input to remediation prioritisation.
• Android Management API — Enroll and provision a device: fully managed versus work-profile devices, and provisioning that starts on a new or factory-reset device.
• Microsoft Learn — Overview of Windows Autopilot: pre-configuring new Windows devices with Entra join and automatic MDM enrolment.
• Microsoft Learn — Create a deployment plan: ring-based update deployment (Preview, Limited, Broad), with criteria to meet before advancing to the next ring.

💡 Written by the Infronest Product & IT Operations Team from live deployment experience across Windows, macOS, Linux and Android fleets.