Original research
One in 12 device recalls is a software defect.
Since 2003 the FDA has attributed 4,239 medical device recalls to a software defect — one in 12 of every recall it has assigned a cause to, and that share has not moved in two decades. 81.6% of them were designed in rather than deployed wrong, which makes an escaped defect a quality operating system problem before it is an engineering one.
- Years tracked
- 2003–2026
- Software recalls
- 4,239
- Share of attributed recalls
- 8.3%
Why this is the finding
A defect that ships as designed has passed every gate the organization has.
Requirements, review, verification, validation, and a regulatory submission — and the fault went through all of them, unnoticed, and shipped. That is not a statement about programmers. It is a statement about the quality operating system around them, which is what decides whether a defect is caught while it is still cheap or found in the field.
It is also what we are most often hired to fix. Three engagements, in three different regulated industries, all of them the same move — find the defect while it is still cheap, by changing the system that was supposed to catch it.
Where we have done it
A major automotive engineering organization
41% reduction in defects.
ASPICE built into daily engineering, requirements traceable through to verification, and defect detection moved upstream into development.
Built to Deliver, Proven to TransformA motorized equipment manufacturer
75% reduction in external warranty claims within 10 months.
A manufacturing quality operating system with tracked KPIs, plus a product-development QOS feeding field failures back into design as preventive learning.
Building a Data-Driven Operating SystemA rapidly growing EV startup
Production environment brought under statistical control.
Control plans, station-level inspection tooling, and FMEAs rebuilt against real failure data rather than against assumptions.
Powering Up
Why we built it
The regulator already named the cause.
The FDA does something no other product-safety regulator does: it codes the root cause of every device recall it classifies, and six of those codes name software. So unlike almost every other industry, you do not have to infer software involvement from free text — the regulator has already said it.
We aggregated it because nobody had. The API returns records, not trends; getting a per-year series out of it takes a query for every year, which is why the number is quoted so rarely and so loosely.
Compiled by Envorso from the FDA device recall database, published at open.fda.gov. Dataset compiled 2026-08-20.
Software-attributed device recalls per year
Recalls initiated, 2003–2026 · as of 2026-08-20 · 2026 year to date
Compiled by Envorso from the FDA device recall database, published at open.fda.gov. Dataset compiled 2026-08-20.
Where the defect came from
81.6% were designed in.
FDA codes a root cause for every recall it classifies, and it distinguishes a defect in the software as designed from one introduced by changing, building, deploying, or running it. The split is not close.
- Designed into the software
- 3,45881.6%
- Introduced by a design change
- 2255.3%
- Change control
- 2185.1%
- Manufacturing or deployment
- 1373.2%
- Design of a manufacturing process
- 1192.8%
- Behaviour in the use environment
- 821.9%
Software design
Software Design Change
Software change control
Software Manufacturing/Software Deployment
Software design (manufacturing process)
Software in the Use Environment
The other one in five
Change control, deployment and use-environment failures together account for the remaining 18.4%. Those are the ones release discipline catches. The rest were already wrong when the release process received them.
Limits
What this dataset cannot tell you.
Published in full, because the argument on this page is that evidence should be checkable, and that is worth nothing if we only publish the parts that help.
A rising share of recalls has no cause assigned at all
FDA increasingly records a root cause of “under investigation by firm” rather than a finding. Those recalls are excluded from the denominator here, because a share of a population that includes unclassified recalls is not a share of anything. But it means the recent software counts are a floor: some of those open investigations will close as software, and we have no way to know how many.
Recent years are undercounted, and always will be
A recall initiated late in a year is often not posted until well into the next one. The final year on the chart is marked incomplete for that reason, but the effect does not stop cleanly at a year boundary — the last two bars should be read as still filling in.
There is no “devices affected” figure
The vehicle dataset can say how many vehicles a recall covered. This one cannot. FDA records quantity as free text — “19 units in the US”, “approximately 1,200”, “unknown” — which cannot be summed honestly, so we do not publish a total. Counting recalls is the only defensible unit here.
The series steps up sharply in 2007, and we do not know why
Software-attributed recalls jump roughly sevenfold between 2006 and 2007, which is far too abrupt to be a change in how devices were built. It is much more likely a change in how FDA coded them. We show the early years rather than trimming them, and we do not treat that step as a finding.
Across the whole span, 13.3% of device recalls carry no assigned cause — 7,835 of 58,710. Every share on this page is calculated against the 50,875 that do.
What it means
The same finding, from the opposite direction.
The fixes people reach for first are the wrong ones. Better release hygiene, tighter change control, more careful deployment — between them, those address the other one in five. The rest were already wrong when the release process received them.
What moves the number is upstream of all of it: requirements that can be traced to the verification that proves them, defect detection that happens in development rather than in late-stage test, and field failures that feed back into design as a mechanism rather than as a post-mortem everyone attends and nobody owns. That is a quality operating system, and it is buildable — it is not a culture problem to be waited out.
Which is the same finding as the vehicle dataset, arrived at from the opposite direction. There the story is growth; here it is persistence. Both say software defects escape into regulated hardware because the delivery system lets them, and that the fix sits upstream of the code.
Two hours to find out whether we recognise your problem.
No deck, no obligation. We listen, we tell you whether we have seen this before, and we say what we think it would take. If a Jump Start is the right next step we will say so — and if it is not, we will say that too.