Topic starter
19/08/2026 3:31 pm
TL;DR: Legacy medical applications stay vulnerable when updates are too costly to use routinely, according to Kusari. Repeatable build, dependency, and release governance can make fixes easier to approve and less disruptive to ship.
Editorial analysis by NHI Mgmt Group, based on content published by Kusari: “Updating Legacy Medical Applications for Modern Security Requirements”.
Key questions
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.
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.
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.
Glossary terms: Software Bill of Materials, Vulnerability Exploitability Echange, Secure Build Process, Dependency Provenance
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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