The vendor owns producing a fixed release and telling customers. The hospital owns installing it. Make that split explicit in writing, give customers a clear upgrade path and interim mitigations, and track which versions are still running. Without that, a patched library can stay vulnerable inside a hospital for years.
Why on-premises is different
In a hosted product, you update once and every customer is fixed. In on-premises software, the bundled library ships inside the installer or container, and the hospital controls when it changes. Your fix exists on your side, but exposure lives on theirs.
This makes the "do you use vulnerable components" question harder to answer honestly. The accurate answer is often "not in the latest release, but some customers run older ones."
Responsibility split
| Task | Vendor | Hospital |
|---|---|---|
| Know which components ship in each release | Yes | Can request the list |
| Assess advisories against released versions | Yes | Reviews the vendor assessment |
| Build and test a fixed release | Yes | May test in staging |
| Publish upgrade steps and interim mitigations | Yes | Reads and plans |
| Install the update | Supports | Yes |
| Retire unsupported old versions | Sets a policy | Follows or negotiates |
Put these in the support or service agreement so nobody learns the split during an incident. Ask counsel for wording on liability.
Steps for a vendor
- Keep a per release component inventory, so you can answer "does version 4.1 contain it" in minutes.
- Publish a support policy stating how many versions receive security fixes.
- For each advisory, state which versions are affected and which release fixes it. Backport only where your policy says so.
- Provide interim mitigations that need no upgrade, such as configuration changes or network controls, when they exist and are tested.
- Track adoption. If your update mechanism reports version, review the share of customers on supported releases each quarter.
- Contact customers on unsupported versions directly when an exploited flaw affects them.
Reducing the time to fix
Smaller, more frequent releases are easier for hospitals to accept than rare large ones. Offer a security only patch line if you can maintain it. Document rollback steps, since change control teams worry about outages as much as attacks.
What reviewers want to hear
"We maintain a component inventory for each release, publish advisories with affected and fixed versions, support the current and previous release with security fixes, and contact customers on older versions when an exploited issue affects them."
Say only what your support policy actually promises.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fixed version is identified for a given component, which is what you publish for customers.
Safeguard's autonomous remediation can open fix pull requests for your own code, off by default with every category on Manual, and its SBOM and scanning help you keep the per release inventory. Customer installs remain a process matter.
Quick check
Do we have to backport fixes to old releases?
Only as far as your support policy and contracts say. State the policy clearly and apply it evenly.
Can we patch inside a hospital without their approval?
Usually not. Change control belongs to the hospital. Agree the update method in advance.
Last reviewed: 19 October 2026.
