Mercedes EZS / EIS Cloning: Exactly What Data Transfers — and the Six Reasons Clones Fail

Who this is for

• Your Mercedes EIS/EZS has failed and someone has told you it can be "cloned" — and you want to know what that actually means before you ship anything
• You bought a used EZS on the assumption it would plug in, and the car will not crank, will not recognise the key, or throws a steering-lock fault
• You are a shop or locksmith who has had a clone come back and you want a checklist of what really goes wrong
• You are trying to work out whether you need a clone, a key, a repair, or a completely different service
• You want the naming sorted out once: EZS, EIS, ELV, ESL, DAS, FBS — which is which

The short version: cloning an EZS/EIS is a data operation, not a parts swap. It succeeds or fails on whether every byte of a specific identity data set can be read cleanly, verified, and written into a compatible donor. Everything below is that data set, and the failure modes that live around it.

EZS, EIS, ELV, ESL, DAS, FBS — decoding the names first

Half the confusion in this subject is vocabulary, and it costs people real money because they buy the wrong part.

EZS is the German name: Elektronisches Zuendschloss — literally "electronic ignition lock." EIS is the same module under its US-facing name: Electronic Ignition Switch. They are not two parts, two revisions, or two systems. EZS and EIS are the identical module. If a seller lists an "EZS module" and your workshop manual says EIS, you are looking at the same casting, the same connector, and the same board. This article uses EZS/EIS interchangeably on purpose, because the parts market does.

ELV / ESL is a different module entirely: Elektrische Lenkradverriegelung / Electronic Steering Lock. It is the motorised bolt that locks and releases the steering column, and it lives in the column, not in the dash. It talks to the EZS and is paired to it, which is why a botched EZS job so often shows up as a steering-lock complaint rather than an ignition complaint. When the ELV motor or gear fails, that is its own bench job — see ELV emulator programming at $350.

DAS is Drive Authorization System — the whole scheme, not a box. DAS is the name for the cooperative arrangement in which the key, the EZS, the engine ECU, the transmission controller and (on later cars) the ESL all have to agree before the engine will start and stay running. When a technician says "the DAS is not authorising," they mean that agreement broke down somewhere, and the EZS is only one of the possible places.

FBS is Fahrberechtigungssystem — the generation label for the drive-authorisation implementations. FBS3 covers the long middle era of Mercedes immobilizer design; FBS4 is the later architecture used from roughly the mid-2010s, and it behaves very differently at the data level. That generational split is the single most important compatibility question in this whole subject, and it has its own detailed treatment in our guide on pre-2014 vs post-2014 FBS4 EIS and the companion piece on FBS4 DSM and ISM cloning.

Get these five terms straight and most of the bad advice on the internet sorts itself out.

What actually lives inside an EZS/EIS

An EZS is not "the ignition switch" in the mechanical sense. It is a small networked computer with non-volatile memory, and the value of the module is entirely in what that memory holds. Here is the data set, item by item.

1. The vehicle and immobilizer identity block

This is the module's sense of which car it belongs to. It is not a single field — it is a structured block that other control units read during the wake-up handshake. Every module on the drive-authorisation chain keeps a copy of, or a derivation from, this identity, which is precisely why replacing an EZS with a virgin or foreign unit does not work: the ECU and the transmission controller are still expecting the old identity and will refuse an unfamiliar one.

2. The key learning table and per-key status bits

The EZS holds a table of the keys the car has learned. Each entry is not a simple yes/no. Each key has status bits attached — enabled, disabled, erased, position in the table — and those bits are why a car can "see" a key and still refuse it. A key that has been disabled at the table level presents itself perfectly and gets rejected every time. When a clone appears to work but one of the customer's two keys does not, the status bits in the table are the first place to look, not the key itself.

3. The shared secret used in the rolling-code challenge

