The ZTDID: The One Attribute That Proves a Device Is Really Autopilot-Registered

Every device that Windows Autopilot knows about carries a marker. It is not the serial number. It is not the group tag. It is a value called the ZTDID, and it lives on an object in Microsoft Entra ID that you never created by hand. When that marker is present, your dynamic device groups fill up and your Autopilot deployment profiles land where you expect. When it is absent, the device still enrols. It still appears in Intune. It still reports as compliant. And it quietly behaves like a machine somebody built manually, because as far as group membership is concerned, that is exactly what it is.

The problem: a device that enrolled cleanly and still behaves hand-built

The ticket usually reads like a contradiction. A laptop was registered with Autopilot months ago. It shows up in the Autopilot devices list with the right serial number. It shows up in Intune as an enrolled, compliant, Microsoft Entra joined Windows device. But the dynamic group that is supposed to contain every Autopilot device does not contain it. No Autopilot deployment profile is assigned. Any configuration you target at that group skips the machine entirely.

Here is what that looks like in the portal. The device record exists and looks entirely normal.

Most engineers chase this in the wrong direction. They check the group tag. They re-save the deployment profile. They force a sync. They rebuild the dynamic group rule from memory. None of that helps, because the missing piece is not in Intune at all. It is a single string on the Entra ID device object, and the Intune portal never shows it to you.

Why it happens: the marker lives on an object you never created

Autopilot registration does two things at once. The obvious one is that a hardware hash gets uploaded and associated with your tenant ID. The less obvious one is that Microsoft Entra ID gets a brand new device object, created before anybody has ever signed in on the hardware.

Microsoft is explicit about this. The registration overview states that when an Autopilot device is registered, it automatically creates a Microsoft Entra object, and that the Autopilot deployment process needs that object to identify the device before the user signs in. The troubleshooting FAQ puts it more bluntly: that object acts as Autopilot's anchor in Microsoft Entra ID for group membership and targeting, including the profile.

That anchor object is where the ZTDID lives. In Microsoft Graph, the property is physicalIds on the device resource. It is a string collection, and Microsoft's own reference labels it "For internal use only." In Entra ID dynamic membership rules, the same data is addressed as devicePhysicalIds. Two names, one collection.

The three bracketed keys Microsoft documents

Entries in that collection are prefixed with a key in square brackets. Microsoft documents exactly three of them for Autopilot purposes, and each one answers a different question.

The distinction matters enormously. [OrderID] is a label you chose and can change. [ZTDId] is not a label. It is proof of registration. A device can have a perfectly correct group tag on its Autopilot record and still have no ZTDID on its Entra object, and in that state no group rule can ever find it.

Why the marker goes missing

There are a handful of documented ways a device ends up enrolled without the marker. Understanding which one applies tells you how to fix it.

• The device was Entra registered before it was Autopilot registered. Microsoft's FAQ describes this case directly. If a workplace-joined or MDM-only enrolled device is not deleted from Entra ID before being joined, the previous trust type is retained. You end up with a device object that predates the Autopilot registration, and that object was never the one Autopilot pre-created.
• The device enrolled without ever being registered. A standard Entra join plus automatic MDM enrolment produces a working, compliant, managed device. It produces no Autopilot registration, so there is no ZTDID. The MS Graph reference for listing devices even shows a sample device with "physicalIds": [], an empty collection, for exactly this kind of machine.
• Registration was added later and has not landed yet. If you enabled Convert all targeted devices to Autopilot, Microsoft says to allow 48 hours for the registration to be processed. During that window the device is enrolled and the marker is not there yet.
• Deregistration left the object behind. Microsoft documents that removing an Autopilot registration does not automatically delete the Entra device object for devices that are or were enrolled in MDM. The registration is gone, the object survives, and the two records disagree.

How to verify: reading physicalIds, and what the device can and cannot tell you

There are three places worth looking, and they are useful in a specific order. Start in the cloud, because that is where the marker actually is.

Step 1: read physicalIds from Microsoft Graph

The Entra portal does not expose physicalIds on a device blade. Graph is the documented read path. The least privileged permission for listing devices is Device.Read.All, for both delegated and application access.

That empty collection is the whole diagnosis. No [ZTDId] entry means no dynamic group membership, which means no profile assignment, which means the device behaves exactly like one somebody imaged by hand.

Step 2: cross-reference against the Autopilot service record

The marker being absent tells you the Entra object has no registration stamp. It does not tell you whether the Autopilot service has a registration for that hardware. Those are two separate records, and comparing them is how you tell "never registered" apart from "registered but the marker landed somewhere else."

Step 3: ask the device, and know the limits of what it can answer

This is where a lot of published guidance goes wrong, so let me be precise. Microsoft does not document a ZTDID field anywhere on the device. The documented field list for dsregcmd /status covers device state, device details, tenant details, user state, SSO state, and diagnostics. It includes DeviceId, Thumbprint, TpmProtected, DeviceAuthStatus, and a long list of others. It does not include ZTDID, and it does not include physicalIds. If you are looking for the marker on the endpoint, you will not find it there.

What the device can tell you is whether it thinks it is Autopilot registered at all. Autopilot profile settings received from the deployment service are stored under one registry key.

