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 recommended for 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 an explicit IDE documentation recommendation.
- 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 potentially helpful but not specifically recommended at IDE; device-specific recommendations may differ.
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.
If your device is still in animal studies, see medical device cybersecurity from animal studies to human trials for what to do before the IDE. 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, continuing IDE-specific recommendations that were already included in the 2023 guidance.
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.
Why Section 524B Does Not Apply to an IDE
Section 524B(a) (21 U.S.C. 360n-2(a)) attaches the cyber device obligations to submissions under specific sections of the FD&C Act: 510(k), 513 (De Novo), 515(c) (PMA), 515(f) (PDP), and 520(m) (HDE). An IDE is submitted under section 520(g). It is not on the list.
That is a statutory scope fact, not a loophole. Its one practical consequence: the FDA cannot refuse to accept an IDE for missing the 524B(b) elements, because those elements are not triggered. The agency can still find your investigational plan inadequate, place a study on clinical hold, and ask cybersecurity questions that must be answered before subjects are enrolled. The February 3, 2026 guidance is broader than the statute and does cover IDE submissions.
Never describe IDE as a "524B pathway" in a submission, a QMS document, or marketing copy.
| IDE (520(g)) | 510(k) / De Novo / PMA / PDP / HDE | |
|---|---|---|
| Section 524B(a) applies | No | Yes, for cyber devices |
| Feb 3, 2026 guidance applies | Yes | Yes |
| Cyber content lives in | 21 CFR 812.25, 812.27 | eSTAR cybersecurity sections |
| Refuse to accept on 524B grounds | Not available | Yes |
| Primary risk framing | Risk to enrolled subjects | Risk across the marketed population |
| Postmarket plan required by statute | No | Yes, 524B(b)(1) |
Also plan how you will handle vulnerabilities discovered during the study, including how a patch reaches deployed investigational units and how the sponsor notifies sites and, where appropriate, subjects. Appendix 3 does not list this as a submission item, but it protects enrolled subjects. A marketing submission's postmarket plan is a future commitment. A mid-study plan has to work during an active investigation, on devices with enrolled subjects, without invalidating the protocol.
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 an explicit IDE documentation recommendation. 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 Is Not Specifically Recommended at IDE but May Support Marketing Submissions
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 matter. Testing documentation is listed as potentially helpful but not specifically recommended for IDE submissions in Appendix 4; device-specific recommendations may differ. Marketing-submission eSTAR templates support both 510(k) and De Novo submissions. Determine IDE cybersecurity scope from the investigational plan and IDE recommendations, not a marketing-template checklist.
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
See also: 8 FDA Cybersecurity Documentation Gaps to Review, SBOM Diffing & CVE Correlation Postmarket, and FDA Cybersecurity Major vs Minor.
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.
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 recommended for the PMA submission. 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 | Could be helpful, not specifically recommended; consider device-specific needs | 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 recommended cybersecurity labeling; 524B(b)(3) concerns the SBOM | 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-day initial IDE review under applicable rules | MDUFA goals: 510(k) 90 FDA days; De Novo 150 FDA days | Applicable PMA review goals depend on route; not guaranteed elapsed time |
| Worst-case cyber outcome | IDE disapproval or withdrawal of approval under 21 CFR 812.30 | 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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. 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, see why Section 524B does not apply to an IDE.
Do I need penetration testing for an IDE submission?
Testing, including penetration testing, is listed as potentially helpful but not specifically recommended for IDE submissions in Appendix 4. That is not a prohibition on submitting relevant testing evidence, and device-specific recommendations may differ. Scope the evidence to investigational risks and the actual device. Penetration testing is recommended for relevant marketing submissions.
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.
Why should informed consent address cybersecurity risks?
Appendix 3 recommends including cybersecurity risks in the informed consent form, citing 21 CFR 50.25(a)(2) and 812.25(g). Explain relevant risks in language participants can understand. This recommendation does not establish how often sponsors omit the information.
What happens if a serious cybersecurity vulnerability is discovered in an investigational device mid-trial?
Evaluate cybersecurity findings under the IDE safety-reporting requirements. Findings meeting the definition of an unanticipated adverse device effect trigger the applicable investigator and sponsor duties under 21 CFR 812.3(s) and 812.150(a)(1) and (b)(1). A vulnerability with possible safety implications is not automatically a reportable UADE; document the evaluation and escalation decision.
Can the FDA place a clinical hold over cybersecurity?
Yes. The agency can find an investigational plan inadequate to protect subjects, and a cybersecurity risk with a credible path to subject harm is a legitimate basis for that finding. The Section 524B mechanisms are not available, but 21 CFR 812 authorities are.
What about a non-significant-risk study with no IDE application?
An abbreviated IDE for a non-significant-risk device does not go to the FDA, so there is no agency cybersecurity review. The IRB still reviews the study, and the sponsor still carries the risk. Do not skip the internal cybersecurity work; the marketing submission will rely on it later.
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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. 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. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.
Sources & references
Primary sources cited in this article. Links open in a new tab.