AADSTS65001: User or admin has not consented to the app

What does AADSTS65001 mean?

DelegationDoesNotExist: The user or administrator hasn’t consented to use the application with ID X. Send an interactive authorization request for this user and resource.

The app asked for a token, but the permission grant it needs doesn’t exist. The fix Microsoft names is an interactive request, which is where the consent prompt appears.

A sibling: 65004 UserDeclinedConsent, “User declined to consent to access the app.” That is the user saying no at the prompt.

Is it an attack?

On its own, no. 65001 shows up whenever an app is used before anyone has consented to it, or when a developer adds a new permission and forgets the consent step.

The security relevance is consent phishing (illicit consent grant). Microsoft describes the attack like this:

the attacker creates a registered application in Microsoft Entra ID that requests access to data such as contact information, email, or documents. The attacker then tricks an end user into granting that application consent … After the illicit application is granted consent, it has account-level access to data without the need for an organizational account. Normal remediation steps (for example, resetting passwords or requiring multifactor authentication (MFA)) aren’t effective against this type of attack

65001 is the state the attacker needs to get past. The interesting moment is when it stops. The consent phishing guide covers the full investigation and the removal steps.

Pattern	Likely meaning
65001 for a known, internal app right after a permission change	A developer added a permission and consent wasn’t granted yet. Benign.
65001 for an app ID you don’t recognise, from several users in a short window	Users were sent a link to an app nobody approved. Look at the app and who published it.
An unfamiliar app goes from 65001 to successful sign-ins	Someone consented. Find the consent event in the audit log and check whether it was user or admin consent.
65001 for an unknown app in non-interactive or service principal sign-ins	Something is trying to use permissions it was never granted. Identify the app before anyone consents to it.

The table above is reasoning built on Microsoft’s attack description, not a list of Microsoft detections.

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

Apps that had 65001 and then had successful user sign-ins:

let window = 7d;
let missingConsent =
    union
        (SigninLogs | project TimeGenerated, AppId, AppDisplayName, UserPrincipalName, ResultType),
        (AADNonInteractiveUserSignInLogs | project TimeGenerated, AppId, AppDisplayName, UserPrincipalName, ResultType)
    | where TimeGenerated > ago(window)
    | where ResultType == "65001"
    | summarize FirstMissing = min(TimeGenerated), MissingUsers = dcount(UserPrincipalName)
              by AppId, AppDisplayName;
union
    (SigninLogs | project TimeGenerated, AppId, UserPrincipalName, ResultType),
    (AADNonInteractiveUserSignInLogs | project TimeGenerated, AppId, UserPrincipalName, ResultType)
| where TimeGenerated > ago(window)
| where ResultType == "0"
| join kind=inner missingConsent on AppId
| where TimeGenerated > FirstMissing
| summarize FirstSuccessAfter = min(TimeGenerated), SuccessUsers = dcount(UserPrincipalName)
          by AppId, AppDisplayName, FirstMissing, MissingUsers
| sort by FirstSuccessAfter desc

Then find the consent itself. Microsoft’s guidance is to search the Microsoft Purview (unified) audit log for the activity “Consent to application” and check IsAdminConsent. The Entra audit log records the same operation; in Log Analytics that is the AuditLogs table:

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

ConsentDetails holds the modified properties of the grant, which is where the admin-consent flag and the granted permissions appear. In the Entra audit log those are the properties named ConsentContext.IsAdminConsent and ConsentAction.Permissions, not a top-level IsAdminConsent field as in Purview. The exact field paths inside InitiatedBy and TargetResources vary; check them against a real event in your workspace before you build an alert on them.

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

How do Conditional Access and MFA affect it?

• 65001 isn’t caused by Conditional Access. It is a missing permission grant.
• MFA does not protect against consent phishing. In Microsoft’s words, resetting passwords or requiring MFA “aren’t effective against this type of attack”, because the app keeps its own access after consent.
• The control that matters is who may consent. Restrict user consent and turn on the admin consent workflow, so a user who hits a consent prompt for a risky app gets 90095 and a request goes to a reviewer, instead of granting access themselves.

How do I fix AADSTS65001?

For developers: grant consent for the permissions the app requests (admin consent for permissions that need it), then retry the sign-in.

For admins:

1. For an app ID you don’t recognise, find out who published it and what it asks for before anyone consents.
2. If an unknown app flipped from 65001 to success, find the “Consent to application” event, check whether it was admin consent, and review what the app accessed.
3. Remove consent from and disable any app you confirm as malicious. Resetting the user’s password alone does not cut off its access.
4. Restrict user consent and enable the admin consent workflow as your standing posture.