This is the heart of the whole system and the reason immobilizers work. The EZS, the keys and the engine control unit share a secret value. On every ignition cycle the modules run a challenge-and-response exchange based on that secret, combined with a counter that advances each time. The key does not send a fixed password; it sends the correct answer to a question that is different every time. Rolling-code and challenge-response schemes of this kind are standard practice in vehicle security engineering, and the underlying methods are documented across the technical literature published by SAE International.

Two consequences follow, and they explain most clone failures:

• If the secret does not transfer intact, nothing else matters — keys, ECU and EZS will never agree.
• If the secret transfers but the counter is left out of step, the modules hold the right secret and still reject each other, because the answers land outside the acceptance window.

4. The VIN

The VIN is stored, and it is read. It is also the field most likely to be checked by an external tool and reported to a technician, which is why a mismatched VIN in a donor is often the first symptom anyone notices. On its own the VIN is not the thing that authorises the start — but a VIN that does not match what the rest of the car expects is a reliable sign that the identity block underneath it did not transfer properly either.

5. ESL/ELV and transmission pairing data

Later cars pair the EZS to the electronic steering lock and to the transmission controller. That pairing is stored data, not a physical arrangement. Clone the EZS without carrying the pairing across — or drop a cloned EZS into a car whose ESL is still married to the original module — and you get the classic symptom set: dash lights, no crank, steering column locked or refusing to release, and a stored fault pointing at the steering lock rather than at the module you actually changed.

6. The stored mileage value the cluster cross-checks

Mercedes stores mileage in more than one control unit and cross-checks the copies. The EZS carries one of them. If a cloned module presents a mileage value that disagrees with the cluster, the car can flag a discrepancy — which is both a real diagnostic tool and a legal boundary. Mileage data is transferred to reflect the vehicle's true mileage only. Rolling an odometer back to a false reading is a federal offence under 49 U.S.C. Chapter 327, and NHTSA has estimated that odometer fraud costs American consumers more than $1 billion a year — which is why no legitimate bench shop will do it, at any price.

Why clones fail — the six real causes

A clone is a copy operation. Copies fail for copy reasons. Here they are, in the order we actually see them.

1. The source EEPROM is unreadable or partially corrupted

This is by far the most common cause, and it is the reason we always try to read the customer's original module first. A source that reads with bad bytes, an incomplete dump, or an inconsistent checksum will produce a clone that looks finished and behaves like a stranger. Partial corruption is worse than total failure, because a totally dead read announces itself immediately, while a dump with a handful of flipped bits in the identity block writes cleanly and then does not start the car.

The professional discipline here is simple and non-negotiable: read, verify the read against a second read, and only then write. A checksum-verified read matters more than a perfect write, because a perfect write of bad data is still bad data.

2. The donor is the wrong FBS generation or hardware revision

An FBS3-era module and an FBS4-era module are not interchangeable in either direction. Neither are certain hardware revisions within a generation, even where the housing and connector are identical. A visually correct donor with a different board revision, a different memory device, or a different bootloader will accept the physical work and reject the data. This is why donor selection is a verification step, not a shopping step, and why part-number matching by picture is not good enough.

3. The keys were never re-synchronised

The secret transferred; the counter did not. The car sees a key it recognises, computes the expected response, receives an answer that is mathematically correct but out of range, and refuses. The customer describes it as "it reads the key but won't start" — which is exactly right and exactly the fingerprint of a counter problem rather than a data problem.

4. The ESL/ELV is still paired to the old module

The cloned EZS is fine. The steering lock is not, because it is still holding a relationship with the module that got replaced. The result is a car with a live dash, no crank, and a steering-lock fault. On some cars the correct answer is to address the pairing; on cars with a failed lock motor, the correct answer is a different service altogether.

5. The cluster or engine ECU rejects the identity

Because drive authorisation is a chain, any link can veto the start. A clone that is internally perfect can still be refused by an engine ECU or cluster that holds a stored identity from the original module and does not accept what it is now hearing. This is the case that most often gets misdiagnosed as "the clone failed," when what actually happened is that a second module needs attention.

