The CRA at a glance: Cybersecurity becomes a product requirement

The CRA makes cybersecurity a product feature. Anyone placing a „product with digital elements“ on the EU market must design and develop it securely, provide it with security updates during its expected lifetime, manage vulnerabilities, assess and (have) document(ed) its compliance with the CRA's strict cybersecurity requirements, and affix the CE mark to the product. The CRA thus draws on the familiar instruments of EU product law and expands them to include cybersecurity.

Both hardware and software are covered, ranging from routers and industrial control systems to desktop applications, mobile apps, and delivered firmware. The decisive factor is the definition in Article 3(1) of the CRA – a product whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network (guideline, page 8, marginal no. 17 f.). Manufacturers bear the primary burden. Importers and distributors have their own tiered verification obligations.

Interestingly, the CRA does not just apply to physical products. Anyone who develops software and offers it commercially in the EU is also considered a manufacturer under the CRA – without having a single device in their portfolio.

The obligations apply in stages. The CRA entered into force on December 10, 2024, conformity assessment bodies can be notified starting June 11, 2026, the reporting obligations begin on September 11, 2026, and the regulation will apply in full from December 11, 2027.

The penalty framework is (which will come as no surprise to anyone who hasn’t completely ignored digital rights legislation in recent years) once again substantial: Violations of the fundamental cybersecurity requirements are subject to fines of up to EUR 15 million or 2.5% of global annual turnover (Art. 64 CRA).

The CRA as a building block of EU digital law

The EU regulates cybersecurity on multiple levels. The CRA is part of the broader vision to make companies and consumers in the EU more resilient and protect them against cyberattacks. The regulatory landscape can be roughly described as follows:

Alongside the CRA, the NIS-2 Directive must first be mentioned. Implemented in Austria by the NISG 2026, this regime is aimed at organizations in certain critical sectors. Anyone operating in a covered sector must implement specific risk management measures and report incidents. The CRA and NISG 2026 can easily be applicable side by side: an industrial company can simultaneously be an entity under the NISG 2026 and a manufacturer under the CRA, with two separate reporting channels and two separate documentation lines.

In addition, there are other components that can affect the same products:

• the GDPR for the processing of personal data;
• the AI Act, whose cybersecurity requirements for high-risk AI systems are deemed to be fulfilled under certain conditions through CRA compliance (Art. 12 CRA);
• the new Product Liability Directive, which explicitly covers software as a product and focuses on omitted security updates; and
• sector-specific regimes like DORA in the financial sector.

Within this framework, the CRA closes the gap at the product level: it ensures that what companies purchase and deploy meets a minimum standard of security, thereby making cybersecurity a purchasing factor and a contractual issue.

The new guide to the CRA: non-binding, but authoritative

The paper was submitted on 07/27/2026 as Annex to Communication C(2026) 5252 published. It comprises around 80 pages and works with numerous practical examples, use cases, and flowcharts. Compared to the consultation draft from early March 2026, the final version is more detailed and, in several points, noticeably more proportionate. The published guideline is not legally binding; a binding interpretation of the CRA can only be made by the ECJ. For practical application, however, it is the most important reference point because market surveillance authorities and notified bodies will orient themselves by it. In addition, the EU Commission maintains a continuously updated FAQ document on CRA implementation Ready.

We have prepared the points relevant to companies and categorized what practically follows from them.

1. Software, web applications, and websites

When does software as a standalone product fall under the CRA? The guide focuses on the place of execution. Software that is made available to users and executed locally on their system is a „product with digital elements“ within the meaning of Article 3(1) of the CRA. This applies to downloads and installed clients just as it does to browser extensions and applications that are developed using web technologies but executed locally (Guide, page 8, marginal no. 20).

Software that is executed purely remotely and accessed solely via a browser is not such a product in and of itself. The same applies to websites that merely provide information (guideline, page 8, marginal no. 21, with reference to Recitals 11 and 12 CRA). Such software is only covered when it is necessary as a „Remote Data Processing Solution“ („RDPS“) for a function of another product (cf. Article 3(2) CRA and right below).

