The EU Cyber Resilience Act is coming, and if you develop WordPress plugins sold or distributed in Europe, it applies to you. Unlike GDPR—which focuses on personal data—the CRA regulates the security of software itself. This is the first comprehensive EU regulation of its kind, and for WordPress developers, ignoring it isn't an option.
This guide walks you through what the CRA actually requires, how it affects WordPress plugin developers, and the practical steps you can take starting today to build compliant products.
Table of Contents
- What Is the EU Cyber Resilience Act?
- Why WordPress Developers Should Care
- Who the CRA Applies To
- Core CRA Requirements for Software
- CRA vs. Other EU Regulations
- Practical Compliance Steps
- How WP HealthKit Supports Compliance
- The Open-Source Question
- Timeline and Enforcement
- Frequently Asked Questions
What Is the EU Cyber Resilience Act?
The Cyber Resilience Act (CRA), formally adopted by the European Council in December 2024, is the EU's response to rising software vulnerabilities and cyber incidents. It's a regulation—not a directive—meaning it applies directly across all EU member states without requiring individual implementation laws.
Start your compliance journey by uploading your plugin to WP HealthKit for a comprehensive security audit. Browse the WP HealthKit directory to see how audited plugins handle security documentation. Check the security leaderboard to benchmark your plugin against others. Learn about free audits for open-source plugins through our open-source program.
The CRA sets baseline security standards for all products and services with digital elements sold in the EU. For software developers, this means documenting security practices, managing vulnerabilities, and committing to security updates throughout a product's lifetime.
The regulation was proposed in 2022 following high-profile supply chain breaches (SolarWinds, Log4j) and reflects the EU's broader strategy to reduce cybersecurity risks. The CRA is intentionally broad and applies to everything from mobile apps to enterprise software to—yes—WordPress plugins.
Key dates to know: The CRA entered into force in January 2025. Most requirements take effect 18 months after entry into force (around July 2026), though some provisions apply sooner. This means 2026 is the critical year for compliance preparation.
Why WordPress Developers Should Care
WordPress powers roughly 43% of all websites globally. That scale means WordPress plugins are valuable targets for attackers and, consequently, they fall directly under CRA jurisdiction if they're distributed to EU customers.
The CRA introduces legal obligations and potential penalties. Non-compliance can result in fines up to €15 million or 2.5% of annual global turnover—whichever is higher. For solo developers or small agencies, these penalties are existential threats.
But beyond penalties, there's a practical business case. The CRA creates a compliance threshold. Developers who document security practices, publish vulnerability policies, and maintain SBOMs gain competitive advantage. You can market compliance as a feature. WP HealthKit helps you prove it.
There's also the supply chain angle. As plugins become critical infrastructure, WordPress site owners increasingly demand security assurance. They'll ask for evidence of security practices, vulnerability handling, and update commitment. CRA compliance becomes your answer.
Who the CRA Applies To
The CRA defines "manufacturers" as natural or legal persons placing products with digital elements on the market. This includes WordPress plugin developers, theme creators, and SaaS providers.
It doesn't matter if you charge for your plugin or release it free. It doesn't matter if you're a solo developer in a small country or a large agency. If you distribute software with digital elements in the EU market, you're a manufacturer under CRA.
The one major exception: open-source software developed and distributed freely on non-commercial open-source platforms has exemptions—but those exemptions are narrower than many assume. We'll cover this in detail below.
You're not covered if your plugin is purely internal (used only by your own organization). You're also not covered for products that don't contain digital elements (though nearly all software does). But if there's any possibility an EU customer uses your plugin, you should assume the CRA applies.
Core CRA Requirements for Software
The CRA doesn't mandate specific technical controls. Instead, it requires evidence of security practices. Here are the core requirements:
Security by Design and Default
You must design and implement your plugin with security as a core consideration, not an afterthought. This means threat modeling, secure coding practices, and security testing throughout the development lifecycle.
Practically: Document your development process. Show code review requirements, security training for your team, and testing methods. You don't need to achieve perfect security—nobody can—but you need to demonstrate you took reasonable precautions.
Vulnerability Handling and Disclosure
You must establish a documented process for receiving, managing, and disclosing security vulnerabilities. This includes a public vulnerability disclosure policy and a mechanism for researchers and users to report issues responsibly.
WP HealthKit helps here: our platform integrates vulnerability reporting workflows, letting researchers and security professionals disclose issues to you securely before public release.
Software Bill of Materials (SBOM)
An SBOM is a structured list of components, libraries, and dependencies in your software. The CRA requires you to provide SBOMs for your products.
This means documenting every third-party library your plugin uses, including versions and licenses. Tools like CycloneDX and SPDX provide standardized formats. WP HealthKit includes SBOM generation so you can export compliant bills of materials.
Security Updates for Product Lifetime
You must provide security updates for the entire lifetime of your product. The CRA doesn't define "lifetime," but it expects reasonable support periods—typically at least 2-5 years depending on your product positioning.
This doesn't mean feature updates; it means security patches. If a vulnerability affects your plugin, users need a patch available.
Incident Reporting Obligations
If a vulnerability in your software affects critical infrastructure or causes significant harm, you may need to report the incident to relevant EU authorities (ENISA—the European Union Agency for Cybersecurity). The thresholds are high, but they exist.
For most WordPress plugins, this requirement is theoretical unless your plugin processes sensitive data or controls infrastructure. Document your incident response process anyway.
CRA vs. Other EU Regulations
You're likely familiar with GDPR. The CRA is completely different and complementary.
GDPR vs. CRA
GDPR regulates personal data processing. The CRA regulates software security. You can be GDPR-compliant but CRA non-compliant, and vice versa. A plugin can handle user data perfectly (GDPR) but contain exploitable vulnerabilities (CRA violation). Both matter.
NIS2 Directive vs. CRA
NIS2 (updated Network and Information Security Directive) applies to critical infrastructure operators and larger organizations. The CRA applies to software manufacturers. NIS2 is about operational security; CRA is about product security. They overlap for large enterprises but mostly target different audiences.
European Accessibility Act (EAA) vs. CRA
The EAA requires digital products to be accessible to people with disabilities. Like the CRA, it's a horizontal regulation affecting many industries. EAA compliance is separate from CRA compliance, though secure code is sometimes more accessible code.
The CRA stands alone as the first regulation directly targeting software security across all industries.
Practical Compliance Steps
CRA compliance isn't a one-time checklist. It's a commitment to ongoing security practices. Here's how to start:
Step 1: Document Your Security Practices
Write a security document for your plugin. Include:
- Development team structure and security responsibilities
- Code review process (peer review, automated checks)
- Testing practices (unit tests, integration tests, security scanning)
- Dependency management (how you track and update libraries)
- Release process (how patches are deployed)
This document doesn't need to be perfect. It needs to show you thought about security systematically.
Step 2: Publish a Vulnerability Disclosure Policy
Create a SECURITY.md file in your plugin repository or a security policy on your website. Include:
- How researchers should report vulnerabilities (email, form, responsible disclosure platform)
- What information to include in a report
- Expected response timeline
- Your commitment to addressing issues within a reasonable period
- When you'll publicly disclose the vulnerability (typically after patching)
This is often called "responsible disclosure" and it's table stakes for modern software.
Step 3: Implement Automated Security Scanning
Use tools to continuously scan your code for known vulnerabilities and security issues. Options include:
- Composer's
security-checkerfor PHP dependencies - OWASP Dependency-Check for broader dependency scanning
- GitHub's native Dependabot for automated dependency updates
- Snyk for continuous vulnerability scanning
- WP HealthKit's integrated scanning for WordPress-specific issues
Automation catches problems before they reach production.
Step 4: Generate and Maintain Software Bills of Materials
Document your plugin's dependencies using SBOM tools. The CycloneDX format is widely supported. Include:
- Direct dependencies (libraries your plugin explicitly uses)
- Transitive dependencies (libraries that your dependencies use)
- Version numbers for all components
- Licenses for all components
WP HealthKit can generate SBOMs automatically from your plugin's composer.json and dependencies.
Step 5: Set Up Dependency Update Workflows
WordPress plugins typically use Composer for PHP dependency management. Set up automated or semi-automated workflows to:
- Monitor for security updates to your dependencies
- Review and test updates in a staging environment
- Deploy patches to production within days
- Communicate updates to users
Tools like Dependabot or Renovate automate this significantly.
Step 6: Create a Security Update Schedule
Commit to security update timelines. For instance:
- Critical vulnerabilities: patch within 24-48 hours
- High-severity vulnerabilities: patch within 1 week
- Medium/low vulnerabilities: patch within 1 month or next release
Document and publish these commitments.
Step 7: Test Security Updates Thoroughly
Security updates sometimes break functionality. Maintain a test suite covering your plugin's core features. Run tests against the last 2-3 WordPress versions and with popular plugins to ensure compatibility.
WP HealthKit includes testing orchestration to simplify this.
How WP HealthKit Supports Compliance
WP HealthKit is built for exactly this: helping WordPress developers prove and maintain security standards.
The platform provides:
- Vulnerability Scanning: Continuous scanning of your plugin code and dependencies, detecting known vulnerabilities against CVE databases.
- Security Audits: Automated analysis of your plugin's security posture against CRA and industry standards.
- SBOM Generation: Export compliant software bills of materials in CycloneDX and SPDX formats.
- Vulnerability Disclosure Workflow: Manage security reports from researchers and users through a structured process.
- Security Documentation: Templates and guidance for security policies, incident response, and update commitment documentation.
- Compliance Reporting: Generate reports demonstrating your compliance with CRA requirements for audits, certifications, or customer assurance.
Rather than managing security practices across multiple tools, WP HealthKit centralizes them. You get evidence of compliance in one platform.
Starting today, you can upload your plugin to WP HealthKit and run a baseline security audit to understand your current compliance gaps.
The Open-Source Question
The CRA has an open-source exemption, but it's narrower than many developers hoped.
What's Exempted
Open-source software developed and distributed through recognized open-source platforms (GitHub, GitLab, etc.) for no commercial gain is exempt from most CRA requirements—but with significant conditions.
The key word is "no commercial gain." If you distribute the software free but accept donations exceeding €10,000 annually, the exemption may not apply. If you offer commercial services around the software (premium support, hosted versions), the exemption may not apply. The law is still being clarified.
What's Not Exempted
Even exempt open-source software must still comply with:
- Security by design (you can't deliberately ship vulnerable code)
- Vulnerability reporting obligations (if incidents affect critical infrastructure)
Additionally, if your open-source plugin is repackaged or bundled with commercial software, the commercial distributor must comply with the CRA. Your exemption doesn't extend to commercial derivatives.
Practical Advice
If you're developing an open-source WordPress plugin:
- Operate on a recognized platform (GitHub, GitLab qualify)
- Ensure it's genuinely free, with minimal or no commercial revenue
- Still implement security best practices (not as legal requirement, but as professional practice)
- Document your commitment to security anyway—it builds trust
If you accept significant donations or offer premium services, assume the CRA applies and plan accordingly.
Timeline and Enforcement
Understanding when requirements take effect is critical for your planning:
10 December 2024: CRA entered into force.
11 September 2026: The Article 14 reporting obligations take effect — 24-hour early warning to ENISA for actively exploited vulnerabilities, 72-hour detailed notification. Your vulnerability disclosure channel and handling process must exist by this date.
11 December 2027: The full set of requirements applies — Annex I essential security requirements, SBOM obligation, CE marking, and the EU Declaration of Conformity.
Enforcement: EU member states designate market surveillance authorities. Non-compliance can result in fines of up to €15 million or 2.5% of global turnover, or products being withdrawn from the EU market.
What does this mean? The reporting deadline is no longer months away — it's here. If you don't have a vulnerability disclosure policy and a monitored security contact in place, that is the single thing to fix this week. We've published a focused walkthrough: The CRA Deadline for WordPress Plugin Developers: What 11 September 2026 Actually Requires.
For the full regulatory text, see the EU Cyber Resilience Act and the ENISA guidance on CRA implementation.
Frequently Asked Questions
Do I have to comply if I'm not in the EU?
If you're outside the EU but sell or distribute plugins to EU customers, yes—the CRA applies to products placed on the EU market. It doesn't matter where you're located. If EU users can download your plugin, you're a manufacturer under CRA.
The "placed on the market" standard is broad. If your plugin is available in the WordPress.org plugin directory or any other publicly accessible repository, EU users can find and use it. That means you're placing it on the market.
What happens if I don't comply?
Non-compliance can result in administrative fines up to €15 million or 2.5% of annual global turnover (whichever is higher). Member states can also ban products from their markets, require recalls, or impose public notices about non-compliance.
For small developers, the financial penalties are existential. Compliance isn't optional if your business depends on WordPress.
Does the CRA apply to WordPress themes?
Yes. Themes are products with digital elements sold in the EU market. If you develop themes, the same CRA requirements apply. Theme marketplaces will likely develop compliance certifications.
Can I comply alone, or do I need a consultant?
You can build compliance practices in-house using the steps outlined above. You don't need expensive consultants. Use WP HealthKit and open-source tools, document your practices, and maintain reasonable security standards.
Consultants help if you're building enterprise-scale plugins or operating in highly regulated industries (finance, healthcare). For typical WordPress plugins, internal documentation suffices.
What if I have no budget for compliance?
Most compliance activities are process-based, not budget-based. Writing documentation is free. Using open-source security tools (like Snyk's free tier or GitHub's built-in scanning) costs nothing. Testing thoroughly takes time, not money.
WP HealthKit offers free scanning tiers so you can start auditing without investment. Budget is the excuse; prioritization is the real constraint.
How does the CRA affect plugin users?
Plugin users benefit significantly. The CRA creates incentives for developers to ship secure software, maintain it responsibly, and disclose vulnerabilities openly. Over time, users get plugins that are more secure, better maintained, and more transparent about risks.
Can my plugin be removed from WordPress.org for non-compliance?
Wordpress.org team hasn't announced CRA-specific enforcement policies yet. But as a platform hosting plugins distributed to EU users, they have liability if hosted plugins violate CRA. Expect eventual WordPress.org policies requiring compliance documentation or removing non-compliant plugins.
Proactive compliance now protects your plugins from future removal.
What's the difference between security scanning and compliance?
Security scanning finds vulnerabilities in code (does the plugin have a SQL injection bug?). Compliance checks that you have processes in place (do you have a documented vulnerability disclosure policy?). Both matter.
A plugin can have zero known vulnerabilities (scanning green) but terrible processes (compliance red). The CRA requires both security and documentation of security practices.
Does WP HealthKit guarantee CRA compliance?
WP HealthKit helps you identify gaps, document practices, and maintain standards. It automates much of the compliance work. But compliance is ultimately your responsibility. WP HealthKit is the toolkit; you're the builder.
Use WP HealthKit to generate audits, get recommendations, document practices, and generate SBOMs. Then verify the output against CRA requirements or with a qualified professional.
What if my plugin uses libraries with known vulnerabilities?
Update the vulnerable dependencies. If updates break compatibility, you have two options: fix the incompatibility or discontinue the plugin.
Leaving known vulnerabilities in place after being notified of them likely violates CRA. WP HealthKit's vulnerability scanner identifies these immediately so you can prioritize fixes.
Next Steps
The EU Cyber Resilience Act is here. If you develop WordPress plugins distributed to EU customers, compliance is no longer optional—it's a regulatory requirement and a competitive advantage.
Start with the practical steps outlined above:
- Document your security practices
- Publish a vulnerability disclosure policy
- Implement automated scanning
- Generate an SBOM
- Set up update workflows
WP HealthKit accelerates every one of these steps. Upload your plugin today, run a baseline audit, and get specific recommendations for your plugin's compliance gaps.
The first-mover advantage is real. Developers who achieve CRA compliance early will market it, build trust, and differentiate from competitors. Don't wait for enforcement—start now.
Questions about WordPress CRA compliance? Upload your plugin to WP HealthKit for a free security audit and compliance assessment.