How it is created — ENG-REC-031 EOL Check: Tools and Dependencies

1. The question this answers

Can you still ship a security patch for this product in year seven? Not "is this component popular", but: will the RTOS, the crypto library, the vendor SDK, the bootloader and the toolchain still be patchable — by upstream or by you — until the end of the declared support period?

The answer changes procurement decisions, so it has to exist before those decisions are made.

2. Inputs

• Launch date plus declared support period, plus the margin your component policy requires. This produces a single date: the horizon. Write it in the header.
• The candidate component list, including build-time tooling and CI images, not only what ships on the device.
• Published EOL and LTS policies from each upstream project or vendor, with the URL and the date you checked.

3. Steps

1. Compute the horizon first and state it as a date. Every verdict in the table is "before" or "after" that date; without it the assessment becomes opinion.
2. State the pass rule. A component passes if its published support end is beyond the horizon, or if a concrete, costed migration or self-maintenance path is documented and approved. "We will deal with it later" is not a pass — write that sentence into the record.
3. List every component and tool in one table: candidate version, published EOL, comparison against the horizon, verdict. Include the toolchain and the build container; reproducing a build in year seven is a real obligation.
4. For LTS-based components, assess the cadence rather than a single date. An LTS line maintained for two to three years passes only if you plan the migrations — so the verdict is "pass with condition", and the condition names the reserved maintenance releases and the effort estimate.
5. Flag the near misses. A vendor programme ending one year inside your horizon is not a pass; it is a conditional that must be closed by a contract clause or by choosing the other candidate.
6. Fail what must fail. A binary component with no EOL commitment and no self-maintenance path is a knock-out under the component policy. Record the resolution path and a date: request contract terms by a deadline, otherwise switch candidates.
7. Route the conditions into the decisions they affect — the hardware selection record, the maintenance budget, the release dossier archive rule.
8. Set the re-check schedule and keep every version of the record.

4. Done when

• The horizon is a date, and every row is judged against it.
• Every "pass with condition" names the condition, its owner and its cost.
• At least one failure path is real: if nothing can fail this check, the check is decorative.
• The conditions appear in the project plan and the maintenance budget, not only in this document.

5. Common mistakes

Checking only what ships on the device and forgetting the toolchain and build environment. Accepting "actively maintained" as a verdict. Running this after the hardware is chosen, which turns a selection criterion into a risk you have to accept.

6. In TRA Studio

Model the EOL check as a recurring activity in your Secure Lifecycle — assigned to the Annex I Part II requirements it satisfies — so the annual re-run is part of the process rather than something that depends on one person remembering.