Welcome. Here you will find the draft Standards for this vertical, as well as an issue tracker where you can submit comments, and discuss the standard.
## Disclaimer
> [!caution]
> Exercising one of the Principles of international standardization – Openness – and taking it to a different level, ETSI is piloting informal public consultations of the vertical standards in support of the Cyber Resilience Act at a much earlier stage than it is usual in the standardization world. In this context, please keep in mind that the standard draft herein is an INTERIM DRAFT, which expectably will be subject to substantial changes before its target publication date in the second semester of 2026. This INTERIM DRAFT document is provided for information and is for future development work within the ETSI Technical Committee CYBER EUSR Working Group (CYBER-EUSR) only. ETSI and its Members accept no liability for any further use/implementation of this Specification. Approved and published specifications and reports shall be obtained exclusively via the ETSI Documentation Service at http://www.etsi.org/standards-search
## Commenting guidelines
Your comments to improve this early draft are very welcomed. To ensure the effectiveness of your contribution, please make sure to include the following elements in your comment:
1. Clear identification of the section of the draft your comment is referring to.
2. Objective proposal to delete content, add content or substitute content.
3. Concrete contribution (exact content you suggest including in the draft as an addition to, or in substitution of, existing content).
4. Brief rationale to justify the proposal (e.g. why the suggested content should be added an/or the existing content should be deleted or substituted).
Please note that comments without concrete contributions will be noted but not acted upon by ETSI CYBER-EUSR. We trust and value your expertise and therefore expect you to take this opportunity to proactively contribute to solving the issues you find while analysing this early draft.
## How to submit comments
You can submit comments from the issue tracker:
1. In the sidebar, click the "Issues" button.
2. Check that the issue you are raising is not already in the list.
3. Click the blue "New Issue" button.
4. Enter a descriptive title for your comment, then select "Vertical Standard Comment" from the templates menu, and fill in the template.
- You can find the line number by Opening the standard from the repository and switching to the "Code" view, using the toggle on the right hand side.
- For the version number, please use the string of letters and numbers in the box to the left of the "History" button at the top of this page. You can click the clipboard icon to automatically copy it.
5. Please remember to **add a label** indicating the type of issue you are opening, and use the template. There are three types of issue
-**Discussions**: for discussion of overarching issues not related to specific elements in the draft standard, or a place for rapporteurs to ask questions to the community.
-**Editorial Comment**: for issues that concern Grammar and Wording of the Standard, and not the technical substance.
-**Technical Comment**: for issues with the technical substance of the standard.
6. Once you are done click "Create Issue". Other users will be able to comment and upvote or downvote the issue you have raised.
> [!warning]
> This repository does not accept pull requests. Please only use the issue tracker.
@@ -476,15 +476,17 @@ This requirement for user agency fundamentally shapes the browser security model
### 4.6.1 Isolation Mechanisms
#### 4.6.1.1 Domain and Origin Isolation
**[DOM]** The manufacturer shall implement security boundaries between different web contexts to prevent unauthorized cross-domain access and maintain the integrity of the same-origin policy.
**[DOM]** The manufacturer shall ensure that execution contexts belonging to different origins are securely isolated to prevent unauthorized data access, code execution, or state manipulation across boundaries.
Isolation shall include process separation, independent storage and cache spaces, and validation of all cross-origin communication through standardized, browser-mediated mechanisms such as Cross-Origin Resource Sharing (CORS), which allows controlled sharing of resources between origins through validated HTTP headers, and postMessage, which provides a secure message-passing interface between isolated contexts (e.g. frames or windows).
Any relaxation of isolation shall be explicitly authorized, documented, and monitored to prevent data leakage or privilege escalation.
**Capability**: Browser implements domain URL isolation and origin-based security contexts (protocol, domain, port combinations)
**Capability**: Browser enforces isolation between domains and origins (defined by scheme, host, and port) to protect integrity and confidentiality of data and execution.
**Conditions**:
* DOM-0: Strict isolation enforced with no relaxation mechanisms
* DOM-1: Isolation with controlled relaxation (CORS, postMessage)
* DOM-2: Isolation with user-configurable exceptions
* DOM-3: Isolation with extensive third-party integration points
* DOM-0: Full isolation: Each origin is strictly separated. No mechanism exists for cross-origin access or relaxation.
* DOM-1: Controlled isolation: Isolation is enforced by default but may be selectively relaxed through standardized, browser-mediated mechanisms (e.g. CORS or postMessage) with explicit validation.
* DOM-2: Configurable isolation: Isolation is enforced by default, but users or administrators can define exceptions via explicit configuration or policy.
* DOM-3: Integrated isolation: Isolation remains in place, but third-party integrations, compatibility modes, or embedded components may introduce controlled exceptions under defined policies.
