On this page
Published: · Updated:
Key Takeaways
- A SIR is a mid-review eSTAR message, not a formal Deficiency (AI) letter.
- SIRs are tightly scoped; respond only to what the reviewer asked.
- Section 524B cybersecurity SIRs cluster around SBOM, threat model, pen test, and postmarket plan.
- In-eSTAR responses preserve review continuity; out-of-band replies restart clocks.
- A pre-submission SIR-prep checklist eliminates 80% of common cybersecurity SIRs.
- Speed and precision matter more than volume; a 3-page answer beats a 30-page dump.
Part of our FDA cybersecurity deficiency, RTA, and hold-letter response series. For the full overview, start with FDA Deficiency Letter vs RTA vs Hold.
An FDA Submission Issue Request (SIR) is a mid-review message inside eSTAR where the lead reviewer asks for a specific fix or clarification before the substantive review can continue. For cybersecurity, most SIRs cite Section 524B gaps, incomplete SBOMs, weak threat models, out-of-scope penetration testing, or thin postmarket plans. Respond in-eSTAR, quickly, with tightly scoped artifacts that answer only what was asked.
A SIR is not a Deficiency Letter, not an RTA, and not a Hold. It is the FDA reviewer asking you, in writing, inside eSTAR, to fix a specific thing before they will keep reading. Treat it like a bug ticket from the person who decides whether your device clears.
Most cybersecurity SIRs land in the first few weeks of substantive review, and most of them are avoidable. They target the same four artifacts every time: SBOM, threat model, penetration test, and postmarket plan. Getting a SIR is not a failure. Getting the response wrong, overreaching, restarting the review clock, or introducing new content the reviewer didn't ask for, is what turns a two-week fix into a two-quarter delay.
This guide covers what a SIR is, how it fits alongside RTA and AI letters, the cybersecurity artifacts SIRs cite most often, and a prep checklist you can run against your eSTAR before you submit.
Why this matters
Since Section 524B of the FD&C Act took effect, cybersecurity is a mandatory element of every "cyber device" premarket submission, and the FDA's Feb 3, 2026 final premarket cybersecurity guidance sets the review baseline. Inside eSTAR, reviewers now have a low-friction way to ping sponsors mid-review: the Submission Issue Request. It looks small, a short message with an attachment field, but it sits directly on the critical path to clearance.
The FDA's own MDUFA V performance data shows the average 510(k) review touches multiple information exchanges before decision. When the interaction is cybersecurity-related, the SIR usually references either the guidance itself or one of the underlying consensus standards: AAMI TIR57, AAMI SW96, IEC 81001-5-1, or the SBOM formats catalogued by CISA. Sponsors who cannot answer in the reviewer's own vocabulary, and in the reviewer's own document taxonomy, invite escalation to a formal AI letter, which does pause the review clock and does show up in the public Summary Statement.
Treating SIRs as a first-class part of your eSTAR workflow, not an interruption, is what keeps a submission on its 90-day clock.
What is an FDA Submission Issue Request (SIR)?
A Submission Issue Request is a lightweight, in-eSTAR message from the lead reviewer identifying a specific problem in your submission that needs to be corrected or clarified before substantive review can continue on that section. It is delivered through the eSTAR portal, attributed to the reviewer, and expects a scoped response, usually a revised artifact, a short narrative, or both.
Three things define a SIR:
- It is mid-review, after acceptance but before decision.
- It is tightly scoped, one issue, or a small cluster of related issues, per SIR.
- It is in-eSTAR, the response is uploaded to the same submission, not sent as an email or a new 510(k).
A SIR does not, by itself, pause the MDUFA review clock the way a formal Additional Information (AI) letter does. But an unanswered or badly answered SIR is the fastest way to earn an AI letter, which does.
How is a SIR different from an RTA, AI, or Hold letter?
Four artifacts sponsors routinely confuse:
| Letter type | When it lands | Clock impact | Response venue |
|---|---|---|---|
| RTA (Refuse to Accept) | Day 1-15 | Resets clock if not fixed | eSTAR resubmission |
| SIR (Submission Issue Request) | Mid-review | No formal pause, but delays substantive review | In-eSTAR message |
| AI / Deficiency letter | Mid-review | Pauses clock; 180-day response window | Formal AI response package |
| Hold letter | Any time cybersecurity is deemed inadequate | Halts all review | Formal remediation package |
Practical implication: a SIR is your last quiet chance to fix a cybersecurity artifact before it becomes a public AI-letter deficiency in your Summary Statement.
For the full comparison of RTA, AI, and Hold, see our FDA Deficiency Letter vs RTA vs Hold Letter guide. Related: how to respond to an FDA cybersecurity AI request, FDA cybersecurity major vs minor deficiency, and what triggers FDA cybersecurity deficiencies.
SIR vs Special 510(k): when each applies to cybersecurity
Sponsors routinely conflate these because both involve "fixing" cybersecurity content, but they operate at opposite ends of the product lifecycle and answer to different regulations.
A SIR is a review-time message. It happens inside an open, in-review eSTAR submission. The FDA is asking you to clarify, expand, or replace an artifact you already sent. No new submission, no new user fee, no new intended use analysis. You respond in-eSTAR and the review continues.
A Special 510(k) is a new submission. It is used post-clearance when a legally marketed device is modified and the change can be verified against well-established methods under the manufacturer's design controls (ISO 13485 clause 7.3, incorporated into 21 CFR Part 820 by the QMSR). It gets a new K-number, a new user fee, and a 30-day review goal (vs 90 days for a Traditional 510(k)).
| Dimension | SIR | Special 510(k) |
|---|---|---|
| Trigger | FDA reviewer flags an issue in an open submission | Sponsor makes a post-market change to a cleared device |
| Timing | Mid-review | Post-clearance |
| Submission vehicle | In-eSTAR message + attachments | New 510(k) submission with new K-number |
| User fee | None | Full MDUFA Special 510(k) fee |
| FDA review goal | Informal; typically weeks | 30 calendar days |
| Governing framework | eSTAR review process | 21 CFR 807.81(a)(3) + "Deciding When to Submit a 510(k) for a Change to an Existing Device" guidance |
| Cybersecurity example | Reviewer asks for a more complete SBOM before clearance | Post-market: swapping TLS 1.2 for TLS 1.3, replacing OpenSSL, adding MFA, changing session token lifetime |
| Design change allowed? | No, never introduce design changes in a SIR response | Yes, that is the point |
For the full Special vs Traditional 510(k) decision framework, see Special vs Traditional 510(k) for cybersecurity changes. For the Letter to File boundary, see Letter to File vs new 510(k) for cybersecurity changes.
The cybersecurity gray zone
The Feb 3, 2026 FDA premarket cybersecurity guidance has quietly raised the bar for what counts as a change that "could significantly affect safety or effectiveness." Post-market cybersecurity changes that teams historically documented as a Letter to File, third-party library CVE patches, crypto library swaps, authentication model changes, SBOM-visible component replacements, increasingly warrant a Special 510(k) because they alter the documented threat model, SBOM attestations, or cybersecurity risk profile referenced in the cleared submission.
Rule of thumb:
- In active review + reviewer sent a message → SIR response. Fix the artifact, do not change the device.
- Cleared device + cybersecurity change that alters the threat model, SBOM, or risk controls → almost always a Special 510(k). Do not paper it as a Letter to File just because it is "just a patch."
- Cleared device + routine patch that does not alter the threat model or risk controls → Letter to File under design change controls, documented in the DHF.
If you receive a SIR that is really asking for a design change, do not try to answer it inside the SIR. Respond stating that the fix requires a design change, withdraw or pause as appropriate, and plan the correct post-clearance submission path.
Cybersecurity change scenarios: SIR vs Special 510(k)
The table below walks 12 real-world cybersecurity changes and states the recommended path. "Gray-zone" rows are the ones teams most often get wrong; the reasoning column explains why the recommendation lands where it does under the Feb 3, 2026 guidance.
| # | Scenario | Lifecycle stage | Recommended path | Reasoning |
|---|---|---|---|---|
| 1 | Reviewer asks for an SPDX-formatted SBOM after you submitted a spreadsheet | Mid-review | SIR response | No device change, replace the artifact and cite guidance §V.A.3. |
| 2 | Reviewer asks for STRIDE-per-element analysis on the existing DFD | Mid-review | SIR response | Analytical deepening, not a design change. |
| 3 | Post-clearance: patch OpenSSL 3.0.11 → 3.0.14 to close a CRITICAL CVE, no interface change | Post-clearance | Letter to File | Like-for-like patch under design controls; threat model unchanged, risk controls unchanged. Log in DHF with VEX update. |
| 4 | Post-clearance: replace OpenSSL with wolfSSL to reduce attack surface | Post-clearance | Special 510(k) | Component swap alters SBOM attestation and the threat model's crypto trust boundary. Verifiable against established methods → Special, not Traditional. |
| 5 | Post-clearance: change TLS 1.2 → TLS 1.3 across all interfaces | Post-clearance | Special 510(k) | Cryptographic control referenced in cleared submission changes. Verification methods are well-established (RFC 8446 test vectors) → Special is appropriate. |
| 6 | Post-clearance: add MFA to the clinician web app | Post-clearance | Special 510(k) | Authentication model in cleared threat model changes; usability/effectiveness aspects require verification, but methods are established. |
| 7 | Post-clearance: shorten session token lifetime from 24h to 1h | Post-clearance | Letter to File (gray-zone) | Configuration change to an existing control, not a new control. Update risk file + DHF; document rationale that the threat model conclusions are strengthened, not altered. |
| 8 | Post-clearance: add a new Bluetooth pairing mode for a service technician | Post-clearance | Traditional 510(k) | New attack surface + new intended user + new interface. Verification methods are not well-established for the pairing UX → Traditional, not Special. |
| 9 | Post-clearance: rotate signing key after suspected compromise | Post-clearance | Letter to File | Operational security response, not a design change. Document under CAPA + postmarket cyber plan. Notify FDA per postmarket guidance if exploitation is confirmed. |
| 10 | Post-clearance: swap cloud provider region (US-East → US-West), no code change | Post-clearance | Letter to File | Deployment change; no change to device SBOM, threat model, or risk controls. Update the postmarket monitoring plan. |
| 11 | Mid-review SIR that would require adding a new authentication factor to close it | Mid-review | Respond, then plan a change | Do not smuggle the design change into the SIR. Reply that the current design meets the guidance section cited, or withdraw and re-submit. Never make a design change inside a SIR response. |
| 12 | Post-clearance: patch a CRITICAL CVE that also requires re-scoping the threat model (attack path was not previously modeled) | Post-clearance | Special 510(k) (gray-zone) | The patch itself would be Letter to File, but re-scoping the threat model changes an artifact referenced in the cleared submission. Under Feb 3, 2026 guidance, the threat-model delta is what pushes this to Special. |
Gray-zone reasoning framework. When the recommendation is not obvious, work through these four gates in order. The first "yes" determines the path.
- Does the change alter the intended use, indications, or a fundamental scientific technology? → Traditional 510(k). No exceptions.
- Does the change introduce a new interface, new user role, or a control whose verification methods are not well-established? → Traditional 510(k).
- Does the change alter an artifact that was part of the cleared cybersecurity submission (SBOM component list, threat model DFD or trust boundaries, cryptographic controls, authentication model, postmarket CVD channel)? → Special 510(k). Verification is against established methods, but the cleared record is now inaccurate and must be re-submitted.
- Is the change a like-for-like patch, configuration tightening, or operational security action that leaves the threat model conclusions and risk controls intact? → Letter to File under design change controls, with SBOM + VEX updated and logged in the DHF.
If gate 3 and gate 4 both feel true, gate 3 wins. The Feb 3, 2026 guidance treats the cybersecurity artifact set as part of the cleared submission, you cannot silently amend it.
Never-in-a-SIR list. Regardless of how narrow the SIR sounds, do not answer it by making any of the following changes inside the SIR response: adding or removing an authentication factor, changing a cryptographic algorithm or key length, adding or removing an interface, changing intended user or use environment, or introducing a new third-party component not listed in the submitted SBOM. All of these require a new submission path, Special or Traditional 510(k), not a SIR reply.
Which cybersecurity artifacts trigger SIRs most often?
Across post-524B 510(k) reviews, cybersecurity SIRs cluster into four artifacts:
1. SBOM completeness and format
Reviewers cite SBOMs that are missing transitive dependencies, use unsupported formats, or omit supplier and version metadata called out in the Feb 3, 2026 guidance. SPDX 2.3 or CycloneDX 1.5 are the safe defaults; anything else invites a SIR. See our medical device SBOM FDA requirements guide and the common VEX mistakes that trigger FDA deficiencies.
2. Threat model rigor
Threat models built from a generic template, no device-specific data flow diagram, no trust boundaries, no linkage to hazards under ISO 14971, draw SIRs asking for STRIDE-per-element analysis and explicit mapping between threats and mitigations. See our step-by-step threat modeling guide for connected and implantable devices and the STRIDE vs DREAD vs PASTA comparison.
3. Penetration test scope
Pen tests scoped to only the mobile app, or only the cloud API, when the device includes firmware, radio interfaces, or a service interface, routinely draw SIRs asking why the excluded surfaces were not tested. See scoping a medical device penetration test and FDA pen test timing for submission.
4. Postmarket plan and coordinated vulnerability disclosure
Postmarket plans that assert "we will monitor and patch" without a named CVD channel, an SBOM update cadence, or a defined vulnerability triage SLA get SIRs asking for the operational details. See the postmarket cybersecurity FDA roadmap and SBOM diffing and CVE correlation for postmarket devices.
Every artifact submitted in response to a cybersecurity SIR should trace back to a section of the Feb 3, 2026 FDA premarket cybersecurity guidance or a named consensus standard. Cite it inline.
SIR example matrix: common issues and expected evidence
Use this matrix as a lookup table when a SIR lands. Each row maps a commonly cited cybersecurity issue to the specific evidence documents reviewers expect back, and the guidance or standard section that anchors the ask. If the response does not include the artifact in the "Expected evidence" column, expect a follow-up SIR or an escalation to an AI letter.
| Cybersecurity issue cited in SIR | Expected evidence documents | Format / standard | Anchor citation |
|---|---|---|---|
| Incomplete SBOM (missing transitive dependencies) | Regenerated machine-readable SBOM + delta summary + updated CMP reference | SPDX 2.3 or CycloneDX 1.5 (.json/.spdx) | Feb 3, 2026 FDA guidance §V.A.3; CISA 2026 SBOM Minimum Elements |
| SBOM missing supplier / version / license metadata | Reissued SBOM with populated fields + supplier attestation letter | SPDX 2.3 or CycloneDX 1.5 | Feb 3, 2026 FDA guidance §V.A.3 |
| Unresolved CVEs without exploitability rationale | VEX document + updated risk assessment tying each CVE to device impact | CycloneDX VEX or CSAF 2.0 | CISA VEX guidance; Feb 3, 2026 FDA guidance §V.A.4 |
| Threat model built from generic template | Device-specific DFD + trust-boundary diagram + STRIDE-per-element table | AAMI TIR57 §5; ISO 14971 linkage | Feb 3, 2026 FDA guidance §V.A.2 |
| Threats not linked to safety hazards | Threat-to-hazard traceability matrix + ISO 14971 risk file excerpt | ISO 14971:2019 §5-7 | Feb 3, 2026 FDA guidance §V.A.2; AAMI TIR57 |
| Missing residual cybersecurity risk statement | Signed residual risk memo + risk management report update | ISO 14971:2019 §8 | Feb 3, 2026 FDA guidance §V.A.5 |
| Pen test scope excludes an interface (firmware, radio, service port) | Revised pen test report covering the interface OR written scope-exclusion rationale | OWASP MSTG / PTES / NIST SP 800-115 | Feb 3, 2026 FDA guidance §V.A.6 |
| Pen test methodology not stated | Test plan appendix naming methodology, tools, and tester credentials | OWASP, PTES, or equivalent | Feb 3, 2026 FDA guidance §V.A.6 |
| Pen test findings not tracked to closure | Findings register with retest evidence + risk acceptance for any residual | Internal QMS format | CAPA under ISO 13485 clause 8.5.2 as incorporated by the QMSR; Feb 3, 2026 FDA guidance §V.A.6 |
| No named coordinated vulnerability disclosure channel | Public CVD policy URL + contact address + intake SLA | ISO/IEC 29147 + 30111 | Feb 3, 2026 FDA guidance §VI.B |
| Postmarket plan lacks SBOM update cadence | Updated postmarket cybersecurity plan with monitoring cadence and triage SLA | AAMI SW96 §7 | Feb 3, 2026 FDA guidance §VI.C |
| No patch delivery mechanism described | Update architecture description + signed-update evidence + rollback plan | IEC 81001-5-1 §9 | Feb 3, 2026 FDA guidance §VI.D |
| No end-of-support (EOS) date | Lifecycle statement in labeling + CMP entry + customer notification plan | AAMI TIR97; PCLC guidance | Feb 3, 2026 FDA guidance §VI.E |
| Missing architecture views (global, multi-patient, updateability) | Architecture Views deliverable set | AAMI SW96 §5 | Feb 3, 2026 FDA guidance §V.A.1 |
| Weak or missing cryptographic controls justification | Crypto inventory + FIPS 140-3 attestation (where applicable) + algorithm rationale | NIST SP 800-131A | Feb 3, 2026 FDA guidance §V.A.7 |
| Authentication / access control not documented | Auth architecture memo + role matrix + session/token controls table | IEC 81001-5-1 §7 | Feb 3, 2026 FDA guidance §V.A.7 |
| Interoperability / third-party integration risks unaddressed | Interoperability risk assessment + partner attestations | AAMI TIR57 §6 | Feb 3, 2026 FDA guidance §V.A.8 |
| Labeling missing cybersecurity information for users | Redlined IFU / operator manual excerpt with cyber section | 21 CFR 801 + FDA guidance | Feb 3, 2026 FDA guidance §VII |
Two rules for using the matrix:
- Send exactly what the row asks for. If the SIR cites an incomplete SBOM, send the SBOM and a one-page delta summary, not a rewritten threat model. Scope creep converts SIRs into AI letters faster than any other single mistake.
- Cite the anchor inline. Every response should reference the guidance section or standard clause in the right-hand column so the reviewer can close the item without re-reading the source.
eSTAR SIR-prep checklist for cybersecurity
Run this before you file. If you cannot check every box, expect a SIR.
SBOM
- SPDX 2.3 or CycloneDX 1.5 format
- All third-party and transitive dependencies included
- Supplier, component name, version, and license fields populated
- Machine-readable file attached in eSTAR, not embedded in a PDF
- Companion VEX document for any known unpatched CVEs
Threat model
- Device-specific data flow diagram (not a template)
- Trust boundaries drawn and labeled
- STRIDE-per-element (or equivalent) applied
- Threats mapped to controls and to ISO 14971 hazards
- Residual risk statement signed off by risk management
Penetration test
- Scope covers every interface listed in the architecture view
- Firmware, radio, and service interfaces explicitly addressed or exclusion justified
- Testing methodology cited (OWASP, PTES, or equivalent)
- Findings tracked to closure with retest evidence
- Report author credentials included
Postmarket cybersecurity plan
- Named CVD channel (email address or portal)
- SBOM update cadence defined
- Vulnerability triage SLA defined
- Patch delivery mechanism described
- End-of-support date declared
eSTAR hygiene
- Every cybersecurity artifact placed in the correct eSTAR attachment slot (not a catch-all appendix)
- File names match the eSTAR field labels
- Cross-references between documents use consistent artifact IDs
- A single Cybersecurity Management Plan ties every document together
For deeper eSTAR-specific mechanics, see our companion guide on preparing eSTAR 510(k) cybersecurity documentation.
How to structure a SIR response that closes the loop
A good SIR response has four parts and never more:
- Restate the reviewer's question in your own words. One or two sentences. This is your alignment check.
- Answer directly. Lead with the answer, not the setup.
- Point to the revised artifact. Name the file, the version, and the specific section that changed.
- Cite the standard or guidance. Section number, page number, date.
Do not attach unrelated updates. Do not use the SIR to introduce design changes. Do not restate your entire cybersecurity story. Reviewers reject scope creep, and scope creep is the single most common way a SIR turns into an AI letter.
Turnaround target: five business days or less for most cybersecurity SIRs. Anything longer signals that you did not have the artifact ready, and the reviewer will treat the next issue on the same submission with less patience.
Reusable SIR response template
Copy the block below into your eSTAR SIR response text field (or the attached PDF/DOCX cover memo). It works for any of the four artifact categories reviewers hit most often. Replace the bracketed placeholders and delete any section that does not apply to the specific issue raised.
Prefer an interactive version? Use the SIR Response Builder to pick your issue type (auth change, crypto change, vulnerability patch, or SBOM/signing change) and get a pre-filled template with example verbiage.
Header block (always include)
SUBMISSION: [K-number / Q-sub / De Novo number]
DEVICE: [Trade name, model]
SIR REFERENCE: [SIR ID from eSTAR, date received]
REVIEWER: [Lead reviewer name, if provided]
RESPONSE DATE: [YYYY-MM-DD]
RESPONSE AUTHOR: [Name, title, e-signature on file]
PRIMARY GUIDANCE: FDA "Cybersecurity in Medical Devices" premarket guidance, Feb 3, 2026
Section 1, Reviewer question, restated
1. UNDERSTANDING OF THE ISSUE
The Agency requested [one-sentence paraphrase of the SIR, using the reviewer's own terminology]. We understand the specific concern to be [one sentence naming the exact artifact, section, or claim in question]. If our interpretation differs from the Agency's intent, please advise and we will supplement this response.
Section 2, Direct answer
See also: Breakthrough Device Designation and Cybersecurity, Q-Sub vs Pre-Sub: FDA Cybersecurity Guide, and Docker Containers in Medical Devices: FDA Testing.
2. RESPONSE
[Lead with the answer in one or two sentences. State the conclusion first, "Yes, the SBOM now includes...", "The threat model has been revised to...", "Pen test scope has been expanded to cover...", before any supporting detail. Do not restate the cybersecurity program. Do not introduce unrelated design changes.]
Supporting detail:
- [Bullet 1: what changed]
- [Bullet 2: why the change resolves the reviewer's concern]
- [Bullet 3: residual risk statement, if any, with rationale]
Section 3, Revised artifact pointer
3. REVISED ARTIFACTS
The following documents have been updated and are attached to this SIR response (and replace the corresponding files in the eSTAR record):
| Artifact | File name | Version | Section changed | Change summary |
|---|---|---|---|---|
| [e.g. SBOM] | [SBOM_DeviceName_v1.2.spdx.json] | v1.2 | Entire file | Added transitive dependencies, license fields, and supplier data per the CISA 2026 SBOM minimum elements |
| [Threat Model] | [ThreatModel_DeviceName_v2.1.pdf] | v2.1 | §4.2, §6.1 | Added STRIDE analysis for [interface]; updated risk scoring for [asset] |
| [Cybersecurity Management Plan] | [CMP_DeviceName_v1.3.pdf] | v1.3 | §7 | Added coordinated vulnerability disclosure procedure and SLA table |
All prior versions are retained in our DHF under [document control ID].
Section 4, Standards and guidance citations
4. REGULATORY BASIS
The revised artifact aligns with the following:
- FDA, "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," final guidance, Feb 3, 2026, Section [X.Y], p. [N]
- FD&C Act §524B(b)(1)-(3), [applicable subsection]
- [AAMI TIR57:2016/(R)2023, Section X] OR [ANSI/AAMI SW96:2023, Section X] OR [IEC 81001-5-1:2021, Clause X], as applicable
- [NTIA "Minimum Elements for a Software Bill of Materials," Jul 12, 2021], for SBOM issues
- [NIST SP 800-30 Rev. 1], for threat/risk methodology, if cited in the submission
Section 5, Verification statement
5. VERIFICATION
The change described above has been verified against [test protocol ID / design verification record ID] and reviewed by [role, e.g. Cybersecurity Lead, Regulatory Affairs Lead]. No changes were made to intended use, indications for use, principles of operation, or the device's substantial equivalence rationale. No new predicate is required.
Section 6, Closing (always include)
6. CLOSING
We believe this response fully addresses SIR [ID]. Please contact [name, email, phone] with any follow-up questions. We are available for a teleconference within two business days if that would accelerate review.
Usage notes
- Turnaround target: five business days from SIR receipt. If you cannot meet it, respond within 48 hours with a committed date, silence is what triggers the next escalation.
- Attachments: name every file
[Artifact]_[DeviceName]_v[X.Y].[ext]. Reviewers open dozens of attachments a week; ambiguous names get skipped. - Do not attach unrelated updates, marketing material, or full copies of the original submission. Attach only what changed.
- Do not use the SIR to introduce design changes. If the fix requires a design change, respond to the SIR stating that, and open a separate amendment.
- Do keep a redlined copy of every revised artifact in your DHF. The FDA may ask for the delta later.
Worked example: OpenSSL CVE patch that shifts the threat model
Below is a fully filled SIR response for one of the most common cybersecurity issues in post-524B reviews: a mid-review third-party library CVE (OpenSSL) that the sponsor patched, which in turn changed the SBOM and required a threat-model update. Copy the wording, swap the bracketed device-specific details, and you have a submittable response.
Scenario. During substantive 510(k) review, the lead reviewer sends a SIR after CVE-2024-5535 is disclosed in OpenSSL. The device, a wireless-connected infusion pump, bundles OpenSSL 3.0.13 in its embedded Linux firmware for its TLS 1.3 clinician-console session. The sponsor upgraded to OpenSSL 3.0.14 (patched), regenerated the SBOM, and updated the threat model. No functional or intended-use change.
Reviewer's SIR (verbatim excerpt):
"CVE-2024-5535 in OpenSSL 3.0.13 has been publicly disclosed and appears in the SBOM submitted with this 510(k). Please provide: (1) exploitability rationale for the device as designed, (2) an updated SBOM if the component has been replaced, and (3) confirmation that the threat model and cybersecurity risk assessment have been updated to reflect the change."
Filled SIR response
SUBMISSION: K253421
DEVICE: AcmeCardio Infusion Pump 3000, Model IP-3000
SIR REFERENCE: SIR-2026-0714-03, received 2026-07-14
REVIEWER: J. Rivera, Lead Reviewer, DHT4
RESPONSE DATE: 2026-07-18
RESPONSE AUTHOR: M. Chen, Director of Product Security (e-signature on file)
ISSUE CATEGORY: Vulnerability patch / SBOM update / threat-model refresh
1. RESTATEMENT OF REVIEWER'S QUESTION
The reviewer is asking us to (a) assess exploitability of CVE-2024-5535 in
OpenSSL 3.0.13 as used in the AcmeCardio IP-3000, (b) provide an updated SBOM
reflecting any component change, and (c) confirm that the threat model and
cybersecurity risk assessment have been updated to reflect the change.
2. DIRECT ANSWER
CVE-2024-5535 (SSL_select_next_proto buffer overread in ALPN handling) is
applicable to the IP-3000 as originally submitted because the device negotiates
ALPN during TLS 1.3 sessions with the clinician console. In our device context
the vulnerability is rated Medium (CVSS 3.1 base 5.9); exploitation requires an
attacker able to send crafted ALPN protocol lists over the segmented clinical
network on which the console operates.
We have replaced OpenSSL 3.0.13 with OpenSSL 3.0.14 (patched upstream on
2024-06-04) in device firmware build 4.2.1-b917. No API-visible or clinical-
functionality changes were introduced. The SBOM, threat model, and risk file
have been updated accordingly and are attached to this SIR response.
3. REVISED ARTIFACT POINTERS
- SBOM | v4.2.1 | AcmeCardio_IP-3000_SBOM_v4.2.1.cdx.json (CycloneDX 1.5)
- SBOM Delta Summary | v4.2.1 | one component changed: pkg:generic/openssl@3.0.13 -> 3.0.14
- VEX Document | v4.2.1 | AcmeCardio_IP-3000_VEX_v4.2.1.cdx.json, CVE-2024-5535 status: "fixed"
- Threat Model | v2.3 | §4.2 (clinician-console TLS trust boundary), STRIDE-per-element table updated for ALPN handling
- Cybersecurity Risk Assessment | v2.3 | §6.1 hazard trace: threat T-CON-14 updated; residual risk unchanged
- Cybersecurity Management Plan (CMP) | v1.4 | §3.2 cross-reference table updated to point to v4.2.1 artifacts
- Verification Report | v4.2.1 | §5.7 TLS regression suite, §5.8 signed-update verification
4. REGULATORY BASIS AND STANDARDS CITED
- FDA Feb 3, 2026 Premarket Cybersecurity Guidance §V.A.3 (SBOM),
§V.A.4 (vulnerability management), §V.A.2 (threat modeling), §VI.C (postmarket monitoring)
- CISA VEX Use Cases (2023) and CycloneDX VEX 1.5
- CISA 2026 SBOM Minimum Elements (July 29, 2026), which replaced the NTIA 2021 list
- AAMI TIR57:2016/(R)2023 §5 (threat modeling process)
- ISO 14971:2019 §7-8 (risk control and residual risk)
- IEC 81001-5-1:2021 §9 (software update controls)
5. VERIFICATION
The patched OpenSSL 3.0.14 build (firmware 4.2.1-b917) was regression-tested
per Test Protocol TP-SEC-041 rev 3 on 2026-07-16 (see Verification Report
v4.2.1 §5.7). The full TLS 1.3 acceptance suite passed with 214/214 test cases.
Signed-update verification passed per TP-SEC-047 rev 2, confirming the firmware
image is signed by the production release key (HSM-protected) and verified by
secure boot prior to install. SBOM regeneration occurred automatically in build
pipeline job #4821 on 2026-07-16; SBOM SHA-256:
7b1a…c4f2 (full hash in the file header).
6. CLOSING
No design changes, no functional changes, and no intended-use changes have
been introduced by this response. The scope of the change is confined to a
patched dependency and the corresponding documentation refresh. We remain
available for a teleconference at the reviewer's convenience.
--
Scope guard: If any further OpenSSL CVEs are disclosed before clearance that
alter the risk profile beyond a dependency bump, we will notify the reviewer
proactively rather than bundling additional changes into this SIR response.
Why this response closes cleanly:
- Alignment sentence first. The restatement mirrors the reviewer's three-part ask verbatim in structure, so the reviewer can check off each item.
- Exploitability rationale before the fix. The direct answer names the specific vulnerable code path (ALPN handling), CVSS, and required attacker position, not a bare "we patched it."
- VEX status attached. The response includes a CycloneDX VEX entry with status
fixed, which is the CISA-recognised value for a patched component. Reviewers reject responses that update the SBOM without a corresponding VEX statement. - Threat model traceability preserved. Threat ID
T-CON-14is referenced, showing that the model change is targeted rather than a wholesale rewrite. Residual risk is explicitly called out as unchanged so the reviewer does not have to re-open the ISO 14971 file to confirm. - Every artifact has a version, filename, and section pointer. Reviewers open dozens of attachments a week; ambiguous references get re-SIR'd.
- No design change smuggled in. The closing paragraph and scope guard state this explicitly, which forecloses the most common escalation path.
If your SIR is on authentication, cryptographic controls, or SBOM/signing rather than a CVE patch, use the SIR Response Builder to generate the same six-section skeleton pre-filled for that issue type.
Traceability table template
Reviewers close SIRs faster when every sentence in your response is traceable to a specific artifact, a specific standard clause, and a specific piece of verification evidence. Paste the table below into the top of your SIR response (or attach as SIR-<number>-Traceability.xlsx) and fill one row per response statement. If a row cannot be filled end-to-end, the statement is not yet defensible and should be revised before submission.
Column definitions:
- Response statement, the exact sentence or claim from your SIR reply (copy verbatim, do not paraphrase).
- eSTAR artifact, filename, version, and section/page anchor where the artifact lives inside the eSTAR project (e.g.,
Threat-Model-v2.3.pdf §4.2). - Standard / guidance citation, the clause, section, or line number in FDA guidance, AAMI TIR57, IEC 81001-5-1, ISO 14971, ANSI/AAMI SW96, or NIST publications that authorises the claim.
- Verification evidence, the test result, scan output, log file, or signed record that proves the statement is true (not just asserted).
- Evidence location, filename and anchor for the verification evidence.
- Owner / date verified, the named individual (role + initials) who verified the row and the date, so the reviewer can see this is not AI-generated boilerplate.
- Status,
Ready|Draft|Blocked, anything notReadymust not ship.
Template (copy-paste):
| # | Response statement | eSTAR artifact (file §section) | Standard / guidance citation | Verification evidence | Evidence location | Owner / date verified | Status |
|---|---|---|---|---|---|---|---|
| 1 | e.g. "The OpenSSL 3.0.14 upgrade eliminates CVE-2024-XXXX in the TLS interface." | SBOM-DeviceX-v1.4.cdx.json (component index 47) | FDA Feb 3, 2026 Premarket Cybersecurity Guidance §V.A.3 (SBOM) | Rebuilt SBOM diff + CVE scanner report showing zero CRITICAL findings | CVE-Scan-2026-03-14.pdf p.2 | J. Smith, Security Lead / 2026-03-14 | Ready |
| 2 | e.g. "Threat model updated; residual risk unchanged." | Threat-Model-v2.3.pdf §4.2, Table 4-B | AAMI TIR57:2016 §5.4; ISO 14971:2019 §7 | Risk matrix delta review signed by risk owner | Risk-Review-Minutes-2026-03-12.pdf | M. Chen, Risk Owner / 2026-03-12 | Ready |
| 3 | e.g. "Pen test re-run against patched build; no new findings." | Pen-Test-Report-v1.2.pdf §6 Retest Summary | FDA Feb 3, 2026 Guidance §V.A.5 (Testing); ANSI/AAMI SW96:2023 §7.4 | Signed retest attestation + raw tool output | PenTest-Retest-Logs.zip | R. Patel, Test Lead / 2026-03-13 | Ready |
| 4 | e.g. "CVD channel and 60-day SLA remain unchanged." | Postmarket-Cyber-Plan-v1.1.pdf §3.2 | FDA Feb 3, 2026 Guidance §VI (Postmarket); ISO/IEC 30111:2019 | Published security.txt + monitored inbox screenshot | security-txt-evidence.pdf | J. Smith, Security Lead / 2026-03-14 | Ready |
| 5 | e.g. "VEX statement issued: status = fixed." | VEX-DeviceX-2026-03-14.cdx.json | CISA VEX Minimum Requirements (Apr 2023); FDA Feb 3, 2026 Guidance §V.A.3 | CycloneDX schema validation pass + SHA-256 hash | VEX-validation.log | J. Smith / 2026-03-14 | Ready |
How to use the table during response drafting:
- Write the SIR response first (six-section skeleton).
- Extract each declarative sentence into a row.
- Fill columns 3 (artifact) and 4 (citation) before touching evidence, this exposes claims that have no authoritative basis.
- Any row that stalls at column 5 (no verification evidence) means the underlying work is not done, not that the response needs better wording. Fix the work, not the sentence.
- Attach the completed table as the first exhibit in the SIR reply. Reviewers routinely open exhibit 1 before reading the narrative, and a clean traceability table pre-answers most follow-up questions.
Rows to flag automatically:
- Any citation to a withdrawn or superseded document (e.g., the 2023 FDA premarket guidance instead of Feb 3, 2026).
- Any evidence dated before the artifact version listed in column 3 (evidence must post-date the change it verifies).
- Any owner field left blank or filled with a team name, reviewers expect an individual.
- Any statement without a citation, either add one or delete the statement.
How Blue Goat Cyber approaches SIR readiness
Blue Goat Cyber runs a pre-submission SIR simulation on every eSTAR we support. Our senior reviewers, CISSP, OSCP, and ex-military red team backgrounds, read your submission the way a lead reviewer at CDRH does, flag the same four artifact categories, and rewrite what needs rewriting before the FDA sees it. We line up SBOM, threat model, pen test, and postmarket plan into a single Cybersecurity Management Plan mapped to the Feb 3, 2026 guidance so a reviewer can trace any question to a specific artifact in under a minute. For clients in active review, we author SIR responses inside your eSTAR project on a five-business-day turnaround. See our FDA premarket cybersecurity service for details. 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
What is a Submission Issue Request in FDA eSTAR?
A Submission Issue Request (SIR) is a message from the lead FDA reviewer delivered inside the eSTAR portal, asking the sponsor to fix or clarify a specific issue in the submission before substantive review continues. It is scoped, informal relative to an AI letter, and expects an in-eSTAR response with the revised artifact attached.
Does an FDA SIR pause the review clock?
No. Unlike a formal Additional Information (AI) letter, a SIR does not pause the MDUFA review clock. However, an unanswered or poorly answered SIR routinely escalates to an AI letter, which does pause the clock for up to 180 days and appears in the public 510(k) Summary Statement.
How fast should we respond to a cybersecurity SIR?
Aim for five business days or less. Cybersecurity SIRs are almost always narrow, a missing SBOM field, a missing interface in pen-test scope, an undefined CVD channel. Slow responses signal that the artifact was not ready at submission and lower reviewer patience on later issues.
Can we add new information to a SIR response?
Only if it directly answers what the reviewer asked. Introducing unrelated updates, new design changes, or a rewritten cybersecurity narrative frequently converts a SIR into an AI letter. Keep the response strictly scoped to the reviewer's question, and cite the guidance section or standard that justifies the answer.
Which cybersecurity artifacts trigger the most SIRs?
Four artifacts account for the majority: incomplete or wrong-format SBOMs, template-based threat models missing device-specific data flow diagrams, penetration tests that exclude firmware or radio interfaces without justification, and postmarket plans lacking a named coordinated vulnerability disclosure channel and defined SLAs.
Is a SIR the same as a Refuse to Accept (RTA) letter?
No. An RTA is a completeness decision issued in the first 15 days that blocks acceptance entirely. A SIR arrives after acceptance, during substantive review, and asks for a specific fix. RTAs reset your clock; SIRs do not, but they can escalate to letters that do.
Related reading
Deficiency-letter cluster:
- FDA Deficiency Letter vs RTA vs Hold Letter
- How to respond to an FDA cybersecurity AI request
- FDA cybersecurity major vs minor deficiency
- What triggers FDA cybersecurity deficiencies for devices
- 510(k) cybersecurity deficiencies that trigger FDA holds
- PMA cybersecurity deficiencies and complete response letters
- FDA 483 cybersecurity observations under QMSR
- VEX mistakes that trigger FDA deficiencies
Related cybersecurity submission topics:
- Preparing your eSTAR 510(k) cybersecurity documentation
- eSTAR cybersecurity: IVD vs non-IVD submissions
- Special vs Traditional 510(k) for cybersecurity changes
- Letter to File vs new 510(k) for cybersecurity changes
- 510(k) cybersecurity requirements every maker must meet
Ready to SIR-proof your eSTAR?
Send us your cybersecurity artifacts and we will run the same SIR simulation the FDA reviewer will. You get a scored gap report and a fix list before you submit. Book a discovery call.
Christian Espinosa, Founder and CEO, Blue Goat Cyber. Christian has led FDA premarket cybersecurity submissions across Class II and Class III devices and is the author of The Smartest Person in the Room. He writes on medical device cybersecurity strategy for MedTech teams working through Section 524B.
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.