Updating legacy medical applications for modern security requirements
You can prepare yourself for future updates by bringing your post-market applications into a modern security paradigm.
Tim Miller
October 8, 2025
Medical device regulators recognize the threat of cyberattack against devices and institutions. As a result, new devices will face more stringent requirements as part of the pre-market submission process. This is great news for future medical devices, but what about the devices already on the market? We recently wrote about steps manufacturers and health delivery organizations (HDOs) can take to secure legacy hardware. There’s another piece of the puzzle, though: addressing legacy medical applications.
The software that runs on devices is hard to update for a variety of reasons. However, only a fraction of the software involved in health care is on-device. There’s a wealth of software for managing patient records and appointments, processing and interpreting data, and more. These applications are an important part of delivering the best care to patients, so keeping them secure is key.
Overcome the inertia incentive
When I talk to leaders in the medical sector, they talk about the incentives to not update software. Getting regulatory approval can be expensive and time-consuming, and it’s not something manufacturers are eager to do. In the United States, the FDA’s General Principles of Software Validation says “when any change (even a small change) is made to the software, the validation status of the software needs to be re-established.” This means that manufacturers have a strong incentive to not make updates except in the most dire of circumstances.
Leaving well enough alone only works when “well enough” is actually well enough. Cybersecurity threats are only increasing in frequency and complexity and attackers don’t spare the medical sector. Medical applications must evolve to continue protecting patients and practitioners.
There are reasons for making postmarket application updates that go beyond cybersecurity and patient safety. New advances in science and technology can produce new features or improved performance. For example, artificial intelligence models may be able to detect breast cancer that experienced human radiologists missed. Since early detection improves the efficacy of treatment, adding AI to radiology software presents a patient outcome improvement — and a competitive advantage. Manufacturers don’t want to forego innovation just because their application is already on the market, so they need to be ready to make updates.
Get ready in advance
Updates are inevitable, so you might as well be ready to deliver them. The best way to do that is to get your processes improved in advance. As Suga Free said, “if you stay ready, you don’t have to get ready.” You’ll deliver better software faster if you’re in a position to focus on updating the software instead of updating the practices.
Even if you don’t have plans to release an update, start by acting like you do. Here are a few concrete steps to take:
- Establish secure development environments. Building software on a developer’s workstation is not a solution. Centralize code, build, and deployment pipelines with robust access controls and audit logging.
- Generate SBOMs for each build. Software bills of materials (SBOMs) are not optional in regulated industries. Automatically generating an SBOM at build time ensures that you will always have an SBOM for software that you ship. The SBOM is also a building block for building a more robust understanding of your software supply chain.
- Track vulnerabilities in your dependencies. With a robust SBOM, you can automatically monitor public and private feeds of vulnerability data. This means when a new vulnerability is announced, you will know exactly where you include the vulnerable software.
- Fix vulnerabilities and update dependencies. Smaller updates are easy to adopt than large updates. If you keep your application’s dependencies up-to-date, the work necessary to produce an application update goes down dramatically. You don’t need to go through the approval process for each update if you’re not shipping it, so keeping dependencies up-to-date gets you to the approval process faster when it’s time to enter the approval pipeline.
- Ingest and produce VEX documents. Vulnerability Exploitability eXchange (VEX) documents indicate how vulnerabilities affect — or don’t affect — your software. If a dependency has a vulnerability but your application does not travel the vulnerable code path, you can clearly indicate that to your customers.
- Use internal mirrors of open source ecosystems. Pulling unvetted libraries directly from public repositories presents a major supply chain risk. As developers need new libraries, they should be vetted and mirrored to an internal repository. Instead of pulling from the public repository, developers (and build systems) pull from the known-safe internal repository.
The best part is that you already need to do this for new products. Retrofitting your in-market applications standardizes the process across your entire portfolio. Not only do you get ready to quickly issue updates when needed, you also get a better experience for your developers.
How Kusari can help
Kusari can help you secure every step of your software supply chain. Our products are built on years of software and security expertise in regulated industries. Using Kusari products helps you meet ISO 14791 requirements — particularly those focused on risk analysis, evaluation, and control. With Kusari Inspector and Kusari Platform, you uncover hidden and transitive dependencies inside legacy software, identify vulnerabilities in older, static codebases that would otherwise be missed, tie your findings to regulatory requirements so you can proactively address compliance and prioritize fixes so you focus on what will make an impact rather than wasting effort on low-risk patches. If you’re ready to take the next step, schedule a custom demo.
Like what you read? Share it with others.
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.jpg)
Previous
No older posts
Next
No newer posts
Want to learn more about Kusari?