What makes a change a Letter to File versus a Special 510(k) under the Feb 3, 2026 guidance?

The Feb 3, 2026 FDA premarket cybersecurity guidance treats the SBOM, threat model, cryptographic controls, authentication model, and postmarket plan as part of the cleared record. If a post-clearance change alters any of those artifacts, the cleared record is no longer accurate and a Special 510(k) is expected. LTF is reserved for like-for-like patches, configuration tightening, or operational actions that leave those artifacts and their conclusions intact.

Can we ever change the device design inside a SIR response?

No. A SIR is a request to clarify or replace an artifact inside an open submission, not to change the device. If closing the SIR requires adding/removing an authentication factor, changing a cryptographic algorithm, adding an interface, or introducing a new component, stop and plan the correct submission path (Special or Traditional 510(k)).

What evidence typically satisfies a cybersecurity SIR on SBOM completeness?

A regenerated SBOM in SPDX 2.3 or CycloneDX 1.5 with supplier, version, license, and transitive dependencies; a matching CycloneDX VEX file with per-CVE status; a SHA-256 hash and generation date; and a cross-reference in the Cybersecurity Management Plan to the SBOM version being submitted.

What evidence satisfies a SIR on threat model rigor?

A device-specific DFD with trust boundaries, STRIDE-per-element analysis with each threat mapped to a mitigation, hazard linkage under ISO 14971:2019, and a signed residual-risk statement. Generic template threat models without device-specific DFDs routinely draw follow-up SIRs.

How is verification evidence different for LTF, SIR, and Special 510(k)?

LTF verification stays in the DHF: regression tests, CVE scan, VEX update, signed by the test lead. SIR verification is targeted, attach exactly the test protocol, retest, or scan output the reviewer named, and make sure the evidence date is after the artifact version it defends. Special 510(k) verification is a full package against the changed control: unit/integration tests, updated pen test if the attack surface shifted, and updated SBOM/VEX/threat model.

Does a cybersecurity SIR pause the MDUFA review clock?

No. A SIR does not pause the clock. However, an unanswered or poorly answered SIR routinely escalates to a formal Additional Information (AI) letter, which does pause the clock for up to 180 days.

Is a Special 510(k) always faster than a Traditional 510(k) for a cybersecurity change?

It is faster only when the change can be verified against well-established methods. Cryptographic algorithm swaps, TLS version upgrades, and MFA additions typically qualify. Novel wireless pairing UX, new sensor interfaces, or changes that touch intended use do not, those need a Traditional 510(k) or a new De Novo, regardless of cybersecurity framing.

Reference tool

LTF vs SIR vs Special 510(k) cybersecurity crosswalk

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.

Decision gates (top to bottom, first "yes" wins)

0 of 4 gates answered. Answer gate 1 to continue.

Change under review (optional, used in the export)

1

Does the change alter intended use, indications, or a fundamental scientific technology?

If yes: Traditional 510(k). Not eligible for Special or LTF.
2

Are you inside an open eSTAR review, responding to a reviewer message?

If yes: SIR response. Fix the artifact; never change the device inside the SIR.

Answer the gates above first.
3

Does the change alter a cybersecurity artifact referenced in the cleared submission, SBOM component list, threat model DFD or trust boundary, cryptographic control, authentication model, or postmarket CVD channel?

If yes: Special 510(k). Verification is against established methods, but the cleared record is no longer accurate.

Answer the gates above first.
4

Is the change a like-for-like patch, config tightening, or operational security action that leaves threat model conclusions and risk controls intact?

If yes: Letter to File under design change controls. Update SBOM + VEX + DHF; no submission.

Answer the gates above first.

Your recommended pathway and PDF export unlock once a gate returns "yes", or once all 4 gates are answered "no".

Pathway basics

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 crosswalk

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. Re-submit updated model as part of the Special 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 (SPDX 2.3 or CycloneDX 1.5).	Component swap (e.g., OpenSSL → wolfSSL), added component, or removed component that was listed in the cleared SBOM. Requires re-submission with updated SBOM + VEX.
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). Verification methods are established → Special.
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. Special 510(k) with updated Authentication Architecture Memo.
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.	No. Never introduce a design change in a SIR response. If the SIR can only be closed by changing the design, stop and plan a Special 510(k).	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.

Never-in-a-SIR list

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.

Add or remove an authentication factor (MFA, cert, biometrics).
Change a cryptographic algorithm, key length, or protocol version.
Add or remove an interface (wireless, wired, service port, API).
Change intended user, use environment, or role permissions.
Introduce a third-party component not listed in the submitted SBOM.
Alter the postmarket CVD channel or vulnerability triage SLA.

Frequently asked questions

Common questions on pathway choice and the evidence that satisfies each cybersecurity factor.

Related tools and guides

SIR Response Builder, generate the six-section reply for auth, crypto, CVE, or SBOM SIRs.
Submission Pathway Selector, full LTF / Special / Traditional / De Novo decision tree.
FDA SIR cybersecurity response guide, templates, worked examples, traceability table.
Special vs Traditional 510(k) for cybersecurity changes.
Letter to File vs new 510(k) for cybersecurity changes.