EU Cyber Resilience Act Reporting - What Devs Need to Know

As of September 11, 2026, part of the EU Cyber Resilience Act is already in effect.

Most of the CRA's requirements do not start applying until December 11, 2027. The reporting obligations in Article 14 started earlier. Manufacturers of covered 'products with digital elements' now have to report certain actively exploited vulnerabilities and severe security incidents through the EU's Single Reporting Platform. The European Commission says those reporting rules also cover in-scope products that were placed on the EU market before the wider CRA requirements take effect in 2027.

For a small software company, plugin developer, or web shop with products reaching EU customers, that creates a practical problem. If something goes wrong, you need to know whether the product is covered, whether the event is reportable, who is responsible for making the report, and when your reporting clock started.

Those are decisions you do not want to make for the first time during an active security incident.

The reporting clock

The CRA requires manufacturers to report two types of events.

1. An 'actively exploited vulnerability' is a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the system owner's permission. Finding a vulnerability during internal testing or receiving a responsible disclosure does not, on its own, make it an actively exploited vulnerability. The regulation specifically distinguishes good-faith security testing and research from malicious exploitation.
   
   
2. A severe incident affecting the security of a product with digital elements. Under Article 14, an incident is considered severe where it negatively affects, or could negatively affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. Or, where it has led (or could lead) to malicious code being introduced or executed in the product or a user's network or information system.

Once the manufacturer becomes aware of one of those events, deadlines are short:

The early warning is deliberately limited. The 72 hour submission adds information about the affected product, the nature of the exploit or incident, the initial assessment and measures already taken or available to users. The final report contains the fuller technical picture. For an actively exploited vulnerability, that includes its severity and impact, details of the fix and, where available, information about the malicious actor.

Manufacturers also have a separate obligation to inform impacted users and, where appropriate, all users about the vulnerability or incident and any measures they can take to reduce its impact.

One detail here that's easy to miss. The clock doesn't necessarily begin at the first suspicious log entry or the first unverified report. The European Commission's July 2026 guidance says a manufacturer is considered aware once an initial assessment gives it a "reasonable degree of certainty" that its' product contains a vulnerability that is being actively exploited, or that a severe incident has compromised the security of the product. That initial assessment should be carried out promptly.

That distinction gives a team time to establish what it is actually looking at. It does not provide an open ended investigation window while everyone waits for perfect forensic certainty.

Reports are submitted once through ENISA's Single Reporting Platform, which became operational on September 11, 2026. The platform handles distribution to the appropriate authorities rather than requiring a manufacturer to file separately with every EU country involved.

Are plugins, themes, apps and SaaS covered?

Well... This is where a simple summary of the CRA can become misleading. The regulation applies to products with digital elements that are made available on the EU market and whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical connection to a device or network. Its definition can include software products and software components that are supplied separately.

Software downloaded or installed on a user's system can fall within the definition, including mobile applications, browser extensions and applications made with web technologies but packaged to execute locally. A web application that runs remotely and is accessed only through a browser is not considered a product with digital elements on that basis alone. Ordinary websites receive similar treatment.

Remote processing can form part of an in scope product where it meets the CRA's definition of a remote data processing solution. Broadly, the remote software must be designed or developed by the manufacturer, or under its responsibility, and its absence would prevent the product with digital elements from performing one of its functions. A 3rd party SaaS service used by a product does not automatically become that manufacturer's remote data processing solution.

The regulation includes separately supplied software components, and the Commission says downloaded or installed software executing on the user's system can be a product with digital elements. A commercially distributed plugin, module or extension sold into the EU should therefore be treated as something that needs a CRA scope review rather than being dismissed as 'just a plugin'. The exact result will depend on how that software is distributed, how it operates and the role of the company providing it.

For shops like ours that build and distribute WordPress plugins, Joomla extensions and other software products, that distinction is worth reviewing product by product rather than assuming one answer covers everything.

A free download is not outside the CRA either. The regulation defines a manufacturer as someone who markets a product under its name or trademark "whether for payment, monetization or free of charge", while making a product available on the market is tied to supply in the course of a commercial activity.

Open source software has it's own rules!

Free and open source software that is not monetized by its manufacturer should not be treated as being supplied as part of a commercial activity. Developers who merely contribute code to an open source project that is not under their responsibility are also outside the CRA on that basis. A manufacturer that commercially places an open source product on the market can still have the normal manufacturer obligations.

The CRA also created a separate category called an "open source software steward" for legal entities that provide sustained support for specific open source projects intended for commercial activity and play a main role in keeping those projects viable. Their reporting obligations under Article 24(3) starts on December 11, 2027, instead of September 11, 2026.

There is another example that is useful for agencies and web development firms. A service provider that helps a customer install open source software on the customer's own server, without substantially modifying that software, is not considered to be placing that open source software on the market.

That is much closer to ordinary implementation work. A web shop that also develops and distributes its own commercial plugin, Joomla extension, desktop application or other software product has a different question to answer.

Being outside the EU does NOT automatically put you outside the CRA

