Google is opening the Android ecosystem to third-party app stores on July 22, 2026. For brands already fighting rogue mobile apps, the change creates new distribution channels to monitor and new trust signals for attackers to exploit.
To comply with a recent U.S. court order, Google will open up the Android ecosystem on July 22, 2026. Third-party app stores will get access to the full Google Play catalog, making it easier for U.S. users to discover and install apps from rival stores on their Android devices.
If you’re a financial institution or enterprise worried about rogue mobile apps impersonating your brand, the obvious question is whether this makes the problem better or worse. Here’s what’s changing, what isn’t, and how to think about the developer choices Google is now putting in front of you.
This is an Android change, not an Apple one, for now
The new requirements come out of the Epic v. Google antitrust case. Courts ruled that Google’s Play Store rules were anti-competitive in how they limited rival app stores and billing, and ordered remedies on Android.
Epic’s separate suit against Apple didn’t reach the same conclusion. That fight is still mostly about payment and “steering” rules, not alternative stores. So this is about your Android risk surface. iOS distribution and rogue-app risk are unchanged for now.
What "Play Catalog Access" actually means
Google will let third-party Android stores access and present the full catalog of Google Play apps, so their users can browse those apps just like they would in Play.
The catch: when a user in a compliant third-party store installs one of your apps, the actual download and installation still occur through Google Play, not from an APK hosted on the third-party store. Under the Google Play Catalog Access Program, these competing stores act more like catalog front ends that deep-link into Google Play than separate distribution channels, at least when they follow the rules.
Why third-party app stores have been a rogue-app problem
Security teams worry about third-party Android stores for good reason. Many have weak or no vetting, which makes them a major source of malware, trojanized apps, and credential-stealing clones. The playbook is consistent: a threat actor takes a legitimate banking or payments APK, adds malicious code, and re-uploads it under the same or a similar name, icon, and description. To the user it looks like the official app. To the financial institution or enterprise whose brand is on it, it’s a look-alike harvesting user credentials or draining accounts from an app store they don’t control.
Historically, installing one of these meant enabling “unknown sources” and sideloading an APK from outside Google Play. That was a red flag. The rule of thumb was simple: if an app isn’t in Google Play or an OEM store you trust, don’t install it.
How the change shifts the risk (but doesn't remove it)
The catalog-access model changes the picture in two ways.
It’s safer for users when stores follow the rules. If a third-party store just lists your app and sends users to Google Play for the install, those downloads still get Play Protect scanning, security review, and data-safety requirements. To keep access, the program requires participating stores to “proactively and in good faith prevent the distribution of malware and Potentially Harmful Apps (PHAs),” enforce policy against fraud, and stay below a 1% malware installation-attempt rate over a rolling 30-day window across all devices globally. That makes it meaningfully safer than sideloading APKs straight from a store’s own servers.
It isn’t a silver bullet. Independent research shows hundreds of malicious apps still bypass Google’s vetting each year despite these controls.
It normalizes third-party stores as a place people find apps. As alternative stores get easier to find and use, more users will start their search there instead of in Google Play. Reputable stores will deep-link into Google Play. Less reputable or outright malicious ones can copy the same experience, offer your app by name, and deliver a tampered APK instead.
So the program plus Google Play-based installation is genuinely safer than pure sideloading when it’s implemented correctly. But normalizing third-party stores gives attackers more chances to impersonate your brand in places you don’t control.
Your risk choices: three Google Play options
Google’s developer settings give app owners three high-level choices for catalog access:
- “Publish all my app listings on all third-party app stores”
- “I’ll manage all third-party app stores individually”
- “Do not publish any of my app listings on any third-party app stores”
These boil down to risk-appetite statements. Here’s how each looks through a security lens.
Option 1: Publish on all third-party stores. Maximum distribution, maximum exposure. Your app shows up wherever users browse, which is good for growth. The cost: you implicitly bless a broad set of catalogs whose governance you may have no visibility into, you give attackers more official listings to clone and re-upload, and your monitoring and takedown footprint grows substantially. For regulated sectors like banking, insurance, and defense, this is hard to justify unless you already have strong mobile-security, fraud, and digital risk protection functions in place. It’s unlikely to be your default-safe option.
Option 2: Manage stores individually. This choice supports a more curated, risk-based approach. You approve a small set of stores that meet your bar for security and governance (say, a major OEM store your customers already use) and keep your app out of niche stores with little legitimate demand and the potential for more rogue-app activity. It maps cleanly to existing enterprise controls: maintain an internal “approved app store” list, document due diligence on each one, and tell customers exactly where to find you (“our official Android app is in Google Play, OEM store X, and store Y”). The nuance can still get lost in translation, and attackers can still upload fakes using your brand. You’ll need discovery and enforcement across the broader ecosystem either way.
Option 3: Publish nowhere but Google Play. The most conservative stance. You keep official Android distribution tightly constrained to Google Play and any corporate channels you already use, like through Mobile Device Management, which aligns with long-standing guidance to avoid unofficial stores. Customer or user messaging is dead simple: “If our Android app isn’t in Google Play or our corporate app portal, it isn’t from us.” But opting out doesn’t stop attackers from extracting your APK or building look-alikes and pushing them to stores you don’t use. If you aren’t watching those ecosystems, your customers may hit a convincing fake long before you know it exists. This option shrinks your official attack surface; it doesn’t remove your obligation to watch for brand abuse elsewhere.
What it means for your digital risk and brand protection strategies
Whichever setting you choose, three things stay true for financial institutions and enterprises:
- Your brand will be used in places you didn’t authorize. Attackers will keep uploading fake and modified apps to third-party stores, especially as users get more comfortable installing from them.
- Mobile app protection and discovery across app stores is now table stakes. You need continuous visibility into where your logos, names, and app-package identifiers show up across official and alternative Android stores, not just Google Play.
- Takedown has to be repeatable. When you find a rogue app, you need a tested playbook for engaging the store, gathering evidence, getting it removed, and warning affected customers.
The court order changes how legitimate stores can promote your apps. It does nothing to stop adversaries from abusing less scrupulous stores, social-engineering your users, and piggybacking on a new trust in alternative marketplaces.
The Bottom Line
Google’s new rules make it easier for alternative Android stores to list your apps, but stores authorized under the Play Catalog Access Program have to send users to Google Play for the actual download, which is safer than traditional APK sideloading. The bigger risk is cultural: as users get comfortable finding apps in third-party stores, attackers will exploit that habit in the less-regulated marketplaces and fake storefronts that don’t follow Google’s rules. Whichever catalog-access option you choose, you still need ongoing monitoring for rogue apps and a clear response process when your brand is abused. That’s enough to have a rational, risk-based conversation about which option fits your institution’s appetite and regulatory environment, without overstating or understating what the court order actually does.
That ongoing discovery and repeatable takedown is exactly what brand protection is for: continuous visibility across every store where your brand can appear, and threats eliminated before your customers reach them.
Key Takeaways
Starting July 22, 2026, third-party Android app stores can access and present the full Google Play catalog. When users install apps through compliant stores, the download still occurs through Google Play, preserving Play Protect scanning and security review.
As alternative stores become normalized, more users will discover apps outside Google Play. Reputable stores will follow the rules, but less scrupulous ones can copy the same experience, offer your app by name, and deliver a tampered or trojanized APK instead.
Publish on all third-party stores (maximum distribution, maximum exposure), manage stores individually (curated, risk-based approach), or publish only on Google Play (most conservative, simplest customer messaging). Each is a risk-appetite statement with different monitoring and takedown implications.
No. Attackers can still extract your APK or build look-alikes and distribute them through stores you don’t control. Opting out shrinks your official attack surface but does not remove the need to monitor for brand abuse across the broader ecosystem.
Yes. The requirements stem from the Epic v. Google antitrust ruling. Apple’s iOS distribution and rogue-app risk are unchanged for now.
