An identity card can tell you who presented it. It cannot tell you whether the software they wrote is safe.

Google is turning that limited signal into a global installation gate. Its Android developer verification program links app package names and signing keys to registered developer accounts. Enforcement began on September 30, 2026 for participating stores in Brazil, Indonesia, Singapore, and Thailand. Google says it will expand the requirement globally in 2027 on certified Android devices running Android 7 or later.

The objective is legitimate: make it harder for repeat scammers to replace one malicious app with another anonymous copy. Critics argue that the mechanism is not proportionate. It concentrates the ability to decide which software installs normally on billions of privately owned devices, while verifying the developer rather than the code.

That distinction explains much of the opposition. The dispute is not simply “security versus openness.” It is whether Android can strengthen malware detection, provenance and user warnings without making one corporation the identity authority for software distributed outside its store.

TL;DR

  • Google is not security-reviewing every registered app. Its own analogy says developer verification is an identity check, separate from inspecting the software.
  • Registration may increase the cost of repeat abuse, but verified accounts, identities and signing keys can still be stolen, purchased or coerced.
  • The program creates a centralized map between legal identities, package names and signing keys, and makes normal installation depend on Google’s registry.
  • Unregistered apps remain installable through ADB or an “advanced flow,” but the user must enable developer mode, restart, wait 24 hours and authenticate before choosing a seven-day or indefinite exception.
  • Blocking or delaying updates to unregistered apps can itself create security exposure. Google says such apps cannot update unless the advanced flow is enabled or ADB is used.
  • A better design would combine cryptographic provenance, transparent reputation, malware scanning and explicit user choice without mandatory real-world identity registration.

What Google Is Actually Changing

Android already requires every APK to be digitally signed. The operating system uses that signature to verify integrity and to ensure an update comes from the same signing identity as the installed app. Historically, those certificates could be self-signed: the cryptographic continuity mattered, not approval from a central certificate authority.

Developer verification adds a separate control plane. Developers who want broad distribution outside Google Play must create an Android Developer Console account, complete identity verification, pay a $25 fee and register their package names and signing-certificate fingerprints. Google says it may also require an APK-based proof-of-ownership challenge for an existing package.

Google has added two important qualifications since the program was first announced:

  • A free limited-distribution account does not require government ID, but it requires a Google account with two-step verification and a linked Google payments profile containing the developer’s legal name and address. Current documentation limits sharing to 50 explicitly authorized devices.
  • Users can install software from unverified developers after activating an advanced flow. That process requires developer mode, anti-coercion prompts, a restart, reauthentication and a 24-hour waiting period. Users can then allow such installations for seven days or indefinitely.

ADB installation remains available without registration. Enterprise apps distributed through a managed organization store are exempt because an administrator controls that environment.

These exceptions mean it would be inaccurate to say Android will make every unregistered APK technically impossible to install. It is accurate to say that Google is making verified registration the default route to ordinary distribution and moving unverified installation behind a deliberately high-friction security exception.

Google’s Security Case Is Not Fiction

Google says malware is over 50 times more prevalent in apps obtained from internet-sideloaded sources than in Google Play. That comparison comes from Google’s own analysis and lacks enough public methodology to evaluate every confounding factor, but the underlying threat is real. Criminals routinely coach victims into installing fake banking, support and investment apps from browsers or messaging services.

The 24-hour delay is a recognizable anti-coercion control. It disrupts an attack in which a scammer keeps the victim on a live call, creates urgency and walks them through disabling protections. Developer identity checks can also increase the time and cost required to re-enter the ecosystem after an account is removed.

Opposing the mandate does not require pretending those benefits do not exist. It requires asking whether the same benefits justify a global identity and installation authority, and whether the control addresses the property users may assume it addresses.

It does not establish that an app is safe.

Google made this distinction clearly in its original announcement: identity verification confirms who the developer is, not what is inside the app. A registered app may still contain a vulnerability, hidden data collection, a malicious dependency or deliberately harmful code. A legitimate developer account can be compromised. A signing key can be stolen. A criminal can use a recruited or synthetic identity until enforcement catches up.

The control adds accountability. It does not replace code analysis, runtime detection, permission boundaries, reproducible builds or incident response.

Security Risk 1: Identity Can Become a False Trust Signal

The first risk is human interpretation. “Verified developer” sounds close to “verified safe,” even when the technical claim is much narrower.

Attackers exploit trust labels. If users, banks or device-management systems begin treating registration as evidence of benign behavior, a compromised verified account gains a more persuasive delivery path. The program can therefore move the valuable target upstream: from creating disposable APKs to stealing developer accounts, payment profiles and signing keys.

Google should measure and publish more than registration volume. Useful security evidence would include:

  • the rate of confirmed malware among verified and unverified apps, normalized by install source and volume;
  • the time between abuse detection, developer action and malicious-app replacement;
  • verified-account takeover and fraudulent-identity rates;
  • false blocks, appeal outcomes and time to restore legitimate distribution;
  • the number of users who miss security updates because registration or advanced-flow state blocks them.

Without that evidence, “millions of apps registered” measures adoption, not security effectiveness.

Security Risk 2: One Registry Becomes a Global Control Plane

The program binds together a developer account, legal identity, package names and signing-key fingerprints. Normal installation then depends on a registration decision delivered to certified devices through Google Play services.

That creates a high-value control plane with several failure modes:

  • Account compromise: control over a developer account may affect package and key registration even when the attacker does not possess the private signing key.
  • Registry or service failure: an erroneous status, unavailable service or broken integration can interrupt installation or updates independently of whether an APK is cryptographically authentic.
  • Administrative error: package-name conflicts and key eligibility rules can force a legitimate developer into review or a package-name change. Google documents an appeal-like process, but the developer remains dependent on its resolution.
  • Policy expansion: a service distributed through Google Play services can change outside a full Android operating-system update. Future policy is therefore not constrained to the exact rules users see today.