For Canadian developers, geography alone is not enough to dismiss the regulation. The CRA is framed around products being made available on the Union market. It expressly defines an importer as an EU-established person that places on the market a product bearing the name or trademark of a person established outside the EU.

Article 14 also contains a reporting route specifically for manufacturers that do not have a main establishment in the EU. It uses an ordered set of criteria based on the manufacturer's authorized representative, importer, distributor and, if needed, where the largest number of users is located to determine the relevant national CSIRT.

For a Canadian software company selling or otherwise commercially supplying a covered product into the EU, "we are based in Canada" is not enough to resolve the scope question.

The penalties are large, with a narrow small business exception

Non-compliance with Article 14 falls within the CRA's highest administrative fine tier: up to €15 million or, for an undertaking, up to 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher. Article 64 of the CRA legal text sets those maximums. Member States establish and apply the penalty rules, and the regulation says factors such as the nature, gravity and duration of the infringement, previous similar fines, company size and market share are to be considered.

There is a specific break for smaller businesses, but it is narrower than it may first sound.

Manufacturers that qualify as microenterprises or small enterprises are exempt from administrative fines for failing to meet the 24 hour early warning deadline in Article 14. That exception does not remove the reporting obligation, and it is not a general exemption from the later Article 14 requirements. Open-source software stewards, separately, are exempt from administrative fines for CRA infringements.

What a small software dev team should put in place

For a small development team, CRA preparation does not have to begin with a giant compliance system. The immediate reporting problem is mostly about knowing your products and having a process that works when the clock starts.

Start with an inventory of software that you make available in the EU. Separate your own products from software you simply install, configure or support for clients. Flag downloaded applications, plugins, modules, browser extensions and other locally executed components for closer review. Keep hosted only applications and websites in a separate group so you can assess whether any of their remote functions form part of a covered product.

Do the same for older products. Article 14 reporting applies to in scope products placed on the market before December 11, 2027, and its guidance says the reporting obligation can continue after a product's support period has ended.

Then decide who owns a CRA incident internally. In a 5 person software company that might simply be the lead developer and one backup, but it should be written down. Somebody needs authority to decide when the initial assessment has reached the awareness threshold, preserve that timestamp, gather the first set of facts and submit the report through the SRP.

Add an "awareness" field to your security incident process. Record when the issue was first reported, what evidence was available, when someone assessed it, and when the team reached a reasonable degree of certainty that active exploitation or a severe incident was occurring. That record becomes much more useful when a 24 hour deadline is measured from awareness rather than from the day a CVE happened to be published.

It is also sensible to prepare three basic report templates around the 24 hour warning, the 72 hour notification and the final report. Do the same for the user communication Article 14 may require. You don't need to know every technical detail for the first submission - the reporting structure assumes that more information becomes available as the investigation progresses.

Component monitoring belongs in that process as well. The Commission's CRA guidance says that where an integrated component contains an actively exploited vulnerability that is exploitable in the manufacturer's own product, the manufacturer of that product has its own reporting obligation. If the vulnerability in the component cannot be exploited in that product, it is not an actively exploited vulnerability in that product for mandatory Article 14 reporting.

For teams maintaining WordPress, Joomla or other dependency heavy products, that means knowing what is inside each release and being able to work backwards quickly when a component advisory happens.

WordPress 7.1.2 is a useful example of the timing problem

WordPress provided a very current example only eleven days after the CRA reporting rules started.

On September 22, 2026, WordPress released version 7.1.2 to fix a critical vulnerability. Under certain server and theme conditions, an unauthenticated attacker could make WordPress include a chosen readable local PHP file outside the active theme directories, with the possibility of remote code execution when the required preconditions were present. The issue is tracked as CVE-2026-87902.

Patchstack reported seeing the first probing attempts at 11:49 UTC that same day, within hours of WordPress 7.1.2 being published. Its original 1st day analysis described that early activity as reconnaissance against harmless core files rather than confirmed payload delivery. The requests were testing whether sites were vulnerable.

The situation developed quickly. Patchstack later updated its report to say that the activity had moved beyond reconnaissance. It observed attempts to include pearcmd.php and write PHP files to disk, with its timeline recording the first file-write attempt at 15:34 UTC on September 22.

On September 23, the Canadian Centre for Cyber Security published an advisory stating that open source reporting indicated CVE-2026-87902 was being exploited in the wild.

There is no source showing that WordPress made a CRA filing, and this example shouldn't be read as a claim that it did. WordPress also raises its own open source classification questions under the CRA.

What the incident does show, however, is how little time a software team may have between a security fix becoming public and evidence of malicious activity appearing. Under Article 14, the first regulatory deadline can be only 24 hours after the manufacturer becomes aware that its own in scope product contains an actively exploited vulnerability.

For a small team, what's most useful is deciding product scope and reporting responsibility before that situation occurs. If your company distributes software into the EU and the classification is close, have qualified counsel confirm how the CRA applies to your particular products and distribution model.

We are providing this as a practical technical overview, not legal advice.