That combination is a textbook unregistered device. It has a tenant from the signed-in user, no assigned tenant from Autopilot, and the disable flag set.

Step 4: read the Autopilot event log

Autopilot writes to its own event log channel. If a device ever attempted an Autopilot flow and was told it was not registered, the evidence is here.

Event 807 is the one that matters here. It is the service telling the device, in plain terms, that it has no Autopilot registration. Here is the full documented catalog for that channel, so you can read the surrounding entries in context.

The fix: repair the registration, not the rule

Once you know the marker is missing, resist the urge to loosen the dynamic group rule so the device slips in. The rule is not the problem. Work through these three things in order.

1. Confirm the dynamic group rule is Microsoft's rule, verbatim

Do this first, because it is fast, and because a mistyped rule produces the exact same symptom on every device instead of one.

1. In the Microsoft Intune admin center, select Groups, then New group.
2. For Group type, select Security.
3. Enter a Group name and Group description.
4. For Microsoft Entra roles can be assigned to the group, select No.
5. For Membership type, select Dynamic Device.
6. Select Owners, then choose the users who should own the group.
7. Under Dynamic device members, select Add dynamic query, then Add expression.
8. Switch to the rule syntax text box and paste the rule for all Autopilot devices exactly as Microsoft publishes it: (device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]"))
9. Select Save, then Create.

If you need to scope by group tag or purchase order instead, these are the two other documented rule strings:

• By group tag, which maps to OrderID: (device.devicePhysicalIds -any (_ -eq "[OrderID]:179887111881"))
• By purchase order: (device.devicePhysicalIds -any (_ -eq "[PurchaseOrderId]:76222342342"))

2. Re-register the device so a fresh marker is stamped

If the rule is correct and one device is still missing, the registration itself needs repairing. Microsoft's documented remedy for a device whose Entra object predates its Autopilot registration is to delete all three records and start over.

1. Sign in to the Microsoft Intune admin center and select Devices.
2. Under By platform, select Windows.
3. Find the device under Device name, open it, and note the Serial number.
4. Select Delete in the toolbar, then Yes to confirm removing it from Intune.
5. Under Device onboarding, select Enrollment, then under Windows Autopilot select Devices.
6. Find the device by the serial number you noted, and select its checkbox.
7. Open the overflow menu on that row. If Unassign user is available, select it and confirm with OK.
8. With the device still selected, choose Delete in the toolbar, then Yes.
9. Select Sync to speed up the deregistration, then Refresh every few minutes until the row disappears.
10. Re-register the device by importing its hardware hash again, then re-enrol it.

3. For an already-managed fleet, register in bulk and wait the documented window

If your audit turns up a large batch of enrolled devices with no registration at all, the Autopilot profile carries a setting that registers them for you.

1. Open the Autopilot deployment profile assigned to the group containing those devices.
2. Set Convert all targeted devices to Autopilot to Yes.
3. Save the profile, and allow 48 hours for the registration to be processed.
4. Re-run your audit and confirm the marker has appeared on the Entra device objects.

Proof it worked: the audit report goes quiet

The companion script for this post walks every Entra device object, extracts physicalIds, and compares what it finds against the Autopilot service's own registration list. It is read-only. Every Graph call is a GET, and the scopes are Device.Read.All and DeviceManagementServiceConfig.Read.All.

A healthy fleet is one where the first counter is high and the three warning counters are explained. You will almost never drive them to zero, and you should not try. Personal devices and Entra registered devices are legitimately not Autopilot devices, and they should legitimately have no marker. What you are hunting is the specific mismatch: a device the Autopilot service believes it has registered, whose Entra object carries no marker. Those are the machines that behave hand-built, and now you have a name for the reason.

References

Microsoft official documentation

• Create device groups for Windows Autopilot — the three documented dynamic device group rule strings for [ZTDid], [OrderID], and [PurchaseOrderId], the group tag to OrderID mapping, and the 48 hour registration processing window.
• Manage rules for dynamic membership groups in Microsoft Entra ID — the devicePhysicalIds device attribute, the operator list, the -any and underscore syntax, case sensitivity rules, and the note that device rules can only be built in the text box.
• device resource type (Microsoft Graph v1.0) — the physicalIds string collection, its "for internal use only" label, and the $filter operators it supports.
• List devices (Microsoft Graph v1.0) — Device.Read.All as the least privileged permission, and the sample response showing an empty physicalIds collection.
• windowsAutopilotDeviceIdentity resource type — the Autopilot device identity properties, including azureActiveDirectoryDeviceId, groupTag, and purchaseOrderIdentifier.
• List windowsAutopilotDeviceIdentities — the GET endpoint and the DeviceManagementServiceConfig.Read.All least privileged scope.
• Windows Autopilot registration overview — registration automatically creating the Microsoft Entra object, and what happens to that object after deregistration.
• Windows Autopilot troubleshooting FAQ — the Provisioning\Diagnostics\Autopilot registry values, the ModernDeployment-Diagnostics-Provider event channel and full Event ID catalog, and the Entra object as Autopilot's anchor.
• Troubleshoot devices by using the dsregcmd command — the complete documented field list, which contains no ZTDID field.
• Automatic registration of existing devices — the documented caveats on Convert all targeted devices to Autopilot.

Community deep-dives