CRA compliance software · Cyber Resilience Act platform
Cyber Resilience Act compliance software for manufacturers.
Vellaci is the operational platform manufacturers use to run their CRA obligations: an SBOM for every release, vulnerability decisions with reasons, Article 14 reporting within 24 and 72 hours, Annex VII technical documentation, and the evidence behind each — in one system of record. It does not certify conformity; it makes your process repeatable and demonstrable.
Article 14 reporting has applied since 11 September 2026 · the regulation applies in full from 11 December 2027 · EU-hosted · prices from €490/month excl. VAT
At a glance
- Who is this for?
- Manufacturers of software, connected, industrial or network products sold in the EU, where security engineering, product management and compliance share CRA obligations — typically 1 to 100+ products.
- What problem does it remove?
- CRA obligations spread across spreadsheets, scanner dashboards, ticket trackers and shared drives, so nobody can show which product versions are exposed, who decided what, or whether an Article 14 deadline is running.
- Where does it fit in the workflow?
- The system of record between your engineering tools and your regulator: it consumes SBOMs and scanner output, adds the human decisions and deadlines the CRA asks for, and keeps the evidence.
- What evidence does it produce?
- SBOM per product version with checksum
- Vulnerability decisions with reasons and VEX export
- Article 14 case revisions and submission records
- Annex VII documentation package
- Hash-chained audit log
- How does implementation work?
- Self-serve: a free Evaluation workspace (1 product, 3 seats) runs the full workflow on your own SBOM the same day. Assisted: Vellaci Readiness (from €4,900) configures scope, products, SBOMs, workflows and the reporting runbook with you in four to six weeks.
- What does it connect to?
- GitHub App (releases, dependency-graph SBOMs)
- GitLab
- CI/CD upload via REST API or CLI (GitHub Actions, GitLab CI, Jenkins, CircleCI examples)
- Jira and Linear (remediation tasks)
- Slack, Microsoft Teams, PagerDuty, signed webhooks (deadline and exploitation alerts)
- SAML / OIDC SSO (Enterprise plan)
What happens after you request a demo?
- We reply within two business days with two proposed times.
- A live walkthrough with a Vellaci operator on the seeded demo workspace, focused on your products and your reporting path.
- If it fits, a written proposal: plan, implementation package, deliverables, prerequisites and exclusions. If it does not, we say so.
What happens after you sign up?
- Confirm your e-mail and create the workspace — no credit card for the free Evaluation.
- Add a product and upload one SBOM (UI, API, CLI or GitHub).
- See matched vulnerabilities ranked by exploitation evidence and run your first CRA review; subscribe only when you choose a plan.
Buyer’s checklist
What must CRA compliance software actually do?
Eight capabilities that follow from the text of the regulation. The criterion and the vendor question are our interpretation; the reason column cites the requirement it comes from. Use the questions with any vendor, including us.
| Capability | Why the CRA makes it necessary | Question to ask any vendor | How Vellaci does it |
|---|---|---|---|
| SBOMs bound to the version they describe | Annex I Part II(1) asks for an SBOM covering at least top-level dependencies; Annex VII asks for documentation per product and version. | “If we upload the SBOM for 2.4, can we still show what 2.3 shipped?” | Each SBOM is bound to a product version, stored with its checksum and never overwritten. |
| Continuous matching for the whole support period | Article 13(8) requires vulnerabilities to be handled effectively for the support period — at least five years in most cases. | “Does a component that becomes exploited next year surface without a re-upload?” | Components are re-matched daily against OSV and GitHub advisories, with CISA KEV and EPSS enrichment. |
| Decisions with reasons, not just statuses | Article 13(7) asks manufacturers to systematically document vulnerabilities they become aware of. | “Is a reason mandatory for 'not affected' and 'accepted risk', and who made the call?” | Reasons are required; every decision carries reviewer and timestamp, exportable as CycloneDX VEX. |
| An explicit reportability review with an awareness time | Article 14 deadlines run from when the manufacturer becomes aware of an actively exploited vulnerability or a severe incident. | “Where is the moment of awareness recorded, by whom, in which timezone?” | A named reviewer confirms awareness and reportability; deadlines start only from that record. |
| Two final-report triggers, computed server-side | Article 14(2)(c) and 14(4)(c) set different final-report triggers for vulnerabilities and incidents. | “Does the tool distinguish 14 days after a corrective measure from one month after the notification?” | Two case types, two triggers, calendar-correct arithmetic, persisted with the rule version. |
| Technical documentation assembled from operational records | Article 13(12) and Annex VII require technical documentation before placing on the market. | “Does the documentation reference the SBOMs, decisions and test reports, or is it a separate document?” | Fourteen Annex VII-oriented sections per product with version history, exported as a ZIP package. |
| Retention and portability | Article 13(13): keep documentation for ten years after placing on the market or the support period, whichever is longer. | “What happens to our evidence if we stop paying?” | 10-year retention by default; a lapsed workspace stays readable and exportable; full export at any time. |
| No automated legal determinations | Scope, classification and reportability are the manufacturer's responsibility under the regulation. | “Does the tool decide reportability, or does it record who decided?” | Vellaci surfaces signals and records decisions; it never decides or submits in your name. |
Regulation → operation → workflow → evidence
What each CRA obligation means for your team, and what it leaves behind.
Every obligation a manufacturer has to run, from the SBOM to the technical documentation: the requirement as the regulation states it, what your engineering, security and compliance teams actually do, the Vellaci workflow that supports it, and the evidence you can show afterwards.
How to read this. Official requirement summarises the text of Regulation (EU) 2024/2847 with its reference. What your team does is Vellaci’s operational interpretation, not legal advice. Vellaci workflow and Evidence describe what the product does today. Methodology · reviewed 2026-10-05.
- Official requirement
- Identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies.
- What your team does (interpretation)
- Generate an SBOM in the build for every released version, keep it with that version rather than overwriting it, and make sure components carry identifiers (purls) that vulnerability data can be matched against.
- Vellaci workflow
- SBOM ingestion per product version (UI, API, CLI, GitHub/GitLab), original file preserved, components normalised and deduplicated. How it works
- Evidence produced
- Original SBOM file with SHA-256 checksum, bound to the version
- Parse record and warnings
- Component inventory per version and diff against the previous version
- Official requirement
- Exercise due diligence when integrating components sourced from third parties, including free and open-source software, so that they do not compromise the product's cybersecurity.
- What your team does (interpretation)
- Know which third-party and open-source components each version ships, watch them for new vulnerabilities over the support period, and record why a risky component was accepted.
- Vellaci workflow
- Component catalogue across all SBOMs with product usage, continuously matched against OSV and GitHub advisories, enriched with CISA KEV and EPSS. How it works
- Evidence produced
- Which products and versions ship a component
- Match history with source and fetch time
- Recorded risk acceptance with reason
- Official requirement
- In relation to the risks posed, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, provide security updates separately from functionality updates.
- What your team does (interpretation)
- Every matched vulnerability gets a human decision — affected, not affected, fixed, accepted — with a reason, an owner and, if affected, a remediation target and the version that fixes it.
- Vellaci workflow
- Triage with mandatory reasons, explainable priority (CVSS, EPSS, KEV, exposure), remediation owner and due date, Jira and Linear ticket links. How it works
- Evidence produced
- Decision history per finding with reviewer and timestamp
- Remediation owner, due date and fixed version
- Linked tickets
- Official requirement
- Systematically document, proportionately to the nature and the cybersecurity risks, relevant cybersecurity aspects of the product, including vulnerabilities the manufacturer becomes aware of and relevant information provided by third parties, and update the risk assessment where applicable.
- What your team does (interpretation)
- Keep the reasoning, not just the status. A 'not affected' without a justification is not documentation; neither is a status that was silently overwritten.
- Vellaci workflow
- Append-only decision history and hash-chained audit log; VEX states with CycloneDX justification codes per product version. How it works
- Evidence produced
- Per-product VEX statements with justification
- Audit log entries with before and after values
- CycloneDX VEX export per version
- Official requirement
- Once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description, the affected products, impact, severity and information helping users remediate; publication may be delayed in duly justified cases.
- What your team does (interpretation)
- Tie each advisory to the finding and the fix release, and record when and where it was published — or why publication was delayed.
- Vellaci workflow
- Fixed versions recorded on findings; CycloneDX VEX export for customers and downstream integrators. How it works
- Evidence produced
- Fixed version linked to the finding
- Exported VEX document
- Publication or delay rationale
- Official requirement
- Apply effective and regular tests and reviews of the security of the product.
- What your team does (interpretation)
- Decide which tests run per release and per period (SAST, dependency scanning, penetration tests, reviews), and keep the reports where an assessor can find them per product.
- Vellaci workflow
- Test reports attached to products and requirements in the evidence vault, with review dates; readiness controls show which are missing or overdue. How it works
- Evidence produced
- Test reports linked to the product, with checksum and review date
- Readiness control status per requirement
- Official requirement
- Provide mechanisms to securely distribute updates so vulnerabilities are fixed or mitigated in a timely manner — automatically where applicable — and disseminate available security updates without delay and, unless otherwise agreed for a tailor-made product, free of charge, with advisory messages.
- What your team does (interpretation)
- Document how updates are signed, delivered and applied per product, and be able to show which release fixed which vulnerability and when it was made available.
- Vellaci workflow
- Secure update mechanism section per product in the technical documentation; fixed versions recorded on findings. How it works
- Evidence produced
- Update mechanism description with version history
- Finding → fixed version → release date
Coordinated vulnerability disclosure and contact address
Annex I, Part II(5)–(6)Applies from 11 Dec 2027- Official requirement
- Put in place and enforce a policy on coordinated vulnerability disclosure, and facilitate the sharing of information about potential vulnerabilities, including by providing a contact address for reporting them.
- What your team does (interpretation)
- Publish a reachable intake channel (for example security.txt), a disclosure policy with response targets, and keep a record of reports received and how they were handled.
- Vellaci workflow
- CVD settings per organisation: vulnerability contact, reporting URL, security.txt status, published policy URL, intake instructions and acknowledge / triage / fix targets; policy template aligned with ISO/IEC 29147. How it works
- Evidence produced
- Recorded contact point, security.txt and policy URL
- Response targets (acknowledge, triage, fix)
- Changes to the settings in the audit log
- Official requirement
- Notify any actively exploited vulnerability contained in the product to the CSIRT designated as coordinator and to ENISA via the single reporting platform: early warning within 24 hours of becoming aware, notification within 72 hours, final report no later than 14 days after a corrective or mitigating measure is available.
- What your team does (interpretation)
- Decide who confirms awareness and reportability, record when they did it and in which timezone, and have the content of each stage ready before the clock runs out.
- Vellaci workflow
- Explicit CRA review on every finding, reporting case with server-computed 24 h / 72 h / final-report deadlines, staged and prefilled forms. How it works
- Evidence produced
- Reportability decision with rationale and reviewer
- Confirmed awareness time and timezone
- Frozen revision of each submitted stage with SRP reference
- Official requirement
- Notify any severe incident having an impact on the security of the product to the coordinator CSIRT and ENISA via the single reporting platform: early warning within 24 hours of becoming aware, notification within 72 hours, final report within one month after the notification.
- What your team does (interpretation)
- Keep incidents separate from vulnerabilities — the final-report trigger differs — and answer the 'severe incident' question explicitly, with a named person and a reason.
- Vellaci workflow
- Incident records with confirmed awareness time and severe-incident review, opening a reporting case with the incident timeline. How it works
- Evidence produced
- Incident record with impact, affected versions and Member States
- Severe-incident decision with rationale
- Final report and its submission record
- Official requirement
- After becoming aware of an actively exploited vulnerability or a severe incident, inform the impacted users — and where appropriate all users — about it and about risk-mitigation and corrective measures they can deploy, where necessary in a structured, machine-readable format.
- What your team does (interpretation)
- Draft the user communication from the same facts as the notification, and keep the version that was actually sent.
- Vellaci workflow
- No dedicated drafting tool: the communication as sent is filed in the evidence vault and linked to the incident or reporting case, next to the corrective measure. How it works
- Evidence produced
- Sent user communication with date, linked to the case
- Corrective measure or fixed version it refers to
- Official requirement
- Handle vulnerabilities effectively for the support period, and determine that period so it reflects the time the product is expected to be in use; it is at least five years unless the product is expected to be in use for less.
- What your team does (interpretation)
- Record a support end date and its rationale per product, keep handling vulnerabilities for every version still inside it, and plan what happens at end of support.
- Vellaci workflow
- Support period with rationale per product, end-of-support alerts, vulnerability handling per supported version. How it works
- Evidence produced
- Support period and rationale on the product record
- Version list showing which versions are still supported
- Official requirement
- Undertake an assessment of the cybersecurity risks of the product, take its outcome into account during planning, design, development, production, delivery and maintenance, document it and update it as appropriate during the support period.
- What your team does (interpretation)
- Write the risk assessment per product, link it to the Annex I controls it justifies, and revisit it when vulnerabilities or incidents change the picture.
- Vellaci workflow
- Risk assessment section in the per-product technical documentation workspace, with version history; per-product obligations view. How it works
- Evidence produced
- Versioned risk assessment section with author and status
- Link between findings and the assessment they updated
- Official requirement
- Draw up the technical documentation before placing the product on the market, containing at least the elements in Annex VII, and keep it, with the EU declaration of conformity, at the disposal of market surveillance authorities for at least ten years after placing on the market or for the support period, whichever is longer.
- What your team does (interpretation)
- Assemble the Annex VII file progressively from records you already keep — SBOMs, vulnerability handling, risk assessment, support period, test reports — instead of writing it once before an audit.
- Vellaci workflow
- Fourteen Annex VII-oriented sections per product with status, version history and evidence links, exported as a ZIP technical package. How it works
- Evidence produced
- Section versions with author and approval status
- ZIP technical package (product record, SBOMs, sections, evidence index)
The product
See the workflows before the call.
Vulnerability queue. Findings ranked by exploitation evidence, each with the product version on the market, the triage reason and the CRA review answer.
See this screen with sample dataReporting case command center. A reporting case with the confirmed awareness time, server-computed deadlines and staged, prefilled notification content.
See this screen with sample dataEvidence and technical documentation. Annex VII-oriented sections per product with status, version history and ZIP package export.
See this screen with sample dataAudit history. An append-only, hash-chained log of who changed which decision and when.
See this screen with sample dataWhere it fits
Next to the tools you already run.
Vellaci is not a scanner, a tracker or a GRC suite. It is the product-centric system of record between them and the regulator.
| What you use today | Good at | Gap for CRA obligations | How Vellaci relates |
|---|---|---|---|
| Spreadsheets and shared drives | Getting started; listing products and owners. | No continuous matching, no deadline engine, no tamper-evident history. Hard to prove what was known when. | Import the product list by CSV and keep the spreadsheet as a historical attachment. |
| SCA scanners (Dependabot, Snyk, Trivy, …) | Finding vulnerable dependencies in repositories and pipelines. | Organised by repository, not by product version on the EU market; no reportability review, awareness time or Article 14 case. | Keep the scanner. Vellaci consumes the SBOMs it produces and adds products, decisions, deadlines and evidence. |
| Ticket trackers (Jira, Linear) | Assigning and tracking engineering work. | A ticket timestamp is not an awareness time; closed tickets are not regulatory evidence. | Remediation tasks are pushed to Jira or Linear and linked back to the finding. |
| General GRC platforms | Policies, controls and organisation-level frameworks (ISO 27001, SOC 2). | Organisation-centric: rarely model product versions, SBOMs, vulnerability decisions or the 24-hour clock. | Vellaci is product-centric; export evidence and reports to your GRC platform if you run one. |
Implementation
From first SBOM to a drilled reporting workflow.
Two ways in. Both end in the same workspace, on a platform plan; nothing is rebuilt or migrated.
Self-serve evaluation
Create a free Evaluation workspace, add one product, upload one SBOM from your pipeline and see matched vulnerabilities, the CRA review and the reporting workflow the same day.
Create a free workspaceVellaci Readiness from €4,900 one-time
Teams with a small portfolio (1–5 products) that must be operational for Article 14 reporting within weeks. Four to six weeks depending on portfolio size and your team's availability; the plan and its progress are visible in your workspace from day one.
Deliverables, prerequisites and exclusionsVellaci Implementation from €9,500 one-time
Multi-product manufacturers (typically 6–25 products) migrating existing evidence, integrating trackers and CI, and standing up product-security processes across teams. Six to ten weeks depending on the number of products, integrations and the volume of evidence to migrate.
Deliverables, prerequisites and exclusionsFAQ
Questions buyers ask about CRA software.
Regulatory statements are summaries of Regulation (EU) 2024/2847, reviewed 2026-10-05; they are operational guidance, not legal advice.
- What is CRA compliance software?
- Software that helps a manufacturer operate the obligations of the Cyber Resilience Act (Regulation (EU) 2024/2847) over a product's life: keeping an SBOM per release, handling vulnerabilities for the support period, reporting actively exploited vulnerabilities and severe incidents under Article 14, maintaining Annex VII technical documentation and keeping the evidence. It supports the manufacturer's process; it does not make a product compliant by itself.
- Can software make our products CRA compliant?
- No. Conformity depends on how the product is designed and maintained and is demonstrated through the conformity assessment route for its category — with a notified body for some important and all critical products. Software like Vellaci makes the required processes repeatable and the evidence available; legal determinations, conformity assessment and CE marking remain yours.
- We already run an SCA scanner. Do we need CRA software?
- A scanner finds vulnerable dependencies in a repository. The CRA asks for more: which product versions on the EU market are affected, who decided what and why, whether Article 14 applies, when the manufacturer became aware, and what was submitted. Vellaci consumes your scanner's SBOMs and adds those layers; it does not replace the scanner.
- When do we need it — now or in December 2027?
- CRA Article 14 reporting obligations are in force as of 11 September 2026. The CRA’s general application date is 11 December 2027. The reporting workflow — awareness, reportability review, 24-hour and 72-hour deadlines — is therefore needed now. SBOM, vulnerability handling, technical documentation and conformity assessment have to be operating before products are placed on the market from 11 December 2027.
- Does Vellaci submit our notifications to ENISA?
- No. The manufacturer submits through ENISA's Single Reporting Platform. Vellaci prepares the content of each stage, tracks the deadlines and records the submission — time, submitter, platform reference, receipt — as a frozen revision with evidence.
- How is it priced?
- A free Evaluation workspace with one product; the Readiness plan at €490/month for up to 5 products; Growth at €990/month for up to 25; Enterprise by contract. Optional one-time implementation from €4,900. Prices excl. VAT.
- Where is our data hosted?
- Database, authentication and storage run in the EU (Frankfurt). Tenant isolation is enforced with row-level security in the database, evidence lives in private storage with short-lived signed URLs, and the audit log is hash-chained. The Trust Center lists every subprocessor.
Read next
- Guide
CRA readiness checklist for software and connected-product manufacturers
A practical CRA checklist across governance, SBOM, vulnerability handling, disclosure, incidents, reporting, support period and documentation, with evidence to keep and current transition milestones.
- Guide
CRA vulnerability handling requirements: what Annex I Part II asks of manufacturers
The eight vulnerability-handling requirements in Annex I Part II, what each one means operationally, the evidence an authority or auditor would expect, and how to run them as one workflow from SBOM to security update.
- Guide
CRA evidence management: what to keep, for how long, and how to keep it provable
The Cyber Resilience Act is evidenced with records, not statements. Which records an authority, notified body, customer or auditor will ask for, the ten-year retention rule, and the properties — provenance, integrity, linkage, retrievability — that make a record count.
- Guide
CRA Article 14 reporting obligations: a practical guide for manufacturers
What must be reported under Article 14 of the Cyber Resilience Act, by whom, to whom and when — the 24-hour early warning, 72-hour notification and final report — and how to operationalise it now that the obligation is in force (since 11 September 2026).
- Docs
Your first 15 minutes
From sign-up to the first vulnerable component.
- Docs
Integrations
GitHub, GitLab, Jira, Linear, Slack, Teams, PagerDuty.
- Free tool
SBOM quality checker
Inspect CycloneDX or SPDX structure, identifiers, metadata and dependency graph locally in your browser.
- Free tool
CRA deadline calculator
24-hour, 72-hour and final-report deadlines from an awareness time, using Vellaci's deadline engine.
See Vellaci run your CRA workflow.
A live walkthrough on a seeded demo workspace, focused on your products and your reporting path — or start free with one product today.