Cyber Resilience Act paperwork,
prepared from your SBOM.
Drop the your Zephyr, Yocto or ESP-IDF build already writes. Declarable fixes what vulnerability databases cannot match, watches it between releases, and drafts the technical file and declaration for you to review and sign. A documentation aid, not legal advice.
reporting has applied since 11 September 2026. Everything else applies from 11 December 2027. Your files are read in your browser.
- vulnerability feeds checked
- 5
- SBOM formats read
- 9
- build systems understood
- 8
- to start, no account for the tools
- €0
Fix your SBOM
Handle vulnerabilities
Prepare the documents
What a product looks like inside Declarable.
A release with its findings and gaps, and the Article 14 clock beside it.
Products / demo-sensor-firmware.cdx.json
Demo sensor firmware 1.0.0
4 components| Severity | Vulnerability | Component | Status |
|---|---|---|---|
| Critical | CVE-2022-37434 | zlib@1.2.11 | Not checked yet |
| High | CVE-2018-25032 | zlib@1.2.11 | Not checked yet |
| High | CVE-2024-28960 | mbedtls@2.28.0 | Not checked yet |
- Annex I Part II (1)Some components cannot be looked up
- Annex I Part II (1)Some components have no version
- Annex I Part II (2)Components have high or critical severity vulnerabilities
Prepare your CRA file in three steps.
- Step 1
Upload the SBOM your build writes
Drop the files from west spdx, create-spdx or esp-idf-sbom, or send them from your build pipeline. Zephyr's four documents are merged into one list, and a Yocto archive is read as it is.
- Step 2
Review what needs work, and why
Identifiers are added where the mapping rows know the component. Known vulnerabilities and the gaps against Annex I are listed, each with the article or annex that asks for it.
- Step 3
Export the drafts, review and sign
The technical file and the declaration of conformity start from what the record already knows. Each page carries the template and legal-state version it was prepared under. You review, edit and sign.
Built for small makers, from the build outwards.
Reads what your build already writes
No new tool in your pipeline. The SBOM your build system writes is enough to start, and what it leaves out is named rather than hidden.
Watches every release after you ship
The release you ship now and the older ones you still support are re-checked against new vulnerability records, and you are emailed when something new affects you. Your decisions carry forward.
Documents that carry their legal state
Every draft records the template and legal-state version it was prepared under, so when a standard is finally cited you can see what to revisit.
One record per product, kept for as long as you support it.
A product is a line of releases. Each one keeps its component list, its findings, the decisions you made about them and the documents you prepared. Export the whole record whenever an importer, a distributor or an authority asks for it.
RegulationENISA Single Reporting PlatformCycloneDX 1.6 JSON · SPDX 3.0.1 JSON
Article 14 reporting, made simple.
Since 11 September 2026, an or a severe incident has to be reported to ENISA in three stages: an early warning within 24 hours of you becoming aware, a notification within 72 hours, and a final report after that.
Declarable times all three from the moment you became aware, in UTC and your time zone, and drafts the text for each stage. You submit it yourself on the ENISA platform.
Article 14 reporting workflow: free on every plan, and it stays on if you cancel.
Questions
Asked before people sign up.
Does the Cyber Resilience Act apply to my product?
It covers products with digital elements that can connect to a device or network and are supplied on the EU market in the course of a commercial activity, with some exclusions such as medical devices and vehicles. The scope check asks the questions that sort a product. Its result points to an answer; the decision stays yours.
Is this certification?
No. Declarable prepares drafts for you to review. Nobody at Declarable assesses or signs off your product, and you sign your own declaration of conformity.
Does Declarable file my Article 14 report for me?
No. It times the 24-hour, 72-hour and final-report deadlines and drafts the text for each one. You submit it yourself on the ENISA platform.
Do my files leave my browser?
Your SBOM is read in your browser. Only component identifiers leave it, and only when you ask for a vulnerability check.
What if a standard is not finalised yet?
The legal-state page says what is settled and what is not. The paperwork follows it, so nothing here claims more than the law has actually decided.
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 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.
Ready to check your first SBOM?
The free check runs in your browser and needs no account. A Free plan keeps 1 product and the Article 14 clock. Paid plans start at €49 a month.
Prefer to ask something first? Questions and answers, and how to reach us
Photographs: Unsplash (Unsplash licence). They show hardware and workbenches, not customers.