It is a Monday in late September and there are three security advisories in the inbox before lunch. One is for a form plugin, one is for a page builder, one is from the host. Each carries a version number, a severity, and some variation of the phrase actively exploited. None of them would have arrived as an email a month ago, and nothing about the website has changed.
What changed is that the people who write those emails stopped choosing when to send them.
Where this comes from. Everything below about the regulation comes from the European Commission's own pages on the Cyber Resilience Act: the reporting page, the legislative summary, and the Commission's page on open source. Where a practical consequence is our reading rather than the Commission's text, we say so in the sentence.
What Actually Starts on September 11
As of September 11, 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents to European authorities through the CRA Single Reporting Platform. The Commission states that the platform “will be operational by 11 September 2026,” and notes that functional and security testing are under way.
The obligation runs on three clocks rather than one, and the first is short enough to change behavior:
- Within 24 hours of becoming aware — An early warning notification.
- Within 72 hours — A full notification with the substance of the issue.
- No later than 14 days after a corrective measure is available — A final report for actively exploited vulnerabilities, and within a month for severe incidents.
One thing to keep straight. This is the first tranche of the regulation rather than the whole of it. The rest of the CRA, including its substantive security requirements for products, applies from December 11, 2027. September is the reporting clock switching on, nothing more.
Who Counts as a Manufacturer, and Why It Is Almost Certainly Your Vendor
The Commission's definition is broad, and the last clause is the one people miss. A manufacturer is “a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge.”
Free of charge is in the definition. Read that final phrase again. The clause reaches a product distributed for payment, for monetization, or free of charge. Being free is not the exemption most people assume it is. A company that gives away a product it markets under its own name is still a manufacturer.
Your commercial plugin vendors, your theme vendor and your host almost certainly sell into the European Union. That makes them manufacturers, and it means their disclosure timing stops being a communications decision and becomes a legal deadline with an authority on the other end of it.
What this does not do to you. Your association is not a manufacturer. You operate a website; you do not place products with digital elements on the European market. This regulation creates no obligation for you, and any vendor or consultant who tells you otherwise is selling something. That reading is ours rather than a Commission statement about associations specifically, but the definition is not ambiguous.
Where Free Plugins Actually Land
This is the part most coverage will get wrong, because it looks like a two-way split and is actually a three-way one.
Unmonetised open source is outside the regime. The Commission states that “free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity,” and separately excludes developers who contribute source code to projects that are not under their responsibility. An unpaid plugin author publishing to the WordPress.org repository picks up no new obligation on September 11.
Stewards sit in the middle. The CRA creates a category for legal persons who sustain open-source projects that are intended for commercial activity: “a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products.” Stewards get what the Commission calls a “light-touch and tailor-made regulatory regime”: a cybersecurity policy, cooperation with market surveillance authorities, and reporting of actively exploited vulnerabilities and severe incidents. Critically, “open-source software stewards are not subject to penalties for infringements of the CRA.”
Commercial manufacturers sit at the far end. They carry the full obligation and the enforcement behind it. The Commission does note one softening even here: manufacturers that qualify as small enterprises may not be fined for missing the 24-hour reporting deadline specifically.
What This Does to the Advisories You Receive
The practical effect, and this is our inference rather than anything the Commission says about websites, is that the advisory flow into your organization becomes uneven in a way it has not been before.
The commercial half of your stack gets faster, blunter and more frequent disclosure, because a vendor writing to a 24-hour clock does not have time to prepare a narrative first. Expect advisories that arrive before the marketing framing, occasionally before a patch, and in larger volume. For anyone actually defending a site that is an improvement, even though it will not feel like one in the inbox.
The free half of your stack does not change at all. Nobody is obliged to tell you anything faster than they already do.
The wrong conclusion to draw, stated plainly. A quiet plugin is not a safe plugin. It is an unreported one. Nothing about anybody's code changes on September 11 — the only thing that changes is who is legally required to speak up, and how quickly. Reading the resulting asymmetry as a quality signal is the single most likely mistake to come out of this, and it points in exactly the wrong direction.
What Is Worth Doing Before September 11
None of this is compliance work, because none of it is your compliance. It is preparation for a change in the volume and tone of what lands in an inbox.
- Know which of your plugins are commercial and which came from the repository. This is the same list that answers the commercial license question, so it is worth building once and keeping.
- Decide who reads them. A faster advisory flow only helps if somebody is on the receiving end of it. If the honest answer is nobody, the change on September 11 makes that gap wider rather than narrower.
- Separate “there is an advisory” from “we patch today.” The two questions that matter are whether the issue is actually being exploited and whether you are on an affected version. Most advisories fail one of those tests, and a vendor writing to a legal deadline is not making that judgment for you.
- Make sure the mail actually arrives somewhere useful. Volume is going up. If a real advisory has to compete with forty pieces of vendor mail to be noticed, it will lose.
Who Reads the Advisories at Your Organization?
That is not a rhetorical question, and it is the only one worth settling before September 11. Tell us who currently receives vendor security mail at your organization and what happens to it after it arrives. What comes back is a single page: which of your vendors sit inside the reporting regime and which sit outside it, where each one publishes its advisories, and a decision line your staff can apply on a Tuesday morning without calling anyone. Patch today, hold for the maintenance window, or ignore. If somebody there is already doing this well, we will say so, and you can go back to ignoring our emails.