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.
At a glance
What this is: This is a migration guide that explains how Passage users and passkeys map into Authsignal, with the key finding that preserving public keys and verified authenticator state is what prevents user disruption.
Why it matters: It matters because identity teams handling human authentication must preserve enrolment state, recovery paths, and audit trails during platform transitions or risk breaking access for active users.
👉 Read Authsignal's migration guide for moving users from Passage to Authsignal
Context
Passkey migration is an identity continuity problem, not just a data export problem. When an authentication platform changes, teams have to preserve verified identity state, authenticator bindings, and the cryptographic material that lets existing passkeys keep working.
For IAM and identity engineering teams, the central risk is breaking the relationship between a user, their verified factors, and the credential metadata needed for seamless login. That makes migration planning part of human identity lifecycle governance, especially where passwordless access is already in production.
Key questions
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. Test the destination system in a staging environment first, then confirm that existing passkeys authenticate immediately after cutover. If any of those bindings break, users will need to re-enrol even if the data export succeeded.
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. A copied user record is not enough if the public key, verified factor status, or default method is missing. In those cases, the login experience breaks even though the migration looks complete.
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. The real task is preserving enrolment state, authenticator bindings, and auditability while separating authentication responsibilities from profile ownership. That is what keeps access continuity intact during a platform switch.
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.
Technical breakdown
Passkey public keys and authenticator continuity
Passkeys depend on public key cryptography, where the server stores the public key and the device keeps the private key. During migration, the public key and associated metadata must move cleanly so the authenticator can still be verified after the platform switch. If the public key is not imported correctly, the user’s existing passkey may still exist on the device but will no longer authenticate against the new system. That creates a hidden re-enrollment event, even when the migration looks complete on paper.
Practical implication: verify that passkey public keys, credential IDs, and device metadata survive the migration path exactly, not approximately.
Verified email and phone as migration anchors
The guide shows a common migration pattern for human authentication: use already verified email and phone attributes to auto-enrol users into the destination system. That works because verification state can be treated as a trusted input when the source system already established it. In practice, this is a lifecycle mapping exercise, not a simple copy operation. The destination platform has to preserve which factors are verified, which methods are allowed, and what the default authentication method should be after cutover.
Practical implication: map verified status fields explicitly and test that each authenticator type lands in the correct enrolment state.
Authentication layer separation and profile data boundaries
Authsignal’s model separates authentication state from broader user profile data, which is a useful architectural pattern for migration design. Identity systems often fail when they try to carry profile, event history, and authentication state through the same boundary without clear ownership. Here, the article makes a clean distinction: authentication data migrates, while user metadata and other profile-owned fields stay in the primary user database or IdP. That separation reduces coupling and makes future platform changes easier to manage.
Practical implication: define which attributes belong in the authentication layer before migration starts, and leave profile-only data where it already belongs.
NHI Mgmt Group analysis
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.
Authentication state is not the same as user profile state, and migration projects fail when the two are mixed: the article’s separation of authentication data from user metadata reflects a governance boundary that many programmes blur. When profile data and authenticator data move together without clear ownership, auditability weakens and recovery logic becomes fragile. Identity teams should keep authentication authority narrow and explicit.
Passkey cutover is a lifecycle event, not a one-time engineering task: the article shows that user ID continuity, enrolment state, and verification timestamps all matter during the transition. That makes migration part of human identity lifecycle management, with change control, cutover testing, and rollback planning all tied to access continuity. Teams should govern the transition as an identity programme milestone.
Zero-disruption migration depends on preserving trust in existing authenticators, not just reissuing access: if users must re-register every passkey, the migration may be technically functional but operationally degraded. That creates avoidable friction and increases support burden at the exact point where trust in the authentication experience matters most. Practitioners should evaluate migration success by preserved authentication behaviour, not by completion of data transfer alone.
From our research:
- 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.
- Forward look: The NHI governance lesson from The State of Secrets in AppSec is that secrets and authenticator state need separate lifecycle controls, especially when systems and identity layers change.
What this signals
Passkey migrations are becoming a normal part of identity programme maintenance, which means the operational burden shifts from password resets to authenticator continuity. The teams that do this well will be the ones that can preserve verification state while changing authentication platforms, without creating a hidden re-enrolment event for users.
Credential continuity gap: the real issue is not whether a user record moved, but whether the authenticating credential still works after the platform boundary changes. That is the point at which migration planning becomes identity governance, not just integration work.
For practitioners
- 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. Do not assume a user object alone contains everything needed for seamless authentication continuity.
- 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.
- Run cutover tests for default verification methods Confirm that the intended default method remains passkey where appropriate, and that fallback methods do not unintentionally change the user’s login path after migration.
- Coordinate rollback around authenticator continuity Build a rollback plan that restores access without forcing mass re-enrolment if passkey imports or verified factor mapping do not behave as expected.
Key takeaways
- Passkey migration succeeds only when authentication state, verified factors, and credential bindings are preserved together.
- The article shows that profile data and authentication data should be treated as separate governance domains during platform change.
- Identity teams should measure migration success by preserved login behaviour, not by whether the export and import completed.
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 CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63C | The migration preserves federation and authenticator continuity across systems. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and credential state are central to the migration workflow. |
| NIST SP 800-53 Rev 5 | IA-5 | Authenticator management directly applies to passkey and verified factor migration. |
| NIST Zero Trust (SP 800-207) | The post reinforces continuous verification across an authentication boundary change. |
Treat verified-factor transfer as an access-control control and validate identity continuity before go-live.
Key terms
- Passkey Public Key: The public half of a passkey credential that the server stores and uses to verify a login challenge. In migration work, this object matters because it preserves cryptographic continuity across platforms, while the private key remains on the user’s device and never leaves it.
- Verified Authenticator: An authentication method that the source system has already confirmed belongs to the user, such as a verified email address or phone number. During migration, verified status can be reused to enrol the same factor in a new platform without forcing the user to repeat the original proofing step.
- Authentication Layer: The part of the identity stack that handles sign-in, factor enrolment, and challenge verification rather than broad user profile management. Separating this layer from profile data makes migrations cleaner because only the data needed to authenticate has to move.
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
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or identity lifecycle management in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
