Therac-25 Case Study: Race Condition, Deaths and Lessons

Reviewed September 17, 2026

Six patients received radiation doses tens to hundreds of times higher than prescribed from a single machine model over an 18-month period, and it took the fourth accident before AECL and hospital physicists correctly identified software as the cause. The Therac-25 incident is taught in nearly every software engineering and safety curriculum because it shows, with unusual clarity, how a latent software defect combined with removed hardware safeguards can kill people through a machine that had operated safely thousands of times before. Understanding exactly what failed, and why the failure took so long to diagnose, is directly relevant to how medical device makers build, verify, and secure software today.

Why This Matters

The Therac-25 is the case study that established why software cannot be treated as a black box in a safety-critical device. Before Therac-25, many manufacturers assumed that software, unlike a mechanical part, either worked or it did not, and that removing a hardware interlock was acceptable if the software "already" checked for the same condition. Leveson and Turner's investigation showed that assumption was false: the software passed years of field use before a specific timing sequence exposed the defect, and no amount of ordinary testing had caught it.

That gap between "worked in the field for years" and "safe" is exactly what the FDA's February 3, 2026 final premarket cybersecurity guidance and standards like IEC 62304 and ISO 14971 now require manufacturers to close through documented risk analysis, software safety classification, and independent verification rather than field experience alone. The guidance also reflects a point Therac-25 makes concrete: safety and security failures share the same root cause pattern, an unverified assumption about how software will behave under conditions nobody tested for.

Regulators and standards bodies did not treat Therac-25 as a one-time engineering mistake. It shaped the expectation, still in force today, that safety-critical software needs a documented hazard analysis, traceable requirements, and verification independent of the original developer, before it ever reaches a patient.

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); CISA Cybersecurity Advisories (including ICS medical advisories); CISA Known Exploited Vulnerabilities Catalog; FDA Medical Device Safety Communications.

What Was the Therac-25?

The Therac-25 was a dual-mode linear accelerator built by Atomic Energy of Canada Limited (AECL) that could deliver either low-energy electron beam therapy or high-energy X-ray photon therapy, selected by software rather than a separate physical configuration for each mode. It was the successor to AECL's Therac-6 and Therac-20 machines, both of which had used the same PDP-11-based control software architecture but retained independent hardware interlocks that physically prevented the beam from firing in the wrong configuration.

AECL's key design change in the Therac-25 was to remove those redundant hardware interlocks and rely on the software to enforce the same safety checks, on the theory that the software had already been proven reliable on the earlier machines. That assumption did not hold, because the earlier machines' hardware interlocks had been silently catching the same software defect for years without anyone noticing it existed.

What Was the Timeline of the Therac-25 Accidents?

Six accidents are documented between June 1985 and January 1987, spread across cancer treatment centers in the United States and Canada. The first occurred in Marietta, Georgia in June 1985, followed by a second in Hamilton, Ontario in July 1985, both producing severe tissue injuries that were not immediately connected to a machine malfunction.

A third accident occurred in Yakima, Washington in December 1985. The fourth and fifth accidents, in Tyler, Texas in March and April 1986, produced overdoses severe enough that a hospital physicist, Fritz Hager, was able to reproduce the fault by rapidly re-entering treatment parameters, which finally pointed investigators toward the software. A sixth accident occurred in Yakima in January 1987. Three of the six patients died from their injuries; the others suffered severe radiation burns and lasting tissue damage.

What Were the Technical Root Causes?

The Therac-25's failures trace to a small number of specific, well-documented software and process defects, not a vague "bug" or single line of bad code.

Reused software without hardware interlocks

AECL carried forward control software from the Therac-6 and Therac-20 into the Therac-25 but removed the hardware interlocks that had backstopped that software on the earlier machines. The software had latent defects the whole time; the hardware had simply been catching them.

The race condition in the data entry editing path

The core defect was a race condition triggered when an operator used the keyboard to edit treatment parameters after they had already been entered, and did so quickly, typically within about eight seconds. If the edit occurred during a specific window in the software's mode-setting sequence, the machine could apply the high-energy X-ray beam current setting while the physical turntable was still in the low-energy electron configuration, delivering an unfiltered, unflattened high-energy beam directly to the patient.

The one-byte overflow in the Set-Up Test counter

A separate defect involved a counter used in the Set-Up Test routine that incremented past its maximum representable value and overflowed to zero. When that overflow occurred at the wrong moment, a safety check that was supposed to run before treatment could be silently skipped, allowing treatment to proceed without the verification it depended on.

Misleading error messages

When the software detected an anomaly, it displayed generic codes such as "Malfunction 54" with no explanation of severity or cause. Operators had no way to distinguish a serious overdose condition from a minor, harmless glitch, so many simply pressed a key to bypass the message and continue treatment.

No independent safety analysis

AECL had not commissioned an independent hazard analysis or code review of the control software before deployment, and the company's own safety analysis relied heavily on the assumption that software, once fielded successfully, was reliable. No process existed to systematically ask what could go wrong in the software's timing behavior specifically.

Operator desensitization to frequent errors

The Therac-25 generated dozens of minor error messages during routine operation that required nothing more than pressing a key to continue. That volume of routine, harmless errors trained operators to treat every error message, including the rare serious one, as routine.

[KEY REQUIREMENT] A safety-critical device should never rely on software alone to enforce a condition that was previously enforced in hardware, unless that software has undergone independent verification specifically targeting timing and concurrency behavior, not just functional correctness.

