Yes, when the business still depends on Windows-integrated or partner federation patterns that ADFS already supports. The key is to isolate that legacy use case from modern customer identity, so the older federation stack does not set the operational pattern for the whole programme.
When keeping ADFS makes sense, and when it becomes a liability
Keeping ADFS can be a pragmatic bridge when legacy applications still depend on Windows-integrated authentication, older federation trust patterns, or partner integrations that are expensive to rework. The mistake is treating that exception as the model for the entire identity programme, because modern customer identity usually needs different controls, different UX, and a different risk posture.
ADFS is best viewed as a constrained compatibility layer. That means documenting exactly which apps, partners, and protocols still require it, then preventing new dependencies from accumulating around it. The cleaner the boundary, the easier it is to retire ADFS later without forcing a disruptive migration or weakening ciam design to accommodate legacy behaviour.
For the underlying identity model, a useful starting point is IAM and IGA Basics, because the real question is usually not “ADFS or not” but how to separate authentication, authorization, and governance across two different user populations.
How to split legacy federation from customer identity
The architectural principle is separation of concern. Legacy federation should be isolated to the systems that genuinely need it, while CIAM should own customer-facing authentication, recovery, consent, and account lifecycle decisions. If both populations share the same operational pattern, the organisation tends to inherit the weakest assumptions from the legacy stack.
That separation is usually easier to maintain when you define hard boundaries for policies, logging, recovery flows, and support processes. A customer login problem should not be solved with a workaround built for internal Windows users, and a partner federation exception should not become the template for every new application onboarded to CIAM.
For customer-facing journeys, Customer IAM (CIAM) Guide is the more relevant reference point, because it reflects the authentication, recovery, and consent patterns that modern external identity programmes normally need.
Where organisations are moving toward stronger trust boundaries, the design also aligns well with NIST Cybersecurity Framework 2.0 and NIST SP 800-207 Zero Trust Architecture, because both push teams to limit trust, segment access paths, and reduce implicit reliance on a single identity pattern.
What the migration strategy should optimise for
The practical goal is not to preserve ADFS indefinitely, but to keep the legacy estate stable while the modern identity plane evolves independently. That usually means a migration sequence in which new customer capabilities go directly to CIAM, existing legacy apps keep their current federation path only where required, and decommissioning criteria are defined in advance.
One common failure mode is partial migration without governance. Teams move a few apps away from ADFS, but keep using ADFS as the default exception handler for new requests, which quietly extends the life of the legacy stack. Another is identity drift, where one population gets modern controls and the other remains stuck with older assumptions about sessions, assurance, and recovery.
If the organisation still has partner federation or older trust relationships to manage, the operational boundaries should be explicit enough that access reviews, entitlement changes, and offboarding remain understandable. That is the part of the programme that determines whether ADFS is a temporary bridge or a permanent shadow platform.
The most useful reference for modern assurance boundaries is NIST SP 800-63 Digital Identity Guidelines, since it helps teams think clearly about authentication strength, assurance, and recovery requirements for CIAM rather than inheriting whatever the legacy stack happens to support.
Risk and Threat Considerations
Keeping ADFS in place creates risk when the legacy trust boundary expands beyond the apps that truly need it. The bigger the shared dependency, the more likely a weakness in configuration, federation trust, or support process can affect both legacy and modern identity flows.
Failure mechanism: Legacy federation becomes the default exception path, so old authentication assumptions, broader trust relationships, or slower change control persist longer than intended. That can create a wider blast radius if the stack is misconfigured, abused, or simply left with stale integrations.
Impact: Customer identity design can become constrained by legacy behaviour, recovery becomes harder to standardise, and the organisation may delay retiring an older stack that should have been isolated to a narrow compatibility role.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Legacy and internal federation decisions hinge on strong user authentication control. |
| IA-8 — Identification and Authentication (Non-Organizational Users) | CIAM and partner-facing federation involve external identities and assurance requirements. | |
| IA-9 — Service Identification and Authentication | Federation boundaries and supporting services rely on machine-to-machine authentication controls. | |
| Recommendation — Apply IA-2 to keep user authentication requirements explicit across legacy and modern identity paths. Use IA-8 to govern authentication for customers and other external users separately from internal users. Use IA-9 to constrain service and federation trust relationships that support legacy identity flows. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question is about separating legacy trust from modern identity patterns and reducing implicit trust. |
| Recommendation — Design the split so legacy federation does not become the default trust model for the wider programme. | ||
Practitioner Guidance
What to prioritise: Keep a written inventory of every application, partner, and protocol that still depends on ADFS, then define which of those dependencies are temporary compatibility exceptions versus long-term architecture choices.
What to verify: Check that CIAM owns customer journeys end to end, including recovery and assurance decisions, while ADFS is limited to the specific legacy and federation cases that cannot yet move. If the boundary is unclear, the migration is not really in control.
Common mistake: Do not modernise the front end while leaving the old federation stack as the unseen policy engine. That usually preserves technical debt and makes the future cutover harder, not easier.
Practitioner takeaway: Treat ADFS as a bounded compatibility layer, not an identity strategy. The decision is healthy only when the legacy exception is narrow, observable, and on a retirement path.
Related resources from NHI Mgmt Group
- What happens when organisations keep custom legacy apps on AD while modern identities move elsewhere?
- What happens when organisations keep legacy authentication in place while expanding cloud, mobile, and shared workstation access?
- What happens when organisations keep legacy TLS settings while expanding APIs and mobile access?
- Should organisations keep classic PAM if they are moving to dynamic access controls?