Medical Device Cybersecurity From Animal Studies to Human Trials

A connected implant or wearable usually moves through a long path before it reaches patients: bench testing, small animal work in mice or rats, larger animals such as pigs or sheep, sometimes primates, and then human studies. Most teams treat cybersecurity as something that starts at the IDE, or worse, at the 510(k), De Novo, or PMA. By then the wireless stack, operating system, and update method were often chosen years earlier, tested in animals, and frozen by the data. Changing them means new testing and harder questions from reviewers. This post walks through each stage, what cybersecurity looks like there, and what to have ready before you enroll the first human subject.

Why this matters

The FDA's final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, dated February 3, 2026, applies to premarket submissions for devices with cybersecurity risk, including Investigational Device Exemptions. Appendix 3 lists what the FDA recommends for an IDE, and the rest of the guidance sets the bar for the marketing submission. For a cyber device under FDA Section 524B, that marketing package includes an SBOM, a threat model, security risk management, testing including penetration testing, and a postmarket plan.

None of that is written for animal studies. But animal studies are where most design decisions get proven. If a pig study validated your device with an unauthenticated Bluetooth link and an open debug port, you now have clinical evidence built on a design you will need to change. The FDA wants security built into design controls, not added at the end, and reviewers can tell when a threat model was written after the device was finished.

There is also a data side. Large animal studies that support safety are typically run under the Good Laboratory Practice rules in 21 CFR Part 58, and electronic records fall under 21 CFR Part 11. If your device or its software produces the study data, the integrity of that data is part of whether the study counts.

Stage 1: Mice and rats, proving the idea

Rodent studies answer basic questions: does the material react badly, does the sensor read anything useful, does the concept work at all. The device is often a prototype with lab software, wired connections, or a development board.

Cybersecurity at this stage is light, and that is fine. What matters is not to lock in shortcuts:

• Write down the software you use. A simple list of operating systems, libraries, and versions becomes the start of your SBOM.
• Keep study data clean. Even outside GLP, a shared lab laptop with no access control is how data gets changed or lost.
• Note the design assumptions. If the plan is to add wireless later, record that, so it gets a threat model before it gets built.

Stage 2: Pigs and sheep, testing a near-final design

Large animals are used because their size and anatomy are closer to humans for many device types. Pigs are common for cardiovascular and many implant studies, and sheep for orthopedic work. By this stage the device usually looks much like the version you plan to put in people, including its wireless link, companion app or programmer, and sometimes cloud reporting.

This is the most important stage for cybersecurity, because the design is becoming real:

• Freeze nothing you have not threat modeled. Draft the architecture views now: the whole system, anything that could affect more than one patient, and how the device gets updated.
• Treat telemetry as real. Wireless data from the vivarium is study data. Encrypt it and record which device and software version produced each reading.
• Remove lab backdoors before they become habits. Debug ports, default passwords, and test accounts added for the animal team have a way of shipping.
• Meet GLP data integrity. If the study supports safety under 21 CFR Part 58, audit trails, access control, and record retention for electronic data should follow 21 CFR Part 11.

Stage 3: Primates, long implants and wireless links

Non-human primates are used less often and mainly where anatomy or behavior matters, such as some neural implants and brain-computer interfaces. These studies can run for months or years, which brings in a problem the shorter studies do not have: the device has to be maintained while implanted.

• Plan updates in the body. If firmware will change during the study, the update process needs signing and checks, the same as it will in people.
• Watch the long-term data path. Months of neural or physiological data moving to a workstation or cloud service need the same protection you will need in a clinic.
• Track component support. A study that runs two years can outlast support for an operating system or radio chip. Note end-of-support dates in the SBOM now.

Stage 4: Humans, from the IDE to the pivotal study

Human studies of a significant-risk device run under an IDE (21 CFR Part 812). That might start with an early feasibility study in a small number of subjects, move to a larger feasibility study, and end with a pivotal study that supports the marketing submission.

See also: Home Use vs Hospital Device Cybersecurity Requirements, Indications for Use, Predicates, and Cybersecurity Scope, and Breakthrough Device Designation and Cybersecurity.

The IDE is the first time FDA cybersecurity reviewers look at your device. Under Appendix 3 of the February 3, 2026 guidance, the FDA recommends a narrower set than the marketing submission: disclosure of cybersecurity risks in the informed consent form, architecture views, a security use case view focused on safety, an SBOM, and general cybersecurity labeling. Our FDA IDE cybersecurity requirements post covers each item and what is deferred.

Two things change once people are involved:

• Patient safety is now the test. The threat model has to show how a compromise could harm a patient, stop the device working, or corrupt data a clinician acts on.
• The pivotal design is the marketed design. Whatever runs in the pivotal study is what the full package must describe. A threat model, penetration test, and postmarket plan built during the trial avoid a scramble at submission.

A simple stage-by-stage checklist

How Blue Goat approaches this

We usually join a project during large animal work or just before the IDE. We start with the architecture you have, not a template, and draft the views the FDA expects: the whole system, multi-patient harm, and updateability. From there we build the SBOM from your real software, write a threat model tied to your hazard analysis under ISO 14971, and flag design choices that will be hard to defend in people, such as open debug interfaces or unsigned updates. For the IDE, we prepare the Appendix 3 items, including informed consent language your clinical team can use. During the trial, we finish the full package, including the penetration test, so it is ready when the pivotal data is. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.

For a narrower start, our threat modeling service fits large animal work, and our full premarket package covers the path from IDE to clearance.

FAQ

Does the FDA require cybersecurity documents for animal studies?

The February 3, 2026 premarket cybersecurity guidance covers IDE and marketing submissions and does not list cybersecurity deliverables for animal studies. Animal studies that support safety are usually run under GLP rules in 21 CFR Part 58, and electronic records fall under 21 CFR Part 11, so the integrity of data your device produces still matters. The design you test in animals also shapes what you will need to defend later.

When should we start the threat model?

Start a draft during large animal work, when the device design is close to final. Rodent prototypes change too much to model in detail, but pig, sheep, and primate studies test the wireless link, app, and update method you are likely to keep. A threat model written then can still change the design. One written after the pivotal study usually cannot.

What cybersecurity does the FDA expect in an IDE?

Appendix 3 of the February 3, 2026 guidance recommends disclosure of cybersecurity risks in the informed consent form, architecture views, a safety-focused security use case view, an SBOM, and general cybersecurity labeling. Items such as penetration testing and a full risk management report are listed as helpful but not specifically recommended at IDE. They are expected in the marketing submission.

Can we change the software between the animal study and the human study?

Yes, and many teams have to, for example to add encryption or remove debug access. Record each change, assess whether it affects safety or study results, and keep the versions tied to the data. Changes made earlier are easier to justify than changes made after the pivotal study, when the FDA will want to know whether the clinical data still applies.

Does an early feasibility study need the full cybersecurity package?

No. An early feasibility study runs under an IDE, so the IDE recommendations in Appendix 3 apply rather than the full marketing package. Using the early study to build the threat model and SBOM properly makes the pivotal study and the marketing submission much easier.

CTA

Planning a large animal study or your first human study? Book a free 30-minute call. We sign a mutual NDA first, then a senior engineer reviews your architecture and tells you what to fix now, what can wait until the IDE, and what the marketing submission will need.