Bosch ME7 EEPROM IMMO OFF for VW / Audi / SEAT / Skoda (2026)

Who this is for

This guide is for the person holding a VW, Audi, SEAT, or Skoda from the 1.8T era who already has the Bosch ME7 engine control unit out on the bench, a chip programmer in hand, and a car that fires for half a second and then dies. That start-then-stall behavior is the classic signature of an active immobilizer refusing to let the engine run. If that is your situation, you are in the right place.

It is also for the engine swapper dropping a 1.8T, 2.0, VR6, 2.8 V6, or 2.7TT into a chassis whose immobilizer data no longer matches the incoming ECU, and for the standalone, off-road, and motorsport builders who want the factory immo logic out of the way so the engine simply runs when it has fuel, spark, and compression. If you own the vehicle and the parts, and you want the immobilizer flags cleared out of the ME7 immo EEPROM cleanly and verifiably, this is written for you.

It is not for anyone trying to defeat emissions controls, and it is not for anyone trying to start a car they do not own. The United States Environmental Protection Agency air enforcement program treats tampering with emissions-related controls as a serious violation, and the National Highway Traffic Safety Administration vehicle theft prevention office exists precisely because immobilizers are anti-theft hardware. Immo-off is a legitimate repair and build tool for lawful owners. It is not a workaround for either of those lines, and this article does not treat it as one.

What the ME7 immo EEPROM is

The Bosch ME7 family — ME7.1, ME7.1.1, and ME7.5 — is the Motronic engine management generation that ran across VW Group four-cylinder and six-cylinder gasoline engines from roughly 1998 to 2006. You will find it in MK4 and early MK5 platform cars, and in the B5 and B6 Audi platforms. Inside that ECU, the engine-running logic lives in the main flash memory, but the immobilizer decision does not. The immobilizer state — whether the ECU believes it has been authorized by the car's immobilizer control unit — is stored in a small, separate serial EEPROM chip on the ECU board.

That distinction matters, because it is the whole reason a bench EEPROM edit works. Bosch Mobility describes the modern engine control unit as the central node coordinating fuel, ignition, and emissions across dozens of sensors and actuators, and immobilizer authorization is one of the gates that node checks before it will keep the engine alive. On the ME7, that gate reads a handful of bytes out of the immo EEPROM. If those bytes say "locked and not matched," the ECU allows the engine to start on residual logic and then cuts fuel and injection within a second or two. Clear the right bytes, correct the checksum that protects them, and the gate stops slamming shut.

The immo EEPROM is a physically distinct part from the flash. It is one of a small number of standard SPI serial EEPROM chips: the 95040, the 95080 or 95P08, or the 95160. You read it, you edit it, and you write it back — the engine calibration in flash is never touched. That is why immo-off through the EEPROM is a targeted operation and not a full ECU reflash.

95040 vs 95080 vs 95160

Three chips cover essentially every ME7 immo EEPROM you will meet, and they differ only in capacity. The 95040 holds 512 bytes. The 95080 and its 95P08 variant hold 1024 bytes. The 95160 holds 2048 bytes. All three are SPI serial EEPROMs in small SOIC-8 packages, and all three are read and written the same way with a bench programmer.

The reason there is more than one chip is that different ME7 revisions and different immobilizer generations reserved different amounts of storage for immo data, adaptation values, and coding. A smaller 95040 does not mean a simpler car; it means a specific ECU hardware revision. Bosch Mobility's engine control unit overview makes the point that a modern ECU coordinates a large number of inputs and stored values, and on the ME7 that stored state is split between the calibration flash and this separate immo EEPROM — which is why the immo chip capacity varies independently of engine size or power. What matters for immo-off is not the raw size but where inside that space the active immo layout lives, and that location moves depending on the chip and the immobilizer generation.

Chip	Capacity	Typical package	Notes
95040	512 bytes	SOIC-8	Common on earlier ME7.5 immo boards
95080 / 95P08	1024 bytes	SOIC-8	Very common across ME7.1 and ME7.5
95160	2048 bytes	SOIC-8	Later revisions, more coding storage

