Passkeys and AuthenticationServices App Review checklist
Passkeys can make login safer, but a passkey-only app can lock out reviewers and users if registration, recovery, and fallback states are not planned.
Use passkeys with a complete account lifecycle: registration, sign-in, device change, lost credential, recovery, and account deletion. Apple says passkeys use iCloud Keychain public-key credentials and AuthenticationServices supports passkeys and security keys. AppReviewReady interpretation: passkey readiness is an account recovery contract, not only a login UI.
Map the passkey account lifecycle
Document how a user creates an account, adds a passkey, signs in on another device, loses access, removes a passkey, and deletes the account. If any step depends on email, phone, support, or Sign in with Apple, name that dependency.
Reviewers need a deterministic login path. A passkey created only on the developer's device will not help App Review verify the submitted build.
Provide a recovery path without weakening trust
- Offer a review account or test passkey flow that can be completed by App Review.
- Handle no iCloud Keychain, passkey unavailable, canceled biometric prompt, and security key fallback states.
- Do not force a user into a dead end after deleting a device credential.
- Account deletion should revoke sessions and explain what happens to passkeys.
- Support should distinguish identity recovery from billing or App Store account recovery.
Keep authentication copy accurate
Passkeys can eliminate passwords, but the app may still collect email, phone, profile, device, risk, or account-recovery data. Privacy labels and onboarding copy should not imply the app collects no account data unless that is true.
AppReviewReady interpretation: avoid marketing passkeys as an approval guarantee. The app still needs reviewer access, account lifecycle handling, and support routes.
Test passkey state transitions
- Register with a new passkey and sign out.
- Sign in on a second device or browser where supported.
- Cancel biometric auth, remove the passkey, and attempt recovery.
- Test security key fallback if supported.
- Delete the account and verify passkey and session cleanup messaging.
Give Review Notes a login route
Do not require the reviewer to reuse a passkey from your device. The route should work from a fresh review environment with the credentials you provide.
If passkeys coexist with Sign in with Apple, enterprise SSO, or password login, test account linking and duplicate-account prevention. The same person should not accidentally create separate paid or private data profiles.
For paid products, verify passkey recovery does not strand the user's subscription entitlement. Billing identity and app-account recovery should have a clear support path.
Test passkey rename or deletion on another device before review.
If the app requires high-risk actions, require fresh authentication before account changes.
Support should know how to verify ownership without asking for passkey secrets.
Passkey review route: Account state: [new or seeded] Registration path: [steps] Sign-in path: [steps] Fallback path: [email, review account] Recovery behavior: [summary] Account deletion: [where] Security key support: [if any]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check passkey readiness
Review passkey login, fallback, recovery, and reviewer access before submission.
Open the tool