Published: June 10, 2026
For an Investigational Device Exemption, the FDA recommends a scoped cybersecurity package in Appendix 3 of the February 3, 2026 premarket cybersecurity guidance: cybersecurity risks in the informed consent form, three architecture view types plus a safety-scoped security use case view, a Software Bill of Materials, and general cybersecurity labeling. A full Cybersecurity Risk Management Report, threat model, vulnerability assessment, penetration testing, and a cybersecurity management plan are listed as "could be helpful but not specifically recommended" at the IDE stage, but they will be required at 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.
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.
- Software changes mid-trial that affect cybersecurity architecture (update mechanism, key management, third-party libraries, OS upgrades) require an IDE supplement under 21 CFR 812.35 and must be tracked against the architecture views and SBOM.
Table of Contents
- Key Takeaways
- Why IDE Cybersecurity Scope Matters Before the Trial Starts
- What the FDA Recommends in an IDE Cybersecurity Submission
- What the FDA Does Not Recommend at IDE (But Will Require at PMA)
- How Architecture Views Are Scoped Differently at IDE
- Class III, Implantables, and the Benefit-Risk Framing
- Why You Should Build the Full PMA Package During the IDE Anyway
- How Blue Goat Cyber approaches IDE cybersecurity
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.
See also: MQTT Vulnerabilities in Connected Medical Devices: FDA Risks, Controls, and Deficiency Patterns, SBOM Diffing and CVE Correlation: The Postmarket Workflow the FDA Expects, and AAMI TIR57 vs TIR97 vs SW96: Medical Device Guide.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
Do I need an SBOM for an NFC-coupled or battery-less investigational implant?
Yes. The Software Bill of Materials is a recommended element regardless of how the device connects. Short-range coupling like NFC reduces attack surface, but that reduction shows up inside the architecture views as a constraint on adversary access. It is not a justification for omitting the SBOM, which the FDA uses for vulnerability monitoring throughout the trial.
Does a feasibility or early-feasibility IDE have a different cybersecurity scope than a pivotal IDE?
The Feb 3, 2026 guidance does not separate feasibility, early-feasibility, and pivotal IDEs in its cybersecurity recommendations. The same Appendix 3 scope applies. In practice, feasibility submissions get reviewed against the same five elements but in the context of a smaller subject population and a shorter exposure window, both of which feed the benefit-risk assessment. Sponsors filing an early-feasibility IDE should still produce the SBOM and architecture views because both will carry forward into the pivotal IDE and the PMA.
What does the FDA expect in the cybersecurity portion of the informed consent form?
The guidance does not prescribe wording. At a minimum the consent must disclose that the investigational device has connectivity, identify the categories of cybersecurity risk (unauthorized access, data exposure, interference with device function), and explain how the sponsor will respond if a cybersecurity issue is discovered during the trial. The consent should be consistent with the general labeling submitted under 21 CFR 812.25(f) so a reviewer reading both does not see contradictory descriptions of connectivity or update behavior.
Do I need to submit a vulnerability management or postmarket monitoring plan with the IDE?
No. The Cybersecurity Management Plan, including postmarket vulnerability monitoring and coordinated disclosure, sits in the "could be helpful but not specifically recommended" column at IDE. That said, sponsors are expected to monitor vulnerabilities affecting components on the SBOM during the trial, because the FDA can ask about new CVEs discovered after IDE approval and the response will be reviewed at PMA. Operationally, you need the process; you do not need to submit it as a formal document with the IDE.
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.
Are software updates allowed during the IDE, and do they need cybersecurity review?
Yes, software updates are allowed and routine during a multi-year IDE. Material changes to the investigational plan require an IDE supplement under 21 CFR 812.35, and changes that affect the cybersecurity architecture, update mechanism, key management, third-party libraries with known vulnerabilities, operating-system upgrades, should be documented against the architecture views and SBOM submitted with the original IDE. The PMA will be reviewed against the current architecture, not the as-filed IDE architecture, so the update history needs to be defensible.
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, CISSP. 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.