The practical takeaway: before you do anything, identify which chip is on your board. The markings are printed on the top of the SOIC-8 package — look for 040, 080, P08, or 160 in the part number. Your programmer must be set to the matching chip type, because reading a 95160 as if it were a 95080 gives you a truncated, useless dump. Our online tool auto-detects the immo layout from the dump you upload, but you still have to give it a complete, correctly sized read of the correct chip. Garbage in, and the byte-verification step will simply refuse the file rather than hand you back something dangerous.

How the immo lock and layouts work

The VW Group immobilizer is a distributed system, not a single box. A transponder in the key talks to a reader coil, which talks to an immobilizer control unit (often integrated into the instrument cluster on these cars), which in turn talks to the engine ECU. Each of those components stores a shared secret and a set of status flags, and they cross-check each other every time you turn the key. The Ross-Tech immobilizer wiki on Immobilizer III ECU swapping documents in detail how tightly the ECU, cluster, and immobilizer data are bound together on exactly these platforms, and why a mismatched ECU will not run without either adaptation or an immo-off.

Inside the ME7 immo EEPROM, the status the ECU cares about is held in a specific region often called the immo "layout" or immo "round." Over the life of these systems, the byte arrangement was revised, so a given dump might have its active immo data in one of several possible offsets. That is what we mean by detecting which "round" is active: the tool reads your dump, works out which layout the ECU is actually using, and targets that region rather than blindly zeroing a fixed address. Blindly writing a fixed offset is exactly how people brick an immo EEPROM — they clear the wrong region on a layout that does not match their assumption, corrupt the checksum, and end up with an ECU in a worse state than a locked one.

There is also a checksum. The immo region is protected by a small checksum so the ECU can detect corruption. If you change the immo flags but leave the checksum stale, the ECU sees a mismatch and can throw immo faults or refuse the data outright. A correct immo-off does two things in the same pass: it clears the immo flags for the detected layout, and it recomputes the checksum so the edited region is internally consistent. Do one without the other and you have not finished the job.

Reading and writing the EEPROM

You need a chip programmer or bench tool that can read and write SPI serial EEPROMs — the same class of tool used for reading a 95040, 95080, or 95160 in-circuit or off the board. The workflow is the same regardless of which of the three chips you have.

First, get the ECU out and open, and locate the immo EEPROM. Second, read the chip with your programmer, set to the correct chip type, and save the dump as a binary file. Read it at least twice and confirm the two reads are identical; a flaky solder joint or a dirty clip can give you a corrupt read, and you never want to base an edit on a bad read. Third, that verified dump is what you upload to the online tool. The tool detects the layout, clears the immo flags, fixes the checksum, and returns a finished binary. Fourth, you write that returned file back to the same chip and verify the write.

The verify step on write-back is not optional. Reading back the chip after writing and comparing it byte-for-byte to the file you intended to write is the only way to know the write actually took. This discipline mirrors how professional automotive diagnostic and programming protocols are specified: ISO 14229, the Unified Diagnostic Services standard, builds read-and-verify semantics into the way ECUs are meant to be accessed, precisely because a partial or corrupted memory operation on a control unit is a serious fault. You are working below the diagnostic layer here, directly on the chip, so the same principle applies with even less margin for error: verify every read and every write.

If you are not comfortable pulling the ECU, identifying the chip, and soldering or clipping onto a SOIC-8 package, that is a legitimate reason to choose the mail-in route instead of the file service. The online tool assumes you can produce a clean dump. If you cannot, sending us the ECU is the honest answer, and we would rather tell you that up front than sell you a file you cannot use.

Byte-verification and why we refuse to guess

