The complete CRA compliance guide for WordPress developers

What is the CRA (Regulation 2024/2847)?

The Cyber Resilience Act, officially Regulation (EU) 2024/2847, is a horizontal cybersecurity regulation adopted by the European Parliament and the Council of the European Union. It sets mandatory cybersecurity requirements for all “products with digital elements” placed on the EU market.

This isn’t a voluntary standard or an industry certification you can ignore. The CRA has the force of law. Manufacturers who fail to comply face fines of up to EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher. For most of us building and selling WordPress plugins independently, the fixed cap is the number that matters. And EUR 15M is more than enough to end a business.

The regulation was published in the Official Journal of the European Union on 20 November 2024 and entered into force on 10 December 2024. Different parts become enforceable on staggered dates, which was supposed to give us time to prepare. That window is closing fast.

Why does this matter for WordPress?

WordPress powers over 40 percent of the web. Thousands of commercial plugins and themes are sold every day through marketplaces, direct sales, and subscription models. Under the CRA, each of these products is a “product with digital elements” if it is made available on the EU market for a fee or as part of a commercial activity. The regulation doesn’t care whether you’re a multinational corporation selling enterprise software or a solo developer with a WooCommerce extension. The same baseline requirements apply to both.

We’re in new territory here. WordPress developers are used to security best practices being recommendations. The CRA turns many of those practices into legal obligations with real penalties if you don’t follow them.

Key dates you cannot miss

The CRA uses a phased timeline. Two dates matter most for WordPress developers:

The September 2026 deadline is the urgent one. You need to have vulnerability handling procedures set up and be connected to the EU single reporting platform for incident notifications. If you sell plugins or themes commercially and haven’t started preparing, start today. Not next week. Today.

The December 2027 deadline covers the broader set of requirements: security-by-design principles, SBOMs, conformity assessment, and ongoing security updates for your product’s support period. It feels far away, but the amount of work involved is much larger, so starting early will save you a lot of headaches.

Who does it affect?

The CRA applies to manufacturers of products with digital elements that are placed on the EU market. In the WordPress world, that typically means:

• Commercial plugin developers who sell plugins directly, through marketplaces like CodeCanyon or Freemius, or via their own websites.
• Commercial theme developers selling themes through ThemeForest, their own shops, or other channels.
• SaaS-connected plugin makers whose plugins connect to cloud services and are sold or bundled commercially.
• Agencies building bespoke plugins or themes for clients, where those products are then distributed or made available to EU end users.

Who is exempt?

The CRA has specific exemptions for open-source software that is developed and supplied outside the course of a commercial activity. Purely volunteer-driven, community-funded open-source projects that do not generate revenue from the software itself are generally outside scope. The boundaries get tricky though. Accepting donations doesn’t automatically trigger the CRA, but offering paid support or premium tiers may.

Not sure whether your plugin falls in scope? Read our dedicated article on determining whether your WordPress plugin is subject to the CRA, or use the free “Am I in scope?” wizard built into CRA Guard.

The 5 core obligations

The CRA lays out its cybersecurity requirements in Annex I. For WordPress developers, these boil down to five practical areas you need to deal with.

1. Vulnerability handling process

You need a coordinated vulnerability disclosure (CVD) policy. In plain terms: a clear, publicly documented way for security researchers and users to report vulnerabilities in your products.

Here’s what that looks like in practice:

• Publish a security.txt file (following RFC 9116) that tells researchers how to report issues.
• Maintain a contact point or dedicated channel for receiving vulnerability reports.
• Triage, verify, and fix reported vulnerabilities in a timely manner.
• Document your vulnerability handling procedures internally.
• Ship patches without unnecessary delay once a vulnerability is confirmed.

This obligation kicks in on 11 September 2026, making it the first compliance milestone. CRA Guard generates a compliant security.txt file and provides a vulnerability handling policy template to get you started.

2. Software bill of materials (SBOM)

The CRA requires you to identify and document all components and dependencies in your products. You do this through a Software Bill of Materials, a machine-readable inventory that lists every library, package, and third-party component your plugin or theme relies on.

For WordPress plugins, this typically includes Composer packages (PHP dependencies) and npm packages (JavaScript dependencies used in your build process). The SBOM should follow an established format like CycloneDX or SPDX.

Why bother? Two reasons. First, it lets you track which vulnerabilities affect your product because you know exactly what code is included. Second, it allows downstream users and authorities to verify your supply chain. Read our practical guide to SBOMs for WordPress plugins for the step-by-step details.

3. Security updates and patches

