Device-Change Login Restoration Is Becoming an Operational Market

A new phone should open directly into a signed-in app

On August 26, 2026, Google announced requirements for automatically restoring a user’s sign-in state after they replace a phone. It said that, from April 2027, apps that do not meet these requirements could see effects on publishing capabilities and store visibility in Google Play, Google’s Android app marketplace.

The scope includes not only apps where sign-in is required, but also apps where users can optionally create an account. If a user has transferred apps and data from an old Android phone by cable or cloud backup, opening the app for the first time on the new device should sign them in without asking again for an ID or password.

Google calls this “zero-tap sign-in”: sign-in that continues without the user pressing anything. It is different from adding a “Sign in with Google” button to an existing screen. The feature securely recognizes an account verified on the previous device on the new one.

The standard approach is Google’s Restore Credentials feature. The old device creates a restore key that proves which account was signed in, and the app on the new device sends that key to the account system behind the app to receive a new signed-in state. It is supported on Android 9 and later, and requires changes to both the app interface and the account system.

Currently, only one account per app can be restored. Cloud restoration also requires conditions such as being signed in to a Google Account, Android backup, and a screen lock, so existing sign-in methods must remain available when restoration fails. Games are currently excluded, while apps with separate security standards, such as financial and healthcare apps, should check whether they can apply for an exception.

The person approving sign-in spending is changing

Consider an assumption. Jiyeon Park runs a meal-subscription app with 12 employees and outsources Android development. Members can join through email, a social account, or an SMS verification code, and their payment history and meal records are tied to their accounts.

Today, when a customer changes phones and opens the app, they first see a sign-in screen. A customer who cannot remember how they originally joined may try email sign-in, press a social sign-in option again, and create a new account if the verification code arrives late.

When a customer inquiry arrives, an operations employee moves between the inbox, member-management screen, and payment history. They repeatedly copy names and phone numbers to find the original account, then ask the customer which account should retain the new account’s meal records and payments. Merging accounts incorrectly can mix one person’s information with another’s, so a person must make the final decision.

Previously, this problem was treated as a development defect or a customer-support cost. Once the new requirements take effect, it will also affect whether updates can be published on time, whether users on new devices reach the first screen, and whether the app faces disadvantages in store visibility. The person holding the new budget is therefore not the developer, but Park or the app operator responsible for release timing and revenue.

What Park will first buy is not difficult security technology itself, but an assessment showing the current flow. She needs to check at once whether login and sign-up prepare the account for restoration, whether restoration information is also deleted at logout and account deletion, which account should move when there are multiple accounts, and which screen a user reaches after automatic restoration fails.

After the feature is added, success must also be measured with numbers. Useful measures include the share of users who completed restoration preparation on the old device, the share automatically signed in on the new device, the share sent back to manual sign-in, the first-screen reach rate, and the number of duplicate-account inquiries. Park will use these measures, rather than a development-completion report, to judge whether release delays and customer churn have fallen.

Some work still cannot leave human hands. Sensitive actions such as changing a payment method or viewing personal information can require additional verification, and customers whose automatic restoration fails need existing sign-in and account-recovery options. Decisions to merge orders and records across multiple accounts should also not be automated; they should go through an operations employee or the customer.

Elsewhere, device migration is treated as a product

Uber measured first launch as part of the revenue flow

Uber, a US company, introduced Restore Credentials in its global rider app using its existing account-verification system. When the app first opens on a new device, it checks the restore key and, if successful, skips passwords, SMS verification codes, and social sign-in. Riders do not pay a separate fee for the feature; they continue to pay for rides as before.

Uber said that design through testing took two months, followed by a five-week two-group comparison test. According to the company, about 10,000 people signed in this way each day; manual sign-ins fell by 3.4%, SMS verification costs fell by 1.2%, first-screen reach increased by 0.575%, and the share of devices completing a trip increased by 0.614%. Its estimate that it could reduce manual sign-ins by about 4 million a year is Uber’s own measurement and should not be applied directly to other apps.

Norway’s BankID made device change into a service

BankID, Norway’s shared electronic identity service, helps bank customers verify who they are when using government and private services. Consumers use BankID itself for free, while businesses pay through sellers based on their use of authentication and electronic signatures.

As BankID moved from a SIM-card-dependent approach to an app, it guided users and banks through the transition for about two years and ended the old method on September 1, 2024. On a new phone, users transfer access through identity-document and facial verification or with their existing device; once the new device is activated, the old app is deactivated. Before the shutdown, its official announcement said the app had more than 3.3 million users. This is an example of treating device change as an independent product flow rather than a customer-support issue.

Four things you can build now

1. A pre-release device-change diagnostic report

This is a service that directly tests login, sign-up, logout, account deletion, and device-change flows, then shows missing steps. It is for operators of booking, shopping, and subscription apps with fewer than 20 employees that outsource their app development.

They need an assessment now because they must determine development scope and costs before April 2027. The first screen should show three groups: “ready,” “needs changes,” and “items requiring a human decision,” alongside the actual screens where issues were found.

2. An automatic sign-in success dashboard

This service shows where users drop off, from restoration preparation through reaching the first screen on a new device. It is for operators of recurring-delivery apps and membership-content apps where repeat purchases by signed-in customers matter.

It is needed because a report that says the feature was installed does not show whether store requirements are met or customer churn has fallen. The first screen should place restoration-preparation rate, automatic sign-in success rate, manual-sign-in fallback rate, and app versions with the most failures side by side.

3. A duplicate-account merge work queue

This service helps operations employees safely identify and merge a newly created account with an existing payment account after a phone change. It is for local academy, fitness-facility, and food-subscription apps that store points, passes, and order records in accounts.

Because automatic restoration handles only one account, duplicate-account work remains for apps that use multiple sign-in methods. The first screen should show payment, points, and recent-usage records for the two candidate accounts, along with a “waiting for customer confirmation” button.

4. A before-you-change-phones guidance screen

This service lets customers check their primary account and backup-preparation status on their old device, and organize the sign-in method to use if restoration fails. It is for hospital-booking, local-membership, and education apps where email, Kakao, and Google sign-ins are mixed.

Automatic restoration alone is not enough for customers who do not meet cloud-backup conditions or use multiple accounts. The first screen should show the current signed-in account, the primary account to transfer, how to confirm backup status, and an alternative process if the old device is lost.

What to check today

Search the past three months of customer inquiries for “phone change,” “can’t sign in,” “old account,” and “paid but missing,” then read just 20 cases. If the same device-change issue appears three or more times, or if there is even one case where payments or records were moved because of a duplicate account, that is evidence to test an automatic-sign-in diagnostic or account-merging service.

Why this matters where you are

Check whether the app stores and device platforms relevant to your market set requirements or incentives around account restoration after device changes. The technical conditions, identity checks, and account-recovery expectations may differ by platform and market. You can begin by reviewing real support cases, then test whether customers can reach their account, payments, and records on a replacement device without creating duplicates.