← All articles

Retiring ADFS: A Pragmatic Migration Path Off Federation Infrastructure

9 June 2026· 6 min read· ADFS· Entra ID· Migration· Authentication
Retiring ADFS: A Pragmatic Migration Path Off Federation Infrastructure
Figure - a phased ADFS exit: discover, migrate, modernise, staged cutover, decommission.Download diagram (SVG)

I have sat on both sides of this one: I designed and deployed a globally resilient ADFS 2016 environment for an international law firm, and years later I led the architecture to retire ADFS entirely at a major UK insurer. Both were the right call at the time. The difference is what the platform ecosystem could do natively.

Why retire it

Every ADFS farm is Tier 0 infrastructure: token-signing certificates that must be protected like domain controller secrets, WAP servers in the DMZ, patching, capacity, and a certificate rotation ceremony that someone has forgotten how to perform. When cloud-side authentication can meet your requirements, the farm is pure liability - attack surface plus operational cost with no differentiating value.

The decision framework

Inventory every relying party and ask three questions:

  • Can the application federate directly with your cloud identity provider using SAML or OIDC as an enterprise application?
  • Do any authentication rules depend on ADFS-specific claim pipeline logic that has no Conditional Access or claims-mapping equivalent?
  • Is there certificate-based or device-based authentication logic that needs a redesigned home?

In my experience the honest blocker list is short and shrinks every year. Most “we need ADFS” claims decompose into “we have not looked at this app since 2017”.

Choose the sign-in model deliberately

For the user authentication path, password hash synchronisation with seamless SSO is the default I recommend - it removes on-premises availability from the sign-in critical path and unlocks leaked-credential detection. Pass-through authentication remains an option where policy genuinely prohibits hash synchronisation, but recognise that you are keeping an on-premises dependency in the sign-in path and architect its resilience accordingly.

Sequencing the cutover

The migration is a programme, not a weekend: migrate relying parties app by app to direct federation, convert the user sign-in method using staged rollout to pilot cohorts, run the farm in parallel while telemetry proves nothing still calls it, then decommission formally - including the WAP estate, the service accounts, and the certificates. The telemetry step is where discipline pays: ADFS logs will surface the forgotten integration test rig that would otherwise page you at 2am post-cutover.

The end state is fewer Tier 0 assets, a simpler protocol stack, and an authentication path that improves without you patching it. Few identity projects offer that much risk reduction for that little regret.

Have an identity challenge worth solving?

I take a small number of freelance and contract engagements each year.

Start a conversation