Cyber Resilience Act guidance: which products, which obligations, from when

The European Commission approved on 27 July 2026 the content of its Cyber Resilience Act (CRA) guidance, the most detailed interpretive document published so far on Regulation (EU) 2024/2847. Eighty-three pages, 67 worked examples, five flowcharts. Non-binding, but it is the reading that market surveillance authorities and notified bodies will apply.

Below is a schematic outline of the scope, obligations and timing of the CRA in the light of what prescribed by the guidance.

To which products does the Cyber Resilience Act guidance say the CRA applies?

According to Article 2(1) of the CRA, it applies to

a product with digital elements whose intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network.

Two clarifications introduced by the guidance are of immediate practical relevance:

• A data connection presupposes the transmission of digitally encoded information, deliberately generated by a sender according to a defined scheme and capable of being decoded as information at the destination, with the consequence that the mere switching of an output on and off does not constitute a data connection.
• Placing on the market, in turn, presupposes supply in the course of a commercial activity, a notion that the guidance addresses at length in relation to open-source software.

Software: the place of execution determines the outcome

The distinction is particularly significant for the gaming and gambling sectors, since a downloadable game client constitutes a product with digital elements, whereas a title played exclusively through a browser does not fall within the scope of the Regulation on that basis alone.

A further rule governs the moment of placing on the market for standalone software. Once a given version is first supplied for distribution or use on the Union market, all copies of that version are considered placed on the market at that same moment, irrespective of the date on which each individual user subsequently downloads it.

A version supplied on 1 January is therefore placed on the market on that date both for the customer who acquires it immediately and for the customer who acquires it several weeks later. Variants of the same software that differ in included components, configurations or enabled functionalities, such as builds for different operating systems or bundles with differing feature sets, are treated instead as distinct products.

Hardware and software may constitute a single product

The channel through which software is delivered to the user is not decisive. Where software is necessary to operate, configure, control or use hardware in accordance with its intended purpose, the two elements together constitute a single product with digital elements, even where the software is obtained separately through an application store or a download link after the hardware has been placed on the market. Both elements are consequently placed on the market at the same point in time.

The guidance illustrates the principle through a network printer that cannot fulfil its intended purpose without its drivers and a fitness wearable whose measurements can be displayed and configured only through the manufacturer’s companion application. The same reasoning applies to console peripherals, virtual reality headsets and connected devices supplied with dedicated configuration utilities.

Cloud services: when remote processing forms part of the product

Remote data processing solutions fall within the perimeter of the product with digital elements. Their identification rests on three cumulative questions:

1. Does the data processing take place at a distance, whether on public cloud infrastructure, on a private cloud or on servers located on the manufacturer’s own premises?
2. Would the absence of that data processing prevent the product from performing one of its functions, this notion being broader than the core functionality or the intended purpose?
3. Has the software been designed and developed by the manufacturer, or under its responsibility, meaning that it has been built solely by or on behalf of the manufacturer on the basis of designs and specifications provided by it?

Where all three questions are answered affirmatively, the remote component forms part of the product and must be addressed in the risk assessment, in the technical documentation and in the conformity assessment. Software deployed by the manufacturer on third-party Infrastructure as a Service or Platform as a Service offerings will ordinarily satisfy the third condition, whereas a third-party Software as a Service application integrated into the product will not, and must instead be treated as a third-party component subject to due diligence and to product-level mitigation measures.

Two boundaries limit the perimeter:

• Only the software modules responsible for the functionality of the product, together with the interfaces those modules use with external services, qualify as remote data processing solutions, with the consequence that back-end systems with which the product does not directly interact remain external dependencies to be assessed and mitigated at product level rather than components of the product itself; and
• Communication infrastructure (i.e.,cellular networks, routers, ethernet cabling and wireless signals) constitutes an enabler of connectivity rather than remote data processing, and no due diligence obligation arises towards the network provider.

Free and open-source software: responsibility first, monetisation second

Software qualifies as free and open-source software only where two conditions are satisfied cumulatively:

• The software is made available under a licence granting the full set of rights referred to in Article 3(48), and
• Its source code is openly and publicly shared.

Software distributed under an open-source licence whose source code is disclosed only to paying customers or to a restricted group of users does not qualify as FOSS for the purposes of the Regulation.

The assessment then proceeds in two stages:

1. Is the software under the responsibility of a given person? Responsibility rests with the natural or legal persons who publish the software and exercise primary control over its development, releases and distribution decisions, generally described as maintainers. Persons who contribute source code without controlling releases, roadmaps or governance are contributors and remain outside the scope of the Regulation, and the existence of technical permissions such as commit access is not sufficient to establish responsibility.
2. Is the software monetised? The guidance addresses the principal scenarios as follows:

