ADFS federation creates identity sprawl and security tradeoffs

At a glance

What this is: This is an analysis of ADFS as a federated SSO pattern and the operational and security tradeoffs it creates for modern identity environments.

Why it matters: It matters because federation decisions affect how IAM teams govern access, harden identity infrastructure, and reduce long-lived trust relationships for users and non-human identities alike.

By the numbers:

• Over 90% of organizations use Active Directory.
• Only 5.7% of organizations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorized access and broadening the attack surface.

👉 Read Okta's article on ADFS authentication, risks, and cloud identity

Context

ADFS sits in the gap between legacy Active Directory authentication and the broader application ecosystem that employees now use across partner portals, cloud services, and externally hosted tools. In practice, it turns a local directory trust into a federated access path, which means the security model depends on the durability of the trust relationship, the health of the ADFS tier, and the control quality around claims and token handling.

For IAM and NHI practitioners, the more interesting question is not whether federation works, but how much operational and security debt it introduces as environments move toward cloud identity, ephemeral access, and machine-mediated access. ADFS can still solve integration problems, but it also concentrates dependency, maintenance, and hardening requirements in a service that becomes part of the identity control plane. That is a common legacy posture, not an ideal end state.

Key questions

Q: How should IAM teams decide whether to keep ADFS in their architecture?

A: Keep ADFS only where it still solves a real integration constraint that modern identity options cannot replace cleanly. If the service mainly persists for historical reasons, it adds trust concentration, patching burden, and certificate lifecycle work. Reassess it against Zero Trust, least privilege, and revocation speed rather than convenience alone.

Q: What is the difference between federation and direct application authentication?

A: Federation delegates part of the authentication process to a trusted identity provider, which issues claims the application accepts. Direct authentication requires the application to verify identity itself, usually through a tighter local or protocol-native flow. Federation improves reach, but it also introduces a dependency whose trust configuration must be maintained carefully.

Q: How can security teams reduce risk in legacy federated access paths?

A: Reduce risk by limiting the number of trusts, tightening claims, enforcing strong server hardening, and monitoring token issuance and certificate lifecycle events. Where possible, replace broad, long-lived trust with shorter-lived authorization and explicit access review. That approach shrinks the attack surface without forcing every integration to be rebuilt at once.

Q: Why do legacy identity systems complicate non-human identity governance?

A: Legacy identity systems were built around human sign-in and stable directory trust, not ephemeral workloads, bots, or AI agents. When those systems are reused for automation, they often inherit standing access, opaque trust paths, and weak revocation discipline. That makes non-human identity governance harder to audit and easier to neglect.

Technical breakdown

How ADFS federation moves trust outside the application

ADFS acts as a federation broker between Active Directory and a target application. The user authenticates against the ADFS service, and ADFS issues a claim that the application trusts as proof of identity. That design avoids direct application authentication against the directory, but it also means access decisions rely on the correctness of claims issuance, trust configuration, and token validation. In security terms, the application no longer owns the full authentication flow. It inherits part of it from a separate identity service that must be reachable, hardened, patched, and monitored.

Practical implication: Treat the ADFS tier as a high-value authentication dependency and monitor it like a control-plane service.

Why ADFS creates hidden operational and resilience costs

Federation is often described as simplifying user access, but the underlying service adds infrastructure that must be licensed, patched, backed up, and made highly available. Each additional relying party or trust relationship adds configuration work and more opportunities for misalignment between policy and implementation. The operational burden becomes visible when teams need to extend access to more applications, because onboarding is not just a permission change. It is a trust-management task that touches server health, certificate lifecycle, and disaster recovery planning.

Practical implication: Map every ADFS dependency to patching, failover, and certificate ownership before expanding its use.

ADFS and non-human identity governance

Although ADFS is usually discussed in human SSO terms, the same trust model affects non-human identities when services, bots, or automation components depend on federated access paths. Any system that exchanges claims for access tokens inherits the same concerns around standing trust, over-privilege, and opaque access paths. That is why ADFS should be viewed through NHI governance as well as human IAM. The challenge is not just user convenience. It is whether long-lived federation patterns can support least privilege and continuous verification in environments that now include workloads and agents.

Practical implication: Review federated trust paths for service accounts and automation before they become undocumented identity dependencies.

Threat narrative

Attacker objective: The attacker aims to turn a compromised or misconfigured federation layer into broad downstream application access.

