Cyber Resilience Act
Where Avocado OS fits in the regulation
Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 sets horizontal cybersecurity requirements for products with digital elements. The Official Journal published it on 20 November 2024. It entered into force on 10 December 2024.
Classification
Annex III lists operating systems as Important Class I, so Avocado OS is in Class I. Your device does not become Class I because it runs Avocado OS. The class of a device comes from its core function. For example, a router or a smart door lock is in Annex III. Most other devices are not. (Article 7(1), Annex III, Implementing Regulation (EU) 2025/2392)
Conformity assessment route
If your device is not in Annex III or Annex IV, you can do the assessment yourself (Module A, internal control). If your device is in Class I, you can use Module A only when harmonised standards, common specifications, or an EU cybersecurity certificate at level "substantial" cover all of Annex I. If not, a notified body must assess the device. Stricter routes apply to Class II and to critical products in Annex IV. In October 2026, no CRA harmonised standards were in the Official Journal yet. (Articles 27 and 32, Annex VIII)
Manufacturer status
You are the manufacturer of your device under Article 13. The open-source software in your device does not change this. Peridio is the manufacturer of Avocado OS. Article 24 gives lighter rules to open-source software stewards, but a steward is by definition not a manufacturer. Thus Article 24 does not apply to Avocado OS. (Articles 3(13), 3(14), 13, and 24)
Timeline
The CRA applies in phases. The table strikes through the milestones that are already in force.
| Date | Milestone |
|---|---|
| 10 December 2024 | Entry into forceIn forceTwenty days after publication in the Official Journal. The phased dates that follow count from this date. |
| 11 June 2026 | Notified bodies framework (Chapter IV)In forceThe rules for the designation and operation of notified bodies apply. This matters only if your conformity route needs a notified body. |
| 11 September 2026 | Article 14 reportingIn forceYou must report actively exploited vulnerabilities and severe incidents on the schedule in the Article 14 section. From this date, you need triage, an on-call rotation, and report templates. |
| 11 December 2027 | Full applicationUpcomingAll Annex I requirements are enforceable. Before you place a product on the EU market, complete the conformity assessment and put the CE marking on it. |
Annex I Part I: product properties
Part I has fourteen requirements. Point (1) is an overall obligation for risk-based design. Point (2) is a separate requirement for "no known exploitable vulnerabilities". Point (3) has twelve sub-items, (3)(a) to (3)(l). Each sub-item applies where applicable, based on your cybersecurity risk assessment under Article 13(2).
The requirement labels use the wording of the regulation. The status and mapping in each row are our assessment. Make sure that they are correct for your product.
| Cite | Requirement | Status | Where it lives |
|---|---|---|---|
| Annex I (1) | Appropriate level of cybersecurity based on the risks“designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks” | You complete | Avocado provides: Lower architectural risk from the immutable rootfs, verified boot, and signed updates. This mapping covers the OS part.You add: Your risk assessment for your product under Article 13(2). Include the OS evidence from this row. |
| Annex I (2) | No known exploitable vulnerabilities“made available on the market without known exploitable vulnerabilities” | You complete | Avocado provides: The build makes an SPDX inventory of each component in your image. A CVE process runs against this inventory. Continuous CVE monitoring and advisory reports for these components are a commercial feature. The open-source build does not block a release on a CVE scan.You add: A CVE process for your application code and your own dependencies. For the OS components, scan the SBOM yourself or subscribe to CVE monitoring. |
| Point (3): risk-dependent sub-items, applied per the Article 13(2) risk assessment | |||
| Annex I (3)(a) | Secure by default configuration“made available on the market with a secure by default configuration… including the possibility to reset the product to its original state” | Configurable | You control the full device configuration in avocado.yaml. You can disable each network service. Factory reset is an A/B re-provision. See Configuration. |
| Annex I (3)(b) | Security updates, including automatic where applicable“ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates… with a clear and easy-to-use opt-out mechanism” | Configurable | TUF-verified updates (Ed25519), A/B partitions with automatic rollback, PKCS#11 hardware-backed signing, and delta compression. Fleet delivery runs through Avocado Connect. You configure Connect and you activate each deployment. As a result, you set the policy for automatic updates and for what an opt-out means for your users. See Atomic Update Architecture. |
| Annex I (3)(c) | Protection from unauthorised access“protection from unauthorised access by appropriate control mechanisms, including… authentication, identity or access management systems, and report on possible unauthorised access” | Configurable | You can configure key-only SSH, account lockout, and password policy in your build. The SSH server is an opt-in extension. A runtime that does not need remote login ships without it. |
| Annex I (3)(d) | Confidentiality of stored, transmitted, and processed data“protect the confidentiality… such as by encrypting relevant data at rest or in transit by state-of-the-art mechanisms” | Configurable | LUKS2 encryption for the writable /var partition. If the target has a TPM or an equivalent security module, the OS seals the key to it and enrolls it on first boot. If the target does not have one, the OS derives the key in software with Argon2id. The OS also enrolls a per-device recovery keyslot that it derives from the SoC UID. Confirm which path your target uses. See Hardware-Backed Encryption. |
| Annex I (3)(e) | Integrity of data, commands, programs, and configuration“protect the integrity… against any manipulation or modification not authorised by the user, and report on corruptions” | OS default | A read-only EROFS rootfs that no process can change at runtime. The OS verifies the SHA-256 of each extension before it merges the extension, and BTRFS checksums protect /var. Corruption events show in the systemd journal. A signed boot chain, with vendor key fuses burned at provisioning, is available on some targets only. Confirm it for your target. See Filesystem Integrity and Secure Boot. |
| Annex I (3)(f) | Data minimisation“process only data… that are adequate, relevant and limited to what is necessary in relation to the intended purpose” | OS default | Minimal base image, no telemetry by default, and isolation per extension. Fleet management is opt-in. |
| Annex I (3)(g) | Availability of essential and basic functions“protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks” | Configurable | A/B rollback, cgroup v2, and a filesystem stack that is safe from power loss are defaults. You can configure resource limits per service, kernel network tuning, and firewall policy in your build. |
| Annex I (3)(h) | Minimise negative impact on other devices or networks“minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks” | Configurable | The base image runs no service that an attacker can use for amplification. It forwards only the traffic that you configure it to forward. You can configure kernel network hardening and egress firewall policy in your build. |
| Annex I (3)(i) | Limit attack surfaces, including external interfaces“designed, developed and produced to limit attack surfaces, including external interfaces” | OS default | You start from an empty image and add only what you declare. There is no set of distribution defaults to audit and remove. Each service, interface, and tool on the device is an extension that you listed in avocado.yaml. |
| Annex I (3)(j) | Exploitation mitigation“reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques” | Configurable | This requirement is about the containment of an exploit. Annex I (2) covers CVE tracking. Each package in the distribution compiles with the toolchain hardening flags on (stack protector, FORTIFY_SOURCE, PIE, RELRO). The rootfs is read-only, and the control plane is written in Rust. You can configure systemd sandboxing per service in your build. |
| Annex I (3)(k) | Security-related logging and monitoring“provide security-related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user” | Configurable | The systemd journal is on by default. It records boot, service, authentication, and integrity events. You can configure persistence, sealing, and size limits. If you need a rule-driven audit trail, the Linux audit daemon is available as a package. |
| Annex I (3)(l) | Secure data deletion and secure data transfer“provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner” | OS default | Factory reset through A/B re-provisioning, ephemeral overlay layers, and LUKS cryptographic erase for encrypted partitions. |
Annex I Part II: vulnerability handling
Part II gives the manufacturer eight process obligations. The OS supplies the update and SBOM tools.
| Cite | Requirement | Status | Where it lives |
|---|---|---|---|
| Part II (1) | Identify and document vulnerabilities and components, including an SBOM“identify and document vulnerabilities and components… including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies” | You complete | Avocado provides: SPDX generation is on by default in the distribution build. `avocado sbom` makes an SPDX 3.0.1 document for exactly the packages that your project installed.You add: The SBOM for your application, merged with ours into one product SBOM. |
| Part II (2) | Address and remediate without delay; separate security from functionality updates where feasible“address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates” | You complete | Avocado provides: Security updates for the OS components. Updates are per extension, so a security update can ship without a functional change.You add: The remediation process for your product: triage, priority, and a fix that ships without delay. The OS supplies the distribution mechanism, and you supply the process that uses it. |
| Part II (3) | Apply effective and regular tests and reviews“apply effective and regular tests and reviews of the security of the product with digital elements” | You complete | Avocado provides: Documented test suites that run in CI, and automated tests on hardware.You add: Security tests for your application, such as penetration tests, fuzzing, and dependency audits, on the schedule that you commit to. |
| Part II (4) | Publicly disclose information about fixed vulnerabilities“publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product… affected, the impacts… their severity and information helping users to remediate” | You complete | Avocado provides: The release changelog lists each security fix and the upstream advisory that it resolves. Structured advisories (severity, affected versions, remediation guidance) are part of the commercial CVE monitoring feature.You add: Advisories for the vulnerabilities in your application. For OS components, refer to our advisories. |
| Part II (5) | Coordinated vulnerability disclosure policy“put in place and enforce a policy on coordinated vulnerability disclosure” | You complete | You add: A coordinated vulnerability disclosure policy for your product. |
| Part II (6) | Facilitate reporting, including a contact address for vulnerability reports“take measures to facilitate the sharing of information about potential vulnerabilities… including by providing a contact address for the reporting of the vulnerabilities discovered in the product” | You complete | You add: A SECURITY.md, a security.txt at /.well-known/, and a monitored contact address for vulnerability reports. |
| Part II (7) | Securely distribute updates“provide for mechanisms to securely distribute updates… to ensure that exploitable vulnerabilities are fixed or mitigated in a timely manner” | OS default | TUF metadata chain (timestamp → snapshot → targets) that avocadoctl verifies, Ed25519 signatures, PKCS#11 hardware signing, and A/B rollback if verification fails. |
| Part II (8) | Free, timely updates with advisory messages“where security patches or updates are available… they are disseminated without delay and free of charge, accompanied by advisory messages providing users with the relevant information” | Configurable | The OS gives you a signed distribution channel, and the changelog documents the security content of each release. You control if your updates get to your users without delay and free of charge. This depends on the deployments that you activate and the terms that you set. |
Article 14: reporting to your CSIRT and ENISA
Article 14 has two separate reporting obligations. Article 14(1) covers actively exploited vulnerabilities. Article 14(2) covers severe incidents having an impact on product security. For both, you send an early warning within 24 hours and a notification within 72 hours. The deadline for the final report is different for each.
| Deadline | Report | Applies to |
|---|---|---|
| Within 24 hours | Early warning | Both vulnerabilities (14(1)) and severe incidents (14(2)) |
| Within 72 hours | Vulnerability or incident notification, with more detail | Both vulnerabilities and incidents |
| 14 days / 1 month | Final report | Vulnerabilities: 14 days after a corrective measure is available. Incidents: 1 month after the 72-hour notification. |
Send notifications to the CSIRT that your Member State designates as coordinator under the NIS2 framework. ENISA gets them through the single reporting platform. In some areas, the regulation gives lighter treatment to microenterprises and small enterprises. Find out if this applies to you. In our reading of Article 13(6), you must report vulnerabilities that you find in components, including open-source components, to the entity that maintains the component. Before you rely on these deadlines, compare them with the text of Article 14.
Annex VII: the technical documentation
Annex VII lists the contents of the technical documentation. You must produce this documentation and keep it for the period that the regulation sets. This period is usually at least ten years after the product goes on the market, or the support period if that is longer. Avocado OS supplies inputs to some of these items, but you write each item.
| Annex VII item | Owner | How Avocado OS feeds into it |
|---|---|---|
| General description of the product | You complete | Your hardware, application, intended use, and deployment environment. |
| Design, development, and production information | Avocado + you | Refer to the Avocado OS architecture, and add the design of your product. |
| Cybersecurity risk assessment (Article 13(2)) | You complete | You write it. It determines which Annex I (3)(a) to (l) items apply to your product. |
| List of essential cybersecurity requirements applied (Annex I) | Avocado + you | Use this page as evidence for the OS part. |
| Harmonised standards or certification schemes applied | You complete | Cite the standards that your conformity relies on. When the EU publishes harmonised CRA standards, they will refer to these requirements. |
| Conformity assessment results | You complete | The Module A internal control report, or a higher module, from your assessment. |
| EU Declaration of Conformity (Annex V) | You complete | Your signed declaration. It identifies the product, the requirements that apply, and the assessment route. |
| Vulnerability handling process description (Annex I Part II) | You complete | Your CVD policy, security contact, and response process. The manufacturer owns all of it. |
| Software Bill of Materials | Avocado + you | The SPDX SBOM for Avocado OS, merged with your application SBOM. |
| Information on the defined support period (Article 13(8)) | You complete | Your support period. Recital 61 expects at least five years, unless the expected product lifetime is shorter. Align it with the support commitment for Avocado OS releases. |
Related reading
The pages that follow document the architecture behind each mapping on this page.
Security architecture
- Secure Boot: the hardware root of trust for Annex I (3)(a) and (3)(e)
- Filesystem Integrity: dm-verity and the immutable rootfs for (3)(a), (3)(e), and (3)(i)
- Hardware-Backed Encryption: LUKS and hardware key storage for (3)(d) and (3)(l)
- Atomic Update Architecture: A/B updates and rollback for (3)(b) and Part II (7) and (8)
- Production-Ready Features: SBOM generation, CVE cadence, and manufacturing security
How it works in practice
- OTA Updates: the signed update path that you operate for (3)(b) and Part II (7) and (8)
- Provisioning: factory provisioning and re-provisioning for (3)(a) and (3)(l)
- Package Feeds: the source of the CVE patch cadence for Annex I (2)
- Lockfiles and Build Stamps: deterministic builds, so that each SBOM traces to one build, for Part II (1)
References
- Regulation (EU) 2024/2847, Official Journal of the European Union, 20 November 2024. Full text on EUR-Lex
- Consolidated version (20 November 2024)
This page gives our good-faith reading of Regulation (EU) 2024/2847. It maps the technical capabilities of the OS to that reading. Harmonised standards, official guidance, and enforcement practice are still in development, and they will change how people read the CRA. Nothing here guarantees compliance. You are responsible for the classification of your product, the conformity assessment route, and the requirements that apply to it. For these decisions, get advice from qualified legal counsel.