"Device authentication failed": hybrid join, the PRT and Intune, end to end

This post has two halves. The first half is the machinery: how a domain-joined Windows PC becomes a device Entra trusts, how that trust turns into the user's Primary Refresh Token (PRT), and how the PRT is what gets the device into Intune. The second half is a real ticket where that chain broke, walked through the way it was actually worked: the evidence, what each clue meant, the fix, and how we proved it was fixed.

If you only remember one idea, make it this one: device identity, user token and device management are a chain, not three separate features. Break the first link and everything after it fails too, with error messages that point at the wrong place.

01One laptop, four records

Before the mechanism, the cast. Most confusion comes from not knowing which object is which.

A hybrid-joined, Intune-managed, Autopilot-registered laptop is represented in four different places. They share a name or a serial number, which makes them look like duplicates, but each one does a different job and they are linked in a specific order.

Record	What it is for	If you delete it
AD computer object	Domain membership, GPOs, and the carrier for userCertificate	The device falls off the domain. Don't.
Entra device object	What Entra checks when the device signs a request. Holds the public key, join type and compliance flag	Device authentication fails immediately (the subject of this post)
Intune record	Policies, apps, compliance, BitLocker/LAPS settings	The device unenrolls at next check-in. User data is untouched
Autopilot placeholder	Remembers "this hardware belongs to us" for future resets	Autopilot no longer recognises the hardware at the next reimage

02How hybrid join actually works

The device gets its identity from a key it generates itself, carried to Entra by a cert in AD.

"Hybrid joined" means the PC is joined to on-prem AD and registered in Entra as the same machine. In a managed (non-federated) tenant, the registration leg is an elegant bit of engineering: the device never sends a password anywhere. It proves who it is with a key only it holds, and it uses AD plus Entra Connect as the trusted courier that introduces that key to Entra.

The pieces, in plain terms:

• The SCP (Service Connection Point) is a small AD object that tells domain-joined PCs which Entra tenant they belong to. It's configured once per forest.
• The join task is \Microsoft\Windows\Workplace Join\Automatic-Device-Join. It runs at sign-in and on a schedule. You can also run it by hand.
• The device ID is the subject of the cert the device creates. It becomes the Entra device object's ID, and it's the ID that Intune, Conditional Access and the sign-in logs all use.
• The private key never leaves the TPM. What reaches AD and Entra is only the public half. That's why a device's identity can't be copied to another machine, and also why it can't be "repaired" from the server side once the two halves disagree.

This also explains the prerequisites people hit in the field. The computer's OU has to be in Entra Connect sync scope, or step ④ never happens. The device needs line of sight to a DC for steps ① and ③, which is why office network or VPN matters.

03The PRT: where the device and the user meet

The user's single sign-on token is only issued to a device Entra recognises.

When a user signs in to Windows, the Entra plugin in the Windows sign-in stack sends her credentials to Entra in a request signed with the device key. Entra looks up the device object, checks that it exists, is enabled and has a public key matching that signature, and only then issues a Primary Refresh Token. The PRT is valid for 14 days, is renewed silently while the device is in use, and is bound to a session key kept in the TPM.

Every M365 app on the machine (Outlook, Teams, Edge, OneDrive) quietly trades the PRT for its own access token. That is what SSO on Windows is. It's also why a broken device identity shows up as "every app is broken at once."

04How the device lands in Intune

Auto-enrollment is triggered by a GPO but performed with the user's token.

For hybrid devices, enrollment is the third link and it depends on the first two:

1. A GPO linked to the computers' OU turns on Enable automatic MDM enrollment using default Azure AD credentials (set to User Credential). Some environments also scope it with a security group. All the GPO does is create a scheduled task under \Microsoft\Windows\EnterpriseMgmt.
2. When the user signs in and holds a PRT, that task uses her token to enroll the device. It only works if she's inside the MDM user scope on the Microsoft Intune app under Entra → Mobility (MDM and WIP).
3. Intune creates the device record, links it to the Entra device ID and sets her as primary user.
4. Intune writes back to the Entra device object: MDM: Microsoft Intune and, once evaluated, the compliance flag. Conditional Access reads that flag.

05The field case: what we saw

A user's laptop, every app failing, and one very informative command.

The ticket was simple: a user couldn't sign in to any M365 app. Windows reported that device authentication had failed and offered to register the device; the registration errored out. Before escalating, someone had already looked in Entra, found the laptop's device object with a blank join type, and deleted it as a bad object. The laptop was still listed in Intune, and the open question was whether to Retire, Wipe or Fresh Start it.

The first thing to run on any device-auth problem is dsregcmd /status. Trimmed and anonymised, it said:

# Device State
             AzureAdJoined : YES
              DomainJoined : YES
# Device Details
                  DeviceId : 1a2b3c4d-0000-4000-8000-00000000c0de
 DeviceCertificateValidity : [ 2019-03-14 -- 2029-03-14 ]
              TpmProtected : YES
          DeviceAuthStatus : FAILED. Device is either disabled or deleted
# Tenant Details
                    MdmUrl : (blank)
# SSO State
                AzureAdPrt : NO
            Attempt Status : 0xc000006d
         Server Error Code : invalid_grant
  Server Error Description : AADSTS50155: Device authentication failed.
