IDE Cybersecurity Requirements: The Investigational Device Guide (2026)

Most teams find this confusing for a defensible reason: the statute and the guidance do not have the same scope, and the difference shows up exactly at the IDE stage. Section 524B of the Federal Food, Drug, and Cosmetic Act is binding law and enumerates the submission types it governs. The FDA's premarket cybersecurity guidance is nonbinding but is the operative interpretation reviewers apply, and it deliberately reaches further than the statute does.

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 applications and submissions made 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 in the list.

That is a statutory scope fact, not a loophole, and it has one narrow practical consequence: the FDA cannot issue a refuse-to-accept decision on an IDE for failing the 524B(b) elements specifically, because those elements are not triggered. Everything else people assume follows from that fact is wrong. The agency can still find your investigational plan inadequate, still place a study on clinical hold, and still ask cybersecurity questions that must be answered before subjects are enrolled.

Never describe IDE as a "524B pathway" in a submission, a QMS document, or marketing copy. Reviewers notice, and it signals that the team has not read the statute.

What the guidance actually asks for at the IDE stage

The February 3, 2026 guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," applies to devices with cybersecurity considerations generally. That set includes 510(k)-exempt devices, IDE applications, and BLA and IND submissions. Cyber devices under 524B(c) are a subset inside that larger set, not the other way around.

Appendix 3 of the guidance sets out the documentation elements the FDA recommends for an IDE, tied back to the investigational plan requirements in 21 CFR 812.25 and the prior-investigations report in 812.27. In practice, the package is:

• A security risk assessment that identifies the cybersecurity risks the device presents and links each one to a potential harm to an enrolled subject, not to a hypothetical commercial user.
• A threat model covering the interfaces the investigational configuration actually exposes. Study builds frequently expose more than production builds do, including debug ports, telemetry endpoints, and unauthenticated service interfaces left in for troubleshooting.
• Security architecture views, scaled to risk. See the scaling rule below.
• A software bill of materials for the investigational build, with known vulnerabilities in third-party components identified and dispositioned.
• A plan for handling vulnerabilities discovered during the study, including how a patch would reach deployed investigational units and how the sponsor would notify sites and, where appropriate, subjects.

The last item is where IDE packages most often fall short. A marketing submission's postmarket plan is a future-tense commitment. An IDE's mid-study vulnerability plan has to be executable during an active clinical investigation, on devices in the hands of enrolled subjects, without invalidating the study protocol. Those are different documents even though both start from the same threat model.

The Appendix 4 scaling rule

Appendix 4 of the guidance is the part teams most often miss. It says documentation breadth should scale with the risk the device presents, and it gives the FDA's own sense of the range.

At the low end, a device with a single limited interface, such as a wired USB connection to a clinician workstation with no network path, may reasonably be documented with a single system-level view and a correspondingly narrow threat model. At the high end, a device that reaches a cloud service, runs on a commercial off-the-shelf operating system, or participates in a multi-patient care environment is expected to show multiple views: the global system view, a multi-patient harm view, an updateability view, and security use case views.

Two framing caveats matter. Table 1 in Appendix 4 is a template for organizing content, not a checklist to be filled in mechanically. And device-specific guidance, where it exists for your product family, takes priority over the general template.

The practical read: decide where your investigational configuration sits on that spectrum, write down the rationale, and let the rationale drive how many views you produce. A one-line justification for producing a single view is far stronger than four thin views produced because someone assumed all four were mandatory.

How IDE differs from 510(k) and PMA in practice

The artifacts overlap heavily. What changes is the audience, the risk frame, and the packaging.

Audience. An IDE is reviewed with an eye on the safety of a bounded, consented, monitored population, often in the dozens or low hundreds. A marketing submission is reviewed against an unbounded population using the device without study oversight. A residual risk that is acceptable under a monitored protocol with trained investigators may be unacceptable once the device ships.

