They should define separate paths for first enrolment, verified device change, and ongoing sign-in. Each path should state which factors are required, how the device is associated to the user, and when re-verification is mandatory.
How CIAM teams should structure passkey enrolment
ciam teams should not treat passkey enrolment as one generic flow. The safer pattern is to separate first enrolment, verified device change, and ordinary sign-in so each flow can enforce the right assurance level, account linkage, and recovery step. That keeps enrollment policy explicit, reduces accidental downgrade paths, and makes later support decisions easier to audit.
For first enrolment, the main question is how the customer proves they are the right person before a passkey becomes a trusted authenticator. For a device change, the question becomes whether the user is re-established through a previously trusted factor or through a stronger recovery path. For ongoing sign-in, the passkey should normally carry the authentication load without re-running full proofing unless policy says otherwise.
CIAM teams should also design the relationship between the user and the device carefully. A passkey can be bound to a single device, synced across a vendor ecosystem, or used alongside other authenticators, and each choice changes the operational model. If your policy depends on one device being trusted, you need a clear rule for how trust is revoked when that device is lost, reset, or replaced.
What each enrolment path must define
Every path should state three things in writing: which factors are required, how the device is associated to the user, and when re-verification is mandatory. That is especially important when the enrolment journey differs between web, mobile, and support-assisted flows, because the same user can encounter different trust decisions in each channel.
First enrolment should answer whether the user can create a passkey after only an existing authenticated session, or whether a step-up factor is needed. Verified device change should answer what qualifies as proof that the new device belongs to the same user and when the old device must be invalidated. Ongoing sign-in should answer whether the passkey alone is enough, or whether risk signals or policy exceptions can trigger additional verification.
For a useful implementation reference on phishing-resistant sign-in and passkey rollout, teams can compare their path design with NIST SP 800-63 Digital Identity Guidelines and Passwordless and Passkeys Guide. For broader CIAM operating patterns, Customer IAM (CIAM) Guide and the Workforce Identity Security Guide show how enrolment, recovery, and step-up decisions need to be explicitly separated.
Why device change is the hardest part of passkey policy
Device change is where many passkey implementations become ambiguous. If the new device is accepted too easily, attackers who have already obtained session access, help desk access, or a secondary factor can silently bind a passkey to their own hardware. If the new device is too hard to register, legitimate users fall back to weaker recovery channels that often become the real attack surface.
The practical goal is to keep device replacement inside a controlled re-verification path, not an improvised support exception. Teams should decide in advance whether device change is self-service, support-mediated, or risk-triggered, and whether the old device must still be present for approval. A clean policy makes it much easier to distinguish normal migration from account takeover.
This is one reason current guidance for phishing-resistant authentication is so useful: passkeys reduce password and phishing exposure, but they do not remove recovery risk. For implementation detail and assurance language, the NIST guideline and the passkeys guide above are the right starting points.
Risk and Threat Considerations
Passkey enrolment is not just a usability issue, because weak enrolment and recovery design can create account takeover paths that bypass the very protection passkeys are meant to provide. The main exposure is not usually the cryptography itself, but the policy gap around how a new device gets authorised and how a stolen session or recovered account can be turned into a lasting trusted authenticator.
Failure mechanism: An attacker who gains temporary access through phishing, social engineering, session theft, or support abuse may exploit an under-specified device-change flow to register their own passkey or replace the user’s trusted device without adequate re-verification.
Impact: Once the attacker controls a trusted passkey path, they can persist beyond password resets and continue to authenticate as the customer, which makes remediation harder and can turn a short-lived compromise into durable account control.
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, OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Passkey enrolment depends on authenticator assurance and re-verification rules. |
| Recommendation — Align enrolment and device-change flows to assurance levels and phishing-resistant authentication guidance. | ||
| OWASP ASVS | V6 — Authentication | Passkey enrolment is an authentication lifecycle problem requiring strong verification paths. |
| V10 — OAuth and OIDC | CIAM passkey journeys often sit inside federated sign-in and step-up orchestration. | |
| Recommendation — Define authentication and recovery requirements for enrolment, device change, and sign-in. Ensure federation flows preserve assurance when a passkey is enrolled or replaced. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Passkeys are authenticators whose lifecycle and replacement need explicit control. |
| IA-2 — Identification and Authentication (Organizational Users) | The core question is how users are authenticated across enrolment and sign-in states. | |
| Recommendation — Manage authenticator issuance, binding, replacement, and revocation through controlled processes. Require the appropriate authentication strength before allowing enrolment or device reassociation. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Passkey enrolment needs clear identity-to-device association and lifecycle ownership. |
| A.5.17 — Authentication information | Passkeys and recovery factors are authentication information that must be protected and governed. | |
| Recommendation — Assign ownership for identity binding and lifecycle handling across enrolment and device change. Control how authentication material is issued, stored, and replaced during enrolment flows. | ||
Practitioner Guidance
What to prioritise: Lock down the device-change path before you scale enrolment. That is the point where user convenience and attacker opportunity most often collide, especially when users replace phones or use synced passkey across ecosystems.
What to verify: Verify that the policy answers three concrete questions for each path: what authenticates the user, what binds the device, and what event forces re-verification. If those answers vary by channel, document the differences explicitly rather than leaving them to implementation detail.
Common mistake: Treating enrolment as a one-time setup task. In practice, passkey trust is lifecycle policy, not just registration, and the recovery and device-change rules will decide whether the control stays strong.
Practitioner takeaway: The best passkey programmes make trust transitions visible, intentional, and revocable, because the security value comes from controlling how a device becomes trusted, not just from making sign-in passwordless.
Related resources from NHI Mgmt Group
- How should security teams handle passkey login when users switch devices?
- How should security teams handle identity data quality when customer journeys move across devices and channels?
- How should security teams handle fragmented telemetry across connected vehicles, edge devices, and AI-driven mobility systems?
- How should teams handle remote file access across devices in a zero trust network?