Short answer
The Cyber Resilience Act (CRA) is an EU regulation (Regulation EU 2024/2847) that mandates cybersecurity requirements for all software and hardware products placed on the European market. It entered into force in December 2024, with key reporting obligations starting September 2026 and full compliance required by December 2027. Any product we ship to the EU — including those built on open source components — falls under its scope.
Detailed explanation
What is the CRA?
The Cyber Resilience Act is a horizontal EU cybersecurity regulation designed to ensure that software and hardware products are built and maintained with security in mind throughout their entire lifecycle. It applies to all “products with digital elements” (PDE) placed on the European market — broadly defined as any software, firmware, or hardware product with a digital component, including mobile apps, operating systems, IoT devices, and networked software.
The CRA covers the full supply chain: manufacturers, importers, and distributors are all in scope. This is not limited to European companies — any organization placing a product on the EU market, regardless of where it is based, must comply.
Key compliance deadlines
Three dates shape compliance planning:
| Date | Obligation |
|---|---|
| 10 December 2024 | CRA entered into force (Regulation EU 2024/2847 published) |
| 11 September 2026 | Vulnerability and incident reporting obligations become mandatory |
| 11 December 2027 | Full compliance required: secure-by-design, conformity assessment, CE marking, SBOM |
⚠️ The September 2026 deadline is closer than it appears and is often underestimated. To report actively exploited vulnerabilities by that date, you must already have SBOMs and a continuous vulnerability monitoring process in place — which takes months to implement correctly.
What the CRA requires from manufacturers
Organizations shipping products to the EU market must meet the following obligations:
Secure-by-design Products must be designed with security as a baseline, not an afterthought. This includes minimizing the attack surface, shipping with secure default configurations, and ensuring data is protected in transit and at rest.
Vulnerability management throughout the lifecycle Manufacturers must establish and maintain processes to identify, track, and remediate vulnerabilities for the supported lifetime of the product (minimum 5 years). This explicitly includes vulnerabilities in third-party open source components integrated into the product.
Software Bill of Materials (SBOM) Manufacturers must produce a machine-readable SBOM covering at minimum all direct and transitive open source and third-party dependencies. The SBOM does not have to be made public but must be available to authorities upon request.
Incident and vulnerability reporting (from September 2026) When an actively exploited vulnerability or a severe security incident is detected, manufacturers must report:
- An early warning within 24 hours to ENISA and the relevant national CSIRT.
- A full notification within 72 hours.
- A final report within 14 days (for vulnerabilities) or 1 month (for severe incidents).
Conformity assessment and CE marking (from December 2027) Products must undergo a conformity assessment (self-assessment for most, third-party for high-risk categories) and carry the CE marking to be placed on the EU market.
How the CRA treats open source software
The CRA draws a careful distinction between different OSS actors:
Non-commercial FOSS: exempt Open source software developed and distributed on a purely non-commercial basis — by individual volunteers or community projects that do not commercialize their work — is exempt from CRA requirements. Projects that recover costs or reinvest profits into non-commercial activities remain exempt.
Open Source Software Stewards: lighter obligations Organizations (companies, foundations) that systematically support or maintain OSS projects used in commercial products fall into a new category: “open source software steward”. They are not subject to the full manufacturer obligations, but carry reduced duties including transparency about known vulnerabilities and support for remediation workflows. Administrative fines for CRA violations do not apply to OSS stewards.
Commercial manufacturers using OSS: fully in scope If our organization ships a product to the EU market that incorporates open source components — even unmodified, well-known components like Linux, OpenSSL, or community-maintained libraries — we are the manufacturer and bear full CRA compliance responsibility for those components. The upstream open source project is not responsible; we are.
This is the critical point: the CRA does not exempt commercial products from OSS components. The integration of OSS into a shipped product transfers full responsibility to the manufacturer.
Impact on our product development practices
The CRA requires concrete changes to how we build, ship, and maintain products:
SBOM as a first-class artifact Every product release must be accompanied by a machine-readable SBOM (CycloneDX or SPDX formats are standard). Our CI/CD pipelines must generate SBOMs automatically at build time, covering all layers including container images and transitive dependencies.
# Example: generating a CycloneDX SBOM in a CI pipeline
syft packages . --output cyclonedx-json > sbom.json
# or using cdxgen, trivy, or equivalent tooling
Continuous vulnerability monitoring — not just at build time We must monitor components in production continuously, not only at the point of integration. A CVE published six months after a product ships is still our responsibility under the CRA. Our SCA tooling must cover the full deployed fleet, not just the latest build.
Defined support lifetime Products must have a declared support period of at least 5 years during which security updates will be provided. End-of-Life open source components (no longer receiving upstream patches) must be replaced or maintained internally before their use in a product shipped to the EU.
Reporting process readiness by September 2026 We need a documented incident and vulnerability response process that can detect a reportable event, classify severity, identify affected EU markets, and submit reports within the 24/72-hour windows. This must be operational before September 2026.
Secure-by-design practices Development teams must adopt security practices from the outset: threat modeling, secure coding guidelines, dependency pinning, and regular security reviews — not just at release.
Product risk classification
The CRA categorizes products into three classes, with increasing scrutiny:
| Class | Examples | Conformity assessment |
|---|---|---|
| Default | Most software products | Self-assessment |
| Important (Class I) | Identity management, password managers, network monitoring tools | Self-assessment against harmonized standard, or third-party |
| Critical (Class II) | OS, hypervisors, firewalls, smart metering | Mandatory third-party assessment |
Contact the OSPO and Legal to determine which class applies to your product.
What to do now
Given the September 2026 reporting deadline is imminent:
- Identify which of your products are in scope (shipped or planned for the EU market).
- Generate SBOMs for those products using our standard tooling — do not wait for December 2027.
- Audit open source dependencies for End-of-Life components and replace them.
- Establish or review your vulnerability response process to meet the 24/72-hour reporting windows.
- Contact the OSPO to assess the risk class of your product and determine whether third-party conformity assessment is required.
Common pitfalls
- Assuming “open source = exempt” — the CRA exempts non-commercial OSS projects, not commercial products that incorporate OSS. If you ship it to the EU, you are the manufacturer.
- Treating SBOM as a December 2027 problem — reporting obligations begin September 2026. You cannot report vulnerabilities without knowing your components. SBOM readiness is a practical prerequisite, not a future checkbox.
- Scoping only direct dependencies — the CRA applies to the full component tree. Transitive dependencies are included in your responsibility.
- Missing the 24-hour early warning window — without automated detection and a defined escalation process, meeting the reporting SLA is operationally impossible at scale.
- Confusing the CRA with NIS2 — the CRA applies to product manufacturers; NIS2 applies to operators of essential services. Both may apply to your organization simultaneously.
See also
- How do we handle open source security vulnerabilities?
- Can I use open source in my project?
- Can we open source our own internal projects?
- EU Cyber Resilience Act — Official EU page
- OpenSSF — EU CRA resources
- ORC Working Group — CRA for open source stakeholders
- Regulation (EU) 2024/2847 — Full text
- Inno3 & CNLL CRA Compliance Guide