AADSTS75011: when the app insists on how you signed in

This one tends to show up the same way every time. Most users sign in fine from the app's home page, but anyone who follows a deep link from an email hits an Entra error page with code AADSTS75011. The message says the authentication method the user signed in with doesn't match the one the application requested.

What's actually happening

In a SAML AuthnRequest, a service provider can include a RequestedAuthnContext element. It tells the identity provider which authentication method it wants, usually something like this:

<samlp:RequestedAuthnContext Comparison="exact">
  <saml:AuthnContextClassRef>
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
  </saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>

Entra honours that request literally. If the user already has a session that was established with MFA, Windows Hello for Business or a certificate, the method no longer matches PasswordProtectedTransport with an exact comparison, and Entra refuses to issue a token.

The deep-link path often builds its request differently from the normal login button, which is why only some routes into the app fail.

How to confirm it

1. Capture the request with the browser's developer tools or a SAML tracer extension.
2. Base64-decode the SAMLRequest parameter (and inflate it if it was sent by redirect).
3. Look for RequestedAuthnContext and note the class reference and comparison type.
4. Check the Entra sign-in log for the failed attempt. The authentication details show which method the user actually used.

Paste the captured SAMLRequest into the SAML decoder. It decodes and inflates it, and flags an exact RequestedAuthnContext automatically.

Common authentication context values

An app asking for PasswordProtectedTransport with exact comparison is effectively saying "only password sign-ins are acceptable", which conflicts with any move to MFA or passwordless.

The fix lives with the service provider

There's no switch in the Enterprise Application to ignore the requested context. The vendor has to change their request. In order of preference:

• Remove RequestedAuthnContext entirely and let the IdP's Conditional Access decide how users authenticate.
• If they must send it, use Comparison="minimum" so a stronger method still satisfies the request.
• Make sure every login route in their app (home page, deep links, mobile) builds the request the same way.

What to send the vendor

Vendors fix this faster when the request is specific. Include:

• The decoded AuthnRequest, highlighting RequestedAuthnContext and Comparison
• The sign-in log entry showing AADSTS75011 and the method the user signed in with
• Which routes fail (deep links) and which work (home page)
• The change you're asking for: remove RequestedAuthnContext, or use Comparison="minimum"

Workarounds while you wait

• Tell affected users to open the app from its home page or from My Apps, where the login flow often doesn't request a context.
• Don't weaken Conditional Access to make the error go away. The problem is the app's request, not your policy.