Cyber

Training

I2C security: what an attacker reads on two wires

By Arnaud

July 9, 2026

5 min read

Sniffing an I2C bus with a logic analyzer on the DVID board

Two traces on a printed circuit board, SDA and SCL. That is all a microcontroller needs to talk to a display, a sensor, a memory or a security component. It is also all an attacker needs to follow the conversation.

I2C is the protocol our customers most often ask about in training. The reason is simple: it is present on almost every electronic board, and almost nobody considers it an attack surface.

I2C in two minutes

I2C (Inter-Integrated Circuit) is a serial bus invented in the 1980s to connect components on the same board.

Two lines: SDA for data, SCL for the clock, held high by pull-up resistors.
A controller and peripherals: the controller (often the microcontroller) initiates every exchange. Each peripheral responds to an address, most often on 7 bits.
Modest data rates: 100 kHz in standard mode, 400 kHz in fast mode, sometimes more.

What the protocol does not provide matters as much as what it does. No encryption. No authentication. No integrity check. Every component connected to the bus sees every exchange, and any component can write to it.

This is not a design flaw. I2C was designed for a world where the circuit board was a trusted zone. The problem starts when a product is sold, and therefore in anyone’s hands.

Capturing I2C exchanges with a logic analyzer

What an attacker does with an I2C bus

1. Listen

A logic analyzer costing a few dozen euros, two clips on SDA and SCL, open-source decoding software. Within minutes, every frame is displayed in clear: address, direction of the exchange, bytes transmitted.

What regularly turns up in these captures:

configuration data read from a memory at boot
credentials or keys stored in an EEPROM
sensor readings before any processing
exchanges with a security component, when the session is not protected

The last case is the most instructive. A security component (TPM, secure element) protects a secret very well as long as it stays inside. If the microcontroller asks it for that secret and the answer travels in clear over the bus, the protection stops at the component’s pin. Researchers have shown several times that a disk encryption key could be recovered this way, simply by sniffing the bus connecting a TPM to the rest of the board.

2. Map

An address scan reveals every peripheral present. Some ranges are characteristic: a response between 0x50 and 0x57 almost always means an EEPROM. The part number printed on the package and the manufacturer’s datasheet do the rest.

3. Read directly

Once the memory is identified, the attacker no longer needs the microcontroller. They connect to the bus with their own adapter, act as the controller and read the entire content. This can often be done without desoldering the component.

4. Write and spoof

The bus is shared, so writing is possible too. Changing a parameter in an EEPROM (serial number, threshold, license option, debug mode flag) is a classic. More elaborate: answering in place of a sensor to feed false readings to the microcontroller.

5. Block

Holding a line low is enough to paralyze the whole bus. On a product that has not planned for this case, the firmware hangs waiting.

What this reveals about the design

Sniffing an I2C bus is rarely an end in itself. It is a step that feeds the rest of the analysis: the secret read from the EEPROM opens an API, the modified parameter re-enables a console, the captured key decrypts a firmware.

Three mistakes keep coming up in the products we see:

Treating external memory as a private space. Anything written to an EEPROM can be read by whoever owns the device.
Trusting data from the bus. A value read over I2C is not authenticated. It must be validated like any external input.
Adding a security component without protecting the link. Most of these components offer an encrypted or authenticated session with the microcontroller. It is often left disabled.

Protecting exchanges between a microcontroller and a security component

The countermeasures that matter

Never send a secret in clear over the bus. Use the security component’s protected session mechanisms when they exist.
Encrypt or authenticate sensitive content stored in EEPROM, with a key that is not in the same memory.
Enable write protection on memories that do not need to be modified in operation.
Validate any data received from a peripheral: bounds, consistency, response time.
Set a maximum timeout on exchanges so that a blocked bus does not freeze the product.
Make physical access harder on sensitive products: traces on inner layers, no test points on critical lines, tamper detection.

None of these measures makes sniffing impossible. They make sure that what is sniffed has no value.

On the regulatory side, these points fall directly under the confidentiality, integrity and attack surface reduction requirements of Annex I of the Cyber Resilience Act, which explicitly targets the product’s interfaces.

Practice it on the DVID board

The DVID board was designed to make these attacks visible. It features an I2C-driven OLED display, a dedicated component that simulates a third-party module or a TPM, and connectors that expose the bus for observation.

In our I2C trainings, participants:

locate the bus lines from the datasheet and the schematic
capture and decode the exchanges with a logic analyzer
identify the peripherals present and their role
recover sensitive information that should not have travelled in clear
derive the design rules to apply to their own product

The module requires no prior offensive security knowledge. A first experience with embedded systems is enough.

Who is it for?

firmware engineers and electronic board designers
pentesters getting started with hardware
product security managers preparing for CRA or IEC 62443-4-2 compliance
cybersecurity or embedded systems students