A motherboard replacement shouldn't break SSO. When it does, the root cause usually isn't technical. It's a gap in the process.
In a cloud-only, Entra-joined fleet, device trust is anchored in the TPM. The device's registration keys, the BitLocker key protector, and the Autopilot hardware hash all tie back to the board. Swap the board and you've effectively created a new device that still carries the old one's identity record.
I've seen how this plays out. The laptop comes back from repair, boots fine, and can't get a Primary Refresh Token. OneDrive fails, Office keeps prompting, Teams breaks. The ticket gets routed as an app problem, and a senior engineer spends an hour proving it's identity.
Fixing one device is straightforward. The better question is why it happened at all.
When I review a device lifecycle, I look for three gaps:
- Repair isn't a defined lifecycle state. Most organizations document provisioning and retirement. Few define what happens when a device's hardware changes, so nothing triggers the identity steps.
- Ownership falls between teams. An OEM depot or warranty vendor does the swap. The service desk handles the return. Nobody owns the Autopilot hash, the BitLocker escrow, or the Entra device object in between.
- Stale objects quietly weaken controls. Conditional Access and compliance policies evaluate device records. Orphaned and duplicate objects muddy reporting, and in a regulated environment, a device record that doesn't match reality is an audit finding waiting to happen.
The proper procedure to follow:
- Before the repair, confirm the BitLocker recovery key is escrowed and deregister the device from Autopilot, per Microsoft's guidance for motherboard replacements.
- After the repair, capture the new hardware hash, reregister, and validate device registration and SSO before the device goes back to the user.
- Retire stale Entra and Intune records, and automate stale-device detection on a schedule with Microsoft Graph instead of relying on someone remembering.
- Write the identity steps into the depot or warranty process and the vendor's SLA, so they don't live in one engineer's head.
The takeaway: senior work isn't closing the ticket faster. It's designing the process so the ticket never gets opened. Map every event that changes a device's hardware, owner, or state, and make sure identity is part of each one.
Where does hardware repair sit in your device lifecycle, and who owns the identity steps?