Key takeaways
- Annex IV of the CRA fixes the declaration's contents as a field list: product identifier, manufacturer, applicable legislation, standards used, signature block, and support period.
- The manufacturer, or someone authorised to act on their behalf, must sign the declaration; no consultant or notified body can sign it for you.
- The declaration must be drawn up before the product is placed on the market and kept available for the whole support period, with full obligations applying from December 2027.
- Publish the signed declaration at a stable public URL and update it rather than deleting it when the declaration changes.
- A new major version, variant, or substantial modification requires a new declaration; routine patches and dependency bumps do not.
A CRA declaration of conformity for software is a signed statement that your product meets the Cyber Resilience Act's requirements, drawn up before you ship and kept available for the whole support period. This guide shows you exactly what goes in it, who signs it, and where it lives, with a filled-in template for a self-hosted Laravel app.
What exactly must a CRA declaration of conformity for software contain?
Annex IV of the CRA fixes the contents of the declaration. The official CRA regulation text on EUR-Lex lists the mandatory fields, and they read like a form, not an essay. Miss one field and the declaration is defective, so it is worth going through them line by line.
The field-by-field template
| Field | What goes in it |
|---|---|
| Product name and identifier | Your product name plus a version or build ID that maps to a release |
| Manufacturer name and address | Your legal entity, even if that is you as a sole trader |
| Declaration statement | An explicit statement that the product conforms with the CRA |
| Applicable legislation | The CRA itself, plus any other EU acts you declare against |
| Harmonised standards or specs used | e.g. EN 18031 series references, or "none applied" with your justification |
| Notified body involvement | Only if your product falls under a class requiring third-party assessment |
| Signature block | Name, role, signature, date, and the place of signing |
| Support period | The end date of the security update commitment |
The signature block and support period are the two fields small teams get wrong most often. The support period is a public promise: once you write a date, you have committed to shipping security updates until then.
Worked example: a self-hosted Laravel app
Say you sell a self-hosted Laravel app. Your declaration names "Acme CRM v3.2", lists you as manufacturer in Germany, cites the CRA, notes that you applied no harmonised standards but tested against the essential requirements directly, and sets a support period of 31 December 2029. Attach it to the SBOM generated from your composer.lock so the version identifier is verifiable.
PatchClock keeps this field list as a checklist per product and flags when a field goes stale, for example when a release ships without an updated declaration. The field-by-field template above is also in our guides library.
Who is allowed to sign the declaration of conformity?
The CRA requires the declaration to be signed by the manufacturer, or by someone authorised to act on their behalf. For a solo founder or a small team, that is simply you or a named co-founder with authority over the product. No external body signs it, and no consultant can sign it for you.
The signature carries weight: by signing, you declare the product meets the applicable requirements and you take personal responsibility for keeping that statement true. If it later turns out the product shipped with a known vulnerability you never patched, the signed declaration points back at you.
That is why the signature should sit on top of a short, checked list of facts about your dependencies and support period, not a one-off document. PatchClock is built around exactly that: a founding tier sized for 3 products and up to 5 people (pricing). Big vendors have compliance staff. Teams of five have whoever signs.
When in the product lifecycle must the declaration be drawn up?
Draw it up before you place the product on the market, not after. The declaration is a prerequisite for affixing CE marking, so it must exist at the moment your Laravel app, plugin, or extension first ships to an EU customer. The European Commission's CE marking guidance confirms the declaration must be drawn up before the product is placed on the market and kept available afterwards.
Two dates matter. September 2026 covers reporting duties for actively exploited vulnerabilities under Article 14. December 2027 is when the full obligations, including the declaration of conformity, apply. In practice, draft yours during 2026 so the September deadline does not catch you mid-document.
Treat the declaration as a living check, not a one-time PDF. PatchClock flags when a condition the declaration asserts, like a current support period or a working security contact, has slipped.
Where and how must the declaration be published or made available?
The declaration has to travel with the product. The CRA requires you to keep it with the technical documentation and make it available to market surveillance authorities on request, and for software sold online you should publish it on your website or provide it digitally with the product download. If you sell a Laravel app or a paid plugin, a public URL like example.com/compliance/product-name.pdf is the practical answer, because customers and market surveillance authorities can find it without emailing you, and a procurement team that cannot reach the document in two clicks will treat it as missing. Keep the published copy identical to the signed one, and update the URL rather than deleting it when the declaration changes. A dead link is as bad as a missing declaration once customers start checking, so verify the URL still resolves as part of your release routine.
If you are tracking which products have a live, current declaration, that check belongs in the same routine as the rest of your CRA upkeep. We write about that workflow on the PatchClock blog.
How does the declaration relate to CE marking and technical documentation?
The three artifacts form a chain: the technical documentation proves the product meets the CRA's essential requirements, the declaration of conformity states that this proof exists and identifies the manufacturer, and the CE mark is the visible signal that both are in place. Affixing CE marking without a signed declaration and a documentation file is a false claim, not a shortcut. Under the Commission's CRA timeline, reporting duties start in September 2026 and full application follows in December 2027, so the documentation file needs to exist before the mark does.
The documentation file is where your day-to-day work lives: an SBOM in CycloneDX generated from composer.lock or package-lock.json, your disclosure policy, a security.txt file, records of handled CVEs, and the support period you committed to. The declaration stays short precisely because it points at this file rather than repeating it. Treat the file as the living record and the declaration as its signed summary; when a dependency changes and a new vulnerability is disclosed, update the file first and check whether the declaration's statements still hold true.
What changes to the product require a new or updated declaration?
The declaration covers one product as placed on the market, so anything that changes what that product is triggers a re-issue. A new major version you ship as a separate product, a new edition or variant (different edition of your Shopware extension, a new plugin SKU), or a substantial modification all count. Under the CRA, a substantial modification is one that affects conformity with the applicable essential requirements, and it resets the assessment.
Routine updates within the same product do not: a patch release, a dependency bump in composer.lock, a security fix for an actively exploited vulnerability. Those stay under the existing declaration, provided the support period is still running and the technical documentation is kept current.
The practical trap is shipping a "new version" that is legally a new product. If you rebrand, relicense, or split your Laravel app into a separate offering, draft a new declaration before it ships.
What are the consequences of a missing or incorrect declaration?
Without a declaration of conformity, you cannot legally affix the CE marking, and market surveillance authorities can require you to withdraw the product, recall it, or stop sales in the EU. The CRA ties penalties to the breach: infringements of Article 13 (the declaration requirement) can trigger fines of up to €2,500,000 or 2.5% of global annual turnover, per Regulation (EU) 2024/2847.
The commercial risk lands sooner. An EU customer's procurement check asks for the declaration and the CE mark; a solo vendor who cannot produce either loses the deal before technical evaluation starts. If a CVE is exploited in your installable app and no declaration or support-period commitment exists, the incident becomes evidence of non-compliance, not just a patch you forgot to ship.
How can a five-person team keep the declaration true over time?
A declaration is a snapshot of claims: security updates available during the support period, vulnerabilities handled per Article 14, an SBOM (CycloneDX from your composer.lock) that matches what actually ships. Those claims rot the moment you push a release and nobody re-checks them. The practical fix is turning each claim into a check that runs on every deploy, so a slipped item surfaces as a failed flag rather than a surprise during an audit or a customer question.
PatchClock does this for PHP vendors: it converts CRA duties into a short list of statements, checks them automatically, and flags when one breaks. Its founding tier covers 3 products and 5 people, matching the "big vendors have compliance departments, teams of five don't" reality.
Running the same checklist against PatchClock itself
Honestly: PatchClock checks and flags, but it does not sign the declaration for you, and it does not replace the legal judgment of who signs. Direct alternatives include ConformOps, ZeroRisk, and Venvera; consultancy firms also offer this as a service. Evaluate each on the same criteria: does it watch your actual dependency files, does it cover your support-period commitments, and does it cost less than the hours it saves.
FAQ
Does a paid WordPress plugin or Shopware extension need its own declaration, or one per vendor?
One per product, not per vendor. The declaration names a specific product and version identifier, so each plugin or extension you sell commercially is its own product with its own signed declaration, support period, and published URL. A free hobby plugin with no commercial placing on the market is a different question than a paid SKU.
Is a declaration of conformity required for software that runs only on the customer's own server?
Yes. Self-hosted software is still a product with digital elements, and selling it to an EU customer places it on the market. The worked example in this guide is exactly that case: a self-hosted Laravel app needs a declaration, an SBOM generated from composer.lock, and a support period just like a SaaS offering does.
Can I write the declaration myself or do I need a lawyer or notified body?
You can write and sign it yourself. Annex IV fixes the fields, and for products not in a class requiring third-party assessment, no notified body is involved. A lawyer can review wording, but the signature must come from you or someone authorised to act on your behalf. No consultant may sign it for you.
What happens if I sell into the EU before December 2027 without a declaration?
The declaration obligation applies from December 2027, so selling before then is not yet a breach of that specific duty. The September 2026 reporting duties for actively exploited vulnerabilities arrive first, though. Drafting your declaration during 2026 avoids scrambling when full application hits and customers start asking for it in procurement checks.
Do I need to translate the declaration into every EU language I sell in?
The CRA requires that information, instructions, and safety communications be clear and understandable to users, and individual member states can impose official-language requirements. In practice, many vendors publish one English declaration plus translations for markets that demand them. Check the national rules of each country you sell into rather than assuming one PDF covers all twenty-seven.