A unified endpoint management (UEM) platform holds the power to configure, patch, lock and erase every laptop, phone and tablet you own, so choosing one is as much a security decision as an IT one. UEM grew out of mobile device management (MDM) and enterprise mobility management (EMM): MDM controls the device, EMM added app and content management for mobile, and UEM brings desktops, mobiles and specialist devices under one console and policy model. Most products now claim all six major platforms, but depth varies widely by operating system, by enrolment method and by ownership model. This vendor-neutral guide is for endpoint, IT operations and security teams writing requirements, running an RFP or consolidating tools, and ends with a proof of concept you can run on real devices.
Key takeaways
- Score depth per platform, not logos. A tick for Linux or ChromeOS can mean inventory only, so test each operating system you run.
- Zero-touch enrolment is the foundation. Apple Automated Device Enrollment, Android zero-touch and Windows Autopilot decide whether devices arrive managed, supervised and hard to un-enrol.
- Compliance is only useful when it gates access. The UEM must feed reliable device state into conditional access and device trust decisions, with a safe default for unassigned devices.
- BYOD needs privacy by design. Android work profiles and Apple User Enrollment separate work from personal data; check exactly what the organisation can and cannot see or erase.
- The UEM console is a tier-zero system. One hijacked administrator or API credential can wipe the fleet, so admin RBAC, multi-admin approval and control of API identities belong in the evaluation, not the hardening backlog.
Define requirements
Start with an inventory: devices by platform, ownership model and use case, and what manages them today, such as Microsoft Configuration Manager (formerly SCCM), standalone MDM or scripts.
- Platforms and versions: Windows, macOS, iOS and iPadOS, Android Enterprise, Linux distributions and ChromeOS, plus kiosk and shared devices. Record minimum OS versions: Apple's account-driven User Enrollment needs iOS 15 or macOS 14, and Android zero-touch has a baseline of Android 9.0.
- Ownership models: corporate-owned single user, corporate-owned with personal use, shared or dedicated devices, and personally owned (BYOD). NIST SP 800-124 Rev. 2 covers both across the device lifecycle.
- Identity and access stack: your identity provider, conditional access engine, certificate authority, VPN or zero trust network access and EDR, which all need device state from the UEM. See the Conditional Access Guide.
- Co-management and migration: Microsoft's co-management model is a useful reference: Windows devices (Entra joined or hybrid joined) are managed by Configuration Manager and Intune at once, and workloads such as compliance, Windows Update policies and device configuration move one at a time with a pilot collection. Ask any shortlisted platform for an equivalent staged handover.
- Control obligations: map requirements to the frameworks you report against, for example NIST SP 800-53 CM-8 (system component inventory), CM-6 (configuration settings), AC-19 (access control for mobile devices) and SI-2 (flaw remediation); CIS Controls v8.1 Control 1 (asset inventory), Control 4 including 4.11 (remote wipe on portable devices) and Control 7 (vulnerability management); and ISO/IEC 27001:2022 Annex A 8.1 (user endpoint devices). The NCSC device security guidance gives platform baselines.
| Ownership model | Typical enrolment | What the organisation controls |
|---|---|---|
| Corporate Apple device | Automated Device Enrollment through Apple Business or Apple School Manager | Supervised: all restrictions, Activation Lock, minimum OS at enrolment, enforced updates |
| Corporate Android, work only | Zero-touch, QR code or NFC provisioning as fully managed or dedicated | Full device policy; kiosk lock-down for dedicated devices |
| Corporate Android, personal use allowed | Work profile on a company-owned device | Work profile plus device-wide policies; personal data not visible |
| Corporate Windows | Windows Autopilot, Entra or hybrid join, automatic MDM enrolment | Full configuration, apps, updates, Autopilot Reset for repurposing |
| Personal iPhone, iPad or Mac | Account-driven User Enrollment with a Managed Apple Account | Managed apps and data, passcode, erase of managed data; no full erase, serial number, device VPN or enforced updates |
| Personal Android | Work profile on a personally owned device | Work profile only; no visibility of the personal profile |
Size changes the answer. A small organisation with one main platform gains most from zero-touch enrolment, compliance-based access and patching. A large or regulated estate also needs RBAC scoped by region, staged rings, co-management during migration, full API coverage and audit evidence. A specialist tool for one platform is acceptable if its compliance signal reaches the same access policy.
Evaluation criteria
Weight the criteria to your inventory and test each one on every platform in scope.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Platform coverage | Full management on Windows, macOS, iOS and iPadOS, Android Enterprise, Linux and ChromeOS; new OS releases supported on release day | Linux or ChromeOS limited to inventory; months of lag after OS releases |
| Enrolment | Apple ADE (supervised), Android zero-touch (provisions on first boot or next factory reset), Windows Autopilot; minimum OS at enrolment | Manual enrolment by users; devices that can leave management after a reset |
| Configuration and compliance policies | Settings catalogue, CIS or NCSC baselines, grace periods and staged actions (notify, lock, retire); devices with no policy non-compliant | Custom scripts needed for basic settings; default "compliant" with no warning |
| Patch and app management | OS and third-party patching with rings and deadlines, app catalogue, automatic app updates | OS patching only; no deadline enforcement or reporting by version |
| Declarative Device Management | Apple DDM configurations, assets and activations; status channel reporting changes; update enforcement by date and time | Only legacy command-and-poll MDM for Apple devices |
| Conditional access and device trust | Compliance signal to your identity provider, device attestation where supported, device certificates, EDR and mobile threat defence signals | Compliance visible only inside the UEM console |
| BYOD privacy | Android work profile and Apple User Enrollment; clear statement of what is collected; selective wipe only | Full enrolment required for personal phones; location collected without need |
| Remote actions | Lock, selective wipe, full wipe, retire, lost mode, passcode reset and restart, with scoping, confirmation and audit trail | Bulk actions with no confirmation or rate limit |
| Reporting | Compliance and patch status by platform and ring, full API, admin audit logs to the SIEM | Static dashboards; audit logs not exportable |
| Security of the UEM itself | Scoped RBAC, phishing-resistant admin MFA, multi-admin approval for destructive and high-impact changes, governed API identities, tenant audit log | Single global admin role; API access only through long-lived shared secrets |
Two details deserve a demonstration. Apple Declarative Device Management lets the device keep a defined state and report changes through a status channel; enforced updates run at a set local time and on macOS force-quit open apps at the deadline, so test the user experience. And the compliance default matters: in Microsoft's documented example, devices with no compliance policy are marked compliant unless an admin changes the tenant setting to Not compliant, and a device that fails to report within the validity period (30 days by default) becomes non-compliant. See the Device Trust and Posture Guide.
Admin and API identities are the real attack surface
The NCSC warns that it is "important to keep MDMs secure as they hold the keys to unlock, decrypt and remote wipe all the devices within your enterprise". The Stryker Intune wiper attack showed it in practice: one hijacked admin account used the platform to wipe tens of thousands of devices. Evaluate four controls:
- Scoped admin RBAC: roles limited by action and by device group or region, so no day-to-day account can wipe the fleet.
- Multi-admin approval: a second administrator must approve wipe, retire and delete actions, role changes, script deployment and policy changes. Microsoft documents this as multi admin approval, noting that "An administrator can't approve their own requests" and that it also applies to app-authenticated Graph calls. Excluded applications bypass it, so keep that list near empty.
- API credentials as privileged NHIs: integrations call the UEM API with service principals, API keys or OAuth clients, and destructive actions are often open to them: the Graph wipe call accepts the application permission DeviceManagementManagedDevices.PrivilegedOperations.All. Require read-only scopes by default, certificate or federated credentials instead of static secrets, a named owner, rotation and an exportable inventory. See the Service Account Security Guide and API Key Management Guide.
- Alerting: bulk remote actions, new admin role assignments and new API permissions streamed to the SIEM.
Questions to ask vendors
- Show configuration, compliance, patching and remote wipe on a real device for each platform we run. What is missing on Linux and ChromeOS?
- How quickly did you support the last two major releases of iOS, macOS, Android and Windows, and which Apple DDM declarations do you support today?
- After a factory reset, does a device enrolled through ADE, Android zero-touch or Autopilot return to management without user action?
- How is a device with no compliance policy, or a device that has stopped reporting, treated by default, and how does that state reach our identity provider?
- On a personal phone enrolled through a work profile or User Enrollment, list every data item you collect and every action we can take.
- Which actions can require a second administrator's approval? Does the approval also apply to API calls, and can any integration bypass it?
- Which API permissions allow wipe, retire, delete or script deployment, and can we issue read-only, scoped and short-lived credentials to integrations?
- How do we stage a migration from our current tool or co-manage during transition, and how do we roll a policy back across a ring?
Red flags
- Platform parity claimed in the datasheet but not demonstrated on Linux, ChromeOS or older OS versions.
- Bulk wipe or retire with no second approval, no rate limit and no alert.
- Integrations that require a global administrator account or a long-lived API key with write access.
- Compliance defaults that treat unmanaged or silent devices as compliant without telling you.
- BYOD enrolment that needs full device control, or vague answers on personal data collection.
- No admin audit log export, or audit history kept for only a few days.
Proof of concept
- Scope it: enrol at least two real devices per platform in scope (corporate and, where relevant, personal) plus a kiosk device. Agree pass criteria first.
- Enrol zero-touch: register test devices in Apple Business or Apple School Manager, the Android zero-touch portal and Windows Autopilot. Confirm supervision, minimum OS enforcement and re-enrolment after a factory reset.
- Apply a baseline: import an NCSC or CIS-aligned configuration in audit or report-only mode where available, then enforce it on a pilot ring.
- Gate access: connect compliance to a conditional access policy in report-only mode, break a rule, such as disabling disk encryption, and time how long until access is blocked and restored. See the Endpoint Security Guide.
- Patch with a deadline: push an OS and a third-party update through two rings with a deadline, then pause and roll back the second ring.
- Test BYOD privacy: on the personal devices, check what the console shows, run a selective wipe and confirm personal data is untouched. See the Mobile Device Security Guide.
- Attack the console: enable multi-admin approval, then try to wipe a test group from one admin account and from an API client. Create a read-only integration identity and confirm it cannot call destructive endpoints. Confirm the SIEM sees every attempt.
- Measure and decide: track enrolment success rate, percentage of devices compliant and reporting within 24 hours, time to block a non-compliant device, patch compliance within the deadline by ring, and the number of admin and API identities holding destructive rights. Keep them after go-live.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Endpoint Security Guide · Mobile Device Security Guide · Device Trust and Posture Guide · Conditional Access Guide · Patch Management Guide