Yes, if the migration is meant to add passkey capability rather than replace the whole identity stack. Social connections usually remain with the primary identity provider, while the authentication layer handles passkeys and MFA. Keeping those responsibilities separate reduces the chance of breaking existing login flows during platform change.
Why social login usually stays with the identity provider during passkey migration
Keeping social login in the identity provider preserves the existing trust boundary while you introduce a new authenticator method. Passkeys change how users prove control of an account, but they do not require you to rebuild federation, account linking, consent, or provider-specific account recovery on the same cutover date. That separation lets the migration focus on authentication quality without destabilising sign-in.
A clean separation also reduces the chance that the migration accidentally breaks users who still depend on Google, Apple, or other social connections for first-time access, step-up recovery, or account re-entry on new devices. The practical question is not whether social login is “legacy”; it is whether the identity provider still needs to broker multiple entry paths while the authentication layer becomes passkey-capable.
When teams keep those layers distinct, they can roll out passkeys incrementally, test enrollment and fallback behaviour, and preserve the existing social identity mapping rules. That is usually safer than moving social connections at the same time as authenticator change, because the failure surface is broader and the debugging path is less clear.
Where the architecture can go wrong
The main failure mode is confusing authentication migration with identity-provider migration. If a team tries to redesign social login, passkey enrollment, MFA policy, and account linking all at once, it is easy to create duplicate accounts, orphaned identities, or broken recovery flows. Those issues are operationally noisy and, in some cases, can lock real users out of their accounts.
Another common mistake is treating passkeys as a replacement for federation rather than an additional authentication method. Social login still carries its own trust assumptions, token handling, and provider dependency. If those are removed too early, downstream applications may lose a working sign-in path even though the new passkey flow is technically sound.
For a broader view of how identity providers, federation, and sign-in hardening fit together, the Identity Provider and SSO Security Guide is the right companion reference. For migration planning, the IAM and Identity Provider Buyer’s Guide is useful because it treats passkeys, SSO, and platform change as connected design choices.
How IAM teams should stage the change
Start by deciding which layer owns what. The identity provider should continue to own social identity federation, account linking, and recovery policy, while the authentication layer owns passkey registration, verification, and step-up behaviour. If those responsibilities are not documented before the rollout, teams tend to duplicate logic in the application layer and create policy drift.
Then sequence the rollout around compatibility, not novelty. Keep existing social connections working, add passkeys as an additional method, and only consider deprecating social paths if usage, recovery outcomes, and user support data show that the organisation can absorb the change safely. A phased deprecation is easier to govern than a hard cut.
If you need a practical migration reference, the Passwordless and Passkeys Guide covers rollout and recovery considerations, including the point that passkeys should be introduced without weakening the existing account-recovery path. For the authentication side of the implementation, NIST SP 800-63 Digital Identity Guidelines is the most relevant external reference because it anchors phishing-resistant authenticators and assurance thinking.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkeys and social login both affect authenticators and assurance during migration. |
| Recommendation — Use phishing-resistant authenticators and stage fallback changes to preserve successful sign-in. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passkey rollout depends on managing authenticators, enrollment, and recovery credentials. |
| IA-2 — Identification and Authentication (Organizational Users) | The migration changes how users authenticate, even when social federation remains in place. | |
| Recommendation — Manage authenticator enrollment, rotation, and recovery to avoid lockouts during migration. Keep authoritative authentication controls consistent while adding passkey sign-in paths. | ||
| ISO/IEC 27001:2022 | A.5.17 — Authentication information | Passkey migration changes how authentication information is protected and used. |
| Recommendation — Protect authentication information and update it only through controlled migration steps. | ||
| OWASP ASVS | V6 — Authentication | Passkey adoption and social-login coexistence are authentication design decisions for applications. |
| Recommendation — Verify the application supports strong authentication without breaking existing login flows. | ||
Practitioner Guidance
What to verify: Confirm that every social-login route still lands on the same authoritative account record after passkey enrollment, and that the new method does not create a parallel identity namespace.
Decision rule: If the change only adds passkey support, keep social connections in the identity provider; if the change also includes account-model redesign or provider replacement, treat it as a separate migration with its own rollback plan.
What to measure: Watch successful sign-in rate, failed recovery attempts, duplicate-account creation, and help-desk tickets tied to login or account linking. Those signals tell you whether the migration is stable before you change fallback policy.
Practitioner takeaway: The safest pattern is to migrate the authenticator first and the identity architecture second, because sign-in reliability usually fails when teams collapse those two changes into one release.
Related resources from NHI Mgmt Group
- What should IAM leaders do when an identity provider must remain in place during migration?
- Which IAM control matters most when organisations need to keep access available during identity provider outages?
- Why can social login increase risk when users keep weak passwords on the upstream identity provider?
- How do teams decide whether to keep SMS MFA during an identity migration?