XR headsets need a dedicated management platform because generic MDMs target phones, tablets, and laptops: devices with fundamentally different control surfaces, file sizes, and user environments than headsets. The gaps show up in production — 2GB file size caps that block VR app deployment, enrollment processes that require individual ADB commands for each device, and no mechanism to control what users see and do inside the headset. Organizations that discover these gaps after deploying hardware at scale pay to fix them twice.
One healthcare organization found this out at $20,000 and thousands of hours of labor.
The company deployed 4,000 XR headsets across more than 30 locations. Their existing MDM handled the initial rollout. But once devices shipped, the problems started: the MDM couldn’t deploy their XR apps (file size limits), couldn’t lock down the in-headset environment (no kiosk mode for XR hardware), and couldn’t push content updates remotely without manual intervention on every device.
Their fix: ship every headset back to IT. Factory-reset each one by hand. Install a purpose-built XR management platform. Ship them all back out.
$10,000 in inbound shipping. $10,000 outbound. Plus the labor. Plus the program delay.
The company asked to remain anonymous. They’re not the only ones who’ve made this mistake.
What breaks when you use the wrong MDM for XR?
Three systems fail, consistently, across organizations that deploy XR fleets on generic MDMs.
App deployment hits a wall at file size. Enrollment breaks at scale. And in-headset control disappears entirely.
Each failure is predictable. Each is manageable at 10 devices during a pilot. At 200 devices across multiple sites, each one stalls a program.
Generic MDMs work well for phones, tablets, and laptops. XR headsets require a different set of controls that generic platforms don’t offer.
Why can’t standard MDMs handle XR app deployments?
Most generic MDMs cap deployable files at 2GB. That’s the first wall.
VR applications regularly exceed 2GB. 360-degree video runs from 500MB to 15GB per file. A single enterprise training module can push past the limit before an IT team knows the limit exists. When the MDM can’t handle the file, the app doesn’t deploy. Admins discover this on a Tuesday when 300 headsets across 8 sites sit idle because a content update failed to push.
The second problem is update mechanics. Generic MDMs don’t support differential updating. Every version update pushes the entire app. On a fleet of 500 headsets, each running a 3GB training application, one update cycle generates 1.5TB of network traffic. Teams don’t find this out during the pilot. They find it when they try to push an update across 200 devices and their site Wi-Fi collapses under the load.
Version management breaks third. Most generic MDMs hold a single active version per app. XR deployments typically need at least two in parallel: a stable production version for live training, and a staging version for QA before a new release goes fleet-wide. Without release channels, admins manage versioning manually, which means they mostly don’t manage it. Devices across locations end up running different app versions, and training outcomes drift with them.
The last gap is visibility. When an app fails to install on a subset of devices, a generic MDM can’t surface that from a dashboard. Admins put on each headset to check. At 50 devices across 3 locations, that’s a full day. At 500 devices across 10 locations, it doesn’t happen.
ArborXR addresses all four: no file size limits, differential updating that pushes only changed bytes, release channels for multi-version control across device groups, and a deployment status dashboard showing real-time install status across every device in the fleet.
Can I use Intune or Workspace ONE for XR?
Yes, with significant caveats that matter once deployments scale.
Intune manages the Android layer of XR headsets: policy enforcement, Wi-Fi configuration, and basic app deployment. It offers no in-headset UX control and no XR-specific content tooling. For IT teams already running Intune, ArborXR is an official Microsoft Intune Device Compliance Partner: XR headsets managed by ArborXR report compliance status directly into Intune, so the same conditional access policies that govern laptops and phones extend to the headset fleet without a separate compliance workflow.
Workspace ONE XR Hub, now under Omnissa, goes further than Intune for XR. It offers an in-headset launcher and some kiosk mode functionality for select devices. Kiosk mode for Meta Quest remains in tech preview. Meta Horizon managed services, now required for Quest devices in enterprise deployments, enables HMS enrollment for Meta Quest. That enrollment path is available to any MDM that supports HMS, including ArborXR. For mixed fleets that include Pico, HTC VIVE, or other AOSP hardware, Workspace ONE still requires ADB commands for each device.
The gaps that remain are in the content management layer. Workspace ONE doesn’t support differential updating for large XR app files. Remote view (the ability to see what a user sees inside the headset) isn’t supported. App version management relies on manual APK uploads with no release channels and no ISV content sharing pipeline.
For organizations already running Workspace ONE across a large device estate, adding XR devices through the same platform is appealing. The organizations that run into its limits are typically running mixed hardware, managing large app files, or needing visibility into deployments across a fleet without accessing individual devices.
A detailed breakdown of where Workspace ONE supports XR and where it doesn’t is at arborxr.com/blog/workspace-one-xr-hub.
One additional factor: the XR management landscape has shifted. Meta Horizon managed services is now free and self-serve, which lowers the barrier to starting an XR program. The ceiling hasn’t changed. HMS is in maintenance mode: no new features, no patches, and no enterprise support escalation path through January 2030. Teams running on HMS alone will hit those limits when they try to scale. Google’s Android XR platform is also adding new devices, including Samsung Galaxy XR and XREAL Aura, that use standard Android enrollment paths but still require purpose-built XR management for content delivery and in-headset control.
What does fleet management look like on a generic MDM at scale?
The enrollment process is the clearest sign that something is wrong.
Enrolling a single XR headset on most generic MDMs requires:
- Download the MDM client APK to a PC.
- Plug in the headset and install the client via ADB command.
- Set the client as device owner via a second ADB command.
- Put on the headset and type credentials using the in-headset virtual keyboard.
For 5 devices, this takes an afternoon. For 500 devices, it requires staff who know ADB, a dedicated block of time per device, and a debug process for enrollment errors that puts a device back to step one. Enrollment errors on generic MDMs are common and hard to diagnose remotely.
The admin interface adds to the overhead. Generic MDMs display feature sets built for phones and tablets. Admins managing XR devices navigate menus full of controls that either don’t apply to headsets or don’t work on them, with no clear indication of which is which. Experienced MDM administrators spend hours figuring out what the platform supports for XR before they can manage anything.
Remote support is the last wall. When a user inside a headset needs help, the admin talks them through it verbally without any view into what the user sees. For programs deploying to people using headsets for the first time, this is a constant support burden with no clean solution on a generic MDM.
How does the wrong management layer affect what users see inside the headset?
Without in-headset control, users see the full native device environment: the OS home screen, the app store, the web browser, and every pre-installed application. On a Meta Quest, that includes the Meta storefront and a fully functional internet browser with no filtering. On a training device deployed to hundreds of employees in a healthcare or manufacturing setting, that’s a compliance problem.
Kiosk mode addresses this by restricting the device to a single designated application that launches automatically on boot. The problem: kiosk mode for XR headsets requires explicit platform support, and most generic MDMs either don’t offer it for XR hardware or have it in tech preview on the most commonly deployed devices.
A VR launcher is a different tool. Kiosk mode locks to one app. A VR launcher gives IT a configurable multi-app environment inside the headset: admins choose which apps appear, disable the native browser and app store, apply company branding, and set the navigation layout. Users get a controlled, professional environment. Admins get fleet-level control without touching each device individually. Generic MDMs don’t offer this.
VR Single Sign-On (SSO) closes the last gap. Shared headsets, standard practice in manufacturing training, healthcare simulation, and most education deployments, need individual identity tied to each session. With VR SSO, users authenticate before accessing content, sessions tie to individual records, and the headset returns to an unauthenticated state when the user exits or the device powers down. No generic MDM supports this.
XR fleet management: what generic MDMs provide vs. what a purpose-built platform provides
*Among generic MDMs, only Omnissa Workspace ONE offers single-app kiosk mode, a VR launcher environment, and multi-app kiosk mode for select XR devices. Kiosk mode for Meta Quest remains in tech preview. For non-Meta AOSP hardware (Pico, HTC VIVE, and others), enrollment requires ADB commands.
“UEMs and traditional MDMs are like swiss army knives. Sure, they have a screwdriver. But you don’t want to build your house with a swiss army knife. ArborXR gives you the tools you need to build in VR.”
Scott Miller, CEO, Miller Creative
Frequently asked questions
What should IT teams look for in a purpose-built XR management platform?
The teams that avoid the rebuild scenario evaluate the management layer before hardware ships, not after.
The evaluation covers five areas. Content delivery: does the platform handle app files over 2GB, support differential updating, and give ISVs a direct delivery path without external cloud storage? Enrollment: does it support bulk enrollment without per-device ADB commands? In-headset control: does it offer kiosk mode and a VR launcher on the specific hardware being deployed, confirmed and not in tech preview? Deployment visibility: can admins see real-time install status across the full fleet from a dashboard, without accessing each device? Version management: does it support release channels for multi-version parallel deployment across device groups?
ArborXR covers all five. Device management, content delivery, fleet provisioning, kiosk configuration, and in-headset launcher control run from a single dashboard built specifically for XR hardware. The platform supports Meta, Pico, HTC VIVE, Magic Leap, and other major XR hardware. More than 3,000 organizations use it to manage XR fleets, including 75+ Fortune 500 companies in manufacturing, healthcare, aviation, and enterprise training.
The $20,000 mistake is avoidable. The organizations that avoid it treat the management layer as a deployment decision, not an afterthought.
What’s the difference between a generic MDM and a purpose-built XR management platform?
Generic MDMs manage the Android or Windows device layer: apps, security policies, Wi-Fi, and remote wipe. They target phones, tablets, and laptops. Purpose-built XR management platforms add the layer above: GB-scale content delivery with differential updating, in-headset UX control (kiosk mode, VR launcher, VR SSO), and deployment visibility across a headset fleet from a single dashboard. Generic tools cover the device OS layer. Purpose-built platforms cover the XR operating environment.
What breaks when you use the wrong MDM for XR?
Three things break consistently. App deployment fails when files exceed the MDM’s size cap (typically 2GB, while many VR apps exceed that). Enrollment becomes unmanageable at scale because generic MDMs require ADB commands and in-headset keyboard input for each device. And in-headset control disappears entirely: no kiosk mode for XR hardware, no VR launcher, and no way to see what users see inside the headset. Each gap is manageable at 10 devices. At 500, each becomes a program-stalling problem.
Can I use Intune or Workspace ONE for XR?
Both platforms offer basic XR device support, enough for a small pilot with IT staff on-site. At fleet scale, the gaps matter: neither supports differential updating for large XR app files, kiosk mode for Meta Quest remains in tech preview in Workspace ONE, and enrolling non-Meta AOSP devices (Pico, HTC, and others) requires ADB commands on both platforms. Content management gaps compound this further: no remote view, no release channels, and no ISV content sharing pipeline. A detailed Workspace ONE comparison is at arborxr.com/blog/workspace-one-xr-hub.
How does differential updating work, and why does it matter for XR?
Differential updating pushes only the changed bytes in an app update, rather than re-downloading the full application. On a 1.2GB app with 100MB of changes, differential updating sends 100MB per device instead of 1.2GB. On a fleet of 500 headsets, that’s 50GB of network traffic per update cycle instead of 600GB. Without differential updating, admins often defer updates to avoid the bandwidth cost, and devices across the fleet end up running different versions.
What is a VR launcher, and why doesn’t standard kiosk mode replace it?
Kiosk mode locks a device to a single application that launches automatically on boot. A VR launcher creates a configurable multi-app environment inside the headset: admins set which apps are accessible, disable the native browser and app store, apply company branding, and control navigation layout. Users get a professional, controlled environment instead of the device’s native OS. For training programs where users need access to multiple applications in a single session, kiosk mode is too restrictive. A VR launcher gives IT full control over the headset environment without limiting users to one app.
What should organizations audit before choosing an XR management platform?
Five areas require evaluation before committing to an XR management platform. Content delivery must support files over 2GB with differential updating, and enrollment must work in bulk without ADB commands for each device. In-headset control requires confirmed kiosk mode and VR launcher support on the specific hardware being deployed (tech-preview features don’t count for production deployments). Deployment visibility and version management complete the checklist: real-time install status from a dashboard, and release channels for parallel version control across device groups. Evaluating these before hardware ships costs an afternoon; discovering the gaps after the fleet is in the field can cost weeks.
ArborXR is one of the few platforms willing to answer the questions most vendors avoid. That transparency extends to how we work with enterprise teams.
Most XR management problems are solvable before they become expensive. ArborXR gives operations and IT teams the controls they need to run fleets without the fire drills. See what that looks like at arborxr.com/explore.