Breaking Change: Error 5000820 Federated Token Validation Policy — Third-Party IDP Integration Blocked by UPN Domain Enforcement

SUMMARY

A recent backend change to Microsoft Entra ID's federated token validation policy (error 5000820) has broken third-party IDP federation for customers whose users' UPN domains do not match the federated domain. This change was not announced via deprecation notice, breaking change documentation, or Azure Service Health notification. We are requesting official guidance on the supported path forward.

BACKGROUND

We are Circle Security, an identity provider (IDP) offering passwordless FIDO2-based authentication via SAML federation with Microsoft Entra ID. Our product federates a domain in the customer's Entra tenant and authenticates users via QR-based FIDO2 challenge/response, eliminating passwords entirely.

Prior to late 2024, our federation setup worked correctly using the following approach:

• Federate a domain (e.g. circleaccess.com) in the customer's Entra tenant
• Match users to their Entra accounts via onPremisesImmutableId
• Return a SAML assertion with a NameID in the federated domain
• Users authenticate passwordlessly regardless of whether their UPN was on the federated domain or a separate managed domain

This worked reliably across multiple customer deployments.

WHAT BROKE

Starting in late 2024 / early 2025, Entra ID began rejecting SAML assertions with error 5000820 ("Federated Token Validation policy") when the authenticating user's UPN domain does not match the federated domain — even when onPremisesImmutableId correctly identifies the user.

This has been confirmed by a Microsoft MVP in the Entra Q&A community (https://learn.microsoft.com/en-us/answers/questions/5709748) as a deliberate backend enforcement change. However, we can find no official Microsoft documentation, deprecation notice, or migration guidance covering this specific change.

We have confirmed the following do NOT resolve the error:

• Adding a proxy/secondary email address matching the federated domain
• Correct immutableId mapping across domain boundaries
• Subdomain variations of the UPN domain

THE CUSTOMER IMPACT

Changing a user's UPN to match the federated domain is not a trivial operation for enterprise customers. The UPN is used as the primary identifier across Microsoft 365 workloads including Exchange Online, Teams, SharePoint, Intune, and third-party SaaS applications integrated via Entra SSO. Enterprise customers with mature Microsoft 365 tenants have told us directly that UPN changes would break dependent systems and require significant change management — making this a deployment blocker in practice, not just in theory.

Furthermore, federating the customer's primary UPN domain is its own risk: when a domain is federated, Entra immediately stops accepting passwords for all users on that domain, making a hard cutover with no pilot capability.

QUESTIONS

1. Is there official documentation for this policy change, and where can we find it?
2. What is the Microsoft-supported path for a third-party IDP to authenticate users whose UPN domain differs from the federated domain? Is the immutableId cross-domain mapping permanently removed, or is there a configuration to restore it?
3. Is there a mechanism to pilot federation for a subset of users on a managed domain without changing their UPNs — for example, via group-scoped federation or per-user federation policy?
4. Is there a supported way to federate a domain while preserving password authentication as a fallback for users on that domain during a transition period?
5. Is Microsoft's External Authentication Methods (EAM) framework the intended replacement for this use case? If so, is there guidance on migrating third-party IDPs from domain federation to EAM?

ENVIRONMENT

• Protocol: SAML 2.0
• Error code: 5000820
• Affected flow: Third-party IDP federation where user UPN domain ≠ federated domain
• Customer tenant type: Commercial (also affects hybrid Azure AD setups)
• Regression: Confirmed working prior to late 2024, broken without notice

We are happy to provide SAML traces, tenant configuration details, or participate in an engineering call. Please route to the Entra ID identity federation team if possible.