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. Is the companion app in scope, the cloud backend, the radios, or just the device hardware. A connected product has many parts, and a scope that says test the device without saying which parts leaves a gap that either gets filled by guesswork or left untested, neither of which serves the client.
Set the Depth and 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. Black-box mimics an outside attacker with no inside knowledge. White-box gives the tester schematics, source, and documentation, which finds more, faster. Grey-box sits between. The choice trades realism against efficiency.
ACCESS LEVELS black-box no docs, no source most realistic, slowest, may miss internals grey-box partial (e.g. block diagram, some docs) balanced white-box schematics + source + 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 testing 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 whether the tester provides or the client 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.
Define What Is Off Limits
Just as important as what is in scope is what is out. Production systems the device connects to, other people’s cloud accounts, shared test infrastructure, and any third-party service the device touches are typically off limits unless explicitly included. A device test that accidentally hammers a live production backend is a serious problem.
Out-of-scope boundaries also cover legal and safety lines: not attacking infrastructure the client does not own, not testing radios in ways that violate spectrum rules, not endangering anyone with a safety-critical device. Naming these in scope keeps the engagement on the right side of lines that are easy to cross by accident during enthusiastic testing.
Set the Rules of Engagement
Beyond targets, the engagement needs operational rules: the testing window, who the tester contacts when something breaks or when they find something critical, how findings are communicated, and what to do if the device is damaged. These logistics prevent the small confusions that derail an otherwise good test.
A particularly important rule is the critical-finding path. If the tester finds something severe enough that the client should know immediately, a fleet-wide key exposed, a remote unauthenticated takeover, the rules should say so rather than waiting for the final report. Agreeing on that channel up front means urgent findings get acted on urgently.
Clarify the Deliverables
Scope should state what the client gets: a report, certainly, but in what form, with what level of detail, and aimed at whom. A report for engineers reads differently from one for executives, and a client expecting reproduction steps for every finding should know whether they are getting them. Aligning on deliverables avoids a final-week mismatch.
It also helps to agree on how findings will be rated and prioritized, so the client is not surprised by the severity scheme. Stating that findings will be ranked by impact and reachability, with concrete remediation, sets the expectation that the deliverable is an actionable plan, not just a list of problems.
Plan for the Information You Need
A hardware test goes faster with the right inputs: datasheets, schematics, a bill of materials, firmware images, and any existing documentation. Scope should list what the client will provide and when, because a tester waiting on a schematic is burning the budget. Gathering these before the engagement starts is part of good scoping.
Even a black-box test benefits from logistics being settled: how units are shipped, whether the tester needs special equipment for this product, whether there are environmental requirements. Surfacing these needs during scoping, rather than discovering them on day one, is what lets the actual testing start promptly when the window opens.
Write It Down and Agree
All of this belongs in a written, mutually agreed scope document: targets, depth, access, destructive-testing allowance, exclusions, rules of engagement, deliverables, and inputs. A signed scope protects both parties, sets shared expectations, and is the reference that settles any mid-engagement question about whether something is in bounds.
The document 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 precise, agreed scope is the foundation that lets the rest of the test proceed with confidence on both sides.
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 the systems that must not be harmed, and sets expectations so the deliverable is what the client needed. The hour spent scoping is repaid many times over in the testing.
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. Scope is the quiet decision that determines whether the hands-on work that follows is worth anything.
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.