What is staged rollout in Microsoft Entra ID?

Staged rollout lets you move selected groups of users from a federated domain to cloud authentication (password hash sync, pass-through authentication or certificate-based authentication) without converting the domain. It's a temporary testing mechanism: Microsoft recommends converting the domain to managed once testing succeeds and not keeping a permanent mix.

How do I convert a federated domain to managed in Microsoft Entra ID?

If AD FS was configured with Entra Connect, run the wizard task Change user sign-in and choose password hash synchronization or pass-through authentication. Otherwise, connect with Microsoft Graph PowerShell and run Update-MgDomain -DomainId contoso.com -AuthenticationType Managed. The conversion can take up to 60 minutes.

Should I choose password hash sync or pass-through authentication?

Microsoft recommends password hash sync for cloud authentication, and the AD FS decommission guide says pass-through authentication should be used only when regulations prohibit synchronizing any password information to the cloud. PTA requires agents on-premises; two or three are usually enough, and a tenant can register up to 12.

How many groups can I use with staged rollout?

Up to 10 groups per feature, so 10 each for password hash sync, pass-through authentication and seamless SSO. There's no limit on users per group, but nested and dynamic groups aren't supported, and a group added for the first time should have no more than 200 members to avoid a time-out.

AD FS to Entra Cloud Authentication with Staged Rollout

To retire AD FS, enable password hash sync (or pass-through authentication agents) and seamless SSO, then use staged rollout to move pilot groups to cloud sign-in while the domain stays federated. When the pilots succeed, convert each domain with the Entra Connect wizard task Change user sign-in or with Update-MgDomain -DomainId contoso.com -AuthenticationType "Managed", turn staged rollout off, and watch AD FS for at least a week. Once no relying party has traffic, remove the Microsoft 365 relying party trust and decommission the farm. Back up the federation settings and the relying party trust first, so you can roll back with New-MgDomainFederationConfiguration.

Who this is for and what you will have at the end

This guide is for administrators whose Microsoft Entra domains are federated with AD FS and who want users to authenticate in Microsoft Entra ID instead. It assumes Microsoft Entra Connect Sync already synchronizes the users and that you're a Hybrid Identity Administrator.

At the end you will have:

A documented and backed-up federation configuration with a tested rollback path.
Pilot users signing in with cloud authentication through staged rollout.
Each federated domain converted to managed authentication.
AD FS and Web Application Proxy servers removed cleanly.

Requirement	Password hash sync	Pass-through authentication	Keep federation
Users sign in with on-premises password	Yes	Yes	Yes
Cloud MFA and Conditional Access	Yes	Yes	Yes
No password hashes stored in the cloud	No	Yes	Yes
On-premises MFA solution	No	No	Yes
On-premises infrastructure needed for sign-in	None beyond sync	Authentication agents	AD FS farm and proxies

Microsoft recommends password hash sync for cloud authentication, and the AD FS decommission guide reserves pass-through authentication for cases where regulation forbids synchronizing any password information. Certificate-based authentication in Microsoft Entra ID is the third option if users authenticate with certificates today.

If you choose PTA, deploy agents close to your domain controllers. Two or three agents are enough for most tenants, a tenant can register at most 12, and the first agent always runs on the Entra Connect server. Don't use the Entra Connect server for the additional agents.

Prerequisites

Hybrid Identity Administrator to configure staged rollout.
Domain Administrator for each forest where you enable seamless SSO.
Entra Connect Sync on a current release. Microsoft notes that a current Connect server shortens the move from hours to minutes. If you plan to enable PTA through the wizard, avoid 2.6.91.0: a bug in that release could make PTA registration fail, fixed in 2.6.92.0.
Cloud-only security groups for the pilot. On-premises groups work but add sync latency.
Company branding and the Conditional Access policies that the migrated users need, configured before they move.
Combined registration for MFA and SSPR, if you use Microsoft Entra MFA.
The synchronizeUpnForManagedUsersEnabled setting set to true, otherwise UPN changes for licensed managed users don't sync.
Microsoft Entra Connect Health for AD FS, so you can see which relying parties still receive traffic.

