How it is created — SDL-STD-022 Support Period & Security Update Policy

1. What this commits you to

The support period is a promise with a cost. It fixes how long you must keep a branch buildable, patchable and signable — which in turn fixes toolchain, SDK and component choices made years earlier. This is why the EOL check and this policy have to agree: declaring seven years while shipping an SDK maintained for four is a compliance gap dressed as a marketing statement.

It is also the document a buyer reads. The end date has to be available at purchase time, so it is a commercial commitment before it is a technical one — which is why management, not engineering, owns the number.

2. Inputs

• The expected use time of each product line — installation lifecycles, maintenance contracts, how long units actually stay in the field. This is the CRA's yardstick, not a marketing preference.
• The EOL assessment for the components and toolchains behind each line: what can genuinely be patched to that horizon, and at what maintenance cost.
• Your update mechanism's real capabilities: signing, rollback protection, recovery, and whether air-gapped sites can be served at all.
• The vulnerability-handling process, whose remediation classes define what "without undue delay" means in days.

3. Steps

1. Set the period per product line, not per product. A single number per line is maintainable; per-SKU exceptions are not. State the rationale — it is part of the technical documentation.
2. Go above the floor where the field life demands it, and say why. Industrial installations outlive consumer devices; a declared period shorter than the realistic use time is the thing an authority will question.
3. Write the deviation rule. Anything below five years needs a demonstrable justification and a named approver. Make that explicit, or it will happen implicitly.
4. Say where the end date is published — user information, product page, technical documentation, available before purchase — and as what: a month and year, not "five years from release", which no customer can evaluate.
5. Handle the awkward cases now, in writing: channel stock and RMA replacements placed on the market later, extensions bought via contract, and what happens at end of support. Extensions must never shorten the published baseline.
6. Announce end-of-support long in advance — twelve months is a defensible norm — with a final security advisory and an unambiguous statement on the product page afterwards.
7. Define what a security update is.* Free of charge, for every unit, without registration barriers; delivered on a separate patch line so a security fix never requires accepting new features, changed defaults or new terms.
8. Write the inseparability exception before you need it: when a fix cannot be separated from a feature release, the advisory says so, the release notes split the content, and someone senior approves it. Without the exception you get silent non-compliance; without the conditions you get it routinely.
9. Specify the distribution mechanism as security properties, not products: signed images with keys in an HSM, signature verification before install, anti-rollback counters, power-fail-safe A/B installation, TLS with pinning, and signed offline packages for air-gapped sites.
10. State the default behaviour. Automatic security updates on by default where unattended restarts are acceptable; where the intended use forbids that, a prominent notification and a one-action opt-in — and record the risk acceptance in the release checklist.
11. List the supported branches per product somewhere maintained, and give users on unsupported branches a free upgrade path.

4. Done when

• Every product line has a period, a rationale and a published end date in month/year form.
• The period is defensible against both the expected use time and the EOL assessment behind it.
• "Free of charge" and "separate from feature updates" are stated as rules, with the exception path and its approver.
• The update mechanism's integrity, anti-rollback and recovery properties are specified, not assumed.
• End-of-support has a notice period, a final advisory and a public statement.
• Management has signed a dated revision.

5. Common mistakes

Declaring a period the toolchain cannot survive. Publishing "5 years" without a date the buyer can read. Bundling security fixes into feature releases because the branch model makes anything else expensive — decide the branch model in favour of the obligation, not the other way round. Forgetting the units that leave the warehouse two years after launch. And treating end-of-support as a silent event.

6. In TRA Studio

The support period is the clock every post-release activity runs against. Record it on the product, model the update and advisory activities in the Secure Lifecycle, and assign the Annex I Part II update requirements to them — so "supported until 2033" is backed by activities with owners rather than by a sentence in a datasheet.