Does the CRA apply to my software product?

Generally yes if it is software made available on the EU market in the course of a commercial activity and can connect, directly or indirectly, to a device or network. Sector regimes (medical devices, aviation, vehicles, marine), national-security products and non-commercial open source are excluded or treated differently. Applicability depends on the product and remote-data-processing definitions in Article 3; see the scope page and the official text, and settle it with your advisers.

Does the CRA apply to SaaS?

A cloud service consumed on its own is generally not a product with digital elements; cloud services are addressed by NIS2. The CRA does cover remote data processing that a product depends on to perform one of its functions (Article 3(2)), so a device or application with a required backend brings that backend into scope. It is a product-by-product boundary, not a blanket rule.

What is an SBOM under the CRA?

Annex I Part II(1) requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. Operationally that means one SBOM per supported product version, refreshed per release, in CycloneDX or SPDX, and kept with the technical documentation.

What must be reported within 24 hours?

An early warning for an actively exploited vulnerability in the product, or for a severe incident having an impact on the security of the product, within 24 hours of becoming aware. The early warning states that the event exists, whether malicious acts are suspected and, where applicable, the Member States concerned. It goes to the coordinator CSIRT and ENISA through the single reporting platform.

What is the difference between the 24-hour and 72-hour notification?

The 24-hour early warning is minimal: existence of the event, suspected malicious activity, Member States concerned. The 72-hour notification adds general information about the product, the nature of the vulnerability or incident, an initial assessment and any corrective or mitigating measures taken or that users can take. Both count from the moment of awareness.

When is the final CRA report due?

It depends on the event. For an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure is available. For a severe incident, within one month after the 72-hour notification. The two triggers differ; do not collapse them into a single 30-day rule.

Which products are Class I, Class II or critical?

Annex III lists important products in two classes by their core functionality — Class I includes browsers, password managers, VPNs, operating systems, routers, smart-home security products and more; Class II includes hypervisors and container runtimes, firewalls and intrusion detection systems, and tamper-resistant microprocessors and microcontrollers. Annex IV lists critical products such as hardware security boxes, smart meter gateways and smartcards. Every other product with digital elements is a default product.

Does Vellaci make a company CRA compliant?

No product can. Vellaci operationalises the requirements — products, SBOMs, vulnerability handling, incidents, reporting preparation, evidence and readiness — so a manufacturer can demonstrate what it does and decided. Legal determinations, conformity assessment and CE marking remain the manufacturer's, with a notified body where required.

Does Vellaci submit reports to ENISA?

No. Notifications are submitted by the manufacturer through the ENISA Single Reporting Platform. Vellaci prepares submission-ready content, tracks the deadlines and records the submission with evidence and an immutable audit trail.

Cyber Resilience Act

What the CRA asks of manufacturers — operationally.

Regulation (EU) 2024/2847 applies to products with digital elements placed on the EU market. Article 14 reporting obligations have been in force since 11 September 2026; the main requirements apply from 11 December 2027. Below is the operational reading — what each obligation means as a record, a workflow or a deadline. It is not legal advice.

In one paragraph. The Cyber Resilience Act is the EU regulation that makes cybersecurity a condition of placing hardware and software on the EU market. Manufacturers must build products to Annex I’s essential requirements, keep handling vulnerabilities for a defined support period, report actively exploited vulnerabilities and severe incidents within 24 hours, 72 hours and a final report, maintain technical documentation, and CE-mark the product after conformity assessment. Reporting is already mandatory; the rest applies from 11 December 2027.

Where to go next

Is my product in scope?
Products with digital elements, the manufacturer role, remote data processing and the SaaS boundary, with the definitions that decide it.
Check the scope questions
Get your CRA gap map
Sixteen questions, about eight minutes: preliminary scope, gaps by area and the highest-risk missing capability.
Start the free assessment
Product cybersecurity risk worksheet
Draft product use context, risk scenarios, controls, residual risk and evidence locally.
Open the risk worksheet
For US companies selling to the EU
Check product-level applicability questions and identify the evidence to prepare without assuming every US business is in scope.
Read the US company guide
CRA readiness checklist
Work through product scope, SBOM, vulnerabilities, reporting and documentation; review ticks stay in this browser.
Open the checklist
Article 14 reporting guide
What must be reported, to whom, by when, and how to run the 24-hour workflow with a small team.
Read the reporting guide

Which obligations apply, and where each one lives in Vellaci?

Scope and roles

