Cyber Resilience Act
Avocado OS is built to help you place products on the EU market.
This page maps the requirements of Regulation (EU) 2024/2847 — the Cyber Resilience Act — to what the operating system provides, what it lets you configure, and what stays in your scope as the manufacturer. The Annex I matrices quote the regulation's own wording beneath each requirement, and every section carries its numbering and citations, so you can check the mappings against the text and against your own analysis.
Jump to:
- Where Avocado OS sits inside the regulation — classification, conformity route, manufacturer status, penalties
- Timeline — the four phased dates, and which are already in force
- Annex I Part I — product properties — the fourteen technical requirements, mapped
- Annex I Part II — vulnerability handling — the eight process obligations, and who owns each
- Article 14 — reporting — the 24-hour / 72-hour / final-report cadence
- Annex VII — technical documentation — the file your conformity assessment asks for
- What stays in your scope — the work no operating system can do for you
Where Avocado OS sits inside 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. It was published in the Official Journal on 20 November 2024 and entered into force on 10 December 2024.
Classification
Annex III lists operating systems among the Important Class I categories. On our reading, Avocado OS as an embedded Linux operating system placed on the EU market is likely to fall into this class — though final classification depends on your product and its intended use. (Annex III)
Conformity assessment route
Important Class I manufacturers may be able to use Module A (internal control) where harmonised standards or a European cybersecurity certification scheme are applied. Provisions for free and open-source software may also affect the available route. Confirm which route applies to your product. (Article 32, Annex VIII)
Manufacturer status
Article 24 introduces a lighter regime for non-commercial open source software stewards. A commercial entity placing a product on the EU market under its own name will, in most cases, be a manufacturer under Article 13 — carrying the conformity assessment, technical documentation, and Article 14 reporting obligations. (Articles 13 and 24)
Penalties
As we read Article 64, the highest tier is set for non-compliance with the Annex I essential requirements and the obligations in Articles 13 and 14: up to €15M or 2.5% of worldwide annual turnover, whichever is higher. Other obligations reach €10M / 2%, and incorrect or misleading information to authorities €5M / 1%. (Article 64)
Timeline
The CRA applies in phases. Milestones already in force are struck through below.
| Date | Milestone |
|---|---|
| 10 December 2024 | Entry into forceIn forceTwenty days after publication in the Official Journal. The clock starts on the phased application below. |
| 11 June 2026 | Notified bodies framework (Chapter IV)In forceNotified body designation and operation apply. Relevant only if your conformity route requires a notified body. |
| 11 September 2026 | Article 14 reportingIn forceActively exploited vulnerabilities and severe incidents must be notified on the cadence below. The capability to do that — triage, on-call, and reporting templates — needs to be in place from this date. |
| 11 December 2027 | Full applicationUpcomingAll Annex I requirements enforceable. Conformity assessment complete and CE marking affixed before the product is placed on the EU market. |
Article 14 reporting has been enforceable since 11 September 2026 — fifteen months ahead of the Annex I requirements. It is an organizational capability rather than a technical one, so no operating system can stand it up on your behalf. If you are placing products on the EU market today, being able to identify a reportable event and notify your designated coordinator CSIRT and ENISA inside 24 hours is the gap to close first.
Annex I Part I — product properties
Part I carries fourteen requirements: an umbrella risk-based design obligation in point (1), a stand-alone "no known exploitable vulnerabilities" in point (2), and twelve risk-dependent sub-items in point (3)(a)–(3)(l) that apply where applicable based on your cybersecurity risk assessment under Article 13(2).
The labels below follow the regulation's wording. The status and mapping in each row are Avocado's assessment, which you should verify for your own 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: Architectural risk reduction — immutable rootfs, verified boot, signed updates — plus this mapping covering the OS portion.You add: Your product-specific risk assessment under Article 13(2), incorporating the OS evidence above. |
| Annex I (2) | No known exploitable vulnerabilities“made available on the market without known exploitable vulnerabilities” | You complete | Avocado provides: The build emits an SPDX inventory of every component in your image, which is what any CVE process has to run against. Continuous CVE monitoring and advisory reporting across those components is a commercial feature; the open-source build does not gate a release on a CVE scan.You add: A CVE process covering your application code and your own dependencies, and a decision on whether to scan the SBOM yourself or subscribe to 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” | OS default | The base image ships no listening network services — SSH, fleet management, and remote access are all opt-in extensions. Root login is locked, the rootfs is read-only EROFS, and factory reset is an A/B re-provision. See Filesystem Integrity. |
| 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, which you configure and from which you activate each deployment — so whether updates are automatic, and what opting out means for your users, is your policy rather than a default. 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 | Key-only SSH, account lockout, and password policy are all configurable in your build. The SSH server itself is an extension you opt into, so a runtime that needs no remote login ships without one. |
| 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. Where the target carries a TPM2 or equivalent security module the key is sealed to it and enrolled on first boot; where it does not, software key derivation is the fallback. A per-device recovery keyslot derived from the SoC UID is enrolled alongside it. Confirm which path your target takes. 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 nothing at runtime can modify, SHA-256 verification of every extension before it is merged, and BTRFS checksums on /var. Corruption surfaces in the systemd journal. A signed boot chain, with vendor key fuses burned at provisioning, is available per target rather than everywhere — confirm it for yours. 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, per-extension isolation. 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 power-loss-safe filesystem stack are defaults. Per- service resource limits, kernel network tuning, and firewall policy are all configurable 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 nothing that can be recruited as an amplification vector, and forwards no traffic it was not configured to forward. Kernel network hardening and egress firewall policy are configurable 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 image with nothing in it and add only what you declare. There is no distribution default set to audit away: every service, interface, and tool on the device is an extension you named in avocado.yaml. |
| Annex I (3)(j) | Exploitation mitigation“reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques” | Configurable | This is about containing an exploit, not tracking CVEs — Annex I (2) covers that. Every package in the distribution is compiled with the toolchain hardening flags on (stack protector, FORTIFY_SOURCE, PIE, RELRO), the rootfs an exploit lands in is read-only, and the control plane is written in Rust. Per-service systemd sandboxing is configurable 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 there out of the box, capturing boot, service, authentication, and integrity events; persistence, sealing, and size limits are configurable. The Linux audit daemon is available as a package when you need a rule-driven audit trail on top. |
| 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 via A/B re-provisioning, ephemeral overlay layers, LUKS cryptographic erase for encrypted partitions. |
Five of the fourteen are properties of the operating system itself and need no work from you. Seven are capabilities the OS supports but whose policy is yours to set, because the right setting depends on what your product does and who operates it. The two that remain — the Article 13(2) risk assessment and vulnerability tracking for your own application code — are yours entirely.
Annex I Part II — vulnerability handling
Part II places eight process obligations on the manufacturer. These are organizational, not technical — the OS carries the update and SBOM machinery, but the policies and the people are yours.
Be careful with the assumption that you can cite an upstream policy instead of writing your own. The OS gives you SBOM generation and a signed update channel; CVE monitoring and structured security advisories for the components in your image are available as a commercial feature. The policies and the people — your CVD policy, your security contact, your response process — are yours either way, and the rows below say which is which.
| 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, and `avocado sbom` emits an SPDX 3.0.1 document for exactly what your project installed.You add: Your application's SBOM, merged with ours into the combined 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, and extension-level granularity so a security update can ship without carrying a functional change alongside it.You add: The remediation process for your product — triage, prioritisation, and shipping the fix without delay. A distribution mechanism is not the same as a 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, plus hardware-backed testing automation.You add: Your application's security testing — penetration testing, fuzzing, dependency audit — on the cadence 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: Security fixes are called out in the release changelog, naming the upstream advisory each one resolves. Structured advisories — severity, affected versions, remediation guidance — come with the commercial CVE monitoring feature.You add: Your product's advisories for application-level vulnerabilities; reference ours for OS components. |
| 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) verified by avocadoctl, Ed25519 signatures, PKCS#11 hardware signing, and A/B rollback on verification failure. |
| 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 security content of each release is documented in the changelog. Whether your updates reach your users without delay and free of charge depends on the deployments you activate and the terms you set — that half is yours. |
Article 14 — reporting to your CSIRT and ENISA
Article 14 imposes two separate reporting obligations: actively exploited vulnerabilities under Article 14(1), and severe incidents having an impact on product security under Article 14(2). Both follow a 24-hour early warning and a 72-hour notification. The final report timing differs.
| 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, in fuller detail | Both vulnerabilities and incidents |
| 14 days / 1 month | Final report | 14 days after a corrective measure is available (vulnerabilities); 1 month after the 72-hour notification (incidents) |
Notifications go to the CSIRT designated as coordinator under the NIS2 framework in your Member State; ENISA receives them through the single reporting platform. The regulation provides for lighter treatment of microenterprises and small enterprises in some respects — check how that applies to you. Vulnerabilities discovered in components, including open-source components, are (as we read Article 13(6)) to be reported to the entity maintaining the component. Confirm the exact cadences against Article 14 before relying on them.
Annex VII — the technical documentation
Annex VII names the contents of the technical documentation you must produce and retain for the period the regulation sets — generally at least ten years after the product is placed on the market, or the support period if that is longer. Avocado OS is an input to several of these items, not a substitute for any of them.
| 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 | Cite the Avocado OS architecture; add your product-specific design. |
| Cybersecurity risk assessment (Article 13(2)) | You complete | Yours to author. It determines which Annex I (3)(a)–(l) items apply to your product. |
| List of essential cybersecurity requirements applied (Annex I) | Avocado + you | Use this page as supporting evidence for the OS portion. |
| Harmonised standards or certification schemes applied | You complete | Cite the standards your conformity rests on. As EU harmonised CRA standards publish, they reference these requirements. |
| Conformity assessment results | You complete | Module A internal control report, or higher, produced as part of your assessment. |
| EU Declaration of Conformity (Annex V) | You complete | Your signed declaration identifying the product, the applicable requirements, and the assessment route. |
| Vulnerability handling process description (Annex I Part II) | You complete | Your CVD policy, security contact, and response process. Manufacturer-owned end to end. |
| 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 indicates an expectation of at least five years unless the expected product lifetime is shorter; align it with the Avocado OS release support commitment. |
What stays in your scope
Annex I Part II, Article 13(8), and Article 14 are organizational obligations. The OS supplies concrete technical inputs you can fold into them — the SPDX document, the signed update artifacts, the changelog — but the processes, the policies, and the people are yours. None of it is discharged by citing an upstream project.
Cybersecurity risk assessment
Required by Article 13(2). It determines which Annex I (3) items apply to your product and how rigorously, and it is documented in your technical documentation. (Article 13(2), Annex VII)
Product SBOM
A combined SBOM covering your application dependencies plus the SPDX document Avocado OS generates. The CRA requires top-level dependencies at minimum. (Annex I Part II (1))
Vulnerability handling and CVD policy
Your CVD policy, SECURITY.md, security.txt, advisory format, and response SLAs — for your
product as a whole. These obligations sit with you as the manufacturer and are not discharged by
citing an upstream policy. (Annex I Part II (4)–(6))
Support period definition
Specify and publish a support period, communicated to the user before purchase. Recital 61 indicates an expectation of at least five years unless the expected product lifetime is shorter. (Article 13(8))
Article 14 reporting capability
Identify your designated coordinator CSIRT, run the 24-hour / 72-hour / 14-day-or-1-month cadence, and train an on-call rotation. Enforceable since 11 September 2026. (Article 14(1)–(2))
Conformity assessment and CE marking
Complete the assessment route that applies to your product, sign the EU Declaration of Conformity, and affix the CE marking before placing the product on the market. (Article 32, Annex V, Annex VIII)
Related reading
Nothing on this page is a claim without a source. The architecture behind each mapping is documented across the Security section, the developer reference, and the Field Notes.
Security architecture
- Secure Boot — the hardware root of trust behind Annex I (3)(a) and (3)(e)
- Filesystem Integrity — dm-verity and the immutable rootfs behind (3)(a), (3)(e), and (3)(i)
- Hardware-Backed Encryption — LUKS and hardware key storage behind (3)(d) and (3)(l)
- Atomic Update Architecture — A/B updates and rollback behind (3)(b) and Part II (7)–(8)
- Production-Ready Features — SBOM generation, CVE cadence, and manufacturing security
How it works in practice
- OTA Updates — the signed update path you operate for (3)(b) and Part II (7)–(8)
- Provisioning — factory provisioning and the re-provisioning route behind (3)(a) and (3)(l)
- Package Feeds — where the CVE patch cadence behind Annex I (2) comes from
- Lockfiles and Build Stamps — the build determinism that makes an SBOM attributable for Part II (1)
Field Notes
- Two boots to trust an update — how A/B rollback makes a bad release survivable, the evidence behind (3)(b) and (3)(g)
- Pull the flash off our i.MX93 and you get ciphertext — LUKS2
/varand a TPM2-sealed keyslot verified on i.MX93 hardware, the evidence behind (3)(d). The note is explicit about which controls in it are verified and which are still design, which is the standard to hold any compliance claim to
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 reflects Avocado's good-faith reading of Regulation (EU) 2024/2847 and maps the OS's technical capabilities to that reading. The CRA's interpretation will continue to be shaped by harmonised standards, official guidance, and enforcement practice that are still developing. Nothing here guarantees compliance. How your product is classified, which conformity assessment route applies, and which requirements apply to it are determinations you are responsible for making — ideally with qualified legal counsel.