Microsoft's edit · Federated sign-in security requirements

22 title: Strengthen federated sign-in security

33 description: Learn how Federated Token Validation Policy strengthens federated sign-in security by preventing cross-domain authentication in Microsoft Entra ID.

44 ms.topic: concept-article

5 −ms.date: 08/18/2026

5 +ms.date: 08/25/2026

66 ai-usage: ai-assisted

77 # 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.

88 ---

99

1010 # Strengthen federated sign-in security in Microsoft Entra ID

1111

12 −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.

12 +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.

1313

14 −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.

14 +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.

1515

1616 > [!IMPORTANT]

1717 > 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.

2020

2121 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.

2222

23 −### What is cross-domain sign-in?

24 −

25 −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.

26 −

27 −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.

28 −

29 −> [!NOTE]

30 −> 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.

31 −

3223 ### Simplified federated sign-in flow

3324

3425 1. A user enters a UPN, such as `[email protected]`.

3526 1. Microsoft Entra ID identifies the domain as federated and directs authentication to the configured identity provider.

3627 1. The identity provider authenticates the user and returns a signed federation token.

37 −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.

38 −1. Federated Token Validation Policy determines whether an additional domain-consistency rule should block the sign-in.

28 +1. Microsoft Entra ID validates the token, including its signature, issuer, validity period, and trust relationship.

29 +1. Microsoft Entra ID maps the assertion to a Microsoft Entra user account.

30 +1. Microsoft Entra ID applies applicable authentication, Conditional Access, and multifactor authentication requirements.

31 +1. Federated Token Validation Policy can apply an additional domain-consistency validation before sign-in completes.

3932

40 −## How Federated Token Validation Policy works

33 +## Existing validation in federated sign-in

4134

42 −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.

35 +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.

4336

44 −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.

37 +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.

4538

46 −If the root domains don't match, Microsoft Entra ID rejects the authentication request.

39 +## How Federated Token Validation Policy strengthens federation security

4740

41 +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.

42 +

43 +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.

44 +

45 +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.

46 +

4847 | Scenario | Expected result with strict domain matching |

4948 | --- | --- |

5049 | The federation realm root domain matches the user UPN root domain. | Sign-in can continue, subject to all other authentication and policy checks. |

5150 | The federation realm root domain differs from the user UPN root domain. | Sign-in is blocked by Federated Token Validation Policy. |

5251 | 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. |

53 −| 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. |

52 +| 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. |

5453

55 −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.

54 +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.

5655

57 −### Subdomain sign-in behavior

56 +### What is cross-domain sign-in?

5857

59 −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.

58 +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.

6059

61 −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.

60 +For example, a token issued through the trust for `domainB.com` maps to a user whose UPN belongs to `domainA.com`.

6261

63 −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.

62 +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.

6463

65 −## Security risk without the policy

64 +> [!NOTE]

65 +> 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.

6666

67 −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.

67 +## Additional protection provided by the policy

6868

69 −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.

69 +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.

7070

71 −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.

71 +The relevant attack scenario requires several prerequisites, including:

7272

73 −For example, an attacker who controls realm A's identity provider and knows the immutable ID of a user in realm B could:

73 +- A tenant with multiple federated domains or federation realms.

74 +- A compromised, malicious, or improperly controlled trusted identity provider.

75 +- Knowledge of the target user's immutable ID or source anchor.

76 +- An identity provider or identity store capable of issuing or configuring arbitrary source anchor values.

7477

75 −- Create a spoofed account in realm A that uses that immutable ID.

76 −- Authenticate through realm A.

77 −- Illegitimately access the user's account in realm B.

78 +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.

7879

80 +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.

81 +

7982 ### Example cross-realm impersonation scenario

8083

81 −Assume a Microsoft Entra tenant contains the following configuration:

84 +Assume a Microsoft Entra tenant contains:

8285

8386 - Federated domain `idpA.com`.

8487 - Federated domain `idpB.com`.

98101 | Identity provider A | `[email protected]` | `user1A` |

99102 | Identity provider B | `[email protected]` | `user2B` |

100103

101 −An attacker could create another user in identity provider B:

104 +If identity provider B is compromised or permits arbitrary source anchor values, an attacker could create another user:

102105

103106 | Location | User | Source anchor |

104107 | --- | --- | --- |

105108 | Identity provider B | `[email protected]` | `user1A` |

106109

107 −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.

110 +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.

108111

109 −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.

112 +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.

110113

111 −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.

114 +### Subdomain sign-in behavior

112115

116 +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.

117 +

118 +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.

119 +

120 +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.

121 +

113122 ## How Microsoft is strengthening security

114123

115124 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.

116125

117 −- A blocked authentication request is expected to return error `AADSTS5000820`: **Sign-in blocked by Federated Token Validation policy. Contact your administrator for details.**

118 −- 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.

126 +A blocked authentication request is expected to return error `AADSTS5000820`: **Sign-in blocked by Federated Token Validation policy. Contact your administrator for details.**

119127

