CRA reporting starts on 11 September 2026: build the evidence path now

The Cyber Resilience Act does not arrive on one date. Its vulnerability and incident reporting obligations start on 11 September 2026, before the wider set of obligations applies. That sequence matters because a reporting workflow cannot be invented safely after the first real incident.

The regulation is the authority. Start with the published CRA text on EUR-Lex and obtain legal advice for your products and role. An OTA platform can record facts and preserve evidence; it cannot decide conformity or report to ENISA for you.

Detection is not the same as awareness

A scanner match is a lead. It may identify a component name and version from an SBOM, but it does not establish product applicability, reachability, active exploitation, or the point at which the manufacturer became aware of a reportable case.

A defensible workflow keeps those states separate:

1. retain the exact vulnerability finding and artifact identity;
2. connect it to the product and supported versions under review;
3. record applicability, reachability, VEX and evidence references;
4. record the awareness decision and its rationale;
5. track each required reporting stage and preserve the submitted revision;
6. connect remediation to the signed release and device outcomes;
7. close only after an authorized review.

That is why Meshanics keeps a vulnerability match in draft until a person makes a product-scoped decision. Automation should reduce transcription, not silently make a legal conclusion.

Test the whole path before the deadline

A tabletop exercise should begin with one real artifact and end with an evidence package another person can verify offline. Check whether the exercise can answer:

• which signed artifact and product versions were affected;
• which devices still reported that version at the observation time;
• who made each assessment, with what evidence and rationale;
• what update was approved, how it rolled out, and what failed;
• what was submitted externally, when, and which revision it was;
• whether every included report byte still matches its signed manifest.

The answer should also expose gaps. Missing SBOM coverage, an unreviewed support period or a device that has not reported recently must not be rendered as an all-clear.

What Meshanics provides

The optional Compliance and Evidence module connects the product register, SBOM and vulnerability findings, progressive Article 14 case records, signed release manifests, rollout outcomes and issued evidence dossiers. Issued packages include hashes and signatures for independent verification. A managed copy is called immutable only when retention is enforced by the configured storage service.

This is evidence for compliance work, not a compliance verdict. The manufacturer still owns product scope, risk decisions, support commitments, conformity assessment, user communication and regulatory submission.

Read the operational guides for CRA secure updates, SBOM evidence, and vulnerability reporting, or run a device evaluation before testing the evidence workflow.