Cyber Resilience Act Article 14 reporting duties begin

Cyber Resilience Act Article 14 reporting duties begin

The EU Cyber Resilience Act's Article 14 reporting duties now apply to software makers and open source maintainers, with 24-hour and 72-hour deadlines.

Cyber Resilience Act Article 14 reporting duties took effect on 11 September 2026, and they reach further than many software makers assume. Article 14 is the first part of the European Cyber Resilience Act, the European Union law on the security of products with digital elements, to become binding. Patchstack, which says it has coordinated more than half of all known vulnerabilities in the WordPress ecosystem and describes itself as one of the most active numbering authorities in the world, published an explanation of the new rules together with the launch of a service to handle them. According to that explanation, the obligations mostly affect companies that make products with digital elements available on the European market, but they also apply to open source software maintainers, whom the law treats as open source stewards. One detail matters for anyone who assumed the clock starts only with new releases: Article 14 covers all products and software, including anything made available on the European market before 11 September 2026.

Two kinds of events have to be reported from that date. The first is a vulnerability that attackers are actively exploiting, meaning a software weakness that is already being used in real attacks rather than one that could merely be used one day. The second is a severe security incident affecting a product. Reports are filed with national cybersecurity authorities and with ENISA, the European Union Agency for Cybersecurity, through a single EU platform. The deadlines are strict: an early warning within 24 hours, a fuller notification within 72 hours, and a detailed final report later. On top of the reports themselves, manufacturers must also tell affected users what happened and how they can protect themselves.

Who exactly carries the duty depends on how the software is funded, and Patchstack uses a WordPress plugin to show how the line is drawn. If the plugin's code is open source under the GPL licence, the widely used licence that lets anyone read and reuse the code, but the plugin also has a premium version or another way of generating revenue for its maintainer, then the seller counts as a manufacturer rather than as an open source steward. A completely free and open source plugin with no commercial intent at all, even if it is maintained by employees of a legal entity, is treated as an open source steward. Article 14 obligations apply in both cases. The difference is that an open source steward cannot be fined, while the European Union can still use other means to get a non-compliant product removed from the European market. Patchstack stresses that this applies across every open source ecosystem and is not specific to WordPress, which it uses as an example because open source there does not mean free: all WordPress plugins are open source and GPL licensed, yet most of the popular ones are commercial products.

Each report is made up of three forms, and each form has its own deadline. The first is an early warning, which must be submitted without undue delay and in any case within 24 hours of the moment the company becomes aware of an actively exploited vulnerability or a severe incident. The second is the notification of that actively exploited vulnerability or severe incident, due without undue delay and in any case within 72 hours, and it has to contain general information plus an initial assessment. The third is the final report. For an actively exploited vulnerability it is due no later than 14 days after a corrective measure, such as a patch (a software update that fixes the flaw), becomes available. For a severe incident it is due within one month after the 72-hour notification.

All of these reports must go through the EU Single Reporting Platform, or SRP. Patchstack's advice is that maintainers create their accounts straight away, because EU Login accounts are personal and multi-factor authentication, a second proof of identity such as a code sent to a phone, is required before the platform can be reached. The SRP has no API, meaning there is no automated way for another system to submit a report on your behalf, and the platform requires three different forms to be completed by hand for every single report. With a hard 24-hour deadline in play, Patchstack says creating the EU accounts immediately makes it far easier to meet that deadline when something actually happens.

Patchstack used the same date to announce a platform for open source maintainers that it says covers Article 14 compliance end to end, free to access at the outset. The company warns that it may introduce a fee in the future, charged per report, if the volume of reports becomes too high and the Single Reporting Platform still has no API. According to Patchstack, the platform does three things: it tracks the active exploitation of individual vulnerabilities, collects evidence and alerts the maintainer once the Article 14 requirements are triggered; it can act as the official Assigned Representative for the maintainer, filing the reports and keeping each form inside its deadline; and it provides a single channel for a managed vulnerability disclosure programme (mVDP) along with a bug bounty programme, for one product or several. Patchstack says the mVDP platform was built for this purpose in collaboration with the European Union (EIC), and that the company is GDPR compliant, certified to ISO 27001 and SOC 2 Type 2, and based in the EU. It also says more than 1,000 open source products and projects already use its mVDP for vulnerability coordination, and it credits partnerships with large web hosting companies and its RapidMitigate technology for what it describes as the fastest and most detailed detection of known exploited vulnerabilities (KEVs) on the market.

For website owners, the practical reading is straightforward. The people filing these reports are the vendors, not the customers, so a site owner will not be filling in EU forms after a plugin is attacked. What changes is the pressure on those vendors: an actively exploited flaw in a commercial plugin now puts its maker on a legal clock to warn users and explain how to protect themselves, and failing to do so carries consequences. Since most popular plugins are commercial, that duty sits with the companies behind them, while free and non-commercial projects must still report but cannot be fined. Either way, the fastest protection for a site remains the same, which is installing security updates and removing software nobody maintains. For teams that would rather not track patch windows themselves, AEU Hosting is our managed WordPress hosting service, built around keeping WordPress sites updated and secured end to end, which is exactly the kind of groundwork this story rewards.

One point worth repeating, because it is easy to miss: the obligations are not limited to software released after the deadline. Products and software already on the European market before 11 September 2026 are covered too, so

How to Protect Yourself

  1. Update your WordPress plugins, themes and core software as soon as a new version appears, because that is how fixes for flaws that are already being attacked reach you.
  2. Turn on automatic updates in WordPress if you have not already, so security fixes install themselves without you having to remember.
  3. Add a second login step, such as a code sent to your phone, and a strong, unique password to every administrator account on your site.
  4. Take a backup of your site regularly and store a copy somewhere separate, so you can restore a clean version if anything goes wrong.
  5. Find out who makes the plugins you rely on and follow their security announcements, so you hear about a serious flaw from them rather than from an attacker.
  6. If a hosting company or agency looks after your site, ask them plainly who applies security updates and how quickly they do it.

Terms Explained

  • Cyber Resilience Act A European Union law that sets security requirements for products with digital elements sold in the EU.
  • open source steward The role the law gives to maintainers of genuinely non-commercial open source software, who must report security problems but cannot be fined.
  • manufacturer Under this law, a company that sells a product or earns money from it, for example the seller of a paid version of a plugin.
  • ENISA The European Union Agency for Cybersecurity, one of the bodies that receives these security reports.
  • Single Reporting Platform The single European Union website where companies must file their reports about exploited flaws and severe incidents.
  • multi-factor authentication A login step where you prove who you are a second way, such as entering a code sent to your phone.
  • patch A software update that fixes a security flaw in a program.
  • actively exploited vulnerability A software weakness that attackers are already using in real attacks, rather than one that could only be used in theory.

Related AEU services