Who Owns the Device After Autopilot: Primary User, Device Affinity, and the Shared-Device Case Where Nobody Should

Twenty identical laptops go out to a warehouse floor. They are meant to be shared. Any shift worker picks one up, signs in, does a job, signs out. Nobody owns them.

Except one person does. Whoever completed the out-of-box experience on each device is now recorded in Microsoft Intune as that device's primary user. Their Company Portal claims the laptop. Their name appears on the helpdesk lookup. User-targeted apps flow to them and not to the nineteen other people who use the machine. No policy failed. No error was logged. Intune did exactly what Microsoft documents it will do.

The problem: one person owns a device meant for twenty

Start with the definition, because the word "primary" hides how much this field does. Microsoft describes a primary user as the user who is primarily associated with a specific Intune device. Microsoft then says that when a device enrolls in Intune, the signed-in user typically becomes the primary user.

That association has an older name too. Microsoft states that when a device is associated with a user, the association is known as Device Affinity. If you came from Configuration Manager, this is the same concept as user device affinity, moved to a cloud object.

The primary user is not cosmetic. Microsoft documents that the primary user property maps a licensed Intune user to their devices in the Company Portal app, the end-user website, and IT pro experiences such as troubleshooting pages that map user accounts to devices by using the primary user.

Now put the wrong name in that field on a shared machine. Microsoft documents the exact consequence. The Company Portal app expects that the account signed in to Company Portal is the primary user of that device. When somebody else is the primary user, Company Portal shows this message:

Nineteen out of twenty shift workers will see that string. They will read "already assigned to someone" and open a ticket. Your helpdesk will then spend its afternoon explaining a field nobody set on purpose.

The reverse case matters just as much. Microsoft documents that if an Intune device has no primary user assigned, the Company Portal app detects it as a shared device, shows a "shared" label on the device tile, and removes self-service actions. Specifically, Microsoft says uninstalling apps and self-service actions such as reset, rename and retire are not available on a shared device. Microsoft adds that Company Portal version 10.3.4651.0 or later is required to use this feature.

So a single-user laptop that somehow ended up with no primary user quietly loses self-service. And Microsoft documents one more dependency in the Autopilot self-deploying article: user self-service BitLocker recovery key retrieval, and using Company Portal to install software assigned to users, both rely on a primary user being set.

Why it happens: enrollment sets affinity, and nothing takes it back

Primary user is assigned by the enrollment method, and the enrollment method also decides when it is assigned. Microsoft publishes the full matrix. These are the Windows and cross-platform rows that matter to an Autopilot fleet.

Read the two rows that solve most of this. Autopilot user-driven Microsoft Entra join sets the enrolling user. Autopilot self-deploying mode sets nobody. Microsoft is explicit in the self-deploying article: Intune does not automatically configure a primary user when using self-deploying mode in Windows Autopilot to provision a Windows device.

That is the whole design. If you deploy a shared device through user-driven mode, you have told Intune that the person at the keyboard during OOBE is the owner. Intune believes you.

Primary user, enrolled by, and device owner are three different things

This is where most audits go wrong. Four fields look like they answer "who owns this device", and they answer four different questions.

What Graph documents as read-only, and what it does not

If you plan to audit this at fleet scale you need to know which properties you can only read. On the Graph managedDevice resource, Microsoft documents the following as read-only: id, userId, userPrincipalName, userDisplayName, deviceName, enrolledDateTime, deviceEnrollmentType, deviceRegistrationState, azureADDeviceId and enrollmentProfileName.

The managedDeviceOwnerType property is the interesting exception. It appears in the documented Update managedDevice request body without the read-only marker that almost every neighbouring property carries. So corporate-versus-personal ownership is patchable. The identity of the primary user is not.

There is also a navigation property. Microsoft documents the users relationship on managedDevice with the description "The primary users associated with the managed device." That relationship is how the primary user is actually represented, which is why the field is not a simple writable string.

Two more properties are worth knowing, and both are documented on the beta managedDevice resource rather than version 1.0. Microsoft documents usersLoggedOn as a loggedOnUser collection that "Indicates the last logged on users of a device", and marks it read-only. The loggedOnUser complex type carries userId and lastLogOnDateTime. Note what is absent: there is no user principal name in that collection, only a directory object id. Microsoft also documents autopilotEnrolled on beta as a read-only boolean that reports whether the managed device was enrolled via Autopilot.

How to verify: read primary user, enrolled by, and logged-on users

Start in the console, because it is the fastest single-device answer. Microsoft documents that the Overview page lists the primary user.

Here is what that card looks like when a shared machine has picked up an owner it should never have had.

Two fields already tell the story. The device was provisioned with a user-driven profile, so a primary user was set during enrollment, exactly as documented. Nobody made a mistake in the console. The mistake was choosing user-driven mode for a shared device.

For a fleet, go to Graph. Every call below is a GET.

You can also confirm the device-side view of enrollment. Microsoft documents the enrollment registry location while troubleshooting automatic enrollment, and notes that a device enrolled into any mobile device management service writes enrollment information there.

Event log surface

There is no Microsoft-documented event ID that fires when a primary user is assigned or changed. What Microsoft does document is the enrollment event surface, which is where the enrolling identity gets established. Channel, stated once:

The scheduled task that drives Group Policy based automatic enrollment logs in a second channel:

The fix: correct affinity per enrollment mode, and remove it where nobody should own the device

Correct a single device

