What MDM remote control can and cannot do across Android, Windows, iOS, and macOS

MDM remote control means what an IT admin can do on a managed device from the admin console, without physically holding the device. That capability sounds uniform, but in practice it is deeply asymmetric across operating systems. Windows and macOS support full remote view and control through Mobile Device Management (MDM). Android sits between full and limited control depending on the device maker. iOS and iPadOS support remote viewing but not remote control, because Apple’s APIs do not allow touch injection into a live device. Any honest guide to MDM remote control has to lead with that reality rather than obscure it.

Two clarifications first. This post is about the remote control feature in MDM. It is not about MDM tools for supporting a distributed workforce, which is a related but distinct topic covered by a different post. MDM here also means Mobile Device Management, not Master Data Management, which is an unrelated data-governance category that shares the acronym. One more note on counting: this post treats iOS and iPadOS as one platform. iPadOS follows iOS unless stated otherwise. 

Three capabilities are commonly bundled under “remote control,” and separating them makes the platform picture cleaner. Remote view is the ability to see the device screen live. Remote control is the ability to interact with the screen via the admin console by injecting taps and inputs. Remote administration is the ability to send management commands such as lock, wipe, restart, or install a policy. All four operating systems support remote administration. Remote view is available almost everywhere. Remote control is where the platforms diverge.

What is MDM remote control?

MDM remote control is the set of IT-initiated remote support capabilities that a managed device exposes to the MDM console. In practice, that boundary is defined by the OS vendor. Apple, Google, Microsoft, and Samsung each publish APIs that MDMs can use, and each draws the line between view, control, and administration in its own way.

For an IT team, the practical question is what a helpdesk agent can actually do when a user calls with a problem. Can the agent see the screen? Can the agent tap the screen for the user? Can the agent run commands with elevated privileges? Can the agent do any of this without the user’s active cooperation? The answers vary by OS, by device model within the OS, and by whether the device is enrolled as supervised or corporate-owned.

Remote view vs remote control vs remote administration

Before the platform breakdowns, the three-way distinction that shapes everything below.

The rest of this post walks the platforms one at a time.

Android: OEM decides how much control you get

Android is the most fragmented picture. What the MDM can do on an Android device depends as much on the device maker as on the OS version.

Vanilla Android Enterprise

Google’s Android Enterprise framework provides screen capture through the MediaProjection API, which the user must approve at the start of each session. Once approved, the MDM can stream the device screen to the admin console. This gives remote view. It does not give remote control, because Android Enterprise itself has no cross-vendor API for injecting touches or keystrokes into a running device. On a Pixel, a stock Motorola, or any device without an OEM management SDK layered on top, view is the ceiling.

Samsung Knox and the SDK deprecation

Samsung has historically been the exception. The Knox SDK exposed remote viewing and remote injection APIs, enabling MDMs to implement full remote control of Samsung devices without third-party agents. Samsung is now deprecating parts of that SDK. Knox SDK remote viewing was deprecated at API level 35 with Knox SDK v3.8, and Samsung has stated it will not fix certain Android 15 issues in the legacy Knox SDK.

The practical current path for Samsung remote control runs through the Knox Service Plugin and OEMConfig, with the MDM pushing an OEMConfig profile that grants a supported remote-support tool (Splashtop, TeamViewer, or another Samsung-supported vendor) the permissions it needs to run unattended. That workflow works well when it is set up carefully. It is more moving parts than the older Knox SDK approach.

Rugged and OEM-specific paths

For rugged Android fleets, the OEM matters even more. Zebra provides remote control of its devices through OEMConfig, with the Zebra OEMConfig Powered by MX app and a partner add-on. Honeywell, Datalogic, Crosscall, M3 Mobile, Sunmi, and other rugged OEMs publish their own equivalents. A cross-platform MDM often orchestrates these through the vendor’s OEMConfig channel rather than reimplementing them, so the depth of remote control on a rugged device typically depends on which add-on the MDM supports for that OEM.

Unattended access on Android dedicated devices

One case does allow unattended access on Android without the user tapping to accept. On Android Enterprise dedicated devices, some MDMs, including Microsoft Intune Remote Help, support unattended remote sessions. This is designed for kiosks, scanners, POS terminals, and similar single-purpose devices where no user is present at the screen to grant consent. Unattended access does not extend to Work Profile BYOD devices or to fully managed corporate phones. The device class must be dedicated to the capability to apply.

Windows: full remote view and control, several paths

Windows is the most flexible platform for remote control, because Microsoft ships several routes to the same outcome.

Intune Remote Help

Intune Remote Help is Microsoft’s managed remote assistance product. It authenticates both the helper and the user through Microsoft Entra ID, checks device compliance before allowing a session, and logs every connection. It supports view-only and full-control sessions with user consent, as well as elevation permissions that allow the helper to enter admin credentials on the user’s device. It runs on the cloud side, so it does not require the device to be on the corporate network. As of 2026, Microsoft announced that Remote Help and the rest of the Intune Suite are included with Microsoft 365 E5 licenses.

Quick Assist and its limits

Quick Assist is the free, built-in Windows remote support tool. It works fine for one-off help but is not tied to Intune, has no compliance checks, and does not produce the audit trail that a managed helpdesk process requires. Windows Remote Assistance, the older equivalent, is being retired. For managed remote support at scale, Quick Assist is not the right long-term answer.

Third-party integrations

Intune integrates with TeamViewer as an alternative to Remote Help, with the connector managed in the Intune admin center. This is useful for organizations that already run TeamViewer or need capabilities Remote Help does not cover. It requires separate TeamViewer licensing on top of Intune.

