{
  "schemaVersion": "1.0",
  "code": "90072",
  "name": "PassThroughUserMfaError",
  "title": "AADSTS90072: External account doesn't exist in the tenant, MFA can't be satisfied",
  "url": "https://brambrinkmeier.com/entra/aadsts/90072/",
  "alternates": {
    "markdown": "https://brambrinkmeier.com/entra/aadsts/90072.md",
    "json": "https://brambrinkmeier.com/api/aadsts/90072.json",
    "html": "https://brambrinkmeier.com/entra/aadsts/90072/"
  },
  "description": "AADSTS90072: an external account isn't in the tenant, or a synced user's ImmutableID doesn't match, so MFA can't be satisfied. Low attack value. KQL.",
  "summary": "AADSTS90072 means a user signed in with an external account that doesn't exist in the tenant they tried to reach, so they can't satisfy that tenant's MFA. It also appears for synced users when the ImmutableID (sourceAnchor) in Active Directory and Microsoft Entra ID don't match. It is a B2B or sync configuration problem with low attack value.",
  "inMicrosoftReference": true,
  "unlistedChecked": null,
  "meaningText": "Microsoft's description:\n\n> **PassThroughUserMfaError**: The external account that the user signs in with doesn't exist on the tenant that they signed into; so the user can't satisfy the MFA requirements for the tenant. This error also might occur if the users are synced, but there is a mismatch in the ImmutableID (sourceAnchor) attribute between Active Directory and Microsoft Entra ID. The account must be added as an external user in the tenant first. Sign out and sign in with a different Microsoft Entra user account.\n\nIn plain terms, the user authenticated somewhere, but the tenant they are trying to reach has no matching account for them. Without an account there, that tenant can't run its MFA for them, so the sign-in stops.\n\nMicrosoft names two causes:\n\n1. **B2B:** an external account that was never added (invited) to the resource tenant.\n2. **Directory sync:** a synced user whose ImmutableID (sourceAnchor) in on-premises Active Directory doesn't match the one in Microsoft Entra ID.\n\nIt is close to [50020](https://brambrinkmeier.com/entra/aadsts/50020/), which also means an outside account isn't in the tenant. Microsoft's description of 90072 adds the MFA angle and the sync cause.",
  "sections": [
    {
      "heading": "What does AADSTS90072 mean?",
      "text": "Microsoft's description:\n\n> **PassThroughUserMfaError**: The external account that the user signs in with doesn't exist on the tenant that they signed into; so the user can't satisfy the MFA requirements for the tenant. This error also might occur if the users are synced, but there is a mismatch in the ImmutableID (sourceAnchor) attribute between Active Directory and Microsoft Entra ID. The account must be added as an external user in the tenant first. Sign out and sign in with a different Microsoft Entra user account.\n\nIn plain terms, the user authenticated somewhere, but the tenant they are trying to reach has no matching account for them. Without an account there, that tenant can't run its MFA for them, so the sign-in stops.\n\nMicrosoft names two causes:\n\n1. **B2B:** an external account that was never added (invited) to the resource tenant.\n2. **Directory sync:** a synced user whose ImmutableID (sourceAnchor) in on-premises Active Directory doesn't match the one in Microsoft Entra ID.\n\nIt is close to [50020](https://brambrinkmeier.com/entra/aadsts/50020/), which also means an outside account isn't in the tenant. Microsoft's description of 90072 adds the MFA angle and the sync cause."
    },
    {
      "heading": "Is it an attack?",
      "text": "No. Both documented causes are configuration problems.\n\n| Pattern | Likely meaning |\n|---|---|\n| A partner user, first time on one of your apps | Not invited as a guest yet, or the invitation went to a different address. Benign. |\n| Your own staff signing in to a partner tenant | Same cause on the partner's side. They need to invite your user. Not your incident. |\n| One or a few of your own synced users, starting after an AD change or a sync server rebuild | ImmutableID / sourceAnchor mismatch. A sync problem to fix, not an attack. |\n| Many different external identities you never invited | Our interpretation, not a Microsoft statement: someone sending outside accounts at your apps. Same reading as the probing row on [50020](https://brambrinkmeier.com/entra/aadsts/50020/). Investigate the source. |\n\nThe third row is the one that needs real work. An ImmutableID mismatch means on-premises and cloud no longer agree which object is which user, and the affected users can't sign in until it is fixed."
    },
    {
      "heading": "How do I find it in my logs (KQL)?",
      "text": "Who hits 90072, against which apps, and whether they are guests or members:\n\n```kusto\nSigninLogs\n| where TimeGenerated > ago(14d)\n| where ResultType == \"90072\"\n| summarize Attempts = count(),\n            Apps = make_set(AppDisplayName, 10),\n            IPs = make_set(IPAddress, 10),\n            HomeTenants = make_set(HomeTenantId, 5),\n            UserTypes = make_set(UserType, 2),\n            CrossTenant = make_set(CrossTenantAccessType, 5),\n            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)\n          by UserPrincipalName\n| sort by Attempts desc\n```\n\nSplit the B2B case from the sync case. Rows where the home tenant is your own tenant point to the sync cause; rows from other home tenants point to B2B:\n\n```kusto\nSigninLogs\n| where TimeGenerated > ago(14d)\n| where ResultType == \"90072\"\n| extend Case = iff(HomeTenantId == ResourceTenantId, \"own tenant (check sync)\", \"external (check B2B)\")\n| summarize Users = dcount(UserPrincipalName), Attempts = count() by Case, AppDisplayName\n| sort by Attempts desc\n```\n\nThat split is our reasoning from the two causes Microsoft lists, not a documented field mapping. Look at one row of each kind in your workspace to see how `HomeTenantId`, `UserType` and `UserPrincipalName` are filled for an account that doesn't exist in the tenant. They may be empty or show the identity from the other side."
    },
    {
      "heading": "How does Conditional Access affect it?",
      "text": "- The error is about MFA, but it isn't a Conditional Access block. The tenant has no account for the user, so there is no user object for your MFA policy to work with.\n- Once the external user is invited, your guest policies decide how they do MFA. Microsoft: *\"If MFA trust is enabled, Microsoft Entra ID checks the user's authentication session for a claim indicating that MFA was fulfilled in the user's home tenant.\"* *\"If MFA trust is disabled, the resource tenant presents the user with a challenge to complete MFA in the resource tenant.\"*\n- Microsoft advises: *\"Before you create the Conditional Access policy, check your cross-tenant access settings to make sure your inbound MFA trust settings are configured as intended.\"*"
    },
    {
      "heading": "How do I fix AADSTS90072?",
      "text": "**For the user:** sign out and sign in again with the account your organisation gave you for that tenant. If you are a partner, ask your contact to invite you as a guest.\n\n**For admins, B2B case:**\n1. Invite the user as a guest (external user) in the resource tenant, using the address they actually sign in with.\n2. Check your cross-tenant access settings for that partner, including inbound MFA trust, so the user knows where they will do MFA.\n\n**For admins, sync case:**\n1. Compare the user's ImmutableID in Microsoft Entra ID with the sourceAnchor value in on-premises Active Directory. Microsoft names a mismatch in that attribute as the cause.\n2. Fix the mapping so both sides refer to the same object, then run a sync and test the sign-in. Our advice, not a Microsoft procedure for this code: find out why the mismatch happened (a re-created AD account, a rebuilt sync server, a changed sourceAnchor attribute) before fixing users one by one."
    }
  ],
  "microsoftWording": {
    "text": "**PassThroughUserMfaError**: The external account that the user signs in with doesn't exist on the tenant that they signed into; so the user can't satisfy the MFA requirements for the tenant. This error also might occur if the users are synced, but there is a mismatch in the ImmutableID (sourceAnchor) attribute between Active Directory and Microsoft Entra ID. The account must be added as an external user in the tenant first. Sign out and sign in with a different Microsoft Entra user account.",
    "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": "b2b-tenant",
      "label": "Guests and tenants"
    },
    "kind": {
      "id": "failure",
      "label": "Failure"
    },
    "attackSignal": {
      "level": "low",
      "label": "Low: usually configuration or user error"
    },
    "mitre": [],
    "tables": [
      "SigninLogs"
    ],
    "isItAnAttack": "No. Both documented causes are configuration problems.\n\n| Pattern | Likely meaning |\n|---|---|\n| A partner user, first time on one of your apps | Not invited as a guest yet, or the invitation went to a different address. Benign. |\n| Your own staff signing in to a partner tenant | Same cause on the partner's side. They need to invite your user. Not your incident. |\n| One or a few of your own synced users, starting after an AD change or a sync server rebuild | ImmutableID / sourceAnchor mismatch. A sync problem to fix, not an attack. |\n| Many different external identities you never invited | Our interpretation, not a Microsoft statement: someone sending outside accounts at your apps. Same reading as the probing row on [50020](https://brambrinkmeier.com/entra/aadsts/50020/). Investigate the source. |\n\nThe third row is the one that needs real work. An ImmutableID mismatch means on-premises and cloud no longer agree which object is which user, and the affected users can't sign in until it is fixed.",
    "conditionalAccess": {
      "heading": "How does Conditional Access affect it?",
      "text": "- The error is about MFA, but it isn't a Conditional Access block. The tenant has no account for the user, so there is no user object for your MFA policy to work with.\n- Once the external user is invited, your guest policies decide how they do MFA. Microsoft: *\"If MFA trust is enabled, Microsoft Entra ID checks the user's authentication session for a claim indicating that MFA was fulfilled in the user's home tenant.\"* *\"If MFA trust is disabled, the resource tenant presents the user with a challenge to complete MFA in the resource tenant.\"*\n- Microsoft advises: *\"Before you create the Conditional Access policy, check your cross-tenant access settings to make sure your inbound MFA trust settings are configured as intended.\"*"
    }
  },
  "kql": [
    {
      "title": null,
      "leadIn": "Who hits 90072, against which apps, and whether they are guests or members:",
      "query": "SigninLogs\n| where TimeGenerated > ago(14d)\n| where ResultType == \"90072\"\n| summarize Attempts = count(),\n            Apps = make_set(AppDisplayName, 10),\n            IPs = make_set(IPAddress, 10),\n            HomeTenants = make_set(HomeTenantId, 5),\n            UserTypes = make_set(UserType, 2),\n            CrossTenant = make_set(CrossTenantAccessType, 5),\n            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)\n          by UserPrincipalName\n| sort by Attempts desc"
    },
    {
      "title": null,
      "leadIn": "Split the B2B case from the sync case. Rows where the home tenant is your own tenant point to the sync cause; rows from other home tenants point to B2B:",
      "query": "SigninLogs\n| where TimeGenerated > ago(14d)\n| where ResultType == \"90072\"\n| extend Case = iff(HomeTenantId == ResourceTenantId, \"own tenant (check sync)\", \"external (check B2B)\")\n| summarize Users = dcount(UserPrincipalName), Attempts = count() by Case, AppDisplayName\n| sort by Attempts desc"
    }
  ],
  "kqlSectionText": "Who hits 90072, against which apps, and whether they are guests or members:\n\n```kusto\nSigninLogs\n| where TimeGenerated > ago(14d)\n| where ResultType == \"90072\"\n| summarize Attempts = count(),\n            Apps = make_set(AppDisplayName, 10),\n            IPs = make_set(IPAddress, 10),\n            HomeTenants = make_set(HomeTenantId, 5),\n            UserTypes = make_set(UserType, 2),\n            CrossTenant = make_set(CrossTenantAccessType, 5),\n            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)\n          by UserPrincipalName\n| sort by Attempts desc\n```\n\nSplit the B2B case from the sync case. Rows where the home tenant is your own tenant point to the sync cause; rows from other home tenants point to B2B:\n\n```kusto\nSigninLogs\n| where TimeGenerated > ago(14d)\n| where ResultType == \"90072\"\n| extend Case = iff(HomeTenantId == ResourceTenantId, \"own tenant (check sync)\", \"external (check B2B)\")\n| summarize Users = dcount(UserPrincipalName), Attempts = count() by Case, AppDisplayName\n| sort by Attempts desc\n```\n\nThat split is our reasoning from the two causes Microsoft lists, not a documented field mapping. Look at one row of each kind in your workspace to see how `HomeTenantId`, `UserType` and `UserPrincipalName` are filled for an account that doesn't exist in the tenant. They may be empty or show the identity from the other side.",
  "fix": {
    "short": "Admin, B2B case: invite the user as a guest in the resource tenant, using the address they sign in with. Admin, synced user: make the ImmutableID in Entra ID match the sourceAnchor in Active Directory, then sync. User: sign in with your account for that tenant, or ask your contact to invite you.",
    "steps": "**For the user:** sign out and sign in again with the account your organisation gave you for that tenant. If you are a partner, ask your contact to invite you as a guest.\n\n**For admins, B2B case:**\n1. Invite the user as a guest (external user) in the resource tenant, using the address they actually sign in with.\n2. Check your cross-tenant access settings for that partner, including inbound MFA trust, so the user knows where they will do MFA.\n\n**For admins, sync case:**\n1. Compare the user's ImmutableID in Microsoft Entra ID with the sourceAnchor value in on-premises Active Directory. Microsoft names a mismatch in that attribute as the cause.\n2. Fix the mapping so both sides refer to the same object, then run a sync and test the sign-in. Our advice, not a Microsoft procedure for this code: find out why the mismatch happened (a re-created AD account, a rebuilt sync server, a changed sourceAnchor attribute) before fixing users one by one."
  },
  "labReproduced": null,
  "labSectionText": null,
  "labRuns": [],
  "verification": "documentation",
  "related": [
    "50020",
    "50076",
    "50079",
    "16000",
    "51004",
    "500021",
    "500200",
    "500571",
    "5000211"
  ],
  "coveredBy": [],
  "sources": [
    {
      "title": "Microsoft Entra authentication and authorization error codes",
      "url": "https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes"
    },
    {
      "title": "Require multifactor authentication strength for external users (Conditional Access)",
      "url": "https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-guests-mfa-strength"
    },
    {
      "title": "SigninLogs table reference (Azure Monitor)",
      "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs"
    }
  ],
  "published": null,
  "lastUpdated": "2026-10-24",
  "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, \"AADSTS90072: External account doesn't exist in the tenant, MFA can't be satisfied\", https://brambrinkmeier.com/entra/aadsts/90072/ (CC BY 4.0)",
  "microsoftErrorLookup": "https://login.microsoftonline.com/error?code=90072"
}