Safeguard
Application Security•

Nuclear decommissioning robots: remote handling and secure software

Sellafield has run a robot arm inside an active glovebox and operated a robot from off site. Here is what the software behind remote nuclear work must get right.

Safeguard Security Team
5 min read

Nuclear decommissioning is one of the clearest cases for remote work: the hazard is radiation and contamination, and the aim is to keep people out of the room. Two public announcements from the UK show how far that has gone.

On 18 March 2025, Sellafield Ltd and AtkinsRéalis reported a trial in which a customised Boston Dynamics Spot robot on the Sellafield site was operated from an immersive room at Westlakes Science Park in Whitehaven. The operator was removed from the nuclear site entirely. The announcement cites a "highly secure virtual access network" and live streamed footage.

On 22 July 2025, Sellafield Ltd and the Nuclear Decommissioning Authority announced RrOBO, the Risk Reduction of Glovebox Operations project. A robotic arm, controlled remotely, was fitted inside an active nuclear glovebox at Sellafield, described as a world first, and was deployed into two gloveboxes at the MOX Active Demonstration Facility. It carried out a series of precise tasks while keeping full containment integrity. The goal is to reduce the hazards that legacy gloveboxes, some up to 60 years old, pose to workers.

This post does not claim any product reduces injuries. It asks what the software behind such systems must get right.

What the public record says, and does not say

The announcements describe capability and intent. The RrOBO page does not report hours worked or the number of workers removed from hazard, and neither announcement gives a safety statistic. That is worth stating plainly, because nuclear work attracts large claims. Check any vendor claim against a primary source with a date.

Why the software matters more when the person is away

When an operator stands in the room, their eyes, hands and judgment are the last safeguard. When they are remote, the safeguard is the control path: video, commands, interlocks and the code in between. Four properties matter most.

  1. Safe stop. If the link drops, a robot arm inside a glovebox must hold or retract in a defined way and keep containment. The behavior must be on the device, tested, and not dependent on the remote site.
  2. Human approval. Any action that cuts, moves or opens something is approved by a person. An AI model may suggest a sequence. It does not approve it.
  3. Tamper evident logs. Record each command, each approval and each sensor reading with trusted time. Store a copy outside the nuclear zone. In decommissioning, records are also evidence.
  4. Offline operation. Active areas are typically isolated from the internet. Scanning, policy checks and AI assistance must work without outbound access, and updates must arrive by a controlled, verified transfer.

Secure updates in a place where change is hard

Nuclear sites change software slowly and for good reason. That makes an update path a high value target and a high risk event.

  • Sign every update and verify the signature on the device.
  • Keep an inventory of exactly what runs on each machine: operating system, robotics middleware, libraries and firmware.
  • Test an update on a replica before it touches a machine in an active area, and keep a rollback.
  • Treat any remote access network as part of the safety case, not as IT plumbing.

What to do now

  1. Ask vendors for an SBOM covering control software and firmware.
  2. Check the SBOM against the CISA Known Exploited Vulnerabilities catalog and the vendor's advisories.
  3. Document what each robot does when the link, the power or the operator console fails.
  4. Define which actions require two person approval.
  5. Run your scanning on site, offline, with no data leaving.

How Safeguard fits, and where it stops

Safeguard does not operate robots or claim any safety outcome. For the supply chain side it offers SBOM generation and import, vulnerability scanning with known exploited status and reachability, firmware, container and dependency scanning, policy gates, audit logs, and fully air gapped deployment with offline models. A local runner keeps code on site.

Try it yourself

Take one robot or controller you know and list its libraries. Then ask: if one of them had a known exploited vulnerability today, how long would it take to find out? The demo below shows vulnerability management on an inventory.

Click through it at your own pace, or open it full screen.

Quick check

What did the RrOBO announcement report about safety outcomes?

It described a robotic arm operating in an active glovebox while keeping containment integrity, in two gloveboxes. It did not report hours worked or workers removed from hazard.

Why are logs evidence in decommissioning?

They record who commanded what and when, which supports investigation and regulatory review. They need protection against alteration.

Why must AI assistance work offline here?

Active areas are isolated, so any assistance that needs the internet is unusable or becomes a connection that should not exist.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.