What happens when existing users are migrated to passwordless sign-in without first verifying their current identity?

The migration can create duplicate accounts, split entitlements, and leave the old and new login paths pointing to different records. That breaks continuity for authorization, audit, and support. A safer approach is gradual opt-in, where users authenticate once with their current method, the account is matched, and the new passwordless method is then attached to the same identity.

Why Unverified Passwordless Migration Breaks Account Continuity

When a passwordless method is added to an account without first confirming who is already behind that login, the system can treat the new sign-in as a different person. That creates a second record instead of extending the existing one, which is why support teams later see “missing” entitlements, conflicting profiles, or users who can sign in but no longer reach the same data and approvals.

The core problem is identity binding. Passwordless is not just a new authentication method, it becomes the new proof that links a person to an account. If that proof is attached before the current identity is verified, the migration can fork the account history and separate the old authenticated path from the new one.

That is why continuity matters as much as strength. A passwordless rollout can be technically secure and still fail operationally if it does not preserve the original identity record, role assignment, and audit trail. For a transition like this, the question is not only whether the new method works, but whether it attaches to the right existing account.

What Goes Wrong in the Directory, Authorization, and Audit Trail

The most immediate failure is duplicated identity state. One record remains tied to the old login method while another is created for the passwordless credential, and those records can diverge in group membership, application entitlements, recovery data, or help desk history. The user experience then becomes inconsistent across systems that rely on a single canonical account.

Authorization is often the first downstream control to drift. If entitlements are stored against one account and sign-in now lands on another, access reviews can appear correct on paper while the actual login path no longer matches the approved permissions. That makes troubleshooting slow and can lead to false assumptions that a user has lost access, when in fact the permissions sit on the wrong identity object.

Auditability suffers too. Logs, approval records, and support actions may reference different account identifiers for the same person, which weakens traceability after a change, incident, or access review. A clean migration keeps a single identity lineage so that the account history, access decisions, and recovery steps remain attributable to one record.

Why Gradual Opt-In Is Safer Than Forced Conversion

A safer migration pattern is to verify the existing user once, confirm the account match, and then attach the new passwordless method to that same identity. Gradual opt-in gives the operator a chance to confirm continuity before changing the primary login path, rather than assuming the new credential or device has correctly mapped itself.

In practice, this means the old method should remain available until the new method has been linked and tested against the existing account state. If the migration flow cannot prove that match, it should stop and route the case for manual verification instead of creating a fresh profile that later has to be merged.

This approach also reduces support risk. Users can fall back to the known good login method while the new method is introduced, which lowers the chance of lockouts, duplicate recovery flows, and entitlement disputes. The control objective is not merely to enable passwordless sign-in, but to preserve identity continuity during the transition.

Risk and Threat Considerations

Unverified migration can be abused as an account takeover and confusion path. If the system accepts a new passwordless assertion without tying it to the pre-existing account, an attacker may create a parallel identity surface, redirect recovery or notifications, or exploit the split record to hide privilege changes from ordinary review.

Failure mechanism: The account is re-created or re-bound on the basis of the new sign-in alone, so access, audit history, and recovery data no longer point to one authoritative identity.

Impact: Users can lose or duplicate access, reviewers may miss entitlement drift, and support or incident response may have to reconcile two records for one person, increasing the chance of unauthorized access persisting unnoticed.

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	Passwordless migration hinges on authenticating the existing user and binding the new authenticator to the right identity.
Recommendation — Verify the current user before binding a new passwordless authenticator to the existing account.
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Existing-user migration depends on correctly identifying and authenticating the user before account changes.
	IA-5 — Authenticator Management	The issue involves attaching and managing a new authenticator without breaking account continuity.
	AU-2 — Event Logging	Split accounts and diverging login paths require auditable records for migration and support traceability.
Recommendation — Require authenticated confirmation before altering a user’s account authentication path. Manage passwordless authenticators so they bind to the intended existing account. Log identity-migration events so account linkage remains traceable.
OWASP ASVS	V6 — Authentication	Passwordless enrollment is an authentication change that must preserve the original authenticated identity.
	V7 — Session Management	Broken continuity can create parallel login state and inconsistent active access after migration.
Recommendation — Ensure the new authentication method is linked to the existing verified account. Preserve session and account continuity when changing sign-in methods.
ISO/IEC 27001:2022	A.5.16 — Identity management	The question centers on maintaining a single controlled identity across authentication method changes.
	A.5.17 — Authentication information	Passwordless sign-in changes the authentication information bound to the account.
Recommendation — Keep one authoritative identity record through passwordless migration. Bind new authentication information only after verifying the existing user.

Practitioner Guidance

What to verify: Before enabling passwordless enrollment, confirm the migration flow requires an established login or equivalent identity proofing step and writes the new factor to the existing account record, not to a fresh profile.

Decision rule: If the system cannot deterministically match the user to the current account, treat the case as a manual verification event rather than an automated migration. That is especially important where the account carries production access, delegated approval rights, or support-sensitive entitlements.

What good looks like: One user, one identity record, one audit trail, with the old and new authentication methods both resolving to the same account until the old path is deliberately retired.

Practitioner takeaway: Passwordless rollout fails when authentication improves faster than identity binding; preserve the account, then change the method attached to it.