Writing a Hardware Pentest Report That Gets Fixed
A vulnerability nobody fixes is wasted work, and the report is what decides whether a finding gets fixed or filed away. The best hardware testing in the world is worthless if the report does not communicate what is wrong, why it matters, and how to fix it, in a way the people who can act on it will actually read. Here is how I write reports that lead to fixes.
The Report Is the Product
Clients do not pay for probing a board; they pay for the report, because that is what they can act on. The hands-on work produces findings, but the report is what turns those findings into changes. Treating the report as the real deliverable, and writing it with as much care as the testing, is what makes an assessment worth its cost.
A report that sits unread, or that engineers cannot act on, means the vulnerabilities stay in the product. So the question that should guide every part of the report is simple: will this make the right person fix the right thing. Everything below serves that goal, because a finding that does not get fixed might as well not have been found.
Write for Two Audiences
A report serves two readers with different needs. Executives and product owners need to understand the risk and decide where to invest, quickly, without the technical detail. Engineers need enough detail to reproduce, understand, and fix each issue. A report that serves only one leaves the other unable to act.
The standard structure handles this: an executive summary for the decision-makers and detailed findings for the implementers. The summary conveys the overall posture and the most important risks in plain language; the findings carry the technical depth. Writing both well, rather than one thoroughly and one as an afterthought, is what gets a report read by everyone who needs it.
Lead with an Honest Executive Summary
The executive summary states the overall security posture, the most significant risks, and the recommended priorities, in language a non-specialist can act on. It should answer, in a page, how bad is it and what should we do first. This is the part leadership reads, and it is where the budget and attention decisions are made.
Honesty matters here more than reassurance. A summary that soft-pedals a fleet-wide key exposure to avoid alarming the client does them no favors, and one that cries wolf over minor issues loses credibility. An accurate, proportionate summary, this device has two critical issues that need fixing before launch and several lower-priority items, is what drives the right response.
Make Each Finding Reproducible
A hardware finding that cannot be reproduced will be doubted and not fixed. Each one needs the exact steps, which pins, which commands, which tools, what was observed, plus photos of the connections and the captured evidence, because hardware results are harder to take on faith than a software stack trace:
- Connect a 3.3V serial adapter to header J3 (GND, TX on pin 2, RX on pin 3)
- Power on and press any key within 2 seconds to halt autoboot at the bootloader prompt
- Run
sf probe; sf read 0x82000000 0x0 0x1000000and TFTP the image out - Result: the full 16 MB firmware is recovered, with no authentication required
Reproduction steps like these let an engineer confirm the issue themselves and, just as important, confirm it is fixed after they change something. A finding they can reproduce is a finding they believe and act on; one described vaguely is one they are tempted to dismiss as the tester getting it wrong.
What Every Finding Must Carry
Beyond reproduction, three things turn a finding from a note into a fix:
- Impact, not just the flaw. Explain the consequence concretely, not the debug port is open but an attacker with the device in hand extracts the firmware and the signing key in minutes, and therefore the whole fleet. A team may shrug at a missing fuse but act on every device in the field can be cloned.
- A reasoned priority. Rank by impact and reachability and show the reasoning, this is critical because it is remotely reachable and yields code execution, so the team can agree or push back with knowledge of their deployment instead of arguing with a bare severity label.
- Concrete remediation. A fix specific to their product, not improve key management but move the signing key into the secure element already on your board and verify the firmware can no longer read it, ideally with a tactical mitigation now and a strategic fix later.
Acknowledge What Works
A report that lists only failures gives a distorted picture and can demoralize a team that did real security work. Noting the controls that are correctly implemented, the secure boot is properly configured, the keys are in a secure element, is honest, builds credibility, and helps prioritization: a weakness behind a strong control is less urgent than the same weakness with nothing behind it, and a report that maps both gives a truer picture than one that catalogs only what is broken.
Match Language to the Audience
Precision builds trust; vagueness erodes it. Name the exact pin, the exact command, the exact file. At the same time, explain or avoid jargon in the parts non-specialists read, because a summary thick with acronyms is one that does not get understood. A report that is technically exact for the engineers and clearly readable for the decision-makers, with neither group left guessing, is a writing skill as much as a security one, and it is part of what separates a report that drives fixes from one that is accurate but inert.
Make It Easy to Track and Verify
A report is more useful when each finding has an identifier and a clear status path, so the team can track remediation and a retest can confirm closure. Numbering findings, stating the verification method, and structuring the report so it can be worked through item by item turns it into a project plan the team can manage.
Offering or planning a retest closes the loop. The reproduction steps that proved the finding are the same steps that confirm the fix, so a follow-up verification is straightforward and gives the client documented assurance that the issues are actually resolved, not just acknowledged. A finding tracked to verified closure is the report doing its full job.
The Report’s Real Measure
The measure of a report is not its length or its polish, it is how many findings get fixed because of it. Reproducible steps, concrete impact, honest prioritization, and actionable remediation are what make that happen, and they are worth as much attention as the testing that produced the findings. A report written this way turns a week at the bench into changes in the product, which is the entire point: the vulnerabilities were always there, and the report is what finally gets them removed.
Where This Fits
Producing reports that engineers act on is the deliverable of every penetration test and product security assessment I run. If you want findings communicated in a way that actually leads to fixes, that is the kind of work we do at Berkner Tech.
