What is MDM?

A successful MFA prompt tells you who just signed in, but nothing about the phone they signed in from. When personal and company phones reach email, Microsoft 365, and line-of-business apps on valid credentials alone, IT ends up extending trust to hardware it never assessed.

The Verizon 2026 Data Breach Investigations Report logged 525 lost and stolen asset incidents but confirmed data disclosure in only 88, attributing the gap partly to organizations “being unable to confirm if the data on the asset was accessed.” Mobile device management is how you stop guessing at figures like that. Here’s everything you need to know about MDM for IT.

So what is MDM? Mobile device management (MDM) is the centralized administration of the smartphones, tablets, and other devices people use for work. IT uses it to enroll devices, enforce security settings, deploy apps, check compliance, and remove corporate data when a device is lost, replaced, or retired.

MDM covers both company-owned devices and BYOD (bring your own device), where employees use their own phones for work. The two need different levels of control, which is why ownership shapes almost every MDM decision covered below.

Why credentials alone can’t secure mobile access

Most organizations already put corporate access behind a username, password, and MFA prompt. That stack does a good job of asking if it’s the right person, but on a mobile device, it leaves several other questions unanswered that attackers can exploit.

The result is these three main blind spots:

1. A verified user isn’t a verified device

Picture an employee opening Outlook on their personal phone. They enter their credentials, approve the Microsoft Authenticator prompt, and they’re in. IT now knows who signed in (technically), but not any of this information:

• Whether the phone runs a supported OS version
• Whether its storage is encrypted
• Whether a screen lock is set
• Whether the device has been jailbroken or rooted

That gap matters because phones are increasingly where attackers go after users. In phishing simulations covered by the Verizon 2026 Data Breach Investigations Report, the median click rate for mobile-centric vectors (such as voice and text messaging) was 40% higher than for email. When the device itself is never assessed, the sign-in prompt carries the entire security load.

A device that was in good shape when it first connected doesn’t necessarily stay that way either. The OS could fall out of vendor support, the user could disable their passcode, or a serious zero-day vulnerability could be disclosed for that model. Without anything rechecking device state, access granted on day one quietly stays in place long after the device stopped deserving it.

» Don’t miss our ultimate RMM security guide

2. Personal phones blur the line between corporate and private

BYOD adds an ownership problem on top of the security one. A company-issued phone can justify full configuration control. An employee’s own phone can’t because it holds family photos, private messages, and apps that are none of IT’s business. Without a way to treat the two differently, you end up in one of two potential bad positions:

• Applying corporate-level control to personal devices, which invites privacy disputes and gives employees a reason to avoid enrolling at all
• Applying no control, which leaves corporate email and files on devices IT can’t assess, restrict, or clean up

Written policy doesn’t resolve this on its own. A rule like “one approved device per user” or “devices must meet our security requirements” only holds if someone checks eligibility when the device joins, then checks again as its OS support, patch level, and known vulnerabilities change.

» Here’s how to prevent configuration drift

3. Lifecycle rules depend on someone remembering to act

Devices get lost, stolen, replaced, and reassigned all the time. When removing an old device depends on a support request being picked up and completed, the device record can outlive the device’s legitimate use by weeks or months.

There’s no evidence the stolen phone was used to reach corporate resources, but nothing in that setup confirmed it couldn’t be. The replacement enrollment didn’t fail, because the one-device rule existed only as an expectation that an administrator would close the old record first.

Removing a device from an IT management console is also a separate step from revoking its directory registration, authentication methods, and active sessions. One missed ticket can leave several of those open at once.

» Don’t miss our guides to Shadow IT and how much it’s costing your business

How MDM works behind the scenes

MDM runs on two components that talk to each other: a management server that IT controls, and a client on each device that receives and carries out what the server sends. The cycle works like this:

