Join Essenvia at RAPS Convergence 2026 — Booth #918
· Charlotte, 15–17 September
Read more →
Letter to file, or new 510(k)? Working through FDA's change guidance
FDA's Change assessment framework
By Soumya Mahapatra
Background
The design change is approved and engineering wants it in the build in six weeks. The decision expected from the regulatory is one question: does this go to file, or does it go to FDA for a new submission ? For most changes the answer is obvious within a minute. For the rest, the guidance narrows the question without closing it, and the work is in the rationale you write rather than the box you tick.
Which guidance governs
Two FDA guidances split the ground between them, both issued the same day:
Deciding When to Submit a 510(k) for a Change to an Existing Device, issued October 25, 2017. It supersedes the January 10, 1997 version of the same title, and remains the current version.
Deciding When to Submit a 510(k) for a Software Change to an Existing Device, issued October 25, 2017, and also current.
They are not alternatives. A change that alters software and touches labeling or hardware runs through both, and the guidances say so: each directs manufacturers to apply all applicable sections when a change is of more than one type.
A third document matters if you have one: Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions, issued August 18, 2025, originally issued December 4, 2024, and current. A modification specified in an authorized PCCP and implemented in conformance with its Modification Protocol does not trigger a new marketing submission. Deviate from the protocol and you are back to the ordinary threshold. A companion guidance, Predetermined Change Control Plans for Medical Devices, issued August 22, 2024, extends the same policy beyond AI-enabled device software functions. It remains a draft, marked not for implementation, and it states that on finalization FDA will make conforming Level 2 updates to both guidances above.
The threshold, and three things that can go wrong
A new 510(k) is required for "[a] change or modification in the device that could significantly affect the safety or effectiveness of the device" or "[a] major change or modification in the intended use of the device." The regulation names design, material, chemical composition, energy source and manufacturing process as examples. The effect can be positive or negative — an improvement can cross the threshold as readily as a degradation. It is also not only about harm: common risk analysis methods define risk in terms of device harms and their effect on safety, but the threshold covers effectiveness as well. That is why the guidance uses the distinct term "risk-based assessment" rather than risk analysis — a harm-only analysis answers half the question.
Wrong comparative device. The assessment compares the modified device to the most recently cleared version — what the guidance calls the original device — not to the version currently in production. For a preamendments device or one granted marketing authorization through De Novo, the comparator is that device instead. Every change is measured back to that same baseline, however many changes have gone to file since.
Changes assessed only one at a time. Where many changes arrive at once, each is assessed separately, as well as in aggregate. Individually minor changes can cross the threshold together, and when their cumulative effect crosses it, the change goes to FDA.
Treating verification as the decision. If the risk-based assessment concludes the change could significantly affect safety or effectiveness, clean verification and validation results do not move it back to file. The relationship runs one way. Unexpected V&V results should force reconsideration of a decision to document — B5.4 for non-IVDs, D4 for IVDs — but successful routine V&V cannot rescue a decision to submit. "Routine" here means the original design verification and validation activities used to assess the original device design, not an expanded test programme assembled for this change.
Intent sits above all of this. A change made with the intent to significantly affect safety or effectiveness — to significantly improve clinical outcomes, to mitigate a known risk, in response to adverse events — is treated as a change that could do so, and a new 510(k) is likely required regardless of where the flowcharts land. The converse does not hold. A change not intended to affect safety or effectiveness still has to be evaluated for whether it could.
Where the decision actually gets made
Change | Assessed under | The question that usually decides it |
Indications for use wording | Flowchart A (A1 → A1.1–A1.5) | Single use to reusable, and Rx to OTC, are automatic. Otherwise: does it describe a new disease, condition or patient population? |
Contraindications | A2 | Adding or deleting one. Adding a contraindication as the only change is identified for a CBE 510(k) |
Warnings, precautions, directions for use | A3, A4 | Does a risk-based assessment identify new or significantly modified risks? |
Control mechanism, operating principle, energy type | B2 | Whether it is one of these at all — almost all such changes go to FDA |
Sterilization, cleaning, disinfection | B3 → B3.1, B3.2 | Category B or novel method, lowered SAL, or a change in how the device is provided |
Packaging or expiration dating | B4 → B4.1 | Is the same method or protocol described in a previous 510(k) used to support it? |
Other design changes — dimensions, performance specifications, components, user interface | B5 → B5.1–B5.4 | Does it significantly affect use, introduce new or significantly modified risks, or make clinical data necessary? |
Materials, including supplier changes | C2 → C5 | New or increased biocompatibility risk, and whether the same material is already used in a similar legally marketed device. If the change could affect performance specifications, C5 routes you back to B5 |
IVD technology, performance and materials | Flowchart D (D1 → D4) | Operating principle, then any device-specific final guidance or classification regulation, then risk-based assessment |
Software | Software guidance, Questions 1–4 | Two "solely" exits first — cybersecurity only, or return to the cleared specification. Then whether it creates or modifies a risk control for a hazardous situation that could result in significant harm. A "no" at Question 4 still routes through the Section VI factors |
Anything not covered above | Section E | Your own risk-based assessment, documented |
The flowcharts are a visual aid and do not carry every consideration; each one has companion text that governs.
Four use cases that are not straightforward
A supplier change that stays inside the material specification. The incoming material meets the same spec. It reads like a letter to file — until you notice the guidance treats a change in supplier, or in a supplier's processing or finishing steps, as a material change even when the result remains within the original material specification. Changes made by your existing supplier count too, not just moves from one supplier to another. Biocompatibility and physical properties depend not only on the material but on how it is processed, the manufacturing methods including sterilization, and the manufacturing residuals left on the finished device. The decision then turns on C4 and C4.1: does the risk assessment identify new or increased biocompatibility concerns, and have you used this material — same formulation, same processing, same type and duration of contact — in one of your own similar legally marketed devices cleared or approved by the FDA. Same polymer, different sterilant, is a different material for this purpose. The biocompatibility assessment itself runs on FDA's ISO 10993-1 guidance.
A refactor with no change to functionality. Refactoring restructures a program's internal structure without changing its clinical performance specification; reengineering reconstitutes the software in a new form and is usually broader. Minor modifications that improve maintainability within the existing specification context are unlikely to require submission. A significant re-write likely does, because of the impact on performance and on risk controls. The guidance names the deciding factors — the complexity of the change, and its effect on risk controls or performance — but no threshold separates the two ends, and a complete rewrite of a core algorithm may require a new 510(k) even with identical performance claims and risk profile. Two further signals help: the extent of change to verification and validation scripts, and whether the architecture is modular enough to bound the blast radius. Neither is decisive, and manufacturers are encouraged to discuss these gray areas with the division that cleared the device.
A security patch that also fixes a defect. Question 1 of the software flowchart asks whether the change is made solely to strengthen cybersecurity with no other impact on the software or device. "Solely" carries the whole question. Patch a vulnerability and, in the same release, correct an unrelated anomaly, and you are not at Question 1 — you have two changes, each assessed on its own and together. The tidy answer is not that the release is a submission; it is that the release contains changes that answer different questions.
The fourth letter to file in eighteen months. Take an implantable pulse generator with four changes over that period. A battery component moved to a second supplier. The firmware algorithm estimating remaining capacity was revised. A manufacturing tolerance affecting current consumption changed. Each assessment concluded, reasonably on its own, that the change did not materially affect safety or effectiveness.
The fourth change looked trivial: an adjustment to the threshold at which the device declares elective replacement. The engineer compared the new threshold against the device currently in production, found a small difference, and documented it and missed the comparative device.
That production device already carried the new battery component, the revised estimation algorithm and the changed current-consumption profile. Measured against the last cleared device instead, discharge characteristics had shifted, the algorithm read the discharge curve differently, average current had moved — and now the replacement threshold was moving too. Together they could alter the relationship between the displayed replacement indication and the therapy time actually remaining. The fourth letter was not a problem because the fourth change was large. It was a problem because it showed the baseline had migrated.
What a defensible letter to file contains
FDA's documentation appendix lists the elements. Highlighting the flowcharts, or answering yes or no to each question without justification, is not sufficient documentation — the file has to let an investigator or a third party follow both the change and the reasoning.
Element | Pitfalls for Auditor Review |
Product name | Model or configuration ambiguity — which variant the assessment covers is unstated |
Date of change assessment | Dated after implementation |
Description of the device | Describes the product line, not the cleared configuration |
Description of the change | Written from the engineering change order, so the regulatory-relevant detail is missing |
Reason for the change | Says "customer feedback" where the real driver was a complaint trend — which raises the intent question |
Applicable regulatory history, including the 510(k) number of the most recently cleared version | Cites the original clearance rather than the most recent one |
Comparison of the modified device to the most recently cleared version | Compared to the current build. This is the one that fails most often |
Applicable elements of the guidance, including the specific questions | Reproduces the flowchart with ticks and no reasoning |
Analysis and conclusion | States the conclusion and missed the analysis |
References to supporting documents, particularly the risk analysis | Points to a risk file that was not updated for this change |
Signatures | Approved by design, not by regulatory |
What to do Monday
Pull your three most recent letters to file. For each, find the sentence that names the comparator device and its 510(k) number. If that sentence is missing, or if it names the previously modified version rather than the most recently cleared one, you have a re-baselining problem that is cheaper to fix now than to explain later. Then check whether the changes were assessed in aggregate as well as individually — that pairing is where accumulated letters to file most often turn out to have crossed the threshold together.
Background
The design change is approved and engineering wants it in the build in six weeks. The decision expected from the regulatory is one question: does this go to file, or does it go to FDA for a new submission ? For most changes the answer is obvious within a minute. For the rest, the guidance narrows the question without closing it, and the work is in the rationale you write rather than the box you tick.
Which guidance governs
Two FDA guidances split the ground between them, both issued the same day:
Deciding When to Submit a 510(k) for a Change to an Existing Device, issued October 25, 2017. It supersedes the January 10, 1997 version of the same title, and remains the current version.
Deciding When to Submit a 510(k) for a Software Change to an Existing Device, issued October 25, 2017, and also current.
They are not alternatives. A change that alters software and touches labeling or hardware runs through both, and the guidances say so: each directs manufacturers to apply all applicable sections when a change is of more than one type.
A third document matters if you have one: Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions, issued August 18, 2025, originally issued December 4, 2024, and current. A modification specified in an authorized PCCP and implemented in conformance with its Modification Protocol does not trigger a new marketing submission. Deviate from the protocol and you are back to the ordinary threshold. A companion guidance, Predetermined Change Control Plans for Medical Devices, issued August 22, 2024, extends the same policy beyond AI-enabled device software functions. It remains a draft, marked not for implementation, and it states that on finalization FDA will make conforming Level 2 updates to both guidances above.
The threshold, and three things that can go wrong
A new 510(k) is required for "[a] change or modification in the device that could significantly affect the safety or effectiveness of the device" or "[a] major change or modification in the intended use of the device." The regulation names design, material, chemical composition, energy source and manufacturing process as examples. The effect can be positive or negative — an improvement can cross the threshold as readily as a degradation. It is also not only about harm: common risk analysis methods define risk in terms of device harms and their effect on safety, but the threshold covers effectiveness as well. That is why the guidance uses the distinct term "risk-based assessment" rather than risk analysis — a harm-only analysis answers half the question.
Wrong comparative device. The assessment compares the modified device to the most recently cleared version — what the guidance calls the original device — not to the version currently in production. For a preamendments device or one granted marketing authorization through De Novo, the comparator is that device instead. Every change is measured back to that same baseline, however many changes have gone to file since.
Changes assessed only one at a time. Where many changes arrive at once, each is assessed separately, as well as in aggregate. Individually minor changes can cross the threshold together, and when their cumulative effect crosses it, the change goes to FDA.
Treating verification as the decision. If the risk-based assessment concludes the change could significantly affect safety or effectiveness, clean verification and validation results do not move it back to file. The relationship runs one way. Unexpected V&V results should force reconsideration of a decision to document — B5.4 for non-IVDs, D4 for IVDs — but successful routine V&V cannot rescue a decision to submit. "Routine" here means the original design verification and validation activities used to assess the original device design, not an expanded test programme assembled for this change.
Intent sits above all of this. A change made with the intent to significantly affect safety or effectiveness — to significantly improve clinical outcomes, to mitigate a known risk, in response to adverse events — is treated as a change that could do so, and a new 510(k) is likely required regardless of where the flowcharts land. The converse does not hold. A change not intended to affect safety or effectiveness still has to be evaluated for whether it could.
Where the decision actually gets made
Change | Assessed under | The question that usually decides it |
Indications for use wording | Flowchart A (A1 → A1.1–A1.5) | Single use to reusable, and Rx to OTC, are automatic. Otherwise: does it describe a new disease, condition or patient population? |
Contraindications | A2 | Adding or deleting one. Adding a contraindication as the only change is identified for a CBE 510(k) |
Warnings, precautions, directions for use | A3, A4 | Does a risk-based assessment identify new or significantly modified risks? |
Control mechanism, operating principle, energy type | B2 | Whether it is one of these at all — almost all such changes go to FDA |
Sterilization, cleaning, disinfection | B3 → B3.1, B3.2 | Category B or novel method, lowered SAL, or a change in how the device is provided |
Packaging or expiration dating | B4 → B4.1 | Is the same method or protocol described in a previous 510(k) used to support it? |
Other design changes — dimensions, performance specifications, components, user interface | B5 → B5.1–B5.4 | Does it significantly affect use, introduce new or significantly modified risks, or make clinical data necessary? |
Materials, including supplier changes | C2 → C5 | New or increased biocompatibility risk, and whether the same material is already used in a similar legally marketed device. If the change could affect performance specifications, C5 routes you back to B5 |
IVD technology, performance and materials | Flowchart D (D1 → D4) | Operating principle, then any device-specific final guidance or classification regulation, then risk-based assessment |
Software | Software guidance, Questions 1–4 | Two "solely" exits first — cybersecurity only, or return to the cleared specification. Then whether it creates or modifies a risk control for a hazardous situation that could result in significant harm. A "no" at Question 4 still routes through the Section VI factors |
Anything not covered above | Section E | Your own risk-based assessment, documented |
The flowcharts are a visual aid and do not carry every consideration; each one has companion text that governs.
Four use cases that are not straightforward
A supplier change that stays inside the material specification. The incoming material meets the same spec. It reads like a letter to file — until you notice the guidance treats a change in supplier, or in a supplier's processing or finishing steps, as a material change even when the result remains within the original material specification. Changes made by your existing supplier count too, not just moves from one supplier to another. Biocompatibility and physical properties depend not only on the material but on how it is processed, the manufacturing methods including sterilization, and the manufacturing residuals left on the finished device. The decision then turns on C4 and C4.1: does the risk assessment identify new or increased biocompatibility concerns, and have you used this material — same formulation, same processing, same type and duration of contact — in one of your own similar legally marketed devices cleared or approved by the FDA. Same polymer, different sterilant, is a different material for this purpose. The biocompatibility assessment itself runs on FDA's ISO 10993-1 guidance.
A refactor with no change to functionality. Refactoring restructures a program's internal structure without changing its clinical performance specification; reengineering reconstitutes the software in a new form and is usually broader. Minor modifications that improve maintainability within the existing specification context are unlikely to require submission. A significant re-write likely does, because of the impact on performance and on risk controls. The guidance names the deciding factors — the complexity of the change, and its effect on risk controls or performance — but no threshold separates the two ends, and a complete rewrite of a core algorithm may require a new 510(k) even with identical performance claims and risk profile. Two further signals help: the extent of change to verification and validation scripts, and whether the architecture is modular enough to bound the blast radius. Neither is decisive, and manufacturers are encouraged to discuss these gray areas with the division that cleared the device.
A security patch that also fixes a defect. Question 1 of the software flowchart asks whether the change is made solely to strengthen cybersecurity with no other impact on the software or device. "Solely" carries the whole question. Patch a vulnerability and, in the same release, correct an unrelated anomaly, and you are not at Question 1 — you have two changes, each assessed on its own and together. The tidy answer is not that the release is a submission; it is that the release contains changes that answer different questions.
The fourth letter to file in eighteen months. Take an implantable pulse generator with four changes over that period. A battery component moved to a second supplier. The firmware algorithm estimating remaining capacity was revised. A manufacturing tolerance affecting current consumption changed. Each assessment concluded, reasonably on its own, that the change did not materially affect safety or effectiveness.
The fourth change looked trivial: an adjustment to the threshold at which the device declares elective replacement. The engineer compared the new threshold against the device currently in production, found a small difference, and documented it and missed the comparative device.
That production device already carried the new battery component, the revised estimation algorithm and the changed current-consumption profile. Measured against the last cleared device instead, discharge characteristics had shifted, the algorithm read the discharge curve differently, average current had moved — and now the replacement threshold was moving too. Together they could alter the relationship between the displayed replacement indication and the therapy time actually remaining. The fourth letter was not a problem because the fourth change was large. It was a problem because it showed the baseline had migrated.
What a defensible letter to file contains
FDA's documentation appendix lists the elements. Highlighting the flowcharts, or answering yes or no to each question without justification, is not sufficient documentation — the file has to let an investigator or a third party follow both the change and the reasoning.
Element | Pitfalls for Auditor Review |
Product name | Model or configuration ambiguity — which variant the assessment covers is unstated |
Date of change assessment | Dated after implementation |
Description of the device | Describes the product line, not the cleared configuration |
Description of the change | Written from the engineering change order, so the regulatory-relevant detail is missing |
Reason for the change | Says "customer feedback" where the real driver was a complaint trend — which raises the intent question |
Applicable regulatory history, including the 510(k) number of the most recently cleared version | Cites the original clearance rather than the most recent one |
Comparison of the modified device to the most recently cleared version | Compared to the current build. This is the one that fails most often |
Applicable elements of the guidance, including the specific questions | Reproduces the flowchart with ticks and no reasoning |
Analysis and conclusion | States the conclusion and missed the analysis |
References to supporting documents, particularly the risk analysis | Points to a risk file that was not updated for this change |
Signatures | Approved by design, not by regulatory |
What to do Monday
Pull your three most recent letters to file. For each, find the sentence that names the comparator device and its 510(k) number. If that sentence is missing, or if it names the previously modified version rather than the most recently cleared one, you have a re-baselining problem that is cheaper to fix now than to explain later. Then check whether the changes were assessed in aggregate as well as individually — that pairing is where accumulated letters to file most often turn out to have crossed the threshold together.
See what your portfolio looks like when everything is sellable — and audit-ready.
A 30-minute demo, on your products and your markets. No sandbox, no trial to configure — a working conversation with people who know regulatory.
See what your portfolio looks like when everything is sellable — and audit-ready.
A 30-minute demo, on your products and your markets. No sandbox, no trial to configure — a working conversation with people who know regulatory.
See what your portfolio looks like when everything is sellable — and audit-ready.
A 30-minute demo, on your products and your markets. No sandbox, no trial to configure — a working conversation with people who know regulatory.