Entra federatedTokenValidationPolicy: the silent default change that blocks federated sign-ins

In mid-August 2026, Microsoft activates a default change in Microsoft Entra ID that causes unexpected sign-in failures for some organisations. The change concerns the federatedTokenValidationPolicy, a setting that governs how Entra handles federated sign-ins where the authentication token comes from a domain that does not match the user's UPN domain.

The change is not a new feature but a security measure announced earlier via Message Center notification MC1303719. For tenants whose federated domains were configured before December 2025, the stricter validation is now automatically enabled. For anyone who created a federated domain since then, the stricter rule was already in place. The rollout is phased and was in effect for most tenants worldwide by mid-August 2026.

What is the federatedTokenValidationPolicy?

Microsoft Entra supports federated authentication, where an external Identity Provider (IdP) issues a token that Entra then accepts to sign in the user. This is widely used in hybrid environments with Active Directory Federation Services (AD FS), as well as integrations with third parties such as Ping Identity, Okta, or other SAML-based systems.

The federatedTokenValidationPolicy determines how Entra handles a specific scenario: a token issued by a federated IdP for a domain that does not match the user's UPN domain. This is called cross-domain federation and is in most cases a configuration error or a legacy of a merger or acquisition where domains and users were never fully consolidated.

Under the old default, Entra accepted such tokens and allowed the user to sign in. Under the new default, the sign-in is blocked and the user receives error code AADSTS5000820: 'Sign-in blocked by Federated Token Validation policy'.

Who is affected by the change?

For most organisations, nothing changes. The change only affects tenants where users sign in via a federated IdP and where the token is issued for a domain other than the user's UPN domain. Concretely, there are three scenarios.

First, organisations that have merged or been acquired where users from one domain sign in via the federation setup of another domain without the UPN domains being consolidated. Second, environments with a central AD FS server handling multiple domains where the internalDomainFederation objects in Entra do not precisely match all user UPN domains. Third, integrations with external IdPs where the IdP issues tokens for a subdomain or alias domain that is not registered as a federated domain in Entra.

Organisations on a cloud-only setup, using Microsoft Entra Password Hash Sync or Pass-through Authentication (PTA), are not affected. The same applies to hybrid environments where UPN domains in AD and Entra are exactly aligned and consistently configured.

How do you diagnose whether your environment is at risk?

The first step is to check whether any federated domains are configured in your tenant at all. You do this via Microsoft Graph by retrieving the internalDomainFederation objects. For each federated domain object you can see which IdP is configured and which domain is included.

Next, check the Entra sign-in logs, available in the Entra portal under Monitoring, for error code AADSTS5000820. If you see this code in the logs before the default has been activated for your tenant, you are already affected and need to act immediately.

A third check is to compare the UPN domains of your users with the registered federated domains in Entra. If there are users whose UPN domain does not match the domain included in the internalDomainFederation configuration, you are at risk.

What do you do when users encounter AADSTS5000820?

There are two correct remediation paths. The recommended path is to repair the federation configuration so that the internalDomainFederation objects in Entra exactly match the UPN domains of the users who rely on them. In most cases, this means updating the federated domain in Entra or adding additional domains to the federation setup.

If a quick adjustment to the federation configuration is not possible, for example because you depend on an external IdP over which you have limited control, you can temporarily create a custom federatedTokenValidationPolicy with the setting rootDomains = none. This disables the strict validation for your tenant. Microsoft explicitly describes this as 'strongly discouraged' because it reverses the security measure, but it gives you time to correct the underlying configuration. Treat this as a temporary measure, not a permanent solution.

Whichever path you choose, actively monitor the sign-in logs as soon as you make a change. Entra Sign-in Logs offer filtering by error code, allowing you to confirm within minutes whether the correction has taken effect.

Why is Microsoft making this change?

The rationale behind the measure is protection against cross-domain sign-in risks. If an attacker manages to obtain a token for a domain that your federation setup accepts but that does not match the user's UPN domain, it can be used to authenticate in your tenant. The strict policy closes this attack path.

In most well-maintained Entra environments this risk does not exist because the federation configuration is tightly set up. But in environments that have grown over the years, through acquisitions, domain migrations, or ad-hoc integrations, there are sometimes federation objects that are configured more broadly than necessary. The new default forces a cleanup that IT teams should have done long ago.

What are the actions for today?

Three steps every IT administrator of a hybrid or federated Microsoft 365 tenant should take this week. First, check in the Entra portal which domains are configured as federated via the Custom domain names tab. Second, review the sign-in logs from the past three weeks for error code AADSTS5000820. If you see that code, the change is already in effect for you and users are already experiencing disruption or shortly will be. Third, compare the UPN domains in your user population with the configured federated domains.

For organisations that work fully cloud-native or use only password hash synchronisation or pass-through authentication, no action is required. The change only affects environments with an active federated IdP connection.

Do you have a hybrid or federated Microsoft 365 environment and want to know whether this change affects your users? Zarioh helps IT teams audit Entra configurations, uncover hidden federation risks, and build a migration plan toward a more robust identity architecture. Contact us for a no-obligation assessment.