What is the Cyber Resilience Act (CRA) and why was it introduced?
The Cyber Resilience Act (CRA) is an EU regulation setting out basic rules for the cybersecurity of products with digital elements. In practice, this covers many software products (apps, embedded software, on-premises software), hardware containing software and, in certain cases, the associated remote/cloud functionality required for the product to operate (definitions in Article 3 of the CRA).
The EU has introduced the CRA to establish a uniform minimum level of cybersecurity for digital products and to prevent different regimes from emerging in each Member State. This reduces fragmentation and makes it more predictable for businesses as to which cybersecurity requirements apply when selling within the EU (see, amongst others, Recital 4 of the CRA).
Important for businesses: the CRA is not about whether you will ever be hacked, but about what you, as a manufacturer or provider, must demonstrably do: security-by-design during development and structural maintenance (updates, vulnerabilities, support) after release.
Who is the CRA relevant to? (roles in the supply chain)
The CRA focuses on parties that place products with digital elements on the EU market (definition in Article 3(22) of the CRA). The Regulation operates on the basis of roles within the supply chain.
The most important role is that of the manufacturer: the party that develops the product or commissions its development and places it on the market under its own name or brand (definition in Article 3(13) of the CRA). In addition, there are the importer (an EU party that places a product from outside the EU on the EU market; Article 3(16) of the CRA) and the distributor (a party in the supply chain that offers the product without making any substantive changes; Article 3(17) of the CRA).
Of particular relevance to businesses is that responsibility can ‘arise’ in unexpected places. If an importer or distributor offers a product under their own name or brand, or makes a substantial change, that party may be treated as a manufacturer for the purposes of the CRA (Articles 21 and 22 of the CRA).
Territorial scope: what if the supplier is American (or everything is based in the US)?
The key question is not where your servers are located, but whether you place the product on the EU market: in other words, whether it is supplied with a view to distribution or use on the Union market as part of a commercial activity, whether or not for payment (definition of ‘placing on the market’ in Article 3(22) of the CRA).
In practical terms, this means that a US provider selling or commercially offering an app to EU users may fall within the scope of the CRA as soon as the app is intended for distribution or use in the EU. The fact that the app runs (in part) in a US cloud environment does not automatically alter this basic test.
A useful clarification is that the CRA explicitly states that the mere hosting of software in open repositories, package managers or collaboration platforms is not, in itself, the same as ‘making available on the market’ (see Recital 20 of the CRA). This is not an exemption, but it does require you to carefully examine who in your supply chain is actually the provider/manufacturer.
Phasing: when do you need to have what in place?
The CRA will be implemented in phases. The key dates for businesses are:
From 11 June 2026, Chapter IV (Articles 35–51) will apply (including the system relating to conformity assessment bodies). From 11 September 2026, Article 14 of the CRA will apply (notification obligations). From 11 December 2027, the Regulation will apply in its entirety (final provision/dates of application, OJ L 2024/2847, p. 67).
Why 11 September 2026 is so important: Article 14 sets out short deadlines, including an early warning within 24 hours and further notifications within 72 hours of the manufacturer becoming aware of an actively exploited vulnerability (Article 14 CRA). This requires a functioning internal process (triage, escalation, decision-making, logging) and clear responsibilities throughout the supply chain — not just by 2027, but before that date.
What specific actions must you take as an entrepreneur? (key obligations)
The CRA revolves around two interrelated areas: (A) requirements for the product and (B) requirements for your organisational processes.
On the product side, the basic principle is that products must be designed, developed and manufactured in such a way as to ensure an appropriate level of cybersecurity (essential requirements in Annex I, Part I of the CRA). In plain language: security must be an integral part of the design, and you must not place the product on the market with known, exploitable vulnerabilities (Annex I, Part I).
On the process side, the focus is on vulnerability handling: how you receive, assess and resolve vulnerabilities, and how you roll out updates securely. This ties in with the obligations for manufacturers set out in Article 13 of the CRA and the process requirements in Annex I, Part II of the CRA, including the organisation of a vulnerability contact point, triage/patching and the effective handling of vulnerabilities throughout a support period.
Furthermore, CRA compliance is largely a matter of evidence and documentation. You must be able to substantiate compliance with technical documentation (obligations set out in Article 31 of the CRA, with minimum content specified in Annex VII of the CRA). This is not a “one-off dossier for the regulator”, but an ongoing evidence file that must be kept up to date throughout the support period.
Finally, the CRA deals with conformity and CE marking. For software, it is explicitly stipulated that the CE marking may be affixed to the EU declaration of conformity or on the website accompanying the software product (Article 30 of the CRA).
Standards and ISO: what is mandatory under the CRA and what is advisable?
The CRA contains no general legal obligation to be ISO-certified (for example, ISO/IEC 27001) as a standalone “certification requirement”. What the CRA does, however, is work with (i) essential requirements, (ii) methods for demonstrating compliance, and (iii) documentation to substantiate this.
An important mechanism is the presumption of conformity: if your product and processes comply with relevant harmonised standards published for the CRA, you may assume that you meet the relevant essential requirements (Article 27 CRA, OJ L 2024/2847, p. 46). In addition, your technical documentation must specify, amongst other things, which standards or technical specifications you have applied, or — if you do not apply them (in full) — how you meet the requirements by other means (Annex VII of the CRA, OJ L 2024/2847, p. 75).
In practice, this means for businesses that even if ISO certification is not a ‘strict’ legal requirement, it may be strategically wise (or contractually necessary) to base your security and compliance approach on recognised standards and frameworks. This helps when dealing with clients who require CRA compliance in contracts, during due diligence, and when building a defensible case for market supervision authorities.
Can a member of the public rely directly on the CRA?
The CRA is a regulation and is therefore directly applicable in every Member State (final provision, OJ L 2024/2847, p. 67). Furthermore, the CRA is linked to consumer enforcement by stipulating that Directive (EU) 2020/1828 on representative actions applies to representative actions concerning infringements of CRA provisions that harm or are likely to harm collective consumer interests (Article 65 of the CRA).
In practice, the CRA is primarily designed as a product compliance and market surveillance regime; however, its direct applicability and link to consumer enforcement increase the risk of complaints, disputes and contractual pressure in which CRA standards are used as a benchmark.
What are the consequences of a breach?
The CRA is aligned with the EU market surveillance framework (including Regulation (EU) 2019/1020). If corrective measures are not taken, supervisory authorities may prohibit or restrict the placing of products on the market and order products to be withdrawn from the market or recalled (including Article 52 et seq. of the CRA).
In addition, Article 64 of the CRA requires Member States to establish penalties and sets out maximum fines. For non-compliance with essential requirements (Annex I) and key obligations such as those relating to manufacturers and reporting obligations (including Articles 13 and 14 of the CRA), the maximum administrative fine may amount to EUR 15,000,000 or (for undertakings) 2.5 per cent of global annual turnover (whichever is higher). For other categories of infringements (for example, relating to documentation/CE marking and certain supply chain obligations), the maximum fine is EUR 10,000,000 or 2 per cent of global annual turnover (whichever is higher).
Why this deserves management attention right now (including with AI coding)
AI-assisted coding (such as Claude, Copilot or similar tools) speeds up development, but does not change who is responsible. As soon as your organisation, as a manufacturer, places an app or product on the EU market, you must demonstrate ‘security by design’, manage third-party components and, above all, have your vulnerability handling and reporting processes up and running. The combination of “faster shipping” and insufficiently mature release governance can therefore actually create greater CRA risk.
Short Q&A
What is CRA compliance? CRA compliance means that your digital product, as well as your development and maintenance processes, meet the requirements of the Cyber Resilience Act, including documentation, CE marking (where relevant), updates and vulnerability handling.
Does the CRA also apply to apps and SaaS? It often does, as soon as the software is offered on the EU market as a product with digital elements and its functionality (including any remote processing) falls within the definitions.
Is ISO/IEC 27001 mandatory under the CRA? Not as a general certification requirement. However, standards (including ISO standards) can be of practical help in demonstrating a mature approach and can play a role in your compliance dossier through harmonised standards or technical specifications.
What is the key deadline? For many businesses, 11 September 2026 is crucial because the notification obligations under Article 14 will apply from that date, with short deadlines.
What if my company is based in the US? The location of your company or hosting is not decisive; what matters is whether the product is intended for distribution or use on the EU market.
What happens if I don’t comply? You may face corrective measures (such as restrictions or product recalls) and fines which — depending on the infringement — can amount to up to EUR 15 million or 2.5 per cent of global annual turnover.
Questions
Do you have any questions regarding this article? Our solicitors are ready to advise you! Contact one of our solicitors via email, by phone or fill in the contact form for a no-obligation initial consultation. We are happy to help you find a solution.
