How to Move From AD FS to Cloud Authentication and Retire Token-Signing Risk

Retrospective: this article looks back at events from December 2020, written in 2026 with the benefit of hindsight.

The SolarWinds attackers used stolen AD FS token-signing certificates to forge SAML tokens (Golden SAML) and access Microsoft 365. Moving authentication from AD FS to Entra ID removes that attack path and reduces on-premises infrastructure. Here is how to migrate.

Step 1: Choose the target method

• Password hash synchronization (PHS) — Microsoft's recommended option: simple, resilient, and enables leaked credential detection.
• Pass-through authentication (PTA) — passwords validated on-premises through agents, if policy requires it.

Step 2: Inventory AD FS usage

List every relying party trust on AD FS: Microsoft 365, plus any third-party SaaS and internal applications. Use the AD FS application activity report in Entra ID to see which apps can move to Entra ID SSO.

Step 3: Migrate applications

Configure each SaaS app for SSO directly with Entra ID (SAML or OIDC), test with pilot users and switch over.

Step 4: Prepare Microsoft 365 cutover

• Enable PHS in Entra Connect (even if you plan PTA, as a backup).
• Recreate any AD FS claim rules and access policies as Conditional Access policies.
• Use staged rollout to move pilot groups to cloud authentication without changing domain federation.

Step 5: Convert domains

When pilots succeed, convert federated domains to managed authentication.

Step 6: Decommission AD FS

Remove relying party trusts, then retire AD FS and Web Application Proxy servers. Monitor sign-in logs for anything still trying to use them.

Until you migrate

Treat AD FS servers as Tier 0, deploy Defender for Identity sensors on them, protect the token-signing certificate, and alert on federation setting changes in Entra ID.