On this page
Published: · Updated:
Key Takeaways
- **Five elements are recommended at IDE** (Appendix 3, Feb 3, 2026 guidance): cybersecurity risks in the informed consent form, three architecture views (global, multi-patient harm, updateability/patchability), a safety-scoped security use case view, an SBOM, and general cybersecurity labeling.
- **Penetration testing is not recommended at IDE**, it sits in the "could be helpful, not specifically recommended" column and is required at the marketing submission instead.
- The **SBOM is the only sub-element** of the Cybersecurity Risk Management Report explicitly recommended at IDE; threat model, vulnerability assessment, traceability, testing, and the cybersecurity management plan are not.
- **Cybersecurity disclosure in the informed consent form** (21 CFR 50.25(a)(2) and 812.25(g)) is the most commonly missed element in first-cycle IDE submissions for connected devices.
- **Scope does not change by device class.** The same five elements apply to Class II and Class III IDEs; classification affects how the FDA weighs the documentation in the benefit-risk assessment, not what you submit.
- **IDE approval does not settle PMA cybersecurity.** The guidance anticipates that OS support windows and third-party updates will force security improvements between trial and marketing submission, so build the full PMA package during the trial.
The FDA's February 3, 2026 guidance recommends a narrow cybersecurity package for an IDE: disclosure of cybersecurity risks in the informed consent form, three architecture views plus a safety-scoped security use case view, an SBOM, and general cybersecurity labeling. A full risk management report, threat model, vulnerability assessment, penetration testing, and cybersecurity management plan are listed as helpful but not required until the marketing submission.
Sponsors planning a clinical trial for a connected device routinely ask the wrong question first: "Do we need the full FDA cybersecurity package for the IDE?" The Feb 3, 2026 final premarket cybersecurity guidance answers that question explicitly in Appendix 3, and the answer is narrower than most teams assume, but the cost of treating "not recommended at IDE" as "not needed yet" shows up later, in the form of cybersecurity deficiencies at PMA after the architecture has already been frozen by clinical data.
This guide walks through exactly what the FDA recommends in an IDE submission, what it deliberately defers to the marketing submission, and why building the full documentation set during the trial is the smart play for any Class III or significant-risk connected device.
Why IDE Cybersecurity Scope Matters Before the Trial Starts
The IDE is the first regulatory checkpoint at which the FDA's cybersecurity reviewers see a connected investigational device. The Feb 3, 2026 guidance ("Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions") brought IDE-specific recommendations into the same document that governs 510(k), De Novo, and PMA submissions, which is new, the 2023 predecessor handled IDE only by reference.
Getting the IDE cybersecurity package wrong has two costs. The first is direct: the FDA can disapprove or condition the IDE, delaying the trial. The second is structural and more expensive: any architecture decision baked in during the trial, operating system, wireless stack, update mechanism, key management, third-party libraries, becomes hard to change at PMA without re-opening clinical data questions. Standards including AAMI TIR57 (security risk management), IEC 81001-5-1 (health software security lifecycle), and ANSI/AAMI SW96 (medical device security risk management) all assume security architecture decisions are made early in the design process, not retrofitted after Phase II.
The IDE cybersecurity scope is narrow on purpose. It is not narrow because the device is investigational. It is narrow because investigational data is the right time to verify clinical safety, and the FDA expects security to be re-evaluated and tightened before marketing authorization.
What the FDA Recommends in an IDE Cybersecurity Submission
Appendix 3 (p. 50) lists five items as "Recommended" for an IDE cybersecurity submission, each tied to a specific 21 CFR 812.25 subsection.
"Cybersecurity documentation recommended in IDE submissions: Inclusion of cybersecurity risks as part of informed consent form (21 CFR 50.25(a)(2) and 21 CFR 812.25(g)); Global, multi-patient and updateability/patchability views (21 CFR 812.25(c), (d)); Security use case views for functionality with safety risks (e.g., implant programming) (21 CFR 812.25(c), (d)); Software Bill of Materials (21 CFR 812.25(c), (d)); General labeling, connectivity and associated general cybersecurity risks, updateability/process (21 CFR 812.25(f))."
Two recommendations get under-weighted by sponsors. The first is the informed consent disclosure: patients enrolling in the trial need to be told the device has connectivity-related cybersecurity risks. This is the element most often missed in first-cycle IDE submissions for connected devices. The second is the SBOM. Table 1 (p. 52) shows that within the broader Cybersecurity Risk Management Report family, threat model, risk assessment, vulnerability assessment, traceability, testing, management plan, the SBOM is the only sub-element pulled into the "Recommended" column at IDE. Everything else is explicitly downgraded.
Requirements documentation for the recommended architecture views is also "Recommended", meaning sponsors should submit not just the diagrams, but the underlying security requirements that each view enforces.
What the FDA Does Not Recommend at IDE (But Will Require at PMA)
Table 1 (pp. 51-53) sorts every element of the marketing-submission cybersecurity package into either the "Recommended" column or the "could be helpful to submit, but not specifically recommended" column for IDE. The full list of items in the second column is operationally significant:
| Element | IDE position |
|---|---|
| Cybersecurity Risk Management Report (full) | Could be helpful, not specifically recommended |
| Threat Model | Could be helpful, not specifically recommended |
| Cybersecurity Risk Assessment | Could be helpful, not specifically recommended |
| Vulnerability Assessment and Software Support | Could be helpful, not specifically recommended |
| Unresolved Anomalies Assessment | Could be helpful, not specifically recommended |
| Traceability | Could be helpful, not specifically recommended |
| Measures and Metrics | Could be helpful, not specifically recommended |
| Testing (including penetration testing, Section V.C) | Could be helpful, not specifically recommended |
| Cybersecurity Management Plans | Could be helpful, not specifically recommended |
This is the formal taxonomy from the guidance footnote: "could be helpful to submit, but not specifically recommended" refers to elements that could be helpful to the FDA if submitted, but are not specifically recommended in Appendix 3.
Two clarifications worth giving every client. First, penetration testing is not expected at IDE. The FDA does not want full third-party penetration test reports against an investigational build that will change before marketing. Second, eSTAR is a 510(k) submission tool, it does not apply to IDE. The right comparator for the IDE cybersecurity package is the 21 CFR 812.25 investigational plan, not any eSTAR template.
How Architecture Views Are Scoped Differently at IDE
A common misreading of Appendix 3 is that the IDE only requires three architecture views. The text actually lists four view types, with the fourth scoped narrowly:
- Global view, the system in its environment, including all interfaces and data flows.
- Multi-patient harm view, paths by which a single device compromise could harm more than one patient.
- Updateability/patchability view, how the device receives, validates, and applies software updates.
- Security use case views, limited at IDE to "functionality with safety risks (e.g., implant programming)."
The fourth view is the one with the IDE-specific scope qualifier. In a full marketing submission, security use case views are expected for "all medical device system functionality through which a security compromise could impact the safety or effectiveness of the device" (p. 22 of the guidance). At IDE, that scope narrows to functionality whose compromise creates direct safety risk, programming pathways on an implantable, dose-control pathways on an infusion pump, image acquisition control on a surgical robot. The example used in the guidance text is implant programming.
For a Class III implantable with wireless connectivity, this view almost always applies, and the FDA reviews it in the context of the benefit-risk assessment for the investigation, not in isolation.
Appendix 4 (pp. 51-52) adds the scaling rule that governs how much of each view you owe. Documentation breadth scales with the device's cybersecurity risk, and the guidance says that scaling is "most evident in the breadth of the Threat Modeling and Architecture Views documentation." A device with a single hardware connection such as a USB port, or a SaMD product with limited software dependencies and connectivity, will likely need only one diagram for each of the global, multi-patient harm, and updateability/patchability views, plus a small subset of security use case views. A device with networking, wireless, cloud, or a commercial operating system will likely need multiple multi-patient harm and updateability/patchability views, because there are multiple ways to cause multi-patient harm or to update the device, and many more security use case views to cover the unique security and clinical use cases in the architecture.
Two framing points from the same appendix are worth holding onto. Table 1 "is not intended to serve as merely a deliverable checklist," and it "represents one possible way to organize the recommended information." Sponsors can present the elements in a way consistent with their existing documentation processes. And where a device-specific guidance carries additional or different recommendations, the device-specific recommendations control over Table 1.
Class III, Implantables, and the Benefit-Risk Framing
The Feb 3, 2026 guidance does not modify the IDE cybersecurity scope based on device classification. The same five "Recommended" elements apply whether the investigational device is Class II or Class III. Cybersecurity scope at IDE is device-type-driven (what the device is and how it connects), not class-driven.
See also: 8 FDA Cybersecurity Deficiencies, Ranked From Real Letters, SBOM Diffing & CVE Correlation Postmarket, and FDA Cybersecurity Major vs Minor.
What does change with a significant-risk Class III device is how the FDA uses the cybersecurity documentation. Appendix 3 (p. 50) states that the FDA "intends to review this information in the context of the overall benefit-risk assessment of investigational devices as outlined in FDA's guidance 'Factors to Consider When Making Benefit-Risk Determinations for Medical Device Investigational Device Exemptions.'" For a significant-risk implantable with wireless connectivity, the security use case views and the multi-patient harm view receive close scrutiny in that benefit-risk weighing, because the same cybersecurity defect can produce different magnitudes of harm depending on what the device does to the patient.
A battery-less or NFC-coupled investigational implant still needs the SBOM and architecture views. Short-range coupling shows up as attack-surface reduction within those views; it is not a justification for skipping them.
Why You Should Build the Full PMA Package During the IDE Anyway
The FDA is explicit on this point. From Appendix 3 (p. 50):
"Approval of an IDE based on the documentation recommended above does not preclude the possibility of future cybersecurity questions or concerns being raised during review of a subsequent marketing application. This is, in part, due to the understanding that design changes may be needed and the temporal nature of cybersecurity. Cybersecurity improvements will likely be needed between the time of clinical trials and when the device is submitted for marketing authorization (e.g., operating system no longer supported or nearing end of support, third-party software updates)."
Three practical consequences follow:
- The architecture you ship in the IDE is the architecture clinical data attaches to. Reworking it for the PMA introduces clinical-equivalence questions you would rather not raise.
- Operating-system support windows and third-party library updates will move during a multi-year clinical trial. The PMA submission has to account for that drift, which is much easier when the threat model and vulnerability monitoring process were established at IDE.
- The full Cybersecurity Risk Management Report, threat model, vulnerability assessment, testing program, and cybersecurity management plan are all required at PMA. Building them during the trial means the PMA cybersecurity section becomes a refresh exercise rather than a from-scratch construction under deadline pressure.
For depth on what the marketing submission will require, see our coverage of FDA PMA cybersecurity requirements and the FDA premarket cybersecurity submission checklist.
IDE vs 510(k) vs PMA: Side-by-Side Cybersecurity Scope
One structural point first, because it is the most common error in this area: Section 524B(a) of the FD&C Act is a marketing-submission statute. It enumerates 510(k), De Novo, PMA, PDP, and HDE. IDE is not a 524B pathway. Cybersecurity expectations at IDE come from Appendix 3 of the FDA's February 3, 2026 final premarket cybersecurity guidance plus unreasonable-risk-to-subjects review under 21 CFR 812.30(b)(4), not from 524B. Our guide to FDA pathway cybersecurity differences walks the same split across every pathway, including HDE, PDP, and Q-Sub.
| Dimension | IDE | 510(k) / De Novo | PMA |
|---|---|---|---|
| Statutory hook | 21 CFR Part 812; guidance Appendix 3. Not a 524B pathway. | Section 524B applies in full | Section 524B applies in full |
| Threat model | Not specifically recommended at IDE | Required, scoped to the marketed configuration | Required, deepest scope including manufacturing and update infrastructure |
| SBOM | Recommended, the only Risk Management Report sub-element pulled in at IDE | Required with support-status and vulnerability fields | Required, plus lifecycle maintenance evidence |
| Architecture views | Global, multi-patient harm, updateability, and security use case views scoped to safety-risk functionality | All four view types at full scope | All four at full scope, with deeper interface and manufacturing detail |
| Penetration testing | Not expected against an investigational build | Expected; scope and independence must be justified | Expected, with the most rigorous evidence and coverage rationale |
| Cybersecurity management plan | Not specifically recommended | Required, including CVD process and patch timelines | Required, plus annual-report treatment of cybersecurity changes |
| QMSR alignment | Design controls apply; full QMS evidence not reviewed at IDE | QMS considerations reviewed per the Feb 2026 guidance | Deepest QMS and manufacturing evidence, subject to preapproval inspection |
| Labeling | General cybersecurity labeling for investigators and sites | Full 524B(b)(3) labeling set | Full labeling set with postmarket support commitments |
| Informed consent | Cyber risk disclosure recommended in the consent form | Not applicable | Not applicable |
| Submission vehicle | IDE application under 21 CFR 812.25. eSTAR does not apply. | eSTAR cybersecurity section | PMA modules |
| Review clock | 30 FDA days | 90 FDA days | 180 FDA days, longer with panel |
| Worst-case cyber outcome | Clinical hold under 21 CFR 812.42 stopping enrollment | Refuse-to-Accept hold at Acceptance Review | Major deficiency letter |
| Postmarket obligations | Mid-study security event reporting to investigators, the IRB, and the FDA; IDE supplements for security patches | 524B postmarket plan, CVD policy, SBOM updates | Same, plus cybersecurity content in PMA annual reports |
The practical read: the IDE package is a subset scoped to subject safety, not a lighter version of the marketing package. Everything downgraded at IDE returns at 510(k) or PMA, so the artifacts you build for the trial should be written to be expanded rather than replaced.
Related reading on the same comparison:
- 510(k) cybersecurity requirements vs other FDA pathways covers how the eSTAR Acceptance Review enforces the 510(k) package format.
- 510(k) vs De Novo vs PMA vs IDE cybersecurity comparison is the side-by-side table, including review clocks and worst-case outcomes.
Related FDA cybersecurity resources
- IDE cybersecurity submission guide - how to assemble the IDE package, with Appendix 3's five elements mapped to 21 CFR 812.25 and the risk-scaling rule from Appendix 4.
- FDA pathway cybersecurity differences: IDE, 510(k), De Novo, and PMA - what each FDA submission pathway expects for threat modeling, SBOM, testing, and postmarket evidence.
- FDA premarket cybersecurity submission checklist - the marketing-submission deliverable set your IDE artifacts should be written to expand into.
- FDA SBOM requirements - the CycloneDX or SPDX content the FDA expects at IDE and again at 510(k) or PMA.
- 510(k) vs De Novo vs PMA vs IDE cybersecurity comparison - side-by-side FDA review clocks, cybersecurity scope, and worst-case deficiency outcomes.
How Blue Goat Cyber approaches IDE cybersecurity
Blue Goat Cyber's IDE engagements are built around the Appendix 3 scope, with optional extensions to seed the PMA package during the trial. We deliver the recommended informed-consent cybersecurity language, the four architecture view types (with the security use case view scoped to safety-risk functionality), the SBOM in CycloneDX or SPDX, and the general cybersecurity labeling block tied to 21 CFR 812.25(f). For sponsors that want the PMA-ready set in parallel, we author the threat model under STRIDE, the security risk assessment under AAMI TIR57 / ANSI/AAMI SW96:2023 and IEC 81001-5-1, and the postmarket cybersecurity management plan against the Feb 3, 2026 guidance. Our team includes CISSP and OSCP-credentialed practitioners with FDA submission experience on Class II and Class III connected devices. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. See our FDA submission services.
If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity support.
FAQ
What does the FDA actually recommend in an IDE cybersecurity submission?
Five elements, listed in Appendix 3 of the Feb 3, 2026 premarket cybersecurity guidance: cybersecurity risks in the informed consent form, three architecture views (global, multi-patient harm, updateability/patchability), a security use case view scoped to functionality with safety risks, a Software Bill of Materials, and general cybersecurity labeling covering connectivity, associated risks, and the update process. Each is tied to a specific subsection of 21 CFR 812.25. For how that IDE scope compares with the full marketing-submission package, see IDE vs 510(k) vs PMA cybersecurity scope and the FDA pathway cybersecurity differences guide. For the statutory scope question and the Appendix 4 risk-scaling rule, see the IDE cybersecurity requirements guide.
Do I need penetration testing for an IDE submission?
No. Penetration testing falls under the "Testing" element in Table 1, which sits in the "could be helpful to submit, but not specifically recommended" column at IDE. The FDA does not expect a third-party penetration test report against an investigational build that will change before the marketing submission. Penetration testing is, however, required at the marketing submission: see the 510(k) cybersecurity testing requirements and the PMA cybersecurity evidence expectations.
Is the cybersecurity scope different for a Class III IDE?
No. The Feb 3, 2026 guidance does not vary IDE cybersecurity scope by device class. The same five recommended elements apply to Class II and Class III investigational devices. What changes is how the documentation is weighed: significant-risk Class III devices, especially implantables with wireless connectivity, get closer review of the security use case view and the multi-patient harm view within the IDE benefit-risk assessment. Class III sponsors should plan the PMA cybersecurity package during the trial rather than after it.
Does IDE approval mean my cybersecurity package is set for the PMA?
No. The FDA states explicitly that IDE approval "does not preclude the possibility of future cybersecurity questions or concerns being raised during review of a subsequent marketing application." Operating-system support windows and third-party software updates are expected to require security improvements between trial and marketing submission, and the full Cybersecurity Risk Management Report is required at PMA. Compare the IDE, 510(k), and PMA requirements side by side before you freeze the trial build.
What's the most common missed element in IDE cybersecurity submissions?
The cybersecurity disclosure in the informed consent form under 21 CFR 50.25(a)(2) and 812.25(g). Sponsors focused on technical documentation routinely forget that patients enrolling in a connected-device study need to be told about connectivity-related cybersecurity risks. This is also the easiest deficiency for the FDA to flag because it is a binary check against the consent form.
What happens if a serious cybersecurity vulnerability is discovered in an investigational device mid-trial?
The IDE is governed by the same Unanticipated Adverse Device Effect (UADE) reporting framework as any other safety signal. A cybersecurity defect with safety implications, remote code execution on an implant programming pathway, for example is reportable under 21 CFR 812.150(a)(1) and triggers an IRB and FDA notification within the prescribed timelines. The cybersecurity management plan you build during the trial should document the triage and escalation path so this decision is not made under time pressure.
More on this topic: the IDE cybersecurity hub collects our IDE guides, pathway comparisons, and related posts in one place.
Talk to us about your IDE cybersecurity package
If you are preparing an IDE for a connected Class II or Class III device, we can scope the Appendix 3 package and the optional PMA-ready extensions in a single engagement. Book a call to walk through your architecture, your trial timeline, and what the FDA will actually expect at both IDE and PMA. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Talk to our team.
Christian Espinosa, Founder. Christian has led FDA cybersecurity submissions for connected medical devices spanning Class II and Class III investigational and marketing pathways, including implantables with wireless connectivity. Read more from Christian.
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.