Microsoft Entra ID
AuthenticationStrengthen federated sign-in security
In brief
The documentation now distinguishes standard token validation, user mapping, and authentication policy checks from the additional domain-consistency validation provided by Federated Token Validation Policy. It also clarifies root-domain matching for federated sign-ins.
What Entra admins need to know
Administrators get clearer guidance for understanding how federated sign-ins and the policy’s security checks work together.
This editorial summary was generated by AI from the documentation changes. Verify important details in the full Microsoft Learn article.
Documentation change
View on Microsoft LearnThe comparison below shows only the changed extract. Use the full-page view for complete context.
Strengthen federated sign-in security in Microsoft Entra ID
Organizations can configure Microsoft Entra ID to trust an external identity provider, such as Active Directory Federation Services (AD FS), or another SAML identity provider, for user authentication. Federated authentication remains a secure and recommended deployment model when configured and managed according to Microsoft guidance. In a federated sign-in, the identity provider authenticates the user and issues a federation token. Microsoft Entra ID validates the token,incoming token and maps it to a user account in the tenant,tenant. As part of this process, Entra performs a series of security and completespolicy checks, including token signature validation, trusted issuer and federation trust verification, token lifetime validation, account mapping, and evaluation of applicable Conditional Access and multifactor authentication requirements. When all validations and policy requirements are successfully met, the sign-in when all applicable checks succeed.is completed.
Federated Token Validation Policy adds a domain-consistency check. It can reject a sign-in whenan additional defense-in-depth control. The policy helps ensure that the root domain represented by the trusted federation realm doesn't matchis consistent with the root domain of the mapped Microsoft Entra user account. This checkadded domain-consistency validation helps preserve the intended security boundary betweenreinforce trust boundaries in tenants that use multiple federated domains in the same tenant.domains.
A federated domain is a verified Microsoft Entra domain whose authentication is delegated to a trusted identity provider. Federation configuration is represented by an internalDomainFederation object. This object is typically created as part of federation setup, including common AD FS or other identity-provider configuration experiences. Administrators might not create it directly.
What is cross-domain sign-in?
Cross-domainSimplified federated sign-in occurs whenflow
- A user enters a UPN, such as
[email protected]. - Microsoft Entra ID identifies the domain as federated and directs authentication to the configured identity provider.
- The identity provider authenticates the user and returns a signed federation
token is accepted from one trusted federation realm buttoken. - Microsoft Entra ID validates the token, including its signature, issuer, validity period, and trust relationship.
- Microsoft Entra ID maps the assertion to a Microsoft Entra user
whose user principal name (UPN) belongs toaccount. - Microsoft Entra ID applies applicable authentication, Conditional Access, and multifactor authentication requirements.
- Federated Token Validation Policy can apply an additional domain-consistency validation before sign-in completes.
Existing validation in federated sign-in
Federated authentication relies on established trust between Microsoft Entra ID and the configured identity provider. Before a different root domain. For example,federated sign-in succeeds, Microsoft Entra ID validates that the token was issued by a trusted federation configuration and that the token issued through the trust for domain B mapscan be mapped to a user whose UPN belongs to domain A.in the tenant.
Without strict domain validation,Depending on tenant configuration and sign-in context, Microsoft Entra ID can accept a token whenalso enforce additional controls such as Conditional Access, multifactor authentication, sign-in risk policies, device requirements, and application authorization. Federated Token Validation Policy doesn't replace these existing protections. It adds another validation layer that helps confirm the token is otherwise valid andfederated trust being used aligns with the asserted identity maps to a user, even ifdomain of the issuing trusted realm and the user UPN belong to different domains. In a tenant with multiple trustedMicrosoft Entra account being accessed.
How Federated Token Validation Policy strengthens federation realms, that behavior can weaken the intended separation between those realms.
Simplified federated sign-in flow
- A user enters a UPN, such as
[email protected].
- Microsoft Entra ID identifies the domain as federated and directs authentication to the configured identity provider.
- The identity provider authenticates the user and returns a signed federation token.
- Microsoft Entra ID validates the token, including its signature and validity, and uses federation data in the token to map the assertion to a Microsoft Entra user.
- Federated Token Validation Policy determines whether an additional domain-consistency rule should block the sign-in.
How Federated Token Validation Policy works
security
Simplified federated sign-in flow
- A user enters a UPN, such as
[email protected]. - Microsoft Entra ID identifies the domain as federated and directs authentication to the configured identity provider.
- The identity provider authenticates the user and returns a signed federation token.
- Microsoft Entra ID validates the token, including its signature and validity, and uses federation data in the token to map the assertion to a Microsoft Entra user.
- Federated Token Validation Policy determines whether an additional domain-consistency rule should block the sign-in.
How Federated Token Validation Policy works
The federatedTokenValidationPolicy resource controls additional validation of federation authentication tokens. It works with the internalDomainFederation object, which maps on-premises federated domains to their corresponding Microsoft Entra ID domains.
When validation is enforced, Microsoft Entra ID compares the federated account or trusted realm root domain with the root domain of the mapped Microsoft Entra account. Users
If the root domains match, sign-in can authenticate successfully only when the verified domain associated with the mapped Microsoft Entra user matches a verified federated domain associated with the authenticating identity provider or trusted realm.
continue, subject to all other authentication and policy checks. If the root domains don't match, Microsoft Entra ID rejects the authentication request.
| Scenario | Expected result with strict domain matching |
|---|---|
| The federation realm root domain matches the user UPN root domain. | Sign-in can continue, subject to all other authentication and policy checks. |
| The federation realm root domain differs from the user UPN root domain. | Sign-in is blocked by Federated Token Validation Policy. |
| The user UPN uses a child domain of the same root domain. | The policy evaluates the root domain. The child domain isn't treated as a separate root domain. |
| A custom configuration explicitly permits cross-domain behavior. | Cross-domain sign-in can be allowed, but the tenant doesn't receive this |
This protection is especially importantuseful in tenants with multiple federated domains because it preventshelps reduce the blast radius of a compromised or misconfigured federated identity provider. It also reinforces trust boundaries between independently managed federated domains in the same tenant.
What is cross-domain sign-ins thatin?
Cross-domain sign-in occurs when a federation token is accepted from one trusted federation realm but maps to a Microsoft Entra user whose UPN belongs to a different root domain.
For example, a token issued through the trust for domainB.com maps to a user whose UPN belongs to domainA.com.
Some organizations intentionally rely on cross-domain behavior for legacy, merger, acquisition, coexistence, or migration scenarios. Federated Token Validation Policy helps administrators identify and control this behavior more explicitly.
Federated Token Validation Policy helps prevent one trusted federation realm from being used to authenticate as users assigned to another root domain when those domains should be independently managed.
The relevant attack scenario requires several prerequisites, including:
In hybrid identity environments, users are linked to their Microsoft Entra accounts by using an immutable ID, which serves as a persistent identifier across the on-premises directory and cloud. This identifier is commonly stored in the If all prerequisites are met, an attacker who controls one trusted federation realm might attempt to issue a token that maps to a user in another realm by asserting that user's source anchor. Federated Token Validation Policy helps block this type of cross-domain access when the root domain of the trusted federation realm doesn't match the root domain of the mapped Microsoft Entra user.Additional protection provided by the policy
onPremisesImmutableId property of the user object in Microsoft Entra ID and often originates from the ms-DS-ConsistencyGuid attribute.
Example cross-realm impersonation scenario
Assume a Microsoft Entra tenant contains:
- Federated domain
idpA.com. - Federated domain
idpB.com. | Identity provider A |[email protected]|user1A| | Identity provider B |[email protected]|user2B|
If identity provider B is compromised or permits arbitrary source anchor values, an attacker could bypasscreate another user:
| Location | User | Source anchor |
|---|---|---|
| Identity provider B | [email protected] | user1A |
A token issued by identity provider B for [email protected] could map to the cloud account for [email protected] if only the source anchor mapping succeeds and no domain-level trust boundaries.consistency validation is enforced.
Setting Federated Token Validation Policy to validate root domains helps prevent this cross-domain access because the token's federation realm root domain and the mapped user's UPN root domain don't match.
Subdomain sign-in behavior
Sign-ins from subdomains, such as [email protected], aren't considered cross-domain sign-ins when the domains share the same root domain, such as contoso.com. These sign-ins continue to be allowed when Federated Token Validation Policy is enabled.
When a user signs in, Microsoft Entra ID extracts the root domain from the UPN and validates it against the root domain used by the federated identity provider. Sign-in is allowed when the root domains match. Otherwise, sign-in is blocked.
This approach provides appropriate securitydomain validation because subdomains typically share the same federation configuration and issuer as the root domain. If a distinct federation configuration is required, first promote the subdomain to a root domain. The policy then validates it independently.
Security risk without the policy
In hybrid identity environments, users are linked to their Microsoft Entra ID accounts by using an immutable ID, which serves as a persistent and unique identifier across both on-premises Active Directory and the cloud. This identifier is important for maintaining consistent identity mapping, especially in tenants with multiple federated domains where each domain is associated with a distinct realm and identity provider, such as AD FS or a SAML identity provider.
The immutable ID is typically stored in the onPremisesImmutableId property of the user object in Microsoft Entra ID. This property contains a Base64-encoded value that originates from the on-premises directory, most commonly derived from the ms-DS-ConsistencyGuid attribute. This value is known as the source anchor and is a foundational element in Microsoft Entra Connect synchronization and federation scenarios.
When Federated Token Validation Policy isn't enabled, an attacker can exploit cross-realm impersonation in tenants configured with at least two federated domains and two federated realms. If an attacker gains administrative control of a federated identity provider, or control of any identity store and claims-issuance process trusted by that identity provider, the attacker might be able to issue assertions that contain arbitrary identity attributes, including values used for account mapping.
For example, an attacker who controls realm A's identity provider and knows the immutable ID of a user in realm B could:
Create a spoofed account in realm A that uses that immutable ID.Authenticate through realm A.Illegitimately access the user's account in realm B.
Example cross-realm impersonation scenario
Assume a Microsoft Entra tenant contains the following configuration:
Federated domainidpA.com.Federated domainidpB.com. | Identity provider A |[email protected]|user1A| | Identity provider B |[email protected]|user2B|
An attacker could create another user in identity provider B:
| |
The legitimate setup between the Microsoft Entra tenant and identity provider A can be replicated in identity provider B if the federated identity provider permits an arbitrary source anchor to be configured. A bad actor can place the source anchor for [email protected] on the [email protected] user in the on-premises directory or identity store.
During authentication, a SAML token issued by identity provider B for [email protected] matches the cloud account of [email protected]. This gives the attacker access to that account without knowing credentials, such as a password, for the account in identity provider A.
Setting Federated Token Validation Policy to validate all root domains prevents this type of cross-domain access when the tenant domain of the mapped UPN and the identity provider domain don't match.
How Microsoft is strengthening security
Microsoft uses a stricter default that blocks cross-domain sign-ins when the federation realm root domain and the mapped user UPN root domain don't match. The change applies to federated domains that have an associated internalDomainFederation object.
A blocked authentication request is expected to return error
AADSTS5000820: Sign-in blocked by Federated Token Validation policy. Contact your administrator for details.A custom configuration can permit cross-domain sign-
in,in for intentional scenarios. However, allowing cross-domain sign-in restores previous behavior and removes this additional domain-consistency validation layer.Identify all federated domains in the tenant, and confirm which domains have an associated
internalDomainFederationconfiguration.Identify intentional cross-domain sign-in dependencies
Review intentional cross-domain sign-in scenarios, including:
- Coexistence environments.
- Shared identity providers.
- Migration projects.
- Configurations where users authenticate through a federation realm that differs from their UPN domain.
Validate representative sign-in scenarios
Test representative users from parent domains and child domains to help identify common configuration issues. Root-domain comparison can cause a child domain to behave differently from a separate root domain.
Successful testing doesn't guarantee that every sign-in path in the tenant has been exercised or that all users are unaffected after enforcement is enabled.
Monitor for AADSTS5000820
After enforcement is enabled, monitor Microsoft Entra sign-in logs for
AADSTS5000820errors. Investigate affected users to identify previously undiscovered cross-domain sign-in dependencies or configuration issues.Evaluate policy exceptions carefully
Configure less-restrictive validation settings only when there's a documented business requirement. Disabling or narrowing validation can restore previous behavior for intentional cross-domain scenarios, but it also removes an additional layer of protection that helps reinforce domain trust boundaries.
Organizations that allow cross-domain sign-in should evaluate compensating controls such as multifactor authentication, Conditional Access, trusted identity-provider governance, privileged access controls, and application-authorization policies.
Policy administration
The
rootDomainsproperty defines the types of domains to which validation applies.allValidates every verified domain in the tenant. This option provides the broadest domain-consistency validation. This option is appropriate for organizations that want to block cross-domain sign-in scenarios or require the strongest validation posture.
- [email protected] signs in by using a token from identity provider A for domainA.com. The root domains match, so sign-in is allowed.
- [email protected] signs in by using a token from identity provider A for domainA.com. The token is associated with domainA.com, but
organizations lose an additional layer of domain validation that can help detect configuration issues or unexpected identities.the mapped account belongs to domainB.com. Sign-in is blocked.
allFederated
Validates only users whose mapped Microsoft Entra account domain is federated. Federated domains are protected, while managed domains are excluded from validation. This option is appropriate for organizations that have many federated domains and want to protect federated trusts while leaving managed accounts unaffected.
Assume that domainA.com and domainB.com are federated, and domainC.com is managed:
- [email protected] has a token from identity provider A. The mapped account domain is federated, so validation applies. Because the root domains don't match, sign-in is blocked.
- [email protected] has a token from identity provider A. The mapped account domain is federated, so validation applies. Because the root domains match, sign-in is allowed.
- [email protected] has a token from identity provider A. The mapped account domain is managed, so validation doesn't apply and sign-in is allowed.
allManaged
Validates only users whose mapped Microsoft Entra account domain is managed. Managed domains are protected, while federated domains are excluded from validation. This option is appropriate when an organization wants to protect managed identities from tokens from unrelated federated domains but has historical federated-to-federated cross-domain scenarios that it isn't ready to break.
- [email protected] has a token from identity provider A. The mapped account domain is managed, so validation applies. Because the domains don't match, sign-in is blocked.
- [email protected] has a token from identity provider A. The mapped account domain is managed, so validation applies. Because the domains don't match, sign-in is blocked.
- [email protected] has a token from identity provider A. The mapped account domain is federated, so validation doesn't apply and sign-in is allowed.
enumerated
Blocks sign-in if the user's mapped account domain is included in the specified domain list and the incoming token's root domain doesn't match. This option supports phased rollout. For example, an organization can validate selected domains that are ready for enforcement while temporarily excluding domains that require additional testing or migration.
The following example validates three domains:
[email protected]has a token from identity provider B. The mapped account domain is in the enumerated list, so validation applies. Because the domains don't match, sign-in is blocked.[email protected]has a token from identity provider B. The mapped account domain isn't in the enumerated list, so validation doesn't apply and sign-in is allowed.
allManagedAndEnumeratedFederated
Validates all managed domains and only the federated domains explicitly listed in the policy. Federated domains that aren't listed are excluded from validation. This option provides immediate protection for all managed domains and gradual rollout for federated domains.
Assume that domainA.com, domainB.com, and domainC.com are federated, and domainD.com and domainE.com are managed. The following example enumerates two federated domains:
domainD.comanddomainE.com, because they're managed.domainA.comanddomainB.com, because they're enumerated federated domains.
none
Disables cross-domain validation. No root-domain matching occurs. This setting can be used to preserve intentional cross-domain sign-in behavior, such as certain legacy, acquisition, coexistence, or migration scenarios. However, it removes the additional domain-consistency protection provided by Federated Token Validation Policy.
For example, [email protected] signs in by using a token from identity provider A for domainA.com. The token is associated with domainA.com, but the mapped user account belongs to domainB.com. Because validation is disabled, sign-in is allowed.
Frequently asked questions
Can an administrator allow cross-domain sign-in?
Yes. An administrator can allow cross-domain sign-in by configuring the validatingDomains resource to use a less-restrictive setting, including none.
This configuration can be used for intentional cross-domain scenarios but removes the additional domain-consistency validation layer. Organizations should use less-restrictive settings only when required and should apply appropriate compensating controls.
Next steps
@@ -2,16 +2,16 @@ title: Strengthen federated sign-in security description: Learn how Federated Token Validation Policy strengthens federated sign-in security by preventing cross-domain authentication in Microsoft Entra ID. ms.topic: concept-article-ms.date: 08/18/2026+ms.date: 08/25/2026 ai-usage: ai-assisted # Customer intent: As an identity administrator, I want to understand and prepare for federated token domain validation so that I can prevent cross-domain sign-in without disrupting legitimate authentication. --- # Strengthen federated sign-in security in Microsoft Entra ID -Organizations can configure Microsoft Entra ID to trust an external identity provider, such as Active Directory Federation Services (AD FS), for user authentication. In a federated sign-in, the identity provider authenticates the user and issues a federation token. Microsoft Entra ID validates the token, maps it to a user in the tenant, and completes the sign-in when all applicable checks succeed.+Organizations can configure Microsoft Entra ID to trust an external identity provider, such as Active Directory Federation Services (AD FS) or another SAML identity provider, for user authentication. Federated authentication remains a secure and recommended deployment model when configured and managed according to Microsoft guidance. In a federated sign-in, the identity provider authenticates the user and issues a federation token. Microsoft Entra ID validates the incoming token and maps it to a user account in the tenant. As part of this process, Entra performs a series of security and policy checks, including token signature validation, trusted issuer and federation trust verification, token lifetime validation, account mapping, and evaluation of applicable Conditional Access and multifactor authentication requirements. When all validations and policy requirements are successfully met, the sign-in is completed. -Federated Token Validation Policy adds a domain-consistency check. It can reject a sign-in when the root domain represented by the trusted federation realm doesn't match the root domain of the mapped Microsoft Entra user account. This check helps preserve the intended security boundary between federated domains in the same tenant.+Federated Token Validation Policy adds an additional defense-in-depth control. The policy helps ensure that the root domain represented by the trusted federation realm is consistent with the root domain of the mapped Microsoft Entra user account. This added domain-consistency validation helps reinforce trust boundaries in tenants that use multiple federated domains. > [!IMPORTANT] > The `federatedTokenValidationPolicy` resource and its related Microsoft Graph APIs are available in preview through the `/beta` endpoint. Preview APIs are subject to change. Use of these APIs in production applications isn't supported.@@ -20,65 +20,68 @@ Federated Token Validation Policy adds a domain-consistency check. It can reject A federated domain is a verified Microsoft Entra domain whose authentication is delegated to a trusted identity provider. Federation configuration is represented by an [`internalDomainFederation`](/graph/api/resources/internaldomainfederation) object. This object is typically created as part of federation setup, including common AD FS or other identity-provider configuration experiences. Administrators might not create it directly. -### What is cross-domain sign-in?--Cross-domain sign-in occurs when a federation token is accepted from one trusted federation realm but maps to a Microsoft Entra user whose user principal name (UPN) belongs to a different root domain. For example, a token issued through the trust for domain B maps to a user whose UPN belongs to domain A.--Without strict domain validation, Microsoft Entra ID can accept a token when the token is otherwise valid and the asserted identity maps to a user, even if the issuing trusted realm and the user UPN belong to different domains. In a tenant with multiple trusted federation realms, that behavior can weaken the intended separation between those realms.--> [!NOTE]-> The comparison is based on root domains. A UPN such as `[email protected]` has the root domain `contoso.com`. A child domain and its parent root domain aren't automatically treated as unrelated domains for this policy check.- ### Simplified federated sign-in flow 1. A user enters a UPN, such as `[email protected]`. 1. Microsoft Entra ID identifies the domain as federated and directs authentication to the configured identity provider. 1. The identity provider authenticates the user and returns a signed federation token.-1. Microsoft Entra ID validates the token, including its signature and validity, and uses federation data in the token to map the assertion to a Microsoft Entra user.-1. Federated Token Validation Policy determines whether an additional domain-consistency rule should block the sign-in.+1. Microsoft Entra ID validates the token, including its signature, issuer, validity period, and trust relationship.+1. Microsoft Entra ID maps the assertion to a Microsoft Entra user account.+1. Microsoft Entra ID applies applicable authentication, Conditional Access, and multifactor authentication requirements.+1. Federated Token Validation Policy can apply an additional domain-consistency validation before sign-in completes.++## Existing validation in federated sign-in++Federated authentication relies on established trust between Microsoft Entra ID and the configured identity provider. Before a federated sign-in succeeds, Microsoft Entra ID validates that the token was issued by a trusted federation configuration and that the token can be mapped to a user in the tenant. -## How Federated Token Validation Policy works+Depending on tenant configuration and sign-in context, Microsoft Entra ID can also enforce additional controls such as Conditional Access, multifactor authentication, sign-in risk policies, device requirements, and application authorization. Federated Token Validation Policy doesn't replace these existing protections. It adds another validation layer that helps confirm the federated trust being used aligns with the domain of the Microsoft Entra account being accessed. -The [`federatedTokenValidationPolicy`](/graph/api/resources/federatedtokenvalidationpolicy) resource controls validation of federation authentication tokens. It works with the `internalDomainFederation` object, which maps on-premises federated domains to their corresponding Microsoft Entra ID domains.+## How Federated Token Validation Policy strengthens federation security -When validation is enforced, Microsoft Entra ID compares the federated account or trusted realm root domain with the root domain of the mapped Microsoft Entra account. Users can authenticate successfully only when the verified domain associated with the mapped Microsoft Entra user matches a verified federated domain associated with the authenticating identity provider or trusted realm.+The [`federatedTokenValidationPolicy`](/graph/api/resources/federatedtokenvalidationpolicy) resource controls additional validation of federation authentication tokens. It works with the `internalDomainFederation` object, which maps on-premises federated domains to their corresponding Microsoft Entra domains. -If the root domains don't match, Microsoft Entra ID rejects the authentication request.+When validation is enforced, Microsoft Entra ID compares the federated account or trusted realm root domain with the root domain of the mapped Microsoft Entra account.++If the root domains match, sign-in can continue, subject to all other authentication and policy checks. If the root domains don't match, Microsoft Entra ID rejects the authentication request. | Scenario | Expected result with strict domain matching | | --- | --- | | The federation realm root domain matches the user UPN root domain. | Sign-in can continue, subject to all other authentication and policy checks. | | The federation realm root domain differs from the user UPN root domain. | Sign-in is blocked by Federated Token Validation Policy. | | The user UPN uses a child domain of the same root domain. | The policy evaluates the root domain. The child domain isn't treated as a separate root domain. |-| A custom configuration explicitly permits cross-domain behavior. | Cross-domain sign-in can be allowed, but this behavior is less secure and is strongly discouraged. |+| A custom configuration explicitly permits cross-domain behavior. | Cross-domain sign-in can be allowed, but the tenant doesn't receive this additional domain-consistency protection. | -This protection is especially important in tenants with multiple federated domains because it prevents cross-domain sign-ins that could bypass domain-level trust boundaries.+This protection is especially useful in tenants with multiple federated domains because it helps reduce the blast radius of a compromised or misconfigured federated identity provider. It also reinforces trust boundaries between independently managed federated domains in the same tenant. -### Subdomain sign-in behavior+### What is cross-domain sign-in? -Sign-ins from subdomains, such as `[email protected]`, aren't considered cross-domain sign-ins when the domains share the same root domain, such as `contoso.com`. These sign-ins continue to be allowed when Federated Token Validation Policy is enabled.+Cross-domain sign-in occurs when a federation token is accepted from one trusted federation realm but maps to a Microsoft Entra user whose UPN belongs to a different root domain. -When a user signs in, Microsoft Entra ID extracts the root domain from the UPN and validates it against the root domain used by the federated identity provider. Sign-in is allowed when the root domains match. Otherwise, sign-in is blocked.+For example, a token issued through the trust for `domainB.com` maps to a user whose UPN belongs to `domainA.com`.++Some organizations intentionally rely on cross-domain behavior for legacy, merger, acquisition, coexistence, or migration scenarios. Federated Token Validation Policy helps administrators identify and control this behavior more explicitly. -This approach provides appropriate security validation because subdomains typically share the same federation configuration and issuer as the root domain. If a distinct federation configuration is required, first [promote the subdomain to a root domain](domains-verify-custom-subdomain.md#change-subdomain-to-a-root-domain). The policy then validates it independently.+> [!NOTE]+> The comparison is based on root domains. A UPN such as `[email protected]` has the root domain `contoso.com`. A child domain and its parent root domain aren't automatically treated as unrelated domains for this policy check. -## Security risk without the policy+## Additional protection provided by the policy -In hybrid identity environments, users are linked to their Microsoft Entra ID accounts by using an immutable ID, which serves as a persistent and unique identifier across both on-premises Active Directory and the cloud. This identifier is important for maintaining consistent identity mapping, especially in tenants with multiple federated domains where each domain is associated with a distinct realm and identity provider, such as AD FS or a SAML identity provider.+Federated Token Validation Policy helps prevent one trusted federation realm from being used to authenticate as users assigned to another root domain when those domains should be independently managed. -The immutable ID is typically stored in the `onPremisesImmutableId` property of the user object in Microsoft Entra ID. This property contains a Base64-encoded value that originates from the on-premises directory, most commonly derived from the `ms-DS-ConsistencyGuid` attribute. This value is known as the [source anchor](~/identity/hybrid/connect/plan-connect-design-concepts.md#sourceanchor) and is a foundational element in Microsoft Entra Connect synchronization and federation scenarios.+The relevant attack scenario requires several prerequisites, including: -When Federated Token Validation Policy isn't enabled, an attacker can exploit cross-realm impersonation in tenants configured with at least two federated domains and two federated realms. If an attacker gains administrative control of a federated identity provider, or control of any identity store and claims-issuance process trusted by that identity provider, the attacker might be able to issue assertions that contain arbitrary identity attributes, including values used for account mapping.+- A tenant with multiple federated domains or federation realms.+- A compromised, malicious, or improperly controlled trusted identity provider.+- Knowledge of the target user's immutable ID or source anchor.+- An identity provider or identity store capable of issuing or configuring arbitrary source anchor values. -For example, an attacker who controls realm A's identity provider and knows the immutable ID of a user in realm B could:+In hybrid identity environments, users are linked to their Microsoft Entra accounts by using an immutable ID, which serves as a persistent identifier across the on-premises directory and cloud. This identifier is commonly stored in the `onPremisesImmutableId` property of the user object in Microsoft Entra ID and often originates from the `ms-DS-ConsistencyGuid` attribute. -- Create a spoofed account in realm A that uses that immutable ID.-- Authenticate through realm A.-- Illegitimately access the user's account in realm B.+If all prerequisites are met, an attacker who controls one trusted federation realm might attempt to issue a token that maps to a user in another realm by asserting that user's [source anchor](~/identity/hybrid/connect/plan-connect-design-concepts.md#sourceanchor). Federated Token Validation Policy helps block this type of cross-domain access when the root domain of the trusted federation realm doesn't match the root domain of the mapped Microsoft Entra user. ### Example cross-realm impersonation scenario -Assume a Microsoft Entra tenant contains the following configuration:+Assume a Microsoft Entra tenant contains: - Federated domain `idpA.com`. - Federated domain `idpB.com`.@@ -98,24 +101,31 @@ The legitimate configuration includes: | Identity provider A | `[email protected]` | `user1A` | | Identity provider B | `[email protected]` | `user2B` | -An attacker could create another user in identity provider B:+If identity provider B is compromised or permits arbitrary source anchor values, an attacker could create another user: | Location | User | Source anchor | | --- | --- | --- | | Identity provider B | `[email protected]` | `user1A` | -The legitimate setup between the Microsoft Entra tenant and identity provider A can be replicated in identity provider B if the federated identity provider permits an arbitrary source anchor to be configured. A bad actor can place the source anchor for `[email protected]` on the `[email protected]` user in the on-premises directory or identity store.+A token issued by identity provider B for `[email protected]` could map to the cloud account for `[email protected]` if only the source anchor mapping succeeds and no domain-consistency validation is enforced.++Setting Federated Token Validation Policy to validate root domains helps prevent this cross-domain access because the token's federation realm root domain and the mapped user's UPN root domain don't match. -During authentication, a SAML token issued by identity provider B for `[email protected]` matches the cloud account of `[email protected]`. This gives the attacker access to that account without knowing credentials, such as a password, for the account in identity provider A.+### Subdomain sign-in behavior++Sign-ins from subdomains, such as `[email protected]`, aren't considered cross-domain sign-ins when the domains share the same root domain, such as `contoso.com`. These sign-ins continue to be allowed when Federated Token Validation Policy is enabled.++When a user signs in, Microsoft Entra ID extracts the root domain from the UPN and validates it against the root domain used by the federated identity provider. Sign-in is allowed when the root domains match. Otherwise, sign-in is blocked. -Setting Federated Token Validation Policy to validate all root domains prevents this type of cross-domain access when the tenant domain of the mapped UPN and the identity provider domain don't match.+This approach provides appropriate domain validation because subdomains typically share the same federation configuration and issuer as the root domain. If a distinct federation configuration is required, first [promote the subdomain to a root domain](domains-verify-custom-subdomain.md#change-subdomain-to-a-root-domain). The policy then validates it independently. ## How Microsoft is strengthening security Microsoft uses a stricter default that blocks cross-domain sign-ins when the federation realm root domain and the mapped user UPN root domain don't match. The change applies to federated domains that have an associated `internalDomainFederation` object. -- A blocked authentication request is expected to return error `AADSTS5000820`: **Sign-in blocked by Federated Token Validation policy. Contact your administrator for details.**-- A custom configuration can permit cross-domain sign-in, but organizations lose an additional layer of domain validation that can help detect configuration issues or unexpected identities.+A blocked authentication request is expected to return error `AADSTS5000820`: **Sign-in blocked by Federated Token Validation policy. Contact your administrator for details.**++A custom configuration can permit cross-domain sign-in for intentional scenarios. However, allowing cross-domain sign-in restores previous behavior and removes this additional domain-consistency validation layer. > [!IMPORTANT] > A tenant can trust more than one federation realm. Strict domain matching helps ensure that a token from one trusted realm can't be used to sign in as an account assigned to another root domain simply because other token-validation and account-mapping checks succeed.@@ -126,7 +136,7 @@ Microsoft uses a stricter default that blocks cross-domain sign-ins when the fed Identify all federated domains in the tenant, and confirm which domains have an associated `internalDomainFederation` configuration. -### Identify cross-domain sign-in dependencies+### Identify intentional cross-domain sign-in dependencies Review intentional cross-domain sign-in scenarios, including: @@ -134,35 +144,23 @@ Review intentional cross-domain sign-in scenarios, including: - Coexistence environments. - Shared identity providers. - Migration projects.-- Configurations where users might authenticate through a federation realm that differs from their UPN domain.+- Configurations where users authenticate through a federation realm that differs from their UPN domain. ### Validate representative sign-in scenarios Test representative users from parent domains and child domains to help identify common configuration issues. Root-domain comparison can cause a child domain to behave differently from a separate root domain. -Successful testing doesn't guarantee that every sign-in path in the tenant has been exercised or that all users will be unaffected after enforcement is enabled.--### Review domain and trust relationships--Examine:--- Domain hierarchies.-- Federation trust relationships.-- Identity-provider configurations.-- Scenarios in which users might authenticate through a domain other than their UPN domain.+Successful testing doesn't guarantee that every sign-in path in the tenant has been exercised or that all users are unaffected after enforcement is enabled. ### Monitor for AADSTS5000820 After enforcement is enabled, monitor Microsoft Entra sign-in logs for `AADSTS5000820` errors. Investigate affected users to identify previously undiscovered cross-domain sign-in dependencies or configuration issues. -### Avoid reducing policy protections+### Evaluate policy exceptions carefully -Configure less-restrictive validation settings only when there's a documented business requirement. Evaluate the associated security implications, and ensure that appropriate compensating controls are in place before you make policy exceptions.+Configure less-restrictive validation settings only when there's a documented business requirement. Disabling or narrowing validation can restore previous behavior for intentional cross-domain scenarios, but it also removes an additional layer of protection that helps reinforce domain trust boundaries. -> [!IMPORTANT]-> Validation and testing can help identify common configuration issues before enforcement is enabled, but they can't guarantee that all affected sign-in scenarios have been discovered.->-> Some cross-domain sign-in dependencies might only be revealed during broader production usage. Treat successful testing as risk reduction, not as confirmation that the environment is free of potential `AADSTS5000820` impacts.+Organizations that allow cross-domain sign-in should evaluate compensating controls such as multifactor authentication, Conditional Access, trusted identity-provider governance, privileged access controls, and application-authorization policies. ## Policy administration @@ -182,55 +180,34 @@ The [`validatingDomains`](/graph/api/resources/validatingdomains) resource uses The `rootDomains` property defines the types of domains to which validation applies. -### `none`--Disables cross-domain validation completely. No root-domain matching occurs. This option is the least secure and is highly discouraged.--For example, `[email protected]` signs in by using a token from identity provider A for `domainA.com`. The token is associated with `domainA.com`, but the mapped user account belongs to `domainB.com`. Because validation is disabled, sign-in is allowed.--> [!WARNING]-> With this option, Microsoft Entra ID doesn't verify that the sign-in domain matches an expected domain for authentication. Organizations lose an additional layer of domain validation that can help detect configuration issues or unexpected identities.->-> If a federated identity provider is compromised or malicious, it could be abused to authenticate users beyond its authorized domain scope. This configuration can increase the impact of a federation compromise from a single domain to potentially the entire tenant.->-> If you use this setting, use controls such as multifactor authentication, Conditional Access, trusted identity providers, and application-authorization policies to protect access.--Typical use cases include legacy tenants, complex acquisition scenarios, and organizations that rely on historical cross-domain federation behavior.- ### `all` -Validates every verified domain in the tenant. This option is the strictest setting.--- `[email protected]` signs in by using a token from identity provider A for `domainA.com`. The root domains match, so sign-in is allowed.-- `[email protected]` signs in by using a token from identity provider A for `domainA.com`. The token is associated with `domainA.com`, but the mapped account belongs to `domainB.com`. Sign-in is blocked.+Validates every verified domain in the tenant. This option provides the broadest domain-consistency validation. This option is appropriate for organizations that want to block cross-domain sign-in scenarios or require the strongest validation posture. -This option is appropriate for organizations that want to eliminate all cross-domain sign-in scenarios or require the highest security posture.+- [email protected] signs in by using a token from identity provider A for domainA.com. The root domains match, so sign-in is allowed.+- [email protected] signs in by using a token from identity provider A for domainA.com. The token is associated with domainA.com, but the mapped account belongs to domainB.com. Sign-in is blocked. ### `allFederated` -Validates only users whose mapped Microsoft Entra account domain is federated. Federated domains are protected, while managed domains are excluded from validation.+Validates only users whose mapped Microsoft Entra account domain is federated. Federated domains are protected, while managed domains are excluded from validation. This option is appropriate for organizations that have many federated domains and want to protect federated trusts while leaving managed accounts unaffected. -Assume that `domainA.com` and `domainB.com` are federated, and `domainC.com` is managed:+Assume that domainA.com and domainB.com are federated, and domainC.com is managed: -- `[email protected]` has a token from identity provider A. The mapped account domain is federated, so validation applies. Because the root domains don't match, sign-in is blocked.-- `[email protected]` has a token from identity provider A. The mapped account domain is federated, so validation applies. Because the root domains match, sign-in is allowed.-- `[email protected]` has a token from identity provider A. The mapped account domain is managed, so validation doesn't apply and sign-in is allowed.--This option is appropriate for organizations that have many federated domains and want to protect federated trusts while leaving managed accounts unaffected.+- [email protected] has a token from identity provider A. The mapped account domain is federated, so validation applies. Because the root domains don't match, sign-in is blocked.+- [email protected] has a token from identity provider A. The mapped account domain is federated, so validation applies. Because the root domains match, sign-in is allowed.+- [email protected] has a token from identity provider A. The mapped account domain is managed, so validation doesn't apply and sign-in is allowed. ### `allManaged` -Validates only users whose mapped Microsoft Entra account domain is managed. Managed domains are protected, while federated domains are excluded from validation.--- `[email protected]` has a token from identity provider A. The mapped account domain is managed, so validation applies. Because the domains don't match, sign-in is blocked.-- `[email protected]` has a token from identity provider A. The mapped account domain is managed, so validation applies. Because the domains don't match, sign-in is blocked.-- `[email protected]` has a token from identity provider A. The mapped account domain is federated, so validation doesn't apply and sign-in is allowed.+Validates only users whose mapped Microsoft Entra account domain is managed. Managed domains are protected, while federated domains are excluded from validation. This option is appropriate when an organization wants to protect managed identities from tokens from unrelated federated domains but has historical federated-to-federated cross-domain scenarios that it isn't ready to break. -This option is appropriate when an organization wants to protect managed identities from tokens from unrelated federated domains but has historical federated-to-federated cross-domain scenarios that it isn't ready to break.+- [email protected] has a token from identity provider A. The mapped account domain is managed, so validation applies. Because the domains don't match, sign-in is blocked.+- [email protected] has a token from identity provider A. The mapped account domain is managed, so validation applies. Because the domains don't match, sign-in is blocked.+- [email protected] has a token from identity provider A. The mapped account domain is federated, so validation doesn't apply and sign-in is allowed. ### `enumerated` -Blocks sign-in if the user's mapped account domain is included in the specified domain list and the incoming token's root domain doesn't match.+Blocks sign-in if the user's mapped account domain is included in the specified domain list and the incoming token's root domain doesn't match. This option supports phased rollout. For example, an organization can validate selected domains that are ready for enforcement while temporarily excluding domains that require additional testing or migration. The following example validates three domains: @@ -253,11 +230,10 @@ Assume that the tenant also contains `domainD.com` and `domainE.com`: - `[email protected]` has a token from identity provider B. The mapped account domain is in the enumerated list, so validation applies. Because the domains don't match, sign-in is blocked. - `[email protected]` has a token from identity provider B. The mapped account domain isn't in the enumerated list, so validation doesn't apply and sign-in is allowed. -This option supports a phased rollout. For example, an organization has 50 federated domains and has verified that 20 domains are ready for enforcement and should never allow cross-domain sign-in. The organization configures the 20 domains as validated and leaves the other 30 domains excluded. This configuration lets the organization gradually tighten security, avoid breaking acquisition or legacy trust models, and pilot enforcement before moving to `all`. ### `allManagedAndEnumeratedFederated` -Validates all managed domains and only the federated domains explicitly listed in the policy. Federated domains that aren't listed are excluded from validation.+Validates all managed domains and only the federated domains explicitly listed in the policy. Federated domains that aren't listed are excluded from validation. This option provides immediate protection for all managed domains and gradual rollout for federated domains. Assume that `domainA.com`, `domainB.com`, and `domainC.com` are federated, and `domainD.com` and `domainE.com` are managed. The following example enumerates two federated domains: @@ -279,9 +255,15 @@ Validation applies to: - `domainD.com` and `domainE.com`, because they're managed. - `domainA.com` and `domainB.com`, because they're enumerated federated domains. -Validation doesn't apply to `domainC.com` because it's federated but isn't included in the enumerated list.+### `none` -This option provides immediate protection for all managed domains and a gradual rollout for federated domains. For example, an organization has 100 federated domains and 10 managed domains. The organization knows that managed domains should never participate in cross-domain sign-in, but only 15 federated domains have been fully validated for enforcement. The organization can validate all 10 managed domains and the 15 validated federated domains while excluding the remaining 85 federated domains until testing is complete.+Disables cross-domain validation. No root-domain matching occurs.+This setting can be used to preserve intentional cross-domain sign-in behavior, such as certain legacy, acquisition, coexistence, or migration scenarios. However, it removes the additional domain-consistency protection provided by Federated Token Validation Policy.++For example, `[email protected]` signs in by using a token from identity provider A for `domainA.com`. The token is associated with `domainA.com`, but the mapped user account belongs to `domainB.com`. Because validation is disabled, sign-in is allowed.++> [!WARNING]+> With this option, Microsoft Entra ID doesn't apply the additional validation that checks whether the sign-in domain matches the expected root domain of the mapped account. If a trusted federated identity provider is compromised, malicious, or improperly configured, the impact could extend beyond its intended domain scope. Use this setting only when there's a documented business requirement and appropriate compensating controls are in place. ## Frequently asked questions @@ -303,11 +285,9 @@ The expected error is `AADSTS5000820`, which indicates that Federated Token Vali ### Can an administrator allow cross-domain sign-in? -Yes. An administrator can allow cross-domain sign-in by setting the `rootDomains` property of the `validatingDomains` resource to `none`. This configuration allows sign-in scenarios in which the authentication domain differs from the user's UPN domain.--When this option is enabled, Microsoft Entra ID doesn't verify that the sign-in domain matches an expected domain for authentication. If a federated identity provider is compromised or malicious, it might be able to authenticate users outside its intended domain scope. This configuration can increase the impact of a federation compromise from a single domain to potentially the entire tenant.+Yes. An administrator can allow cross-domain sign-in by configuring the `validatingDomains` resource to use a less-restrictive setting, including [`none`](strengthen-federated-sign-in-security.md#none). -Organizations that use this setting should rely on controls such as multifactor authentication, Conditional Access, trusted identity providers, and application-authorization policies.+This configuration can be used for intentional cross-domain scenarios but removes the additional domain-consistency validation layer. Organizations should use less-restrictive settings only when required and should apply appropriate compensating controls. ## Next steps