B2266 – The drive authorization data are implausible. An incorrect or incompatible configuration was detected. (Mercedes-Benz)

Mercedes-Benz-specific code — factory diagnostic data

Last updated: April 2, 2026

Definition source: Mercedes-Benz factory description · Autel MaxiSys Ultra & EV. Diagnostic guidance is based on factory-defined fault logic for this code.

B2266 means your Mercedes-Benz detected drive authorization data that does not make sense. In plain terms, the van may crank but not start, or it may refuse to start to protect against an incorrect key or control module mismatch. According to Mercedes-Benz factory diagnostic data, this code indicates “the drive authorization data are implausible” and an “incorrect or incompatible configuration was detected.” That points to a plausibility failure in the anti-theft/authorization handshake, not a single failed part. The fault often appears after module programming, battery issues, wiring faults, or network communication problems that corrupt or block authorization data.

🔍Decode any Mercedes-Benz Sprinter 907 VIN — free recalls, specs & safety ratings — free VIN decoder with NHTSA data

B2266 Quick Answer

B2266 sets when Mercedes-Benz drive authorization information fails a plausibility check. The vehicle may deny starting because the involved modules do not agree on valid authorization data or configuration.

What Does B2266 Mean?

Official meaning (Mercedes-Benz): “The drive authorization data are implausible. An incorrect or incompatible configuration was detected.” In practice, the vehicle sees a mismatch in the data used to permit starting. The system responds by limiting or denying drive enable. This protects the vehicle when modules, keys, or stored configuration do not align.

What the module actually checks: the drive authorization system compares identification and security-related data between modules over the vehicle network. The module also checks whether coded configuration and learned values match what the vehicle expects. Why it matters: the DTC message does not prove a bad module or key. It only identifies a suspected trouble area, per SAE J2012-DA guidance. You must confirm whether the mismatch comes from network integrity, power/ground stability, incorrect coding, or an actual security component fault.

Theory of Operation

On Mercedes-Benz vehicles, “drive authorization” links the key (or fob), the immobilizer functions, and engine start enable. Several control units exchange coded data and status messages before the engine control system allows fueling and cranking authorization. The system expects consistent identifiers, correct configuration, and valid rolling or synchronized security information.

B2266 sets when that exchange fails a plausibility check. The failure can come from incorrect programming, a control unit swapped without proper teach-in, or corrupted data during a low-voltage event. Network issues can also break the handshake. A missing message, altered data bytes, or wrong configuration can look “implausible” even when parts still work.

Symptoms

You will usually notice starting authorization problems first, then warning messages and scan-tool clues.

• No-start Engine cranks but will not start, or the starter does not engage.
• Start denied message Cluster message such as “Start Error” or a drive authorization warning may appear.
• Intermittent start Vehicle starts sometimes, then refuses on the next key cycle.
• Key recognition Remote/key detection acts inconsistent, especially after battery disconnects.
• Reduced functions Certain body functions may disable because authorization stays incomplete.
• Multiple DTCs Related security, network, or configuration codes may store in other modules.
• Post-repair event The symptom starts after module replacement, programming, or coding work.

Common Causes

• Incorrect module coding or variant configuration: A mismatched configuration makes the drive authorization dataset fail plausibility checks during handshake.
• Control unit replacement without SCN/online coding completion: The system stores “default” or incomplete parameters, so the authorization data no longer matches the vehicle’s identity set.
• Variant mismatch between immobilizer-related modules: If one module expects a different dataset format, the authorization exchange becomes incompatible and sets B2266.
• Low system voltage during start or coding event: Voltage sag can corrupt write operations or interrupt authorization messaging, creating implausible stored values.
• High-resistance power or ground to an authorization-related module: A weak feed or ground causes resets and partial communication that the logic interprets as implausible data.
• Connector pin fit, corrosion, or water intrusion: Increased resistance or intermittent opens distort authorization data transfer and trigger a plausibility fault.
• CAN network integrity issue on the body/drive authorization bus: Noise, poor shielding, or intermittent open/short conditions can alter or delay messages until the data fails plausibility.
• Aftermarket device affecting ignition/immobilizer circuits: Remote start, alarm, or tracker wiring can change message timing or circuit states and break authorization plausibility.
• Software level incompatibility between modules: A module with an out-of-family software version may use different validation rules and reject otherwise valid authorization data.

Diagnosis Steps

Use a Mercedes-capable scan tool that supports full vehicle network scans, coding status, and guided tests. You also need a DVOM for voltage-drop testing, a headlamp-style test load, and basic back-probing tools. For intermittent issues, use the scan tool’s snapshot recording during a start attempt. Keep a battery maintainer connected during testing and any programming.

