How it is created — PSM-LST-001 Product & Support Register

1. Why this artifact exists

A vulnerability arrives naming a component version. Three questions follow immediately: which of our products contain it, which of those are still in support, and which branches do we have to fix. Triage cannot start until all three are answered, and none of them can be answered from the codebase — the codebase knows what is on main today, not what is in a cabinet in a factory in Bavaria.

Most small manufacturers hold this in one person's memory, and it works until the day it has to work under a deadline. The register is what turns "roughly five years, I think, and there's an old branch for that one customer" into a lookup.

It is also the document that makes a published support-period claim checkable. You committed to an end date in the user information of every unit you shipped; the register is where you can still see what you committed to, per hardware revision, years later.

2. Inputs

• Your support-period policy: the defaults per product line, and the rule for what happens when the policy changes.
• Placement-on-market dates per product and hardware revision. Not release dates — placement is what starts the clock.
• The branch model: which branch is current, which are contractually long-term, which are retired and what the upgrade path is.
• Customer contracts containing long-term support commitments, because those create branches you would not otherwise maintain.
• Your release dossiers and per-product risk assessments, so the register can point at them rather than restate them.

3. Steps

1. Make the row a hardware revision, not a product. Revisions differ in components, so they differ in which advisories apply. A product-level row will eventually force you to over-notify or under-notify.
2. Record the baseline that was in force at placement, and the current published date, in separate columns. When your policy improves, you extend the date; you do not rewrite the history. The technical documentation shipped with those units states the original number, and a register that contradicts it cannot be reconciled during an audit.
3. Write the rule that extensions never shorten a published date. Then apply it visibly — an aligned end date across revisions is a decision worth showing, because the alternative is three different dates in one customer's cabinet.
4. List supported branches with an end date each, and treat the list as exhaustive: a branch not on it gets no fixes, and users on it get a published upgrade path rather than silence.
5. Cap the number of long-term branches deliberately. Each one multiplies the cost of every future security release. Two is a defensible ceiling; the point is that the number is a decision rather than an accumulation.
6. Give the register an entry point tied to the release gate, not to shipping. A product in the field that never entered the register is a product nobody is monitoring, and that is exactly the one that will be named in an advisory.
7. Point at the per-product documents rather than copying them. Risk assessment, threat model, release dossier, latest advisory. The register is an index; the moment it duplicates content it starts to disagree with it.
8. Reconcile against the public support pages on a schedule. Monthly is enough. Where they differ, the published page is what the customer relied on — it wins until you correct it, and the mismatch is a finding.
9. Retain superseded revisions. An advisory published next year has to be verifiable against the branch and support data in force when it was written.
10. Drive end-of-support from this register: the 12-month announcement, the final advisory, the product-page statement. If EOS is driven from anywhere else, the register will be the thing that is out of date.

4. Done when

• Every product with digital elements in the field has a row, per hardware revision.
• Each row states placement date, the baseline at placement, and the current published end date.
• Supported branches are listed with end dates, and every unsupported branch has a published upgrade path.
• Changes to published end dates require management approval and are recorded.
• The public support matrix and this register agree, and someone checks that they do.
• End-of-support actions are triggered from here.

5. Common mistakes

Tracking products instead of hardware revisions. Overwriting an end date when the policy improves, so the register no longer matches the documents shipped with the product. Letting long-term branches accumulate one customer at a time until every security fix needs five backports. Adding products at shipment rather than at the release gate. And keeping the register in a spreadsheet nobody reconciles against the public page — at which point you have two answers to a question that can only have one.

6. In TRA Studio

The support period is where a product's obligations end, and almost every post-release requirement is scoped by it. Keep the end date and the supported branches visible on the product, not buried in a document, so that the lifecycle requirements you have assigned are read against a real horizon. A vulnerability-handling requirement assigned to a product whose support end date nobody can state is assigned to an open-ended commitment.