# Essential Cybersecurity Requirements This document provides a high-level description of how Dispel meets the **Essential Cybersecurity Requirements** set out in **Annex I, Parts I and II** of Regulation (EU) 2024/2847 (Cyber Resilience Act, or "**CRA**") for the digital elements listed below. Corporate IT systems, internal tooling, and unrelated SaaS components are out of scope except where they directly support the security properties of the listed products. #### **Digital Elements in Scope** * Dispel Applications (macOS, iOS, Windows) * Wicket ESI ## CRA Requirements ### Annex I, Part I: Secure-by-Design and Development | CRA Requirement | Conformity Statement | | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | | Protection against unauthorized access | The products implement authenticated and authorized access mechanisms appropriate to their operating environments, preventing unauthorized logical access. | | Confidentiality of data | Data processed, stored, or transmitted by the products is protected using industry-standard cryptographic mechanisms by default. | | Integrity of data, commands, and code | Integrity protections are applied to product code, configuration, commands, and updates to prevent unauthorized modification. | | Availability and resilience | The products are designed to remain available and to fail safely under adverse conditions, including resilience to common attack techniques. | | Secure-by-default configuration | Products are delivered with secure default configurations that do not require additional hardening to achieve baseline security. | | Minimization of attack surface | Only necessary services, interfaces, and permissions are enabled by default; unnecessary functionality is disabled or excluded. | | Protection from known vulnerabilities | Known vulnerabilities in product components are identified and addressed prior to release. | | Secure update mechanisms | Updates are delivered through authenticated and integrity-protected mechanisms to prevent tampering. | | Secure lifecycle support | Security updates are provided for a defined support period appropriate to the product lifecycle. | | Logging and monitoring (where appropriate) | Security-relevant events are recorded or surfaced in a manner appropriate to the product’s role and environment. | | Least privilege | Products operate using the minimum privileges required for their intended functionality. | | Protection against malicious code execution | Measures are implemented to prevent unauthorized or malicious code execution within the product. | | Secure interoperability | Interactions with operating systems and external components are designed and implemented securely. | | Resistance to common attack techniques | Product design considers common attack vectors such as spoofing, replay, tampering, and privilege escalation. | ### Annex I, Part II: Vulnerability Handling and Post-Market Obligations | CRA Requirement | Conformity Statement | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------- | | Vulnerability handling process | A documented vulnerability handling process is maintained for the products in scope. | | Coordinated Vulnerability Disclosure (CVD) | A public channel exists for the responsible disclosure of security vulnerabilities. | | Vulnerability intake and triage | Reported vulnerabilities are assessed, prioritized, and tracked based on severity and impact. | | Timely remediation | Security vulnerabilities are remediated without undue delay. | | Secure distribution of fixes | Security fixes are distributed using the same secure update mechanisms as standard releases. | | User and customer communication | Users are informed of relevant security issues when appropriate. | | Exploitation awareness | Information about known or suspected exploitation is monitored and considered during response activities. | | Regulatory reporting | Procedures exist to report actively exploited vulnerabilities to relevant EU authorities when required by law. | | Software Bill of Materials (SBOM) | Software composition information is maintained for the products. | | Record retention | Records relating to vulnerabilities and remediation actions are retained for regulatory review. | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://legal.dispel.com/security-and-data-protection/compliance/eu-cyber-resilience-act/essential-cybersecurity-requirements.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.