Fictitious example. ACME Embedded GmbH, its products, records and document IDs are invented for illustration. Use this as a structural model, not as a template to adopt unchanged — and not as legal advice.
SDL-STD-022 — Support Period & Security Update Policy
| Document ID | SDL-STD-022, rev. 2.0 |
| Owner | Managing Director (product-line decisions) with Product Security Lead |
| Approved by | Managing Director, 2026-07-29 |
| Reference | CRA Art. 13(8) (support period), Annex I I(2) & Part II(2)(7)(8) (security updates); SDL-PROC-001 activities 0.4, 3.4, 4.2 |
| Applies to | All ACME products with digital elements |
| Review | Annually in the management review |
1. Support period
1.1 Definition. The support period is the time during which ACME ensures vulnerabilities of a product are handled effectively per PSM-PROC-002, including provision of security updates. It is determined per product before placing on market, considering the expected use time of the product — for our industrial customer base this is deliberately set above the regulatory minimum.
1.2 Defaults by product line:
| Product line | Support period from placement on market | Rationale |
|---|---|---|
| Industrial sensors & gateways (S/G series) | 7 years | Industrial installation lifecycles; customer maintenance contracts |
| Accessories with digital elements (commissioning tools) | 5 years | Regulatory floor; shorter field life |
Deviations below 5 years require an MD-approved justification recorded in the technical documentation (expected shorter use time must be demonstrable).
1.3 Publication. The support period end date (month/year) is stated: (a) in the user information delivered with the product, (b) on the product support webpage, (c) in the technical documentation, and (d) it is available at purchase time. For products already in the field, the current end date per hardware revision is maintained in the public support matrix (PSM-LST-001, published excerpt).
1.4 Extension and end-of-support. Extensions (e.g. via paid long-term contracts) never shorten the published baseline. End-of-support is announced ≥ 12 months in advance via advisory and customer notification; a final security status advisory is published at EOS. After EOS, the product page states clearly that no further security updates are provided.
1.5 Spare parts / re-placement. Units placed on the market later (e.g. channel stock, RMA replacements) inherit the support end date of the product line as published — the clock is managed per product line, and the published end date is binding.
2. Security updates
2.1 Free of charge. Security updates are provided free of charge for the entire support period, for every unit placed on the market, without registration barriers beyond what the update mechanism technically requires.
2.2 Separation from feature updates. Security fixes are shipped as separate security updates wherever technically feasible:
- Version scheme:
MAJOR.MINOR.PATCH— security-only releases incrementPATCHon every supported branch (e.g. 3.4.x security branch maintained in parallel to 3.5 feature development). - A security update never requires the user to accept new features, changed defaults, or new terms.
- Exception rule: if a fix is technically inseparable from a feature release, the advisory states this explicitly and the release notes separate security content from feature content; requires PSL approval, recorded in the case file.
2.3 Timeliness. Security updates are released without undue delay per the remediation classes in PSM-PROC-002 §3 (emergency ≤ 7 days target, high ≤ 30, medium ≤ 90). Where a fix needs longer, mitigations are published in the interim.
2.4 Supported branches. For each product, the branches receiving security updates are listed in PSM-LST-001. Minimum: the latest release branch plus any branch declared "long-term" in customer contracts. Users on unsupported branches are directed to a free upgrade path.
3. Secure distribution mechanism
- Integrity & authenticity: all update images are signed (release signing key in HSM, 4-eyes release signing per SDL-STD-025); devices verify signatures before installation; anti-rollback counters prevent downgrade to vulnerable versions.
- Channel: updates are distributed via the ACME update service over TLS (certificate pinning on companion tools) and, for air-gapped industrial sites, as signed offline packages with published SHA-256 checksums.
- Default behaviour: automatic installation of security updates is enabled by default where the product class permits unattended restarts; where intended use requires controlled maintenance windows (see risk acceptance pattern in SDL-CHK-030 item D2), the device prominently notifies the user of pending security updates, and the opt-in path is one action.
- Recoverability: update process is power-fail safe (A/B slots); a failed update never leaves the device in a less secure state.
- Transparency: every security update ships with an advisory (ACME-SA-…) listing fixed vulnerabilities per PSM-PROC-002 §5.
4. User information (delivered with each product)
The quick-start/user documentation states, in plain language: the support period end date; where security advisories are published; how updates are installed (and the default behaviour); the contact point for reporting vulnerabilities (security@…); and where the SBOM information notice can be requested.
5. Records
Per product: the support-period determination and rationale, the published support statement, update release records with signing evidence, and EOS notices — all quality records, retained 10 years after the last unit is placed on the market, referenced from the Annex-VII technical documentation.
Revision history
| Rev | Date | Change | Approved |
|---|---|---|---|
| 1.0 | 2025-03-10 | Initial issue (5-year default) | MD |
| 2.0 | 2026-07-29 | 7-year default for industrial lines; branch policy; offline update packages; EOS advisory rule | MD |