6. Physically damaged solder joints on the source board

The last one is not a software problem at all. EZS boards suffer cracked joints, corroded pads and heat-fatigued connections, especially on the W164, X164 and W251 chassis where the module sits in a punishing thermal environment. A board with an intermittent joint may read differently on two consecutive attempts — which is exactly why we read twice. When the board itself is the problem, the fix is a repair rather than a clone: see Mercedes W164 / X164 / W251 EIS repair at $399.

On a bad EZS I will read it three times before I touch a donor. If the three dumps do not agree byte for byte, that module is telling me something — usually that a joint is cracked or the memory is on its way out. People rush the read because the write is the exciting part, and then they blame the donor.

— Independent European driveability technician, 18+ years on Mercedes drive-authorisation systems (anonymized)

Clone, key, repair, or emulator — which service you actually need

	EIS cloning	EIS key programming	W164/X164/W251 EIS repair	ELV emulator programming
Core problem	Module dead or being replaced; identity must move	Module healthy; car needs a key added or all keys lost	Module has a board-level fault (joints, pads, memory)	Steering lock motor/gear failed
What moves	Full identity data set onto a donor	A key learned into the existing table	Nothing — the original module is fixed	Steering-lock function replaced by emulator
Keys kept	Existing keys keep working when the clone is clean	Existing keys unaffected	Existing keys unaffected	Not a key job
Donor needed	Yes — verified compatible	No	No	Emulator hardware
Price	$250	$150	$399	$350

If you are stuck between the first two columns, the dedicated comparison in EIS cloning vs key programming walks the decision in more detail, and the all-keys-lost scenario has its own cost breakdown in our Mercedes all-keys-lost EIS guide.

The bench discipline: read, verify, then write

The reason this work belongs on a bench rather than in a driveway is not mystique. It is power, repeatability and the ability to stop.

1. Intake and verification. VIN, chassis, year, the module's part number from the label, and a description of the symptom. Generation and donor compatibility get confirmed before anything is written.
2. Powered read on a regulated supply. The module is powered from a bench supply that does not sag, brown out, or drop mid-operation. A voltage dip during a memory operation is one of the classic ways a marginal module becomes a dead one.
3. Read twice, compare. Two independent dumps are compared byte for byte. Disagreement means a hardware problem on the source board — and that changes the job from a clone to a repair, before any donor is committed.
4. Checksum and structure verification. The identity block, the key table and the secret are checked for structural sanity, not just for a successful read return code.
5. Donor preparation and write. The verified data set is written to the compatible donor.
6. Read-back verification. The donor is read back and compared to the source. This is the step that separates a finished job from a hopeful one.
7. Return with tracking. The module ships back on the flat-rate return tier you chose at checkout, from $24.95.

Steps 3 and 6 are the ones amateurs skip, and they are the two steps that decide whether the car starts.

Proof of ownership, and why it is not optional

EZS/EIS work is immobilizer work, which means it is security work. Proof of ownership is required — title, registration, or equivalent documentation tying the vehicle to the person requesting the service, and for shops, the corresponding customer paperwork.

This is not paperwork for its own sake. Vehicle theft remains a large-scale property crime: the National Insurance Crime Bureau has tracked roughly a million motor-vehicle thefts a year in recent reporting, and motor-vehicle theft consistently ranks among the largest property-crime categories in the FBI's national crime statistics. A shop that programs immobilizer data without verifying ownership is a shop that will eventually be used. We would rather ask an honest customer for a document than become somebody's tool.

The same logic runs through the manufacturer side. Mercedes-Benz USA treats drive-authorisation components as security-relevant parts with controlled ordering and identity requirements, and the aftermarket has followed with equivalent verification expectations.

Cost and decision framing

