Zero-Tap Sign-In: Android's April 2027 Deadline

1. Introduction#

From April 2027, Google Play will require every Android app with sign-in to restore that sign-in automatically when a user moves to a new device. Jean-Pierre Pralle (Product Manager, Android Credential Manager, Google) called zero-tap sign-in restoration the topic most on his mind at Authenticate 2026. Apps, data and permissions already move to a new phone, but the sign-in does not. The fix is the Restore Credentials API and its restore key, which reuses existing passkey server code. Apps that miss the deadline risk losing full publishing capabilities and visibility in the Play Store. This article covers the requirement, the open questions from the conference, an implementation guide and what Apple offers in comparison.

2. What does the Google Play Zero-Tap Sign-in Requirement demand?#

The Google Play requirement demands that apps supporting optional or mandatory sign-in restore the user's signed-in state after a device-to-device transfer or cloud backup restore. Google announced it in August 2026 and enforcement starts in April 2027. The Android Restore Credentials API is the primary way to comply. Compliance is measured by successful restore key retrieval.

The Play Console Help Center defines which apps the requirement applies to, which are excluded and which exceptions exist:

Apps in scope:

• Mobile and tablet apps with sign-in must comply: The rule covers apps with optional or mandatory sign-in on phones and tablets. Other form factors are not covered.
• Signed-out users must stay signed out: Users who were signed out or in guest mode on the old device should arrive in the same state on the new device.

Apps out of scope:

• Apps without accounts are not affected: If an app has no sign-in, there is nothing to restore.
• Games are excluded for now: Google expects dedicated guidance for games in 2027.

Exceptions:

• Block Store counts only if live by 30 September 2026: Existing Block Store integrations are accepted only if they were in production by that date and restore sign-in successfully.
• Regulated apps can request an exemption: Apps under strict regulatory mandates, such as financial services or healthcare, may request one in Play Console before enforcement.

The Android Developers Blog from 26 August 2026 states the consequence: apps that do not comply may lose full publishing capabilities or optimal visibility in the Play Store.

3. Why is Google pushing Zero-Tap Sign-in Restoration?#

Google is pushing zero-tap restore because sign-in is the one thing that does not survive a device switch today. Jean-Pierre Pralle said at Authenticate 2026 that apps, data, notifications and permissions all transfer to a new Android phone, but users must sign in again in every app. Many users do not bother, and apps lose them.

Pralle named two benefits for app teams:

• Signed-in apps can re-engage users at once: An app that is signed in on the new device can immediately remind the user of a running streak or an abandoned shopping cart.
• Users no longer need to remember their method: Users do not remember whether they used a passkey, federation or a password for each app. With one restore mechanism, they do not need to.

The requirement also connects to account recovery. Claire Forszt and Bill Chen from Google described the "device transition problem" in a separate Authenticate 2026 session: passkeys increase reliance on the device and many users own only one. Restore Credentials covers the planned switch to a new phone. It does not cover a user who lost their only device without a backup, which is the topic of our article on passkey account recovery.

4. How does a Restore Key work?#

A restore key is a credential that the app creates silently after sign-in and that moves to the new device with the app data. Jean-Pierre Pralle described it at Authenticate 2026 as an "invisible passkey": it behaves like a passkey on the server, but it is system-managed and hidden from the passkey management page. On the new device, the app retrieves it and signs the user in before first interaction.

Source: Corbado, based on Android developer documentation

The restore key goes through four stages:

1. The app creates the key after sign-in: It calls CreateRestoreCredentialRequest. The server receives a public key that is similar to a passkey public key, so the same server code handles it.
2. Android backup moves the key with the app data: With cloud backup, the key is downloaded with the app data to the new device. With device-to-device transfer, it moves from the old to the new device through the USB cable.
3. The app retrieves the key on the new device: It calls GetRestoreCredentialOption on first launch, before the user interacts with the app.
4. The server verifies the assertion like a passkey sign-in: The user is signed in without a password, OTP or passkey prompt.

Cloud backup requires that the user is signed in to a Google Account, has Android data backup enabled and has a screen lock. Otherwise, creation throws an E2eeUnavailableException. We cover the mechanism in more detail in our Android 16 passkeys article and the official documentation describes all requirements.

5. What did Google answer about Security and Limits at Authenticate 2026?#

Google's Jean-Pierre Pralle addressed five practical limits in the Authenticate 2026 Q&A: one account per app, an opaque transfer mode, unchanged risk engines, the abuse question and deletion on sign-out. Google considers zero-tap restore about as safe as a passkey, but recommends step-up where an app needs it.

