EU's Cyber Resilience Act - complete guide for open source vendors

Compliance determination

Do developers outside the EU or without an EU business need to worry about the CRA?

Yes. The CRA applies if EU users can access your software and you have any commercial activity, regardless of where you're located.

Quick compliance check: do you need CRA compliance?

✅ YES - Full CRA compliance required if ANY of these apply:

• EU users can download/buy your plugins
• You offer any paid services (support, premium versions, custom development)
• You're a business entity developing plugins
• Your plugins are on WordPress.org + you have any commercial activity

❌ NO - CRA exemption applies only if ALL of these are true:

• Pure hobby project with zero commercial aspects
• Individual developer (not a business entity)*
• No paid services or monetization of any kind
• No EU users (technically impossible to verify/maintain)

* If you're a legal entity (company, foundation, etc.) maintaining open source software, you may be classified as an "open source software steward" under the CRA, which has different obligations than manufacturers but is not exempt.

⚠️ GREY AREA - Get legal advice if ANY of these apply:

• You accept donations but provide no paid services
• You're employed by a company but develop plugins as personal projects
• You contribute to commercial plugins from other developers

Timeline & deadlines

How much time do I have?

The CRA has four key implementation dates:

Requirements & risk categories

Understanding the CRA – Core Principles & Requirements 

All new products must be hardened to:

• Prevent unauthorized access
• Protect data (e.g., through encryption)
• Resist interception or tampering
• Continue functioning during a denial-of-service (DoS) attack
• Avoid disrupting other connected devices, even when under attack

Additionally, all products must be capable of receiving security updates separate from regular updates and, if necessary, rolling back to previous versions. This includes:

Allowing users to roll back an update if something goes wrong, or reset the product to its original factory settings.

Being able to get updates, whether directly or remotely.

Notifying users when updates are available.

Risk assessment categories in the CRA

The CRA categorizes products based on their cybersecurity risk. This is important because the category determines how you, as a developer or manufacturer, need to prove your product is secure. Here are the categories:

Default Category (No specific class / Lower Risk): Most WordPress plugins. Self-assessment allowed.

Class I (Important Products with Digital Elements): Higher-risk products affecting other systems. Third-party assessment required.

Examples:

• Standalone and embedded web browsers.
• Password manager software.
• Network management systems.

Class II (Critical Products with Digital Elements) This category is for products presenting the highest level of cybersecurity risk, where a security failure could cause very severe harm or disruption. These products must undergo a conformity assessment by an independent third-party organization to ensure they meet the CRA's tough security standards.

Examples:

• Hardware Security Modules (HSMs).
• Industrial Control Systems (like PLCs or SCADA systems).
• Firewalls and intrusion detection/prevention systems.

Consequences & enforcement

What happens if you don't comply with the CRA?

Ignoring the CRA can lead to serious consequences. First, non-adherence to the CRA can result in substantial fines, ranging from €5,000,000 to €15,000,000. The exact rules and procedures will vary for each EU Member State, but the penalties will be calculated as 1% to 2.5% of an operator's total worldwide annual turnover from the previous financial year.

Authorities can immediately remove non-compliant products from all EU-accessible platforms and mandate user notifications.

Beyond fines, authorities can immediately remove your plugins from WordPress.org, CodeCanyon, and other platforms accessible to EU users. For serious violations, they may require you to notify all existing users and assist with product removal, even from websites you don't control.

CE marking & documentation

CE marking and Declaration of Conformity: your product's EU passport

Before your WordPress plugin can legally be distributed in the EU market, it must display the CE marking and be accompanied by an EU Declaration of Conformity. Think of these as your product's official "passport" for the European market.

This requirement becomes enforceable on December 11, 2027. After this date, plugins without proper CE marking cannot be distributed on any EU-accessible platform.

What is CE marking?

CE marking indicates your plugin meets EU cybersecurity requirements.

Key requirements

• Visible CE marking must be affixed to your product (digitally for software)
• Declaration of Conformity must be readily available to authorities and users
• Authorized representative is required if you're based outside the EU
• Product identification linking the marking to your specific plugin/version

EU Declaration of Conformity: what you must include

Your Declaration of Conformity is a formal document stating that your WordPress plugin meets CRA requirements. It must contain:

• Your company details (name, address, contact information)
• Product identification (plugin name, version, unique identifier)
• Applicable EU legislation (reference to CRA regulation)
• Harmonized standards used for conformity assessment
• Conformity assessment procedure followed (self-assessment for most plugins)
• Risk category classification (Default, Class I, or Class II)
• Authorized representative details (if applicable)
• Date and location of declaration
• Authorized signature and title of signatory

For WordPress plugin developers

• Digital CE marking can be displayed in your plugin's documentation, readme files, or admin interface
• Declaration availability through your website, plugin repository listing, or downloadable document
• Version-specific declarations are required for each major release with security changes
• Record keeping of declarations for at least 10 years after product withdrawal

Required documentation: risk assessment, SBOM (Software Bill of Materials), security testing records, and incident response plan. Keep for 10 years after product withdrawal.

Your 90-day CRA preparation plan

Don't Wait: With less than 3 years until full compliance, starting now gives you a significant advantage over competitors who delay.

