From 30 September 2026, apps installed on certified Android devices in Brazil, Indonesia, Singapore and Thailand must come from a developer whose identity Google has verified, and Google plans to extend the requirement worldwide in 2027. It applies to every app on certified devices running Android 7 or later, including apps distributed outside Google Play, which is the part that changes most for developers who sideload, use alternative stores or ship enterprise builds by link. Apps already on Play are mostly registered automatically. Everyone else registers through the new Android Developer Console, with a 25 dollar fee for full distribution or a free limited account capped at 20 devices.
Short answer
Android developer verification ties every installable app to a verified developer identity, its package name and its signing keys. Enforcement starts on 30 September 2026 for installs from participating stores on certified devices in four countries, then expands globally from 2027. If you publish only on Google Play with Play App Signing, most of your apps are already registered. If you distribute APKs directly, through another store or to testers by link, you need to verify your identity, register your package names and add your signing keys, or users will meet an extra installation flow designed to make unverified installs slow and deliberate.
The timeline, from Google's developer verification page, is short enough to plan around now:
| Date | What happens | Who it affects |
|---|---|---|
| August 2026 | Developer APIs, limited distribution accounts and the advanced flow for power users launch | All developers outside Play, testers, power users |
| 30 September 2026 | Unregistered apps cannot be installed from participating stores on certified devices in Brazil, Indonesia, Singapore and Thailand | Apps distributed to users in those countries |
| 2027 and beyond | Verification expands to all apps on certified Android devices globally | Every Android developer distributing to the public |
What verification actually requires
Verification has three parts, and each one catches a different kind of problem.
Your identity
Individuals provide personal identity information to Google. Organisations provide a D-U-N-S number, which Dun and Bradstreet issues for free but which, according to Google's verification FAQ, can take up to 28 days to obtain. If your company does not already have one, that lead time is the first thing to start, because nothing else can be finished without it.
Your package names
You register the package names that belong to you. The package name becomes the anchor that links an installable app to a verified owner, which is exactly what stops a malicious copy of a popular app from reusing its name under a new identity.
Your signing keys
You add and verify the signing keys for each package, and you can register more than one key per package. The FAQ is blunt about the risk: if you have lost a signing key, you cannot register the packages it signed. For teams that inherited an app from an agency or a former developer, confirming that you actually hold the release key is the most important check in this whole process.
Who needs to do what
The work depends almost entirely on how your app reaches users.
Google Play only
Google says Play automatically registers about 99 percent of apps. If you use Play App Signing, eligible apps are claimed automatically. Your job is to confirm in Play Console that every app shows as registered and to handle the small number that are not.
Play plus direct downloads or other stores
Apps that are on Play and also distributed elsewhere are registered through Play Console. Check that the signing key used for the off-Play builds is registered too. A build signed with a different key from the one Play knows about is, as far as verification is concerned, a different app.
Outside Play entirely
Developers who never use Play register through the new Android Developer Console. A full distribution account costs a one-time 25 dollars. A limited distribution account is free, needs no government ID, and lets you share apps with up to 20 specific devices, which suits students, hobbyists and small test groups. A limited account can be upgraded to full, but not the other way round.
Enterprise and managed devices
Apps pushed through an organisation's store to managed devices do not need verification, because the IT administrator has already vetted them. Google still recommends registering them, so installs work if the same app is ever downloaded on an unmanaged device.
What users will see for unverified apps
Unverified apps are not banned outright. Instead, Google is building an advanced flow for people who deliberately want to install them, and it is designed to be slow.
According to the FAQ, the user enables developer mode, confirms they are not being coached by someone pressuring them to lower their security, restarts and reauthenticates, then waits 24 hours before confirming with biometrics or a PIN. After that one-time setup they can allow unverified installs for seven days or indefinitely, and a warning still appears for each unverified app with an option to install anyway.
For a developer, the practical meaning is simple. An unverified app is no longer one tap away for ordinary users. Anyone whose distribution depends on direct APK downloads, a beta link sent to customers, or an alternative store, should treat registration as a release requirement rather than an option.
Two exceptions matter for development work. Apps installed through adb do not require verification, so local builds and debugging are unaffected. And if a user has disabled the advanced flow, updates to unregistered apps fail, which can strand existing installs of an app that was never registered.
Why Google is doing this
The stated goal is to deter bad actors who repeatedly spread malware and scams by distributing apps under new names after each takedown. Package names and signing keys tied to a verified identity make that harder: a banned operator cannot simply re-sign the same malware with a fresh key and a fresh name.
The security case maps onto long-standing guidance. The OWASP Mobile Application Security Verification Standard treats code integrity and resilience against tampering as core properties of a mobile app, and repackaged copies of legitimate apps, re-signed with an attacker's key and loaded with extra code, are one of the most common Android threats. Verification attacks that problem at installation time rather than inside each app.
It also changes the threat model for developers. A stolen or leaked signing key used to be a serious incident mainly because an attacker could push an update that looked authentic. Under verification, the registered key is also part of your identity record, so protecting it, rotating it when needed and keeping it out of repositories and build logs matters even more.
A checklist for the next two months
- Inventory every app and every distribution channel. Play, direct download, other stores, enterprise, testers. Each channel decides which console you use.
- Confirm you hold every release signing key. For each package, find the key that signed the builds users have installed. If an agency or former employee holds it, get it transferred securely now.
- Start the D-U-N-S number if your organisation does not have one. The up to 28-day lead time is the longest step.
- Check Play Console for any apps not automatically registered, and register them manually.
- Register off-Play apps in the Android Developer Console when it opens to you, including every signing key you use.
- Move testers to a limited account or Play testing tracks if you currently share APKs informally.
- Update your release documentation so every new app and new signing key is registered as part of the release process.
- Tell your users early if they install your app outside Play, especially in the four first countries, so they know what a registered app looks like and are not surprised by a changed installation prompt.
Where a security scan fits
Verification proves who published an app. It says nothing about whether the app itself is safe: a verified developer can still ship hardcoded API keys, over-broad permissions, exported components or insecure storage. Those are build-level problems that an automated pass over the APK or AAB can find before release. A scanner like PTKD.com analyses the built artifact and reports issues such as exposed secrets, risky permissions and insecure network settings by severity, mapped to OWASP MASVS. It does not register your app, verify your identity or manage your keys; the registration itself happens in Google's consoles.
The two checks complement each other. Verification makes it harder for someone else to impersonate your app. A scan makes it less likely that your own, verified app gives an attacker an easy way in.
Common questions from teams preparing now
Does this affect apps already installed on users' devices?
Installed apps keep running. The checks apply at installation and update time on certified devices. The risk for existing users is updates: if an app remains unregistered and the user has not enabled the advanced flow, updates fail, so users can be left on an old version.
What about apps built with cross-platform frameworks or app builders?
Verification looks at the package name and signing key, not at how the app was built. A React Native, Flutter or builder-generated app is registered exactly like a native one. What matters is that you, not the builder platform, control the signing key and the package name, or that you know exactly which account does.
What should agencies and white-label builders do?
Agencies that publish apps on behalf of clients face the ownership question most sharply. The verified developer, the registered package name and the signing key should all belong to the client who owns the app, not to the agency that built it. If an agency account currently holds a client's app, registration is the moment to fix that, because moving a verified registration later is likely to be harder than setting it up correctly once.
White-label platforms that generate many apps for many customers should decide early whether each customer registers its own app or the platform registers on their behalf, and document which key signs which build. Mixed arrangements, where some builds are signed by the platform and some by the customer, are exactly the case where installs start failing after enforcement.
Does verification replace Play Protect or app review?
No. Play Protect continues to scan apps on devices, and Google Play's review process continues for apps on Play. Verification adds an identity check at installation for all apps on certified devices. A verified developer whose app turns out to be harmful can still be acted on through the existing mechanisms, and verification makes it harder for that developer to return under a new name.
Do open source projects need to register?
Google publishes a guide for registering new and existing open source apps. Projects distributed through alternative stores should check how those stores handle signing, because the key that signs the distributed build is the one that has to be registered.
What to take away
- From 30 September 2026, unregistered apps cannot be installed from participating stores on certified devices in Brazil, Indonesia, Singapore and Thailand, with a global rollout planned from 2027.
- Verification ties your identity, your package names and your signing keys together; losing a signing key means you cannot register the packages it signed.
- Play apps are mostly registered automatically; off-Play apps go through the Android Developer Console, at 25 dollars for full distribution or free for up to 20 devices.
- adb installs are exempt, enterprise apps on managed devices are exempt, and unverified installs remain possible through a deliberately slow advanced flow.
- Verification proves who published an app, not that it is secure, so keep scanning builds with a tool such as PTKD.com before each release.
