Entra ID - Federation or EAM for Passkey deployment

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.