A deprecated feature remains a security risk until its code and dependencies are actually removed from every supported release. Deprecation is a notice to users. It does not change what the code does, who can call it, or which vulnerable libraries it still pulls in.
Deprecated is not deleted
Semantic Versioning, the convention many libraries follow, defines deprecation as a communication step. Its text says deprecating public API functionality requires a new minor release that marks it as deprecated, and that the feature should stay in at least one minor release before removal in a new major release. So by design there is a window where deprecated code still ships.
For a product team, that window is the risk period. During it:
- the code still runs in production
- its dependencies still need patches
- customers still depend on it, so you cannot simply switch it off
The three clocks
Plan the end of a feature against three separate dates, and write all three down.
| Clock | Question | Example owner |
|---|---|---|
| Announce | When do customers learn it is going away? | Product manager |
| Freeze | When do we stop adding features but keep fixing security bugs? | Engineering lead |
| Remove | When is the code deleted from every supported version? | Engineering lead |
The security commitment is the middle clock. Say plainly whether security fixes continue during the freeze period. If they do not, say so in the announcement, because customers need to decide whether to keep running it.
What to do with dependencies during the freeze
A deprecated module often holds the oldest dependencies in the product, because nobody upgraded them after the feature stopped getting attention. Two practical options:
- Keep patching them until removal. This is safest, and cheap if the module is small.
- Isolate the module, with reduced permissions and no new network exposure, and give it a firm removal date.
Avoid a third option, which is quietly ignoring alerts on deprecated code. Scanners will keep reporting it, and the noise hides new findings elsewhere. If you accept the risk, record it with an owner and an end date rather than muting the alerts.
Announce removal in a way customers can act on
A useful removal notice includes the replacement, a migration path, the last version that contains the feature, and the date after which security fixes stop. The Secure by Design material from CISA argues that technology providers should own customer security outcomes at the executive level, which is a reasonable lens here: a quiet removal pushes the risk onto customers.
Verify the removal
After the removal release ships, check that it actually removed the risk. Regenerate the dependency inventory and confirm that the libraries used only by the old feature are gone, not just unused. A dependency that stays in the lockfile stays in the scan results and in any SBOM you hand a customer.
Quick check
Does deprecating a feature stop it receiving security fixes?
Not automatically. That is a policy choice you must state in the announcement, with a date.
Can we just ignore scanner alerts on deprecated code?
Not safely. Fix it, isolate it, or record a time limited risk acceptance with an owner.
How do we prove the old code is gone?
Compare dependency inventories before and after the removal release.
Safeguard's SBOM and dependency scanning can produce that before and after inventory, and the free scan at gold.safeguard.sh/scan is a quick way to start.
Sources
Last reviewed: 19 October 2026.
