ETSI EN 304 626

This is a vertical pack: a product-category standard, published in full and evaluated alongside the horizontal CRA rule pack— it supplements that pack for one Annex III category, it does not replace it. Everything below — every requirement, applicability entry, assessment block, correspondence row, threat and draft defect — is rendered from the same file the assessment engine reads. Nothing is generated at answer time, so this page cannot drift from what the product evaluates.

The same data, machine-readable, is served at /api/pack/vertical?id=en-304-626 — fetch it, keep a copy, and diff it when the draft moves. Because the standard is a moving draft, the source card pins exactly which text this pack was built from, and the draft gaps card records the defects we found in that text rather than papering over them.

On this page: source & license · how it attaches · requirement index · full text · CRA correspondence · threats · draft gaps · how it's built

Source, license and attribution

• Source: https://labs.etsi.org/rep/stan4cra/en-304-626 (the ETSI Labs draft repository), commit 078b416a, retrieved 2026-09-02.
• License: BSD-3-Clause, © 2025 ETSI. Redistributed with attribution as the license requires; the verbatim requirement and mitigation text below is reproduced from the interim draft.

To be plain about what that means: the normative requirement and assessment text on this page is reproduced verbatim from the interim draft under the license above, with the required copyright notice, conditions and disclaimer preserved in full below. The draft is a consultation document, not an ETSI deliverable — approved versions of ETSI standards are available only from the ETSI Documentation Service, and nothing reproduced here confers any presumption of conformity.

How this pack attaches

The pack applies to products classified under the CRA Annex III item “Operating systems” (pack category id: important-1). Attaches to a product whose CRA classification matched the Annex III 'Operating systems' item, or manually. The horizontal CRA pack keeps evaluating the product either way; this pack adds the category-specific requirements on top.

Scope (the draft’s own)

Applicability (the draft’s own)

The 16 use cases

Applicability is declared per use case: the draft defines 16 product contexts, and each clause-5 requirement states, per use case, whether it is required. The index below renders every column; enabling the pack on an assessment means choosing one of these.

Requirement index

Every requirement in one place: the 19 clause-5 requirements with their per-use-case applicability. Ids link to the full verbatim text below; each row is addressable so a review can cite specific rows.

● = required for that use case · — = not required. Use cases: UC-LR Operating system for learning and research · UC-IoT-1 Non-internet-connected device such as a bluetooth speaker · UC-IoT-2 Internet-enabled power switch · UC-IoT-3 Internet-connected "smart home" device · UC-RO-1 Consumer-grade home wireless router · UC-OT-1 Business-grade remote door locking system · UC-MOB-1 Personal mobile device · UC-WE-1 Wearable health tracker · UC-PC-1 Personal computer in a fixed and generally safe location · UC-PC-2 Enterprise workstation in a fixed and generally safe location · UC-LA-1 Personal laptop · UC-LA-2 Enterprise laptop · UC-PS-1 Personal server · UC-SE-1 Enterprise server in a datacenter with no user accounts · UC-SE-2 Enterprise server in a datacenter with only trusted user accounts · UC-SE-3 Enterprise server in a datacenter hosting many untrusted user accounts.

5.2.2 — TR-NKEV: No known exploitable vulnerabilities at first use

5.2.3 — TR-SSDD: Secure design and development

5.2.4 — TR-MISO: Prevent local unauthorized access of memory-addressable security-relevant data

5.2.5 — TR-MSAF: Mitigate memory safety errors

5.2.6 — TR-LMII: Limit incident impact

5.2.7 — TR-MINI: Minimize impact on other devices and services

5.2.8 — TR-SDEF: Secure by default configuration

5.2.9 — TR-SCUD: Secure updates

5.2.7 — TR-AUTH: Authentication and access control

5.2.7 — TR-CDST: Confidentiality of data stored on the product

5.2.8 — TR-CDTX: Confidentiality of data transmitted by product

5.2.9 — TR-CRYP: Encryption

5.2.10 — TR-IDST: Integrity of data stored on the product

5.2.11 — TR-IDTX: Integrity of data transmitted by the product

5.2.12 — TR-DMIN: Data Minimization

5.2.13 — TR-AVAI: Availability

5.2.14 — TR-LMAS: Minimize exposed interfaces

5.2.15 — TR-LOGG: Logging and monitoring