• Enrollment: The device registers with the MDM server, either automatically on first boot for company-owned hardware, through an admin-led setup, or when the employee signs in themselves. Enrollment establishes trust and tells the server whether the device is company-owned or personal.
• Policy and configuration: IT defines settings on the server, such as passcode rules, encryption requirements, Wi-Fi and VPN profiles, and approved apps. The server delivers them to the device as profiles or policies.
• Commands and check-ins: The server can send commands such as lock, selective wipe, or full wipe. Devices check in on a schedule or when prompted. Apple devices, for example, are prompted through Apple’s push notification service.
• Reporting and compliance: The device reports its state back, including OS version, encryption, passcode, and jailbreak or root status. The server compares that against policy and flags anything that falls out of compliance.

The server can be hosted in the cloud or on your own infrastructure. Cloud-based MDM is usually quicker to set up and easier to scale across many devices or clients. On-premises MDM gives you more control over where data lives, but you take on hosting, patching, and securing the server yourself, and that server carries the same wipe-everything risk described later in this guide.

» Learn more about asset lifecycle management

Ownership decides the enrollment model

Enrollment is the point where a device becomes managed, and both major mobile platforms offer separate enrollment paths for company-owned and personal devices.

For company-owned Apple devices, Automated Device Enrollment registers hardware to the organization through Apple Business, so a phone enrolls and applies its configuration the first time it’s switched on.

For personal Apple devices, account-driven User Enrollment works differently. The employee signs in with a Managed Apple Account that the organization owns, and corporate apps and data are stored in a separate, cryptographically protected volume. The organization can’t see or manage personal data tied to the user’s own Apple Account, and the user can unenroll at any time.

Android Enterprise follows the same ownership logic. Fully managed mode suits company-owned devices used only for work, and gives IT device-level policies that work profiles don’t have. A work profile on a personal phone creates a bounded corporate workspace, leaving the personal side untouched. Company-owned phones that allow personal use get a work profile with some additional device controls.

Where compliance meets access

Enrollment alone doesn’t secure anything. The value comes when compliance status feeds the access decision.

In a Microsoft environment, for example, an Intune compliance policy can define the device requirements, and Microsoft Entra Conditional Access can require a device to be marked compliant before it reaches selected resources. When a phone drops below the minimum OS version or loses its passcode, it fails compliance and loses access until the issue is fixed. That’s what moves device trust from a one-time enrollment check to an ongoing condition.

On personal phones that aren’t fully enrolled, app protection policies offer a lighter option. They protect corporate data inside managed apps, such as blocking copy and paste into personal apps, without managing the device as a whole.

» Here’s how to pilot Conditional Access for privileged users

Where MDM falls short

MDM is a strong control, but it doesn’t solve everything on its own. Here’s where it falls short:

• It doesn’t replace your identity platform: User accounts, authentication methods, and offboarding still belong in the directory, such as Microsoft Entra ID. Removing a device from the MDM console doesn’t necessarily revoke its directory registration, its authentication methods, or the sessions it already holds.
• Its reach on personal devices is deliberately limited: User Enrollment and Android work profiles protect privacy by restricting what IT can see and do. On a personal phone, you can remove corporate data, but you can’t wipe the whole device or inspect it the way you can a company-owned one.
• The console itself becomes a target: A platform trusted to configure, lock, and wipe every enrolled device is a single point of failure if an attacker gets admin access. That’s what happened to medical technology company Stryker on March 11, 2026. The company disclosed a cyberattack affecting its Microsoft environment and said there was no indication of ransomware or malware. The attackers used the built-in wipe command in Microsoft Intune to wipe the company’s devices. A week later, CISA issued an alert urging organizations to harden their endpoint management systems, using Microsoft’s best practices for securing Intune and applying the same principles to other endpoint management platforms.

Essentially, an MDM can enforce encryption, compliance, and access rules perfectly and still put the fleet at risk if its admin functions aren’t locked down.

How to set up and run MDM without overreach

Getting MDM right comes down to proportion. Control should match who owns the device, destructive power should never sit with a single account, and every device should have exactly one platform responsible for it.

