AADSTS90095: Admin consent required, request access

What does AADSTS90095 mean?

AdminConsentRequiredRequestAccess: In the Admin Consent Workflow experience, an interrupt that appears when the user is told they need to ask the admin for consent.

This is the same situation as 90094, a user needing admin consent, but in a tenant where the admin consent workflow is enabled. Instead of a dead end, the user can send a request to the reviewers you designated.

Is it an attack?

The code is an expected step, not a failure. It means your consent controls are set up the way you want them.

The security work is in what the requests are for. 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.

With the workflow on, an attacker’s link ends at a 90095 and a request in your queue. The risk moves to the reviewer: if a reviewer approves a malicious app, the attack succeeds with admin consent.

Pattern	Likely meaning
One user, a known SaaS tool	A normal access request. Review it on its merits.
Many users, the same unfamiliar app, in a short window	A link to that app went round, possibly by phishing. Treat the request as suspicious until the app is vetted.
An app name imitating a Microsoft or internal tool	Treat as phishing until shown otherwise. Don’t approve.

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 requesting, and how many users each:

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

Did a reviewer approve one of them? 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

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 before alerting on them.

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

How do Conditional Access and MFA affect it?

• 90095 isn’t a Conditional Access result. It comes from your consent settings and the admin consent workflow.
• MFA doesn’t protect against an app that has been granted consent. Microsoft says password resets and MFA “aren’t effective against this type of attack”. The review step is the control.

How do I fix AADSTS90095?

For the user: send the request with a short reason, then wait for the reviewer.

For admins and reviewers:

1. Before approving, check the app’s publisher, the permissions requested, and whether someone in the business actually needs it.
2. Grant only the permissions the app needs.
3. If several users requested the same unfamiliar app at once, treat it as a possible phishing campaign: deny, warn the users, and look for the delivery message.
4. Keep this setup. Restricted user consent plus the admin consent workflow is the recommended posture.