Four ways a device gets into Autopilot, and why they behave differently forever

Open the Windows Autopilot devices list in any tenant that has been running for more than a year. You will see rows that look identical. Same columns, same profile status, same serial number format. They are not identical. Some of those devices were registered by the manufacturer before they were boxed. Some were registered by a reseller in Partner Center. Some were imported from a comma-separated values (CSV) file by an administrator on a Tuesday afternoon. Some were pulled in silently by a deployment profile setting nobody remembers enabling.

Those four origins behave differently for the rest of the device's life. They differ in who is allowed to deregister the device, in whether the Microsoft Entra ID object survives deregistration, in what happens when the motherboard is replaced, and in whether a group tag could be set at the source at all. Worse, the Autopilot device record does not tell you which origin a device came from. This post explains each path, what each one stamps on the record, and how to run a mixed fleet without guessing.

The problem: one device list, four kinds of device

The symptom is always an inconsistency the admin cannot explain. A laptop goes for a motherboard swap. The service desk deregisters it, the repair centre returns it, and it never picks up an Autopilot profile again. A batch of machines arrives with a group tag already set, and the next batch from the same supplier arrives with nothing. A device is deleted from Autopilot and vanishes from Microsoft Entra ID as well. The next device is deleted from Autopilot and the Entra object stubbornly remains.

None of that is random. Each behaviour follows from how the device got into the service in the first place. Microsoft documents the registration methods separately, and the differences sit in the fine print of each article rather than in one comparison table. Here are the four paths as Microsoft describes them.

That is the blade where all four kinds of device land, indistinguishable from each other. The table below is the comparison Microsoft's documentation implies but never prints in one place.

Two details in that table deserve emphasis. First, only the manual CSV path lets you set a group tag at the moment of registration. Every other path produces an untagged record that somebody has to tag afterwards. Second, only the manual path is restricted to the 4K hardware hash. Microsoft states plainly that device owners can only register their devices with a hardware hash, and that the PKID and tuple methods are available through OEMs or CSP partners.

Why it happens: registration is a database write, not a device attribute

The root cause is architectural, and once you see it the inconsistencies stop being surprising. Autopilot registration is not something stored on the device. It is a row in a service Microsoft runs. The OEM registration article is unusually direct about this. Microsoft writes that the service "provides the backend database that associates hardware hashes with customer tenants", and that when an OEM registers devices for a customer "they're writing that data to this database and not directly to the customer's tenant". It adds that no permissions to the customer's tenant are granted or required for that to work.

That single sentence explains most of the downstream behaviour. Your tenant is not the system of record for Autopilot registration. Your tenant holds a projection of it. Successful registration, per Microsoft's overview, requires two things to complete. The hardware hash is captured and uploaded, and the device is associated to an Azure tenant ID. Different actors are allowed to write different parts of that row, and they write it from different places.

Consequence one: the entity that registered it owns the deregistration

This is the rule that breaks repair workflows. Microsoft's motherboard replacement guidance states it explicitly: "Before the device arrives at the repair facility, the entity that registered the device must deregister it." It then splits the instruction in two. If the IT administrator registered the device, they deregister it from Intune or the Microsoft 365 admin center, "because devices registered in Intune don't show up in Microsoft Partner Center (MPC)". If the OEM or CSP partner registered it, they deregister it from Partner Center, "which also removes it from the customer IT Admin's Intune account".

Read that asymmetry again. A partner deleting a device in Partner Center reaches into your Intune view and removes the row. You deleting a device in Intune does not put it back in the partner's list. Microsoft says so directly. For a partner to register a device in Partner Center, the device first has to be deregistered by the customer. The Partner Center documentation says the same thing from the other side, noting that a partner "can't manage devices your customer uploaded to Microsoft Store for Business or the Microsoft Intune Portal".

Consequence two: partner deregistration is narrower than it looks

Deregistering in Partner Center only removes the Autopilot registration. Microsoft lists what it does not do. It does not unenroll the device from the mobile device management (MDM) solution such as Intune. It does not disjoin the device from Microsoft Entra ID. Only the customer can do those two things. So a partner-initiated deregistration on an already-deployed device leaves you holding an enrolled, joined, unregistered machine.

There is a further wrinkle for OEMs with the Direct API. Microsoft documents that if the customer granted consent through the automated process, the OEM can use the API to deregister devices it did not register itself. That deregistration still only removes the device from the Autopilot program. It leaves Intune and Entra ID untouched.

Consequence three: the Entra object outcome depends on enrollment, not on path

This is the behaviour most often mistaken for a difference between registration paths. It is not. Microsoft documents it as a function of the device's join and enrollment state. For devices that are not currently enrolled in MDM, removing the Autopilot registration "can also result in the associated Microsoft Entra device object being removed". For devices that are or were enrolled in MDM, removing the registration "doesn't automatically delete the Microsoft Entra device object", and the device can remain in Entra ID while no longer being registered.

