Why the Cyber Resilience Act (CRA) is not just another compliance measure, but a change in doctrine for anyone placing a digital product on the European market ?
On December 11, 2027, the CE marking will officially incorporate cybersecurity. For the first time in the history of the Union, the security of digital products ceases to be a marketing promise or a differentiating factor: it becomes a enforceable regulatory requirement, subject to sanctions and at the heart of product compliance. As the deadline approaches and the first wave of reporting obligations begins, manufacturers, importers, distributors and publishers who still consider the Cyber Resilience Act as something to be dealt with later are taking a real industrial risk.
This article offers an operational analysis of Regulation (EU) 2024/2847, better known as Cyber Resilience Act (CRA), and charts a credible compliance path for organizations that design, integrate or market products with digital components.
A settlement that puts an end to a historical asymmetry
For thirty years, the digital sector was the only place where a product could be marketed while shirking responsibility for its security flaws. A recalled car, a withdrawn drug, a banned toy: product compliance has long existed for physical goods. But for vulnerable firmware, a connected device left without a patch, or an integrated and then abandoned open-source library, the end user remained—and still remains—the last line of defense against risk.
The CRA puts an end to this asymmetry. Entering into force on December 10, 2024, the regulation applies its main obligations from December 11, 2027, and its reporting obligations from September 11, 2026, pursuant to Article 71. It is a continuation of the European cybersecurity strategy and directly complements the NIS 2 Directive: where NIS 2 regulates the organizations, The Cyber Resilience Act regulates the products. Continuity is intentional — and structuring.
For design, governance, and cybersecurity teams, this means one thing: security can no longer be a late fix. It becomes a intrinsic property of the product, verifiable, documented, and accompanied by long-term commitments.
A horizontal scope of application
The Cyber Resilience Act (CRA) applies to all products containing digital elements (PDEs) placed on the European market, whether hardware or software, if they are capable of establishing a logical or physical, direct or indirect connection with another device or network. Also covered are... remote treatment solutions when they are designed or developed by the manufacturer — or on its behalf — and are necessary for a function of the product. The definition is deliberately broad.
To measure this scope, we need to move beyond the cyber examples that spontaneously come to mind. The CRA primarily covers the daily ecosystem of European citizens and businesses These include connected watches and trackers, thermostats and home automation systems, smart locks, interactive toys, consumer surveillance cameras, connected industrial equipment, mobile applications, and professional software. "Cyber" products in the strict sense, such as firewalls, SIEMs, VPNs, or password managers, represent only a fraction, albeit one with more demanding compliance procedures.
Article 2 of the regulation also provides for a number of’sectoral exclusions, This applies particularly when products are already subject to other harmonized European legislation, as well as for products developed exclusively for national defense and security. The precise scope of each exclusion must be verified on a case-by-case basis. In most European industrial value chains, at least one product nevertheless falls under the CRA.
The most fundamental distinction then concerns the product classification, which determines the rigor of the conformity assessment process:
- THE standard products — the overwhelming majority of the market, from connected toys to household appliances — fall under a self-assessment by the manufacturer.
- THE important products, These devices, divided into two classes according to their criticality, require a reinforced procedure. Class I includes, for example, password managers, certain home routers, and consumer VPN solutions; Class II covers, in particular, firewalls, IDS/IPS, general-purpose operating systems, hypervisors, and certain secure components.
- THE critical products fall under the most demanding regime: their conformity must, where a relevant European certification scheme is available, be demonstrated by a procedure adapted to the level of assurance required.
The regulation reasons by main function A laptop is not considered a critical product simply because it includes a secure element, but this separately sold secure element may fall under the enhanced security regime. This distinction directly influences the evaluation process that the manufacturer must conduct.
The essential requirements
Annex I of the regulation forms the operational core of the text. It lists the essential cybersecurity requirements that any product concerned must meet. Without going into an exhaustive analysis, six main principles structure the framework:
- Secure and default design.
- No known exploitable vulnerabilities at the time of market launch.
- Secure update mechanism.
- Vulnerability management throughout the entire support period.
- Production and maintenance of a software nomenclature.
- Explicit support period of at least five years, unless a shorter expected lifecycle is justified by the manufacturer.
The text also requires the retention of technical documentation for ten years after the product is placed on the market.
For teams used to thinking in terms of projects and sprints, this shift to a long-term commitment regarding resilience is probably the most profound cultural change brought about by the regulation.
Incident reporting
This is the most immediate obligation, and probably the most underestimated. From September 11, 2026, pursuant to Article 14, manufacturers will have to report to the’ENISA and to the relevant national CSIRT any actively exploited vulnerability affecting any of their products, as well as any serious security incident affecting product security.
The notification schedule follows an escalation logic:
- Early warning within 24 hours of becoming aware of active operations or a serious incident.
- Structured notification within 72 hours, with an initial assessment of severity and impact.
- Final report within 14 days once the corrective or mitigation measure is available for exploited vulnerabilities, or one month after the initial notification for serious incidents.
ENISA is deploying a single reporting platform for this purpose, operational by September 11, 2026; manufacturers submit a single report, which is then relayed to the competent authorities.
For an organization that has never structured its PSIRT, CVD channel, or notification workflows, four months will not be enough. This is especially true for manufacturers whose products are already on the market: the reporting obligation applies from September 2026, regardless of the full implementation of the regulation in December 2027.
The unforgiving calendar
The Cyber Resilience Act is one of the few European regulations to include a phased implementation ramp but without an amnesty mechanism. Three milestones must be included in any 2026-2027 cybersecurity master plan:
| Date | Due date |
| June 11, 2026 | Application of the rules relating to the designation of notified bodies. |
| September 11, 2026 | Entry into force of the reporting obligations of Article 14. |
| December 11, 2027 | Full application of the regulation to all products newly placed on the European market. |
Products placed on the market before December 11, 2027, are not retroactively subject to the main requirements of the CRA, unless there is a substantial subsequent change. However, the reporting obligations of Article 14 apply from September 11, 2026, including to products already on the market.
Added to this is the notion of substantial modification : an update that changes the intended use or significantly increases the cyber risk of an existing product can bring that product back into the CRA scope, even if it was marketed before 2027. The precise scope of this concept will be the subject of Commission guidelines, but it must be integrated into product version decisions from today.
CRA and NIS 2: two texts, one same structure
The most frequent strategic error observed among our clients over the past eighteen months is treating the CRA as a project siloed, disconnected from other ongoing regulatory projects. This is not only ineffective, but costly.
The central link, intended by the European legislator, is that between CRA and NIS 2 NIS 2 regulates organizations operating essential or critical services, while the CRA regulates the products themselves, regardless of the status of the organization that designs them. The NIS 2 directive requires regulated entities to ensure the security of their ICT supply chain; the CRA ultimately provides them with the guarantee that products marketed in the European market meet a minimum cybersecurity standard. The two texts are mutually reinforcing.
For manufacturers whose clients are in the financial sector, a third dimension comes into play in a way indirect The DORA regulation, which governs the operational resilience of financial entities, imposes strict requirements on these entities with regard to their critical ICT providers. While not making the manufacturer directly subject to DORA, this regime creates contractual pressure that can anticipate, or even exceed, the requirements of the CRA.
The challenge for CIOs, CISOs, and legal departments is to pooling cross-cutting evidence — vulnerability management policy, incident response plan, supplier governance, logging — while clearly distinguishing the compliance objects specific to each text: CE marking, EU declaration of conformity and SBOM on the CRA side; register of entities and notifications on the NIS 2 side.
The price of inertia
The CRA's sanctions regime is calibrated to the most stringent European standards. Failure to comply with essential cybersecurity requirements or reporting obligations may result in administrative fines of up to €15 million or 2.51 TFPs of global annual turnover, whichever is higher, in accordance with Article 64.
Beyond the fines, three practical consequences should be anticipated:
- The withdrawal of the non-compliant product from the market by the national supervisory authorities, with a temporary or permanent ban on placing it on the market.
- The reputational risk associated with publicizing withdrawal decisions and incident reports.
- Civil and contractual exposure vis-à-vis professional clients, in particular those who must prove to their own authorities the rigor of their supplier selection.
Building a credible trajectory
At this stage, the operational question is: where to begin? The experience accumulated through consulting, auditing and incident response missions makes it possible to structure a trajectory in six projects, sized over eighteen to twenty-four months.
1. Map the product portfolio. To exhaustively identify the PDEs marketed on the European market, classify them with regard to Annexes III and IV, and decide for each one on the applicable conformity assessment regime.
2. Map the discrepancies with Annex I. Review the design, testing, vulnerability management and update mechanisms to structure the compliance roadmap.
3. Industrialize SBOM and dependency management. Equip the automated production of SBOMs in the CI/CD chain, deploy correlation with CVE flows, and implement tool-based triage of third-party vulnerabilities.
4. Structure the PSIRT and the reporting chain. Define roles, public CVD channels, customer communication models, and simulate end-to-end compliance with deadlines 24h / 72h / 14 days before September 2026.
5. Define the support period and the customer agreement. Decide on the duration of the commitment product by product, formalize the update procedures, and integrate these commitments into the technical documentation and general terms and conditions.
6. Prepare the technical documentation and the EU declaration of conformity. Compile the documentation required by the supervisory authorities: risk analysis, mitigation measures, test evidence, log of vulnerabilities addressed, SBOM, EU declaration of conformity, CE marking.
Conclusion: from delivered product to accompanied product
The Cyber Resilience Act will not be the easiest European regulation for many organizations to absorb. It disrupts economic models built on one-off delivery; it imposes a logic of secure lifecycle where version logic prevailed; he introduces the notion of’long-term commitment in markets accustomed to short-termism.
But—and this is perhaps the most interesting angle for European players—it also rebalances the market. For years, manufacturers who were investing in the security of their products were penalized by the competition from those who did not. The CRA reverses this dynamic. It transforms cybersecurity investment into regulatory competitive advantage, and makes CE marking a mark of trust in a world where doubt has become the norm.
Organizations that take this issue seriously in the coming months will not only avoid fines but will also build a differentiating capital of trust, which can be used against their customers, partners, and regulators. Others will discover, in the fall of 2026 and then the winter of 2027, that product compliance is not something that can be addressed in a rush.
Between these two paths, there are eighteen months and a decision to be made.
About Us
For over 16 years, Intrinsec has offered a comprehensive cybersecurity consulting service, supporting companies across all relevant topics. Governance, Risks, Audit And Compliance.
Since 2024, the Consulting team has been certified PACS by ANSSI across all activities (Risk management, security certification, secure architecture and crisis management preparedness).