1. Apps can restore only one account: The API stores one restore key, so apps choose one account, typically the last used or primary one. Google is exploring more storage.
2. The transfer mode is invisible to the app: A bank in the audience asked for a trust signal showing how the credential was transferred. Pralle said the relying party cannot see whether the user chose device-to-device or cloud restore. Google views device-to-device transfer as strong proof of possession. Relying parties decide what step-up to add.
3. Existing risk engines stay in place: Restore Credentials does not change new-device logic, scopes or fraud checks. Apps keep their existing workflows.
4. Abuse protection works like for passkeys: Asked how to stop bad actors, Pralle said the backend is "pretty much the same" as a passkey and asked for concrete attack vectors.
5. Sign-out must delete the key: Apps must delete the key on sign-out, for example on shared devices. Uninstalling the app or clearing its data deletes keys automatically.

Corbado's Passkey Benchmark 2026 shows why the new-device moment matters: passkey logins on a recognized device succeed 95% to 99% of the time, while identifier-first logins on an unrecognized Android browser succeed 70% to 85% of the time (Passkey Benchmark 2026).

6. How do you implement Restore Credentials before April 2027?#

Implementing Restore Credentials takes four steps: create the key after sign-in, retrieve it on the new device, delete it on sign-out and verify it on the server with existing passkey code. The Android developer documentation lists exact APIs and minimum versions. Google also offers an AI coding skill and documentation to speed up the integration, Jean-Pierre Pralle said at Authenticate 2026.

Prerequisites: androidx.credentials 1.5.0 or higher, Android 9 (API 28) or higher and Google Play services 24220000 or higher, per the implementation guide.

Step 1: Create the restore key at sign-in. Call createCredential with CreateRestoreCredentialRequest at sign-in, registration and session start. Keep isCloudBackupEnabled at its default true. If E2eeUnavailableException occurs, retry with false so device-to-device transfer still works.

Step 2: Retrieve the key on the new device. Call getCredential with GetRestoreCredentialOption on first app launch. If app data backup is enabled, also call it in BackupAgent.onRestoreFinished(). The docs warn against onRestore, which only runs for key-value backups.

Step 3: Delete the key on sign-out. Call clearCredentialState with ClearCredentialStateRequest(TYPE_CLEAR_RESTORE_CREDENTIAL) on sign-out and on server-side session invalidation, such as an HTTP 401.

Step 4: Verify the key on the server. Reuse the FIDO passkey registration and authentication code. Store restore keys separately from passkeys in the database, because users manage passkeys themselves, while restore keys are system-managed and must not appear in passkey management pages.

Two notes apply on top of the four steps:

• Each package name needs its own key: Restore keys are tied to the package name, so a main app and sub-apps with different package names need separate keys.
• Push tokens are not restored: Apps using Firebase Cloud Messaging must fetch a new token and send it to the backend after restore.

7. Which other Android Identity Features shipped in 2026?#

Android shipped several Credential Manager features in 2026 that complement Restore Credentials. Together they reduce passwords and OTPs at sign-up, sign-in and device switch. Jean-Pierre Pralle presented them at Authenticate 2026:

• Conditional create upgrades password users silently: It creates a passkey after an autofilled password sign-in. It has been available for a while but is little known. Pralle advised always notifying the user, for example by email. Our guide to conditional create covers the implementation.
• The Signal API removes stale passkeys: It tells password managers when a passkey was invalidated, so they stop suggesting it. See our WebAuthn Signal API article for details.
• Verified email replaces the email OTP: The Digital Credentials API returns a verified Gmail address in good standing. Paired with passkey creation, sign-up takes two clicks. Pralle said it is rolled out to billions of Android users.
• Phone number verification is live: It is available on Android today. Verified email and phone in one call is planned.
• Credential Manager reaches TV and cars: It now runs on Google TV and Android Automotive OS, mainly through the hybrid flow. Support covers roughly ten years of Android versions and is not limited to Google devices.
• Hybrid sign-in needs fewer taps: The Android QR scanner starts the passkey flow without an extra tap, NFC tap is a new transport and the flow works with spotty connectivity.

Source: Jean-Pierre Pralle (Google), Authenticate 2026

8. Does Apple offer an Equivalent to Android Restore Credentials?#

Apple offers no dedicated restore key API and no App Store requirement comparable to Google Play's April 2027 rule. iOS apps can keep users signed in on a new iPhone in two ways: by syncing their own keychain items through iCloud Keychain or by relying on passkeys, which sync through iCloud Keychain by default. Both depend on the user's iCloud settings, and neither is enforced by Apple.

Keychain items sync only when the app opts in: By default, keychain items added by third-party apps do not sync. According to Apple's documentation for kSecAttrSynchronizable, an app must set this attribute to sync an item to the user's other devices through iCloud. Since iOS 14, iCloud Keychain syncs passwords, certificates and cryptographic keys. Updating or deleting a synchronizable item affects all copies on all devices.

Device-only items stay on the old phone: Apple's guide on restricting keychain item accessibility states that items whose accessibility value ends in ThisDeviceOnly can be restored to the same device that created a backup, but they are not migrated when another device's backup is restored. Such items also cannot be synchronizable.

