Penetration Testing

The single most common cybersecurity testing deficiency in submissions is a scanner report presented as penetration testing. Automated scanning finds known vulnerabilities in network-reachable services. It does not exercise the physical interfaces, the firmware, the wireless stack, the pairing logic, or the business logic of the companion app - which is where medical device weaknesses concentrate.

FDA expects testing to be commensurate with the device's risk and architecture, performed by people with relevant expertise, and documented well enough that a reviewer can see what was actually attempted.

A credible scope covers the full attack surface: hardware interfaces including JTAG, SWD, UART, and exposed test pads; firmware extraction and reverse engineering to look for hardcoded credentials, weak cryptography, and missing secure boot; the wireless stack, most often BLE pairing and bonding, plus Wi-Fi and any proprietary protocol; the mobile or desktop companion application; and the cloud APIs behind it, including authorization logic between tenants.

Provide the tester with the architecture, the threat model, and real hardware they are allowed to destroy. Black-box-only testing of a device you designed wastes budget rediscovering facts you could have handed over on day one.

A report that lists findings by CVSS score is a security deliverable, not a regulatory one. What reviewers need is the mapping: which threats from the model were tested, by what method, with what result, and for anything unresolved, why the residual risk is acceptable in terms of patient harm.

Timing matters as much as quality. Testing scheduled immediately before submission produces findings you cannot remediate, forcing a choice between slipping the filing and documenting risk acceptances that invite questions. Testing early enough to fix, retest, and show closure is what makes the evidence package convincing.