For most Microsoft 365 environments, Microsoft Entra ID can replace ADFS with a simpler, more secure authentication model. Learn what to review before making a change.
If your organization still uses Active Directory Federation Services (ADFS) for Microsoft 365 sign-ins, it is time to reassess whether you still need it.
ADFS may be working as intended, but for many organizations, Microsoft Entra ID can now provide cloud authentication without requiring on-premises federation infrastructure.
Some legacy applications or specialized authentication requirements may still depend on ADFS. But if those requirements no longer exist, keeping it can mean carrying avoidable cost, complexity, and security responsibility.
Why Organizations Used ADFS
ADFS made sense when the Microsoft cloud was in its infancy, and Microsoft recommended that organizations deploy it. For years, it provided a way to connect on-premises Active Directory to Microsoft cloud services while allowing the organization to keep control of the authentication process and integrate with the traditional on-prem bubble.
This approach is known as federated authentication. When a user tried to access a Microsoft cloud service, Microsoft redirected the sign-in request to the organization’s ADFS environment. ADFS verified the user and sent a trusted response back to Microsoft.
That model was effective for organizations with specific identity, application, or compliance requirements. The question today is whether those requirements still justify the infrastructure needed to support ADFS.
Why Reassess ADFS Now
Microsoft Entra ID now provides cloud authentication and identity-security capabilities that can eliminate the need for ADFS in many environments. If your organization does not have a documented reason to continue authenticating users through ADFS, it is worth reviewing whether the federation layer is still necessary.
Moving authentication to Entra ID can reduce the number of servers and dependencies involved in a sign-in. It can also make it easier to use current security controls, such as Conditional Access, multifactor authentication, device-based signals, Identity Protection, and phishing resistant passwordless authentication.
Microsoft supports staged rollout and application migration tools, so organizations can test a new sign-in model with selected users and applications before transitioning more broadly.
You Should Review ADFS If…
An ADFS assessment is worth prioritizing if one or more of these statements is true:
- You use ADFS primarily for Microsoft 365 sign-ins.
- You are unsure which applications still depend on ADFS.
- ADFS creates recurring IT work through certificate renewals, authentication, troubleshooting, outages, or federation-related maintenance.
- You want to expand Conditional Access, phishing-resistant multifactor authentication, passkeys, or passwordless sign-in.
- You have not formally reviewed your federation strategy for several years.
The Ongoing Risk of ADFS
ADFS can continue working for years without drawing attention. Users sign in, email works, and no immediate problem appears. That is why organizations often leave it in place.
Because ADFS sits in the Microsoft 365 sign-in path, keeping it means continuing to secure and operate the servers, certificates, service accounts, administrative access, Web Application Proxy components, and related dependencies that support sign-ins.
If those systems are compromised, misconfigured, or unavailable, the impact can reach far beyond one server. Users may be unable to access Microsoft 365, Dynamics 365, Business Central, and other services that rely on the sign-in path.
The point is not that every ADFS deployment is insecure. The point is that ADFS creates a security and availability responsibility that puts access to your cloud services at risk and is likely no longer necessary.
The Operational Cost of Keeping ADFS
The cost conversation is not usually about eliminating a separate per-user identity subscription. It is about reducing the infrastructure and staff effort required to keep the ADFS authentication path running.
Your team may still be maintaining:
- Windows servers and Web Application Proxy servers.
- Load balancers and other network dependencies.
- Certificates, patching cycles, monitoring, backups, and disaster recovery processes.
- Troubleshooting procedures for sign-in failures and application changes.
- The specialized expertise needed when a certificate expires or an authentication dependency breaks.
Even if no one writes an “ADFS license” check, the environment is not free. Moving authentication to Entra ID will reduce direct infrastructure costs and staff time by reducing the number of systems involved in authentication.
What Changes with Entra Authentication
Moving from ADFS to Microsoft Entra ID means Microsoft Entra ID becomes the primary service that verifies users for cloud sign-ins.
Your organization may keep on-premises Active Directory if you need it and identities can continue to synchronize from Active Directory to Entra ID. The key change is that users no longer need to authenticate through your ADFS infrastructure for many Microsoft cloud services.
It reduces the number of systems your team must operate and support while making it easier to apply current identity protections, including Conditional Access, multifactor authentication, Identity Protection, device-based signals, and passwordless sign-in options.
The move can also improve the user experience. Depending on your environment and readiness, you may be able to introduce Windows Hello for Business, passkeys, FIDO2 security keys, or Microsoft Authenticator while reducing dependence on passwords.
In practical terms, the project is not only about turning off servers. It is a chance to simplify sign-ins, eliminate your infrastructure as a dependency to access Cloud services, and strengthen how your organization controls access.
Move in Stages, Not All at Once
One reason organizations leave ADFS alone is fear of the cutover. Authentication affects everyone, and a problem could prevent users from accessing the tools they need to work. An “if it isn’t broken, don’t touch it” approach is understandable.
A staged approach can start with a controlled pilot, then expand after your team validates application access, user experience, exceptions, and rollback plans.
A controlled migration can follow this pattern:
- Ensure Entra is secured and setup for native authentication (CA policies, authentication methods and overall Entra security posture)
- Select a pilot user or group.
- Test the Entra sign-in experience and application access.
- Resolve exceptions and document dependencies.
- Expand the rollout in controlled waves.
- Retire ADFS only after the new sign-in path has been validated.
This approach replaces a dramatic cutover with incremental testing. Your organization can validate the future state before removing the infrastructure it depends on.
ADFS Retirement Checklist
Before changing your authentication model, document the current environment and test the target state.
Current ADFS dependencies
- Which domains still use ADFS for sign-ins?
- Which applications, relying-party trusts, claims rules, or custom sign-in requirements depend on it?
- Which users, groups, locations, or business processes rely on the current sign-in flow?
Application readiness
- Can each ADFS-connected application use Entra ID instead?
- Does any application require remediation, replacement, or a different authentication approach?
Security readiness
- Which authentication methods are enabled in Entra ID?
- Which Conditional Access policies are in place, and which should be added before migration?
- Is the organization ready for multifactor authentication, phishing-resistant authentication, or passwordless sign-in?
Migration readiness
- Which users can participate in an initial pilot?
- How will you validate application access and the user experience?
- What is the rollback plan if you discover an unexpected dependency?
Find Out Whether You Still Need ADFS
JourneyTeam’s Foundational Identity Analysis helps you determine whether ADFS is still required in your environment—and, if it is not, how to reduce dependence on it without disrupting users or critical applications.
We review your current sign-in model, ADFS dependencies, Entra ID readiness, authentication methods, and Conditional Access policies. Then we provide a practical roadmap for pilot testing, staged migration, exception handling, and ADFS retirement where appropriate.
The objective is to give your organization a simpler, more resilient identity foundation with fewer systems to operate and less risk to manage.
If ADFS remains part of your Microsoft 365 sign-in path, schedule an assessment before the next certificate renewal, outage, or security review forces the conversation.