The EU Commission expressly neutralises two circumstances that are frequently misunderstood:

• The manner in which development has been financed is irrelevant to the commercial character of the supply, so that grants, sponsorships and paid feature development do not convert a project into a product placed on the market; and
• A not-for-profit entity established in such a way that all earnings after costs are used to achieve not-for-profit objectives does not place its FOSS on the market, even where the software is directly monetised.

Where FOSS is published without being placed on the market, the legal person publishing it may qualify as an open-source software steward under Article 3(14) and become subject to the more limited set of obligations laid down in Article 24. A single entity may hold both roles simultaneously in respect of different projects, and an entity publishing both a free community edition and a paid enterprise edition of the same software will be the steward of the former and the manufacturer of the latter. The reporting obligations of stewards are calibrated to the support actually provided, in accordance with Article 24(3):

Categories falling outside the scope of the Regulation

Three categories warrant particular attention:

1. Spare parts intended to replace identical components and manufactured to the same specifications are exempt under Article 2(6), with identity assessed by reference to the functional role of the component and to those characteristics that are relevant to cybersecurity, such as cryptographic mechanisms, protocols and access control features;
2. Components designed and constructed exclusively for integration into vehicles covered by Regulation (EU) 2019/2144 or Regulation (EU) No 168/2013 fall outside the scope, provided that the exclusivity of their destination is objectively verifiable; and
3. Products governed by the other instruments listed in Article 2(2) are likewise excluded.

The exemption for spare parts is subject to an evidentiary condition that manufacturers should anticipate. The maintenance or repair purpose must be apparent from the context of the supply, whether through identification of the product or product family in the order or commercial offer or through supply via after-sales or service channels, and supporting evidence must be kept available for market surveillance authorities. The same item offered through general retail or through online channels open to the public will not benefit from the exemption.

What are the obligations under the Cyber Resilience Act guidance?

The obligations may be organised into six blocks, which are cumulative rather than alternative.

1. Cybersecurity risk assessment

The risk assessment required by Article 13(2) constitutes the foundation of the entire compliance architecture, since it determines which of the essential requirements set out in Part I of Annex I are applicable to the product and how those requirements are to be implemented.

Three principles are behind the cybersecurity risk assessment:

1. The internal risk tolerance of the manufacturer, its commercial strategy and considerations of cost are not relevant in determining whether identified risks have been sufficiently addressed;
2. The Regulation does not permit the transfer of cybersecurity risk or responsibility to users or third parties in order to compensate for shortcomings in product design; and
3. Where the assessment identifies risks that cannot be adequately treated, compliance may require changes to the design, to the functionality or to the intended purpose of the product.

Residual risk is recognised as an inherent outcome of any risk treatment process, since cybersecurity risks cannot be entirely eliminated. It cannot, however, be accepted at the discretion of the manufacturer, and a product may be placed on the market only where residual risks have been sufficiently addressed through the implementation of the essential requirements.

2. Essential requirements, due diligence and technical constraints

Part I of Annex I governs product security and Part II governs vulnerability handling. Components sourced from third parties attract the due diligence obligation laid down in Article 13(5), which requires the manufacturer to

• Determine what the product needs from each component in order to meet its cybersecurity objectives; and
• Verify, in a risk-based manner, that the component satisfies those needs, whether through technical specifications, security documentation, conformity or assurance documentation, or testing.

External elements that the manufacturer does not control must nonetheless be addressed through product-level measures. The guidance refers, among others, to

• Cryptographic authentication of remote commands,
• Verification of the integrity of configuration changes;
• Generation of security-relevant logs and the assurance that the unavailability of an external service does not cause the product to enter an insecure state.

Complex systems receive proportionate treatment rather than an exemption. Where an essential requirement cannot be fulfilled because the intended purpose of the product requires interoperability with existing dependencies or compliance with mandated interoperability requirements, the manufacturer is expected to identify and document the constraint, to assess the associated risks and to implement alternative or compensatory mitigation measures. Where the product is technically capable of supporting both a secure protocol and a legacy protocol, the secure protocol is to be implemented and enabled by default. The constraint must be reassessed periodically, and the product updated where the constraint can be lifted or reduced over time.

3. Conformity assessment and the notion of core functionality

For the purposes of determining the applicable conformity assessment regime, a product may have only one core functionality, which corresponds to its main features and technical capabilities, without which the product would not be able to meet its intended purpose.

