ETSI EN 304 617

Cybersecurity (CYBER); CRA; Cybersecurity requirements for web browsers · vertical pack 0.1.0 · 83 clause-5 requirements · Annex K

INTERIM DRAFT under open consultation — subject to substantial change before publication; approved versions come only from the ETSI Documentation Service. Not cited in the Official Journal: conformance confers NO presumption of conformity today.

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-617 — 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 · Annex K · CRA correspondence · threats · draft gaps · how it's built

Source, license and attribution

Source: https://labs.etsi.org/rep/stan4cra/en-304-617 (the ETSI Labs draft repository), commit f774a5fe, retrieved 2026-09-02.
License: BSD-3-Clause, © ETSI. Redistributed with attribution as the license requires; the verbatim requirement and assessment 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.

Full license text

Copyright 2025 ETSI

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice,
   this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors
   may be used to endorse or promote products derived from this software without
   specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.

How this pack attaches

The pack applies to products classified under the CRA Annex III item “Standalone and embedded browsers” (pack category id: important-1). Attaches to a product whose CRA classification matched the Annex III browsers 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)

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 "2". 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], which is as follows:

> 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).
>
> 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 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] Annex I under the conditions identified in annex A of this document.

Applicability (the draft’s own)

The technical requirements of the present document apply under the product context described in Clause 4, which shall be in accordance with its intended use. The equipment shall comply with all applicable technical requirements of the present document at all times when operating in such product context.

The applicability of the requirements to the Use Cases / Security Profiles are defined below:

Editor's Note: If there is a matrix mapping the use cases to the technical requirements of the standard, it should be inserted in this clause. Alternatively, there can be such a matrix/mapping in each subclause below.

The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.

The 3 use cases

Applicability is declared per use case: the draft defines 3 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.

General Purpose Web Browser Use CaseUC-CONS

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.

Enterprise Browser Use CaseUC-INST

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.

Embedded Browser Use CaseUC-ETAB

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.

Requirement index

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

Id	Requirement (first line)	UC-CONS	UC-INST	UC-ETAB
5.2 — No known exploitable vulnerabilities
REQ-KEV-1	The product shall incorporate only components, including third party and open source elements, for which no known exploitable vulnerabilities exist at the time of release.	●	●	●
REQ-KEV-2	In accordance with the requirement to apply effective and regular tests to the security of the product, the product shall be tested to demonstrate the absence or mitigation of known exploitable vulnerabilities.	●	●	●
REQ-MEM-KEV-1	The web browser's source code that parses untrusted, non-trivial data, shall undergo ongoing automated dynamic analysis to identify vulnerabilities.	●	●	●
REQ-MEM-KEV-2	The product's source code shall undergo ongoing automated static analysis to identify vulnerabilities.	●	●	●
REQ-MEM-KEV-3	The product shall be implemented using programming languages, language features, and/or automation-enforced coding conventions that limit the introduction of memory safety vulnerabilities.	●	●	●
5.3 — Secure by default configuration
REQ-TLS-SBD-1	The product shall be configured by default to reject TLS protocol versions, ciphers and configurations which present high risk to exploitation.	●	●	●
REQ-TLS-SBD-2	The product shall be configured by default with an appropriate trusted root store based on the manufacturer's risk assessment and documented policy.	●	●	●
REQ-EXT-SBD-1	The product shall execute extensions with minimal privileges by default.	●	●	●
REQ-EXT-SBD-2	The product shall execute extensions in an isolated context.	●	●	●
REQ-PWR-SBD-1	The product's technical documentation shall describe all web platform APIs it implements that fall under the definition of a Powerful Web Platform Feature, detailing the specific APIs and the mechanism by which express user permission is obtained before they can be used by a website.	●	●	●
REQ-PWR-SBD-2	The product shall provide a mechanism for users to select the default behaviour when a web page wishes to use a given Powerful Web Platform Feature, which shall at least include denying by default.	●	●	●
5.4 — Secure Updates
REQ-TLS-SU-1	The product's root store shall be kept up to date appropriately, based on the manufacturer's risk assessment and documented policy.	●	●	●
REQ-EXT-SU-1	The product shall support automatic updates of extensions, and before installing an update shall cryptographically verify the update.	●	●	●
REQ-STORE-SU-1	The product shall maintain the validity of data stored to disk across updates.	●	●	●
REQ-STORE-SU-2	The product shall update the Public Suffix List regularly.	●	●	●
5.5 — Authentication and access control
REQ-EXT-AAC-1	The product shall enforce a granular permission model for the extension.	●	●	●
REQ-EXT-AAC-2	The product shall grant an extension only the permissions declared in its manifest and granted in accordance with the product's permission model.	●	●	●
REQ-EXT-AAC-3	The product shall prompt the user with the manifest-declared permissions prior to installation, listing the capabilities and implications of each permission, and allow the user to approve or decline the installation.	●	●	●
REQ-EXT-AAC-4	The product shall allow the user to review and revoke extension access to specific origins after installation.	●	●	●
REQ-EXT-AAC-5	The product shall ensure isolation between the execution and data contexts of different extensions.	●	●	●
REQ-STORE-ACC-1	The product shall store data and enforce access according to the Same Origin Policy.	●	●	●
REQ-STORE-ACC-2	The product shall not share or make data available across browser profiles.	●	●	●
REQ-STORE-ACC-3	The product shall enforce Same Origin Policy access control for storage data outside rendering processes.	●	●	●
REQ-SOP-AAC-1	The product shall deny access in one origin to all parts of another origin, except as defined in the user documentation.	●	●	●
REQ-SOP-AAC-2	The product shall isolate origin-specific data such as cookies, Web Storage, IndexedDB and any other storage, ensuring it's not available to any other origin, except through protocol-determined methods.	●	●	●
REQ-PWR-AAC-1	The product shall require express user permission before allowing a web page to use Powerful Web Platform Features.	●	●	●
5.6 — Confidentiality
REQ-TLS-CON-1	The product shall support TLS versions and configurations indicated as "recommended" (R) of the ENISA Agreed Cryptographic Methods [1], and it may support TLS versions and configurations indicated as "legacy" (L).	●	●	●
REQ-TLS-CON-2	The web browser shall check the full validity of certificate chain through to the root, including for expiration.	●	●	●
REQ-TLS-CON-3	The product shall warn or obstruct the user from interacting with content served over insecure connections, including expired certificates and insecure TLS configurations.	●	●	●
REQ-TLS-CON-4	The product shall implement appropriate technologies to promote or require the use of HTTPS rather than HTTP.	●	●	●
REQ-TLS-CON-6	The web browser shall have a mechanism to respond to the revocation or loss of trust of CA certificates.	●	●	●
REQ-EXT-CON-1	The product shall prevent secrets stored by extensions from being read by other extensions or by web content.	●	●	●
REQ-STORE-CON-1	The product shall not send third-party cookies by default. They may be supported consistent with the `Partitioned` attribute.	●	●	●
REQ-STORE-CON-2	The product shall make use of OS access control, encryption methods or other mechanisms to ensure confidentiality of disk-stored data.	●	●	●
REQ-STORE-CON-3	The product shall store browser cache data such that they are keyed to both top-level site and resource.	●	●	●
REQ-SOP-CON-1	The product shall only allow scripts to access the body of a cross-origin HTTP response where the source origin has opted to allow access by the requesting origin.	●	●	●
REQ-SOP-CON-2	Where the product allows cross-origin embedding of a resource in documents, the product shall limit information about that resource as specified in the technical documentation.	●	●	●
5.7 — Integrity
REQ-EXT-INT-1	The product shall cryptographically verify extensions before installation and update.	●	●	●
REQ-PWR-INT-1	The product shall protect permission prompts against manipulation by the web page.	●	●	●
REQ-PWR-INT-2	The product shall only enable Powerful Web Platform Features for use within Secure Contexts.	●	●	●
5.8 — Data Minimisation
REQ-PWR-DM-1	Powerful Web Platform Feature permissions shall be origin-scoped by default, with broader scoping permitted only via express user action, or opt-in by the origins.	●	●	●
REQ-PWR-DM-2	Powerful Web Platform Feature permissions decisions shall apply to each Browser Profile separately.	●	●	●
5.9 — Availability Protection
REQ-AP-1	The web browser shall take steps to reduce the risk that errors or crashes in one website running in one tab cause other, unrelated tabs to crash.	●	●	—
REQ-AP-2	The web browser shall take steps, on a best-effort basis, to save the state of running websites such that they can be restored later following an incident.	●	●	—
REQ-EXT-AP-1	The product shall make the best effort to prevent the ability of an extension to make the product unavailable.	●	●	●
REQ-ISO-AP-1	The product shall take steps to reduce the risk that errors or crashes in one website running in one tab cause other, unrelated tabs to crash.	●	●	●
REQ-ISO-AP-2	The product shall take steps, on a best-effort basis, to save the state of running websites such that they can be restored later following an incident.	●	●	●
REQ-STORE-AP-1	The product shall retain data stored to disk in case of a crash and make it available upon browser restart.	●	●	●
5.10 — Impact Minimisation
REQ-IM-1	The web browser's technical documentation shall describe all network protocols implemented by the browser, or include references to such protocols. These protocols shall either be industry standards (preferably), or be described with similar technical detail to industry standards.	●	●	●
REQ-EXT-IM-1	If the product is running with elevated system privileges, extensions will be prevented from executing with those elevated privileges.	●	●	●
REQ-EXT-IM-2	The product shall permit extensions to communicate with native applications only when declared in the extension manifest and the native application is configured according to the product requirements for doing so.	●	●	●
REQ-EXT-IM-3	The product shall not permit an extension to initiate connections to services on the loopback interface (e.g., `localhost` or `127.0.0.1`) unless localhost access is declared in the extension manifest.	●	●	●
REQ-ISO-IM-1	The product's technical documentation shall describe all public network protocols implemented by the product, or include references to such protocols. These protocols shall be described in publicly available specifications, or be described with sufficient technical detail to permit an independent implementation.	●	●	●
REQ-PWR-IM-1	The product shall deny cross-origin iframes access to Powerful Web Platform Features by default.	●	●	●
5.11 — Minimisation of Attack Surfaces
REQ-MAS-1	The web browser's technical documentation shall describe all web-exposed interfaces, or include references to such descriptions. These interfaces shall either be industry standards (preferably), or be described with similar technical detail to industry standards.	●	●	●
REQ-MAS-2	The web browser shall apply fuzz testing to web-exposed interfaces including HTML, CSS, JavaScript, WebAssembly, HTTP and TLS, as well as APIs, headers, options, etc exposed within those interfaces.	●	●	●
REQ-EXT-MAS-1	The product's extension APIs shall be documented, and the documentation shall specify for each API the purpose, inputs and outputs, permissions required, its security-related behaviour, and the platforms the API is available on.	●	●	●
REQ-EXT-MAS-2	The product shall support enterprise policy controls allowing administrators to disable the extension feature entirely, or specify an allow-list of extensions.	—	●	—
REQ-EXT-MAS-3	The product shall enforce the scope of extension resources available to web content, as declared in the manifest.	●	●	●
REQ-ISO-MAS-1	The product's technical documentation shall describe all web-exposed interfaces, or include references to such descriptions. These interfaces shall be described in publicly available specifications, or be described with sufficient technical detail to permit an independent implementation.	●	●	●
REQ-SOP-MAS-1	The product shall enforce restrictions from a source origin on how its resources may be used across origins, as defined in the user documentation.	●	●	●
REQ-MEM-MAS-1	The web browser shall use operating system functionality to restrict the capabilities and privileges of architectural components of the web browser.	●	●	●
5.12 — Exploitation Mitigation Mechanisms
REQ-EMM-1	The web browser shall separate certain web browser components from each other to reduce the scope of exploits.	●	●	●
REQ-EMM-2	The web browser shall isolate different sites from each other, including from side-channel attacks.	●	●	●
REQ-EMM-3	The web browser shall reduce the privileges of its various components with respect to the operating system to the level required to perform their tasks.	●	●	●
REQ-EXT-EMM-1	The product shall enforce a Content Security Policy for extension pages and scripts injected into web content.	●	●	●
REQ-EXT-EMM-2	The product shall validate an extension's manifest before installation and update, reject manifests that are malformed or contain disallowed content, and ignore unrecognised optional fields.	●	●	●
REQ-ISO-EMM-1	The product shall separate certain product components from each other to reduce the scope of exploits, using process isolation or similar industry standard mitigations.	●	●	●
REQ-ISO-EMM-2	The product shall isolate different sites from each other, including from side-channel attacks.	●	●	●
REQ-ISO-EMM-3	The product shall reduce the privileges of its various components with respect to the operating system to the level required to perform their tasks.	●	●	●
REQ-MEM-EMM-1	The web browser shall include runtime assertions as to the correctness of program state, which fail safely when violated.	●	●	●
REQ-MEM-EMM-2	The web browser shall use compiler features designed to reduce the risk of exploitation.	●	●	●
REQ-MEM-EMM-3	The web browser shall use mitigation technologies provided by the operating systems and/or hardware on which the web browser is designed to run.	●	●	●
5.13 — Logging and Monitoring
REQ-TLS-LOG-1	The product shall present a user interface giving visibility into the security properties of the connection, including the origin.	●	●	●
REQ-EXT-LOG-1	The product shall provide the user the ability to identify which user-installed extensions are currently running, and the permissions in effect for each.	●	●	●
REQ-STORE-LOG-1	The product shall provide an interface for viewing information about stored data at a granularity of site or narrower (e.g. origin).	●	●	●
REQ-PWR-LOG-1	The product shall provide a user interface listing the Powerful Web Platform Features granted or denied to the web page being displayed.	●	●	●
5.14 — Data Removal and Transparency
REQ-TLS-DRT-1	The product shall make available functionality to reset TLS-related functionality to the initial safe settings, including selection of algorithms and protocol versions, root certificates, and any other relevant properties.	●	●	●
REQ-EXT-DRT-1	The product shall enable the removal of individual extensions, which shall delete all data associated with the extension, and revoke all permissions granted to it.	●	●	●
REQ-STORE-DRT-1	The product shall ensure when storage data is deleted, it uses appropriate APIs that ensure the data is deleted from the underlying storage device.	●	●	●
REQ-STORE-DRT-2	The product shall provide reset functionality that removes all stored data across all sites and browser profiles.	●	●	●
REQ-STORE-DRT-3	The product shall have a user interface for deleting storage at a granularity of site or narrower (e.g. origin).	●	●	●
REQ-PWR-DRT-1	The product shall provide a user interface allowing revocation of previously granted permissions for Powerful Web Platform Features.	●	●	●
5.15 — Vulnerability Handling
Annex K — cryptography
K.1.1	The product shall, by default, use State-of-the-Art cryptography algorithms listed in (CRY-SOTA), to be used for the supported security mechanism of the product where applicable.	Conditional — see text
K.2	Where applicable the product shall by default be prepared to update cryptographic algorithm used for the supported security mechanism of the product to maintain when there are indications that the used cryptographic algorithm will not stay SOTA anymore within the intended lifetime of the product.	Conditional — see text

