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, as a rule at least five years of security support, and 24-hour early warnings for actively exploited vulnerabilities or severe security incidents.
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, the reporting obligations likewise apply from 11 September 2026 (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, product-related cloud applications
- Mobile apps, for instance from an app store
- 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.
As a manufacturer you are responsible if you market the product under your own name or trademark. In contract development that can be your client, so clarify who takes on which security tasks.
A simple rule of thumb: if the device can connect to any network — whether Wi-Fi, Bluetooth, mobile, Ethernet, or any other protocol — it generally falls under the CRA. Excluded are areas that already have their own rulebooks, such as regulated medical devices. And pure cloud services with no link to a covered product do not fall under it merely because they are reachable over a network — where the service belongs to your product, however, it is covered with it.
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 acting outside a commercial activity are not covered (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 takes on this role for projects that want it — it cannot be imposed. 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 a cybersecurity strategy and document it verifiably — 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 must be reported insofar as OTTRIA is involved in development. Severe security incidents must be reported where they affect development systems provided by OTTRIA (Art. 24(3))
- Early access to security reports wherever supported projects involve OTTRIA in their confidential reporting processes — which means we know about vulnerabilities before they become public
- 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
The steward obligations under Art. 24 apply from 11 December 2027.
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, Art. 13(5) requires the due diligence owed. Recital 34 names concrete checks for this: comparison against public vulnerability databases, a look at the project's update history, and your own security tests. How deeply you check follows from the component's risk — that you check, and can evidence it, is not optional.
SBOM obligation (Annex I Part II No. 1, Art. 13(24)) #
Manufacturers must identify and document the vulnerabilities and components of their products — among other things through an SBOM in a common machine-readable format covering at least the top-level dependencies. The Commission may later specify format and elements bindingly (Art. 13(24)). For steering your own risk, however, the statutory minimum is not enough: most vulnerabilities sit in the transitive dependencies.
Five years of security support (Art. 13(8)) #
Manufacturers must as a rule provide security updates for at least five years. For longer expected usage periods, correspondingly longer; for a shorter expected usage period, for that shorter period. Security updates must be provided without delay and, as a rule, free of charge (Annex I Part II No. 8) and, where technically feasible, offered separately from functional updates (Annex I Part II No. 2).
Only for tailor-made products may manufacturers and business users depart from the free-of-charge rule. If you buy bespoke software, put this point in the contract — otherwise you will later pay for security updates you need anyway.
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 | Exploited vulnerability: final report once a corrective or mitigating measure is available (Art. 14(2)) |
| 1 month | Severe incident: final report after the incident notification (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.
The 24- and 72-hour deadlines run from the point of awareness. For severe incidents still ongoing, a progress report is required first; the final report follows within one month of the incident being handled.
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 public vulnerability databases, update history and own testing |
| 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: the manufacturer reporting obligations have applied since 11 September 2026. They 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