On 11 September 2026, the first enforceable obligations of the EU Cyber Resilience Act (CRA) take effect. If you sell a WordPress plugin — or give one away while earning money from it in any way — and a single one of your users is in the EU, this applies to you. This guide is the plain-English version: what actually changes on that date, who is genuinely in scope, and the five concrete things to put in place this week.
Table of Contents
- What changes on 11 September 2026 (and what doesn't)
- Am I actually in scope?
- The 24-hour reporting rule, explained
- Five things to put in place this week
- Drop-in SECURITY.md and security.txt templates
- What happens on 11 December 2027
- FAQ
What changes on 11 September 2026 (and what doesn't)
The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024, but its obligations arrive in two waves:
- 11 September 2026 — the reporting obligations of Article 14 take effect. Manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware of them, with a fuller notification within 72 hours. The same timelines apply to severe security incidents affecting the product.
- 11 December 2027 — everything else: the full Annex I essential security requirements, CE marking, the EU Declaration of Conformity, and the formal SBOM obligation.
So the September deadline is narrower than most of the panic suggests. You do not need CE marking next month. What you need is a working vulnerability handling process — because from 11 September, "I didn't know" stops being a defence the moment a researcher emails you about an exploit being used in the wild. (For the full background on the regulation, see our complete CRA compliance guide.)
That said, the smart move is to treat September 2026 as the real deadline. The processes you need for the reporting obligation (a disclosure channel, internal triage, patch-and-tag releases) are the same ones the 2027 requirements build on.
Am I actually in scope?
The CRA regulates products "made available on the market" in a commercial context. For WordPress plugin developers, work through this list:
- You sell a plugin or theme (own site, CodeCanyon, freemium with a paid tier) → in scope. You're a "manufacturer" under the CRA.
- Your plugin is free, but you earn revenue connected to it — paid support, hosting bundles, a SaaS that the plugin connects to, agency work that ships it → in scope. "Free of charge" doesn't take you out of scope; "non-commercial" does, and monetisation of any kind makes it commercial.
- Your plugin is genuinely non-commercial — no paid tier, no donations tied to features, no business behind it → the CRA's open-source carve-outs likely apply to you. Note that even then, a company using your plugin commercially has its own obligations, and the 2027 rules introduce the "open-source steward" concept for foundations and registries.
- You're an agency building sites for clients → you're on the manufacturer/importer spectrum for the products you ship and operate. You need per-plugin evidence: what you installed, its security state, and a disclosure route. (This is exactly what our agency fleet dashboard tracks.)
One persistent myth: being outside the EU doesn't exempt you. If your product is available on the EU market — and a downloadable plugin is, by definition, available everywhere — you're in scope. Penalties run to €15 million or 2.5% of global turnover, whichever is higher, and market surveillance authorities can have non-compliant products withdrawn from the EU market.
The 24-hour reporting rule, explained
From 11 September 2026, when you become aware that a vulnerability in your product is being actively exploited, the clock starts:
- Within 24 hours — an early warning to ENISA via the single reporting platform, flagging the vulnerability and the exploitation. This is deliberately light: it's an alert, not a post-mortem.
- Within 72 hours — a fuller notification: severity, impact, indicators of compromise, and what you're doing about it.
- After remediation — a final report once a fix is available.
Two things matter here for plugin developers specifically.
First, "becoming aware" is doing a lot of work. If a researcher reports exploitation to you, or it appears on Wordfence or WPScan, you are aware. You can't unknow it. Which means you need a channel through which reports actually reach you — which brings us to the VDP.
Second, the reporting obligation sits on top of the CRA's vulnerability handling requirements (Annex I, Part 2): you must have a coordinated vulnerability disclosure policy, you must handle reports, and you must distribute security fixes "without delay" and — ideally — separately from feature releases with clear changelog tagging. All of this needs to exist before the deadline, because it's the machinery that makes 24-hour reporting possible at all.
Five things to put in place this week
None of this requires a lawyer or a consultant. A focused afternoon gets you most of the way:
1. Publish a vulnerability disclosure channel. A SECURITY.md in your repo root and a security.txt at /.well-known/security.txt on your site, each with a monitored contact. This is the single most-checked item — and the one most plugins fail. Our audits check for it automatically in every scan.
2. Set up a monitored security inbox. security@yourdomain.com, read daily, with an acknowledgement target (48–72 hours is the norm). A disclosure channel that nobody reads is worse than none.
3. Write down your triage process. Half a page: how you assess severity, who decides, how fast you patch, when you credit reporters. The CRA wants evidence of a process, not perfection.
4. Adopt security-tagged releases. Security fixes go out separately from feature releases, flagged clearly in the changelog (e.g. = 1.4.2 = * Security: Fixed SQL injection in export handler). Bundling a fix silently into a feature release is exactly what the CRA's update obligations target.
5. Generate an SBOM for your plugin. A machine-readable inventory of your Composer packages, npm dependencies and bundled libraries. It's formally required in 2027, but when a supply-chain CVE drops you'll need it to answer "am I affected?" inside the 24-hour window — so build it now. Every WP HealthKit audit generates a CycloneDX SBOM from your plugin ZIP, free.
If you want the done-for-you route, the CRA Readiness bundle produces the audit, SBOM, OpenVEX document and drop-in SECURITY.md/VDP templates from one ZIP upload.
Drop-in SECURITY.md and security.txt templates
SECURITY.md (repo root):
# Security Policy
## Supported Versions
| Version | Supported |
| ------- | --------- |
| 2.x | Yes |
| < 2.0 | No |
## Reporting a Vulnerability
Please report vulnerabilities privately to **security@example.com**.
- We acknowledge reports within 72 hours.
- We aim to release a fix within 14 days for critical issues.
- We follow coordinated disclosure: we will agree a public
disclosure date with you after a fix is available.
- Please do not open public issues for security reports.
/.well-known/security.txt (your website):
Contact: mailto:security@example.com
Expires: 2027-08-31T00:00:00Z
Preferred-Languages: en
Policy: https://example.com/security-policy
The Expires field is mandatory and must be in the future — a stale security.txt is treated as absent.
What happens on 11 December 2027
The second wave is the big one, and it's why starting now pays off:
- Annex I essential security requirements — products must ship secure-by-default, with no known exploitable vulnerabilities at release. A documented security assessment per release becomes table stakes.
- SBOM obligation — you must maintain a component inventory and provide it to market surveillance authorities on request.
- CE marking and EU Declaration of Conformity — manufacturers self-declare conformity (plugins sit in the default, non-critical category, so self-assessment applies rather than third-party certification).
- Support period — security updates for the expected product lifetime, minimum five years in most cases.
Every one of those is a process you should be running in 2026 to be credible in 2027.
FAQ
Does the CRA apply to my free wp.org plugin? If it's genuinely non-commercial — no paid tier, no upsell, no business behind it — the open-source carve-outs likely apply. The moment any revenue is connected to it, you're in scope.
I'm a solo developer. Is this really enforceable against me? The obligation scales with the law, not with your headcount. Enforcement against solo developers is likely to be complaint- or incident-driven — which is precisely why having the basics (VDP, security-tagged releases, an SBOM) is the rational response. The basics are cheap.
Does my agency have obligations even if we didn't write the plugins we install? Yes, for the products you customise, ship and operate. You need a per-plugin security posture and a disclosure route for each client fleet.
What's the fastest way to check where I stand? Run your plugin ZIP through a free WP HealthKit audit — the CRA scanner checks your SECURITY.md/VDP contact, changelog security tagging and component inventory in about a minute, and the report doubles as your risk assessment artefact. For the compliance paperwork itself, the CRA Readiness bundle generates the SBOM, OpenVEX and templates in one pass.
Where's the official text? Regulation (EU) 2024/2847 on EUR-Lex. Article 14 covers the September 2026 reporting obligations; Annex I covers the 2027 essential requirements.
This guide is maintained by the WP HealthKit team and reflects our reading of the CRA as of August 2026. It is not legal advice — for a formal position on your specific situation, talk to a lawyer who knows EU product regulation.