AADSTS530031: Access policy does not allow token issuance (fix)

What does AADSTS530031 mean?

Microsoft’s error code reference doesn’t list AADSTS530031 (checked 30 October 2026). We found no other Microsoft page that documents it either. The wording below comes from user reports.

On Microsoft Q&A, a user posted this sign-in log entry:

Sign-in error code: 530031 Failure reason: Access policy does not allow token issuance.

The client app was Browser. The user said the account was still blocked after being excluded from every Conditional Access policy. The thread’s title blames Identity Protection, but nobody in the thread confirmed that. A moderator (not identified as a Microsoft employee) answered that a matching Conditional Access policy was blocking token issuance.

On a Tencent Cloud developer Q&A, a .NET app that requested a SharePoint token with grant_type=password got:

AADSTS530031: Access policy does not allow token issuance.

The same response carried error: interaction_required and suberror: message_only. The accepted answer there also points at a Conditional Access policy for SharePoint.

The phrase is not unique to 530031. Users quote it as the second sentence of the listed code 53003: “AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.”

Our reading: 530031 is a policy block in the same family as 53003. Microsoft doesn’t document which kind of policy produces 530031 instead of 53003, so we can’t say whether it is Conditional Access, Identity Protection, or something else. Don’t build detections on that distinction until Microsoft documents it.

Is it an attack?

Usually not. It is a policy blocking a sign-in, like 53003. The attack value comes from the context.

Pattern	Likely meaning
530031 for a user or app that worked before	A new or changed policy now applies to it. Users report exactly this.
530031 on a script using grant_type=password (ROPC)	The script can’t satisfy the policy’s requirements, since ROPC can’t do interactive steps. Likely, going by the Tencent report.
530031 for a user excluded from all Conditional Access policies	A different policy layer may be involved. The Q&A user suspected Identity Protection; unconfirmed.
530031 from an unfamiliar IP or country	Our reasoning: the request got as far as a policy decision. Check the user’s other sign-ins from that IP.

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

Microsoft doesn’t document which sign-in table 530031 is logged in. The Q&A user saw it with client app Browser, which suggests interactive sign-ins, but check:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "530031"
| summarize Rows = count() by SourceTable

The context of each block, side by side with 53003. ConditionalAccessStatus is documented as “success, failure, or notApplied.” The risk columns help test the Identity Protection theory:

union
    (SigninLogs | project TimeGenerated, ResultType, ResultDescription, UserPrincipalName, AppDisplayName, ClientAppUsed, IPAddress, ConditionalAccessStatus, RiskLevelDuringSignIn, RiskState),
    (AADNonInteractiveUserSignInLogs | project TimeGenerated, ResultType, ResultDescription, UserPrincipalName, AppDisplayName, ClientAppUsed, IPAddress, ConditionalAccessStatus, RiskLevelDuringSignIn, RiskState)
| where TimeGenerated > ago(30d)
| where ResultType in ("530031", "53003")
| summarize Rows = count(), Users = dcount(UserPrincipalName)
          by ResultType, ConditionalAccessStatus, RiskLevelDuringSignIn, RiskState, ClientAppUsed
| sort by ResultType asc, Rows desc

If 530031 rows show ConditionalAccessStatus == "notApplied" while 53003 rows show failure, that supports a non-Conditional Access cause in your tenant. That is a test you can run, not a documented fact.

How does Conditional Access affect it?

• Both user reports and their answers point at a Conditional Access policy. Microsoft’s Conditional Access troubleshooting page is the right tool even though it doesn’t list 530031.
• Microsoft’s steps: open the sign-in, select the Conditional Access tab, which “shows the specific policy or policies that resulted in the sign-in interruption.” The Troubleshooting and support tab may give the reason.
• If the Conditional Access tab shows nothing that failed, use the sign-in diagnostic (Basic info > Troubleshoot Event) or the What If tool.

How do I fix AADSTS530031?

For the user: you can’t fix this yourself. Send IT the error code, the time, and the correlation ID from the error page.

For developers: stop using grant_type=password for user tokens. Our reading: ROPC has no way to show an MFA prompt or prove a device, so a policy that needs either blocks it. Use an interactive flow through MSAL, or a service principal for unattended jobs.

For admins:

1. In Entra ID > Monitoring & health > Sign-in logs, filter on the user and the time and open the 530031 row. Read the Conditional Access tab first.
2. If a policy failed, decide whether the block is intended. Adjust the policy or the user’s device, location or authentication method.
3. If no policy failed, check the user’s risk state in Identity Protection and the second query above. Then run the sign-in diagnostic.
4. If you can’t find the cause, open a support case. Microsoft asks for the request ID, date and time from the sign-in event. With no Microsoft documentation for this code, support is the only authoritative answer.