Answer with the truth and a plan. Most real products carry at least one component past its support date. A good answer says you know which ones, have assessed the risk, have compensating controls where needed, and have a dated plan to replace them. A flat "no" tends to be disbelieved.
Why the question is asked
An end-of-life component stops receiving security fixes. A hospital reviewer is asking whether new flaws in your stack could stay open forever. The Security Rule asks you to implement measures sufficient to reduce identified risks to a reasonable and appropriate level (45 CFR 164.308(a)(1)(ii)(B)), and an unsupported component with no plan is hard to defend under that wording.
Choose your honest answer
| Your situation | How to answer |
|---|---|
| None found after a real check | "No unsupported components in the shipped release as of this date, based on our latest inventory." |
| A few, with plans | "Yes, two components. Here is the risk assessment, the compensating control, and the replacement date." |
| Many, no plan yet | "Yes. We have built the inventory, ranked by exposure, and will share a plan by a stated date." |
| Cannot tell | "We are building this view now. Expect an answer by a stated date." |
Do not choose the first row unless the inventory supports it. Support dates are public for many runtimes and frameworks, but you have to check each one against the version you actually ship.
Steps to prepare
- Take the current SBOM and list each component's version.
- Check each against its project's published support policy. Do this for runtimes, frameworks, base images and major libraries.
- For each unsupported item, record where it sits, whether it handles patient data, and whether its known flaws are reachable.
- Choose a treatment: upgrade, replace, isolate, or accept with sign off.
- Set a target date and an owner.
Compensating controls might include network isolation, input filtering in front of the component, reduced privileges, or enhanced monitoring. Describe them factually and test them. Do not describe a control that exists only in a plan.
What a risk acceptance should contain
Name the component and version, the reason it cannot be replaced yet, the risks, the controls, the approver and a review date. An acceptance with no expiry becomes permanent by default. Set the date.
Wording example
"We identified two components past their support date in the current release. Both sit behind internal services that do not handle ePHI directly. They are isolated by network policy and monitored. Replacement is scheduled for the second quarter release, and the acceptance is reviewed quarterly."
Only write that if every clause is true.
Try it yourself
Click through it at your own pace, or open it full screen. Check how base image and package layers are surfaced, since old base images are a common source of unsupported components.
Safeguard's dependency and container scanning can list versions, and its policies can flag components past a rule you set. Support dates themselves come from each project, so confirm them there.
Quick check
Is one unsupported component a deal breaker?
Rarely. Reviewers weigh exposure and your plan. An unexplained one is the problem, not the existence of one.
Where do we find support dates?
On each project's own release or support policy page. Record the source and the date you checked.
Sources
Last reviewed: 19 October 2026.
