The pros and cons of current regulations on using external software components in medical device software (SOUP or OTS)

The Contradiction of External Software Regulations

The regulations around external software components are mostly risk-averse and safety-oriented. This negates the benefit of updating components frequently. In this article, we look into this contradiction.

Regulatory Framework: IEC 62304 vs FDA Guidance

Currently, when developing software for medical devices, there are two sets of rules that deal with external software components:

• IEC 62304
• FDA guidance from 2019 — “Off-The-Shelf Software Use in Medical Devices”

IEC 62304 defines SOUP as follows:

So it’s really part of the software — a package, a dependency, a module linked in.

The FDA casts a wider net with their definition of Off-The-Shelf software (OTS):

These definitions already give you a sense of what the regulators are afraid of: software developed outside the building where the strict rules don’t apply.

It makes sense — everything developed under IEC 62304 is very strictly controlled and documented from start to finish, and as such can be traced and audited.

The Reality of Modern Software Development

But let’s look at the reality.

Any modern app — web, mobile, or otherwise — written in a language like Python, PHP, .NET, or JavaScript uses tons of open source libraries.

Open source claims to be more secure because of the “many eyeballs” principle. In practice, this is often proven to be correct.

The Update Problem

To make matters worse, the frequent and useful updates to these open source libraries are not easily integrated into medical device software.

Because any update to the SOUPs — like upgrading to the latest version — triggers a full new software release, including all required verification and testing.

Why the Distrust?

So why are all these open source libraries treated with such disdain?

Part of it is healthy pessimism — the assumption that software not created under strict regulatory rules is inferior, or at least unproven.

This is certainly true for closed-source software, but much less so for open source.

Outdated Standards and Slow Progress

The FDA is often the pioneer when it comes to new regulations in software for medical devices.

The IEC 62304 standard, however, is widely considered outdated, and recent attempts to modernize it have failed — delaying any new version by at least five years.

The SBOM Approach

If you want insight into the FDA’s current thinking, look at the draft guidance on cybersecurity for medical devices.

In it, they introduce a concept from the telecom industry: the Software Bill of Materials (SBOM).

An SBOM is a machine-readable list of all software components used in a product, including version numbers.

This information can be propagated automatically through the entire supply chain.

There are tools that can scan these SBOMs to:

• detect known defects
• identify vulnerabilities
• generate reports

This creates full transparency, allowing users — including clients, patients, and healthcare professionals — to understand potential risks.

Real-World Impact

You can imagine hospital IT teams keeping a very close eye on this as part of their cybersecurity defense.

What Comes Next

This guidance is still in draft status, meaning it is not yet mandatory.

However, the FDA has a history of finalizing guidance documents with minimal changes.

That means this approach could become standard within a year or two — potentially reshaping the medical device software market.