The EU Commission provides an even more specific definition. Covered are those modules that are responsible for the functionality of the product, including the interfaces used by them. Downstream back-end systems with which the product does not directly interact are not RDPS (guidelines, pages 63 ff.). This is of considerable practical significance for SaaS providers. Anyone who operates exclusively a browser-based solution does not automatically become a manufacturer within the meaning of the CRA for that reason alone. Anyone who additionally delivers an installation package, a plug-in, an agent, or a desktop app, certainly does, and specifically for that component.

Virtually just as relevant is the statement in the guidance document on the placing on the market of software. Identical copies of the same version are considered to have been placed on the market as soon as that version is first offered for distribution or use within the Union. By contrast, variants that differ in components, configuration, or unlocked functionality are separate products with their own decisive date (guidance document, page 7, marginal no. 14). This directly affects version and release management.

2. Remote Data Processing: Where is the boundary?

The CRA covers not only the device itself, but also the remote processing without which it could not fulfill its function. The cloud behind the smart thermostat is part of the product, not just a service alongside it. To this end, the guide uses three cumulative test questions and supplements them with a flowchart as well as use cases ranging from mobile banking apps to industrial robots (guide, pages 63 et seq., on use cases pages 70 et seq.).

The exam questions are as follows:

1. Does the data processing take place remotely?
2. Would her absence prevent the product from performing one of its functions?
3. Was the software developed by the manufacturer or under their responsibility?

According to the guidelines, pure third-party SaaS, IaaS, or PaaS services that a manufacturer merely uses are generally not considered their own remote data processing solutions (RDPS). However, they must be taken into account as an external dependency in the cybersecurity risk assessment pursuant to Article 13(2) of the CRA and are subject to the due diligence obligations of Article 13(5) of the CRA (guidelines, pages 68 f.). For manufacturers, this means reviewing contracts and relationships with such services within the supply chain as well.

3. Spare parts: functional analysis, stricter context verification

The CRA also addresses spare parts. Every component with digital elements that is placed on the market individually is fundamentally a product in its own right under the CRA, complete with its own risk assessment, its own conformity assessment, and its own CE marking. This would be impracticable for repairs. Article 2(6) of the CRA therefore exempts spare parts that replace identical components and are manufactured according to the same specifications (see also Recital 29 of the CRA). In practice, where this exception ends determines whether a spare part can be supplied without further ado or whether it becomes a separate CRA case.

The guideline interprets the spare parts exception flexibly and therefore fundamentally makes it easy to control. „Identical“ does not necessarily mean physically or technically the same in every respect. The decisive factors are the functional role and the properties relevant to cybersecurity (guideline, page 32 marginal no. 99). Minor deviations are therefore harmless as long as they do not alter the cybersecurity profile of the component. Differences in algorithms, communication protocols, cryptographic mechanisms or access controls, on the other hand, speak against a common identity (guideline, page 32 marginal no. 100). In that case, the new spare part is to be treated as a separate product with digital elements.

The context is also decisive. The part must be supplied specifically for the repair or the extension of the lifespan of an identified product or product family; technical compatibility alone is not sufficient. The repair purpose must be evident from the circumstances of delivery, such as the order, quotation, or after-sales channel, and the supporting evidence must be kept for market surveillance (guidelines, pages 31 f, marginal note 97). A complete product that is integrated into a larger one, such as a programmable logic controller in an automation system, can also fall under the exception (guidelines, page 33, marginal note 102).

4. Free and Open-Source Software (FOSS)

Open-source software poses a fundamental problem for the CRA. The regulation ties its obligations to the making available on the market as part of a commercial activity. However, a large portion of open-source software is created without any sales process; it is published and not sold. The guide therefore addresses this issue in three steps and dedicates one of its longest sections to it, spanning around 14 pages (Guide, pages 16 ff.).

