FDA Pen Test Requirements: Timing, Scope and Recency

Why this matters

The FY2025 MDUFA Performance Report lists cybersecurity among the subject-matter expert areas that may be involved in reviewing a device submission. In our experience, the most common pen test problem is not "no pen test", it is "pen test against the wrong build" or "pen test too old to reflect the submitted device." Both are timing problems.

Under Section 524B of the FD&C Act and the Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (Feb 3, 2026 final guidance), the pen test report is one of the artifacts reviewers expect in the submission. If reviewers cannot trace the tested configuration to the submitted configuration, the report does not count, regardless of how thorough it was.

Start reading here if you're earlier in the lifecycle: pen test timing is the last timing question, not the first. If your team is still deciding when cybersecurity work should begin at all, read When to Start Medical Device Cybersecurity in Product Development first, it maps every SPDF activity to its correct design-control phase, so the pen test window in this article lands on a stable foundation.

What the Feb 3, 2026 guidance actually says about pen test timing

The guidance does not specify a calendar window. What it does require is that testing be performed against the device as designed and that the report describe the version under test, the methods used, the findings, and the disposition of each finding. The implication, and the way reviewers apply it in practice, is that the tested version must match the submitted version, with controlled exceptions documented.

The guidance also positions penetration testing inside the broader Secure Product Development Framework (SPDF). Pen testing is the final independent validation that the SPDF actually produced a secure device, which means it has to happen late enough to be meaningful (after design freeze) but early enough that findings can be remediated and re-verified before submission.

What an FDA pen test report must include

Before timing matters, the report itself has to be complete. The Feb 3, 2026 final guidance asks for a penetration test report that documents five things:

1. Tester independence and expertise
2. Scope of testing
3. Duration of testing
4. Testing methods employed
5. Results, findings, and observations

A report missing any of these draws questions no matter how recent it is. Scope is where most reports fall short: reviewers expect the tested attack surface to trace back to the threat model and the architecture views in the same submission. See how we scope and document FDA penetration testing for medical devices.

The four practical timing constraints

1. Recency

The unwritten working standard is 3 to 6 months from test completion to submission. Up to 12 months is sometimes accepted with strong justification (no security-relevant changes, documented change control showing nothing in scope moved). Beyond 12 months you should plan for an AI letter asking for a refresh or expect to refresh proactively.

2. Version-match

The tested firmware, hardware revision, third-party components, and configuration must match what is in the submission. "We tested v1.4.2 and shipped v1.4.5 with three bug fixes" is not automatically a problem, but every delta between tested and submitted versions must be classified for security relevance and documented in the test report's scope statement or in an addendum.

3. Post-change re-test triggers

Re-test (full or scoped) when any of the following happen after the original pen test:

• New or upgraded third-party dependency (especially crypto, TLS, networking, parser libraries)
• Change to authentication, authorization, or session management
• Change to a network interface, protocol, or exposed API
• Change to update mechanism, signing, or rollback behavior
• Fix to a finding from the prior pen test (the fix itself must be verified)
• OS, kernel, or RTOS version change
• Change to the cryptographic module or key management

4. Pre-submission remediation

Every High and Critical finding must be remediated or formally risk-accepted with traceability into the Security Risk Assessment and ISO 14971 risk file. "Will fix postmarket" is not an acceptable disposition for a High at submission. Mediums and Lows can be carried into postmarket with documented justification, but the disposition table needs to be complete.

Where pen testing fits in the submission lifecycle

The clean sequence reviewers expect to see in the documentation:

Threat model + SAVs ─► Design freeze ─► Pen test on final build ─►
Remediation ─► Re-test of fixes (delta) ─► Submission package frozen ─►
eSTAR submission

Common antipatterns that compress this and create timing problems:

• Pen test scheduled too early, against a build that still changes substantially before submission
• Pen test scheduled too late, leaving no time to remediate Highs before the submission deadline
• Pen test scheduled at the right time but on a build that diverges during remediation, with no delta re-test of the final build
• Pen test run by a vendor without medical-device specific scoping, producing IT-network findings that do not match the device's threat model

See also: Medical Device Pen Testing: FDA vs EU MDR 2026, DAST vs Penetration Testing for FDA Submissions, and FDA & AI Pen Testing for Medical Devices.

