Building an Attack Tree for Embedded Hardware
An attack tree is a simple, powerful way to reason about how an attacker reaches a goal. You put the goal at the root and break it into the alternative ways to achieve it, then break those down again until you reach concrete steps. For embedded hardware, it turns a vague worry into a map you can prioritize and defend.
Why an Attack Tree
Security discussions drift without structure, jumping between a clever attack someone read about and a worry someone has, with no way to tell which matters. An attack tree imposes order by starting from what the attacker wants and working backward through how they could get it. The result is a shared picture the whole team can reason about.
For embedded products the value is concrete. Hardware gives an attacker many paths, the debug port, the firmware, the buses, the radios, the cloud link, and an attack tree lays those paths side by side so you can compare them honestly. It is the difference between defending against the last attack you heard about and defending against the cheapest path into your actual device.
The Structure: Goal, Paths, Steps
An attack tree has a single goal at its root, for example extract the firmware encryption key. Below it sit the alternative high-level approaches, and below those the concrete steps each approach requires. Children combine in one of two ways: OR nodes, where any child achieves the parent, and AND nodes, where all children are required together.
GOAL: Extract the firmware encryption key
OR-- Read it from the device
| OR-- Dump flash and find the key [if key in flash]
| OR-- Read it over an open debug port [if JTAG/SWD open]
| AND- Defeat readout protection
| +-- Glitch the RDP check at boot
| +-- Then dump flash over debug
OR-- Recover it from runtime
| AND- Get debug or code execution
| AND- Read the decrypted key from RAM
OR-- Get it from outside the device
OR-- Find it in a leaked SDK or repo
OR-- Obtain it from the manufacturing lineReading the tree top to bottom shows every distinct way to the goal at a glance. The OR branches are alternatives an attacker chooses between; the AND branches are steps that must all succeed. That structure is what later lets you find the cheapest complete path and the single defenses that cut off the most branches.
Start From the Attacker’s Goal
Build the tree from the top by naming what an attacker actually wants from your product, not what attacks exist. Common goals for a connected device are extracting a key, running unsigned firmware, cloning the device, recovering user data, or pivoting to the cloud backend. Each worthwhile goal gets its own tree.
Naming the goal precisely matters because it focuses everything below. Run unsigned firmware and extract the signing key are different goals with different trees, even though they share steps. Starting from a real, valuable goal keeps the tree grounded in what the attacker is paying their time to achieve, rather than in a catalog of techniques.
Decompose Into Paths
Under the goal, lay out the high-level approaches as OR branches, the genuinely different routes an attacker could take. For extracting a key those might be read it from storage, recover it from runtime memory, or obtain it outside the device entirely. Each branch is a different world with different prerequisites.
The discipline at this level is completeness without overlap: cover the real alternatives, including the unglamorous ones like a key leaked in a public repository or harvested at the factory. Attackers take the easiest path, and the easiest path is frequently not the technically impressive one, so a tree that omits the boring routes will mislead your priorities.
Break Down to Concrete Steps
Keep decomposing each path until the leaves are concrete actions you can reason about: clip onto the SPI flash and dump it, glitch the readout-protection check, find the debug header and connect, sniff the I2C line to the secure element. A leaf should be specific enough to estimate its difficulty and to map to a defense.
This is where the tree earns its keep, because concrete leaves connect to your design decisions. The leaf glitch the RDP check maps directly to whether you enabled glitch detection and redundant checks. The leaf dump flash and find the key maps to whether the key is in flash at all. Abstract worries become specific, checkable conditions.
Annotate the Leaves
A tree becomes a prioritization tool once you annotate the leaves with attributes: estimated cost or skill, time, equipment needed, and whether the step is even possible given the design. These annotations propagate up the tree and let you compute the cheapest complete path to the goal.
GOAL: Run unsigned firmware OR-- Skip secure boot via glitch cost=MED gear=glitch-rig feasible=YES OR-- Find a signing key in flash cost=LOW gear=clip+prog feasible=NO (key in SE) OR-- Exploit an update-path bug cost=MED gear=none feasible=UNKNOWN OR-- Replace flash with own image cost=LOW gear=programmer feasible=YES (no verify)
The annotations make the answer jump out. Here, replacing the flash with your own image is low cost with common gear and feasible because nothing verifies it, so that is the path an attacker takes, not the glitch attack that gets all the attention. The tree just told you where to spend your defensive effort.
Find the Cheapest Path
An attacker does not take the hardest route, they take the cheapest one that works. Reading the tree for the lowest-cost complete path, an OR branch needs only its cheapest child, an AND branch costs the sum of its children, tells you how your device will actually be attacked, which is rarely the scenario people fixate on.
This is the single most useful output. It reframes the conversation from is this exotic attack possible to what is the easiest way in, and it consistently surfaces mundane weaknesses, an unverified flash, an open debug port, a shared key, that outrank the dramatic ones. Defending the cheapest path first is how you spend a limited budget where it counts.
Use It to Prioritize Defenses
With the cheapest paths identified, look for defenses that cut off the most branches at once. Moving the key into a secure element prunes every read-it-from-storage and read-it-from-RAM branch simultaneously. Enabling verified boot prunes the entire replace-the-flash subtree. A single well-chosen control can collapse large parts of the tree.
This is where attack trees beat a flat list of findings: they show which defenses have leverage. A fix that closes one obscure leaf is worth less than one that prunes a whole subtree, even if both address one finding on paper. The tree makes that leverage visible, so you invest in the controls that change the most paths.
Keep It Honest About Feasibility
A leaf marked not feasible because of a design choice is a defense you can point to, but it has to be true. Marking dump flash and find the key as infeasible because the key is in a secure element is only valid if the key never touches flash or RAM in the clear. The tree is only as honest as its feasibility annotations.
This is why building the tree pairs well with actual testing. An assumption in the tree, the debug port is locked, the key never reaches RAM, becomes a hypothesis to verify on real hardware. Where testing contradicts the tree, the tree was wrong and a path you thought was closed is open, which is exactly the kind of gap worth finding before an attacker does.
A Living Document
An attack tree is not a one-time artifact. As the design changes, a new interface, a moved key, an added radio, the tree changes with it, and revisiting it catches paths that a change quietly opened. It also grows as you learn, incorporating new techniques and findings from testing.
Kept current, the tree becomes a shared reference for the whole team: engineers see how their component fits the attacker’s paths, and leadership sees where the real risk concentrates. That shared, evolving picture is more valuable than any single snapshot, because security decisions keep getting made long after the first model.
From Tree to Action
The output of the exercise is a prioritized list of defenses tied to the paths they close, which feeds directly into the security requirements and the test plan. Each cheap path becomes a requirement to close it, and each closed path becomes a test to confirm it stays closed on real hardware.
That hand-off is what keeps the attack tree from being a whiteboard exercise that fades. The cheapest paths become must-fix requirements, the feasibility assumptions become test cases, and the whole thing becomes a traceable line from how an attacker would get in to what the team built and verified to stop them.
Where This Fits
Building attack trees and using them to prioritize defenses is core threat-modeling work, and it is most valuable early, before the design is locked. If you want help mapping how your product could be attacked and where to spend your defensive effort, that is the kind of work we do at Berkner Tech.