Device makers

EU Cyber Resilience Act paperwork for a small device maker

You build a connected device and you are not a compliance team. The Cyber Resilience Act now asks you for a list of the software inside the product, a way to hear about security flaws, a risk assessment, a technical file, and a declaration you sign. Nobody has told you which of these is the real work and which is a form.

Some of it already applies. Since 11 September 2026, if a flaw in your product is being actively exploited or a severe incident hits its security, you have 24 hours from becoming aware to warn the authorities (Article 14). Most of the rest applies from 11 December 2027. You want to know what to do first, in plain English, without hiring a consultant to read the Regulation for you.

Check an SBOM, free

The eight duties the CRA puts on a device maker

The asks more of a maker than this (the CE mark, for one). These eight are the paperwork Declarable is built around.

The eight duties, where each comes from in the Regulation, and what Declarable does about it
Duty	Where it comes from	What Declarable does
Component list (SBOM) — every piece of software inside your product, listed in a format machines can read		Reads the SBOM your build writes, adds the identifiers vulnerability databases need, flags binary blobs (closed-source binaries) and the subsystems it leaves out, and writes a CycloneDX 1.6 file.
Vulnerability handling — finding, fixing and telling people about security flaws for as long as you support the product		Checks your components against public vulnerability databases, re-checks every day the release you ship now and the older releases you still support, emails you what is new, and records for each finding whether it affects your product. A disclosure policy and security.txt generator is free.
Reporting to ENISA — telling ENISA, the EU Agency for Cybersecurity, about an exploited flaw or a severe incident, in three steps		Times the 24-hour, 72-hour and final-report deadlines from the moment you became aware, drafts the text for each stage and reminds you before each falls due. It does not file for you: you submit on the ENISA platform yourself.
Risk assessment — working out which cybersecurity risks your product faces and letting that shape how you build it

The dates

11 September 2026: applies.
11 December 2027: the rest of the Regulation applies, including the technical file and the declaration of conformity for products placed on the EU market.

Source: Regulation (EU) 2024/2847 (Cyber Resilience Act), as recorded in legal state 2026.10.13-1.

What Declarable does about it

Reads the SBOM your build writes, adds the identifiers vulnerability databases match on and tells you what is missing.
Asks the scope questions that point to the assessment route your product is likely to need.
Counts the 24-hour, 72-hour and final-report deadlines from the moment you became aware.
Drafts the CRA section of the declaration of conformity you already sign.
Prepares a disclosure policy and a security.txt file for you to review and publish.
Prepares drafts of the risk assessment, the technical file and the user information from your product record.

What it does not do

It does not judge whether your product meets the Regulation. Nobody at Declarable assesses or signs off your product.
It does not give legal advice. For a legal question, ask a lawyer.
It does not replace an outside assessment body where your product needs one.
It does not file reports for you. You submit them yourself on the ENISA platform.

Questions

Does the Cyber Resilience Act apply to my device?: It covers products with digital elements that connect to a device or network and are sold in the EU, with some exclusions (Article 2). The scope check asks the questions that decide it. It is a pointer, not a ruling.
What do I have to do first?: Reporting an actively exploited vulnerability or a severe incident has applied since 11 September 2026 (Article 14), so know who in your team would start the 24-hour clock. After that, a clean SBOM is the base for most of the other documents.
Do I need an outside assessment body?: Most products can use self-assessment. Products on the higher-risk lists in Annexes III and IV need more (Article 32). The scope check names the route your product is likely to need.
Are my files kept?: The free tools read your files in your browser. When you ask for a vulnerability check, only component identifiers are sent, not the files.

Check an SBOM, free

What Declarable is, and what it is not

A documentation aid. Declarable prepares drafts and checklists for you to review and edit.
Not legal advice. For a legal question about your product, ask a lawyer.
Not certification. Nobody at Declarable assesses or signs off your product. You sign your own declaration of conformity.
Not an assessment body. Some products need an outside assessment body: an An important product, class I. Self-assessment (module A) is open only if its maker applies in full a harmonised standard, a common specification or a European cybersecurity certification scheme at assurance level “substantial” or higher; otherwise a notified body takes part: modules B and C, or module H (Article 32(2)). Open-source software whose technical documentation is public may self-assess (Article 32(5)). product unless its maker fully applies a harmonised standard or one of the alternatives in Article 32(2), and those on the CRA's Annex III class II and Annex IV lists — the higher-risk product categories, where self-assessment is not enough. Declarable is not one. The scope check asks the questions that point to your category.
Not a filing agent. Declarable does not file reports for you. You submit them yourself on the ENISA platform.

Source for the assessment lists and when an outside body is needed: Annexes III and IV and Article 32 of Regulation (EU) 2024/2847 (Cyber Resilience Act), as recorded in legal state 2026.10.13-1.

EU Cyber Resilience Act paperwork for a small device maker

Duty

Where it comes from

What Declarable does

Component list (SBOM) — every piece of software inside your product, listed in a format machines can read

Reads the SBOM your build writes, adds the identifiers vulnerability databases need, flags binary blobs (closed-source binaries) and the subsystems it leaves out, and writes a CycloneDX 1.6 file.

Vulnerability handling — finding, fixing and telling people about security flaws for as long as you support the product

Checks your components against public vulnerability databases, re-checks every day the release you ship now and the older releases you still support, emails you what is new, and records for each finding whether it affects your product. A disclosure policy and security.txt generator is free.

Reporting to ENISA — telling ENISA, the EU Agency for Cybersecurity, about an exploited flaw or a severe incident, in three steps

Times the 24-hour, 72-hour and final-report deadlines from the moment you became aware, drafts the text for each stage and reminds you before each falls due. It does not file for you: you submit on the ENISA platform yourself.

Risk assessment — working out which cybersecurity risks your product faces and letting that shape how you build it