It depends on the vendor, and the answer is rarely in the sales deck. Many vendors patch only the latest release or the latest two. Ask for the supported version policy in writing, find out which version you will actually run, and put a minimum support window into the contract.
Why this question matters more than the patch SLA
A fast patch SLA is worth little if the fix ships only for a version you are not running. Commercial software upgrades can be slow in real organizations. A major upgrade may need testing, retraining or changes to integrations. If the vendor patches only the newest release, you inherit an upgrade project every time a flaw appears.
NIST SP 800-40 Rev. 4 frames patching as preventive maintenance. That works only when the patches are available for the version you have deployed. So the supported version policy is part of the security terms, not a footnote in the product lifecycle page.
Questions to put to the vendor
- Which release lines receive security fixes today? Ask for names and version numbers, not "recent versions."
- When a new major version ships, how long does the previous one keep getting security fixes?
- Are security fixes backported, or must you upgrade to a newer minor release to get them?
- Does the answer differ by deployment model, hosted or on-premises?
- Where is the policy published, and how much notice does the vendor give before changing it?
- If a flaw is exploited in the wild, does the vendor patch every supported line or only the latest?
CISA's Secure by Demand guide asks how easily customers can install security patches and whether the manufacturer supports them broadly and enables automatic updates. Use that as a prompt: a vendor that makes patching easy usually has a clear answer for older lines too.
Common policy shapes
| Shape | What it means for you | What to check |
|---|---|---|
| Latest only | Every fix needs an upgrade | Upgrade effort and release cadence |
| Latest plus one previous | A grace period of one release | How long the previous release stays supported |
| Long term support line | A slower line with fixes only | Length of the support window and who qualifies |
| Fixed calendar window | Support ends on a date | Whether the date is in the contract |
None of these is wrong. Each fits some buyers. The mistake is choosing without knowing.
What to write into the contract
- A named minimum period during which the version you buy will receive security fixes.
- A commitment to give written notice, for a stated period, before ending support for a version.
- A statement that security fixes are not held back for a paid upgrade tier. If the vendor will not agree, you want to know that before signing.
- A right to a documented mitigation when you cannot upgrade in time.
What to do on your side
Record the version you deploy and the date support for that line ends, in the same place you track licenses. Set a reminder well before that date. When the date approaches, plan the upgrade as a normal change, not an emergency.
If you have already bought and find the policy is poor, ask for a support statement in writing now. Then plan around the date the vendor gives.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how findings are grouped and tracked over time, which is the habit that keeps version dates from slipping.
Safeguard supports this on the buyer side with SBOM and dependency scanning plus asset discovery, so you can see which products and versions you actually run.
Quick check
Should I ask for backported fixes?
Yes. If the vendor will not backport, every fix forces an upgrade, so plan for that cost.
Where do I find the vendor's supported versions?
Ask for the written lifecycle or support policy, and have the supported version numbers named in the contract.
Sources
Last reviewed: 19 October 2026.
