Entra ID - Federation or EAM for Passkey deployment

Adding to the good answer above, here are a few points that usually decide this:

1. On authentication strength for EAM: External MFA (the GA name for EAM) satisfies the "Require multifactor authentication" grant, including PIM and device registration. It is still not supported in authentication strengths, built-in or custom. Microsoft hasn't committed to a date, so don't plan around it.

2. Option 1 (replace ADFS with third-party federation) keeps you federated. Entra then never sees the first factor, Entra-native passkeys and phishing-resistant strengths become harder to enforce, and you swap one IdP dependency for another. Option 2 is the long-term direction.

3. A practical sequence:

- Enable password hash sync now, even if you stay federated for a while. It's your break-glass path if ADFS fails, and Entra ID Protection needs it to detect leaked credentials.

- Use staged rollout by group, pilot first. Groups can be rolled back.

- Keep the third party as External MFA so users notice almost nothing.

- Then enable Entra passkeys (Authenticator or FIDO2) with passkey profiles. Require the "Phishing-resistant MFA" strength for admins and high-risk groups first. That needs P1, not P2.

- As users register passkeys, External MFA becomes a fallback and you can reduce it over time.

4. If you don't have P2: risk-based CA needs P2. Many tenants cover the gap with compliant/hybrid-joined device requirements, token protection where supported, short sign-in frequency for admins, and sign-in logs streamed to a SIEM. Buying P2 only for privileged users is also allowed.

5. Pitfall: if users are enabled for SMS/voice, passkey auto-enablement since September 1, 2026 can add an "all passkey types" profile on top of yours. Check before the pilot, because it can let synced passkeys through.

Docs: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-external-method-provider and https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-staged-rollout

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.