Because automatic registration only ever applies to devices already enrolled in MDM, every device from that path falls into the second category by definition. Deregistering it will leave an Entra object behind. A never-deployed OEM-registered device sitting in a stockroom falls into the first category.

Consequence four: automatic registration is a one-way door

The fourth path generates the most confused tickets, because it is a checkbox rather than an action. In a Windows Autopilot deployment profile, setting Convert all targeted devices to Autopilot to Yes registers every corporate-owned, non-Autopilot device in the assigned groups. Microsoft's documented behaviour is worth quoting closely. Personally owned devices are not registered. Allow 48 hours for the registration to be processed. When the device is unenrolled and reset, Autopilot enrolls it again.

Then the important sentence: "After a device is registered in this way, disabling this setting or removing the profile assignment won't remove the device from the Windows Autopilot deployment service." The device must instead be removed directly. Turning the setting off does nothing retroactive. It only stops future conversions.

Microsoft also notes what the setting does not do. It does not convert an existing Microsoft Entra hybrid joined device in the assigned groups into a Microsoft Entra joined device. It only registers the devices for the Autopilot service. Admins who expected a join-type migration get a registration and nothing else.

How to verify: what Graph exposes, and what it does not

Now the part most tooling gets wrong. There is no provenance property. I checked both API versions of the resource, and neither exposes a registration source, a registering actor, or even a registration timestamp.

The v1.0 windowsAutopilotDeviceIdentity resource has exactly these properties: id, groupTag, purchaseOrderIdentifier, serialNumber, productKey, manufacturer, model, enrollmentState, lastContactedDateTime, addressableUserName, userPrincipalName, resourceName, skuNumber, systemFamily, azureActiveDirectoryDeviceId, managedDeviceId and displayName. The resource has no relationships in v1.0.

The beta version adds profile and remediation state, not provenance. It adds deploymentProfileAssignmentStatus, deploymentProfileAssignmentDetailedStatus, deploymentProfileAssignedDateTime, azureAdDeviceId, three Surface Hub device account fields, remediationState, remediationStateLastModifiedDateTime and userlessEnrollmentStatus. None of those names the actor who created the record.

Confirm it yourself with a single read-only call. The scope documented for the list operation is DeviceManagementServiceConfig.Read.All, which is the least privileged of the two options Microsoft lists.

The endpoint sits at a long path, so here it is on its own line for copying.

What is inferable, and how strong each signal is

Provenance is not readable, but it is partly inferable. The trick is knowing exactly how weak each signal is. Two of them come from documented asymmetries in what each path is allowed to submit.

That last row is the only genuine provenance test available, and it lives outside your tenant. If a device appears in the partner's Partner Center customer device list, the partner registered it. If it does not, somebody in your organisation did.

There is no registry key and no event log channel that records how a device was registered, so this post has no registry reference table and no Event ID catalog. That absence is part of the answer rather than a gap in the write-up. Registration state lives in the Microsoft-run service, so there is nothing local to read. The device-side artefacts you can inspect relate to the profile downloaded during the out-of-box experience, not to who created the registration record.

Confirming a device can still be identified after a hardware change

Hardware repair is where provenance stops being trivia. Microsoft's guidance is that the hardware hash changes every time it is generated, and that the service tolerates changes such as a new hard drive. Large changes such as a motherboard replacement will not match, so a new hash must be generated and uploaded. The recommended sequence is deregister, replace, capture a new 4K hardware hash, reregister, reset, and return.

The repair table in Microsoft's guidance is worth reading in full before you write a runbook. Three entries matter most for a mixed fleet.

The fix: build the provenance register Microsoft does not give you

You cannot make the service report provenance. You can make provenance a property of your process instead of a property you hope to query. Five steps, in order.

Step 1: pick one registration path per procurement channel and write it down

This is the whole fix in one sentence. Decide, per supplier, who registers. Record it in the purchase order and in your asset system at the moment of purchase, because that is the last moment the answer is certain. Microsoft's preference is clear. It recommends registering through Intune with a 4K hardware hash only for testing or other limited scenarios, and says that in most cases you should use Partner Center instead. Its stated reasons are the availability of free Intune accounts that lack robust vetting, and the fact that 4K hardware hashes contain sensitive information only device owners should maintain.

Step 2: stop the automatic path unless you mean it

Audit every deployment profile for the conversion setting before it audits you.

1. Sign in to the Microsoft Intune admin center.
2. On the Home screen, select Devices in the left pane.
3. Under By platform, select Windows.
4. Under Device onboarding, select Enrollment.
5. Under Windows Autopilot, select Deployment Profiles.
6. Open each profile, select Properties, and check the Convert all targeted devices to Autopilot value on the Basics page.
7. Review the Assignments page for every profile where it is set to Yes. Those assigned groups are the set of devices being registered.

