Cyber Resilience Act: le scadenze del 2026 e del 2027

The Regulation on products with digital elements has been in force since 10 December 2024: reporting obligations apply from 11 September 2026, and the main obligations apply from 11 December 2027.

— Studio LX20 Law Firm

A regulation that touches those who "make" software, not just those who use it.

For years, the European cybersecurity discipline has been read by financial operators as a matter of organisational security: IT risk governance measures, operational continuity, incident management. The Cyber Resilience Act shifts the axis. It does not primarily regulate the user, but the product: hardware and software placed on the European market.

The Commission describes it in explicit terms: «The Cyber Resilience Act (CRA) aims to safeguard consumers and businesses buying software or hardware products with digital elements». The object of protection is therefore the consumers and businesses that purchase products with digital elements; the addressee of the obligations is whoever designs, develops and maintains those products.

For a banking institution or a fintech company, this distinction is not academic. A group that develops a payment application, an onboarding module, an authentication device, and supplies it to third parties in the course of its own activity, does not necessarily find itself in the role of end user. It may find itself in that of manufacturer. Before asking what obligations weigh on that role, however, it is worth asking whether the regulation applies at all.

The perimeter, before the merits.

The provision on scope of application is Article 2 of Regulation (EU) 2024/2847, and must be read together with the definitions in Article 3. Three filters decide almost everything.

The first is placing on the market. The regulation applies to products with digital elements «made available on the market» whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network (Art. 2, para. 1). And making available on the market is, pursuant to Art. 3, point 22), the supply, for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge. An application developed and used solely within the group is not, for that reason alone, made available on the market: internal development is not the triggering fact — the triggering fact is the supply to third parties in the course of a commercial activity.

The second filter is the most relevant for those providing services in an as-a-service mode. Remote data processing solutions fall within the definition of a product with digital elements only where the software has been designed and developed by the manufacturer or under its responsibility, and its absence would prevent the product from performing one of its functions (Art. 3, points 1 and 2). Recital 12 makes this explicit in the negative: cloud services «whose design and development fall outside the responsibility of the manufacturer of a product with digital elements are not covered by the scope», and to SaaS, PaaS and IaaS models Directive (EU) 2022/2555 applies instead. For an operator that predominantly distributes services, not products, this is the first check to be carried out, not the last.

The third filter concerns express exclusions. Article 2 excludes products subject to the rules on medical devices and in vitro diagnostic devices and on motor vehicles (para. 2), those certified under Regulation (EU) 2018/1139 on civil aviation (para. 3), marine equipment (para. 4), identical spare parts (para. 6), and products developed for national security or defence purposes (para. 7): none of these cases intersects with banking or fintech activity, and they are mentioned here so that the reader may verify they have been considered. What must instead be kept under observation is Art. 2, para. 5, which allows the application of the regulation to be limited or excluded, by delegated act, for products already covered by other Union rules addressing the same risks with an equivalent or higher level of protection. This is the exit mechanism relevant to entities already subject to a sector-specific security regime.

The timeline: four dates, two of which have already passed

The most operationally relevant point is the temporal sequence, which Article 71 sets out as follows:

10 December 2024: entry into force of the regulation, the twentieth day following publication in the Official Journal; 11 June 2026: application of Chapter IV, Articles 35 to 51, on the notification of conformity assessment bodies; 11 September 2026: application of Art. 14, manufacturers' reporting obligations; 11 December 2027: general application of the regulation.

The first two substantive deadlines have already matured. The reporting obligations are in force: the Commission describes them as «already applying as of 11 September 2026». The 11 June 2026 date is the one that opened the designation of notified bodies, and must be read together with the timing of a certification procedure, which cannot be compressed at will.

This is not, moreover, a gradual approach that shields the existing product fleet. Article 69, para. 2, limits the substantive requirements to products placed on the market before 11 December 2027 only where, from that date, they undergo a substantial modification; but para. 3 expressly derogates: the reporting obligations under Art. 14 «apply to all products with digital elements that fall within the scope of this Regulation and that have been placed on the market before 11 December 2027». Reporting, therefore, today also concerns what is already installed at customers' premises.

What must be reported, to whom, and by when

Article 14 identifies two triggering events, not one.

The first is an actively exploited vulnerability contained in the product, of which the manufacturer becomes aware (para. 1). The second is a severe incident having an impact on the security of the product (para. 3): pursuant to para. 5, an incident is severe if it has an adverse effect, or is capable of having an adverse effect, on the capability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or if it has led or is capable of leading to the introduction or execution of malicious code in the product or in the user's systems.

In both cases, notification is simultaneous to the CSIRT designated as coordinator and to ENISA, and passes through the single reporting platform established under Art. 16. The deadlines are strict: an early warning within 24 hours of becoming aware; a notification within 72 hours; a final report within 14 days of a corrective measure being made available, for vulnerabilities, and within one month of the notification, for incidents.

Those who have already built notification procedures for other regulatory frameworks do not start from scratch, but nor can they reuse them without verification: the subjective prerequisite (the manufacturer), the object (the product with digital elements), the triggering facts and the addressees differ from those of the network security and financial services regimes.

What the regulation requires of the manufacturer

The Commission summarises the content of the obligations in a way that is useful for structuring a gap analysis: «The CRA introduces mandatory cybersecurity requirements for manufacturers, covering the planning, design, development and maintenance of such products. These obligations must be met at every stage of the value chain.»

