FDA's 2026 Draft Guidance on Robotically-Assisted Surgical Devices: What's New

FDA's Robotically-Assisted Surgical Devices: Premarket Submissions guidance, issued on September 25, 2026, is a draft distributed for comment and marked “Draft: Not for Implementation”. It defines what counts as a RASD and excludes pre-operative planning and stereotaxic systems. It also expects fail-safe operation when teleoperation fails, and asks for training that covers OR staff, not only surgeons. This summary is based on the document as indexed in our FDA surgical robotics and SaMD base. The base holds no earlier FDA RASD guidance to compare against, so “what's new” here means what this draft sets out.

Status and timeline

• Issued: September 25, 2026, by FDA's Center for Devices and Radiological Health.
• Status: draft. When finalized, it will represent FDA's current thinking. Until then it is a proposal.
• Comments: due within 60 days of publication of the notice of availability in the Federal Register, via regulations.gov.
• Legal effect: like all FDA guidance, nonbinding recommendations unless specific statutory or regulatory requirements are cited.

What counts as a RASD, and what does not

The draft defines a RASD as “a teleoperated, software-controlled system” that integrates robotic technologies to help qualified practitioners precisely position and control surgical instruments in open, minimally invasive, or endoluminal procedures. RASDs are used under the direct control or supervision of a qualified practitioner and rely on a leader/follower control architecture, possibly with some automated functions. It describes three typical subassemblies: an operator (surgeon) console, a bedside/patient subassembly with working arms, and an OR staff subassembly such as a tower.

Fail-safe teleoperation and system controls

Because a RASD is a leader-follower system controlled by wired or wireless signals, the draft treats timely, accurate signal exchange as essential. Its key sentence: “RASDs should have fail-safe operation in the event of teleoperation faults (e.g., cable disconnection, electromagnetic interference).” The non-clinical testing it recommends includes:

• Total system latency, from hand input to instrument motion to the displayed image, kept within pre-defined, clinically justified limits under worst-case loads. FDA recommends testing at least three RASDs, or giving a rationale for fewer.
• Motion scaling and tremor reduction: characterizing scaling ratios across the workspace and showing that unintended input frequencies are filtered without losing intentional movement.
• Control stability: an accidental jolt to the hand controls should not reach the instruments in a way that could injure the patient.
• Fault recovery and emergency removal: detecting faults within clinically justified timeframes, reaching a safe state, and measuring the time needed to undock and give emergency access to the patient.
• Emergency and safety stops: halting motion and deactivating active instruments within a predefined limit, verified by measuring the distance traveled after activation.

Training that reaches the whole OR team

The draft asks each manufacturer to develop a training program validated to help users reach competency before clinical use, and to summarize the plan in the premarket submission. The key sentence: “The training program and competency expectations should not only focus on surgeons, but also include other OR staff, such as bedside assistants and surgical scrub nurses, who interact with RASDs.”

It also asks manufacturers to re-evaluate training when user interfaces change, including new instruments or new user groups. Training should account for each group's clinical background and familiarity with other robots, and should set measurable success criteria, such as the number of procedures surgeons generally need to reach competency. This fits FDA's existing public statements. FDA's computer-assisted surgical systems page says FDA does not accredit physician training and that hospitals should ensure other surgical staff are trained. The draft focuses on what the manufacturer should build and show.

Software, cybersecurity and AI features

• Software documentation: FDA thinks RASD software functions generally warrant the Enhanced Documentation Level of the final premarket software guidance. Claiming Basic needs a scientific rationale.
• Cybersecurity: if the RASD is a cyber device under section 524B(c), the submission must meet section 524B(b). The assessment, including penetration testing, should cover every connected network element, for example a simulation of the RASD communicating with a compromised hospital network.
• AI/ML features (segmentation, critical structure identification, instrument tracking): perform a risk assessment, discuss them with FDA via Q-Submission, and consider a Predetermined Change Control Plan for expected post-authorization software changes.
• Non-device functions such as procedure timers or video recording should be assessed for their impact on device functions.

Clinical evidence, umbrella procedures and labeling

For new RASDs, the draft says clinical data are often needed. FDA generally considers investigational RASDs to be significant risk devices under the IDE regulation (21 CFR Part 812). It recommends nine surgical endpoints: length of hospital stay; intraoperative adverse events; transfusion rate; conversion rate; post-operative adverse events, readmissions and reoperations through 30 days; mortality; and operative time. Comparator data from robotic procedures are preferred over laparoscopic data, and laparoscopic over open.

Appendix A sets out an umbrella and covered procedure paradigm. Data from a complex, higher-risk procedure (for example low anterior resection with total mesorectal excision) can support authorization for less complex procedures in the same specialty without procedure-specific data. The paradigm is meant for adding procedures, not for claims about treating a specific disease or condition.

On labeling, the draft recommends prominent emergency withdrawal procedures, learning-curve information and a summary of all in vivo evaluations. It proposes a statement that “outcomes related to the specific treatment of underlying disease or patient condition were not evaluated” as part of the authorization. It also says RASDs should generally be labeled “MR Unsafe” absent testing showing otherwise.

To check a specific point, ask the base, for example “If our robot's training program only covers surgeons, is that good enough for FDA?” The answer quotes the draft and states its draft status.

What to do while the draft is open

1. Check the scope first: confirm your system is a leader/follower, teleoperated RASD and not a planning, stereotaxic, remote or autonomous system that the draft excludes or does not address.
2. Gap-assess your verification plan against the teleoperation, control, kinematics, reliability and safety-stop sections, including worst-case latency testing on at least three systems.
3. Map every user group (surgeon, bedside assistant, scrub nurse, reprocessing staff) to training modules and human factors validation scenarios, including team scenarios.
4. Align clinical protocols with the nine recommended endpoints and decide early whether an umbrella and covered procedure strategy fits your indications.
5. Review your proposed labeling for emergency withdrawal, learning-curve data and the disease-outcome statement.
6. If you disagree with a recommendation, use the comment period; once the guidance is final, use the Q-Submission Program for device-specific questions.

Source: FDA draft guidance, Robotically-Assisted Surgical Devices: Premarket Submissions. Because it is a draft, check fda.gov for the final version before relying on any recommendation. This article is not regulatory advice.