Scoping a Hardware Penetration Test
A good hardware penetration test starts long before a probe touches a board. It starts with scope: what gets tested, how deeply, with what access and information, and what risks are acceptable. Hardware testing carries physical and commercial risks that software testing does not, and getting the scope right is what makes the engagement productive instead of destructive. Here is how I scope one.
Why Scope Matters More for Hardware
In software testing a bad scope wastes time. In hardware testing it can destroy expensive prototypes, miss the threats that matter, or have the tester spend a week on a chip-level attack the client never cared about. The physical and one-of-a-kind nature of hardware raises the stakes of getting scope wrong, so it deserves real attention up front.
Scope is also where expectations are set. A client who thinks a hardware pen test means trying to brick the device is surprised by a firmware analysis, and one who expects a quick check is surprised by a glitch campaign. Agreeing on what the test is, and is not, before it starts is what aligns the work with what the client actually needs.
Define the Target Precisely
Name exactly what is under test: which product, which hardware revision, which firmware version, and how many units are available. Hardware findings can be revision-specific, so the exact board and firmware matter, and the number of units decides whether destructive testing is even possible. Be specific about boundaries within the product too, whether the companion app, the cloud backend, and the radios are in scope or just the device hardware, because a scope that says test the device without saying which parts leaves a gap that gets filled by guesswork or left untested.
Set the Depth to the Threat Model
Decide how deep the test goes, driven by the threat model. A device whose threat model includes a well-funded attacker with lab access warrants side-channel and fault-injection work; a device whose realistic threat is a curious owner does not. Matching depth to the real threat keeps effort proportional and the budget where it counts.
Stating the threat model in scope also frames the findings. If invasive chip-level attacks are out of scope because they are outside the threat model, the report says so, and a finding that needs decapping is noted as out of scope rather than missed. The threat model is the lens that decides which of the many possible attacks are worth the time.
Choose the Access Level
Black-box, grey-box, or white-box dramatically changes what a test finds in the time available, trading realism against efficiency:
| Access level | What the tester gets | Trade-off |
|---|---|---|
| Black-box | No docs, no source | Most realistic, slowest, may miss internals |
| Grey-box | Partial, such as a block diagram and some docs | Balanced |
| White-box | Schematics, source, and keys | Fastest coverage, least attacker realism |
For most product assessments, white or grey box is the better value, because the goal is to find the device’s weaknesses, not to prove an outsider can find them in a fixed time. Reserving black-box for when realism is specifically the point keeps a limited budget focused on coverage rather than on rediscovering what the documentation would have shown.
Agree on Destructive Testing
Hardware testing can damage or destroy units: desoldering a chip, decapping a package, or a glitch that bricks a board. Scope must state explicitly whether destructive testing is allowed, how many units can be sacrificed, and who supplies them. This is not boilerplate; it is the difference between a finding and an incident.
Spelling this out protects both sides. The tester knows they can lift a flash chip without a panicked phone call, and the client knows in advance that two of the ten units may not survive. Leaving it unsaid leads either to overcautious testing that misses findings or to surprise damage that sours the engagement.
What the Scope Document Must Pin Down
Beyond targets, depth, and access, a complete scope nails down four things that quietly derail engagements when left vague:
- What is off limits. Production systems, other people’s cloud accounts, shared infrastructure, and third-party services the device touches are out unless explicitly named, along with the legal and safety lines: no attacking infrastructure the client does not own, no spectrum-rule violations, no endangering a safety-critical device.
- Rules of engagement. The testing window, who the tester contacts when something breaks, and above all the critical-finding path, so a fleet-wide key exposure or a remote takeover reaches the client immediately rather than waiting for the report.
- Deliverables. What the client gets and for whom, since a report for engineers reads differently from one for executives, plus how findings will be rated and prioritized so the severity scheme is no surprise.
- Information and logistics. The datasheets, schematics, BOM, and firmware the client will provide and when, plus shipping, special equipment, and environmental needs, because a tester waiting on a schematic is burning the budget.
Write It Down and Agree
All of this belongs in a written, mutually agreed scope document. It does not need to be long, but it needs to be specific: vague scope is where engagements go wrong, the tester does what seems reasonable and the client expected something else. A signed, precise scope protects both parties, sets shared expectations, and is the reference that settles any mid-engagement question about whether something is in bounds.
Scope as the Test’s Foundation
Good scoping is not bureaucracy, it is what makes a hardware pen test effective. It aims the effort at the threats that matter, sizes the depth to the budget and risk, protects the units and systems that must not be harmed, and sets expectations so the deliverable is what the client needed. A test built on a clear scope finds the right things, in the right depth, without nasty surprises; a test built on a vague one wanders, risks the wrong assets, and ends in a report that misses the point.
Where This Fits
Scoping the engagement well is the first thing I do on any hardware penetration test, because everything downstream depends on it. If you want a hardware assessment scoped to your product, your threat model, and your real risks, that is the kind of work we do at Berkner Tech.
