.. _cra_faq:

EU Cyber Resilience Act (CRA) #############################

.. warning:: This document is for informational purposes only and does not constitute legal advice. Consult with your legal counsel for compliance guidance specific to your situation.

Overview

The Cyber Resilience Act ([CRA24]_) is an EU regulation that establishes cybersecurity requirements for products with digital elements (PDEs) placed on the EU market. It entered into force on December 10, 2024.

.. admonition:: Key Dates :class: important

June 11, 2026: Assessment bodies operational
September 11, 2026: Manufacturers must report vulnerabilities and incidents
December 11, 2027: Full regulation applies

This page explains how the CRA relates both to manufacturers using Zephyr in commercial products, and to the Zephyr Project itself in its role as an open-source software steward.

For manufacturers, the CRA imposes essential cybersecurity requirements (Annex I Part I) along with vulnerability handling and reporting obligations (Annex I Part II). For the Zephyr Project as an open-source software steward, the CRA introduces a tailored set of obligations, including maintaining a cybersecurity policy, reporting actively exploited vulnerabilities and severe incidents, and cooperating with market surveillance authorities.

For Manufacturers Using Zephyr

Does the CRA apply to my product?

The CRA applies if you place a product with digital elements (PDE) on the EU market for commercial purposes. This includes hardware devices with embedded software, and standalone software products.

Which category does my product belong to?

The CRA classifies products into categories based on risk: Important Products (Annex III) and Critical Products (Annex IV). Products not listed in either category are considered Default products and have lower requirements.

For example, default products can typically rely on self-assessment (see :ref:compliance_path) with fewer documentation and assurance requirements.

.. list-table:: :header-rows: 1 :widths: 15 25 60

- Category
- Short description
- Example Zephyr Use Cases
- Default
- Products with digital elements that are not listed as "important" or "critical".
- - Wi-Fi smart bulb or switch (e.g., running Matter over Thread/Wi-Fi).
  - Wearable activity tracker or smartwatch for personal wellness.
  - Bluetooth LE audio accessory or wireless sensor tag.
- Important (Class I)
- Higher-risk products, often consumer-facing, performing security- or access-relevant functions.
- - Smart door lock or access control reader for residential use.
  - Smart home hub or router managing network traffic.
  - Connected alarm system or security sensor.
- Important (Class II)
- Higher-risk products used in enterprise/industrial/infra contexts or with privileged network roles.
- - Industrial Programmable Logic Controller (PLC) or robot controller.
  - Micro-controllers with Secure Enclave/TEEs used for device identity.
  - Industrial IoT gateway performing edge processing.
- Critical
- Products whose compromise could severely impact critical infrastructure or essential services.
- - Smart electricity meter or water meter with remote shut-off.
  - Hardware Security Module (HSM) or smartcard firmware.
  - Safety-critical sensors used in energy or transport grids.

.. admonition:: Core Functionality vs. Integration :class: important

Classification is determined by the core functionality of the final product, not by the individual components it integrates (Article 7_).

Integrating an important or critical component (e.g., a secure element, embedded browser) into another product does not automatically render that product important or critical.
A product that can perform the functions of an important/critical category but whose core functionality is different is not considered to have that core functionality.

Examples:

If you build a network firewall using Zephyr, the core function is security, making the product an Important Product (Class II).
If you build a coffee machine using Zephyr, and you utilize Zephyr's networking stack features to protect the device, the core function remains making coffee. This is a "default" product.

In a nutshell, using security-critical Zephyr features (like cryptography or secure boot) in a device does not elevate that device to a higher risk class.

For detailed classification, see Annex III_ and Annex IV. The full list of product categories with technical descriptions is provided in Implementing Regulation (EU) 2025/2392.

.. _compliance_path:

Which compliance path must I choose?

The CRA defines different conformity assessment procedures based on your product category. You must choose the path that corresponds to your classification and reliance on harmonized standards.

.. list-table:: CRA Product Categories & Assessment Routes :widths: 20 55 25 :header-rows: 1

- Category
- Conformity Assessment Procedure
- Third-Party Audit?
- Default
- Module A (Internal Control). Self-assessment by the manufacturer.
- No
- Important Class I
- Module A ONLY IF harmonized standards are fully applied. Otherwise: Module B + Module C, or Module H.
- Yes, if standards not fully used
- Important Class II
- Module B + Module C, or Module H. (Self-assessment is NOT allowed).
- Yes (Mandatory)
- Critical
- European Cybersecurity Certification (e.g., EUCC) or Module B + Module C + Module H (pending delegate acts).
- Yes (Mandatory)

The "Modules" refer to specific assessment procedures defined in Decision No 768/2008/EC_ ("New Legislative Framework") and adapted by the CRA in Annex VIII_:

