AADSTS75011: Sign-in method doesn't match what the app asked for (fix)

What does AADSTS75011 mean?

Microsoft’s description:

NoMatchedAuthnContextInOutputClaims: The authentication method by which the user authenticated with the service doesn’t match requested authentication method. To learn more, see the troubleshooting article for error AADSTS75011.

This is a SAML single sign-on error. The app put a RequestedAuthnContext element in its SAML request. That element names the authentication method the app wants, as an AuthnContextClassRef value such as urn:oasis:names:tc:SAML:2.0:ac:classes:Password.

Microsoft’s troubleshooting article explains the cause: the user had already signed in before reaching the app, and “the AuthnContext (authentication method) used for that previous authentication is different from the one being requested.” Microsoft Entra ID “won’t perform a fresh authentication request”. It reuses the authentication context it already has, so the response can’t contain the method the app asked for.

Microsoft’s example is a federated user who signed in to My Apps with Windows Integrated Authentication through AD FS. The session’s AuthnContextClassRef is then urn:federation:authentication:windows, and “there will be a mismatch if the app requests other than urn:federation:authentication:windows.” The article names a second case: a session where MFA was used.

Is it an attack?

No documented attack pattern exists for 75011. It is an agreement problem between the app’s SAML request and the user’s existing session. Our reading: the sign-in fails before the app receives an assertion, so an attacker gains nothing from it.

Pattern	Likely meaning
75011 for many users of one SAML app, starting on a specific day	The app (or a change to it) started sending RequestedAuthnContext. Configuration.
75011 only for federated users	Likely, based on Microsoft’s AD FS example: the session came from the federation service with a method the app doesn’t accept.
75011 only for users who signed in with MFA or a certificate earlier in the session	The session method (for example a certificate or MFA) is stronger or different from the one the app named. Configuration.
75011 that goes away when the user opens the app in a private window	Likely the same cause: without an existing session, the user authenticates fresh and the method can match. Unconfirmed.

Exclude it from failure-based attack detections.

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

Microsoft doesn’t document which sign-in table 75011 is logged in. Check where it lands in your workspace first:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "75011"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable

Which apps cause it, and whether the sessions came from a federation service:

SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "75011"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            FirstSeen = min(TimeGenerated),
            Protocols = make_set(AuthenticationProtocol, 5),
            Issuers = make_set(TokenIssuerType, 5)
          by AppDisplayName, AppId
| sort by Rows desc

AuthenticationProtocol is documented with values including saml20. A FirstSeen date that lines up with a change to the app is the most useful clue. TokenIssuerType is documented with values including AzureAD and ADFederationServices. If Issuers shows ADFederationServices rather than AzureAD, you are likely in Microsoft’s AD FS scenario.

Users who hit 75011 and then succeeded on the same app the same day, a sign that a fresh sign-in (for example a new browser session) works around it:

let mismatches =
    SigninLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "75011"
    | summarize FirstFail = min(TimeGenerated) by UserPrincipalName, AppId, AppDisplayName;
let successes =
    SigninLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "0"
    | summarize LastSuccess = max(TimeGenerated) by UserPrincipalName, AppId;
mismatches
| join kind=leftouter successes on UserPrincipalName, AppId
| extend RecoveredLater = isnotnull(LastSuccess) and LastSuccess > FirstFail
| summarize Users = count(), Recovered = countif(RecoveredLater) by AppDisplayName
| sort by Users desc

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

How do I fix AADSTS75011?

For the user: close the browser (or open a private window) and open the app again. That may help because there is no earlier session to reuse. This is not a documented fix. If it still fails, report it to the app’s owner with the time of the error. It is not something you can fix on your side.

For developers (the SAML app):

1. Remove RequestedAuthnContext from the AuthnRequest if you can. Microsoft calls it “an optional value” and its first suggestion is to “ask the application if the value could be removed”.
2. If you must keep it, request a fresh sign-in. Microsoft says “the SAML request must contain the value, forceAuthn="true"”, so the requested method is used. The SAML protocol reference describes ForceAuthn as forcing the user “to reauthenticate, even if they have a valid session with Microsoft Entra ID.”
3. If you keep RequestedAuthnContext, set Comparison to exact. Microsoft’s SAML reference says it “must be set to exact”, and lists the AuthnContextClassRef values Microsoft Entra ID supports. Only request one of those.

For admins:

1. Use the second query to find the app and the date it started.
2. Ask the vendor whether the app can stop sending RequestedAuthnContext, or send ForceAuthn="true" with it. Both changes are made in the app’s SAML request, not in Entra ID.
3. If the app needs MFA, enforce that with a Conditional Access policy on the app instead of asking for it in the SAML request. Our recommendation, not a step from Microsoft’s article.