1. Entry occurs through a trusted federation path where access depends on the integrity of ADFS claims and token handling rather than direct application authentication.
2. Escalation follows when over-trusted claims, weak trust configuration, or insufficient hardening let an identity assert broader access than intended.
3. Impact is credential or session abuse across connected applications, especially when the federation tier becomes a shared dependency for many users and services.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ADFS is a trust-concentration problem, not just an authentication convenience. Federation reduces the friction of external access, but it also centralizes policy enforcement and failure modes in a service that sits between users and applications. When that tier is under-managed, the organization inherits brittle trust relationships instead of simpler authentication. The practitioner takeaway is to treat federation as a security dependency that must earn its place in the architecture.

Legacy federation can slow the move to modern NHI governance. ADFS-era thinking assumes identity is mostly about human users and domain-controlled apps. That assumption no longer holds in environments where service accounts, API-driven workflows, and AI agents also need bounded access. The longer a team treats federation as a universal answer, the more likely it is to overlook the governance needs of non-human identities. The practical conclusion is to evaluate whether ADFS still belongs in the access path for every workload.

Identity sprawl often begins with convenience, then becomes policy debt. Each new federated connection looks like a small integration decision, but it expands the trust graph and increases the surface area that must be reviewed, rotated, and audited. Over time, the control problem shifts from access enablement to exception management. That pattern is visible across many identity environments, and the right response is to reduce standing trust wherever a shorter-lived authorization model is available.

Federation must now be measured against Zero Trust and least privilege outcomes. If the architecture cannot continuously verify identity, constrain blast radius, and support operational revocation, then it does not align cleanly with modern security expectations. The goal is not to eliminate federation everywhere, but to define where it is still justified and where it has become legacy scaffolding. The practitioner conclusion is to re-score ADFS against current governance requirements, not historical convenience.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorized access and broadening the attack surface, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that revocation lag is still a major governance failure.
• For a broader breakdown of how privilege and trust failures show up in real incidents, see the 52 NHI Breaches Analysis.

What this signals

Federated identity will keep surviving, but only where teams can prove it reduces risk more than it adds operational debt. For most programmes, the next step is not a full rip-and-replace. It is a controlled reduction of standing trust, with ADFS or similar federation layers used only where they still provide a clear access boundary and measurable governance value.

Identity blast radius is now the right lens for legacy federation decisions. When a single authentication tier can unlock many downstream applications, the governance question becomes how much damage one misconfiguration or compromise can create. Teams should use this lens to prioritise which trusts to retire first and where stronger claims controls are needed.

The governance pressure will intensify as NHI and AI agent access paths are layered on top of human SSO. With 92% of organisations exposing NHIs to third parties, according to Ultimate Guide to NHIs, the same trust assumptions that made ADFS workable for users can become a liability when extended to automation and external dependencies.

For practitioners

• Inventory every federated trust relationship Document which applications rely on ADFS, which claims they consume, and which teams own each trust relationship. Include service accounts, automation paths, and partner-facing applications so hidden dependencies do not remain outside review.
• Harden the ADFS tier as critical identity infrastructure Apply patching, backup, certificate rotation, and high-availability controls to the ADFS servers and supporting components. Monitor authentication anomalies, token issuance failures, and configuration drift as control-plane events.
• Reassess where federation is still justified Compare each ADFS integration against modern cloud identity options, shorter-lived credentials, and policy-based access patterns. Keep federation where it solves a real integration problem, but retire it where it mainly preserves legacy dependency.
• Extend governance to non-human access paths Review whether bots, workloads, and service accounts inherit trust assumptions that were designed for human sign-in. Apply the same review discipline to claims, privileges, and revocation paths used by automation.

Key takeaways

• ADFS solves a real access problem, but it does so by concentrating trust in a control-plane service that must be managed like critical infrastructure.
• The main risk is not authentication in isolation, but the accumulated operational debt of trusts, certificates, patching, and downstream application dependencies.
• Modern IAM and NHI governance should keep federation where necessary, but reduce standing trust wherever shorter-lived access models can take over.

Key terms

• Federated Trust: A federated trust is the relationship that allows one identity system to vouch for a user or workload to another system. In ADFS-style models, the application accepts claims from the federation layer instead of authenticating directly. That reduces friction, but it also expands the number of components that must be trusted and defended.
• Identity Control Plane: The identity control plane is the set of services, policies, and dependencies that decide who or what gets access. It includes federation, claims issuance, token validation, and revocation workflows. When this layer fails or is overextended, the organisation can lose control over both human and non-human access paths.
• Identity Blast Radius: Identity blast radius is the amount of access an attacker or misconfiguration can reach after compromising one identity or trust point. In federated environments, the blast radius grows when a single service can unlock many applications. Practitioners use the concept to decide where to shorten trust and reduce downstream exposure.

Deepen your knowledge

ADFS federation and legacy identity trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment still depends on federated access paths, the course is a practical next step.

This post draws on content published by Okta: ADFS authentication, risks, and cloud identity tradeoffs. Read the original.