EN-304-617_v0.0.6.md

**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

---

### UC-B11: Desktop Applications with Embedded Browser Navigation (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-1 or DOM-2
- **EXT**: EXT-0 (typically no extension system in embedded context)
- **ENC**: ENC-1
- **LOG**: LOG-2 or LOG-3
- **UPD**: UPD-0 or UPD-1
- **PRO**: PRO-2 (custom protocol handlers)
- **SYS**: SYS-2
- **EMB**: EMB-2 or EMB-3 (mandatory - this is an embedded browser use case)

**Critical Requirements**: EMB-2-REQ-1 through EMB-2-REQ-10 OR EMB-3-REQ-1 through EMB-3-REQ-12, EMB-REQ-1 through EMB-REQ-9, DOM-1-REQ-1 through DOM-1-REQ-9, ENC-1-REQ-1 through ENC-1-REQ-19, LOG-2-REQ-1 through LOG-2-REQ-20, UPD-0-REQ-1 through UPD-0-REQ-24, PRO-2-REQ-1 through PRO-2-REQ-12, SYS-2-REQ-1 through SYS-2-REQ-15

**Special Focus**: EMB-REQ-1 (JavaScript bridge security), EMB-REQ-2 (URL scheme handler validation), EMB-REQ-3 (content source policy), EMB-REQ-8 (host-web boundary), EMB-REQ-9 (custom protocol security), PRO-REQ-3 (protocol handler registration), PRO-REQ-11 (scheme validation)

**Assessment References**: All EMB assessments are critical; PRO-REQ-3, PRO-REQ-11, DOM-REQ-5-9, SYS-REQ-7-15, LOG-REQ-13-16

---

### UC-B12: Super-App Platforms (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-2 or DOM-3 (strict isolation between mini-apps required)
- **EXT**: EXT-0 or EXT-1 (mini-app system replaces traditional extensions)
- **ENC**: ENC-0 or ENC-1 (financial transactions require strictest)
- **LOG**: LOG-3 (comprehensive logging for security and fraud detection)
- **UPD**: UPD-0 or UPD-1 (platform-controlled updates)
- **PRO**: PRO-2 (custom URL schemes for mini-app invocation)
- **SYS**: SYS-2
- **EMB**: EMB-3 (mini-apps are embedded web content with elevated privileges)
- **RDPS**: RDPS-2 (platform services processing sensitive data)

**Critical Requirements**: DOM-2-REQ-1 through DOM-2-REQ-12 OR DOM-3-REQ-1 through DOM-3-REQ-9, EMB-3-REQ-1 through EMB-3-REQ-12, EMB-REQ-1 through EMB-REQ-10, EMB-REQ-19, EMB-REQ-20, LOG-3-REQ-1 through LOG-3-REQ-20, ENC-0-REQ-1 through ENC-0-REQ-23, UPD-0-REQ-1 through UPD-0-REQ-24, PRO-2-REQ-1 through PRO-2-REQ-12, SYS-2-REQ-1 through SYS-2-REQ-15, RDPS-2-REQ-1 through RDPS-2-REQ-18

**Special Focus**: DOM-REQ-9 (cross-origin isolation), DOM-REQ-10 (origin-based access control), DOM-REQ-11 (site isolation), EMB-REQ-1 (JavaScript bridge between platform and mini-apps), EMB-REQ-4 (permission model for mini-apps), EMB-REQ-8 (boundary enforcement), EMB-REQ-19 (mini-app sandboxing), LOG-REQ-13 (security event logging), LOG-REQ-14 (anomaly detection), ENC-REQ-17 (payment data protection)

**Platform-Specific Requirements**: Mini-app validation and review process; platform API permission model; payment system security; shared authentication security; mini-app isolation enforcement; supply chain security for third-party mini-apps; monitoring and behavioral analysis; emergency mini-app revocation capability

**Assessment References**: DOM-REQ-9-12, EMB-REQ-1-20, LOG-REQ-13-16, ENC-REQ-17, PRO-REQ-11, SYS-REQ-7, RDPS-REQ-16-18

---

## B.3 Capability Condition Level Selection Guide

