Microsoft Intune enrollment methods cheat sheet

The process that enables device management for a device is called device enrollment. During enrollment, Intune installs a Mobile Device Management (MDM) certificate on the device; the certificate is how the device communicates with the Intune service, and it is what lets Intune start enforcing enrollment restrictions, compliance policies and configuration policies. Registration in Microsoft Entra ID comes first: the user must authenticate and establish a device identity in the tenant before the device can enroll, and which identity option you use (Entra registration, Entra join, or hybrid join) determines which enrollment methods are available.

Two identity options carry most enrollments. Microsoft Entra registration is the identity option for personal and corporate-owned mobile devices — the user signs in to work resources with their work account, and the device gets an Entra registered state. Microsoft Entra joined is the option for corporate-owned Windows devices using co-management, with the user signing in to the device itself; Microsoft Entra hybrid joined adds the on-premises domain join for environments that still have Active Directory. A device is enrolled to one user or enrolled userless (no primary user is assigned); single devices cannot be enrolled to multiple users.

Before users can enroll, the tenant's MDM authority must be set — choose Intune MDM Authority (or Intune co-management). Enrollment is enabled for every platform by default, and you restrict platforms with enrollment-restriction policies rather than by turning enrollment off. The enrollment methods below are the current documented list, with the flow that makes each one work and the prerequisite that catches people out.

Enrollment methods at a glance

Current Intune enrollment methods and who performs each step (enrollment guide).
Method	Devices	Who does it	Requirements / Notes
User self-service: Company Portal or Settings	Personal + corporate, virtually every platform	The device user	Device is Entra registered. MDM authority = Intune, user has an Intune license. Windows users can connect a work or school account from Settings (no domain join), sign in to Company Portal, or select 'Allow my organization to manage my device' at a Microsoft 365 app sign-in. BYOD variants: Apple User Enrollment / Apple Device Enrollment, Android personally owned work profile.
Windows Autopilot (user-driven, pre-provisioned, self-deploying)	Corporate Windows desktops, laptops, kiosks	Admin prepares (registration + profile); user finishes at OOBE; OEM/reseller may run the technician flow for pre-provisioned	Device registered with the Autopilot service by hardware hash + tenant, then an Autopilot profile assigned (a default profile applies if none is assigned). Entra ID P1/P2 required. Entra join is supported by all scenarios; hybrid join only by user-driven and pre-provisioned. TPM attestation required for pre-provisioned and self-deploying (physical devices only).
Android Enterprise corporate: QR, Google zero-touch, Samsung Knox, NFC, token	Corporate Android: fully managed (COBO), dedicated (COSU), corporate-owned work profile (COPE), plus AOSP corporate userless / user-associated	IT admin provisions; device user (or nobody, with zero-touch) at first boot	Connect Intune to managed Google Play first. QR code is the documented recommendation for most scenarios. Zero-touch requires devices from an authorized zero-touch reseller; provisioning starts right out of the box. Token entry uses the afw#setup DPC identifier with an enrollment token that never expires. COBO and COPE devices should be factory reset when switching from another MDM.
Apple Automated Device Enrollment (ADE)	Corporate iOS/iPadOS, macOS, tvOS, visionOS purchased through Apple Business Manager or Apple School Manager	Apple program + Intune; user completes Apple Setup Assistant during OOBE	Requires an Apple MDM push certificate plus an Apple enrollment program token. Supports supervision and zero-touch provisioning. Devices get corporate-owned status. Factory reset required to switch from another MDM. Userless deployments (no user affinity) are supported.
Apple Configurator	Corporate iOS/iPadOS or macOS, physically in hand	IT admin on a Mac, wired connection	Setup Assistant enrollment wipes the device and takes serial numbers; Direct enrollment does not wipe and never associates a user — meant for shared and kiosk devices. Use it when you have no access to Apple Business or School Manager.
Apple User Enrollment / Apple Device Enrollment (BYOD)	Personal iOS/iPadOS	The device user, in Company Portal	Apple User Enrollment keeps managed data and apps on a separate volume and is the lighter-touch option. Apple Device Enrollment gives you more control over settings, such as more granular passcode requirements. Personal Macs follow the Company Portal BYOD flow.
Bulk: provisioning package, or a device enrollment manager	Corporate Windows (package); any platform (DEM account)	IT admin	Windows Configuration Designer creates a provisioning package applied at OOBE or from Settings — no reimaging. A device enrollment manager (DEM) account can enroll and manage up to 1,000 devices, versus 15 devices for a standard non-admin account. DEM is not compatible with every method, such as Apple automated device enrollment.
Group Policy or co-management enrollment	Corporate Windows (Entra hybrid join)	Automatic (scheduled task) or Configuration Manager	A Group Policy triggers automatic enrollment on hybrid joined devices without user interaction, for environments that do not use Configuration Manager. Co-management enrolls existing Configuration Manager clients and lets you move workloads to Intune. Entra registered ('workplace joined') devices are not supported for co-management.
MAM without enrollment	Personal or unmanaged Android / iOS/iPadOS	The user, by signing in to managed apps	App protection policies only — no MDM certificate, no device in management. The Company Portal app is still required on Android to receive app protection policies. Data protection is limited to work apps: selective wipe removes org data without touching personal apps.

