Penetration Testing Scope for FDA Submissions: A 510(k) / De Novo / PMA Guide

Talk to a MedTech cybersecurity expert

What "full attack surface" means

FDA's 2026 final premarket cybersecurity guidance expects the test report to demonstrate coverage of every interface a threat actor could reach. In practice, that means six distinct test domains:

• Firmware - secure boot, debug interfaces (JTAG/SWD/UART), update integrity, key storage, runtime integrity.
• Hardware - chip-level attack surface, side channels, fault injection where relevant to threat model.
• Wireless - BLE, Wi-Fi, cellular, NFC, proprietary RF. Pairing, encryption, GATT permissions, rogue-AP scenarios.
• Mobile companion app - iOS and Android: storage, transport, IPC, biometric handling, jailbreak/root checks.
• APIs - REST/GraphQL endpoints: authn, authz, IDOR, mass assignment, rate limiting, BAA-relevant logging.
• Cloud backend - tenancy isolation, IAM configuration, key management, logging integrity, data export paths.

White-box vs black-box: why white-box wins for FDA

The 2026 guidance says reviewers expect testers to leverage source code, threat models, and architecture documentation. That is white-box testing by definition. Black-box testing simulates an external attacker but consistently misses logic flaws in firmware update validation, key management, secure boot, and inter-component trust assumptions - exactly the controls that matter for patient safety. Default to white-box for premarket, reserve black-box for adversary-simulation scenarios after clearance.

Scope by submission pathway

510(k)

Full attack surface, white-box. Test plan should explicitly compare the cybersecurity attack surface to the predicate device, especially where you have added connectivity, mobile, or cloud beyond the predicate's footprint. Reviewers cite 'predicate divergence not addressed' often.

De Novo

Full attack surface, white-box, plus an architectural-justification section because there is no predicate. The pen test report should map findings against the security architecture you proposed in the De Novo classification request.

PMA

Deepest documentation requirement. Pen test evidence flows into the design history file with full traceability. PMA reviewers frequently coordinate with non-cyber reviewers (risk management, human factors) so the pen test report should be cross-referenced from the security risk assessment and the ISO 14971 risk file.

IDE

Scope focuses on whether unresolved cybersecurity risks could expose study subjects to unreasonable risk under 21 CFR §812.42. Pen testing must validate that compensating controls in the clinical environment are sufficient before enrollment.

The Letter of Attestation

A signed document from the testing firm stating that testing was conducted in accordance with the FDA premarket cybersecurity guidance, that the full attack surface was covered, and that every finding has been remediated or formally risk-accepted. Reviewers look for it because it confirms the test meets FDA-specific expectations rather than general IT-security best practice. Without one, expect a deficiency.

What a reviewer-ready report contains

1. Executive summary with risk-rated findings and Letter of Attestation reference.
2. Methodology section documenting white-box approach, tools, and standards (NIST SP 800-115, OWASP MASVS, OWASP ASVS, OWASP API Top 10).
3. Attack surface inventory with coverage notes per interface.
4. Findings written with severity (CVSS + clinical impact under ISO 14971), reproduction steps, evidence (screenshots, packet captures, code references), remediation, status.
5. Traceability appendix linking findings back to threat-model entries.
6. Signed Letter of Attestation.

Scope mistakes that get cited

• Mobile app tested but not in source-leveraged white-box mode (jailbreak detection bypassed in 30 minutes during reviewer follow-up).
• Cloud testing limited to OWASP API Top 10 scan - no tenancy or IAM validation.
• Wireless tested in protocol stack only, not at the radio layer.
• Firmware tested via released binary - secure boot and key storage not exercised.
• No Letter of Attestation - or a Letter that does not enumerate scope.

Frequently asked questions

Can the test be scoped to one attack surface, like firmware only?

How long does a full-coverage engagement take?

What standards should the methodology cite?

Do you need our source code?

How is medical device pen testing different from IT pen testing?

Is retesting included?

Can a single report support FDA, EU MDR, and IEC 81001-5-1?

Do you test in clinical environments?

What about AI/ML model components?