Here is the part that separates a safe service from a reckless one. When your dump arrives, the tool does not immediately start editing. It first identifies the chip size and the active immo layout, then byte-verifies that what it is looking at is a layout it can process cleanly. Only when that check passes does it clear the flags and rewrite the checksum. If the layout is not one we can process cleanly — an unusual revision, a partial read, a dump from something that is not actually a ME7 immo EEPROM — nothing is written, you are not charged, and we route you to the mail-in service instead.

We never guess. A bad EEPROM write does not produce a harmless error; it produces immo faults, and in the worst case an ECU that will not accept correct data afterward. The stakes are the same ones that make immobilizers effective anti-theft devices in the first place. The Insurance Institute for Highway Safety reported that a software anti-theft update cut theft claim frequency sharply for the vehicles that received it, roughly halving the affected theft rate in their analysis — a concrete reminder that the immobilizer logic you are editing is real security hardware, not a nuisance flag. Treat it with that level of care, and the honest failure mode is "we refused and did not charge you," never "we guessed and bricked it."

That refusal path is the point. It is easy to build a tool that always returns a file. It is harder, and far more useful, to build one that returns a file only when it is sure, and otherwise says no. The refusal is free, it is automatic, and it is what keeps the byte-verified promise from being marketing.

Start-then-stall vs no-crank

Immo-off fixes one specific symptom, and it is important to know whether you actually have that symptom before you spend anything. An active immobilizer lets the starter crank and the engine catch, then cuts fuel and injection so the engine stalls within one to two seconds. Crank, fire, die. If you turn the key and the engine starts and immediately stalls, over and over, an immo mismatch is a leading suspect — especially right after an ECU swap.

A no-crank is a different animal. If the starter does not turn the engine at all, you are looking at a dead battery, a bad starter, an ignition switch, a neutral safety or clutch switch, or a wiring fault — not the immobilizer. Immo-off will do nothing for a no-crank, because the immobilizer sits downstream of cranking. The engine has to be able to turn and catch before the immo cut can even express itself. The Ross-Tech immobilizer documentation is a good place to confirm the behavior for these specific platforms before you commit, because it walks through how the ECU and immobilizer interact during a start attempt.

So before you pull the ECU: confirm you have a start-then-stall, not a no-crank. Confirm the stall is immo-related and not, say, a fuel pump or crank sensor that lets the engine catch on residual pressure and then quit. Immo-off is the right tool for the immobilizer problem and only that problem. Buying it to chase a no-crank is money spent on the wrong fault.

Price and alternatives

The online file service is $150, and the finished file comes back in seconds once byte-verification passes. You upload your dump, the tool detects the layout and clears the immo flags and fixes the checksum in one pass, you pay only if it verified cleanly, and you download the ready-to-write binary. If it cannot verify your layout, you are not charged and you go to mail-in.

That in-seconds turnaround is only possible because these cars are, in electronics terms, simple and well-understood. Newer vehicles are a different world. McKinsey's analysis of automotive software and electronics architecture describes electronics and software growing to roughly a third of total vehicle content and heading toward an even larger share as software-defined architectures take over — tens of interconnected control units and hundreds of millions of lines of code. A twenty-year-old ME7 with its immobilizer state sitting in a 512-to-2048-byte serial EEPROM is the opposite end of that curve, which is exactly why a clean, bounded, byte-verifiable operation is possible at all.

Here is how the options compare:

Option	Price	Turnaround	Requires	Best for
Online file service	$150	Seconds after verify	Your own chip programmer and a clean dump	DIYers with bench tools
Mail-in service	Varies	Ship time plus bench time	Sending us the ECU	No programmer, or unusual layout
DIY hex editing	"Free"	Hours plus risk	Deep knowledge, high risk	Not recommended

DIY hex editing is in that table only to be honest about it. People do it, and people brick chips doing it, because they guess at the layout or forget the checksum. The $150 service exists to take the guessing out. The mail-in fallback on the Bosch ME7 EEPROM immo-off service page exists for when you do not have a programmer or your layout is not one the tool can process cleanly.

What experts say