● = required for that use case · — = not required. Use cases: UC-CONS General Purpose Web Browser Use Case · UC-INST Enterprise Browser Use Case · UC-ETAB Embedded Browser Use Case. Annex K entries are conditional on the product’s use of cryptographic mechanisms, not on the use case.

5.2 — No known exploitable vulnerabilities

Proposed ESR code: KEV

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (a).

> NOTE: It is proposed that a cross-vertical task force could work on the technical requirements to be included in this clause.

REQ-KEV-1 — The product shall incorporate only components, including third party and open source elements,…Clause 5.2

Requirement (verbatim from the interim draft)

The product shall incorporate only components, including third party and open source elements, for which no known exploitable vulnerabilities exist at the time of release.

Note: The manufacturer may relay on documentation in the form of an Software Bill of Materials (SBOM) as well as reasoning of why known vulnerabilities are not exploitable under the applicable, expected operational environment.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-KEV-2 — In accordance with the requirement to apply effective and regular tests to the security of the…Clause 5.2

Requirement (verbatim from the interim draft)

In accordance with the requirement to apply effective and regular tests to the security of the product, the product shall be tested to demonstrate the absence or mitigation of known exploitable vulnerabilities.

Note: To demonstrate compliance, the manufacturer may rely on manual security testing (e.g., penetration testing), automated vulnerability scanners, or a combination of both, depending on what is most comprehensive and technically feasible for the product's technology stack.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-MEM-KEV-1 — The web browser's source code that parses untrusted, non-trivial data, shall undergo ongoing au…Clause 5.2

Requirement (verbatim from the interim draft)

The web browser's source code that parses untrusted, non-trivial data, shall undergo ongoing automated dynamic analysis to identify vulnerabilities.

Example: Code that parses media files is subjected to fuzz testing in an environment that enables the detection of memory safety errors, such as LLVM sanitisers.

Objective

The manufacturer conducts ongoing automated dynamic analysis to identify vulnerabilities in the web browser.

Preparation

- Documentation describing how code is selected to undergo automated dynamic analysis.
- Documentation describing how, and how often, the automated dynamic analysis is conducted.
- Documentation describing a methodology for measuring and improving the code coverage of their dynamic analysis tools over time.
- Code coverage reports.
- A sample of bug tracker entries generated by each dynamic analysis technique described in the documentation.

Activities

The following steps are to be carried out in order:

Review the documentation.
Review the code coverage reports.
Review the bug tracker entries.

Verdict

- Pass:
    - The documentation describes a methodology for how code is selected to undergo automated dynamic analysis.
    - The documentation describes one or more dynamic analysis techniques and how they are automated and integrated into the web browser's software development lifecycle.
    - The documentation describes a robust methodology for measuring and improving the code coverage of their dynamic analysis tools over time.
    - Code coverage reports demonstrate that the dynamic analysis achieves the coverage targets defined in the manufacturer's methodology, or show documented progress toward those targets.
    - The bug tracker entries show evidence of being filed in an automated fashion as described in the documentation.
    - The bug tracker entries describe identified vulnerabilities.
    - The bug tracker entries show the identified vulnerabilities have been fixed.
- Fail:
    - Any of the above are not fulfilled.

Evidence the standard asks for

Log of documentation and bug tracker entry review.

REQ-MEM-KEV-2 — The product's source code shall undergo ongoing automated static analysis to identify vulnerabi…Clause 5.2

Requirement (verbatim from the interim draft)

The product's source code shall undergo ongoing automated static analysis to identify vulnerabilities.

Example: Via LLM code analysis, static application security testing tools.

Objective

The manufacturer conducts ongoing automated static analysis to identify vulnerabilities in the web browser.

Preparation

- Documentation describing the automated static analysis that is conducted.
- A sample of bug tracker entries generated by each static analysis technique described in the documentation.

Activities

The following steps are to be carried out in order:

1. Review the documentation.
2. Review the bug tracker entries.

Verdict

- Pass:
    - The documentation describes one or more static analysis techniques and how they are automated and integrated into the web browser's software development lifecycle.
    - The bug tracker entries show evidence of being filed in an automated fashion as described in the documentation.
    - The bug tracker entries describe identified vulnerabilities.
    - The bug tracker entries show the identified vulnerabilities have been fixed.
- Fail:
    - Any of the above are not fulfilled.

Evidence the standard asks for

Log of documentation and bug tracker entry review.

REQ-MEM-KEV-3 — The product shall be implemented using programming languages, language features, and/or automat…Clause 5.2

Requirement (verbatim from the interim draft)

The product shall be implemented using programming languages, language features, and/or automation-enforced coding conventions that limit the introduction of memory safety vulnerabilities.

Example: Via the use of memory safe languages, bounds checked container classes, restrictions on the use of raw pointers.

Objective

The web browser's source code is hardened against the introduction of memory safety vulnerabilities.

Preparation

- Documentation describing the techniques the manufacturer uses to limit the introduction of memory safety vulnerabilities into the web browser.
- Documentation describing how those methods are applied to the architectural components of the web browser.
- For architectural components to which those methods are not applied, documentation describing the mitigations in place to reduce the risk of memory safety vulnerabilities from being successfully exploited.
- Documentation describing the policies by which those methods are applied to the web browser's software development lifecycle.
- Relevant software development lifecycle artefacts, such as design documents, bug tracker entries, security review outcomes.
- The web browser's source code.

Activities

The following steps are to be carried out in order:

Review the documentation.
For each of the methods used to limit the introduction of memory safety vulnerabilities, confirm via spot checks of the source code that the method is applied in accordance with the documentation.
Confirm the relevant software development lifecycle policies are being followed via spot checks of artefacts.

Verdict

- Pass:
    - The documentation describes methods that limit the introduction of memory safety vulnerabilities.
    - The documentation maps those methods to the architectural components of the web browser.
    - The mitigations applied to relevant architectural components convincingly reduce the risk of memory safety vulnerabilities from being successfully exploited.
    - The relevant software development lifecycle policies are being followed.
- Fail:
    - Any of the above are not fulfilled.

Evidence the standard asks for

Log of documentation, source code, and artefact review.

5.3 — Secure by default configuration

Proposed ESR code SBD

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (b).

REQ-TLS-SBD-1 — The product shall be configured by default to reject TLS protocol versions, ciphers and configu…Clause 5.3

Requirement (verbatim from the interim draft)

The product shall be configured by default to reject TLS protocol versions, ciphers and configurations which present high risk to exploitation.

Editor's note: "high risk to exploitation" is ok to say? and should we say "reject or warn" instead of "reject". See also REQ-TLS-CON-3.

Editor's note: This requirement might be implied by Annex K. TODO: Research this interpretation and delete if redundant.

Objective

The product is configured by default to reject TLS protocol versions, ciphers and configurations which present high risk to exploitation.

Preparation

- Install the product from scratch, or reset it to its default settings.
- Configure a web server to expose websites served with several protocol versions, ciphers or configurations which present a high risk to exploitation.

Activities

The following steps are to be carried out in order:

1. Navigate to each website and observe how it loads.

Verdict

- Pass: Each navigation attempt to the vulnerable website is blocked by the product.
- Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Logs or screenshots showing the product's response to the navigation.

REQ-TLS-SBD-2 — The product shall be configured by default with an appropriate trusted root store based on the…Clause 5.3

Requirement (verbatim from the interim draft)

The product shall be configured by default with an appropriate trusted root store based on the manufacturer's risk assessment and documented policy.

Applicability

Web browsers which maintain their own root store, rather than using the OS's root store.

Objective

The product is configured by default with an appropriate trusted root store based on the manufacturer's risk assessment and documented policy.

Preparation

- Install the product from scratch, or reset it to its default settings.
- Locate the technical documentation indicating the product's trusted root store policy.
- Prepare a web server with TLS signed from a trusted root.

Activities

The following steps are to be carried out in order:

1. Check that the trusted root policy exists
2. Navigate to the website and observe the results

Verdict

- Pass:
  - The trusted root policy exists
  - Navigating to the trusted site succeeds
- Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Logs or screenshots showing the product's response to the navigation
Root store policy and listing of trusted roots

REQ-EXT-SBD-1 — The product shall execute extensions with minimal privileges by default.Clause 5.3

Requirement (verbatim from the interim draft)

The product shall execute extensions with minimal privileges by default.

Example: The extension execution process runs with no greater operating system privileges or capabilities than are required for the extension execution context.

Editor's note: Could home in MAS? or IM?

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: extensions execute at full product privilege, or successfully invoke privileged browser or OS APIs.

Preparation

- A test extension declaring no permissions.
- Tools for inspecting processes on the operating system.
- Code executing privileged browser and OS APIs from inside the extension.

Activities

The following steps are to be carried out in order:

Install the test extension
Inspect the OS-level process the product runs the extension in, record privilege level
Inspect the log of the extension's attempt to run privileged APIs

Verdict

- Pass:
  - OS privilege level of the extension process is less than the product process.
  - The extension invocation of privileged APIs failed.
- Fail:
  - OS privilege level of the extension process equals the product process, or the extension's invocation of privileged APIs succeeded.
  - The extension escalates privilege at runtime via a privileged API not enumerated by activities.
  - The extension is initially low-privilege but escalates after the inspection point.

Evidence the standard asks for

Process inspection log.
Extension console log.

REQ-EXT-SBD-2 — The product shall execute extensions in an isolated context.Clause 5.3

Requirement (verbatim from the interim draft)

The product shall execute extensions in an isolated context.

Editor's note: This covers the default configuration - the exploitation mitigation is covered in section 5.12.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: an extension reads or modifies state belonging to the product, a loaded web page, or the operating system.

Preparation

- Product private state is selected, such as a unique string, or a configuration value.
- A text file on the operating system, with test data.
- A web page loaded in the product, with test data.
- A test extension declaring no permissions, and executing attempts to read and modify state in the product, the loaded web page, and the operating system.
- Console log access.

Activities

The following steps are to be carried out in order:

1. Install the test extension
2. Load a web page in the product

Verdict

- Pass:
  - Product private state data access was denied.
  - File system text file access was denied.
  - Web page test data access was denied.
- Fail:
  - Cross-context state access was possible in the product, the loaded web page, or the operating system.

Evidence the standard asks for

Console log output from the test extension demonstrated state access or denial.

REQ-PWR-SBD-1 — The product's technical documentation shall describe all web platform APIs it implements that f…Clause 5.3

Requirement (verbatim from the interim draft)

The product's technical documentation shall describe all web platform APIs it implements that fall under the definition of a Powerful Web Platform Feature, detailing the specific APIs and the mechanism by which express user permission is obtained before they can be used by a website.

Objective

The Powerful Web Platform Features supported by the product are documented.

Preparation

- The product's technical documentation.

Activities

-  Review the documentation.

Verdict

- Pass:

    - The product's technical documentation correctly lists the Powerful Web Platform Features supported by the product.
    - For each Powerful Web Platform Feature listed, the mechanism by which express user permission is obtained is detailed.

- Fail:
    - Any of the above are not fulfilled.

Evidence the standard asks for

Log of documentation review.

REQ-PWR-SBD-2 — The product shall provide a mechanism for users to select the default behaviour when a web page…Clause 5.3

Requirement (verbatim from the interim draft)

The product shall provide a mechanism for users to select the default behaviour when a web page wishes to use a given Powerful Web Platform Feature, which shall at least include denying by default.

Objective

The product provides a mechanism for users to configure default behaviour when a web page requests to use a Powerful Web Platform Feature.

Preparation

- The product installed from scratch, or reset to its default settings.
- Test web page or pages that exercises every Powerful Web Platform Feature identified in the product's technical documentation.