# Diagnostic Data
      Last HostName Update : SUCCESS   Client Time : 2022-10-03

Read line by line, that output tells the whole story:

Line	What it means
AzureAdJoined : YES	The laptop believes it's hybrid joined. This is only its local opinion.
DeviceAuthStatus : FAILED	Entra rejects that belief. The device object it's claiming is gone or disabled.
Cert valid from 2019	The identity dates from the original join, years ago.
Last device write 2022	The last time this device successfully updated its Entra object. It had been quietly broken for a long time before anyone noticed.
AADSTS50155	No PRT because of device authentication, not the user's password.
MdmUrl blank	No working Intune link from the device's point of view.

So the diagnosis: the laptop and Entra disagreed about who the laptop was. The blank join type in Entra was the symptom of an object that had already drifted out of sync. Deleting it didn't cause the problem, but it did make it final, because the laptop was now presenting a device ID with no object behind it at all.

06Why not wipe, retire or Fresh Start?

Every one of those acts on the wrong record.

The Intune record wasn't the problem. It was a downstream casualty. The broken thing was the join state on the laptop, and none of the Intune actions touch that without also destroying something the user needs.

Action	What it does	Here?
Wipe	Factory reset. User data gone.	No
Fresh Start	Reinstalls Windows and strips apps. Not meant for hybrid-joined devices.	No
Retire	Removes Intune profiles, certs and apps. Keeps user data. Doesn't touch the join.	Doesn't fix it
Reset the join	Drops the stale identity locally and lets the device re-register. No user data touched.	Yes

07The fix, step by step

Clear the stale identity on both sides, re-run the join, and let the chain rebuild itself.

1. Leave, on the laptop (elevated):

dsregcmd /leave
dsregcmd /status      # expect AzureAdJoined : NO

2. Clear the old cert from AD (on a DC or anywhere with RSAT; the AD module won't be on the laptop). After the leave, the laptop no longer has the private key that matches this cert. Leaving it on the object risks Entra Connect syncing a dead identity back up.

Set-ADComputer WS-EXAMPLE01 -Clear userCertificate

3. Reboot, sign in, and run the join task (elevated on the laptop, on the corporate network or VPN):

schtasks /run /tn "\Microsoft\Windows\Workplace Join\Automatic-Device-Join"

Then confirm the new cert reached AD. It prints as a long column of byte values, which is fine; you're only checking that something is there.

Get-ADComputer WS-EXAMPLE01 -Properties userCertificate |
  Select-Object -ExpandProperty userCertificate

4. Sync (on the Entra Connect server):

Start-ADSyncSyncCycle -PolicyType Delta

The device reappears in Entra as Microsoft Entra hybrid joined, with Registered showing Pending.

5. Run the join task again to complete pass 2, then check:

dsregcmd /status | findstr /i "AzureAdJoined DeviceAuthStatus AzureAdPrt"
             AzureAdJoined : YES
          DeviceAuthStatus : SUCCESS
                AzureAdPrt : NO      # run as the local admin, so NO is correct

6. Have the user sign out fully and back in. Lock and unlock isn't enough. Then check again in her session.

08Proving it was fixed

Validate each link, in the user's session, not the admin's.

PS C:\Users\user> dsregcmd /status | Select-String "SSO State" -Context 0,10
                AzureAdPrt : YES
      AzureAdPrtUpdateTime : 2026-01-12 18:02 UTC
      AzureAdPrtExpiryTime : 2026-01-26 18:02 UTC     # 14 days, renews on its own
    Executing Account Name : CONTOSO\user
               KeySignTest : PASSED

• Link 1 (join): Entra shows the device as Microsoft Entra hybrid joined, and Registered now has a date instead of Pending.
• Link 2 (PRT): AzureAdPrt : YES in the user's session. Outlook, Teams and Edge all signed in silently.
• Link 3 (Intune): a new enrollment appeared three minutes after the PRT was issued, with the user as primary user. That timing is the GPO task firing as soon as it had a token to use. The Entra object flipped to MDM: Microsoft Intune.
• Link 4 (compliance): a brand-new record shows Not evaluated and OS 0.0.0.0 until its first full check-in. Hit Sync and give it half an hour or so; it isn't broken.

Two things went away with the deleted Entra object and needed putting back:

# BitLocker: re-escrow the recovery key to the new object
$kp = (Get-BitLockerVolume C:).KeyProtector | ? KeyProtectorType -eq RecoveryPassword
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $kp.KeyProtectorId

# LAPS: repopulates once Intune policy lands; nudge it with
Invoke-LapsPolicyProcessing

One more thing: if LAPS manages the local admin account you've been using all afternoon, its password rotates as soon as policy applies. Retrieve the new one from Entra before you need it.

09"Why are there two devices in Entra?"

The question everyone asks at the end, and the one object you must not clean up.

In this case the Autopilot page showed the laptop with Profile status: Not assigned and no group tag, which means it was registered in some earlier bulk import but Autopilot isn't actively doing anything for it. Deleting it is harmless to today's problem, but it's a fleet decision (does this organisation use Autopilot for reimages or not?), not something to tidy up in the middle of a ticket.

10The confusions, laid out

Every one of these came up while this ticket was being worked.

Anonymised from real support work. Device names, serial numbers, IDs, tenant details and account names have been changed.