Functions ancillary to the core functionality do not alter the classification, so that a smartphone integrating an operating system does not thereby acquire the core functionality of an operating system, and security orchestration, automation and response software whose capabilities substantially exceed those of a security information and event management system is generally not classified as such a system. The guidance states expressly that a manufacturer may not misrepresent the core functionality of its product in order to escape a more stringent regime, and identifies inconsistencies between promotional materials, instructions for use and technical documentation as the indicator that authorities will examine.

Further points are relevant:

• The application of a harmonised standard covering the core functionality permits recourse to the internal control procedure, but the presumption of conformity extends only to the risks actually covered by that standard, with the consequence that ancillary functionalities falling outside its scope benefit from no presumption and require the additional measures adopted to be separately documented;
• Modules that are also made available on the market separately, whether through separate purchase, licensing or subscription, constitute standalone products classified on the basis of their own respective core functionalities;
• Where variants of a product share the same architecture, security-relevant design and intended purpose, and are exposed to the same cybersecurity risks, a single risk assessment, a single set of technical documentation, a single conformity assessment and a single EU declaration of conformity may cover the entire family, provided that the declaration clearly identifies the variants concerned.

4. Support period

The minimum period of five years operates as a safeguard rather than as a default, since Article 13(8) requires the support period to reflect the period during which the product is expected to be in use, with the consequence that products reasonably expected to remain in use for longer than five years should be given correspondingly longer support periods. The end date of the support period must be indicated to the purchaser at the time of purchase, specifying at least the month and the year.

Article 13(10) introduces a measure of flexibility for iteratively developed software, permitting the manufacturer to address and remediate vulnerabilities only in the version last placed on the market, provided that users of earlier versions may upgrade free of charge and without incurring additional costs. The guidance interprets the notion of additional costs restrictively:

• personnel time,
• routine testing,
• configuration adjustments and
• upgrades of underlying dependencies

constitute reasonable operational effort inherent in software maintenance, whereas mandatory purchases of new hardware, infrastructure replacement and fundamental changes to the operating environment fall within the notion and preclude reliance on the provision.

5. Vulnerability handling and upstream obligations

The obligations under Part II of Annex I comprise policies and procedures for handling vulnerabilities reported from internal or external sources, the provision of security updates, a coordinated vulnerability disclosure policy and the application of effective and regular tests and reviews throughout the support period. The requirement of regularity does not entail the mechanical repetition of an unchanged test campaign at fixed intervals, but rather the periodic review of whether newly identified threats or newly discovered vulnerabilities require the existing tests to be updated, followed by the execution of the tests so identified.

Products must be made available on the market without known exploitable vulnerabilities. A vulnerability is to be regarded as known where it is listed in the European vulnerability database or in other prominent vulnerability databases, where it has been disclosed to the manufacturer through coordinated disclosure by a security researcher, where it has emerged from the manufacturer’s own internal testing and analysis, or where it has been publicly and prominently reported by reliable media outlets. A vulnerability is exploitable where it has the potential to be effectively used by an adversary under practical operational conditions, as distinct from theoretical or laboratory conditions.

The report of a vulnerability does not, however, amount to its confirmation. The manufacturer is required to investigate the report, to verify its veracity and its applicability to the specific product, and thereafter to determine, on the basis of the cybersecurity risk assessment, whether the product may be securely placed on the market or whether the vulnerability must first be remediated. The guidance accepts that postponing a release carries its own risks, particularly where the release also remediates other exploitable vulnerabilities or is necessary for the continued operation of critical systems.

Vulnerabilities identified in integrated components must be reported to the person or entity manufacturing or maintaining the component, in respect of the version integrated and in accordance with any established disclosure channels, and any security fix developed by the manufacturer must be shared upstream in a machine-readable and verifiable format compatible with the licence of the component. Manufacturers are encouraged to consult publicly accessible vulnerability databases, project-specific advisories and issue trackers before reporting, in order to avoid duplicate submissions, and are relieved of the obligation where the maintainer is already aware of the vulnerability or where the component no longer has a maintainer.

6. Reporting to ENISA and to the CSIRT

Actively exploited vulnerabilities and severe incidents having an impact on the security of the product must be notified simultaneously to ENISA and to the CSIRT designated as coordinator, in accordance with the following sequence:

A vulnerability affecting an integrated third-party component is subject to mandatory notification only where it is actually being exploited in the manufacturer’s product. Where the vulnerable code is not reachable, or where the vulnerability has not been exploited in that product, the mandatory reporting obligation does not arise, although voluntary reporting under Article 15 remains available and the vulnerability handling obligations continue to apply in full.

The moment from which the deadlines run is defined by reference to awareness. The manufacturer is regarded as having become aware when, following an initial assessment conducted promptly upon detection of a suspicious event or upon receipt of a report from a third party, it holds a reasonable degree of certainty that a vulnerability contained in its product is being actively exploited or that a severe incident has compromised the security of that product. Impacted users must also be informed under Article 14(8), on a risk-based and proportionate basis, and the guidance confirms that disclosure may be limited to the users or customers concerned where the product is deployed in sensitive or essential environments and where public disclosure of technical details could itself facilitate further exploitation.

3. When do the obligations apply?

Four points relating to the temporal application of the Regulation merit particular attention:

1. The reporting obligation does not operate retroactively. Active exploitation of which the manufacturer had already become aware before 11 September 2026 falls outside the obligation. Where, by contrast, the manufacturer was aware of a vulnerability before that date without being aware of any active exploitation, and exploitation subsequently occurs or comes to its attention thereafter, the vulnerability becomes subject to the reporting obligation. The obligation applies to products placed on the market before 11 December 2027 and continues to apply after the expiry of the support period.
2. Products designed before the date of application do not require redesign. Units manufactured in accordance with a type or model designed before December 2027 may be placed on the market thereafter, provided that a current cybersecurity risk assessment demonstrates that the existing security measures address the identified risks. The manufacturer is not required to recreate historical design or test documentation, since doing so would not contribute to the security of the product, but remains subject to the conformity assessment procedure, the drawing up of the EU declaration of conformity, the affixing of the CE marking and the vulnerability handling obligations.
3. A substantial modification results in a new placing on the market. A modification qualifies as substantial where it alters the level of cybersecurity risk in a manner that the manufacturer had not considered in its risk assessment, or where it modifies the intended purpose for which the product has been assessed. The scale of the change is not determinative: the introduction of a persistent login feature storing authentication tokens locally has been identified as a substantial modification, whereas the activation of functionalities already foreseen and assessed in the original design has not. Security updates are generally not substantial modifications, since their purpose is to reduce risk, unless they alter the intended purpose or introduce new dependencies, as occurs where local encryption functionality is replaced by a remote encryption service operated by the manufacturer. The assessment may usefully be structured around four questions drawn from the guidance, namely whether the update introduces new threat vectors, whether it enables new attack scenarios, whether it changes the likelihood of previously identified attack scenarios and whether it changes their potential impact. A negative answer to all four indicates that the modification is unlikely to be substantial, provided that the assumptions and mitigation measures relied upon in the risk assessment remain valid. The consequences depend upon the identity of the person carrying out the modification. An importer, a distributor or any other natural or legal person who substantially modifies a product already placed on the market and makes it available becomes its manufacturer, in respect of the modified part alone where the modification does not affect the cybersecurity of the product as a whole, and in respect of the entire product where it does. The assembly of components into a new product does not constitute a modification at all, since the integrator places a new product on the market and is its manufacturer for all purposes. Where the original manufacturer carries out the modification, documentation and test results relating to unaffected parts may be reused, and any third-party assessment focuses on the parts actually modified. A further consequence deserves to be noted, since it is frequently assumed to operate otherwise: a substantial modification does not automatically reset or extend the support period. The relevant question is whether the modification affects the factors that originally determined the expected use time of the product. A software update adding new operating modes to a robot vacuum cleaner does not affect the physical durability of the hardware, so that the original support period continues to run, whereas the replacement of the embedded computing platform of a programmable logic controller with components designed for a significantly longer operational lifetime does affect those factors and requires the support period to be recalculated.
4. Existing certificates provide a transitional benefit of limited scope. An EU type-examination certificate issued under the delegated act supplementing the Radio Equipment Directive or under the Machinery Regulation dispenses the manufacturer from reassessing or re-demonstrating compliance, but only in respect of the cybersecurity risks actually covered by that certificate and only until 11 June 2028, even where the validity of the certificate extends beyond that date under the legislation on the basis of which it was issued. Risks identified through the CRA risk assessment beyond that perimeter, including those relating to vulnerability handling processes, data minimisation and reduction of the attack surface, remain the responsibility of the manufacturer.

Six weeks separate the publication of this guidance from the first enforceable deadline. The greater part of the work required is documentary rather than technical, and concerns the mapping of the product portfolio, the classification of each product, the preparation of technical documentation and risk assessments, and the establishment of a reporting process capable of operating within the twenty-four hour deadline at any hour of the day.

The DLA Piper technology and cybersecurity team assists software developers, gaming operators and manufacturers of connected products with CRA readiness assessments, product classification, technical documentation and vulnerability handling procedures. Enquiries concerning the position of a specific product portfolio are welcome.

On a similar topic, the article “NIS 2 – Personal Liability of Directors For Lack of Compliance” may be of interest.