Your Product Has Five Support Clocks. Most Plans Track One.

The companion article to this one asks a single question: which recipe builds the kernel in your image, and who has committed to maintaining it. Answer that first, because it decides which row of the support lifecycle table below applies to you. This article takes the answer and turns it into a plan.

The premise is that a support lifecycle built on one date is built on the wrong number. Teams write down the Yocto release and its end date because those are the easy ones to find. The date that actually decides whether a customer gets a security fix in 2029 is usually somewhere else, held by somebody who has never been in the planning meeting. We have written before about spotting an SoC whose kernel support has already lapsed and about what the shorter kernel LTS window means for planning; this piece assembles those into one register.

The five clocks in an embedded Linux support lifecycle

Before the detail, the shape of it. A product’s support lifecycle is the overlap of five independent commitments. Here they are as definitions; the dates, owners and review triggers come later, in the register.

• The upstream kernel branch. Ends on kernel.org’s projected date for your longterm series.
• The layer that supplies your kernel recipe. OE-Core under the Yocto LTS, or a vendor layer on its own published terms.
• The build system. Bitbake, OE-Core and meta-yocto, on the Yocto release’s own date. This is also the clock your toolchain and C library run on, since those recipes live in OE-Core.
• The silicon. A longevity commitment measured from launch, with conditions attached.
• Your own maintenance obligation. The date you must still be able to ship a validated update.

The rest of this article works through the ones teams get wrong most often, then puts all five in a register.

The upstream clock in your support lifecycle

The upstream kernel is the clock teams read first, and it is the one most often mistaken for the whole support lifecycle. Here is the table as kernel.org publishes it, with the arithmetic that matters for planning added on the right. Both computed columns treat the projected end-of-life month as the last supported month, which is the convention kernel.org’s own wording implies. Remaining is counted from 1 September 2026.

Read the third column and the fourth column together. Under the projections published today, each adjacent pair of longterm kernels happens to share an end date, and the older member of each pair therefore receives roughly a year more total maintenance than the younger one. Linux 6.12 gets about four years and one month; 6.18, released a year later, gets about three years and one month. Both stop in the same month.

The consequence for a product team is narrow but useful: under the projections published today, remaining upstream-maintenance time does not distinguish 6.12 from 6.18. If you are starting a design now and weighing the two, the support-window argument gives you nothing, because both are projected to end in December 2028. Everything else still distinguishes them, and those are the criteria worth the time: driver coverage for your silicon, which branch your vendor is actually feeding, whether the features you need are present without backports, and what the migration would cost. Just not the end date.

One caution before this becomes a planning rule of its own. kernel.org publishes no policy of retiring longterm kernels in pairs, and this article is not reporting one. What it is reporting is the state of the published table: projected end-of-life dates get extended when there is enough industry interest, and those extensions have so far landed on shared calendar years. That is an observation about six branches, not a mechanism, and it may not hold for the 7.x series. Use it to test the Yocto LTS anchor you are choosing today, and re-read the table rather than assuming the pattern when the next longterm kernel is designated.

The support lifecycle clock that can lapse early

The silicon is usually the clock quoted with most confidence in a design review. NXP’s Product Longevity programme states a minimum period of either ten or fifteen years for each participating product, measured from that product’s launch date, with the period given per part number in the programme table. That is a real and useful commitment, and it is the number that makes a fifteen-year product plan look supportable.

Two clauses on that same page deserve to be read before the number is quoted. The first is that the participating products, the longevity period, or both are subject to change due to circumstances beyond NXP’s reasonable control, or when NXP has not received any material orders for the part for a period of twelve months. Note what that second condition measures: total demand for the part, not your own orders. A fifteen-year commitment can therefore shorten because the rest of the market moved on, which is a market risk rather than an engineering one, and it is not tracked by anybody in a kernel discussion. The second clause is that NXP may require customers to migrate to a product that is form, fit and function compatible with the participating product. Form, fit and function compatible is a hardware statement. It does not by itself guarantee that the same device tree, the same defconfig or the same driver revisions carry across.

