How should organisations migrate authentication away from ADFS in a hybrid identity environment?

Organisations should plan the migration in stages, test each change, and validate downtime risk before switching production traffic. Password Hash Synchronization and Pass-through Authentication both reduce dependence on ADFS, but the right path depends on how ADFS was originally configured and whether Azure AD Connect is already in place. A controlled migration lowers attack surface while preserving sign-in continuity.

What a Hybrid Migration Away from ADFS Really Changes

Moving authentication off ADFS is not just a platform swap, it changes where sign-in decisions are made, how users are routed, and how much dependence remains on an on-premises federation stack. The main design choice is whether cloud authentication can replace ADFS without breaking existing user flows, legacy apps, or conditional access assumptions. In practice, the best path is usually the one that reduces federation complexity while preserving the login experience users and applications already rely on.

For most organisations, Password Hash Synchronization and Pass-through Authentication are the two main routes because they both reduce the need to keep ADFS in the critical path. The right choice depends on what ADFS was doing beyond simple federation, whether the tenant already uses Azure AD Connect, and whether any application or claim logic still depends on ADFS-specific behaviour.

Move first from “can we authenticate?” to “what does ADFS still add that the cloud service must replace?”
Inventory applications that depend on federation, custom claims, or legacy sign-in endpoints before changing user traffic.
Treat Azure AD Connect health and configuration as part of the migration dependency, not a background detail.

When the goal is to simplify the sign-in path, the migration should be measured against continuity, not just feature parity. That means testing the new flow under real user conditions, including password reset, device trust, conditional access, and any application-specific authentication edge cases. A staged cutover also makes it easier to fall back if latency, token issuance, or authentication policy behaviour is not what production expects.

One useful reference point is Microsoft’s broader identity guidance, but the operational question is always the same: can the new path issue reliable sign-ins with less operational drag than ADFS? If not, the organisation has changed technology without removing the underlying dependency.

Migration Patterns That Usually Work Best

Password Hash Synchronization is often the simplest long-term target because it removes most runtime dependence on ADFS and makes cloud sign-in the default path. Pass-through Authentication can be a better transitional choice when organisations want passwords validated on-premises but still want to retire federation. Both approaches can be valid, but they differ in operational burden, failure modes, and the amount of infrastructure that must stay healthy.

Some environments can move directly if ADFS was used mainly for basic federated authentication. Others need an intermediate phase because of custom claim rules, third-party integrations, or sign-in policies that were built around federation. In those cases, the migration should be sequenced so that each application is validated before the final cutover, rather than trying to replace everything in one change window.

The clearest sign of a low-friction migration is that the new method works without application rework and without creating a second authentication standard for users. The clearest sign of a hard migration is that ADFS is embedded in business-critical app logic, in which case remediation work belongs before decommissioning, not after.

For teams that want a migration path grounded in common identity practice, the most useful public references are NIST SP 800-63 Digital Identity Guidelines for authentication assurance and the OWASP ASVS controls that reinforce sign-in and session expectations.

Risk and Threat Considerations

ADFS retirement reduces attack surface, but only if the replacement path is hardened and the cutover is controlled. A rushed migration can leave organisations with broken sign-in flows, weak fallback logic, or a temporary mix of federation and cloud auth states that is harder to monitor than the original setup.

Failure mechanism: The most common failure is assuming authentication behaviour will be identical after migration, then discovering that claims, conditional access, device trust, or app-specific routing behaved differently once production traffic moved.

Impact: The result can be sign-in disruption, user lockout, or an extended period where both old and new paths remain active, increasing operational complexity and making incident response harder.

Migration also changes the security profile of account compromise. If ADFS was masking legacy app design or custom trust logic, moving to cloud-based authentication can expose weak application assumptions that were never remediated. For that reason, the security review should include downstream applications, not just the identity provider replacement.

Practitioners can also use this transition to reduce dependence on long-lived federation infrastructure, which is valuable when the migration replaces a brittle on-premises control with a more observable cloud-authentication path. The target is not only fewer moving parts, but fewer places where sign-in failure can become a broader outage.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines — Digital Identity Guidelines	Covers authenticators, assurance and federation migration decisions.
Recommendation — Align the target sign-in flow to the assurance level and authenticator requirements.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	ADFS migration reduces reliance on long-lived federation and credential material.
Recommendation — Reduce standing authentication dependencies and retire legacy federation secrets.
CIS Controls v8	6 — Access Control Management	Migration changes how accounts authenticate and how access paths are governed.
Recommendation — Review and remove obsolete access paths as authentication moves off ADFS.
NIST Zero Trust (SP 800-207)	Policy Decision Points and Enforcement — Policy Decision Points and Enforcement	Hybrid migration shifts where authentication and access decisions are enforced.
Recommendation — Move policy enforcement to the cloud path and validate enforcement consistency.

Practitioner Guidance

What to prioritise: Validate the user journey first, then the infrastructure. In practical terms, the highest-value test is whether a real user can sign in to the real applications that matter, not whether a lab account can complete a happy-path login.

Implementation sequence: Start with dependency discovery, move to pilot users, then cut over applications with the cleanest authentication patterns before touching the apps that depend on custom claims or legacy federation logic. This sequencing lowers the chance that a single unresolved edge case blocks the whole program.

What to verify: Confirm failover behaviour, password reset flow, conditional access evaluation, and rollback assumptions before decommissioning ADFS. If any of those are untested, the migration is still experimental even if the new sign-in screen appears to work.

Practitioner takeaway: The safest ADFS migration is the one that removes federation only after the organisation has proved that cloud sign-in can absorb every business-critical authentication path without hidden dependencies.