What is an ADFS connection?

An ADFS connection is a link between an application and Active Directory Federation Services. It allows users to sign in to cloud applications through Single Sign-On. This enables secure and user-friendly authentication.

ADFS stands for Active Directory Federation Services, a Microsoft technology that enables organisations to use Single Sign-On (SSO) both internally and in the cloud.

ADFS (Active Directory Federation Services) is an application that is connected to Active Directory. It enables you to use on-premises AD data to provide Single Sign-On (SSO) to applications outside the corporate network.

What is the difference between Active Directory and ADFS?

Active Directory manages users, groups, and devices and handles authentication for on-premises systems within your network. ADFS extends that authentication to cloud applications through federation. The two are complementary: ADFS uses Active Directory as its data source and cannot operate without it.

Not officially. ADFS is a Windows Server role and remains supported for as long as your Windows Server version is. That said, Microsoft stopped adding new features to ADFS and now publishes a decommission guide for organisations that want to migrate to Entra ID. If you are thinking about a long-term authentication strategy, Entra ID is where Microsoft is investing.

Can HelloID replace ADFS?

For organisations looking to federate non-Microsoft cloud applications without maintaining on-premises federation servers, HelloID Access Management is a practical alternative. For Microsoft-centric environments, Entra ID is typically the more natural replacement.

ADFS: what is Active Directory Federation Services?

Active Directory (AD) is the directory service most Windows-based organisations use to manage users, groups, devices, and access policies. It handles authentication for everything within your network: file shares, printers, internal applications. What it does not do, at least not natively, is authenticate users to cloud applications.

That is the gap ADFS fills. It sits alongside Active Directory and uses its data to authenticate users to cloud applications via modern protocols such as SAML (Security Assertion Markup Language) and OIDC (OpenID Connect).

The mechanism behind this is called federation. Running a hybrid environment means managing two worlds: your on-premises systems and your cloud applications. Most IT teams want to control authentication across both from a single place. To make that work, each cloud application hands its login process back to your own identity platform. That handoff is federation, and ADFS acts as the trusted broker. The cloud application accepts it because a trust relationship has been configured between them in advance.

How ADFS Works

Here is what the sign-in process looks like from a user's perspective in a typical hybrid environment:

You start your computer and sign in with your Active Directory credentials. Your username and password are verified against AD and you are connected to the corporate network.
Internal applications open automatically. Because you are already authenticated, Integrated Windows Authentication (IWA) handles the rest behind the scenes. No second login needed.
You open a cloud application such as Salesforce. It recognises that your organisation uses ADFS and redirects your login request to the ADFS server.
ADFS checks via IWA that you are already signed in. You do not need to authenticate again.
ADFS sends a token containing your identity data to Salesforce. Salesforce validates it and grants you access automatically.

The result is seamless SSO across your entire environment, with every authentication decision made through infrastructure you control.

ADFS vs Entra ID

If your organisation uses both on-premises and cloud applications, there are two main approaches to handling authentication across them. You can run ADFS alongside Active Directory and keep everything on-premises, or you can use Entra ID (formerly Azure AD), Microsoft's cloud-based identity platform, alongside your local Active Directory.

Both options solve the same problem. The differences are in how they solve it and what they cost to run.

	ADFS	Entra ID
Deployment	On-premises servers	Cloud-based, managed by Microsoft
Setup	Complex: servers, certificates, load balancers	Simpler: configured through the Azure portal
Ongoing maintenance	Managed internally by your IT team	Handled by Microsoft
SSO support	Cloud and on-premises applications	Cloud and on-premises (via Entra Connect)
Protocols	SAML, OIDC	SAML, OIDC, OAuth 2.0
Advanced security features	Limited to base federation	Conditional Access, risk-based MFA, phishing-resistant authentication
Password hash storage	Stays on-premises	Synchronised to the cloud
Microsoft's investment	Supported; no new features planned	Actively developed; Microsoft's recommended path
Best suited for	Heavy on-premises environments; bespoke configurations	Cloud-first or hybrid organisations

Is ADFS Still Worth Using?

ADFS is not deprecated. It is a Windows Server role and stays supported as long as your Windows Server version is. But Microsoft's direction is clear: every new identity capability, Conditional Access, risk-based MFA, phishing-resistant authentication, is being built in Entra ID. ADFS gets no new features. Microsoft now publishes an official AD FS decommission guide and actively surfaces migration recommendations within the Entra admin portal.

ADFS still makes sense in a few specific situations:

Your organisation runs predominantly on-premises workloads and cloud adoption is genuinely limited.
You need bespoke claim configurations or custom authentication logic that Entra ID cannot replicate.
Your security policy does not allow password hashes to be synchronised to the cloud, which Entra ID's standard configuration requires.

Outside those scenarios, particularly where Microsoft 365 is already in use, Entra ID is the more practical choice. The server infrastructure ADFS requires adds operational overhead without a meaningful benefit for organisations that are predominantly cloud-based.

Benefits and Drawbacks of ADFS

Benefits	Drawbacks
Authentication stays entirely on-premises	Requires servers, certificates, and load balancers to run
Password hashes are not stored in the cloud	Higher administrative overhead compared to Entra ID
Supports bespoke claim configurations	No access to Entra ID features: Conditional Access, risk-based MFA, passwordless sign-in
Full control over the federation infrastructure	An ADFS outage takes down cloud application sign-in for all users
	New capabilities such as passwordless login must be built and maintained manually

ADFS and HelloID

HelloID interacts with ADFS in two distinct ways, depending on how your environment is structured.

Access Management

The HelloID Access Management module includes a built-in identity provider and connects to third-party directories and identity providers, including Active Directory, Entra ID, ADFS, and Google Workspace. In hybrid environments where multiple identity providers are running in parallel, HelloID can coordinate authentication across those platforms from a single layer.

If your organisation uses ADFS mainly to federate non-Microsoft cloud applications, HelloID Access Management is often a more straightforward alternative. It delivers the same federation and SSO capability without requiring on-premises federation servers.

Provisioning, Service Automation, and Governance

Many organisations handle authentication separately, relying on Microsoft's own stack for sign-in and SSO while using an IAM platform for everything else. In that setup, Active Directory or Entra ID becomes a target system: HelloID creates accounts, assigns permissions, and manages the full user lifecycle, then pushes those settings through a standard connector.

The specific federation mechanism your organisation uses, whether AD with Entra ID or AD with ADFS, does not affect how HelloID operates. Provisioning and governance work the same way regardless.