Most timing failures are calendar failures, not technical failures. Build the pen test window into the program schedule before design freeze, not after.

Talk to us about scoping a pen test for your submission window →

Special cases: IDE, Special 510(k), PMA supplements, Letter-to-File

IDE submissions. Cyber IDE expectations are lighter than premarket clearance, but the same logic applies: the pen test should reflect the investigational device. See our FDA IDE cybersecurity requirements post for what is and is not required at IDE.

Special 510(k) for cybersecurity changes. A Special 510(k) for a cyber change typically requires pen testing scoped to the change. The full prior pen test stays referenced; the new test focuses on the modified attack surface. See Special vs Traditional 510(k) for cybersecurity changes.

PMA supplements. Similar logic to Special 510(k): scope the new test to the change, but reviewers expect more documentation tying the change to the original pen test baseline.

Letter-to-File. A Letter-to-File decision for a cyber change still requires evidence that the change does not invalidate the prior pen test. If the change touches anything on the re-test trigger list above, a Letter-to-File is likely the wrong path. See Letter-to-File vs new 510(k) for cybersecurity changes.

When your pen test is too old: delta re-test vs full re-test

Use this decision logic when the calendar has gotten away from you.

The delta re-test is the most under-used option. It is cheaper and faster than a full re-test, and when scoped correctly it produces evidence reviewers accept. The scoping memo is the artifact that makes or breaks it.

How Blue Goat approaches pen test timing

Blue Goat Cyber's medical device practice is led by engineers with CISSP, OSCP, and prior military red-team backgrounds. We scope pen tests against the submission calendar, not the engineering calendar, so the test runs on the build that ships and the remediation window closes before the eSTAR lock. When a manufacturer comes to us with an aging pen test from another provider, we run the delta-vs-full decision against the change history and produce a scoping memo reviewers can map to the submission.

See our medical device cybersecurity services for the full scope, including pen test case design and choosing the right pen test provider. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity submission support.

FAQ

How recent does a pen test have to be when I submit to the FDA?

There is no hard calendar rule in the Feb 3, 2026 guidance. The working standard reviewers apply is 3 to 6 months from test completion to submission, with up to 12 months sometimes accepted if you can prove no security-relevant changes occurred. Over 12 months almost always draws an Additional Information request asking for a refresh.

Does the pen test need to be on the exact firmware version I'm submitting?

Yes, or close enough that every delta is classified and documented. The pen test report must identify the firmware version, hardware revision, and configuration tested, and reviewers must be able to map those to the submitted device. Small changes can be covered with an addendum and change-control evidence; large changes require a delta or full re-test.

What changes after a pen test require a re-test before submission?

New or upgraded third-party dependencies (especially crypto and TLS), changes to authentication, authorization, network interfaces, exposed APIs, update mechanism, signing, or rollback, fixes to prior pen test findings, and OS, kernel, or RTOS version changes. Any of these should trigger a documented re-test, scoped or full.

Can I submit with open High or Critical findings if I plan to fix them postmarket?

No. High and Critical findings must be remediated or formally risk-accepted with traceability into the Security Risk Assessment and the ISO 14971 risk file before submission. "Will fix postmarket" is not an acceptable disposition for a High or Critical at submission time and is a near-certain deficiency.

What is a delta re-test and when is it enough?

A delta re-test is a pen test scoped to changes made since the original test, plus their dependencies. It is enough when the changes are contained, well-documented, and do not touch broad cross-cutting concerns like authentication, cryptography, or the update path. When the changes are broad or touch the trust model, a full re-test is the right call.

Does a Letter-to-File for a cybersecurity change require a new pen test?

A Letter-to-File still requires evidence that the change does not invalidate prior pen test results. If the change touches anything on the standard re-test trigger list, a Letter-to-File is usually the wrong submission path and a Special 510(k) with a scoped re-test is the cleaner option.

CTA

If you have a submission window in the next 90 days and your pen test is older than 6 months, the safest move is a scoping conversation now, not after the AI letter arrives. We will run the delta-vs-full decision and produce a test plan that matches your submission calendar. Schedule a discovery session →

More on this topic

• Medical Device Pen Testing: FDA vs EU MDR 2026