Start with the registration path
Windows Autopilot registration associates a device identity with an organization. Microsoft describes the hardware hash as part of that registration identity, but the best collection path depends on who has physical custody of the device and when the record is created.
| Situation | Preferred approach | Operational reason |
|---|---|---|
| New devices purchased through an eligible OEM or reseller | Partner or OEM registration | Avoids opening and manually processing every device before deployment. |
| Small evaluation or lab batch | Manual script-based collection | Useful for controlled testing where each device and output can be inspected. |
| Existing device being repurposed | Manual collection with ownership review | The device may already have Entra, Intune, or Autopilot history that must be understood. |
| Repair or motherboard replacement | Follow Microsoft and OEM replacement guidance | A major hardware change can alter the identity represented by the record. |
Manual collection is not a substitute for a scalable supply-chain process. Microsoft’s guidance positions it primarily for testing and evaluation. If technicians routinely unbox hundreds of new devices to run a script, the process should be reviewed with the supplier before more automation is layered on top.
Preserve the chain from device to record
The most expensive collection errors are often not malformed hashes. They are valid records associated with the wrong physical device, customer, batch, or tenant. At collection time, retain enough non-secret context to answer these questions later:
- Which physical device produced the record, and does its displayed serial number match firmware or chassis information?
- Who collected it, when, and through which script or workflow version?
- Which customer, tenant, purchase order, location, or deployment wave owns the handoff?
- Was the device new, repurposed, repaired, or previously managed?
- Was the result uploaded immediately, or merged into a later batch?
Do not place passwords, access tokens, recovery keys, or other secrets in this tracking record. The goal is provenance: enough evidence to reconnect a CSV row to its source without expanding the security impact of the file.
Choose online or offline collection deliberately
Microsoft provides supported PowerShell-based ways to gather the Autopilot device information, and Windows setup can also produce diagnostics in controlled scenarios. An online workflow can reduce handoffs by sending the information directly to the intended service, but it requires deliberate authentication and tenant verification. An offline workflow produces a file that can be reviewed before upload, but every copy, rename, spreadsheet edit, and merge becomes a new opportunity to damage or misroute the record.
For a shared technician process, decide the path before the device reaches the bench. Document the required privilege, whether internet access is allowed, where output is stored, how the target tenant is confirmed, and when local copies are removed under your retention policy.
Validate the output before it joins a batch
- Confirm the output contains a nonblank serial number and hardware hash.
- Compare the serial number with a second source on the device.
- Open the file as plain text and make sure the hardware hash has not been truncated or split by a real newline.
- Record the intended tenant and batch outside the CSV when those values are not part of the supported schema.
- Check whether the serial number or hash already appears in the working batch.
- Keep the original collection output until the normalized result is reviewed; do not overwrite the only source copy.
- After registration, confirm the resulting Autopilot record and intended profile state.
Microsoft supports up to 500 devices in a CSV import batch. That is a limit, not a target. Smaller batches are easier to reconcile when a record is rejected, already registered, or associated with another administrative context.
Do not confuse adjacent device objects
An Autopilot registration, a Microsoft Entra device identity, and an Intune managed-device record describe related but different parts of the lifecycle. Seeing one does not prove that the other two exist or are healthy. Record the identifier and portal context for the object you inspected instead of writing “device exists” in a ticket.
If collection succeeds but registration reports that the device is already assigned, stop before deleting anything. Determine whether the conflict is a duplicate row, a stale record in the same tenant, or an ownership issue involving another tenant. A technically valid hash does not establish that your tenant is entitled to claim the device.