The first step concerns the term. According to Article 3, point 48 of the CRA, FOSS is only considered to be software that cumulatively fulfills two conditions: it is under a free and open-source license that grants all rights to access, use, modify, and redistribute, and its source code is openly shared. If the source code is made accessible only to paying customers or a limited circle, it is not FOSS within the meaning of the CRA despite having a free license (Guideline, page 17, marginal no. 44 et seq.).

In the second step, it must be clarified who is responsible for the software. This is the person who publishes it and decides on development, releases, and distribution—in practice, therefore, the „maintainers“ (regarding the term: Guidelines, page 18, marginal number 49). Anyone who merely contributes code remains a contributor and has no CRA obligations—even if they have commit rights. Technical permissions alone do not establish responsibility (Guidelines, page 18, marginal number 49, as well as Recital 18 CRA).

The third step is commercial activity. Anyone who charges a price for the software itself, for example for pre-compiled binaries, places it on the market and is a manufacturer (Guidelines, page 18, marginal number 51). The same applies if other products or services are monetized via the free software, for example via advertising, commissions, or subscriptions, or if use is tied to the processing of personal data for purposes other than improving security, compatibility, or interoperability (Guidelines, page 19, marginal number 54).

• Paid support and consulting services related to freely available software do not, in and of themselves, make it commercial. The decisive factor is whether access to the software or its maintenance is tied to a payment (guideline, page 20, marginal no. 55 et seq.). Regarding donations, the guideline goes further than recital 15 of the CRA suggests: a mere donation link does not constitute a profit-making intent, even if the revenue exceeds the costs of conception, development, and provision. FOSS supported exclusively through donations is therefore generally not considered placed on the market (guideline, page 21, marginal no. 61).
• The situation is different if downloads, current versions, or security updates are effectively only available to donors. In that case, the donation acts like a price (guideline, pages 21 f., marginal note 62 including examples 21 & 22). On the other hand, who finances the development does not change this classification: sponsorships, grants, or paid development work do not turn freely available FOSS into a market product (guideline, page 22, marginal notes 63 ff.). Non-profit organizations whose surpluses are used exclusively for non-profit purposes also do not put the FOSS they publish into circulation (guideline, page 22, marginal note 66).

Remarkable is the treatment of dual models. A Community Edition remains an independent, non-monetized product, even if the same provider builds a paid edition on the same code or incorporates it into a larger product. Assessment is product-related and not based on the business model as a whole (Guideline, page 19 marginal number 52). If the provider is a legal entity, however, it is subject to the duties of an open-source software administrator for the free version (Guideline, page 19 marginal number 53).

For projects that are not placed on the market, the CRA provides for a distinct role with mitigated obligations. Open-source software stewards („open-source software stewards“, Art. 3 point 14 CRA) are legal entities that sustainably support FOSS without monetizing it, for example through hosting, governance, or dedicated development resources. They are subject only to the obligations of Article 24 CRA, and the extent of the reporting obligations depends on the type of support pursuant to Article 24(3) CRA. Those who provide exclusively non-technical support, such as branding, governance rules, or community work, have no reporting obligations. Those who provide the project's IT infrastructure must report severe incidents in that infrastructure pursuant to Article 14(3) CRA. Only those who contribute dedicated development resources, for example through release management or the handling of vulnerability reports, must also report actively exploited vulnerabilities pursuant to Article 14(1) CRA (Guideline, pages 25 f, marginal nos. 79 ff). The typical case is the foundation behind a major project.

For companies that merely use open-source components, the situation remains manageable. Anyone who integrates FOSS into their own product does not thereby become the manufacturer of the component. However, they remain responsible for their own product, owe the due diligence pursuant to Article 13(5) of the CRA, and must report vulnerabilities in integrated components and contribute security fixes back to the project (Article 13(6) of the CRA; guidelines, page 26, marginal no. 86 et seq.).

5. Updates and essential changes

Software is continuously being further developed. The CRA must therefore answer when an update legally becomes a new product. The term for this is substantial modification pursuant to Article 3(30) of the CRA, meaning a modification after the placing on the market that either affects the compliance of the product with the essential requirements set out in Annex I, Part I, or results in a change to the intended use for which the product has been assessed.

