---
url: 'https://www.corbado.com/blog/android-restore-credentials-zero-tap-sign-in'
title: 'Zero-Tap Sign-In: Android''s April 2027 Deadline'
description: 'Google Play requires zero-tap sign-in restore from April 2027. What Google shared at Authenticate 2026 and how to implement Restore Credentials.'
lang: 'en'
author: 'Vincent Delitz'
date: '2026-10-29T13:48:18.371Z'
lastModified: '2026-10-31T07:00:09.632Z'
keywords: 'zero-tap sign-in, Google Play April 2027 requirement, Google Play sign-in restore, Android Restore Credentials, Authenticate 2026'
category: 'WebAuthn Know-How'
---

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

## Key Facts

- Google Play requires apps with optional or mandatory sign-in to **restore the signed-in
  state on a new Android device from April 2027**.
- The **Restore Credentials API** creates a restore key, which Google's Jean-Pierre Pralle
  described at Authenticate 2026 as an **"invisible passkey"** that users cannot manage.
- Restore Credentials **supports only one account per app**, so apps with several
  signed-in accounts must pick one, typically the primary or most recently used account.
- Google Play **measures compliance by successful restore key retrieval**, according to
  the Play Console Help Center.
- The API needs **Android 9 (API 28), Google Play services 24220000 and
  androidx.credentials 1.5.0** or higher, per the Android developer documentation.
- **Games are currently out of scope**, and existing Block Store integrations count only
  if they were **in production by 30 September 2026**.
- Apple offers **no equivalent API and no App Store mandate**. iOS apps rely on iCloud
  Keychain sync of their own keychain items or on synced passkeys.

## 1. Introduction

From April 2027, Google Play will require every
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/blog/how-to-enable-passkeys-android) Restore Credentials API is the primary way
to comply. Compliance is measured by successful restore key retrieval.

The
[Play Console Help Center](https://support.google.com/googleplay/android-developer/answer/17492799)
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](https://www.corbado.com/passkeys-for-banking) or
  [healthcare](https://www.corbado.com/passkeys-for-healthcare), may request one in Play Console before
  enforcement.

The
[Android Developers Blog](https://android-developers.googleblog.com/2026/08/app-quality-memory-optimization-secure-onboarding.html)
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](https://www.corbado.com/blog/passkey-account-recovery-authenticate-2026).

## 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.

![Android restore key flow from the old device via end-to-end encrypted cloud backup or device-to-device transfer to the new device and server verification](https://www.corbado.com/website-assets/android_restore_key_flow_new_device_ac20bf34ef.png)

_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](https://www.corbado.com/blog/android-16-passkeys) and the
[official documentation](https://developer.android.com/identity/sign-in/restore-credentials)
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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/world-passkey-day-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](https://www.corbado.com/blog/world-passkey-day-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](https://www.corbado.com/blog/webauthn-errors) 1.5.0 or higher, Android
9 (API 28) or higher and Google Play services 24220000 or higher, per the
[implementation guide](https://developer.android.com/identity/sign-in/restore-credentials-implementation).

**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](https://www.corbado.com/blog/conditional-create-passkeys) 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](https://www.corbado.com/blog/webauthn-signal-api) article for details.
- **Verified email replaces the email OTP:** The
  [Digital Credentials API](https://www.corbado.com/blog/digital-credentials-api) returns a verified Gmail
  address in good standing. Paired with
  [passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices), 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.

![Android Digital Credentials flow that verifies the email at sign-up without magic links or OTPs](https://www.corbado.com/website-assets/authenticate_2026_android_digital_credentials_email_verification_968ff0efab.jpg)

_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](https://www.corbado.com/blog/webauthn-errors) apps can keep users signed in
on a new iPhone in two ways: by syncing their own keychain items through
[iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) or by relying on passkeys, which sync through
[iCloud Keychain](https://www.corbado.com/glossary/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](https://developer.apple.com/documentation/security/ksecattrsynchronizable),
an app must set this attribute to sync an item to the user's other devices through iCloud.
Since [iOS](https://www.corbado.com/blog/webauthn-errors) 14, [iCloud Keychain](https://www.corbado.com/glossary/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](https://developer.apple.com/documentation/security/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](https://www.corbado.com/faq/is-face-id-passkey). The user still starts that sign-in, which makes it a
[one-tap](https://docs.corbado.com/corbado-connect/features/one-tap-login) flow instead of
a zero-tap restore. Our article on
[Apple passkeys on iOS and macOS](https://www.corbado.com/blog/apple-passkeys-ios-macos) explains the sync model.

For cross-platform apps, this means two different restore paths. On Android, Restore
Credentials becomes mandatory. On [iOS](https://www.corbado.com/blog/webauthn-errors), 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](https://www.corbado.com/observe) is the
[authentication observability](https://www.corbado.com/blog/authentication-observability) layer that makes this
visible from the login you already run. [Login Methods](https://www.corbado.com/observe/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.

[Video: Device health](https://www.corbado.com/videos/features/device-health.mp4) ([See how Corbado Connect ships this](https://www.corbado.com/connect))

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](https://www.corbado.com/observe/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](https://www.corbado.com/observe/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](https://www.corbado.com/connect) adds passkeys on top of
the identity stack you already run, with the native
[corbado-android](https://github.com/corbado/corbado-android) SDK for Android apps.
[Rollout Rules](https://www.corbado.com/faq/gradual-rollout-support-passkey-adoption) gate
[passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) 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.

## 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.