FDA Pen Test Timing: How Recent Does Your Penetration Test Need to Be at Submission?

Key Takeaways

• There is no statutory "X days old" rule, but the working standard reviewers apply is 3 to 6 months, with 12 months as the outside edge before an AI letter becomes likely.
• Version-match matters more than calendar age. A 2-month-old pen test against a stale build is worse than a 5-month-old test against the exact submitted version.
• Any security-relevant change after the test (new dependency, crypto change, interface change, fixed vulnerability, OS or kernel update) triggers a documented re-test, scoped or full.
• Open High or Critical findings at submission time are a near-certain deficiency. Remediation or formal risk acceptance must be complete and traceable into the Security Risk Assessment.
• IDE, Special 510(k) for cyber changes, and PMA supplements each have their own timing nuances. Letter-to-File decisions still require evidence that the change does not invalidate prior pen test results.

Table of Contents

• What the Feb 3, 2026 guidance actually says about pen test timing
• The four practical timing constraints
• Where pen testing fits in the submission lifecycle
• Special cases: IDE, Special 510(k), PMA supplements, Letter-to-File
• When your pen test is too old: delta re-test vs full re-test
• How Blue Goat approaches pen test timing

Why this matters

Cybersecurity testing is one of the top deficiency categories cited in CDRH Additional Information letters, behind only software documentation and clinical evidence per the FDA's FY2024 CDRH performance reporting. Within that category, the most common pattern 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 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.

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.

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

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

See also: DAST vs Penetration Testing: What the FDA Requires, Does the FDA Accept AI Pen Testing for Medical Devices?, and FDA Penetration Testing Requirements for Medical Devices.

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.

Situation	Recommended action
Test under 6 months old, no security-relevant changes	Use as-is; document version-match in the report scope
Test 6 to 12 months old, no changes	Add a written re-confirmation memo from the test provider and a change-control attestation; submit
Test over 12 months old, no changes	Scoped re-test focused on regression and any new public CVEs against the SBOM
Any age, contained security-relevant changes to known modules	Delta re-test scoped to changed modules and their dependencies
Any age, broad changes (auth, crypto, networking, update path)	Full re-test on the final build
Open Highs or Criticals at submission deadline	Do not submit; remediate and run a verification re-test first

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.

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 →

About the author

Christian Espinosa, CISSP, Founder, Blue Goat Cyber. Christian leads a team focused exclusively on medical device cybersecurity for FDA premarket submissions and postmarket compliance, including pen test scoping and remediation planning against the submission calendar. Read more about Christian.