| Use Case Risk | DOM | EXT | ENC | LOG | UPD | PRO | SYS | EMB | RDPS |
|---------------|-----|-----|-----|-----|-----|-----|-----|-----|------|
| Standard | DOM-1 | EXT-1/2 | ENC-1 | LOG-1 | UPD-1 | PRO-1 | SYS-1 | EMB-1 | RDPS-0/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 | RDPS-0/2 |
| Critical | DOM-0/1 | EXT-0 | ENC-0 | LOG-3 | UPD-0 | PRO-0 | SYS-0/1 | EMB-0/1 | RDPS-0/3 |

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

**RDPS Note**: RDPS capability level selection depends on whether remote data processing is used and the sensitivity of data processed. RDPS-0 (no remote processing) is always acceptable and mandatory for air-gapped deployments. When remote processing is used, select RDPS level based on data sensitivity: RDPS-1 for non-sensitive data, RDPS-2 for sensitive data, RDPS-3 for critical data with regulatory requirements.

## 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
- **Section 6.6.5**: RDPS-REQ-1 through RDPS-REQ-60

## B.5 Remote Data Processing Systems (RDPS) Mapping

**RDPS Capabilities** are independent of deployment use cases but apply when browsers employ remote data processing for any functionality. The appropriate RDPS capability level should be selected based on data sensitivity and criticality:

### RDPS-0: No Remote Data Processing (Fully Local Operation)

**Applicable to**:

- **UC-B3**: Kiosks and Shared Terminals (air-gapped deployments)
- **UC-B8**: Critical Infrastructure (air-gapped SCADA/ICS systems)
- Any deployment requiring complete network isolation

**Requirements**: RDPS-0-REQ-1 through RDPS-0-REQ-7

**Assessment References**: RDPS-REQ-52 through RDPS-REQ-58

**Key Characteristics**: Zero network connectivity, all data local-only, no telemetry, no remote authentication, complete offline operation

---

### RDPS-1: Limited Remote Processing (Non-Sensitive Data)

**Applicable to**:

- **UC-B1**: General Purpose Web Browsing (preferences sync, bookmark sync)
- **UC-B2**: Development and Testing Environments (extension sync, settings sync)
- **UC-B10**: Adapted Browsers (non-sensitive preference synchronization)

**Requirements**: RDPS-1-REQ-1 through RDPS-1-REQ-15

**Assessment References**: RDPS-REQ-1 through RDPS-REQ-15

**Key Characteristics**: TLS 1.3+ encryption, certificate validation, graceful offline degradation, rate limiting, non-sensitive data only (configuration, preferences, non-critical bookmarks)

**Data Examples**: UI preferences, theme settings, non-sensitive bookmarks, display configuration, language preferences

---

### RDPS-2: Extended Remote Processing (Sensitive Data)

**Applicable to**:

- **UC-B4**: Financial Services (session state, transaction logs)
- **UC-B5**: Healthcare and Medical Systems (audit logs, anonymized analytics)
- **UC-B6**: E-Government Services (authentication state, encrypted form data)
- **UC-B7**: Enterprise Applications (SSO tokens, policy sync, encrypted data sync)

**Requirements**: All RDPS-1 requirements PLUS RDPS-2-REQ-1 through RDPS-2-REQ-18

**Assessment References**: RDPS-REQ-1 through RDPS-REQ-32, RDPS-REQ-59

**Key Characteristics**: Data encryption at rest, mutual TLS, redundant backups, per-user per-origin access controls, audit logging, integrity verification, replay attack defense, data minimization

**Data Examples**: Authentication tokens, encrypted passwords, financial transaction logs, healthcare audit trails, enterprise policy data, encrypted user documents

**Special Considerations**:

- GDPR compliance required for EU deployments
- Sector-specific regulations for healthcare (UC-B5)
- Financial services regulatory requirements (UC-B4)
- Enterprise data residency requirements (UC-B7)

---

### RDPS-3: Full Remote Processing (Critical Data - Maximum Security)

**Applicable to**:

- **UC-B5**: Healthcare and Medical Systems (patient data, medical records - where remote processing is legally permitted)
- **UC-B6**: E-Government Services (citizen PII, legal documents, classified data)
- **UC-B7**: Enterprise Applications (trade secrets, financial records, strategic data)
- **UC-B8**: Critical Infrastructure (control data, operational parameters - where remote processing is absolutely necessary and properly secured)

**Requirements**: All RDPS-1 and RDPS-2 requirements PLUS RDPS-3-REQ-1 through RDPS-3-REQ-20

