What each section of an ELTON product security testing report holds, why FDA reviewers need it, and an example report to download.
Every section answers a question a reviewer asks; the appendices are the evidence behind the findings.
| Section | What it holds | Why it is there |
|---|---|---|
| Product and scope | What was tested: the system description, in-scope components with versions or serial numbers, tools and techniques, what was out of scope, and the counts from the twin (components, interfaces, data flows, assets, initial-access points, test cases, findings). | A reviewer reads scope before findings. The counts show the whole product was in scope, and every test case can be traced to the resource it targeted. |
| Executive summary | The assessment type and period, the findings by verdict and by severity, assessment coverage (resources, entry points, test cases, passed and failed), the top findings, notable strengths and strategic recommendations. | The first page carries the handful that needs fixing. Splitting by verdict before severity keeps a directly exploitable finding from hiding among weaknesses. |
| Methodology | The assessment process in two phases (build, model and test; analyze, rate and validate), coverage against the four FDA testing categories, the testing types, and how each CVSS v4.0 metric is computed from a fixed rubric. | FDA asks for methodology, scope, duration and tester independence. Mapping to security requirements, threat mitigation, known vulnerability and penetration testing answers it in the reviewer’s own categories. |
| Digital twin overview | The model the test ran against: components, data flows, interfaces, assets, software materials, countermeasures, initial access, trust levels, threats and the architecture diagram. | Coverage only means something against a model of the product. The twin is what the test cases were generated from, and what each finding is placed on. |
| Findings | Every finding, grouped by exploitability first and then by CVSS v4.0 severity: summary, exploitability, preconditions and postconditions, CVSS v4.0 and v3.1, SSVC, CWE, discovery, lifecycle status, remediation, verification, the contexts it is exploitable in, and the evidence. | A finding a reviewer can act on states how it is reached, what it gives an attacker, how it was found and how the fix will be proven. Each one traces back to the failed test case that surfaced it. |
| Fixed vulnerabilities | Vulnerabilities found and fixed before the assessment closed, listed for completeness and counted in no total. | FDA wants to see how vulnerabilities were managed during development, not only what is left. A fix with its retest is evidence of the SPDF working. |
| Appendix: digital twin | The source materials the twin was built from (documents, binaries, code, runtime captures) and which parts of the twin each one informed, plus the architecture in full. | A reviewer can see what the model rests on and how deep the access was, which sets the confidence of every Not Affected. |
| Appendix: threat coverage | Every threat on the architecture that was tested, with its EMB3D and CWE identifiers and the test cases that covered it, pass or fail. | The trace from threats to test cases lives here. It evidences the control mitigations claimed elsewhere in the security documentation, including where nothing was found. |
| Appendix: test cases | Every test case: objective, pass and fail criteria, outcome, analysis and the finding it produced. | The record of how each part of the product was tested. A failed test case with no finding attached reads as a missing finding, so the two lists have to agree. |
| Appendix: CVSS justifications | For every scored finding, metric by metric: the value, the rubric questions that decided it, the answer to each and the evidence it rests on. | A rating with its reasoning survives review. The rubric is built on the FDA-qualified MDDT rubric for applying CVSS to medical devices. |
The example is a draft product security testing report for a fictional infusion pump, generated by the ELTON platform. Read it next to the whitepaper How ELTON Tests a Medical Device for the process behind it.
The fact rail beside each finding is what lets product security and FDA read it the same way.
Directly exploitable, conditionally exploitable, unexploitable weakness or mitigated weakness, derived from the dependency graph.
What the attacker must hold to reach the finding, and what it gives them to carry into the next step.
Every initial-access position and use case, with the preconditions it meets or leaves unmet.
CVSS v4.0 and v3.1 vectors with scoring rationale, plus SSVC: exploitation, technical impact, automatable.
How it was found and its status history from Needs Triage to Affected or Fixed, with dates.
Prescriptive fixes in priority order, and the test case to rerun to prove the fix.
The full report with its traceability appendices is what ELTON recommends goes to FDA.
The approach comes from the guidance, from conversations with FDA, and from submission feedback on pentests over the last 24 months across 510(k)s and PMAs. The move to test-case based reporting came directly from FDA questions when a pentest report had too few findings and no clarity on how key areas were tested.
With an SPDF, final pentest reports should have fewer findings, ideally none. The trace from threats to test cases is then what evidences the control mitigations claimed elsewhere in the security documentation. Pentesting is implementation testing, historically negative; in December 2025 FDA told us it wants to see positive test cases too.
Most of it is submission feedback, and there are relevant sections: test case traceability to design (premarket guidance Section V.A.3 and Appendix 2; QMSR design inputs and design verification), and vulnerability traceability to test cases (Section V.A.3 test reports and V.A.1 unresolved anomalies).
“You provided a penetration testing report that contains a subset of findings. Please provide evidence of testing for all in-scope components and any historical testing performed during development, as well as how those vulnerabilities were managed.”
Evidence, in ELTON’s case, is test cases. A pentest methodology with no evidence of how the product was tested where no vulnerability was found is no longer a compliant testing methodology. A manufacturer can try without it and may succeed, but the issues we saw at like manufacturers are why we changed. The traceability reports can be removed from the product security report on request; we recommend they go to FDA, and without them we cannot guarantee the report is fit for submission or support the question when it comes.
Where each activity stems from in the guidance or its reference standard is mapped in Every ELTON Activity, Traced to FDA (section 2.4 carries the deficiency above) and on the FDA compliance page.
A SQL injection is still a SQL injection after a WAF goes in front of it.
Reachable from the known attack surface, every precondition met as shipped.
Reachable once another finding produces the condition it needs.
Not reachable from the known attack surface. It still speaks to the fragility of the design.
A mitigation exists and the retest shows it holds.
From a compliance standpoint this is our opinion, and it aligns with regulators: FDA treats an SBOM CVE as needing a CVSS rating and a justification even when it is not directly exploitable. Weaknesses are clearly labeled, so product security and FDA can see they are not the same as directly exploitable.
The failed test cases are in the traceability. A reviewer who sees a failed test case with no finding attached will conclude the finding is missing. Every finding carries the preconditions and postconditions that drive its exploitability, and some will drop out on your feedback about access, code or network position.
Manufacturers are receiving a high volume of AI-driven vulnerability disclosures, many not exploitable from external interfaces, and fixing them because they arrive through CISA. Identifying and fixing everything is becoming common because AI lets people find and report what used to take a ten-year pentesting background.
R&D usually sees the full list and decides, and in development it generally just fixes it. We would not expect a product team to make the risk call on a fix only because a finding is not directly exploitable.
Testing in development and testing postmarket produce different outcomes, and ELTON adjusts for that.
Fixes are easy and cheap at this stage, and there is little return on debating exploitability when something is clearly a vulnerability and should be fixed. The provided environment is also not always the one customers deploy.
Fielded devices change on a release cycle measured in months, so exploitability in the deployed configuration decides what is fixed now, what waits for a release, and what is dispositioned with its rationale.
What does an ELTON test report contain?
Product and scope, an executive summary split by exploitability verdict and severity, the methodology mapped to FDA testing categories, a digital twin overview, every finding with its trace, the vulnerabilities fixed during the assessment, and appendices for the twin, threat coverage, every test case and every CVSS justification.
Why is the report longer than a traditional pentest report?
FDA asks for evidence of testing for all in-scope components, including where nothing was found. The test cases and threat coverage are that evidence; the findings a manufacturer has to fix are still on the first pages.
Can the traceability appendices be removed?
On request, yes. ELTON recommends they go to FDA, because without them the report cannot be guaranteed fit for submission and the coverage question a reviewer asks has no answer in the document.