A printable one-page reference that ties each pathway decision to the specific cybersecurity factors the FDA expects at the Feb 3, 2026 guidance bar, threat model, SBOM/component, cryptographic controls, authentication, interfaces, and verification evidence.
Answer the gates top to bottom. The first "yes" wins, so gate 3 (cleared cybersecurity artifact changed?) beats gate 4.
0 of 4 gates answered. Answer gate 1 to continue.
Does the change alter intended use, indications, or a fundamental scientific technology?
If yes: Traditional 510(k). Not eligible for Special or LTF.
Are you inside an open eSTAR review, responding to a reviewer message?
If yes: SIR response. An SIR response answers the review questions. Device changes made during review need to be described and can affect the submission and pathway.
Could the change significantly affect safety or effectiveness under the FDA software change guidance (for example, a new or changed risk, or a change to a control that addresses a hazardous situation)?
If yes: A new 510(k) is likely needed. Special 510(k) eligibility is a separate check: the change must be to your own device and be verifiable with well-established methods. Otherwise plan a Traditional 510(k).
Have you documented that the change does not significantly affect safety or effectiveness, with risk analysis and verification (for example, a like-for-like patch that leaves threat model conclusions and risk controls intact)?
If yes: Letter to File under design change controls. Update SBOM + VEX + DHF; no submission.
| Factor | Letter to File (LTF) | Submission Issue Request (SIR) | Special 510(k) |
|---|---|---|---|
| Trigger | Sponsor makes a post-clearance change that does not significantly affect safety/effectiveness. | FDA reviewer sends a message inside an open eSTAR submission asking for a fix. | Sponsor makes a post-clearance change verifiable against well-established methods. |
| Lifecycle stage | Post-clearance. | Mid-review (before clearance). | Post-clearance. |
| Governing basis | 21 CFR 820.30 design controls + "Deciding When to Submit a 510(k)" guidance. | eSTAR review workflow; no separate regulation. | 21 CFR 807.81(a)(3) + Special 510(k) guidance; 30-day review goal. |
| Cybersecurity factor | Letter to File | SIR response | Special 510(k) |
|---|---|---|---|
| No change to DFD, trust boundaries, threats, or residual risk. Update the model to reflect the change; log delta review in DHF. | The threat model itself is not being changed, the SIR asks you to clarify or extend the existing model (e.g., STRIDE-per-element, missing DFD element, hazard linkage). | Threat model changes: new trust boundary, new threat class, new/removed mitigation, or altered residual risk. If these could significantly affect safety or effectiveness, include the updated model in the new 510(k). | |
| Like-for-like patch of an existing component (same supplier, same functional role). Update SBOM + VEX in the DHF; do not re-submit. | SBOM is missing fields, wrong format, or missing transitive dependencies. Replace the artifact in eSTAR in a machine-readable format. | Component swap (e.g., OpenSSL → wolfSSL), added component, or removed component that was listed in the cleared SBOM. Assess under the software change guidance. If a new 510(k) is needed, include the updated SBOM and vulnerability assessment. | |
| Configuration tightening within an already-cleared control (e.g., key rotation cadence). No algorithm change. | Reviewer asks for missing crypto details (algorithm, key length, protocol version). Provide the documentation; do not change the design. | Algorithm, key length, or protocol version change (e.g., TLS 1.2 → 1.3; RSA-2048 → ECDSA P-256). Assess under the software change guidance. If a new 510(k) is needed, established verification methods may support Special eligibility. | |
| Backend-only tightening of an existing control (e.g., shortening session lifetime) that strengthens without altering the model. | Reviewer asks for the auth model, role-to-action matrix, or session controls to be documented. Provide the memo; do not add/remove factors. | Add/remove authentication factor, new user role, new privileged action, or new re-auth requirement. Assess under the software change guidance. If a new 510(k) is needed, include the updated authentication documentation. | |
| No new interface. Existing interface behaviour unchanged. | Reviewer asks why an interface was excluded from pen-test scope or missing from the DFD. Justify or extend scope; do not add interfaces. | New interface only if verification methods are well-established (rare for wireless/pairing UX, those trend Traditional). Otherwise Traditional 510(k). | |
| Regression tests + updated CVE scan + VEX. Signed by test lead; filed in DHF. | Attach the specific test protocol, retest result, or scan output the reviewer named. Evidence must post-date the artifact version being defended. | Full verification package against the changed control: unit + integration tests, updated pen test if attack surface shifted, updated SBOM/VEX, updated threat model. | |
| No change unless the CVD channel, SLA, or monitoring cadence is altered. | Reviewer asks for a named CVD channel, SBOM update cadence, or triage SLA. Provide operational detail; do not restructure the plan. | Re-submit the postmarket plan if the change alters the monitoring surface, CVD scope, or update mechanism referenced at clearance. | |
| Yes, that is the point. Documented under design controls, not submitted. | An SIR response answers the review questions. Device changes made during review need to be described and can affect the submission and pathway. | Yes, that is the point. Design change with verification against established methods. | |
| None. Filed in the DHF and available on inspection. | In-eSTAR message + attached artifacts. No new K-number, no user fee. | New 510(k) submission with new K-number and MDUFA user fee. 30-day review goal. |
Regardless of how narrow a SIR sounds, do not close it by making any of these changes inside the SIR reply. All require a new submission path.
Common questions on pathway choice and the evidence that satisfies each cybersecurity factor.