The same caution applies to everything short of a migration. Product change notifications, errata, manufacturing-site transfers and security-related part changes can all arrive inside a longevity window and each can create software validation work. Longevity protects a procurement horizon; it does not freeze a software platform. Treat any part change as a potential engineering change with its own BSP and revalidation impact.

So the longest clock in the support lifecycle is not simply long. It is long, conditional, and expressed in units that do not translate directly into software effort.

What to do after upstream support ends

If the provider check in the companion article put you on linux-yocto in OE-Core, the Yocto LTS answers much of what follows for you until April 2030, and your planning question is what happens after that. If it put you on a vendor layer or your own fork, the rest of this section is the work. Either way the question is the same: what supplies kernel security fixes for your product after the upstream branch stops, and who has agreed to do it? There are four defensible answers and they cost different things. The point is not that one is correct. It is that the choice is dated, owned and written down.

The commercial option is the one most often missing from an engineering-led discussion, because it is bought rather than built. Several vendors sell exactly this: a hardened Yocto LTS derivative with kernel maintenance committed for a stated number of years, covering the vendor layers the upstream Yocto LTS does not, which converts the gap from an engineering risk into a line item. Whether it is the right answer depends on whether their supported board set covers your silicon, so it is a procurement conversation to start early rather than a fallback to reach for in 2029.

We name no vendor here, because terms and durations are negotiated per contract and change. What does not change is the list of things to insist the contract states, and it is short enough to take into the first meeting: which Yocto release series, which kernel branches and which BSP or vendor layers are covered by name; how long security fixes continue after both the upstream kernel and the Yocto LTS reach end of life; the CVE response time and the scope of backporting; and whether you receive tested update images and the evidence you need for your own qualification, or sources you must build and validate yourself. A quotation that does not answer those five is not yet an offer you can plan against.

The last option is the one most often assumed to remove the problem, so it is worth stating what it actually involves. CIP exists for products with exactly these life cycles — its own documentation describes target use cases with life cycles of twenty-five to fifty years. CIP states that its SLTS kernels are supported for at least ten years, and its maintenance policy says in the other direction that any given SLTS branch is unlikely to be economically maintainable for much more than ten years — so about a decade is both the floor and the realistic ceiling for one branch. The same policy says that new SLTS branches start only every two to four years, and that once a branch is past kernel.org LTS, architecture and hardware support is limited to the needs of CIP members. Two further conditions matter for a product team. CIP releases sources rather than binaries, except for its own platforms. And it does not guarantee in-kernel API or ABI stability within an SLTS branch, though it does say that incompatible changes to user-space APIs will not be accepted. Neither is a flaw. Both mean that choosing SLTS is a decision to keep an integration and validation capability in house for the life of the product.

The support lifecycle register, written down

A support lifecycle register is a strategy artifact: an explicit statement of what the team is standing on, and until when. Most treatments of this count three clocks — upstream, vendor, product. In practice there are more, because the build system keeps a calendar of its own, the kernel recipe belongs to whichever layer supplies it rather than to the release as a whole, and one clock governs all the others. Note that the second and third rows below are alternatives: fill in the one your provider check returned, and delete the other.

The last row is the one that governs the rest, and it is the one most often left off. A component can remain supported upstream long after a product has lost the ability to ship a validated update; a team can equally keep maintaining a component years after the community stopped. What a customer experiences is not the upstream date but whether your organisation can still produce, test and deploy a fix. Fill that row in first, then read the others as constraints on it.

The third row is the one most teams have never filled in, and it is usually the one that binds. Most teams do not build the kernel from kernel.org sources; they build the vendor’s branch, and it is the vendor’s willingness to keep patching that branch, not the upstream projection, that decides whether a fix reaches your product. The kernel.org and Yocto LTS dates set the outer bound. Look for the layer’s own statement first — meta-freescale, for example, publishes per-branch dates and splits bug fixes from BSP backports, giving an earlier date for BSP backports than for bug fixes — and where a layer publishes nothing, that absence is itself the finding, and it converts into a question with a name attached to it rather than a blank cell.

Two decisions follow from the table, and both have dates. The first is the rebase decision, which must be made well before December 2028 rather than at it, because a kernel uplift on a shipped product is a release cycle and not a patch. The second is the review date for the anchor itself, which should be the day the next longterm kernel is designated, since that is when you find out whether the shared-date pattern held.