The professionals who do this work for a living converge on the same discipline: identify before you edit, and verify after you write. It is the same read-and-verify rigor that ISO 14229, the Unified Diagnostic Services standard, formalizes for higher-level ECU access, applied one layer down at the raw chip.

On these VW Group cars the failure is almost never the concept of immo-off — it is someone who cleared a fixed offset without checking which layout the ECU was actually running, then wrote it back without fixing the checksum. Detect the layout, correct the checksum in the same pass, verify the write byte for byte, and it is boring and repeatable. Skip a step and you make a locked ECU into a dead one.

— Master automotive locksmith, 15+ years on the bench (anonymized)

That is the entire philosophy of a byte-verified service in three sentences. The layout detection is not a convenience; it is the safety mechanism. The checksum fix is not a nicety; it is what makes the edit valid. And the refusal to return a file when the layout does not verify is not a limitation; it is the feature that keeps a bad write from ever happening.

Frequently asked questions

Do I need a chip programmer to use the online service?

Yes. The online file service works on the dump you provide, so you need a bench tool that can read and write SPI serial EEPROMs — 95040, 95080/95P08, or 95160 — and you need to be comfortable pulling and opening the ECU and reading the correct chip. If you do not have that, use the mail-in Bosch ME7 EEPROM service instead and send us the ECU.

Will this work on my specific car?

It covers VW, Audi, SEAT, and Skoda from roughly 1998 to 2006 running Bosch ME7.1, ME7.1.1, or ME7.5 — MK4 and early MK5, B5 and B6, with 1.8T, 2.0, VR6, 2.8 V6, and 2.7TT engines. The only real test is the dump itself: upload it, and byte-verification tells you whether your exact layout can be processed. If it cannot, you are not charged and you go to mail-in. You can also check your platform on the calculators page first.

What happens if the tool cannot read my layout?

Nothing gets written and you pay nothing. If your dump is an unusual revision, a partial or corrupt read, or not actually a ME7 immo EEPROM, byte-verification fails, the tool refuses to return a file, and you are routed to the mail-in service. We never return a guessed file, because a bad write causes immo faults.

Is immo-off legal?

Immo-off is a repair and build tool for lawful vehicle owners — swaps, standalone and off-road, motorsport, and repair. It is not for defeating emissions controls, which the United States Environmental Protection Agency treats as a violation, and it is not for starting a vehicle you do not own, which is the exact scenario the National Highway Traffic Safety Administration theft-prevention work targets. Ownership and lawful purpose are on you. Full details on the process are on the how-it-works page.

My car cranks but will not start at all — will this fix it?

Only if your symptom is start-then-stall: the engine catches and then dies within a second or two. Immo-off does nothing for a true no-crank, where the starter will not turn the engine, because that is a battery, starter, switch, or wiring fault upstream of the immobilizer. Confirm you have a start-then-stall before you buy.

Does immo-off change my engine tune?

No. The immobilizer state lives in a separate serial EEPROM, not in the engine calibration flash. Clearing the immo flags and fixing the immo checksum leaves your fueling, ignition, and boost maps untouched. It is a targeted edit to the immo region only.

The bottom line

If you own a 1.8T-era VW, Audi, SEAT, or Skoda, you have a start-then-stall rather than a no-crank, and you already have a chip programmer and a clean read of the immo EEPROM, the online service turns immo-off into a two-minute job: upload, byte-verify, pay $150, download the finished file in seconds, write it back, and verify. The tool detects your immo layout, clears the flags, and fixes the checksum in one pass, and if your layout does not verify cleanly it refuses, charges you nothing, and sends you to mail-in.

Start with the details on the how-it-works page so you understand the read-verify-write discipline, confirm your platform and chip on the calculators page, and when you are ready, run the file through the Bosch ME7 EEPROM immo-off service. If you want to know who is behind the tool and the byte-verified promise, read about founder Adrian Torres. Honest failure modes, no guessing, and a file that is ready to write — that is the whole offer.