Passkey Creation: In-App After Unlock

In-App Nudge: After Unlock (Post-Authentication)

This in-app prompt appears after users unlock the app and offers passkey creation for future authentication. The timing makes the prompt easy to notice, but it can cause consecutive device-verification interactions.

Local app unlock protects an existing session. Creating a passkey adds a credential for a future remote sign-in.

iOS
Android

App unlock using local protection

User unlocks the app using a local biometric or an app/device PIN.
User is now authenticated within the app session.

In-App Nudge appears immediately after unlock

After successful unlock and once the authenticated screen is stable, the app can show a dismissible creation nudge.
Readiness and nudge frequency follow the shared targeting policy.
This timing can place the system passkey-creation sheet immediately after local unlock. Some implementations use the After CTA timing to separate the two interactions.

User chooses to create passkey

If the user accepts, the system passkey-creation sheet appears.
The user authorizes creation with a platform-supported device-unlock method.

Passkey creation successful

User successfully creates a passkey and it is now linked with the user account for the respective native app.
The new passkey can be used for a future sign-in.

Acceptance criteria

Benchmark as	User reach
Strategy	Mid

This strategy reaches users who stay signed in and therefore rarely complete a full login. It can, however, add a second device-verification interaction directly after local app unlock.

ID	Level	Acceptance criterion	How to verify
N2.4-AC01	Core	Evaluate the flow only after local app unlock has completed and the authenticated session is stable.	Exercise successful, cancelled and failed unlocks plus rapid background and foreground transitions. The nudge becomes eligible only after successful unlock in a stable foreground state.
N2.4-AC02	Core	Start the platform registration ceremony only after the user accepts a dismissible in-app nudge.	Exercise accept, dismiss and back actions. Acceptance starts one ceremony; every dismissal path leaves the unlocked app usable without opening a system credential sheet.
N2.4-AC03	Core	Bind registration to the account authenticated when the ceremony starts and reject the response if that account changes before completion. After successful verification, store the credential for that account and confirm that it can complete a later sign-in.	Start creation, then switch accounts, sign out or supersede the session before returning the response. No changed or stale account context registers a credential. Complete a valid creation, sign out and confirm that the new passkey signs in to the same account.

References

Relevant criterion: N2.4-AC01: Native apps: Passkeys vs. local biometrics distinguishes local app unlock from remote authentication and covers post-unlock prompting.
Relevant criterion: N2.4-AC02: Passkeys user journeys supports an explicit, dismissible user decision before passkey creation.
Relevant criterion: N2.4-AC03: Web Authentication: An API for accessing Public Key Credentials: Level 3 defines account and relying-party binding.

​In-App Nudge: After Unlock (Post-Authentication)

​Acceptance criteria

​References

In-App Nudge: After Unlock (Post-Authentication)

Acceptance criteria

References