EN-304-617.md

**If Embedded**: EMB-1-REQ-1 through EMB-1-REQ-17, EMB-REQ-8, EMB-REQ-3, EMB-REQ-22

**Compliance**: GDPR data protection, session re-auth, auto-timeout, audit trails

**Assessment References**: ENC-REQ-1-7, LOG-REQ-7-9, LOG-REQ-19, LOG-REQ-11, EMB-REQ-3, EMB-REQ-22 (if embedded)

---

### UC-B6: E-Government Services Access (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-1
- **EXT**: EXT-1
- **ENC**: ENC-0
- **LOG**: LOG-2 or LOG-3
- **UPD**: UPD-0 or UPD-1
- **PRO**: PRO-1
- **SYS**: SYS-1 or SYS-2

**Critical Requirements**: ENC-0-REQ-1 through ENC-0-REQ-23, ENC-REQ-2, ENC-REQ-3, SYS-REQ-29, DOM-1-REQ-1 through DOM-1-REQ-9, LOG-REQ-15, UPD-0-REQ-1 through UPD-0-REQ-24

**Special**: Digital signatures, smart card integration, eIDAS compliance, legal non-repudiation

**Assessment References**: ENC-REQ-2-3, ENC-REQ-6, SYS-REQ-29, LOG-REQ-15

---

### UC-B7: Enterprise Applications (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-2
- **EXT**: EXT-1 or EXT-2
- **ENC**: ENC-1
- **LOG**: LOG-3
- **UPD**: UPD-0 or UPD-1
- **PRO**: PRO-2
- **SYS**: SYS-2
- **EMB** (if Electron/CEF/Tauri): EMB-2 or EMB-3

**Critical Requirements**: DOM-2-REQ-1 through DOM-2-REQ-12, LOG-3-REQ-1 through LOG-3-REQ-20, LOG-REQ-13, LOG-REQ-14, LOG-REQ-16, EXT-2-REQ-10, UPD-0-REQ-1 through UPD-0-REQ-24, PRO-2-REQ-11, SYS-2-REQ-11 through SYS-2-REQ-15

**Enterprise Features**: SSO, DLP, extension allowlisting, profile separation, BYOD containerization

**Assessment References**: DOM-REQ-9-11, LOG-REQ-13-16, LOG-REQ-19, EXT-REQ-3, PRO-REQ-3, SYS-REQ-7

---

### UC-B8: Critical Infrastructure (Risk Level: CRITICAL)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-0 or DOM-1
- **EXT**: EXT-0
- **ENC**: ENC-0
- **LOG**: LOG-3
- **UPD**: UPD-0
- **PRO**: PRO-0 or PRO-1
- **SYS**: SYS-0 or SYS-1
- **EMB** (if SCADA/ICS): EMB-0 or EMB-1

**Critical Requirements**: DOM-0-REQ-1 through DOM-0-REQ-6, EXT-0-REQ-1 through EXT-0-REQ-3, ENC-0-REQ-1 through ENC-0-REQ-23, LOG-3-REQ-1 through LOG-3-REQ-20, LOG-REQ-11, UPD-0-REQ-1 through UPD-0-REQ-24, UPD-REQ-5, UPD-REQ-11, PRO-0-REQ-1 through PRO-0-REQ-5, SYS-0-REQ-1 through SYS-0-REQ-13

**If Embedded**: EMB-0-REQ-1 through EMB-0-REQ-7, EMB-REQ-17, EMB-REQ-20, EMB-REQ-27, EMB-REQ-31

**Additional**: Zero trust, mTLS, RBAC, air-gapped deployment, supply chain controls, physical security

**Assessment References**: ALL assessments at strictest criteria; ENC-REQ-1-11, UPD-REQ-1-11, LOG-REQ-10-11, SYS-REQ-26-28, EMB-REQ-17-31 (if embedded)

---

### UC-B9: Security Research (Risk Level: CRITICAL)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-2 or DOM-3
- **EXT**: EXT-3
- **ENC**: ENC-1
- **LOG**: LOG-3
- **UPD**: UPD-2 or UPD-3
- **PRO**: PRO-3
- **SYS**: SYS-3

