Grant an end-of-life exception only with a dated retirement plan, compensating controls that you can test, network isolation and a short term. Accepting unpatched software is not a decision about one CVE, it is a decision about every future one, so the exception must carry a hard end.
Why EOL is different
A normal exception waits for a fix. An end-of-life exception has no fix coming. Every new advisory will stay open, so the risk grows with time. That is why these should be the shortest, most conditional approvals in your register.
Steps
- Confirm it is truly EOL. Check the vendor or project's published support policy, not a rumour. Ask whether paid or extended support exists.
- Find the real dependency. Which services run it, and which data and networks does it touch?
- Set a retirement milestone. Replacement, upgrade, or decommission, with an owner and a date.
- Add compensating controls. Isolate the host, restrict inbound and outbound traffic, remove it from the internet, tighten authentication, increase monitoring.
- Prove the controls work. See how to prove a compensating control works for an exception.
- Approve at a senior level. EOL exceptions carry more exposure than most.
- Set a short term with a checkpoint. Review progress on the retirement plan, not just the controls.
What to put in the record
| Field | Content |
|---|---|
| Component and version | Exact, with where it runs |
| Support status | Source and date checked |
| Exposure | Network position, data touched |
| Controls | List with test evidence |
| Retirement | Plan, owner, target date |
| Review dates | Checkpoints before expiry |
Red lines
Do not grant an EOL exception for anything directly reachable from the internet without strong isolation in front of it. Do not renew it without visible progress on the retirement plan. Do not accept it on the basis that "it has not been attacked so far".
Related background is in managing EOL software dependencies and the PHP 7.4.33 vulnerabilities and EOL risk write up.
Alternatives to consider first
- Upgrade to a supported release, even if it is painful
- Replace the dependency with a maintained alternative
- Wrap it behind a gateway that limits what can reach it
- Extended support from a commercial source, if available
Each of these changes the exposure more than paperwork does.
Metrics to watch
Count EOL exceptions by age and by whether the retirement date has moved. A date that moves twice is a warning sign that the plan has no owner.
Safeguard's SBOM and dependency scanning help you find where end-of-life components actually run, and its asset discovery helps surface systems nobody remembered to list.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how new findings surface over time, which is exactly what keeps happening to unpatched software.
Quick check
Can an EOL exception be open ended?
No. Without an end date it becomes a permanent acceptance of unpatched code.
Is isolation enough on its own?
Only if you can show it works. Test the controls and keep the evidence.
Last reviewed: 19 October 2026.