Two elements warrant close attention.

The first is the temporal extension. The obligations cover planning, design, development and maintenance, and are not exhausted upon placing on the market: vulnerability management accompanies the support period, defined by Art. 3, point 20), as the period during which the manufacturer ensures that vulnerabilities are handled in accordance with the essential requirements set out in Annex I, Part II. Determining its duration is a product and contractual choice, not a subsequent compliance step. For those marketing software with frequent releases, this is a process requiring documentation, traceability and assigned responsibilities.

The second is the subjective extension along the value chain: the obligations «must be met at every stage of the value chain». Whoever integrates third-party components into its own product cannot regard the matter as delegated to the upstream supplier. On the contractual level, this suggests a review of software supply clauses: service levels on vulnerability management, mutual information obligations, duration of support, audit rights.

Conformity assessment and CE marking

The regulation adopts the typical structure of European product legislation. The Commission states that «Products will bear the CE marking to indicate that they comply with the CRA requirements and national market surveillance authorities will ensure enforcement of the rules».

The ordinary regime, pursuant to Art. 32, para. 1, is the internal control procedure based on module A of Annex VIII: the assessment remains internal to the manufacturer. The involvement of a notified body depends on the product's class. For important products falling within Class I of Annex III, EU-type examination or full quality assurance is required only where the manufacturer has not applied, or has applied only in part, harmonised standards, common specifications or European cybersecurity certification schemes — or where these do not exist (Art. 32, para. 2). This is a condition that today, in the absence of consolidated harmonised standards, must be verified product by product and may alter the outcome. For important products of Class II, the procedure involving a third-party body is always required (Art. 32, para. 3). For critical products, Art. 8 allows a European cybersecurity certification to be imposed by delegated act.

Verification by a notified body, where required, takes place prior to placing on the market. This is a constraint that must be built into release planning, not managed downstream.

The relationship with other regimes

A point not to be underestimated in designing internal compliance: the regulation does not replace other applicable legislation. The Commission clarifies that the CRA «complements other legislation in this area, specifically the NIS2 Directive» and forms part of the Union's 2020 cybersecurity strategy and the Union's security strategy.

For financial operators, however, the overlap that matters is not only that with the NIS2 Directive. Regulation (EU) 2022/2554 (DORA) is not subject to any exclusion under Art. 2 of the CRA, and Recital 125 indeed indicates that the CRA "will facilitate compliance with supply chain security obligations" by entities subject to DORA and NIS2 that use products with digital elements. Recital 72 places DORA among the regimes imposing complementary reporting obligations, and encourages Member States to consider single national points of entry precisely in order to reduce the burden of parallel notifications.

Complementarity means partial overlap, not alternativeness. The same group may be subject to organisational obligations as a financial entity, to reporting obligations as such, and to product and notification obligations as a manufacturer, with thresholds, deadlines and addressees that do not coincide. Mapping the perimeters — which group companies, which products, which services, which processes — is a preliminary activity, not a consequence.

Small and medium-sized enterprises, free software, standards

The framework provides for certain specific tracks. Article 33 sets out support measures for microenterprises and small and medium-sized enterprises. Articles 24 and 25 lay down a dedicated regime for free and open-source software, distinguishing the figure of the open-source software steward — defined by Art. 3, point 14) — from that of the manufacturer, and providing for a voluntary security attestation. Article 27 finally anchors the presumption of conformity to harmonised standards: technical standardisation is the instrument through which general requirements become verifiable specifications, and it is therefore the workstream to monitor in order to anticipate design choices, all the more so because, for Class I products, it determines whether or not a notified body is required.

Commission documentation

On 27 July 2026, the Commission published Communication C(2026) 5252 and its accompanying annex, containing practical guidance «to help manufacturers, developers, and businesses of all sizes meet their obligations under the Cyber Resilience Act». The guidance — adopted within the framework of Art. 26 of the regulation and expressly stated to be non-binding — addresses, among other things, the scope of application with regard to remote data processing solutions and free and open-source software, the notion of substantial modification, the support period, and the procedures for fulfilling reporting obligations. Also available are the legal text, a summary of the provisions, and a frequently-asked-questions document on implementation. This is explanatory material: useful for guiding operational choices, but not a substitute for the legislative text, which remains the sole benchmark for compliance.

What to do now

A reasonable sequence, for those who have not yet begun the work:

Scope: establish, before anything else, whether and for which offerings the regulation applies — product or service, placing on the market or internal use, design responsibility for remotely provided components — and which group entities take on the role of manufacturer within the meaning of Art. 3, point 13). Inventory: identify products with digital elements already placed on the market, including those released in the past, given that the reporting obligations reach them pursuant to Art. 69, para. 3. Reporting process: since the obligation is already in force, verify without delay the capacity to detect, assess and notify, within 24 and 72 hours, both actively exploited vulnerabilities and severe incidents, and the consistency of this with existing notification flows. Classification: verify which products fall within the classes of Annex III and which assessment procedure follows, taking into account the availability of harmonised standards. Support period: determine it at the design stage and reflect it in documentation and contracts. Supply contracts: update clauses with software component suppliers, in line with the extension of obligations along the value chain. Technical documentation: establish, from the design stage, the traceability required for CE marking.

2027 may seem far off. It is not, for those who must revise a product's architecture or negotiate a certification — and it is not at all far off for the reporting obligations, which are not a deadline to prepare for but an obligation already in effect.