1. Confirm B2266 in a full vehicle scan and record DTC status. Save freeze frame data where available, focusing on battery voltage, ignition state, and start/drive authorization state at the moment the code set. Compare stored versus pending codes, since some faults store only after repeat detection.
2. Check power distribution first. Inspect relevant fuses, prefuse blocks, and body power feeds tied to drive authorization and immobilizer functions. Do a quick visual of the circuit path and grounds before any meter work, because water intrusion and loose terminals often create plausibility faults.
3. Verify battery condition and cranking voltage behavior. Load-test the battery and confirm the charging system does not under- or over-voltage. If the fault appears after a weak battery event, treat voltage instability as a prime suspect before chasing modules.
4. Perform voltage-drop tests on the suspected authorization-related module power and ground circuits under load. Use a commanded output or key-on state to load the circuit, then measure drop across power feed connections and across ground paths. Accept less than 0.1 V drop on grounds with the circuit operating, because continuity checks alone miss high resistance.
5. Run a network scan and note which modules report drive authorization or immobilizer-related faults. Look for accompanying CAN, configuration, “not coded,” or “control unit not authorized” messages. A cluster of related codes usually points to a shared power/ground, bus issue, or incomplete coding event.
6. Inspect connectors and harness sections tied to the suspected modules and bus backbone. Check for spread terminals, pin push-out, corrosion, and signs of moisture. Pay special attention to areas near the steering column, kick panels, under-seat modules, and firewall pass-throughs common on Sprinter layouts.
7. Check CAN physical integrity if other bus faults appear. With ignition ON, verify the bus remains stable and the module stays online during wiggle testing. Do not use ignition-OFF voltage readings as a reference for communication bias, since the network bias requires powered modules.
8. Use live data to evaluate authorization plausibility inputs. Watch key recognition/ESL/immobilizer status (names vary by platform), terminal status, and “drive enable” parameters during a start attempt. If the scan tool supports it, compare expected vs actual authorization state transitions.
9. Differentiate freeze frame versus a technician-triggered snapshot. Freeze frame shows the conditions when B2266 set. A snapshot recording during multiple start cycles helps catch a brief dropout, reset, or implausible transition that never appears in a static data view.
10. Check for recent module replacement, programming, or coding history. If a module shows “not configured” behavior, treat configuration integrity as the fault area, not the hardware. Verify coding/SCN status per Mercedes service information and confirm the vehicle identity data matches across participating modules.
11. After repairs, clear codes and repeat the same operating conditions that set the DTC. Confirm B2266 does not return as pending or stored. If the monitor behaves like a two-trip logic on your platform, complete two drive cycles and recheck readiness and stored DTCs.

Professional tip: Treat B2266 as a plausibility and configuration problem first, not a “bad module” verdict. On Mercedes platforms, a single weak ground or low-voltage event can create resets that look like incompatible authorization data. Prove power, ground, and network stability with voltage-drop and wiggle testing before you schedule programming or replace a control unit.

Possible Fixes

• Restore clean power and ground integrity: Repair high-resistance connections, loose fasteners, or damaged cables proven by voltage-drop testing under load.
• Repair connector or harness faults: Correct pin fit issues, remove corrosion, repair water intrusion damage, and restore proper shielding or routing on affected wiring.
• Correct network integrity issues: Repair CAN opens/shorts, poor splices, or noise sources verified during an ignition-on stability test and wiggle test.
• Complete required Mercedes coding/SCN programming: Perform the correct configuration steps after module replacement or software updates, using approved procedures and stable battery support.
• Remove or rewire aftermarket interference: Isolate remote start/alarm/tracker wiring that alters ignition or authorization circuits, then confirm normal authorization transitions.
• Update module software to matched levels: If service information calls for it, update participating modules so they share compatible validation logic and datasets.

Can I Still Drive With B2266?

You can often drive a Mercedes-Benz Sprinter 907 with B2266 stored, but you may not be able to restart it after a key-off event. This code flags implausible drive authorization data, so the vehicle may crank and not start, or it may show “Start Error” style messages depending on platform. If the engine runs normally right now, avoid cycling the ignition until you complete checks. Plan your route so you can park safely if the authorization fails. Treat any sudden no-start, immobilizer warning, or repeated key recognition issues as a tow situation, not a “keep trying” situation.

How Serious Is This Code?

B2266 ranges from an inconvenience to a hard no-start, because drive authorization controls whether the engine controller allows starting. When the code sets as history and the vehicle starts consistently, it mainly signals a configuration or plausibility mismatch that needs correction. Severity rises fast when the fault sets current and repeatable, because the Sprinter can deny start authorization without warning. This code rarely creates an on-road safety hazard like braking or steering loss, but it can strand the vehicle and disrupt fleet uptime. Treat intermittent starts, key recognition delays, or recent module work as high priority.

Common Misdiagnoses

Technicians often replace keys, the ignition switch, or an immobilizer antenna first, because the symptom “feels like” a key problem. B2266 does not prove a bad key. It points to implausible authorization data, which often ties to configuration, variant coding, or module synchronization. Another common miss involves ignoring the FTB suffix -56. In the SAE J2012DA FTB table, -56 commonly maps to “Not Configured,” so a module may lack valid personalization after programming. Shops also clear codes repeatedly, which wipes context and freezes the failure pattern. Verify power, ground, CAN integrity, and coding status before any parts decisions.

Most Likely Fix

The most frequent confirmed repair directions for B2266 involve restoring correct configuration and synchronization of the drive authorization path, not replacing hardware. On Sprinter platforms, that means verifying variant coding and performing the Mercedes-Benz drive authorization teach-in or SCN coding routine with the proper scan tool after a battery event or module replacement. The next most common direction targets basics that corrupt data plausibility. Correct low system voltage, poor grounds, or intermittent network faults that cause modules to disagree. Confirm the root cause with scan-tool data and wiring checks before you reprogram or replace any control unit.

Repair Costs

Repair cost depends on whether the confirmed root cause is wiring, connector condition, a sensor, a module, or the labor needed to diagnose the fault correctly.