Five of the nine enrollment paths begin by erasing the machine. Learning that after the hardware has shipped costs a week nobody planned for.
What enrollment actually does is install a management certificate and switch on policy enforcement. Which route you take then governs three separate things: whether the machine has to be erased on the way in, how far your policies can reach afterward, and how much the person holding it has to do. Those questions belong to procurement at least as much as to engineering.
- Five platformsAndroid, Apple, Linux, macOS and Windows
- Reset requiredFor iOS, macOS and three Android modes
- 1,000 devicesWhat a device enrollment manager can enroll
- 180 daysBefore idle device records are deleted
Seven questions to close out before hardware is ordered.
Five enrollment paths require a factory reset first
The table is published and unambiguous. Erasure is required for iOS and iPadOS, for macOS, and for three Android Enterprise modes: corporate-owned work profile, fully managed, and dedicated devices. It is not required for the Android Enterprise personally owned work profile, for Android device administrator, for Linux or for Windows. Device logistics for the entire program follow from that one grid.
Corporate-owned gets more control than personal
Devices classified as corporate-owned or organization-owned unlock more granular settings and policies, with additional password settings that allow stricter requirements than a personal device permits. Worth pairing with a second published detail: anything Microsoft Entra registered is marked as personally owned, which is the usual mechanism by which a company laptop ends up filed in the wrong category.
Only the Apple platforms carry an extra prerequisite
The prerequisites table is short. iOS and iPadOS require a mobile device management push certificate from Apple plus an Apple ID; macOS requires the push certificate. Android, Android Enterprise, Linux and Windows carry no additional platform requirement at all. The Apple certificate is also the annual expiry that takes an entire fleet offline whenever its renewal has no owner.
Enrollment restrictions, which default in the permissive direction
Every platform is enabled for enrollment out of the box, and blocking the ones you do not intend to support takes an enrollment restriction policy. Put that alongside the policies capping how many devices, and which types, any one person may bring in, and you have the mechanism that keeps a fleet from accumulating hardware nobody agreed to support.
A device enrollment manager account for bulk work
For staging hardware before it reaches employees, the device enrollment manager account handles up to 1,000 mobile devices, and it is an Intune permission applied to an ordinary Entra user account. One caveat is published clearly: it does not work with every enrollment method, and Apple automated device enrollment is called out by name.
Settings survive on platforms that are not wiped
A quiet detail with loud consequences. On the platforms that skip the reset, devices begin receiving Intune policy at enrollment, but anything you have not explicitly configured in Intune is left exactly as it was. A machine migrated in from another management product can therefore carry its old configuration indefinitely, invisibly, until something behaves oddly.
Idle records are deleted after a defined period
The management certificate renews itself as long as the device keeps talking to the service, and stops renewing once a device is wiped or fails to sync for an extended stretch. Idle devices are then deleted from record 180 days after that certificate expires. Knowing this in advance saves somebody concluding that historical devices vanished through a fault.
A device already in a user's hands cannot take five of the nine enrollment paths without being wiped.
The reset requirement is published per enrollment method, and no other single fact rewrites more deployment plans after everyone has signed off on them.
- Erasure required, as published: iOS and iPadOS, macOS, Android Enterprise corporate-owned work profile, Android Enterprise fully managed, and Android Enterprise dedicated devices.
- Erasure not required: the Android Enterprise personally owned work profile, Android device administrator, Linux and Windows.
- For hardware already in circulation the implication is severe. Bringing in-use iPhones or Macs under a corporate enrollment means every unit is wiped and rebuilt, which is a communications plan, a data migration and a support surge rather than a configuration change.
- For hardware still on order the implication runs the other way entirely. New devices enrolled before they are issued take the corporate path at no cost to anybody, which is why this table belongs in the refresh conversation rather than in the technical design that comes afterward.
Four practices that turn enrollment into a choice instead of an accident.
We bring the erasure requirements into the purchasing discussion
Five of the published paths cannot be taken without erasing the device. On new hardware that costs nothing. On hardware in daily use it becomes a data migration, an internal communications exercise and a spike in tickets. Sorting out which population is which before anybody raises a purchase order converts an expensive retrofit into a decision that costs nothing because it was taken at the right time.
We get the corporate classification right at the start
Corporate-owned classification unlocks more granular settings and stricter password requirements, while anything Entra registered gets marked as personally owned. Devices that land in the wrong bucket are awkward to reclassify and quietly cap what you are able to enforce, so the identification method deserves more attention at the outset than it usually receives.
We clean up what the previous product left behind
Where no wipe occurs, any setting you have not configured in Intune is simply left untouched. A device brought over from another management product carries its previous configuration along indefinitely, and nobody sees it until behavior stops making sense. We inventory and clear that as part of the migration rather than after the first confused ticket.
We use restrictions to keep the estate to what you support
Enrollment stands open on every platform until you close it. Blocking the platforms you never intended to support, and capping how many devices and which types one person can enroll, takes about five minutes and prevents years of accumulated exceptions that nobody ever consciously agreed to.
Six US situations where the enrollment decision has real consequences.
A business moving an existing iPhone fleet under management
Because iOS and iPadOS enrollment requires a factory reset, an in-use fleet means every handset wiped and rebuilt. That is a notification plan, a backup and restore path and a wave of support calls, not a configuration change. Aligning it with a hardware refresh, where the devices are new anyway, removes the cost completely.
A remote-first company shipping devices to new hires
A device enrollment manager account covers up to 1,000 mobile devices and exists precisely to enroll and configure hardware before handing it over. When your new hires will never visit an office, that is the difference between a laptop that works the moment it is unboxed and a support call on day one. Note that it does not work with Apple automated device enrollment.
A regulated business tightening controls on company-owned hardware
Devices classified as corporate-owned or organization-owned unlock more granular settings, including additional password settings that allow stricter requirements. When a HIPAA safeguard, an FTC Safeguards Rule control or an insurance condition specifies device requirements, your ability to satisfy it rests on a classification decision taken at enrollment.
An operator deploying shared and single-purpose devices
Android Enterprise dedicated devices are wiped at enrollment and staged centrally, which fits handhelds, scanners and tablets passed between shifts. That is a fundamentally different logistics model from an employee-owned device with a work profile, and running both inside one project produces two incompatible sets of arrangements.
An organization migrating from another management product
Hardware enrolled elsewhere has to be removed from that provider first, and unenrolling typically leaves the features and settings that were configured in place. On the platforms that skip a factory reset, those settings survive into Intune unless Intune explicitly configures them, which accounts for a great deal of otherwise inexplicable behavior after a migration.
An institution wanting to limit what people can enroll
Every platform is open for enrollment by default, and an enrollment restriction policy closes the ones you do not want. Combined with policies capping the number and type of devices any individual may enroll, that stops a large and varied user population from assembling a fleet full of hardware nobody planned to support or secure.
How US organizations bring devices under management.
| Feature | Designed enrollment model | Whatever path people used | Unmanaged devices |
|---|---|---|---|
Corporate devices marked as corporate | Yes | Partly | Not applicable |
Stricter policies available where appropriate | Yes | Inconsistent | No |
Unsupported platforms blocked | Yes | No | Not applicable |
Device count per user limited | Yes | No | Not applicable |
Bulk enrollment before issue | Yes | Rarely | No |
Old settings from a previous product removed | Yes | No | Not applicable |
Enrollment failures monitored | Yes | No | Not applicable |
Apple certificate renewal owned | Yes | Discovered when it expires | Not applicable |
Stale records understood | Yes | No | Not applicable |
User experience at enrollment | Designed | Varies | Not applicable |
Erasure requirements and platform prerequisites, route by route.
Enrollment path
Android Enterprise personally owned with a work profile
- Factory reset required
- No
- Practical consequence
- The tidiest route for hardware an employee already owns, with the work side walled off
Enrollment path
Android Enterprise corporate-owned work profile
- Factory reset required
- Yes
- Practical consequence
- Suits new stock, or a scheduled wipe and reissue with notice to staff
Enrollment path
Android Enterprise fully managed
- Factory reset required
- Yes
- Practical consequence
- Company hardware only, staged before anybody receives it
Enrollment path
Android Enterprise dedicated devices
- Factory reset required
- Yes
- Practical consequence
- Shared and single-purpose units, prepared centrally
Enrollment path
Android device administrator
- Factory reset required
- No
- Practical consequence
- Legacy, and deprecated wherever Google Mobile Services are present
Enrollment path
iOS and iPadOS
- Factory reset required
- Yes
- Practical consequence
- Also depends on an Apple push certificate and an Apple ID
Enrollment path
macOS
- Factory reset required
- Yes
- Practical consequence
- Also depends on an Apple push certificate
Enrollment path
Windows
- Factory reset required
- No
- Practical consequence
- Machines can enroll where they stand, though old settings may survive the move
Enrollment path
Linux
- Factory reset required
- No
- Practical consequence
- Enrollment initiated by the user on supported distributions
Five steps, and the pilot is not a formality.
- 1
Confirm the prerequisites are actually in place
Management authority set to Intune, which applies even where Configuration Manager runs alongside it in co-management. Licenses assigned. Supported devices confirmed. An Apple push certificate obtained wherever iOS, iPadOS or macOS appear in scope, with a named person accountable for renewing it.
- 2
Decide the path per population
Personal or corporate ownership, and the enrollment method that follows from it, checked against the published reset requirements. Whether the hardware is new or already in service, since that decides whether erasure is free or expensive. And whether anything currently sits in another management product, which has to be unenrolled first.
- 3
Set restrictions before opening enrollment
Since every platform starts open, the ones you have no intention of supporting get blocked explicitly. Policies capping how many devices and which types any one person can enroll go in at the same moment, because both are dramatically easier to apply before a fleet exists than to retrofit around one that already does.
- 4
Pilot in stages, starting genuinely small
The recommended shape is to start small and widen deliberately: assign the enrollment policy to a pilot or test group, add more users to that group once early testing looks clean, then extend to further pilot groups. Following it surfaces problems with the enrollment experience while the affected population is still small enough to call one by one.
- 5
Establish the operational rhythm
Incomplete user enrollments watched through the published report. Apple push certificate renewal owned by a named person with a reminder well ahead of the date. And a shared understanding that idle records disappear 180 days after the management certificate expires, so Intune should never be mistaken for a permanent asset register.
What organizations ask about device enrollment.
Fifteen decisions that determine the enrollment experience.
Prerequisites
- Is the MDM authority set to Intune?Required even where co-management is in play.
- Are Intune licenses assigned?To everyone who will enroll a device.
- Is the Apple push certificate in place?Needed for iOS, iPadOS and macOS.
- Who renews the Apple certificate?It expires, and the fleet expires with it.
- Which administrative role is being used?Policy and Profile Manager is the least privileged fit.
Path decision
- Are these new or existing devices?Five of the paths begin with an erasure.
- Personal or corporate-owned?Corporate unlocks stricter password settings.
- Are devices already in another MDM?Remove them from the incumbent first.
- Do you need bulk enrollment before issue?That is the DEM account, up to 1,000 devices.
- Is Apple automated device enrollment in scope?The DEM account does not work with it.
Keeping it clean
- Which platforms should be blocked?Every one of them is open by default.
- How many devices may one person enroll?Enrollment policies can cap this.
- Are settings from a previous product still present?They persist wherever no wipe occurred.
- Is there a pilot group?A staged approach is the recommended shape.
- Who watches incomplete enrollments?A published report covers exactly this.
The pages around this one.
Windows Autopilot
The Windows provisioning route in depth, where enrollment turns into a machine that sets itself up.
Android Enterprise management
The Android methods examined closely, including the factory reset table and zero-touch staging.
MDM solutions
The cross-platform view of what management looks like once devices are in.
Work out how many of your devices would have to be wiped. That number is the project.
Five of the published routes begin with a factory reset. Where most of the fleet is heading for a refresh anyway, that costs almost nothing. Where it is not, the timing is a decision worth taking deliberately rather than discovering halfway through.
Related Services
Explore more solutions that work great with this service