The CRA reporting obligations start today: what a plugin vendor does now
Almost every article about the Cyber Resilience Act says there is a reporting duty. Hardly any of them says how a one-person vendor actually meets it on a Monday morning.
Today is 11 September 2026, which means Article 14 of the Cyber Resilience Act applies. Its official heading is reporting obligations of manufacturers. That it applies from this exact date is set out in Article 71 of Regulation (EU) 2024/2847.
Plenty has been written about the CRA, and most of it sits at the same altitude: there is a duty to report, there are deadlines, start preparing. What those articles leave out is the part that matters when an email actually arrives describing an exploited flaw in your plugin. Which body, which deadline counting from which moment, and what you write down over the next few hours.
That is what follows. It is an assessment based on research as of 21 August 2026, and it is not legal advice. Where a detail was uncertain, the text says so.
Who this actually covers
Two definitions carry the whole thing. A product with digital elements is defined in Article 3(1) as a software or hardware product and its remote data processing solutions, explicitly including components placed on the market separately. A plugin distributed on its own falls within that wording. A manufacturer, under Article 3(13), is anyone who develops such products or has them developed and markets them under their own name or trademark, whether for payment, monetisation or free of charge. That last clause surprises people: a free plugin published under your name in the directory makes you a manufacturer under the wording.
One honest caveat. That reading follows well from the primary definitions, but there is still no statement from a national authority or from the Commission that names WordPress plugins explicitly.
Three dates, and only one of them is today
The CRA arrives in stages, which is the most common mix-up in conversations about it. Article 71 names three dates:
- 11 June 2026: Chapter IV applies, covering notified bodies. For a plugin vendor without a conformity assessment, nothing changes here.
- 11 September 2026: Article 14 applies, the reporting obligations. That is today.
- 11 December 2027: the rest of the regulation applies. That includes CE marking, technical documentation, conformity assessment and the software bill of materials from Annex I Part II.
So what begins today is the duty to report when something happens. What begins in 2027 is the duty to demonstrate, on an ongoing basis, how you build. Buying SBOM tooling today is buying for the year after next.
Two reporting tracks with separate clocks
The 24 hours, 72 hours, 14 days formula appears in almost every overview. It describes exactly one of the two cases Article 14 covers. The second case shares the first two stages and ends on a different deadline.
Track 1: actively exploited vulnerability
| Stage | Deadline | Clock starts at | Source |
|---|---|---|---|
| Early warning | without undue delay, in any event within 24 hours | the manufacturer becoming aware | Art. 14(2)(a) |
| Vulnerability notification | within 72 hours | becoming aware of the actively exploited vulnerability | Art. 14(2)(b) |
| Final report | no later than 14 days | a corrective or mitigating measure being available | Art. 14(2)(c) |
Track 2: severe security incident
| Stage | Deadline | Clock starts at | Source |
|---|---|---|---|
| Early warning | within 24 hours | the manufacturer becoming aware | Art. 14(4)(a) |
| Incident notification | within 72 hours | becoming aware of the incident | Art. 14(4)(b) |
| Final report | within one month | submission of the incident notification | Art. 14(4)(c) |
Two things stand out that the shorthand hides. First, the final report for an incident is due after one month, not after 14 days. Germany's BSI states this one-month deadline on its own pages. Second, the clocks start in different places: the 24 and 72 hours run from the moment you become aware, the 14 days run from the moment a fix is available, and the month runs from the moment you filed the 72-hour notification.
In practice the final report in the vulnerability track can fall due weeks after the early warning, and its calendar entry only exists once the fix does.
What triggers the duty, and what does not
An actively exploited vulnerability requires credible indications that an attacker is in fact exploiting it. A severe security incident is an event that negatively affects, or can affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of data.
An ordinary bug does not trigger a report, and neither does a routine update. A flaw a researcher discloses to you that nobody is exploiting belongs in your normal fix process. Sit on credible evidence of exploitation for three days, though, and you have missed the first deadline. Telling those two situations apart is the first question you answer in an emergency.
The second duty people keep missing
Article 14(8) requires the manufacturer to inform the users of the product about the vulnerability or the incident and, where relevant, about corrective or mitigating measures the users can take, in a machine-readable format where necessary.
This is a duty in its own right, separate from the filing to the authorities, and for a plugin vendor it is the most visible part of the whole regulation, because every customer sees it. It is also the part most likely to fail without preparation: if you distribute your plugin for free through wordpress.org, you do not know your users. You have the update channel, the release notes and the readme, and whether that is enough is a question better answered before an incident than during one.
Where the report goes, and why that is still awkward
Reports go simultaneously to the coordinating CSIRT and to ENISA, through the single reporting platform under Article 16. The receiving CSIRT forwards the report to the CSIRTs of the other member states where your product is made available.
That is the regulation. Reality on 21 August 2026 looked like this:
- The platform was not publicly reachable. ENISA phrased it in the future tense: as of 11 September 2026 onwards, the platform will be used by CSIRTs and manufacturers for mandatory reporting.
- There was no public registration link. The production address of the platform had not been published.
- ENISA had published user guides for registration and for filing, last updated in July and August 2026, and named a helpdesk address: cra-srp-helpdesk@enisa.europa.eu.
- According to those guides, sign-in runs through EU Login. On first access you provide your role, the responsible CSIRT, a legal agreement and manufacturer details.
An ENISA update of 3 August 2026 takes some pressure off. Validation of your account by the coordinating CSIRT is not a precondition for having met the reporting duty; it runs in parallel, so an account that has not been cleared yet does not by itself put you in breach. Cross-border forwarding to other CSIRTs is done manually. And ENISA advises creating the EU Login account in advance while leaving the platform registration until you have a report to file. Those points come from a secondary source; the ENISA guidance documents themselves were not freely retrievable.
The national piece, using Germany as the worked example
You report to the CSIRT of the member state where your main establishment is. For Germany that is the BSI with CERT-Bund, which confirms the deadline structure on its own pages, including the one-month final report for severe incidents, and points to ENISA for the platform.
The German implementing act was not yet in force on 21 August 2026. The bill sits as Bundestag document 21/6134 of 26 May 2026, first reading on 11 June 2026, then referred to the interior committee, with no objections from the Bundesrat. It creates no new obligations; it assigns responsibilities, making the BSI the national market surveillance authority and notifying authority, and the CSIRT that receives reports from 11 September 2026. No procedural update after June 2026 was found at the time of research.
The contrast with the AI Act is instructive. There, the German implementing act has been in force since 29 July 2026. For the CRA it is still working its way through parliament while the regulation applies directly from today. A regulation does not wait for its national companion law, which is worth remembering wherever in the Union you are established.
What a missed report costs
Article 64(2) sets out fines for infringements of the essential requirements in Annex I and of the obligations in Articles 13 and 14: up to 15,000,000 euros or, for undertakings, up to 2.5 percent of total worldwide annual turnover for the preceding financial year, whichever is higher. That last clause is frequently dropped, which reverses the meaning. It is not an option to pick the smaller number.
For context: Article 64(3) provides up to 10,000,000 euros or 2 percent for other obligations, and Article 64(4) up to 5,000,000 euros or 1 percent for supplying incorrect, incomplete or misleading information to notified bodies and market surveillance authorities.
Then there is Article 64(10), which hardly anybody quotes. Fines do not apply to manufacturers that are microenterprises or small enterprises insofar as the failure concerns the deadline in Article 14(2)(a) or Article 14(4)(a). Those are the two 24-hour early warnings. Open-source software stewards are likewise exempt from fines under that provision.
The exemption is narrow, and it is routinely read too broadly. It covers the deadline for the early warning. It does not release you from the reporting duty itself, it does not cover the 72-hour notification, and it does not cover the final report. A small vendor who simply never reports sits in the same fine range as a large one.
The first 24 hours, in practice
What follows is a working routine, not a reproduction of statutory form requirements. The regulation names deadlines and recipients; which fields the platform's form actually asks for was not publicly visible on 21 August 2026. What is listed here is the material you need to assemble for a report either way.
Hour zero. The report arrives, by email to your security address, through the support forum, or via a disclosure platform. Record the date and time to the minute. That is when the clock starts, and it is the one detail you cannot reconstruct later.
First hour. One person decides which track. Are there indications of actual exploitation, such as log entries, compromised installations, a public exploit? Then track one. Has something happened that undermines the product's protective function, such as a tampered update or a break-in on your build infrastructure? Then track two. Both at once is possible, and when in doubt the stricter track applies. The decision goes down in writing.
By hour four. Establish scope: which product, which versions, since when, which configuration is affected at all, and whether there is a mitigation users can apply without updating. Keep in touch with the reporter in parallel so they do not publish while you work.
By hour 24. File the early warning. It is called an early warning for a reason, and it is allowed to contain open questions.
What you need for the early warning
- Product name, affected versions, manufacturer details.
- Time and source of your awareness.
- A short description of what happened and what leads you to conclude exploitation.
- A first assessment of impact and of how widely the affected versions are deployed.
- The member states where the product is available. For a plugin in the open directory that is the whole Union.
- What is already under way, and when you expect a fix.
What belongs in your own log
The log is the least glamorous and most useful half of the work. It is what later answers the question of whether you met the deadlines. A text file in the repository is enough, as long as somebody keeps it.
- Time and source of awareness.
- The decision on which track, with a two-sentence reason.
- Timestamps for the early warning, the 72-hour notification and the final report, each with the recipient.
- The moment a fix became available. That is what you count the 14 days from in the vulnerability track.
- The customer notice exactly as it went out, and when.
- Affected versions and the version that carries the fix.
What the customer notice looks like
Short, factual, no reassurance padding. Name the affected versions, say what a user should do now, say from which version the problem is fixed. If there is an interim mitigation, it goes at the top. For a WordPress plugin the place for this is the readme with its changelog entry plus the update itself, along with your security page and, if you have a customer list, an email. The machine-readable part of Article 14(8) is, for a plugin, effectively the version information in the update channel.
What has to be in place beforehand
- A published security contact, ideally a dedicated mailbox rather than the support forum.
- A
/.well-known/security.txtper RFC 9116, so reporters find the route without guessing. - A coordinated disclosure policy: what you commit to, what you ask for, what the scope is.
- A way to reach every affected user. For free directory plugins that is the update channel and the readme; for paid products it is the customer list.
- A fixed place for the log, created before you need it.
None of this takes a weekend. All of it takes too long in the middle of an incident.
Where we stand ourselves
Because a guide that only makes demands is worth little: we run a security page with a published security contact, committed response times, a defined scope and our coordinated disclosure policy, alongside a /.well-known/security.txt per RFC 9116 pointing back to that page. For the self-declaration behind it there is a free tool: the CRA self-declaration generator turns your own details into a security.txt, a readme section for wordpress.org and public security information for your website. It runs in your browser, collects no email address and stores nothing.
What is not yet in place here belongs in the same paragraph. For our free plugins in the WordPress directory, Wellenbrecher among them, we do not know the installations; our route to those users is the update channel and the readme, and nothing else. Registration on the reporting platform is not possible yet, so only the EU Login account can be prepared. And our incident log lives internally. It is not a public page.
Our reporting route is public
The security page carries the security address, the coordinated disclosure policy, the scope and the response times we commit to. It is also the target of the policy line in our security.txt.
Frequently asked questions
Does the CRA apply to a free plugin?
Under the wording of Article 3(13), a manufacturer is anyone who markets a product with digital elements under their own name or trademark, whether for payment, monetisation or free of charge. A free plugin in the directory fits that description. Free and open-source software that is not commercialised falls outside the scope in principle, according to the Commission guidance published at the end of July 2026. The real assessment lies between those two cases, and it is a legal question.
Do I have to report every security bug?
No. What must be reported is an actively exploited vulnerability, meaning there are credible indications of actual exploitation, and a severe security incident that affects or can affect the product's protective function. An ordinary bug and a routine update do not trigger a report. A disclosed flaw with no sign of exploitation belongs in your normal fix process.
Is the final report due after 14 days or after one month?
Both, depending on the track. For an actively exploited vulnerability the final report is due no later than 14 days after a corrective or mitigating measure is available, Article 14(2)(c). For a severe security incident it is due within one month of submitting the incident notification, Article 14(4)(c). The popular shorthand mentions only the 14 days.
Where do I register for the reporting platform?
On 21 August 2026 there was no public link for that. ENISA's single reporting platform was not publicly reachable and its production address had not been published. What could be cited was the ENISA topic page and the helpdesk address cra-srp-helpdesk@enisa.europa.eu. ENISA advises creating the EU Login account in advance and leaving the platform registration itself until you have a report to file.
Can a small vendor really be fined?
The range in Article 64(2) applies in principle to everyone: up to 15,000,000 euros or, for undertakings, up to 2.5 percent of worldwide annual turnover, whichever is higher. Article 64(10) exempts microenterprises and small enterprises from fines insofar as the failure concerns the 24-hour early warning deadline, and exempts open-source software stewards as well. That exemption covers this deadline. The reporting duty itself, the 72-hour notification and the final report are untouched by it.
