Request for Long-Term Supported Solution – Per-User Authentication Routing in a Federated Domain

Microsoft Entra does not provide a permanent group-based or per-user authentication-routing policy that splits users sharing the same federated UPN domain between the federated IdP and Microsoft Entra; the supported production design is to choose one authentication type for that domain and use Staged Rollout only to pilot a domain-wide migration.

Direct answers

• Per-user or group-based routing within the same federated domain: Not as a permanent production configuration. Home Realm Discovery uses the user’s UPN to determine the sign-in location; a user in a federated domain is directed to that domain’s configured IdP.^1^
• Same UPNs with permanently mixed authentication: No supported architecture in the cited documentation satisfies this requirement.
• A supported feature other than Staged Rollout: None documented for permanent, user-selective Microsoft 365 routing within one UPN domain.
• Staged Rollout for long-term coexistence: No. Microsoft explicitly defines it as a temporary testing mechanism and says it is not designed as a permanent configuration.^2^
• Recommended production approach: Pilot cloud authentication with selected groups, then convert the entire domain from federated to managed authentication. Microsoft recommends Password Hash Synchronization (PHS) for cloud authentication.^3^

Recommended implementation

1. Select the final domain-wide authentication model.
   • Keep the domain federated: all normal interactive sign-ins for that UPN suffix continue to route to xyz.
   • Move the domain to managed authentication: users authenticate through Microsoft Entra using PHS, Pass-through Authentication, or an applicable cloud authentication method.
2. Prepare cloud authentication.
   • Microsoft recommends PHS.
   • Configure the required Microsoft Entra authentication methods, Conditional Access, MFA, tenant branding, and recovery processes before migration.^3^
3. Use Staged Rollout only for a pilot.
   • A Hybrid Identity Administrator is required.
   • Use a cloud-managed security group where possible.
   • Nested and dynamic groups are unsupported.
   • Staged Rollout applies to Microsoft Entra Connect-provisioned users and browser or modern-authentication traffic.^2^
4. Account for the initial sign-in behavior already encountered.
   • A newly included user normally completes one additional interactive federated sign-in before managed authentication takes effect.
   • TAP is the documented workaround: add the user to the Staged Rollout group, issue a TAP, and have the user use it for the initial Microsoft Entra sign-in.^2^
5. Validate documented exceptions. Staged users can still reach federation through legacy authentication, applications supplying domain_hint, unsupported Windows/PRT scenarios, or cached sessions. SSPR with on-premises writeback is not guaranteed while a security group is in Staged Rollout.^2^
6. Perform the domain-wide cutover.
   • Record the current federation configuration.
   • Schedule a maintenance window and document rollback.
   • Convert the domain from federated to managed.
   • Allow for up to 60 minutes during domain conversion.
   • Validate representative browser, Office, device, MFA, Conditional Access, and recovery sign-ins in the Entra sign-in logs.^3^

If permanent mixed authentication is mandatory

The supported boundary must be changed from users/groups to domains. For example:

• [Email] — federated to xyz
• [Email] — managed by Microsoft Entra

A subdomain normally inherits its parent’s authentication type. It must first be promoted to an independent root domain through Microsoft Graph and then changed to Managed.^4^

Connect-MgGraph -Scopes "Domain.ReadWrite.All","Directory.AccessAsUser.All"

# After adding, verifying, and promoting cloud.contoso.com:
Update-MgDomain -DomainId "cloud.contoso.com" `
  -BodyParameter @{ AuthenticationType = "Managed" }

Get-MgDomain -DomainId "cloud.contoso.com"

This requires appropriate Microsoft Graph domain permissions and changes the selected users’ sign-in UPN suffix, so it does not meet the requirement to preserve their existing UPNs. Email delivery addresses can be planned separately, but they must not be treated as equivalent to the authentication UPN without validating the affected Microsoft 365 workloads.

Application-level HRD policies are also not an equivalent solution. They control a particular application’s acceleration, domain-hint handling, or direct ROPC password validation; they do not create a general per-user Microsoft 365 routing policy.^1^

References

1. Home Realm Discovery for an application
2. Migrate to cloud authentication using Staged Rollout
3. Migrate from federation to cloud authentication
4. Change subdomain authentication type in Microsoft Entra ID