Every AD FS farm holds a token-signing key that can mint a sign-in for any federated user, and the safest way to remove that risk is to stop needing AD FS at all. Microsoft recommends moving authentication and applications from AD FS to Microsoft Entra ID, and its tooling now covers each step: the AD FS application activity report, claim rule tests, one-click SAML app migration, staged rollout and domain conversion. This guide is the runbook for that move, from inventory through cutover to switching the servers off, with the rollback point at each stage. It is for identity architects and Windows administrators who own AD FS. Hardening AD FS while it still runs is covered in the AD FS Security Guide.
This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.
Key takeaways
- There is no AD FS end date to wait for. Microsoft has not announced a retirement of AD FS itself; the drivers are the security of the token-signing key, the host operating system lifecycle and the cost of running a farm.
- Migrate users first, then apps. Microsoft's decommission guidance recommends moving user authentication to password hash sync (PHS) or certificate-based authentication first, with pass-through authentication (PTA) only where rules forbid syncing password hashes.
- The activity report is your inventory. It lists every relying party with sign-ins in the last 30 days and grades each as Ready to migrate, Needs review or Additional steps required based on its claim rules.
- Staged rollout de-risks the cutover. Test cloud authentication with cloud groups before running Update-MgDomain to convert each domain to managed, a change that can take up to 60 minutes.
- Decommission means removing keys, not just servers. Wait for a week of zero AD FS traffic, then remove load balancer and DNS entries, uninstall WAP and AD FS, reimage the hosts, delete the service account and clean the certificate sharing container.
What is changing and why
With a federated domain, Entra ID trusts tokens signed by your AD FS farm. Anyone who obtains the token-signing certificate can forge SAML tokens for any user and bypass MFA, the technique known as Golden SAML (MITRE ATT&CK T1606.002). Adding or changing a federation trust in the tenant is itself an attack technique (T1484.002), as is tampering with hybrid authentication components (T1556.007). See the Golden SAML and Federation Trust Abuse Defence Guide.
Migration moves three things: user authentication (from AD FS to PHS, PTA or certificate-based authentication in Entra ID), applications (relying party trusts re-created as Entra enterprise applications) and access policy (AD FS access control policies and claim rules replaced by Conditional Access and Entra claims configuration).
| Sign-in method | How it works | Microsoft position | Consider when |
|---|---|---|---|
| Password hash sync (PHS) | Entra Connect syncs a hash of the password hash; Entra ID validates sign-ins | Recommended; preferred with certificate-based authentication | Default choice; no on-premises dependency at sign-in |
| Certificate-based authentication (CBA) | Entra ID validates X.509 certificates directly | Preferred option | Smart card or phishing-resistant certificate users |
| Pass-through authentication (PTA) | Agents on domain-joined servers validate passwords against AD | Only where regulation prohibits syncing password information | Strict data residency rules; needs agents (maximum 12 per tenant) |
Official timeline and current status
As checked on 8 November 2026, Microsoft has published no end of support date for the AD FS role. The dates that matter are those of the Windows Server version hosting the farm, plus your own project milestones.
| Item | Date or status | Implication |
|---|---|---|
| AD FS role | No retirement announced; Microsoft recommends moving to Entra ID | Plan on your own timetable, driven by risk |
| Windows Server 2016 (common AD FS host) | Extended support ends 13 January 2027 (06:59 Pacific Time, so the end of 12 January) | Farms on 2016 need migration or a host upgrade within weeks |
| Staged rollout | Temporary testing mechanism, not a permanent configuration | Plan the domain conversion, do not live in staged mode |
| One-click app migration | Available for SAML applications in the AD FS application migration view | Speeds up the simple majority of apps |
Who and what is affected
- Relying party trusts: every SaaS and line-of-business app federated through AD FS, including WS-Federation apps that one-click migration does not handle.
- Microsoft 365 sign-in: the "Microsoft Office 365 Identity Platform" trust and any custom claim rules on it.
- MFA: on-premises MFA providers plugged into AD FS, and the domain's federatedIdpMfaBehavior or SupportsMfa setting.
- Devices: Windows 10 earlier than 1903 that acquires a Primary Refresh Token through WS-Trust, non-persistent VDI, and Windows Hello for Business hybrid certificate trust, which uses AD FS as its registration authority.
- Legacy protocols: POP3, SMTP and older Outlook clients that authenticate through federation.
- Non-human identities: the AD FS service account (often a gMSA), Connect Health agents, and the token-signing and decryption certificates. See the Group Managed Service Accounts (gMSA) Guide.
Finding affected systems and identities
- Install Connect Health for AD FS: the migration dashboard needs Entra Connect plus the Connect Health AD FS agents, Entra ID P1 or P2, and a role such as Application Administrator, Cloud Application Administrator or (read-only) Global Reader or Report Reader.
- Read the AD FS application activity report: in the Entra admin centre under Monitoring and health, Usage and insights. It lists AD FS apps with active sign-ins in the last 30 days; the same data is available from Microsoft Graph (beta) through getRelyingPartyDetailedSummary. Microsoft's own relying parties are excluded.
- Triage claim rule test results: each app is graded, and failing rules are named.
- Find apps the report misses: relying parties with no sign-ins in 30 days (quarterly or annual processes) do not appear; list all trusts with Get-AdfsRelyingPartyTrust and compare.
- Document domain settings: run Get-MgDomainFederationConfiguration for each federated domain and record PreferredAuthenticationProtocol, federatedIdpMfaBehavior, SupportsMfa and PromptLoginBehavior.
| Claim rule test | What it flags | Entra approach |
|---|---|---|
| UNSUPPORTED_CONDITION_PARAMETER | Regex condition matching | Transformations such as IfEmpty(), StartWith(), Contains() |
| UNSUPPORTED_ISSUANCE_TRANSFORMATION | Regex claim transformation | Extract(), Trim(), ToLower() |
| UNSUPPORTED_ISSUANCE_CLASS | ADD used to build claims | Multiple claim transformations |
| EXTERNAL_ATTRIBUTE_STORE | Attribute store other than Active Directory (SQL, LDAP) | Sync the attribute to Entra ID or redesign the claim |
| CONDITION_MATCHES_UNSUPPORTED_ISSUER | Condition on an issuer other than AD or Entra ID | Review the claims provider design |
| RESTRICTED_CLAIM_ISSUED | Restricted claim that cannot be transformed | Agree an alternative claim with the app owner |
Migration options
Applications
- SAML apps graded Ready to migrate: use one-click migration, which creates the app registration and service principal, basic SAML settings, compatible claims and assignments. It does not migrate Conditional Access or signing certificates; the new app stays inactive until you redirect the app's sign-in to Entra ID.
- OIDC, OAuth and WS-Federation apps: register manually as app registrations or non-gallery enterprise applications; gallery connectors exist for many SaaS apps.
- Older on-premises protocols: publish through Entra Application Proxy or a Secure Hybrid Access partner.
- Stages per app: Microsoft describes moving from the AD FS app, to a test instance against a test tenant (optional), to a test instance against the production tenant, then production. Confirm the AD groups that gate access are synced and identical in Entra ID first.
Users and domains
- Prepare: upgrade Entra Connect to the latest version, enable PHS (and run a full sync) or deploy PTA agents away from the Entra Connect server, and enable Seamless SSO with Enable-AzureADSSOForest for each forest if older Windows clients remain.
- Replace policy: rebuild AD FS access control policies as Conditional Access, block legacy authentication, and set federatedIdpMfaBehavior to rejectMfaByFederatedIdp unless you rely on a third-party MFA provider during the transition.
- Back up: run the AD FS Rapid Restore Tool and export the Microsoft 365 relying party trust and its claim rules with Export-CliXML.
- Staged rollout: add cloud security groups (not nested or dynamic; up to 10 groups per feature, 200 users on first add) and test for at least a few weeks. Issuing a Temporary Access Pass right after adding a user avoids the extra federated sign-in.
- Convert domains: starting with the smallest or a test domain, run Update-MgDomain -DomainId <domain> -AuthenticationType "Managed" in a maintenance window, then confirm with Get-MgDomain. Domains can be converted one at a time.
Testing and rollback
- Staged rollout gaps: legacy authentication, apps sending domain_hint, non-persistent VDI and smart card users still go to federation during staged rollout, so test them separately before domain conversion.
- Group changes are slow: membership edits can take up to 24 hours, and moving a user in or out of scope requires one more sign-in on the old path.
- App rollback: point the application back at AD FS; the relying party trust should stay in place until the app has run on Entra ID through a full business cycle.
- Domain rollback: re-federate with New-MgDomainFederationConfiguration using the settings documented beforehand, and restore custom claim rules. Plan cutovers out of hours so rollback affects few users.
- Password expiry: decide how password expiry will apply to synced users before cutover; Microsoft notes that enabling CloudPasswordPolicyForPasswordSyncedUsersEnabled applies a fixed 90-day expiry and that programmatic changes to PasswordPolicies are not supported.
- Self-service password reset: SSPR with on-premises writeback is not guaranteed to work consistently for users in a staged rollout group, so tell pilot users how to get help, and confirm writeback after the domain conversion.
Decommissioning order
- Confirm no relying party has traffic for at least one week in Connect Health and the AD FS event logs; remove the Microsoft 365 relying party trust.
- Take a final backup (optional), then remove AD FS from internal and external load balancers and delete the farm DNS records.
- Record the CertificateSharingContainer distinguished name with Get-ADFSProperties; delete the SQL configuration database if one is used.
- Remove published applications and uninstall Web Application Proxy, then uninstall AD FS starting with secondary nodes.
- Delete the SSL certificates, reimage the servers with full disk formatting, delete the AD FS service account and clear the CertificateSharingContainer contents with ADSI Edit.
Risks of doing nothing
- Standing forgery risk: the token-signing key remains a single secret that grants access to every federated app.
- Unsupported hosts: farms on Windows Server 2016 lose security updates after January 2027.
- Half-migrated estates: moving apps but leaving domains federated keeps the farm, and its key, on the critical path.
- Policy signals: use Entra Conditional Access and Identity Protection for risk-based policy once apps move; AD FS access control policies use their own rule model.
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-2, IA-8, AC-2, CM-7 | Authentication of users and partners; account lifecycle for the service account; removing unneeded federation services |
| NIST CSF 2.0 | PR.AA-03, ID.AM-08 | Users and services authenticated; federation servers retired through their lifecycle |
| MITRE ATT&CK v20 | T1606.002, T1484.002, T1556.007 | Forged SAML tokens, trust modification and hybrid identity abuse that migration removes |
Metrics to track: relying parties remaining on AD FS; daily AD FS sign-ins, trending to zero; percentage of users on managed authentication; apps graded Additional steps required still open; days since the last AD FS sign-in before decommission; number of federated domains remaining.
Practitioner checklist
- Install Connect Health AD FS agents and export the application activity report and the full relying party list.
- Grade every app and assign owners for Needs review and Additional steps required.
- Back up AD FS with the Rapid Restore Tool and export the Microsoft 365 trust and claim rules.
- Enable PHS (or CBA, or PTA where required) and Seamless SSO where older clients need it.
- Rebuild access control policies as Conditional Access and block legacy authentication.
- Migrate SAML apps with one-click migration and the rest manually, in test then production stages.
- Run staged rollout with cloud groups, then convert domains one by one with Update-MgDomain.
- Wait for a week of zero AD FS traffic before removing trusts, DNS and load balancer entries.
- Uninstall WAP and AD FS, reimage hosts, delete the service account and clean the certificate container.
Standards and references
- Microsoft Learn: Migrate from federation to cloud authentication
- Microsoft Learn: Use the AD FS application migration to move AD FS apps to Microsoft Entra ID
- Microsoft Learn: Stages of AD FS application migration
- Microsoft Learn: Migrate to cloud authentication using Staged Rollout
- Microsoft Learn: AD FS decommission guide
- Microsoft Learn: Usage and insights report
- Microsoft Learn: Windows Server 2016 lifecycle
- MITRE ATT&CK: Forge Web Credentials, SAML Tokens
Related NHI Mgmt Group resources: AD FS Security Guide · Golden SAML and Federation Trust Abuse Defence Guide · Microsoft Entra Connect and Cloud Sync Hardening Guide · Conditional Access Guide