Most Google Play developer accounts are not lost to policy enforcement. They are lost to operations: a password shared over chat, a phishing email answered at one in the morning, a change nobody read in the Activity log, a keystore that existed on exactly one laptop, or six months of silence that Google's inactivity rules read as abandonment. Google publishes a complete security playbook for Play Console accounts, and almost none of it gets read until the account is already gone.

What this article answers: whether 2-Step Verification is actually required, why sharing a login is the riskiest shortcut in this business, how the Activity log records every change and who made it, how to tell an official Google enforcement email from a phishing attempt, the correct sequence when an account looks compromised, why your developer account should not live on your personal Google Account, where to keep your keystore, and the exact inactivity criteria that close accounts without a single policy violation.

1. Is 2-Step Verification actually required for Play Console access?

Google's official guidance on protecting a developer account recommends turning on 2-Step Verification for all accounts with access to Play Console — not only the owner's. That wording matters in a business where team members, contractors or account managers sign in to the same console.

With 2-Step Verification enabled, a verification code retrieved from a mobile device or phone number is required whenever an account signs in from a new device. You can authorise multiple devices and configure backup options, which is precisely what you want to have done before a phone is lost, replaced or factory reset. Google also lists 2-Step Verification as the action to take immediately after a compromise, to stop it happening twice. The setup flow itself is documented in Google Account Help.

2. Can we just share the Play Console password across the team?

No, and this is the shortcut that costs people accounts. Google is explicit that a shared password hands over far more than Play Console: if the same Google Account is also used for Gmail or the payments center, whoever holds the password also holds your email and your financial information. That is a vendor, a freelancer or an ex-teammate with the keys to the business.

The supported alternative is to add users to the developer account. Added users sign in to Play Console with their own email address, which preserves individual accountability and lets you revoke one person without rotating the owner's credentials. Google's guidance on managing access is worth quoting as policy: review regularly who has access, treat admin-level access granted to unknown or untrusted accounts as a significant security risk, and make prompt removal of users who no longer need access a team rule rather than a good intention.

3. How do I find out whether someone changed something in my account?

Read the Activity log. It records changes made in Play Console by account users for the lifetime of the developer account — not a rolling window you can miss. By default all apps are shown and up to 200 changes are displayed, and the Application and Changed item filters (one of each at a time) let you search by app or package name or by change type.

Each entry carries five fields: the app, the page and section where the change happened, the change itself, the email address of the user who made it, and the local date and time. That combination is what turns "something changed" into "this address changed this, on this date". Pair it with the Google Dashboard and recent-activity view for the Google Account itself, and with the Play Console notifications bell — official enforcement actions and critical account alerts also appear there, which makes it the second place to check after any suspicious message.

4. I got an email saying my account will be suspended. Is it real?

Check the sender address, not the display name. Google Play only contacts developers from official addresses ending in @google.com. Anything else is phishing, however convincing the layout.

Google lists the standard traps: urgent or threatening language claiming the account is suspended, compromised or under investigation; requests for login details; and invitations to add unknown users or to open a chat or email thread for "emergency verification" or "compliance checks". Google will never ask for your password, never ask you to add unknown users to your developer account, and never run a compliance check over a chat thread.

Before clicking, hover the link and read the destination: if it is not the official play.google.com/console domain, do not click it. The safe path is to ignore the message and verify in the product — the Activity log and the notification bell carry the real enforcement actions, and Play Console has a report-as-phishing path for the message itself.

One honest caveat that phishing makes worse: by publishing on Play you agree to the Developer Distribution Agreement, and Google is not required to send a warning before suspending or terminating an account. The absence of an email proves nothing either. Verify account state inside Play Console, never from your inbox.

5. My account shows signs of a compromise. What is the correct sequence?

  1. Contact Play support with any information you have — the support team checks the account for signs of unauthorised activity.
  2. Change the Google Account password immediately if you entered your Google Account details on any site linked from the suspicious notification.
  3. Re-secure the account: 2-Step Verification on every account that can reach Play Console, plus a review of who currently has access.
  4. Recover access through Google Account Recovery if you are locked out, and use Gmail Help's compromised-account guidance for the account itself.
  5. Audit the damage: Activity log, app and release status, payments profile, and the keystore backup from question 7 — a hijack is usually discovered late, so assume more happened than you can see.

6. Should my developer account live on my personal Google Account?

Google recommends using a different account for the developer account than for personal use, on simple compartmentalisation logic: if one is compromised, the other stays secure. If you registered with your personal account years ago, there is an official path out — register a new developer account, then prepare and request the app transfer with the support team, and if you close the old account Google refunds the original $25 registration fee.

The same separation applies to the address your customers see. Google recommends a different email address for the store-listing contact details than the one used to register the developer account, so that a compromise of one does not take the other with it. Keep the registration inbox actively monitored for official messages, because that is the address Google uses to reach the account owner.

7. Where should I store my keystore — and does the Google Account matter?

Enrol in Google Play App Signing, or back up your keystore in a safe and secure place. The reason is not convenience: without the keystore you cannot update the app at all, because every version has to be signed with the same key. A lost key is the difference between shipping an update and re-listing an app.

Then copy one non-obvious detail straight out of Google's own advice: if you back the keystore up through a Google Account — Drive, Gmail, an attachment — use a different Google Account than the one running your developer account. Backing up to the same account protects nothing; it places the key inside the exact account a hijacker is already holding.

8. Can Google close my account for inactivity, with no policy violation at all?

Yes. Google Play developer accounts are intended for developers who actively publish and maintain apps, and inactive accounts are closed — without refunding the registration fee. Two independent sets of criteria define inactivity:

When either set is met, the account is marked for closure, an email is sent to the owner, and the state is shown clearly in Play Console. Reminder emails go out at 60, 30 and 7 days, and ignoring them means closure with no refund. Two actions prevent it: verify the contact details on the Account details page, and create and publish an app or publish an update to an existing one. If you hold a parked account as an asset, the second action is the one that keeps it alive — there is no "I signed in once" exemption from the phone and email verification requirement.

The pattern behind all eight answers

Every one of these is an operational control, not a policy argument: unique credentials, named users instead of a shared login, a habit of reading the Activity log and the notification bell, separation between personal and business Google Accounts, one keystore copy outside the developer account, and a calendar entry for dormant accounts. Accounts in this business are assets, and while enforcement drama gets discussed, the loss mechanism that actually fires is administrative. Note the asymmetry as well: app removals, suspensions and warnings all count as strikes against the standing of the account, and a termination for violating the Developer Distribution Agreement also permanently suspends related accounts — so the cheapest security work you ever do is the work that stops a compromise from becoming an enforcement case.

Sources