ADFS

Expanded Definition

ADFS, or Active Directory Federation Services, is a federation service that issues or brokers authentication assertions between an organisation’s identity system and external or connected services. It is used when a relying party trusts the ADFS-issued token instead of authenticating the user or workload directly.

The key boundary is that ADFS is not the application being accessed and not the directory itself. It is the trust bridge, which means its role is defined by claims, token issuance, signing, and federation relationships rather than by local password verification alone. That distinction matters because federation failures often look like identity failures somewhere else in the stack.

In practice, ADFS is often discussed alongside SAML and claims-based access. Usage in the industry is still fairly stable, but implementation patterns vary across estates, especially where older federation configurations coexist with newer cloud identity flows. For a broader machine-identity context, the OWASP Non-Human Identity Top 10 is useful because it frames the credential and trust problems that often surround federation services.

Examples and Use Cases

ADFS appears anywhere an organisation wants central authentication with downstream trust in issued assertions rather than direct local logins.

• Employees sign in once to reach SaaS apps that accept federated claims from ADFS.
• AWS IAM Identity Center can use ADFS as an upstream identity source, so access decisions follow the federation trust path.
• Legacy internal applications rely on ADFS to avoid building their own authentication layer.
• Partner or customer portals use ADFS when external users are authenticated through a trusted identity provider.
• Hybrid estates keep ADFS during phased migration to cloud identity, trading simplicity of transition for ongoing federation maintenance.

One practical tradeoff is that federation centralises trust and simplifies access management, but it also concentrates failure in the assertion issuer. If the signing or trust configuration drifts, many downstream services can fail at once even though their own application code has not changed.

Security Implications

ADFS is security-critical because compromise or misconfiguration of the federation layer can undermine every service that relies on its assertions. The main issue is not merely account takeover; it is trust-path abuse, where a malicious or faulty assertion becomes accepted as proof of identity by connected systems.

Common failure conditions include weak protection of federation signing material, overly broad claims issuance, poor monitoring of token issuance, and stale trust relationships that remain in place after environment changes. When that happens, access may remain valid longer than intended, and responders may find that the visible symptom is downstream access rather than an obvious ADFS alert.

NHI Management Group notes that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which is especially relevant where federation components can sign or endorse access for many services. The practical lesson is that the federation server itself becomes a high-value trust asset, not just another directory-adjacent server.

Domain and Governance Relevance

In NHI governance, ADFS matters because it often sits at the point where human and non-human access converge. Service accounts, automated jobs, integrations, and application access can all be authenticated through the same federation path, so ownership of the trust chain must be explicit and auditable.

That changes governance in two ways. First, identity assurance is no longer just about the upstream directory; it also depends on the federation service, token rules, and signing keys. Second, lifecycle decisions become more important because federation trust relationships tend to outlive the systems that created them. ADFS is therefore a control plane issue as much as an identity product.

For practitioners managing machine access, federation is only safe when its trust assumptions are periodically reviewed, especially where external services or automated workloads depend on assertions that were originally set up for convenience.

Related resources from NHI Mgmt Group

• How should IAM teams decide whether to keep ADFS in their architecture?
• Why do ADFS-based phishing attacks evade normal URL filtering?
• How should security teams manage ADFS certificate dependencies without causing outages?
• When does ADFS become the wrong choice for identity architecture?