You can reasonably defer an upgrade for an unreachable finding if the severity is not critical, nothing suggests active exploitation, and you can schedule a review. You should patch anyway when the fix is cheap, when the flaw is on a known exploited list, or when the analysis is weak for that code.
The case for deferring
Upgrades have a cost. They can break behavior, need testing and consume attention that could go to reachable issues. If the vulnerable function is never called, the near term risk from that specific flaw is low, and effort is better spent elsewhere.
The case for patching anyway
- The upgrade is trivial. A patch release with no API change and passing tests takes little time.
- The code could become reachable. A small change can add the call. Patching removes the risk.
- The analysis is weak here. Heavy use of reflection, plugins or generated code lowers confidence in the label.
- It is on a known exploited list. CISA describes its KEV catalog as an input to prioritization. A match deserves a second look even when your tool says not reachable.
- A customer or auditor asks. Some contracts set patch windows that ignore reachability. Read yours.
A decision table
| Situation | Suggested action |
|---|---|
| Not reachable, low or medium, trivial upgrade | Include in the next routine update |
| Not reachable, low or medium, risky upgrade | Defer with a reason and review date |
| Not reachable, critical severity | Read the path, check dynamic features, then upgrade soon |
| Not reachable, listed as exploited | Verify product presence and exposure, then upgrade |
| Reachable and exposed | Upgrade or mitigate now |
| Cannot tell | Treat as reachable |
This is a starting point for your own policy, not a standard.
What to write when you wait
- The finding and the package.
- The evidence: the analysis, date and commit.
- Why waiting is acceptable.
- The owner.
- A review date, ideally tied to the next release.
That record is the same shape as the one in how to set up a security exception process.
The hidden cost of waiting
Deferred items accumulate. Without an expiry they become permanent, and the list is rarely revisited. Put an end date on every deferral and review it as scheduled. See when to re-run reachability analysis.
Quick check
Does a customer SLA care about reachability?
Only if the contract says so. Many contracts define patch windows by severity alone, so read the wording before you rely on a not reachable label.
Is deferring a security risk?
Any deferral carries some risk. Writing down the reason, owner and date makes it a managed risk instead of a forgotten one.
Safeguard users can see reachability and fix availability on the same finding, including autonomous remediation fix PRs, which are off by default and require you to enable them. Try the free scan.
Sources
Last reviewed: 19 October 2026.
