Publish an end-of-support date well before it arrives, notify users through every channel they use, say what stops (security fixes included) and point to the upgrade path. One SSDF PO.1.2 example says policies should cover the whole life cycle, including notice of impending end of support and the end-of-life date.
What the SSDF mentions
PO.1.2 asks you to document security requirements for the software you build. One of its examples says to ensure that policies cover the entire software life cycle, including notifying users of the impending end of software support and the date of end-of-life. Another example ties archive retention to the SDLC model and software end of life.
It does not set a notice period, so choose one that fits your customers and put it in your policy.
Why it is a security matter
Software that no longer gets fixes still runs in the world. When a new vulnerability appears, users of the unsupported version have no patch. Buyers know this, and many ask what your support policy is.
What the notice should say
| Item | Detail |
|---|---|
| Version affected | Exact versions and builds |
| Date security fixes stop | A calendar date |
| What changes on that date | No patches, no advisories, support limits |
| Upgrade path | Steps, supported target version |
| Where to get help | Contact or documentation page |
Steps
- Put a support policy in writing, with a standard notice period.
- Maintain a public page listing each version and its support dates.
- Send notices through email, in-product messages and release notes.
- Remind users at set points before the date.
- After the date, mark the version as unsupported and keep the page up.
- Record who received notices, where records allow.
Inside your own house
Apply the same thinking to components you depend on. PW.4.4 examples say to check that each component is still maintained and to plan for those that are not. Your own end-of-support date is the mirror image of a supplier's. See our post on checking components are still maintained.
Evidence
- The support policy
- The public version and dates page
- Copies of notices with send dates
- Release archives retained per your policy
- Advisory history for the version
Plan the last release
Before the date arrives, decide whether a final security release is warranted, and tell users if so. Archive the final build, its SBOM and its signatures under your retention policy, as the PO.1.2 and PS.3 examples suggest. Update the public page and docs so the unsupported status is clear to anyone who lands on them from a search. Clear endings are part of responsible maintenance.
Quick check
How much notice is enough?
SSDF does not say. Pick a period that gives customers time to plan, state it in your policy and follow it.
Do we still publish advisories for unsupported versions?
That is your policy choice. If you do not, say so in the support policy so customers know the risk.
Safeguard's SBOM and dependency scanning can show which versions of components you ship. The free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
