What is the EU Cyber Resilience Act (CRA)?

The EU Cyber Resilience Act (CRA), officially EU Regulation 2024/2847, is a comprehensive EU regulation that establishes mandatory cybersecurity requirements for products with digital elements sold in the European Union. It applies to hardware and software products that can connect to networks or process data. The CRA aims to ensure that manufacturers, importers, and distributors maintain security throughout a product's lifecycle, including vulnerability management, security updates, and transparent communication with users. Full enforcement begins December 11, 2027.

Does the CRA apply to SaaS (Software as a Service) products?

Yes, the CRA applies to most SaaS products. The regulation covers 'products with digital elements' which includes software that processes data or connects to networks. Cloud-based SaaS applications fall under this definition if they are sold or made available to EU customers. However, not all 22 CRA requirements apply to every SaaS product—typically 8-12 requirements apply to cloud-only B2B SaaS, while IoT products may need to comply with all 22. Use the free CRA Compliance Toolkit at cra-toolkit.com to determine which specific requirements apply to your product.

What are the main CRA requirements for software products?

The main CRA requirements for software products include: 1) Secure by Design (Article 10.1) - integrating security throughout development, 2) Secure by Default (Article 10.2) - shipping with secure default configurations, 3) Software Bill of Materials/SBOM (Article 10.5) - maintaining a list of all software components, 4) Vulnerability Handling (Article 13) - having a process to receive and address security vulnerabilities, 5) Security Updates (Article 10.4) - providing security updates for at least 5 years or the product's expected lifetime. Additional requirements may apply based on your specific product type and classification.

When does CRA enforcement begin and what are the key deadlines?

The CRA enforcement happens in phases: 1) December 10, 2024 - CRA enters into force, 2) September 11, 2026 - Conformity assessment bodies must be designated, 3) September 11, 2026 - Vulnerability and incident reporting obligations begin, 4) December 11, 2027 - Full enforcement of all requirements. Organizations selling products with digital elements in the EU should begin compliance preparations now to meet these deadlines.

What is an SBOM and why does CRA require it?

An SBOM (Software Bill of Materials) is a comprehensive list of all software components, libraries, and dependencies used in a product—like an ingredients list for software. CRA Article 10.5 requires manufacturers to maintain SBOMs because: 1) It enables rapid identification of affected products when vulnerabilities are discovered (e.g., Log4j), 2) It provides transparency about third-party components and their security status, 3) It supports vulnerability management and incident response. Free tools like CycloneDX, Syft, and Trivy can generate SBOMs automatically from your codebase.

How much does CRA compliance cost?

CRA compliance costs vary significantly: Hiring consultants typically costs €8,000-€15,000 for initial assessment and €20,000-€50,000+ for full implementation support. However, DIY compliance is possible at minimal cost using free, open-source tools: CycloneDX for SBOM generation, OWASP Dependency-Track for vulnerability monitoring, Trivy for container scanning, and Semgrep for static analysis. The free CRA Compliance Toolkit at cra-toolkit.com helps identify which requirements apply to your product, potentially saving thousands in unnecessary consultant fees. Additionally, EU SMEs can apply for up to €30,000 in grants through the SECURE/Secure4sme program (50% co-financing).

Is my US-based company affected by the CRA?

Yes, if your US-based company sells products with digital elements to customers in the European Union, the CRA applies to you. The CRA has extraterritorial reach—it applies based on where products are sold, not where the company is based. If you place products on the EU market (even through distributors or resellers), you must comply with CRA requirements. This is similar to how GDPR applies to non-EU companies that process EU residents' data.

What products are exempt from CRA?

Several categories are exempt from CRA: 1) Internal tools not placed on the market, 2) Custom software developed for a single client, 3) Products already regulated under other EU frameworks (medical devices, vehicles, aviation), 4) National security and military products, 5) Open-source software developed non-commercially by individuals or non-profit foundations (though commercial entities using open-source remain liable). SaaS products serving only internal company use would not be in scope, but any product offered to external EU customers likely falls under CRA.

