The EU Cyber Resilience Act (CRA) — Frequently Asked Questions
The Cyber Resilience Act (Regulation (EU) 2024/2847, “CRA”) introduces, for the first time, binding, horizontal cybersecurity requirements for products with digital elements sold in the EU. It affects manufacturers, importers and distributors of hardware and software worldwide — not only “IT companies” — and backs its requirements with CE marking, market surveillance powers and substantial fines. The CRA entered into force on 10 December 2024, its incident- and vulnerability-reporting obligations apply from 11 September 2026, and its full set of requirements applies from 11 December 2027.
This page answers the questions companies most frequently ask us about the CRA. It is written for a general business audience and is deliberately practical.
Please note: This FAQ provides general information only and is not legal advice. It reflects the state of the law as of July 2026. The CRA continues to evolve through implementing and delegated acts, harmonised standards and European Commission guidance, several of which were still in draft or pending at the time of writing. Please seek individual advice before making compliance decisions. For a scope check tailored to your products, contact SES Berlin.
1. The basics
What is the Cyber Resilience Act?
The CRA is an EU regulation that sets mandatory cybersecurity requirements across the entire lifecycle of “products with digital elements” — from design and production through the whole support period. It works within the EU's New Legislative Framework: products must meet essential requirements, undergo conformity assessment, carry the CE marking and be accompanied by an EU declaration of conformity. Because it is a regulation, it applies directly in all Member States without national transposition.
Legal basis: Regulation (EU) 2024/2847; essential requirements in Annex I.
What are the goals of the CRA?
The CRA pursues two core objectives: ensuring that products with digital elements placed on the EU market carry fewer vulnerabilities and are secure by design and by default, and ensuring that manufacturers take responsibility for cybersecurity throughout a product's lifecycle, including handling vulnerabilities and providing security updates. A second aim is transparency, so that businesses and consumers can make informed decisions and use products securely.
Who is covered by the CRA?
The CRA primarily addresses manufacturers of products with digital elements, but also imposes independent duties on importers and distributors. Authorised representatives and, in a lighter form, open-source software stewards are also addressed. Whether you are “covered” turns first on whether your product is a product with digital elements (see below) and then on your role in the supply chain.
Legal basis: definitions in Art. 3 CRA; economic-operator obligations in Art. 13, 14, 18–23 CRA.
Am I affected — how do I check?
Ask, in order: (1) Do I make available, on the EU market, a product that contains software or firmware (a “product with digital elements”)? (2) Does that product connect — directly or indirectly — to a device or network? (3) What is my role (manufacturer, importer, distributor, or do I place products on the market under my own brand or substantially modify them)? If the answer to (1) and (2) is yes and you are anywhere in that supply chain, the CRA very likely applies to you. Because classification, the manufacturer “fiction” and the open-source rules can be counter-intuitive, a documented scope check per product line is worthwhile.
2. Scope — products, software and exceptions
What is a “product with digital elements”?
A “product with digital elements” is any software or hardware product, including its remote data-processing solutions, whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Two conditions must be met cumulatively: it must be a software or hardware product, and it must have that data connection. Purely offline products with no data connection fall outside the CRA.
Legal basis: Art. 3(1) and (2) CRA.
Does the CRA cover standalone software, mobile apps and SaaS?
Standalone software and mobile apps that meet the definition — i.e. software with a direct or indirect data connection — are in scope as products with digital elements. Standalone software-as-a-service (SaaS) and cloud services are generally outside the CRA and are instead governed primarily by NIS2, DORA and the GDPR. The important exception is a “remote data-processing solution”: where cloud-side software is designed and developed by the manufacturer and is necessary for the product to perform its functions, it is treated as part of the product and is in scope.
Legal basis: Art. 3(1), (2) CRA; the SaaS/cloud boundary is developed further in Commission FAQ guidance, still developing.
Is there an exception for free and open-source software (FOSS)?
Yes. Free and open-source software supplied outside the course of a commercial activity is not covered by the CRA at all. Where FOSS is genuinely non-commercial — developed collaboratively and made available for use, modification and redistribution without a commercial purpose — the regulation's manufacturer duties do not attach. But the picture changes as soon as the software is commercialised, and a lighter regime applies to “open-source software stewards” (see the dedicated questions below).
Legal basis: recitals on FOSS; Art. 3(14) and Art. 24 CRA.
Are there other product exceptions?
Yes. Products already covered by sector-specific EU cybersecurity rules — for example medical devices, in-vitro diagnostics, motor vehicles, and civil-aviation and certain machinery products — are wholly or partly carved out where those regimes already achieve an equivalent level of protection. Certain products developed exclusively for national security or defence, and some others, are also excluded. Sectoral rules generally take precedence over the CRA to the extent they overlap.
Legal basis: Art. 2 CRA and recitals on sectoral precedence; precise boundaries to be assessed case by case.
Does providing software between group companies (intra-group) count?
The CRA is triggered by “making available on the market” in the course of a commercial activity. Whether an internal transfer of software between companies of the same group amounts to placing on the market — and therefore triggers CRA obligations — depends on the facts, in particular whether the product is supplied for distribution or use in the course of a commercial activity or is purely internal. This is one of the points on which Commission guidance is still developing, so intra-group arrangements should be assessed case by case rather than assumed to be out of scope.
Legal basis: “making available on the market” / “placing on the market”, Art. 3 CRA; to be assessed case by case.
3. Roles and duties
What are a manufacturer's duties?
Manufacturers carry the core of the CRA. Before placing a product on the market they must carry out a cybersecurity risk assessment, apply the essential requirements of Annex I on a risk basis and document this, provide the product without known exploitable vulnerabilities, carry out conformity assessment, draw up the technical documentation and the EU declaration of conformity, and affix the CE marking. Throughout the support period they must handle vulnerabilities, provide security updates, and comply with the reporting duties.
Legal basis: Art. 13 and Art. 14 CRA; Annex I.
Beware the “manufacturer fiction”: own-brand and substantial modification
Anyone who places a product on the market under their own name or trademark, or who substantially modifies a product already on the market and then makes it available, is treated as the manufacturer and takes on the full manufacturer obligations under Art. 13 and 14 — even if a third party actually built the product. In addition, an economic operator falling within Art. 21 is treated as bearing manufacturer duties. This “manufacturer fiction” frequently catches distributors, integrators and rebranders who assumed they were merely reselling.
Legal basis: Art. 3(13) CRA (definition), Art. 21 CRA.
What are an importer's duties?
An importer may only place on the market products that comply with the CRA. Before doing so the importer must verify that the manufacturer has carried out conformity assessment, drawn up the technical documentation, affixed the CE marking and provided the required information and instructions. Where an importer has reason to believe a product is non-compliant or presents a significant cybersecurity risk, it must not place it on the market and must inform the manufacturer and the market surveillance authorities.
Legal basis: Art. 19 CRA (importers).
What are a distributor's duties?
Distributors must act with due care in relation to the CRA. Before making a product available they must check that it bears the CE marking, that the manufacturer and, where applicable, the importer have met their labelling and documentation duties, and that the required instructions are present. If a distributor believes a product is non-compliant or presents a significant risk, it must not make it available and must notify the relevant actors and authorities. Remember that own-branding or substantial modification pushes a distributor into full manufacturer duties.
Legal basis: Art. 20 CRA (distributors); Art. 21 CRA.
Is an authorised representative required?
No — appointing an authorised representative is optional (“may appoint”). It is, however, practically advisable for non-EU manufacturers who have no EU importer, because market surveillance authorities need an economic operator established in the Union to address (in line with Regulation (EU) 2019/1020). For non-EU manufacturers, the establishment of the authorised representative also determines which CSIRT is competent for reporting.
Legal basis: Art. 18 CRA; Art. 14(7) CRA; Regulation (EU) 2019/1020.
4. Open-source software stewards and fines
What is an “open-source software steward”?
An open-source software steward is a legal person — not a natural person and not a “manufacturer” — that systematically and sustainably supports the development of specific free and open-source software products that are intended for commercial activities, and that plays a role in ensuring their viability. Typical examples are the large open-source foundations. Stewards are subject to a lighter set of duties than manufacturers, reflecting the special nature of open-source development.
Legal basis: Art. 3(14) CRA; recitals on stewards.
What must an open-source software steward actually do?
Stewards have a reduced obligation set under Art. 24: they must put in place and document a cybersecurity policy to foster secure development and effective vulnerability handling, cooperate with the market surveillance authorities, and comply with the reporting duty in Art. 24(3) (which links back to the reporting mechanism in Art. 14). Stewards do not affix the CE marking, do not carry out conformity assessment, and are not subject to the manufacturer's documentation-retention duties.
Legal basis: Art. 24 CRA, including Art. 24(3).
Are open-source foundations exposed to CRA fines?
Only in part. Art. 64(10)(b) exempts stewards only from the fines under Art. 64(3)–(9). The Art. 64(2) tier — up to €15 million or 2.5% of worldwide annual turnover — still applies to stewards, most relevantly via the reporting duty in Art. 24(3) in conjunction with Art. 14. So it is not correct to say that foundations face no CRA fines: their exposure is narrowed, not eliminated.
Legal basis: Art. 64(2) and Art. 64(10)(b) CRA; Art. 24(3) in conjunction with Art. 14 CRA.
What if the open-source software is commercialised?
Once open-source software is placed on the market in the course of a commercial activity — for example through paid support, monetisation, advertising-financed or data-driven models, or dual licensing — the full manufacturer scope applies to the entity doing so. Importantly, one organisation can be both: a steward for the upstream project it supports, and a manufacturer for its own commercial distribution of the same software.
Legal basis: Art. 3(13), 3(14) CRA; recitals on commercial activity.
5. Core obligations in operation
What is the support period and what about security updates?
Manufacturers must determine and support a support period during which they handle vulnerabilities and provide security updates. The CRA sets a floor of at least 5 years; the period may be shorter only where the product is expected to be in use for a shorter time, and must be longer where the expected product lifetime is longer. The support period must be determined, documented, and communicated transparently to users.
Legal basis: Art. 13(8) CRA; transparency under Art. 13(19) CRA.
Do I need a software bill of materials (SBOM)?
Yes, in substance. Manufacturers are responsible for the security of the whole product, including third-party and open-source components, and must exercise documented due diligence on those components. As part of the technical documentation they must draw up and keep an SBOM covering at least the top-level dependencies of the product, in a commonly used and machine-readable format (formats such as SPDX or CycloneDX are typical). The SBOM supports vulnerability management and must be available to market surveillance authorities.
Legal basis: Art. 13 CRA and Annex I; technical documentation Annex VII.
What are the reporting obligations (24h / 72h / final report)?
The reporting duty is triggered by knowledge of an actively exploited vulnerability or a severe incident affecting the security of the product. The manufacturer must file: a 24-hour early warning, a 72-hour notification, and a final report. The final report is due 14 days after a corrective or mitigating measure is available (for an actively exploited vulnerability), or one month after the 72-hour notification (for a severe incident). Reporting is done once through the ENISA Single Reporting Platform, which routes the report to the coordinating CSIRT (determined by main establishment or authorised representative) and to ENISA. These duties are cumulative with any parallel obligations under NIS2 and the GDPR.
Legal basis: Art. 14 CRA; Art. 16 CRA; Art. 14(7) CRA.
When is software “placed on the market”?
Software is “placed on the market” when it is made available on the EU market for the first time in the course of a commercial activity, whether for payment or free of charge. “Making available on the market” is any supply for distribution or use on the EU market in the course of a commercial activity. This concept — rather than a formal sale — is what triggers CRA obligations, and it matters for timing, for the manufacturer fiction, and for legacy products.
Legal basis: definitions in Art. 3 CRA.
6. Conformity, CE marking and legacy products
Do I need conformity assessment and CE marking — and must I re-certify an existing CE product?
Products with digital elements must undergo conformity assessment, be covered by an EU declaration of conformity, and bear the CE marking before being placed on the market from 11 December 2027. The route depends on classification (see below): most products can be self-assessed, while “important” and “critical” products may require the involvement of a notified body. A CE marking under other EU legislation does not substitute for CRA conformity — the CRA adds its own cybersecurity conformity, so existing CE products will generally need CRA assessment for their cybersecurity aspects.
Legal basis: Art. 13(12), Art. 28–32 CRA; classification in Annex III/IV.
How is a product classified (default / important / critical)?
Most products fall into the default category and are subject to manufacturer self-assessment. Products listed in Annex III are “important” (Class I or Class II) and may require a notified body. A small set listed in Annex IV are “critical” and may be subject to stricter routes such as European cybersecurity certification. The manufacturer performs the classification in the first instance, guided by the product's core functionality; Commission guidance on classification is still developing.
Legal basis: Art. 7 and Annex III (important), Annex IV (critical) CRA.
Can I keep selling my legacy products?
Products placed on the market before 11 December 2027 generally do not need to be retrofitted to the CRA. That changes only if such a product is substantially modified after that date, in which case it is treated as a new product and the CRA applies in full. Manufacturers should be prepared to demonstrate that a given update is not a substantial modification.
Legal basis: Art. 69(2) CRA; “substantial modification” Art. 3(30) CRA.
What is a “substantial modification”?
A substantial modification is a change to a product after it has been placed on the market that affects its compliance with the essential requirements or changes its intended purpose — for example the addition of a materially new function or interface. Ordinary security patches and bug fixes are generally not substantial modifications; genuinely new functionality may be. Because the burden is on the manufacturer, it is prudent to document update decisions.
Legal basis: Art. 3(30) CRA; Commission draft guidance.
7. Penalties and other consequences
What are the fines under the CRA?
The CRA provides for three tiers of administrative fines: up to €15 million or 2.5% of total worldwide annual turnover (whichever is higher) for breaches of the essential requirements in Annex I and the core obligations in Art. 13 and 14; up to €10 million or 2% for breaches of other obligations; and up to €5 million or 1% for supplying incorrect, incomplete or misleading information. As with the GDPR, these ceilings are turnover-linked and can be very significant.
Legal basis: Art. 64(2), 64(3) and 64(4) CRA.
What are the consequences beyond fines?
Fines are not the only, or even the most disruptive, consequence. Market surveillance authorities can order corrective action, require compliance, restrict or prohibit the making available of a product, and order its withdrawal or recall — even for CE-marked products that present a significant cybersecurity risk. Without a valid CE marking there is no lawful market access, and non-compliant products can be refused entry at the EU border. Separately, civil product liability applies.
Legal basis: Art. 52–56 CRA in conjunction with Regulation (EU) 2019/1020.
How does civil / product liability interact with the CRA?
Under the revised Product Liability Directive (Directive (EU) 2024/2853, “PLD”), software and digital elements are expressly covered, and a product can be defective because of a cybersecurity vulnerability or a faulty or missing security update. The PLD provides for no-fault (strict) liability and covers damage such as the destruction or corruption of data. A product's compliance — or non-compliance — with cybersecurity requirements such as the CRA is a factor to be taken into account when assessing defectiveness (Art. 7(2) PLD); it is not an automatic presumption of defect. Conversely, documented CRA compliance can support a manufacturer's defence.
Legal basis: Directive (EU) 2024/2853 (PLD), in particular Art. 7(2).
8. Relationship to other EU regimes
How does the CRA relate to NIS2, DORA and the GDPR?
The CRA is a product regulation and sits alongside — rather than replaces — these other regimes. NIS2 obliges operators of essential and important entities to manage risk and report incidents; a CRA reporting event can therefore coincide with a parallel NIS2 report. DORA governs digital operational resilience in the financial sector, and the GDPR governs personal-data breaches. Standalone cloud and SaaS services fall primarily under NIS2, DORA and the GDPR rather than the CRA. Reporting under the CRA is cumulative with any parallel NIS2 or GDPR notification duties, so incident governance should be designed to satisfy all applicable regimes together.
Legal basis: recitals on interaction; Art. 14–16 CRA; NIS2, DORA, GDPR and PLD as separate instruments.
Quick self-check: Am I affected?
Answer each question yes/no. Several “yes” answers strongly suggest the CRA is relevant and a scope check is warranted:
- Do you make software or hardware available on the EU market in the course of business?
- Does that product connect, directly or indirectly, to a device or a network?
- Do you sell products under your own brand, or modify products made by others before selling them?
- Do you import into, or distribute within, the EU products that contain software or firmware?
- Do you maintain, or financially support, open-source software that is intended for commercial use?
- Is your product not fully covered by a sector-specific regime (medical devices, motor vehicles, aviation, etc.)?
- Will your product still be sold, or receive updates, on or after 11 December 2027?
What to do now — next steps
- Run a scope check per product line — determine which products are “products with digital elements”, who is the CRA manufacturer, and how each product classifies (default / important / critical).
- Map your role across your portfolio — you may be a manufacturer for some products, an importer or distributor for others, and possibly an open-source steward.
- Build secure-by-design and vulnerability-handling processes, including an SBOM approach (SPDX/CycloneDX) and documented due diligence on third-party and open-source components.
- Set and document support periods (at least 5 years, longer where lifetimes are longer) and the associated transparency information.
- Stand up integrated incident- and vulnerability-reporting governance now, aligned to the 24h/72h/final-report cadence and the ENISA Single Reporting Platform, and coordinated with NIS2 and GDPR reporting.
- Prepare conformity documentation and CE ahead of the 11 December 2027 deadline.
How we can help
SES Berlin advises manufacturers, importers, distributors and open-source organisations on the Cyber Resilience Act — from an initial scope and classification check per product line, through conformity and CE strategy, support-period and SBOM governance, to integrated incident-reporting processes across the CRA, NIS2 and the GDPR. If you would like a scope check for your products, please get in touch.
This FAQ is general information, not legal advice, and reflects the law as of July 2026.
Regulation text: All the provisions cited in this FAQ 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.
The EU Cyber Resilience Act (CRA) — Frequently Asked Questions
The Cyber Resilience Act (Regulation (EU) 2024/2847, “CRA”) introduces, for the first time, binding, horizontal cybersecurity requirements for products with digital elements sold in the EU. It affects manufacturers, importers and distributors of hardware and software worldwide — not only “IT companies” — and backs its requirements with CE marking, market surveillance powers and substantial fines. The CRA entered into force on 10 December 2024, its incident- and vulnerability-reporting obligations apply from 11 September 2026, and its full set of requirements applies from 11 December 2027.
This page answers the questions companies most frequently ask us about the CRA. It is written for a general business audience and is deliberately practical.
Please note: This FAQ provides general information only and is not legal advice. It reflects the state of the law as of July 2026. The CRA continues to evolve through implementing and delegated acts, harmonised standards and European Commission guidance, several of which were still in draft or pending at the time of writing. Please seek individual advice before making compliance decisions. For a scope check tailored to your products, contact SES Berlin.
1. The basics
What is the Cyber Resilience Act?
The CRA is an EU regulation that sets mandatory cybersecurity requirements across the entire lifecycle of “products with digital elements” — from design and production through the whole support period. It works within the EU's New Legislative Framework: products must meet essential requirements, undergo conformity assessment, carry the CE marking and be accompanied by an EU declaration of conformity. Because it is a regulation, it applies directly in all Member States without national transposition.
Legal basis: Regulation (EU) 2024/2847; essential requirements in Annex I.
What are the goals of the CRA?
The CRA pursues two core objectives: ensuring that products with digital elements placed on the EU market carry fewer vulnerabilities and are secure by design and by default, and ensuring that manufacturers take responsibility for cybersecurity throughout a product's lifecycle, including handling vulnerabilities and providing security updates. A second aim is transparency, so that businesses and consumers can make informed decisions and use products securely.
Who is covered by the CRA?
The CRA primarily addresses manufacturers of products with digital elements, but also imposes independent duties on importers and distributors. Authorised representatives and, in a lighter form, open-source software stewards are also addressed. Whether you are “covered” turns first on whether your product is a product with digital elements (see below) and then on your role in the supply chain.
Legal basis: definitions in Art. 3 CRA; economic-operator obligations in Art. 13, 14, 18–23 CRA.
Am I affected — how do I check?
Ask, in order: (1) Do I make available, on the EU market, a product that contains software or firmware (a “product with digital elements”)? (2) Does that product connect — directly or indirectly — to a device or network? (3) What is my role (manufacturer, importer, distributor, or do I place products on the market under my own brand or substantially modify them)? If the answer to (1) and (2) is yes and you are anywhere in that supply chain, the CRA very likely applies to you. Because classification, the manufacturer “fiction” and the open-source rules can be counter-intuitive, a documented scope check per product line is worthwhile.
2. Scope — products, software and exceptions
What is a “product with digital elements”?
A “product with digital elements” is any software or hardware product, including its remote data-processing solutions, whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Two conditions must be met cumulatively: it must be a software or hardware product, and it must have that data connection. Purely offline products with no data connection fall outside the CRA.
Legal basis: Art. 3(1) and (2) CRA.
Does the CRA cover standalone software, mobile apps and SaaS?
Standalone software and mobile apps that meet the definition — i.e. software with a direct or indirect data connection — are in scope as products with digital elements. Standalone software-as-a-service (SaaS) and cloud services are generally outside the CRA and are instead governed primarily by NIS2, DORA and the GDPR. The important exception is a “remote data-processing solution”: where cloud-side software is designed and developed by the manufacturer and is necessary for the product to perform its functions, it is treated as part of the product and is in scope.
Legal basis: Art. 3(1), (2) CRA; the SaaS/cloud boundary is developed further in Commission FAQ guidance, still developing.
Is there an exception for free and open-source software (FOSS)?
Yes. Free and open-source software supplied outside the course of a commercial activity is not covered by the CRA at all. Where FOSS is genuinely non-commercial — developed collaboratively and made available for use, modification and redistribution without a commercial purpose — the regulation's manufacturer duties do not attach. But the picture changes as soon as the software is commercialised, and a lighter regime applies to “open-source software stewards” (see the dedicated questions below).
Legal basis: recitals on FOSS; Art. 3(14) and Art. 24 CRA.
Are there other product exceptions?
Yes. Products already covered by sector-specific EU cybersecurity rules — for example medical devices, in-vitro diagnostics, motor vehicles, and civil-aviation and certain machinery products — are wholly or partly carved out where those regimes already achieve an equivalent level of protection. Certain products developed exclusively for national security or defence, and some others, are also excluded. Sectoral rules generally take precedence over the CRA to the extent they overlap.
Legal basis: Art. 2 CRA and recitals on sectoral precedence; precise boundaries to be assessed case by case.
Does providing software between group companies (intra-group) count?
The CRA is triggered by “making available on the market” in the course of a commercial activity. Whether an internal transfer of software between companies of the same group amounts to placing on the market — and therefore triggers CRA obligations — depends on the facts, in particular whether the product is supplied for distribution or use in the course of a commercial activity or is purely internal. This is one of the points on which Commission guidance is still developing, so intra-group arrangements should be assessed case by case rather than assumed to be out of scope.
Legal basis: “making available on the market” / “placing on the market”, Art. 3 CRA; to be assessed case by case.
3. Roles and duties
What are a manufacturer's duties?
Manufacturers carry the core of the CRA. Before placing a product on the market they must carry out a cybersecurity risk assessment, apply the essential requirements of Annex I on a risk basis and document this, provide the product without known exploitable vulnerabilities, carry out conformity assessment, draw up the technical documentation and the EU declaration of conformity, and affix the CE marking. Throughout the support period they must handle vulnerabilities, provide security updates, and comply with the reporting duties.
Legal basis: Art. 13 and Art. 14 CRA; Annex I.
Beware the “manufacturer fiction”: own-brand and substantial modification
Anyone who places a product on the market under their own name or trademark, or who substantially modifies a product already on the market and then makes it available, is treated as the manufacturer and takes on the full manufacturer obligations under Art. 13 and 14 — even if a third party actually built the product. In addition, an economic operator falling within Art. 21 is treated as bearing manufacturer duties. This “manufacturer fiction” frequently catches distributors, integrators and rebranders who assumed they were merely reselling.
Legal basis: Art. 3(13) CRA (definition), Art. 21 CRA.
What are an importer's duties?
An importer may only place on the market products that comply with the CRA. Before doing so the importer must verify that the manufacturer has carried out conformity assessment, drawn up the technical documentation, affixed the CE marking and provided the required information and instructions. Where an importer has reason to believe a product is non-compliant or presents a significant cybersecurity risk, it must not place it on the market and must inform the manufacturer and the market surveillance authorities.
Legal basis: Art. 19 CRA (importers).
What are a distributor's duties?
Distributors must act with due care in relation to the CRA. Before making a product available they must check that it bears the CE marking, that the manufacturer and, where applicable, the importer have met their labelling and documentation duties, and that the required instructions are present. If a distributor believes a product is non-compliant or presents a significant risk, it must not make it available and must notify the relevant actors and authorities. Remember that own-branding or substantial modification pushes a distributor into full manufacturer duties.
Legal basis: Art. 20 CRA (distributors); Art. 21 CRA.
Is an authorised representative required?
No — appointing an authorised representative is optional (“may appoint”). It is, however, practically advisable for non-EU manufacturers who have no EU importer, because market surveillance authorities need an economic operator established in the Union to address (in line with Regulation (EU) 2019/1020). For non-EU manufacturers, the establishment of the authorised representative also determines which CSIRT is competent for reporting.
Legal basis: Art. 18 CRA; Art. 14(7) CRA; Regulation (EU) 2019/1020.
4. Open-source software stewards and fines
What is an “open-source software steward”?
An open-source software steward is a legal person — not a natural person and not a “manufacturer” — that systematically and sustainably supports the development of specific free and open-source software products that are intended for commercial activities, and that plays a role in ensuring their viability. Typical examples are the large open-source foundations. Stewards are subject to a lighter set of duties than manufacturers, reflecting the special nature of open-source development.
Legal basis: Art. 3(14) CRA; recitals on stewards.
What must an open-source software steward actually do?
Stewards have a reduced obligation set under Art. 24: they must put in place and document a cybersecurity policy to foster secure development and effective vulnerability handling, cooperate with the market surveillance authorities, and comply with the reporting duty in Art. 24(3) (which links back to the reporting mechanism in Art. 14). Stewards do not affix the CE marking, do not carry out conformity assessment, and are not subject to the manufacturer's documentation-retention duties.
Legal basis: Art. 24 CRA, including Art. 24(3).
Are open-source foundations exposed to CRA fines?
Only in part. Art. 64(10)(b) exempts stewards only from the fines under Art. 64(3)–(9). The Art. 64(2) tier — up to €15 million or 2.5% of worldwide annual turnover — still applies to stewards, most relevantly via the reporting duty in Art. 24(3) in conjunction with Art. 14. So it is not correct to say that foundations face no CRA fines: their exposure is narrowed, not eliminated.
Legal basis: Art. 64(2) and Art. 64(10)(b) CRA; Art. 24(3) in conjunction with Art. 14 CRA.
What if the open-source software is commercialised?
Once open-source software is placed on the market in the course of a commercial activity — for example through paid support, monetisation, advertising-financed or data-driven models, or dual licensing — the full manufacturer scope applies to the entity doing so. Importantly, one organisation can be both: a steward for the upstream project it supports, and a manufacturer for its own commercial distribution of the same software.
Legal basis: Art. 3(13), 3(14) CRA; recitals on commercial activity.
5. Core obligations in operation
What is the support period and what about security updates?
Manufacturers must determine and support a support period during which they handle vulnerabilities and provide security updates. The CRA sets a floor of at least 5 years; the period may be shorter only where the product is expected to be in use for a shorter time, and must be longer where the expected product lifetime is longer. The support period must be determined, documented, and communicated transparently to users.
Legal basis: Art. 13(8) CRA; transparency under Art. 13(19) CRA.
Do I need a software bill of materials (SBOM)?
Yes, in substance. Manufacturers are responsible for the security of the whole product, including third-party and open-source components, and must exercise documented due diligence on those components. As part of the technical documentation they must draw up and keep an SBOM covering at least the top-level dependencies of the product, in a commonly used and machine-readable format (formats such as SPDX or CycloneDX are typical). The SBOM supports vulnerability management and must be available to market surveillance authorities.
Legal basis: Art. 13 CRA and Annex I; technical documentation Annex VII.
What are the reporting obligations (24h / 72h / final report)?
The reporting duty is triggered by knowledge of an actively exploited vulnerability or a severe incident affecting the security of the product. The manufacturer must file: a 24-hour early warning, a 72-hour notification, and a final report. The final report is due 14 days after a corrective or mitigating measure is available (for an actively exploited vulnerability), or one month after the 72-hour notification (for a severe incident). Reporting is done once through the ENISA Single Reporting Platform, which routes the report to the coordinating CSIRT (determined by main establishment or authorised representative) and to ENISA. These duties are cumulative with any parallel obligations under NIS2 and the GDPR.
Legal basis: Art. 14 CRA; Art. 16 CRA; Art. 14(7) CRA.
When is software “placed on the market”?
Software is “placed on the market” when it is made available on the EU market for the first time in the course of a commercial activity, whether for payment or free of charge. “Making available on the market” is any supply for distribution or use on the EU market in the course of a commercial activity. This concept — rather than a formal sale — is what triggers CRA obligations, and it matters for timing, for the manufacturer fiction, and for legacy products.
Legal basis: definitions in Art. 3 CRA.
6. Conformity, CE marking and legacy products
Do I need conformity assessment and CE marking — and must I re-certify an existing CE product?
Products with digital elements must undergo conformity assessment, be covered by an EU declaration of conformity, and bear the CE marking before being placed on the market from 11 December 2027. The route depends on classification (see below): most products can be self-assessed, while “important” and “critical” products may require the involvement of a notified body. A CE marking under other EU legislation does not substitute for CRA conformity — the CRA adds its own cybersecurity conformity, so existing CE products will generally need CRA assessment for their cybersecurity aspects.
Legal basis: Art. 13(12), Art. 28–32 CRA; classification in Annex III/IV.
How is a product classified (default / important / critical)?
Most products fall into the default category and are subject to manufacturer self-assessment. Products listed in Annex III are “important” (Class I or Class II) and may require a notified body. A small set listed in Annex IV are “critical” and may be subject to stricter routes such as European cybersecurity certification. The manufacturer performs the classification in the first instance, guided by the product's core functionality; Commission guidance on classification is still developing.
Legal basis: Art. 7 and Annex III (important), Annex IV (critical) CRA.
Can I keep selling my legacy products?
Products placed on the market before 11 December 2027 generally do not need to be retrofitted to the CRA. That changes only if such a product is substantially modified after that date, in which case it is treated as a new product and the CRA applies in full. Manufacturers should be prepared to demonstrate that a given update is not a substantial modification.
Legal basis: Art. 69(2) CRA; “substantial modification” Art. 3(30) CRA.
What is a “substantial modification”?
A substantial modification is a change to a product after it has been placed on the market that affects its compliance with the essential requirements or changes its intended purpose — for example the addition of a materially new function or interface. Ordinary security patches and bug fixes are generally not substantial modifications; genuinely new functionality may be. Because the burden is on the manufacturer, it is prudent to document update decisions.
Legal basis: Art. 3(30) CRA; Commission draft guidance.
7. Penalties and other consequences
What are the fines under the CRA?
The CRA provides for three tiers of administrative fines: up to €15 million or 2.5% of total worldwide annual turnover (whichever is higher) for breaches of the essential requirements in Annex I and the core obligations in Art. 13 and 14; up to €10 million or 2% for breaches of other obligations; and up to €5 million or 1% for supplying incorrect, incomplete or misleading information. As with the GDPR, these ceilings are turnover-linked and can be very significant.
Legal basis: Art. 64(2), 64(3) and 64(4) CRA.
What are the consequences beyond fines?
Fines are not the only, or even the most disruptive, consequence. Market surveillance authorities can order corrective action, require compliance, restrict or prohibit the making available of a product, and order its withdrawal or recall — even for CE-marked products that present a significant cybersecurity risk. Without a valid CE marking there is no lawful market access, and non-compliant products can be refused entry at the EU border. Separately, civil product liability applies.
Legal basis: Art. 52–56 CRA in conjunction with Regulation (EU) 2019/1020.
How does civil / product liability interact with the CRA?
Under the revised Product Liability Directive (Directive (EU) 2024/2853, “PLD”), software and digital elements are expressly covered, and a product can be defective because of a cybersecurity vulnerability or a faulty or missing security update. The PLD provides for no-fault (strict) liability and covers damage such as the destruction or corruption of data. A product's compliance — or non-compliance — with cybersecurity requirements such as the CRA is a factor to be taken into account when assessing defectiveness (Art. 7(2) PLD); it is not an automatic presumption of defect. Conversely, documented CRA compliance can support a manufacturer's defence.
Legal basis: Directive (EU) 2024/2853 (PLD), in particular Art. 7(2).
8. Relationship to other EU regimes
How does the CRA relate to NIS2, DORA and the GDPR?
The CRA is a product regulation and sits alongside — rather than replaces — these other regimes. NIS2 obliges operators of essential and important entities to manage risk and report incidents; a CRA reporting event can therefore coincide with a parallel NIS2 report. DORA governs digital operational resilience in the financial sector, and the GDPR governs personal-data breaches. Standalone cloud and SaaS services fall primarily under NIS2, DORA and the GDPR rather than the CRA. Reporting under the CRA is cumulative with any parallel NIS2 or GDPR notification duties, so incident governance should be designed to satisfy all applicable regimes together.
Legal basis: recitals on interaction; Art. 14–16 CRA; NIS2, DORA, GDPR and PLD as separate instruments.
Quick self-check: Am I affected?
Answer each question yes/no. Several “yes” answers strongly suggest the CRA is relevant and a scope check is warranted:
- Do you make software or hardware available on the EU market in the course of business?
- Does that product connect, directly or indirectly, to a device or a network?
- Do you sell products under your own brand, or modify products made by others before selling them?
- Do you import into, or distribute within, the EU products that contain software or firmware?
- Do you maintain, or financially support, open-source software that is intended for commercial use?
- Is your product not fully covered by a sector-specific regime (medical devices, motor vehicles, aviation, etc.)?
- Will your product still be sold, or receive updates, on or after 11 December 2027?
What to do now — next steps
- Run a scope check per product line — determine which products are “products with digital elements”, who is the CRA manufacturer, and how each product classifies (default / important / critical).
- Map your role across your portfolio — you may be a manufacturer for some products, an importer or distributor for others, and possibly an open-source steward.
- Build secure-by-design and vulnerability-handling processes, including an SBOM approach (SPDX/CycloneDX) and documented due diligence on third-party and open-source components.
- Set and document support periods (at least 5 years, longer where lifetimes are longer) and the associated transparency information.
- Stand up integrated incident- and vulnerability-reporting governance now, aligned to the 24h/72h/final-report cadence and the ENISA Single Reporting Platform, and coordinated with NIS2 and GDPR reporting.
- Prepare conformity documentation and CE ahead of the 11 December 2027 deadline.
How we can help
SES Berlin advises manufacturers, importers, distributors and open-source organisations on the Cyber Resilience Act — from an initial scope and classification check per product line, through conformity and CE strategy, support-period and SBOM governance, to integrated incident-reporting processes across the CRA, NIS2 and the GDPR. If you would like a scope check for your products, please get in touch.
This FAQ is general information, not legal advice, and reflects the law as of July 2026.
Regulation text: All the provisions cited in this FAQ 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.