The delimitation determines the effort, schedule, and deliverability. A substantially modified product is considered newly placed on the market, requiring a new conformity assessment, updated technical documentation, and a new declaration of conformity. Anyone who substantially modifies and makes available a third-party product becomes a manufacturer themselves (Articles 21 and 22 CRA), and anyone who substantially modifies a product placed on the market before December 11, 2027, after that date does so as well (Article 69(2) CRA; Guide, page 30, marginal no. 91).

The benchmark is the risk and not the technical scope. As a rule, a security update is not a substantial modification, even if it makes deep changes to the code (Recital 39 CRA; Guidelines, page 36, marginal no. 108). Conversely, even a small feature can be sufficient. The guidelines cite as an example a „remember me“ function that stores login tokens locally: technically inconspicuous, but posing new risks of token theft and session hijacking and thus constituting a substantial modification (Guidelines, page 35, Example 44).

The guide names four questions that can be used to direct the assessment (guide, page 37, marginal note 110). Does the update introduce new attack vectors, such as additional interfaces, communication channels, or external dependencies? Does it enable new attack scenarios? Does it alter the probability of already known scenarios? Or does it change their impact? If the answer is consistently no and the assumptions of the risk assessment still hold, there is generally no significant change.

One relief in this regard is frequently overlooked. Functions that the manufacturer has already provided for and evaluated in its risk assessment may be unlocked later without this constituting a substantial modification (guideline, pages 34 f, marginal no. 106 including ex. 42 & 43). Anyone who includes planned roadmap functions early in the risk assessment spares themselves compliance work later.

The consequences are more proportionate than in the draft. If the original manufacturer carries out the modification, they remain the manufacturer, but can continue to use existing tests and documentation for unchanged aspects and focus the conformity assessment on the modified parts (Guide, page 40 f). If a third party substantially modifies the product and makes it available, pursuant to Article 22 of the CRA, the manufacturer obligations generally apply only to the modified part, unless the modification affects the cybersecurity of the product as a whole (Guide, page 39 f).

With this, the Commission defuses the interpretation set out in the draft, according to which a substantial modification to a product placed on the market before the date of application would always force the entire product into full CRA compliance. It remains unaffected that the substantially modified product is considered as newly placed on the market.

Regardless of the classification, vulnerability handling pursuant to Annex I, Part II of the CRA remains applicable, and risk assessment as well as technical documentation must be kept continuously up to date (Art. 13(7) and Art. 31(2) CRA; Guidelines, page 38, marginal no. 113).

In everyday operations, three cases can be distinguished. A bug fix or security update changes neither the conformity assessment nor the support period. A new feature with new risks is a substantial modification, but triggers the assessment only for the modified parts and does not automatically restart the support period. A spare part without modified cybersecurity-relevant properties remains outside the scope of the CRA pursuant to Article 2(2) [note: literal translation is Article 2 Paragraph 6], provided the repair context is demonstrable.

6. The support period: reassessment yes, restart no

The support period is the timeframe during which you must address vulnerabilities and provide security updates. It is based on the expected lifetime of the product and must be disclosed to customers at the time of purchase (Article 13(8) CRA; Guidelines, page 42 et seq.). As a result, it is also a sales and pricing matter rather than just a technical metric.

A material change triggers a reassessment of the support period, but does not automatically lead to its restart or extension. The decisive factor is whether the change affects the factors that originally determined the expected useful life. If they remain the same, only the remaining time of the original period continues to run for the modified product (Guideline, page 44 et seq.).

Two further clarifications deserve attention. The five years are a lower limit and not a standard value, because where a longer useful life is to be expected, the period is to be set longer. And in the case of iteratively developed software, each version placed on the market is to have its own declared support period. Although Article 13(10) of the CRA permits vulnerabilities to be fixed only in the respective current version, this is only allowed if the upgrade is possible free of charge and without additional costs. According to the guidance, this does not cover what goes beyond what is usual for software updates, such as forced new hardware purchases (guidance, page 42 ff).