What is the difference between CRA and NIS2?

CRA and NIS2 are complementary EU regulations with different focuses: CRA (Cyber Resilience Act) focuses on PRODUCT security—ensuring hardware and software products sold in the EU are secure by design. NIS2 (Network and Information Security Directive 2) focuses on ORGANIZATIONAL security—requiring essential and important entities to implement cybersecurity measures and report incidents. A company might need to comply with both: NIS2 for their organizational security practices, and CRA for any products they manufacture and sell. CRA has specific technical requirements (SBOM, vulnerability handling), while NIS2 focuses on governance, risk management, and incident reporting.

How do I check if CRA applies to my product?

To check if CRA applies to your product, ask these questions: 1) Do you sell or make your product available in the EU market? 2) Is your product software or hardware that processes data or connects to networks? 3) Are you the manufacturer (creator/seller) of the product? If you answered YES to all three, CRA likely applies. The free CRA Compliance Toolkit at cra-toolkit.com provides a 5-minute assessment that determines exactly which of the 22 CRA requirements apply to your specific product type, saving you hours of research through the 200+ page regulation.

What are the CRA penalties for non-compliance?

CRA penalties can be severe: up to €15 million or 2.5% of global annual turnover (whichever is higher) for violations of essential cybersecurity requirements. For less severe infringements, fines can reach €10 million or 2% of turnover. Providing misleading information to authorities can result in fines up to €5 million or 1% of turnover. Additionally, non-compliant products can be withdrawn from the EU market entirely, resulting in significant revenue loss beyond the fine itself.

What is a Software Bill of Materials (SBOM) and how do I create one for CRA?

A Software Bill of Materials (SBOM) is a comprehensive inventory of all software components, libraries, and dependencies in your product — like an ingredients list for software. CRA Article 10.5 requires manufacturers to create and maintain SBOMs. You can generate one for free using tools like CycloneDX CLI, Syft, or Trivy. The SBOM should include component names, versions, suppliers, and known vulnerabilities. Integrate SBOM generation into your CI/CD pipeline for automatic updates. The free CRA Compliance Toolkit at cra-toolkit.com/cra-sbom-requirements provides detailed guidance.

Does the CRA apply to open-source software?

It depends. Non-commercial open-source software developed by individuals or non-profit foundations is generally exempt from CRA. However, commercial entities that use, integrate, or distribute open-source software in their products remain fully liable under CRA for those products. Additionally, the CRA introduces a new category called open-source software stewards (Article 24) — organizations that systematically support open-source projects used commercially. Stewards have reduced obligations focused on cybersecurity policies and cooperation with authorities, but they are not exempt entirely. Learn more at cra-toolkit.com/cra-for-stewards.

How does CRA affect companies outside the EU?

The CRA has extraterritorial reach, similar to GDPR. If your company — regardless of where it is headquartered (US, UK, India, etc.) — sells or makes available products with digital elements to customers in the EU market, you must comply with CRA requirements. This applies whether you sell directly or through distributors, resellers, or app stores. Companies outside the EU should designate an authorized representative within the EU and begin compliance preparations well before the December 2027 full enforcement deadline. Use the free assessment at cra-toolkit.com/does-cra-apply-to-me to check your obligations.

CRA Incident Reporting Guide: 24h/72h/14-Day Process

Article 14 EU Regulation 2024/2847

CRA Incident Reporting Guide

The 3-stage vulnerability and incident reporting process required by Article 14 of the Cyber Resilience Act — explained in plain language for developers and product teams.

Article 14 reporting obligations are now in effect

Notify without undue delay: early warning within 24 hours and notification within 72 hours of awareness. Vulnerability final report: within 14 days after a corrective or mitigating measure is available. Severe incident final report: within one month after the actual incident notification.

What Starts the Clock?

The reporting obligation is triggered when a manufacturer becomes aware of either:

Trigger 1: Actively Exploited Vulnerability

You discover (or are informed) that a vulnerability in your product is being actively exploited in the wild. This includes vulnerabilities in third-party components you integrate.

