AADSTS700003: Device object was not found in the tenant (fix)

What does AADSTS700003 mean?

Microsoft’s error code reference doesn’t list AADSTS700003 (checked 30 October 2026).

Microsoft documents it in a troubleshooting article. When you sign in to an app integrated with Microsoft Entra ID, you get AADSTS700003 with one of these messages:

Device object was not found in the tenant ‘<TenantName>’ directory.

Your organization has deleted this device.

Microsoft’s cause: “This issue occurs because the device object is deleted on your home tenant. When a device is deleted, the “Delete device” activity type is recorded in the Microsoft Entra audit log.“ The article covers all three ways a device gets an identity: Microsoft Entra registered, Microsoft Entra joined and Microsoft Entra hybrid joined.

Our reading: the device still holds credentials tied to its old device object, such as its Primary Refresh Token, and tries to use them. Entra can’t find the object, so it refuses. This is the deleted-device counterpart of 135011, where the device object still exists but is disabled.

Users report it in places that aren’t obviously device-bound. An Atlassian knowledge base article describes a Jira Data Center mailbox connected through OAuth 2.0 that stopped sending and receiving mail, with this in the log:

AADSTS700003: Device object was not found in the tenant ‘xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx’ directory.

Atlassian’s fix was to regenerate the OAuth credentials and tokens and apply them in Jira again. Atlassian attributes the cause to a Microsoft security fix; Microsoft’s article doesn’t mention one. On Microsoft Q&A, a user hit “Error code 700003” in Microsoft Teams on a family computer that, they said, the school district’s IT had removed.

Is it an attack?

Usually not. It follows a device deletion, which is normal cleanup.

Pattern	Likely meaning
700003 for several users the day after a stale-device cleanup	The cleanup removed devices that were still in use. Check the audit log for who ran it.
700003 for one user after a reinstall or device swap	The old device object was deleted while something still used it. Re-register the device.
700003 from a server-side integration	A token tied to a device was stored by a service. Atlassian’s fix: create new tokens.
700003 after you deleted a device during incident response	Probably the device you removed, still trying to sign in. Its IP in the sign-in rows shows where it is.

How do I find it in my logs (KQL)?

Microsoft doesn’t document which sign-in table 700003 is logged in. Check where it lands first:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "700003"
| summarize Rows = count() by SourceTable

Who is affected and from where. DeviceDetail is dynamic in SigninLogs and a string in AADNonInteractiveUserSignInLogs, so each leg parses it first. Property names come from the Graph deviceDetail resource; we don’t know whether they are filled in for a device that no longer exists:

let rows =
    union
        (SigninLogs | extend D = parse_json(tostring(DeviceDetail)) | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName, IPAddress, UserAgent, D),
        (AADNonInteractiveUserSignInLogs | extend D = parse_json(DeviceDetail) | project TimeGenerated, ResultType, UserPrincipalName, AppDisplayName, IPAddress, UserAgent, D);
rows
| where TimeGenerated > ago(14d)
| where ResultType == "700003"
| extend DeviceId = tostring(D.deviceId), DeviceName = tostring(D.displayName), OS = tostring(D.operatingSystem)
| summarize Rows = count(), Apps = make_set(AppDisplayName, 10), IPs = make_set(IPAddress, 10),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by UserPrincipalName, DeviceId, DeviceName, OS
| sort by FirstSeen asc

Who deleted devices, and when. Microsoft’s article names the audit activity Delete device. TargetResources and InitiatedBy are dynamic columns; the property paths below follow their usual shape, so check them against one row of your own before you rely on them:

AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName == "Delete device"
| extend DeviceName = tostring(TargetResources[0].displayName),
         DeviceObjectId = tostring(TargetResources[0].id),
         ByUser = tostring(InitiatedBy.user.userPrincipalName),
         ByApp = tostring(InitiatedBy.app.displayName)
| project TimeGenerated, DeviceName, DeviceObjectId, ByUser, ByApp, Result, LoggedByService
| sort by TimeGenerated desc

Line up the FirstSeen time from the second query with the deletions in the third. A deletion shortly before the first 700003 for that user is your cause.

How do I fix AADSTS700003?

For the user: tell IT. Microsoft’s article says to “engage the home tenant administrators to determine when and why your device object is deleted.” If IT agrees the device should stay, re-register it with the steps below. On a school or work device you don’t manage, don’t do this on your own.

For admins: find the deletion with the third query. Then, if the device should stay, have the user re-register or re-join it. Microsoft’s steps by join type:

Join type	Microsoft’s steps
Microsoft Entra registered, Windows 10/11	Settings > Accounts > Access Work or School, select the account, Disconnect, then register the device again.
Microsoft Entra registered, iOS and Android	In Microsoft Authenticator, Settings > Device Registration > Unregister device, then register again.
Microsoft Entra registered, macOS	Use Intune Company Portal to unenroll the device and remove the registration, then register again.
Microsoft Entra joined	In an elevated PowerShell console, run the command below, select Sign in and sign in with the Entra ID account.
Microsoft Entra hybrid joined	In an elevated PowerShell console, run the command below, reboot, and sign in with the domain credential.

Microsoft Entra joined:

dsregcmd /forcerecovery

Microsoft Entra hybrid joined:

dsregcmd /leave

For a hybrid joined device, our reading is that the device registers again through the normal hybrid join process after the reboot. Check that a new device object appears.

For developers and integration owners: a stored token that fails with 700003 won’t recover. Re-authorize the connection to get new tokens, as Atlassian recommends for Jira mailboxes.

To prevent it: our suggestion is to check sign-in activity before a stale-device cleanup deletes a device, and to disable before you delete. A disabled device fails with 135011 instead, which gives you a window to undo the change before the object is gone.