Organisations should treat passkey portability as a controlled identity lifecycle problem, not a convenience feature. The secure path is to use standardised import and export formats, preserve strong protection during transfer, and avoid plaintext handling at every stage. Teams should also plan for migration, recovery, and user choice across password managers so portability improves resilience instead of weakening trust.
Why portability should be governed like identity lifecycle, not user convenience
Passkey portability changes more than migration mechanics. It affects who can move authenticators, which devices or managers remain trusted, how recovery is handled, and whether an organisation can still enforce revocation when a user changes platform. That is why portability needs lifecycle rules, ownership, and a clear decision on what “portable” means for corporate accounts versus personal use.
For teams already managing credential rotation and offboarding, the same discipline applies here: portability must preserve control of the authenticating material while still allowing the user to move between approved ecosystems. The lifecycle view is the best way to avoid accidental lock-in, orphaned registrations, or a transfer path that weakens the original assurance level.
Standardisation matters because portability without common formats becomes policy by vendor default. Organisations should prefer ecosystems that support interoperable export and import, then validate whether the transfer preserves device binding, account ownership, and recovery options. Where portability is supported by a managed identity program, it should sit alongside lifecycle governance and short-lived credential handling so the portability path does not silently create a long-lived exposure.
Controls that keep transfer safe without turning portability into plaintext migration
The main risk is not the existence of export and import itself, but how the data is handled during transfer. If a portability workflow exposes passkeys in plaintext, reuses weak recovery channels, or skips device and account verification, the organisation has simply moved the problem from one platform to another. Secure portability should maintain confidentiality and integrity throughout the move, including at rest, in transit, and during any temporary unpacking step.
NIST Cybersecurity Framework 2.0 is a useful governance lens here because the issue spans identity assurance, data protection, and recovery. Organisations should also align the transfer model with key-management discipline, because portability is fundamentally about protecting an authenticating secret or key material while it changes form or custody. That is why NIST SP 800-57 Key Management is relevant when the design involves cryptographic wrapping, escrow, or re-protection during migration.
The practical control question is whether the organisation can prove that no one handled the underlying material in a readable form and that the receiving system re-established protection before the import completed. If that cannot be demonstrated, the portability design is too permissive for enterprise use. In those cases, the safer answer is to limit portability to approved managers, approved devices, and auditable recovery workflows rather than allowing free-form exports.
For wider control coverage, organisations can map the same requirements to CIS Controls v8 and the access, account management, and data protection practices that already support strong credential hygiene. If portability affects regulated environments, ISO/IEC 27001:2022 Information Security Management provides the governance frame for treating the transfer path as part of the control environment, not an exception to it.
What good portable passkey governance looks like in practice
Good practice starts with a policy decision: which identities may export, under what conditions, and to which destinations. Not every account should be equally portable. High-value or privileged users may need tighter restrictions, stronger re-authentication, or mandatory support-assisted migration. That trade-off is often preferable to universal portability, because it lets organisations preserve user choice without creating a path that weakens assurance for sensitive roles.
What to verify: confirm that the destination manager or device supports the same assurance level, that recovery remains available if the source is lost, and that revocation on the old platform is immediate after transfer. Also verify whether the portability workflow changes the phishing resistance or device-bound properties that made passkeys attractive in the first place.
Decision rule: if export creates any plaintext exposure, treat the workflow as a high-risk migration and require stronger approval, monitoring, or an alternative path. If the transfer cannot preserve revocation, auditability, and user recovery, do not call it portability, call it a new credential issuance process.
Practitioner takeaway: the safest portability model is the one that lets users move without letting secrets wander, which means standardisation, re-protection, and revocation must travel together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV — Govern | Portability needs policy, ownership, and risk decisions across identity and recovery workflows. |
| PR.AA — Identity Management, Authentication and Access Control | Passkey portability directly changes authentication assurance and access continuity. | |
| PR.DS — Data Security | Export and import must protect passkey material from plaintext handling or exposure. | |
| Recommendation — Define who can export passkeys, under what conditions, and how exceptions are approved. Preserve authentication strength and revoke the old binding immediately after transfer. Encrypt or re-protect transferable material so no readable secret is exposed during migration. | ||
| NIST SP 800-63 | IAL — Identity Assurance | Portability can alter assurance if transfer and recovery downgrade trust in the bound authenticator. |
| AAL — Authentication Assurance Level | Passkey portability must not weaken the authentication strength of the account after migration. | |
| FAL — Federation Assurance Level | When portability crosses managers or ecosystems, the trust and assertion model must remain controlled. | |
| Recommendation — Keep the receiving process aligned to the original assurance level before accepting the moved passkey. Require a transfer path that preserves the account's authentication assurance level. Validate that any cross-ecosystem transfer preserves the intended trust and recovery model. | ||
| CIS Controls v8 | 5 — Account Management | Passkey portability is a credential lifecycle change that needs controlled assignment and revocation. |
| 3 — Data Protection | Portable passkeys are sensitive authenticating material that must stay protected in transit and at rest. | |
| 6 — Access Control Management | Portability must preserve least privilege and prevent uncontrolled reuse across managers or devices. | |
| Recommendation — Track export, import, and revocation as accountable account-management events. Protect transferred passkey material with encryption and restricted handling throughout the move. Limit portability to approved destinations and remove obsolete access bindings after migration. | ||
Related resources from NHI Mgmt Group
- How should security teams implement an AI gateway in multi-cloud environments without creating new lock-in?
- How should security teams implement biometric authentication for citizen access without creating new privacy and fraud risks?
- How should organisations automate access to shared social media accounts without creating new security gaps?
- How should security teams implement OAuth device flow for CLI tools without creating new credential risks?
