PSM-LST-001 — Product & Support Register

1. What this register is for

Three questions have to be answerable in minutes, not days: which products are still in support, which firmware branches still receive security fixes, and which versions is a given advisory about. Every one of them is a lookup, and none of them can be reconstructed from the codebase.

This register is therefore the single source of truth for:

• the published support end date per product and hardware revision (SDL-STD-022 §1.3);
• the branches that receive security updates (SDL-STD-022 §2.4);
• the scope of "affected versions" in triage (PSM-PROC-003 P2.1) and in advisories (P4.2);
• the population that must be reached when a vulnerability is actively exploited (Art. 14(8)).

§2 is published as the public support matrix; §3 and §4 are internal.

2. Support matrix (published excerpt)

Support end dates are stated as month/year and are binding. Extensions never shorten a published date (SDL-STD-022 §1.4). Units placed on the market later inherit the end date of their hardware revision (§1.5).

Note on the S200-AP extension. Revisions B and C were placed on the market under SDL-STD-022 rev. 1.0, whose default was five years. When rev. 2.0 raised the industrial default to seven years, the Managing Director extended the existing revisions to a single aligned date (2030-05) rather than leaving three end dates in the field. The original baselines are kept in this table because the technical documentation of those units states them, and a support matrix that quietly overwrites history cannot be reconciled against the documents shipped with the product.

Placement responsibility. The S200-AP is placed on the EU market by ACME Embedded Asia Pte. Ltd. and carries an EU authorised representative (REG-REC-019). The obligations in this register apply unchanged; only the placing entity differs.

3. Supported branches (internal)

Minimum per SDL-STD-022 §2.4: the latest release branch, plus any branch declared long-term in a customer contract. A branch not listed here receives no security fixes, and users on it are directed to the free upgrade path.

A fix for a vulnerability affecting both 3.5.x and 3.4.x is developed on both (PSM-PROC-003 P3.2). Two branches is a deliberate ceiling: each additional long-term branch is a multiplier on every future security release, and is only opened where a contract requires it.

4. Per-product references (internal)

5. Maintenance rules

1. A product enters this register at the release gate (SDL-PROC-001 #3.7), not at first shipment. A product in the field but not in the register is a product nobody is monitoring.
2. A new hardware revision is a new row. Revisions differ in components, and therefore in which advisories apply to them.
3. End dates change only by MD decision, and only upward. Every change is recorded in §7.
4. Branch changes are the VM's, because triage scope depends on them; retiring a branch requires a published upgrade path first.
5. End of support is executed from this register: the 12-month advance announcement, the final security advisory, and the product-page statement that updates have ceased (SDL-STD-022 §1.4, SDL-PROC-001 #4.7).
6. The register is reconciled against the published support pages monthly. A mismatch between what this table says and what a customer can read is a finding, and the published page wins until corrected.

6. Records

This register is itself a quality record. Superseded revisions are retained — an advisory published in 2027 must be verifiable against the branch and support data that were in force when it was written.

7. Revision history