1. If reviewers cannot reach a login-gated, invite-only, paid, or otherwise restricted core feature, Google treats that as an App access failure. Play Console Help requires App access instructions that tell reviewers how to open restricted functionality; when they cannot, you typically see "We couldn't review your app because of login issues," and the same gap can also be scored as Minimum Functionality because the declared core flows never ran.
2. Enter credentials in Play Console under Policy → App content → App access. If any feature needs a sign-in, code, invite, or special role, choose the option that some or all functionality is restricted and add an instruction set before you send the release. Do not leave App access on "all functionality is available without special access" when a login screen is the first thing reviewers hit.
3. In the instructions, write a complete stranger-proof path: username and password (or a reviewer one-time code), how to handle 2FA, the exact in-app or deep-link route to the gated screen, and any test-environment, tenant, or region notes. Example shape: "Sign in with the account below → Home → Wallet → Transfer. Use the staging tenant listed here. Do not enable 2FA on this user."
4. When login is required, provision a dedicated demo or test account that already holds the data and entitlements needed to exercise every declared core feature. An empty, expired, or "new user with no content" account often fails even when the password is correct, because reviewers still cannot reach the product you submitted.
5. Strip or bypass factors reviewers cannot complete from their devices: SMS OTP, email magic links that land in your inbox, hardware keys, device-bound authenticator apps, and aggressive captchas. If a second factor cannot be removed, put a current, working code or a documented bypass in the same App access instructions and keep it fresh. A login that waits on an SMS to your phone is treated as a login-issues rejection.
6. Keep every listed credential valid for the whole review window — several days at minimum, longer if you use Managed Publishing or expect a resubmit. Do not rotate the password mid-review, lock the account after a few logins, or geo-fence the demo user to a country reviewers cannot match. If you must change the password, update App access in the same console session before you resubmit.
7. Offer a non-login path when the product allows it: guest mode, "Continue without account," or a reviewer build that unlocks core features without credentials — and declare that path in App access so reviewers are not forced through a sign-in you did not intend as the only door. Restricted Content (age gates, paid catalogs, region-locked media) still needs a working route; guest mode does not replace a content rating or a lawful age check.
8. If you already received "We couldn't review your app because of login issues," fix App access first, then resubmit: confirm the username/password on a clean device, paste the exact navigation steps, disable 2FA on the demo user, and verify the account can reach every declared core feature. A resubmit that leaves the App access form unchanged usually repeats the same rejection.