It can justify a time-boxed exception, but only when the upgrade is planned and funded, exposure is limited in the meantime, and the term is short. "It is expensive" alone is not a reason. "It is scheduled for the next quarter and here is how we reduce risk until then" is.
Major version upgrades break things. APIs change, plugins stop working, tests fail. Teams reasonably ask to defer, and security teams reasonably worry that deferral becomes permanent.
Look for cheaper options first
Before accepting, check whether you can get the fix without the full jump.
- A patch release on your current major line.
- A backport from a vendor or distribution that maintains older versions.
- A configuration change or feature flag that disables the vulnerable path.
- A compatible replacement library.
If one of these works, take it and note the remaining upgrade as ordinary maintenance rather than risk.
Make the case in numbers you can verify
A convincing request answers four questions.
| Question | Good answer |
|---|---|
| How big is the upgrade? | Estimate in engineer weeks, with the blocker named |
| When will it happen? | A scheduled release, not "later" |
| How exposed is the vulnerable code? | Reachability or call path analysis |
| What limits risk until then? | Specific controls, with owners |
Reachability matters here. If a scanner reports a flaw in a function your code never calls, the cost of the upgrade weighs differently than if the flaw sits on a request path. FIRST publishes EPSS scores, which estimate exploitation likelihood over 30 days, and they can help frame urgency, though they are not a substitute for knowing your own exposure.
Set the term to the plan
Tie the expiry to the upgrade milestone plus a small buffer. If the milestone slips, the renewal is a new decision with a new review. Cap the number of renewals. Many teams allow one, then require escalation to a more senior approver.
Escalation after the second renewal
By the second renewal the real question is no longer technical. Someone has to decide whether to fund the upgrade, retire the system, or accept ongoing exposure at executive level. Put that decision in front of the right person, in writing, and record the outcome.
Watch for end of support
If the version is also out of vendor support, it will stop receiving fixes at all, and the exception turns into a standing risk. Treat that as a trigger to move the upgrade from backlog to roadmap.
Where Safeguard fits
Safeguard's reachability analysis helps show whether the vulnerable code is used, and its autonomous remediation with fix PRs, which is off by default, can propose upgrade changes you review before merging.
Try it yourself
Click through it at your own pace, or open it full screen. Compare findings before and after reachability filtering to see which ones actually sit on a call path.
Quick check
How many times can a version exception be renewed?
Set a cap in policy, often one renewal, then require senior escalation. Open-ended renewals defeat the purpose of an expiry.
Does a vendor backport count as a fix?
Often yes, if the vendor states the CVE is addressed in the version you run. Confirm with the vendor advisory, not the version number alone.
Sources
Last reviewed: 19 October 2026.