Article 14(1)

Trigger 2: Severe Security Incident

An incident that negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions; or that has led, or is capable of leading, to the introduction or execution of malicious code.

Article 14(3), (5)

Key point: The clock starts when you become aware — not when you confirm or fully analyze the issue. Early notification with incomplete information is expected and required.

The 3-Stage Reporting Timeline

1

24h

2

72h

3

Final report: 14 days / one month

Incident case

Case titleResponsible personReporting authority

Case deadlines

Cases are saved on this device for the current account and product. No cloud sync, regulatory submission or background alert is performed. Calendar events require import into your calendar. Times are entered locally; calendar-month calculations use UTC.

Reporting event Awareness timestamp Corrective or mitigating measure available (vulnerability) Actual Article 14(4)(b) notification timestamp (incident)

Submission records (self-reported)

1: Actual submission time 1: Receipt or notification reference

2: Actual submission time 2: Receipt or notification reference

3: Actual submission time 3: Receipt or notification reference

Stage 1 deadline (24h)

Set awareness timestamp

Set trigger date to calculate

Stage 2 deadline (72h)

Set awareness timestamp

Set trigger date to calculate

Final report: 14 days / one month

Select an event type and enter its final-report trigger timestamp.

Set trigger date to calculate

1

Stage 1: Early Warning

Within 24 hours Article 14(2)(a) / 14(4)(a)

This is your first notification. The goal is to alert authorities quickly, even with limited information. Don't wait until you have a complete picture — speed matters more than detail at this stage.

Minimal information to include:

● That you have an actively exploited vulnerability or severe incident
● Which EU Member States your product is available in (if known)
● Whether the incident is suspected to be caused by unlawful or malicious acts (for incidents)
● Sensitivity classification — whether you want restricted dissemination

2

Stage 2: Detailed Notification

Within 72 hours Article 14(2)(b) / 14(4)(b)

Now you provide a more complete picture. By this point you should have more details about the vulnerability, its exploitation, and what you're doing about it.

Full list of required fields:

● General information about the affected product (name, version, category)
● General nature of the exploit and of the vulnerability
● Corrective or mitigating measures you have taken
● Corrective or mitigating measures users can take
● Sensitivity assessment of the notified information
● Member States where product is available

3

Stage 3: Final Report

Final report: 14 days / one month Article 14(2)(c) / 14(4)(c)

Notify without undue delay: early warning within 24 hours and notification within 72 hours of awareness. Vulnerability final report: within 14 days after a corrective or mitigating measure is available. Severe incident final report: within one month after the actual incident notification.

What to include:

● A detailed description of the vulnerability, including its severity and impact
● Information about any malicious actor that exploited the vulnerability (if available)
● Details about the security update or corrective measures made available

Note for severe incidents (Article 14(4)(c)): The final report deadline is 1 month after the Stage 2 notification, and must include: detailed incident description, root cause analysis, and applied and ongoing mitigation measures.

Auto-Generate ENISA Notification Templates

Use this tool to automatically generate all 3 stages of ENISA notification templates based on a CVE and your product information. Perfect for streamlining your reporting process. Prefer a guided, step-by-step version instead? Open the ENISA Reporting Wizard →

CVE ID * Product Name * Product Version Manufacturer Awareness Time * Fix Available (optional)

Where to Send It

All notifications must be submitted simultaneously to two entities via a single mechanism:

1. ENISA Single Reporting Platform

ENISA is setting up a single reporting platform (Article 16) where manufacturers submit all notifications. This platform will route your notification to the appropriate national CSIRT automatically.

Article 16

2. National CSIRT (Coordinator)

Submit to the CSIRT of the EU Member State where your company has its main establishment (where cybersecurity decisions are predominantly taken). The CSIRT receives and coordinates the response.

Article 14(7)

No EU establishment? If your company has no EU headquarters, submit to the CSIRT of the Member State where your authorized representative, importer, or distributor with the most products is established (Article 14(7)).

EU National CSIRT Directory