Mail-in bench cloning is priced flat because the work is defined: EIS cloning is $250 and EIS key programming is $150, each plus the flat-rate return shipping tier you select at checkout, from $24.95. Board-level repair on the W164 family is $399; ELV emulator work is $350.

Set that against context. Dealer-level drive-authorisation work on a European car is quoted in four figures often enough that owners abandon otherwise sound vehicles over it — and the average vehicle on American roads is now well over a decade old, a trend documented repeatedly by Consumer Reports and reflected in the long-term dependability tracking published by J.D. Power, whose industry studies routinely report problem counts on the order of two hundred per hundred vehicles at the three-year mark. Older cars mean more electronic modules aging out of service, and more owners who need a repair path that is not "replace it at list price."

The honest decision rule:

• Original module reads cleanly and you want to keep your keys — clone it.
• Original module is physically damaged but repairable — repair it, do not clone it.
• Module is fine and you just need keys — key programming, not cloning.
• Complaint is really the steering lock — that is the ELV path, not the EZS path.

Frequently asked questions

Is EZS the same thing as EIS? Yes — identical module, two names. EZS is the German abbreviation for Elektronisches Zuendschloss and EIS is the US-facing Electronic Ignition Switch. Parts listings use both interchangeably, so match on part number and chassis rather than on the acronym in the advert.

Will my existing keys still work after the EZS is cloned? When the clone is clean, yes — that is the entire point of cloning rather than replacing. The key learning table, the per-key status bits and the shared secret all move to the donor, so the keys the car already knows remain valid and no new keys need cutting or learning.

Why does my cloned module read the key but still refuse to start? That pattern almost always means the rolling counter is out of synchronisation rather than the data being wrong. The key and module hold the correct shared secret, but the counter values sit outside the acceptance window, so a mathematically valid response is rejected on every attempt.

Can any used EZS be used as a donor? No. The donor has to match the FBS generation and the hardware revision, not just the physical housing and connector. A visually identical module from the wrong generation or a different board revision will accept the physical work, reject the data, and waste both the part and the shipping.

Does cloning change my odometer reading? The stored mileage value transfers so the module agrees with the rest of the car, reflecting the vehicle's true mileage only. Correcting an odometer to a false reading is a federal offence under 49 U.S.C. Chapter 327 and is never performed here at any price.

What if the original module cannot be read at all? Then cloning is off the table and the job changes. Depending on the chassis and the failure, the path is either a board-level repair to recover the module, or a different drive-authorisation route entirely — which is why we verify the read before committing a donor rather than after.

Do you need proof of ownership? Yes, always. EZS/EIS work is immobilizer and security work, so documentation tying the vehicle to the requester — title, registration, or the equivalent shop paperwork — is required before any programming is performed.

The bottom line

EZS and EIS are the same module under two names, and cloning it is a data operation with a very specific payload: the vehicle and immobilizer identity block, the key learning table and its status bits, the shared secret behind the rolling-code challenge, the VIN, the ESL and transmission pairing data, and the stored mileage the cluster cross-checks. Get all of that across intact and the car keeps its keys and its relationships. Miss any of it and you get one of six predictable failures — a corrupted source read, a mismatched donor generation or revision, an unsynchronised counter, a steering lock still married to the old module, a cluster or ECU that vetoes the new identity, or a cracked joint on a board that was never healthy enough to read in the first place.

Which is why the bench order matters more than the tooling: read, read again, verify, then write, then read back. EIS cloning is $250, key programming is $150, W164/X164/W251 repair is $399 and ELV emulator work is $350, each plus the return shipping tier you pick at checkout from $24.95. Ship USPS to PO Box 120241, Arlington TX 76012, or UPS/FedEx to 1009 Oakwood Ln # 120241, Arlington TX 76012 — couriers cannot deliver to a PO Box. Proof of ownership is required. Message us with your VIN, chassis and a photo of the module label and we will confirm the generation and the donor requirement before anything ships.