Configuration Manager Remote Control

For organizations still running Configuration Manager (formerly SCCM), Configuration Manager has a native Remote Control feature that predates the cloud-based Intune tools. It works on domain-joined and workgroup machines and is the standard on-prem path. Under co-management, teams often keep Configuration Manager Remote Control alongside Intune Remote Help during the migration to cloud-native management.

iOS and iPadOS: remote view only, always with user consent

Apple’s iOS and iPadOS present the tightest boundary. MDM can see the screen. It cannot control it.

Why Apple does not allow touch injection

Apple has consistently designed iOS around a privacy-first model in which no third-party app or MDM can synthesize input into another app or into the system UI. The MDM protocol on iOS provides remote administration commands and configuration profiles. It does not expose a remote-injection API. Every third-party MDM works within this limit. Any vendor page that claims full remote control on iOS is describing something else, usually a scoped policy change or a targeted management command.

How screen broadcast works in practice

MDMs implement iOS and iPadOS remote view via Apple’s built-in screen broadcast mechanism, part of the operating system’s Screen Recording feature. When the admin initiates a session, the user is prompted to start screen broadcasting. The user has to accept the prompt and select the MDM’s broadcast helper before the stream begins. The screen is then streamed to the admin console. When the admin ends the session, or the user stops broadcasting, the stream ends. The workflow requires an active user on the device at all times. This works on iOS 11 and later and iPadOS 13 and later.

What supervised mode changes and does not

Supervised iOS and iPadOS devices, enrolled through Automated Device Enrollment via Apple Business, unlock deeper management commands than user-approved enrollment allows. Supervision does not unlock remote control. The touch-injection restriction is a platform-level design decision, not an enrollment-tier permission. Supervised iPads used as kiosks or dedicated hardware still require user-initiated screen broadcast for view sessions, unless the device is being managed via Classroom or other narrowly scoped Apple frameworks.

macOS: full remote view and control, with a consent step

macOS supports full remote view and control through the MDM, but the mechanism differs from Windows and Android and includes a user consent step that surprises teams new to Mac management.

MDM enables Remote Management, then ARD works

macOS has a built-in Remote Management feature based on the Apple Remote Desktop (ARD) protocol. Apple documents that MDM can enable Remote Management on managed Macs by sending the appropriate MDM command. Once enabled, an admin can connect from the MDM console, Apple Remote Desktop, or a compatible third-party client, and either view the screen or take full control. This is the native path, and it is well supported by Jamf, Kandji, Mosyle, Addigy, Intune, and other Mac MDMs.

The Screen Recording permission problem

The consent step is Apple’s Privacy Preferences Policy Control (PPPC) framework. In recent macOS versions, an app that wants to view or control the screen must hold the Screen Recording permission, which the user must grant in System Settings. MDM cannot pre-grant Screen Recording; by design, Apple excludes it from silent approval. What MDM can push is a PPPC profile that lets a standard user approve the MDM’s remote support tool without admin rights, and the user still has to complete the toggle in Screen Recording before the first session. Teams that skip this step during onboarding often discover it only at the moment of the first support call. 

Off-network macOS remote support

Native ARD is designed for local network use. For remote Macs on user home networks, teams usually pair the MDM with a cloud-relayed remote support tool. Common patterns include Jamf’s TeamViewer integration, Intune Remote Help (which supports macOS), and standalone tools like TeamViewer or Splashtop with MDM-pushed configuration. The pattern is the same across MDMs: the MDM pushes the tool and the PPPC permissions, and the tool handles the cloud relay.

What remote administration does everywhere

Remote administration is the capability set that works uniformly across Android, Windows, iOS, iPadOS, and macOS through the MDM protocol. It is often conflated with remote control, but it is a different mechanism.

These commands work through the MDM protocol regardless of whether a user is at the screen. They do not require the user to accept a session prompt. For lost-device recovery, offboarding, and mass compliance enforcement, remote administration is the tool that IT actually reaches for. Remote view and control are for interactive troubleshooting.

Designing your remote support workflow across the fleet

The platform asymmetry has direct consequences for how a helpdesk is designed. Building a workflow that assumes uniform remote control across all four OS families produces a lot of frustration on the first iOS support call.

Apple-only fleet. Expect view-only on iPhones and iPads, full view and control on Macs with the PPPC consent step handled during onboarding. Design the iOS support flow around walking the user through fixes verbally while the admin watches the screen. Do not promise the user that IT will “take over” their iPhone screen. Plan the Mac PPPC prompt into the enrollment experience so the user has already accepted Screen Recording before the first support ticket.

Android-only fleet. Establish the OEM early. Samsung, Zebra, Honeywell, and Datalogic each have their own remote-control path, and the MDM needs to support the appropriate OEMConfig app and vendor add-on for each. For unsupported Android devices, plan for view-only via user-initiated broadcasts, or narrow the fleet to supported models.

Windows-only fleet. Standardize on Intune Remote Help if you are on Microsoft 365 E5 or the Intune Suite. Retain Configuration Manager Remote Control for the co-management transition. Reserve Quick Assist for one-off cases where the caller is not a managed user.

Mixed fleet. Accept the asymmetry rather than fight it. iOS callers get view-only troubleshooting. Android callers get full control on supported OEMs and view-only on the rest. Mac and Windows callers get full control after the appropriate consent flow. A cross-platform MDM such as Bento MDM implements each OS-level capability as the OS supports it, presented from one admin console. That consolidation does not remove the platform limits; it just means an admin does not have to switch tools between users.

Which MDM approach fits your fleet?

Frequently asked questions