MQB48 is the immobiliser platform used across modern VW, Audi, Seat and Skoda models. It sits behind both standard keyed ignitions and keyless KESSY systems, and it behaves differently depending on whether you’re doing a simple Add Key or a full All Keys Lost (AKL) procedure.
This guide breaks down:
Add Key vs AKL on MQB48
Automatic vs manual gearbox implications
Keyless KESSY vs standard keyed systems
What needs to be read in each scenario
What data is actually used (CS, IMMO, sync, key authorization)
Risk levels and typical failure patterns
1. MQB48 Architecture – What’s Actually Involved
MQB48 immobiliser systems typically involve:
BCM2 / BCM (Body Control Module) – core immobiliser brain
Instrument cluster – stores IMMO data and sync information
Engine ECU – stores CS/ISN and participates in authorisation
KESSY module (keyless cars only) – handles proximity and start authorisation
Key transponder / remote – stores key ID and cryptographic data
The exact combination depends on:
Automatic vs manual gearbox
Keyless KESSY vs standard keyed ignition
Brand (VW, Audi, Seat, Skoda) and model year
2. Add Key vs All Keys Lost – Core Differences
Add Key (MQB48)
At least one working key is present
System already has valid CS, IMMO and sync data
You typically read BCM2/BCM and cluster partially
Key is added into an existing authorization structure
Risk is relatively low if voltage is stable
All Keys Lost (AKL)
No valid key available
System must be rebuilt from EEPROM/flash data
You usually need full BCM2/BCM, full cluster, and sometimes ECU
CS, IMMO, sync and key authorization must be reconstructed
Risk is high: corruption or mis‑writes can lock BCM2 or cluster
3. Automatic vs Manual Gearbox – Why It Matters
MQB48 immobiliser logic is similar between automatic and manual, but there are subtle differences:
Automatic gearbox:
Often tied into start authorization (e.g. selector in P/N)
Some models store additional start‑condition flags in BCM/ECU
Faults can present as “no crank” even when immobiliser is technically OK
Manual gearbox:
Clutch switch and start authorization are simpler
Fewer conditions to satisfy for crank
Immobiliser faults more clearly show as “start blocked”
From a key programming perspective:
The data you read (BCM2, cluster, ECU) is broadly the same
But diagnostic symptoms differ: auto cars can look like immobiliser faults when they’re actually gearbox/start‑condition issues.
4. Keyless KESSY vs Standard Keyed Systems
Standard Keyed MQB48
Physical key in ignition or key barrel
Transponder is read via coil
BCM2 + cluster + ECU handle immobiliser logic
No proximity or comfort access logic
Add Key and AKL focus on CS/IMMO/sync only
Keyless KESSY MQB48
Proximity key (smart key)
KESSY module handles:
Key presence
Start button authorization
Comfort access (door handle unlock)
BCM2 + cluster + ECU still handle immobiliser, but KESSY adds:
Extra key authorization layers
Additional sync and rolling code logic
From a programming standpoint:
Keyless systems often require more complete reads and more careful handling of key authorization blocks.
AKL on KESSY cars is significantly higher risk than on standard keyed systems.
5. MQB48 Add Key – Technical Workflow
Typical Add Key Steps (Standard Keyed)
Confirm at least one working key
Read BCM2/BCM partial
Read cluster partial
Extract CS, IMMO and sync data
Generate new key data
Write new key authorization into BCM2/BCM
Test start and remote functions
Typical Add Key Steps (Keyless KESSY)
Confirm at least one working smart key
Read BCM2/BCM partial
Read cluster partial
Read KESSY key authorization area (depending on system)
Extract CS, IMMO, sync and key authorization data
Generate new smart key data
Write key authorization back into BCM2/KESSY
Test proximity, start button and comfort access
6. MQB48 AKL – Technical Workflow
AKL (Standard Keyed)
Remove and bench‑read BCM2/BCM full
Read cluster full
Read ECU if required (some variants)
Extract full CS, IMMO, sync and key authorization data
Generate new key set from EEPROM/flash
Write reconstructed data back to BCM2/BCM and cluster
Adapt keys and test start
AKL (Keyless KESSY)
Bench‑read BCM2/BCM full
Read cluster full
Read ECU (often required)
Read KESSY module if separate
Extract CS, IMMO, sync, key authorization and rolling codes
Rebuild key set and authorization structure
Write data back carefully to avoid lockout
Test proximity, start button and comfort access
7. Data Types – CS, IMMO, Sync, Key Authorisation
Data Type | Purpose | Where Stored (Typical MQB48) |
|---|---|---|
CS (Component Security) | Core immobiliser identity | BCM2/BCM, ECU |
IMMO Data | Vehicle immobiliser identity | Cluster, BCM2/BCM |
Sync Bytes | Key authorisation sync between modules | BCM2/BCM, cluster |
Key Authorization | Which keys are valid and how they’re used | BCM2/BCM, KESSY (keyless systems) |
Add Key uses existing CS/IMMO/sync and appends new key authorisation.
AKL rebuilds CS/IMMO/sync and key authorisation from EEPROM/flash.
8. Risk Levels & Failure Patterns
Scenario | Risk Level | Typical Failure Pattern |
|---|---|---|
Add Key – Standard Keyed | Low | Mis‑written key slot, occasional sync issues |
Add Key – Keyless KESSY | Medium | Proximity works but start fails, comfort access issues |
AKL – Standard Keyed | High | BCM2/cluster corruption, CS mismatch |
AKL – Keyless KESSY | Very High | KESSY lockout, rolling code issues, full no‑start |
Common pitfalls:
Unstable voltage during bench reads
Partial reads used where full reads are required
Writing mismatched CS/IMMO between BCM2, cluster and ECU
Ignoring KESSY authorisation blocks on keyless cars
If you’re stuck on MQB48 Add Key or AKL, especially on keyless KESSY cars, MCC Wolverhampton can assist with BCM2/BCM bench reads, IMMO data extraction and safe key programming.
MQB48 Key Programming & AKL Help