Manufacturers, importers, distributors, authorised representatives and open-source stewards have distinct obligations. Vellaci's onboarding produces a preliminary scope assessment and records the reasoning.

Classification

Default products, important products (Class I and II, Annex III) and critical products (Annex IV) follow different conformity routes. Classification in Vellaci is explicit, reasoned and approved by a person.

Vulnerability handling

Annex I Part II: SBOM, remediation without delay, testing, disclosure of fixes, coordinated vulnerability disclosure, secure and free updates. Vellaci makes each an operational workflow with evidence.

Reporting (Article 14)

Actively exploited vulnerabilities and severe incidents: 24-hour early warning, 72-hour notification, final report. Vellaci's command center runs those timers from a confirmed awareness time.

Support period

Products need a defined support period reflecting expected use — at least five years unless the product is used for less — recorded with rationale and end-of-support alerts.

Technical documentation

Annex VII documentation assembled progressively in a structured workspace with version history and evidence links, retained for ten years or the support period.

Timeline

When does the CRA apply?

10 Dec 2024In force
Regulation (EU) 2024/2847 enters into force.
Art. 71(1)
11 Jun 2026In force
Provisions on the notification of conformity assessment bodies apply, so notified bodies exist before full application.
Art. 71(2)
11 Sep 2026In force
Article 14 reporting obligations apply — in force now: 24-hour early warning, 72-hour notification and final report for actively exploited vulnerabilities and severe incidents.
Art. 71(2)
11 Dec 2027Upcoming
The regulation applies in full: essential requirements, conformity assessment, CE marking, technical documentation, support period, market surveillance and penalties.
Art. 71(2)

Reporting deadlines

What must be reported, and by when?

Article 14 sets three stages for two kinds of event. The early warning and the notification count from awareness; the final report has a different trigger for each event type.

Event	Stage	Deadline	Counted from
Actively exploited vulnerability	Early warning	24 hours	From becoming aware (Art. 14(2)(a))
Actively exploited vulnerability	Notification	72 hours	From becoming aware (Art. 14(2)(b))
Actively exploited vulnerability	Final report	No later than 14 days	After a corrective or mitigating measure is available (Art. 14(2)(c))
Severe incident	Early warning	24 hours	From becoming aware (Art. 14(4)(a))
Severe incident	Notification	72 hours	From becoming aware (Art. 14(4)(b))
Severe incident	Final report	Within 1 month	After the 72-hour notification (Art. 14(4)(c))

Notifications go to the CSIRT designated as coordinator in the Member State of the manufacturer’s main establishment and to ENISA, through the single reporting platform (Article 16). Try the deadline calculator with your own awareness time, or read the full reporting timeline.

Essential requirements

What does Annex I require?

Part I — product properties

Applied on the basis of the cybersecurity risk assessment.

Made available without known exploitable vulnerabilities
Secure-by-default configuration, with a reset option
Security updates, automatic where appropriate, with opt-out
Protection against unauthorised access; authentication and access control
Confidentiality and integrity of data, commands and configuration; encryption at rest and in transit
Data minimisation; availability of essential functions; limiting negative impact on other systems
Limited attack surfaces; mitigation of exploitation impact; security-related logging
Secure deletion and transfer of user data

Part II — vulnerability handling

Operated for the whole support period.

Identify and document vulnerabilities and components — the SBOM
Address and remediate vulnerabilities without delay
Apply effective and regular tests and reviews
Publicly disclose information about fixed vulnerabilities
Put in place and enforce a coordinated vulnerability disclosure policy
Facilitate information sharing; provide a contact address
Distribute updates securely; provide security updates promptly and free of charge

Who it is for

What does the CRA mean for your kind of product?

The obligations are the same; where they bite differs by product type. Four pages take each segment in turn.

Software manufacturers

Applications, operating systems, developer tooling; SBOMs from package managers per release; the SaaS boundary.

Connected and IoT products

Firmware SBOMs, secure update mechanisms, support periods measured in device lifetimes, smart-home Class I categories.

Industrial and embedded products

Reusing IEC 62443 work, long service lives, embedded SBOMs, secure microcontrollers and gateways.

Network and security products

Routers, VPNs, firewalls, IAM and SIEM are important products under Annex III with heightened obligations.

FAQ

The questions manufacturers ask first.

Short answers first, detail in the linked guides. Regulatory summaries are operational guidance, not legal advice.

