VellaciEU Cyber Resilience Act compliance for product manufacturers

Context

The Cyber Resilience Act (EU regulation 2024/2847) applies to anyone placing a product with digital elements on the European market — software, firmware, a connected device. Since 11 September 2026 a manufacturer must report an actively exploited vulnerability or a severe incident to its CSIRT and to ENISA: an early warning within 24 hours, a notification within 72 hours, a final report after that.

The regulation does not ask for good intentions; it asks for dates, names and documents. A manufacturer that cannot produce the SBOM of the shipped version, the trace of the reporting decision and the evidence of what was submitted is not compliant, however good its actual security is.

Problem

Most manufacturers answer those questions today from spreadsheets and ticket timestamps. That fails on three specific points, and each one is fatal in an audit.

• Exposure is a project, not a query: finding out which products ship a vulnerable library means reopening builds instead of asking an inventory.
• The clock has no defensible start: a ticket timestamp is not awareness, and nobody signed the decision to report.
• Evidence is reconstructed afterwards: without immutable revisions and an audit log, what was submitted is no longer distinguishable from what was corrected later.

Hardest part

The core of the product is a clock a regulator will accept. The engineering temptation is to start the countdown automatically as soon as an exploited vulnerability is detected — it is measurable, it is clean, and it is wrong: the regulation speaks of the manufacturer’s awareness, not of the publication date of an advisory.

So the product decision was to require human confirmation before any clock. Vellaci may flag a vulnerability as potentially reportable — for example because a component you ship is listed in the CISA KEV catalogue — but a named reviewer confirms or rejects it, with a rationale, and it is that decision that starts the countdown.

The rest follows. The deadline is persisted with the rule version that produced it, its source timestamp and its timezone; statuses and alerts are computed by background jobs, never only in the browser, so a clock keeps running when nobody has the tab open. And the final-report triggers are two, not one: for an exploited vulnerability, fourteen days from the moment a corrective measure is available; for an incident, one calendar month after the 72-hour notification.

The product as a system

1. Product + SBOM→
2. Vulnerability match→
3. Reviewer decision→
4. Article 14 clocks→
5. Submission + evidence

Product decisions

Three decisions shape the product more than the stack does.

• Rank by exploitation signal, not alphabetically and not by CVSS alone: KEV and EPSS first, because a 9.8 that is never exploited deserves less of your week than a 7.5 being actively exploited on a component you ship.
• Show the gap map before asking for an e-mail address: sixteen questions, eight minutes, a banded result rather than a score — a manufacturer discovering the CRA needs to understand its exposure before entering a sales funnel.
• Sell the software self-serve and the setup as a service: the Vellaci Readiness engagement configures scope, products, SBOMs, workflows and the evidence structure with the customer, because the first configuration is where compliance is won or lost.

Screens

From input to fulfillment — every stage, its layer, what happens there.

Architecture

The system is organised around a single graph: Organisation → Product → Version → Release → SBOM → Component → Vulnerability → Assessment → Remediation → Incident → CRA Notification → Evidence. Every screen is a view over that graph, and every record connects back to a product that is actually on the EU market.

Ingestion is the foundation: an SBOM is validated, parsed into a normalised component model and bound to a product version — the original file preserved with its SHA-256 checksum, and historical facts never rewritten when a newer SBOM arrives. Deduplication happens by canonical purl at the organisation level while product/version relationships are preserved, which turns “which products ship this library?” into a one-line query.

Above that, intelligence is continuous rather than episodic: components are matched against OSV and GitHub advisories, enriched with CISA KEV and EPSS, and re-checked daily. A component shipped six months ago that enters the KEV catalogue today surfaces on the product page without anyone re-running a scan.

Domain model

Organisation → Product → Version

A first-class registry: lifecycle states, classification reasoning, owners, support periods, immutable version history.

Release → SBOM

The document stays attached to the version it describes; the original file is preserved with its SHA-256 and historical facts are never rewritten when a newer SBOM arrives.

Component

A catalogue deduplicated by canonical purl, with product usage, dependency relationships, licences and exposure counts.

Vulnerability → Assessment → Remediation

Triage with a mandatory reason, a remediation owner, a VEX state, and the CRA review that asks the Article 14 question.

Incident

Separate records for exploitation, compromised devices and update-infrastructure compromise — each with its confirmed awareness timestamp.

CRA Notification

The case: type, product, owner, server-computed deadlines, staged forms, submission record.

Evidence

A checksummed file or link tied to a product, a requirement, a vulnerability, an incident or a case, with a review date and legal hold.

Current status

In production, subscriptions live through Stripe. Published pricing (September 2026): a free Evaluation workspace (1 product, 3 seats, 10 SBOMs/month), Readiness €490/month, Growth €990/month, Enterprise under contract, and Vellaci Readiness implementation from €4,900. Article 14 reporting obligations have been in force since 11 September 2026.

Business and operating model

A free workspace that is not a demo: one real product, three seats and the full reporting workflow — enough to carry a genuine case end to end. The subscription starts when the number of products, seats or SBOMs outgrows that, which is the moment a manufacturer actually puts its portfolio under the CRA. Beside it sits a fixed-price implementation engagement: scope, products, SBOMs, workflows and evidence structure configured with the customer. The software sells self-serve; the setup sells as a service, because a manufacturer discovering the regulation is not buying a tool — it is buying a way out of uncertainty.

What shipped

• SBOM ingestion (CycloneDX, SPDX) with continuous matching against OSV, GitHub advisories, CISA KEV and EPSS — exposure becomes a query, not a project
• Article 14 clocks computed server-side from a confirmed awareness time, with the rule version, source timestamp and timezone persisted; statuses and alerts run as background jobs
• Human confirmation before any timer: a named reviewer confirms or rejects reportability with a rationale, so the deadline has an owner and a defensible start
• Immutable revisions — every save is a hashed revision, the submitted one is frozen, amendments link back to it — plus a checksummed evidence vault exportable at any time
• Vulnerabilities ranked by exploitation signal (KEV + EPSS), not alphabetically
• A free 16-question readiness assessment as the top of the funnel: the gap map is shown before an e-mail address is asked for

Acquisition

Acquisition is built on the intents of a manufacturer discovering the regulation: scope (“is my product in?”), product categories, the Article 14 deadlines, the difference between an incident and a vulnerability, the Annex VII technical documentation, the conformity assessment routes, the support period. Free tools sit alongside them — a CRA deadline calculator, a security.txt generator — answering a real question without an account.

Every page leads to the same door: the sixteen-question assessment. It is the site’s only conversion point, and it gives its result before asking for anything.