Angular end of support: upgrade, pay or accept the risk
· Menno-Paul Schreuder
Every Angular version stops receiving security fixes on a fixed date. When yours does, you have three options. What each one costs, when it makes sense, and how to keep the next one from becoming a project.
- Angular
- Security
Current status
| Version | Status | Long-term support ends |
|---|---|---|
| Angular 22 | Active | June 2028 |
| Angular 21 | Long-term support | June 2027 |
| Angular 20 | Long-term support | 28 November 2026 |
| Angular 19 and older | No longer supported | — |
Source: Angular versioning and releases (opens in a new tab). This table is updated whenever a version leaves support; the date at the top of this post shows when it was last checked.
How Angular support works
Every major version of Angular gets 24 months of support. The first 12 months are active support, with regular updates and fixes. The next 12 months are long-term support, with critical fixes and security patches only. After that, the Angular team stops fixing it, security issues included. Since Angular 22 there is one major release per year.
Nothing breaks on the day support ends. The application keeps running, which is exactly why the date is easy to miss. The problem shows up later: a vulnerability is published that will not be patched for your version, or a library you depend on drops support for it and you can't take its fixes either.
When your version reaches that date, you have three options.
Option 1: Upgrade
For an application with a future, this is almost always the right answer. An upgrade moves one major version at a time, using ng update and the official Angular update guide (opens in a new tab). Angular itself is rarely the hard part. The work is in everything around it: third-party libraries that need a compatible version or a replacement, deprecated APIs, custom build setups and, most of all, how much of the application is covered by tests you trust.
Which version to go to? The newest, one major version at a time. Stopping a version short only buys you months before the next deadline. Move to a new major once a few patch releases are out and your critical libraries officially support it. In practice that's a few weeks after a release; the first minor release (x.1) is a handy marker, not a guarantee.
Then make it routine. The real lesson of every end-of-support date is that two versions behind is expensive and one version behind is cheap. Upgrade once a year, after each major release, and it stays a small, plannable task instead of a project. AI-assisted tooling has also made a one-off upgrade cheaper than it used to be, which shifts the balance further towards upgrading.
Harden while you're at it. An upgrade rebuilds your dependency tree anyway, which makes it the natural moment to tighten how those dependencies are installed. See npm supply-chain attacks: which defences actually stop them.
Option 2: Pay for extended support
Commercial vendors sell security patches for Angular versions the Angular team no longer supports (HeroDevs (opens in a new tab) is one example). The application stays as it is; the vendor patches the framework.
That makes sense in a few situations:
- The application will be replaced or retired within a year.
- You need a bridge while an upgrade is planned and scheduled.
- Every change to the application is expensive to validate, for example in regulated environments.
The trade-offs: the cost comes back every year, the gap to current Angular keeps growing (so the eventual upgrade only gets bigger), and you depend on the vendor for fixes. Check what is covered: the framework itself, or also the libraries around it.
Option 3: Accept the risk, deliberately
This is the option most organisations take without saying so. It can be defensible, for example for an internal tool behind a VPN or single sign-on, without sensitive data, with a replacement already planned.
What turns it from neglect into a decision:
- Record it in your risk register, with an owner and a review date.
- Add compensating measures: a strict Content Security Policy, dependency monitoring that alerts on new vulnerabilities, and as little exposure as possible.
- Set an end date for the application or for the decision itself.
If your organisation falls under the Cyberbeveiligingswet, in force since 15 August 2026 (opens in a new tab), its duty of care requires a documented risk analysis that covers decisions like this one, including risks in your supply chain.
If those conditions don't apply to your application, you are back at options 1 and 2.
Side by side
| Upgrade | Extended support | Accept the risk | |
|---|---|---|---|
| Cost | One-off, smaller each time if routine | Every year, for as long as you stay | Low now, open-ended later |
| Good when | The application has a future | It's being retired, or as a short bridge | Low exposure and a planned end |
| Watch out for | Libraries and test coverage | The upgrade you postpone keeps growing | Undocumented, it's not a decision |
Where to start
Whichever option you choose, start with an inventory: which applications run which Angular version, which libraries they depend on, and how well they are tested. That tells you how big an upgrade really is, and whether options 2 or 3 are worth considering at all. It's also exactly what an upgrade scan delivers.