Assign User Does Not Lock the Device: What Autopilot AssignedUser Really Does

A new laptop is registered for Windows Autopilot. You open the Windows Autopilot devices blade, tick the row, and select Assign user. You pick the new starter. You type a friendly name. You save. The device now looks like it belongs to that person.

Then the courier delivers it to the wrong desk. Somebody else opens the box, connects to Wi-Fi, signs in with their own work account, and walks away with a fully provisioned corporate laptop. The Autopilot record still names the person you assigned. The Intune record names the person who actually signed in. Nothing failed, nothing alerted, and nothing was misconfigured.

The problem: an assignment that reads like a lock

The wording in the portal invites the wrong conclusion. The toolbar button says Assign user. The resulting property is labelled User. The blade even offers Unassign user from the row menu. Every one of those words implies ownership, and ownership implies exclusion.

It helps to separate two questions that admins tend to merge into one. The first question is what the assignment configures. The second question is what the assignment prevents. Microsoft answers the first question clearly and repeatedly. It answers the second question in exactly one place, and the answer is narrower than most people expect.

Here is what the assignment configures, quoted from the user-driven Microsoft Entra join tutorial: "If a Windows Autopilot device is assigned to a user, then any user policies and application installs assigned to that user is applied to the device during the Windows Autopilot process." The same sentence appears verbatim in the hybrid join tutorial and in both pre-provisioning tutorials.

Read that again. It is a statement about policy scope. It describes which configuration is pulled forward into the provisioning window. It says nothing at all about who is permitted to complete the out-of-box experience, or OOBE.

The practical consequence is that three separate records can name three different things after a deployment. The Autopilot device identity holds the user you assigned. The Intune managed device holds the user who actually enrolled. The Microsoft Entra device object holds an owner set during registration. Nothing in the admin center puts those three side by side, so a mismatch can sit in a tenant for years.

Why it happens: two strings on a cloud object

Every Autopilot device is represented in Microsoft Graph as a windowsAutopilotDeviceIdentity. Assigning a user is the assignUserToDevice action against that object. The action takes exactly two parameters, and both of them are plain strings.

Notice what is missing from that list. There is no boolean like an enforce-assigned-user flag. There is no restriction object, no allowed-users collection, no scope. The entire feature surface is two strings, plus whatever behaviour the service chooses to attach to them.

Where enforcement is documented, and where it is not

Microsoft does document username enforcement in one specific case. It appears on the Windows Autopilot known issues page, under a heading that names the exception rather than the rule: "A non-assigned user can sign in when using user-driven mode with Active Directory Federation Services (ADFS)."

The body of that entry is the most important paragraph on this whole topic. Microsoft states that in a user-driven Microsoft Entra joined environment, if the assigned user is a cloud-native Microsoft Entra account, the username is enforced and the user is only asked for their password, with no way to sign in with another user ID. It then states that when ADFS is used, the username assignment is not enforced, and a different user than the one assigned can sign in on the device.

So the honest answer is not "it never restricts anything." The honest answer is more specific, and more awkward. Enforcement is documented for one join type, one deployment mode, and one account type. Microsoft describes it inside a known-issues article, in the course of explaining the case where it breaks. That reads as a behaviour of the sign-in experience, not a stated security guarantee. Microsoft nowhere describes it as an authorization boundary.

Equally important is what Microsoft does not say. There is no equivalent enforcement statement for Microsoft Entra hybrid join, even though the hybrid tutorial offers the same Assign user step with identical wording. There is no enforcement statement for the user flow of a pre-provisioned deployment. And self-deploying mode does not use an assigned user at all. Microsoft states the device either remains at the sign-on screen, "where any member of the organization can sign in by specifying their Microsoft Entra credentials," or automatically signs in as a local account.

Windows Autopilot device preparation, the newer profile experience, sidesteps the concept entirely. It requires that the device is not registered as an Autopilot device, and drives configuration through enrollment time grouping rather than a per-device user assignment.

The validation gap on import

The assignment can also be set at import time, by adding an Assigned User column after the Hardware Hash column in the registration file of comma-separated values, or CSV. The documented header format is a single line.

Microsoft is unusually direct about how little checking happens here. The documentation states that during upload of a CSV file, the only validation Microsoft performs on the Assigned User column is to check that the domain name is valid. It goes on to say that Microsoft does not perform individual UPN validation to ensure that an existing or correct user is being assigned.

That warning is the clearest evidence of what the feature really is. A field that can lock everybody out when it is wrong, but cannot reliably lock the wrong person out when it is right, is a pre-fill mechanism with a sharp edge. It is not an access control.