Activities

The following steps are to be carried out in order:

Locate the product's UI that allows configuring the default behaviour of individual Powerful Web Platform Features.
Verify the existence of options to deny or block access by default to every Powerful Web Platform Features supported by the product.
For each Powerful Web Platform Feature, set the default behaviour to block or deny.
Navigate to the test web page or pages and trigger the request to access every Powerful Web Platform Feature.

Verdict

- Pass:
    - The product settings provide an option to individually deny access to all supported Powerful Web Platform Features by default.
    - Applying the setting automatically blocks the test web page's access to Powerful Web Platform Features without presenting a permission prompt to the user.
- Fail:
    - The deny-by-default option does not exist.
    - Any Powerful Web Platform Feature is still accessible, or still prompts the user despite the deny-by-default setting being applied.

Evidence the standard asks for

Screenshots of the settings UI presenting the option.
Console logs and/or UI captures from the test web page showing the denied request.

5.4 — Secure Updates

Proposed ESR code: SU

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (c).

REQ-TLS-SU-1 — The product's root store shall be kept up to date appropriately, based on the manufacturer's ri…Clause 5.4

Requirement (verbatim from the interim draft)

The product's root store shall be kept up to date appropriately, based on the manufacturer's risk assessment and documented policy.

Applicability

Web browsers which maintain their own root store, rather than using the OS's root store.

Objective

The product's root store is kept up to date in accordance with the documented policy.

Preparation

- Install the product from scratch, or reset it to its default settings.
- Locate the documented policy describing how and when the trusted root store is updated.
- Capture the initial trusted root store contents.

Activities

The following steps are to be carried out in order:

Exercise the documented root store update mechanism (e.g., product update, separate channel).
Capture the trusted root store contents after the update.
Compare the change against the documented policy.

Verdict

- Pass:
    - The documented update mechanism functions as documented
    - The resulting change to the root store is consistent with the documented policy.
- Fail: Either of the above are not fulfilled.

Evidence the standard asks for

Documented root store update policy.
List of trusted roots before and after the update.

REQ-EXT-SU-1 — The product shall support automatic updates of extensions, and before installing an update shal…Clause 5.4

Requirement (verbatim from the interim draft)

The product shall support automatic updates of extensions, and before installing an update shall cryptographically verify the update.

Applicability

Extensions installed via the product's extension distribution channel. Extensions installed by enterprise policy, by the developer as unpacked extensions, or sideloaded directly by the user are out of scope of this requirement.

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

The product supports automated updates of extensions, and cryptographically verifies extension updates prior to installation.

Preparation

- A correctly signed test extension installed via the product's extension distribution channel.
- Update variations of the test extension: signed correctly, signed incorrectly, unsigned, and malformed.
- A test extension update server.

Activities

The following steps are to be carried out in order:

Install the test extension.
Configure the update server with an update variation.
Perform update per product documentation.
Repeat steps 2-3 with each variation.

Verdict

- Pass:
  - Correctly signed update is installed.
  - All other variations are not installed.
- Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Product user interface per the documentation, showing the update status for an extension.

REQ-STORE-SU-1 — The product shall maintain the validity of data stored to disk across updates.Clause 5.4

Requirement (verbatim from the interim draft)

The product shall maintain the validity of data stored to disk across updates.

Objective

Assess whether the product maintains the validity of data stored to disk across updates.

Preparation

- Reset browser to factory default settings.
    - Prepare tooling to initiate an update.
    - Prepare tooling that will provide visibility into data stored in the browser.
    - Load data into browser to cover available storage mechanisms, including LocalStorage, Cookie storage and IndexedDB.

Activities

Making use of tooling, verify the data that has been added to storage.
Perform the update of the browser.
Verify whether the data is available in storage after the update.

Verdict

- Pass:
        - The data is available prior to browser update.
        - The data available subsequent to browser update is identical.
    - Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Screenshot(s) or log output from tooling to demonstrate each verdict

REQ-STORE-SU-2 — The product shall update the Public Suffix List regularly.Clause 5.4

Requirement (verbatim from the interim draft)

The product shall update the Public Suffix List regularly.

Objective

Assess whether the product updates the public suffix list regularly.

Preparation

- Technical documentation containing public suffix list update policy.
    - Browser with out-of-date public suffix list, with known missing suffix.
    - Identify methodology or tooling to test Public Suffix List entries, e.g.
        - Set a cookie at the PSL level, or
        - Tooling to inspect and output PSL.

Activities

Verify state of the missing PSL suffix.
Await update according to policy.
Verify the updated state of the missing PSL suffix.

Verdict

- Pass:
        - Testing initially shows known-missing entry as not present in internal list of eTLDs.
        - After update period, testing shows known-missing entry is present in internal list of eTLDs.
    - Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Screenshot(s) or log output from tooling to demonstrate each verdict

5.5 — Authentication and access control

Proposed ESR code: AAC

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (d).

REQ-EXT-AAC-1 — The product shall enforce a granular permission model for the extension.Clause 5.5

Requirement (verbatim from the interim draft)

The product shall enforce a granular permission model for the extension.

Example: Permissions are decomposed into capability groupings rather than a single all-or-nothing grant.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

An extension receives the capabilities it requests but no more, and in capability-specific granularity.

Preparation

- Documentation of extension capabilities, and test extensions declaring each declaring a permission and exercising it, for a random sample of available capabilities.

Activities

The following steps are to be carried out in order:

1. Install extension, and execute the capability
2. Repeat for each extension

Verdict

- Pass:
  - Exercise of the capability in the extension was confirmed.
- Fail:
  - The extension was not able to exercise the capability.

Evidence the standard asks for

Product user interface per supplied documentation.
Console logs of extension execution.

REQ-EXT-AAC-2 — The product shall grant an extension only the permissions declared in its manifest and granted…Clause 5.5

Requirement (verbatim from the interim draft)

The product shall grant an extension only the permissions declared in its manifest and granted in accordance with the product's permission model.

Note: Some permissions are considered low-impact and auto-granted without an explicit user-visible prompt. The user-prompt requirement is covered separately by REQ-EXT-AAC-3.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: an extension exercises a capability without manifest declaration, or beyond what the permission model grants (manifest/model bypass).

Preparation

- Product documentation of the permission model, identifying which permissions are auto-granted and which require an explicit user grant.
- Test extension A: declares one auto-granted permission and one user-grant permission, with code exercising both, instrumented to log access.
- Test extension B: declares the user-grant permission, with code exercising it, instrumented.
- Test extension C: does not declare the user-grant permission but contains code attempting to exercise it, instrumented.

Activities

The following steps are to be carried out in order:

Install extension A, completing the product's normal install flow including any user-grant step for the declared permission.
Install extension B, and at the user-grant step, decline.
Install extension C.
For each installed extension, exercise the instrumented code and record which capabilities were reached.

Verdict

- Pass:
  - Extension A exercises both the auto-granted and the user-granted capabilities.
  - Extension B cannot exercise the capability for which the user declined the grant.
  - Extension C cannot exercise the undeclared capability.
- Fail:
  - An extension exercises a capability not declared in its manifest.
  - An extension exercises a capability the permission model did not grant.
  - The product surfaces an auto-grant for a permission not declared in the manifest.

Evidence the standard asks for

Extension console logs and test extension instrumentation.
Product permission-model documentation referenced for the auto-grant / user-grant classification.

REQ-EXT-AAC-3 — The product shall prompt the user with the manifest-declared permissions prior to installation,…Clause 5.5

Requirement (verbatim from the interim draft)

The product shall prompt the user with the manifest-declared permissions prior to installation, listing the capabilities and implications of each permission, and allow the user to approve or decline the installation.

Applicability

Extensions installed via the product's extension distribution channel. Extensions installed by enterprise policy, by the developer as unpacked extensions, or sideloaded directly by the user are out of scope of this requirement.

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: granted capabilities do not match the user's approve-or-decline decision; for example, a capability is available after the user declined.

Preparation

- Test extension with declared permissions and exercising code instrumented to log access to capability of the permission being tested.

Activities

The following steps are to be carried out in order:

Install test extension
Capture user interface, confirm declared permissions are visibly prompted
Accept, and confirm
Repeat process for second extension, but decline

Verdict

- Pass:
  - In both cases, the permissions requested and clearly visible and the user is presented with a decision to grant or decline.
  - In the approve case, the extension is able to exercise the capability.
  - In the decline case, the extension cannot exercise the capability.
- Fail:
  - The resulting capability access by the extension does not match what was granted by the user.
  - The user dismisses the prompt without an explicit choice and the install proceeds with a default outcome.
  - The prompt appears after install has begun.

Evidence the standard asks for

User interface captures.
Extension console logs.

REQ-EXT-AAC-4 — The product shall allow the user to review and revoke extension access to specific origins afte…Clause 5.5

Requirement (verbatim from the interim draft)

The product shall allow the user to review and revoke extension access to specific origins after installation.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: an extension retains origin access after the user revokes it (revocation bypass).

Preparation

- Test extension with declared and approved access to one or more websites.

Activities

The following steps are to be carried out in order:

Install the test extension, approving access to the requested sites
After install, view the extension permissions user interface
Use the extension to access the origin
If the origin requested is listed, revoke it
Use the extension to access the origin

Verdict

- Pass:
  - The extension install user interface shows the correct origin.
  - The extension permissions user interface shows the correct origin.
  - The extension is able to access the origin when granted, or not when declined.
  - Origin access is revocable in the extension management user interface.
  - After revocation, the extension can no longer access the origin.
- Fail:
  - After revocation, the extension can still access the origin.
  - Revocation is reported in the UI but takes effect only after browser restart.
  - Active sessions and in-flight requests retain access despite revocation.

Evidence the standard asks for

Product user interface for extension install and management.
Extension console log.

REQ-EXT-AAC-5 — The product shall ensure isolation between the execution and data contexts of different extensi…Clause 5.5

Requirement (verbatim from the interim draft)

The product shall ensure isolation between the execution and data contexts of different extensions.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: one extension reads another extension's data or invokes its functions (cross-extension breach).

Preparation

- Install two test extensions.
- The first writes data to storage and implements a background function.
- The other attempts to access the data and call the function.

Activities

The following steps are to be carried out in order:

Install both extensions
Validate that the first extension wrote its data and that its function loaded
Attempt to read the storage and invoke the function from the other extension

Verdict

- Pass:
  - The second extension cannot access the data or invoke the function of the first.
- Fail:
  - The second extension can access the data or invoke the function of the first.

Evidence the standard asks for

Extension console log.

REQ-STORE-ACC-1 — The product shall store data and enforce access according to the Same Origin Policy.Clause 5.5

Requirement (verbatim from the interim draft)

The product shall store data and enforce access according to the Same Origin Policy.

Objective

Assess whether the product presents stores and enforces access according to Same Origin Policy.

Preparation

- Prepare tooling that will provide visibility into data available for a given context.
    - Website hosted on origin A, that will provide storage data.
    - Website hosted on origin B, that will provide storage data.
    - Reset browser to factory default settings.

Activities

Navigate to the website on origin A.
Making use of tooling, verify the data is added to storage, and is available in the context.
Navigate to the website on origin B.
Verify that the data set when accessing the first site is unavailable in the new context.
Verify that the data set when accessing the second site is available in the new context.
Navigate back to the website on origin A.
Verify that the data set by the site is still available.

Verdict

- Pass:
        - When site adds data to storage it is available.
        - When the site looks for data, it does not see data from the other origin
        - When the second site sets data it is also available.
        - When navigating back to the first site, the data set when visiting initially will still be available.
    - Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Screenshot(s) or log output from tooling to demonstrate each verdict

REQ-STORE-ACC-2 — The product shall not share or make data available across browser profiles.Clause 5.5

Requirement (verbatim from the interim draft)

The product shall not share or make data available across browser profiles.

Objective

Assess whether the product enforces separation of data across browser profiles.

Preparation

- Identify a relevant website that can be used to set uniquely identifiable data.
    - Prepare tooling that will provide visibility into data available for a given browser profile.
    - Identify supported browser profiles (eg private browsing, user profiles etc).
    - Reset browser to factory default settings.
    - Prepare browser configuration to support available browser profiles.

Activities

Open the website in the default browser profile, and note the data set by the website.
Open the website in each other browser profile, and note the data available in each profile.
Using the default browser profile, reload the website and note the data available.

Verdict

- Pass
        - The data gets set in the default browser profile when visiting the website.
        - For each browser profile available, the data is set by the browser profile context successfully.
        - The data set in the default browser profile is not available in any other browser profile.
        - Upon returning to the website, the data set initially is still available, and data set in individual profiles are not available.
    - Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Screenshot(s) or log output from tooling to demonstrate each verdict

REQ-STORE-ACC-3 — The product shall enforce Same Origin Policy access control for storage data outside rendering…Clause 5.5

Requirement (verbatim from the interim draft)

The product shall enforce Same Origin Policy access control for storage data outside rendering processes.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-SOP-AAC-1 — The product shall deny access in one origin to all parts of another origin, except as defined i…Clause 5.5

Requirement (verbatim from the interim draft)

The product shall deny access in one origin to all parts of another origin, except as defined in the user documentation.

Example: Web pages may load images from other origins, message using `window.postMessage` and may access limited properties such as `Location`. Web pages may not access the document object model or global Window scope from scripts of other origins. The user documentation references industry standards with implementation recommendations and additinal examples.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-SOP-AAC-2 — The product shall isolate origin-specific data such as cookies, Web Storage, IndexedDB and any…Clause 5.5

