Long-term support for medical devices

Time is relative, as we know from both Einstein, and the simple experience of being in a waiting room for what feels like forever. And, with Medical, when we say, “Long-term maintenance”, we mean Long-term. While a connected speaker might be expected to live for 5-10 years, medical devices are commonly required to last 20 to 30 years. 

Decades of effort to ensure those devices continue to work safely. Decades where, should a problem occur, devices must be repaired, or replaced. And decades where, regardless of the ebbs and flows of technologies and companies, the software (and hardware!) needs to keep running. 

Luckily, we don’t need a crystal ball, but we can – and should – plan for it. Zooming in on the software, this means: 

• Being able to own and maintain the technologies used, no matter what happens 
• Understand how security vulnerabilities are impacting your product 
• Having a long-term software and maintenance strategy 

Since our 30-year-old Linux v1.0, it grew to be the OS powering billions of devices. Yocto is the industry standard to create Linux distribution for embedded, supported by most hardware vendors, and offers everything needed by even the most demanding and complex products.

From system generation across multiple hardware, to secure boot, and software inventory information. 

And you might be thinking: “Is it certified for medical though?” and this is where I mention that you have a choice. To either have a commercial pre-certifiable solution but be locked with it, with no guarantee it will be around in 15 years (let alone 30 years). Or do a bit more upfront work and have the guarantee you will be able to maintain it. No surprises. 

I personally think that one is the easiest to solve. The only way to maintain something is to own it. And the only way to own the software stack is Open source. Open source that you can fully access and modify, without asterisks. And there, without a doubt, Yocto Linux is where the industry is consolidating for microprocessors. 

Your security strategy and risk mitigations must be designed for your specific product context. Both are essential outputs of threat modeling and cybersecurity risk assessment, activities recommended by the FDA for Pre-Market Approval (PMA). This means identifying and having control over: 

• The environment around your product: connectivity, personnel training, physical access 
• The interfaces, mechanisms, and software inside your product 

You are probably already convinced of the need to track vulnerabilities. If not willingly, because of 524B(b) and its constraints regarding both monitoring and deployment of security patches. Let’s break down the process: 

1. Regularly gather vulnerabilities that affect your software components using the SBOM 
2. Review all new and updated vulnerabilities and identify those of impact 
3. Apply patches and updates necessary to address them 
4. Perform appropriate testing and validation 
5. Distribute 

Gathering vulnerabilities is done automatically with tools (such as CVE Scan), which also focus on reducing the number of false positives. I recommend continuously running your vulnerability monitoring, to be alerted in case of a critical vulnerability. Provided a good tool is used for Step 1, the review (2) and application of patches (3) can typically be executed in a few days, if you are using a Long-Term Support version (this is important!). 

You might have already identified the pain point in this list: the Testing and Validation (4). In most cases, this is going to be your bottleneck to enable more frequent updates. That is, unless you have a good coverage of automated tests, at the Integration, System, and Functional level. 

Going back to time relativity, you might be surprised to learn that long-term supported version with Linux and Yocto are only a few years long. Because it depends on individual and company contributors, maintaining it for a long time is not easily achievable. 

To benefit from the continued support and patches from the community, you must plan your software release strategy around it. Enters “LTS hopping”! Yocto’s LTS are now maintained for 4 years instead of 2, making it easier for OEM to adopt. Planning every 2-4 years to move from one LTS to another guarantees you will get the latest updates and patches. 

While hopping to a new long-term version needs additional testing and validation, the return on investment is a vastly more efficient maintenance cycle, reducing bugs, vulnerabilities, and effort.

During development 

• Select software and tools you can maintain, no matter what (i.e. Open source!) 
• Perform threat modeling and security risk analysis. Identify risks, context, and mitigations, and implement those mechanisms and mitigations. 
• Create a lean OS image, with only the software you require 
• Build test automation for integration, system, and functional tests 

Every 1-3 months once released 

• Monitor vulnerabilities using automation (automatically, with alerts) 
• Review, and patch vulnerabilities 
• Test and validate, leveraging automated tests, and deploy 

Every 2-4 years 

• Upgrade (“hop”) to latest available Long-Term Support version of your OS to continue receiving security patches 
• Test and validate, leveraging automated tests, and deploy 

You will also find that those regular updates make it easier for products at different stages of their lifecycle to share code, tools, and workflow. This maintenance loop does strongly benefit from being common across different products, to reuse patches and to even the ebbs and flows of this activity. 

Ultimately, this is accelerated by having a cross-product platform approach, which fully builds on reusing both resources and process, and saves cost and effort at scale.