5.2.16 — TR-SCDL: Secure deletion

5.2.17 — TR-SDTR: Secure data read and transfer

5.2.18 — TR-VULH: Vulnerability handling

Correspondence to the CRA

The draft’s own correspondence table: which of its clauses address which essential requirement of CRA Annex I. This is the draft’s claim, reproduced as it stands — not Vandorisk’s judgment of coverage, and (status block above) not a presumption of conformity.

Where the table covers CRA Annex I Part 1 only, the Part 2 (vulnerability handling) obligations remain assessed through the horizontal CRA pack(II.1–II.8).

Threat catalogue

The 10 threats the draft derives its requirements against, verbatim:

Draft gaps

Defects and holes we found in the interim draft while building this pack — recorded rather than papered over; they will be rechecked against each new draft. A standard under consultation is allowed to have holes. A pack that hides them is not.

• TR-SCUD: clause 5.2.9 contains a bare TODO heading (5.2.9.5 — the draft notes it awaits a submission from an unavailable ETSI member).
• TR sections without any Requirement text in this interim draft: TR-AUTH, TR-CRYP — TR-AUTH ("future revisions will include state-of-the-art authentication requirements") and TR-CRYP ("waiting on the cross-vertical cryptography approach"; there is no Annex K). They are kept as empty topics, not as answerable requirements.
• Clause numbering collides in this draft (three sections numbered 5.2.7, two 5.2.8, two 5.2.9, and two mitigation headings numbered 5.2.8.4); requirements and mitigations are identified by their TR-/MI- codes, which are unique.
• assessment criteria drafted for only 2 of 19 requirements: only TR-MSAF and TR-LMII carry a requirement-level assessment block (their shared "Default Preparation, Verdict, and Evidence"); the other 17 requirements have assessment: null. Assessment prose does exist per MITIGATION (bulleted Objective/Preparation/Activities/Verdict/Evidence inside each entry of a requirement's mitigations list, preserved verbatim), because this draft has not yet separated clause-6 assessment criteria from clause-5 requirements — clause 6 (Conformity Assessment) is empty apart from an editor's note saying the guidance stays adjacent to the requirements for now.
• Clause 5.3 (Risk Mitigation Sets) assigns mitigations per security profile SP-* using bare codes, several of which clause 5.2 never defines (SUAP, SUAO, SUVP, SUOE, SUDC, AUTH, CRYP, VULH, DMIN, KEVT-vs-SCAN alternates and MSAF-*/MZRO-*/MRWX-* wildcards). Per-use-case applicability therefore cannot be derived reliably and is not fabricated: every loaded requirement is treated as applicable (applicability {}), and the profile tables remain in the draft for manual consultation.
• Four availability mitigations under TR-AVAI are TODO stubs with no normative text yet (MI-FDRP, MI-LMEM, MI-FAIR, MI-DOST) — their verbatim TODO lines are preserved in the mitigations list.
• Annex D.4 names risk-transfer mitigations that clause 5.2 does not define (MI-SUDC, MI-SUOE, MI-SUAO) — dangling references in this interim draft.
• This draft has no Annex K (cryptography) and no Annex R (RDPS); rdps is loaded empty. Annex A maps by CRA requirement description rather than Annex I item numbers, and flags AUTH and CRYP as 'waiting on cross-vertical'.
• The draft's ids are TR-XXXX (requirements) and MI-XXXX (mitigations); it contains no REQ-prefixed ids. MI-SCFS references "TR-SDDV", a code defined nowhere — the surrounding section is TR-SSDD.
• Annex C numbers its threats C.4.3–C.4.7 then C.4.9–C.4.13 — C.4.8 does not exist in this interim draft; the 10 published threats are loaded.

How this pack is built, and corrections

The pack is produced by a deterministic parser over the vendored draft text pinned in the source card— no model writes or rewrites any requirement. When ETSI updates the draft, the pack is rebuilt from the new text, the draft gaps are rechecked, and the result ships as a new pack version — never a silent edit.

The interim draft and, once published, the standard itself are the authoritative texts — this pack reproduces and cites them, it does not replace them, and nothing on this page is legal advice. If you find an error — a mis-parsed requirement, an applicability entry that does not match the draft, a gap we missed — write to hello@vandorisk.com. The horizontal pack this one attaches alongside is published at /pack, with every tracked vertical standard listed there.