Nothing lands on the device

It also helps to see where the assignment does not appear. Microsoft documents the on-device registry location that holds the Autopilot profile settings received from the deployment service. The assigned user is not one of the values there.

How to verify: read the assignment and the primary user side by side

Verification means reading two records and comparing them. Start with the assignment itself, in the Autopilot devices blade.

Selecting a device opens its property pane. Microsoft documents that the assigned user is listed under User and User friendly name. Now read the other half, on the enrolled device record.

This is where the two records diverge. Microsoft's table of how the primary user gets populated is explicit. For a Windows device enrolled through the Microsoft Entra join Autopilot out-of-box experience, the primary user assigned is the enrolling user, and it is assigned during enrollment. For Autopilot self-deploying mode, the primary user is None.

The assigned user is not in that table at all. The primary user comes from whoever authenticated, full stop.

Doing this by hand does not scale past a handful of devices, and the blade has a documented filtering bug. Microsoft's known issues page says that viewing Autopilot devices in Intune "might not work as expected if attempting to filter results," and recommends using the Graph API to properly query and filter devices instead. So go to Graph.

What the event log will and will not tell you

Autopilot writes its own event log, and it is worth knowing what is in there before you go hunting for an assigned-user event. Microsoft documents the channel as follows.

Read down that list and note the pattern. Events 809 and 815 concern the assigned profile. Not one documented event ID reports the assigned user, and none records a comparison between the assigned user and whoever signed in. There is no client-side audit trail for this, which is exactly why the audit has to happen in Graph.

The fix: use the assignment for what it is, and restrict elsewhere

There are two halves to this. Set the assignment correctly, because it does real work on policy scope. Then stop relying on it for anything security related.

Setting and clearing the assignment

Microsoft's documented click path for assigning a user runs as follows.

1. Sign in to the Microsoft Intune admin center.
2. In the Home screen, select Devices in the left hand pane.
3. In Devices | Overview, under By platform, select Windows.
4. In Windows | Windows devices, under Device onboarding, select Enrollment.
5. In Windows | Windows enrollment, under Windows Autopilot, select Devices.
6. Locate the device, tick the box to its left, then select Assign user in the toolbar.
7. In the Select user window, find and select the user, then select Select. Microsoft notes the selected user must be licensed to use Intune.
8. In the property pane, check the User friendly name value, adjust it if required, then select Save.

Clearing it happens from the row menu rather than the toolbar, which is easy to miss.

1. In the Windows Autopilot devices screen, select the device by ticking its checkbox.
2. Select the extended menu icon at the far right of the device row.
3. Select Unassign user. Microsoft notes this option is greyed out when there is no assignment to remove.
4. Confirm the warning dialog with OK.

Correcting the primary user is a separate action against a separate object.

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

Microsoft documents the constraints on that last one. It is supported on Windows devices only, and only on devices that are Microsoft Entra joined or Microsoft Entra hybrid joined, not on devices that are only Microsoft Entra registered. The user must be licensed for Intune. It requires the Managed devices/Set primary user permission. It does not change local group membership, and it does not change the "Enrolled by" user.

What actually restricts who can set a device up

If the requirement is genuinely "only this person may provision this device," then the assigned user is the wrong control. These are the documented mechanisms that do constrain the deployment.

Proof it worked: mismatches before and after

The companion script reads both collections and joins them. It resolves each Autopilot record to its Intune device by managedDeviceId first, then by serial number as a fallback, and classifies the result.

Treat a Mismatch as an inventory and allocation finding, not a security incident. It means the wrong person unboxed the device, and the assignment did not stop them because it was never designed to. The remediation is to correct the primary user, and to stop treating the assignment as an allocation guarantee.

The script fails loudly rather than quietly. If either Graph call errors, if a required scope was not granted, or if the Autopilot collection comes back empty, it aborts with exit code 1 instead of printing a summary. An empty result caused by a scoped-away read looks identical to a healthy tenant, and that is the one output an audit script must never produce.

References

Community deep dive

One closing thought on wording, because wording is what caused this. The button says Assign user, and assignment in most IT contexts implies exclusivity. In Autopilot it means what user device affinity meant in Configuration Manager: this is the person whose apps and policy we should bring along. Anyone who can authenticate to your tenant, join a device to Microsoft Entra ID, and enrol in Intune can still finish the job. If that set of people is larger than you are comfortable with, the answer lives in your Entra device settings and your enrollment restrictions, not in a text field on a device record.