Licences and law / Development and agents
Selling a plugin or app in Europe: what the Cyber Resilience Act requires from September
Selling a plugin, browser extension or application can involve cybersecurity responsibilities that go beyond fixing bugs when they appear. Since September 2026, certain manufacturers have had to report vulnerabilities and incidents within specific timeframes, so you need an operational procedure before a problem arises.
If you sell software in the European Union, the Cyber Resilience Act (CRA) already imposes reporting obligations on manufacturers within its scope from 11 September 2026. You need to be able to handle actively exploited vulnerabilities and serious security incidents, submit the required information within the relevant deadlines, and prepare for the other requirements that apply from 11 December 2027.
Your first task is not to develop a new feature. It is to decide how you will receive reports, who will assess their severity, and who will handle reporting and coordinate the response.
Check whether your software may fall within the CRA
The type of product matters. The European Commission guidance published on 27 July 2026 considers certain software that runs on a user device, including browser extensions, to be products with digital elements. Websites operating remotely are generally outside this category.
If you sell a Blender add-on, an extension or a desktop application, it is reasonable to assess whether it falls within the regulation. However, you should not assume that it does without reviewing the product's characteristics and your role in bringing it to market.
Distinguish between these situations:
- Software installed on a user's device: check whether it qualifies as a product with digital elements.
- Browser extension: do not automatically exclude it because it is small or distributed through an extension store.
- Remote web service: assess whether the service falls outside the category described in the guidance or forms part of a product covered by the regulation.
- Open-source project: distinguish your role as a manufacturer from the role that may apply to an open-source software steward.
Classification depends on the circumstances. If you are unsure whether the regulation applies, seek specialist advice before deciding that you have no obligations.
What do you need to do from September 2026?
Article 14 of the CRA establishes reporting obligations for manufacturers. ENISA launched its Single Reporting Platform on 11 September 2026.
The main reporting timeframes described are:
| Criterion | What to check |
|---|---|
| Early warning | Notification within 24 hours. |
| Subsequent notification | Report within 72 hours. |
| Final report for a vulnerability | Submission within 14 days of the patch. |
| Final report for an incident | Submission within one month. |
| Platform access | Set up an EU Login account with two-factor authentication. |
| Products already on the market | Review the applicable obligations even if the product was already being sold. |
The deadlines depend on the type of notification and the specific circumstances. Do not treat them as a single countdown that applies to every technical fault. Establish a procedure to determine whether an issue meets the conditions that trigger the regulation's reporting duties.
The obligation also applies to products already on the market. However, published guidance on the reporting regime indicates that you do not need to report retrospectively what you already knew before 11 September 2026.
How to set up a minimum process for a small team
You do not need to begin with a complex structure. You need to ensure that every relevant report reaches someone who can assess it and take action.
Prepare this checklist:
- Reporting channel: set up an email address or form for vulnerability reports from users, researchers and collaborators.
- Owner: appoint someone to review reports and initiate a response.
- Assessment criteria: document how to distinguish a routine bug from a potentially actively exploited vulnerability or a serious incident.
- Access account: prepare EU Login and the two-factor authentication required to use the platform.
- Reporting template: create a structure for collecting product details, the issue, known impact and actions taken.
- Decision log: record when the report was received, assessed, escalated and communicated.
- Remediation process: define how to prepare, validate and distribute a patch, and when users should be informed.
The aim is to reduce the time spent deciding who should act when a problem occurs. If you develop and sell software, this process can become part of your routine product maintenance and support planning. You can complement this review with our guide to planning your web stack support calendar.
What changes in December 2027?
The date to mark in your planning is 11 December 2027. According to ENISA, the main CRA requirements begin to apply on that date. Open-source software stewards also become subject to the reporting obligations from then, whereas manufacturers have been subject to them since 11 September 2026.
Do not confuse the date when the main requirements begin to apply with the start of the reporting obligations.
If you develop software for clients, distribute add-ons or maintain installable applications, review the documentation, maintenance processes and security measures you need for the requirements that apply to you. It is worth linking this planning to how you manage dependencies, updates and security reports. Our guide to ComfyUI security in a production studio can help put software security reviews into the context of a production environment.
What risks should you assess, and what should you not assume?
Non-compliance can carry significant financial penalties. Information published by ECIJA cites fines of up to 15 M€ or 2.5% of turnover. Article 64(10) of the regulation also establishes a specific exception for micro and small enterprises in relation to fines for missing the 24-hour early-warning deadline. This exception does not remove the other obligations or amount to a general exemption from the CRA.
Do not assume that the size of your business means you can ignore the process. Equally, do not assume that every fault must be reported in the same way. Identify the product type, your role, the nature of the problem and the applicable deadlines.
This article provides general information about technical and regulatory requirements, not legal advice. Confirm how the CRA applies to your circumstances with a specialist, particularly if you sell paid add-ons or distribute software under an open-source model.
What decision should you make this week?
This week, document the products you distribute, check whether they may fall within the CRA and appoint an owner for security reports. Then prepare EU Login access, a reporting template and an escalation procedure. This will help you address obligations that already apply and plan the remaining work for December 2027 without confusing the two timelines.
If you need to develop or adapt an application to support security, maintenance and reporting workflows, tell us what software you distribute and how you maintain it.
Sources
- ENISA: The CRA Single Reporting Platform is launched.
- Hogan Lovells: EU Cyber Resilience Act vulnerability and incident reporting obligations now apply.
- ECIJA: Cyber Resilience Act: obligations to report vulnerabilities and incidents from September 2026.
- Lexgo: EU Commission guidance on the Cyber Resilience Act: what businesses need to know.
- Springlex: Regulation (EU) 2024/2847, Article 64.
Checked on October 14, 2026