Starting on 11 September 2026, the first obligations under the European Cyber Resilience Act will kick in – more specifically, Article 14. This mostly affects companies that make products with digital elements available on the European market, but it also applies to open-source software maintainers who, under the law, will be considered open-source stewards.
Most open source maintainers have already been dealing with a significant increase of vulnerability reports and coordination. We know this first hand, as we’ve coordinated more than 50% of all known vulnerabilities in the WordPress ecosystem and being one of the most active CNA’s all-time.
Before sharing what we just launched, and how it helps open source maintainers save significant amount of time – let’s go over the CRA Article 14 obligations that open source stewards and manufacturers need to keep in mind to stay compliant with the EU law.
Important! Article 14 applies to all products and software – even if they were made available on the European market before 11 September 2026.
Obligation to report active exploits and severe incidents to the European platform
Starting 11 September 2026, the EU Cyber Resilience Act requires manufacturers of software and connected products to report two things: vulnerabilities that attackers are actively exploiting and severe security incidents affecting their products. Reports go to national cybersecurity authorities and the EU cybersecurity agency ENISA through a single EU platform, and the deadlines are tight: an early warning within 24 hours, a fuller notification within 72 hours, and a detailed final report later. Manufacturers must also tell affected users what happened and how to protect themselves.
Who is obligated?
Let’s start with an example: a WordPress plugin. Its code is GPL-licensed and open source. However, it has a premium version or another way to generate revenue or financial gain for the maintainer. This makes the seller of the plugin a manufacturer, not an open-source steward. A completely FOSS WordPress plugin that has no commercial intent at all, but is maintained by employees of a legal entity, would be considered to be an open-source steward. Article 14 obligations apply to both. The difference is that open-source stewards can’t be fined. However, the EU can still use other means necessary to remove a non-compliant product from the European market.
This applies across all open-source software ecosystems and is by no means exclusive to WordPress. WordPress is just a good example because, in this ecosystem, open source does not mean free. While all WordPress plugins are open source and have a GPL license, the majority of the popular ones are products with commercial intent.
What and when needs to be reported?
There are two separate cases that need to be reported: vulnerabilities that attackers are actively exploiting and severe security incidents affecting the products. The EU sets very strict reporting deadlines. Each report consists of three forms with individual deadlines.
Early warning (24 hours):
Submit an early warning without undue delay and in any case within 24 hours of becoming aware of the actively exploited vulnerability or severe incident.
Actively Exploited Vulnerability/Severe Incident Notification (72 hours):
Submit the notification without undue delay and in any case within 72 hours of becoming aware, providing general information and an initial assessment.
Final report (14 days / 1 month):
- For actively exploited vulnerabilities: no later than 14 days after a corrective measure (e.g., a patch) becomes available.
- For severe incidents: within one month after the 72-hour notification.
How to report?
All of the above-mentioned reports must go to the EU Single Reporting Platform (SRP). Maintainers first need to create a personal EU Login account. EU Login accounts are personal, and multi-factor authentication (MFA) is required to access the SRP.
The SRP does not have an API, and the platform requires 3 different forms to be completed manually per report. Taking the hard 24-hour deadline into account, it’s best to create the EU accounts immediately. This will make it easier to meet the deadline once an actively exploited vulnerability or severe incident needs to be reported.
Managed Article 14 reporting via Patchstack as an AR (Assigned Representative)
Starting from today, Patchstack provides a free-to-access* platform for open source maintainers to cover entire CRA Article 14 compliance.
Including:
a) Patchstack tracks the active exploitation of individual vulnerabilities, collects evidence, and notifies the maintainer once Article 14 requirements kick in;
b) Patchstack can act as the official Assigned Representative (AR) for the maintainer, fulfilling the Article 14 requirements and ensuring that the deadlines for each reporting form are met; and
c) Patchstack provides a single-channel mVDP and a bug bounty program for one or multiple software / products.
The Patchstack mVDP platform has been built for this purpose in collaboration with the European Union (EIC). Patchstack is a GDPR-compliant, ISO 27001- and SOC 2 Type 2-certified EU-based company.
Over 1000 open source products and projects already use the Patchstack mVDP for vulnerability coordination. Due to our partnerships with the leading web hosting companies in the world and the accuracy and scale of Patchstack RapidMitigate – we are uniquely positioned to provide the fastest and most detailed known exploited vulnerabilities (KEVs) detection on the market.
As open source maintainer, you can create your free account here: https://patchstack.com/cra-article14-for-open-source-maintainers/
*We may introduce a fee in the future to cover Article 14 reporting on a per-report basis if the volume becomes too high and the Single Reporting Platform does not introduce an API.
