Integration responsibilities
Account identifiers and login choices
Use the account identifier defined by your integration, such as a username or customer number. Email is an example, not a requirement. If accounts can share an email address, agree on a unique mapping to the account before enrollment. Your backend must resolve the verified passkey identity to that same account at login. Compare identifier-first and passkey-button approaches. Include account switching and unknown-user behavior in the design. Review what the UI reveals about an account before authentication, including remembered identifiers on shared devices.Enrollment and adoption
Offer enrollment after a successful login, once the user has completed your required authentication steps. Keep the eligibility check in the flow even if the account already has a passkey: the user may be on another device or using a different credential provider. You can also offer enrollment at another authenticated point in your app. The SDKs support an enrollmentsituation so configured rules can distinguish those contexts. Agree on the situation names and behavior with Corbado. Conditional creation is a separate, platform-dependent option after eligible password autofill; it does not replace explicit enrollment for everyone.
Measure enrollment and passkey login usage separately. Login frequency, device changes, credential availability and your chosen prompts affect how quickly enrollment turns into repeat usage.
Fallback, recovery and lost devices
Define what happens when the user cancels, has no usable passkey or cannot complete the ceremony. Your application must handle the SDK’s fallback result and provide the intended alternative login. Recovery belongs to your identity system. Decide how users regain access if they lose every usable credential, how support verifies identity and when a recovered account may enroll a new passkey. A synced passkey may be available on a replacement device, but this depends on the user’s credential provider and access to it. For a lost or stolen device, distinguish revoking a passkey from revoking existing application sessions. Deleting a passkey from the server prevents its future use there; it does not itself terminate your application’s sessions. Review both actions in your incident and recovery procedures.Shared devices and security keys
A remembered identifier or device context is not proof of the person using the device. Include account switching, sign-out and shared-device tests. Review your user-verification configuration and how people share access to local device credentials. If you plan to use hardware security keys, agree on the allowed authenticators and enrollment policy. Test registration, login, loss of a key and a replacement path across your supported clients. Avoid assuming a security-key experience is identical to a synced platform passkey.Native app authentication and local unlock
Local biometric unlock and passkey authentication serve different steps. Local unlock can protect access to an existing app session. Connect authenticates against a server so your backend can create a session, for example after reinstallation or when reauthentication is required. Your application still owns device registration, session revocation and any activation policy. A passkey login does not automatically transfer or remove an existing device registration. Design those transitions explicitly. The native integration guide covers the SDK flow. The native passkey UX guides explain platform-specific journey choices.Engineering handoff
Record these decisions before starting:- Surfaces: Web domains, native apps, RP ID and development/production setup.
- Identity: Account mapping, authenticated token issuance and session creation.
- Journeys: Enrollment points, login patterns, account switching, fallback and recovery.
- Controls: User-verification policy, supported authenticators and initial rollout audience.
- Operations: Success measures, support procedures, rollout pause criteria and console access.