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 finding needs the steps to reproduce it: which pins, which commands, which tools, what was observed. For hardware, this means photos of the connections, command transcripts, and the captured evidence, because hardware results are harder to take on faith than a software stack trace.
FINDING F-03: Unauthenticated firmware read over UART bootloader Reproduce: 1. Connect 3.3V serial adapter to header J3 (GND, TX=pin2, RX=pin3) 2. Power on; press any key within 2s to halt autoboot at the => prompt 3. Run: sf probe; sf read 0x82000000 0x0 0x1000000; tftpput ... 4. Result: full 16 MB firmware recovered, no authentication required Evidence: photo IMG_042, transcript uart_dump.log
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.
Explain the Impact, Not Just the Flaw
Engineers fix what they understand to matter. Each finding should explain the consequence in concrete terms: not just the debug port is open but an attacker with the device in hand can extract the firmware and any keys it contains in minutes, which for this product means the signing key and therefore the whole fleet. The impact is what justifies the fix.
Connecting the technical flaw to the business or user consequence is what moves a finding up the priority list. A team may shrug at a missing fuse but act on every device in the field can be cloned. Spelling out where the flaw leads, in the client’s terms, is how a report makes the case for the effort a fix requires.
Rank by Impact and Reachability
Findings must be prioritized, because a flat list paralyzes. Rank each by impact and how reachable it is, so the team sees what to fix first. An internet-reachable critical outranks a finding that needs invasive physical access, and the ranking, with its reasoning, is what turns the report into a sequenced plan rather than a pile.
Showing the reasoning behind each rating is what makes it trustworthy and actionable. This is critical because it is remotely reachable and yields code execution lets the team agree or push back with specific knowledge of their deployment. A bare severity label invites argument; a reasoned one invites action.
Give Concrete, Actionable Remediation
Each finding needs a fix the team can actually implement, specific to their product, not a textbook platitude. 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 directly. The more concrete the remediation, the more likely it is done correctly.
Where a full fix is a larger effort, offering both a tactical mitigation and a strategic fix helps. Short term, disable the undocumented telnet service in the init script; long term, add a build step that strips debug services from release images. Giving the team a path they can start now, and a destination, is more useful than an all-or-nothing recommendation.
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 tells the team which defenses to preserve as they change other things.
Acknowledging strengths also helps prioritization, because it shows where the existing defenses already contain a finding’s impact. 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.
Be Precise and Avoid Jargon Where You Can
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 a summary that does not get understood. Match the language to each section’s audience.
The goal is a report that is technically exact for the engineers and clearly readable for the decision-makers, with neither group left guessing. That balance 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 in the first place.
A report written this way respects both the client’s time and the work that went into finding the issues. It turns a week at the bench into changes in the product, which is the entire point. The vulnerabilities were always there; 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.