Latest

Approved—and already outdated the very next day?

The approval process assesses the current state of the technology. However, a medical device remains in use for 10 to 15 years. Three questions determine whether it will remain safe, maintainable, and available during that time.

Why approval is only a snapshot

Day 1: Everything has been tested, documented, and certified. Day 2: A new security vulnerability in an open-source library is disclosed. Nothing has changed on the device, and yet it no longer meets the standards of its certification. Approval is a snapshot in time. Afterward, the device remains in the field for 10 to 15 years. Components are discontinued, prices and availability fluctuate, new features are demanded, and cybersecurity requirements increase.
The MDR is clear on this point: software must be developed in accordance with the state of the art, including risk management and information security. The same applies to the IVDR. Guideline MDCG 2019-16 also expects manufacturers to monitor and respond to vulnerabilities throughout the entire product lifecycle. The state of the art continues to evolve. A device in the field does not do this on its own.

Which three questions will shape the next 15 years?

New security vulnerabilities are highly likely to arise over the course of a connected device’s lifecycle. Whether a manufacturer can handle them depends on three questions. They differ primarily in how much time is available to respond:

Hours: Am I even affected?
Weeks: Can I roll out the fix safely?
Years: Can I keep this up for 15 years?

Hours: Am I affected?

A new vulnerability is disclosed, usually as a CVE (Common Vulnerabilities and Exposures) entry in the public catalog of known security vulnerabilities. The first question from quality management, sales, or customers is: Is our device affected? Without a well-maintained Software Bill of Materials (SBOM), this means manually searching through hundreds of open-source components. That takes weeks, and the result remains uncertain. With a well-maintained SBOM and a defined assessment process, it’s simply a matter of comparing the component inventory with a vulnerability feed. A reliable assessment is then available within hours. This requires three building blocks:

Automated SBOM: Software components and license information are generated during every build in the project, rather than compiled retrospectively.
Automated CVE monitoring: Security databases are continuously compared against the SBOM.
Product context: Version, configuration, code actually enabled, exposure (e.g., is the affected interface accessible from the outside?), product variants, and installed base.

It is the context that turns a match into an assessment. The process ultimately yields one of three outcomes: not affected, apply a patch, or analyze further. Another key factor is the attack surface. Every software component running on the device must be monitored and assessed. Those who use only what is required in production have less to monitor. A custom-built embedded Linux system typically contains significantly fewer components than a general-purpose operating system like Android.

Weeks: Can I safely roll out the fix?

Wanting to fix a problem isn’t the same as being able to fix it. Once it’s clear that a patch is needed, other questions come into play:

Can I reproduce the affected build exactly?
Is the toolchain still available?
Are the operating system, kernel, and libraries still being maintained?
Are the tests automated, or is everything done manually?

A security patch that cannot be reliably built and tested does not solve any problems. That is why software maintenance must be included in the planning from the very beginning: regular update cycles for the product, operating systems and libraries with Long-Term Support (LTS), and automated test coverage. Hardware-in-the-loop tests verify the software on the actual target hardware. This increases test coverage and confidence in every update. Updateability is a matter of product architecture. The process consists of five steps: securely generating, signing, distributing, installing, and verifying the update package.

However, another question is crucial: What happens if the update fails partway through? A device that no longer boots after a power outage during installation is a serious problem in the field. A clean rollback to the last working state must therefore be part of the architecture.

Years: Will the device last 15 years?

There are two hands on this clock. The first is software support: LTS versions of the Linux kernel and libraries are typically supported for three to five years. That’s significantly shorter than the device’s lifespan. The second hand is component availability. Discontinuations and supply shortages are part of everyday life.

Both hands run out long before the device is taken out of service. For a regulated medical device, an unplanned change often means redesign and revalidation—that is, time and costs that no one had budgeted for.

What helps:

A lifecycle approach from the start: Software—including the maintenance process and component alternatives—is factored into the development phase. Recurring software updates are established as a process.
Plan for long-term effort: Analyses, preventive obsolescence screening, redesigns, and maintenance are predictable tasks that can be planned—either internally or with partners.
Close coordination: Development, manufacturing, and the marketing authorization holder coordinate throughout the entire lifecycle, not just when an issue arises.

What must the supplier provide?

The manufacturer bears product responsibility. However, much of the information it needs for this purpose is generated by suppliers. To ensure this information can be incorporated into the technical documentation, it should be governed by contractual and procedural arrangements:

Automated SBOM: Components, versions, licenses
CVE assessment (full or partial): Scan and technical assessment
Release notes: Changes and risks
Support and Limitations: Maintenance process, clear responsibilities
PCN/EOL: Change and end-of-life notifications with impact analysis and change management
Traceability: Mapping of serial numbers to software/hardware versions

Here's how Ginzinger electronic systems provides support

Ginzinger electronic systems develops, manufactures, and supports custom electronics and embedded systems. Specifically, this means the following for the three questions:

GELin, Ginzinger’s embedded Linux distribution, automatically generates the SBOM during the build process and also documents open-source licenses.
Security monitoring and software maintenance for GELin-based devices
Long-term support and product maintenance: obsolescence management, redesigns, and maintenance, coordinated between in-house development and manufacturing

Providing active support for a medical device over 15 years is becoming increasingly challenging. The good news: the tools to do this are available. An automated SBOM answers the “hour” question, an updatable architecture based on LTS answers the “week” question, and a planned lifecycle process answers the “year” question. It is crucial that all three are established before approval, not after.