EN-304-617.md.backup

<div align="center">
**ETSI EN 304-617 {{VERSION}} ({{YEAR}}-{{MONTH}})**
</div>

![~~CAPTION~~](media/etsi-coverpage-logo.png)
HARMONISED EUROPEAN STANDARD  
CYBER; CRA; <br />
Essential cybersecurity requirements for Browsers 


<div style="text-align: center;">
Reference<br />
&lt;Workitem><br />
Keywords<br />
&lt;keywords><br />

ETSI<br />
650 Route des Lucioles<br />
F-06921 Sophia Antipolis Cedex - FRANCE<br />
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16<br />
Siret N° 348 623 562 00017 - APE 7112B<br />
Association à but non lucratif enregistrée à la<br />
Sous-préfecture de Grasse (06) N° w061004871<br />
</div>



**_Important notice_**

The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI deliverable is the one made publicly available in PDF format on [ETSI deliver](ETSI deliver) repository.

Users should be aware that the present document may be revised or have its status changed, this information is available in the [Milestones listing](Milestones listing).

If you find errors in the present document, please send your comments to the relevant service listed under [Committee Support Staff](Committee Support Staff).

If you find a security vulnerability in the present document, please report it through our [Coordinated Vulnerability Disclosure (CVD)](Coordinated Vulnerability Disclosure (CVD)) program.

**_Notice of disclaimer & limitation of liability_**

The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of experience to understand and interpret its content in accordance with generally accepted engineering or other professional standard and applicable regulations.

No recommendation as to products and services or vendors is made or should be implied.

No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness for any particular purpose or against infringement of intellectual property rights.

In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use of or inability to use the software.

<br />

**_Copyright Notification_**

No part may be reproduced or utilised in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorised by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media.

&copy; ETSI yyyy.

All rights reserved.<br />

</div>

# Contents

<br />

# Intellectual Property Rights

Essential patents

IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations pertaining to these essential IPRs, if any, are publicly available for **ETSI members and non-members** , and can be found in ETSI SR 000 314: _"Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards"_ , which is available from the ETSI Secretariat. Latest updates are available on the [ETSI IPR online database](https://ipr.etsi.org/).

Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.


Trademarks

The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.

**DECT&#8482;**, **PLUGTESTS&#8482;**, **UMTS&#8482;** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP&#8482;**, **LTE&#8482;** and **5G&#8482;** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M&#8482;** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM&#174;** and the GSM logo are trademarks registered and owned by the GSM Association.

# Foreword

> DRAFT FOREWORD - DO NOT CONSIDER THE CONTENT

This draft Harmonised European Standard (EN) has been produced by ETSI Technical Committee Cyber Working Group for EUSR (CYBER-EUSR), and is now submitted for the combined Public Enquiry and Vote phase of the ETSI Standardisation Request deliverable Approval Procedure (SRdAP).

```
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.

Transposition table

The Harmonised Standard shall have appropriate transposition periods specified. A Harmonised Standard confers presumption of conformity when it has been published in the Official Journal of the European Union (OJEU) and transposed by a member state.

The Technical Body may propose different dates to the default ones (3, 6, 18). Technical Bodies who wish to propose different dates are advised to indicate this clearly in the approved committee draft.

| Proposed national transposition dates                          |                                 |
|----------------------------------------------------------------|---------------------------------|
| Date of latest announcement of this EN (doa):                  | 3 months after ETSI publication |
| Date of latest publication of new National Standard            |                                 |
| or endorsement of this EN (dop/e):                             | 6 months after doa              |
| Date of withdrawal of any conflicting National Standard (dow): | 18 months after doa             |

The Technical Body should advise the ETSI Secretariat if the above default national transposition dates are inappropriate for the particular standard.



# Modal verbs terminology

In the present document "**should** ", "**should not** ", "**may** ", "**need not** ", "**will** ", "**will not** ", "**can** " and "**cannot** " are to be interpreted as described in clause 3.2 of the [ETSI Drafting Rules](https://portal.etsi.org/Services/editHelp/How-to-start/ETSI-Drafting-Rules) (Verbal forms for the expression of provisions).

"**must** " and "**must not** " are **NOT** allowed in ETSI deliverables except when used in direct citation.

# Executive summary


Browsers represent one of the most complex and security-critical software products in modern computing, serving as the primary gateway between users and internet resources while processing untrusted content from millions of sources daily. The browser's architecture encompasses multiple interconnected subsystems - including rendering engines, JavaScript/WebAssembly execution environments, network stacks, and extension frameworks, each presenting distinct attack surfaces that shall be defended while maintaining performance, compatibility with legacy web content, and user autonomy.

Unlike traditional security products that can enforce restrictive controls, browsers shall balance protection against an evolving threat landscape with respect for user choice, creating unique challenges where users may deliberately choose to visit malicious sites, install risky extensions, or disable security features. The browser's multi-layered trust model, spanning from the highly privileged browser core through semi-trusted extensions to completely untrusted web content, requires sophisticated isolation mechanisms, granular permission systems, and careful mediation of system resource access. 

Given browsers' ubiquitous deployment across consumer, enterprise, and specialized environments, their role as platforms for Progressive Web Applications, and their position as primary targets for nation-state and criminal actors, establishing proportionate security requirements under the Cyber Resilience Act demands careful consideration of the inherent tensions between security, functionality, performance, and user agency that define the modern web browsing experience.

# Introduction

This European harmonised standard defines cybersecurity requirements applicable to browsers.

This document will provide security requirements and assessment criteria covering all elements defined in CRA Annex I Part 1 and Part 2 for stand alone browsers, as mentioned in CRA Annex III Class I important products.
This work item intends to produce an EN as candidate for harmonisation, under the standardisation request in support of the implementation of the CRA (M/606).

<br />

# 1 Scope

This standard focuses on browsers, both standalone and embedded. Browsers are software products with digital elements that enable end users to access and interact with web content hosted on servers that are connected to local and remote networks.

Within the context of an operating system, browsers are user-applications with a primary function and probable daily use. They are often leveraged as means of accessing remote authentication (single-sign-on) or even as a bridge (deep-link) to another application that has already been installed. In both cases, all systems have the notion of a “default browser” that can then be instrumented by other applications to navigate to a website or perform such an activity.

The activity of browsing can be defined in the following steps:

1. A machine accesses remote resources and source code, such as HTML, JavaScript/WebAssembly, and CSS.
2. This source is represented visually, acoustically, or in some other form.
3. The user interacts with the rendered representation through input and output interfaces, including visual observation, text entry, pointer interaction, or other supported input modalities.

## 1.1	Browser 

### 1.1.1	Standalone

Standalone browsers are applications that fulfil the functions of browsing.

Web browsers are software applications that access, retrieve, and interact with information and resources addressed by URLs. A standalone browser may be used for everyday tasks such as reading email, managing a calendar, or consuming the news. 

Such programs commonly have interfaces for managing multiple websites, browsing history, bookmarks, user identities, passwords, and other settings. 

They can commonly be extended with browser extensions, which are products with digital elements that have the ability to read, store, and modify the websites that users interact with.

### 1.1.2 Embedded

Embedded browsers are browsing services that are integrated into another system or application. 

As such, they are programs using the same baseline technology of browsing but are commonly used for “single purpose” browsing. This means that instead of opening the user’s preferred standalone browser, the hosting application will open an embedded browser to keep the user’s attention. It is not common for a user to be able to change the configuration of an embedded browser.

### 1.1.3 Progressive Web Apps (PWA)

Progressive Web Apps are web applications that can be installed to a user's device from a standalone browser and subsequently operate in a dedicated application-like context.

PWAs leverage browser capabilities including service workers, application manifests, and isolated storage to provide offline functionality, push notifications, and integration with operating system features such as the application launcher and task switcher. When installed, they execute within the browser's process architecture but present themselves to the user as distinct applications with their own windows, icons, and settings.

Unlike traditional web pages, installed PWAs maintain separate configuration contexts from the main browser, including distinct storage partitions, permission grants, and display modes. They may register custom protocol handlers, manage their own cache strategies through service workers, and receive operating system events such as share targets or file handlers. Despite this application-like presentation, PWAs remain fundamentally web applications subject to the same security boundaries and web platform APIs as content rendered in standard browser tabs.

### 1.1.4 Browser Extensions

Browser extensions are third-party software components that integrate with and extend the functionality of standalone browsers.

Extensions operate with elevated privileges compared to standard web content, enabling them to intercept and modify network requests, inject scripts into web pages, access cross-origin resources, interact with browser APIs, and persist data across browsing sessions. They are distributed through vendor-operated extension stores or side-loaded through developer modes, and are subject to varying degrees of review, validation, and ongoing monitoring depending on the browser vendor's policies.

Unlike web applications that execute within the constraints of the same-origin policy, extensions declare their required permissions through manifest files and, once granted, operate with capabilities that span multiple origins and browser contexts. They may consist of background scripts or service workers for persistent logic, content scripts that execute within web page contexts, popup interfaces, options pages, and other components. The security model of extensions creates a unique trust boundary where extensions act as intermediaries between the browser core and web content, requiring careful permission management, isolation mechanisms, and code signing to prevent abuse while enabling legitimate functionality enhancements.

## 1.2 Derivative Browsers and Manufacturer Obligations

A significant proportion of browsers placed on the market are derivative products based on open source browser engines or substantially complete browser implementations. Understanding the manufacturer's obligations for such derivative products is essential to the proportionate application of this standard.

### 1.2.1 Open Source Browser Engines and Derivative Products

Open source browser projects such as Chromium, Gecko (Firefox), and WebKit provide complete or near-complete browser implementations that serve as the foundation for derivative products. These upstream projects are stewarded by organizations that maintain the core rendering engines, JavaScript execution environments, network stacks, and security architectures, but the projects themselves do not constitute products placed on the EU market with CE marking.

When an economic operator takes such an open source project, applies modifications (whether substantial or minor), and places the resulting browser on the market under their own brand or distribution channel, that operator becomes a manufacturer under the Cyber Resilience Act <a name="_ref_i.1">[i.1]</a>. This classification applies regardless of the extent of modification - from minor branding and default configuration changes to substantial feature additions, custom user interfaces, or integration of proprietary services.

### 1.2.2 Spectrum of Derivative Modifications

Derivative browsers exist along a spectrum of modification, each with implications for conformity assessment:

**Minor Modifications**: Browsers that modify only branding elements, default search providers, homepage settings, bundled bookmarks, or visual themes while maintaining the upstream codebase's security architecture, update mechanisms, and core functionality. Examples include rebranded releases for specific markets or partnerships.

**Configuration-Level Modifications**: Browsers that alter default privacy settings, tracking protection levels, extension policies, or feature flags to differentiate the product while preserving the underlying implementation. Such modifications may strengthen or weaken security postures relative to the upstream project.

**Feature Additions**: Browsers that integrate additional capabilities such as built-in VPN services, cryptocurrency wallets, AI assistants, proprietary synchronization services, or vertical-specific toolbars. These additions create new attack surfaces and data processing considerations beyond those present in the upstream project.

**Architectural Modifications**: Browsers that modify process architecture, sandbox implementations, network request routing, certificate validation logic, or other security-critical components. Such changes may fundamentally alter the security properties inherited from the upstream project.