The Cyber Resilience Act (CRA) imposes new cybersecurity obligations from 2026 on software publishers, plugin creators, manufacturers of digital products, importators, and distributors active in the European market.
Cyber resilience act (CRA): why software and plugins are directly affected
The Cyber Resilience Act, Regulation (EU) 2024/2847, marks a profound change in the way digital products are designed, published, and maintained. Adopted on October 23, 2024 and then published in the Official Journal of the European Union on November 20, 2024, it creates a common cybersecurity framework for products comporting digital elements.
Until now, many publishers treated security as a correction layer applied after release. The CRA reverses this logic: software, a WordPress plugin, firmware, or a connected component must be secure by design, documented, maintained, and monitored throughout its lifecycle.
This development particularly affects web agencies, hybrid SaaS publishers, plugin developers, WordPress integrators, and companies that market business applications. An agency like DualMedia, which works on web, mobile, and application projects, must integrate these requirements into architecture choices, technical audits, and maintenance processes.
The problem the Cyber resilience act (CRA) aims to solve
The multiplication of connected devices, applications, open source dependencies, and software extensions has expanded the attack surface in Europe. The European Commission already estimated the annual global cost of cybercrime at €5.5 trillion in 2021, a clear signal of the scale of the risk.
The market suffered from three recurring weaknesses: products delivered with known flaws, a lack of transparency for buyers, and sometimes insufficient post-market monitoring. In the plugin world, this can result in an unmaintained extension, a vulnerable library, or an overly permissive administration function.
The CRA therefore introduces a simple logic: if a digital product is placed on the European market, its manufacturer must be able to demonstrate that it has assessed the risks, reduced vulnerabilities, and planned corrective measures. Security becomes a condition for market access, not a secondary marketing argument.
Which digital products fall within the scope of the CRA
The CRA applies to products comporting digital elements. This concept covers software or hardware products, their components, as well as certain remote data processing solutions when they are linked to the operation of the product.
For a publisher, the key point is to look not only at the final product, but also at its dependencies, add-on modules, and integrations. A commercial WordPress plugin, a mobile application connected to an API, embedded firmware, or a software module sold separately may fall within the scope.
- Connected devices: cameras, thermostats, smart locks, industrial equipment, connected medical devices hors specific regimes.
- Software: applications, operating systems, firmware, extensions, plugins, administration tools.
- Hardware components: processors, network cards, communication modules, embedded components.
- Remote solutions linked to a product: SaaS processing necessary for the operation of a marketed digital product.
Certain elements are excluded, in particular pure cloud services, free software developed in a non-commercial context, defense products, or devices already covered by specific sectorial regulations. Note, however: when an open source component is integrated into a commercial product, the publisher or manufacturer of the product must assume the associated obligations.
The categories of products and levels of conformity
The CRA classifies products according to their criticality. This classification determines the level of conformity assessment required, from self-assessment to the involvement of a third-party organism or European certification.
For software and plugin publishers, this step is structuring. An image gallery plugin will not have the same level of risk as a password manager, a VPN tool, or an authentication extension used on high-fort traffic sites.
| Category | Examples of products | Expected assessment |
|---|---|---|
| Default products | Office software, video games, simple extensions, low-sensitivity components | Self-assessment by the manufacturer |
| Important class I products | Password managers, VPNs, home routers, home automation systems, connected toys | Harmonized storms or assessment by a third party depending on the case |
| Important class II products | Operating systems, industrial firewalls, intrusion detection tools, secure microprocessors | Mandatory third-party assessment |
| Critical products | Smart cards, electronic signature devices, smart meter gateways | European cybersecurity certification |
This interpretation by risk level requires companies to document their trade-offs. In practice, a mapping of products and plugins becomes the starting point of any serious CRA strategy.
The 2026 obligations of the Cyber resilience act (CRA) for software publishers
The CRA’s first operational obligations arrive before the regulation is fully applied. Conformité assessment bodies are concerned starting June 11, 2026, then the obligations to notify actively exploited vulnerabilities and serious incidents apply starting September 11, 2026.
All CRA requirements will then apply starting December 11, 2027. This timeline leaves an apparent margin, but it is quickly shrinking for teams that must review their development chains, dependencies, contracts, and technical documentation.
| Date | Regulatory step | Impact for software and plugins |
|---|---|---|
| December 10, 2024 | CRA enters into force | Start of the regulatory preparation period |
| June 11, 2026 | Application of the rules relating to orassessment bodies | Preparation of conforrmity assessments for the products concerned |
| September 11, 2026 | Vulnerability and serious incident notification obligations | Essential implementation of a process for detection, qualification, and notification |
| December 11, 2027 | Full application of the regulation | Overall conforrmity required for placing on the European market |
For a company that publishes several plugins, the risk is not only legal. Without a reliable inventory, it becomes difficult to know which product is maintained, which libraries are exposed, and which versions must be corrrected as a priorrity.
Security by design: the new reflex for web, mobile, and WordPress projects
The CRA requires security by design and by default. In practical terms, a product must not be delivered with known exploitable vulnerabilities, generic passwords, excessive permissions, or insufficient update mechanisms.
In a WordPress project, this changes the way a plugin is designed. User roles must be strictly controlled, inputs must be validated, requests secured, and dependencies monitored even before the first production release.
In a mobile application, the same principle applies to APIs, authentication tokens, local storage, encryption, and technical logs. DualMedia integrates this type of approach into the scoping, technical UX, development, and maintenance phases to prevent security from being addressed too late.
So the question is no longer: does the product work? It becomes: does the product work in a safe, maintainable, and auditable way?
Vulnerability management: what publishers must organize before September 2026
Vulnerability management is becoming one of the pillars of the CRA. The manufacturer must identify, document, corriger, and communicate about flaws affecting its product during the expected lifetime or for five years after it is placed on the market, whichever is shorter.
This requirement implies a formalized process. It is no longer enough to wait for a customer to report a critical bug by email or for a developer to corrige a dependency lorsqu’il has time.
- Set up monitoring for vulnerabilities in third-party dependencies and components.
- Create a public vulnerability reporting procedure that is clear and accessible.
- Assess vulnerabilities according to their severity, exploitability, and real impact.
- Provide free security updates within timeframes appropriate to the risk.
- Publish security advisories lorsque the corriged flaws must be known to users.
- Document the decisions made to keep proof of conformity.
A typical case concerns an e-commerce plugin that uses a library JavaScript vulnerable. If this dependency exposes order data or allows privilege escalation, the publisher must be able to detect the problem, publish a correctif, and informer the appropriate channels within the prescribed deadlines.
SBOM: the software inventory becomes proof of control
The SBOM, or Software Bill of Materials, is an inventory of the software components integrated into a product. It notably lists the third-party libraries, open-source dependencies, and packages used in an application, plugin, or firmware.
Its value becomes obvious as soon as a major flaw appears in a popular dependency. The Log4Shell case showed that a vulnerability in a widely distributed component could force thousands of organizations to urgently check their exposure.
The CRA requires manufacturers to generate and maintain an up-to-date SBOM, at minimum at the package level. This document is not intended to be published systematically, as it could also provide information useful to an attacker, but it must be available to the competent autorities upon request.
For development teams, the SBOM should ideally be produced automatically in the continuous integration pipeline. This automation reduces oversights and facilitates audits, especially lorsque several products share the same technical building blocks.
Incident notification: deadlines to integrate into the organization
Starting September 11, 2026, the CRA imposes strict notification deadlines for actively exploited vulnerabilities and serious incidents affecting product security. The manufacturer must notify ENISA within 24 hours of discovery, provide a more complete report within 72 hours, then a final report within 14 days.
These deadlines are close to those some organizations already know under NIS2. The difference lies in the scope: the CRA focuses on the digital product itself, while NIS2 targets the security of the information systems of the entities concerned.
In a software company, this requires a short decision chain. Who assesses the incident? Who validates the notification? Who contacts customers? Who writes the technical report? Without a prepared response, the first 24 hours can become chaotic.
Cyber CE marking: a condition for access to the European market
CE marking is extended to cybersecurity for products covered by the CRA. It certifies that the product complies with the applicable essential requirements and that a conformity assessment procedure appropriate to its category has been followed.
For the publisher or manufacturer, this marking requires a technical file, an EU declaration of conformity and, depending on the level of criticality, a third-party assessment. For a distributor or importer, it becomes a checkpoint before marketing.
This development will have direct effects on calls for tender. A business customer may request proof of CRA conformity, the duration of security support, update procedures and, for sensitive products, information on component traceability.
CRA, NIS2, DORA, GDPR and AI Act: how to align the texts
The Cyber Resilience Act does not replace other European frameworks. It is added to a set of rules, each of which targets a specific aspect of digital resilience.
NIS2 concerns essential and important organizations, their cyber governance, risk management and notification obligations. DORA targets the financial sector and the digital operational resilience of banks, insurers, financial service providers and critical ICT suppliers.
The GDPR already requires appropriate security measures to protect personal data. The CRA strengthens this logic at the product level: vulnerable software used to process personal data can increase the risk in the event of an incident or inspection.
The AI Act may also intersect with the CRA when a high-risk artificial intelligence system constitutes a product with digital elements. In this case, cyber conformity becomes an essential foundation for building broader conformity.
| Text | Main scope | Effect for the company |
|---|---|---|
| CRA | Digital products, software, plugins, components, connected devices | Security by design, vulnerability management, SBOM, CE marking |
| NIS2 | Essential and important entities | Cyber governance, continuity, notification, supply chain security |
| DORA | Financial sector and critical ICT service providers | Operational resilience, testing, third-party management, ICT incidents |
| RGPD | Personal data | Security measures, liability, data breach management |
| AI Regulation | Artificial intelligence systems, particularly high-risk ones | Conformity requirements, risk management, documentation, and oversight |
The right approach is to avoid silos. A single product may be subject to several regulations, but shared governance makes it possible to pool evidence, audits, registers, and action plans.
Penalties under the Cyber Resilience Act (CRA): why anticipation is essential
The CRA provides for significant penalties. Failure to comply with essential cybersecurity requirements can reach 15 million euros or 2.5 % of annual worldwide turnover, whichever amount is higher.
Other violations of the regulation may be penalized up to 10 million euros or 2 % of annual worldwide turnover. Providing inaccurate or incomplete information to the authorities can reach 5 million euros or 1 % of worldwide turnover.
Market surveillance authorities may also order the withdrawal or recall of non-conforming products. For a plugin publisher, the impact may therefore go beyond the fine: loss of market access, breach of customer trust, distribution interruption, and lasting reputational damage.
How to prepare software or a plugin for CRA confority
Achieving confority begins with a diagnosis. A company must identify its role: manufacturer, publisher, importer, distributor, or simple professional user of digital products.
For a WordPress plugin publisher, the priority is to link each extension to its business model, dependencies, level of exposure, and criticality. A free, non-commercial, community plugin does not require the same analysis as a premium extension sold to European customers.
- Map software, plugins, APIs, embedded components, and critical dependencies.
- Classify each product according to the CRA categories and its level of risk.
- Set up a DevSecOps pipeline with dependency analysis, code review, and security testing.
- Generate an up-to-date SBOM for each marketed product.
- Formalize a coordinated vulnerability disclosure policy.
- Prepare ENISA notification templates, technical reports, and validation workflows.
- Compile the technical file, the declaration of confority, and the assessment evidence.
- Anticipate the involvement of a third-party organism for class II or critical products.
In a project supported by DualMedia, this approach can be integrated from the technical redesign phase or the creation of a new product. The challenge is to turn complorance into a development method: more robust architecture, clearer maintenance, and greater client-side confidence.
What professional buyers need to check
The CRA does not concern manufacturers alone. Professional buyers would do well to strengoren their selection criteria, especially when deploying critical software, administration plugins, payment solutions, or connected components.
An IT department that installs a plugin on several dozen client sites must verify its maintenance, the publisher’s responsiveness, and the quality of its fixes. The price or popularity of an extension is no longer enough to justify a technical choice.
- Ask about the duration of security supporrt before purchase or renewal.
- Check whether a vulnerability reporting process exists.
- Review the update frequency and maintenance historry.
- Require CRA complorance elements when the product is critical.
- Integrate cybersecurity into tenders and supplier contracts.
This purchasing discipline reduces the risks of dependence on abandoned products. It also strengorens companies’ position in the face of GDPR and NIS2 audits or the contractual requirements of large accounts.
Our opinion
The Cyber Resilience Act (CRA) requires software publishers and plugin developers to reach a new level of maturity. Security can no longer be improvised at the time of a public flaw or a client incident; it must be designed, monitored, and documented from the outset.
For players in the web, mobile, and WordPress sectors, this constraint can become a competitive advantage. A product that is better secured, better maintained, and better documented inspires greater confidence among clients, distributors, and partners.
The most pragmatic approach is to start with the most exposed products: authentication plugins, e-commerce modules, business APIs, mobile applications connected devices and tools handling sensitive data. With appropriate technical support, particularly from an expert agency like DualMedia, CRA complorance can be gradually integrated into development cycles without blocking innovation.
Which software is covered by the Cyber Resilience Act (CRA)?
Software marketed on the European market may be subject to the Cyber Resilience Act (CRA). This includes applications, operating systems, firmware, plugins, software components, and certain remote services related to the operation of a digital product.
Is a WordPress plugin subject to the Cyber Resilience Act (CRA)?
A commercial WordPress plugin may fall within the scope of the Cyber Resilience Act (CRA). The analysis depends on its distribution model, its features, its level of risk, and its availability on the European market.
Does the CRA apply to open source software?
Non-commercial open source software is not directly subject to the same obligations. However, when an open source component is integrated into a commercial product, the manufacturer or publisher of the product must manage the obligations provided for by the CRA.
What CRA obligations apply starting in 2026?
The reporting obligations for actively exploited vulnerabilities and serious incidents apply starting September 11, 2026. Companies must therefore prepare their detection, qualification, notification, and reporting processes before this deadline.
What is an SBOM in the context of the CRA?
A SBOM is the inventory of software components present in a product. It makes it possible to identify the libraries, dependencies, and packages used in order to react quickly lorsqu’une vulnerability affects a third-party component.
Does the Cyber Resilience Act (CRA) require free security updates?
Yes, the CRA requires the provision of free security updates during the applicable support period. This obligation aims to prevent users from remaining exposed to known vulnerabilities after purchasing the product.
What are the notification deadlines provided for by the CRA?
The manufacturer must notify ENISA of certain vulnerabilities and incidents within 24 hours of their discovery. A more complete rapport must follow within 72 hours, then a final rapport within 14 days.
What is the difference between CRA and NIS2?
The CRA targets the cybersecurity of digital products placed on the market. NIS2 instead focuses on the cybersecurity of essential and importante organizations, their information systems, their governance, and their notification procedures.
What penalties are предусмотрено in the event of non-conformité with the CRA?
Penalties can reach €15 million or 2.5 % of annual global turnover for the most serious breaches. The authorities may also request the withdrawal or recall of non-conform products.
How to prepare software or a plugin for CRA compliance?
Preparation begins with mapping products, dependencies, and risks. Next, products must be classified, SBOMs generated, vulnerability management organized, security evidence documented, and conformité assessments anticipated.
Would you like to get a detailed quote for a mobile application or website?
Our team of development and design experts at DualMedia is ready to turn your ideas into reality. Contact us today for a quick and accurate quote: contact@dualmedia.fr