The present document specifies vulnerability handling activities, technical requirements and corresponding assessment criteria for web browsers related to cybersecurity. The products with digital elements in scope, thereafter "the Products":
The present document specifies technical requirements and corresponding assessment criteria for web browsers related to cybersecurity. The products with digital elements in scope, thereafter "the products" are specified within the "technical description" of the "category of product" number <mark>"2"</mark>. by the Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 on the technical description of the categories of important and critical products with digital elements pursuant to Regulation (EU) 2024/2847 of the European Parliament and of the Council. [\[i.2\]](#_ref_i.2), which is as follows:
- are specified within the "technical description" of the "category of product" number <mark>"2"</mark>. by the Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 on the technical description of the categories of important and critical products with digital elements pursuant to Regulation (EU) 2024/2847 of the European Parliament and of the Council. [\[i.2\]](#_ref_i.2); and
> Software products with digital elements that enable end users to access, render, and interact with web content and services hosted on servers that are connected to networks such as the Internet. They typically include a browser engine for interpreting and displaying content written in markup language (e.g. HTML), support for web protocols (e.g. HTTP, HTTPS), the ability to execute scripts and manage user inputs as well as storage of temporary or persistent data from websites (cookies).
- are only covered within the product context described in clause 4.
>
> This category includes but is not limited to standalone applications that fulfil the functions of browsers, embedded browsers intended for integration into another system or application as well as browsers with AI agent integration.
_The first EC assessment results have pointed out that the standards shall cover the full scope of the product category._
The products are only covered within the product context described in clause 4. The present document specifies technical characteristics and methods of assessment for:
-**Standalone web browsers**: standalone applications that fulfill the functions of web browsers
-**Embedded web browsers**: reusable software components which act as a web browser integrated into a larger application
The present document covers those Products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1) Annex I under the conditions identified in annex A of this document.
The present document covers those Products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1) Annex I under the conditions identified in annex A of this document.
<mark>Editor's Note: E-mail from Camille Dornier on 23 Feb 2026: I have asked colleagues from DG GROW regarding the possibility to quote the CRA definitions in standards. In a nutshell, **it is ok to quote the definitions from the CRA legal text** ; but DG GROW advises against quoting normative parts of the legal act as it could lead to misinterpretation. This opens the door to quoting CRA definitions but only definitions, **no other parts of the text**.</mark>
The present document specifies [technical characteristics and methods of assessment] for equipment [or types of equipment]:
1.<equipment type 1>;
1.<equipment type 2>;
1.<etc.>
# 2 References
# 2 References
## 2.1 Normative references
## 2.1 Normative references
@@ -129,6 +124,8 @@ The following referenced documents are not necessary for the application of the
<spanid="_ref_i.4"></span><aname="_ref_i.4">[i.4]</a> prEN 40000-1-1: "Cybersecurity requirements for products with digital elements - Vocabulary" [Version and date to be added upon its publication by CEN CENELEC]
<spanid="_ref_i.4"></span><aname="_ref_i.4">[i.4]</a> prEN 40000-1-1: "Cybersecurity requirements for products with digital elements - Vocabulary" [Version and date to be added upon its publication by CEN CENELEC]
<spanid="_ref_i.5"></span><aname="#_ref_i.5">[i.5]</a> Web Platform Design Principles, World Wide Web Consortium Group Note, 27 January 2026 https://www.w3.org/TR/design-principles/#safe-to-browse
<mark>Editor's Note: The EC advises that the references between verticals should be informative.</mark>
<mark>Editor's Note: The EC advises that the references between verticals should be informative.</mark>
@@ -209,12 +206,42 @@ For the purposes of the present document, the [following] abbreviations [given i
## 4.1 Product Functions
## 4.1 Product Functions
The intended purpose of standalone and embedded web browsers is to access and interact with the shared World Wide Web. This access includes everything from reading the news and online encyclopedias to accessing critical systems related to finance, government, healthcare, etc.
Browsers are general purpose software: When presented with a web browser, including an embedded one, user expectations are generally that they can trust it as their "user agent" to do any internet-related task which they can access -- which, via links and other navigation mechanisms, expands to the whole web.
The breadth of reasonably forseeable uses for all web browsers implies that there are many risks in common across use cases.
## 4.2 Product Architecture
## 4.2 Product Architecture
To access websites and make them available to users, web browsers need components to handle the following:
- Networking (including HTTPS and TLS)
- HTML interpretation and rendering
- CSS layout
- JavaScript and WebAssembly code execution
> NOTE: Java™ is the trade name of a programming language developed by Oracle Corporation.
- Image decoding
- SVG, MathML rendering
- GPU use, both to support rendering of HTML+CSS and for WebGPU
- Multimedia and video conferencing
- Camera, microphone and geolocation
TODO: Describe how these are put together, typical process architectures, include a diagram, etc.
## 4.3 Operational Environment
## 4.3 Operational Environment
### 4.3.1 General description
### 4.3.1 General description
A web browser may be used on any device which supports a user interface and sufficient resources to run the browser. This includes desktop and laptop computers, mobile phones, smart televisions, certain embedded devices, etc.
Different contexts where web browsers are used may have different risk profiles, for example:
- Use of a browser embedded within a social media application, for external links
- Consumer use on a personal computer or smartphone
- "Enterprise" desktop/laptop computers within the context of an undertaking (including critical infrastructure)
### 4.3.2 Physical/Hardware environment
### 4.3.2 Physical/Hardware environment
### 4.3.3 Logical/Software environment
### 4.3.3 Logical/Software environment
@@ -231,13 +258,74 @@ For the purposes of the present document, the [following] abbreviations [given i
<mark>- What recommendation we make for due diligence on integrated components?</mark>
<mark>- What recommendation we make for due diligence on integrated components?</mark>
### 4.4.1 Security functions provided outside the product
Across browsers and operating systems, different choices are made in different contexts about what is provided by the browser and what is implemented in the surrounding operating system and system libraries, with security functions performed at those other levels. For example:
- Some standalone browsers (e.g., on mobile platforms) are implemented with the use of a platform-provided embedded browser, subsuming most security functions
- Networking, including certificate validation and management, selection of algorithms, TLS broadly, etc.
- Image decoding, text rendering and Unicode handling (no inherent security function, but a historical source of exploitable vulnerabilities)
- Integrated password manager (may also be provided via an extension)
- Handling links which may be interpreted as references to native applications, whether via OS-registered origins or custom schemes
- Scoping permission to access camera, microphone, geolocation or other sensitive information
- etc. (This is list is not exhaustive.)
In such cases, when functionality is implemented outside of the browser in such system libraries or operating systems, the responsibility for handling the risk is transferred to this library, following a risk assessment by the browser which integrates the OS/library that this is reasonable.
### 4.4.2 Security functions provided to other components
Web browsers provide a secure, trustworthy environment to render websites, which may be used as part of other products.
The web platform maintains a surface area such that "It should be safe to visit a web page" [i.5]. Going to a website does not grant that website risky capabilities over the user's computer. By contrast, other platforms presenting a direct user interface typically involve either a platform curation step, or some risk being taken on by the user. Many mitigations in Clause 5 relate to ensuring that web browsers meet this guarantee.
This property makes the web an ideal low-risk way to deliver application user interfaces.
## 4.5 Users
## 4.5 Users
Almost all computer users interact with web browsers at some point. This includes:
- General public
- Children, students
- Vulnerable adults
- Users of the web with respect to sensitive data
- Professionals in all fields of work
- Workers in critical infrastructure
- Users with accessibility needs
## 4.6 Use Cases
## 4.6 Use Cases
The use cases may be defined by a combination of the product context elements described in clauses 4.1 to 4.5.
### 4.6.1 Standalone browser use cases
**UC-CONS**: Standalone web browser for individual consumers
- Used for accessing the whole web, including sensitive/critical applications.
- Users are, in general, not educated or aware of cybersecurity issues.
- Installed on mobile phones, desktop and laptop computers, televisions, larger embedded devices, etc.
- Includes flexible settings, including high-risk features like developer mode, etc.
**UC-INST**: Standalone web browser for institutional or enterprise use, including critical infrastructure
- Central IT administration may set "enterprise policy" to configure security-related policies.
- Used in environments which are often taking other sorts of precautions, e.g., at the network/VPN level, physical access, etc.
- May be used to access "internal" websites which may have been developed with more or less attention to security, or which have special authentication needs.
### 4.6.2 Embedded browser use cases
**UC-ETAB**: Browser-like tab component for embedding in a larger application
- Used by embedding applications to enable linking to outside content while encouraging the user to return to the parent application
- Intended to facilitate access to just one website, omitting any UI to enter URLs or searches
- Grants access via links to the rest of the World Wide Web; users may "forget" that they are inside another application
- Typically no settings UI, and no integration into enterprise policy.
- Could share the state with the user's default browser
# 5. Technical requirements for the Products
# 5. Technical requirements for the Products
<mark>Editor's Note:This is the normative clause of the standard, defining the technical requirements to implement the Essential Security Requirements of the CRA regulation. The text of the regulation shall never be copied or interpreted in the standard.</mark>
<mark>Editor's Note:This is the normative clause of the standard, defining the technical requirements to implement the Essential Security Requirements of the CRA regulation. The text of the regulation shall never be copied or interpreted in the standard.</mark>
@@ -728,6 +816,63 @@ The purpose of this assessment case is (the conceptual assessment) whether the p
[^5]:defined in [ACM]
[^5]:defined in [ACM]
# Annex O (informative): Products not handled by this document
(NOTE: This section is informative and may be removed if the EC prefers. Inclusion or omission of use cases in this standard does not affect manufacturers' legal requirement to perform a risk assessment.)
## O.1: Products which are not web browsers
- Platforms providing for the use of web technology which only handle trusted content under the control of the platform provider, such as:
- Products that use web technologies are part of their internal UI
- An embedded HTML renderer for use in an offline ebook reader
- Products which contain a web browser but whose primary purpose is not that of a web browser
- e.g., a social media application which contains an in-app browser tab for following links
- The embedded browser inside the social media app is definitely a browser (if it was distributed to the supply chain as a product). But the overall social media application isn't, and might not be "important" with respect to Annex III of the Cyber Resilience Act.
- Use of web technology without direct end users, e.g., to download websites to build an index to search the web or for automated testing.
## O.2: Products with unhandled risks
Certain products on the market as of the time of this writing, which may be considered to fit within the definition of web browsers, are subject to certain risks for which this document does not contain a treatment.
- Embedded browsers which provide a mechanism for the integrator to give privileged handling of certain first-party content
- Untreated risks: validating the first party content; avoiding privilege escalation from third-party content
- Embedded browsers which contain the capability for the integrator to add additional functionality to websites, e.g., via bridges from script to native APIs
- Untreated risks: ensuring isolation between native code and web content
- Applications of web technology which use a distribution mechanism for content other than navigation to websites, e.g., app stores or mini-app platforms
- Untreated risks: safe curation, distribution of applications; safety of any additional APIs provided to applications which go beyond typical web browser APIs
- Note: this case might be analyzed as out of scope of the definition of web browsers
- Web browsers with AI agent integration, to autonomously perform actions (e.g., navigations, form submissions)
- Untreated risks: information leaks to and across websites, actions may be taken which are not what the user wanted
- The harmonised standard is expected to deliver technical solutions within the generally acknowledged state of the art and not in areas still rapidly evolving.
# Annex V (informative): Guide for derivative web browsers
## V.1 General
A significant proportion of browsers placed on the market are derivative products based on open source browser engines or substantially complete browser implementations. Requirements under the CRA for such "derivative web browsers" are the same as for any other web browser. This section contains some relevant considerations for derivative browsers.
## V.2 Applying Voluntary Security Attestations
The conformity assessment for such derived browsers may make reference to "Security attestation of free and open-source software", per Article 25 of the CRA [i.1]. As of the time of this writing, there is ongoing work at the European Commission and in open-source efforts to define such attestations and how they may be applied.
The hope in the browser context is that such attestations may make it easier to apply this standard, if an "upstream" attestation may be applied to demonstrate some of the requirements in this document.
Vulnerability handling requirements are defined in Annex I part II of [i.1], and explained further in [2]. This section includes notes on how these sections may apply in practice.
Updates from upstream for derivative browsers come in two forms:
-**Rebases**:
- Updating a derivative browser to a newer version from upstream is referred to as a "rebase".
- Some upstream browsers have fast (e.g., monthly) major version release cycles, with a vulnerability handling policy where upstream only ports fixes to a certain window of versions (e.g., a few months).
- If a derivative browser does not "rebase" to a version with such upstream backports, it risks not getting all relevant fixes (if no one else developed the backport).
- The failure to rebase is where the highest security risk from derived browsers exists in practice as of this publication.
-**Security hotfixes**:
- Upstream browsers sometimes release patches against current versions to address especially urgent exploitable vulnerabilities. It is important to distribute these updates promptly, relative to risk.
- Note that, with frequent rebases, the window for such exploits is somewhat limited, as they will be picked up in the rebase.
# History
# History
_The following table will automatically be filled in by the ETSI Secretariat._
_The following table will automatically be filled in by the ETSI Secretariat._
@@ -735,14 +880,6 @@ _The following table will automatically be filled in by the ETSI Secretariat._
