> For the complete documentation index, see [llms.txt](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/eu-cyber-resilience-act.md). # EU Cyber Resilience Act What the EU Cyber Resilience Act asks of a product with digital elements, how Heeler assesses Annex I, and how to put a product in scope. The **Cyber Resilience Act** (CRA), Regulation (EU) 2024/2847, sets the cybersecurity requirements for **products with digital elements** placed on the EU market. Its Annex I lists what such a product must do and how its manufacturer must handle vulnerabilities. Heeler assesses a product against Annex I and shows which requirements it can answer from evidence and which need a statement from you. {% hint style="warning" %} CRA is off by default until an Administrator puts a product in scope. The evidence Heeler selects for each requirement is Heeler's reading of the regulation, and its [crosswalk](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md#crosswalk) shows the CIS Controls v8.1 Safeguards behind that evidence. The assessment is readiness evidence, not a compliance determination. {% endhint %} ## What the CRA is The CRA applies to products with digital elements that are placed on the EU market. For a software company that usually means **installable software**: mobile and desktop apps, SDKs and libraries, agents, browser extensions and firmware. Pure SaaS that customers use over the internet is out of scope. Two dates matter: | From | What applies | | --------------------- | --------------------------------------------------------------------------------- | | **11 September 2026** | Article 14: reporting of actively exploited vulnerabilities and severe incidents. | | **11 December 2027** | The full Annex I obligations. | {% hint style="info" %} No harmonised standard for the CRA is cited in the Official Journal yet, so no standard gives a presumption of conformity. The cover of every CRA report carries this disclaimer: *"Annex I readiness evidence for products with digital elements. No harmonised standard is cited in the Official Journal, so no presumption of conformity exists; conformity is decided per product through the Article 13 risk assessment and the applicable assessment route."* {% endhint %} ## Annex I in Heeler Heeler holds the 22 Annex I requirements in two chapters: | Chapter | Requirements | | ------------------------------------------- | ------------------------------------------------------------------------------ | | **Annex I Part I: Product properties** | **I.1** risk-based design, and the security properties **I.2.a** to **I.2.m**. | | **Annex I Part II: Vulnerability handling** | **II.1** to **II.8**. | Annex I has no levels. Every requirement applies to every product in scope, so an application's Standards tab shows one **All requirements** card instead of level cards, and the requirements table has no level column. Requirement keys display as they read in the regulation, for example **I.2.b** or **II.1**. Requirement text is reproduced verbatim from EUR-Lex. Reuse is authorised under Commission Decision 2011/833/EU. ## Putting a product in scope CRA is off for every application until an **Administrator** puts it in scope. CRA obligations attach to each product, so the usual path is to put each product in scope on its own: 1. Make sure the standard is adopted under **Administration > Program > Standards**. See [Standards](/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/program-policy/standards.md). 2. Open the application's **Standards** tab, select the CRA standard, and turn on **In CRA scope**. If every application you have is a product in scope, set **Default for applications** to **On** on the CRA card instead. Each application's own **In CRA scope** setting still overrides that default. You do not have to find the products yourself. The CRA page under **Standards** shows Administrators a **Suggested applications** card. It lists applications whose repositories look like installable software, with the reason for each as a badge: * iOS or Android projects. * A direct dependency on Electron, Tauri, React Native, Capacitor or a browser-extension framework. * A public repository with a published release. Select **Enable** on a row to put that application in scope. Its first assessment is queued and appears in a few minutes. Six attributes sit beside the **In CRA scope** switch on the application's Standards tab: | Attribute | What it records | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Product classification** | **Default**, **Important, Class I**, **Important, Class II** or **Critical**, from Annex III and IV of the CRA. The classification changes the conformity route, not the Annex I requirements. | | **Placed on the EU market** | Whether the product is on the EU market. Such products fall under Article 14 reporting now and the full Annex I obligations from 11 December 2027. | | **Support period ends** | A date. Article 13(8): the end of the period in which vulnerabilities are handled. At least five years, or the expected use time if shorter. | | **Single point of contact** | Article 13(17): the address users report vulnerabilities to. | | **User information** | Annex II: where the information and instructions to the user are published. | | **Technical documentation** | Article 31: where the technical documentation for the product is kept. | All six print on the [report](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/compliance-reports.md) cover under **Product information**. ## What Heeler evidences and what you attest Heeler answers 15 of the 22 requirements, fully or in part, from evidence it already collects: | Requirement | Evidence | | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **I.2.a** No known exploitable vulnerabilities | Known-exploited dependency vulnerabilities, critical SAST findings, and a blocking guardrail on severe vulnerabilities with a fix. | | **I.2.b** Secure by default configuration | Secrets in the repository or CI/CD, hard-coded credentials and debug settings, untrusted CI triggers, and a blocking secret-scanning guardrail. | | **I.2.d** Protection from unauthorised access | Unauthenticated endpoints, and SAST findings on session cookies and tokens in URLs. | | **I.2.e** Confidentiality | SAST findings on cleartext transport, certificate validation, weak randomness and weak cryptography, and a blocking cryptography guardrail. | | **I.2.f** Integrity | SAST findings on injection and deserialisation, and a blocking injection guardrail. | | **I.2.h** Availability | SAST findings on catastrophic regular expressions, missing rate limits and unbounded outbound calls. | | **I.2.j** Limit attack surfaces | Documentation and monitoring endpoints exposed to the internet, and unauthenticated endpoints. | | **I.2.k** Exploitation mitigation | SAST findings on browser-side mitigations such as CSP, CORS, CSRF and framing. | | **I.2.l** Security logging and monitoring | SAST findings on log injection and sensitive data in logs. | | **II.1** Components and SBOM | An SBOM per code root that covers every direct dependency. | | **II.2** Remediate without delay | Findings past their SLO, fixable high-severity dependency vulnerabilities, and a blocking SLO guardrail. | | **II.3** Regular security tests | SAST, dependency and secret scans that ran in the last 30 days, and a blocking SAST guardrail. | | **II.5** Coordinated vulnerability disclosure policy | The OpenSSF Scorecard security policy check. | | **II.6** Sharing information about vulnerabilities | The OpenSSF Scorecard security policy check. | | **II.7** Secure distribution of updates | The OpenSSF Scorecard signed releases check. | The other seven are organisational or product-behaviour obligations that no code signal can show. They read **Manual** until someone attests to them for the product: **I.1**, **I.2.c**, **I.2.g**, **I.2.i**, **I.2.m**, **II.4** and **II.8**. CRA obligations attach to each product, so every CRA attestation is per application. See [Dispositions](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md#dispositions). The evidenced requirements also show a [crosswalk](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md#crosswalk) to CIS Controls v8.1 Safeguards. CIS publishes no CRA mapping, so every CRA crosswalk entry is a **Heeler reading**. ## Marking a requirement not applicable Part I (2) applies "where applicable". The manufacturer's cybersecurity risk assessment (Article 13) decides which of those properties apply to the product. Heeler does not guess this for you. When your risk assessment finds that a requirement does not apply, record it as a **not applicable** disposition on the requirement, with the justification as its statement (Article 13(4) asks you to document it). The requirement then leaves the score, and the report carries your justification. See [Dispositions](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md#dispositions). ## Enforcing The **Enforce CRA Annex I** bundle turns the Annex I controls Heeler can enforce into pull-request guardrails: known exploitable and critical vulnerabilities with a fix, exposed secrets, injection and cryptography findings, and overdue vulnerability SLOs. See [Guardrail Bundles](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/guardrail-bundles.md). ## Related * [Assessments](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/assessments.md): how Heeler scores an application, and how dispositions work. * [Standards](/mrecEO40m5D6bt7Pq5pE/administer-and-monitor/program-policy/standards.md): adopting the standard for your organization. * [Compliance Reports](/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/compliance-reports.md): the assessment as a document, with the CRA disclaimer on its cover. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.heeler.com/mrecEO40m5D6bt7Pq5pE/standards-and-compliance/eu-cyber-resilience-act.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.