CRA Compliance Suite

The EU Cyber Resilience Act (CRA) is a comprehensive regulation establishing mandatory cybersecurity requirements for products with digital elements sold in the European Union. It requires manufacturers to implement security by design, manage vulnerabilities, provide security updates, and maintain transparency throughout the product lifecycle. The regulation applies to software, hardware with digital elements, and remote data processing solutions.

The CRA is expected to be formally adopted in late 2024 and will enter into force 20 days after publication in the EU Official Journal. Full enforcement begins 36 months after entry into force, expected in late 2027 or early 2028. Organizations should start preparing immediately as compliance requires significant changes to development practices and documentation.

The CRA applies to "products with digital elements" placed on the EU market. This includes software applications, plugins, themes, mobile apps, IoT devices, and hardware with embedded software. If you sell or distribute software commercially in the EU, the CRA likely applies. The key factor is commercial activity—purely non-commercial open source development may be excluded, but commercial distributions are covered.

Non-compliance can result in fines up to €15 million or 2.5% of global annual turnover (whichever is higher) for serious violations. Additional penalties include €10 million or 2% of turnover for incorrect information, product recalls, market exclusion, and injunctions prohibiting sales. Beyond financial penalties, non-compliance damages reputation and customer trust.

While GDPR focuses on data protection and privacy, the CRA focuses on product cybersecurity and supply chain security. GDPR regulates how you handle personal data; the CRA regulates how you design, build, and maintain software products. Both apply to EU market activities, but they address different aspects of digital regulation. You must comply with both if you process personal data and sell software products.

Yes. The CRA applies to all products placed on the EU market, regardless of where the manufacturer is located. If you're based in the US, Canada, Australia, or anywhere else but sell to EU customers, your products must comply with CRA requirements. This is similar to GDPR's extra-territorial application.

Products with digital elements include any hardware or software product that relies on digital technology. This encompasses standalone software (applications, plugins, themes), hardware with embedded software (IoT devices, smart appliances, industrial equipment), and remote data processing solutions (SaaS platforms, cloud services). Essentially, if it has code that executes, it's likely covered.

Open source software developed and distributed entirely outside commercial context is generally excluded from CRA requirements. However, this exclusion is narrow. If you accept payment, offer premium features, provide commercial support, or monetize your open source project in any way, it's likely covered by the CRA. The GPL license itself doesn't exempt you—commercial activity is what matters.

A Software Bill of Materials (SBOM) is a comprehensive inventory of all components in your software product, including direct dependencies, transitive dependencies, and their versions. The CRA requires SBOMs to enable rapid vulnerability response, supply chain transparency, and incident management. When a vulnerability is discovered in a popular library (like Log4Shell), an SBOM lets you instantly identify affected products.

Secure by design means integrating security considerations throughout the entire development lifecycle rather than adding security as an afterthought. This includes threat modeling during design, secure coding practices, security testing, vulnerability scanning, and default secure configurations. Products should ship with strong security out of the box, not require users to configure security manually.

You must define and communicate a support period during which you'll provide security updates. The CRA doesn't specify a minimum duration, but it must be "appropriate to the lifecycle" of the product. For enterprise software, 2-5 years is common. For consumer products, 1-2 years minimum. You must clearly communicate this support period to users and honor your commitment.

A vulnerability disclosure policy documents how security researchers and users can report security vulnerabilities to you, how you'll respond, and what timeline you'll follow for fixes. The CRA requires manufacturers to establish vulnerability disclosure processes and respond to reports appropriately. This typically includes a security contact email, response timeline commitments, and coordinated disclosure practices.

It depends on your product's risk classification. Most standard software products (including WordPress plugins) can use self-assessment and don't require third-party certification. However, critical products classified as Class I or II (identity management systems, network security products, operating systems) require conformity assessment by a notified body. The vast majority of WordPress developers can self-assess.

Once the CRA is in force, compliant products must display CE marking indicating they meet essential requirements. This is similar to CE marking for physical products in the EU. The marking can be physical (on packaging) or digital (displayed in software or documentation). You cannot affix CE marking until you've completed conformity assessment and created your Declaration of Conformity.

