AADSTS7000112: The application is disabled (fix)

What does AADSTS7000112 mean?

Microsoft’s description:

UnauthorizedClientApplicationDisabled: The application is disabled.

The app has a service principal (an enterprise application) in the tenant, and that service principal is switched off. In the Entra admin center this is the Enabled for users to sign-in? property. Microsoft describes what No does:

If this option is set to No, then no users are able to sign in to the application, even if they’re assigned to it. Tokens aren’t issued for the application. This setting not only prevents users from signing in but also restricts service principals from accessing the application using application permissions.

In Microsoft Graph the same switch is the service principal’s accountEnabled property: “If set to false, then no users are able to sign in to this app, even if they’re assigned to it.” Our reading is that 7000112 is what a client sees when it hits that switch. Microsoft’s description doesn’t say so in those words.

The error message usually names the app. Microsoft’s Exchange Online troubleshooting article shows this example: “AADSTS7000112: Application ‘00000002-0000-0ff1-ce00-000000000000’(Office 365 Exchange Online) is disabled.”

Disabled by Microsoft

An app can also be disabled from Microsoft’s side. Graph has a separate property, disabledByMicrosoftStatus, which “Specifies whether Microsoft has disabled the registered application”, with the value DisabledDueToViolationOfServicesAgreement for “suspicious, abusive, or malicious activity, or a violation of the Microsoft Services Agreement”. That property sits on the app registration, in the publisher’s tenant. Whether a Microsoft-disabled app returns 7000112 or a different code in your tenant isn’t documented.

Reproduced in the lab

On 30 October 2026 an automated lab run registered an app, created its service principal, set accountEnabled to false on that service principal, and then signed a test user in through it. Entra returned AADSTS7000112:

AADSTS7000112: Application ‘’() is disabled.

That confirms the cause directly: the service principal, the enterprise application object in your tenant, is the thing that is disabled. The app registration itself was untouched and still existed. The message names the application ID and the display name, so you can go straight to Enterprise applications and look at that object’s Enabled for users to sign-in? setting.

The sign-in log row isn’t captured yet; see how pages are checked.

In the lab tenant’s sign-in logs the row appears under User sign-ins (interactive), Status Failure, Conditional Access Not Applied. The Application column shows the disabled app’s own display name, not the sign-in client, so the row points straight at the application you need to re-enable.

Is it an attack?

The error itself is not. It is a block working. What matters is who disabled the app and why.

Pattern	Likely meaning
7000112 for an app an admin disabled during an incident	Working as intended. The app is cut off.
7000112 for a suspicious app after you disabled it, from IPs you don’t own	Possibly the app’s operator, or tooling using its tokens, is still trying (unconfirmed). Each row gives you an IP and a time. Worth recording, not worth re-enabling.
7000112 for a Microsoft first-party app (Exchange Online, Teams, SharePoint)	Someone disabled a Microsoft service principal in your tenant. Microsoft’s Exchange Online article shows this breaks Microsoft 365 sign-in with “Sorry, but we’re having trouble signing you in.” Check the audit log for who did it.
7000112 for a line-of-business app nobody remembers disabling	A clean-up job, a script, or an admin who thought the app was unused. Check the audit log before re-enabling.

A disabled Microsoft first-party service principal is worth a second look. Our reading, not a Microsoft statement: disabling Exchange Online or another core service principal is a quick way to cause a tenant-wide outage, so if nobody on your team did it on purpose, treat the account that did as suspect until you know.

If you disabled an app as part of a consent phishing response, see the consent phishing investigation guide, which treats 7000112 as one of the codes to watch afterwards.

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

Microsoft doesn’t document which sign-in table 7000112 lands in. A disabled app blocks both users and app-only access, so it can appear in all three. Check where it lands in your workspace:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "7000112"
| summarize Rows = count(), Apps = dcount(AppId) by SourceTable

Which disabled apps are still being used, by how many users, and from where:

union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "7000112"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            IPs = dcount(IPAddress),
            SampleIPs = make_set(IPAddress, 10),
            Resources = make_set(ResourceDisplayName, 5),
            FirstSeen = min(TimeGenerated)
          by AppId, AppDisplayName = coalesce(AppDisplayName, ServicePrincipalName)
| sort by Users desc

Who changed a service principal, and when. Microsoft’s audit log reference lists Update service principal in the ApplicationManagement category. Disabling an enterprise app is likely logged as that activity; Microsoft doesn’t say so:

AuditLogs
| where TimeGenerated > ago(30d)
| where Category == "ApplicationManagement"
| where OperationName == "Update service principal"
| mv-expand Target = TargetResources
| mv-expand Prop = Target.modifiedProperties
| where tostring(Prop.displayName) == "AccountEnabled"
| project TimeGenerated,
          App = tostring(Target.displayName),
          ServicePrincipalId = tostring(Target.id),
          OldValue = tostring(Prop.oldValue),
          NewValue = tostring(Prop.newValue),
          ByUser = tostring(InitiatedBy.user.userPrincipalName),
          ByApp = tostring(InitiatedBy.app.displayName)
| sort by TimeGenerated desc

The audit activity name comes from Microsoft’s audit log reference. The modified property name AccountEnabled is our assumption based on the Graph property, not checked against Microsoft documentation. If the query returns nothing, drop the AccountEnabled line and read the modifiedProperties of the rows yourself. Non-interactive and service principal sign-in rows are aggregated, so row counts there are not request counts. ResultType is a string column, so compare it with "7000112".

How does Conditional Access affect it?

• 7000112 is not a Conditional Access block. A disabled app gets no tokens at all, whatever your policies say.
• Don’t confuse it with 53003, which is a Conditional Access block. The fix and the owner are different.

How do I fix AADSTS7000112?

For the user: you can’t fix this yourself. The app is turned off in your organisation. Tell your IT team which app showed the error.

For developers: if your app is multi-tenant and a customer gets 7000112, the customer’s admin disabled your app’s service principal in their tenant. You can’t re-enable it from your side. Ask them to.

For admins:

1. Find out who disabled it and why with the audit log query, before changing anything. If it was disabled during an incident, leave it disabled.
2. If it was a mistake: in Enterprise applications > the app > Properties, set Enabled for users to sign-in? to Yes. In Microsoft Graph, set accountEnabled to true on the service principal.
3. For Exchange Online, Microsoft’s article gives the steps with the old MSOnline module (Set-MsolServicePrincipal -AccountEnabled $true on app ID 00000002-0000-0ff1-ce00-000000000000). That article notes the MSOnline and Azure AD modules are deprecated and points to Microsoft Graph PowerShell instead.
4. If the account that disabled a Microsoft first-party app can’t explain it, investigate that account like any other suspicious admin action.
5. If you want to block an app permanently, disabling is fine. Remove it later once nothing legitimate depends on it. After removal the code a client gets will probably change, to 700016 or 700011; which one isn’t documented.