Risk frame. IDE cybersecurity risk analysis should state the protections the study itself provides, such as site network controls, investigator training, and device accountability procedures, and then be explicit that those protections disappear at commercialization. Reviewers respond well to sponsors who name that gap rather than leaving it implicit.

Packaging. There is no eSTAR cybersecurity section to populate. The content lands in the investigational plan and the report of prior investigations. Sponsors who try to paste an eSTAR-shaped package into an IDE end up with a document that answers questions nobody asked and skips the ones 21 CFR 812 actually poses.

For a full side-by-side across every premarket route, see FDA pathway cybersecurity differences. For the step-by-step assembly of the package itself, including Appendix 3's five elements mapped to their 21 CFR 812.25 subsections and the Appendix 4 scaling rule, see the IDE cybersecurity submission guide. For the narrative walkthrough with the FDA's own language quoted, see FDA IDE cybersecurity requirements.

Making IDE work carry forward to the marketing submission

The strongest argument for doing IDE cybersecurity properly is not the IDE. It is that a well-built investigational package removes most of the work from the eventual 510(k), De Novo, or PMA.

That only holds if identifiers stay stable. The threat model produced for the IDE should use the same threat IDs, asset IDs, and control IDs that the marketing submission will use. When they diverge, the marketing submission's traceability breaks, and the leading cybersecurity deficiency pattern the FDA raises is precisely a broken chain from threat to control to test to patient harm.

A practical sequence that works:

1. Build the threat model once, at IDE stage, with production-intent identifiers.
2. Generate the SBOM from the investigational build and keep regenerating it as the build changes, rather than producing a one-off snapshot.
3. Run the security testing that the threat model calls for. Scope it to threats, not to an asset inventory.
4. Track every finding from the study period in one register, so the marketing submission can show a closed loop rather than a fresh start.
5. At the transition to the marketing submission, restate the risk analysis against the unmonitored commercial population and document what changed.

Teams that follow that sequence typically find the cybersecurity portion of the eventual submission is an extension exercise rather than a rebuild. Teams that treat the IDE as a throwaway do the whole thing twice, and the second pass is the one that runs against a submission clock.

Frequently asked questions

Does my IDE need an SBOM?

The statute does not require one, because 524B(b)(3) does not attach to an IDE. The guidance recommends one for any device with software, and reviewers routinely ask for it. Producing an SBOM during the investigational stage is also the cheapest time to do it, because the build is smaller and the dependency set is still being decided.

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 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 at all, so there is no agency cybersecurity review. The IRB still reviews the study, and the sponsor still carries the risk. The internal cybersecurity work should not be skipped simply because nobody at the agency is reading it; the marketing submission will read it later.

Do we need penetration testing before the study starts?

Not always, and the guidance does not mandate it at IDE stage. The deciding question is whether the threat model identifies a threat whose mitigation cannot be demonstrated any other way. If it does, test it before subjects are enrolled. See FDA penetration testing scope for 510(k) for how scope is derived from a threat model.

Does an IDE cybersecurity package satisfy Section 524B later?

Not on its own. It supplies most of the raw material, but the marketing submission adds the statutory elements 524B(b) requires, in particular the postmarket vulnerability management plan and the coordinated disclosure process, plus the eSTAR packaging. Treat the IDE package as the spine and the marketing submission as the finished body.

How Blue Goat approaches IDE cybersecurity

We scope IDE cybersecurity as the first phase of the premarket engagement rather than as a separate product, because the artifacts are the same ones the marketing submission needs. That means the threat model is built once with production-intent identifiers, the SBOM pipeline is stood up against the investigational build, and the mid-study vulnerability plan is written to be executable at your sites rather than as a paper commitment.

If you already have an active study and no cybersecurity documentation behind it, that is a recoverable position. The work is reconstructive rather than net new, and it is far cheaper to do now than during a marketing-submission review clock.

Talk to a premarket cybersecurity expert or read the full-service premarket package.

Related: the IDE cybersecurity hub collects every IDE guide, blog post, and pathway comparison we publish.