A federated domain is a domain configured so authentication happens outside Microsoft Entra ID. Usually through an on-premises identity provider like Active Directory Federation Services (ADFS), Okta, or PingFederate. Instead of checking passwords directly in the cloud, Entra ID simply trusts a signed token. Signed token that handed back by that external system.
If you manage Microsoft 365 or a hybrid Azure setup, you’ve probably run into this term. You will run into it while deciding how sign-in should actually work for your organization. It’s not just a toggle in a settings panel. It changes where authentication physically happens, who controls it day to day, and what breaks first when something goes wrong.
What Is a Federated Domain?
A federated domain delegates the entire login process to an external identity provider. Federated domain doing that instead of letting Entra ID verify passwords on its own. When someone signs in, Entra ID redirects the request to that external system. Which sends back a trust token confirming who the user is.
A few things define how this setup actually behaves in practice:
- Authentication happens on the identity provider’s servers, not inside Entra ID itself
- It requires a configured trust relationship, commonly called federation, between the two systems
- ADFS is the most common option, though Okta and PingFederate show up frequently in enterprise environments too
- It sits under the broader concept of federated identity, which links a person’s identity data across separate, otherwise independent systems
None of this is unique to Microsoft, by the way. The same general pattern shows up anywhere single sign-on connects two organizations or platforms that don’t share a user database.
How a Federated Domain Differs From a Managed Domain
The core difference between a federated domain and a managed domain comes down to one question: where does authentication actually happen, on your own infrastructure or directly inside Entra ID?
| Aspect | Federated Domain | Managed Domain |
| Where authentication happens | On your identity provider, e.g. ADFS, Okta, PingFederate | Directly inside Microsoft Entra ID |
| Setup effort | Higher. Needs a federation trust, often a dedicated ADFS server or cluster | Lower. Mostly handled through Entra ID Connect |
| Offline resilience | Breaks if the identity provider goes down | Keeps working even if the on-premises network is offline |
| Typical fit | Organizations with strict compliance rules or legacy SSO already in place | Teams that want fewer moving parts and a cloud-first setup |
| Password policy | Enforced by the external identity provider | Enforced by Entra ID |
Neither option is objectively better. It mostly comes down to what your organization already has running. And also how much control your security team insists on keeping in-house.
How Federated Domain Authentication Works
When someone signs into a federated domain, Entra ID never checks the password at all. It redirects the request to the trusted identity provider, waits for a signed token, and lets the user in once that token checks out.
- The user enters their email at a Microsoft 365 or Entra sign-in page.
- Entra ID recognizes the domain as federated and redirects the browser to the configured identity provider, usually ADFS.
- The identity provider prompts for credentials, or completes the sign-in silently if the device already trusts the internal network.
- Once verified, it issues a signed security token back to Entra ID.
- Entra ID checks that token against the federation trust and grants access.
The whole exchange usually takes under a second when the identity provider is healthy. When it isn’t, that’s where problems tend to start. More on that shortly.
Pros and Cons of a Federated Domain
A federated domain gives an organization tighter control over authentication and better integration with legacy systems. That control comes at a price: added complexity, and a dependency on infrastructure your own team has to keep alive.
Advantages of a Federated Domain
- Keeps sensitive authentication logic on-premises. Which matters in compliance-heavy industries like finance or healthcare
- Works cleanly with legacy applications already wired into ADFS or another SSO system. So nothing needs re-architecting
- Supports advanced MFA setups tied to smart cards or hardware tokens, something not every managed configuration handles as smoothly
Trade-offs to Consider
- Requires a dedicated server or cluster. Plus ongoing patching and certificate renewal
- Creates a single point of failure. If ADFS goes down, cloud sign-in usually goes down with it
- Adds latency in some cases, since every login request has to travel out to the identity provider and back before Entra ID grants access
How to Check If Your Domain Is Federated or Managed
The fastest way to check whether a domain is a federated domain or a managed one is a single PowerShell command through the Microsoft Graph module.
Connect-MgGraph -Scopes Domain.Read.All -NoWelcome
Get-MgDomain | Select-Object Id, AuthenticationType
The AuthenticationType column returns either Federated or Managed for each domain in the tenant. No admin access to PowerShell? The Microsoft 365 admin center shows the same information under Settings, then Domains, next to each domain’s authentication type.
Before any of this works, though, Entra ID needs proof the domain actually belongs to you, typically through a TXT record you can confirm with a quick DNS lookup. That verification step is separate from a WHOIS lookup, which just confirms public registration details rather than authentication settings, though IT teams often check both when bringing a new domain online.
Security Considerations of Federated Domains
A federated domain can actually make certain attacks harder to pull off, mainly because Entra ID never gets the chance to confirm whether a given email address belongs to a real, active account.
That matters more than it sounds. Attackers running account enumeration or password-spraying campaigns often rely on cloud identity platforms leaking small signals about which addresses are valid. Federation blocks that path by routing everything through an external system Entra ID doesn’t get visibility into.
A few other things worth keeping in mind:
- MFA and conditional access rules configured at the identity provider level don’t automatically sync with Entra ID’s own protections. Someone has to keep both sides aligned manually
- A compromised ADFS server effectively compromises every account tied to that domain, so hardening that one system carries outsized weight
- This is a different concern from securing the domain itself, things like locking the registration or keeping WHOIS data private. Both layers matter if the goal is protecting a domain from takeover attempts end to end
Common Federated Domain Problems and How to Fix Them
Most federated domain issues trace back to one root cause: something happened to the identity provider, whether that’s downtime, an expired certificate, or a broken trust configuration.
ADFS Outage Locks Out Cloud Sign-In
This is the most disruptive failure mode, and also the most common. If the on-premises ADFS server goes down and there’s no failover farm behind it, users can’t authenticate into Microsoft 365 at all. It all happen even though nothing changed on the Entra ID side. Some organizations keep a documented emergency procedure to temporarily convert the affected domain to managed authentication using Password Hash Sync as a fallback. Then switch back once ADFS recovers.
Expired Federation Certificate
Federation trusts rely on signing certificates that expire, typically every year or so depending on configuration. When one lapses unnoticed, token validation starts failing across the board. Enabling AD FS auto certificate rollover, and setting a calendar reminder regardless, avoids most of these incidents.
Password Policy Mismatch
On-premises Active Directory password policies don’t always match what users expect from a cloud-first product like Microsoft 365. This mismatch tends to surface as a wave of confused helpdesk tickets right after federation goes live. Documenting the actual policy for support staff, rather than assuming it mirrors Entra ID defaults, heads off a lot of that confusion.
Sign-In Latency
Because every login round-trips to the identity provider, users sometimes notice a delay compared to managed authentication. Network placement of the ADFS servers relative to end users, and proxy configuration, usually explain most of the gap.
How to Migrate From a Federated Domain to a Managed Domain
Migrating a federated domain to managed authentication mainly comes down to running a PowerShell command to switch the domain’s authentication type. Paired with password hash sync so nobody gets locked out mid-migration.
- Enable Password Hash Sync (or Pass-through Authentication) through Entra ID Connect ahead of time. So cloud-ready passwords already exist before the switch.
- Run Get-MgDomain to confirm the current authentication type and keep it documented, useful if a rollback becomes necessary.
- Convert the domain using the Microsoft Graph PowerShell module. Keep the federation configuration details on hand in case you need New-MgDomainFederationConfiguration to roll back.
- Allow up to 60 minutes for the change to fully propagate. And schedule the cutover outside business hours where possible.
- Test sign-in with a small group of pilot accounts before rolling the change out tenant-wide.
Rollback is possible but not instant. So treat this as a planned change with a maintenance window, not something to run mid-afternoon on a whim.
When Should You Use a Federated Domain?
Choose a federated domain when your organization already depends on an existing identity provider. Especially for compliance, legacy application support, or authentication methods Entra ID doesn’t fully replicate on its own.
Choose Federated When Compliance Requires On-Premises Control
Regulated industries sometimes need authentication logs and enforcement to stay within their own infrastructure. Federation keeps that control local while still allowing cloud access to Microsoft 365.
Choose Federated When Legacy Systems Are Already Wired to ADFS
If internal applications already authenticate against ADFS. Extending that same trust to Entra ID is usually simpler than re-architecting everything around a new identity model.
Choose Managed When You Want Fewer Moving Parts
Smaller IT teams, or organizations without dedicated identity engineers. Generally will do better with managed authentication. There’s no server to patch, no certificate to track, no single point of failure sitting between users and their inbox.
Choose Managed When Uptime Matters More Than Legacy Compatibility
Managed domains keep working even during an on-premises outage. For organizations where every minute of downtime has a real cost. That resilience alone can outweigh whatever federation would have offered.
Making the Right Call for Your Organization
There isn’t a universal right answer here, and in practice, plenty of organizations don’t fully commit to one side or the other right away. It’s fairly common to run a mixed state for a while: a handful of domains still federated for legacy reasons. While newer or lower-risk domains move to managed as confidence builds.
That gradual approach tends to work better than an all-at-once switch. Mainly because it gives IT teams room to catch policy mismatches and certificate issues on a smaller scale before they become tenant-wide headaches.
FAQ
Can a domain be both federated and managed at the same time?
Not the same domain, no. Authentication type is set per domain in Entra ID, so a tenant with multiple domains can absolutely run a mix, some federated, some managed. Depending on what each domain needs.
Is a federated domain more secure than a managed one?
It depends on what you’re securing against. Federation blocks certain enumeration attacks by keeping authentication logic external. But it also introduces a single point of failure that, if compromised, affects every account on that domain.
How long does converting a federated domain to managed usually take?
The technical change itself takes up to 60 minutes to propagate. Planning it properly, including pilot testing, tends to add several days on top of that.
Do small businesses really need a federated domain?
Rarely. Most small and mid-sized organizations are better served by managed authentication. Since maintaining ADFS infrastructure without dedicated staff usually creates more risk than it solves.
What happens if the on-premises identity provider goes down for good?
Users on that federated domain lose the ability to sign in until either the provider is restored or the domain is converted to managed authentication as an emergency fallback.
Can a federated domain work with identity providers other than ADFS?
Yes. While ADFS is the most common choice in Microsoft-centric environments. Third-party identity providers like Okta and PingFederate support the same federation model.
References
- Microsoft Learn, “What Is Difference Between Federated Domain vs Managed Domain”
- Icewolf Blog, “The Difference Between Managed and Federated Domain”
- Matrixpost.net, “Azure AD, Federated Domain vs. Managed Domain”
- Wikipedia, “Federated Identity”
- War Room by RSM US, “Managed vs. Federated Office 365, What’s the Difference?”
- Bishnu Baliyase, “Federated Domain vs. Managed Domain, Understanding the Difference and Migration Process”