7. Core functionality and modular products

The classification as an important or critical product (Articles 7 and 8 in conjunction with Annexes III and IV of the CRA) is based on the core functionality of the product as a whole. The technical descriptions of the categories can be found in the Implementing Regulation (EU) 2025/2392. The path to conformity depends on the classification. Standard products may be assessed internally, important Class I products only if a relevant harmonized standard, a common specification, or a European cybersecurity certification scheme is fully applied. For Class II and for critical products, an external body must be involved (guideline, pages 47 et seq. and pages 52 et seq.).

Additional functions that merely complement or extend the core functionality do not change the classification. Nor does the integration of a higher-classified component have a spillover effect. A smartphone that contains an operating system is therefore not an operating system itself. To select the conformity assessment procedure, a single core functionality is assigned to a product, which must be named in the technical documentation. Caution is advised with modular platforms. Modules with their own functionality that can be purchased, licensed, or subscribed to separately are standalone products and must be classified separately (guidelines, pages 47 ff).

8. Reporting obligations: ready for September 11, 2026?

Starting from September 11, 2026, the Reporting obligations pursuant to Article 14 CRA for actively exploited vulnerabilities and severe security incidents. Reporting is done once via the ENISA Single Reporting Platform. The report goes simultaneously to that CSIRT, i.e., the responsible national computer emergency response team designated as coordinator for the location of the main branch, and to ENISA. An additional report pursuant to the CRA is not intended alongside this. Reporting obligations under other legal acts, such as the NISG 2026 or Article 33 of the GDPR, remain unaffected by this (Guidelines, pages 74 et seq.).

The schedule is tight. The early warning must be submitted within 24 hours of awareness, further information will follow within 72 hours, the final report for vulnerabilities no later than 14 days after the availability of a corrective measure and for security incidents within one month (Article 14(2) to (4) CRA).

The guideline specifies the scope of application in several respects. The obligations also cover products placed on the market before September 11, 2026, and continue to apply after the support period has expired. The CRA does not require retroactive reporting of vulnerabilities that were already known and exploited before the deadline, but it does require reporting if the exploitation occurs or becomes known only afterward (guideline, pages 78 f.). In the case of vulnerabilities in third-party components, the end-product manufacturer's reporting obligation only applies if the vulnerability is actively exploited in their product. Obligations regarding vulnerability handling and reporting to the upstream provider remain unaffected (Article 13(6) CRA; guideline, page 77). The information provided to users pursuant to Article 14(8) CRA must be risk-based and proportionate. Unfiltered disclosure of technical details is not required where it would increase the risk.

This can be prepared in just a few steps. Set up an EU Login account for registration, the ENISA guidelines work through registration and reporting, identify the responsible CSIRT, and set up the internal escalation so that the 24-hour deadline is met even on a Friday evening. Anyone who accesses the platform for the first time only when an emergency occurs loses precisely the hours that make up the deadline.

Conclusion and next steps

The guideline is more than an editorial update. It is much closer to the realities of modern software development and industrial systems than the draft from spring 2026. It is not legally binding. Those who deviate from it do not act unlawfully per se, but bear the burden of proof vis-à-vis market surveillance authorities and notified bodies. Manufacturers should therefore redefine locally executed software and web applications, introduce a documented equivalence check of cybersecurity-relevant properties for spare parts, define support periods per version, and establish a written process for substantial modifications. Otherwise, it remains a general appeal: check your supply chains and open-source components and establish robust reporting processes for September 11, 2026.

Frequently Asked Questions (FAQs)

Are you prepared for the CRA?

ATB.LAW supports you in establishing and maintaining CRA compliance, reviews your contracts, and stands by your side as a partner in all matters relating to EU digital law. Contact Stefan Knotzer and Roman Taudes at any time under office@atb.law or by phone at 01 39 12345 for a non-binding initial consultation.