Decommissioning a Device in Microsoft Entra ID

Decommissioning a device in Microsoft Entra ID looks deceptively simple from either end — click Disconnect on the device, or click Delete in the cloud. Either one alone leaves you with the failure mode that filled the previous post: stale GUIDs, orphaned device objects, and a re-join that never completes because the cloud and the device disagree about what exists. This guide is the procedure that doesn’t leave that mess.

There are three device-join models in Entra (Registered, Joined, Hybrid Joined), and each has a slightly different decommission path. Follow the section that matches the device you’re retiring — don’t mix steps between scenarios. Every section ends with a verification checklist; you’re done when every line passes, not before.

The three scenarios at a glance

Always do both sides. Cleaning only the device leaves an orphaned cloud entry. Cleaning only the cloud leaves the local cert and registry state. Either case will bite you when someone re-images the device with the same hostname.

Scenario 1 — Entra Registered (BYOD) decommission

Personal device, never domain-joined, connected only via Settings > Access work or school. The lightest of the three.

What gets cleaned

• Work account entry removed from Windows Settings
• MS-Organization-Access cert removed from the user-level Personal cert store
• SSO to M365 stops on this device for this user
• Device identity object deleted from Entra Admin Center

Part A — on the device

1. Sign in to Windows as the user who registered the device.
2. Settings (Win+I) > Accounts > Access work or school.
3. Find the work account entry (e.g. er01@ezaz2281.onmicrosoft.com — Connected to Azure AD).
4. Click it > Disconnect > Yes.
5. The entry disappears from the list.

Verify the cert is gone

1. Win+R > mmc > Enter.
2. File > Add/Remove Snap-in > Certificates > Add > My user account (NOT Computer) > Finish > OK.
3. Certificates – Current User > Personal > Certificates.
4. Confirm the MS-Organization-Access cert is no longer there. If it is, right-click and delete.

dsregcmd /status on the device

WorkplaceJoined : NO
AzureAdPrt      : NO

Part B — cloud cleanup

1. entra.microsoft.com as Global Admin.
2. Identity > Devices > All Devices.
3. Search by hostname or owner.
4. Find the entry with Join Type Microsoft Entra Registered.
5. Tick > Delete > confirm.

Also worth checking: Identity > Users > the user > Devices tab. The device should no longer appear there either.

Verification checklist — Scenario 1

Scenario 2 — Entra Joined decommission

Corporate device fully joined to Entra ID. User logs in with their Entra ID work account. There’s a critical pre-step here: Entra-Joined devices have no local user accounts by default. If you run dsregcmd /leave without first enabling a local admin, you can’t log back into Windows after the disjoin.

What gets cleaned

• Device leaves Entra ID join — Windows login reverts to local accounts
• MS-Organization-Access cert removed from the computer-level cert store (different from BYOD)
• Conditional Access and Intune policies stop applying
• Primary Refresh Token cleared, SSO stops
• Device identity deleted from Entra Admin Center

Part A — on the device

Step 1 — enable a local admin BEFORE you do anything else

1. Sign in with an Entra ID account that has local admin rights.
2. Right-click Start > Computer Management.
3. Local Users and Groups > Users.
4. If the built-in Administrator account exists but is disabled, right-click > Properties > uncheck Account is disabled > OK.
5. Right-click Administrator > Set Password > pick a strong one.
6. Note the password somewhere safe.

Alternative: create a new local user (right-click Users > New User) and add it to the local Administrators group. Either is fine; the point is having a local credential that survives the disjoin.

Skip this step and you lock yourself out of the machine after Step 2. The user’s Entra credentials still work for sign-in only as long as the device knows about Entra; once you run /leave, those credentials are useless on this device.

Step 2 — dsregcmd /leave

Command Prompt as Administrator:

dsregcmd /leave

Wait for completion. This clears the registration state, removes the PRT, and tears down the device’s side of the join. Restart the device.

Step 3 — verify after restart

Sign in as the local Administrator you enabled in Step 1. Then:

dsregcmd /status

Expect:

AzureAdJoined : NO
AzureAdPrt    : NO
DomainJoined  : NO

Step 4 — remove the cert from the computer store

1. Win+R > mmc.
2. File > Add/Remove Snap-in > Certificates > Computer account (NOT user) > Local computer > Finish > OK.
3. Certificates (Local Computer) > Personal > Certificates.
4. Right-click the MS-Organization-Access cert if present > Delete.

Step 5 — clean up Settings if anything lingers

Settings > Accounts > Access work or school. If any work account entry still appears, click > Disconnect.

Part B — cloud cleanup

1. entra.microsoft.com > Identity > Devices > All Devices.
2. Search by hostname.
3. Find the entry with Join Type Microsoft Entra Joined.
4. Tick > Delete > confirm.

