Performing a thorough cybersecurity risk analysis for a medical device isn’t optional once your product qualifies under Section 524B of the FD&C Act. The FDA’s 2026 cybersecurity guidance is direct: if your device meets the “cyber device” threshold, you must demonstrate reasonable assurance of cybersecurity in your premarket submission, and a documented risk analysis is the primary instrument for doing that. This isn’t a paperwork exercise you can defer to the end of development.
Engineering teams frequently run into trouble not because they lack security knowledge, but because a medical device cybersecurity risk assessment requires translating technical threat scenarios into the safety-first language FDA reviewers expect. Knowing that a device has an unauthenticated API endpoint is one thing. Documenting why that endpoint creates a hazardous situation that could lead to patient harm, scoring that risk with a defensible rationale, and linking it to a tested control is something else entirely.
At Blue Goat Cyber, we work through this process with medical device manufacturers across a wide range of device classes and submission types. The framework below reflects the same structured approach our team follows, from the first threat modeling session through the final documentation package. By the end, you’ll have a clear, stepwise process you can apply to your own device.
What the FDA and ISO 14971 Actually Require
The “Cyber Device” Designation and What It Triggers
Under Section 524B of the FD&C Act, as clarified in FDA’s 2026 cybersecurity guidance, a “cyber device” is broadly defined as a network-capable device containing software that is susceptible to cybersecurity threats, including devices that can connect to the internet or other networked systems. This classification isn’t a technicality. It activates a mandatory set of cybersecurity documentation requirements for every premarket submission you file, whether a 510(k), De Novo, or PMA. For more detailed guidance on how to structure those premarket artifacts, see the FDA Cybersecurity Premarket Guidance, Blue Goat Cyber.
The FDA takes a risk-based approach, which means the depth of your analysis scales with device complexity and patient risk exposure. A connected insulin pump warrants a more exhaustive analysis than a low-acuity wireless scale. There’s no fixed checklist, but there is a clear expectation: document your reasoning systematically and make it traceable.
Where ISO 14971 Fits In (and Where It Ends)
ISO 14971 provides the foundational risk management framework for medical devices, and the FDA explicitly expects manufacturers to apply it to cybersecurity risks. The standard requires identifying hazards, estimating and evaluating risks, implementing controls, and monitoring their effectiveness across the device lifecycle. Cybersecurity fits squarely into that workflow when threats are framed as potential sources of patient harm.
The FDA is equally explicit that security risk management is distinct from safety risk management. You need both, and they must be traceable to each other. IEC 81001-5-1 extends ISO 14971’s principles specifically to cybersecurity for health software, addressing threats like unauthorized access and cyberattacks alongside traditional safety hazards. It effectively connects the two disciplines within a single risk management workflow.
Medical Device Cybersecurity Risk Analysis: Threat Modeling
Defining the Device’s Assets, Interfaces, and Threat Environment
Threat modeling is the first analytical step, and no risk scoring is valid without it. Before assigning numbers, your team must define what’s worth protecting: software components, data flows, communication interfaces, and any third-party dependencies embedded in the device stack. Common interface types include Wi-Fi, Bluetooth, USB, and cloud APIs, but the scope should reflect your specific architecture. A practical template can help structure workshops and outputs; consider using a cybersecurity risk assessment template to ensure consistent artifacts.
The FDA expects manufacturers to treat the network environment where the device operates as hostile by default. Your analysis can’t stop at the device boundary. It has to account for the broader ecosystem: hospital networks, connected infrastructure, external cloud services, and the supply chain itself. Anything that touches your device is in scope.
Common Attack Vectors in Connected Medical Devices
Real-world data makes the threat landscape concrete. According to Claroty’s 2023 State of XIoT Security Report, 99% of hospital-managed IoMT devices carry known exploitable vulnerabilities, and 21% of connected devices use weak or default credentials. Separately, research from Cynerio found that between 14 and 20% of connected devices run outdated operating systems with no patch path available. These aren’t hypothetical edge cases. They represent baseline conditions your device enters when it leaves the manufacturer.
Four threat scenarios your model should address are ransomware that encrypts device data or locks critical functions; unauthorized access that allows an attacker to alter clinical settings or therapy parameters; denial-of-service attacks via wireless protocols that render the device unavailable during a critical window; and data breaches targeting patient information stored on or transmitted by the device.
The threat model output, a documented list of threats, attack vectors, and proposed mitigations, becomes a direct input to the risk estimation step. Per the FDA’s 2026 guidance and the eSTAR submission template requirements, it’s also a required artifact in cyber device premarket submissions. Build it with the submission reviewers in mind.
Mapping Cyber Threats to Patient Safety Hazards
Separating Security Risk from Safety Risk and Then Linking Them
The ISO 14971 workflow requires a clear chain of reasoning: a cybersecurity event becomes a hazardous situation when it can plausibly lead to patient harm. An unauthorized command injection that forces an infusion pump to deliver an incorrect dose is not just a security event. It’s a safety hazard with a specific severity and probability, scored using the same framework you apply to every other risk in the device.
The FDA requires separate assessments for safety and cybersecurity, but both must be traceable to each other. If a threat in your security assessment can cause harm documented in your safety assessment, those two records must link. Reviewers check for this specifically. Missing traceability between the two files is one of the most consistent causes of cybersecurity deficiency letters in premarket submissions.
Scoring Severity and Likelihood with a Defensible Rationale
Severity scores must be anchored in clinical outcomes, not abstract data loss. Severity 5 means death or serious irreversible injury. Severity 1 means negligible inconvenience with no clinical impact. Every score in between requires a clear, documented clinical rationale. “High severity because the data is sensitive” won’t satisfy a reviewer. “High severity because exploitation can cause incorrect therapy delivery leading to irreversible patient injury” will.
Likelihood estimation in cybersecurity is more nuanced than in traditional safety analysis. It requires accounting for attacker motivation, required access level, skill prerequisites, and compensating controls already in place. A vulnerability requiring physical access, specialized firmware tools, and advanced reverse-engineering skills carries a materially lower likelihood score than one exploitable remotely with publicly available code.
A 5×5 impact-likelihood matrix is a practical and widely accepted scoring tool. The FDA doesn’t mandate a specific format, but it does require the rationale behind each score to be documented. The number alone isn’t sufficient, the reasoning that produced it must be captured in the risk management file.
Selecting Controls and Justifying Residual Risk
Layered Control Strategies Aligned with FDA Guidance
Per the FDA’s 2026 cybersecurity guidance, security objectives are organized into five categories: authenticity, authorization, availability, confidentiality, and secure updatability. Every control you select should map back to at least one of these. If you can’t articulate which objective a control serves, it shouldn’t appear in the submission as a primary defense.
The layered approach works like this: reduce the attack surface by design, remove unused ports, harden default configurations, and eliminate unnecessary services before the device ships. Then break exploit chains through strong authentication and encrypted communications. From there, limit impact using partitioning and failsafe behaviors that preserve essential device performance even under attack. Finally, enable detection through logging and alerting that gives operators visibility into anomalous behavior.
Controls must be verifiable. The FDA expects verification and validation evidence for every control, along with traceability to the corresponding test. Where a control isn’t directly testable, a reasoned justification and alternative evidence must be documented. Design controls with testability in mind from the start.
Documenting Residual Risk Acceptance with a Written Rationale
Residual risk is the risk that remains after all controls are applied. The FDA requires manufacturers to evaluate whether this remaining risk is acceptable relative to the clinical benefit the device provides and relative to the state of the art in comparable devices. Neither “residual risk is low” nor “controls are in place” is a complete answer.
The residual risk acceptance statement is a specific document: it identifies the hazardous situation, names the controls applied, quantifies the remaining risk level using your established scoring criteria, and provides a written explanation of why the benefit-risk tradeoff is acceptable. It needs a signature from appropriate personnel, and it becomes a permanent part of the risk management file.
This document will be reviewed during the FDA premarket assessment. Draft it as if a reviewer with no context for your device will be reading it independently. Clarity and completeness here reduce the probability of a follow-up information request.
Medical Device Cybersecurity Risk Analysis: Testing and Evidence
Vulnerability Scanning, Penetration Testing, and SBOM Analysis
Verification and validation testing is how the FDA confirms that the controls documented in your analysis actually work. Three primary methods apply here. Vulnerability scanning automates the identification of known weaknesses in software and firmware. Penetration testing simulates real-world attacks against the device. SBOM analysis surfaces vulnerabilities in third-party components your device depends on but that your team didn’t write.
For high-risk connected devices, the FDA expects comprehensive independent penetration testing aligned with PTES or CREST standards. The scope must cover firmware, APIs, communication protocols, and hardware interfaces. For moderate-risk devices, the scope can be narrowed, but key attack vectors from the threat model must still be covered. Independent means external to the development team; internal testing can supplement, but typically doesn’t satisfy the independence requirement on its own.
Fuzz testing, static application security testing (SAST), and dynamic application security testing (DAST) are supporting methods that strengthen the overall evidence package. They close coverage gaps that manual penetration testing can miss, particularly in complex firmware and protocol stacks, but they don’t replace it.
What the Design History File Must Capture
All testing artifacts belong in the Design History File as part of the quality management system. Each test record should include the protocol used, the scope and methodology, findings with severity ratings, remediation actions taken, and a traceability matrix linking each test back to a specific security requirement and the corresponding risk in the risk management file.
The chain from threat to control to test evidence must be unbroken. FDA reviewers look specifically for this chain. A control that appears in the risk assessment but has no corresponding test record is the most common source of cybersecurity deficiency letters in premarket submissions. Build your traceability matrix as you go, reconstructing it after the fact rarely produces a clean record.
Assembling the Regulatory Submission Package
Required Documentation Artifacts for a Premarket Submission
A complete cyber device submission requires a specific set of documentation artifacts. The core deliverables include a cybersecurity management plan, threat model and risk assessment report, security architecture documentation, SBOM with vulnerability traceability in machine-readable format, verification and validation testing evidence, residual risk acceptance statements, and cybersecurity labeling disclosures.
All of these feed into the Secure Product Development Framework (SPDF) documentation, which demonstrates to the FDA that cybersecurity is embedded in the manufacturer’s quality system rather than assembled at the end of development. The SPDF is evidence of process maturity, not just product security.
For electronic submissions using the FDA’s eSTAR template, each artifact maps to a specific section of the submission template. Mismatched or incomplete entries generate additional information requests that pause the clearance timeline. The eSTAR process has very little tolerance for documentation that’s complete in substance but filed in the wrong place.
How Blue Goat Cyber Builds Submission-Ready Packages
Blue Goat Cyber specializes in building complete FDA cybersecurity submission packages for medical device manufacturers. The team’s exclusive focus on medical device cybersecurity means they understand how reviewers read these files and where documentation gaps tend to surface, the kinds of nuances that broad-practice cybersecurity firms, for whom medical devices are one service line among many, typically don’t develop.
The integrated engagement model means Blue Goat Cyber handles threat modeling, risk analysis, control documentation, penetration testing, SBOM development, and SPDF documentation as a single coordinated workflow. Device manufacturers don’t need to coordinate multiple vendors, interpret guidance documents independently, or discover gaps after a submission has already been filed.
Manufacturers who engage Blue Goat Cyber early in the design phase can avoid one of the most costly outcomes in the clearance process: a deficiency letter that stalls the timeline while the product sits in review. Addressing cybersecurity documentation before submission is generally far less disruptive, and far less expensive, than responding to a deficiency under time pressure after the fact.
Putting It All Together
The end-to-end medical device cybersecurity risk analysis follows a clear sequence. Build the threat model first. Map identified threats to patient safety hazards using the ISO 14971 framework. Score each risk with documented clinical rationale for both severity and likelihood. Apply layered controls that address the FDA’s five security objectives. Test every control and capture the results with full traceability. Then assemble the complete documentation package with each artifact properly organized for your submission format. For a broader perspective on how the landscape for medical device cybersecurity is evolving, see Navigating the Evolving Cybersecurity Landscape for Medical Devices, Blue Goat Cyber.
The FDA isn’t asking for perfection. It’s asking for evidence that you’ve thought through the risks systematically and made reasoned, documented decisions. A submission that shows clear thinking, honest residual risk acceptance, and thorough testing will consistently outperform one that attempts to minimize or obscure risks that any competent reviewer will find.
If assembling this package feels overwhelming, that’s exactly the problem Blue Goat Cyber was built to solve. A firm that does nothing but medical device cybersecurity brings focused expertise and a submission track record that generalist consultants can’t replicate. If you need help with your medical device cybersecurity risk analysis, please schedule a no-cost Discovery Session with us today!