Passkeys cover sign-in after the switch: A passkey saved in iCloud Keychain is available on the new iPhone, so the user can sign in with Face ID. The user still starts that sign-in, which makes it a one-tap flow instead of a zero-tap restore. Our article on Apple passkeys on iOS and macOS explains the sync model.

For cross-platform apps, this means two different restore paths. On Android, Restore Credentials becomes mandatory. On iOS, the team decides whether a synchronizable keychain token, a passkey or a fresh sign-in is acceptable for its risk model.

9. How Corbado can help#

The Play requirement makes the new-device moment a compliance metric. For most teams, it already is a conversion problem: users who switch phones either land signed in, sign in again with a passkey or fall back to a password and an OTP. Which of these happens depends on the Android version, the OEM and the Play services build on each device, and that mix differs from app to app.

Corbado Observe is the authentication observability layer that makes this visible from the login you already run. Login Methods puts passkey, password and social side by side on share of logins, completion, error rate and duration, so a fallback to passwords after a device switch shows up as a share of traffic. Subflow Explorer counts the OTP paths that a missed restore pushes users into, with completion rate, error rate and duration percentiles for each.

See how Corbado Connect ships this →

Android fragmentation is the second view. Observe splits every login and enrollment by OS, OS version and browser, and Device Health classifies ceremony outcomes per device brand and model. A single OEM model that fails the credential prompt therefore separates itself from Android in general. Passkey Errors attributes the failures behind a weak cohort to a WebAuthn reason, carrying the raw error name, message and code the client returned. User debugging replays a single journey with its device context, which helps support teams when a user reports being signed out after a phone switch.

Restore keys reuse the passkey server logic, so the open question for most teams is whether their passkey layer is ready. Corbado Connect adds passkeys on top of the identity stack you already run, with the native corbado-android SDK for Android apps. Rollout Rules gate passkey creation and login per client, so a build that only behaves from a certain Android version upwards can take the passkey path at a share you are comfortable with, while older builds keep the flow they have.

10. Conclusion#

Google Play's zero-tap sign-in requirement turns Android Restore Credentials from an optional feature into a compliance task with an April 2027 deadline. Jean-Pierre Pralle of Google framed it at Authenticate 2026 as the missing piece of device migration: apps and data move, sign-in now moves too. The restore key reuses passkey infrastructure, supports one account per app and is checked by successful retrieval.

Teams with passkeys in place face a small integration. Teams without them should start with the server side now. Two details are easy to miss: an app that does not delete the key on sign-out signs users back in after they signed out, and regulated apps that need an exemption must request it in Play Console before enforcement. Because the transfer mode stays invisible, risk engines and step-up rules remain relevant. On iOS, there is no mandate, so cross-platform teams have to define their own restore behavior with iCloud Keychain and passkeys.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (more than 80% passkey activation rate). Talk to a Passkey Expert →

Frequently Asked Questions#

What is Android Restore Credentials?#

Android Restore Credentials is a Credential Manager API that signs users back into an app automatically on a new Android device. The app creates a restore key after sign-in. The key moves with the app data via cloud backup or device-to-device transfer, and the app uses it to sign in silently on the new device. Google described it at Authenticate 2026 as an "invisible passkey".

When does the Google Play zero-tap sign-in requirement start?#

Google Play enforces the zero-tap sign-in restoration requirement from April 2027. It applies to mobile and tablet apps with optional or mandatory sign-in. Games are currently out of scope. Block Store integrations count as compliant only if they were in production by 30 September 2026. Apps under strict regulatory mandates can request an exemption in Play Console before enforcement.

Is a restore key the same as a passkey?#

A restore key is not a passkey, but it uses the same server-side implementation. According to the Android developer documentation, its public key is similar to a passkey public key, so the passkey registration and authentication code can handle it. Restore keys are system-managed and hidden from the passkey management page, so the documentation recommends distinguishing them from passkeys in the database. Restore Credentials supports one account per app.

Can banks see how a restore key was transferred?#

No, the transfer mode is opaque to the relying party. Google's Jean-Pierre Pralle confirmed at Authenticate 2026 that apps cannot tell whether the user restored from cloud backup or via device-to-device transfer. Google considers device-to-device transfer strong proof of possession. Banks and other regulated apps should keep their risk engines and add step-up authentication where their policies require it.

Does Restore Credentials help if a user loses their only phone?#

Only if the user had cloud backup enabled. Cloud backup of the restore key requires a Google Account sign-in, Android data backup and a screen lock. Without a backup, there is nothing to restore and the user goes through normal account recovery. Google discussed this "device transition problem" separately at Authenticate 2026 and presented verifiable digital credentials as a future recovery path.

Does iOS have an equivalent to Android Restore Credentials?#

No, Apple has no dedicated restore key API and no App Store mandate like Google Play's. iOS apps can sync their own keychain items through iCloud Keychain by setting kSecAttrSynchronizable, while items marked ThisDeviceOnly are not migrated to a new device. Passkeys saved in iCloud Keychain are available on the new iPhone, but the user still starts the sign-in.