Product security
The operating layer between engineering and compliance.
Vellaci's wedge is product security plus CRA operations: the primitives are products, requirements, evidence, technical assets, incidents, workflows, deadlines and an audit trail. Engineering keeps its tools; compliance gets a system of record; auditors get a trail they can follow.
Product registry
Lifecycle from draft to withdrawn, owners and security owners, classification with reasoning and approval, EU market availability by Member State, repositories, versions and tags.
Classification
Annex III Class I / Class II and Annex IV categories matched against declared core functions, with Annex references, an approver and an override rationale stored on the product.
Support periods
Start, end, expected lifetime and rationale per product, with end-of-support alerts and the Article 13(8) baseline shown in context.
Coordinated disclosure
Contact point, security.txt status, disclosure policy generated from an editable template aligned with ISO/IEC 29147, SLAs and intake instructions.
Technical documentation
Fourteen Annex VII-oriented sections per product with version history, exportable as a ZIP technical package for notified bodies or authorities.
Readiness framework
Configurable requirements across twelve domains with owners, evidence, review dates and weighted scoring — a management view, never a certificate.
Policies and templates
CVD policy, secure development policy, update policy and incident runbook templates versioned with approvals.
Exports and portability
PDF, CSV, JSON and ZIP reports; a complete organisation export at any time; public API and CLI. Your data, no lock-in.
Manufacturer obligations
Article 13 in operational terms.
| Article 13 | Obligation (summary) | Operational answer |
|---|---|---|
| 13(1)–(3) | Design, develop and produce in accordance with the essential requirements; carry out a cybersecurity risk assessment and keep it in the technical documentation | Risk assessment section per product; readiness controls mapped to Annex I Part I |
| 13(5) | Exercise due diligence when integrating third-party components, including free and open-source software | SBOM per version, component provenance, licence and vulnerability intelligence |
| 13(6) | Report a vulnerability in an integrated component to its maintainer and share the fix | Upstream disclosure log on the finding |
| 13(8) | Determine and document the support period; handle vulnerabilities effectively throughout it | Support period with rationale, end-of-support alerts, vulnerability handling per supported version |
| 13(12)–(13) | Draw up the technical documentation and carry out conformity assessment; keep documentation for ten years or the support period, whichever is longer | Annex VII workspace; retention ≥ 10 years by default; conformity route from classification |
| 13(15)–(18) | Identification, contact details, user information and instructions, single point of contact | Product master data; user-facing security information section; published contact point |
| 13(20) | Corrective actions when a product is not in conformity; inform authorities and users | Incident and task workflows with evidence and communications log |
FAQ
Product-security questions, answered.
- What is the support period and who decides it?
- Article 13(8) requires manufacturers to determine a support period that reflects the time the product is expected to be in use, taking into account user expectations, the nature of the product and relevant Union law; it should be at least five years unless the product is expected to be used for a shorter time. The manufacturer decides and documents the rationale. Vellaci records start, end, expected lifetime and rationale per product and alerts before end of support.
- What goes into the technical documentation?
- Annex VII: a general description of the product, its intended purpose and versions; a description of the design, development and vulnerability-handling processes; the cybersecurity risk assessment; the support period; the standards applied; test reports; the EU declaration of conformity; and, where applicable, the SBOM. Vellaci structures fourteen sections per product with version history and evidence links, exportable as a technical package.
- Do we have to publish our SBOM?
- No. The SBOM is part of the technical documentation and must be available to market surveillance authorities on request. Many manufacturers share it with customers under agreement; Vellaci lets you export it per version when you choose to.
- What does the readiness score mean?
- A weighted operational view across governance, risk, secure development, vulnerability management, SBOM, disclosure, updates, incidents, reporting, documentation, support and conformity — each requirement with an owner, status, evidence and review date. It is a management instrument to see gaps and progress. It is not a legal certification and Vellaci never presents it as one.
Read next
- Guide
CRA product classification: default, important (Class I / II) and critical
How Annex III and Annex IV categories work, the core-functionality test, what changes for conformity assessment under Article 32, edge cases, and how to document a classification decision that will survive scrutiny.
- Guide
The CRA support period: how long, how to decide and what to publish
Article 13(8) requires a support period of at least five years unless the product is used for less, during which vulnerabilities are handled and security updates provided. How to determine it, document the rationale, publish it and manage end of support.
- Guide
CRA technical documentation: what Annex VII requires and how to keep it current
The contents of the technical documentation under Article 31 and Annex VII — product description, design and vulnerability-handling processes, risk assessment, support period, standards, test reports, declaration and SBOM — with a structure you can maintain per product for ten years.
- Guide
Coordinated vulnerability disclosure under the CRA: policy, intake and security.txt
Annex I Part II requires manufacturers to enforce a coordinated vulnerability disclosure policy and publish a contact address. What the policy must contain, how to align it with ISO/IEC 29147 and 30111, how to run intake, and how it connects to Article 14.
- Docs
Product registry
Products, versions, lifecycle, classification, exposure context.
- Docs
Roles and permissions
Owner, admin, security, compliance, engineer, auditor, external advisor.
- Free tool
security.txt generator
An RFC 9116 security.txt for your vulnerability contact point.
Make product security auditable.
From a dependency to a decision to evidence — with names and timestamps.