Step 1: Document and back up federation

Record the current federation settings for each domain:

Connect-MgGraph -Scopes "Domain.Read.All"
Get-MgDomainFederationConfiguration -DomainId contoso.com | Format-List

Look specifically for customized PreferredAuthenticationProtocol, federatedIdpMfaBehavior, SupportsMfa (used only when federatedIdpMfaBehavior isn't set) and PromptLoginBehavior. You need these values to rebuild federation if you roll back.

Back up AD FS itself. On the primary AD FS server, export the Microsoft 365 relying party trust with its claim rules:

(Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML "C:\temp\O365-RelyingPartyTrust.xml"

For a full farm backup, use the AD FS Rapid Restore Tool.

Understand how MFA works today

While domains are federated, MFA can come from AD FS or from Microsoft Entra ID. The domain's federatedIdpMfaBehavior controls which:

Value	Behavior
`acceptIfMfaDoneByFederatedIdp`	Accept MFA done by AD FS; otherwise Microsoft Entra ID performs MFA (default when nothing is set)
`enforceMfaByFederatedIdp`	Accept MFA done by AD FS; otherwise redirect to AD FS for MFA
`rejectMfaByFederatedIdp`	Always perform Microsoft Entra MFA and ignore AD FS MFA claims

If users currently satisfy MFA at AD FS, for example with an on-premises MFA server or adapter, they must be registered for Microsoft Entra MFA methods before they move. After conversion, AD FS is no longer in the sign-in path.

Step 2: Inventory what still depends on AD FS

Converting the Microsoft 365 domain doesn't affect other relying parties in the farm, but you can't retire AD FS until they move too.

Relying party trusts. List every trust and use Connect Health or AD FS event logs to see which have traffic. SaaS apps can be reconfigured to authenticate with Microsoft Entra ID through the app gallery or an app registration. On-premises apps can use Microsoft Entra application proxy.
Access control policies. Replace AD FS access control policies with Conditional Access policies. Microsoft also recommends a Conditional Access policy that blocks legacy authentication.
Sign-in page customizations. An onload.js customization can't be reproduced in Microsoft Entra ID. Users always sign in with a UPN or email address, and the page uses company branding.
Devices and VDI. Windows 10 earlier than 1903 and users with non-routable on-premises UPNs fall back to the AD FS WS-Trust endpoint. Non-persistent VDI on Windows 10 1903 or later must stay on a federated domain. Windows Hello for Business hybrid certificate trust with AD FS as registration authority isn't supported in staged rollout.

Step 3: Prepare password hash sync, PTA and seamless SSO

Password hash sync

Enable Password hash synchronization on the Optional features page of the Entra Connect wizard. Let a full password hash sync cycle complete so every user's hash is in Microsoft Entra ID before anyone moves.

Pass-through authentication

On a domain-joined server running Windows Server 2016 or later with TLS 1.2 enabled (not the Entra Connect server), download and install the Microsoft Entra Connect authentication agent, then install more agents for high availability. Review your Microsoft Entra smart lockout settings so on-premises accounts aren't locked out by attackers.

Seamless SSO

Seamless SSO gives domain-joined Windows 7 and 8.1 devices silent sign-in; Windows 10 and later use the Primary Refresh Token, and Apple devices can use the Microsoft Enterprise SSO plug-in. To enable seamless SSO without changing federation, run this on the Entra Connect server:

cd "$env:ProgramFiles\Microsoft Azure Active Directory Connect"
Import-Module "$env:ProgramFiles\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1"
Import-Module .\AzureADSSO.psd1
 
New-AzureADSSOAuthenticationContext            # Hybrid Identity Administrator sign-in
Get-AzureADSSOStatus | ConvertFrom-Json
 
$creds = Get-Credential                        # Domain Administrator for the forest
Enable-AzureADSSOForest -OnPremCredentials $creds

This creates the AZUREADSSOACC computer account in the forest. Repeat for each forest, and deploy the seamless SSO URLs to the intranet zone by Group Policy. Seamless SSO applies only to users selected for staged rollout and doesn't affect existing federation.

Step 4: Enable staged rollout for pilot groups

Sign in to the Microsoft Entra admin center as a Hybrid Identity Administrator.
Browse to Entra ID > Entra Connect > Connect sync.
Under Staged rollout of cloud authentication, select Enable staged rollout for managed user sign-in.
Turn on the features: Password Hash Sync and Seamless single sign-on, or Pass-through authentication and Seamless single sign-on. Combining PHS and PTA in staged rollout isn't supported.
Add the pilot groups to each feature.

Limits and behavior to plan around:

Up to 10 groups per feature; no limit on users per group.
No nested groups, no dynamic groups, and a group that contains contact objects can't be added.
When you first add a group, keep it to 200 members to avoid a UX time-out; add more members afterwards. Membership edits can take up to 24 hours to apply.
Seamless SSO applies only to users who are in the seamless SSO group and in a PHS or PTA group.
Staged rollout applies only to synchronized users, and only to browser and modern authentication traffic. Legacy authentication such as POP3 and SMTP keeps using federation, as do apps that send a domain_hint.

A newly added user must complete one more interactive sign-in through AD FS before managed authentication applies. To avoid that, issue a Temporary Access Pass right after adding the user and have them sign in with it; Microsoft Entra ID evaluates the TAP before redirecting to AD FS. Removing a user also needs one more sign-in before they return to federation. SSPR and Identity Protection remediation can reset a user's staged rollout state and send them back to AD FS once.

What changes for pilot users

Password changes on-premises take up to 2 minutes to reach Microsoft Entra ID.
By default no password expiration applies to staged rollout users with PHS. Enabling CloudPasswordPolicyForPasswordSyncedUsersEnabled sets a fixed 90-day expiration from the on-premises password change.
SSPR with writeback isn't guaranteed to work consistently during staged rollout.

Step 5: Validate the pilot

Outside the corporate network, open https://myapps.microsoft.com in a private browser window and enter a pilot user's UPN. The user should see the Microsoft Entra branded sign-in page, not AD FS.
On a domain-joined device on the intranet, repeat the test. A seamless SSO user sees "Trying to sign you in" and then signs in silently.
In Sign-in logs, filter by the user and confirm the sign-ins.
On AD FS, check the event logs for sign-ins that still arrive from pilot users.

Staged rollout writes audit events when a feature is enabled, a group is added, and a user is enabled. The Hybrid Auth workbooks in the admin center show users added and removed and their sign-ins.

Grow the pilot in waves. Staged rollout isn't a permanent state; Microsoft advises against long-term mixed authentication because it can produce unexpected authentication flows.

Step 6: Convert the domains to managed

Plan a maintenance window outside business hours. Conversion can take up to 60 minutes, during which new browser sign-ins may not prompt for credentials. Modern authentication clients keep working on their refresh tokens. You don't have to convert all domains at once; start with a test domain or the one with the fewest users.

Option A: Entra Connect wizard

Use this if AD FS was configured through Entra Connect. Check under Additional tasks > Manage Federation > View federation configuration: if the AD FS farm appears, it was.

Open Entra Connect, select Configure, then Change user sign-in.
Sign in with a Global Administrator account.
On User sign-in, choose Password hash synchronization (and select Do not convert user accounts) or Pass-through authentication. Select Enable single sign-on if needed.
Enter Domain Administrator credentials on the Enable single sign-on page.
On Ready to configure, keep Start the synchronization process when configuration completes selected and select Configure.

This converts all federated domains at once. In the admin center, confirm Federation is Disabled, and Seamless single sign-on and Password Hash Sync are Enabled.

Option B: Microsoft Graph PowerShell, one domain at a time

Use this for domains not configured by Entra Connect, for third-party federation, or to convert domains individually. First run the wizard's Change user sign-in task as in Option A; on the User sign-in page, Do not configure is preselected, so federation stays on. In the admin center, confirm that Federation is Enabled and Password Hash Sync is Enabled before you convert. With PTA, confirm in the admin center that every agent shows Active before converting; converting with unhealthy agents risks an authentication outage.

Connect-MgGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"
 
Update-MgDomain -DomainId contoso.com -AuthenticationType "Managed"
 
Get-MgDomain -DomainId contoso.com | Select-Object Id, AuthenticationType

Afterwards, update the sign-in method in Entra Connect so it recognizes PTA as enabled.

Step 7: Finish the cutover

Turn staged rollout features Off once every domain is managed.
Retest sign-in with the same validation steps.
Roll over the seamless SSO Kerberos decryption key at least every 30 days. Run Update-AzureADSSOForest -OnPremCredentials $creds once per forest after the same module imports and New-AzureADSSOAuthenticationContext. Running it more than once per forest breaks seamless SSO until users' Kerberos tickets expire. It isn't needed on staging servers.
Monitor PTA agent servers and their event logs under Application and Service logs.

Rollback

If you need to return to federation, convert the domain back with New-MgDomainFederationConfiguration, using the values you documented in Step 1, and restore relying party trust claim rules from the exported XML if needed. Because the conversion can take up to an hour, schedule cutovers so that a rollback also fits inside the window.

Step 8: Decommission AD FS

Run cloud authentication for at least a week and watch Connect Health and AD FS logs. If a relying party still shows sign-ins, migrate that app first. When nothing is left:

Optionally take a final backup with the Rapid Restore Tool.
Remove AD FS entries from internal and external load balancers.
Delete the DNS records for the farm name.
On the primary server, run Get-AdfsProperties and note the CertificateSharingContainer DN.
If the configuration database is in SQL Server, delete it before uninstalling.
On each Web Application Proxy server, remove the AD FS published applications, then run Uninstall-WindowsFeature Web-Application-Proxy,CMAK,RSAT-RemoteAccess.
Starting with secondary nodes, run Uninstall-WindowsFeature ADFS-Federation,Windows-Internal-Database, then delete C:\Windows\WID\data\adfs\*.
Delete the AD FS TLS certificates, re-image the servers, and delete the AD FS service account.
Remove the content of the CertificateSharingContainer DN with ADSI Edit.

Troubleshooting

Pilot users still land on the AD FS page. The app sends domain_hint, the client uses legacy authentication, or the user hasn't done the extra federated sign-in yet. Use a TAP, or test through My Apps.

A user isn't moved after group membership changed. Membership edits can take up to 24 hours. Check that the group isn't nested or dynamic.

Seamless SSO doesn't sign users in silently. The user must be in both the seamless SSO group and a PHS or PTA group, and the SSO URLs must be in the intranet zone.

Update-AzureADSSOForest fails. Enter the domain admin in contoso\admin format and make sure the account isn't in Protected Users.

Device registration or PRT fails after cutover. Check for Windows 10 earlier than 1903 or non-routable UPNs, which relied on the AD FS WS-Trust endpoint.

UPN changes stop syncing after conversion. Enable synchronizeUpnForManagedUsersEnabled.

PTA and seamless SSO are configured separately from the sync engine and keep working if you later move synchronization to Cloud Sync, compared in Entra Cloud Sync vs Connect Sync. If the Entra Connect server itself is due for replacement, use a staging mode swing migration.

Checklist

Federation settings documented; relying party trust exported; Rapid Restore backup taken.
Every relying party and AD FS access control policy inventoried, with a target in Microsoft Entra ID.
Users registered for Microsoft Entra MFA if MFA happened at AD FS.
Full password hash sync completed; PTA agents active if used; seamless SSO enabled per forest.
Staged rollout pilots validated in sign-in logs and AD FS logs.
Domains converted (wizard or Update-MgDomain), staged rollout turned off.
Kerberos key rollover scheduled every 30 days.
AD FS quiet for at least a week before decommissioning.

Migrate from AD FS to Entra cloud authentication with staged rollout