128 +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.

129 +

120130 > [!IMPORTANT]

121131 > 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.

122132

126136

127137 Identify all federated domains in the tenant, and confirm which domains have an associated `internalDomainFederation` configuration.

128138

129 −### Identify cross-domain sign-in dependencies

139 +### Identify intentional cross-domain sign-in dependencies

130140

131141 Review intentional cross-domain sign-in scenarios, including:

132142

134144 - Coexistence environments.

135145 - Shared identity providers.

136146 - Migration projects.

137 −- Configurations where users might authenticate through a federation realm that differs from their UPN domain.

147 +- Configurations where users authenticate through a federation realm that differs from their UPN domain.

138148

139149 ### Validate representative sign-in scenarios

140150

141151 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.

142152

143 −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.

144 −

145 −### Review domain and trust relationships

146 −

147 −Examine:

148 −

149 −- Domain hierarchies.

150 −- Federation trust relationships.

151 −- Identity-provider configurations.

152 −- Scenarios in which users might authenticate through a domain other than their UPN domain.

153 +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.

153154

154155 ### Monitor for AADSTS5000820

155156

156157 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.

157158

158 −### Avoid reducing policy protections

159 +### Evaluate policy exceptions carefully

159160

160 −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.

161 +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.

161162

162 −> [!IMPORTANT]

163 −> 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.

164 −>

165 −> 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.

163 +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.

166164

167165 ## Policy administration

168166

182180

183181 The `rootDomains` property defines the types of domains to which validation applies.

184182

185 −### `none`

186 −

187 −Disables cross-domain validation completely. No root-domain matching occurs. This option is the least secure and is highly discouraged.

188 −

189 −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.

190 −

191 −> [!WARNING]

192 −> 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.

193 −>

194 −> 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.

195 −>

196 −> If you use this setting, use controls such as multifactor authentication, Conditional Access, trusted identity providers, and application-authorization policies to protect access.

197 −

198 −Typical use cases include legacy tenants, complex acquisition scenarios, and organizations that rely on historical cross-domain federation behavior.

199 −

200183 ### `all`

201184

202 −Validates every verified domain in the tenant. This option is the strictest setting.

203 −

204 −- `[email protected]` signs in by using a token from identity provider A for `domainA.com`. The root domains match, so sign-in is allowed.

205 −- `[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.

185 +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.

206186

207 −This option is appropriate for organizations that want to eliminate all cross-domain sign-in scenarios or require the highest security posture.

187 +- [email protected] signs in by using a token from identity provider A for domainA.com. The root domains match, so sign-in is allowed.

188 +- [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.

208189

209190 ### `allFederated`

210191

211 −Validates only users whose mapped Microsoft Entra account domain is federated. Federated domains are protected, while managed domains are excluded from validation.

212 −

213 −Assume that `domainA.com` and `domainB.com` are federated, and `domainC.com` is managed:

192 +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.

214193

215 −- `[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.

216 −- `[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.

217 −- `[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.

194 +Assume that domainA.com and domainB.com are federated, and domainC.com is managed:

218195

219 −This option is appropriate for organizations that have many federated domains and want to protect federated trusts while leaving managed accounts unaffected.

196 +- [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.

197 +- [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.

198 +- [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.

220199

221200 ### `allManaged`

222201

223 −Validates only users whose mapped Microsoft Entra account domain is managed. Managed domains are protected, while federated domains are excluded from validation.

224 −

225 −- `[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.

226 −- `[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.

227 −- `[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.

202 +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.

228203

229 −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.

204 +- [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.

205 +- [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.

206 +- [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.

230207

231208 ### `enumerated`

232209

233 −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.

210 +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.

234211

235212 The following example validates three domains:

236213

253230 - `[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.

254231 - `[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.

255232

256 −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`.

257233

258234 ### `allManagedAndEnumeratedFederated`

259235

260 −Validates all managed domains and only the federated domains explicitly listed in the policy. Federated domains that aren't listed are excluded from validation.

236 +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.

261237

262238 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:

263239

279255 - `domainD.com` and `domainE.com`, because they're managed.

280256 - `domainA.com` and `domainB.com`, because they're enumerated federated domains.

281257

282 −Validation doesn't apply to `domainC.com` because it's federated but isn't included in the enumerated list.

258 +### `none`

283259

284 −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.

260 +Disables cross-domain validation. No root-domain matching occurs.

261 +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.

285262

263 +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.

264 +

265 +> [!WARNING]

266 +> 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.

267 +

286268 ## Frequently asked questions

287269

288270 ### Does this change how the identity provider authenticates the user?

303285

304286 ### Can an administrator allow cross-domain sign-in?

305287

306 −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.

307 −

308 −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.

288 +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).

309289

310 −Organizations that use this setting should rely on controls such as multifactor authentication, Conditional Access, trusted identity providers, and application-authorization policies.

290 +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.

311291

312292 ## Next steps

313293

Federated sign-in security requirements

Microsoft's edit · 26 Aug 15:50 UTC