Remember what turning it off achieves. It stops future conversions only. Anything already converted stays registered until you deregister it explicitly.

Step 3: tag at source where you can, and immediately after import where you cannot

Only the manual CSV path accepts a group tag at registration. The documented header and row format is exact, and the surrounding rules are unforgiving.

Microsoft's rules for that file are strict. Extra columns are not allowed. Quotation marks are not allowed. Only ANSI-format text files are allowed, and headers are case-sensitive. Use a plain-text editor such as Notepad, because editing and saving in Microsoft Excel does not produce a usable file. Up to 500 devices can be registered per CSV upload through the portal.

For the three paths that cannot tag at source, tag straight after the record appears. Microsoft documents that device name, group tag and username can all be edited after upload.

1. Sign in to the Microsoft Intune admin center.
2. Go to Devices, then under By platform select Windows.
3. Under Device onboarding, select Enrollment.
4. Under Windows Autopilot, select Devices.
5. Select the device, then edit Group tag in the pane on the right.
6. Select Save, then select Sync in the toolbar.

The reason to care is dynamic group membership. Intune's group tag field maps to the OrderID attribute on Microsoft Entra devices, and the documented dynamic rule is an exact match against that prefixed value. An untagged device matches nothing.

Two sibling rules are documented alongside it and are useful for a mixed fleet. A rule matching (device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]")) selects every Autopilot-registered device. A rule matching [PurchaseOrderId] selects devices from a specific purchase order, which is exactly the attribute the upstream paths populate and the manual path cannot.

Step 4: write two deregistration runbooks, not one

Split the runbook by who registered the device, because Microsoft's rule is that the registering entity deregisters. For an admin-registered or auto-converted device, the order matters. Delete from Intune first, then unassign the user if the option is available, then delete from Autopilot, then sync.

That path is the Microsoft 365 admin center alternative, where the action is Delete device. For a partner-registered device, raise it with the partner and let them delete it in Partner Center, then complete the Intune and Entra ID cleanup on your side. Their deletion removes the Autopilot registration and the Intune-visible row. It does not unenroll or disjoin anything.

Step 5: audit what you actually have

The companion script reports the documented facts and separates them from the inferences, so nobody downstream mistakes a hint for a source. It reads with Invoke-MgGraphRequest -Method GET only, requests DeviceManagementServiceConfig.Read.All, and aborts with a non-zero exit code rather than printing an empty list after a failed query.

A profile status of Fix pending means Autopilot is still attempting to register the device. Microsoft's guidance is that if it stays there for an extended period without reaching Assigned, or switches to Attention required, you should deregister the device manually and reregister it.

Proof it worked: a fleet you can explain

The output below is illustrative, not a real tenant run, and the serial numbers are redacted placeholders. It shows the shape of the answer. Facts and inferences are kept apart, and the tool states plainly that the source is not readable.

What good looks like after this work is not a new column. It is four things being true at once. Every Autopilot device carries a group tag, so no device falls out of every dynamic group. Every procurement channel has a named registering party recorded outside the Autopilot service. The conversion setting is deliberately set on a scoped profile rather than inherited from a profile assigned to all devices. And the repair runbook asks who registered the device before it asks anything else.

The honest summary of the whole topic is short. Autopilot has one device list and four ways in, those ways in behave differently forever, and the service will not tell you which one you are looking at. Record it yourself at purchase time, or accept that you are inferring it for the life of the asset.

References

• Windows Autopilot registration overview — the four registration paths, the deregistration procedure, and what happens to the Microsoft Entra device object afterwards.
• Windows Autopilot OEM registration process — the service data statement that OEMs write to the Autopilot database rather than your tenant.
• Reseller, distributor, or partner registration of Windows Autopilot devices — CSP authorization and the PKID recommendation.
• Manual registration of devices for Windows Autopilot — the platform capability table with per-portal limits and accepted device IDs.
• Manually register devices with Windows Autopilot — CSV format, the 500-device limit, hash collection methods and registration error codes.
• Automatic registration of existing devices — the requirements for the automatic path.
• Configure Windows Autopilot profiles — the full documented behaviour of Convert all targeted devices to Autopilot.
• Create device groups for Windows Autopilot — group tag to OrderID mapping and the dynamic membership rule syntax.
• Windows Autopilot motherboard replacement — the rule that the registering entity must deregister, plus the per-scenario support table.
• Windows Autopilot customer consent — OEM and CSP authorization, and OEM permission revocation.
• Windows Autopilot FAQ — the six registration channels and the hardware hash invalidation guidance.
• windowsAutopilotDeviceIdentity resource type — the complete v1.0 and beta property lists, with no provenance field in either.
• List windowsAutopilotDeviceIdentities — the endpoint and the least-privilege read scope.
• Use Windows Autopilot profiles on new devices (Partner Center) — the partner CSV columns and the limits on managing customer-uploaded devices.

Community deep-dives, both fetched and confirmed on topic: