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.
Key Dates
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 Which compliance path must I choose?) with fewer documentation and assurance requirements.
Category |
Short description |
Example Zephyr Use Cases |
|---|---|---|
Default |
Products with digital elements that are not listed as “important” or “critical”. |
|
Important (Class I) |
Higher-risk products, often consumer-facing, performing security- or access-relevant functions. |
|
Important (Class II) |
Higher-risk products used in enterprise/industrial/infra contexts or with privileged network roles. |
|
Critical |
Products whose compromise could severely impact critical infrastructure or essential services. |
|
Core Functionality vs. Integration
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.
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.
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 [1] 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 [1] audits your Quality Management System (QMS) governing design, production, and testing.
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).
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.
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. |
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 Software bill of materials: 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, What are the 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 Security Vulnerability 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 Security Vulnerability 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 Zephyr Security Overview
Vulnerability reporting process: Security Vulnerability Reporting
Secure coding guidelines: Secure Coding
- 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
Implementing Regulation (EU) 2025/2392 (Technical descriptions of important and critical product categories)
Standards and Technical Specifications
Relevant existing standards:
ETSI EN 303 645 - Cyber Security for Consumer Internet of Things: Baseline Requirements
ETSI is developing harmonized standards in response to the CRA Standardisation Request (M/606). 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.