Safeguard
Security Guides•

Therac-25: how a software bug became a radiation overdose

What went wrong with the Therac-25 radiation machine, why software replaced hardware interlocks, and what software teams still take from the case today.

Safeguard Security Team
4 min read

The Therac-25 radiation machine overdosed patients between 1985 and 1987 because software replaced hardware interlocks and carried timing and counter faults that no one had independently reviewed. At least six overdoses are recorded, and three patients died. It remains the standard example of an ordinary bug becoming physical harm.

What the machine was

The Therac-25 was a computer-controlled radiation therapy machine made by Atomic Energy of Canada Limited and introduced in 1982. It could treat in an electron mode or a photon mode. The photon mode needs a tungsten target in the beam path, because the raw electron beam is far too intense to hit a patient directly.

Earlier models in the family used hardware interlocks to guarantee that. The Therac-25 relied on software checks instead.

The faults that were found

Two software faults are described in the sources. In the first, an operator who typed one mode and then edited it to the other within roughly eight seconds could leave the machine in a state where the high current electron beam fired without the target in place. The edit was simply not processed.

In the second, a flag was incremented rather than set to a fixed value. When the counter wrapped around to zero, a safety check was skipped.

There were also process faults. Code was reused from earlier machines, whose hardware interlocks had been quietly masking the defects. Testing concentrated on hardware. The software was not independently reviewed.

Why it kept happening

Error messages showed only the word MALFUNCTION and a number, and the manual did not explain them. Some dangerous conditions only paused the machine, so operators got used to pressing a key and carrying on.

The manufacturer also told users that an overdose was impossible, which pushed hospital staff to doubt their own observations. The first complaint reached the US regulator late, according to the summary of the record we reviewed, and early fixes targeted a microswitch rather than the underlying logic.

Lessons that still apply

Keep an independent layer. When a hardware interlock is removed, the software becomes the only safeguard, and software can be wrong. Safety functions deserve a second, independent line of defence.

Do not reuse code on trust. Code that ran safely on one platform may have been protected by something the new platform lacks. Revalidate the assumptions, not only the interfaces.

Treat unexplained errors as signals. A cryptic error that operators learn to dismiss is a hazard in itself.

Take field reports seriously. Claims that something cannot happen should be tested, not repeated.

Review independently. The review that matters is the one done by people who did not write the code.

The medical device software lifecycle standard IEC 62304 was created in response to incidents of this kind, according to the source reviewed. See our explainer on software of unknown provenance in medical software for how that standard treats third party code.

Where supply chain tooling fits

The Therac-25 fault was in code the manufacturer wrote and reused. Today a device ships with many third party libraries as well, and the same questions apply: what is in the build, who reviewed it, and what changed. Safeguard can generate and analyse an SBOM for a project and run dependency scanning, which gives a safety team a current inventory to review. A free scan is at gold.safeguard.sh/scan. That helps with inventory. It does not replace a safety case.

Quick check

How many deaths were linked to the Therac-25?

The summary we reviewed says at least six overdoses occurred between 1985 and 1987 and that three patients died of them. One case is described as having a cancer cause of death alongside radiation damage, so exact counts vary by source.

Was it a hardware or a software failure?

Both mattered. The software had faults, and the hardware interlocks that earlier models used to contain such faults had been removed.

Sources

  • Therac-25, Wikipedia, a secondary summary; check figures against the original investigation reports before citing them formally.

Last reviewed: 19 October 2026.

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.