AADSTS135011: Device used during authentication is disabled

What does AADSTS135011 mean?

Device used during the authentication is disabled.

Microsoft’s reference table gives no PascalCase name for this code. The device object in Entra ID has its account disabled, so Entra ID won’t use it for authentication.

Is it an attack?

The code itself is not an attack. It is the result of an admin action. The question is why the device was disabled and what is still trying to use it.

Pattern	Likely meaning
Device disabled during stale-device cleanup, user still has it	Benign. The user is on a device you retired.
Device disabled during incident response, then 135011 rows appear	The quarantined device is back online and trying to get tokens. Note the IP, time and app.
135011 from an IP or country the user never uses	Possible attacker-held device or replayed device-bound session. Investigate (reasoning, not a Microsoft statement).
Many users failing with 135011 at once	Bulk disable by a script or policy. Check the audit log for who disabled them.

Microsoft’s own revoke-access procedure disables the user’s devices as one of its steps:

Update-MgDevice -DeviceId $Device.Id -AccountEnabled:$false

So in an incident, 135011 is often the expected aftermath of that step. Its value is forensic: each row tells you when and from where the disabled device reconnected.

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

Every disabled device still attempting sign-ins, with where it came from:

union
    (SigninLogs
     | where TimeGenerated > ago(14d)
     | where ResultType == "135011"
     | extend DeviceId = tostring(DeviceDetail.deviceId),
              DeviceName = tostring(DeviceDetail.displayName),
              Country = tostring(LocationDetails.countryOrRegion),
              Log = "Interactive"),
    (AADNonInteractiveUserSignInLogs
     | where TimeGenerated > ago(14d)
     | where ResultType == "135011"
     | extend DeviceId = tostring(parse_json(DeviceDetail).deviceId),
              DeviceName = tostring(parse_json(DeviceDetail).displayName),
              Country = tostring(parse_json(LocationDetails).countryOrRegion),
              Log = "NonInteractive")
| summarize Attempts = count(),
            IPs = make_set(IPAddress, 10),
            Countries = make_set(Country, 5),
            Apps = make_set(AppDisplayName, 5),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            Logs = make_set(Log)
          by UserPrincipalName, DeviceId, DeviceName
| sort by LastSeen desc

Focus on one incident: the device you disabled, after the time you disabled it.

let incidentDevice = "<device-object-id>";
let disabledAt = datetime(2026-10-01T09:00:00Z);
union
    (SigninLogs
     | where TimeGenerated > disabledAt
     | extend DeviceId = tostring(DeviceDetail.deviceId)),
    (AADNonInteractiveUserSignInLogs
     | where TimeGenerated > disabledAt
     | extend DeviceId = tostring(parse_json(DeviceDetail).deviceId))
| where DeviceId == incidentDevice
| project TimeGenerated, UserPrincipalName, ResultType, IPAddress, AppDisplayName,
          ClientAppUsed, UserAgent
| sort by TimeGenerated asc

DeviceDetail is dynamic in SigninLogs and string in AADNonInteractiveUserSignInLogs, so each leg of the union extracts the device ID its own way before the tables are combined. The property names follow the Microsoft Graph signIn device detail object; check them against a row in your own workspace first.

Which log 135011 lands in is reasoned from the mechanism, not measured: a device-based SSO refresh is non-interactive, a fresh sign-in is interactive. The first query searches both.

How does Conditional Access affect it?

• 135011 is not a Conditional Access result code. It reports the state of the device object itself.
• Disabling the device removes it as an option for policies that require a compliant or hybrid joined device. If the user’s only managed device is disabled, they will start hitting 53000 or 53001 from whatever device they use next.
• Microsoft’s revoke-access procedure treats disabling devices and revoking the user’s refresh tokens (Revoke-MgUserSignInSession) as separate steps. Do both. The same page notes that access tokens last one hour by default, so already-issued access tokens can keep working until they expire, unless Continuous Access Evaluation applies (Exchange, SharePoint and Teams through CAE-capable clients), where Microsoft says revocation is enforced with “latency of up to 15 minutes”. The session revocation guide has the detail.

How do I fix AADSTS135011?

For the user: contact IT. The device has been disabled on purpose or by cleanup, and you can’t re-enable it yourself.

For admins:

1. Check the Entra audit log for who disabled the device and when.
2. If it was disabled during incident response, leave it disabled. Record each 135011 row (IP, time, app) as evidence of where the device is.
3. If it was a mistake or a stale-device cleanup that hit a device still in use, re-enable it:

Update-MgDevice -DeviceId $Device.Id -AccountEnabled:$true

4. If the device is gone for good, delete the device object and have the user register a new device.