Table of contents
If you ask whether Active Directory Federation Services (AD FS) is end of life, the technically accurate answer is no: AD FS is a Windows Server role, and support depends on the Windows Server version you run. But if you look at where Microsoft is investing, the direction is clear. New identity capabilities such as Conditional Access, phishing-resistant MFA, risk-based controls, and modern app integration are centered on Microsoft Entra ID.
Microsoft also publishes an official AD FS decommission guide and guidance to migrate from federation to cloud authentication. That combination tells the real story: AD FS is still supported, but many organizations are choosing to retire it.
This guide explains the real status of AD FS in 2026, what Microsoft's migration path handles well, and what to do with the application tail that often keeps AD FS farms alive years after the main migration is done.
The Real Status of AD FS in 2026
AD FS has not been formally end-of-lifed as a standalone product. It remains part of Windows Server, so the support window depends on the Windows Server release underneath it.
The practical issue is different. AD FS is no longer where modern identity capabilities are moving fastest. Microsoft Entra ID is where most organizations now centralize SSO, MFA, Conditional Access, device posture, risk-based sign-in, and modern application access policy.
That is why the better question is not only "when does AD FS support end?" It is "what business or security reason do we still have to keep federation servers and Web Application Proxy infrastructure running?"
Why Organizations Are Choosing to Retire AD FS
- Security surface: AD FS is sensitive identity infrastructure. It includes federation servers, token-signing material, and often Web Application Proxy servers exposed at the edge.
- Operational cost: teams must maintain servers, certificates, load balancers, patches, monitoring, and high availability for infrastructure whose main job is login.
- Policy gap: many auditors, cyber insurers, and security teams now expect Conditional Access-class controls, phishing-resistant MFA, and centralized identity governance.
- Modernization pressure: many organizations already use Microsoft Entra ID for Microsoft 365 and want the same control plane for more applications.
What the AD FS Migration Tooling Handles Well
Microsoft's AD FS migration path is useful for applications that already behave like standard SAML or OIDC relying parties. The application activity reporting and migration tooling can help inventory AD FS usage, identify candidates, and move many relying party trusts into Microsoft Entra ID.
For clean SAML and OIDC apps, the project is often straightforward: inventory the relying party, create or migrate the Entra enterprise application, map claims, test sign-in, cut over, and monitor.
If every application behind AD FS fits that pattern, retirement is mostly a wave-planning exercise. Most real environments, though, have an application tail.
The App Tail: What Keeps AD FS Alive
The hard part is not usually the first group of applications. It is the last group. AD FS estates often include apps that accumulated over many years and do not fit a clean SAML or OIDC migration path.
- Header-based applications that depend on trusted HTTP headers instead of directly speaking SAML or OIDC.
- Integrated Windows Authentication or Kerberos applications published through Web Application Proxy.
- Non-claims-aware applications that cannot be changed to consume modern identity tokens.
- Vendor applications with limited authentication options or no practical modernization roadmap.
- Custom applications with claim rules that were built around old assumptions and are risky to rewrite.
This tail is why AD FS farms often survive the migration. A handful of applications can keep federation servers, WAP servers, and certificate operations alive indefinitely.
Closing the Tail with an Access Proxy
Tail applications do not always need AD FS itself. They need what AD FS plus WAP was doing for them: authenticate the user, enforce access policy, and pass identity to the application in the format it already understands.
Datawiza Access Proxy sits in front of these applications and lets users authenticate with Microsoft Entra ID while the application keeps its existing login pattern. Datawiza can pass trusted HTTP headers to header-based applications, support Kerberos constrained delegation for IWA/Kerberos applications, and enforce URL-level authorization before traffic reaches the app.
This access-layer approach is aligned with Microsoft's Secure Hybrid Access pattern. Microsoft documents Datawiza as a partner option for configuring secure hybrid access with Microsoft Entra ID.
The result is a cleaner migration path: move standard apps with Microsoft tooling, front the tail apps with Datawiza, then retire the AD FS and WAP infrastructure when traffic is gone.
A Practical AD FS Retirement Plan
- Inventory AD FS activity. Identify every relying party, WAP-published application, app owner, authentication method, and traffic pattern.
- Separate clean apps from tail apps. Standard SAML and OIDC apps can usually move through the Microsoft Entra migration path. Header-based, IWA, Kerberos, and non-claims-aware apps need an access-layer plan.
- Migrate clean apps in waves. Test claim mappings, user assignments, group-based access, and rollback steps before expanding.
- Place Datawiza in front of the tail. Keep the app unchanged while Entra ID handles user sign-in and Datawiza handles the app-facing identity pattern.
- Watch for zero traffic. Once the activity report and logs show AD FS is no longer serving applications, follow Microsoft's decommission guidance.
Your Options, Compared
Stay on AD FS
This preserves the status quo, but keeps federation servers, WAP servers, certificates, and AD FS-specific security exposure in place. It may be acceptable short term, but it does not move the estate toward modern access policy.
Migrate Standard Apps Only
This is a useful milestone, but it can leave two identity systems running indefinitely: Entra ID for the clean apps and AD FS for the tail.
Retire the Farm with Tooling plus Proxy
This combines Microsoft's migration tooling for standard apps with Datawiza Access Proxy for the apps the tooling cannot move cleanly. The end state is simpler: Entra ID as the identity control plane and no AD FS farm kept alive for a small app tail.
Related WAM Migration Guides
AD FS is one part of a broader WAM modernization pattern. If your environment also includes SiteMinder, Oracle Access Manager, or ISAM/WebSEAL, use the WAM migration hub and the related platform guides to plan the application tail.
- SiteMinder migration: modernize WebAgent and header-based applications one app at a time.
Read the SiteMinder migration guide
- Oracle Access Manager migration: compare OAM 12c/14c planning with an enterprise IdP plus proxy path.
- ISAM migration: move WebSEAL junction patterns to a modern access layer while preserving application headers.
Frequently Asked Questions
Is ADFS end of life?
No formal end-of-life date exists for AD FS as a standalone product. AD FS follows the lifecycle of the Windows Server version it runs on. The more practical point is that Microsoft is investing in Microsoft Entra ID for modern identity, access policy, and MFA capabilities.
When does AD FS support end?
It depends on the Windows Server version running AD FS. Teams should check their exact Windows Server lifecycle, patch level, and support status before planning retirement dates.
What applications are hard to migrate from AD FS to Entra ID?
Header-based apps, IWA/Kerberos apps, non-claims-aware apps, and applications with complex custom claim rules are often the hardest. These are good candidates for an access proxy pattern because the app can stay unchanged while access moves to Entra ID.
How do header-based applications leave AD FS?
A proxy becomes the new front door. Users authenticate with Entra ID, and the proxy passes trusted identity headers to the application. The application does not need to be rewritten for SAML or OIDC.
Can Datawiza help with AD FS MFA and 2FA too?
Yes. Datawiza can enforce MFA at the access proxy layer for existing web applications. It can use Datawiza built-in MFA or integrate with identity and MFA services such as Microsoft Entra ID, Duo, Okta, Ping, and others depending on the environment.
The Bottom Line
AD FS is not formally dead, but many organizations are ready to stop operating it. The blockers are usually not the clean SAML apps. They are the last header-based, Kerberos, and hard-to-change applications that keep the farm alive.
If those apps are what is holding back your AD FS retirement, book a demo. Bring your AD FS application inventory, and we can walk through which apps should move directly to Entra ID and which ones should move behind Datawiza Access Proxy.
