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

Why This Matters for Security Teams

ADFS is rarely a purely technical choice anymore. For most IAM teams, the real question is whether ADFS still solves an integration problem that modern identity tooling cannot replace without unacceptable risk. When it remains in place by default, it often becomes a trust concentration point, a patching dependency, and a certificate lifecycle burden that slows revocation and recovery. That matters because identity failures are rarely isolated: the wrong federation decision can widen blast radius across workloads, partners, and administrative paths. NIST’s NIST Cybersecurity Framework 2.0 still pushes teams toward asset visibility, governance, and risk-based control selection rather than preserving legacy components for convenience. In NHI environments, that pressure is amplified by the way secrets and service accounts are commonly mishandled, as seen in the JetBrains GitHub plugin token exposure case and broader NHIMG research on exposed credentials. In practice, many security teams discover ADFS is overdue for retirement only after a certificate outage or federation incident has already disrupted access.

How It Works in Practice

The decision should start with dependency mapping, not product preference. Identify every application, partner trust, token flow, and legacy protocol that still requires ADFS, then separate hard dependencies from habits. If a workload can move to modern federation, conditional access, or workload identity without breaking business logic, the default answer should trend toward decommissioning. If not, keep ADFS only as a constrained exception with compensating controls.

Good practice is to treat ADFS as a bounded trust broker. That means tight patch cadence, explicit certificate ownership, monitored expiry windows, and a documented rollback path. It also means separating human sign-in from machine and service authentication wherever possible. For non-human workloads, modern guidance favours short-lived credentials, JIT provisioning, and workload identity primitives instead of long-lived federation dependencies. NHIMG research shows why this matters: 91.6% of secrets remain valid five days after notification, and 71% of NHIs are not rotated on time, which means slow revocation can keep an old trust path alive long after a change is made. That same pattern is visible in exposed secret incidents such as Azure Key Vault privilege escalation exposure, where over-broad access and poor lifecycle discipline turn a control into an attack path.

• Keep ADFS only for applications that cannot yet support modern federation or token-based alternatives.
• Document every relying party and remove trusts that no longer have a current business owner.
• Use least privilege, RBAC, and explicit administrative separation for the ADFS platform itself.
• Monitor certificate expiry, federation anomalies, and token issuance patterns as operational controls.
• Prefer JIT, ephemeral secrets, and workload identity for automated systems where possible.

NIST CSF 2.0 and Zero Trust Architecture both support this style of reduction: minimise standing trust, verify at request time, and shorten the lifespan of secrets and access grants. These controls tend to break down when a large portfolio of legacy applications still depends on WS-Fed or custom claims logic because the migration effort becomes application-specific rather than identity-specific.

Common Variations and Edge Cases

Tighter federation control often increases migration cost, requiring organisations to balance risk reduction against application compatibility and partner constraints. That tradeoff is real, especially in regulated environments, mergers, or environments with older SaaS integrations. The current guidance suggests preserving ADFS only as long as it is the least disruptive way to support a proven business requirement, not because it feels safer to keep a familiar platform.

There are a few cases where retention is reasonable. Some applications cannot yet consume modern protocols without redesign. Some partner ecosystems still require claims transformations that are costly to rebuild. Some regulated workflows need a phased migration with dual-running during cutover. Even then, ADFS should be treated as transitional, not strategic. Use the platform as a bridge while building toward stronger identity primitives such as short-lived tokens, workload identity, and policy evaluation at request time. Where the question is about autonomous software or AI agents, the bar should be even higher: agent behaviour is goal-driven and unpredictable, so static federation patterns are usually a poor fit for runtime authorisation. That is where current guidance increasingly favours context-aware decisions, ephemeral credentials, and explicit workload identity instead of broad, persistent trust.

For IAM teams, the practical test is simple: if ADFS cannot be justified by a live dependency, a measurable control gap, or a migration timeline with accountable owners, it should not remain in the architecture.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• Why do non-human identities complicate zero trust architecture?
• How should teams secure non-human identities across cloud and SaaS?
• How should teams reduce the risk from exposed NHI secrets?