None of these possibilities proves Google intends abuse. Security architecture should not require benevolent intent. It should minimize how much harm any company, administrator, compromised account or legal demand can cause.

Security Risk 3: The Identity Database Creates Coercion Value

For a commercial publisher, providing business identity may be routine. For a developer of censorship-circumvention, secure-communications, labor-organizing or whistleblowing software, the link between legal identity and package can be dangerous.

The Electronic Frontier Foundation warns that once a platform builds an identity database and an installation gate, governments and private parties have an incentive to demand access or removal. The risk is not limited to a database breach. Lawful orders, political pressure and jurisdictional restrictions can all use the same centralized relationship.

Google acknowledges one concrete boundary: developers in comprehensively sanctioned countries cannot complete verification because Google is legally prohibited from doing business with them. Google says checks will not run on devices physically located in those countries. That exception illustrates the larger point. Software availability is now coupled to one US company’s legal and commercial position, even when the software never uses Google Play.

Anonymous publication is not proof of malice. In some threat models it is a safety control.

Security Risk 4: Update Friction Can Leave Known Vulnerabilities Exposed

Google’s FAQ says an unregistered app cannot be installed or updated unless advanced flow is enabled or ADB is used. This matters because patch delivery is part of security.

Consider an open-source app installed before the global rollout. If its maintainer declines identity registration and the user has not enabled the exception, a critical update can fail even though the new APK has the correct signing key and preserves the existing trust chain. The mechanism distinguishes registered from unregistered, not patched from vulnerable.

The advanced flow reduces this risk for technically confident users. It does not remove it for people who do not discover why an update failed, cannot wait 24 hours during an urgent migration, or interpret the warning as evidence that the signed update itself is malicious.

This is the most direct security objection to treating registration as a prerequisite for ordinary installation. A security control should not silently make authentic security updates harder to receive.

Open-Source Distribution Bears the Cost

Alternative repositories do more than mirror APK files. Some build applications from published source, apply their own review policy and sign repository builds in controlled infrastructure. Google now documents a workflow for those repositories, including registering both developer and repository signing-key fingerprints and performing an APK ownership challenge.

That workflow proves accommodation is technically possible. It also makes every participating project and repository depend on Google’s developer account and registry. Developers who do not register can still publish, but every user must first accept the advanced-flow burden.

F-Droid and a broad coalition of digital-rights, open-source and technology organizations argue that this changes Android from an open distribution model into permissioned distribution with an exception. Their central criticism is that a platform is not meaningfully open merely because an expert can recover the old behavior after a warning sequence and a cooling-off period.

What Critics Want Instead

Android does need stronger protection against coerced sideloading and disposable malware campaigns. The answer should preserve independent distribution and make claims that match the evidence.

A more proportionate design would:

  1. Keep code signing decentralized. Continue to accept self-signed APKs and use signature continuity as the basis for authentic updates.
  2. Separate identity, reputation and code analysis. Show each as a distinct signal. A verified legal identity must never be presented as a malware verdict.
  3. Make registration optional and useful. Developers could voluntarily attach a verified identity or organization to a signing key without making that registration a condition of normal installation.
  4. Use transparent, appealable blocklists for confirmed harm. Publish auditable criteria, signed status records, removal reasons, expiry rules and aggregate appeal metrics.
  5. Preserve secure updates. If an installed app’s update matches the existing signing lineage, registration status should not prevent the user from patching it.
  6. Target coercion at the risky event. A delay may be justified when a live-call scam or remote-control session is detected. It should not become a blanket penalty for every independent software source.
  7. Support repository attestations and reproducible builds. Let independent stores publish signed build provenance and transparency logs that users or organizations can choose to trust.
  8. Allow a durable owner-controlled policy. Users should be able to authorize a repository, signing key or package without asking Google to approve the developer behind it.

This approach would not eliminate malware. Neither will mandatory identity verification. It would distribute trust, preserve patch delivery and make compromised components easier to replace.

What You Can Do Today

  • Read Google’s current documentation before repeating early claims about the program. The advanced flow and limited-distribution account materially changed the original proposal, even though the central gate remains.
  • Support independent Android repositories and demand that they publish signing, build-isolation, incident-response and key-rotation practices.
  • Do not treat “verified developer” as “safe app.” Validate the source, signing fingerprint, requested permissions and update path according to the risk of the application.
  • If your organization distributes APKs outside Google Play, inventory package names and signing keys now. Test installation and update behavior on the affected certified-device configurations, but do not upload private signing keys: Google’s process asks for certificate fingerprints and signed proof, not the secret key itself.
  • Ask Google and regulators for public effectiveness, false-positive, appeal and account-compromise metrics before the global rollout.
  • Join the Keep Android Open campaign and sign the Keep Android Open petition if you support preserving independent software installation.

Why the Opposition Persists

Google has identified a real attack pattern and built a control that may slow it down. That does not justify making one private company the mandatory identity broker for software installed outside its marketplace.

The security boundary Android already understands is the signing key: it proves whether an update belongs to the same software lineage. Malware detection should evaluate behavior and code. Reputation should be transparent and plural. User choice should remain usable without a day-long permission ritual.

That is why opposition to the global mandate persists even after Google added ADB access, limited-distribution accounts and the advanced flow. Critics want Google to halt the rollout, publish evidence from the regional deployment and replace mandatory central registration with an optional, interoperable trust layer.

Sources