Enrollment is the moment a device goes from unmanaged to managed — and it is where your compliance evidence begins. This video walks through an end-to-end enrollment: a brand-new corporate laptop powering on for the first time, automatically enrolling into the MDM, joining the right device group, and receiving its first compliance policy. Watching the flow makes the abstract idea of "managed" concrete, and shows you exactly which artifacts an auditor can ask for.
No account needed
This is a conceptual walkthrough. You do not need an MDM tenant or a test device to follow along. The flow shown — automated enrollment, group assignment, policy application, compliance reporting — is the same across Intune, Jamf, Kandji, and Workspace ONE; only the console differs.
Invalid YouTube ID or URL: PLACEHOLDER_VIDEO_ID
The enrollment flow, step by step
1. Procurement registers the device. For corporate-owned hardware, the device serial number is added to Apple Business Manager (Apple), Windows Autopilot (Microsoft), or Android zero-touch before it reaches the employee. This is what enables zero-touch: the device is pre-claimed by your organization, so it knows where to enroll the moment it connects to the internet.
2. The device powers on and finds the MDM. During the out-of-box setup, the device contacts Apple/Microsoft/Google, learns it belongs to your organization, and is handed the address of your MDM server. No manual profile installation, no IT person touching the device.
3. Enrollment establishes management. The device installs the management profile and, for corporate hardware, becomes supervised/automated-enrolled — meaning management is non-removable and the full control surface is available. The MDM now has a record for this device: serial, model, OS version, assigned user.
4. Group assignment. The device lands in a device group based on rules (OS type, ownership, department, or the assigned user's identity-provider group). Group membership decides which profiles and policies it inherits — "Corporate macOS," "Engineering Windows," "BYOD iOS," and so on.
5. Policies and profiles apply. The MDM pushes the group's configuration: encryption enforcement, passcode policy, screen-lock timeout, Wi-Fi/VPN, certificates, the managed app catalog. The device applies each one and reports the result.
6. First compliance evaluation. The device is evaluated against the compliance definition (encrypted? passcode set? OS at minimum version? not jailbroken?). It now shows up in the compliance report as compliant or non-compliant — and that record, with its timestamp, is your earliest evidence that the control applied to this device.
User-initiated enrollment
Not every device is zero-touch. BYOD phones and contractor laptops typically use user-initiated enrollment: the user opens a company portal, signs in with their identity provider, and installs a management profile themselves. This grants a deliberately narrower control surface — usually app management and a "company data only" wipe — because the device is personally owned. The distinction matters for evidence: a user-enrolled BYOD device cannot be made to prove full-disk encryption the way a supervised corporate device can, so your control scope has to reflect that.
Reading enrollment as evidence
Every step above leaves a record, and several are directly useful in an audit:
- The enrollment record — who enrolled, which device, when, and which profiles applied. This is your "device is under management as of date X" proof.
- The applied-policy report — confirmation that each configuration profile reached the device and applied successfully.
- The enrollment-to-compliance timeline — how quickly a new device reaches a compliant state. A fleet that takes days to apply encryption to new laptops has a gap worth noting.
GRC Engineer's lens
Capture the enrolled-state screenshot and the applied-policy report for at least a sample of devices — these are exactly the artifacts that satisfy "how do you ensure new devices are configured securely before use?" The enrollment timeline is also a control in its own right: if a laptop can sit unmanaged for a week before policies land, that window is the finding. Strong programs make enrollment a prerequisite for access (via Conditional Access, covered in Module 3.3), so an un-enrolled device simply cannot reach company data.
What to carry forward
Enrollment is where management — and evidence — begins. Zero-touch enrollment (Apple Business Manager, Autopilot) gets corporate devices to a compliant state with no manual handling, while user-initiated enrollment covers BYOD with a narrower, privacy-respecting scope. In both cases, the enrollment and applied-policy records are early, reusable audit evidence.
Next, you will put this into practice: designing the actual compliance policies that get pushed to four different device types.