CRA compliance for WordPress plugins

The Cyber Resilience Act (Regulation (EU) 2024/2847) applies to products with digital elements: software or hardware products and their remote data processing solutions, including components placed on the market separately (Art. 3(1)). A plugin is software intended for integration into another system (Art. 3(6)); supplied separately from WordPress, it is a product in its own right. Software that never opens a socket still counts as indirectly connected through the platform it runs on (Art. 2(1); FAQ 1.3).

What decides most cases is commercial activity. Making available on the market means supply in the course of a commercial activity, whether for payment or free of charge (Art. 3(22)). A free plugin in the wordpress.org directory that sits beside a paid Pro edition, paid support or a hosted service tied to it is monetised, and monetised software is supplied commercially (Recital 18; FAQ 4.5.2). A licence check or update endpoint of yours without which one of the plugin’s functions cannot work is remote data processing and is assessed with the plugin (Art. 3(2)).

Two situations fall outside. Open-source software that is not monetised by its manufacturer is not a commercial activity; donations, sponsorship and hosting on a package directory do not change that (Recitals 18 and 20). A plugin built only for your own sites is never placed on the market (FAQ 1.5). An organisation that supports a plugin’s development without marketing it may be an open-source software steward under the lighter Article 24 regime (Art. 3(14); Recital 19).

Most plugins are default products and self-assess under module A (Art. 32(1)). A plugin is important only when its core functionality matches an Annex III category as described in Implementing Regulation (EU) 2025/2392: malware scanning, single sign-on or multi-factor authentication, a password manager (class I, points 4, 1 and 3) or a web application firewall (class II, point 2). Bundling an important component does not make the host important (FAQ 3.2).

Reporting is already live. Since 11 September 2026, every manufacturer of an in-scope product, including products already on the market, must notify actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform (Art. 14; Art. 69(3); Art. 71(2)): early warning within 24 hours of becoming aware, notification within 72 hours, final report within 14 days of a corrective measure or one month for an incident (Art. 14(2), (4)), all to the CSIRT coordinator of your main establishment (Art. 14(7)); impacted users must be informed (Art. 14(8)).

From 11 December 2027 the rest of the Regulation applies to products placed on the market from then: Annex I essential requirements, Annex VII technical documentation, Annex V declaration of conformity, CE marking and Annex II user information (Art. 71(2)). Earlier products stay under Article 14 alone unless substantially modified (Art. 69(2)–(3); Art. 3(30)); placing on the market is counted per unit and per version (FAQ 7.2).

No harmonised standard has been cited in the Official Journal yet, so there is no presumption of conformity to rely on (Art. 27). Unfinished versions may be distributed for testing for a limited time if they carry a visible non-compliance notice (Art. 4(3); FAQ 1.6).

1. 1. Decide scope per plugin and per edition

   Assess the free and the Pro edition separately, note whether a service of yours is remote data processing, and record the reasoning. Then determine the class from the plugin’s core functionality, not its feature list.

2. 2. Publish a vulnerability contact and a disclosure policy

   Provide a contact address for vulnerability reports and a coordinated disclosure policy (Art. 13(17); Annex I, Part II, points (5) and (6)), in a security.txt file and in the readme, answered by a person: the point of contact must allow direct, rapid communication.

3. 3. Prepare Article 14 reporting today

   Write down who decides that you are aware, who has access to the Single Reporting Platform, which CSIRT coordinates for you and what the first 24 hours look like. Rehearse it once.

4. 4. Keep a software bill of materials per release

   Produce a machine-readable SBOM covering at least the top-level dependencies (Annex I, Part II, point (1)), including bundled JavaScript and Composer packages, watch it against vulnerability feeds, and report a component vulnerability to its maintainer as well as fixing it (Art. 13(6)).

5. 5. Set a support period and an update routine

   Choose a support period of at least five years (Art. 13(8)), state its end date at purchase (Art. 13(19)), ship security updates without delay and free of charge, separately from feature releases where feasible (Annex I, Part II, points (2) and (8)), keep each one available for ten years (Art. 13(9)), and start the Annex VII technical file and risk assessment (Art. 13(2)–(3); Art. 31) so the declaration of conformity and CE marking can follow (Art. 28; Art. 30).

Permenta gives each plugin edition its own entry in the product registry, records the scope answer with its reasoning, generates the security.txt file and the disclosure policy, and runs the Article 14 desk with the clocks against ENISA’s field list. SBOMs from your build are matched against vulnerability feeds daily, and every release, advisory and filing lands on a hash-chained ledger you can show a customer or an authority years later.

• Art. 2(1)
• Art. 3(1), (2), (6), (14), (22), (30)
• Art. 4(3)
• Art. 13(2), (3), (6), (8), (9), (17), (19)
• Art. 14
• Art. 24
• Art. 27
• Art. 28
• Art. 30
• Art. 31
• Art. 32
• Art. 69(2), (3)
• Art. 71(2)
• Annex I, Parts I and II
• Annex II
• Annex V
• Annex VII
• Implementing Regulation (EU) 2025/2392
• Commission FAQ v1.4: 1.3, 1.5, 1.6, 3.2, 4.5.2, 7.2
• Recitals 18, 19, 20