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 the 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) made cybersecurity documentation a gating criterion for clearance under Section 524B of the FD&C Act. 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.

Gaps in this area are the single most common driver 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 a Section 524B postmarket 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" is a strong signal that a new 510(k) is needed. Multiple yeses make the letter-to-file path indefensible.

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., reducing default logging verbosity, 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 Almost Always Require a New 510(k)

These are the calls where letter to file is the wrong answer:

• 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).

For most of these, a Special 510(k) is the right pathway if the change is well-scoped. 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(b) did not move the letter-to-file threshold. It did three things that make a bad call far more expensive:

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

1. Created an explicit cybersecurity bar at premarket. A change you justified as letter-to-file in 2022 might no longer meet current the FDA expectations for what a cleared device's security baseline looks like.
2. Created postmarket monitoring obligations (SBOM maintenance, vulnerability disclosure, patch cadence). A change that breaks one of these implicit commitments is now visible to the FDA without an inspection.
3. Created a clear basis for enforcement. A device that ships with a misclassified cyber change is now demonstrably non-compliant with a specific statutory provision, not just a guidance document.

A letter to file that would have been a 483 observation under the old regime can now be a Warning Letter or recall under the new one.

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). Any of those is cheaper than an RTA on a misclassified submission or a postmarket enforcement action.

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 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

When does a cybersecurity change qualify as a letter to file vs a new 510(k)?

A cybersecurity change stays letter to file when it does not alter the device's threat model, attack surface, cryptographic implementation, authentication, or external interfaces, typically like-for-like patches inside an already-cleared update mechanism. It requires a new 510(k) when any of those shift, because the FDA's 2017 Deciding When to Submit a 510(k) for a Change to an Existing Device guidance treats those shifts as significantly affecting safety or effectiveness.

Is a CVE patch always letter to file?

No. A patch that changes interfaces, adds new dependencies, or alters the trust boundary is a new 510(k) candidate even if its purpose is remediation. The intent of the change does not determine the regulatory path, the impact does. A patch that swaps a vulnerable TLS library for a different library with a different API is rarely letter to file, regardless of the CVE it closes.

Does the FDA review my letters to file?

Not proactively. Letters to file are internal DHF records the FDA does not see unless an inspection, recall investigation, or postmarket review under Section 524B brings them into scope. At that point they either defend the call or become findings, so the documentation quality at the time you wrote them is what determines the outcome.

If I am unsure, should I default to filing a 510(k)?

No. Default to a Pre-Sub (Q-Sub). Filing a 510(k) for a change that did not require one wastes review capacity and locks the device into a longer change cycle. Filing a letter to file when you needed a 510(k) creates an enforcement risk. The Pre-Sub is the only path that resolves the ambiguity at low cost.

How does the February 3, 2026 FDA premarket cybersecurity guidance change letter-to-file decisions?

The 2026 guidance defines what a cleared device's cybersecurity baseline looks like. A change that drifts the device away from that baseline is harder to justify as letter to file even if the 2017 guidance flowchart would have allowed it before. Treat the 2026 guidance as a ceiling on what letter to file can absorb.

What documentation does a cyber-change letter to file need?

At minimum: the change description, the threat-model delta (or a statement that the threat model is unchanged with justification), the verification evidence, the 2017 guidance flowchart with each decision node answered, and a signed regulatory rationale. Letters that skip the flowchart walk-through are the ones that fail inspection.

More on this topic

• Does Device Class Decide FDA