WordPress-specific checklist

CRA checklist for WordPress developers

As a WordPress plugin or theme developer, your products will likely fall under the default risk category of the CRA. This means you can perform a self-assessment to declare conformity. However, to ensure you are compliant, you'll need to address the following:

WordPress-specific considerations

• Auto-Updates & Security: Separate security patches from feature updates. Ensure your update process can roll back if needed and clearly communicate security vs. feature changes to users.
• Marketplace Compliance: WordPress.org distribution still requires CRA compliance if you offer any commercial services. Commercial marketplaces (CodeCanyon, etc.) make you a clear manufacturer with full obligations.
• Multi-Site Networks: Assess how plugin vulnerabilities could affect entire WordPress networks, not just individual sites. Document network-admin security guidance separately.
• Child Theme Dependencies: If you modify parent themes substantially or add security features, you become the manufacturer. Document parent theme security dependencies and coordinate updates.

Secure development & design

• Integrate Security from the Start: Incorporate security checks and considerations throughout your entire development lifecycle. Follow WordPress secure coding best practices (e.g., use nonces, validate and sanitize all inputs, escape outputs, use prepared SQL statements, check user capabilities).
• Secure Defaults & Resets: Ensure your plugin/theme has secure settings enabled by default upon activation. If your product has configurable security settings, provide an easy way for users to reset them to a known secure default state.
• Regular Risk Assessment: Perform a cybersecurity risk assessment specifically for your plugin/theme. Consider its features, the data it handles, and the potential impact if a vulnerability is exploited. Identify and document potential threats and how you mitigate them.
• No Known Exploitable Vulnerabilities at Release: Thoroughly test for and fix any known exploitable vulnerabilities before releasing a new version or update.

Vulnerability management & response

• Vulnerability Disclosure Policy (VDP): Create and publish a clear VDP, outlining how you handle vulnerability reports, expected response times, and how you disclose fixed vulnerabilities.
• Establish a Vulnerability Handling Process: Set up a process for users and researchers to report security vulnerabilities to you.
• Timely Security Patches: Release security updates separately from features. Ensure WordPress auto-update compatibility and document rollback procedures.
• User Notification of Exploits & Incidents: If a vulnerability in your plugin/theme is being actively exploited or a severe security incident occurs, prepare to inform your users clearly about the risk and mitigation steps.

Documentation, transparency & user guidance

• Maintain Technical Documentation: Keep up-to-date technical documentation that includes security considerations, your risk assessment summary, and vulnerability handling processes.
• Software Bill of Materials (SBOM): Create and maintain an SBOM listing all components, libraries (e.g., third-party JavaScript, PHP libraries), and dependencies used in your plugin/theme.
• Clear User Instructions: Provide clear, accessible instructions for users on secure installation and configuration, secure use and maintenance of your plugin/theme, how to obtain security updates, where to report security vulnerabilities, contact information for support, and the intended purpose and security functions of the product.
• Information on Support & Update Lifespan: Clearly state the period during which you will provide security updates (the CRA suggests at least five years or the expected product lifetime).

Security practices & testing

• Regular Code Scanning & Audits: Test across WordPress versions and popular plugin combinations. For multi-site networks, assess the impact of vulnerability network-wide.
• Dependency Management: Keep track of third-party libraries and components you use; update them promptly when they have security fixes.
• Data Security & Minimization: Only process and store data that is essential for your plugin/theme's functionality. Implement measures to protect the confidentiality and integrity of any data handled (e.g., sensitive user settings, submitted form data).
• Access Control: Ensure your plugin/theme correctly implements WordPress roles and capabilities to prevent unauthorized access to its functions or data.
• Incident Response Plan: Develop a basic plan for how your organization will respond if a security incident affects your plugin/theme or users.

Patchstack solution

How Patchstack helps with CRA compliance

Patchstack simplifies several key parts of CRA compliance for plugin and theme developers and streamlines vulnerability disclosure:

• Reviews and filters vulnerability reports, removing low-quality submissions so you only receive legitimate security reports
• Provides and manages your complete Vulnerability Disclosure Program (mVDP)
• Assigns official CVEs
• Reduces legal liability through proper vulnerability handling procedures
• Provides audit trail documentation for compliance reviews
• Ensures coordinated disclosure following responsible security practices
• Helps prepare for future CRA reporting requirements

The CRA is a sweeping regulation, and complying with all 71 articles can be overwhelming. Patchstack helps by streamlining the most time-consuming tasks.

One of the core CRA requirements is having a clear Vulnerability Disclosure Policy (VDP). Without a managed process, you'd need to handle every security report yourself, including vague or low-effort submissions that waste time. Patchstack's managed VDP (mVDP) solves this by acting as an expert intermediary.

Our team pre-screens incoming reports, so only valid and relevant issues reach you. This reduces noise and helps you focus on actual vulnerabilities.

Patchstack is also the largest CVE Numbering Authority globally, assigning more CVEs than major companies like Microsoft. This structured approach not only strengthens your security posture but also prepares you for CRA obligations around public vulnerability databases and incident disclosures.

In short, Patchstack helps make CRA compliance achievable without slowing your development work.