“White box or black box?” is the wrong question if you only ask it once.
In software, the split already changes the toolchain — static analysis against source versus dynamic testing against a running target, each catching bug classes the other structurally misses. On embedded hardware the same split goes one step further: black box doesn’t just mean less information, it means the device isn’t reachable yet. You can’t attach a debugger to a bus you haven’t identified.
Both terms describe how much a tester starts with. On hardware, that starting point also decides how much has to be earned physically before the actual security testing can begin.
Black box: the device as it ships
No schematics, no source, no debug documentation. Just the unit, as a customer would receive it.
This is where an attacker with a retail sample starts, so it’s also where the assessment starts:
- Find as much information as possible (OSINT, Open Source Intelligence)
- Open up the case, crack it open if it’s sealed, remove potting resin if needed
- Teardown and chip identification: markings, package, pinout guesswork
- Continuity mapping to find test points and populate the ones that matter
- Logic analyzer and scope on suspected buses (I2C, SPI, UART) to catch live traffic
- JTAG/SWD pinout recovery via scan when the header isn’t labeled
- Flash extraction, in-circuit or desoldered, to read out firmware without vendor cooperation
- Fuzzing whatever external interface exists: network stack, USB, RF
Expected result: a concrete answer to “what can someone do with a unit bought off a shelf and zero inside knowledge.” Nothing borrowed from design intent — only what’s observable and reachable from outside.
White box: the device as it was designed
Schematics, firmware source, memory maps, key management documentation, debug interfaces already known and enabled.
This trades discovery for coverage:
- Static and manual review of firmware and bootloader code
- Direct JTAG/SWD access — no time spent reverse-engineering the header
- Chain-of-trust and secure boot review against the actual design, not a guess at it
- Key derivation and entropy source audit — this is where most “AES-256, so it’s secure” claims fall apart
- BOM review against known CVEs and silicon errata for the specific parts used
Expected result: exhaustive, root-cause findings, in a fraction of the time black box needs to reach the same conclusions. This is the approach for pre-market hardening and for documentation that holds up under scrutiny — not “we believe it’s secure,” but evidence of why.
Grey box: what’s actually disclosed
Most real engagements aren’t pure black or pure white, just as hacker’s hats never are. They’re scoped grey box: some artifacts handed over, others deliberately withheld, to match a specific access scenario rather than an abstract “attacker” or “designer” role.
On embedded hardware, the combination that gets withheld matters as much as the one that gets provided:
- Schematics provided, firmware withheld — checks whether firmware-level protections (secure boot, flash encryption) hold even against someone with full electrical knowledge of the board. Typical for assessing how can a clone be made.
- Firmware binary provided, schematics withheld — checks whether firmware hardening survives without knowledge of the physical attack surface. Typical to assess the disclosure via firmware update binaries.
- JTAG/SWD enabled and documented, key management docs withheld — the realistic case of a leaked debug credential or an insider with bench access but no crypto design documentation.
- Chip-level datasheets provided, board-level schematics withheld — the common case when the client integrates a module or SOM they didn’t design.
Expected result: findings scoped to a specific, realistic disclosure scenario — what happens if X leaks but not Y — instead of exhaustive coverage or open-ended discovery. This is also, in practice, the version most engagements actually buy: it maps to something concrete (a partner, a supply-chain leak, an insider), not to a textbook role. It’s also where the bench matters most: half the artifacts are known, half still have to be earned physically — a pinout recovered, a flash chip lifted, a probe fixture printed to reach a test point the design never intended to expose.
When to use which
Black box alone — post-market, third-party product, or the question is specifically what an outside attacker without any inside knowledge can reach. No more, no less.
White box alone — pre-market, internal product, budget and timeline matter, and the deliverable needs to be documentation-grade.
Grey box — when the disclosure boundary itself is the threat model: what a partner, an insider, or a supply-chain leak would realistically have access to.
Both, full black and full white — when “compliant” also has to mean “secure,” independent of any specific disclosure scenario. White box gives you the map. Black box tells you whether someone without the map gets there anyway. If they do, the threat model has a hole the paperwork doesn’t show.
If you’re evaluating whether your product needs black box, white box, or both, get in touch. The first step is a short, qualified discovery call.
