A Windows Autopilot import that does nothing after you select Import is usually not an Intune outage. In many cases the portal is rejecting the CSV payload before it can create the Autopilot device record. The useful clue appears in the browser network trace, not in the visible admin center UI: 400 Cannot convert the literal ‘[DEVICEHASH]’ to the expected type ‘Edm.Binary’.
That message means Intune received a hardware hash value that it could not parse as the binary value expected by the Autopilot registration service. The device may be fine. The tenant may be fine. The CSV is the first thing to prove.
This guide gives desktop engineers a practical way to fix Autopilot hardware hash import error 400 Edm.Binary, rebuild a clean CSV, and avoid chasing the wrong Autopilot failure path.
What the 400 Edm.Binary Error Actually Means
Windows Autopilot registration depends on a hardware identity, usually called the hardware hash. Microsoft documents the manual registration flow as two parts: collect the device hardware identity, then upload that information in a CSV file. Microsoft also notes that a CSV upload can register up to 500 devices at a time, but you should confirm the previous batch completed before sending another one.
The hardware hash is not a friendly inventory field. It is a long Base64 value that represents device identity data. During import, Intune sends that value through Microsoft Graph and the Autopilot service expects it as binary data. If the value is truncated, wrapped, edited, exported badly, or placed under the wrong column, the service cannot convert it. That is when the request fails with a 400 response and the Edm.Binary message.
Microsoft’s Autopilot troubleshooting FAQ calls out this exact pattern: when selecting Import appears to do nothing, a network trace commonly shows a 400 error. The response body can say it cannot convert the literal hardware hash value to Edm.Binary. Microsoft points to an incorrectly formatted device hash as the most likely cause.
Treat this as a data-quality incident. Do not reset the device repeatedly. Do not delete random Intune records until you know the import file is valid.
Common Causes in Real Deployments
Most bad imports come from small handling mistakes after the hash is collected. The original collection may have succeeded, but the CSV was damaged before upload.
Check these causes first:
- The hardware hash was copied from a console window instead of kept inside the generated CSV.
- The CSV was opened in Excel and saved with altered formatting.
- A mail gateway, ticketing system, or remote support transcript wrapped the hash line.
- The file was merged manually and a comma was added inside the hash field.
- The CSV header names were changed.
- The file contains a blank line, extra notes, or multiple header rows.
- The hash was collected from an older script version or from the wrong output file.
- A device row was split across two lines because of line wrapping.
- A tenant-to-tenant transfer reused stale hashes without checking ownership and existing registrations.
The failure is easy to misread because the Intune admin center can stay quiet. The upload dialog may close or appear idle. The device never appears under Windows Autopilot devices, so the admin assumes Autopilot discovery, profile assignment, or licensing is broken. In this case, the registration never got that far.
Step 1: Prove the Import Request Is Failing
Start by confirming the symptom instead of guessing.
- Open the Microsoft Intune admin center.
- Go to Devices → Windows → Windows enrollment → Devices under Windows Autopilot.
- Open browser developer tools before you select Import.
- Use the Network tab and preserve the log.
- Import the CSV again.
- Filter for failed requests with status 400.
- Open the response body and look for Cannot convert the literal and Edm.Binary.
If you see that response, the import request reached the service but the payload was not valid. Capture the failing request ID, timestamp, tenant, and CSV filename in your incident notes. That information is useful if you later need Microsoft support, but you can usually fix the file without opening a case.
Also check whether only one row fails. If you imported a multi-device CSV, split it into smaller batches. A single corrupted row can make the whole batch look like a portal issue.
Step 2: Recollect the Hash Cleanly
For test devices and break-fix scenarios, recollect the hash rather than repairing a suspicious file by hand. Microsoft recommends using the Get-WindowsAutopilotInfo PowerShell script for manual registration. The Microsoft Learn article notes that the script was updated to use Microsoft Graph PowerShell modules instead of the deprecated AzureAD Graph modules, so use the current version from the PowerShell Gallery.
On the affected device, run this from an elevated PowerShell session:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
New-Item -Type Directory -Path "C:\HWID" -Force
Set-Location -Path "C:\HWID"
$env:Path += ";C:\Program Files\WindowsPowerShell\Scripts"
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned
Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile AutopilotHWID.csvUpload C:\HWID\AutopilotHWID.csv as generated. Do not paste the hash into a new workbook. Do not re-save it from Excel. If you need to inspect it, use Notepad, VS Code, or PowerShell.
For devices that are still in OOBE, use the same collection approach from the provisioning environment if that is your standard process. The key is to preserve the generated row exactly.
Step 3: Validate the CSV Before Upload
A quick local validation catches most import failures. You are not trying to decode every Autopilot attribute. You are checking for CSV shape, required columns, and obvious hash corruption.
Run this against the file before upload:
$csv = Import-Csv "C:\HWID\AutopilotHWID.csv"
$csv | Format-List
$required = @('Device Serial Number','Windows Product ID','Hardware Hash')
$missing = $required | Where-Object { $_ -notin $csv[0].PSObject.Properties.Name }
if ($missing) { throw "Missing columns: $($missing -join ', ')" }
foreach ($row in $csv) {
if ([string]::IsNullOrWhiteSpace($row.'Hardware Hash')) {
throw "Blank hardware hash for serial $($row.'Device Serial Number')"
}
if ($row.'Hardware Hash'.Length -lt 1000) {
throw "Hardware hash looks truncated for serial $($row.'Device Serial Number')"
}
}The exact hash length varies, so do not build an approval process around a single number. A very short value is suspicious, though. A normal Autopilot hash is long enough that truncation is obvious when compared to a known-good row.
If you must combine multiple devices into one file, use PowerShell to merge CSVs instead of copying rows manually:
Get-ChildItem C:\HWID\*.csv |
Import-Csv |
Export-Csv C:\HWID\Autopilot-import-batch.csv -NoTypeInformation -Encoding UTF8Then open the merged file in a text editor and confirm there is one header row, one row per device, and no notes above or below the data.
Step 4: Check for Existing or Wrong-Tenant Records
A clean CSV can still fail later if the device identity is already registered in the wrong place. Microsoft explains that before a device is deployed with Windows Autopilot, it must be registered with the Autopilot deployment service and associated with an Azure tenant ID. The Autopilot registration creates a Microsoft Entra object used to identify the device before user sign-in.
Before retrying a problem device, check:
- Windows Autopilot devices in Intune for the serial number.
- Microsoft Entra devices for stale objects with the same serial number or device name.
- Any previous tenant that owned the device.
- Reseller, distributor, or OEM registration status if the device should have been registered by a partner.
- Whether a motherboard replacement changed the identity enough to require a new hash.
Microsoft’s registration overview notes that large hardware changes, such as a motherboard replacement, may require a new hash. A hard drive change is usually less severe, but do not rely on old identity data after major repair work.
If the device is already registered as a personal Microsoft Entra registered device or an Intune MDM-only enrollment, clean up the old management path before trying to make it an Autopilot corporate-owned device. Mixing enrollment models creates confusing symptoms later in OOBE.
Step 5: Retry in a Controlled Batch
Once you have a clean file, retry with one known-good device before uploading a large batch.
Use this workflow:
- Import a one-row CSV.
- Wait for the import status to complete.
- Confirm the device appears under Windows Autopilot devices.
- Assign or confirm the Autopilot deployment profile.
- Wait for profile assignment to complete before resetting or shipping the device.
- Only then import the rest of the batch.
For large manual imports, keep the batch under the Microsoft documented 500-device CSV limit. In practice, smaller batches are easier to troubleshoot. If one row fails, you want to know which device caused it without splitting a huge file under pressure.
Document the source of each batch. Include collection date, collection method, technician, file name, and the target tenant. This sounds basic, but it prevents a common help desk loop where three teams keep uploading three different copies of the same bad CSV.
Limitations and Gotchas
The Edm.Binary error is about import formatting, not Autopilot readiness. After the device imports successfully, you still need to validate the normal deployment path: profile assignment, enrollment restrictions, licensing, network access, TPM attestation for self-deploying or pre-provisioning scenarios, and Enrollment Status Page behavior.
Do not assume the newest CSV is the best CSV. A newly collected hash from a repaired device may be correct while an older OEM or reseller record still points to a previous identity. Conversely, if a device was already registered correctly by a partner, a manual upload may be unnecessary.
Avoid Excel for Autopilot hash handling. Excel is useful for inventory review, but it is a poor tool for preserving long encoded strings. If your process requires human review, review serial numbers in a separate inventory export and keep the Autopilot import file untouched.
Finally, do not publish hardware hashes in tickets, screenshots, or chat channels outside your support boundary. The hash is not a password, but it is device identity material used for tenant registration. Treat it as operationally sensitive.
Conclusion
When Autopilot import fails with 400 Cannot convert the literal ‘[DEVICEHASH]’ to the expected type ‘Edm.Binary’, focus on the CSV. The service is telling you it cannot parse the hardware hash value it received.
The fastest fix is to confirm the 400 response in the browser network trace, recollect the hash with the current Get-WindowsAutopilotInfo script, validate the CSV shape, and retry with one device before batching. Once the import succeeds, move back to the usual Autopilot checks: tenant association, profile assignment, enrollment restrictions, and OOBE readiness.
That order saves time. Repair the registration data first, then troubleshoot deployment.