The prerequisite chain in order: MDM authority set (Tenant administration > Tenant status > Tenant details shows MDM authority), Intune licenses assigned, supported OS on the device, an Apple MDM push certificate for anything Apple, a managed Google Play connection for Android Enterprise, and the Azure AD connector (Intune Connector for Active Directory) if you deploy hybrid-join Autopilot. iOS/iPadOS devices also need an Apple ID-issued MDM push certificate.

How enrollment works

The trip from empty device to managed device

Entra registration or join comes first: device identity established, user authenticated. Intune does not store identities — Entra supplies authentication, users and groups, and Conditional Access signals.
Enrollment installs the MDM certificate. From the check-in on, Intune applies enrollment restrictions, compliance policies and configuration policies that target the user group.
Policies are usually deployed during enrollment. Microsoft advises starting with a baseline set of policies for all users and devices, then adding stricter policies per group.
Enrollment is enabled by default for all platforms; you gate it with enrollment restrictions (block a platform, OS version, manufacturer, or ownership type). Restrictions are documented as best-effort barriers, not security features.
Corporate-owned classification: Intune auto-marks devices that meet criteria such as registered serial/IMEI, Apple automated device enrollment, Windows Autopilot, or bulk provisioning as corporate-owned. iOS/iPadOS and macOS devices are personally owned by default. Corporate-owned is what unlocks stricter passcode settings.
Housekeeping: the MDM certificate renews automatically while the device talks to Intune. It does not renew for wiped devices, and Intune deletes idle device records 180 days after the certificate expires.

Enrollment and identity decisions that change which methods you can use

Microsoft Entra registration: Personal and corporate-owned mobile devices; user signs in to apps and web resources with a work account. Devices show as Entra registered — the identity for BYOD and for MAM without MDM.
Microsoft Entra joined: Corporate-owned Windows devices (and feature for co-management); user signs in to the device with their work account. Cloud-native option Microsoft recommends for new deployments.
Microsoft Entra hybrid joined: Windows devices joined to on-premises AD and registered in Entra. Requires domain-controller connectivity (on-prem or VPN) for Autopilot hybrid join; remote hybrid-join Autopilot needs the Intune Connector for Active Directory.
Enroll to one user or none: A device is enrolled to a single user, or userless with no primary user (Autopilot self-deploying, Android dedicated, userless ADE, DEM-owned devices). Single devices cannot be enrolled to multiple users.
Device limit: Enrollment device limit restrictions run 1-15 devices per user; a standard non-admin account can enroll 15, a DEM account 1,000.

Windows Autopilot: registration, profile, rollout

Autopilot scenarios with the join types and user-association support each one has (Autopilot scenarios doc).
Scenario	Entra join	Hybrid join	User assigned	Who interacts	Notes
User-driven	Yes	Yes	Yes	The user runs deployment	Device must be registered with the Autopilot service + a profile assigned. No TPM attestation, so physical devices and VMs both work.
Pre-provisioned	Yes	Yes	Yes	Technician flow (admin/OEM/reseller), then user flow	Splits the deployment; needs TPM attestation, so physical devices only. User still completes the sign-in flow.
Self-deploying	Yes	No	No	None — fully automated	No user ESP. TPM attestation required, physical devices only. Used for kiosks and multi-user devices.
Existing devices	Yes	Yes	NA	IT admin (Configuration Manager task sequence)	Not itself an Autopilot deployment: reimages the device, then runs a real Autopilot deployment (typically to convert hybrid to cloud join).
Reset	Yes	No	NA	Local or remote trigger	Rebuilds the existing Windows installation back to factory state; device stays registered. Hybrid join devices not supported.

Registration and profile assignment are two different steps. A device must be registered (hardware hash uploaded and associated with the tenant — ideally by the OEM, reseller or distributor) before Autopilot works. If no Autopilot profile is assigned, the device receives the Windows Autopilot default profile. Autopilot devices live under Devices > Enrollment > Windows > Windows Autopilot > Devices, and they only appear in the normal Windows devices list after a licensed user signs in. Never register Entra registered ('workplace joined') or Intune MDM-only devices — those are for personal devices, while Autopilot registration is corporate-owned.

MAM vs MDM: enrollment and beyond

The two management modes and what each one can do

