The penetration test report FDA asks for under section 524B

Where the requirement comes from

Section 3305 of the Food and Drug Omnibus Reform Act of 2022, enacted on 29 December 2022, added section 524B, “Ensuring Cybersecurity of Medical Devices”, to the Federal Food, Drug, and Cosmetic Act. It took effect on 29 March 2023. Under 524B(a), a person who submits a 510(k), PMA, PDP, De Novo or HDE for a device meeting the definition of a cyber device must submit information to ensure the device meets the requirements in 524B(b).

The operative guidance is Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued on 3 February 2026. It supersedes the guidance of 27 June 2025; the revision realigns the document from the Quality System Regulation to the Quality Management System Regulation, whose final rule at 89 FR 7496 took effect on 2 February 2026 and incorporates ISO 13485:2016 by reference. Every page is marked “Contains Nonbinding Recommendations”. The statute binds; the guidance says how the agency expects it to be met.

Is your device a cyber device?

Section 524B(c) defines a cyber device as a device that “(1) includes software validated, installed, or authorized by the sponsor as a device or in a device; (2) has the ability to connect to the internet; and (3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats”.

All three limbs have to be satisfied. In practice limb two decides most cases and it is written as capability, not intended use: a device with a cellular modem that your labelling says should not be connected still has the ability to connect. Limb one turns on who validated, installed or authorised the software, which brings sponsor-authorised third-party software inside the definition. Limb three is broad enough that a device satisfying the first two will rarely escape it.

The five report elements, quoted

Section V.C of the guidance lists the types of testing FDA recommends for inclusion in a submission: security requirements, threat mitigation, vulnerability testing described in ANSI/ISA 62443-4-1, and penetration testing. Under the last of these the guidance is unusually specific about the report.

The testing should identify and characterize security-related issues via tests that focus on discovering and exploiting security vulnerabilities in the product. Penetration test reports should be provided and include the following elements: Independence and technical expertise of testers; Scope of testing; Duration of testing; Testing methods employed; and Test results, findings, and observations.FDA, Cybersecurity in Medical Devices, 3 February 2026, section V.C

Read that list as a specification for a document rather than a description of an activity. A report that describes findings brilliantly and says nothing about who ran the test, for how long, or against what scope, is missing three of the five. This is the single easiest thing to get right before a submission and one of the more common gaps in reports written for an internal audience.

The five elements and what a complete answer looks like

Element	What the report has to establish	Common gap
Independence and technical expertise of testers	Who performed the work, their relationship to the development team, and the basis for their competence	A report signed only with a company name, with no statement of independence at all
Scope of testing	The exact build, the interfaces, roles and accounts included, the backend environment, and what was excluded and why	A scope written as a product name rather than a version and an interface list
Duration of testing	The calendar window and the tester effort behind it	A single date, which reads as a one-day review whatever actually happened
Testing methods employed	The techniques used, with tool names, versions and configuration	Method described as “manual and automated testing”, which tells a reviewer nothing
Test results, findings, and observations	Every finding with reproduction evidence, plus observations that were not findings	Only the findings that were fixed, with the rest quietly absent

What the guidance says about independence

This is the part manufacturers most often ask about, and the guidance answers it in one paragraph immediately after the five elements.

Device manufacturers should indicate in the test reports by whom the testing was performed (e.g., independent internal testers, external testers) and what level of independence those responsible for testing devices have from the developers responsible for designing devices. In some cases, it may be necessary to use third parties to ensure an appropriate level of independence between the two groups, such that vulnerabilities or other issues revealed during testing are appropriately addressed. For any third-party test reports, manufacturers should provide the original third-party report.FDA, Cybersecurity in Medical Devices, 3 February 2026, section V.C

Three separate obligations sit in that paragraph. You must state the level of independence. You must consider whether a third party is necessary for the device in question. And where a third party did the work, you must provide the original report, not an internal summary of it.

The stated reason for the independence rule is not procedural: it is “such that vulnerabilities or other issues revealed during testing are appropriately addressed”. The concern is a tester who reports to the people whose design the finding criticises. That framing is useful when you decide how to staff a campaign, because it tells you what an adequate answer looks like. A separate internal team with its own reporting line and no involvement in the design of the device under test can be defensible for a lower-risk device. The same team embedded in the product group is harder to defend for an implantable or a networked therapy platform.

Note the final sentence of the section too: “For all testing, manufacturers should provide their assessment of any findings including rationales for not implementing or deferring any findings to future releases.” The tester writes the findings; the manufacturer writes the assessment. Submitting one without the other leaves the reviewer to judge severity without your risk context.

Penetration testing is not the whole of section V.C

The same section lists vulnerability testing “described in ANSI/ISA 62443-4-1” as a separate item, with an enumerated set of analyses the submission should evidence.

• Abuse or misuse cases, malformed and unexpected inputs, covering robustness and fuzz testing
• Attack surface analysis
• Vulnerability chaining
• Closed box testing of known vulnerability scanning
• Software composition analysis of binary executable files
• Static and dynamic code analysis, including testing for credentials that are “hardcoded,” default, easily guessed, and easily compromised

Alongside these, the guidance asks for evidence that each design input security requirement was implemented successfully, evidence of boundary analysis with the rationale for the boundary assumptions, and evidence that risk control measures are effective against the threat models in the architecture views. Footnote 47 adds that for any testing tools or software used, the details may include the tool name, version information and any settings or configuration options.

Practically, that split means a penetration test does not discharge the vulnerability-testing bullet and a fuzzing campaign does not discharge the penetration-testing bullet. A submission needs both, and a scoping conversation that treats them as one line item will produce a gap the reviewer finds.

The architecture views the test has to line up with

Section V.B asks for four types of security architecture view, “at minimum”: a Global System View, a Multi-Patient Harm View, an Updateability and Patchability View, and Security Use Case Views. Each is documented with diagrams and explanatory text, and each should identify security-relevant elements and interfaces, define the security context and boundaries, align with the security objectives, and establish traceability to requirements.

• Global system view. The device and all internal and external connections, including software update infrastructure, healthcare facility network impacts, intermediary connections or devices, cloud connections and patient home network impact.
• Multi-patient harm view. How the device and the systems it operates in defend against and respond to attacks with the potential to harm multiple patients. FDA’s own example is a set of multiparameter bedside monitors restarting at once, leaving a ward unmonitored.
• Updateability and patchability view. The end-to-end process that deploys updates and patches, which FDA notes “will likely include traversing technology that the device manufacturer does not control”.
• Security use case views. All functionality where a compromise could affect safety or effectiveness, across operational states such as power on, standby and transition, and clinical states such as programming, alarming, delivering therapy and reporting results.

The guidance scales this explicitly. A device with one hardware connection or a SaMD product with limited connectivity “will likely only need to have single architecture view for each of the global system, multi-patient harm, and updateability/patchability views”, while networking, wireless, cloud and commercial operating systems push the count up. This is the cheapest scoping input a tester can be given, because the views already say what the manufacturer believes the boundaries are.

Where the report sits in the submission

Appendix 4 of the guidance summarises the recommended premarket submission documentation. The top-level rows are the cybersecurity risk management report, measures and metrics, architecture views, testing, labeling, and cybersecurity management plans. Under the risk management report sit the threat model, the cybersecurity risk assessment, the SBOM, the vulnerability assessment and software support information, the unresolved anomalies assessment and traceability.

For an IDE submission the table marks only the SBOM, the architecture views and the labeling as “recommended”, with the rest listed as potentially helpful but not specifically recommended. FDA also cautions that the table “is not intended to serve as merely a deliverable checklist”, and that a manufacturer may organise the same content differently as long as it is present.

Two statutory items travel with the test evidence. Section 524B(b)(1) requires a plan to monitor, identify and address postmarket cybersecurity vulnerabilities and exploits, including coordinated disclosure, with 524B(b)(2)(A) covering updates and patches on a reasonably justified regular cycle and 524B(b)(2)(B) covering out-of-cycle patches for critical vulnerabilities that could cause uncontrolled risks. Section 524B(b)(3) requires the SBOM, which the guidance asks to be machine-readable, consistent with the October 2021 NTIA minimum elements, and to carry for each component the level of support provided through monitoring and maintenance and the end-of-support date.

After clearance: the cadence

The guidance treats testing as a lifecycle activity rather than a submission artifact.

FDA recommends that cybersecurity testing should occur throughout the SPDF. Security testing early in development can ensure that security issues are addressed prior to impacting release timelines and can prevent the need to redesign or re-engineer the device. After release, cybersecurity testing should be performed at regular intervals commensurate with the risk (e.g., annually) to ensure that potential vulnerabilities are identified and able to be addressed prior to their ability to be exploited.FDA, Cybersecurity in Medical Devices, 3 February 2026, section V.C

The parenthetical is an example, not a rule, and “commensurate with the risk” is the operative phrase. A device whose compromise could affect therapy delivery across a hospital warrants a shorter interval than an unconnected diagnostic reader. The justification for whatever interval you choose belongs in the cybersecurity management plan, which is where the guidance also puts the justification for the regular update cycle.

Modifications

Section VII.D states that a manufacturer required to submit an application under one of the enumerated pathways for a device modification also has to comply with section 524B. What differs is how much information is needed, which turns on whether the change touches cybersecurity.

Changes that may impact cybersecurity “could include changes to authentication or encryption algorithms, new connectivity features, or changing software update process/mechanisms”. Changes unlikely to impact cybersecurity “could include changes in materials, sterilization method changes, or a change to an algorithm without change to architecture/software structure/connectivity”. For the second category the guidance allows a reference to the previously provided plan plus a summary of any changes to it.

That distinction has a direct consequence for test planning. New connectivity or a changed update mechanism is precisely the kind of change that invalidates the interesting parts of an earlier campaign, so the modification submission is the moment the retest has to already be done rather than the moment it gets scheduled.

A short checklist before you submit

• Does the report name the testers, their relationship to the development team and the basis for their competence, on its own pages rather than in a cover email?
• Does the scope statement give a firmware version, an application version, a backend environment, the interfaces covered and the exclusions with reasons?
• Does it give a calendar window and the effort behind it?
• Does the method section name tools with versions and relevant configuration, as footnote 47 contemplates?
• Are all findings present, including those you decided not to fix, each with your own assessment and a rationale where remediation is deferred?
• For deferred issues, does the submission contain the release plan the guidance asks for: which vulnerabilities, anticipated timelines, whether interim devices receive the update, and how long it takes to reach them?
• If a third party did the work, are you submitting their original report rather than your summary of it?
• Do the architecture views and the test scope describe the same device, with the same interfaces and the same boundaries?

Eight questions, all answerable from the report itself. A report that fails any of them is not wrong, but it will generate a deficiency and a cycle of correspondence that the same work, written differently, would have avoided.