Join our Newsletter — 33% off our NHI Course
Home FAQ NHI Lifecycle Management How should organisations manage passkey portability without creating…
NHI Lifecycle Management

How should organisations manage passkey portability without creating new security and lock-in risks?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 19, 2026 Domain: NHI Lifecycle Management

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.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0GV — GovernPortability needs policy, ownership, and risk decisions across identity and recovery workflows.
PR.AA — Identity Management, Authentication and Access ControlPasskey portability directly changes authentication assurance and access continuity.
PR.DS — Data SecurityExport 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-63IAL — Identity AssurancePortability can alter assurance if transfer and recovery downgrade trust in the bound authenticator.
AAL — Authentication Assurance LevelPasskey portability must not weaken the authentication strength of the account after migration.
FAL — Federation Assurance LevelWhen 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 v85 — Account ManagementPasskey portability is a credential lifecycle change that needs controlled assignment and revocation.
3 — Data ProtectionPortable passkeys are sensitive authenticating material that must stay protected in transit and at rest.
6 — Access Control ManagementPortability 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.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 19, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org