Letter to File vs New 510(k)

If you maintain a cleared medical device, the question that comes up every sprint is not which 510(k) to file. It is whether you have to file one at all.

The 2017 FDA flowchart was written before Section 524B. The decision logic still controls, but the stakes of getting a cybersecurity call wrong are now an enforcement and recall risk - not just a paperwork miss.

Why this matters

Changing a cleared or approved device? Start with the device changes decision guide, then see PMA supplement cybersecurity changes and Special vs Traditional 510(k).

The FDA's Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (Feb 3, 2026 final guidance) provides nonbinding recommendations for cybersecurity evidence and aligns with the QMSR. Section 524B of the FD&C Act separately establishes binding obligations for cyber devices in applicable premarket submissions. Reviewers now apply this guidance to letter to file vs new 510(k) for cybersecurity changes the same way they apply software lifecycle expectations from IEC 62304 and security risk-management expectations from AAMI TIR57 and ANSI/AAMI SW96:2023.

In our experience, gaps in this area are among the most common drivers of first-cycle cybersecurity Additional Information (AI) requests. The FDA's FY2025 MDUFA Performance Report lists cybersecurity among the subject-matter expert areas that may be involved in reviewing a device submission, alongside sterility, biocompatibility, and software. Treating it as a checklist exercise rather than a design-controlled engineering artifact is what creates the gap.

What a Letter to File Actually Is

A letter to file is a document inside your DHF that records:

1. The change being made.
2. The regulatory rationale for not submitting a new 510(k).
3. The risk-based evidence supporting that rationale - design controls, verification, validation, and (for cyber) threat-model and security-risk-assessment deltas.
4. The approvers and the date.

It is not filed with the FDA. The FDA encounters it during a routine inspection, a for-cause inspection after an adverse event, a recall investigation, or another regulatory review. At that point your rationale either holds up or it becomes a 483 observation.

The Decision Framework, Reframed for Cyber

The 2017 guidance asks, for every change, whether it could significantly affect the safety or effectiveness of the device. For a cybersecurity change, translate that into five concrete questions:

1. Does the change alter the threat model? (New actors, new attack vectors, new trust boundaries.)
2. Does it change the attack surface? (New interfaces, new protocols, new exposed services.)
3. Does it change the cryptographic posture? (New algorithms, new key lengths, new key management, removed crypto.)
4. Does it change the authentication or authorization model? (New auth mechanisms, removed MFA, new roles.)
5. Does it change the intended use or use environment? (Adding remote access, cloud dependency, third-party integration.)

Any "yes" calls for further assessment under the applicable FDA device-change and software-change guidance. It does not, by itself, require a new 510(k).

Changes That Usually Stay Letter to File

Assuming your DHF backs them up and the change-control record is clean:

• Like-for-like patches of an existing component to the next minor version, with no API or interface change.
• Signed firmware updates delivered through an already-cleared update mechanism with no change to the mechanism itself.
• VEX status updates for SBOM components - changing a vulnerability from under_investigation to not_affected with justification.
• Documentation-only SBOM refreshes when component versions are updated but no functional change ships.
• Security configuration hardening that tightens existing controls without changing interfaces (e.g., increasing appropriate security-event logging, disabling an unused but already-cleared service).
• CVE response patches that remediate a vulnerability in an existing component without changing functionality, interface, or threat model.

In each case the letter to file should still include a threat-model delta statement ("no change") and a security-risk-assessment delta - even if the conclusion is "no new risk introduced."

Changes That Need Careful 510(k) Assessment

These changes need a documented safety, effectiveness, and intended-use assessment; an internal record may still be appropriate:

• New cryptographic algorithms or key infrastructure (e.g., migrating from RSA to ECC, adding post-quantum primitives).
• New authentication mechanisms (adding SSO, removing MFA, changing from password to certificate-based auth).
• New wireless or remote-access paths (adding BLE, Wi-Fi, cellular, or a cloud sync path).
• Secure Boot added or removed, or chain-of-trust restructured.
• New third-party components that materially change the attack surface or pull in unfamiliar transitive dependencies.
• Intended-use-adjacent changes that enable remote operation, remote diagnostics, or new data flows.
• Replacing an end-of-support OS or runtime (e.g., Windows 10 IoT to Windows 11 IoT, or moving from a deprecated RTOS to a new one).

If a new submission is needed, assess Special 510(k) eligibility, including whether established evaluation methods can support review of results in summary or risk-analysis form. The Special vs Traditional call is covered in a separate post in this cluster.

The Gray Zone

