CRA Guide · for WordPress plugin developers
The EU Cyber Resilience Act, article by article
Regulation (EU) 2024/2847 — what each article means for someone shipping a commercial WordPress plugin into the EU market. Written without legalese. Updated as ENISA publishes harmonised standards.
On this page
Who's in scope
The CRA applies to anyone who places a “product with digital elements” on the EU market. Commercial WordPress plugins qualify. So do themes that ship custom post types, shortcodes, or API integrations. Free plugins are exempt only if there’s no commercial activity attached — no paid upgrade, no donations tied to development, no advertising revenue, no bundled sale. Most freemium plugins are in scope through the paid edition.
Geography is about the market, not the developer. If an EU customer can buy your plugin, the CRA applies whether you’re in Sydney, San Francisco, or São Paulo.
Key dates
10 December 2024 — CRA entered into force. Transition period began.
11 September 2026 — Vulnerability disclosure and incident reporting (Articles 13–14) apply.
11 December 2027 — Full CRA application. All requirements in effect.
The September 2026 date is the one most plugin developers should plan around. From that date on, you can be asked to produce the technical file on 48 hours’ notice and you must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware.
Article 13 — Vulnerability disclosure
You have to maintain a documented vulnerability handling process and publish a coordinated vulnerability disclosure policy. The policy needs a reachable channel for researchers to report issues — typically a dedicated email or a security.txt entry at a known location — plus a stated response SLA, scope (which products and versions are covered), safe-harbor terms for good-faith reporters, and ideally a PGP key for encrypted submissions.
The reference standard is ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling). You don’t have to implement those standards literally, but ENISA-derived audits will look at them.
For a WordPress plugin specifically: a published page at /security/ or similar URL with the policy content, plus a /.well-known/security.txt file pointing researchers to it. MMCRA Toolkit drafts the policy and publishes it as a WordPress page or exports it as standalone HTML.
Article 14 — Vulnerability handling and reporting
Two obligations that often get conflated:
Ongoing handling. Monitor your dependencies (libraries you ship, including transitive ones) for newly disclosed vulnerabilities. Document remediation. Ship security updates without unreasonable delay. The CRA doesn’t fix “unreasonable” but most regulators read it as days for critical, weeks for high.
Active-exploitation reporting. If a vulnerability in your product is being exploited in the wild, you have to file an Early Warning to ENISA within 24 hours of becoming aware. A full Vulnerability Notification follows within 72 hours, and a Final Report (root cause, scope, remediation) within 14 days. You also have to notify affected users without undue delay.
The 24-hour clock is real. It starts when you “become aware” — which is broadly interpreted. A customer email saying their site is compromised may count.
Article 17 — Authorised representatives
Manufacturers based outside the EU must appoint an authorised representative inside the EU who can take regulatory correspondence and produce documentation on demand. The representative doesn’t take liability for your product, but they’re the addressable point of contact for ENISA and national market surveillance authorities.
Most plugin developers handle this by either contracting with a compliance representative service or, if they have an EU-based collaborator, naming that person. The representative’s name and address goes on the EU Declaration of Conformity and (typically) the public website.
Article 23 — Conformity assessment
For most WordPress plugins, conformity assessment is self-declaration — Module A, internal production control. You evaluate that your product meets the CRA essential requirements (Annex I), document the evidence in the technical file, sign the EU Declaration of Conformity, and you’re conforming.
Products classified as “important” or “critical” (Annex III) take a more involved assessment route. For WordPress, that’s mostly authentication and password management plugins, network security plugins, and anything classified as a managed service. Standard content management plugins, ecommerce add-ons, and most utility plugins fall under self-declaration.
Annex II — Technical documentation
The technical file is the document collection a regulator can demand on 48 hours’ notice. Contents required by Annex II include:
- Product description, intended use, foreseeable misuse
- Software Bill of Materials covering dependencies (CycloneDX or SPDX format; CycloneDX is the format ENISA references most often)
- Architecture description and design choices relevant to security
- Risk assessment
- List of harmonised standards applied (when those are published — currently the EN 18031 series is in development)
- Test results and reasoning
- The signed EU Declaration of Conformity
Keep all of this for 10 years from the date the product was placed on the market.
Annex V — EU Declaration of Conformity
A short, signed declaration that identifies the product, the manufacturer (and EU authorised representative if applicable), the standards applied, and the conformity assessment route taken. One per product. Updated whenever the product materially changes.
The DoC is the artifact regulators ask for first. It’s typically a single-page document. MMCRA Toolkit produces one per plugin populated from your Settings, exportable as HTML and ready for print-to-PDF and signature.
Article 31 — Market surveillance
National market surveillance authorities (in each EU member state) can request your technical file at any time. They can also order corrective action if they think your product doesn’t conform, including market withdrawal in extreme cases. They share intelligence across the EU through the Safety Gate (formerly RAPEX) network.
Practically, this means: keep the technical file ready to deliver on 48 hours’ notice. The Compliance Bundle MMCRA Toolkit exports is built around this scenario.
Penalties
Article 64 sets maximum administrative fines:
- Essential requirements violations (Annex I): up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher.
- Other obligations: up to €10 million or 2% of turnover.
- Incorrect or misleading information to a regulator: up to €5 million or 1% of turnover.
National authorities set the actual fine within those caps based on severity, intent, and prior history. The percentage-of-turnover formulation matters because for established plugin businesses, 2.5% of revenue can exceed €15 million.
What plugin developers need to do before Sept 11, 2026
A working list:
- Decide whether each of your plugins is in scope (commercial activity test).
- Appoint an EU authorised representative if you’re not based in the EU.
- Publish a Vulnerability Disclosure Policy and a security.txt for each product.
- Generate an SBOM for each shipped product in CycloneDX 1.6 format.
- Sign an EU Declaration of Conformity for each product.
- Stand up an ongoing vulnerability monitoring process against your dependencies.
- Document an incident-response runbook with the 24h / 72h / 14-day deadlines.
- Store everything as the technical file. Be ready to ship it on 48 hours’ notice.
MMCRA Toolkit handles items 3–8 from inside your WordPress install. See the product page or read the full deadline checklist.
Not legal advice. This guide is for orientation. Talk to qualified counsel about your specific obligations, especially around the authorised representative requirement, classification under Annex III, and the choice of conformity assessment route.
Produce the artifacts in an afternoon.
MMCRA Toolkit runs every CRA control inside your existing WordPress. SBOM, VDP, signed DoC, monitoring, Compliance Bundle. From $149/yr.