**Assessment References**: RDPS-REQ-1 through RDPS-REQ-51, RDPS-REQ-59, RDPS-REQ-60

**Key Characteristics**: End-to-end encryption, hardware-backed keys, high availability with failover, disaster recovery, real-time integrity monitoring, SIEM integration, zero-trust architecture, compliance logging, automated security scanning, incident response procedures, access revocation, transparency reporting, forward secrecy, user notifications, enterprise policy enforcement

**Data Examples**: Medical records, patient health information, classified government data, trade secrets, financial statements, critical infrastructure operational data, personal identifiable information (PII)

**Regulatory Compliance**:

- GDPR Article 32 (Security of Processing) - full compliance required
- eIDAS Regulation (for e-government - UC-B6)
- NIS2 Directive (for critical infrastructure - UC-B8)
- Sector-specific EU regulations (healthcare, financial services)
- ISO 27001/27017/27018 certifications recommended

**Special Considerations**:

- Geographic data residency enforcement required
- Multi-tenant isolation mandatory
- Cryptographic proof of integrity
- 24/7 incident response capability
- Regular penetration testing and security audits
- Documented disaster recovery with tested procedures
- Enterprise administrator security policy controls

---

### RDPS Capability Selection Matrix by Use Case

| Use Case | Recommended RDPS Level | Data Types | Key Controls |
|----------|------------------------|------------|--------------|
| UC-B1 (General Browsing) | RDPS-0 or RDPS-1 | Preferences, bookmarks | Graceful offline, TLS 1.3+ |
| UC-B2 (Development/Testing) | RDPS-1 | Settings, extensions | Sync controls, rate limiting |
| UC-B3 (Kiosks) | RDPS-0 (mandatory) | None (local only) | No remote processing |
| UC-B4 (Financial) | RDPS-2 or RDPS-3 | Tokens, transactions | Encryption at rest, mTLS, audit logs |
| UC-B5 (Healthcare) | RDPS-2 or RDPS-3 | Audit logs, patient data | Sector regulations, E2EE, DR |
| UC-B6 (E-Government) | RDPS-2 or RDPS-3 | Citizen PII, documents | Data residency, zero-trust, compliance logging |
| UC-B7 (Enterprise) | RDPS-2 or RDPS-3 | Enterprise data, policies | Enterprise controls, SIEM, HA |
| UC-B8 (Critical Infrastructure) | RDPS-0 (preferred) or RDPS-3 | Control data | Air-gap preferred; if remote: max security |
| UC-B9 (Security Research) | RDPS-0 or RDPS-1 | Research data | Isolated environments, no sensitive data |
| UC-B10 (Adapted Browser) | Inherit from use case | Depends on deployment | Match upstream + manufacturer obligations |

**Important Notes**:

1. **RDPS-0 is mandatory** for air-gapped deployments (UC-B3 kiosks, UC-B8 critical infrastructure in isolated networks)

2. **RDPS capability levels are additive**: RDPS-2 includes all RDPS-1 requirements; RDPS-3 includes all RDPS-1 and RDPS-2 requirements

3. **Data classification drives RDPS level**: Manufacturers shall classify all remotely processed data and select appropriate RDPS level based on highest sensitivity

4. **Regulatory compliance**: RDPS-3 is recommended for all use cases with regulatory requirements (GDPR, NIS2, eIDAS, sector-specific regulations, etc.)

5. **User control**: For RDPS-1 and above, users should have transparency and control over what data is processed remotely

6. **Enterprise deployments**: UC-B7 should typically use RDPS-2 or RDPS-3 with enterprise policy controls (RDPS-3-REQ-20)

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

## C.1 European Standards and Regulations

The present document is developed in support of the Cyber Resilience Act (CRA) and relates to the following European regulations and directives:

### C.1.1 Cyber Resilience Act (EU) 2024/...

The present document provides security requirements and assessment criteria for browsers as Class I important products under CRA Annex III. It covers all essential cybersecurity requirements defined in CRA Annex I Part 1 (secure development) and Part 2 (vulnerability handling), supporting the harmonization objectives of Standardisation Request M/606.

### C.1.2 General Data Protection Regulation (GDPR) - Regulation (EU) 2016/679

The present document includes requirements for:

