Paid extended security updates are better described as an alternative source of support than a compensating control. They keep some security fixes coming for a limited period, but they have a fixed end and exclusions. Use them to buy time inside a retirement plan, not as a permanent answer.
What the program provides, using one vendor as an example
Microsoft's documentation for the Windows 10 Extended Security Updates program is a clear public example. It describes ESU as a paid program that lets organizations and individuals receive security updates for enrolled PCs after the end of support date of October 14, 2025. Several details matter for risk decisions:
- Devices must be running Windows 10 version 22H2 to be eligible.
- ESU does not include new features, customer requested non-security updates or design change requests.
- General technical support is not provided for versions past end of support. The program covers licence activation, installation and possible regressions of the ESU itself.
- Updates are purchased by year, are cumulative, and organizations can receive them for a maximum of three years after end of support.
- Microsoft says the PCs keep working without ESU, but it will no longer provide technical support, feature updates or quality updates including security and reliability fixes.
Other vendors and open source support providers structure things differently. Read the terms for each.
Where it fits in NIST's thinking
NIST's unsupported components control lists replacement first and, if that is not possible, alternative sources of continued support. Its guidance says organizations can establish in-house support through customized patches for critical components, or obtain external providers who give ongoing support through contracts, and notes such providers can include open source value-added vendors. Paid extended updates are one of those alternative sources.
Why it is not the same as a compensating control
| Question | Extended updates | Isolation and monitoring |
|---|---|---|
| Does it remove vulnerabilities? | Some, those the vendor chooses to fix | No |
| Does it cover all flaws? | Not necessarily, only the issues the vendor covers | Reduces exposure to all of them |
| Does it have an end date? | Yes | Lasts as long as you maintain it |
| Does it need your effort? | Deployment and testing | Design, operation and review |
They work well together: extended updates for what gets fixed, isolation for what does not.
How to record it in an exception
- Name the product, the version and the program, with the coverage end date.
- State what is excluded, such as application layer components the vendor does not cover.
- Keep proof of enrolment and that updates are being applied.
- Add isolation and monitoring for the gaps.
- Set the retirement milestone well before the coverage end date, with a buffer for slips.
Questions to ask before relying on it
- Does the program cover every component we run, or just the operating system?
- What happens if a fix needs a feature the old system lacks?
- Can we apply the updates without breaking the legacy application? Test first.
- What do we do in the final year, when the end is in sight?
Quick check
Are extended updates the same as normal support?
No. In the Microsoft example, general technical support is not included, and the program has exclusions and a maximum duration.
Do I still need isolation if I buy extended updates?
Usually yes. Updates cover only the flaws the vendor fixes, so layered controls cover the rest.
Sources
- Microsoft Learn: Extended Security Updates (ESU) program for Windows 10
- NIST SP 800-53 Rev 5 control catalog (OSCAL JSON, NIST oscal-content repository) (SA-22 Unsupported System Components)
Last reviewed: 19 October 2026.