Requirement (verbatim from the interim draft)

The product shall isolate origin-specific data such as cookies, Web Storage, IndexedDB and any other storage, ensuring it's not available to any other origin, except through protocol-determined methods.

Editor's note: is this limited to top-level pages?

Editor's note: are cookies awkward here? in what way?

Editor's note: need to add examples for cross domain storage access is allowed, etc.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-PWR-AAC-1 — The product shall require express user permission before allowing a web page to use Powerful We…Clause 5.5

Requirement (verbatim from the interim draft)

The product shall require express user permission before allowing a web page to use Powerful Web Platform Features.

Objective

The product does not allow web pages to access Powerful Web Platform Features without express user permission.

Preparation

- The product installed from scratch, or reset to its default settings.
- Test web page or pages that exercises every Powerful Web Platform Feature identified in the product's technical documentation.

Activities

- For every Powerful Web Platform Feature identified in the product's technical documentation:
	- Navigate to the test web page.
    - Verify via the web page's behaviour and/or console log that the Powerful Web Platform Feature is not available to the web page.
    - Trigger the script to request the Powerful Web Platform Feature.
    - Take whatever action is necessary to allow the web page access to the Powerful Web Platform Feature.
    - Verify via the web page's behaviour and/or console log that the Powerful Web Platform Feature is now available to the web page.

Verdict

- Pass:
    - The web page does not receive access to Powerful Web Platform Features unless the user has taken an action to explicitly approve.
- Fail:
    - The above is not fulfilled.

Evidence the standard asks for

Screenshots of the UI allowing the user to give express permission to access the Powerful Web Platform Feature.
Console logs and/or UI captures from the test web page showing no access was possible prior to user approval.
Console logs and/or UI captures from the test web page showing access was possible after user approval.

5.6 — Confidentiality

Proposed ESR code: CON

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (e).

In this clause, reference can be made to the Annex K (normative), specifying State Of The Art Cryptography

REQ-TLS-CON-1 — The product shall support TLS versions and configurations indicated as "recommended" (R) of the…Clause 5.6

Requirement (verbatim from the interim draft)

The product shall support TLS versions and configurations indicated as "recommended" (R) of the ENISA Agreed Cryptographic Methods [1], and it may support TLS versions and configurations indicated as "legacy" (L).

Note: These algorithms are listed on page 37-38 of 1. TLS 1.3 [i.7] is R, and TLS 1.2 [i.6] is L. The L[2025] algorithms (with CBC) are not considered state of the art, and should be ignored.

Editor's note: This requirement might be implied by Annex K. TODO: Research this interpretation and delete if redundant.

Objective

The product supports all TLS versions and configurations marked as recommended by ENISA Agreed Cryptographic Methods.

Preparation

- Install the product from scratch, or reset it to its default settings.
- Identify the current list of recommended TLS versions and configurations from ENISA Agreed Cryptographic Methods [1].
- Configure web servers, each serving content under a distinct recommended TLS version/configuration.

Activities

The following steps are to be carried out in order:

1. Navigate to each test server and record whether the connection succeeds.

Verdict

- Pass: Each recommended TLS version/configuration is reachable from the product.
- Fail: The pass condition is not fulfilled.

Evidence the standard asks for

Logs or screenshots of each navigation result.
Reference list of ENISA recommended TLS versions/configurations used.

REQ-TLS-CON-2 — The web browser shall check the full validity of certificate chain through to the root, includi…Clause 5.6

Requirement (verbatim from the interim draft)

The web browser shall check the full validity of certificate chain through to the root, including for expiration.

Objective

The product validates the full certificate chain through to the root, including expiration and revocation.

Preparation

- Install the product from scratch, or reset it to its default settings.
- Configure a baseline web server with a valid TLS certificate chained to a trusted root.
- Configure additional web servers with: an expired certificate, a revoked certificate, a certificate chained to a root not in the product's trusted root store, and an incomplete chain.

Activities

The following steps are to be carried out in order:

1. Navigate to the baseline server and record the result.
2. Navigate to each defective-chain server and record the result.

Verdict

- Pass:
  - The baseline server is reachable.
  - For each defective-chain server, the product's response visibly differs from the baseline (e.g., blocked, warned, error).
- Fail: Either of the above is not fulfilled.

Evidence the standard asks for

Logs or screenshots of each navigation result.
Certificate details for each test server.

REQ-TLS-CON-3 — The product shall warn or obstruct the user from interacting with content served over insecure…Clause 5.6

Requirement (verbatim from the interim draft)

The product shall warn or obstruct the user from interacting with content served over insecure connections, including expired certificates and insecure TLS configurations.

Example: When presenting content served with cryptographic methods with a certain risk of exploitation, a web browser presents a user with a user interface element representing a broken lock, or an interstitial requiring user interaction to proceed.

Objective

The product warns or obstructs the user from interacting with content served over insecure connections.

Preparation

- Install the product from scratch, or reset it to its default settings.
- Configure web servers, each serving content over an insecure variant: an expired certificate, a certificate chained to an untrusted root, and an insecure TLS configuration such as a deprecated protocol version or weak cipher.

Activities

The following steps are to be carried out in order:

1. Navigate to each test server.
2. Record the product's UI response and whether content interaction is permitted, with or without an explicit user override.

Verdict

- Pass: For each insecure variant, the product presents a warning UI or obstructs interaction with the content.
- Fail: The pass condition is not fulfilled.

Evidence the standard asks for

Screenshots or recordings of the warning/obstruction UI for each variant.

REQ-TLS-CON-4 — The product shall implement appropriate technologies to promote or require the use of HTTPS rat…Clause 5.6

Requirement (verbatim from the interim draft)

The product shall implement appropriate technologies to promote or require the use of HTTPS rather than HTTP.

Example: Implementation of HSTS [i.8], active mixed content blocking [i.9], and HTTPS-First loading strategies.

Objective

The product implements one or more technologies that promote or require HTTPS over HTTP.

Preparation

- Install the product from scratch, or reset it to its default settings.
- Configure web servers serving the same content over HTTP and over HTTPS.

Activities

The following steps are to be carried out in order:

1. Navigate to the HTTP variant and observe whether the product upgrades to HTTPS, warns, or blocks.
2. Load an HTTPS page that includes HTTP subresources and observe mixed-content handling.

Verdict

- Pass: The product applies at least one technology that promotes or requires HTTPS, such as HSTS, HTTPS-First mode, automatic HTTP-to-HTTPS upgrade, or mixed-content blocking.
- Fail: The pass condition is not fulfilled.

Evidence the standard asks for

Logs or screenshots of HTTP vs HTTPS navigation behaviour.

REQ-TLS-CON-6 — The web browser shall have a mechanism to respond to the revocation or loss of trust of CA cert…Clause 5.6

Requirement (verbatim from the interim draft)

The web browser shall have a mechanism to respond to the revocation or loss of trust of CA certificates.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-EXT-CON-1 — The product shall prevent secrets stored by extensions from being read by other extensions or b…Clause 5.6

Requirement (verbatim from the interim draft)

The product shall prevent secrets stored by extensions from being read by other extensions or by web content.

NOTE: This requirement addresses the platform-enforced isolation boundary between extensions, and between extensions and web content. It does not address application-level leaks within an extension's own code.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: secrets stored by one extension are readable by other extensions or by web content (secret disclosure).

Preparation

- A test extension stores a secret.
- Another test extension and a test web page attempt to read it.

Activities

The following steps are to be carried out in order:

Install both test extensions and open test web page in a tab.
Verify the test extension stored the secret.
Use the second extension to attempt to read the stored secret via every extension API that can access storage.
Use the test web page to attempt to read the stored secret via every storage API available to web pages.

Verdict

- Pass:
  - The stored secret can't be read from the reader extension or from the web page.
- Fail:
  - The stored secret can be read from the reader extension or from the web page.

Evidence the standard asks for

Console log from extension and from the web page.

REQ-STORE-CON-1 — The product shall not send third-party cookies by default. They may be supported consistent wit…Clause 5.6

Requirement (verbatim from the interim draft)

The product shall not send third-party cookies by default. They may be supported consistent with the `Partitioned` attribute.

NOTE: The product can provide users the ability to share third-party cookies, whether on a case-by-case basis through interaction as in Storage Access API or throughout their browser profile through configuration.

Objective

Assess that third-party cookies are not sent by default.

Preparation

- Reset browser to factory default settings.
    - Prepare tooling to view browser http requests.
    - Prepare tooling to view stored cookies.
    - Website hosted on site A, that provides cookies.
    - Website hosted on site B, with :
      - embedded resources from site A,
      - iframe from site A that sets a `Partitioned` cookie, and
      - iframe from site A that sets a cookie without the `Partitioned` keyword.

Activities

Visit website on site A, and verify the cookies that have been set.
Visit website on site B, and verify whether the cookies are sent to site A when loading resources.
Verify whether either of the cookies from site A iframes embedded on site B are stored.
Reload website on site B, and verify the cookies sent to site A when loading resources.
Visit website on site A, and verify whether the cookies sent.

Verdict

- Pass:
        - The cookies are set successfully for site A.
        - The cookies are not sent to site A, when loading site B.
        - The cookie set within an iframe without a `Partitioned` keyword is not stored.
        - The cookie set within an iframe with a `Partitioned` keyword can be stored.
        - On reloading the site, cookies from site A are not sent to site B.
        - If the `Partitioned` keyword cookie was stored, it can be sent to the site A iframes and resources within site B.
        - When re-visiting the website on site A, the cookies only cookies sent are those set directly visiting that site.
    - Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Screenshot(s) or log output from tooling showing request data to demonstrate each verdict.
Screenshot(s) or log output from tooling showing cookie storage state to demonstrate each verdict.

REQ-STORE-CON-2 — The product shall make use of OS access control, encryption methods or other mechanisms to ensu…Clause 5.6

Requirement (verbatim from the interim draft)

The product shall make use of OS access control, encryption methods or other mechanisms to ensure confidentiality of disk-stored data.

Objective

Assess that OS access control, encryption methods and other mechanisims are used to ensure confidentiality of disk-stored data.

Preparation

- Access to product source code.
    - Access to OS documentation.

Activities

- Identify available access control methods for OS.
    - Identify data written to disk by product.
    - Verify that the data stored uses appropriate access control mechanisms.

Verdict

- Pass: Each instance of data written to disk is using appropriate access control.
    - Fail: The above is not fulfilled.

Evidence the standard asks for

List of disk-stored data from product.
Corresponding list of OS access control mechanisms used and justification for why each is appropriate.

REQ-STORE-CON-3 — The product shall store browser cache data such that they are keyed to both top-level site and…Clause 5.6

Requirement (verbatim from the interim draft)

The product shall store browser cache data such that they are keyed to both top-level site and resource.

Objective

Assess that browser storage cache data is keyed to both top-level site and resource.

Preparation

- Website hosted on site A, including resource A from site C.
    - Website hosted on site B, including resource A from site C.
    - Tooling to inspect browser cache.
    - Tooling to inspect request data.
    - Reset browser to factory default settings.

Activities

1. Visit the website hosted on site A and inspect browser cache.
    2. Visit the website hosted on site B, verify request data and inspect browser cache.

Verdict

- Pass:
        - If resource A from site C is stored in browser cache, it should keyed to site A.
        - Request data from site B should include resource A from site C. It should not have been retrieved from cache.
        - If resource A from site C is stored in browser cache, it may be stored twice, and can be keyed against both site A and site B.
    - Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Screenshot(s) or log output from tooling showing browser cache content to demonstrate each verdict.
Screenshot(s) or log output from tooling showing request and response for resource A, when visiting site B, to demonstrate the corresponding verdict.

REQ-SOP-CON-1 — The product shall only allow scripts to access the body of a cross-origin HTTP response where t…Clause 5.6

Requirement (verbatim from the interim draft)

The product shall only allow scripts to access the body of a cross-origin HTTP response where the source origin has opted to allow access by the requesting origin.

Example: Implementation of Cross-Origin Resource Sharing (CORS)

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-SOP-CON-2 — Where the product allows cross-origin embedding of a resource in documents, the product shall l…Clause 5.6

Requirement (verbatim from the interim draft)

Where the product allows cross-origin embedding of a resource in documents, the product shall limit information about that resource as specified in the technical documentation.

Example: Cross-origin embedding of the height and width of an image are exposed to scripts, while the contents of the image are not exposed unless CORS is enabled by the source origin of the image.

Editor's note: In principle, CON-1 might imply CON-2, and maybe we could put this all in assessment steps. Or maybe better to be explicit?

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

5.7 — Integrity

Proposed ESR code: INT

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (f).

Note: TLS-related clauses contribute to integrity.

REQ-EXT-INT-1 — The product shall cryptographically verify extensions before installation and update.Clause 5.7

Requirement (verbatim from the interim draft)

The product shall cryptographically verify extensions before installation and update.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

The product cryptographically verifies an extension before installation and before update.

Preparation

- Four test extensions, signed correctly, incorrectly, unsigned, and malformed.
- Four more test extension, each an update of the correctly signed extension, and these four each of signed correctly, signed incorrectly, unsigned, and malformed.
- A test extension update server.

Activities

The following steps are to be carried out in order:

