Passkey Creation: In-App After Key Action

In-App Nudge After a Key Action

Use an in-app nudge after a named, completed action to offer passkey creation at a stable, low-disruption moment. Separating it from app unlock avoids immediately stacking prompts, although the selected action may itself have required verification. Use this nudge when users stay signed in for long periods and rarely see the login flow.

Choose a meaningful trigger: Prefer a completed reauthorization, security-related task or transaction whose result is already visible. Do not treat arbitrary CTA clicks, page views, passive banners or unresolved transactions as equivalent key-action triggers.

iOS
Android

App unlock via local biometric

User unlocks the app using local biometrics (e.g., Touch ID, Face ID).
User is authenticated within the app session.

User interacts with app (CTAs, actions)

User completes one of the documented actions configured as a qualifying trigger.

In-App Nudge appears after the selected action

After the named action completes successfully, the app may show the nudge.
Readiness and nudge frequency follow the shared targeting policy.

User engages with nudge

User sees concise messaging about passkey benefits (faster, more secure logins).
User can accept to create passkey or skip to continue using the app.

Passkey creation (if accepted)

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

Continue to app dashboard

User proceeds to app dashboard with or without creating a passkey.
If skipped, the nudge may appear again after another eligible action, subject to the configured cooldown and frequency policy.

Keep the nudge short, avoid blocking flows, and offer a clear skip so users remain in control.

Acceptance criteria

Benchmark as	User reach
Strategy	Mid

The expected impact depends on the trigger. A completed reauthorization or security-related transaction shows clear user intent. A passive dashboard banner does not provide the same context and should not be benchmarked as equivalent.

ID	Level	Acceptance criterion	How to verify
N2.5-AC01	Core	Show this nudge only after a named user action, such as reauthorization or a security-related task, completes successfully. An arbitrary button click, page view or permanent banner is not the same trigger.	Exercise every configured trigger plus nearby failed, cancelled and unrelated actions. Only the named, successfully completed actions show the nudge.
N2.5-AC02	Core	The nudge explains how creating a passkey improves a future sign-in.	Review every message variant. Each explains the future sign-in benefit before the user accepts.
N2.5-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.
N2.5-AC04	Core	Provide accept and skip controls and start the platform registration ceremony only after the user chooses accept.	Exercise accept, skip, dismiss and back actions. Accept starts one ceremony; every other action leaves the completed task usable without opening a system credential sheet.

References

Relevant criteria: N2.5-AC01–AC02 and N2.5-AC04: Native apps: Passkeys vs. local biometrics distinguishes high-intent post-transaction prompting from post-unlock and passive-banner strategies.
Relevant criteria: N2.5-AC01 and N2.5-AC04: How to get high passkey adoption in creation flows covers trigger-aware creation and explicit post-action nudges.
Relevant criteria: N2.5-AC02 and N2.5-AC04: Passkeys user journeys identifies completed reauthorization and account-related moments as appropriate creation opportunities.
Relevant criteria: N2.5-AC03–AC04: Create a passkey on Android defines user-mediated creation and account-bound request data.
Relevant criterion: N2.5-AC03: Web Authentication: An API for accessing Public Key Credentials: Level 3 defines account and relying-party binding.

​In-App Nudge After a Key Action

​Acceptance criteria

​References

In-App Nudge After a Key Action

Acceptance criteria

References