Letter to File vs New 510(k) for Cybersecurity Changes

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.

Key Takeaways

• A letter to file is a DHF-internal justification; the FDA does not see it unless they ask in an inspection or after an incident.
• The controlling document is still the FDA's 2017 Deciding When to Submit a 510(k) for a Change guidance, layered on top of 21 CFR 807.81(a)(3).
• Cybersecurity changes that do not alter the threat model, attack surface, crypto, authentication, or interfaces usually stay letter to file.
• Cybersecurity changes that do alter any of the above usually require a new 510(k) - Special if your own device, Traditional if the security risk profile materially shifts.
• Section 524B does not move the threshold, but it raises the consequences of a bad call: misclassified cyber changes can become enforcement findings.
• A Pre-Sub (Q-Sub) is the cheapest way to confirm a borderline call before you commit to letter to file.

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:

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 design controls per 21 CFR 820.30, 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.

FAQs

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.

Does the FDA review my letters to file? Not proactively. They become visible during inspections, recall investigations, or postmarket reviews triggered under Section 524B. At that point they either defend the call or become findings.

If I am unsure, should I default to filing? No. Default to a Pre-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 this interact with the Feb 3, 2026 the FDA premarket cybersecurity guidance? 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.