1. Attempt installation of each variation, recording the result.
2. For the correctly signed extension, attempt update with each variation, recording the result.

Verdict

- Pass:
  - The correctly signed extension is installed, all others are rejected by the product.
  - Only the correctly signed update is installed, all others are rejected by the product.
- Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Extension console logs.
Product user interface captures.

REQ-PWR-INT-1 — The product shall protect permission prompts against manipulation by the web page.Clause 5.7

Requirement (verbatim from the interim draft)

The product shall protect permission prompts against manipulation by the web page.

Objective

Permission prompts cannot be obscured, modified, or approved by web pages.

Preparation

- The product installed from scratch, or reset to its default settings.
- A test web page that uses a Powerful Web Platform Feature and attempts to manipulate the product's permission prompt. For example by utilizing CSS z-index overlays, transparent iframes, DOM manipulation etc.

Activities

The following steps are to be carried out in order:

1. Navigate to the test web page.
2. Trigger the script to request access to the Powerful Web Platform Feature.

Verdict

- Pass:
    - Any permission prompt is unable to be obscured or manipulated by the test web page.
- Fail:
    - The above is not fulfilled.

Evidence the standard asks for

Screenshot of the permission prompt or other UI surface.

REQ-PWR-INT-2 — The product shall only enable Powerful Web Platform Features for use within Secure Contexts.Clause 5.7

Requirement (verbatim from the interim draft)

The product shall only enable Powerful Web Platform Features for use within Secure Contexts.

Objective

Web pages accessed via non-secure contexts are unable to use Powerful Web Platform Features.

Preparation

- The product installed from scratch, or reset to its default settings.
- Test web page or pages that exercises every Powerful Web Platform Feature identified in the product's technical documentation in a non-secure context.

Activities

The following steps are to be carried out in order:

- For every Powerful Web Platform Feature identified in the product's technical documentation:
    - Navigate to the test web page.
    - Trigger the script to request the Powerful Web Platform Feature.
    - Verify via the web page's behaviour and/or console log that the Powerful Web Platform Feature is not available to the web page.

Verdict

- Pass:
    - The user is not prompted to grant access to any Powerful Web Platform Feature.
    - The web page does not receive access to any Powerful Web Platform Feature.
- Fail:
    - Any of the above are not fulfilled.

Evidence the standard asks for

Console logs and/or UI captures from the test web page showing no access to the Powerful Web Platform Features.

5.8 — Data Minimisation

Proposed ESR code: DM

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (g).

Note: TLS-related clauses contribute to data minimization.

REQ-PWR-DM-1 — Powerful Web Platform Feature permissions shall be origin-scoped by default, with broader scopi…Clause 5.8

Requirement (verbatim from the interim draft)

Powerful Web Platform Feature permissions shall be origin-scoped by default, with broader scoping permitted only via express user action, or opt-in by the origins.

Objective

A permission granted to one origin is not automatically inherited by a different origin without explicit intent.

Preparation

- The product installed from scratch, or reset to its default settings.
- Two test web pages hosted on distinct origin (Origin A and Origin B), that both request the same Powerful Web Platform Feature.
- Two test web pages hosted on distinct sites (Site A and Site B), that both request the same Powerful Web Platform Feature.

Activities

The following steps are to be carried out in order:

Load Origin A, trigger the request, and explicitly grant the permission.
Verify Origin A has access.
Load Origin B and attempt to access the Powerful Web Platform Feature.
Load Site A, trigger the request, and explicitly grant the permission.
Verify Site A has access.
Load Site B and attempt to access the Powerful Web Platform Feature.

Verdict

- Pass:
    - Origin B does not inherit the permission and must prompt the user independently or fail automatically.
    - Site B does not inherit the permission and must prompt the user independently or fail automatically.
- Fail:
    - Any of the above are not fulfilled.

Evidence the standard asks for

Console logs and/or UI captures from the test web page showing access to the Powerful Web Platform Features has been granted to the test page on Origin A.
Console logs and/or UI captures from the test web page showing no access to the Powerful Web Platform Features to the test page on Origin B.

REQ-PWR-DM-2 — Powerful Web Platform Feature permissions decisions shall apply to each Browser Profile separat…Clause 5.8

Requirement (verbatim from the interim draft)

Powerful Web Platform Feature permissions decisions shall apply to each Browser Profile separately.

Objective

A permission granted or denied in one Browser Profile does not extend to another Browser Profile.

Preparation

- The product installed from scratch, or reset to its default settings and configured with two distinct Browser Profiles (e.g., Profile A and Profile B).
- A test web page that uses a Powerful Web Platform Feature.

Activities

The following steps are to be carried out in order:

1. Load the test site in Profile A, trigger the request, and explicitly grant the permission.
2. Load the test site in Profile B and attempt to access the Powerful Web Platform Feature.

Verdict

- Pass:
    - The permission state in Profile B is unaffected by Profile A, and the product does not provide access to the Powerful Web Platform Feature on step 2 of the assessment activities without express user permission.
- Fail:
    - The above is not fulfilled.

Evidence the standard asks for

Console logs and/or UI captures from the test web page showing access to the Powerful Web Platform Features has been granted to the test page in Profile A.
Console logs and/or UI captures from the test web page showing no access to the Powerful Web Platform Features to the test page in Profile B.

5.9 — Availability Protection

Proposed ESR code: AP

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (h).

REQ-AP-1 — The web browser shall take steps to reduce the risk that errors or crashes in one website runni…Clause 5.9

Requirement (verbatim from the interim draft)

The web browser shall take steps to reduce the risk that errors or crashes in one website running in one tab cause other, unrelated tabs to crash.

Example: Running different tabs in different renderer processes some of the time

Note: Guarantees here are not absolute. Current web browsers have various cases where one tab can take another down.

Applicability

UC-CONS and UC-INST

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-AP-2 — The web browser shall take steps, on a best-effort basis, to save the state of running websites…Clause 5.9

Requirement (verbatim from the interim draft)

The web browser shall take steps, on a best-effort basis, to save the state of running websites such that they can be restored later following an incident.

Applicability

UC-CONS and UC-INST

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-EXT-AP-1 — The product shall make the best effort to prevent the ability of an extension to make the produ…Clause 5.9

Requirement (verbatim from the interim draft)

The product shall make the best effort to prevent the ability of an extension to make the product unavailable.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

The product makes a best-effort attempt to prevent extensions from making the product unavailable.

Preparation

- Test extensions, one with a hot CPU loop, one with unbounded memory allocation, and one with a crash if possible.
- Tools for process inspection.
- Product documentation.

Activities

The following steps are to be carried out in order:

Install a test extension
Try opening a new tab, opening a web page
Try disabling the extension
Repeat for each extension

Verdict

- Pass: At least one of the following holds:
  - Product can open a new tab, navigate to a website, and disable the extension under the resource conditions caused by the extension.
  - Has documentation explaining the best effort made.
- Fail:
  - The product is unresponsive (user cannot open a new tab, navigate, or disable the extension) AND no mitigating approach is documented.

Evidence the standard asks for

Process logs.
Product documentation

REQ-ISO-AP-1 — The product shall take steps to reduce the risk that errors or crashes in one website running i…Clause 5.9

Requirement (verbatim from the interim draft)

The product shall take steps to reduce the risk that errors or crashes in one website running in one tab cause other, unrelated tabs to crash.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-ISO-AP-2 — The product shall take steps, on a best-effort basis, to save the state of running websites suc…Clause 5.9

Requirement (verbatim from the interim draft)

The product shall take steps, on a best-effort basis, to save the state of running websites such that they can be restored later following an incident.

Editor's note: Need conclusion wrt this being about page state such as scroll position, form data or storage or unspecific or more specific.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-STORE-AP-1 — The product shall retain data stored to disk in case of a crash and make it available upon brow…Clause 5.9

Requirement (verbatim from the interim draft)

The product shall retain data stored to disk in case of a crash and make it available upon browser restart.

Objective

Assess that in the case of a crash the data stored to disk is made available upon browser restart.

Preparation

- Prepare a method to induce crash
    - Prepare tooling to inspect the data stored within the browser.
    - Website that will store data

Activities

Visit website and verify it has set data.
Follow steps to induce crash
Restart browser
Verify data exists in browser.
Visit website and verify that the data is available to it.

Verdict

- Pass: Data set by the website during the first step is presented back to site during final step.
    - Fail: The above is not fulfilled.

Evidence the standard asks for

Screenshot(s) or log output from tooling to demonstrate verdict.

5.10 — Impact Minimisation

Proposed ESR code: IM

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (i).

REQ-IM-1 — The web browser's technical documentation shall describe all network protocols implemented by t…Clause 5.10

Requirement (verbatim from the interim draft)

The web browser's technical documentation shall describe all network protocols implemented by the browser, or include references to such protocols. These protocols shall either be industry standards (preferably), or be described with similar technical detail to industry standards.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-EXT-IM-1 — If the product is running with elevated system privileges, extensions will be prevented from ex…Clause 5.10

Requirement (verbatim from the interim draft)

If the product is running with elevated system privileges, extensions will be prevented from executing with those elevated privileges.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: an extension inherits the elevated OS privileges of an elevated product process (privilege inheritance).

Preparation

- Test extension.
- Product launched with elevated privileges using the method provided on the operating system.
- Tool for process inspection.

Activities

The following steps are to be carried out in order:

Launch the product with elevated privilege.
Install a test extension.
Inspect the extension process and record its privilege.

Verdict

- Pass:
  - The process running the extension does not have the elevated privileges of the main product process or processes.
- Fail:
  - The process running the extension carries the elevated privileges of the product process.

Evidence the standard asks for

Process inspection log.

REQ-EXT-IM-2 — The product shall permit extensions to communicate with native applications only when declared…Clause 5.10

Requirement (verbatim from the interim draft)

The product shall permit extensions to communicate with native applications only when declared in the extension manifest and the native application is configured according to the product requirements for doing so.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: an extension communicates with undeclared, unconfigured, or misconfigured native applications (unauthorized native-app communication).

Preparation

- Test extension declaring a native application configured per vendor requirements, and a second application that is undeclared or unconfigured.
- Tool for observing application communication in the OS, or control of the native application configured.

Activities

The following steps are to be carried out in order:

Install the test extension.
Connect to the declared and configured application.
Connect to the undeclared application.
Remove the application configuration, connect again from the extension.

Verdict

- Pass:
  - Only the declared and configured application is reachable.
  - Removing configuration breaks the connection.
- Fail:
  - Any undeclared, unconfigured, or misconfigured native application is reachable from the extension.

Evidence the standard asks for

Extension console logging.
Native application logging.

REQ-EXT-IM-3 — The product shall not permit an extension to initiate connections to services on the loopback i…Clause 5.10

Requirement (verbatim from the interim draft)

The product shall not permit an extension to initiate connections to services on the loopback interface (e.g., `localhost` or `127.0.0.1`) unless localhost access is declared in the extension manifest.

Editor's note [OPEN]: Confirm that major browsers currently enforce this.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: an extension without a localhost manifest declaration reaches a service on the loopback interface (undeclared loopback access).

Preparation

- Webserver bound to the loopback interface.
- A hosts-file entry mapping a non-loopback hostname to a loopback address.
- Loopback address variants to exercise: `localhost`, `127.0.0.1`, `::1`, `0.0.0.0`, a `*.localhost` subdomain, and the hosts-file hostname.
- Test extension declaring localhost access.
- Test extension not declaring localhost access.
- Tool for observing local network traffic.

Activities

The following steps are to be carried out in order:

1. Install the declaring extension and attempt connection to the webserver via each variant.
2. Install the non-declaring extension and attempt connection via each variant.

Verdict

- Pass:
  - The declaring extension connects via every variant.
  - The non-declaring extension is blocked on every variant.
- Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Localhost network traffic log.

REQ-ISO-IM-1 — The product's technical documentation shall describe all public network protocols implemented b…Clause 5.10

Requirement (verbatim from the interim draft)

The product's technical documentation shall describe all public network protocols implemented by the product, or include references to such protocols. These protocols shall be described in publicly available specifications, or be described with sufficient technical detail to permit an independent implementation.

Editor's note: Discussion around this was not concluded. HAS did not like asking for technical docs. Sam raised asking for user docs instead. Andrew suggested that in some circumstances it's not needed at all, eg explicit cooperation between client and server. Daniel E had concerns about lowering the bar even in cooperation contexts.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-PWR-IM-1 — The product shall deny cross-origin iframes access to Powerful Web Platform Features by default.Clause 5.10

Requirement (verbatim from the interim draft)

The product shall deny cross-origin iframes access to Powerful Web Platform Features by default.

Objective

The product prevents cross-origin iframes from accessing Powerful Web Platform Features without explicit delegation from the top-level document.

Preparation

- The product installed from scratch, or reset to its default settings.
- A top-level test web page hosted on Origin A.
- An embedded cross-origin iframe hosted on Origin B inside the test page, configured without any explicit permission delegation.
- A script in the cross-origin iframe attempting to request a Powerful Web Platform Feature.

Activities

The following steps are to be carried out in order:

1. Load the top-level test web page.
2. Trigger the script to request the Powerful Web Platform Feature from within the embedded cross-origin iframe.

Verdict

- Pass:
    - Access to the feature is blocked for the cross-origin iframe automatically, without prompting the user.
- Fail:
    - The above is not fulfilled.

Evidence the standard asks for

Console logs and/or UI captures from the test web page showing access to the Powerful Web Platform Feature is being blocked.

5.11 — Minimisation of Attack Surfaces

Proposed ESR code: MAS

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (j).

REQ-MAS-1 — The web browser's technical documentation shall describe all web-exposed interfaces, or include…Clause 5.11

Requirement (verbatim from the interim draft)

The web browser's technical documentation shall describe all web-exposed interfaces, or include references to such descriptions. These interfaces shall either be industry standards (preferably), or be described with similar technical detail to industry standards.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-MAS-2 — The web browser shall apply fuzz testing to web-exposed interfaces including HTML, CSS, JavaScr…Clause 5.11

Requirement (verbatim from the interim draft)

The web browser shall apply fuzz testing to web-exposed interfaces including HTML, CSS, JavaScript, WebAssembly, HTTP and TLS, as well as APIs, headers, options, etc exposed within those interfaces.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-EXT-MAS-1 — The product's extension APIs shall be documented, and the documentation shall specify for each…Clause 5.11

Requirement (verbatim from the interim draft)

The product's extension APIs shall be documented, and the documentation shall specify for each API the purpose, inputs and outputs, permissions required, its security-related behaviour, and the platforms the API is available on.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

All extension APIs supported by the product are documented with their purpose, inputs and outputs, permissions, security aspects, and platform availability.

Preparation

- Product extension API documentation.

Activities

- Review documentation of each supported API for the elements in the requirement

Verdict

- Pass:
  - Each supported API is documented with the required elements.
- Fail:
  - Any of the above are not fulfilled.
  - Undocumented APIs are reachable at runtime that are not on the documented surface.
  - Documented API behavior diverges from the actual implementation.

Evidence the standard asks for

Log of documentation review.

REQ-EXT-MAS-2 — The product shall support enterprise policy controls allowing administrators to disable the ext…Clause 5.11

Requirement (verbatim from the interim draft)

The product shall support enterprise policy controls allowing administrators to disable the extension feature entirely, or specify an allow-list of extensions.

Applicability

Enterprise browsers (UC-INST)

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

The product supports using enterprise policy to disable extensions entirely, or restricting loaded extensions via an allow-list.

Preparation

- Applicability: Enterprise browsers (UC-INST).
- Test environment that can apply the enterprise-policy support in the product per the supplied technical documentation.
- Two test extensions.

Activities

The following steps are to be carried out in order:

Apply a policy to disable all extensions.
Attempt to install an extension.
Remove the policy.
Apply a policy containing an allow list of one of the two test extensions.
Attempt to install both test extensions.
Remove the policy.

Verdict

- Pass:
  - Each policy has the specified effect.
  - Removing each policy reverts to product default behavior.
- Fail:
  - Any of the above are not fulfilled.
  - Policy is enforced for new installs but pre-installed extensions remain active.

Evidence the standard asks for

User interface capture.
Enterprise policy logging if applicable.

REQ-EXT-MAS-3 — The product shall enforce the scope of extension resources available to web content, as declare…Clause 5.11

Requirement (verbatim from the interim draft)

The product shall enforce the scope of extension resources available to web content, as declared in the manifest.

Example: Extensions may bundle assets in their packages, and browsers may allow them provide web pages with access to static assets, such as images, scripts and styles. Extensions declare these assets in their manifest, and browsers restrict access to only the declared assets.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: undeclared extension resources are reachable by web content (resource scope bypass).

Preparation

- Test extension declaring static assets as available to web content, and containing static assets which are not declared.
- Test web page accessing the declared and undeclared resources in the extension.

Activities

The following steps are to be carried out in order:

1. Install extension.
2. Load test web page.

Verdict

- Pass:
  - Declared resources are accessible by the test page as declared.
  - Undeclared assets not accessible by the test page.
- Fail:
  - Undeclared resources are reachable by the test page.

Evidence the standard asks for

Test page source code.
Network logging.
Extension source code.

REQ-ISO-MAS-1 — The product's technical documentation shall describe all web-exposed interfaces, or include ref…Clause 5.11

Requirement (verbatim from the interim draft)

The product's technical documentation shall describe all web-exposed interfaces, or include references to such descriptions. These interfaces shall be described in publicly available specifications, or be described with sufficient technical detail to permit an independent implementation.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-SOP-MAS-1 — The product shall enforce restrictions from a source origin on how its resources may be used ac…Clause 5.11

Requirement (verbatim from the interim draft)

The product shall enforce restrictions from a source origin on how its resources may be used across origins, as defined in the user documentation.

Example: Usage of cross-origin options such as `X-Frame-Options` or `Cross-Origin-Resource-Policy` allow source origins to specify usage constraints for products to receive and enforce.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-MEM-MAS-1 — The web browser shall use operating system functionality to restrict the capabilities and privi…Clause 5.11

Requirement (verbatim from the interim draft)

The web browser shall use operating system functionality to restrict the capabilities and privileges of architectural components of the web browser.

Example: Via sandboxed processes, system call filtering.

Objective

The web browser takes steps to limit exposed operating system attack surface, which also serves to limit the consequences of successful exploitation, unless a documented functional requirement necessitates elevated privileges.

Preparation

- Documentation describing the operating system functionality used by the web browser to limit exposed operating system attack surface and limit the consequences of successful exploitation.
- Documentation describing how those methods are applied to the architectural components of the web browser.
- For architectural components to which those methods are not applied, documentation describing the rationale for this decision, and mitigations in place to reduce exploitation risk.
- The web browser's source code.
- Tools to inspect a running binary.

Activities

The following steps are to be carried out in order:

Review the documentation.
For each method of operating system functionality listed in the web browser documentation, confirm via spot checks of the source code that the method is applied in accordance with the documentation.
Run tools to inspect the running web browser.

Verdict

- Pass:
    - The documentation describes operating system functionality that can limit exposed operating system attack surface, and limit the consequences of successful exploitation.
    - The documentation maps those methods to the architectural components of the web browser.
    - For each of the methods listed in the documentation as not being applied to an architectural component, the documentation convincingly describes the rationale for this decision.
    - The mitigations applied to relevant architectural components convincingly reduce the risk of exploitation.
    - For each method that results in changes readily inspectable in a running binary, tooling confirms the method is in use.
- Fail:
    - Any of the above are not fulfilled.

Evidence the standard asks for

Log of documentation review.
Log of tooling output.

5.12 — Exploitation Mitigation Mechanisms

Proposed ESR code: EMM

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (k).

REQ-EMM-1 — The web browser shall separate certain web browser components from each other to reduce the sco…Clause 5.12

Requirement (verbatim from the interim draft)

The web browser shall separate certain web browser components from each other to reduce the scope of exploits.

Examples: Sandboxing JavaScript/WebAssembly from the rest of the renderer process, containing the renderer and networking in separate processes

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-EMM-2 — The web browser shall isolate different sites from each other, including from side-channel atta…Clause 5.12

Requirement (verbatim from the interim draft)

The web browser shall isolate different sites from each other, including from side-channel attacks.

Example: Process isolation of sites

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-EMM-3 — The web browser shall reduce the privileges of its various components with respect to the opera…Clause 5.12

Requirement (verbatim from the interim draft)

The web browser shall reduce the privileges of its various components with respect to the operating system to the level required to perform their tasks.

Example: In the context of a browser with the separation of a renderer and browser process, denying direct access of the renderer process to various OS system calls

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-EXT-EMM-1 — The product shall enforce a Content Security Policy for extension pages and scripts injected in…Clause 5.12

Requirement (verbatim from the interim draft)

The product shall enforce a Content Security Policy for extension pages and scripts injected into web content.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: scripts execute despite CSP, whether inline scripts on an extension page or undeclared scripts injected into web content.

Preparation

- Test extension with an extension page containing inline script and also a content script injected into a web page.

Activities

The following steps are to be carried out in order:

Install the test extension
Load the extension page
Load the test web page

Verdict

- Pass:
  - Product console log shows that the inline remote script and the content script injected into the web page are both blocked.
- Fail:
  - Either the inline script on the extension page or the injected content script executes.
  - CSP is enforced for `<script>` but bypassable via event handlers, `eval`, dynamic imports, Worker scripts, or trusted-types violations.
  - CSP is applied in report-only mode rather than enforcing.

Evidence the standard asks for

Console log showing CSP blocks.

REQ-EXT-EMM-2 — The product shall validate an extension's manifest before installation and update, reject manif…Clause 5.12

Requirement (verbatim from the interim draft)

The product shall validate an extension's manifest before installation and update, reject manifests that are malformed or contain disallowed content, and ignore unrecognised optional fields.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

The product validates extension manifests before install and update, rejects manifests that are malformed or contain disallowed content, and ignores only unrecognised optional fields. "Disallowed content" means a value in a known field that violates the product's documented manifest schema (e.g., a permission string outside the product's permission set, a disallowed CSP directive, an out-of-form host-permission pattern).

Preparation

- Product documentation of the manifest schema, including the permission set, allowed CSP directives, and required vs optional fields.
- A valid baseline manifest, and variants for: malformed (invalid JSON), disallowed content in a known field, an unrecognised optional field, an unrecognised required field.

Activities

The following steps are to be carried out in order:

1. Attempt install with each variant manifest, recording each result.
2. Install the valid baseline, then attempt update with each variant, recording each result.

Verdict

- Pass:
  - Install and update fail for the malformed, disallowed-content, and unrecognised-required-field variants.
  - Install and update succeed for the unrecognised-optional-field variant, and the unknown field grants no capability.
  - The valid baseline installs and updates successfully.
- Fail:
  - Any of the above are not fulfilled.
  - Disallowed content is silently normalised or substituted with a default that grants more than requested.
  - Update validation is looser than install validation.
  - Early parse failure short-circuits validation and hides subsequent errors.

Evidence the standard asks for

User interface capture.
Extension logs.

REQ-ISO-EMM-1 — The product shall separate certain product components from each other to reduce the scope of ex…Clause 5.12

Requirement (verbatim from the interim draft)

The product shall separate certain product components from each other to reduce the scope of exploits, using process isolation or similar industry standard mitigations.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-ISO-EMM-2 — The product shall isolate different sites from each other, including from side-channel attacks.Clause 5.12

Requirement (verbatim from the interim draft)

The product shall isolate different sites from each other, including from side-channel attacks.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-ISO-EMM-3 — The product shall reduce the privileges of its various components with respect to the operating…Clause 5.12

Requirement (verbatim from the interim draft)

The product shall reduce the privileges of its various components with respect to the operating system to the level required to perform their tasks.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-MEM-EMM-1 — The web browser shall include runtime assertions as to the correctness of program state, which…Clause 5.12

Requirement (verbatim from the interim draft)

The web browser shall include runtime assertions as to the correctness of program state, which fail safely when violated.

Example: Via the use of ASSERT() or CHECK() statements that result in an unexploitable crash.

Objective

The web browser contains runtime checks which help prevent the web browser from entering an unexpected state, which can lead to exploitable vulnerabilities.

Preparation

- Documentation describing the techniques developers can use to ensure that runtime invariants hold and fail in an unexploitable fashion.
- The web browser's source code.

Activities

The following steps are to be carried out in order:

1. Review the source code that implements the techniques developers can use to ensure that runtime invariants hold and fail in an unexploitable fashion.
2. Review the usage of the techniques within the source code.

Verdict

- Pass:
    - The techniques developers can use to ensure that runtime invariants hold and fail in an unexploitable fashion.
    - The techniques are widely used within the source code.
- Fail:
    - Any of the above are not fulfilled.

Evidence the standard asks for

Log of source code review.

REQ-MEM-EMM-2 — The web browser shall use compiler features designed to reduce the risk of exploitation.Clause 5.12

Requirement (verbatim from the interim draft)

The web browser shall use compiler features designed to reduce the risk of exploitation.

Example: stack canaries, source code fortification, variable initialisation.

Objective

The web browser uses hardening features provided by the compiler.

Preparation

- Documentation describing the security relevant compiler flags and features that are enabled in the product's release configuration.
- The web browser's source code and build configuration.
- Tools to inspect compiled binaries.

Activities

The following steps are to be carried out in order:

Review the documentation.
For each of the security relevant compiler flags and features listed in the web browser documentation, confirm via inspection of the web browser source code and build configuration that it is indeed being used in the build of the release configuration.
Run tooling against the web browser's compiled binaries.

Verdict

- Pass:
    - The compiler flags and features listed as being used in the web browser documentation are indeed being used in the build of the release configuration.
    - For each security relevant compiler flag, the enablement of which results are readily inspectable in the resulting compiled binary, tooling output confirms the feature is in a state that matches the web browser documentation.
- Fail:
    - Any of the above are not fulfilled.

Evidence the standard asks for

Log of documentation review.
Log of source code and build configuration review.
Log of tooling output.

REQ-MEM-EMM-3 — The web browser shall use mitigation technologies provided by the operating systems and/or hard…Clause 5.12

Requirement (verbatim from the interim draft)

The web browser shall use mitigation technologies provided by the operating systems and/or hardware on which the web browser is designed to run.

Example: hardware-assisted memory tagging, Address Space Layout Randomization.

Objective

The web browser uses hardening features provided by the operating system and/or hardware.

Preparation

- Documentation describing the mitigation technologies provided by the operating system and/or hardware on which the web browser is designed to run, which are used by the web browser.
- Documentation describing the rationale for not using any mitigation technologies provided by the operating system and/or hardware on which the web browser is designed to run.
- The web browser's source code and build configuration.