MDM (device enrollment): Device is enrolled (MDM certificate); Intune manages the whole device — settings, security, apps. Full wipe and retire are available. Typical for corporate-owned devices, and for BYOD users who agree to get managed.
MAM (app protection policies): Only the work apps and the data inside them are managed. Device stays unmanaged; the user keeps control of personal apps and content. Typical for personal BYOD. Works with or without MDM — and runs alongside MDM on corporate devices too.
MAM without MDM limits: Apps are not deployed to the device (user installs from the store); no certificate profiles; no company Wi-Fi or VPN profiles; no compliance status. Protection = app PIN, data relocation rules, encryption, selective wipe.
Selective wipe: MAM selective wipe removes company data from the apps (the SDK checks for wipe requests about every 30 minutes and at first app launch). A full device wipe restores factory defaults — full wipe and MDM retire only exist on MDM-enrolled devices.
The scope gotcha: If both the MDM and MAM user scopes are enabled in the Intune automatic enrollment configuration, the <strong>MAM scope takes precedence</strong> and the device is not enrolled in Intune at all. Unset one if you expected enrollment for those users.

Troubleshooting enrollment: dsregcmd

The verified Windows diagnostics command — identity state, not management state

REM 1) Run as the signed-in user (the User State section needs a user context)
dsregcmd /status

REM 2) Elevated prompt: SYSTEM-context pre-join diagnostics and the KeySignTest check
dsregcmd /status

The dsregcmd sections that answer the enrollment questions

Device State: AzureAdJoined / EnterpriseJoined / DomainJoined: YES NO NO = Entra joined; NO NO YES = domain joined; YES NO YES = Entra hybrid joined; NO YES YES = on-premises DRS joined.
User State: WorkplaceJoined: YES = Entra registered (the BYOD state). Also NgcSet for Windows Hello and WamDefaultSet for Web Account Manager.
DeviceAuthStatus: SUCCESS means the device exists and is enabled in Entra; FAILED means it is disabled or deleted.
Tenant Details: MdmUrl / MdmTouUrl / MdmComplianceUrl empty = MDM automatic enrollment is not configured or the current user is out of MDM scope. Their presence does not prove the device is managed.
AzureAdPrt (SSO State): YES if a Primary Refresh Token exists for the signed-in user; absent PRTs are the usual reason 'check device state on cloud sign-in' grows into a ticket.
Enrollment vs join: dsregcmd shows the identity state. A device can be Entra joined and still not MDM enrolled — check Intune (Devices > Windows) and the Company Portal for the management side.

Manual enrollment for a Windows PC runs from Settings > Accounts > Access work or school > Connect — add the work account without selecting a domain-join option for BYOD, or choose the join option when the work account should also join the device. There is no Intune enrollment PowerShell cmdlet; every admin center action (including enrollment) has a Microsoft Graph API equivalent, which is how you automate it.

FAQ

What is the difference between MDM registration and enrollment?

Registration is the identity step: the device (or the user's account) is registered or joined in Microsoft Entra ID. Enrollment is the management step: Intune installs the MDM certificate and starts enforcing policies. Microsoft's own glossary separates them — device registration is what happens when a hardware hash is associated with the Autopilot service, while enrolling a device means adding it to Intune. Registration in Entra is a required prerequisite for Intune management ('the process that enables device management for a device is called device enrollment').

Does enrolling a personal device let my company wipe it?

If the device is MDM enrolled, yes — Intune supports a full device wipe (factory reset) and retire (removes company data and management) on enrolled devices. If the user chooses MAM-only protection (no enrollment), the company can only do a selective wipe that removes corporate data from the managed apps, never personal apps or data. Apple User Enrollment keeps work data on a separate volume by design, which limits what a wipe touches.

How many devices can one user enroll?

A standard non-admin Microsoft Entra user can enroll 15 devices; a device enrollment manager (DEM) account can enroll and manage up to 1,000. You can tighten this with enrollment device limit restrictions, which accept a range of 1 to 15 devices per user. Limits do not apply to Windows enrollments that use shared device mode (co-managed, GPO, Entra joined, Autopilot, DEM) — for those, Microsoft points you to the hard device limit in Microsoft Entra ID.

When do I need Microsoft Entra ID P1 or P2?

Not for plain Intune: the compliance docs state that Intune compliance does not require Microsoft Entra ID. You need Entra ID P1 or P2 for Conditional Access, for Windows Autopilot, and for co-management (the prerequisites list Entra ID P1 or P2). Intune itself requires Intune licenses for the devices and users you manage.

IPv4 subnet calculator — break any CIDR block into network, range, broadcast and usable hosts.
IP range to CIDR — turn an arbitrary address range into its minimal covering CIDR blocks.
VLSM calculator — split a block into right-sized subnets by host requirements.