CRA readiness for software manufacturers.

Two events are reportable: an actively exploited vulnerability in your product, and a severe incident having an impact on the security of the product. Awareness starts the clock. A software company therefore needs an internal rule for what awareness means — a confirmed customer report, a CISA KEV listing that names a component you ship in an exploitable configuration, exploitation observed in telemetry — and a named person who records the timestamp with its timezone.

The stages are fixed. An early warning within 24 hours of awareness states that an exploited vulnerability or severe incident exists and whether malicious acts are suspected. A notification within 72 hours adds general product information, the nature of the vulnerability or incident, an initial assessment and any corrective or mitigating measures. The final report for an actively exploited vulnerability is due no later than 14 days after a corrective or mitigating measure is available; for a severe incident it is due within one month after the 72-hour notification. Notifications go to ENISA and the coordinator CSIRT through the single reporting platform. Vellaci prepares the content and records the submission; your organisation submits.

• An assigned representative with access to the ENISA reporting platform and a deputy, named in the reporting runbook.
• A reportability review that distinguishes a critical-severity finding from an actively exploited one, with the reviewer, rationale and timestamp recorded — including for “not reportable” decisions.
• A release-to-component map so you can tell within minutes which shipped versions contain the affected component.
• A rehearsed drill of the 24-hour path, repeated quarterly, with the drill report kept as evidence.

The CRA Reporting Command Center runs those clocks from a human-confirmed awareness time, stages the three forms with prefilled facts and freezes each submitted revision. The Article 14 guide covers the legal text in detail.

Registry and classification. Each product is recorded with its lifecycle state, owners, support period and a classification decision with reasoning and approver — default, Class I or Class II — so the conformity route is explicit and reviewable.

SBOM per release. Generate CycloneDX or SPDX from your package manager or build pipeline and push it from CI through the REST API or CLI, or let the GitHub App import releases and dependency-graph SBOMs automatically. SBOM management keeps every document immutable and attached to its version, deduplicates components by package URL and matches them continuously against OSV, GitHub advisories, CISA KEV and EPSS.

Triage with reasons. Findings become decisions with a name on them: exploitability, VEX status, remediation owner and target version. An explicit CRA review asks the Article 14 question for each exploited finding rather than leaving it implicit in a severity score. See vulnerability management.

Incidents and reporting. Product-security incidents are separate records with explicit awareness timestamps and a reportability review. A confirmed reportable event opens a reporting case with server-computed 24-hour, 72-hour and final-report deadlines, staged forms and a recorded ENISA SRP submission with receipt.

Evidence and readiness. Policies, test reports, disclosure policy, release notes and drill reports live in a checksummed evidence vault linked to products and requirements; a weighted readiness framework shows what is missing per product; a hash-chained audit log lets an auditor reconstruct every decision. Plans start with a free Evaluation workspace — see pricing and which plan fits — and Vellaci Readiness configures the workspace with your team.