Microsoft Intune: devices that set themselves up
Devices are the second half of every access decision. I set up Microsoft Intune so that a new device becomes managed without manual work and its compliance is a measurement rather than a claim.
Typical starting point
Inconsistently configured devices
Devices come from different sources with different states. Every notebook is set up by hand and ends up slightly different.
Compliance is a statement, not a measurement
Nobody knows for certain whether a device is encrypted and up to date, so Conditional Access cannot build on it.
Devices without an owner
Warehouse scanners or workshop tablets belong to the company, are used by changing people and should do exactly one job. User-based rules do not apply here.
What I implement
- Windows 11 with Entra join and automatic Intune enrollment
- Windows Autopilot: user-driven profile, standard account instead of local administrator, consistent device names
- macOS through the Company Portal, iOS and Android Enterprise
- Compliance policies and configuration profiles per platform
- Separate user and device groups, so that assignments apply reliably
- App deployment, including Win32 apps, and Managed Google Play
- Private devices through app protection policies (MAM) rather than full management
- Dedicated Android devices in kiosk mode with Managed Home Screen
What matters
The key question for any device is whether it has a user. With a company phone, an employee signs in, Conditional Access applies, and apps and policies can go to user or device groups. A dedicated device in a warehouse has no personal sign-in, user-based policies do not apply, and only device groups make sense. Protection there comes from compliance, lock mode and remote wipe.
With an Autopilot profile, a few settings matter: user-driven as the standard case in mid-sized companies, a pure cloud join, a standard account rather than local administrator, hidden account options, and a naming template so that nobody assigns device names by hand. I record such decisions with their reasons, so that they stay understandable later.
Approach
1. Understand
Which devices exist, who owns them, how do they enter the company today? Are there private devices, or devices with no fixed user?
2. Design
Group structure, platforms, compliance rules and a path from pilot to rollout. A pilot group first, not all devices at once.
3. Implement
Build enrollment, profiles, apps and compliance, and check them on real pilot devices until a new device finishes without rework.
4. Hand over
A runbook for enrollment, replacement and remote actions. After that, Conditional Access can build on device compliance.
What you get
- Working enrollment and compliance for the agreed platforms
- Documented group structure and configuration baseline
- Runbook for enrollment, replacement and remote actions
- Handover to your operations team
Backed by
Windows, macOS and Android Enterprise are documented in the lab: Entra join, an Autopilot profile, compliance and a dedicated Android device enrolled by QR code. All from my own test environments.
Common questions
Do all devices have to move at once?
No. New policies run for a pilot group first. Existing devices follow in waves, and only then is a Conditional Access rule for compliant devices worthwhile.
What about private devices?
That is what app protection policies are for: company data inside the apps is protected without managing the whole device.
Have you rolled out Autopilot in large environments?
No. My Intune experience comes from my own test tenants. The Autopilot profile is configured and documented there; a broad rollout for a client is still to come.