IT Operations
MDM Best Practices: A Checklist
A practical MDM checklist — enrolment, policy baselines, encryption, patching, app control, offboarding and privacy — based on what actually goes wrong in production.
Most MDM deployments do not fail technically. They fail because enrolment was optional, the policy was never enforced, and nobody removed access when people left. This checklist covers the things that actually cause problems.
1. Enrolment
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 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
2. Policy
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
3. Patching
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.
4. Applications
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
5. Offboarding
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
6. Privacy
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.
Infronest
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 14-day free trial at infronest.com — no credit card required.
Frequently Asked Questions
- What are the most important MDM best practices?
- Mandatory enrolment before data access, one written security baseline enforced everywhere, encryption verified rather than assumed, ring-based patching with severity SLAs, application and removable-media control, offboarding tied to the HR leaver process, and published transparency about what IT can see.
- Should companies allow BYOD?
- BYOD is workable if you use work-profile separation, restrict what IT can see on the personal side, and accept reduced control. Company-owned devices give far stronger enforcement. Whichever you choose, write the policy down and tell employees exactly what is monitored.
- How often should MDM policies be reviewed?
- Review the baseline at least twice a year, and after any major OS release, since new OS versions frequently change what a management agent can enforce. Exceptions should carry expiry dates so the review has teeth.
- How do you wipe a device when an employee leaves?
- Revoke accounts and sessions first, then send the wipe: full wipe for company-owned devices, work-profile wipe only for BYOD. Track the command until the device acknowledges it — a wipe sent to an offline device has not executed — and keep it pending so it fires the moment the device reconnects.
- Can MDM wipe personal photos on a BYOD phone?
- It should not, and a correctly configured deployment cannot: on BYOD, work data sits in a managed work profile, and the wipe removes only that profile. Wiping the personal side of an employee-owned device creates legal exposure, which is why the profile boundary should be technical, not just policy.
- What should an MDM baseline policy include?
- At minimum: screen lock with timeout, verified full-disk encryption, host firewall on, local admin rights removed, automatic OS updates with a controlled deferral window, and legacy protocols disabled. Write it down and enforce it through the MDM — an unwritten baseline cannot be audited.
- How quickly should critical patches be applied?
- Critical or actively exploited vulnerabilities within 24–72 hours, high severity within 7–14 days, medium within 30 days. Use CISA's Known Exploited Vulnerabilities catalog as the trigger for the fastest lane, and verify patches actually applied — including completed reboots — rather than trusting the deployment job.