The WordPress Plugin Developer's EU CRA Readiness Checklist: What You Need to Do Before 2027

If you sell a WordPress plugin with a pro tier, offer paid support, or monetize in any way, the EU Cyber Resilience Act (CRA) applies to you. The first compliance deadline is September 11, 2026 — roughly six months from now. The full requirements land December 11, 2027.

Most solo plugin developers don't know this yet. When Patchstack attempted responsible disclosure across 1,571 plugins in late 2024, they couldn't even reach 1,162 of the developers. Over 900 never responded at all. That's the ecosystem the CRA is about to land on.

This post breaks down exactly what the CRA requires, which plugins are in scope, and the specific AI-powered tools that make compliance manageable for a one-person operation.

Is Your Plugin In Scope?

The CRA applies to "products with digital elements" placed on the European market with any commercial activity. The trigger is broader than direct sales:

Your Situation	In Scope?
Free plugin, no pro version, no ads, no company	Likely exempt
Free plugin with a paid "Pro" version	Yes
Free plugin with paid support/consulting	Yes
Free plugin maintained by a company	Yes
Free plugin that collects data or shows ads	Yes
Truly non-monetized, individual maintainer	Likely exempt

There is no active-users threshold. A plugin with 50 installs and a $29/year pro license faces the same obligations as WooCommerce. The determining factor is commercial activity, not popularity.

If you're unsure, the OpenSSF published a brief guide for OSS developers in July 2025 that clarifies the exemption boundaries. The EU's own open source guidance is the authoritative source.

What the CRA Actually Requires

The obligations fall into four categories. All apply to commercially active plugins targeting EU users.

1. Security by Design

• Ship with no known exploitable vulnerabilities
• Secure defaults at installation (no admin/admin, no debug mode left on)
• Documented cybersecurity risk assessment
• Minimized attack surface

2. Vulnerability Reporting (Starting September 2026)

When you become aware of an actively exploited vulnerability in your plugin:

• Within 24 hours: File an early warning via ENISA's Single Reporting Platform (SRP) to your national CSIRT
• Within 72 hours: Submit a complete notification with full details
• Within 14 days of patch: Submit a final report

This clock only starts when exploitation is confirmed in the wild, not when a researcher privately reports a bug to you.

3. SBOM (Software Bill of Materials)

• Machine-readable format — CycloneDX or SPDX
• Cover at minimum all top-level dependencies (your composer.json / package.json)
• Not required to be public, but must be available to market surveillance authorities
• Retain for 10 years after product withdrawal

4. Documentation and CE Marking

• Declaration of Conformity (DoC) for each major version
• Published end-of-support date (something almost no plugin dev currently does)
• Security updates must be free and separable from feature updates
• CE marking confirming conformity (for software, this lives in your DoC and product description)

AI Tools That Make This Manageable

The good news: every technically difficult requirement has AI-powered tooling that handles the heavy lifting. Here's the stack a solo developer actually needs.

The Checklist

Before September 11, 2026 (Reporting Deadline)

• Determine if your plugin has any commercial activity (pro version, support contracts, ads, company involvement)
• If exempt, document why in writing — you may need to demonstrate this
• Enroll in Patchstack's free managed VDP or establish your own formal disclosure process
• Add a SECURITY.md to your plugin repo with reporting channel, expected response time, and disclosure timeline
• Add a security contact to your WordPress.org plugin readme
• Register on ENISA's Single Reporting Platform
• Write a one-page internal response process: what happens when someone reports a vulnerability?
• Define what "active exploitation" means for your context so you know when the 24-hour clock starts

Before December 11, 2027 (Full Compliance)

• Set up automated SBOM generation in your build process (Snyk CLI or CycloneDX)
• Generate an SBOM for your current plugin version and store it versioned
• Integrate Snyk Code or Semgrep for static analysis in your workflow
• Write a cybersecurity risk assessment (1-2 pages: attack surface, data handled, auth requirements)
• Publish a formal end-of-support date in your readme
• Confirm your plugin supports WordPress's native auto-update mechanism
• Prepare a Declaration of Conformity for each major version
• Verify your plugin falls in the "default category" (self-assessment sufficient) or check if it's Class I Important
• Set up 10-year documentation retention (a versioned Git repo plus cloud backup covers this)
• Ensure security updates can be released separately from feature updates

The Three Things to Do This Week

If you can only do three things before September 2026:

1. Determine your scope. Is your plugin commercially active? If yes, you're in the CRA. If truly non-monetized, document your exemption basis.
2. Get a formal VDP. Enroll in Patchstack's free managed VDP. This covers the single hardest obligation — handling inbound vulnerability reports professionally — without building custom infrastructure.
3. Register on ENISA's SRP. So you can actually file the 24h/72h reports if an actively exploited vulnerability hits your plugin. Don't wait until you're under a 24-hour deadline to figure out the filing process.

The Unresolved Problem: Reaching Your Users

One CRA requirement has no clean solution yet: notifying users when a vulnerability is being actively exploited. Most plugin developers distributing through WordPress.org have no direct relationship with their users. You can't identify who installed your plugin. You can't email them a security notice.

The WordPress community, Patchstack, and EU regulators are still working through this tension. For now, the practical approaches are:

• Use WordPress admin notices in your plugin to surface critical security advisories
• Publish advisories on your website and plugin changelog
• Leverage WordPress.org's built-in auto-update system to push patches quickly
• If you have a mailing list for pro users, use it for security communications

This Is GDPR 2.0 — But You Have Better Tools

The community is calling the CRA "GDPR for software." The comparison is apt: widespread initial panic, eventual practical guidance, and ultimately a mixed compliance reality where small developers do what's proportionate.

The difference this time: AI-powered tools make the technically hard parts — SBOM generation, vulnerability scanning, dependency monitoring — nearly automated. What would have required a dedicated security team five years ago now runs as a GitHub Action or a single CLI command.

The CRA isn't going away. The deadlines are real. But the compliance path for a solo developer is surprisingly tractable: enroll in Patchstack's VDP, add Snyk or Semgrep to your build, generate your SBOMs, and document your security posture. That covers 90% of what you need.

Start with the three things. The rest follows naturally.