The Risk Medical Device Manufacturers Don’t Realize They Have...

When a medical device manufacturer licenses software from a small, innovative developer, it gains a capability it could not easily build on its own. It also takes on a dependency that rarely shows up in a product roadmap: the ongoing ability of that developer to maintain, patch, and support the code.

Most of the time, that dependency works quietly in the background. The developer ships updates, answers questions, and fixes issues. The risk only becomes visible when something changes on the developer’s side, and by then the manufacturer’s options are limited to whatever was planned.

This guide looks at that dependency from a technology continuity perspective: where third-party software sits in medical devices, how the relationship can break down, and how a verified escrow arrangement gives manufacturers a practical path forward after the licensing or partnership agreement is signed.

Where Third-Party Software Lives in Medical Devices

Third-party software typically reaches a medical device in one of two ways.

Embedded software. Manufacturers license operating systems, communication stacks, algorithms, and firmware modules from specialist developers and build them into physical devices. Once integrated, that code becomes part of the product, and any future change to it, including a security fix, depends on someone having the source code and the knowledge to rebuild it.

Standalone software. Regulators now authorize Software as a Medical Device (SaMD), which the International Medical Device Regulators Forum defines as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” Manufacturers increasingly license, co-market, or bundle these applications from the startups that create them. Many run in the cloud, which adds hosting environments, deployment scripts, and infrastructure access to the list of things the manufacturer relies on but does not control. 

A growing share of both categories now includes AI models, which introduces a third layer of dependency: the trained model itself, along with the code, data pipelines, and documentation needed to maintain it.

Why This Is the Manufacturer’s Problem

Regulators such as the FDA and their counterparts in Europe focus heavily on two areas for device software: cybersecurity and reliable operation over the life of the product. Recent FDA cybersecurity requirements, for example, expect manufacturers of connected devices to monitor for vulnerabilities, maintain a Software Bill of Materials (SBOM), and provide updates and patches after the device reaches the market. Quality system rules also expect manufacturers to oversee their suppliers and respond when a supplier can no longer meet its commitments.

The specific obligations vary by device and market, and your regulatory team is best placed to interpret them. The common thread is simple: those responsibilities stay with the manufacturer, regardless of who wrote the code. If a developer can no longer support its software, the manufacturer still needs a way to patch it, maintain it, and keep it running.

Three Ways the Developer Relationship Breaks Down

1. Support Ends While the Software Stays in Use

In 2019, the FDA issued a safety communication about a set of vulnerabilities known as URGENT/11 in IPnet, a third-party networking component used in several operating systems. The FDA noted that the component may no longer have been supported by its original vendor, and that some manufacturers had licenses allowing them to keep using it without support.

That detail captures the core issue. A license gives a manufacturer the right to use software. It does not guarantee that anyone will be available to fix it.

2. The Developer Goes Out of Business

Pear Therapeutics built one of the first FDA-authorized prescription software therapies and partnered with a major pharmaceutical company to bring it to market. In April 2023, Pear filed for Chapter 11 and stopped accepting new prescriptions while it looked for a buyer. A year later, Better Therapeutics, another developer with an FDA-authorized app, wound down operations and sold its assets.

Both companies had validated, authorized products. Both were small, innovative organizations that ran into business challenges. For any partner relying on their software, the future of that software was decided through a bankruptcy process and an asset sale rather than a continuity plan.

3. The Product Is Abandoned

Second Sight Medical Products developed the Argus II retinal implant, used by more than 350 people worldwide. After discontinuing the product in 2019, the company ran into financial trouble and largely stopped operating, leaving users with devices that no longer had technical support or software updates.

Second Sight was the manufacturer rather than a third-party developer, but the lesson carries over directly. When the organization holding the software knowledge disappears, everyone who depends on that software inherits the consequences.

A Note on AI Software