Activities

The following steps are to be carried out in order:

1. Review the documentation.
2. For each of the mitigation technologies listed in the web browser documentation, confirm via inspection of the web browser source code and build configuration that it is indeed being used in the release configuration.

Verdict

- Pass:
    - The mitigation technologies listed in the web browser documentation are indeed being used by the release configuration of the web browser.
    - For each of the mitigation technologies listed in the documentation as not being used, the documentation convincingly describes the rationale for this decision.
- Fail:
    - Any of the above are not fulfilled.

Evidence the standard asks for

Log of documentation review.
Log of source code and build configuration review.

5.13 — Logging and Monitoring

Proposed ESR code: LOG

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (l).

REQ-TLS-LOG-1 — The product shall present a user interface giving visibility into the security properties of th…Clause 5.13

Requirement (verbatim from the interim draft)

The product shall present a user interface giving visibility into the security properties of the connection, including the origin.

Objective

The product presents a user interface giving visibility into the security properties of the connection, including the origin.

Preparation

- Identify multiple relevant websites with various levels of the security of their connections, at different origins.
- Locate the relevant user interface based on the technical documentation of the product.

Activities

The following steps are to be carried out in order:

1. Navigate to each of the various websites identified.
2. Open the security UI and observe the information displayed.

Verdict

- Pass: For each website, the UI includes the URL and any other relevant security properties of the connection.
- Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Screenshots of security UI for each website

REQ-EXT-LOG-1 — The product shall provide the user the ability to identify which user-installed extensions are…Clause 5.13

Requirement (verbatim from the interim draft)

The product shall provide the user the ability to identify which user-installed extensions are currently running, and the permissions in effect for each.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

The product provides a way to identify which user-installed extensions are currently running, and the permissions in effect for each.

Preparation

- User-installed test extension A, declaring two or more distinct permissions.
- User-installed test extension B, with a background script or service worker as its only runtime.
- Product documentation locating the running-extensions interface.

Activities

The following steps are to be carried out in order:

Install both test extensions.
Open the running-extensions interface and record which extensions and permissions are shown.
Install a third user extension while the interface is open and record whether it appears without a restart.

Verdict

- Pass:
  - Both test extensions are listed, including the background-only one.
  - The permissions shown for each match the permissions in effect.
  - The third extension appears without a restart.
- Fail: Any of the above are not fulfilled.

Evidence the standard asks for

User interface captures.

REQ-STORE-LOG-1 — The product shall provide an interface for viewing information about stored data at a granulari…Clause 5.13

Requirement (verbatim from the interim draft)

The product shall provide an interface for viewing information about stored data at a granularity of site or narrower (e.g. origin).

Objective

Assess that the product provides an interface for viewing information about stored data at a granularity of site or narrower.

Preparation

- Prepare tooling to inspect the data stored within the browser.
    - User documentation describing process for deleting data.
    - Website on site A that will store data, including:
      - cookie data
      - LocalStorage
      - IndexedDB storage
    - Website on site B that will store data, including:
      - cookie data
      - LocalStorage
      - IndexedDB storage

Activities

Visit website on site A, and verify it has set data.
Visit website on site B, and verify it has set data.
Follow user documentation for deleting data against site A.
Verify whether data for site A has been removed.
Verify whether data for site B has been removed.

Verdict

- Pass:
        - Data is set successfully during website vists.
        - User documentation provides clear steps for removing data at a site level.
        - Data is successfully removed from site A.
        - Data is not removed from site B.
    - Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Screenshot or log output from tooling at each step to show data.
User documentation providing instructions for data removal.

REQ-PWR-LOG-1 — The product shall provide a user interface listing the Powerful Web Platform Features granted o…Clause 5.13

Requirement (verbatim from the interim draft)

The product shall provide a user interface listing the Powerful Web Platform Features granted or denied to the web page being displayed.

Objective

The product provides a user interface allowing the user to view the current permission status of Powerful Web Platform Features for the active web page.

Preparation

- The product installed from scratch, or reset to its default settings.
    - A test web page that uses several Powerful Web Platform Features.

Activities

The following steps are to be carried out in order:

Navigate to the test web page.
Trigger two feature requests: grant access to the first, and deny access to the second.
Open the product's site-specific security/permissions UI.

Verdict

- Pass:
    - The UI accurately lists the specific Powerful Web Platform Features and explicitly reflects their current states as "granted/allowed" and "denied/blocked" for that page.
    - Applying the setting automatically blocks the test web page's access to the Powerful Web Platform Feature without presenting a permission prompt to the user.
- Fail:
    - The UI is missing, or it does not accurately reflect the active permission states.

Evidence the standard asks for

UI screenshots of the site information/permission panel showing the correct status.

5.14 — Data Removal and Transparency

Proposed ESR code: DRT

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 1 (2) (m).

REQ-TLS-DRT-1 — The product shall make available functionality to reset TLS-related functionality to the initia…Clause 5.14

Requirement (verbatim from the interim draft)

The product shall make available functionality to reset TLS-related functionality to the initial safe settings, including selection of algorithms and protocol versions, root certificates, and any other relevant properties.

Applicability

Web browsers which allow changing TLS-related settings.

Objective

The product provides functionality that resets TLS-related settings to the initial safe configuration.

Preparation

- Install the product from scratch, or reset it to its default settings.
- Capture the initial TLS-related state: enabled algorithms and protocol versions, trusted root certificates, and any other TLS-related settings.
- Locate the reset functionality in the product UI or documentation.

Activities

The following steps are to be carried out in order:

Modify TLS-related state from its initial values, such as disabling a protocol version, adding a custom trusted root, or altering a TLS-related setting.
Exercise the reset functionality.
Capture the post-reset TLS-related state.
Compare the post-reset state against the initial snapshot.

Verdict

- Pass:
  - The reset functionality is available and exercisable.
  - The post-reset state matches the initial state across all modified TLS-related properties.
- Fail: Either of the above is not fulfilled.

Evidence the standard asks for

TLS state snapshots before modification, after modification, and after reset.

REQ-EXT-DRT-1 — The product shall enable the removal of individual extensions, which shall delete all data asso…Clause 5.14

Requirement (verbatim from the interim draft)

The product shall enable the removal of individual extensions, which shall delete all data associated with the extension, and revoke all permissions granted to it.

Applicability

Per clause 5.1: “The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.”

Objective

Failure mode: data or granted permissions remain after extension removal (residual state).

Preparation

- Test extension installed with several permissions requested, and which writes to its storage area.
- Tool for viewing product extension storage.

Activities

The following steps are to be carried out in order:

Install the test extension, granting all permissions requested.
Inspect the extension storage area, verifying the extension data was written.
Remove the extension from the product.
Inspect each storage area again, and user interface for permissions management.

Verdict

- Pass:
  - After extension removal there is no data in the storage area or granted permissions.
- Fail:
  - After removal, extension data remains in the storage area, or permissions granted to the extension remain in effect.
  - Extension data persists in profile or cloud sync after local removal.
  - Tab-local state and in-memory caches are retained until product restart.
  - Some storage areas (newer or platform-specific APIs) are missed by the inspection.

Evidence the standard asks for

Storage and permission inspection before and after extension removal.

REQ-STORE-DRT-1 — The product shall ensure when storage data is deleted, it uses appropriate APIs that ensure the…Clause 5.14

Requirement (verbatim from the interim draft)

The product shall ensure when storage data is deleted, it uses appropriate APIs that ensure the data is deleted from the underlying storage device.

Objective

Assess that in cases of storage data deletion, the data is effectively deleted.

Preparation

- Access to product source code.
    - Access to integration API documentation.
    - Any required test tooling for verification of memory.

Activities

- Identify internal APIs that provide for the deletion of storage data.
    - Identify all implementations of the APIs.
    - Identify underlying system APIs used for data management, and their accompanying documentation.

Verdict

- Pass:
        - For each storage deletion API implementation, each has either
            - System vendor documentation for the system API, providing guarantee of deletion, or
            - Test that upon calling API, underlying data is deleted from memory.
    - Fail: Any of APIs where one of the criteria are not fulfilled.

Evidence the standard asks for

List of internal APIs implementations providing storage deletion.
Corresponding list of underlying system APIs, and documentation their references.
Screenshot(s) or log output from test tooling for each API in the case of manual test verification.

REQ-STORE-DRT-2 — The product shall provide reset functionality that removes all stored data across all sites and…Clause 5.14

Requirement (verbatim from the interim draft)

The product shall provide reset functionality that removes all stored data across all sites and browser profiles.

Objective

Assess that the reset functionality removes all stored data across all sites and browser profiles.

Preparation

- Prepare tooling to inspect browser profiles and data stored within browser.
    - Website that will store instances of all data supported by the browser.
    - Browser in factory default state.
    - User documentation for performing browser reset.
    - List of browser profile capabilities.

Activities

Verify with tooling only default browser profile exists, and no data is stored.
Create an instance of each supported browser profile.
Verify with tooling that each profile exists, and no data is stored.
With each profile, visit the website to set data.
Verify with tooling that each profile still exists, and has data stored.
Follow user documentation for performing reset.
Verify with tooling only default browser profile exists, and no data is stored.

Verdict

- Pass: At each verification step, the expected profiles and data are present.
    - Fail: The above is not fulfilled.

Evidence the standard asks for

Screenshot(s) or log output from tooling at each step to show data.
User documentation for performing reset.

REQ-STORE-DRT-3 — The product shall have a user interface for deleting storage at a granularity of site or narrow…Clause 5.14

Requirement (verbatim from the interim draft)

The product shall have a user interface for deleting storage at a granularity of site or narrower (e.g. origin).

Objective

Assess that the product provides an interface for users to delete storage at a granularity of site or narrower.

Preparation

- Prepare tooling to inspect the data stored within the browser.
    - User documentation describing process for deleting data.
    - Website on site A that will store data, including
      - cookie data,
      - LocalStorage, and
      - IndexedDB storage.
    - Website on site B that will store data, including
      - cookie data,
      - LocalStorage, and
      - IndexedDB storage.

Activities

Visit website on site A, and verify it has set data.
Visit website on site B, and verify it has set data.
Follow user documentation for deleting data against site A.
Verify whether data for site A has been removed.
Verify whether data for site B has been removed.

Verdict

- Pass:
        - Data is set successfully during website vists.
        - User documentation provides clear steps for removing data at a site level.
        - Data is successfully removed from site A.
        - Data is not removed from site B.
    - Fail: Any of the above are not fulfilled.

Evidence the standard asks for

Screenshot(s) or log output from tooling at to demonstrate each verdict.
User documentation providing instructions for data removal.

REQ-PWR-DRT-1 — The product shall provide a user interface allowing revocation of previously granted permission…Clause 5.14

Requirement (verbatim from the interim draft)

The product shall provide a user interface allowing revocation of previously granted permissions for Powerful Web Platform Features.

Objective

Permission to use Powerful Web Platform Features granted to a web page can be easily revoked by the user via a provided interface.

Preparation

- The product installed from scratch, or reset to its default settings.
    - A test web page that uses a Powerful Web Platform Feature.

Activities

The following steps are to be carried out in order:

Load the test page, trigger the request, and explicitly grant the permission.
Verify the web page can successfully access the feature.
Open the product's user interface (either site-specific controls or global settings) and revoke the permission.
Reload the test page and attempt to use the feature again.

Verdict

- Pass:
    - The product provides a UI to revoke the permission.
    - The revocation UI indicates the permission is removed, and the web page loses access to the feature.
- Fail:
    - The revocation UI is missing.
    - The revocation UI indicates the permission is removed, but the web page retains access.

Evidence the standard asks for

UI screenshots of the revocation process.
Console logs and/or UI captures from the test web page showing no access to the Powerful Web Platform Features after revocation.

5.15 — Vulnerability Handling

This clause addresses the requirements in the CRA [i.1] Annex 1 Part 2.

The requirements specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [2] shall be fulfilled for the product.

Annex K — cryptography

The draft’s Annex K cryptography provisions, as this pack makes them answerable. Everything inside the entries is the draft’s text.

ETSI Drafting rules do not allow footnotes. All footnotes in this Annex will have to be deleted or replaced by relevant references and notes before publication. Once the text of this Annex will be agreed, the definitions included in the notes will be moved to Clause 3 of the present document.

> NOTE: the text of this annex is currently being edited, not final.