Microsoft documents the change action, and the constraint that comes with it. For Windows devices that are Microsoft Entra joined or Microsoft Entra hybrid joined, the primary user of a device can be updated.

1. Sign in to the Microsoft Intune admin center.
2. Choose Devices, then All devices, then choose a Windows device.
3. Choose Properties, then Change primary user.
4. Select a new user and choose Select.

Microsoft publishes a "what you need to know" list against that action. Read all of it before you script anything around it.

• Supported on Windows devices only. Enrollment is required to assign a new primary user on iOS, iPadOS and Android.
• Supported on Microsoft Entra joined and Microsoft Entra hybrid joined devices only. Not supported on devices that are Microsoft Entra registered only.
• To be assigned as the primary user, the user must be licensed for Intune.
• Updates across Intune and Microsoft Entra ID can take up to 10 minutes to be reflected.
• Changing the primary user does not change local group membership, such as the local Administrators group.
• Changing the primary user does not change the "Enrolled by" user in Intune.
• To change or remove the primary user of a device, you need the Managed devices/Set primary user permission.

That last bullet is the one people miss when the button is greyed out. The permission exists as a distinct right in Intune role-based access control. Microsoft's built-in roles reference shows Managed devices | Set primary user in Help Desk Operator, Endpoint Security Manager and School Administrator. A Read Only Operator has Managed devices | Read and cannot set it.

Removing the primary user is the same action and the same permission. Microsoft's wording is "to change or remove the Primary user of a device". Removal is how you turn an accidentally-owned device back into a shared device, because Microsoft defines a device with no primary user as a Shared Device.

Configure the device for genuine sharing

Clearing the primary user fixes the record. It does not change how Windows behaves at the sign-in screen. For that you want shared PC mode.

1. Sign in to the Microsoft Intune admin center.
2. Select Devices, then Manage devices, then Configuration, then Create, then New policy.
3. Set Platform to Windows 10 and later.
4. Set Profile type to Templates, then Shared multi-user device. Select Create.
5. Name the profile, then work through Configuration settings.
6. In Assignments, select the device group that receives the profile. Microsoft explicitly notes: be sure to assign the profile to device groups in your organization.
7. Review and create.

That template writes the SharedPC configuration service provider. Here is the whole node set, so you can see what the profile is actually doing. Parent node, stated once:

Microsoft is precise about ordering, and it is easy to get wrong. For almost every node above, the documentation says: if used, this value must be set before the action on the EnableSharedPCMode node is taken. The Intune template handles that ordering for you. A hand-built custom OMA-URI profile does not.

Deploy shared devices in the right mode next time

The durable fix sits upstream of all of this. If a device should have no owner, provision it in a mode that assigns no owner. Microsoft states that self-deploying mode allows deployment of a Windows device as a kiosk, digital signage device, or a shared device, and that no primary user is configured.

Three documented constraints decide whether you can use it.

• Self-deploying mode is supported for Microsoft Entra join only. Microsoft states it is not supported for Microsoft Entra hybrid join devices.
• It uses the device's Trusted Platform Module 2.0 hardware to authenticate the device, and devices must also support TPM device attestation. Microsoft states that a self-deploying attempt on a device without TPM 2.0 support, or on a virtual machine, fails when verifying the device with an 0x800705B4 timeout error, and that this includes Hyper-V virtual TPMs.
• A device cannot automatically re-enroll through Autopilot after an initial self-deploying deployment. Microsoft's documented remedy is to delete the device record in the Intune admin center.

Microsoft also names the trade-off directly. Some Intune capabilities rely on a primary user being set, including user self-service BitLocker recovery key retrieval and using Company Portal to install software assigned to users. Microsoft notes that a licensed user signing in to a self-deployed device is still entitled to their own features, such as Conditional Access. If you need any of the primary-user-dependent capabilities, Microsoft says a primary user can be set manually after provisioning.

Proof it worked: the affinity report comes back clean

The companion script reads three signals per device and reports only disagreements. It is read-only, GET only, and it redacts identifiers by default. The output below is illustrative, produced against placeholder values rather than a live tenant.

Three numbers tell you whether the fleet is healthy. The NoPrimaryUser count should roughly match your shared and kiosk estate. The AffinityMismatch count should be small and should map to real desk moves. The SharedFlagWithOwner count should be zero, because a device Windows reports as shared should not carry a named owner.

That shared flag is worth trusting because Microsoft documents it on both sides. On the beta managedDevice resource it is hardwareInformation.isSharedDevice. In the admin center Hardware page it appears as Shared device, defined as: if Yes, the device is shared by more than one user. Microsoft lists that field for Windows and iOS.

One operational note before you script corrections. Microsoft documents the Change primary user action in the admin center, and documents the permission it needs. I could not find a Microsoft-official Intune Graph reference page for a write action that sets the primary user, and Microsoft documents userId and userPrincipalName as read-only. Peter van der Woude published the beta reference form the community uses. Treat any bulk-correction script as unsupported until Microsoft documents it, keep the audit read-only, and drive the change through the documented action.

References

Microsoft official

Community deep dive

The lesson is not that Intune got something wrong. Intune recorded whoever finished setup, which is documented behaviour and usually the right answer. The lesson is that device ownership is decided at provisioning time, by which Autopilot mode you chose. A shared device provisioned through a user-driven profile will always come out with an owner. Fix the profile, and the audit stays clean without anybody clicking Change primary user again.