Passwordless for Microsoft 365 starts with federation
The conversation that keeps coming up
There’s a pattern I see regularly when talking with enterprise customers about Microsoft 365: they want to go passwordless, they’re already using Cisco Duo for multi-factor authentication (MFA) through a conditional access integration, but they assume the next step would require a massive identity migration project. It’s a reasonable assumption, but it’s wrong. Federation is simpler than its reputation suggests, and it doesn’t require moving your existing applications anywhere.
A quick reality check on your current options
Many organizations come to me already using one of our conditional access integrations with Entra ID, either the custom control or the newer Microsoft Entra External MFA (formerly known as Microsoft External Authentication Methods, or EAM) integration. Both of these integrations are great at what they do: they let you enforce Duo MFA after users authenticate with their Microsoft password. The experience is familiar, the rollout is quick, and you can be up and running in minutes.
But here's the thing: these integrations kick in after the password. Microsoft handles the initial password validation, then hands off to Duo for the second factor. That architecture works well for MFA, but it means passwordless authentication isn't on the table. You can't eliminate the password when someone else is asking for it first.
With federation, the dynamic shifts. When you federate your domain to Duo SSO, Microsoft recognizes your users by their email domain and immediately redirects them to Duo before they ever see a password prompt. Duo owns the entire authentication process, which means we can offer passwordless options like passwordless Duo Push and passkeys right from the start. For your users, this means the login experience shifts slightly: instead of entering their password on a Microsoft page, they'll enter it on a Duo page—or skip the password entirely if you've enabled passwordless authentication.
Want to understand how federation compares to other single sign-on (SSO) approaches? Read our guide to federated identity management vs. SSO.
"But I don't want to move all my apps"
This is probably the most common concern I hear, and it's completely understandable. Organizations often have hundreds or even thousands of applications connected to Entra ID for SSO. The thought of migrating all of those to a new identity provider sounds like a massive undertaking.
Here's the key insight: you don't have to. When you federate your domain to Duo, your existing Entra ID-connected applications continue to work. The federated authentication flow just adds a step: users are redirected from Entra ID to Duo, authenticate with Duo (including passwordless if you've enabled it), and then get redirected back through Entra ID to their application. These redirects happen so quickly that users barely notice, especially if you're using features like Duo Passport to reduce friction across multiple apps.
I've worked with customers who had legitimate concerns about this: they imagined months of migration work, application-by-application. In practice, most of them had federation up and running in an afternoon (in their sandbox—can’t forget about change control), with all their existing apps working exactly as before. The difference is that now their users can go passwordless.
What about my conditional access policies?
Another common misconception is that federating to Duo means abandoning your Entra ID conditional access policies. This isn't the case. Your conditional access policies continue to apply to federated logins, they just evaluate after the user has completed authentication with Duo and been redirected back to Entra ID.
This gives you flexibility. You can keep your existing conditional access policies in place, or you can consolidate enforcement to the Duo side using Duo's policy engine—or some combination of both. Many customers find that Duo's policy framework is easier to manage, especially for things like device trust checks, but the choice is yours.
A note on the Microsoft External MFA transition
If you're currently using our conditional access custom control integration, you may be aware that Microsoft is moving toward their Entra External MFA (formerly known as Microsoft External Authentication Methods, or EAM) framework as the replacement for custom controls. Many customers are evaluating the jump from custom controls to External MFA right now, and it's worth considering federation as part of that conversation.
Both External MFA and the custom control integration share the same fundamental limitation: they operate after the password. They're both excellent for enforcing MFA, but neither unlocks passwordless. If passwordless or features like Duo Passport for seamless cross-context authentication are on your roadmap, federation is the path that gets you there.
External MFA does have some advantages over the custom control integration, particularly around satisfying Microsoft’s built-in MFA requirements for admin portals and privileged identity management. But it also has limitations: For instance, Microsoft restricts you to a single External MFA integration per Entra ID tenant, whereas with custom controls you could create multiple integrations for granular visibility and control. Federation shares this one-integration-per-tenant limitation with External MFA, but it offers something neither conditional access integration can: a consistent, unified authentication experience across all your applications, and the ability to go passwordless.
Using External MFA alongside federation
One point worth clarifying: federation and External MFA aren’t mutually exclusive. In fact, most customers I work with end up using both. Federation handles authentication for your federated domain—the users with email addresses like jdoe@example.com who make up the bulk of your organization. But there are authentication scenarios that federation doesn’t cover.
For example, you may have accounts on your default “onmicrosoft.com” domain, such as service accounts, break-glass admin accounts, or guest accounts. These non-federated accounts still authenticate directly with Microsoft and can still be protected by Duo via EAM. Similarly, Entra ID Privileged Identity Management (PIM) verification prompts and other flows that aren’t traditional authentication flows can be protected using EAM.
The practical takeaway: think of federation as your primary integration for everyday user authentication, with External MFA providing coverage for the edge cases and administrative scenarios that fall outside the federated flow.
What about staged rollouts?
A common question I get: “Can we start with IT, then roll out to marketing, then sales?” The short answer is that federation is a hard cutover at the domain level—you can’t selectively federate some users in a domain while leaving others unfederated.
That said, if you have multiple domains in your Entra ID tenant, you can stage your rollout domain by domain. Each domain is a separate federation configuration, so you could start with a smaller domain to build confidence before federating your primary domain. And if you want hands-on experience before touching production at all, you can federate a test domain in your production tenant or use a sandbox Entra ID tenant. If you’ve been looking for an excuse to buy a fun domain name, here it is. Trying the federation process yourself is a great way to get familiar with the architecture and the PowerShell commands involved.
One important note about subdomains: once you verify a domain in Entra ID, any subdomains you verify afterward will inherit that domain’s federation configuration. So if you verify example.com and then test.example.com, you can’t independently federate the subdomain. If you’re setting up a greenfield environment and anticipate needing independent subdomain configurations, verify your subdomains first.
This is a well-traveled path
I want to address something I sense from customers sometimes: a hesitation around whether federation is a proven approach. Maybe it feels like a bigger architectural change than it really is, or maybe the word “federation” just sounds intimidating.
The reality is that federation is how enterprise identity has worked for decades. If your organization ever used Active Directory Federation Services (AD FS)—and many enterprises did—you were already federating. The difference is that Duo SSO is dramatically easier to set up and manage than AD FS ever was. The actual federation process typically takes just a few minutes: verify the prerequisites in Entra ID, create the application in the Duo Admin Panel, run the preconfigured PowerShell script we provide, and you're done.
I've walked through this process with healthcare systems managing thousands of clinicians, with law firms protecting sensitive client data, with financial institutions under strict regulatory requirements. The pattern is consistent: what seems like a big step turns out to be straightforward, and the capabilities it unlocks—passwordless authentication, simplified authentication flows, centralized policy management—make it well worth the investment.
Getting started federating identity with Duo
If you're interested in exploring federation for your organization, here's what I'd recommend. First, take a look at our Duo Single Sign-On for Microsoft 365 documentation. It walks through the prerequisites and federation process in detail. The main requirements are straightforward: a verified domain in Entra ID, and users synced via Entra Connect Sync (though Duo's new directory capabilities are opening up even more options here).
If you're a current Duo Care customer working through this decision, reach out to your Duo Care team. We've had these conversations many times, and we're happy to help you think through the architecture that makes the most sense for your organization. The goal isn’t to push everyone toward federation regardless of their situation; it’s to make sure you’re aware of the full range of options and what each one unlocks. That said, if passwordless is on your roadmap, federation is likely the path you’re looking for.
Explore the Duo Single Sign-On for Microsoft 365 documentation to get started or contact your Duo Care team to talk through your options.