Volkswagen bricks Home Assistant integration with signed-JWT lockout

5 min read 1 source clear_take
├── "VW is using security as cover for closing off third-party access and control"
│  └── top10.dev editorial (top10.dev) → read below

The editorial argues that signed client assertions with hardware attestation are genuinely good at proving app authenticity, but the real effect here is locking out third-party clients entirely. Frames this as the connected-car version of a decade-long consumer tech pattern where APIs are closed for control with security as the load-bearing justification.

├── "This is a fundamentally different lock — reverse engineering won't work this time"
│  └── top10.dev editorial (top10.dev) → read below

Past VW auth breaks were 'lock changes' that could be reverse-engineered from an APK in an afternoon. A device-bound signing key backed by Play Integrity or App Attest requires modifying the app binary on rooted devices with hooks — a fragile pipeline that can't realistically be shipped to thousands of Home Assistant users.

├── "The change is internally framed as anti-credential-stuffing, not anti-Home-Assistant"
│  └── @Anonymous VW Group employee (Hacker News) → view

A commenter identifying as a VW Group employee surfaced to say the change was not communicated internally as a deliberate Home Assistant kill, but as 'hardening against credential-stuffing.' Suggests the third-party lockout may be collateral damage from a security initiative rather than the stated goal.

└── "This is reason enough to never buy another VW"
  └── @Hacker News commenters (Hacker News) → view

A steadily rising current in the 187-point HN thread expresses the view that closing off legitimate owner access to their own vehicle's data is a betrayal of the buyer relationship. These commenters treat the integration break as a purchase-decision signal, not just a technical inconvenience.

What happened

On GitHub issue #967 of `robinostlund/homeassistant-volkswagencarnet` — the de facto Home Assistant integration for Volkswagen, Skoda, SEAT, Audi, and Cupra vehicles — users started reporting `401 Unauthorized` errors against the MyCar (formerly We Connect) backend. The cause, quickly pinned down by the maintainer community, isn't a rotated secret or a deprecated endpoint. Volkswagen's identity provider now demands a `client_assertion` parameter on the token exchange: a signed JWT that proves the request originated from the official Volkswagen mobile app, signed with a key that lives inside the app's attestation flow.

The integration has reverse-engineered VW's auth before — multiple times. Each previous break was a lock change; this one is a different lock entirely. A static client ID and PKCE flow can be lifted out of an APK in an afternoon. A device-bound signing key backed by Play Integrity or App Attest cannot, at least not without modifying the app binary, running it on a rooted device with hooks, and shipping that fragile pipeline to thousands of Home Assistant users who just want their garage to know when the car is home.

The thread on Hacker News (187 points) is doing what HN threads do when a vendor pulls the ladder up: a mix of forensic curiosity, RTFM finger-wagging, and a steadily rising current of "I will never buy another VW." One commenter, an apparent VW Group employee, surfaced briefly to say the change wasn't communicated internally as a Home Assistant kill, but as "hardening against credential-stuffing." Whatever the intent, the effect is unambiguous: third-party clients are out.

Why it matters

This is the connected-car version of a pattern that has hardened across consumer tech for a decade. The API isn't being closed for security — it's being closed for control, with security as the load-bearing justification. Signed client assertions with hardware attestation are genuinely good at one thing: proving that a specific binary, on a specific device, in an un-tampered runtime, is making the request. They're not meaningfully better at proving the *user* authorized the request — that's still a password and an OAuth consent screen. What they exclude is exactly what Home Assistant is: a user-controlled client that the vendor didn't ship.

Compare the approaches. Tesla, for all its other sins, ships an actual OAuth-authenticated owner API and recently rolled out a per-vehicle virtual key model that — while irritating to set up — is a legitimate consent primitive. BMW's iDrive API has been a perpetual cat-and-mouse with open-source clients but has never fully attested. Ford and GM have lobbed third-party automation off and on, depending on insurance-data monetization deals. Volkswagen's move puts them at the strictest end of a spectrum that, across the industry, is sliding one direction only.