What is the Cyber Resilience Act?: Regulation (EU) 2024/2847, the Cyber Resilience Act, lays down horizontal cybersecurity requirements for products with digital elements — hardware and software — placed on the EU market. It obliges manufacturers to design products securely, handle vulnerabilities throughout a defined support period, report actively exploited vulnerabilities and severe incidents, draw up technical documentation and affix the CE marking after conformity assessment. It entered into force on 10 December 2024; Article 14 reporting obligations have applied since 11 September 2026 and the regulation applies in full from 11 December 2027.
Does the CRA apply to my software product?: Generally yes if it is software made available on the EU market in the course of a commercial activity and can connect, directly or indirectly, to a device or network. Sector regimes (medical devices, aviation, vehicles, marine), national-security products and non-commercial open source are excluded or treated differently. Applicability depends on the product and remote-data-processing definitions in Article 3; see the scope page and the official text, and settle it with your advisers.
Does the CRA apply to SaaS?: A cloud service consumed on its own is generally not a product with digital elements; cloud services are addressed by NIS2. The CRA does cover remote data processing that a product depends on to perform one of its functions (Article 3(2)), so a device or application with a required backend brings that backend into scope. It is a product-by-product boundary, not a blanket rule.
What is an SBOM under the CRA?: Annex I Part II(1) requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. Operationally that means one SBOM per supported product version, refreshed per release, in CycloneDX or SPDX, and kept with the technical documentation.
What must be reported within 24 hours?: An early warning for an actively exploited vulnerability in the product, or for a severe incident having an impact on the security of the product, within 24 hours of becoming aware. The early warning states that the event exists, whether malicious acts are suspected and, where applicable, the Member States concerned. It goes to the coordinator CSIRT and ENISA through the single reporting platform.
What is the difference between the 24-hour and 72-hour notification?: The 24-hour early warning is minimal: existence of the event, suspected malicious activity, Member States concerned. The 72-hour notification adds general information about the product, the nature of the vulnerability or incident, an initial assessment and any corrective or mitigating measures taken or that users can take. Both count from the moment of awareness.
When is the final CRA report due?: It depends on the event. For an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure is available. For a severe incident, within one month after the 72-hour notification. The two triggers differ; do not collapse them into a single 30-day rule.
Which products are Class I, Class II or critical?: Annex III lists important products in two classes by their core functionality — Class I includes browsers, password managers, VPNs, operating systems, routers, smart-home security products and more; Class II includes hypervisors and container runtimes, firewalls and intrusion detection systems, and tamper-resistant microprocessors and microcontrollers. Annex IV lists critical products such as hardware security boxes, smart meter gateways and smartcards. Every other product with digital elements is a default product.
Does Vellaci make a company CRA compliant?: No product can. Vellaci operationalises the requirements — products, SBOMs, vulnerability handling, incidents, reporting preparation, evidence and readiness — so a manufacturer can demonstrate what it does and decided. Legal determinations, conformity assessment and CE marking remain the manufacturer's, with a notified body where required.
Does Vellaci submit reports to ENISA?: No. Notifications are submitted by the manufacturer through the ENISA Single Reporting Platform. Vellaci prepares submission-ready content, tracks the deadlines and records the submission with evidence and an immutable audit trail.

Primary sources

Regulation (EU) 2024/2847 — Cyber Resilience Act (EUR-Lex) — Official Journal text; individual articles and annexes are cited where relevant.
CRA Article 13 — Obligations of manufacturers — Due diligence, support period, technical documentation, conformity.
CRA Article 14 — Reporting obligations of manufacturers — Early warning (24 h), notification (72 h), final report.
CRA Annex I — Essential cybersecurity requirements — Part I product requirements; Part II vulnerability-handling requirements including the SBOM.
CRA Article 71 — Entry into force and application — Article 14 reporting obligations have applied since 11 September 2026; the regulation applies in full from 11 December 2027.
CRA Article 64 — Penalties — Up to €15 million or 2.5 % of worldwide annual turnover for essential-requirement breaches.
ENISA — Cyber Resilience Act — Single reporting platform and guidance for manufacturers.
European Commission — Cyber Resilience Act

Last reviewed 2026-09-30. Article references are to Regulation (EU) 2024/2847 as published in the Official Journal.

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).
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 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.
Guide
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.
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
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.
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
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.
Free tool
SBOM quality checker
Inspect CycloneDX or SPDX structure, identifiers, metadata and dependency graph locally in your browser.
Free tool
security.txt generator
An RFC 9116 security.txt for your vulnerability contact point.

Find out where you stand.

A preliminary scope and gap assessment in about eight minutes, then a 20-minute review with a person.

Get my CRA gap map Book a CRA readiness review