" " indicates required fields
On November 6, 2026, FDA’s Center for Devices and Radiological Health (CDRH) released Evaluating Benefit-Risk in Robotic Medical Devices with Autonomous or Remote Teleoperation Capabilities. The paper is not draft or final guidance, and FDA says it does not set regulatory expectations. It is an early request for input, organized around 15 discussion questions.
For manufacturers of connected medical devices, the cybersecurity sections are worth a close read. They show how FDA is thinking about risk when a device acts on its own, is controlled from a distance, or both.
Our reading is this. As medical robots become more autonomous and more remotely operated, cybersecurity risk depends less on any single part and more on how components, networks, software, and human users interact. That is why manufacturers need continuous, context-aware risk assessment across the product lifecycle.
The paper looks at robotic device systems that perform diagnostic, therapeutic, or rehabilitative tasks on human anatomy. Its scope goes beyond surgery and includes imaging, navigation, and endoluminal devices.
It focuses on two capabilities:
FDA notes that robotic systems with autonomous capabilities have been on the US market for years. It also states that, as of July 2026, no remotely teleoperated or fully autonomous robotic device system has received US marketing authorization. FDA is asking these questions before any such system has been authorized.
FDA is careful with its terms. Automatic behavior follows predictable rules, while autonomous behavior adapts to changing conditions. Autonomy is also a spectrum, and a system with some autonomous functions is very different from a fully autonomous one. FDA references several frameworks for classifying levels of autonomy and does not adopt any single one.
Autonomy could bring more consistent task execution, better accuracy, wider access to care, and a lower burden on users. The risks FDA lists include errors that execute before a user can step in, limited ability to adapt to unexpected conditions, and users who rely too heavily on the system. Where a system uses AI or machine learning, FDA adds unpredictable behavior outside the training data and performance that degrades over time.
Remote teleoperation could bring specialist care to underserved areas and speed up treatment for time-sensitive conditions. Some risks may increase with the separation between the remote user and the patient: slower response to adverse events, latency or loss of connectivity, loss of real-time imaging, and reduced sensory feedback for the user. FDA also notes that the locations with the most to gain may carry the greatest risk, because they have the fewest on-site resources.
From a cybersecurity point of view, the most important part of the paper is what happens when autonomy and remote teleoperation sit in the same system. FDA says the combination can create risks that neither capability creates alone, and gives two examples:
FDA adds a third point that matters most for security teams. In a system with both capabilities, a single cybersecurity vulnerability may compromise autonomous decision making and remote user control at the same time.
This is why a component-by-component assessment falls short. A review that looks at the robot, the network, and the user controls separately can miss the risks created by how they interact. The handoff between modes, the dependence on a live video feed, and the fallback when connectivity drops are properties of the system, not of any one part.
FDA states the principle directly. An end-to-end system perspective, not a review of isolated components, is an important part of evaluating cybersecurity risk.
This discussion sits alongside existing law. Section 524B of the FD&C Act already establishes cybersecurity requirements for qualifying cyber devices, including software-enabled devices with internet connectivity and characteristics susceptible to cybersecurity threats. These obligations apply to covered premarket submissions independently of the questions FDA raises in this paper.
FDA lists five cybersecurity considerations, drawn from its existing premarket cybersecurity guidance:
| Consideration | What FDA says |
|---|---|
| Network performance | Cybersecurity incidents, design vulnerabilities, or signal problems can degrade the network. A system that depends on connectivity may stop working. |
| System-level threats | Risk has to be evaluated end to end. A weakness in one element can spread across the whole system. |
| Integrity and non-repudiation | Without strong authentication and integrity controls, the accuracy of commands sent to the robot cannot be guaranteed. |
| Availability | Both the control end and the procedural end must stay functional for the full procedure. |
| Reliance on users | Users may not be able to spot and address a cyber threat on their own. |
The last point comes with a concrete example. A cybersecurity issue affecting the integrity of the video feed may not be apparent to a user at the patient’s bedside. The paper also observes that users may not have the bandwidth to deal with cybersecurity problems while they are performing a procedure.
Question 12 goes to the heart of the challenge. It asks what evidence might demonstrate a robotic device system’s ability to withstand unexpected degradations in connectivity or cybersecurity breaches. It also asks what safety controls may be needed to address hardware and software failure, and gives velocity limits, force safety stops, and positional monitoring as examples.
FDA does not answer the question. That is the purpose of the paper. But the question itself is telling, because it asks for demonstrated resilience at the system level, not a list of security features.
A threat model is a starting point, not proof of resilience. Showing that a system holds up also takes testing, validation, and documented controls. The paper’s risk mitigation section points the same way. It describes verification and validation that confirms the system performs as intended across a range of scenarios, including worst-case conditions.
The paper says risks may be mitigated through system design, performance testing, labeling, training, and postmarket oversight. It highlights four areas: verification and validation across scenarios that include worst-case conditions, user oversight and manual override, human factors and training, and postmarket monitoring through real-world data and Medical Device Reporting.
The discussion paper does not establish new requirements. Existing medical device safety and cybersecurity obligations remain in place, while FDA seeks input on appropriate approaches and benchmarks for evaluating these emerging capabilities.
| Questions | Subject |
|---|---|
| 1 | Terminology |
| 2 to 6 | Autonomous capabilities |
| 7 to 10 | Remote teleoperation |
| 11 and 12 | Combined risks, cybersecurity, and resilience |
| 13 to 15 | Risk mitigation and postmarket oversight |
The full wording of each question is in the FDA discussion paper.
Although the discussion paper introduces no new regulatory requirements, its questions suggest several practical steps manufacturers can take when evaluating system-level cybersecurity risks:
System-level risk is hard to manage when architecture, software components, vulnerabilities, and threat models live in separate tools and documents.
C2A Security’s EVSec platform connects them in a contextual cyber model of the product. That helps teams identify attack paths, prioritize risk, and manage product cybersecurity from design through postmarket.
The discussion paper sets no requirements, so no tool can claim to satisfy it. EVSec supports the cybersecurity work that underpins the questions FDA is asking. The table shows where it connects.
| What the FDA paper raises | How EVSec supports the work |
|---|---|
| System-level threats and cascading vulnerabilities | A cyber model of components, interfaces, and trust boundaries, with attack path analysis and contextual risk assessment across the whole system. |
| Integrity of commands and sensor data | Threat modeling of interfaces and trust boundaries, including attack scenarios against command and data paths. |
| Connectivity degradation | Risk analysis that helps teams identify failure scenarios and the controls needed to handle them. EVSec does not test or guarantee network performance. |
| Handoffs between autonomous and remote modes | Assessment of threats and dependencies between systems, so interaction risks are visible in one model. |
| Vulnerability exposure and Section 524B | SBOM management and vulnerability prioritization in the context of the device. |
| Verification and validation | Security tests derived from the threat model, with controls traced to threats and attack paths. This supports the manufacturer’s testing and does not replace it. |
| Postmarket oversight | Continuous vulnerability monitoring and risk reassessment as devices are updated. |
The common thread is the cyber model. Threat modeling, SBOM intelligence, and vulnerability monitoring all work from the same picture of the product. As architectures evolve or new CVEs are disclosed, EVSec helps teams keep threat models, risk assessments, and compliance documentation aligned through continuous monitoring and automated workflows.
That matters for the kind of device FDA is describing. A remotely operated or autonomous robotic system has a user console, a patient-side system, a network, and sensor and imaging data, often from different suppliers. A static, point-in-time threat model struggles to keep up with that.
EVSec’s AutoSynth AI capabilities help turn product architecture inputs into draft threat models and risk assessments, reducing the manual effort required to build and maintain them. Security teams retain control over reviewing the analysis, refining threats, and deciding how risks should be treated. The result is a more consistent approach across complex products and development teams.
EVSec does not establish a robotic system’s clinical safety, guarantee connectivity resilience, or replace clinical verification and validation. Manufacturers remain responsible for implementing and validating safety controls, conducting the appropriate testing, and demonstrating that the device is safe and effective.
What EVSec does is help make sure the cybersecurity work behind those activities is connected, current, and documented.
Medical device manufacturers are already working this way. Elekta, a leader in precision radiation therapy, selected EVSec to support dynamic threat modeling, SBOM management, vulnerability prioritization, and compliance reporting across its device and software portfolio.
Learn how C2A Security’s EVSec platform supports contextual cybersecurity risk management for medical devices, from design through postmarket. Explore EVSec for Medical Devices or schedule a demo.
