Cyber Resilience Act: the three dates that matter and the transitional period nobody talks about

The Cyber Resilience Act is the European regulation on cybersecurity of «products with digital elements»: software included. It is a regulation, not a directive: it applies directly, without national transposition (EU Reg. 2024/2847). The date everyone cites — December 2027 — is just one of the three provided, and for those who already have software on the market it is not even the first one that matters.

• Three application dates (art. 71): conformity assessment bodies from 11 June 2026, manufacturers' reporting obligations from 11 September 2026, everything else from 11 December 2027.
• Software already on the market remains outside the technical requirements as long as it does not undergo a «substantial modification» — but vulnerability reporting obligations apply to all in-scope products (art. 69).
• Pure SaaS is out of scope: the cloud falls within scope only when it is a functional part of a product (art. 3).
• Free software is not exempt if provided in the course of a commercial activity (art. 3).

The question that every company with software already on the market asks itself is: «do I have to redo everything?». Art. 69 gives an answer in two halves, and almost everyone only tells the first one.

Translated into decisions: existing software escapes technical requirements until it is substantially modified, but it does not escape the obligation to report actively exploited vulnerabilities. Those who already have products on the market should not be asking «what do I do by 2027?»: they should be asking who, within the company, notices an exploited vulnerability and reports it — from September 2026. This is a matter of process and monitoring, not of rewriting code. And for those planning a significant change to an existing product, the date of the change becomes the date on which the requirements kick in: it must be included in the project plan, not discovered afterwards.

The boundary lies in the definitions of Art. 3: the regulation covers software and «the related remote data processing solutions», defined as processing whose absence would prevent the product from performing one of its functions. In practice: the cloud falls within the scope when it is a functional part of a product — the backend without which the app does not work — while a pure SaaS sold as a standalone service does not meet the definition (for that, the reference is rather NIS2). It is a distinction to be handled with precision, because the same architecture can fall on one side or the other depending on how the product is packaged and sold.

Pay attention also to free software: making available on the market covers the supply «for consideration or free of charge [...] in the course of a commercial activity» (Art. 3). A free component distributed as a commercial lever for a paid service falls within commercial activity — a zero price is not a shortcut to exit the scope.

How we position ourselves with respect to these regulations, product by product, is something we have put in black and white on the Security and compliance page.

Many articles on the Cyber Resilience Act open with the fines. We don't mention them, for a simple reason: we have not yet verified Chapter VII on the text of the regulation, and our rule is not to publish regulatory figures read second-hand. The same applies to two points that deserve a dedicated reading: the qualification of software developed under a single commission and the implementing acts on the classes of important and critical products. When we have verified them, we will update this article.

In the meantime, the right motivation for dealing with the CRA is not the fear of a fine: it is that its requirements — vulnerability management, guaranteed updates, transparency on components — are becoming the criterion by which customers choose their suppliers, even before the law makes them mandatory. Those who buy software have already started asking "who maintains it, and how".