{
  "schemaVersion": "1.0",
  "code": "75011",
  "name": "NoMatchedAuthnContextInOutputClaims",
  "title": "AADSTS75011: Sign-in method doesn't match what the app asked for (fix)",
  "url": "https://brambrinkmeier.com/entra/aadsts/75011/",
  "alternates": {
    "markdown": "https://brambrinkmeier.com/entra/aadsts/75011.md",
    "json": "https://brambrinkmeier.com/api/aadsts/75011.json",
    "html": "https://brambrinkmeier.com/entra/aadsts/75011/"
  },
  "description": "AADSTS75011: a SAML app requested an authentication method the user's session doesn't match. A config issue; remove RequestedAuthnContext or force auth. KQL.",
  "summary": "AADSTS75011 means a SAML app asked for a specific authentication method in its request, and the method the user already signed in with is different. Microsoft Entra ID reuses the existing session instead of signing the user in again, so the two don't match. It is a configuration problem with low attack value. Fix it by removing RequestedAuthnContext or adding ForceAuthn.",
  "inMicrosoftReference": true,
  "unlistedChecked": null,
  "meaningText": "Microsoft's description:\n\n> **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](https://learn.microsoft.com/troubleshoot/azure/active-directory/error-code-aadsts75011-auth-method-mismatch).\n\nThis 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`.\n\nMicrosoft'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.\n\nMicrosoft'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.",
  "sections": [
    {
      "heading": "What does AADSTS75011 mean?",
      "text": "Microsoft's description:\n\n> **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](https://learn.microsoft.com/troubleshoot/azure/active-directory/error-code-aadsts75011-auth-method-mismatch).\n\nThis 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`.\n\nMicrosoft'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.\n\nMicrosoft'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."
    },
    {
      "heading": "Is it an attack?",
      "text": "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.\n\n| Pattern | Likely meaning |\n|---|---|\n| 75011 for many users of one SAML app, starting on a specific day | The app (or a change to it) started sending `RequestedAuthnContext`. Configuration. |\n| 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. |\n| 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. |\n| 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. |\n\nExclude it from failure-based attack detections."
    },
    {
      "heading": "How do I find it in my logs (KQL)?",
      "text": "Microsoft doesn't document which sign-in table 75011 is logged in. Check where it lands in your workspace first:\n\n```kusto\nunion withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs\n| where TimeGenerated > ago(7d)\n| where ResultType == \"75011\"\n| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable\n```\n\nWhich apps cause it, and whether the sessions came from a federation service:\n\n```kusto\nSigninLogs\n| where TimeGenerated > ago(30d)\n| where ResultType == \"75011\"\n| summarize Rows = count(),\n            Users = dcount(UserPrincipalName),\n            FirstSeen = min(TimeGenerated),\n            Protocols = make_set(AuthenticationProtocol, 5),\n            Issuers = make_set(TokenIssuerType, 5)\n          by AppDisplayName, AppId\n| sort by Rows desc\n```\n\n`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.\n\nUsers 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:\n\n```kusto\nlet mismatches =\n    SigninLogs\n    | where TimeGenerated > ago(1d)\n    | where ResultType == \"75011\"\n    | summarize FirstFail = min(TimeGenerated) by UserPrincipalName, AppId, AppDisplayName;\nlet successes =\n    SigninLogs\n    | where TimeGenerated > ago(1d)\n    | where ResultType == \"0\"\n    | summarize LastSuccess = max(TimeGenerated) by UserPrincipalName, AppId;\nmismatches\n| join kind=leftouter successes on UserPrincipalName, AppId\n| extend RecoveredLater = isnotnull(LastSuccess) and LastSuccess > FirstFail\n| summarize Users = count(), Recovered = countif(RecoveredLater) by AppDisplayName\n| sort by Users desc\n```\n\n`ResultType` is a **string** column, so compare it with `\"75011\"`, not `75011`."
    },
    {
      "heading": "How do I fix AADSTS75011?",
      "text": "**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.\n\n**For developers (the SAML app):**\n1. 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\"*.\n2. 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.\"*\n3. 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.\n\n**For admins:**\n1. Use the second query to find the app and the date it started.\n2. 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.\n3. 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."
    }
  ],
  "microsoftWording": {
    "text": "**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](https://learn.microsoft.com/troubleshoot/azure/active-directory/error-code-aadsts75011-auth-method-mismatch).",
    "source": "Microsoft's error code reference, as quoted on the page",
    "sourceUrl": "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes"
  },
  "securityReading": {
    "category": {
      "id": "app-config",
      "label": "App configuration"
    },
    "kind": {
      "id": "config",
      "label": "Configuration error"
    },
    "attackSignal": {
      "level": "low",
      "label": "Low: usually configuration or user error"
    },
    "mitre": [],
    "tables": [
      "SigninLogs"
    ],
    "isItAnAttack": "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.\n\n| Pattern | Likely meaning |\n|---|---|\n| 75011 for many users of one SAML app, starting on a specific day | The app (or a change to it) started sending `RequestedAuthnContext`. Configuration. |\n| 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. |\n| 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. |\n| 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. |\n\nExclude it from failure-based attack detections.",
    "conditionalAccess": null
  },
  "kql": [
    {
      "title": null,
      "leadIn": "Microsoft doesn't document which sign-in table 75011 is logged in. Check where it lands in your workspace first:",
      "query": "union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs\n| where TimeGenerated > ago(7d)\n| where ResultType == \"75011\"\n| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable"
    },
    {
      "title": null,
      "leadIn": "Which apps cause it, and whether the sessions came from a federation service:",
      "query": "SigninLogs\n| where TimeGenerated > ago(30d)\n| where ResultType == \"75011\"\n| summarize Rows = count(),\n            Users = dcount(UserPrincipalName),\n            FirstSeen = min(TimeGenerated),\n            Protocols = make_set(AuthenticationProtocol, 5),\n            Issuers = make_set(TokenIssuerType, 5)\n          by AppDisplayName, AppId\n| sort by Rows desc"
    },
    {
      "title": null,
      "leadIn": "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:",
      "query": "let mismatches =\n    SigninLogs\n    | where TimeGenerated > ago(1d)\n    | where ResultType == \"75011\"\n    | summarize FirstFail = min(TimeGenerated) by UserPrincipalName, AppId, AppDisplayName;\nlet successes =\n    SigninLogs\n    | where TimeGenerated > ago(1d)\n    | where ResultType == \"0\"\n    | summarize LastSuccess = max(TimeGenerated) by UserPrincipalName, AppId;\nmismatches\n| join kind=leftouter successes on UserPrincipalName, AppId\n| extend RecoveredLater = isnotnull(LastSuccess) and LastSuccess > FirstFail\n| summarize Users = count(), Recovered = countif(RecoveredLater) by AppDisplayName\n| sort by Users desc"
    }
  ],
  "kqlSectionText": "Microsoft doesn't document which sign-in table 75011 is logged in. Check where it lands in your workspace first:\n\n```kusto\nunion withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs\n| where TimeGenerated > ago(7d)\n| where ResultType == \"75011\"\n| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable\n```\n\nWhich apps cause it, and whether the sessions came from a federation service:\n\n```kusto\nSigninLogs\n| where TimeGenerated > ago(30d)\n| where ResultType == \"75011\"\n| summarize Rows = count(),\n            Users = dcount(UserPrincipalName),\n            FirstSeen = min(TimeGenerated),\n            Protocols = make_set(AuthenticationProtocol, 5),\n            Issuers = make_set(TokenIssuerType, 5)\n          by AppDisplayName, AppId\n| sort by Rows desc\n```\n\n`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.\n\nUsers 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:\n\n```kusto\nlet mismatches =\n    SigninLogs\n    | where TimeGenerated > ago(1d)\n    | where ResultType == \"75011\"\n    | summarize FirstFail = min(TimeGenerated) by UserPrincipalName, AppId, AppDisplayName;\nlet successes =\n    SigninLogs\n    | where TimeGenerated > ago(1d)\n    | where ResultType == \"0\"\n    | summarize LastSuccess = max(TimeGenerated) by UserPrincipalName, AppId;\nmismatches\n| join kind=leftouter successes on UserPrincipalName, AppId\n| extend RecoveredLater = isnotnull(LastSuccess) and LastSuccess > FirstFail\n| summarize Users = count(), Recovered = countif(RecoveredLater) by AppDisplayName\n| sort by Users desc\n```\n\n`ResultType` is a **string** column, so compare it with `\"75011\"`, not `75011`.",
  "fix": {
    "short": "Developer or vendor: remove RequestedAuthnContext from the SAML AuthnRequest, or keep it and send ForceAuthn=true so the user signs in fresh. Admin: ask the app vendor for that change; it is made in the app, not in Entra ID. User: report it to the app owner with the time.",
    "steps": "**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.\n\n**For developers (the SAML app):**\n1. 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\"*.\n2. 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.\"*\n3. 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.\n\n**For admins:**\n1. Use the second query to find the app and the date it started.\n2. 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.\n3. 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."
  },
  "labReproduced": null,
  "labSectionText": null,
  "labRuns": [],
  "verification": "documentation",
  "related": [
    "50076",
    "50074",
    "50058",
    "76021",
    "500031",
    "750054"
  ],
  "coveredBy": [],
  "sources": [
    {
      "title": "Microsoft Entra authentication and authorization error codes",
      "url": "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes"
    },
    {
      "title": "Error AADSTS75011: authentication method doesn't match requested authentication method",
      "url": "https://learn.microsoft.com/troubleshoot/azure/active-directory/error-code-aadsts75011-auth-method-mismatch"
    },
    {
      "title": "Single sign-on SAML protocol",
      "url": "https://learn.microsoft.com/en-us/entra/identity-platform/single-sign-on-saml-protocol"
    },
    {
      "title": "SigninLogs table reference (Azure Monitor)",
      "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs"
    },
    {
      "title": "AADNonInteractiveUserSignInLogs table reference (Azure Monitor)",
      "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/aadnoninteractiveusersigninlogs"
    }
  ],
  "published": "2026-10-30",
  "lastUpdated": "2026-10-30",
  "lastVerified": null,
  "license": "CC BY 4.0",
  "licenseUrl": "https://creativecommons.org/licenses/by/4.0/",
  "licenseNote": "CC BY 4.0 covers the author's own text and classification fields. Quoted Microsoft error wording belongs to Microsoft, is quoted with its source and can change.",
  "attribution": "Bram Brinkmeier, \"AADSTS75011: Sign-in method doesn't match what the app asked for (fix)\", https://brambrinkmeier.com/entra/aadsts/75011/ (CC BY 4.0)",
  "microsoftErrorLookup": "https://login.microsoftonline.com/error?code=75011"
}