AADSTS9002346: App is for personal Microsoft accounts only (fix)

What does AADSTS9002346 mean?

Microsoft’s error code reference doesn’t list AADSTS9002346 (checked 30 October 2026). We found no other Microsoft page that names it. The wording below is from a lab run:

AADSTS9002346: Application ‘<app id>’(<app name>) is configured for use by Microsoft Account users only. Please use th…

The lab records only the first line of error_description, cut at about 160 characters. The sentence completes as “Please use the /consumers endpoint to serve this request”, which is how the same message appears in a user report for the near-identical code 9002331.

The setting behind it is Supported account types on the app registration. Microsoft’s signInAudience page maps the portal choices to manifest values:

Supported account types	signInAudience
Accounts in this organizational directory only (Single tenant)	AzureADMyOrg
Accounts in any organizational directory (Any Microsoft Entra directory - Multitenant)	AzureADMultipleOrgs
Accounts in any organizational directory … and personal Microsoft accounts (such as Skype, Xbox)	AzureADandPersonalMicrosoftAccount
Personal Microsoft accounts only	PersonalMicrosoftAccount

An app at PersonalMicrosoftAccount exists only for consumer accounts, and consumer accounts sign in through /consumers. Microsoft’s OpenID Connect reference describes the endpoint values:

Value	Microsoft’s description
common	Users with both a personal Microsoft account and a work or school account from Microsoft Entra ID can sign in to the application.
organizations	Only users with work or school accounts from Microsoft Entra ID can sign in to the application.
consumers	Only users with a personal Microsoft account can sign in to the application.
Directory (tenant) ID or domain	Only users from a specific Microsoft Entra tenant … can sign in to the application.

So the request named a tenant that the app does not serve. Microsoft’s reference does list the mirror case, AADSTS9002332: “Application ‘{principalId}’({principalName}) is configured for use by Microsoft Entra users only. Please do not use the /consumers endpoint to serve this request.” 9002346 is the same check in the other direction.

9002346 and 9002331

9002331 carries the same sentence with a different number. A Microsoft Q&A thread quotes it as “AADSTS9002331: Application ‘…73f’(…Demo) is configured for use by Microsoft Account users only. Please use the /consumers endpoint to serve this request.”, and a Microsoft moderator answers: “From your error message, it looks like your App Registration is set for users to sign-in using their PersonalMicrosoftAccount only.”

On a current tenant, the lab run below produced 9002346 for that condition, not 9002331. We can’t tell from one tenant whether 9002331 is older, path-specific or flow-specific, so treat them as one condition and match on both in a detection rule.

Reproduced in the lab

On 30 October 2026 an automated lab run registered an app with Supported account types set to personal Microsoft accounts only, then sent a password-grant (ROPC) token request to the lab tenant’s own endpoint, with a user from that tenant. Entra returned AADSTS9002346:

AADSTS9002346: Application ‘<app id>’(<app name>) is configured for use by Microsoft Account users only. Please use th…

Control requests in the same run, using an ordinary single-tenant app on the same endpoint with the same user, reached the credential check and returned either a token or a credential error. So 9002346 is about the app’s supported account types and the endpoint, not about the user or the password.

No sign-in log row was captured. 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, with the Application column naming the personal-accounts-only app.

Is it an attack?

No. The app’s supported account types and the endpoint the code calls disagree.

Pattern	Likely meaning
A sample or tutorial app fails on the first run	Registered as Personal Microsoft accounts only while the code uses a tenant ID, /organizations or /common.
Work account users can’t sign in to an app that works with a personal account	The app was never meant for work accounts, or the account type was set wrongly at registration.
A third-party product fails for all your staff	The vendor’s app registration is consumer-only. Only the vendor can change that.
It appears right after someone edited the app registration	Supported account types was narrowed to personal accounts only. Check the audit log.

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

Which sign-in table 9002346 lands in is undocumented, and our reading is that most of these never reach your tenant’s logs at all: a consumer-only app usually has no service principal in your tenant, and the refusal happens at the endpoint. Expect few or no rows, and check with a union rather than guessing one table:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType in ("9002346", "9002331") or ResultSignature in ("9002346", "9002331")
| summarize Rows = count(), Apps = make_set(AppId, 10), LastSeen = max(TimeGenerated) by SourceTable, ResultType

If you do get rows, the faster question is which account types your own app registrations use. That is a Graph or PowerShell query against the directory, not a log query:

Connect-MgGraph -Scopes "Application.Read.All"
Get-MgApplication -All |
    Where-Object { $_.SignInAudience -eq "PersonalMicrosoftAccount" } |
    Select-Object DisplayName, AppId, SignInAudience

How do I fix AADSTS9002346?

For the user: if you have a personal Microsoft account (Outlook.com, Hotmail, Xbox), try signing in with that one. If the app is meant for your work account, report it to whoever owns the app.

For developers:

1. Decide who the app is for. Personal accounts only: send the request to https://login.microsoftonline.com/consumers/, which is what the error message asks for.
2. If work or school accounts must sign in too, change Supported account types on the app registration. For both kinds of account, use AzureADandPersonalMicrosoftAccount and the /common endpoint.
3. Don’t hardcode a tenant ID in an app registered for personal accounts only. The two settings contradict each other.

For admins:

1. For your own app registration, check Supported account types on the app’s Authentication page, and agree any change with the developer. Microsoft’s signInAudience page lists the validation rules that differ between the account types, so a change can also require edits elsewhere in the registration.
2. For a vendor’s app, you cannot change it. Ask the vendor for a registration that supports work accounts.