These four areas cover where most deployments either overreach or leave gaps:

Step 1: Build your BYOD policy around access, not ownership

A BYOD MDM policy works best when it governs what a personal phone can reach, not what the employee does with it.

That flexibility reduced an obvious source of friction between security requirements and personal preference. For a workable baseline for the access requirements, start here:

• One approved device per user for corporate access: This limits registered corporate-access devices, not how many phones an employee owns.
• Enrollment and approval before access: Valid credentials alone don’t make a device authorized.
• A required MFA method: Registering an authenticator app is a separate requirement from enrolling the device, and one doesn’t satisfy the other.
• Security eligibility: Supported OS versions, available security updates, and known vulnerabilities determine whether a device qualifies, not manufacturer preference.

Next, match the enrollment model to ownership. For personal devices, that means Apple User Enrollment, an Android work profile, or app protection policies alone, rather than full device management.

Then write down the privacy boundary in plain terms. IT shouldn’t need access to any of this employee data:

• Photos
• Personal messages and email
• Contacts
• Browsing history
• Privately installed apps

The boundary has to describe the enrollment model you actually deploy. Full device management, work profiles, and app-level protection give IT different capabilities, so a privacy promise written for one won’t hold for another.

Step 2: Make device changes a verified process

The stolen phone scenario above is what happens when lifecycle rules live in a ticket queue. Closing that gap means turning device changes into checked steps rather than requests someone has to remember to complete.

When a device is lost or stolen, work through these steps in order:

• Confirm the device’s identity, assigned user, and ownership classification in the MDM console before taking any action
• Remove corporate data from the device. For a personal phone, use a selective wipe that removes only corporate data (Intune calls this Retire). For company-owned hardware, a full wipe may be appropriate, with a second administrator’s approval
• Disable or delete the device’s registration in your identity platform, such as Microsoft Entra ID, since removing it from MDM doesn’t do this automatically
• Remove the lost device from the user’s registered authentication methods
• Revoke the user’s active sessions so tokens issued to the lost device stop working
• Confirm the old enrollment is gone before approving any replacement device

The last step should be a standing rule for every replacement, not just theft. A new phone shouldn’t be approved while the previous enrollment still exists, unless there’s a documented exception.

Approval also shouldn’t be permanent, so review device eligibility periodically, and pull access from phones whose OS has fallen out of vendor support or that carry a significant unresolved vulnerability. Base that decision on the vendor’s security updates and advisories and the device’s actual exposure, not a CVE severity score on its own.

Step 3: Lock down the MDM console

The Stryker incident showed that the console capable of wiping every device is a target in its own right. Treat it like any other privileged infrastructure, with controls layered so that no single compromised account can trigger a fleet-wide incident:

• Role-based access control: Separate day-to-day enrollment, compliance, and app management from destructive operations, and scope each admin role to the device groups that person is responsible for.
• Phishing-resistant authentication: Require FIDO2 security keys or passkeys for MDM admin accounts, since standard MFA is a baseline rather than enough for accounts that can change thousands of endpoints.
• Just-in-time privilege: Use Privileged Identity Management where available so admin roles are activated only when needed, with a justification and a time limit.
• Multi-admin approval: Require a second, independently authenticated administrator for high-impact actions, and make sure requesters can’t approve their own requests.
• Audit and alerting: Log role changes, device actions, policy changes, and approvals, and alert on high-impact activity independently of the admin performing it.
• Emergency recovery: Keep a documented way to restore admin access that doesn’t depend on the compromised platform.

CISA’s guidance after the Stryker attack specifically recommended second-admin approval for sensitive actions such as device wiping, app and script deployment, and RBAC changes. In practice, these actions belong behind it:

• Remote wipe and factory reset, especially across multiple devices
• Bulk device retirement or removal from management
• Changes to admin roles, permissions, or scope
• Changes that weaken critical security or compliance policies
• Bulk app or script deployments
• Any change to the approval controls themselves