- Data minimization in telemetry and logging (Article 5)
- User consent for data processing (Article 7)
- Security of processing (Article 32)
- Data subject rights (Articles 15-22)
- Privacy by design and default (Article 25)

### C.1.3 eIDAS Regulation - Regulation (EU) No 910/2014

Requirements related to:

- Certificate validation and trust (Chapter 5.3 ENC requirements)
- Electronic identification for e-government use cases (UC-B6)
- Trust service providers integration

### C.1.4 NIS2 Directive - Directive (EU) 2022/2555

Security requirements supporting critical infrastructure protection (UC-B8):

- Incident response procedures (RDPS-REQ-45)
- Security monitoring and logging (LOG requirements)
- Risk management and security measures

## C.2 ISO/IEC International Standards

### C.2.1 ISO/IEC 27001 - Information Security Management Systems

Referenced throughout the document for:

- Audit logging and log management (LOG-REQ-12, LOG-REQ-13, LOG-REQ-19)
- Access control implementation (DOM-REQ-6, RDPS-REQ-21)
- Information security controls and risk management
- Compliance auditing and security frameworks
- Recommended certification for RDPS-3 capability (Section 5.9)

### C.2.2 ISO/IEC 27017 - Cloud Services Information Security

Referenced for RDPS (Remote Data Processing Systems) requirements:

- Cloud-specific security controls
- Shared responsibility model
- Recommended certification for RDPS-3 capability

### C.2.3 ISO/IEC 27018 - Protection of PII in Public Clouds

Referenced for RDPS data protection:

- Personal data protection in cloud environments
- Privacy controls and PII handling
- Recommended certification for RDPS-3 capability

### C.2.4 ISO/IEC 27035 - Information Security Incident Management

Referenced for incident response procedures:

- Incident detection and reporting frameworks (RDPS-REQ-45)
- Response procedures and escalation
- Post-incident analysis

### C.2.5 ISO/IEC 29147 - Vulnerability Disclosure

Referenced for vulnerability handling:

- Coordinated vulnerability disclosure (UPD-REQ-8)
- Communication with security researchers
- Disclosure timelines and processes

### C.2.6 ISO 22301 - Business Continuity Management

Referenced for RDPS disaster recovery:

- Business continuity planning (RDPS-REQ-3)
- Recovery objectives (RTO/RPO)
- Disaster recovery procedures (RDPS-REQ-36)

### C.2.7 ISO 8601 - Date and Time Format

Referenced for standardized timestamp formats:

- Log timestamp formatting (LOG-REQ-17)
- Consistent time representation across systems

## C.3 Related ETSI Standards

_No directly related ETSI standards have been identified at the time of publication. Future work may establish relationships with ETSI security standards as they are developed._

## C.4 Relationship to Other Standards Bodies

### C.4.1 W3C Web Standards

The present document builds upon W3C web security standards including:

- Content Security Policy (CSP)
- Cross-Origin Resource Sharing (CORS)
- Subresource Integrity (SRI)
- Web Crypto API
- Permissions API

These W3C standards define the technical mechanisms that browser security requirements are built upon.

### C.4.2 WHATWG Standards

References HTML Living Standard and related specifications for:

- Origin and same-origin policy definitions
- DOM security model
- Web application security features

### C.4.3 IETF Standards

References IETF RFCs for cryptographic and network security:

- TLS 1.3 (RFC 8446)
- Certificate Transparency (RFC 6962)
- HSTS (RFC 6797)
- OAuth 2.0 and related security protocols

## C.5 Industry Security Frameworks

The present document aligns with recognized security frameworks:

### C.5.1 CIS Benchmarks

- Configuration security scanning (RDPS-REQ-42)
- Baseline security configurations
- Hardening guidelines

### C.5.2 NIST Cybersecurity Framework

While not mandatory for EU compliance, NIST standards are referenced for technical guidance on:

- Cryptographic standards (NIST SP 800 series)
- Incident response (NIST SP 800-61)
- Log management (NIST SP 800-92)
- Key management (NIST SP 800-57)

These references provide technical implementation guidance that is internationally recognized and compatible with EU requirements.

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

## D.1 Assets

### D.1.1 Data

_What data is stored on the product?_

### D.1.2 Product functions

_See the functions in Section 4.4._

## D.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._

## D.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_

## D.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 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>|
|              |              |               |
|              |              |               |