By 
Last week, we wrote about Google's Android Developer Verification Program and how it represents a fundamental shift in what Android has always stood for. One of the natural questions that article raises is: if Google is tightening its grip on stock Android, what about the alternatives? What about GrapheneOS?
It is a fair question, and on the surface the answer looks obvious. GrapheneOS is free, open-source, and built entirely outside of Google's corporate structure. It ships no Google apps by default, it cannot be controlled by Play Store policies, and it has consistently been rated as one of the most technically secure Android distributions available. If the concern is Google centralising control over the Android ecosystem, GrapheneOS looks like the logical refuge.
Except that right now, in the same weeks that Google's verification program is dominating tech headlines, GrapheneOS users are getting locked out of their cars, flagged to law enforcement for choosing a private operating system, and treated as anomalies by platforms they pay to use. The escape hatch has its own wall, and it is being built by companies that are not even aware they are building it.
What Is GrapheneOS, and Why Does It Exist
GrapheneOS is an open-source mobile operating system built on top of the Android Open Source Project (AOSP). It is developed by the GrapheneOS Foundation and targets users who want strong privacy and security without compromising on Android app compatibility. As of April 2026, the project has approximately 400,000 active users, a number that has grown significantly as privacy-conscious consumers have looked for alternatives to stock Android and iOS.
The technical case for GrapheneOS is not subtle. It ships with a hardened memory allocator, more aggressive address space layout randomisation, stronger app isolation, and a smaller attack surface from Google services. Security updates ship faster than most OEM distributions. The project recently partnered with Motorola to bring official GrapheneOS support beyond Google Pixel devices, signalling that it is moving from a niche project to something more mainstream.
By every objective technical measure, a GrapheneOS device is more secure, more up-to-date, and more resistant to compromise than the average stock Android phone. That is not a point of controversy among security researchers.
Which makes what is happening to its users right now particularly difficult to rationalise.
Volkswagen: You Can Access Your Car From a Five-Year-Old Unpatched Phone, Just Not This One
Volkswagen users running GrapheneOS began reporting recently that they could no longer log into the official VW app or remotely control their vehicles. The failure is not a bug. It is a deliberate enforcement decision.
Volkswagen's app now requires a device to pass specific checks through Google's Play Integrity API, a system that verifies whether a device is running an officially certified Android environment. GrapheneOS does not pass those checks, not because it is insecure, but because it is not an official Google product and does not carry Google's proprietary certification. The result is that a Volkswagen owner running one of the most secure mobile operating systems available cannot unlock their own car from their phone.
The comparison that GrapheneOS forum users are drawing is the one that matters most here. The VW app continues to work on stock Android devices that are completely end-of-life: phones that are no longer receiving security patches, carrying years of unaddressed vulnerabilities, potentially exposed to remote code execution exploits that have been public knowledge for years. Those phones pass. GrapheneOS, which ships timely security updates and is actively maintained, does not.
Volkswagen's response when users raised this was essentially a "sorry, unsupported" reply. The company confirmed that "alternative operating systems" including GrapheneOS, LineageOS, and similar custom ROMs are not part of the supported application environment for the VW app.
That response is technically accurate and completely unsatisfying. Nobody is asking Volkswagen to provide technical support for custom ROMs. The question being raised is whether a car manufacturer should be using Google's certification framework as the sole definition of whether a device is trustworthy enough to control a vehicle, when that framework has no meaningful correlation with actual security.
How Play Integrity Actually Works, and Why It Creates This Problem
To understand why this keeps happening, it is worth being precise about what Play Integrity does and what it does not do.
Google's Play Integrity API is a system developers use to verify three things: whether an app is genuine and unmodified, whether it came from the Play Store, and whether the device it is running on is trustworthy. That last check is the relevant one here.
The API returns verdicts at different trust tiers. MEETS_BASIC_INTEGRITY means the device passes basic checks. MEETS_DEVICE_INTEGRITY means the device is a certified Android device with Google's approval. MEETS_STRONG_INTEGRITY is the highest tier, requiring hardware-backed security signals and, on Android 13 and above, a security update within the last year.
GrapheneOS does not receive a MEETS_DEVICE_INTEGRITY verdict because certification requires devices to carry a cryptographic signature from a Google-approved OEM and include Google's proprietary components in a specific way. GrapheneOS is built entirely from open-source components and does not participate in that certification process by design.
This is where the fundamental flaw lies. Developers integrating Play Integrity are not conducting a security audit of your device. They are checking a box: does Google vouch for this device? If yes, proceed. If no, block. The metric being used is compliance with Google's ecosystem, not actual device security. Those two things can overlap. They are not the same thing.
A five-year-old phone running a certified Android build passes MEETS_DEVICE_INTEGRITY. A fully patched, actively maintained, security-hardened GrapheneOS device does not. The API is measuring the right thing for detecting modified apps or rooted devices running sketchy software. It is measuring entirely the wrong thing when applied to a privacy-focused OS that is objectively more secure than what it is being compared against.
Volkswagen's development team almost certainly did not sit down and decide to lock out GrapheneOS users. What they more likely did was turn on stricter integrity enforcement to block rooted phones and tampered app builds, and GrapheneOS became collateral damage. The end result is the same from the user's perspective, but the mechanism matters: this is not malice, it is outsourcing. Volkswagen handed their security model to Google's SDK and stopped thinking about it.
Yoti: Using a Private OS Gets You Flagged to Police
The Volkswagen situation is frustrating. The Yoti incident is something else entirely.
Yoti is a British digital identity and age verification company whose tools are integrated into Sony PlayStation, TikTok, Meta, Spotify, and OnlyFans. Sony began rolling out mandatory age verification for PlayStation Network users in the UK and Ireland in 2026, driven by requirements under the UK Online Safety Act.
A GrapheneOS user attempting to complete PlayStation's age verification through Yoti received a customer support response claiming their device had been "automatically reported to both the authorities and our security team." The stated reason: the user was running GrapheneOS, which Yoti cited as having "past security concerns."
Yoti subsequently denied that the screenshots of the exchange match their records and suggested the messages may have been fabricated by the support agent. GrapheneOS publicly described the response as "customer support making ridiculous claims" and characterised it as fearmongering from an agent trying to close a ticket.
Whether or not any actual law enforcement report was filed, the episode revealed something important about how GrapheneOS users are being treated by systems that rely on device fingerprinting for trust signals. When a platform cannot verify your device through Google's attestation framework, it does not conclude that you value privacy. It concludes that you are an anomaly. And in systems designed around fraud prevention, anomaly detection defaults to suspicion.
The broader context around Yoti does not help their credibility here. In March 2026, Spain's data protection regulator AEPD fined Yoti approximately 950,000 euros for GDPR violations including improper biometric data retention, invalid consent mechanisms, and excessive data storage periods. Separately, researchers from the Georgia Institute of Technology and the University of California accused the company of collecting excessive data during age verification, including operating system version, RAM, and processor architecture, and sharing that data with third-party services including credit card companies, geolocation services, and data brokers. Yoti has denied those claims and called for the research to be withdrawn.
A company with that specific track record flagging GrapheneOS users for "security concerns" is a particular kind of irony.
The Pattern Being Established
These are not isolated incidents. This is the third significant case in recent weeks where choosing a more private operating system has resulted in losing access to services. The consistent mechanism is the same in each case: Play Integrity certification, or a similar attestation framework, acts as a proxy for trust, and any device that does not participate in Google's approval chain gets flagged or blocked regardless of its actual security posture.
The practical message being sent to privacy-conscious users is uncomfortable but clear: the more seriously you take your own security, the more mainstream services will treat you as a problem.
This matters not just for the roughly 400,000 GrapheneOS users directly affected, but for what it signals about the direction of the mobile ecosystem more broadly. If Play Integrity becomes the de facto standard by which every significant app decides who gets access, then Google's certification framework becomes a quiet prerequisite for participating in digital life, even for users who have made a deliberate and technically informed choice to operate outside that framework.
That is a form of control that does not require policy announcements or official mandates. It just requires enough developers to tick the "require device integrity" box without thinking too hard about what that box actually measures.
GrapheneOS Is Not a Perfect Alternative Either
This is a good moment to be honest about the limits of the GrapheneOS escape hatch, even before the Play Integrity problem is considered.
GrapheneOS only runs on Google Pixel devices, with Motorola support beginning rollout in 2027. If you do not own a Pixel, you cannot run it. The installation process requires comfort with flashing firmware and working through a command-line web installer: it is more accessible than it used to be, but it is still not a mainstream experience. There is no equivalent of walking into a phone shop and asking for a GrapheneOS handset.
Beyond the technical barrier, the compatibility picture has always required compromise. Many popular apps either do not work or require workarounds involving GrapheneOS's sandboxed Google Play feature, which allows running Google's app framework in a restricted environment without giving it system-level access. That sandboxed approach works well for most apps, but it cannot spoof Play Integrity attestation at the highest device integrity tiers, which is exactly why the Volkswagen and Yoti situations are happening.
The project has also faced its own institutional pressures. GrapheneOS ceased operations in France in late 2025 following government pressure and legal threats. The project publicly stated in March 2026 that it will not comply with legislation requiring collection of user age data, which reflects a principled stance but also signals ongoing friction with regulatory environments in multiple jurisdictions.
None of this makes GrapheneOS a bad option. For the users it serves, it remains technically exceptional. But it is not a seamless escape from the trade-offs of the mainstream mobile ecosystem. It trades one set of constraints for another.
The Actual Problem, Plainly Stated
The root issue is not Google, or Volkswagen, or Yoti specifically. The root issue is that device attestation has become infrastructure, and that infrastructure has a single controlling authority.
When Google's Play Integrity API becomes the standard mechanism by which apps decide whether a device is trustworthy, Google's definition of "trustworthy" becomes the effective policy for the entire ecosystem. That definition, by design, excludes any operating system that does not carry Google's certification. Not because those systems are insecure, but because Google cannot commercially certify what it does not control.
Companies like Volkswagen are not running security audits. They are delegating the security decision to Google's SDK and moving on. That is understandable from an engineering resource perspective. It is also how a monopoly on trust gets built without anyone explicitly choosing to build one.
For users, the ask should be simple: if your app supports remotely accessing a vehicle, controlling financial accounts, or verifying someone's identity, you should be able to explain your security model in terms of what the device actually does, not just whether Google has approved it. An operating system that ships security patches faster than your stock Android OEM does, that isolates apps more aggressively, and that does not share device telemetry with advertising ecosystems should not be disqualified from "trusted" status because it chose not to carry Google's paperwork.
The Android Developer Verification Program is changing how apps get distributed on Android. The Play Integrity API is quietly shaping who gets to use them at all. Both trends are worth watching, and right now they are pointing in the same direction.
Comments