One requirement regime

The regulation asks for evidence. Start from the release.

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) makes cybersecurity evidence a condition of market access for products with digital elements. SBOMFlow supports preparation of that evidence from the build you actually ship — it helps organise what your teams already produce and assists release-review workflows — and leaves every conformity judgment where the regulation puts it: with people.

Available today · optional regime view Never files a report · never decides conformity

This page describes one view of the release record, not the product. A run declares which requirement regime it is executed under, and none is a first-class answer: choose it and nothing on this page is derived, the run assesses no requirement, and the empty result reads not assessed rather than no gaps. Everything else SBOMFlow does — composition, vulnerability and VEX context, preserved test and runtime evidence, review, gates, drift, portable handoffs — happens either way. What the record is, before any regulation

Illustrative brand image, synthetic: six document panels threaded left to right by one continuous ink line, the final panel drawn bolder
One thread of evidence through every release — illustrative brand image · synthetic

The published schedule

These are the dates the official sources currently state.

  1. 10 Dec 2024 In force The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force.
  2. 11 Sep 2026 Reporting begins Article 14 reporting obligations apply from this date. ENISA's single reporting platform is scheduled to be operational from it — confirm its current status with the official sources before you rely on it.
  3. 11 Dec 2027 Main obligations Secure-by-design, vulnerability handling, technical documentation, and conformity assessment apply across the market.

Article 14 reporting is the first obligation to land — if you ship connected products into the EU, that clock is the one to check first, and it lands on releases you have already shipped. Verify against the primary sources: European Commission — Cyber Resilience Act ↗ European Commission — CRA reporting ↗ Regulation (EU) 2024/2847 (EUR-Lex) ↗

Where SBOMFlow helps

Engineering evidence for four kinds of CRA work.

SBOMFlow supports the evidence side of CRA readiness: it observes what a release actually contains, helps organise the evidence beside it, and exposes the gaps. It never decides conformity, and it never files anything. The current build is v0.5.0, available to approved private testers; the capability statuses below describe that build.

Release-backed technical evidence

Available today

Every audit maps observed evidence to a versioned model of the regulation — Annex I product requirements first — with an explicit list of what is present, what is manual-only, and what is missing. Annex VII technical-documentation workspaces and Article 14 reporting-readiness drafts are produced on request, from the same evidence.

You get
CRA coverage map, evidence pack, gap list, UNSIGNED drafts for humans to finish
You keep
the conformity judgment, with your assessor or notified body where required

SBOM & component transparency

Available today

Validated CycloneDX and SPDX SBOMs from the real build, with field-presence checks against NTIA minimum elements and BSI TR-03183-2 — presence facts a reviewer can act on, never a conformance verdict — plus a redactable pack for the importers and distributors who ask.

You get
reproducible SBOMs, presence checks, shareable evidence with verification hashes
You keep
the decision about what to share, and with whom

Vulnerability-handling continuity

Available today Post-market case workflow experimental

The CRA expects vulnerability handling to continue after release. SBOMFlow correlates advisories against what each shipped release actually contained, layers in exploitation context as triage input, records human decisions on a tamper-evident trail, and — in the experimental post-market preview — carries PSIRT cases from intake to human-verified remediation. Where advisory coverage for an ecosystem is unknown, the run says so rather than reading as clean, and a comparison between two releases states whether it actually ran — “nothing changed” and “nothing was compared” are different results.

You get
exposure candidates per shipped release, recorded triage, drift between releases
You keep
every "affected / not affected" call — with a valid justification required

Reporting preparation — never filing

Available today · drafts only

Article 14 reporting is a human act with legal consequences. SBOMFlow prepares clearly-watermarked UNSIGNED DRAFTs with the evidence attached, so the person who submits has the record in front of them. SBOMFlow never transmits, signs, or submits anything, and never contacts a CSIRT, ENISA, or any reporting platform. Every reporting draft is watermarked unsigned; 0.5.0 tightened that check and re-verified the pinned reporting field table against the platform’s published version.

You get
draft content traceable to release evidence, ready for a human to complete
You keep
the submission itself — on the official platform, under your authority
Illustrative brand image, synthetic: four identical blank cream envelopes in an even row, the second lifted slightly and held by a single paperclip
Four kinds of work; one evidence discipline behind each · illustrative brand image, synthetic

The deeper technical detail lives in the docs: CRA-oriented evidence · capability matrix · honest limitations.

Before you ask

One regime among others, and never a verdict.

Is SBOMFlow a CRA tool?

No — the CRA is one view you can ask the release record for. Run with no regime and the record carries no regulatory content at all. And no tool makes you compliant: SBOMFlow prepares engineering evidence and shows the gaps in it, and whether that satisfies a regulation is a judgement for your people, your assessor, and where required a notified body.

What about other regulations?

Other regimes are served the same way, from a requirement list you write and the engine validates. SBOMFlow publishes no requirement text of its own for them, because a mapping we authored would read as a claim we are not entitled to make.

Does it file Article 14 reports?

No. It prepares unsigned drafts with the evidence attached, for the person who submits them on the official platform. SBOMFlow never files a report and never contacts a CSIRT, ENISA or any reporting platform.

Read this before you buy anything CRA-related — from us or anyone else:

  • No tool can make a product CRA-conformant. Conformity is a legal outcome involving your processes, documentation, and — for many products — third-party assessment.
  • SBOMFlow produces engineering evidence and gap assessments to support that work. It is not legal advice, and it does not replace your assessor, notified body, or counsel.
  • Regulatory guidance evolves. We pin our evidence model to a versioned reading of the regulation and update it deliberately — check the primary sources above for the current legal state.

A 20-minute CRA evidence review, from your real release.

Tell us what you build and how you release it. We'll show you what a release-backed evidence pack looks like for a product like yours — including the gaps — and give you a straight answer on fit.