The CRA requires you to provide security updates for the entire support period of your product. Once you put a product on the EU market, you are legally obligated to address known vulnerabilities for at least the expected product lifetime, and in any case for a minimum of five years from the date of placing on the market.

In practical terms, you need to:

• Deliver security patches promptly and free of charge.
• Separate security updates from feature updates where feasible, so users can apply fixes without being forced to upgrade to new functionality.
• Inform users about available security updates through appropriate channels.
• Maintain the infrastructure to distribute updates reliably.

For those of us used to annual licence renewals, this creates a real tension: even if a customer’s licence lapses, you may still owe them security-only updates for the duration of the support period. That’s a business model question we all need to think about carefully.

4. Incident reporting to ENISA

When you become aware of an actively exploited vulnerability in your product, the CRA requires you to notify ENISA (the EU Agency for Cybersecurity) through the single reporting platform. The reporting timeline is strict:

• Within 24 hours: An early warning that a vulnerability is being actively exploited.
• Within 72 hours: A more detailed notification about the nature of the exploit, the affected products, and any corrective measures taken or planned.
• Within 14 days: A final report including a root cause analysis and confirmation that remediation measures have been applied.

This three-stage structure mirrors what NIS2 requires for critical infrastructure operators, but the CRA extends it to all product manufacturers. It applies from 11 September 2026.

If that sounds stressful, it is. Getting a 24-hour report together while you’re also trying to patch a live exploit is no fun. CRA Guard’s Incident Centre (available in the paid tier) gives you structured templates for each reporting stage and tracks the 24h/72h/14d deadlines with countdown timers so you don’t miss a filing window.

5. Documentation and conformity assessment

The CRA requires you to prepare technical documentation showing how your product meets the cybersecurity requirements. Good news for most of us: WordPress plugins and themes fall under the “default” (non-critical) category, so this is a self-assessment process. You do not need a third-party audit.

Your documentation should cover:

• A general description of the product, its intended use, and its cybersecurity properties.
• A risk assessment identifying cybersecurity risks and how they are mitigated.
• The SBOM (as described above).
• Evidence of your vulnerability handling and incident reporting processes.
• An EU Declaration of Conformity stating that the product meets CRA requirements.

CRA Guard’s free tier includes five document templates covering the most common requirements: Vulnerability Disclosure Policy, Security Update Policy, Risk Assessment Framework, EU Declaration of Conformity, and Technical Documentation Outline. They’re starting points, not finished documents, but they save you from staring at a blank page.

Step-by-step compliance roadmap

A regulation this big can feel overwhelming. We found it helps to break the work into phases so you’re not trying to do everything at once. Here’s a roadmap built specifically for WordPress plugin and theme developers.

Phase 1: Assessment (start now)

1. Determine whether you are in scope.Use CRA Guard’s free wizard or read our scope guide to work through the questions.
2. Inventory your products. List every plugin and theme you sell or distribute commercially. For each one, note which dependencies it includes (Composer packages, npm libraries, third-party API integrations).
3. Review your current security posture. Do you already have a vulnerability disclosure policy? A security.txt file? A process for issuing security patches? Figure out where the gaps are.

Phase 2: Foundation (by June 2026)

1. Publish a security.txt file. CRA Guard generates one for you and installs it at the correct location on your site.
2. Write your vulnerability disclosure policy.Use CRA Guard’s template as a starting point and adapt it to your workflow.
3. Set up an internal vulnerability handling process. Define who receives reports, how they are triaged, and what your target response times are.
4. Start monitoring your dependencies.Use CRA Guard’s vulnerability scanner or subscribe to advisory feeds for the libraries you use.

Phase 3: September 2026 deadline

1. Make sure your vulnerability handling process actually works. Test it by running a simulated vulnerability report through your workflow. You don’t want to discover problems when a real exploit lands.
2. Prepare for incident reporting. Familiarise yourself with the ENISA single reporting platform and the 24h/72h/14d timeline. Have templates ready so you can file quickly under pressure.
3. Audit your security update mechanism. Confirm that you can release and distribute patches rapidly when needed.

Phase 4: Full compliance (by October 2027)

1. Generate your SBOM.CRA Guard’s SBOM generator reads your composer.json and package.json to produce a CycloneDX 1.5 document.
2. Complete the technical documentation. Use the document templates in CRA Guard to produce your risk assessment, conformity declaration, and technical documentation package.
3. Work through the self-assessment. The CRA Guard compliance checklist has 26 items mapped to CRA articles. Go through each one and verify that every requirement is addressed.
4. Prepare the EU Declaration of Conformity. This is the formal statement that your product meets CRA requirements. CRA Guard provides a template you can fill in and sign.
5. Keep it going. Set up regular dependency scans, keep your documentation current, and review your processes at least once a year. Compliance is not a one-off project.