What would change this support lifecycle

Projected end-of-life dates are projections. kernel.org states that a new longterm kernel usually starts with a two-year projected EOL that can be extended if there is enough interest from industry, and the current dates already reflect exactly that kind of extension. December 2028 could move. If it does, the sixteen-month interval shrinks or disappears, and the shared-date pattern may not hold for the next generation. Policies move too: the Yocto LTS window was itself extended to four years in 2023, and the set of layers the Yocto LTS covers is a policy decision that can be revisited.

That does not weaken the argument; it is the argument. A plan built on a date you have checked, with a named owner and a review trigger, treats a date change as an update. A plan built on the assumption that the newest release is the safest one meets it as a surprise.

Key takeaways

• An embedded Linux support lifecycle has five clocks, not one: the upstream kernel branch, the layer that supplies your kernel recipe, the build system, the silicon, and your own maintenance obligation.
• Under the projections published today the longterm branches share end dates in pairs, so choosing the newer kernel of a pair does not extend your upstream window. That is the state of the table, not a kernel.org policy.
• The last clock governs the whole support lifecycle. A component can stay supported upstream long after your organisation has lost the ability to ship a validated update.
• Four options cover the years after upstream support ends: a planned rebase, self-maintenance, a commercially supported platform, or an SLTS branch. Each assigns the work to somebody. Deferral without an owner, a budget and a review date does not.
• Super-long-term support relocates the maintenance work rather than removing it: sources rather than binaries, no in-kernel ABI guarantee inside a branch, and hardware scope narrowed to members’ needs after upstream LTS ends.
• Silicon longevity of 10 or 15 years is a stated minimum with conditions attached, including total demand for the part. A form-fit-function migration is a hardware equivalence, not a software one.
• Give every row of the support lifecycle a named owner and a review trigger. A plan built on a date you have checked treats a date change as an update rather than a surprise.

Frequently asked questions

Why does a support lifecycle need five clocks rather than one date?
Because five different organisations make the promises: kernel.org for the upstream branch, the Yocto Project for the components in its LTS policy, the layer maintainer or vendor for your kernel recipe, the silicon vendor for supply, and your own organisation for shipping validated updates. They expire on different days and no single date summarises them.

Does picking the newest longterm kernel give me the longest support?
Only across generations. Between two branches that share an end date it does not. Linux 6.12 receives about four years and one month of maintenance in total and 6.18 about three years and one month, and both are projected to stop in December 2028, so from September 2026 they leave the same remaining window. Choose between them on driver coverage, which branch your vendor is feeding, and migration cost instead.

Which clock in the support lifecycle is binding?
Your own maintenance obligation, expressed as the date you must still be able to ship a validated update. The others are constraints on it. Among the external ones, the layer that supplies your kernel recipe is usually the tightest, and where a layer publishes two dates the BSP backport date is the one that bites first.

Does buying super-long-term support remove the problem?
No, it relocates it. The Civil Infrastructure Platform targets life cycles of twenty-five to fifty years, but its own policy says a given SLTS branch is unlikely to be economically maintainable for much more than ten years, that new branches start only every two to four years, that it releases sources rather than binaries, and that it does not guarantee in-kernel API or ABI stability within a branch. Choosing it is a decision to keep integration and validation capability in house.

Is a 15-year silicon longevity commitment enough for a 15-year product?
It covers supply of the part, not maintenance of the software. The commitment is also conditional: NXP states that the longevity period may change when it has received no material orders for twelve months, and that it may require migration to a form, fit and function compatible product, which is a hardware equivalence rather than a software one.

When should the rebase decision be made?
Well before the upstream end-of-life date rather than at it, because a kernel uplift on a shipped product is a release cycle and not a patch. Set the review date for the anchor itself to the day the next longterm kernel is designated, since that is when you find out whether the shared-date pattern held.

Further reading

• The Linux Kernel Archives — Active kernel releases
• Yocto Project — Stable Release and LTS
• meta-freescale — maintenance policy and per-branch support dates
• Civil Infrastructure Platform — kernel maintenance policies
• NXP — Product Longevity programme