**Critical Requirements**: LOG-3-REQ-1 through LOG-3-REQ-20, LOG-REQ-6, LOG-REQ-17, DOM-3-REQ-9, EXT-3-REQ-9 through EXT-3-REQ-12, SYS-3-REQ-15

**Environment Isolation**: Disposable VMs, network capture, air-gapped zones, snapshot/rollback, behavioral logging

**Important**: Deploy ONLY in isolated research environments; NOT for production

**Assessment References**: LOG-REQ-1-20, LOG-REQ-17, EXT-REQ-4, all assessments in adversarial conditions

---

### UC-B10: Adapted Browser with Modified Features (Risk Level: Standard to High)

**Primary Capabilities and Recommended Conditions**:

- **All capabilities**: Inherit from upstream browser
- **LOG**: May vary (LOG-1, LOG-2, or LOG-3)
- **UPD**: UPD-0 or UPD-1 (manufacturer-controlled)
- **EMB** (if native integration added): EMB-2 or EMB-3

**Critical Requirements**: All upstream requirements PLUS UPD-REQ-2, UPD-REQ-11, EMB-REQ-9, LOG-REQ-9, LOG-REQ-7, LOG-REQ-8

**If Native Integration Added**: EMB-2-REQ-1 through EMB-2-REQ-10 OR EMB-3-REQ-1 through EMB-3-REQ-12, EMB-REQ-1, EMB-REQ-2, EMB-REQ-3, EMB-REQ-9

**For Bundled Extensions**: EXT-REQ-4, EXT-REQ-17, supply chain security

**Manufacturer Obligations**: Timely upstream patches, security review, transparency, maintaining security controls, supply chain security

**Risk Level**: Standard (minimal modifications) to High (extensive modifications, sensitive data, high-risk deployment)

**Assessment References**: All upstream assessments PLUS EMB-REQ-9, UPD-REQ-2, LOG-REQ-9, EMB assessments if native integration

---

## B.3 Capability Condition Level Selection Guide

| Use Case Risk | DOM | EXT | ENC | LOG | UPD | PRO | SYS | EMB |
|---------------|-----|-----|-----|-----|-----|-----|-----|-----|
| Standard | DOM-1 | EXT-1/2 | ENC-1 | LOG-1 | UPD-1 | PRO-1 | SYS-1 | EMB-1 |
| High | DOM-1/2 | EXT-0/1 | ENC-0/1 | LOG-2/3 | UPD-0/1 | PRO-0/1 | SYS-0/1/2 | EMB-0/1/2 |
| Critical | DOM-0/1 | EXT-0 | ENC-0 | LOG-3 | UPD-0 | PRO-0 | SYS-0/1 | EMB-0/1 |

**Note**: Specific deployments shall conduct detailed risk assessments per Annex D to determine appropriate condition levels.

## B.4 Cross-Reference to Assessments

All assessments in Chapter 6 map to requirements referenced in this annex:

- **Section 6.1**: DOM-REQ-1 through DOM-REQ-12
- **Section 6.2**: EXT-REQ-1 through EXT-REQ-18
- **Section 6.3**: ENC-REQ-1 through ENC-REQ-21
- **Section 6.4**: LOG-REQ-1 through LOG-REQ-20
- **Section 6.5**: UPD-REQ-1 through UPD-REQ-23
- **Section 6.6**: PRO-REQ-1 through PRO-REQ-23
- **Section 6.7**: SYS-REQ-1 through SYS-REQ-32
- **Section 6.8**: EMB-REQ-1 through EMB-REQ-32

# Annex C (informative): Relationship between the present document and any related ETSI standards (if any)

_List any related ETSI standards and how they interact with the present document._

# Annex D (informative): Risk identification and assessment methodology

## C.1 Assets

### C.1.1 Data

_What data is stored on the product?_

### C.1.2 Product functions

_See the functions in Section 4.4._

## C.2 Threats

_Based on the assets, what are the threats during:_

- _Use for intended purpose or reasonably foreseeable use_
- _When integrated into another product_

_Example threats can be found in the same documents suggested in the section on security requirements._

## C.3 Assumptions