Real-world cybersecurity changes are rarely clean. Common gray-zone cases:

• TLS version bumps (1.2 to 1.3) with no other change. Usually letter to file if the cipher suite policy and certificate handling are unchanged. New submission if you are deprecating ciphers the labeling claimed support for.
• SBOM component swaps for end-of-support libraries where the replacement is functionally equivalent. Letter to file if the API surface is identical and the new component is in the same trust boundary. New 510(k) if the replacement introduces new transitive dependencies or runs in a different process context.
• Cloud backend changes that do not touch the device firmware. Letter to file is tempting, but if the device's security claims depended on the old backend's controls, the change can re-enter device scope.
• Adding a CVD or VDP process to an already-cleared device. Process-only changes usually stay letter to file, but Section 524B postmarket expectations may already require this regardless.

For each gray-zone case, document:

• The threat model before and after, with a delta.
• The security risk assessment before and after, with a delta.
• The verification and regression test evidence.
• A defensible written rationale tied to the 2017 guidance flowchart.

How Section 524B Changes the Stakes

Section 524B does not change the new-510(k) threshold in 21 CFR 807.81(a)(3), and it does not apply retroactively to every fielded device. When a qualifying new submission is required for a cyber device, the sponsor must address Section 524B's monitoring and coordinated vulnerability disclosure plan, cybersecurity and patching processes, and SBOM submission requirements.

See also: Special vs Traditional 510(k), FDA 510(k) & PMA Cybersecurity Guide, and Indications for Use, Predicates, and Cybersecurity Scope.

Document change decisions under the QMSR, including ISO 13485:2016 design and development records where applicable. Reporting and correction obligations under 21 CFR Parts 803 and 806 must be evaluated separately; an internal change record neither replaces those obligations nor automatically causes enforcement action.

Pre-Sub as the De-Risker

If the call is borderline, a Pre-Submission is the cheapest insurance available. A focused Pre-Sub for a cybersecurity change should include:

• A one-paragraph description of the change.
• The threat model delta.
• The security risk assessment delta.
• The proposed verification and regression test evidence.
• A direct question: "Does the FDA agree that the change described above does not require a new 510(k) and can be managed under our design controls per ISO 13485 clause 7.3 as incorporated by the QMSR, supported by the documented threat-model and security-risk-assessment deltas?"

The FDA can answer with a path-confirmation, a request for a Special 510(k), or a request for a Traditional 510(k). Feedback can reduce uncertainty, but it is nonbinding. eSTAR submissions undergo technical screening rather than the RTA checklist.

What to Put in the Letter to File for a Cyber Change

When letter to file is the right call, the document should contain at minimum:

• Change description and scope.
• Reference to the 2017 Deciding When to Submit a 510(k) for a Change guidance and the specific flowchart branch followed.
• Threat model delta (or "no change" statement).
• Security risk assessment delta (or "no change" statement).
• SBOM diff and VEX delta if any components changed.
• Verification and regression test summary.
• Cybersecurity labeling impact assessment (does the change require any update to user-facing security documentation).
• Approver signatures and date.

A thin letter to file - one paragraph and an approver name - is the document that gets you a Warning Letter. A thorough one is the document that defends the call.

Reviewer and Inspector Red Flags

These patterns draw scrutiny in an inspection or postmarket review:

• A run of letter-to-file decisions on cybersecurity changes with no threat-model delta documentation.
• Letter-to-file decisions on changes that touched crypto, auth, or interfaces.
• Letter-to-file decisions made without security engineering signoff.
• A pattern of letter-to-file followed by a postmarket incident that exploited the changed code.
• Letter-to-file rationale that cites only the 2017 guidance without referencing the device's specific security risk assessment.

If the change does need a new 510(k), Special vs Traditional 510(k) covers which type to file.

How Blue Goat approaches this

Blue Goat Cyber's medical device practice is led by engineers with CISSP, OSCP, and prior military red-team backgrounds. We treat cybersecurity documentation as design-controlled engineering output, not a submission template, every artifact (threat model, SBOM, security risk assessment, penetration test, labeling) traces back to a controlled requirement and a verified result.

Our engagements deliver the full Feb 3, 2026 guidance documentation set scoped to the device's risk profile, integrated with the existing IEC 62304 software lifecycle and ISO 14971 risk file. See our medical device cybersecurity services for the full scope. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

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

Need help deciding, change by change, whether a new submission is needed? See our medical device security advisory.

Related reading: Indications for Use, Predicates, and 510(k) Cybersecurity Scope.

FAQ

More on this topic

• Does Device Class Decide FDA