The Intune primary user is a single field on a device record, and it decides both more and less than most admins assume. It controls what the signed-in person sees and can do in Company Portal. It does not control which policies or apps reach the machine. Between those two facts sit the two most common tickets on the subject: a shared laptop nobody can retire, and a Change primary user button that is greyed out with no explanation on the page.
Intune stamps the value at enrolment time, which is why it tracks whoever completed the Intune enrollment status page rather than whoever is using the device today. Below is what the field governs, how each enrolment method sets it, why the change action disables itself, and the failure modes that follow a device from one owner to the next. Verified against Microsoft Learn on 27 August 2026.
What the Intune primary user actually controls
Microsoft’s own description is narrow and worth reading literally. The primary user maps a licensed Intune user to their devices in the Company Portal app, the Company Portal website, and the IT pro experiences in the admin center. That is the whole remit. It is a mapping for end-user experience and for troubleshooting views, not an authorisation boundary.
The clearest proof of that is what happens when the field is empty. Microsoft documents that a device with no primary user is treated as a Shared Device: Company Portal labels the tile as shared, apps can still be requested and installed, but uninstalling apps and the self-service actions, reset, rename and retire, are not available. Note the order of those clauses. App delivery continues on a device with no primary user at all. Self-service stops. If app assignment depended on the primary user, a shared device would install nothing.
So the practical rule is this: the primary user is the switch for end-user self-service. Policy and app targeting is decided by group assignment, entirely separately, in the same way that scope tags govern admin visibility rather than deployment. Two systems, one field each, routinely mistaken for one another.
How the primary user gets set, by enrolment method
Intune assigns the primary user automatically during or shortly after enrolment, and the enrolment method decides whether the device gets one at all. The table below is Microsoft’s, as published on 27 August 2026.
| Platform | Enrolment method | Primary user assigned | When |
|---|---|---|---|
| Windows | Add work or school (user driven) | Enrolling user | During enrolment |
| Windows | Modern app sign-in (user driven) | Enrolling user | During enrolment |
| Windows | Enroll in MDM only (user driven) | Enrolling user | During enrolment |
| Windows | Microsoft Entra join (OOBE) | Enrolling user | During enrolment |
| Windows | Microsoft Entra join (Autopilot OOBE) | Enrolling user | During enrolment |
| Windows | Microsoft Entra join (bulk enrolment token) | None | Not applicable |
| Windows | Microsoft Entra join (Autopilot self-deploying mode) | None | Not applicable |
| Windows | Microsoft Entra hybrid join with automatic enrolment GPO | First user to sign in to Windows | When first user signs in |
| Windows | Co-management | First user to sign in to Windows | When first user signs in |
| Cross-platform | User driven enrolment with the Company Portal app | Enrolling user | During enrolment |
| Cross-platform | Device Enrollment Manager | Enrolling DEM user | During enrolment |
| iOS/iPadOS, macOS | Apple automated device enrolment with user affinity | Enrolling user | During enrolment |
| iOS/iPadOS, macOS | Apple automated device enrolment without user affinity | None | Not applicable |
| Android | Corporate-owned, dedicated devices | None | Not applicable |
Two rows deserve more attention than they usually get. Microsoft Entra hybrid joined devices enrolled by Group Policy, and co-managed devices, take the first user who signs in to Windows. On a build bench that is the engineer. On a device reimaged for a replacement starter, it is whoever logged in first to check the image. Neither is the person who will actually use the machine, and neither event is announced anywhere.
The other is the Device Enrollment Manager account. A DEM account enrols the device and becomes its primary user. That is by design, and for a genuinely shared pool it is the correct outcome, but it means every device enrolled that way carries a service account in the field Company Portal reads.
One gap worth naming: Microsoft’s table does not list Autopilot device preparation as its own row as of 27 August 2026. It names Microsoft Entra join with Autopilot OOBE and Autopilot self-deploying mode, which are the classic profiles. If you have moved to Autopilot device preparation, confirm the behaviour on a test device rather than assuming one of the classic rows applies. I have not run device preparation in production, so I am not going to tell you which row it behaves like.
Where to find and change the Intune primary user
To read it: Microsoft Intune admin center, Devices, choose the device, and the primary user is listed on the Overview page.
To change it: Devices, All devices, choose a Windows device, Properties, Change primary user, select a user, then Select. Microsoft states the update can take up to 10 minutes to reflect across Intune and Microsoft Entra ID, so a portal still showing the old value two minutes later is not evidence of a failure.
The constraints on that action are the whole story behind the greyed-out button, and they are documented rather than mysterious:
- Windows devices only.
- Microsoft Entra joined and Microsoft Entra hybrid joined devices only, not Microsoft Entra registered.
- The target user must be licensed for Intune.
- The administrator needs the Managed devices/Set primary user permission.
- On iOS/iPadOS and Android, enrolment is required to assign a new primary user.
The failure modes
Change primary user is greyed out
This carries more Microsoft Q&A threads behind it than any other question on the subject, and in almost every case the cause is one of the five constraints above rather than a bug. Check the join type first, on the device Overview page: a Microsoft Entra registered device, typically a personal machine added with Add work or school rather than joined, will never offer the action. Check your own role second, because a delegated operator without Managed devices/Set primary user sees the control and cannot use it. Check the target user’s Intune licence third. Only then start suspecting the service.
The local Administrators group does not follow the primary user
Changing the primary user does not change local group membership, and Microsoft says so explicitly. On a Microsoft Entra joined device the user who performed the join is added to the local Administrators group at join time, and reassigning the device in Intune afterwards leaves that membership exactly where it was. The previous owner keeps local admin on a machine they no longer hold. The new owner does not gain it. If that matters in your estate, and it should, the fix is a separate policy targeting local group membership, not the primary user field.
Enrolled by is a different field and it does not move
Changing the primary user does not change Enrolled by either. The two sit near each other on the device Overview page and are routinely read as the same value. Enrolled by is history: it records who ran the enrolment. Primary user is current state. When you are working out why a device behaves as though it belongs to somebody else, read both, and treat the gap between them as a clue rather than a defect.
The shared device nobody can retire
A device with no primary user is a Shared Device, and Company Portal removes reset, rename and retire from it. That surprises the admin who cleared the field deliberately, to stop one person’s name being attached to a kiosk, and then finds the service desk cannot walk a user through a retire. The shared handling also needs Company Portal version 10.3.4651.0 or later, which is worth checking on any device still running the client version baked into an old image. Decide it deliberately: end-user self-service or shared, not both. When you are the one retiring the device, the ordering in wipe versus retire matters considerably more than who the primary user was.
The stale primary user after a device changes hands
Nothing in Intune reassigns the primary user when a laptop moves from one employee to another. The field stays on the leaver until a human changes it, and Company Portal carries on offering the device to an account that may already be disabled. Build the change into the joiner, mover and leaver process, because there is no automatic mechanism that will do it for you. If the device also stops reporting after the handover, that is a different problem and the sync diagnosis order applies instead.
What I would do differently
First, decide the shared-device question at enrolment rather than afterwards. The enrolment methods that produce no primary user, Autopilot self-deploying mode, bulk enrolment tokens, Apple automated device enrolment without user affinity, and Android corporate-owned dedicated devices, all get there cleanly and by design. Enrolling a device user-driven and clearing the field later reaches the same state with a worse audit trail and an extra manual step that somebody will forget.
Second, stop using this field as a reporting proxy for who owns a device. It is accurate on a user-driven Windows enrolment and unreliable nearly everywhere else: a service account on DEM-enrolled devices, the build engineer on hybrid joined devices, empty on shared ones, and stale on anything that has changed hands, unless the handover went through a remote Autopilot reset, which clears the field and the Entra device owner along with it. Keep ownership in the system where you can actually control it, and read the Intune primary user for the one thing it reliably decides, which is whether Company Portal self-service works for the person holding the machine.
I have not run this at fleet scale. My tenant is a lab with no enrolled devices, so the behaviour above comes from Microsoft’s documentation as it stands today and from the shape of the questions practitioners keep asking. Where the documentation is silent, as it is on Autopilot device preparation, I have said so rather than filled the gap with a guess.
Last verified: 27 August 2026.
