Multi-client rollout of nearly 650 corporate Windows devices via Microsoft Intune and covering the full identity-driven device lifecycle: initial deployment and user assignment, ongoing joiners, movers and leavers processes, cross-site device reassignment, and secure decommissioning.
Background
Clients required fully managed Windows devices for both new employees and their wider user base. Each device; whether newly deployed or repurposed was provisioned and assigned to an individual user’s Microsoft account in Entra ID before user onboarding and device distribution. This ensured that the correct applications, configuration profiles, security policies, and compliance settings were automatically applied based on the user’s role and requirements, enabling a consistent and secure experience from first sign-in.
Working as part of a 3–4 technician team, I took ownership of key areas within the identity-driven device lifecycle, including hardware hash collection, Intune device registration, configuration and compliance policy design, and application deployment. I also played a central role in managing the joiners, movers, and leavers process—reassigning devices as users changed roles or locations, and securely decommissioning devices when users left the organisation.
Key differentiator: Every device was assigned to a specific user’s Microsoft account in Entra ID. Autopilot pre-configured the out-of-box experience so that when the user signed in for the first time, they automatically received a fully configured, policy-compliant device. This same identity-driven approach was used throughout the device lifecycle. When a user changed roles or left the organization, their access was revoked, and the device was either reassigned to another user or securely wiped.
Architecture
How hardware, Intune, Entra ID, and end users connect across the Autopilot deployment flow.
How it was done
How the team executed the deployment from unboxed hardware to a user-ready, fully managed device.
The team would ensure hardware hashes were either provided by the vendor or collected via a pre-configured< strong>Autopilot hardware hash collection executable to record each device's unique hardware identity. The hardware hash, serial number, and product ID would be stored into a CSV file which would be uploaded directly into Intune to register the devices in the Autopilot program.
Get-WindowsAutoPilotInfo · CSV upload to IntuneOnce registered, each device would adopt the Autopilot deployment profile configured for user-driven mode. Devices were then individually assigned to their respective user's Microsoft Entra ID account, once booted Autopilot pre-populated the sign-in experience for that specific user. No generic setup, no shared credentials.
User-driven Autopilot profile · Entra ID user assignmentConfiguration policies were created in Intune covering device settings, Windows Update rings, BitLocker encryption, security baselines, and desktop experience. These were assigned to device groups so they applied automatically during the Enrollment Status Page (ESP) phase before the user reached the desktop.
Configuration profiles · Security baseline · BitLocker · Update ringsCompliance policies were defined to enforce minimum security standards; OS version requirements, BitLocker status, and antivirus state. Devices that didn't meet requirements were flagged as non-compliant and blocked from accessing company resources via Conditional Access until remediated.
Compliance policies · Conditional Access integrationRequired applications were deployed as Required assignments to device or user groups, installing automatically during or after the ESP phase. This included Microsoft 365 and line-of-business apps. Optional apps were made available through the Company Portal.
Required app assignments · Company Portal · Line-of-business appsDevices were handed to end users with the zero touch setup complete. All users had to do was sign-in, chsange their password, and their ready to take ownership.
Zero-touch delivery · Enrollment Status Page · OOBEIdentity & Access Management
Alongside initial deployment, this engagement included ongoing identity-driven device lifecycle management across multiple clients and sites. Because every device was tied to a specific user account in Entra ID, any change to that user's status had a direct, managed impact on their device.
When a new staff member joined a client at any site, a device from that site's allocated pool was registered in Intune via the Autopilot hardware hash collected during the original deployment run. The device was assigned directly to the new user's Entra ID account before they arrived — meaning on first boot, Autopilot recognised the device, applied the correct deployment profile for that client's tenant, and walked the user through a pre-populated sign-in flow.
Movers were the most varied scenario across this engagement. Staff moved between roles within the same site or transferred between different client sites. Each situation required a different combination of Intune and Entra ID actions depending on whether the device moved with the user or stayed at the site.
User moved to a different team or department at the same site. Their Entra ID account was moved to the appropriate group; updated app assignments and configuration policies pushed automatically to the device via Intune without any re-enrollment or physical access needed.
User relocated to another site within the organisation. If the device travelled with them, the device group assignment in Intune was updated to the destination site, triggering the correct site-specific policies. If the device stayed behind, it was Autopilot-reset and reassigned to a new joiner at that site, or added to a holding group pending the next deployment cycle.
When a user left a client, the offboarding process ran in two parallel tracks: identity (Entra ID account) and device (Intune). Because the two were linked, acting on the account side immediately affected what the device could access, even before the physical device was returned.
Why this is IAM work: A device assigned to a user in Entra ID carries that user's identity and access rights. Managing what happens to the device at each lifecycle stage: who it's assigned to, what policies it carries, whether it can access resources is a direct extension of identity governance. The joiners/movers/leavers process here wasn't handled separately from endpoint management: it was the same operation, executed through the same tooling, on the same identity plane.
Lifecycle flow
How a single device moves through states across sites and user roles, from first enrollment to decommission or reassignment.
Policy framework
The policy framework applied to every device across all sites and clients.
Collaboration
A coordinated 3 to 4 person effort; responsibilities split across hardware hash conolidation, Intune configuration, policy management, and device provisioning before handoff.
All Technicians of the team get the proper permissions to perform their roles in the project.
Results
The process was documented and repeatable enough to run at a large scale per client site on a regular cadence, with consistent policy application, zero-touch delivery, and a full lifecycle management capability built in from day one.
Stack