Topic starter
19/08/2026 3:31 pm
TL;DR: Legacy medical applications are difficult to update because validation, approval, and supply-chain controls slow change, according to Kusari. The security problem is not only patch backlog but the absence of repeatable build, dependency, and release governance that lets regulated software evolve safely.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “Updating Legacy Medical Applications for Modern Security Requirements”.
Key questions
Q: What breaks when legacy medical applications are not built for repeatable updates?
A: Teams end up treating every security fix like a special project, which slows validation, increases release friction, and leaves vulnerable dependencies in place longer than necessary.
Q: Why do validation and approval cycles increase security risk in regulated software?
A: They create a strong incentive to delay even small changes, so known vulnerabilities remain exposed while teams wait for the next justified release window.
Q: What do security teams get wrong about supplier SBOMs?
A: They often assume receipt equals assurance.
Practitioner guidance
- Establish controlled build and deployment environments Move legacy medical application builds off individual workstations and into centralised pipelines with strong access controls and audit logging.
- Generate an SBOM for every build Automatically produce a software bill of materials at build time so each shipped release has a traceable dependency inventory.
- Continuously monitor dependency vulnerability feeds Connect SBOM data to public and private vulnerability sources so teams can locate affected packages the moment a new issue is disclosed.
Bottom line: Legacy medical applications often remain vulnerable because the update process is too expensive to use regularly, not because teams lack awareness of the risk.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:14 pm
Secure update discipline is now part of medical software resilience. In regulated care settings, the old assumption that stability comes from leaving software alone no longer holds. Attackers do not pause for approval cycles, and a pipeline that cannot absorb small fixes reliably becomes a security liability. Practitioners should treat updateability as a control objective, not an afterthought.
A question worth separating out:
Q: How should organisations govern dependency updates in medical software portfolios?
A: They should normalise smaller, routine dependency updates instead of waiting for large, risky change events. That approach reduces release pressure, shortens approval work when a real fix is needed, and makes it easier to keep older applications aligned with current security expectations.
👉 Read our full editorial: Legacy medical applications need secure update pipelines, not patch delay