On this page
Published:
Key Takeaways
- Cybersecurity effort should rise with patient harm potential, and device class is a useful first signal of where a device sits on that scale.
- Device class alone does not settle cybersecurity risk; connectivity, autonomy, and clinical context can move a low-class device up the scale.
- Section 524B obligations are a floor for cyber devices, not a target, and the FDA guidance itself is framed around risk rather than a fixed checklist.
- In the deficiency letters we analyzed, the most common problems were thin evidence, not missing documents, which is what minimum-effort submissions tend to produce.
- Building above the minimum costs less than answering an [Additional Information letter](/services/fda-cybersecurity-deficiency-response "cybersecurity deficiency rescue") and losing weeks of review time.
Medical device cybersecurity should scale with the harm a device can cause. A Class III implant and a Class I wellness accessory should not carry the same security program, and neither should stop at the statutory floor. Section 524B sets minimum obligations for cyber devices. The FDA's February 3, 2026 guidance asks for documentation proportionate to cybersecurity risk. Our position: scale up with risk, and build above the minimum at every level.
I get asked some version of the same question every week: "What is the least we can do and still get cleared?"
I understand why. Budgets are tight and launch dates are fixed. But the question assumes cybersecurity is a checkbox with one correct size. It is not. The FDA's February 3, 2026 guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, says its recommended documentation "will naturally scale with the level of cybersecurity risk."
That is the right principle. Here is where we stand on it, and why we push clients past the minimum even when the minimum would probably pass.
Why This Matters
Section 524B of the FD&C Act requires sponsors of cyber devices to submit a plan to monitor and address postmarket vulnerabilities, to maintain processes that provide reasonable assurance the device and related systems are cybersecure, and to provide a software bill of materials. Those duties are law. Everything else in the February 3, 2026 guidance is a recommendation, and the guidance says so.
That leaves manufacturers with a choice. Some read "recommendation" as "optional." We read it as the FDA telling you what reasonable assurance usually looks like.
The standards point the same way. ISO 14971 asks you to manage risk in proportion to harm. AAMI TIR57 and AAMI SW96 apply that thinking to security risk. IEC 81001-5-1 builds security activities into the software lifecycle. None of them treat security as one fixed size.
Our own data shows the cost of thin evidence. In our review of 30+ FDA cybersecurity deficiency letters, 90% raised SBOM gaps, and 70% each raised security controls written only as principles, labeling, and testing. Those are not missing-document problems. They are evidence problems.
The practical stakes are simple. When a reviewer cannot tell whether a control is adequate, they ask. Each question costs review time, and review time costs launch dates.
What does a sliding risk scale for device cybersecurity mean?
A sliding risk scale means the depth of your cybersecurity work rises with the harm an attack could cause. A device that can deliver therapy, change a diagnosis, or fail silently needs deeper analysis, more testing, and stronger controls than one that only displays data.
This is not a loophole for low-risk devices. Every cyber device still owes the Section 524B items. The scale changes how much evidence you build around them.
"The below documentation will naturally scale with the level of cybersecurity risk. This will be most evident in the breadth of the Threat Modeling and Architecture Views documentation." (FDA, Cybersecurity in Medical Devices, February 3, 2026, Appendix 1, page 51)
Why device class is a starting point, not the answer
Device class is the fastest signal of where a device sits on the scale, but it is not the whole answer. Class reflects overall safety risk. Cybersecurity risk also depends on how the device connects, what it controls, and who can reach it.
A few examples of how a device can move up the scale:
| Factor | Moves risk up when... |
|---|---|
| Connectivity | The device reaches the internet, a hospital network, or a cloud service |
| Control | Software can change therapy, dosing, or alarms |
| Autonomy | Decisions happen without a clinician checking them |
| Scale | One compromise could reach many devices at once |
| Patient setting | The device runs at home, outside managed hospital networks |
A Class II device with remote dosing control can carry more cybersecurity risk than a Class III device that never connects to anything. We start with class, then adjust for these factors.
What "above the bare minimum" looks like at each level
Above the bare minimum means you can show a reviewer why each control is adequate, not just that it exists. The table below shows how we scale that in practice. It reflects Blue Goat Cyber's approach, not an FDA tier system.
| Risk level | Bare minimum | What we recommend |
|---|---|---|
| Lower (limited connectivity, no therapy control) | Section 524B items, basic threat model | Threat model tied to the actual architecture, SBOM with support status, targeted penetration testing of exposed interfaces |
| Moderate (networked, influences clinical decisions) | Section 524B items, threat model, SBOM | Full architecture views, traceable security requirements, independent penetration testing, documented vulnerability assessment for each component |
| Higher (therapy control, implants, cloud fleets) | Section 524B items plus guidance artifacts | All of the above, plus deeper testing such as fuzzing, a tested incident response process, and a postmarket plan with named owners and timelines |
See also: Medical Device Cybersecurity: Nanotech, AI Model Integrity for Medical Devices: Signing and Updates, and AI Training Data Security for Medical Devices: FDA Evidence.
Notice that the lowest tier still goes beyond the floor. That is deliberate.
Why minimum-effort submissions draw deficiencies
Minimum-effort submissions tend to describe controls instead of proving them, and that is exactly what reviewers flag. We read more than 30 FDA Additional Information letters in full for our MTEC webinar, "What the FDA Actually Wrote." The pattern was consistent, and it matches the full ranked list of deficiency categories: SBOM, controls described as principles, labeling, testing, risk assessment, the risk management report, unresolved anomalies, threat models, architecture views, and cloud responsibility.
The documents were usually there. The evidence behind them was not. SBOMs were present but missing support status or end-of-support dates. Security controls were written as principles, and reviewers responded that the adequacy of the control could not be determined. In one letter, that same finding appeared nine separate times.
That is what "bare minimum" produces in practice: a submission that technically answers every heading and still cannot show that the device is secure. Going above the minimum is how you stop the reviewer from having to ask.
Inline CTA: Want to see where your submission sits on the risk scale? Ask us for a fixed-fee quote and we will reply within 24 hours.
How Blue Goat Cyber Approaches This
We size every engagement to the device in front of us. We start with device class and intended use, then map connectivity, control paths, and deployment setting to place the device on the risk scale. From there we set the depth of the threat model, the scope of penetration testing, and the level of evidence each control needs.
Our team holds certifications including CISSP, CSSLP, OSWE, OSCP, CRTE, and CRTL. We have supported 275+ devices, with zero cybersecurity-related rejections to date. The goal is never a thicker binder. It is a submission where each control is traceable from requirement to test result, so a reviewer can confirm adequacy without writing back.
See how we apply this on our FDA premarket cybersecurity services page. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed.
Frequently Asked Questions
Does medical device cybersecurity risk depend on device class?
Partly. Device class is a useful first signal because it reflects overall safety risk. Cybersecurity risk also depends on connectivity, whether software controls therapy, autonomy, and the setting where the device runs. A connected Class II device that controls dosing can carry more cybersecurity risk than an isolated Class III device. Use class to start the assessment, then adjust for those factors.
Is meeting Section 524B enough to get cleared?
Section 524B sets legal minimums for cyber devices: a postmarket vulnerability plan, processes for reasonable assurance of cybersecurity, and an SBOM. Reviewers also look at whether the evidence shows controls are adequate, guided by the February 3, 2026 guidance. Submissions that meet only the statutory items with thin evidence often receive Additional Information requests asking for more detail.
Does a low-risk device need any cybersecurity work?
Yes, if it meets the cyber device definition. Every cyber device owes the Section 524B items regardless of class. A lower-risk device may need less testing depth and simpler documentation, but it still needs a threat model, an SBOM, and a postmarket plan. Lower risk changes how much evidence you build, not whether you build it.
Is the FDA guidance a legal requirement?
No. The February 3, 2026 guidance is nonbinding and describes the FDA's current thinking. Section 524B of the FD&C Act is the legal requirement for cyber devices. In practice, reviewers use the guidance to judge whether a submission shows reasonable assurance of cybersecurity, so departing from it means you need a clear justification.
Does going above the minimum mean more paperwork?
Not necessarily. Going above the minimum means stronger evidence, not longer documents. Traceable requirements, testing matched to the threat model, and component-level vulnerability assessments often make a submission shorter and clearer. The goal is that a reviewer can confirm each control is adequate without having to ask a follow-up question.
CTA
Not sure where your device sits on the cybersecurity risk scale? Send us your device description and we will tell you what the minimum looks like for it, and what we would add. You get a fixed-fee quote within 24 hours. Request a quote.
About the author: Christian Espinosa is the founder and CEO of Blue Goat Cyber and host of the Med Device Cyber Podcast. A U.S. Air Force veteran with red team experience, he has worked through about 50 FDA cybersecurity deficiency letters and presented "What the FDA Actually Wrote" for MTEC in 2026. Read more about 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.