You're responsible for vulnerabilities in all components of your product, including third-party libraries and dependencies. Monitor your dependencies for disclosed vulnerabilities using tools like GitHub Dependabot, Snyk, or automated SBOM scanning. When vulnerabilities are discovered, assess impact, update affected components, and release security updates within required timelines. Your SBOM makes this process manageable.

You must report actively exploited vulnerabilities or severe incidents to ENISA (the EU cybersecurity agency) within specific timelines: early warning within 24 hours, detailed report within 72 hours, and final report within 14 days. You must also notify affected users and provide security updates. Establish incident response procedures now so you're prepared when issues arise.

CRA Compliance Suite automates the complex technical tasks required for CRA compliance. We analyze WordPress plugins, themes, and extensions to generate Software Bill of Materials (SBOMs), scan for security vulnerabilities, check dependencies, and create compliance documentation. Our platform turns weeks of manual work into minutes of automated analysis, specifically designed for WordPress developers.

Upload your plugin ZIP file to our platform. We automatically extract and analyze your code, detecting Composer dependencies (composer.json), npm packages (package.json), bundled third-party libraries, WordPress core requirements, and PHP version dependencies. We generate comprehensive SBOMs in both CycloneDX and SPDX formats, complete with version information, licenses, and vulnerability data.

We scan for WordPress-specific vulnerabilities (SQL injection, XSS, CSRF, authentication bypasses) using WordPress coding standards. We also check known vulnerabilities in your dependencies against CVE databases and security advisories. Our analysis includes OWASP Top 10 issues, WordPress plugin security best practices, and common coding errors that lead to security problems.

Yes! Our Pro and Business plans support multiple products. You can create separate projects for each plugin or theme, track them individually, and manage compliance documentation for your entire portfolio. Batch analysis features let you scan multiple plugins simultaneously, perfect for agencies or developers maintaining several products.

Absolutely. We generate EU Declaration of Conformity templates, technical documentation templates, security policy templates, and conformity assessment checklists customized for your products. These templates are based on CRA requirements and industry best practices, saving you dozens of hours creating documentation from scratch.

Free plans include email support and comprehensive documentation. Pro plans add priority support with faster response times. Business and Enterprise plans include dedicated support, compliance consulting, and assistance with complex compliance scenarios. All plans include access to our knowledge base, video tutorials, and compliance guides.

Both formats are acceptable for CRA compliance. SPDX is better if license compliance is your primary concern and you need ISO standard compliance. CycloneDX is better for security and vulnerability management focus with excellent tool integration. We recommend generating both formats (our platform does this automatically) to maximize compatibility with different tools and customer requirements.

Include WordPress core in your SBOM as a framework dependency with the minimum required version. For example, if your plugin requires WordPress 5.9+, document this in your SBOM. Since WordPress is open source and actively maintained, you should also document that security updates come from WordPress.org rather than your organization. Your responsibility is ensuring compatibility with secure WordPress versions.

Bundled libraries (JavaScript files copied directly into your plugin rather than loaded via npm) must be included in your SBOM. Modern SBOM tools can detect many common libraries, but manual verification is important. Document library names, versions, source URLs, and licenses. Our platform automatically detects popular bundled libraries like jQuery plugins, Select2, Chart.js, and others.

Regenerate SBOMs whenever dependencies change: after running composer update or npm update, when adding or removing dependencies, for each new plugin version, and when security updates require dependency changes. Integrate SBOM generation into your build pipeline so it happens automatically with every release. This ensures your SBOMs always match your actual code.

Yes! We provide API access and webhook integrations for automated scanning. You can trigger scans from your CI/CD pipeline (GitHub Actions, GitLab CI, Jenkins, etc.) and receive vulnerability alerts automatically. This lets you catch security issues during development before they reach production. Enterprise plans include advanced automation features and custom integrations.

Document plugin dependencies in your technical documentation and product information. If your plugin requires WooCommerce, Advanced Custom Fields, or other plugins to function, list these as dependencies. While you're not responsible for vulnerabilities in those plugins, you should monitor their security status and inform users if a dependency has known security issues that affect your plugin's functionality.

GPL licensing and CRA compliance are separate concerns. GPL dictates redistribution rights; CRA dictates security requirements. You can have GPL-licensed code that's fully CRA compliant. In fact, GPL's source code requirement aligns well with CRA transparency obligations. Include license information in your SBOM and ensure GPL compliance alongside CRA compliance—both are important, and both are achievable.