The community reaction frames this correctly. The car you bought has a computer in it; the computer talks to a server you don't own; the server decides whether your scripts run. One top HN reply put it dryly: "Right-to-repair fought for the OBD port. Nobody fought for the API, and now we don't have one." That's the structural read. The EU's Data Act, which is supposed to give vehicle owners access to data their cars generate, doesn't take full effect until September 2026 and explicitly does not mandate API access — it mandates *data portability*, which a vendor can satisfy with a CSV export. A client assertion gate is fully compliant with the letter of that law.

There's also a quieter implication for the integration maintainers. `volkswagencarnet` is maintained by volunteers. The realistic options now are: (1) extract the signing key via app instrumentation and ship a pre-signed assertion (legally gray, technically fragile, will be detected and revoked); (2) proxy through a community-run intermediary that runs the official app in a VM farm (legally grayer, operationally absurd); (3) declare the integration end-of-life for new MyCar accounts and grandfather existing tokens until they expire. Option 3 is what usually happens. The HA forum has already started a "affected models" thread that reads like a wake.

What this means for your stack

If you have Home Assistant scripts that depend on VW telemetry — geofencing, charge scheduling tied to solar production, climate pre-warm on calendar events — assume they will stop working within the existing refresh-token window, which for VW is roughly 90 days. Snapshot what you actually use. Most users will discover they were polling battery state and lock status; that's two data points, both available via a Bluetooth proximity sensor and an OBD-II dongle with a SIM, for about $80 total and zero vendor dependence.

More broadly: treat any vendor cloud API in your home automation graph as a planned outage, not a service. The integrations that survive long-term — Zigbee, Z-Wave, ESPHome, Matter (mostly), local Hue, local HomeKit — all share the property that the vendor cannot disable them remotely. Anything that round-trips through `vendor.com/oauth/token` is on borrowed time, and the time gets shorter every year. Build with local protocols where they exist; isolate cloud dependencies behind a single integration layer so when the inevitable happens, you replace one node, not twenty automations.

For anyone shipping a product with a public-ish API: this episode is also a recruiting tool against you. Developers reading the HN thread are noting which brands they will and won't buy next. Volkswagen sold approximately 9.2 million vehicles in 2025; the Home Assistant install base is somewhere north of 600,000 active instances. The overlap is small in raw numbers but enormously overrepresented in the segment that writes the reviews, files the bugs, and tells their families what to buy.

Looking ahead

The interesting variable is whether the EU Data Act, when it bites in September, forces VW to offer a real API rather than a quarterly data export. The boring base case is that VW ships a CSV download portal, calls it compliant, and the Home Assistant integration stays dead. The optimistic case requires regulators to define "access" in machine-readable, real-time terms — and there is currently no draft language that does so. Until then, the rule for connected-vehicle automation is the same rule that has applied to every other vendor cloud: own the endpoint, or accept that you're renting the feature.

Hacker News 351 pts 175 comments

Volkswagen blocks Home Assistant by requiring client assertion

→ read on Hacker News
kuizu · Hacker News

Wasn't the EU Data Act (https://digital-strategy.ec.europa.eu/en/policies/data-act) put in place to exactly prevent these kind of scenarios (Article 4 and 5)?"where the user cannot directly access the data from the connected product or related service, the data hol

NiekvdMaas · Hacker News

BYD DMCAd my whole repo to connect to their cars... https://github.com/github/dmca/blob/master/2026/05/2026-05-2... It's a shame these car makers are locking down their cars (which are brought for a premium!) and going on a crusade against open sourc

venzaspa · Hacker News

Quite a few other manufacturers have done the same thing. I use a reverse engineered Polestar library to get charging status but I'm in the middle of building a CANBUS sniffer to do the same job because I don't trust they won't do the same thing as this.I don't really understand

vincnetas · Hacker News

This comment has really nice translation of corpo-speek to human language :https://github.com/robinostlund/homeassistant-volkswagencarn...Why are they shooting them selves in the feet? Is this really a tangible income stream? Is it really increasing security?

Retr0id · Hacker News

Client Assertion is an OAuth feature, but that is not at all what is being discussed here, if anyone else was confused. It is only present in the HN title and is not mentioned on the page.

// share this

// get daily digest

Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.