Forum Discussion
Entra ID - Federation or EAM for Passkey deployment
Question for the community: Looking to replace Entra to ADFS federation and also implement passkey. Have an existing deployment with a third party MFA provider. I want to limit the disruption for my end users as much as possible and am looking at 2 possible paths forward:
- Replace ADFS with third party, allowing Passkey and push from the third party, as well as first factor auth.
- Move to Entra staged rollout with EAM and have Entra deal with first factor. I know this wont include the ability to use third party first factor.
Issues I am seeing is that the system browser setting needs to be enabled on the tenant and cant enforce external auth strengths in entra conditional access. All roads keep leading back to Entra which is fine with me but I do not currently have a P2 license for the advanced risk analytics. My third party currently has that capability. Would also love to know any rumblings of authentication strenght support for External MFA.
What are some of the configurations out there that you all are doing and any pros/cons of each.
1 Reply
Both paths work, but they solve different things, and I would separate the decision into first factor and phishing-resistant factor. My take, from the Microsoft documentation as I understand it:
- Moving off ADFS. Staged rollout is the low-disruption way to do it: move users group by group from federation to cloud authentication (password hash sync or pass-through), and roll back a group if something breaks. Once the last group is moved you can retire the federation trust. That part does not depend on which MFA you choose.
- Third-party MFA through EAM. External authentication methods let your current provider act as an MFA method inside Entra, and it satisfies the Require multifactor authentication grant. Users keep the MFA experience they know. The limits you found are real: it does not work with authentication strengths, so you cannot require it as a specific strength, and risk signals from your provider do not feed into Entra Conditional Access.
- Passkeys the Entra way. Entra passkeys (FIDO2, and the Authenticator passkey) work natively, and they are the route to a phishing-resistant requirement through an authentication strength, which is a Conditional Access feature included with P1. You do not need P2 for that.
- Risk-based policies are what you lose without P2, since the ID Protection signals need it. Without P2 you can partly make up for it with Conditional Access on location, device compliance and sign-in frequency, smart lockout, and the sign-in logs exported to your SIEM.
A pattern that keeps disruption low is to move first factor to Entra with staged rollout, keep your third party as the MFA through EAM for now, and then roll out Entra passkeys to groups (admins and high-risk users first), requiring the passkey strength for them. As for authentication strength support for external MFA, I have not seen a committed date, so check What's new in Entra and the roadmap before you plan around it.