If /leave ran cleanly, the device may already show as Enabled: No in Entra. Delete it anyway — disabled isn’t the same as gone, and disabled rows confuse re-joins later.

Verification checklist — Scenario 2

Scenario 3 — Hybrid Entra Joined decommission

The most involved of the three because there’s an on-prem AD object too. You have to clean three places: the device, Entra ID, and on-prem AD.

What gets cleaned

• MS-Organization-Access cert removed from the computer cert store
• Device disjoined from on-prem AD (computer object stops being authoritative)
• PRT cleared, SSO stops
• Device identity deleted from Entra Admin Center
• Computer object deleted from on-prem AD

Part A — on the device

Step 1 — dsregcmd /leave

Command Prompt as Administrator:

dsregcmd /leave

This clears the Entra side of the dual identity. The device stays domain-joined to your on-prem AD until you do Step 2.

Step 2 — disjoin from the on-prem domain

1. System > Domain or workgroup (or Advanced system settings > Computer Name > Change).
2. Member of: Workgroup > type WORKGROUP (or any workgroup name).
3. OK. Provide a domain admin credential when prompted to allow the disjoin.
4. Welcome to the workgroup message > OK.
5. Restart when prompted.

After restart, sign in with a local administrator account. (Same caveat as Scenario 2 — if there’s no local admin account ready, you can’t log in. On hybrid-joined corporate devices the local Administrator usually exists, just confirm before disjoining.)

Step 3 — verify state on the device

dsregcmd /status

Expect:

AzureAdJoined : NO
DomainJoined  : NO
AzureAdPrt    : NO

Step 4 — remove the cert from the computer store

Same procedure as Scenario 2 Step 4. certlm.msc > Personal > Certificates > delete any MS-Organization-Access cert if it lingers.

Part B — cloud cleanup

1. entra.microsoft.com > Identity > Devices > All Devices.
2. Search by hostname.
3. Find the Hybrid Joined entry.
4. Tick > Delete > confirm.

Part C — on-prem cleanup

1. On the DC: Active Directory Users and Computers.
2. Computers (or your custom OU).
3. Find the device’s computer object > right-click > Delete > confirm.

This is the step most people forget. The on-prem object is what triggers Entra Connect to potentially recreate the cloud device on the next sync — if you delete from Entra but leave the AD object, the device may reappear in Entra after the next sync cycle (usually as a fresh Pending entry that confuses everything later).

Alternatively run a delta sync after the AD deletion to push the removal up faster:

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

Verification checklist — Scenario 3

Things that bite people

Entra Joined device with no local admin — locked out after /leave

The single most preventable mistake in this whole guide. Always enable the local Administrator account and set a password before running dsregcmd /leave on an Entra-Joined device. Recovery without it requires booting from install media and resetting the local admin from a Recovery Command Prompt — possible but tedious.

Hybrid device disjoined locally but on-prem AD object left behind

Entra Connect’s next sync sees the still-present on-prem object, recreates the cloud device, and you’re back where you started. Always delete the AD computer object as part of Hybrid decommission.

Cloud delete only, device left in Settings

The cert and the registry keys are still on the device. Next time the device boots and the user opens Outlook, you’ll see odd auth errors and possibly a quiet re-registration if the user signs in to a new device-join flow with the same account. Do both sides.

Device shows as Enabled: No in Entra and you assume that’s clean

Disabled is not deleted. Disabled devices still consume the device count cap and still appear in some reports. Always Delete after Disable.

Hybrid disjoin with the wrong account

You need a domain admin credential to disjoin a device that’s domain-joined. Local admin alone isn’t enough. Have one ready before you start.

Re-imaging without decommissioning first

The classic source of the GUID mismatch failure mode covered in the previous post. Always run the decommission procedure for the existing identity before wiping and re-joining the same hostname.

Bulk decommission — PowerShell

For more than a handful of devices, do the cloud side via Microsoft Graph PowerShell instead of clicking through the portal. Outline only:

Connect-MgGraph -Scopes "Device.ReadWrite.All"
$device = Get-MgDevice -Filter "displayName eq 'DESKTOP-8MMB5Q0'"
Remove-MgDevice -DeviceId $device.Id

Pair with Get-ADComputer + Remove-ADComputer for the on-prem side, and a remote dsregcmd /leave via PowerShell Remoting for the device side. Test the script on one device first — bulk delete in Entra is irreversible.

What’s next

Devices are decommissioned cleanly. The next post in the Entra ID Security pathway shifts focus from devices to external identity: Microsoft Entra B2B Collaboration — how to invite partner-org users into your tenant, scope what they can access, and offboard them later without leaving the same kind of stale identity records that prompted this guide.