Key takeaways
- Regulation (EU) 2024/2835 is the binding final text; rebuild your compliance checklist from it, not from proposal-era summaries.
- Charging for a WordPress plugin, Laravel app, or Shopware extension makes you a manufacturer under the CRA, with SBOM, Annex I, and Article 14 duties.
- Article 14 reporting starts 11 September 2026: 24-hour notification to ENISA for actively exploited vulnerabilities, with full obligations applying 11 December 2027.
- A composer.lock or package-lock.json is raw SBOM data, not an SBOM; convert it to CycloneDX with a serial and timestamp, regenerated on every release.
- Free open-source software you publish without monetising carries lighter steward duties, judged per product rather than per company.
The cyber resilience act final text, published as Regulation (EU) 2024/2835 in the Official Journal, binds you as a manufacturer with the same core duties as large vendors: a SBOM, coordinated vulnerability handling, 24-hour actively exploited vulnerability reporting under Article 14, and a stated support period. This walkthrough quotes each article's operative wording and maps it to concrete actions for a Laravel app, WordPress plugin, or Shopware extension.
What changed between the cyber resilience act proposal and the final text?
The 2022 proposal became Regulation (EU) 2024/2835, published in the Official Journal in November 2024. If your notes still cite the proposal, they are out of date on article numbers, dates, and scope. The final published text on EUR-Lex is the version that binds you.
Timeline: proposal to final text
The Commission proposal came in September 2022. Political agreement followed in 2024, and the regulation entered into force shortly after publication, with the main obligations phasing in through 2026 and 2027. Reporting duties under Article 14 start earlier than the full conformity requirements, so your earliest deadline is not your last one.
What the final text tightened or dropped
The final text narrowed some scope, clarified the treatment of open-source stewards separately from manufacturers, and set concrete timelines the proposal left vague. The practical takeaway for a five-person team: rebuild your checklist from the final articles, not proposal-era summaries. When a flagged CVE like CVE-2026-114572 lands in your dependency tree, the deadlines you are working against come from the adopted text, not the draft.
Which cyber resilience act requirements apply to which product classes?
The final regulation sorts products into two classes. Most products fall under the default class in Annex I, part I. A smaller set, listed in Annex I, part II, is classed as important and faces stricter third-party assessment. Installable PHP products almost always land in the default class.
Default class: most PHP products
A Laravel app, a paid WordPress plugin, or a Shopware extension sold to EU customers sits in the default class. You self-assess: run the Annex I essential requirements, keep technical documentation, and handle vulnerabilities per Article 14. No notified body is involved.
When software counts as important
Annex I, part II covers products with higher risk profiles, such as software managing network functions or privileged access. A typical CRUD application or plugin does not qualify. If you sell tooling that manages firewalls, hypervisors, or identity infrastructure, check part II before assuming self-assessment.
Annex I and Annex II in practice
| Annex | What it holds | Your action |
|---|---|---|
| Annex I, part I | Default-class products | Self-assessment, documentation, SBOM |
| Annex I, part II | Important-class products | Conformity assessment by third party |
| Annex II | CE declaration content | Draft your declaration of conformity |
When a CVE hits a dependency, class does not change your reporting duty. See how a real advisory plays out at https://patchclock.com/security-digest/advisories/cve-2026-114554.
What does the final text say about SBOM obligations?
The exact wording and where it sits
Annex I of the final regulation requires manufacturers of products with digital elements to identify and document components, including a software bill of materials in a machine-readable format covering at least the top-level dependencies. The European Commission's CRA page confirms the text is published and the main obligations phase in through 2027. If you ship a Laravel app or WordPress plugin, you are documenting what your product is built from.
CycloneDX from your lockfiles
Your composer.lock and package-lock.json already contain almost everything an SBOM needs: exact package versions, hashes, and dependency trees. The work is converting them into CycloneDX, the format most EU buyers and reviewers expect, and keeping that conversion automatic so it never drifts from what you actually ship. A tool that regenerates the SBOM on every release beats a hand-maintained spreadsheet every time. A composer.lock-based SBOM must record, per dependency, the package name, the exact resolved version, the source or dist URL, and the content hash, then declare the format as CycloneDX with a unique serial and timestamp so a reviewer can tell a fresh export from a stale one. Direct dependencies alone do not satisfy the Annex I wording: transitive packages in your lockfile are components of your product too. Anything you patch or vendor manually, such as a forked plugin file, must appear as a component with a version, or your SBOM is incomplete in the exact way an auditor checks for first.
What a reviewer will actually check
Three things: does the SBOM exist and parse, does it match the shipped versions, and do known CVEs in those components have a documented response. A stale SBOM listing versions you no longer ship fails the second check, which is why automation matters. When a CVE lands in a package you use, you need a written position on whether it affects you; see our advisory on CVE-2026-104827 for the format we use.
How does the CRA treat open-source software stewards and manufacturers?
Steward duties under the final text
The final text defines "open-source software steward" for entities that develop open-source software on a non-commercial basis, make it available to the public, or maintain it, without monetising it. Stewards carry lighter duties: they must keep their contact details current, follow a vulnerability disclosure policy, and cooperate with manufacturers whose products rely on their code. No SBOM, no support-period commitment, no Annex I essential requirements.
Why paid PHP extensions make you a manufacturer
Charging for a WordPress plugin or Shopware extension is monetisation. Place it on the EU market with commercial intent and you are a manufacturer under Article 3(1), with every obligation that follows: SBOM, secure development per Annex I, vulnerability handling, and Article 14 reporting. The steward role is not a discount tier for you.
Free open-source software you merely publish
If you publish a free Laravel package and someone else bundles it into a paid product, you may sit in steward territory. The boundary is who places the product with a digital element on the market and who profits. Track your own role per product, not per company. PatchClock's own sizing assumes you are a manufacturer for anything you sell; where that judgement is close, document the reasoning, and keep your data handling defensible (see https://patchclock.com/privacy).
What is the current cyber resilience act status and key compliance timeline?
The final text entered into force on 10 December 2024. Most obligations apply from 11 December 2027, but the reporting duties in Article 14 start earlier: actively exploited vulnerabilities and severe incidents must be reported within 24 hours from 11 September 2026, when the main parts of the regulation become binding.
Dates that matter for a small vendor
- 10 December 2024: entry into force.
- 11 September 2026: reporting obligations and the supporting provisions apply.
- 11 December 2027: full application, including SBOM and secure-by-default requirements.
What is already binding
Nothing substantive yet. The 2026 deadline is the first real test, and ENISA's reporting guidance (reporting channels and Article 14 mechanics) is the reference for how notifications actually get filed. If a CVE like CVE-2026-107255 lands in one of your dependencies after September 2026, the clock starts immediately.
How do Article 14 reporting duties fit into the final text?
Article 14 of the final regulation sets two reporting tracks for manufacturers, and both apply to your Laravel app or paid plugin the same way they apply to a large vendor's product.
24-hour and 72-hour clocks
If you become aware of an actively exploited vulnerability in your product, you must notify ENISA within 24 hours. A severe incident having an impact on security gets an early warning within 24 hours and a notification within 72 hours. These clocks start when you have sufficient information to assess the event, not when you first hear a rumour.
ENISA vs market surveillance reporting
The same notifications go to the market surveillance authorities of the member states where your product is sold. If the vulnerability affects products you ship into several member states, one ENISA report plus member state reports covers the duty.
What counts as actively exploited
The final text defines actively exploited as a vulnerability for which effective exploit code exists, or for which there is evidence of malicious use. Track your CVE feed and your composer.lock and package-lock.json dependencies against that definition, not against vendor silence.
How can vendors verify their products fall within CRA scope?
Start with the final text's definitions. Your product is a "product with digital elements" if it is a standalone or combined hardware/software product whose intended use involves direct data processing. An installable Laravel app, a paid WordPress plugin, or a Shopware extension that processes customer data qualifies. "Placing on the market" covers any commercial supply in the EU, including subscriptions and downloads.
The definitions that decide it
Three questions settle most cases: do you sell it (even for €9), does it process data, and does it ship with digital elements? If yes to all three, you are a manufacturer under the CRA and carry the full obligation set.
Edge cases: self-hosted apps and marketplace plugins
Self-hosted installs still count; hosting location is irrelevant. Marketplace-distributed plugins are squarely in scope, since the CRA reaches software placed on the market through intermediaries. Free open-source software outside a commercial activity falls under steward rules instead, which carry lighter duties. Document your SBOM in a standard format such as CycloneDX (specification) so scope decisions stay auditable.
Which obligations should a five-person team fix first?
A short list of things to keep true
Rank by risk, not by article order. First: know what your products contain, meaning a current SBOM in CycloneDX generated from composer.lock or package-lock.json. Second: a published security.txt and disclosure policy, because Article 14's 24-hour reporting clock has no mercy for teams still deciding who reads the inbox. Third: a declared support period per product. Fourth: a working process for actively exploited vulnerabilities, so you can patch and ship inside a week. Everything else can wait until these four stay true continuously, not just on audit day.
Where PatchClock fits, and where it falls short
PatchClock turns those four into checks that run automatically and flag when one slips, sized for the founding tier of 3 products and 5 people. It does not write your SBOM for you, does not assess vulnerabilities in your own code, and does not replace the technical documentation Annex II requires. If you ship a Laravel app with custom business logic, that logic is your job.
ConformOps, ZeroRisk, Venvera and consultancies compared on the same criteria
ConformOps (conformops.eu), ZeroRisk (zerorisk.com) and Venvera (venvera.com) are direct CRA-readiness tools; OCCTET (occtet.eu) is adjacent; consultancies advise on notified-body routes. Judge all of them, PatchClock included, on the same criteria: does it keep the SBOM current, does it shorten your 24-hour response, does it fit a team of five without a hire. Where PatchClock cannot answer yes, the honest answer above is your buying guide.
FAQ
Does the CRA apply to free plugins I publish without charging for them?
If you publish free open-source software without monetising it, you fall under the lighter "open-source software steward" duties: current contact details, a vulnerability disclosure policy, and cooperation with manufacturers who bundle your code. Charging for a plugin, even a small amount, makes you a manufacturer with the full obligation set. Judge your role per product, not per company.
Do I need a CE mark or a logo on my software under the cyber resilience act?
Yes. As a manufacturer placing a product with digital elements on the EU market, you must affix the CE marking once your product conforms, and draft the declaration of conformity whose content Annex II specifies. For default-class software like a paid plugin or Laravel app, self-assessment supports the marking; no notified body is involved unless your product is important-class.
What happens if I miss the September 2026 reporting deadline?
Article 14 requires notification to ENISA within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, and to market surveillance authorities in member states where you sell. Missing the deadline is non-compliance with a binding obligation from 11 September 2026, exposing you to enforcement. The clocks start when you have sufficient information to assess, so prepare the process now.
Is a composer.lock file enough to satisfy the SBOM requirement?
Not directly. Annex I requires a software bill of materials in a machine-readable format, and your lockfile holds the raw data: exact versions, hashes, and the full transitive dependency tree. The work is converting it into CycloneDX with a unique serial and timestamp, regenerated automatically on every release. A stale export or a hand-maintained spreadsheet fails the reviewer's check.
Who enforces the CRA against a vendor outside the EU?
Market surveillance authorities of the member states where your product is placed on the EU market enforce the regulation, regardless of where you are based. Selling downloads, subscriptions, or plugins into the EU is placing on the market, so a US or UK vendor carries the same duties: SBOM, vulnerability handling, and Article 14 reporting, with enforcement happening in member states.