_List assumptions that are relevant to the risk analysis for these threats. Everything is hackable if you try hard enough. What kinds of threats are in and out of scope? What are you assuming is the sophistication of attack? Relate to use cases. Some examples might include:_

- _Not being attacked by a state actor_
- _Not using sophisticated or expensive hardware snooping techniques_
- _No secret hardware backdoors in other components_

## C.4 Risk assessments of threats

_For each threat identified above, use likelihood and magnitude of the threat to assess its risk in the context of use cases. The results should be consistent with the mapping of use cases to security levels._

_Guidance from latest PT1 draft:_

> _An analysis in terms of likelihood and magnitude of a product’s threats is required to be able to determine the product’s risks._
> _NOTE 1 This document does not require a specific methodology for a cybersecurity risk analysis as long as the cybersecurity risk estimation is based on the likelihood of occurrence and magnitude of loss or disruption of cybersecurity risks. Thus, different approaches and models such as the fishbone model, event tree analysis or fault tree models can be used within the analysis of cybersecurity risks._
> _NOTE 2 A qualitative estimation of the cybersecurity risks can be performed using risk matrices that map qualitative categories of the likelihood of occurrence and qualitative categories of magnitude of loss or disruption to cybersecurity risk categories._
> _NOTE 3 A quantitative estimation of the cybersecurity risks can be performed using scoring systems that map qualitative categories of the likelihood of occurrence and qualitative categories of magnitude of loss or disruption to certain values._

# Annex E (informative): Risk evaluation guidance

## E.1 Mapping of risks to requirements

_Table mapping the identified risks to requirements_

## E.2 Risks not treated by the requirements

_If any risks are not treated by the normative requirements, describe non-normative suggestions to mitigate them._

## E.3 Risk acceptance criteria

_Describe how to decide if residual risks are tolerable._

## E.4 Residual risks

_Describe how to treat any residual risks, for example by documenting them or informing the user._

# Annex J

- potential vulnerability
- discovered vulnerability
- known vulnerability
- publicly known vulnerability
- actively exploited vulnerability
- exploited vulnerability
- exploitable vulnerability
- known exploitable vulnerability
- known newly emerged vulnerability
- notified vulnerability
- AI specific vulnerability
- fixed vulnerability

- https://wpt.fyi/results/cors?label=stable&label=master&aligned
- https://html5test.co/ 
- https://caniuse.com/
- https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/faq.md 
- https://chromium.googlesource.com/chromium/src/+/master/docs/security/compromised-renderers.md

# Annex K
Crypto todo

https://certification.enisa.europa.eu/publications/eucc-guidelines-cryptography_en 

# Annex L (informative): Relationship between the present document and the requirements of EU Regulation 2024/2847

DRAFT ANNEX L - DO NOT CONSIDER THE CONTENT

The present document has been prepared under the Commission's standardisation request C(2025) 618 final to provide one voluntary means of conforming to the requirements of Regulation (EU) No 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) No 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act).
Once the present document is cited in the Official Journal of the European Union under that Regulation, compliance with the normative clauses of the present document given in table A.1 confers, within the limits of the scope of the present document, a presumption of conformity with the corresponding requirements of that Regulation and associated EFTA regulations.
> NOTE:    The above paragraphs have to be repeated in the Foreword.

The annex shall have a table for a clear indication of correspondence between normative clauses of the standard and the legal requirements aimed to be covered.

**It should be evaluated - on the basis of the legal requirements supported and other information given in a harmonised standard - how detailed correspondence can be indicated between the normative elements of the harmonised standard and the legal requirements aimed to be covered. However, where this correspondence is expressed in too general terms, it could lead to a situation where the Commission cannot assess whether the Harmonised Standard satisfies the requirements, which it aims to cover, and subsequently publication of its references in the OJEU according to Article 10(6) of the Regulation is significantly delayed or is not possible at all.**

# Annex : Change history

| Date       | Version | Information about changes |
|------------|---------|---------------------------|
|&lt;Month year>|   <#>   | &lt;Changes made are listed in this cell> |
|            |         |                           |
|            |         |                           |
|            |         |                           |

<br />

# History

| Version      | Date         | Milestone      |
|--------------|--------------|---------------|
| <Month year> | <#>          | <Changes made>|
|              |              |               |
|              |              |               |