Kaye Grant
← Failure AtlasMedical Devices · 1987

Therac-25: The Machine That Trusted Software With Lives

A radiation therapy machine dropped the hardware safety locks of its predecessors and trusted software alone. A timing bug then delivered massive overdoses while the screen read normal. Patients died.

Failure typeDeterministic (a race condition, reliable under the right timing)
Where it failedPeople · Process · Technology
FiledJun 2026
The missing control

Earlier models had physical interlocks that made an overdose impossible; the Therac-25 removed them and relied on software with no independent check. The control absent: a hardware safety layer the software cannot override, and a process that treats injury reports as signal rather than explaining them away.

NIST RMFIndependent safety layers. The check on a system cannot live inside the system.
ISO 42001Treat operator reports of harm as signal, and investigate before the next dose.
EU AI ActFor systems that can injure, robustness and human oversight are not optional.
STAMPRemoving the hardware interlock removed the control that kept the hazard contained.
PlainIf the only thing stopping a lethal dose is software, eventually it will not stop it.

Between 1985 and 1987, a radiation therapy machine called the Therac-25, built by the company AECL, gave at least six patients massive radiation overdoses, some more than a hundred times the intended dose. Several of them died. It is the first case anyone serious about software safety learns, because nearly every modern lesson is already in it.

Earlier models, the Therac-20 and before, had physical interlocks: hardware that made it mechanically impossible to fire the high-power beam without the protective apparatus in place. The Therac-25 removed them. It relied on software to enforce the safety that metal had enforced before.

The software had a flaw. If an operator typed and corrected the treatment settings quickly, a race condition in the code could leave the machine in a state where it fired the high-power electron beam without the target that was supposed to spread and weaken it. The screen showed a normal dose, or an obscure error, Malfunction 54, that the manual did not explain. The operator, seeing nothing obviously wrong, could administer the dose again.

Where it failed

The bug was deterministic. Given the same fast sequence of keystrokes, the same dangerous state resulted. It was not bad luck, it was reproducible, which is exactly why testing should have found it and a safety review should have refused to ship without an independent check.

But the bug was the smallest part. The same race condition had existed in the Therac-20, and no one was hurt, because the hardware interlocks caught it. The Therac-25’s failure was the decision to remove those interlocks and trust software alone, with no independent layer to catch a software fault. And when injuries were reported, AECL was slow to accept that the machine could be at fault, testing in ways that did not reproduce the problem and reassuring hospitals while patients kept being harmed. The break was in technology, in process, and in people, in that order of depth.

The software fault was old. Removing the hardware that caught it is what made it lethal.

How it could have been caught

Keep an independent safety layer that the software cannot talk its way past, because the whole point of a safeguard is to catch the failure of the thing it guards. Write error messages that tell the operator what is actually wrong, so a dangerous state cannot hide behind a number. Test the concurrent, fast-input cases, not just the tidy ones. And treat the first report of harm as the most important signal you will get, not a complaint to be managed. Each accident after the first was a control that did not fire.

What it means for AI

Therac-25 is decades old and reads like a brief for the present. Its lessons are the ones AI keeps relearning. Do not let the only check on a system live inside that system. A working safeguard should not be removed just because a newer, smarter version is supposed to make it unnecessary. And software should never be trusted with an irreversible action when there is no independent layer to stop it.

A model is the software-only safety case all over again: opaque, sure of itself, and capable of a wrong answer that the screen presents as normal. The control is the same one AECL removed: an independent check, outside the model, that can catch it when it fails, and a culture that treats the first sign of harm as a reason to stop rather than a problem to explain.

← Back to the Atlas