Country	CSIRT	Website
Austria	CERT.at	cert.at
Belgium	CERT.be	cert.be
Bulgaria	CERT Bulgaria	govcert.bg
Croatia	CERT.hr	www.cert.hr
Cyprus	CSIRT-CY	csirt.cy
Czech Republic	NUKIB CSIRT	nukib.cz
Denmark	CFCS CERT	cfcs.dk
Estonia	CERT-EE	www.cert.ee
Finland	NCSC-FI	www.kyberturvallisuuskeskus.fi
France	CERT-FR (ANSSI)	www.cert.ssi.gouv.fr
Germany	CERT-Bund (BSI)	www.bsi.bund.de
Greece	GR-CSIRT	csirt.cd.mil.gr
Hungary	NCSC-HU	nki.gov.hu
Ireland	CSIRT-IE	www.ncsc.gov.ie
Italy	CSIRT Italia	www.csirt.gov.it
Latvia	CERT.lv	cert.lv
Lithuania	CERT-LT	www.nksc.lt
Luxembourg	CIRCL	www.circl.lu
Malta	CSIRTMalta	csirtmalta.org
Netherlands	NCSC-NL	www.ncsc.nl
Poland	CERT Polska	cert.pl
Portugal	CERT.PT	www.cncs.gov.pt
Romania	CERT-RO	cert.ro
Slovakia	SK-CERT	www.sk-cert.sk
Slovenia	SI-CERT	www.cert.si
Spain	CCN-CERT / INCIBE-CERT	www.incibe.es
Sweden	CERT-SE	www.cert.se
EU (ENISA)	ENISA	www.enisa.europa.eu

Source: ENISA CSIRTs Network. Contact details may change — verify with ENISA's official directory before submitting reports.

Don't Forget: Notify Your Users

After becoming aware of an actively exploited vulnerability or severe incident, you must also inform the impacted users of your product — and where appropriate, all users. Include any risk mitigation steps users can take. Use a structured, machine-readable format where appropriate.

Article 14(8)

Readiness Checklist: 10 Items Before Sept 2026

Article 14 has applied since 11 September 2026. Make sure you have the following in place:

1

Published a Coordinated Vulnerability Disclosure (CVD) policy on your website Annex I, Part II (5)

2

Designated a security contact (e.g., security@yourcompany.com) for vulnerability reports Annex I, Part II (6)

3

Identified your national CSIRT and ENISA reporting endpoint Article 14(7)

4

Created internal escalation procedures — who decides to report and who writes the notification Article 14(1)

5

Pre-filled notification templates for all 3 stages (download from above) Article 14(2)

6

Set up vulnerability monitoring (subscribe to CVE feeds, NVD, vendor advisories for your dependencies) Annex I, Part II (1)

7

Established a process to assess whether a vulnerability is "actively exploited" Article 14(1)

8

Tested your reporting process with a dry run or tabletop exercise Best Practice

9

Documented your support period and communicated it to users Article 13(8)

10

Set up a mechanism to notify affected users quickly (email list, advisory page, machine-readable format) Article 14(8)

Related Tools

Vulnerability Lookup

Search CVEs and check if they trigger CRA reporting obligations

CVD Policy Builder

Create a compliant vulnerability disclosure policy for your website

Security.txt Generator

Generate a security.txt file to make your security contact easily discoverable

CRA Timeline

View all CRA key dates and milestones

ENISA Reporting Wizard

Step-by-step guided version of the notification generator below

Submission and Activity Audit Log

No activity yet. Template downloads and timeline actions are recorded here with timestamps.

Compliance Tools

CRA Incident Reporting Guide

What Starts the Clock?

The 3-Stage Reporting Timeline ?

Case deadlines

Stage 1: Early Warning

Stage 2: Detailed Notification

Stage 3: Final Report

Auto-Generate ENISA Notification Templates

Where to Send It

Don't Forget: Notify Your Users

Readiness Checklist: 10 Items Before Sept 2026

Related Tools

Submission and Activity Audit Log

The 3-Stage Reporting Timeline