Step 4: Split the work cleanly between MDM and RMM

Most IT teams already run an RMM tool for workstations and servers, so adding MDM raises an obvious question of which platform owns which device. Running both works when every device type has one clear owner and neither tool duplicates the other’s job.

Identity stays outside both platforms. User accounts, authentication methods, and offboarding belong in your identity platform, so neither console becomes a competing source of truth about who should have access. Keep these consistent across both:

• Asset identity: Every device has one traceable record showing its assigned user, device type, managing platform, and status.
• Ownership classification: Company-owned and personal devices are labeled the same way in both systems, because the permitted actions differ.
• Security baseline: Supported OS versions, patch expectations, and encryption requirements follow one organizational standard, even when the enforcement mechanism differs.
• Device status: A device marked lost, retired, or replaced in one system isn’t still authorized in the other.
• Admin permissions: Both consoles follow least privilege, with second-admin approval for bulk or destructive actions.
• Incident handling: IT issues from either platform follow the same service desk process, so nothing gets fixed in one console and forgotten in the other.

Reconcile both platforms against a common inventory on a regular schedule. The checks that matter most are unmanaged devices, duplicate registrations, devices assigned to inactive users, and unsupported OS versions.

Atera’s RMM handles infrastructure monitoring and remote management across Windows, Mac, and Linux, plus patch management for Windows and macOS. RMM alerts can create tickets automatically, depending on your alert settings. For phones and tablets, Atera partners with GoTo to offer Miradore as a dedicated MDM that runs alongside the RMM rather than inside it, so mobile compliance issues can feed into the same service desk workflow as everything else.

What to look for in MDM software

Feature lists look similar from one vendor to the next. These criteria separate the platforms that fit how you actually manage devices from the ones that only look good in a demo:

• Enrollment options by ownership: Automated enrollment for company-owned Apple and Android devices, plus User Enrollment and work profiles for BYOD. If a platform only offers full device management, personal phones turn into privacy disputes.
• Platform coverage: Support for iOS, iPadOS, and Android, plus any Mac or Windows devices you want it to handle. Check whether features differ by operating system, because they often do.
• Compliance tied to access: The ability to pass device compliance status to your identity platform, so a failing device loses access instead of just appearing in a report.
• App and data protection: Managed app deployment and app-level policies for phones you can’t fully manage, such as blocking copy and paste into personal apps.
• Admin safeguards: Granular role-based access, phishing-resistant sign-in for admins, second-admin approval for wipes and bulk actions, and audit logs. After the Stryker incident, these are core requirements, not extras.
• Lifecycle controls: Selective wipe as well as full wipe, lost-device actions, and retirement workflows, with a clear way to confirm the old enrollment is gone before a replacement is approved.
• Cloud or on-premises hosting: Cloud-based MDM is easier to set up and scale. On-premises gives you more control over data location but adds hosting and security work. Choose based on client or compliance requirements, not preference alone.
• Inventory and reporting: One record per device showing owner, assigned user, OS version, and compliance status, in a format you can reconcile against your RMM.

Score each option against the device mix you actually have. An MSP supporting clients with mostly BYOD fleets needs different strengths from an internal team managing company-issued phones, and the right platform is the one that matches that mix.

Device trust is an ongoing job

MDM earns its place by repeatedly answering a question enrollment only answers once: should this device still have access? Answering it well needs compliance that feeds access decisions, controls that stop at the work profile on a personal phone, a replacement process that actually removes the old device, and a console locked down tightly enough that one compromised admin account can’t wipe the fleet.

None of that holds up if phones sit in a silo apart from the rest of your endpoints. Atera’s RMM covers monitoring and remote management across Windows, Mac, and Linux, plus patch management for Windows and macOS while Miradore takes on enrollment, policy, and lifecycle management for phones and tablets.

» Learn more about connecting via Atera’s Work from Home or try it for free today