The Electron team supports the latest three stable major versions, and only the latest minor release in each series. Any desktop app pinned to an older major is outside that window. Record the Electron version in your inventory as a runtime, not as an ordinary library.
What the policy says
Electron's release timelines page states the version support policy directly. The latest three stable major versions are supported. Its example: if the latest release is 42.1.x, then the 41.0.x and 40.2.x series are supported as well. It adds that only the latest minor release of each stable series is supported, so a security fix lands in 42.1.x but there is no separate fix for an older minor in the same series.
The page also describes how Node.js is handled: stable Electron lines receive minor and patch bumps of Node.js after those are released, with patch bumps shipping in Electron patch releases and minor bumps resulting in a minor Electron release. Security-only branches receive security-related changes from Node.js but not the rest.
It also records a past exception: the team temporarily extended support for Electron 22 until 10 October 2023 because of an extended end of life for older Windows versions. That is a reminder that exceptions are announced, not assumed.
Why Electron is a runtime, not a library
An Electron app ships its own copy of the runtime. Users do not get a newer one from the operating system. So the app's exposure follows the version you bundled, and a fix reaches users only when you build and release a new version of your app. That has three effects on an inventory:
- The Electron version needs its own row, with a support status.
- The Node.js version bundled with it is a related fact, since Node-level fixes arrive through Electron releases.
- Your update channel matters. An app that auto-updates can catch up quickly. One distributed as an installer that users rarely refresh will lag.
For code-level risks specific to Electron, see Electron app security best practices and Electron app supply chain security.
A quick audit
- Find the Electron version in the app's package.json and lock file.
- Compare it with the three supported majors on the timelines page.
- If it is outside the window, note how many majors behind you are.
- Check the install base: how many users run which app version.
- Decide the upgrade size. Each skipped major can bring breaking changes.
Upgrading one major at a time keeps breakage attributable. Run your end-to-end tests on every target platform, since native modules compiled for one Electron version often need rebuilding for the next.
Fields for the register
| Field | Example |
|---|---|
| Runtime | Electron, exact version |
| Bundled Node.js | Version reported by the build |
| Status | In window or outside the three-major window |
| Check date | 19 October 2026 |
| Update channel | Auto-update or manual installer |
| Owner | App team |
Try it yourself
Click through it at your own pace, or open it full screen. Look for how the app and its components are separated, then add the runtime as its own row.
Where Safeguard fits
Safeguard's SBOM and dependency scanning reads your lock file, so Electron and its native modules appear as inventory items you can attach support fields to. Try the free scan at gold.safeguard.sh/scan.
Quick check
How many Electron majors get fixes at once?
Three, per the project's stated policy: the latest three stable majors.
Does a fix for 42.1.x also reach 42.0.x?
No. Only the latest minor of each supported series is fixed.
Sources
Last reviewed: 19 October 2026.
