Cyber Resilience Act – What Must Be Done?
A step-by-step compliance guide for manufacturers, importers, distributors and open-source software stewards
The EU Cyber Resilience Act (Regulation (EU) 2024/2847, the “CRA”) turns product cybersecurity from a voluntary good practice into a binding legal obligation for anyone who places “products with digital elements” on the EU market. It entered into force on 10 December 2024. The reporting obligations become applicable on 11 September 2026, and the full set of requirements — essential requirements, risk assessment, SBOM, EU Declaration of Conformity and CE marking — applies from 11 December 2027. Non-compliance can trigger fines of up to EUR 15 million or 2.5 % of worldwide annual turnover, market withdrawal or recall, and loss of market access.
This page answers the practical question every affected business is asking: what do I actually have to do? It is structured as a roadmap — from the initial scope check, through your role and its duties, to conformity assessment, reporting infrastructure and the key deadlines. Each step names the relevant CRA article so you can trace every obligation to its source.
Disclaimer. This page provides general information only and does not constitute legal advice. It reflects the state of the law as of July 2026. The CRA is a new and evolving instrument: implementing acts, harmonised standards and Commission guidance are still being developed, and some points remain unsettled. Do not act on this overview alone. For advice on your specific products and supply chain, please contact SES Berlin.
Step 1 — Scope Check: Are You Even In Scope? (Per Product Line)
Do not run a firm-wide CRA project before you know which of your products are actually caught. Run the scope check product line by product line.
What to do. For each product, ask two cumulative questions: (1) Is it a product with digital elements — i.e. does it contain software or hardware and (2) does it have a direct or indirect data connection to a device or network? Both conditions must be met. A product that works purely offline, with no data connection at all, is outside the CRA.
Watch the boundary cases:
- Standalone SaaS / cloud services are generally outside the CRA and fall under NIS2, DORA or the GDPR instead — unless the service is a remote data processing solution within the meaning of Art. 3(2), in which case it is treated as part of the product and is caught.
- Free and open-source software (FOSS) developed or supplied outside the course of a commercial activity is carved out; a dedicated, lighter regime applies to open-source software stewards (see Step 2).
- Sector-specific regimes (medical devices, motor vehicles, aviation, machinery) take precedence in whole or in part, so a product already governed by one of those cybersecurity frameworks may be excluded.
Legal basis: Art. 2, Art. 3(1), Art. 3(2) CRA; Recital 31.
Step 2 — Determine Your Role and Its Duties
The CRA allocates duties by role. The same product can involve several economic operators, each with a different obligation set. Identify your role (or roles) first, because everything downstream depends on it.
Manufacturer (the heaviest duties)
What to do. If you develop or manufacture the product, or have it designed/manufactured and market it under your own name or trademark, you carry the full manufacturer obligations. In practice this means you must: carry out a cybersecurity risk assessment before placing the product on the market; design and build the product to the essential requirements in Annex I (secure-by-design); operate a vulnerability handling process; maintain a software bill of materials (SBOM); define and honour a support period; compile technical documentation; draw up the EU Declaration of Conformity; and affix the CE marking.
Legal basis: Art. 13 and Art. 14 CRA.
Importer
What to do. If you place on the EU market a product from a manufacturer established outside the EU, verify before doing so that the manufacturer has carried out the conformity assessment, drawn up the technical documentation, affixed the CE marking and provided the required information and instructions. Do not place a non-conforming product on the market, and act where you have reason to believe a product is non-conforming.
Legal basis: Art. 19 CRA.
Distributor
What to do. Before making a product available, check that it bears the CE marking and that the manufacturer and importer have met their labelling and documentation duties, acting with due care in relation to the applicable requirements. Do not make available a product you know or ought to know is non-conforming.
Legal basis: Art. 20 CRA.
Authorised Representative (optional)
What to do. A manufacturer may appoint an authorised representative established in the EU — this is optional, not mandatory. It is practically advisable for non-EU manufacturers that have no EU importer, because it provides an economic operator in the Union for market surveillance purposes (in line with Regulation (EU) 2019/1020). For a non-EU manufacturer, the establishment of the authorised representative also determines the competent CSIRT for reporting purposes.
Legal basis: Art. 18 CRA; Art. 14(7) CRA; Regulation (EU) 2019/1020.
Open-Source Software Steward (a distinct, lighter role)
What to do. If you are a legal person (only legal persons qualify) that systematically and sustainably supports the development of specific FOSS intended for commercial use and ensures its viability — for example a foundation of the Linux/Python/Eclipse type — you are an open-source software steward, not a manufacturer. You are subject to a reduced catalogue: put in place a cybersecurity policy, cooperate with market surveillance authorities, and report actively exploited vulnerabilities and severe incidents. You do not affix CE marking, carry out a conformity assessment, or keep the manufacturer's documentation.
Watch the fine print on fines. The steward's exemption from penalties is only partial: Art. 64(10)(b) exempts stewards only from the fines under Art. 64(3)–(9). The Art. 64(2) tier — up to EUR 15 million or 2.5 % — still applies to stewards, in particular through the reporting obligation. Do not describe stewards as fine-exempt.
Note that a single organisation can be both: a steward for its upstream project and a manufacturer for its own commercial distribution. Commercialised open source (paid support, ad-funded, data monetisation, dual licensing) falls into full manufacturer scope.
Legal basis: Art. 3(14), Art. 24, Art. 24(3), Art. 64(2), Art. 64(10)(b) CRA; Recitals 18–19.
The “Manufacturer Fiction” — Own-Brand and Substantial Modification
What to do. Recognise when you become a manufacturer even though you did not build the product. Anyone who markets a product under their own name or trademark, or who makes a substantial modification to a product and then places it on the market, takes on the full manufacturer duties. This is the trap for OEM/white-label resellers and system integrators.
Legal basis: Art. 21 CRA; Art. 3(30) CRA (definition of “substantial modification”).
Step 3 — Secure-by-Design and Annex I
What to do. Design and produce each in-scope product so that it meets the essential cybersecurity requirements in Annex I, applied on a risk-based basis. There is no one-size-fits-all checklist: run a cybersecurity risk assessment for the specific product, decide which Annex I requirements apply and to what depth, implement them, and — critically — document both the assessment and the implementation. The CRA does not require a “zero-vulnerability” state; it requires managed, documented security appropriate to the product's risk, including the handling of known vulnerabilities.
Legal basis: Art. 13 CRA; Annex I CRA.
Step 4 — Vulnerability Handling and Reporting: Build the 24h / 72h / Final Workflow
This is the first hard operational deadline (11 September 2026) and the area most likely to catch businesses unprepared. Build the workflow now.
What to do. Establish an internal process that triggers on awareness of an actively exploited vulnerability or a severe incident and produces reports on the statutory clock:
- 24 hours — early warning to the coordinating CSIRT and ENISA;
- 72 hours — a fuller notification;
- Final report — for a vulnerability, within 14 days after a corrective or mitigating measure is available; for a severe incident, within one month after the 72-hour notification.
Report once through the ENISA Single Reporting Platform; the platform routes the report to the coordinating CSIRT and ENISA, and the CSIRT distributes onward. The competent CSIRT is determined by your main establishment (or, for a non-EU manufacturer, by the establishment of the authorised representative). Vulnerabilities in third-party components are reportable too.
Build integrated reporting governance. CRA reporting is cumulative with NIS2 and GDPR breach notification. Do not stand up three siloed processes: build one incident-response governance that can fire the right notifications to the right authorities within each regime's deadlines.
Legal basis: Art. 14, Art. 14(7), Art. 16, Art. 24(3) CRA.
Step 5 — Support Period: Define, Justify and Document It
What to do. For each product, determine the support period during which you will provide security updates. The statutory floor is five years — but five years is a minimum, not a default: a shorter period is permissible only where the product is expected to be in use for less time, and a longer period is required where the product's lifetime is longer. Document the reasoning behind the period you choose. Be transparent about the end date and notify users of the impending expiry.
Legal basis: Art. 13(8) CRA; Art. 13(19) CRA.
Step 6 — Components and SBOM: Supplier Due Diligence
What to do. You are responsible for the whole product, including third-party and open-source components. Establish documented due diligence on your suppliers and components — check CE status where relevant, update history and vulnerability databases. Produce a machine-readable software bill of materials (SBOM) covering at least the top-level dependencies, in a common format such as SPDX or CycloneDX, and keep it available for market surveillance as part of your technical documentation.
Legal basis: Art. 13 CRA; Annex I CRA.
Step 7 — Conformity Assessment and CE Marking
What to do. Bring each in-scope product through conformity assessment and CE marking:
- Classify the product. The default is self-assessment. Important products (Class I and Class II, Annex III) and critical products (Annex IV) face stricter routes; where required, a notified body must be involved. The manufacturer primarily determines the classification, using the core-functionality criterion.
- Compile the technical documentation, run the assessment route for the product's class, draw up the EU Declaration of Conformity, and affix the CE marking.
- Where harmonised standards exist, build to them to benefit from the presumption of conformity.
- Existing CE-marked products (e.g. under other NLF legislation) must have their conformity extended to cover CRA requirements — a CE mark for another regime does not satisfy the CRA.
Legal basis: Art. 13(12), Art. 28–32 CRA; Annex III and Annex IV CRA.
Step 8 — Contracts and Supply Chain
What to do. CRA duties cross company boundaries, so allocate them expressly in your contracts. Revisit supplier, OEM and white-label agreements to allocate CRA obligations and appropriate indemnities: who runs the risk assessment, who maintains the SBOM, who feeds vulnerability information for the reporting clock, and who bears liability for a non-conforming component. Decide, and document, whether you will appoint an authorised representative (Step 2). Remember that if you white-label under your own brand, the manufacturer fiction makes you the manufacturer regardless of what the contract says between the parties.
Legal basis: Art. 18, Art. 21 CRA (roles); Art. 13, Art. 14 CRA (duties to allocate).
Step 9 — Timeline and Priorities
What to do. Sequence the work against the statutory dates. The reporting infrastructure is the first hard deadline (11 September 2026), so prioritise the 24h/72h/final workflow and the ENISA Single Reporting Platform onboarding ahead of the broader conformity work. Then build toward full compliance by 11 December 2027.
For legacy products placed on the market before 11 December 2027, there is no retrofit obligation — unless the product is substantially modified after that date, in which case it must be brought into CRA conformity. Finally, take a considered decision on EUCC certification where it is relevant to your market or procurement requirements.
Legal basis: Art. 71 CRA (dates); Art. 69(2) CRA (legacy products); Art. 3(30) CRA (substantial modification).
Step 10 — Consequences of Non-Compliance
Understanding the downside sharpens the priorities. Non-compliance is not only about fines.
Fines. Three tiers apply:
- up to EUR 15 million or 2.5 % of worldwide annual turnover (whichever is higher) — for breaches of the essential requirements / core obligations (Art. 64(2));
- up to EUR 10 million or 2 % — for other obligations, including importer/distributor duties, conformity assessment and CE (Art. 64(3));
- up to EUR 5 million or 1 % — for incorrect, incomplete or misleading information (Art. 64(4)).
Market surveillance measures. Authorities can order corrective action, require conformity, restrict or prohibit making the product available, and order its withdrawal or recall — even for CE-marked products that present a significant cybersecurity risk.
Loss of market access. Without a valid CE marking there is no lawful placing on the market, and products can be refused entry at the border.
Civil product liability. Under the revised Product Liability Directive (Directive (EU) 2024/2853), software and digital elements are expressly covered, and vulnerabilities or defective/omitted updates can constitute a product defect. Compliance with CRA security requirements is a factor to be taken into account when assessing defectiveness under Art. 7(2) PLD — it is not an automatic presumption of defectiveness. Conversely, documented CRA compliance strengthens the manufacturer's defence.
Legal basis: Art. 64(2)–(4), Art. 52–56 CRA; Regulation (EU) 2019/1020; Directive (EU) 2024/2853 (Art. 7(2)).
Compliance Checklist (Actionable To-Dos)
- Run a scope check per product line (product with digital elements + data connection; offline out; SaaS out unless remote data processing).
- Determine your role(s) — manufacturer, importer, distributor, authorised representative, open-source software steward — and check for the manufacturer fiction.
- Perform and document a risk assessment; apply Annex I on a risk-based basis.
- Build the 24h / 72h / final reporting workflow; onboard to the ENISA Single Reporting Platform; confirm your coordinating CSIRT.
- Integrate CRA reporting with NIS2 and GDPR into one incident-response governance.
- Define, justify and document the support period (five-year floor); set up end-of-support transparency.
- Establish supplier due diligence and produce an SBOM (SPDX/CycloneDX).
- Classify each product; compile technical documentation; draw up the EU Declaration of Conformity; affix CE; involve a notified body where required.
- Extend existing CE-marked products to CRA conformity.
- Allocate CRA duties and indemnities in supplier / OEM / white-label contracts.
- Decide on an authorised representative and on EUCC certification.
- Plan for legacy products (no retrofit unless substantially modified).
Timeline Table
| Date | Milestone | What must be in place |
|---|---|---|
| 10 Dec 2024 | CRA enters into force | Awareness and internal CRA project mandate; begin scope analysis |
| 11 Jun 2026 | Chapter IV applies (notification of conformity assessment bodies) | Notified-body landscape available; classification and assessment route decisions can be finalised |
| 11 Sep 2026 | Reporting obligations apply; ENISA Single Reporting Platform operational | 24h/72h/final workflow live; CSIRT routing confirmed; integrated NIS2/GDPR reporting governance |
| 11 Dec 2027 | Full application | Annex I secure-by-design, risk assessment, SBOM, support period, technical documentation, EU Declaration of Conformity, CE marking |
| Ongoing | Support period | Security updates and vulnerability handling throughout the (minimum five-year) support period; end-of-support notifications |
How SES Berlin Can Help
The CRA touches product design, contracts, incident response and market access at once — and much of the detail is still being filled in by implementing acts, harmonised standards and Commission guidance. SES Berlin advises manufacturers, importers, distributors and open-source software stewards on scope analysis, role classification, reporting governance, conformity assessment and supply-chain contracts. If you would like a structured CRA readiness review for your product portfolio, please get in touch.
Regulation text: All the provisions cited in this roadmap can be found in the CRA regulation text (Regulation (EU) 2024/2847) — with a table of contents of all articles and annexes and the link to the official full text.
Cyber Resilience Act – What Must Be Done?
A step-by-step compliance guide for manufacturers, importers, distributors and open-source software stewards
The EU Cyber Resilience Act (Regulation (EU) 2024/2847, the “CRA”) turns product cybersecurity from a voluntary good practice into a binding legal obligation for anyone who places “products with digital elements” on the EU market. It entered into force on 10 December 2024. The reporting obligations become applicable on 11 September 2026, and the full set of requirements — essential requirements, risk assessment, SBOM, EU Declaration of Conformity and CE marking — applies from 11 December 2027. Non-compliance can trigger fines of up to EUR 15 million or 2.5 % of worldwide annual turnover, market withdrawal or recall, and loss of market access.
This page answers the practical question every affected business is asking: what do I actually have to do? It is structured as a roadmap — from the initial scope check, through your role and its duties, to conformity assessment, reporting infrastructure and the key deadlines. Each step names the relevant CRA article so you can trace every obligation to its source.
Disclaimer. This page provides general information only and does not constitute legal advice. It reflects the state of the law as of July 2026. The CRA is a new and evolving instrument: implementing acts, harmonised standards and Commission guidance are still being developed, and some points remain unsettled. Do not act on this overview alone. For advice on your specific products and supply chain, please contact SES Berlin.
Step 1 — Scope Check: Are You Even In Scope? (Per Product Line)
Do not run a firm-wide CRA project before you know which of your products are actually caught. Run the scope check product line by product line.
What to do. For each product, ask two cumulative questions: (1) Is it a product with digital elements — i.e. does it contain software or hardware and (2) does it have a direct or indirect data connection to a device or network? Both conditions must be met. A product that works purely offline, with no data connection at all, is outside the CRA.
Watch the boundary cases:
- Standalone SaaS / cloud services are generally outside the CRA and fall under NIS2, DORA or the GDPR instead — unless the service is a remote data processing solution within the meaning of Art. 3(2), in which case it is treated as part of the product and is caught.
- Free and open-source software (FOSS) developed or supplied outside the course of a commercial activity is carved out; a dedicated, lighter regime applies to open-source software stewards (see Step 2).
- Sector-specific regimes (medical devices, motor vehicles, aviation, machinery) take precedence in whole or in part, so a product already governed by one of those cybersecurity frameworks may be excluded.
Legal basis: Art. 2, Art. 3(1), Art. 3(2) CRA; Recital 31.
Step 2 — Determine Your Role and Its Duties
The CRA allocates duties by role. The same product can involve several economic operators, each with a different obligation set. Identify your role (or roles) first, because everything downstream depends on it.
Manufacturer (the heaviest duties)
What to do. If you develop or manufacture the product, or have it designed/manufactured and market it under your own name or trademark, you carry the full manufacturer obligations. In practice this means you must: carry out a cybersecurity risk assessment before placing the product on the market; design and build the product to the essential requirements in Annex I (secure-by-design); operate a vulnerability handling process; maintain a software bill of materials (SBOM); define and honour a support period; compile technical documentation; draw up the EU Declaration of Conformity; and affix the CE marking.
Legal basis: Art. 13 and Art. 14 CRA.
Importer
What to do. If you place on the EU market a product from a manufacturer established outside the EU, verify before doing so that the manufacturer has carried out the conformity assessment, drawn up the technical documentation, affixed the CE marking and provided the required information and instructions. Do not place a non-conforming product on the market, and act where you have reason to believe a product is non-conforming.
Legal basis: Art. 19 CRA.
Distributor
What to do. Before making a product available, check that it bears the CE marking and that the manufacturer and importer have met their labelling and documentation duties, acting with due care in relation to the applicable requirements. Do not make available a product you know or ought to know is non-conforming.
Legal basis: Art. 20 CRA.
Authorised Representative (optional)
What to do. A manufacturer may appoint an authorised representative established in the EU — this is optional, not mandatory. It is practically advisable for non-EU manufacturers that have no EU importer, because it provides an economic operator in the Union for market surveillance purposes (in line with Regulation (EU) 2019/1020). For a non-EU manufacturer, the establishment of the authorised representative also determines the competent CSIRT for reporting purposes.
Legal basis: Art. 18 CRA; Art. 14(7) CRA; Regulation (EU) 2019/1020.
Open-Source Software Steward (a distinct, lighter role)
What to do. If you are a legal person (only legal persons qualify) that systematically and sustainably supports the development of specific FOSS intended for commercial use and ensures its viability — for example a foundation of the Linux/Python/Eclipse type — you are an open-source software steward, not a manufacturer. You are subject to a reduced catalogue: put in place a cybersecurity policy, cooperate with market surveillance authorities, and report actively exploited vulnerabilities and severe incidents. You do not affix CE marking, carry out a conformity assessment, or keep the manufacturer's documentation.
Watch the fine print on fines. The steward's exemption from penalties is only partial: Art. 64(10)(b) exempts stewards only from the fines under Art. 64(3)–(9). The Art. 64(2) tier — up to EUR 15 million or 2.5 % — still applies to stewards, in particular through the reporting obligation. Do not describe stewards as fine-exempt.
Note that a single organisation can be both: a steward for its upstream project and a manufacturer for its own commercial distribution. Commercialised open source (paid support, ad-funded, data monetisation, dual licensing) falls into full manufacturer scope.
Legal basis: Art. 3(14), Art. 24, Art. 24(3), Art. 64(2), Art. 64(10)(b) CRA; Recitals 18–19.
The “Manufacturer Fiction” — Own-Brand and Substantial Modification
What to do. Recognise when you become a manufacturer even though you did not build the product. Anyone who markets a product under their own name or trademark, or who makes a substantial modification to a product and then places it on the market, takes on the full manufacturer duties. This is the trap for OEM/white-label resellers and system integrators.
Legal basis: Art. 21 CRA; Art. 3(30) CRA (definition of “substantial modification”).
Step 3 — Secure-by-Design and Annex I
What to do. Design and produce each in-scope product so that it meets the essential cybersecurity requirements in Annex I, applied on a risk-based basis. There is no one-size-fits-all checklist: run a cybersecurity risk assessment for the specific product, decide which Annex I requirements apply and to what depth, implement them, and — critically — document both the assessment and the implementation. The CRA does not require a “zero-vulnerability” state; it requires managed, documented security appropriate to the product's risk, including the handling of known vulnerabilities.
Legal basis: Art. 13 CRA; Annex I CRA.
Step 4 — Vulnerability Handling and Reporting: Build the 24h / 72h / Final Workflow
This is the first hard operational deadline (11 September 2026) and the area most likely to catch businesses unprepared. Build the workflow now.
What to do. Establish an internal process that triggers on awareness of an actively exploited vulnerability or a severe incident and produces reports on the statutory clock:
- 24 hours — early warning to the coordinating CSIRT and ENISA;
- 72 hours — a fuller notification;
- Final report — for a vulnerability, within 14 days after a corrective or mitigating measure is available; for a severe incident, within one month after the 72-hour notification.
Report once through the ENISA Single Reporting Platform; the platform routes the report to the coordinating CSIRT and ENISA, and the CSIRT distributes onward. The competent CSIRT is determined by your main establishment (or, for a non-EU manufacturer, by the establishment of the authorised representative). Vulnerabilities in third-party components are reportable too.
Build integrated reporting governance. CRA reporting is cumulative with NIS2 and GDPR breach notification. Do not stand up three siloed processes: build one incident-response governance that can fire the right notifications to the right authorities within each regime's deadlines.
Legal basis: Art. 14, Art. 14(7), Art. 16, Art. 24(3) CRA.
Step 5 — Support Period: Define, Justify and Document It
What to do. For each product, determine the support period during which you will provide security updates. The statutory floor is five years — but five years is a minimum, not a default: a shorter period is permissible only where the product is expected to be in use for less time, and a longer period is required where the product's lifetime is longer. Document the reasoning behind the period you choose. Be transparent about the end date and notify users of the impending expiry.
Legal basis: Art. 13(8) CRA; Art. 13(19) CRA.
Step 6 — Components and SBOM: Supplier Due Diligence
What to do. You are responsible for the whole product, including third-party and open-source components. Establish documented due diligence on your suppliers and components — check CE status where relevant, update history and vulnerability databases. Produce a machine-readable software bill of materials (SBOM) covering at least the top-level dependencies, in a common format such as SPDX or CycloneDX, and keep it available for market surveillance as part of your technical documentation.
Legal basis: Art. 13 CRA; Annex I CRA.
Step 7 — Conformity Assessment and CE Marking
What to do. Bring each in-scope product through conformity assessment and CE marking:
- Classify the product. The default is self-assessment. Important products (Class I and Class II, Annex III) and critical products (Annex IV) face stricter routes; where required, a notified body must be involved. The manufacturer primarily determines the classification, using the core-functionality criterion.
- Compile the technical documentation, run the assessment route for the product's class, draw up the EU Declaration of Conformity, and affix the CE marking.
- Where harmonised standards exist, build to them to benefit from the presumption of conformity.
- Existing CE-marked products (e.g. under other NLF legislation) must have their conformity extended to cover CRA requirements — a CE mark for another regime does not satisfy the CRA.
Legal basis: Art. 13(12), Art. 28–32 CRA; Annex III and Annex IV CRA.
Step 8 — Contracts and Supply Chain
What to do. CRA duties cross company boundaries, so allocate them expressly in your contracts. Revisit supplier, OEM and white-label agreements to allocate CRA obligations and appropriate indemnities: who runs the risk assessment, who maintains the SBOM, who feeds vulnerability information for the reporting clock, and who bears liability for a non-conforming component. Decide, and document, whether you will appoint an authorised representative (Step 2). Remember that if you white-label under your own brand, the manufacturer fiction makes you the manufacturer regardless of what the contract says between the parties.
Legal basis: Art. 18, Art. 21 CRA (roles); Art. 13, Art. 14 CRA (duties to allocate).
Step 9 — Timeline and Priorities
What to do. Sequence the work against the statutory dates. The reporting infrastructure is the first hard deadline (11 September 2026), so prioritise the 24h/72h/final workflow and the ENISA Single Reporting Platform onboarding ahead of the broader conformity work. Then build toward full compliance by 11 December 2027.
For legacy products placed on the market before 11 December 2027, there is no retrofit obligation — unless the product is substantially modified after that date, in which case it must be brought into CRA conformity. Finally, take a considered decision on EUCC certification where it is relevant to your market or procurement requirements.
Legal basis: Art. 71 CRA (dates); Art. 69(2) CRA (legacy products); Art. 3(30) CRA (substantial modification).
Step 10 — Consequences of Non-Compliance
Understanding the downside sharpens the priorities. Non-compliance is not only about fines.
Fines. Three tiers apply:
- up to EUR 15 million or 2.5 % of worldwide annual turnover (whichever is higher) — for breaches of the essential requirements / core obligations (Art. 64(2));
- up to EUR 10 million or 2 % — for other obligations, including importer/distributor duties, conformity assessment and CE (Art. 64(3));
- up to EUR 5 million or 1 % — for incorrect, incomplete or misleading information (Art. 64(4)).
Market surveillance measures. Authorities can order corrective action, require conformity, restrict or prohibit making the product available, and order its withdrawal or recall — even for CE-marked products that present a significant cybersecurity risk.
Loss of market access. Without a valid CE marking there is no lawful placing on the market, and products can be refused entry at the border.
Civil product liability. Under the revised Product Liability Directive (Directive (EU) 2024/2853), software and digital elements are expressly covered, and vulnerabilities or defective/omitted updates can constitute a product defect. Compliance with CRA security requirements is a factor to be taken into account when assessing defectiveness under Art. 7(2) PLD — it is not an automatic presumption of defectiveness. Conversely, documented CRA compliance strengthens the manufacturer's defence.
Legal basis: Art. 64(2)–(4), Art. 52–56 CRA; Regulation (EU) 2019/1020; Directive (EU) 2024/2853 (Art. 7(2)).
Compliance Checklist (Actionable To-Dos)
- Run a scope check per product line (product with digital elements + data connection; offline out; SaaS out unless remote data processing).
- Determine your role(s) — manufacturer, importer, distributor, authorised representative, open-source software steward — and check for the manufacturer fiction.
- Perform and document a risk assessment; apply Annex I on a risk-based basis.
- Build the 24h / 72h / final reporting workflow; onboard to the ENISA Single Reporting Platform; confirm your coordinating CSIRT.
- Integrate CRA reporting with NIS2 and GDPR into one incident-response governance.
- Define, justify and document the support period (five-year floor); set up end-of-support transparency.
- Establish supplier due diligence and produce an SBOM (SPDX/CycloneDX).
- Classify each product; compile technical documentation; draw up the EU Declaration of Conformity; affix CE; involve a notified body where required.
- Extend existing CE-marked products to CRA conformity.
- Allocate CRA duties and indemnities in supplier / OEM / white-label contracts.
- Decide on an authorised representative and on EUCC certification.
- Plan for legacy products (no retrofit unless substantially modified).
Timeline Table
| Date | Milestone | What must be in place |
|---|---|---|
| 10 Dec 2024 | CRA enters into force | Awareness and internal CRA project mandate; begin scope analysis |
| 11 Jun 2026 | Chapter IV applies (notification of conformity assessment bodies) | Notified-body landscape available; classification and assessment route decisions can be finalised |
| 11 Sep 2026 | Reporting obligations apply; ENISA Single Reporting Platform operational | 24h/72h/final workflow live; CSIRT routing confirmed; integrated NIS2/GDPR reporting governance |
| 11 Dec 2027 | Full application | Annex I secure-by-design, risk assessment, SBOM, support period, technical documentation, EU Declaration of Conformity, CE marking |
| Ongoing | Support period | Security updates and vulnerability handling throughout the (minimum five-year) support period; end-of-support notifications |
How SES Berlin Can Help
The CRA touches product design, contracts, incident response and market access at once — and much of the detail is still being filled in by implementing acts, harmonised standards and Commission guidance. SES Berlin advises manufacturers, importers, distributors and open-source software stewards on scope analysis, role classification, reporting governance, conformity assessment and supply-chain contracts. If you would like a structured CRA readiness review for your product portfolio, please get in touch.
Regulation text: All the provisions cited in this roadmap can be found in the CRA regulation text (Regulation (EU) 2024/2847) — with a table of contents of all articles and annexes and the link to the official full text.