Key takeaways
- A CRA support period statement is the manufacturer's public declaration of how long a product will receive security updates, at least five years for most products with digital elements.
- The statement must name a concrete end-of-support date, the free security update commitment, a vulnerability contact channel, and where the SBOM and technical documentation live.
- Publish the statement on a permanent URL on your own domain, kept in sync with your product page, documentation, and security.txt file.
- Never publish an end-of-support date you cannot honour, because shortening a stated support period after the fact is itself a compliance problem.
- When the support period ends, notify users at least 30 days in advance, tag the final release, and update your security.txt so users are never left in silence.
A CRA support period statement is the document where you, as the manufacturer, declare how long you will keep shipping security updates for a product, which for most software means at least five years after sale under the EU Cyber Resilience Act's Article 13(6). It must state that period, the end-of-support date, and where buyers can get updates and vulnerability reports. If you sell a paid WordPress plugin or Laravel app into the EU with no compliance staff, this is one of the few CRA documents you cannot skip, and it is short enough to draft in an afternoon.
What does the statement actually declare?
A CRA support period statement is the public declaration where you, as the manufacturer, state how long your product with digital elements will receive security updates. Under Annex I of the CRA, the support period must cover the expected lifetime of the product and be no shorter than five years, and you must tell users about it before they buy. For a paid WordPress plugin or a self-hosted Laravel app, that means publishing a concrete end-of-support date per product, not a vague "as long as it's viable". Your Article 14 duties, including the 24-hour reporting clock, run for that whole period — see our guide to CRA Article 14 reporting deadlines.
Which CRA articles require a support period statement?
Article 13 information and instructions
Article 13 sets out what manufacturers must tell buyers: the support period, the end date, and how security updates will be handled. The support period statement is where those facts live. If your statement omits the end date, you have not met the information duty.
The support period duty itself
The CRA pairs the statement with real obligations: you must keep shipping security updates for products with digital elements throughout the support period you declare. Annex I's essential requirements expect this to match your risk profile, and the recitals on proportionality let a five-person team scale the depth of work, not skip the duty. Declare what you can actually sustain.
Where the statement must be published
The statement goes on your product page and in the technical documentation, so it must stay in sync with what you ship. For a plugin or Laravel app, that means the README or marketplace listing carries the same dates as your docs. PatchClock checks that the published statement still matches reality; the founding tier covers 3 products and 5 people, see Pricing for CRA compliance software.
What must the statement contain?
The CRA does not publish a fill-in template, but the regulation's support period obligations (Articles 13 and 14) imply six things your statement must state. Here is the breakdown, element by element.
End-of-support date
State the calendar date on which security updates stop for each product. The duration must reflect how long customers can reasonably expect the product to stay secure, and the CRA text on EUR-Lex lets you justify a shorter period based on your size and product risk, so a solo vendor is not held to a big vendor's five-year default.
Security update commitment
Say that you will provide security updates, free of charge, for the full support period, and that updates address vulnerabilities affecting the product's security functions. This is the core of Article 14.
Vulnerability handling contact and disclosure policy
Publish a working contact channel (a security.txt file or a monitored mailbox) and link your coordinated disclosure policy. Article 14's 24-hour early-warning duty for actively exploited vulnerabilities only works if buyers know where to report.
SBOM and technical documentation pointers
State where customers can get the SBOM (CycloneDX generated from composer.lock or package-lock.json is fine) and where the technical documentation lives.
| Element | CRA obligation it maps to |
|---|---|
| End-of-support date | Support period duration (Art. 13) |
| Update commitment | Free security updates (Art. 14) |
| Contact channel | Vulnerability reporting (Art. 14) |
| Disclosure policy | Coordinated disclosure (Art. 14) |
| SBOM pointer | SBOM provision on request (Art. 13) |
Keep each element short enough to verify. PatchClock tracks these as a checklist per product; we write about the mechanics on the PatchClock blog.
How does the support period statement relate to the end-of-support date?
The statement is the promise; the end-of-support date is the point where the promise stops. Your statement says how long you will ship security updates and handle vulnerability reports under Article 14 obligations like the 24-hour ENISA reporting. The date is the timestamp when that duty ends and users stop expecting patches.
The CRA deliberately avoids a fixed number of years. Duration must match the expected lifetime of the product in the way it is used, so a Laravel app with a long installed base needs a longer stated period than a plugin you plan to retire.
Two practical consequences: never publish an end-of-support date you cannot honour, because shortening a stated period is itself a problem; and track the date against your release history. An advisory like CVE-2026-104181 in filament/filament only counts while the period is open.
How do you draft one for a PHP product?
Choosing a duration you can keep
Pick a support period you can honour without a team. The CRA requires support for at least five years for most products with digital elements, per the Commission guidance on CRA obligations. If your Laravel app has shipped updates for two years and you can realistically commit to five, state five. Stating ten to look safe is how you end up legally bound to maintain a plugin you abandoned in year three.
A worked example for a paid WordPress plugin
Draft it as a short document, not a legal essay. One realistic version for a paid WordPress plugin:
Support period statement — MailSync Pro, version 2.x. We will provide security updates for MailSync Pro until 31 December 2031, at least five years from the date this version was placed on the market. Updates are distributed through the WordPress.org plugin repository and our own update server, and are announced on our changelog. Known vulnerabilities in our dependencies, tracked in composer.lock and package-lock.json, are patched within our normal release cycle. After the support period ends, we will publish a notice at this URL at least 30 days in advance, along with the last supported version number. Vulnerability reports are accepted via the security.txt file at the root of this domain.
That statement covers the required elements: the product, the end-of-support date, how updates are delivered, where the end-of-support notice will appear, and a contact channel. Keep it in your repository next to the changelog so the two never drift apart, and note each revision publicly, as we do at PatchClock's changelog.
Where to publish it
Put the statement on a permanent URL linked from your product page, your documentation root, and your security.txt file. WordPress.org plugin pages and Shopware Marketplace listings get reindexed and pruned; your own domain does not. The URL is part of the obligation, so it must survive redesigns and domain moves.
What happens when the support period ends?
When the support period ends, the CRA expects you to say so. You notify users before the date arrives, make clear that security updates will stop, and warn that unpatched vulnerabilities will remain. That last part matters: the duty is not to keep the product safe forever, it is to tell people when it stops being maintained.
The failure mode regulators care about is silence. A plugin that quietly stops receiving releases, with no end-of-support notice and no disclosure policy pointing to its status, leaves users running exploited code with no way to know. The practical cost lands on the customer, who bought a product on the strength of a published commitment and got abandoned without a signal, and on you, because the gap between your statement and your release history is exactly the kind of inconsistency a market surveillance authority can act on. A short notice on your site, a release tagged as final, and an updated security.txt are enough to close the loop honestly.
Common mistakes vendors make in support period statements
The most common failure is a vague duration: "we support this plugin for the foreseeable future" is not an end date, and Article 14 obligations are dated. A close second is an unreachable contact, so a CVE report has nowhere to go when the 24-hour early-warning duty starts ticking.
Third is contradiction: the statement promises three years of security updates, but the changelog shows the last release was 14 months ago. Buyers and ENISA guidance both treat the published statement as a commitment you must keep.
Fourth is copy-paste boilerplate copied from another vendor's page that references support tiers you do not actually offer. Laravel's published support policy works as a precedent because it names concrete versions and dates, which is the level of specificity yours needs.
How do you keep the statement true over time?
A statement is a promise with a date on it. The end-of-support date, the update channel, and the vulnerability handling policy all have to stay true from the day you publish until the day the support period ends. That is a tracking problem, and tracking is where solo teams slip.
What PatchClock checks, and what it does not
PatchClock turns the statement into a short list of things that must remain true: the support end date is still in the future, the security contact from your disclosure policy still answers, and your SBOM (CycloneDX from composer.lock or package-lock.json) is current. When one slips, you get flagged before a customer or ENISA-relevant deadline does.
It does not write the statement for you, decide your support period, or push the patches themselves. Big vendors have dedicated staff for this. Teams of five have a checklist that runs itself, and PatchClock is that checklist for up to 3 products on the founding tier.
FAQ
Do I need a separate support period statement for every plugin version I ship?
No. One statement can cover a product line, like "MailSync Pro, version 2.x", as long as it names the end-of-support date for that scope. If a new major version ships with a different update channel or a different support period, publish a revised statement rather than silently extending the old one.
Can I shorten the support period after publishing it?
Not safely. The published end-of-support date is a commitment, and pulling it forward leaves customers running code they were told would stay patched. If your situation genuinely changes, notify users well in advance, explain why, and expect the change to be visible in your release history. Never publish a date you cannot honour in the first place.
Does the statement need to be in the language of every country I sell to?
The CRA requires that buyers understand the information before purchase, so a statement only in a language your EU customers cannot read defeats the duty. For most solo vendors selling into a few markets, English plus the languages of your main customer bases is a reasonable, proportionate reading of the obligation.
Do free or open-source plugins need a support period statement?
The CRA's manufacturer duties apply to products placed on the market, and free software developed outside a commercial activity is treated differently. But if you monetise a plugin through paid support, a pro version, or a marketplace listing, you are a manufacturer in practice, and the statement duty follows the commercial product, not the licence.
What happens if I stop maintaining a product without publishing an end-of-support notice?
That silence is the failure regulators care about. Users keep running code with no way to know it is unpatched, and your published statement contradicts your changelog. A final release tagged as such, a notice on the permanent statement URL at least 30 days ahead, and an updated security.txt close the loop honestly.