Active Directory Federation Services

Expanded Definition

active directory Federation Services, commonly called ADFS, is a federation layer that lets an organisation issue trusted authentication for applications without forcing every application to manage passwords directly. In NHI security, it often becomes part of the trust chain for service portals, internal apps, and partner-facing integrations that rely on Active Directory-backed identities. The distinction matters because ADFS is not the same as native directory sign-in, and it is not a secrets manager or an access gateway. Its role is to assert identity across boundaries, usually by issuing claims or tokens after authentication has succeeded.

Definitions vary across vendors when ADFS is discussed alongside SSO, identity providers, and federation brokers, so practitioners should treat the term as a specific Microsoft federation service rather than a generic login stack. For control design, the important question is where trust is established, how claims are minted, and what happens when the federation service is compromised. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because federation must be governed as a privileged trust function, not just an application convenience. The most common misapplication is treating ADFS as a default authentication shortcut, which occurs when teams enable it broadly without reviewing claims, token scope, or trust dependencies.

Examples and Use Cases

Implementing ADFS rigorously often introduces dependency and availability risk, because one federation service can become a high-value trust anchor for many applications at once, requiring organisations to weigh single sign-on convenience against blast-radius containment.

• Internal line-of-business applications use ADFS to accept corporate identity assertions instead of storing local usernames and passwords, which centralises control but also concentrates exposure if the federation tier is weak.
• Partner access scenarios use ADFS to bridge separate identity domains, where claims and trust rules determine what an external user or system may reach.
• Legacy enterprise applications integrate with ADFS when they cannot speak modern cloud-native identity protocols directly, making federation a transitional control rather than a final-state architecture.
• Incident reviews often trace compromised application access back to overbroad trust relationships, similar to the pattern described in the Cisco Active Directory credentials breach, where identity infrastructure became part of the attack path.
• Security architects map ADFS-backed flows against federated trust and session controls documented in NIST SP 800-53 Rev 5 Security and Privacy Controls to determine whether claims issuance and token handling are adequately protected.

NHIMG research shows how often identity infrastructure becomes a target: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and that pattern is highly relevant when ADFS is used to broker access for automated systems.

Why It Matters in NHI Security

ADFS matters because it can silently expand the trust surface for non-human identities. If service accounts, API clients, or automated workflows authenticate through federation, the security team must understand how those identities are asserted, which claims are trusted, and whether downstream applications validate them consistently. Weak configuration can create a situation where a single compromised federation pathway grants broad access across many systems. NHIMG notes that 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, which is especially dangerous when federation makes privilege propagation fast and hard to inspect. NHIMG’s Ultimate Guide to NHIs also documents that only 5.7% of organisations have full visibility into their service accounts, a visibility gap that makes federated access paths harder to govern.

Practical governance means reviewing federation trust boundaries, session lifetime, claim issuance rules, and recovery procedures when the identity provider is unavailable or compromised. Organisational risk rises further when ADFS is treated as “set and forget” infrastructure instead of a monitored security control. Teams should pair federation reviews with identity inventory, secrets hygiene, and privileged access monitoring using guidance from the Ultimate Guide to NHIs and control baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls. Organisations typically encounter ADFS as a critical issue only after an application outage, credential compromise, or unexpected trust failure, at which point federation becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why does Active Directory Certificate Services increase identity risk?
• How should teams decommission legacy Active Directory forests without breaking business services?
• What breaks when Active Directory Certificate Services templates are too permissive?
• How should organisations build DORA-aligned ICT risk management around Active Directory and other identity services?