Cyber Resilience Act: Cybersecurity obligations for all products with digital elements
The Cyber Resilience Act (EU Regulation 2024/2847) introduces mandatory cybersecurity requirements for all products with digital elements placed on the EU market. Software is treated like a physical product: with CE marking, five years of security support, and 24-hour reporting deadlines for vulnerabilities.
The Regulation entered into force on 10 December 2024. The reporting obligations apply from 11 September 2026. Full application of all provisions begins on 11 December 2027. For existing products placed on the market before that date, reporting obligations apply retroactively (Art. 69(3)).
Who is affected? #
Manufacturers of products with digital elements #
This covers virtually all software and connected devices placed on the EU market:
- Desktop software, server software, cloud applications
- Mobile apps
- Plugins and extensions
- Games
- Operating systems
- Connected devices (IoT) — both IT and OT
- Firmware and embedded software
The decisive factor: if your product contains digital elements and is made available on the EU market, you fall under the CRA — regardless of whether your company is based in the EU.
A simple rule of thumb: if the device can connect to any network — whether Wi-Fi, Bluetooth, mobile, Ethernet, or any other protocol — it falls under the CRA.
Open source software #
Free and open source software only falls within scope when it is placed on the market in the course of a commercial activity. Mere development and provision in public repositories is not sufficient (Recital 20). Individual contributors are not affected (Art. 18, Recital 18). However, when open source software is integrated as part of a commercial product, the manufacturer bears full responsibility (Art. 13(5)).
Open Source Steward — the new CRA category #
The CRA introduces an entirely new legal category: the "open source software steward" (Art. 3 No. 14). An Open Source Steward is a legal person that is not a manufacturer but systematically and sustainably supports the development of FOSS products intended for commercial activities.
OTTRIA voluntarily registers as an Open Source Steward. This is not a convenience but a deliberate commitment. As a steward, OTTRIA has in practice more obligations than a non-steward that merely uses open source components:
- Active cybersecurity strategy: OTTRIA must develop, implement, and make public a documented cybersecurity strategy — not only for its own company but for every project it supports (Art. 24(1))
- Vulnerability management as a duty: Documentation, remediation, and elimination of vulnerabilities must be actively promoted. OTTRIA commits to not just reporting but coordinating fixes and creating them itself (Art. 24(1))
- Cooperation with authorities: Upon request of market surveillance authorities, OTTRIA must submit all documentation and assist in risk mitigation (Art. 24(2))
- Reporting obligations: Actively exploited vulnerabilities and severe security incidents must be reported insofar as OTTRIA is involved in development (Art. 24(3))
- Early access to security reports for supported projects (Art. 24(3))
- No fines: The CRA does not provide for financial sanctions against stewards (Art. 64(10b)). This does not diminish the seriousness of the obligations — authorities can request corrective measures at any time
For you as a manufacturer, this means: if you integrate open source components managed by a steward, this facilitates your due diligence obligation under Art. 13(5). The voluntary security attestation under Art. 25 can further simplify this evidence.
What does the CRA require? #
CE marking for software (Art. 29, 30) #
Every product with digital elements will in future require a CE marking. For software, this is affixed on the declaration of conformity or the website. The CE marking confirms that all essential cybersecurity requirements from Annex I are met.
Freedom from known exploitable vulnerabilities (Annex I Part I No. 2a) #
Products must be placed on the market without known exploitable vulnerabilities. For FOSS components, the obligation goes further: Art. 13(5) in conjunction with Recital 34 requires checking against the EU vulnerability database for all known vulnerabilities — not just the exploitable ones.
SBOM obligation (Annex I Part II No. 1, Art. 13(24)) #
Manufacturers must create and maintain a software bill of materials documenting vulnerabilities and components. The SBOM must be in a common machine-readable format and cover at least the top-level dependencies.
Five years of security support (Art. 13(8)) #
Manufacturers must provide security updates for at least five years. For longer expected usage periods, correspondingly longer. Security updates must be provided without delay and free of charge (Annex I Part II No. 8) and offered separately from functional updates (Annex I Part II No. 2).
Vulnerability management #
- Address and remedy vulnerabilities without delay (Annex I Part II No. 2)
- Establish and implement a coordinated vulnerability disclosure policy (CVD policy) (Annex I Part II No. 5)
- Provide a contact address for vulnerability reports (Annex I Part II No. 6)
- Ensure secure distribution of updates (Annex I Part II No. 7)
- Test and review security regularly and effectively (Annex I Part II No. 3)
Reporting obligations (Art. 14) #
| Deadline | Obligation |
|---|---|
| 24 hours | Early warning for actively exploited vulnerabilities or severe incidents (Art. 14(2)) |
| 72 hours | Notification with assessment (Art. 14(2)) |
| 14 days | Final report after corrective measure (Art. 14(2)) |
| 1 month | Final report (Art. 14(4)) |
| Without delay | Inform users about the vulnerability and remedial measures (Art. 14(8)) |
These deadlines apply on weekends and public holidays as well. The reporting obligations apply from 11 September 2026 — including for existing products.
Due diligence for FOSS integration (Art. 13(5-6)) #
When integrating open source components into your product, you must exercise due diligence — including for components that have not been made available on the market. Possible due diligence measures according to Recital 34: check for CE marking, security updates available?, free from known vulnerabilities (EU database)?, additional security checks. If you discover vulnerabilities in open source components, you must inform the responsible person or entity and share the security patch (Art. 13(6)).
Consequences of non-compliance #
Fines #
| Level | Amount | Legal basis |
|---|---|---|
| Highest level | EUR 15 million or 2.5% of worldwide annual turnover | Art. 64(2) — violations of essential cybersecurity requirements (Annex I) and manufacturer obligations (Art. 13, 14) |
| Medium level | EUR 10 million or 2% of annual turnover | Art. 64(3) — obligations for authorised representatives, importers, distributors |
| Lowest level | EUR 5 million or 1% of annual turnover | Art. 64(4) — false or incomplete information |
| Open Source Steward | No fines | Art. 64(10b) — explicit statutory exemption |
EU market loss and recall #
Market surveillance authorities can order market withdrawal and recall (Art. 54, 56). The European Commission can order an EU-wide recall (Art. 56) — with immediate effect for the entire single market. This is inherently publicly visible.
Collective actions #
From 11 December 2027, collective actions under EU Directive 2020/1828 are applicable (Art. 65 CRA). Consumer protection organisations can collectively sue manufacturers.
What OTTRIA covers #
| CRA obligation | OTTRIA service |
|---|---|
| Create and maintain SBOM (Annex I Part II No. 1) | SBOM evaluation and ongoing monitoring of your SBOM in machine-readable format |
| Address and remedy vulnerabilities (Annex I Part II No. 2) | Coordinate upstream fixes or create them ourselves |
| Test and review security (Annex I Part II No. 3) | Code reviews, security tests, regression tests for OSS components |
| CVD policy (Annex I Part II No. 5) | Disclosure management as part of the steward role |
| Secure update distribution (Annex I Part II No. 7) | Patch coordination and backports |
| Due diligence for FOSS (Art. 13(5)) | Documented assessment of all OSS dependencies against the EU vulnerability database |
| Reports to authorities (Art. 14) | Support for your reports with technical details and assessments |
| Post-market surveillance | Ongoing monitoring of all SBOM components after release |
| Steward attestation (Art. 25) | Evidence of systematic OSS governance for your due diligence obligation |
What OTTRIA does not cover #
- CE declaration of conformity: The declaration of conformity is your obligation as manufacturer (Art. 28). OTTRIA provides the basis for the OSS components, but you declare the conformity.
- Your risk assessment: The overall risk assessment of your product under Art. 13(2) is your responsibility.
- Non-OSS components: OTTRIA covers exclusively open source dependencies.
- Your systems: OTTRIA does not work in your systems but in the open source world.
- Resolution time guarantees: We respond as quickly as possible and document every step. Resolution times cannot be predicted.
What do you present to the auditor? #
OTTRIA delivers #
- SBOM evaluation and risk analysis under Annex I Part II No. 1 and Art. 13(24)
- Vulnerability documentation per OSS component
- Patch history with remediation protocols
- Steward attestation as evidence of systematic OSS governance
- Documentation of due diligence for FOSS integration under Art. 13(5)
- Ongoing post-market surveillance reports
You add #
- CE declaration of conformity under Art. 28
- Your overall risk assessment under Art. 13(2)
- Conformity assessment (for FOSS: simplified procedure possible under Art. 32(5), Module A, when technical documentation is public)
- Your internal reporting processes under Art. 14
Transition periods (Art. 71) #
| Date | What applies |
|---|---|
| 10 December 2024 | Entry into force of the Regulation |
| 11 June 2026 | Notification of conformity assessment bodies |
| 11 September 2026 | Reporting obligations apply (Art. 14) — including for existing products |
| 11 December 2027 | Full application of all provisions |
Act now: between today and 11 September 2026, fewer than six months remain. The reporting obligations require processes that you cannot build overnight.
Implementation in Germany #
The CRA is an EU Regulation and applies directly in all member states — without national transposition. However, member states must designate national market surveillance authorities to oversee compliance. In Germany, this will likely be the Federal Office for Information Security (BSI), possibly in cooperation with the Federal Network Agency.
Since the CRA applies directly, there are no national deviations in requirements. Differences between EU countries may arise in supervisory practice and enforcement.
The reporting obligations apply from September 2026. Are you prepared? Check your CRA readiness now.
Further reading