Notifications
Clear all
Topic starter
11/07/2026 8:37 pm
TL;DR: Passage’s shutdown on January 16, 2026 makes migration planning a passkey governance issue, not just an implementation task, because Authsignal’s guide shows how verified email, phone, and passkey public keys map into a new authentication layer without re-enrollment, according to Authsignal. The hard part is preserving identity continuity, auditability, and authenticator state across systems, not simply moving users.
NHIMG editorial — based on content published by Authsignal: How to migrate from Passage to Authsignal
Questions worth separating out
Q: How should teams migrate passkeys without forcing users to re-enrol?
A: Keep the public key, credential ID, device metadata, and verified state intact across the migration.
Q: Why do passkey migrations fail even when user records copy successfully?
A: They fail when teams move profile data but lose the cryptographic or verification state that makes the authenticator usable.
Q: What do identity teams get wrong about authentication platform migration?
A: They often treat migration as a data-mapping exercise instead of a lifecycle event.
Practitioner guidance
- Inventory every authenticator type before cutover Separate verified email, verified phone, and passkey records into distinct migration paths so each factor lands in the correct enrolment state.
- Validate passkey public key imports in a test tenant Check that imported credential IDs, device names, backup flags, and verification timestamps still support successful login after the target system accepts the migration dataset.
- Preserve authentication and profile boundaries Keep user metadata, social login state, and event history in the systems that own them, while moving only the authentication state required for login and MFA.
What's in the full article
Authsignal's full migration guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step API examples for enrolling verified email, SMS, and WhatsApp authenticators during migration
- Code-level migration patterns for mapping Passage user objects into Authsignal user and authenticator records
- Passkey export coordination details for transferring public keys without forcing re-enrollment
- Integration guidance for replacing Passage SDK calls with Authsignal flows across login, registration, session, and MFA
👉 Read Authsignal's migration guide for moving users from Passage to Authsignal →
Passkey migration from Passage: what IAM teams need to map?
Explore further
11/07/2026 9:06 pm
Passkey migration exposes the identity continuity gap between verification state and credential state: verified email or phone can be re-established programmatically, but passkey continuity depends on preserving the public key and device binding. That split means migration success cannot be measured only by user records moving across systems. Practitioners should treat authenticator fidelity as a first-class control objective, not a backend detail.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
Q: How do IAM teams know a passkey migration was successful?
A: Success means existing users can sign in with their current passkeys without re-registration, support tickets stay low, and the destination system shows the correct verification timestamps and authenticator records. If users are silently forced into fallback methods, the migration has not preserved authentication continuity.
👉 Read our full editorial: Passage migration shows why passkey identity mapping matters
