The editorial argues there is no security justification for blocking GrapheneOS since the VW app handles no payments and the car itself is the secure element. GrapheneOS is objectively more hardened than stock Android — verified boot, hardware-backed attestation, stricter permissions — yet fails Google's certified-device whitelist purely as a policy choice, not a security one.
Surfaced the GrapheneOS forum thread to Hacker News where it hit 362 points, framing it as Volkswagen blocking users of a more-secure OS. The submission's traction reflects developer-community frustration that Play Integrity is being weaponized against hardened Android forks.
The editorial points out that this is the same Volkswagen whose Cariad division shipped a widely-panned EV infotainment system and whose telemetry endpoints leaked precise GPS locations of 800,000 EVs to the open internet for months in 2024 — discovered by the Chaos Computer Club, not by VW. An automaker with that security posture lecturing customers about phone OS integrity is absurd.
The editorial frames the mechanism as Google's certified-device whitelist becoming a de facto gate for third-party services, where apps treat MEETS_DEVICE_INTEGRITY and MEETS_STRONG_INTEGRITY as hard requirements. GrapheneOS — despite being more secure — cannot pass because Google's whitelist is a policy choice, effectively letting Google decide which Android distributions users are allowed to run if they want access to mainstream apps.
Pixel 8 and 9 owners posting screenshots of the 'device not supported' error are documenting a growing pattern: banking apps, government apps, and now automakers gate access on Play Integrity verdicts that GrapheneOS structurally cannot pass. The forum thread reflects a community position that this is an attestation-driven enclosure of the Android ecosystem.
GrapheneOS users started reporting this week that the official Volkswagen app — the one that handles remote lock/unlock, climate pre-conditioning, charge scheduling on ID-series EVs, and trip data — now refuses to launch on their phones. The thread on discuss.grapheneos.org hit 362 on Hacker News, with owners posting screenshots of the same generic 'device not supported' error. The phones in question are Pixel 8s and 9s running a hardened Android fork that ships with verified boot, hardware-backed key attestation, and a stricter permission model than the stock OS Volkswagen is implicitly endorsing.
The mechanism is almost certainly Google's Play Integrity API. Apps call it to ask Google's servers, 'is this device a real, Google-certified Android device running an unmodified Play-approved OS?' GrapheneOS, despite being more secure than the OEM build it replaces, returns `MEETS_BASIC_INTEGRITY` but fails `MEETS_DEVICE_INTEGRITY` and `MEETS_STRONG_INTEGRITY` — because it is not, and cannot be, on Google's certified-device whitelist. The GrapheneOS team has spent years documenting that this is a policy choice by Google, not a security one. Volkswagen, like a growing list of banking and government apps, now treats those two stronger verdicts as a hard gate.
Notably, there is no security justification offered. The Volkswagen app does not handle payments. The car itself is the secure element. The phone is, at most, a convenient remote control over an HTTPS API that is already authenticated with the user's account credentials.
This is the same Volkswagen whose Cariad software division shipped an in-car infotainment system widely panned as one of the worst in any production EV, and whose telemetry endpoints leaked the precise GPS location of 800,000 EVs to the open internet for months in late 2024 — discovered by the German Chaos Computer Club, not by VW. An automaker with that track record is now in the business of telling customers which mobile operating system is 'secure enough' to talk to a car they own.
The broader pattern is what GrapheneOS developers have been warning about for three years: attestation creep. The Play Integrity API was sold as anti-fraud tooling for high-value financial transactions. It has metastasized. McDonald's app, Revolut, several state-level COVID apps, Australian MyGov, UK NHS login, and now your car. Each integration is individually defensible; the aggregate is a quiet redefinition of 'a smartphone' to mean 'a device whose root of trust is delegated to Google.' Custom ROMs, including ones demonstrably more hardened than stock, are getting locked out of the physical world one app at a time.
The irony is sharp. GrapheneOS is what security researchers actually carry. It's the recommended device for journalists in hostile environments, for Edward Snowden, for the EFF's threat-modeled users. It supports hardware-backed key attestation — the very primitive Play Integrity is built on — and exposes it through `KeyMint` exactly the way AOSP intended. Volkswagen could verify device security via that standard API without going through Google's commercial certification program. They chose not to. Or, more likely, they outsourced the decision to whoever built their mobile SDK and never thought about it.
Community reaction on the HN thread split along predictable lines. The 'just install the stock OS' camp gets shouted down quickly — the whole point of buying a $40k+ EV is that it should outlast a phone OS policy decision. The 'sue under right-to-repair' camp points to the EU's Digital Markets Act and the pending Cyber Resilience Act, both of which arguably require interoperability for vehicle telematics. And the 'reverse engineer the API' camp is already linking to the existing `evcc` and `WeConnect` open-source projects that talk to VW's backend directly — without the app, without attestation, and without Volkswagen's permission.
If you build a mobile app and someone on your team has suggested adding Play Integrity, ask three questions. First: what's the actual threat? If it's account takeover, you want device binding and step-up auth, not OS attestation. If it's API abuse, you want rate limiting and behavioral signals, not a hardware check that excludes 0.1% of your users and 100% of your security-conscious ones. Play Integrity is the cheapest possible answer to a question you probably haven't defined.
Second: what's your fallback path? GrapheneOS users are a rounding error in raw numbers but a meaningful slice of the security and developer community that writes about your product. The HN thread is currently the #2 story on the site. Volkswagen is getting the kind of coverage that no PR team optimizes for. If you must use attestation, gate only the highest-risk flows behind it, and offer a documented manual verification path — email + photo of registration, whatever — for users on alt OSes. This is what some banks have grudgingly started to do.
Third: where does the attestation live? If it's in the mobile SDK your vendor ships, you may not even know it's there until your users start filing complaints. Audit the integrity checks in your build. Same goes for WebAuthn flows that demand platform authenticators — there are equivalent exclusion patterns on the web. The practical advice for developers carrying a GrapheneOS device, meanwhile, is the one the community has converged on: keep a second cheap stock-Android phone in a drawer for the 5-10 apps that refuse to work, and write to vendors every time you have to use it. The friction is the point.
The EU's Digital Markets Act has already forced Apple to allow third-party app stores. The next regulatory frontier is exactly this — whether platform attestation can be used to functionally exclude alternative operating systems from the consumer hardware ecosystem. Germany, of all places, is where this fight is loudest, and Volkswagen, of all companies, may have just handed regulators the cleanest possible test case. Either Play Integrity gets a mandated 'equivalent security' carve-out for hardened forks, or the next decade of car ownership comes with a forced OS upgrade attached. Bet on the regulators getting there before VW does.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.