The hardware attack surface: what happens on the bench

Why the board comes first

Almost every deep finding in a connected product starts with the firmware, and almost every firmware extraction starts with the board. Once a tester has the image, the rest of the engagement changes character: hard-coded credentials become readable, the update verification logic becomes reviewable, the proprietary radio protocol becomes decodable, and the cloud API stops being a black box because the client for it is now on the desk.

That is also the attacker’s sequence, which is why the law now points at it directly. Annex I Part I, point (2)(j) of the Cyber Resilience Act requires products to be designed, developed and produced to limit attack surfaces, including external interfaces. ETSI EN 303 645 gets there sooner and more specifically: provision 5.6-3 says device hardware should not unnecessarily expose physical interfaces to attack, and provision 5.6-4 says that where a debug interface is physically accessible, it shall be disabled in software.

Finding the interfaces

The first hour of a teardown is unglamorous. Open the enclosure without destroying the evidence, photograph both sides of the board, and identify the major components: the main processor or SoC, external flash, RAM, radio modules and any secure element. Part numbers go into a list because the datasheets decide what is worth trying next.

Then the tester looks for what is reachable. That means populated headers, of course, but mostly it means the things that are not obviously connectors at all.

• Unpopulated header footprints. A four-pin row with a square pad on pin one is a serial console in almost every case.
• Test points. Bare pads used in production test, often labelled on the silkscreen with exactly the signal name a tester wants.
• Vias and traces to a known pin. If the datasheet says the SoC drives its debug interface on specific pins, the trace goes somewhere, and that somewhere is reachable with a fine probe.
• Repurposed external connectors. A USB port wired to a serial bridge, an RJ45 with unusual pin assignment, or an audio jack carrying a console. EN 303 645 gives the archetype: a micro-USB port meant only to supply power should be physically configured so it cannot also allow command or debug operations.
• Programming interfaces on modules. Radio and Wi-Fi modules frequently carry their own debug pins, separate from the host processor.

A logic analyser on candidate pins during boot answers most questions quickly. A serial console announces itself: a burst of activity at power-on, a recognisable baud rate, and readable text.

Serial consoles and debug interfaces

A live UART is the single most productive finding in embedded testing, and it is common. What the tester establishes is not simply whether the port exists, but how much of the boot sequence it exposes and what it accepts.

The bootloader

Many devices can be interrupted during boot into a bootloader prompt. From there a tester can often change kernel arguments, boot into single-user mode, read memory, or write a new image. Where the bootloader is protected, the protection may be a password compiled into the image, which the firmware extraction step will find anyway.

The runtime console

After boot, the same port may present a login prompt, a diagnostic menu or an unauthenticated shell. EN 303 645 provision 5.6-4 is explicit about what good looks like here: its worked example describes a UART disabled through the bootloader software, with no logon prompt and no interactive menu available as a result. Note the standard for “disabled”: not obscured, not undocumented, not requiring a special cable. Nothing there to talk to.

JTAG and SWD

The debug interface of the processor itself is a different order of access: halt the core, read and write memory, single-step the firmware. Modern parts almost all support locking it, whether through fuses, option bytes or a life-cycle state, and the tester’s job is to confirm the lock was actually applied to the production build rather than only planned. Scan-chain enumeration on a shipped unit answers that in minutes.

The two questions that follow are worth asking of any design: does the lock survive a firmware update, and does it survive a factory reset? A device that unlocks debug in recovery mode has a locked front door and an open back one.

Getting the firmware out

If the debug interfaces are properly closed, the memory is the next route, and it is a physical one.

• In-circuit reading. A clip on a SOIC-8 SPI NOR flash reads the image with the board powered down, or with the processor held in reset. Fast, non-destructive, and it works far more often than manufacturers expect.
• Chip-off. Desoldering the flash or eMMC and reading it in a programmer or adapter. Destructive to that unit, reliable, and unaffected by anything the firmware does.
• The update package. Often the easiest route of all. If the manufacturer publishes update images, the analysis can start before the hardware arrives.
• The debug interface. Where JTAG or SWD is open, memory can simply be dumped through it.

Flash encryption changes the economics rather than the outcome. If the key lives in the SoC and the flash content is encrypted at rest, an in-circuit read yields ciphertext, and the tester has to work on the processor instead. That is a much larger effort, which is exactly the point of doing it.

Whatever the route, what comes out is inspected for the same things every time: credentials and API keys, private keys and certificates, hard-coded Wi-Fi or cloud secrets, service accounts, the component inventory and its versions, debug tooling that shipped by accident, and the code that verifies the next update. That last item matters most, because it decides whether the manufacturer can still fix anything found in the others. The CRA note covers the update and SBOM duties that hang off it.

Radios

The radio interface is what makes a product radio equipment, and therefore what makes the RED cybersecurity requirements apply to it in the first place. On the bench it is treated as another bus: something to capture, decode, replay and then break.

The highest-yield moment is provisioning. Pairing and onboarding exchanges are where key material is established, and they are frequently the least examined part of a protocol implementation because they only happen once per device. A tester captures the exchange with a protocol sniffer or software-defined radio and asks whether the session key is derived from something the attacker cannot observe, fixed in the firmware, or simply transmitted.

After that the work is systematic: enumerate the exposed services on the link – a BLE GATT table is a service inventory in the same sense as an open port list – and test each characteristic or endpoint for what it accepts without authentication. Then replay, then malform, then downgrade. Then stand up a network the device should refuse to join and see what it does.

Everything here maps back to the requirement text. Point (d) of RED Article 3(3) is about not harming the network or misusing network resources. Point (e) is about safeguards for personal data and privacy. Annex I of the CRA covers the same ground at points (2)(e) and (2)(f). The full mapping is in the standards ledger on the home page.

Fault injection and side channels, honestly

Voltage glitching, clock glitching, electromagnetic fault injection and power analysis are real techniques with real results, and they are frequently oversold. They are worth commissioning when the threat model justifies them: a device holding keys that protect other people’s assets, a payment or access-control product, or a design whose entire security argument rests on secure boot.

They are not worth commissioning as a default line item on a consumer sensor. The work is slow, the setup is per-target, and a report that spends five days characterising a glitch on a product whose UART was open is a report that spent its budget in the wrong place. Sequence matters: the cheap findings first, the expensive ones only when the cheap ones are gone.

What good looks like

The table below is the shape of the evidence a hardware section of a report should produce. It is also a usable design checklist.

Designing the surface down

Everything above is cheaper to prevent than to find. Four decisions remove most of the hardware findings a tester would otherwise write up.

1. Make the production programming and debug state a distinct, verified step. Blowing the lock fuse should be a line in the manufacturing test that fails the unit if it did not take, not an instruction in a document.
2. Treat the console as a product feature with a lifecycle. Decide what it outputs in production, disable interaction in the bootloader as EN 303 645 describes, and test that decision on a retail unit rather than on a bring-up board.
3. Put the root of trust where a clip cannot reach it. If the boot chain can be broken by rewriting external flash, everything else is decoration.
4. Remove the pads you do not need, and document the ones you keep. An interface that is present because nobody asked whether it still had a purpose is the most common finding in this category.

Then have someone try it on a production unit. The attack surface mapper lists what that involves for each exposure, and the note on the EN 18031 restrictions covers the one software behaviour that outranks all of this for conformity purposes.