What is the typical fixed-fee range?

Writing the scope statement so it survives review

The scope statement is the first thing a reviewer reads in your test report and the most common place a package loses credibility. A weak statement names a product ("the XYZ System"); a strong one enumerates targets, versions, and access levels.

A workable structure:

• Targets, individually named. Firmware version and build ID, mobile app versions for each platform, cloud API endpoints and environment, service and debug interfaces, wireless protocols in use, and any hardware interfaces physically accessible on the device.
• Access level per target. Whether testers had source, credentials, design documents, and hardware samples. State the number of physical units provided; hardware attacks that require destructive analysis are impossible with a single loaner.
• Explicit exclusions with rationale. Anything not tested, and why. An exclusion with a reason is a scoping decision. An exclusion discovered by the reviewer is a gap.
• Traceability to the threat model. The scope should reference the threat IDs the test was designed to exercise, which is what turns a generic security assessment into evidence for this submission.

Depth of evidence, not just breadth

Reviewers increasingly distinguish between a scan and a test. Automated vulnerability scanning, fuzzing, and static analysis are separate expectations from penetration testing, and a report that presents scanner output as penetration testing draws a deficiency for missing manual assessment.

What manual testing looks like in the report: attack narratives with the steps taken, the observed behavior, and the evidence captured; attempts that failed and why they failed, because negative results are how a reviewer knows a control was actually exercised; and reproduction detail sufficient for your own engineers to replicate the finding.

The most useful section in a mature report is the one describing controls that held. "Attempted firmware downgrade to v1.8 via the update channel; rejected by rollback protection with signature version check; see evidence 4.3" does more for a submission than five informational findings.

Independence, and what it actually requires

The guidance expects testing independent of the design team. Independence is not only about hiring an outside firm. An internal team can qualify if it does not report to engineering leadership, did not participate in design decisions, and has authority to publish findings without design-team approval. Document which arrangement you used and how independence is preserved, because reviewers ask when the tester shares a company name with the manufacturer.

Retesting matters as much as the original test. When findings are remediated, a focused retest of those findings, documented separately, is what closes the loop. A remediation table with no retest evidence leaves the reviewer with your word for it.

Where to go next

Scoping is where penetration testing budgets are won or lost. A test scoped too narrowly produces a clean report that a reviewer does not believe. A test scoped without reference to the threat model produces findings nobody can tie to a claim. Both cost more than getting the scope right the first time.

Start from the interface inventory, not the price. List every way data or commands enter and leave the system: wireless radios, physical ports, the mobile application, the cloud API, the clinician portal, the update channel, the service and diagnostic interface, and any hardware debug path that ships enabled. For each one, decide tested, not tested, or tested with limitations, and write the reason. That table becomes your scope statement, and it is the single artifact reviewers use to judge whether your testing was adequate.

Then match depth to the interface. A BLE pairing implementation needs radio-level testing with real hardware, not a protocol review. Firmware needs extraction and analysis, including a look for hardcoded credentials, debug interfaces, and signature verification on the update path. A cloud backend handling PHI needs authenticated and unauthenticated testing plus authorization boundary work between tenants. Applying the same generic web-application methodology to all of them is the most common way a report ends up looking thin.

Sequence testing so remediation fits. Findings arrive, get fixed, and get retested, and the retest has to appear in the final report. Teams that book a single test window with no retest budget end up filing a report with open findings and a promise, which invites questions.

Establish independence explicitly. The tester should not be the person who wrote the code being tested, and the report should state the basis for that separation. Internal teams can satisfy this if the organizational separation is real and documented.

Finally, write the scope statement before testing begins and attach it to the report. A scope agreed after results exist always reads that way.

• Medical Device Penetration Testing Service - full-system manual testing scoped from your threat model, with remediation retest included.
• BLE & RF Penetration Testing - radio-level work on pairing, key handling, and traffic protection for wireless devices.
• Firmware Penetration Testing - extraction, binary analysis, secure boot and update chain verification.
• PHI Cloud Backend Penetration Testing - API authorization, tenant isolation, and data protection testing for the backend the device talks to.