COMPLIANCE · EU CRA

SBOM evidence for the Cyber Resilience Act, at ingest.

If you place a product with digital elements on the EU market, the CRA makes a machine-readable software bill of materials your obligation — not a nice-to-have. Attestree generates that SBOM, and a signed provenance attestation, automatically the moment each component enters. It won't make you CRA-compliant on its own. It removes the part you'd otherwise reconstruct by hand.

THE CLOCK
11 Sep 2026
Article 14 reporting applies

Manufacturers must report actively exploited vulnerabilities and severe incidents to their CSIRT and ENISA — a 24-hour early warning, 72-hour detail, 14-day final report.

11 Dec 2027
Main obligations apply

The essential requirements take full effect — including the Annex I Part II(1) duty to ship a machine-readable software bill of materials.

EU CRA = Regulation (EU) 2024/2847, in force 10 Dec 2024.

WHAT THE TEXT SAYS

The SBOM requirement, in the CRA's own words.

Manufacturers shall "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies of the product."

— Annex I, Part II(1)

Two words carry the weight: machine-readable rules out a PDF, and at least the top-level dependenciessets a floor, not a ceiling. The Commission points to CycloneDX and SPDX as the formats that qualify. Attestree emits CycloneDX 1.6, generated with Syft at the moment of ingest — not a post-hoc scan reconstructed at audit time.

THE MAPPING

Capability to obligation, with the citation.

Annex I · Part II(1)

CycloneDX 1.6 SBOM, generated at ingest

The CRA asks for "a software bill of materials in a commonly used and machine-readable format covering at least the top-level dependencies." Attestree produces exactly that — CycloneDX, via Syft, the moment each artifact enters — and captures deeper than the top-level minimum.

Article 13 · third-party due diligence

Signed in-toto / SLSA provenance attestation

When you integrate a third-party component, Article 13 expects due diligence on it. Attestree's signed attestation is that diligence, recorded: a verifiable statement of where the component came from, who built it, and that it was not altered before it reached you.

Annex I · Part II(1) — "identify vulnerabilities"

Real sandbox detonation + behavioral record

The same clause asks you to "identify and document vulnerabilities and components." Detonating a package in a controlled VM and recording what it actually does surfaces behavior a manifest scan never would — evidence gathered before the component ships, not after.

Living SBOM

Continuous reconciliation across the fleet

Under the CRA the SBOM is a living document, not a one-time PDF. Attestree's continuous inventory keeps the component picture current as versions change, so the evidence you hand an auditor matches what is actually deployed.

A signed, exportable evidence bundle — the auditor-ready package that bolts the SBOM, attestation and detonation record together — ships today on any deployment with a production signing key. The builder re-verifies every span before sealing a SHA-256 manifest, and itrefuses to build from dev-signed spans — so the free Community Edition, which signs with a local dev-grade key, cannot produce one. That refusal is the point: a bundle you can submit is one the tooling would not fake.

WHAT WE DON'T COVER

The CRA is bigger than an SBOM. We do the SBOM.

The honest scope, because the alternative loses an audit. Attestree automates the component-inventory and provenance evidence. The rest of the CRA programme stays with you or your GRC tooling:

  • The full vulnerability-handling process and coordinated disclosure policy
  • Article 14 incident & vulnerability reporting to your CSIRT and ENISA (the 24h / 72h / 14-day clock)
  • Conformity assessment, the EU declaration of conformity, and CE marking
  • The complete Annex VII technical documentation package
  • Your product-level risk assessment and the Annex I Part I essential requirements
ALSO COVERS · US FEDERAL

One evidence pipeline, both sides of the Atlantic.

The same CycloneDX SBOM and signed attestation that map to the CRA also map to Executive Order 14028, the NIST Secure Software Development Framework (SP 800-218), and the CISA Secure Software Development Attestation Form. You don't run a second tool to answer a US federal SBOM question — it's the same artifact, already signed. For the engineering-org view of this, seeAttestree for SaaS engineering.

FAQ

Straight answers.

Does Attestree make my product CRA-compliant?

No — and any tool that claims to is overselling. The CRA is a broad regulation: risk assessment, vulnerability handling, incident reporting, conformity assessment and CE marking all remain your responsibility. Attestree automates one specific, load-bearing piece — the machine-readable SBOM and signed provenance evidence for the components you integrate (Annex I Part II(1) and the third-party due-diligence duty in Article 13).

What SBOM format does Attestree produce?

CycloneDX 1.6, generated with Syft at the moment each artifact is ingested — a commonly used, machine-readable format the CRA accepts (alongside SPDX). It covers more than the CRA top-level-dependency minimum, and you can export the top-level view on its own.

When do I need this by?

The CRA entered into force on 10 December 2024. The Article 14 reporting obligations — for actively exploited vulnerabilities and severe incidents — apply from 11 September 2026. The main obligations, including the Annex I Part II(1) SBOM requirement, apply from 11 December 2027. The reporting clock starts first.

The CRA only requires top-level dependencies — isn't a deeper SBOM overkill?

Top-level is the legal minimum. Attestree captures the deeper tree because the same SBOM serves vulnerability identification and the US EO 14028 / NIST SSDF attestation, which expect more. The deeper data is there when you need it; the top-level export satisfies the CRA on its own.

Does this help with US federal SBOM requirements too?

Yes. The same CycloneDX SBOM and signed attestation map to Executive Order 14028, the NIST Secure Software Development Framework (SP 800-218), and the CISA Secure Software Development Attestation Form. One evidence pipeline, both regimes.

Start the SBOM before the deadline.

Generate a signed CycloneDX SBOM and provenance attestation for every component at ingest — in the free Community Edition, on your own hardware.

Informational, not legal advice. Confirm your CRA obligations with qualified counsel.