K.1.1 — The product shall, by default, use State-of-the-Art cryptography algorithms listed in (CRY-SOTA…Annex K

Requirement (verbatim from the interim draft)

The product shall, by default, use State-of-the-Art cryptography algorithms listed in (CRY-SOTA), to be used for the supported security mechanism of the product where applicable.

> NOTE 1: The use of _security mechanism e.g. authentication, access control, secure communication, secure storage and secure update are described in the main text of this standard._

> NOTE 2: Cryptographic algorithm primitives (in short, algorithms e.g. public- and private-key encryption algorithms, hash functions, authentication codes, digital signatures) are classified as CRY-SOTA if they are listed in the [ACM][^1] document and are suitable for the implementation of supported security mechanisms of the product.

> NOTE 3: Supporting evidence options that an algorithm, which is not included in CRY-SOTA, is applicable and suitable for the respective use case, are listed in the related assessment criteria ( K.1.2.1) clause.

Applicability

Annex K is normative for the product's cryptography. Clause 5.6 states: “In this clause, reference can be made to the Annex K (normative), specifying State Of The Art Cryptography”. The requirement itself is conditioned “where applicable” on the product's supported security mechanisms.

Objective

The purpose of this assessment case is (the conceptual assessment) whether the implemented algorithms are identified as CRY-SOTA.

Preparation

- Preconditions for the test: If applicable, the product is in the default- configuration. Otherwise, the product is in the delivery state, where it is available on the market in accordance with CRA Annex I part 1(2) (b).

Activities

- For every security mechanism the list of used algorithms, which are reachable over an external interface and identified as CRY- SOTA shall be documented.

Verdict

- The verdict PASS shall be assigned if evidence has been provided.

- The verdict FAIL shall be assigned otherwise

If the verdict in K.1.2.1 has been assigned FAIL, the following assessment has to be performed additionally:

Evidence the standard asks for

description of the performed test
all test records of the performed test

Guidance

The draft adds a conditional follow-up assessment (its heading number K.1.2.2 is duplicated in the draft), quoted verbatim:

#### K.1.2.2 Additional conditional assessment:

##### K1.2.2.1 Assessment objective

If for a certain security mechanism and use case no CRY-SOTA algorithm is applicable, evidence shall be provided in the documentation that a suitable algorithm has been implemented for this evidence instead.

##### K.1.2.2.2 Assessment preparation:

Preconditions for the test: If applicable, the product is in the default configuration state. Otherwise, the product is in the delivery state, where it is available on the market in accordance with CRA Annex I part 1(2) (b).

##### K.1.2.2.3 Assessment activities:

For every security mechanism and for every used algorithm, which is reachable over an interface of the product and identified as not included in CRY- SOTA, the documentation shall provide evidence

- that this algorithm is applicable and suitable for the respective use case

#### K.1.2.4 Supporting Evidence:

1. Identification of the certain algorithm by reference in further  publicly available  applicable algorithm catalogues as  national cryptographic catalogues[^2] or vertical use case specific cryptographic algorithm catalogues[^3]

2. No entry of known exploitable vulnerabilities  provided in  ENISA  "European Vulnerability Database.[^4]

3. Description of the performed test

4. all test records of the performed test

#### K.1.2.5 Assignment of verdict:

- The verdict PASS shall be assigned if respective evidence has been provided,
- The verdict FAIL shall be assigned otherwise.

> NOTE 3: Functional correctness and completeness assessment criteria of the documentation are to be specified in accordance with the capabilities set in the specific vertical Standards.

[^1]: defined in [ACM]
[^2]: e.g. BSI – BSI TR-02102-1, Cryptographic Mechanisms: Recommendations and Key Lengths , Vers. 2025-01, January 31, 2025
[^3]: e.g. EPC342-08 /Version 15.0 /Guidelines on cryptographic algorithms usage and key management - PPSSG / 7 March 2025
[^4]: European Vulnerability Database established pursuantto Article 12(2) of Directive (EU) 2022/2555, https://euvd.enisa.europa.eu/ENISA

K.2 — Where applicable the product shall by default be prepared to update cryptographic algorithm use…Annex K

Requirement (verbatim from the interim draft)

Where applicable the product shall by default be prepared to update cryptographic algorithm used for the supported security mechanism of the product to maintain when there are indications that the used cryptographic algorithm will not stay SOTA anymore within the intended lifetime of the product.

> NOTE 4: To maintain SOTA for cryptographic algorithm within the intended lifetime of the product concepts to consider are crypto agility additional to the capability of updating cryptographic algorithms on the product in accordance to Secure Update and Secure Communication mechanism.

> NOTE 5: Formal verification can use mathematical proofs and /or rigorous methods to prove an algorithm's correctness, ensuring it meets its formal specification for all valid inputs, unlike testing which only samples cases. This process involves creating formal models, using techniques like theorem proving or model checking, and is crucial for critical systems like cryptography finding hard-to-spot bugs and guaranteeing security/reliability_._

> NOTE 6: The [ACM] listing has two classes of SOTA algorithms; Legacy mechanisms with an expiry date as defined in ACM, and Recommended mechanisms with no set expiry date.

> NOTE 7: For products or components of products that cannot have their cryptographic algorithms updated for example if the implementation or part uses a hardware-based root of trust, it is important that the intended lifetime of the equipment does not exceed the recommended usage lifetime of the cryptographic algorithms used by the product. Thereby the implementation of an algorithm can include the specific implementation of their parameters

> NOTE 8: If a component storing the algorithm or corresponding parameters of a main product is replaced by a new component, the product is considered as a new product according to the New Legislative Framework Blue Guide, if the replacement provides a substantial modification to the main product

Applicability

Annex K is normative for the product's cryptography. Clause 5.6 states: “In this clause, reference can be made to the Annex K (normative), specifying State Of The Art Cryptography”. The requirement itself is conditioned “where applicable” on the product's supported security mechanisms.

Objective

The purpose of this assessment case is (the conceptual assessment) whether the product is prepared to update cryptographic algorithms for the supported security mechanism.

Preparation

- Preconditions for the test: If applicable, the product is in the default- configuration. Otherwise, the product is in the delivery state, where it is available on the market in accordance with CRA Annex I part 1(2) (b).

Activities

- For every used SOTA algorithm, which is reachable over an interface, the life span of the algorithm is documented, as well its property, if the algorithm is considered as legacy or recommended algorithm.[^5]
- If the life span of the product exceeds the life span of a legacy algorithm, the algorithm is marked as updatable by a recommended algorithm in the documentation.
- If an algorithm is identified as SOTA recommended, no further action is required.

Verdict

- The verdict PASS shall be assigned if respective evidence has been provided,
- The verdict FAIL shall be assigned otherwise.
<br />

[^5]: defined in [ACM]

Evidence the standard asks for

Description /documentation of the performed test.
All test records of the performed test.

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.

CRA provision	Draft clause(s)
Annex I, Part 1, (1)	5
Annex I, Part 1, (2)(a)	5.2
Annex I, Part 1, (2)(b)	5.3
Annex I, Part 1, (2)(c)	5.4
Annex I, Part 1, (2)(d)	5.5
Annex I, Part 1, (2)(e)	5.6
Annex I, Part 1, (2)(f)	5.7
Annex I, Part 1, (2)(g)	5.8
Annex I, Part 1, (2)(h)	5.9
Annex I, Part 1, (2)(i)	5.10
Annex I, Part 1, (2)(j)	5.11
Annex I, Part 1, (2)(k)	5.12
Annex I, Part 1, (2)(l)	5.13
Annex I, Part 1, (2)(m)	5.14
Annex I, Part 2	5.15

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 13 threats the draft derives its requirements against, verbatim:

T-01 — Cross-origin separation failure

An attacker origin bypasses origin restrictions or structured cross-origin controls. Impact / violated invariant: Direct confidentiality/integrity loss; violates origin-based isolation. (Applicable use cases: GP, EN, EB.)

T-02 — Origin-compromising active content and persistence abuse

Malicious or injected script executes with origin authority, optionally persisting. Impact / violated invariant: Same-origin authority abuse. (Applicable use cases: GP, EN, EB.)

T-03 — Capability escalation through permissioned surfaces

A malicious origin acquires or abuses permissioned capability surfaces. Impact / violated invariant: Non-ambient access assumptions are weakened. (Applicable use cases: GP, EN, EB.)

T-04 — XS-Leaks / cross-site inference

The attacker does not directly read cross-origin content, but infers state through observable side effects of cross-site interaction. Impact / violated invariant: Violates the invariant that cross-site behavior should not become an unintended oracle for sensitive state. (Applicable use cases: GP, EN.)

I-01 — Renderer / engine compromise

Malicious content exploits engine or renderer bugs. Impact / violated invariant: Confinement fails. (Applicable use cases: GP, EN, EB.)

I-02 — Timing / grouping implementation choices preserve or amplify inference surface

Timer precision, browsing-context grouping, or result handling preserve signals attackers can measure. Impact / violated invariant: XS-Leaks surface grows despite correct direct-read enforcement. (Applicable use cases: GP, EN.)

I-03 — Storage, cookie, or credential handling defects

Incorrect credential or state scoping affects when cross-site requests carry state. Impact / violated invariant: Cross-site oracle surface expands. (Applicable use cases: GP, EN.)

E-01 — Passive or active network attack

Attacker observes or tampers with traffic. Impact / violated invariant: Transport guarantees fail. (Applicable use cases: EB.)

E-02 — Trusted-UI spoofing and consent deception

Malicious site imitates browser UI or abuses confusing flows. Impact / violated invariant: Phishing and unsafe consent. (Applicable use cases: GP, EN.)

E-03 — Cross-site inference attacker

A malicious origin deliberately probes another site through permitted cross-site interactions and observes side effects. Impact / violated invariant: Sensitive cross-site state becomes inferable without direct reads. (Applicable use cases: GP, EN.)

D-01 — PKI / transport trust failure

External trust failure weakens secure transport assumptions. Impact / violated invariant: Wrong-endpoint trust or downgrade exposure. (Applicable use cases: GP, EN, EB.)

D-02 — Server-side state-dependent behavior becomes oracle

Server emits redirects, error codes, or load behavior that differ by state. Impact / violated invariant: Browser-enforced read restrictions do not stop inference. (Applicable use cases: EN.)

D-03 — OS / kernel compromise below browser controls

Local privileged compromise defeats browser confinement. Impact / violated invariant: Browser-enforced boundaries collapse. (Applicable use cases: GP, EN, EB.)

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.

The draft carries 29 <mark>-flagged editor's notes/open issues (draft version v0.1.1, 2026-04-04), including two TODOs about requirements that may be implied by Annex K (REQ-TLS-SBD-1, REQ-TLS-CON-1) and unresolved discussions on REQ-ISO-IM-1 and REQ-SOP-AAC-2.
No per-use-case applicability matrix exists yet: clause 5.1 carries an editor's note that a matrix mapping use cases to requirements "should be inserted". Only 3 requirements carry their own "Applicability:" prose naming use-case ids, from which a required/not-required map was derived; every other requirement is carried with an empty applicability map (treated as applicable to all use cases).
24 of 83 clause-5 requirements have NO assessment block in clause 6 of this interim draft: REQ-KEV-1, REQ-KEV-2, REQ-STORE-ACC-3, REQ-SOP-AAC-1, REQ-SOP-AAC-2, REQ-TLS-CON-6, REQ-SOP-CON-1, REQ-SOP-CON-2, REQ-AP-1, REQ-AP-2, REQ-ISO-AP-1, REQ-ISO-AP-2, REQ-IM-1, REQ-ISO-IM-1, REQ-MAS-1, REQ-MAS-2, REQ-ISO-MAS-1, REQ-SOP-MAS-1, REQ-EMM-1, REQ-EMM-2, REQ-EMM-3, REQ-ISO-EMM-1, REQ-ISO-EMM-2, REQ-ISO-EMM-3. Their packs entries carry assessment: null.
Clause 6's block [ACC-STORE-AAC-1] targets “REQ-STORE-AAC-1”, an id clause 5 never defines; the pack attaches it to REQ-STORE-ACC-1, whose text its Assessment Reference restates. Related draft inconsistency: clause 5.5 announces ESR code “AAC” but the STORE requirements in it use “ACC” (REQ-STORE-ACC-1..3).
REQ-TLS-CON-6 exists but no REQ-TLS-CON-5 is defined — an id-sequence gap in the draft.
Clauses 5.9–5.12 contain near-duplicate requirement pairs (REQ-AP-1/2 vs REQ-ISO-AP-1/2; REQ-IM-1 vs REQ-ISO-IM-1; REQ-MAS-1 vs REQ-ISO-MAS-1; REQ-EMM-1/2/3 vs REQ-ISO-EMM-1/2/3) — apparently parallel drafts of the same provisions not yet merged. Both variants are carried verbatim.
Clause 5.15 (Vulnerability Handling) defines no REQ ids: it is a single normative sentence delegating to CEN/CLC JT013090:2026 (prEN 40000-1-3), and clause 6.15 likewise delegates its assessment. The pack carries no answerable entry for it; CRA Annex I Part 2 remains assessed through the horizontal pack.
Clause 6.3 is titled “Secure by design” while the corresponding clause 5.3 is “Secure by default configuration” — a draft heading mismatch.
Annex K is marked “currently being edited, not final” and contains duplicated heading numbers (two K.1.2.2 / K.1.2.4 / K.1.2.5 blocks); the Annex K entries' ids (K.1.1, K.2) are the draft's clause numbers, its only identifiers for them.
The Executive summary and Introduction clauses are template placeholders; Annex C, Annex <D...J> and Annex G are empty skeletons.
REQ-AP-1: use-case applicability derived from its own “Applicability:” prose (UC-CONS and UC-INST); unnamed use cases marked not-required.
REQ-AP-2: use-case applicability derived from its own “Applicability:” prose (UC-CONS and UC-INST); unnamed use cases marked not-required.
REQ-EXT-MAS-2: use-case applicability derived from its own “Applicability:” prose (Enterprise browsers (UC-INST)); unnamed use cases marked not-required.
clause 6 block [ACC-STORE-AAC-1] targets “REQ-STORE-AAC-1”, an id clause 5 never defines; attached to REQ-STORE-ACC-1, whose text its Assessment Reference restates.

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.