What Was the Regulatory and Industry Aftermath?

See also: What Is MedTech? MedTech vs Medical Device vs Life Sciences, CVSS Scoring for Medical Devices: A Complete Walkthrough, and Medical Device Software Development: A Compliance Guide.

The Therac-25 accidents led the FDA to recall and require corrective action on the remaining machines, and AECL redesigned the software and reinstated hardware interlocks. More significantly, the case became a reference point cited in the development of subsequent software safety standards, because it demonstrated a concrete, documented failure chain rather than a hypothetical risk.

Leveson and Turner's 1993 IEEE Computer paper, based on AECL's own incident records and interviews, remains the standard sourced account of the incident and is still assigned in software engineering and biomedical engineering coursework today. The paper's central finding, that the accidents resulted from a systemic development and safety-culture failure rather than a single coding mistake, directly shaped how later standards frame software safety as a lifecycle discipline rather than a testing checkbox.

How Do Modern Standards Address Each Therac-25 Root Cause?

Every root cause identified in the Therac-25 investigation maps to a specific control that is now standard practice, or explicitly required, in medical device software development.

Why Do Safety and Security Share the Same Failure Modes?

Therac-25 was a safety failure, not a security failure, but the pattern is identical to one seen repeatedly in medical device security incidents: an unverified assumption about how software behaves under conditions nobody explicitly tested. A race condition that an attacker could trigger deliberately is a security vulnerability; the same race condition triggered by an operator's typing speed was a safety defect. Both come from the same source, insufficient verification of the software's actual behavior under untested conditions.

This is why the FDA's February 3, 2026 final premarket cybersecurity guidance asks manufacturers to build security into the same secure product development framework used for safety, rather than treating cybersecurity as a separate bolt-on activity. Defense in depth, the principle that no single control failure should lead directly to patient harm, applies equally to a missing hardware interlock and a missing network segmentation boundary.

Designing safety-critical software?

Blue Goat Cyber is a medical-device-only cybersecurity firm. Our team runs the threat modeling, penetration testing, and FDA-facing documentation MedTech submissions live or die on. Secure MedTech product design consulting

What This Means If You Are Commissioning Software Safety and Security Testing

Most teams read the Therac-25 case as history. If you are the person who has to buy verification work for a device whose software enforces a safety condition, it is a specification. Every root cause below is still something an independent test program either looks for or misses, and the difference usually shows up in how the engagement was scoped rather than in the final report's length.

Two practical notes for budgeting. Concurrency and fault injection work on embedded code costs more analyst time than interface scanning, so a quote that does not mention either is probably not scoped for this class of problem. And the independence requirement is why in-house verification alone tends to draw follow-up questions: the team that wrote the assumption is rarely the team that finds it. Our medical device penetration testing cost guide breaks down what each layer of that scope adds to a number.

How Blue Goat Cyber Approaches This

Blue Goat Cyber applies the same lesson the Therac-25 investigation taught the industry: software behavior needs to be independently verified against realistic failure conditions, not just functional requirements. Our medical device threat modeling work identifies race conditions, timing dependencies, and single points of failure in device software and architecture before they reach a patient or a submission reviewer.

We pair that with medical device penetration testing to validate that safety-relevant logic cannot be bypassed or manipulated through an exposed interface, and we help manufacturers build the ISO 14971 risk management file and IEC 62304 safety classification documentation the FDA's February 3, 2026 premarket cybersecurity guidance expects. If the FDA raises cybersecurity deficiencies after our submission support, we resolve them at no additional cost.

Frequently Asked Questions

What was the Therac-25?

The Therac-25 was a computer-controlled radiation therapy machine built by Atomic Energy of Canada Limited (AECL) in the early 1980s, designed to deliver both electron beam and high-energy X-ray cancer treatment from a single unit. It replaced the hardware safety interlocks used in AECL's earlier Therac-6 and Therac-20 with software-only controls.

How many people were harmed by the Therac-25?

Six documented accidents occurred between June 1985 and January 1987, and three of the affected patients died from their radiation injuries. The others suffered severe radiation burns and permanent tissue damage.

What caused the Therac-25 overdoses?

The primary cause was a race condition in the software's data entry editing path, which could let the beam fire in high-energy mode without the correct physical configuration in place if an operator edited treatment parameters quickly. A separate counter overflow defect and the removal of hardware interlocks compounded the risk.

Why did it take so long to identify the cause?

Early incidents were attributed to operator error or unrelated equipment problems because the software had operated without incident for years and the error messages the machine displayed gave no indication of an overdose. It took a hospital physicist reproducing the exact keystroke timing during the fourth accident to demonstrate the software defect directly.

Who documented the Therac-25 investigation?

Nancy Leveson and Clark Turner published the standard account, "An Investigation of the Therac-25 Accidents," in IEEE Computer in 1993, based on AECL incident records, FDA correspondence, and interviews. It remains the most cited and most rigorously sourced account of the incident.

What is the main lesson for medical device manufacturers today?

The main lesson is that software cannot be assumed safe because it has run successfully in the field; it needs independent verification against a documented hazard analysis, and no single software check should be the only barrier preventing patient harm. Standards like IEC 62304 and ISO 14971, and the FDA's current cybersecurity guidance, exist specifically to enforce that discipline.

CTA

If your device relies on software to enforce a safety condition that used to sit in hardware, that is exactly the pattern that caused the Therac-25 accidents. Contact Blue Goat Cyber to threat model your device's failure modes before an independent reviewer, or a real-world incident, finds them first.