Every document we generate is traceable to the clause it satisfies.

Most CRA compliance content on the internet paraphrases the law. We work the other way around: each artifact CRA Label produces is built from the text of Regulation (EU) 2024/2847 and cites the exact article or annex point it addresses — in the document itself, so it holds up if a market-surveillance authority ever asks.

One honest fact before the table: under the CRA, most small manufacturers self-assess (internal control, Module A — Art. 32, Annex VIII). No authority pre-approves your paperwork, and the Commission has not yet fixed an official SBOM format (the Art. 13(24) implementing act is not adopted as of mid-2026). That is why we generate both CycloneDX and SPDX, validate against both official schemas, and regenerate free of charge when the format is fixed. Anyone promising "certified CRA compliance" today is selling something that does not exist.

CRA Label artifact	What the regulation requires	Where
SBOM (CycloneDX + SPDX, signed, plus human-readable report)	Identify and document vulnerabilities and components, "including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies". Included in technical documentation; produced to authorities on reasoned request — publication to users is not required.	Annex I Part II (1) Annex VII (2), (8) Recital 77
Format-proofing	The Commission may fix the SBOM format and elements by implementing act — not yet adopted. We emit both candidate formats and re-generate free when it lands.	Art. 13(24)
Technical documentation file	General product description and intended purpose; design, development and vulnerability-handling documentation; cybersecurity risk assessment; support-period rationale; standards applied (or alternatives adopted); test reports; copy of the declaration of conformity.	Art. 31 Annex VII (1)–(7)
Support-period statement	"The support period shall be at least five years", or the expected use time if shorter; the reasoning behind the chosen period goes into the technical documentation.	Art. 13(8) Annex VII (4)
Vulnerability-handling process checklist	Address vulnerabilities and provide security updates; a coordinated vulnerability disclosure policy; a public contact address for vulnerability reports; secure update distribution; security patches "without delay and free of charge".	Annex I Part II (2), (5), (6), (7), (8)
Product classification & conformity route	Which conformity assessment procedure applies: self-assessment by default; Class I important products may self-assess by applying harmonised standards; Class II and critical products need third-party routes.	Art. 32 Annexes III, IV, VIII
Article 14 incident workflow (guided drafts + deadline clocks)	For actively exploited vulnerabilities and severe incidents: early warning within 24 hours of awareness, fuller notification within 72 hours, final report within 14 days (vulnerabilities) or 1 month (incidents) — submitted via the Single Reporting Platform. Draft fields mirror ENISA's published reporting template.	Art. 14(1)–(5) Art. 16
EU Declaration of Conformity draft roadmap	The declaration whose copy belongs in the technical documentation, per the official structure; CE marking follows its own rules.	Art. 28, Annex V Arts. 29–30
Signed evidence (ML-DSA, FIPS 204)	Beyond the regulation. Documentation must remain at authorities' disposal for at least 10 years or the support period, whichever is longer — post-quantum signatures make your evidence tamper-evident across that entire horizon.	supports Art. 13(13)

Citations verified against the regulation text; sources: EUR-Lex — Regulation (EU) 2024/2847 · European Commission — CRA summary · ENISA — Single Reporting Platform.

← Back to CRA Label