AI adds a distinct continuity challenge – an AI model may need to be retrained, recalibrated, or revalidated as data and conditions change. That work requires far more than source code: it depends on model files, training and inference code, data preparation steps and performance testing scripts. If a developer exits and those materials leave with it, the manufacturer may hold a working model today with no practical way to maintain it tomorrow.

Matching the Risk to the Escrow Response

What a Strong Medical Device Escrow Deposit Includes

A source code snapshot alone rarely gives a manufacturer what it needs. Depending on the product, a complete deposit can include:

• Source code for every version in commercial use, not only the latest release
• Build scripts, compiler and toolchain versions, and environment configuration
• The SBOM and a list of third-party and open-source dependencies with version numbers
• Architecture, design and interface documentation
• Test procedures used to confirm the software works as intended
• For AI-enabled software: model files, training and inference code, data preparation pipelines, model documentation and performance testing scripts
• For cloud-hosted software: infrastructure-as-code, deployment configurations, environment documentation and access instructions

Release Conditions That Reflect Real-World Risk

Standard release conditions cover bankruptcy and cessation of business. Medical device relationships often benefit from additional triggers that reflect how support actually breaks down, such as:

• Failure to deliver security patches within an agreed timeframe
• Failure to address a disclosed vulnerability
• Discontinuation of the licensed product
• An acquisition in which the new owner will not continue support

In-house counsel can align these conditions with the existing license or partnership agreement, so that access to the deposit is clear and enforceable when it matters. 

Verification: Confirming the Deposit Actually Works

A deposit only has value if the manufacturer can use it. PRAXIS Technical Verification is built around a full rebuild standard: confirming that the software can be reconstructed from what was deposited.

At Level 3, preceded by the earlier verification levels, PRAXIS witnesses, evaluates, and video-captures the depositor building the software from source code, identifying the steps, resources, and artifacts the build requires. The video becomes part of the deposit alongside source code, credentials and documentation, and PRAXIS provides a comprehensive findings report once the audit is complete. A Level 3 test does not prove the completeness, accuracy, or functionality of the deposit, but it gives manufacturers much deeper insight into what they would actually receive. 

For compliance teams, that findings report also serves as documented evidence that a critical software supplier has a verified contingency in place.

Keeping Coverage Current and Complete

Deposits that keep pace with releases. Medical device software changes often through patches, model updates, and new versions. PRAXIS Automated Escrow connects deposits directly to the developer’s repository, so the escrowed version stays aligned with the version in the field. 

Every version, for as long as it matters. Devices often stay in use for many years, and different units may run different software versions. PRAXIS Infinite Retention keeps every deposited version available, so a manufacturer supporting an older installed base can access the exact code running on those units. 

Security and predictability. Medical device deposits can include sensitive intellectual property, credentials, and model files. PRAXIS maintains SOC 2 certification, operates under U.S. jurisdiction for a clear and predictable legal venue, and offers all-inclusive pricing that makes it easier to budget escrow across a portfolio of software suppliers.

Practical Next Steps by Role

These steps assume the licensing or partnership agreement is already in place.

In-house counsel: Review existing software agreements for escrow provisions, identify critical developers without coverage, and align release conditions with how support could realistically fail.

Product managers: Build an inventory of third-party software and AI models in each product, and flag any component your team could not rebuild, patch, or retrain without the original developer.

Compliance managers: Document a continuity plan for each critical software supplier and keep verification findings reports with your supplier oversight records.

Executives: Identify which revenue-generating or patient-critical products depend on a single small developer, and make verified escrow a standard part of software partnership governance.

Closing the Gap

Small, innovative developers are a major source of progress in medical technology, and partnering with them is often the right decision. The goal is to make sure the manufacturer can keep supporting its products and its patients if a developer’s circumstances change.

URGENT/11, Pear Therapeutics, Better Therapeutics, and Second Sight show that this risk is real and well documented. A current, verified escrow deposit turns an open-ended dependency into a planned and manageable one.