Does the EU Cyber Resilience Act apply to your WordPress plugin?

Start with the product and your role. A WordPress plugin's price and your business's legal form are not enough to decide which Cyber Resilience Act obligations apply.

Correction, September 29, 2026: The earlier version incorrectly said Commission open-source guidance had not been published and presented an oversimplified role matrix. This update removes that matrix and distinguishes the reporting dates for manufacturers and open-source software stewards.

Use the current Commission guidance

The Commission's open-source overview links to published CRA guidance, including a section on free and open-source software. Read that guidance alongside the regulation when assessing a product. Older community notes marked as awaiting guidance are not a substitute for the current official position.

The overview distinguishes software supplied in commercial activity from open-source software that its manufacturer does not monetize. It also describes the separate steward role for legal persons providing sustained support and ensuring the viability of certain open-source products intended for commercial activities.

That distinction does not support a rule that every free company plugin is automatically a steward product, or that every free sole-trader plugin is automatically outside scope. Establish the facts for the particular product and activity before assigning a role.

Match the reporting date to the role

The Commission's reporting overview states that manufacturer reporting obligations started on September 11, 2026. It gives December 11, 2027 for open-source software stewards' reporting obligations under Article 24(3).

Do not apply one of those dates to a business until its relevant role is established. The reporting timetable is also not a complete summary of every CRA requirement or transitional provision.

Prepare the evidence for a useful assessment

I would start with an inventory: each product, its distribution model, who develops and maintains it, and the activities through which it earns revenue. Keep the facts separate from the legal classification you want checked.

Then document the actual release and vulnerability-handling process. Who receives a report? Who investigates it? What evidence is retained? Who decides that a fix is ready? A security email address or SECURITY.md file can help people find that process, but it does not demonstrate compliance on its own.

Keep a record of what ships in each release and how updates reach users. Ask a qualified adviser to assess material classification questions against the current regulation and guidance. This article does not classify an individual business or certify a plugin as compliant.

Disclosure. MaxtDesign builds and sells WordPress plugins, and we have been looking at whether there is a business in package provenance and verification. So we have a stake in the argument above. We are not building a competing package manager. If we ever run a verification service, our own plugins are permanently out of scope for it, and that exclusion gets stated publicly rather than promised quietly.