AADSTS90094: Administrator consent is required

What does AADSTS90094 mean?

AdminConsentRequired: Administrator consent is required.

The user reached a consent prompt for an app, and the permissions requested are ones your tenant doesn’t let users grant themselves. The user is stopped until an admin consents.

If your tenant has the admin consent workflow turned on, the user sees 90095 instead and can send a request to a reviewer.

Is it an attack?

The code itself means a control worked. Whether there is an attack behind it depends on the app.

Microsoft’s illicit-consent guidance describes the attack: an attacker registers an app, tricks a user into consenting, and then “has account-level access to data without the need for an organizational account”. The full quote and the investigation are on the 65001 page and in the consent phishing guide.

Each 90094 is a user who reached a consent prompt and was stopped. That makes it a data point for consent-phishing attempts:

Pattern	Likely meaning
One or two users, a well-known SaaS app your company is adopting	A legitimate app waiting for admin review. Benign.
Many users, one unfamiliar app, within hours	Users were sent a link to that app. That is the shape of a consent-phishing campaign. Look up the app and its publisher.
An app name that imitates a Microsoft or internal tool, from an unverified publisher	Treat as phishing until shown otherwise.
90094 for an app, then a “Consent to application” audit event for the same app	Someone with admin rights consented. Confirm that was a deliberate review.

This reading is built on Microsoft’s attack description, not on a Microsoft detection rule.

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

Which apps users are being stopped on:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == "90094"
| summarize Users = dcount(UserPrincipalName),
            Attempts = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            SampleUsers = make_set(UserPrincipalName, 10),
            IPs = make_set(IPAddress, 10)
          by AppId, AppDisplayName
| sort by Users desc

An app with several users in a short window and no business owner is the one to look at first.

Did anyone grant consent anyway? Microsoft’s guidance is to search the Microsoft Purview (unified) audit log for “Consent to application” and check IsAdminConsent. The Entra audit log records the same operation; in Log Analytics:

AuditLogs
| where TimeGenerated > ago(30d)
| where OperationName == "Consent to application"
| extend Actor = tostring(InitiatedBy.user.userPrincipalName),
         AppName = tostring(TargetResources[0].displayName),
         AppObjectId = tostring(TargetResources[0].id),
         ConsentDetails = TargetResources[0].modifiedProperties
| project TimeGenerated, Actor, AppName, AppObjectId, Result, ConsentDetails
| sort by TimeGenerated desc

Compare AppName with the apps from the first query. The admin-consent flag sits inside ConsentDetails as the property named ConsentContext.IsAdminConsent (the granted permissions are in ConsentAction.Permissions). Field paths inside InitiatedBy and TargetResources vary; check them against a real event in your workspace. Note that the audit log identifies the app by its service principal object, while sign-in logs use AppId, so match on name or look up the IDs.

ResultType is a string column, so compare it with "90094", not 90094.

How do Conditional Access and MFA affect it?

• 90094 isn’t a Conditional Access result. It comes from your consent settings.
• MFA doesn’t help against consent phishing once consent is granted. Microsoft says password resets and MFA “aren’t effective against this type of attack”. The consent restriction that produced this 90094 is the control that matters.
• Recommended posture: restrict user consent and turn on the admin consent workflow. Users then get 90095 and a request goes to reviewers, instead of a dead end that pushes them to find another way.

How do I fix AADSTS90094?

For the user: ask your IT team to review the app. Don’t try other accounts to get past the prompt.

For admins:

1. Look up the app from the first query: publisher, requested permissions, and whether anyone in the business asked for it.
2. If it is legitimate, grant admin consent for the permissions it needs, and no more.
3. If it looks like phishing, warn the users who hit it and check the audit query for any consent that did go through.
4. Enable the admin consent workflow so future requests reach a reviewer as 90095.