How to fix "Need admin approval" (AADSTS65001, AADSTS90094) for an Outlook calendar app

Why calendar apps hit it now

Microsoft Entra decides what a user may approve with a consent policy. Microsoft's app consent policies page (updated August 28, 2026) describes the setting labeled "Let Microsoft manage your consent settings": "This is also the default for a new tenant. The setting's rules are currently: End users can consent for any user consentable delegated permissions EXCEPT:"

For Microsoft Graph: Files.Read.All, Files.ReadWrite.All, Sites.Read.All, Sites.ReadWrite.All, Mail.Read, Mail.ReadWrite, Mail.ReadBasic, Mail.Read.Shared, Mail.ReadBasic.Shared, Mail.ReadWrite.Shared, MailboxItem.Read, Calendars.Read, Calendars.ReadBasic, Calendars.ReadWrite, Calendars.Read.Shared, Calendars.ReadWrite.Shared, Chat.Read, Chat.ReadWrite, OnlineMeetings.Read, OnlineMeetings.ReadWrite, MailBoxFolder.Read, MailBoxFolder.ReadWrite, MailBoxSettings.Read, MailBoxSettings.ReadWrite, Contacts.ReadWrite, Contacts.Read.Shared, Contacts.ReadWrite.Shared, Tasks.Read, Tasks.Read.Shared, Tasks.ReadWrite, Tasks.ReadWrite.Shared, People.Read.

Every calendar permission is on it, including the narrowest, Calendars.ReadBasic. So is MailBoxSettings.Read, which you need to read working hours. There is no smaller scope that gets a calendar app under the line.

Microsoft calls this a managed policy: its conditions "are automatically updated based on Microsoft's latest security recommendations for end-user consent." Admins tracking Microsoft 365 message center post MC1097272 report that the calendar permissions were added in a rollout that started in October 2025 and finished by late November 2025. That timing comes from third-party write-ups, not a Microsoft page, and it is not documented whether existing tenants already on this setting were moved. Microsoft's own pages are not consistent either: the user consent settings page lists only microsoft-user-default-low and microsoft-user-default-legacy as built-in options.

The practical result: on a tenant with default settings, expect "Need admin approval" from any app that asks for calendar access.

The error codes

Microsoft's error code reference describes them as follows:

AADSTS65001 usually means a token was requested for permissions nobody has granted yet. AADSTS90094 and AADSTS90095 mean the user reached the consent screen and was not allowed to grant what you asked for. AADSTS65004 is different: the user could have approved and chose not to.

Publisher verification and risk-based step-up consent

A second, older mechanism produces the same screen. Risk-based step-up consent treats "consent requests for newly registered multitenant apps that aren't publisher verified and require nonbasic permissions" as risky and steps them up to admin consent. "This step-up capability is enabled by default, but it results in a behavior change only when user consent is enabled." When the admin consent workflow is off, the user sees:

AADSTS90094: needs permission to access resources in your organization that only an admin can grant. Request an admin to grant permission to this app before you can use it.

Publisher verification removes this one. Microsoft: "Beginning November 2020, if risk-based step-up consent is enabled, users can't consent to most newly registered multitenant apps that aren't publisher verified." To be verified you need a Microsoft AI Cloud Partner Program account that has completed verification, an app registered with a work or school account, and a publisher domain that isn't *.onmicrosoft.com. "Microsoft doesn't charge developers for publisher verification."

Get verified anyway. The user consent page recommends allowing user consent "only for applications that have been published by a verified publisher", so tenants with stricter settings need it. But it does not get you past the default policy above: that list applies to every app, verified or not.

The fix: admin consent

An administrator grants consent once for the whole organization. Microsoft's admin consent page gives the URL:

https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id}

{organization} is the tenant ID or one of its verified domains. The value organizations "causes the consent to happen in the home tenant of the user you sign in with", which is the one to put in a link you send to customers.

Who can grant it

• Privileged Role Administrator, "for granting consent for apps requesting any permission, for any API."
• Cloud Application Administrator, AI Administrator or Application Administrator, for any permission "except Microsoft Graph app roles (application permissions)."
• A custom role with the permission to grant permissions to applications.

A calendar app that acts for signed-in users uses delegated permissions, not app roles, so any of these roles can approve it.

Admins can also grant consent from the Entra admin center, under Entra ID, Enterprise apps, All applications, then Permissions, once the app exists in their tenant.

After that, "granting tenant-wide admin consent to an application allows all users to access the application unless otherwise restricted." Users sign in and connect without the approval screen.

Let users ask from the screen

If the admin consent workflow is on, a blocked user "can send a request for admin approval", which is emailed to designated reviewers. A Global Administrator has to turn it on, and reviewers still need one of the roles above to approve.

What to tell users

Detect the codes above in the error_description your OAuth callback receives, and show a page written for this case instead of a generic failure. Something like:

Your organization's Microsoft 365 settings require an administrator to approve calendar access for new apps. Send this link to your IT administrator. Once they approve, come back and connect again.

Include the admin consent URL with your client ID, the exact permissions you request and why, and your publisher name as it appears on the consent screen. IT teams approve faster when they can see the permission list before they click.

Personal Outlook.com and Hotmail accounts have no organization and no administrator. The person consents for themselves.

How Pyas handles it

With Pyas Auth, end users approve Pyas on Microsoft's own consent screen, and Microsoft has already verified it. Microsoft's default consent policy still applies, though: on a work tenant with default settings, an administrator approves calendar access for the organization once, with Pyas Auth too. With Native Auth, you use your own OAuth client per provider, so the admin consent URL carries your client ID. Once an account is connected, GET /v2/accounts/{accountId}/status says whether it works and, if not, why and the fix. To reconnect it, create a connect session with its accountId, and PyasConnect opens straight to that account inside your app.

Common questions

Does publisher verification fix "Need admin approval"?

Not on a tenant using Microsoft's default policy. It removes risk-based step-up consent, but Calendars.* permissions are excluded from user consent for every app under that policy.

Will prompt=consent get the user past it?

No. It shows the consent screen again, and the user is still not allowed to grant those permissions.

Can I ask for fewer permissions to avoid it?

Not for calendar access. Calendars.ReadBasic, the narrowest calendar permission, is on Microsoft's list.

Does this affect personal Outlook.com accounts?

No. Consent policies are settings of a Microsoft Entra organization. A personal account approves for itself.