How CRA Guard helps

We built CRA Guard because we were facing these same requirements ourselves and couldn’t find a tool that addressed them from a WordPress developer’s perspective. It runs inside your WordPress dashboard and gives you what you need at every stage of the compliance process.

Free features

• “Am I in scope?” wizard– Answer 5–7 questions to find out whether the CRA applies to your products.
• 26-item compliance checklist– Every item mapped to specific CRA articles so you know exactly what each requirement refers to.
• 5 document templates– Vulnerability Disclosure Policy, Security Update Policy, Risk Assessment Framework, EU Declaration of Conformity, and Technical Documentation Outline.
• security.txt generator– Creates a compliant security.txt file following RFC 9116 and installs it on your site.
• Compliance score dashboard– A 0–100 score with green/amber/red status so you can see at a glance where you stand.
• CRA education centre– Plain-language breakdowns of CRA articles with actionable guidance.

Premium features

• SBOM generator – Reads your composer.json and produces a CycloneDX 1.5 JSON document.
• Vulnerability scanner– Checks your dependencies against the OSV.dev database and alerts you to known vulnerabilities.
• Incident Centre– Structured templates for the 24h/72h/14d ENISA reporting timeline with countdown timers.
• PDF compliance reports– Generate reports for clients, auditors, or your own records.
• Email alerts– Get notified when new vulnerabilities are found in your dependencies.

Frequently asked questions

Does the CRA apply to free WordPress plugins?

Generally, no. The CRA exempts open-source software developed and supplied outside the course of a commercial activity. If your plugin is completely free, community-developed, and not part of a commercial offering, it is likely outside scope. But freemium plugins where the free version exists to sell a premium tier? Those may well fall within scope. See our detailed scope analysis.

I am based outside the EU. Does the CRA still apply to me?

Yes, if your products are available to customers in the EU. The CRA applies to products placed on the EU market regardless of where the manufacturer is located. Think of it like GDPR: it applies to any business processing EU residents’ data, no matter where the business is based. Same principle here.

What counts as “placing on the market”?

Making a product available for distribution or use on the EU market in the course of a commercial activity. For WordPress plugins, this means selling through your own website, listing on marketplaces accessible from the EU, or distributing through any channel where EU customers can get the product.

Do I need a third-party audit?

Almost certainly not. Most WordPress plugins and themes fall under the default (non-critical) product category, which allows self-assessment. You only need a third-party audit if your product falls into one of the critical product categories in the CRA annexes (operating systems, firewalls, hardware security modules, that sort of thing). A standard WordPress plugin wouldn’t qualify as critical.

What is the minimum support period?

The CRA requires security updates for the expected product lifetime, with a minimum of five years from the date the product is placed on the market. This applies to security updates specifically. You’re not obligated to keep adding features, but you must patch known vulnerabilities for the duration of the support period.

How does this relate to GDPR?

They’re separate regulations tackling different problems. GDPR governs data protection and privacy. The CRA governs the cybersecurity of products. But they can overlap: a security vulnerability that leads to a data breach may trigger obligations under both. Read our CRA vs GDPR comparison for the full breakdown.

What happens if I do not comply?

Market surveillance authorities can impose fines of up to EUR 15 million or 2.5% of global annual turnover for non-compliance with cybersecurity requirements. They can also order products to be pulled from the market or restrict their availability. Even without formal enforcement, non-compliance creates real legal and reputational risk. Nobody wants to be the first WordPress developer to get fined.

Can I just withdraw my plugin from the EU market?

You could. Stop selling to EU customers and the CRA stops applying to new sales. But you’d be walking away from a market of over 440 million consumers and the businesses that serve them. For most of us, compliance is a better bet than retreat. And honestly, most of the CRA requirements (vulnerability handling, dependency tracking, security updates) are things we should be doing anyway. They’re good engineering practice.

Start your CRA compliance work today

The September 2026 deadline is close. Every week you spend preparing now is a week you won’t spend panicking later.

CRA Guard gives you a structured path from “where do I start?” to “fully compliant.” Install the free version, run the scope wizard, and see your compliance score. When you’re ready for SBOM generation, vulnerability scanning, and incident reporting, upgrade to a premium plan.

Download CRA Guard Free on WordPress.org

Disclaimer: CRA Guard assists with compliance processes and provides templates, checklists, and tooling to support your CRA readiness. It does not constitute legal advice. For definitive guidance on your regulatory obligations, consult a qualified legal professional with expertise in EU cybersecurity regulation.