Google Play App Access in 2026: 8 Questions About Sign-in Details and Review Credentials

If any part of a Google Play app sits behind a login, a membership, a region lock or a location gate, reviewers cannot see it — and the Google Play app access declaration, which Play Console now labels Sign-in details, is the one place where you hand them a way in. It lives on the App content page next to your ads declaration, privacy policy, target audience and content ratings, and it is the first thing to check when a release comes back as "we could not review your app".

This article answers the eight questions developers actually ask about sign-in details: when the declaration applies, where the fields live, what belongs in the free-text box, how to handle a one-time password or multi-factor authentication, what reviewers do with the credentials you supply, and how to resubmit after a rejection without sitting in a support queue. Everything below follows Google's own Play Console Help documentation; where a limit exists, we quote it.

One clarification first. Sign-in details are about reviewer access, and they are not the same thing as identity verification (KYC), the AdSense or AdMob address PIN, or tax information (W-8BEN / W-9). Those are separate declarations with separate evidence. What follows is only about letting the app review team reach the parts of your app that a normal user cannot reach without credentials.

Q1. What is the Sign-in details declaration, and when does it apply?

The rule is wider than "my app has a login screen". Google's wording on the App content page: if your entire app or parts of your app are restricted based on login credentials, sign-in details, memberships, location, or other forms of authentication, you must provide all required details to enable access to your app.

That covers a conventional email-and-password login, but it also covers a subscription-only area, a members-only section, a feature gated behind a code you issue to customers, and gated content that only appears for users in a particular country or on a particular device. If a reviewer's session would hit a wall you never described, the declaration is incomplete — and the release can come back unreviewed for that reason alone.

Q2. Where do I fill it in, and how do I change it later?

The declaration lives on the App content page in Play Console, reached from Policy and programs → App content (some console views show the path as Monitor and improve → Policy and programs → App content). That page has two tabs:

• Needs attention — declarations that require your input, which must be completed before the relevant deadlines to stay compliant.
• Actioned — declarations you have already actioned. Google's own guidance is that you should review them regularly and keep them up to date, which is exactly where credential drift gets caught before a rejection does.

Under Sign-in details, select Start. If you have declared it before, the button reads Manage instead. Then click + Add new instructions and provide your access details. You can add up to five sets of instructions — that is how you describe more than one route in, for example a free-tier account and a separate paid-tier account.

Q3. What belongs in a set of instructions — and what is "Any other instructions" for?

Each set is a small credential record: a name for it, the username, the password, and any other instructions. The field people under-use is Any other instructions. Google names it as the place to explain anything special about your login mechanism — a one-time password, multi-factor authentication, or a login form with more than two fields.

Write it as if handing over to a colleague who has never opened the console: which user role the account holds, whether the app asks for a permission grant on first launch, whether an onboarding screen has to be dismissed, whether a region selector has to be changed before the paid content appears. A set of instructions that is technically correct but leaves those surprises unmentioned still produces a "could not access" rejection.

Q4. My restriction is a membership, a region or a device — is that covered?

Yes. The declaration is written around "login credentials, sign-in details, memberships, location, or other forms of authentication", so a paid membership tier, a location-restricted catalogue, and a build that only unlocks for approved hardware all belong here. Two practical consequences:

• If access depends on something a reviewer cannot reproduce — your city, your network, a physical token — describe how to make the app behave as if that condition were satisfied, using a review account or a documented test path. Where the gate is a device-level check rather than an account check, say so in Any other instructions and supply the account that reaches the content behind it.
• If a feature is genuinely unavailable to everyone, state that plainly. A clear statement is better than implying the feature is reachable when it is not.

Q5. My app uses a one-time password or MFA. What do I write?

This is the single most common reason a sign-in rejection repeats. Google's instruction is to use the Any other instructions field whenever your login uses a one-time password, multi-factor authentication, or more than two fields.

Then make the second factor survivable for the reviewer. In practice that means one of two patterns: a review account whose second factor is a value you can state and keep stable for the whole review window, or a review account for which the extra challenge is not triggered at all. What does not work is a challenge that lands on a phone only you can read, or a code that rotates every thirty seconds with nobody to read the next one. And the account itself must belong to the app and the developer account you are representing — never hand over a third party's credentials, or an identity that is not the one behind the account, because that is precisely the misrepresentation Play policies penalise.

Q6. What do reviewers do with the credentials, and what makes them stop working?

Reviewers sign in with what you supplied and exercise the features they can reach, so the declaration has to stay true for the entire review window. The failures are almost always ordinary lifecycle events:

• Password rotation. A security reset on the review account invalidates what you wrote; update the declaration in the same sitting.
• Expiring trial or subscription. A review account on a seven-day trial that lapses mid-review is a dead end.
• Device or region binding. An account locked to a device fingerprint, an IP range or a storefront cannot be used from wherever the reviewer signs in.
• Stale second factor. The code you wrote down has rotated, or it was sent to a number the reviewer does not control.
• Incomplete scope. The account exists but reaches only the free tier, while the release notes describe paid features.

The habit that prevents all five is a short pre-release check: sign in as the review account, walk the features named in the release notes, then confirm the declaration still matches what you just did.

Q7. My update was rejected or the app was removed. How do I resubmit?

Google documents a self-service path, and it does not require contacting or waiting for a reply from the policy support team:

1. Open Play Console and go to the Sign-in details page.
2. Update your sign-in details information and click Save.
3. Go to the Publishing overview page — the change appears in the Changes ready to send for review section.
4. Click Send for review to submit the change.

Notice what the sequence implies: the declaration is itself a change that goes through review, so correcting it in the console is only half the job — it has to be sent. If managed publishing is switched on for the app, the fix will sit in the ready-to-send state until you send it, and review windows are not instant.

Q8. How does this sit alongside the rest of the App content page?

Sign-in details is one declaration among many on the same page, and reviewers read them together. The neighbours worth checking in the same pass:

• Ads. You must declare whether the app contains ads, including ads delivered through third-party ad SDKs, native ads and banners. House ads and a simple cross-promotion "More Apps" menu are treated differently from monetised inventory, and misrepresenting ad presence is itself a policy violation that can lead to suspension.
• Privacy policy. Required on the store listing and inside the app once you touch sensitive permissions or data, and required regardless of data access for apps that target children.
• Target audience and content, which pulls the app into additional policies when children are in scope.
• Permissions declaration form for high-risk or sensitive permissions such as SMS or Call Log, which needs Play's approval before release.
• Content ratings — fill in the questionnaire for every app, because an Unrated app can be removed from Google Play.
• COVID-19 contact tracing or status functionality and News and Magazine status, both of which are declarations you must answer when they apply.

Keep the whole page current, not just the field that triggered the rejection. A launch is rarely stalled by one declaration; it is stalled by the one nobody re-read after the app changed.

Where KappS fits in

KappS helps developers keep accounts and releases in a state that stands up to platform scrutiny. On this topic that means preparing and submitting compliant material: writing review instructions that actually describe the login flow, keeping a review account alive and correctly scoped for every release, describing multi-factor access so that a reviewer can pass it on a legitimate account of your own, and auditing the rest of the App content page before a launch instead of after a rejection.

We do not provide anyone else's documents or identity, we do not sell accounts, and we do not promise outcomes. The declaration only works when what you write down matches what your app really does — which is also the only version of this that is safe to keep.

Sources (Google official documentation): Play Console Help — Prepare your app for review (App content: privacy policy, ads, sign-in details, target audience and content, permissions declaration form, content ratings); Control when app changes are reviewed and published; Google Play Ads policy; User Data policy.