Debug Interfaces (JTAG, SWD, UART)
JTAG, SWD and UART are the debug and console interfaces on nearly every board. What they give an attacker, how they should be locked, and what we find in device tests.
Updated This page as Markdown
In short
Debug interfaces are the hardware ports engineers use to program, debug and observe a microcontroller or SoC: JTAG (IEEE 1149.1), Arm SWD, vendor-specific ports such as Infineon DAP, and the UART serial console. Left open in a shipped product, they give full access to memory, registers and often a root shell. Locking them is a basic requirement of ETSI EN 303 645 and a standard item in every hardware penetration test.
What are debug interfaces?
Debug interfaces are the ports a chip exposes so that developers and the factory can program it, step through code and read its state. The common ones:
- JTAG (IEEE 1149.1) is a four- or five-wire test access port (TCK, TMS, TDI, TDO, optional TRST) that was designed for boundary-scan testing and is used by every major CPU family for debugging and flashing.
- SWD (Serial Wire Debug) is Arm’s two-wire variant (SWDIO, SWCLK) used on Cortex-M and many Cortex-A devices, defined in the Arm Debug Interface specification.
- Vendor ports such as Infineon’s DAP on AURIX, Renesas’ debug interfaces or the ESP32’s JTAG over USB serve the same purpose.
- UART is not a debug interface in the strict sense but a serial console. On embedded Linux devices it typically shows the boot loader prompt and a login or root shell; on microcontrollers it often carries a command interpreter or firmware update protocol.
Through a debug interface an attacker has what the developer had: full read and write access to memory and peripherals, control of execution, and the ability to flash new code.
Where is it defined?
JTAG is standardised in IEEE 1149.1; the Arm debug architecture in the ADIv5 and ADIv6 specifications, together with the CoreSight documentation. Protection mechanisms are vendor-specific: readout protection levels on STM32, APPROTECT on Nordic chips, eFuse-based JTAG disable on ESP32, password-protected debug on AURIX, lifecycle states on NXP processors. The security requirement comes from standards and regulation: ETSI EN 303 645 provision 5.6-4 requires that physically accessible debug interfaces are disabled in software; the OWASP IoT Security Testing Guide covers debug interfaces as a test category; UN R155 Annex 5 lists unauthorised physical access and manipulation of the vehicle’s software among the threats to mitigate.
What it means in practice
Open or weakly protected debug interfaces are the single most common finding in our hardware tests, across appliances, IoT modules and ECUs. Typical patterns: a UART console that drops into a root shell without a password; an SWD port that is “disabled” in the configuration file but never locked in the fuses; readout protection level 1 on a microcontroller where a documented downgrade or a voltage glitch gives access anyway; a production tester mode reachable over a diagnostic routine that re-enables JTAG.
In household and medical appliance tests we have usually recommended the same three steps: burn the eFuses that lock the debug port in the production line, remove the interactive console from the production image and keep a signed debug firmware for field service. On an ECU the equivalent is the HSM-managed debug password plus a documented, authenticated unlock procedure for the service workshop. The debug port is also the best route for firmware extraction, which is why it comes first in the test plan.
Common misunderstandings
Debug interfaces are not a problem only for devices an attacker can buy. A single open port on a device sold in volume gives the attacker the firmware of all of them, and with it the keys and vulnerabilities that apply to every unit in the field. And locking the port is not the same as removing the risk: fault injection and chip-level attacks exist, which is why keys should live in a hardware security module or a secure element rather than in general flash.
FAQ
Frequently asked questions
Do I have to remove debug interfaces from production devices?
Not remove, but disable or protect. ETSI EN 303 645 provision 5.6-4 says that physically accessible debug interfaces shall be disabled in software. In practice: set the chip's readout and debug protection permanently (fuses or option bytes), require authentication for debug access where the chip supports it, and turn the UART console into a log-only output or disable it. Unpopulated headers alone do not help; the pads are still there.
What can an attacker do with an open JTAG port?
Halt the CPU, read and write all memory including flash and RAM, dump keys that are in RAM at that moment, set breakpoints to bypass checks like a PIN comparison or a signature verification, and flash modified firmware. With an open JTAG port the device's software security is irrelevant.
How do you find debug ports if they are not labelled?
Visual inspection for test pads and headers, continuity to the chip pins from the datasheet, a logic analyser to spot UART traffic during boot, and a JTAG pin finder that tries pin combinations. For packages like BGA we use the vendor documentation and, if needed, X-ray or layer inspection. Finding the port is usually a matter of hours.
Sources
Related pages
- GlossaryFirmware ExtractionFirmware extraction means getting the code and data out of a device for analysis. The methods from update files to chip-off, what attackers find, and how to make it hard.
- GlossarySecure BootSecure boot verifies the signature of every stage of firmware before it runs. How the chain of trust works, where it is specified, and where it fails in real devices.
- InsightsHardware Penetration Test: How It Works, Step by StepWhat happens in a hardware pentest: teardown, debug ports (UART, JTAG, SWD), firmware extraction, secure boot and eFuse checks, what we need from you and what you get.
- InsightsIoT Penetration Testing: What We Attack and What We FindWhat an IoT pentest covers, from debug ports and firmware to radio, apps and cloud, which findings come up most often, and how to prepare your device for testing.
- ServicesWe open the case. Then the firmware.Hardware pentests for embedded devices: debug interfaces, firmware extraction, secure boot, fault injection and firmware reverse engineering in our lab.
