CRA security update requirements: how long must you support your WordPress plugin?

The security update requirement

Article 13 of the CRA says manufacturers must “ensure that vulnerabilities of the product with digital elements are handled effectively and in accordance with the essential requirements set out in Annex I, Part II.” Part II of Annex I includes a specific obligation: provide security updates for the duration of the support period.

This is not optional. It is not best practice. It is a legal requirement with fines attached. If you place a product on the EU market and a vulnerability is found during the support period, you must patch it and deliver the update to users. Not eventually. The regulation says “without delay.”

Security updates must be:

• Free of charge to users
• Delivered through the same channel the product was distributed (for WordPress plugins, that means the WordPress update mechanism)
• Accompanied by advisory information about the vulnerability and the fix
• Provided in a timely manner once the vulnerability is identified

How long is the support period

The CRA sets a minimum support period of five years from the date the product is placed on the market. However, this five-year floor is not absolute. The regulation says the support period should reflect:

• The expected product lifetime
• Reasonable user expectations
• The nature of the product

For a WordPress plugin that charges an annual licence fee, the “expected product lifetime” is arguably tied to the active subscription period. A user who stops paying has a different expectation than one who continues renewing. But the regulation does not explicitly address subscription models for software. This is one of the areas where enforcement guidance will need to clarify.

The safe interpretation: plan for at least five years of security updates from the date each version is first sold. If your plugin has been on the market since 2025, you should be prepared to provide security patches through at least 2030.

What the five years covers

The support period covers security updates only, not feature development. You are not required to add new features, improve performance, or fix non-security bugs after the support period starts winding down. You are required to patch vulnerabilities and deliver those patches to users.

What counts as a security update

The CRA does not define “security update” with surgical precision, but the context makes the scope clear:

• Patches for known vulnerabilities in your code. Someone reports an XSS, you fix it, you push the update.
• Dependency updates that address security issues. If a library in your composer.json has a published CVE, updating to the patched version counts.
• Configuration changes that mitigate security risks. Tightening default permissions, removing deprecated insecure functions, hardening file access.

What does not count:

• New features marketed as “security improvements”
• Performance optimisations
• WordPress version compatibility updates (unless they fix a security issue)
• UI changes

The line between “security fix” and “general maintenance” is not always obvious. If upgrading to a new WordPress version is required to close a security hole, that counts. If it is just for compatibility, it does not.

What happens at end of life

Every plugin eventually reaches end of life. You stop active development, you move on, the technology changes. Under the CRA, you cannot just remove the plugin from WordPress.org and call it done. You have obligations:

1. Inform users. You must notify users that the product is reaching end of life and that security updates will stop. Give them enough notice to migrate or find alternatives.
2. Continue security updates until the support period ends. End of life announcements do not cut short the support period. If you committed to five years, you provide five years.
3. Make the last version’s source code available. Annex I, Part II requires that when security updates can no longer be provided, the manufacturer should allow users to access the source code for security maintenance purposes, where technically feasible.

For WordPress plugins that are already GPL, the source code requirement is automatically met. Users already have access to the code. But the notification and continued patching obligations still apply.

The solo developer problem

Five years of mandatory security patching is a big commitment for a solo developer. Life happens. You change careers. You lose interest. You get ill. The regulation does not account for the personal circumstances of individual developers.

This is the uncomfortable truth of the CRA for the WordPress ecosystem. A regulation designed for companies with security teams applies equally to a solo developer selling a $29 plugin from their spare bedroom. The obligations are the same. The fines are the same (up to EUR 15 million, though enforcement against solo developers is a different question).

We do not have enforcement precedent yet to know how regulators will handle solo developers who genuinely cannot continue maintaining a plugin. But the regulation is the regulation. If you place a product on the EU market, you accept these obligations.

Practical strategies

Given the reality of the five-year commitment, here is how WordPress developers can plan:

1. Price for sustainability.If you owe five years of security updates, your pricing must fund five years of maintenance. A one-time $29 licence that obligates you to half a decade of patching is a bad deal. Annual licensing (like CRA Guard’s model) aligns revenue with ongoing obligations.
2. Minimise your attack surface. Fewer dependencies means fewer things that can break. A plugin with 50 Composer packages has 50 potential sources of vulnerabilities you need to monitor and patch. Keep dependencies lean.
3. Automate vulnerability monitoring. You cannot manually check the OSV.dev database every week for five years. Automated scanning catches new CVEs in your dependencies and alerts you. This is one area where the cost of tooling pays for itself.
4. Document your support period. State clearly in your plugin documentation, your website, and your Declaration of Conformity how long you will provide security updates. Set expectations with users from day one.
5. Have an exit plan. If you ever need to stop maintaining a plugin, plan for it. Notify users in advance. Transfer maintenance to another developer or open the project to community maintenance. Make the source code easily forkable.
6. Keep your SBOM current. An up-to-date dependency list makes security patching faster. When a CVE drops for a library, you can immediately check if you are affected instead of spending hours auditing your codebase.

Common questions

Does the five-year requirement apply to each version or from the first release?

From the date each version is placed on the market. If you release version 3.0 in January 2028, you owe security updates for that version through at least January 2033. Earlier versions that users are still running have their own support timelines.

Can I limit the support period to paying customers only?

The regulation says security updates must be provided free of charge. If a user purchased your plugin and their licence expired, you still need to make the security update available. Whether you deliver it automatically or require a manual download is a grey area, but withholding it entirely is risky.

What if I sell the plugin to another company?

Obligations transfer to the new owner. If you sell your plugin business, the buyer inherits the support period commitments. Make this explicit in the sale agreement.

What about plugins that are abandoned on WordPress.org?

WordPress.org already closes plugins that have unresolved security issues. Under the CRA, an abandoned plugin with users in the EU creates a liability. If you cannot maintain it, formally end-of-life it with proper notice rather than letting it rot.

Does the five-year requirement start from September 2026?

The full compliance requirements (including the support period obligation) apply from December 2027. Products placed on the market after that date must meet the requirement. For products already on the market, the implementation guidance is still being developed.

Plan your support commitment

CRA Guard helps you track your compliance obligations, including vulnerability monitoring across your dependency tree. Automated weekly scans mean you find new CVEs before they become incidents. That is the foundation of a sustainable five-year support commitment.

Get Early AccessView Pricing Plans

Sources

• Cyber Resilience Act full text (Article 13, Annex I Part II)
• EU Commission: CRA legislative summary
• HeroDevs: EOL dependencies and CRA compliance

Disclaimer: This article is for informational purposes and does not constitute legal advice. The security update requirements described here are based on Regulation (EU) 2024/2847 Article 13 and Annex I, Part II. Consult qualified legal counsel for advice specific to your situation.