Module A_ (Internal production control): You create the technical documentation, perform the risk assessment, and declare conformity yourself. No external auditor is required.
Module B_ (EC-type examination) + Module C_ (Conformity to type): A Notified Body [#nb]_ examines the technical design (Module B) and issues a certificate. You then ensure production conforms to that type (Module C).
Module H_ (Full Quality Assurance): A Notified Body [#nb]_ audits your Quality Management System (QMS) governing design, production, and testing.

.. [#nb] Notified Bodies will become operational by June 11, 2026.

What are my main obligations as a manufacturer?

The CRA defines manufacturer obligations primarily in Article 13_ (product requirements and due diligence) and Article 14_ (vulnerability handling and reporting). Regardless of a product's classification, the following core obligations apply to all manufacturers of products with digital elements.

Risk assessment Assess and document cybersecurity risks throughout the product lifecycle.

Due diligence Exercise due diligence when integrating third-party components (including open-source software like Zephyr).

Vulnerability handling Handle vulnerabilities for at least 5 years (support period), including receiving reports and applying updates.

Incident reporting Report actively exploited vulnerabilities affecting Zephyr, as well as severe incidents affecting the project's infrastructure.

Technical documentation Create documentation per Article 31_ and Annex VII_.

Conformity assessment Assess conformity per Article 32_ and Annex VIII_.

CE marking Affix CE mark and draw up EU declaration of conformity.

What are the penalties for non-compliance?

Up to EUR 15,000,000 or 2.5% of worldwide annual turnover (Article 13_ & Article 14_ violations).
Up to EUR 10,000,000 or 2% of turnover (violations of other obligations).

.. _cra_vulnerability_reporting_obligations:

What are the vulnerability reporting obligations?

The CRA distinguishes between "ordinary" vulnerabilities (handled through your normal vulnerability management process) and cases that trigger strict notification timelines under Article 14_: actively exploited vulnerabilities and severe incidents.

The tables below summarize the minimum reporting steps.

.. list-table:: Actively exploited vulnerabilities (Article 14_ (1) and (2)) :header-rows: 1 :widths: 20 20 60

- Step
- Deadline
- Content (minimum)
- Early warning
- Within 24 hours of becoming aware
- Notify via the single reporting platform to your CSIRT coordinator and ENISA that an actively exploited vulnerability affects your product. Indicate, where known, in which Member States the product is available.
- Vulnerability notification
- Within 72 hours of becoming aware
- Provide general information on the affected product, the general nature of the exploit and the vulnerability, corrective or mitigating measures already taken, and measures users can take. Indicate, where applicable, how sensitive you consider the notified information to be.
- Final report
- No later than 14 days after a corrective or mitigating measure is available
- Describe the vulnerability, its severity and impact, any information on malicious actors exploiting it (if available), and details on the security update or other corrective measures made available.

.. list-table:: Severe incidents (Article 14_ (3) through (6)) :header-rows: 1 :widths: 20 20 60

- Step
- Deadline
- Content (minimum)
- Early warning
- Within 24 hours of becoming aware
- Notify via the single reporting platform to your CSIRT coordinator and ENISA that a severe incident impacts the security of your product. Indicate whether it is suspected to be caused by unlawful or malicious acts and, where known, in which Member States the product is available.
- Incident notification
- Within 72 hours of becoming aware
- Provide general information on the nature of the incident, an initial assessment (including impact/severity as known at the time), corrective or mitigating measures already taken, and measures users can take. Indicate, where applicable, how sensitive you consider the notified information to be.
- Final report
- Within 1 month after the incident notification
- Provide a detailed description of the incident, including severity and impact, the type of threat or likely root cause, and applied and ongoing mitigation measures.

How can I obtain an SBOM (Software Bill of Materials)?

Zephyr can automatically generate SBOMs for your application using the west spdx command.

See :ref:west-spdx for details on how to configure and use this tool.

How should I handle Zephyr vulnerabilities?

As a manufacturer integrating Zephyr into a product, you remain responsible for vulnerability management and, where applicable, CRA reporting. Zephyr provides vulnerability information, but you must assess and act on it for your own product.

A practical workflow is:

Stay informed. Register to the Zephyr Vulnerability Alert Registry_ to receive notifications when vulnerabilities are disclosed.
Assess impact. For each advisory, use your SBOM and configuration to determine whether the affected Zephyr component is present, reachable, and security-relevant in your product.
Plan remediation. Decide on the appropriate response (e.g., apply a patch, adjust configuration, ...).
Deploy fixes. Integrate, test, and roll out the chosen fix, and update your SBOM and product documentation as needed.
Meet reporting obligations. If the vulnerability affects your product and is actively exploited, or leads to a severe incident, report it in line with the Article 14_ timelines and as per the previous section, :ref:cra_vulnerability_reporting_obligations.

What timelines does Zephyr follow for vulnerability handling?

Zephyr operates its own PSIRT process with target timelines for triage, notification, and disclosure. These are project timelines, not legal deadlines for manufacturers.

Your CRA reporting obligations as per Article 14_ are triggered by when you become aware that your product is affected by an actively exploited vulnerability or a severe incident. This can be earlier than some of the Zephyr milestones below, meaning you might have to send an early warning or incident report even before a Zephyr fix is available or before public disclosure.

Zephyr uses private GitHub security advisories and an embargo period (at most 90 days) to coordinate fixes and disclosure. While the full process is described in :ref:reporting, the key milestones are:

Within 7 days: PSIRT feedback to initial reporter.
Within 30 days: Manufacturers notified via alert registry and fix made available from the project.
Up to 90 days total: Security-sensitive vulnerabilities are made public after embargo period.

Do I need to report vulnerabilities I find in Zephyr?

Yes, under Article 13(6)_, if you discover a vulnerability in a component (including Zephyr) integrated into your product, you must report it. What's more, if you develop a fix for that vulnerability, you must also share the relevant code or documentation. See :ref:reporting.

Additionally, consider voluntary reporting to CSIRT or ENISA per Article 15_.

For Zephyr as an Open Source Steward

What is Zephyr's role under the CRA?

Zephyr is an "open-source software steward" under Article 3_ (14): a legal person that systematically provides sustained support for developing PDEs intended for commercial activities.

Zephyr's obligations under Article 24:

Cybersecurity policy Document security policies and vulnerability handling.

Cooperation Work with market surveillance authorities to mitigate risks.

Incident reporting Report actively exploited vulnerabilities for the project and severe incidents affecting Zephyr's infrastructure (to the extent Zephyr is involved).

Does the CRA apply to Zephyr contributors?

No. The CRA does not apply to individual contributors to Zephyr (Recital 18_).

Contributors developing features or fixing bugs are not subject to CRA obligations.

How is Zephyr meeting its steward obligations?

Article 24(1)_: Security policy (Complete)

Documented at :ref:security-overview
Vulnerability reporting process: :ref:reporting
Secure coding guidelines: :ref:secure code

Article 24(2)_: Cooperation with authorities (In Progress)

Registered CVE Numbering Authority (CNA) since 2017
Active Zephyr Project Security Incident Response Team (PSIRT)
In Progress: Identifying CSIRT coordinator for EU

Article 14(1)_ & Article 14(3)_: Incident reporting (In Progress)

In Progress: Determining if NVD processes work for CSIRT/ENISA reporting
Plan to align with EU reporting requirements

Article 14(8)_: User notification (Complete)

Vulnerability Alert Registry for manufacturers and integrators
CVE publication and security advisories

Article 52(3)_: Corrective actions (Complete)

Established processes in place with CVE authorities
Timely response through PSIRT

External Resources

Official CRA documentation

EU CRA Regulation 2024/2847 <https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847>_
Implementing Regulation (EU) 2025/2392_ (Technical descriptions of important and critical product categories)
ENISA CRA Requirements-Standards Mapping <https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping>_
European Commission CRA FAQ <https://digital-strategy.ec.europa.eu/en/faqs/cyber-resilience-act-questions-and-answers>_

Standards and Technical Specifications

Relevant existing standards:

ETSI EN 303 645 <https://www.etsi.org/deliver/etsi_en/303600_303699/303645/>_ - Cyber Security for Consumer Internet of Things: Baseline Requirements

ETSI is developing harmonized standards in response to the CRA Standardisation Request (M/606) <https://ec.europa.eu/growth/tools-databases/enorm/mandate/606_en>_. Public draft standards include product-specific requirements for:

Operating Systems (prEN 304 626)
Browsers (prEN 304 617)
Password Managers (prEN 304 618)
Firewalls (prEN 304 636)

For the complete list of draft standards and participation in public consultations, see the ETSI Cyber Resilience Act Portal <https://docbox.etsi.org/cyber/CYBER/Open>_.

Educational resources

Linux Foundation: Understanding the EU CRA <https://training.linuxfoundation.org/express-learning/understanding-the-eu-cyber-resilience-act-cra-lfel1001>_
Linux Foundation CRA Readiness Report <https://www.linuxfoundation.org/research/cra-readiness>_
Linux Foundation CRA Compliance Best Practices <https://www.linuxfoundation.org/research/cra-compliance-best-practices>_
OpenSSF CRA Guidance <https://openssf.org/public-policy/eu-cyber-resilience-act/>_

Zephyr-specific resources

:ref:security-overview
:ref:reporting
Zephyr Vulnerability Alert Registry_
:ref:Zephyr Vulnerabilities <vulnerabilities>

.. _Decision No 768/2008/EC: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008D0768 .. _Module A: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008D0768#d1e41-98-1 .. _Module B: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008D0768#d1e288-98-1 .. _Module C: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008D0768#d1e439-98-1 .. _Module H: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32008D0768#d1e1719-98-1

.. _CRA Requirements-Standards Mapping: https://www.enisa.europa.eu/publications/cyber-resilience-act-requirements-standards-mapping

.. _Recital 18: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#rct_18

.. _Annex I Part I: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_I .. _Annex I Part II: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_I .. _Annex III: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_III .. _Annex IV: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_IV .. _Annex VII: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_VII .. _Annex VIII: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ:L_202402847#anx_VIII

.. _Implementing Regulation (EU) 2025/2392: https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32025R2392

.. _Zephyr Vulnerability Alert Registry: https://www.zephyrproject.org/vulnerability-registry/