Resources
Guides and tools for CRA operations.
Written for engineering, security and compliance leads who need operational answers, not statutory recitals. Every guide cites the regulation, carries a key-facts table and ends with the questions we hear most.
Free tools
SBOM quality checker
Check CycloneDX or SPDX structure, purl coverage, missing fields and dependency graph signals in your browser.
CRA deadline calculator
Compute 24 h / 72 h / final-report deadlines from an awareness time, using Vellaci's deadline engine.
security.txt generator
Generate an RFC 9116 security.txt for your vulnerability contact point.
Guides
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).
CRA reporting timeline: 24 hours, 72 hours and the final report
How the Article 14 deadlines are computed, where the final-report trigger sits for vulnerabilities versus incidents, how calendar months and daylight-saving time behave, and three worked examples.
Incident or vulnerability? How the CRA treats the two reportable events
Actively exploited vulnerabilities and severe incidents share the 24-hour and 72-hour steps but differ in definition, notification content and final-report trigger. How to classify an event, when one becomes the other, and what to record.
SBOM guide for the CRA: formats, minimum content and operations
CycloneDX versus SPDX, what a CRA-oriented SBOM must contain, which tools generate one per ecosystem, how to keep it current per release, how to share it, and how it feeds vulnerability handling and VEX.
VEX vs SBOM: component inventory and exploitability context
A concise technical comparison of SBOM and VEX, how component matching leads to product-specific exploitability statements, and what each artifact can and cannot establish.
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.
CRA conformity assessment: Modules A, B + C and H, notified bodies and CE marking
The conformity assessment procedures of Article 32 and Annex VIII explained by product class, how harmonised standards give a presumption of conformity, when a notified body is needed, and what the declaration of conformity and CE marking require.
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.
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.
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.
CRA vs NIS2: products versus organisations, and how the reporting duties fit together
The Cyber Resilience Act regulates products with digital elements; NIS2 regulates essential and important entities. Many manufacturers face both. How scope, obligations and the 24-hour / 72-hour / one-month reporting steps compare, and how to run one runbook for both.
Open source and the CRA: stewards, commercial manufacturers and upstream duties
When open-source software is in scope of the Cyber Resilience Act, what the light-touch regime for open-source software stewards in Article 24 requires, and what commercial manufacturers who integrate open source must do under Article 13.
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.
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.
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.
Looking for a definition? See the CRA glossary or the Annex III and IV product categories.
Turn the checklist into operations.
Vellaci implements every item as a workflow with evidence.