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 Single Reporting Platform: Simple ENISA SRP Guide

The quick answer

The Single Reporting Platform (SRP) is ENISA's online system for mandatory CRA vulnerability and incident reporting from 11 September 2026.

Who reports?

Manufacturers and, to the extent they are involved in product development, open-source software stewards.

What is reported?

Actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.

When does it start?

The CRA reporting obligations apply from 11 September 2026.

Where do you report?

Submit through the ENISA CRA Single Reporting Platform, not by ordinary email.

Submit once

Your designated national CSIRT initially receives the notification. The SRP also makes it available to ENISA and supports dissemination to other relevant national CSIRTs.

Who needs access?

An Assigned Representative submits on behalf of the manufacturer or open-source software steward.

Registration: screen by screen

These official ENISA reference screens show the complete Assigned Representative registration flow.

1

Choose your role

Select Assigned Representative and continue.

ENISA SRP role selection with Assigned Representative selected — The first screen asks what type of user you are.

2

Select the designated CSIRT

Choose the CSIRT responsible for your organisation.

ENISA SRP designated CSIRT selection screen — The platform provides a searchable list of national CSIRTs.

3

Check personal details

Confirm the details populated from EU Login.

ENISA SRP form showing Assigned Representative personal details — Check first name, last name, email, and legal name before continuing.

4

Add the manufacturer

Enter the manufacturer name, address, and requested additional information.

ENISA SRP manufacturer details form — Required manufacturer fields must be complete before Continue is enabled.

5

Accept a backup invitation

A Secondary Representative reviews the pre-filled organisation details and accepts the invitation.

ENISA SRP invitation screen for a backup Assigned Representative — The invitation link expires after seven days.

Reference screens published by ENISA on 3 August 2026. The live interface may change. View current ENISA registration guidance

Do not register pre-emptively

ENISA advises starting registration when you need to submit a specific notification. CSIRT validation of the representative can continue in parallel and does not prevent submission. Prepare EU Login, roles, and organisation details now.

How to submit a notification

Use one notification record for the full reporting lifecycle.

Notification: screen by screen

Follow the official ENISA screens from the first early warning through the final report.

1

Start a notification

Use Submit new notification from the Dashboard.

ENISA SRP Dashboard with Submit new notification button — A new case is created and pre-filled with your Assigned Representative role.

2

Complete the Early Warning tab

Enter the mandatory information currently available.

ENISA SRP Early Warning notification form — Mandatory fields are marked; optional fields can provide useful context.

3

Select or add a manufacturer

Choose an approved or pending manufacturer, or create a new one.

ENISA SRP manufacturer selector inside an early warning — Manufacturer validation can continue in parallel with reporting.

4

Submit or save a draft

Submit before the deadline or save incomplete work as a private draft.

ENISA SRP notification form with draft and submit controls — A draft is visible only to you and does not satisfy the reporting deadline.

5

Check status before validation

The Dashboard lists the notification while CSIRT validation is pending.

ENISA SRP Dashboard showing a notification before CSIRT validation — Use the Dashboard to reopen the same case for later stages.

6

Check status after validation

The Dashboard reflects the updated validation and notification status.

ENISA SRP Dashboard showing a notification after CSIRT validation — Status changes help confirm where the notification is in the workflow.

7

Add the 72-hour notification

Open the existing case and complete the 72-hour Notification tab.

ENISA SRP 72-hour Notification form — Do not create a separate case for the 72-hour update.

8

Submit the Final Report

Open the same case and complete the Final Report tab.

ENISA SRP Final Report form — After the final report is submitted, the notification becomes non-editable.

Reference screens published by ENISA on 3 August 2026. The live interface may change. View current ENISA notification guidance

The deadlines

The clock starts when your organisation becomes aware of the event.

Within 24 hours

Early warning

Give the initial facts about the actively exploited vulnerability or severe incident.

Within 72 hours

Detailed notification

Provide general information, an initial assessment, impact, and available corrective or mitigating measures.

Vulnerability final report

14 days after a measure is available

Submit no later than 14 days after a corrective or mitigating measure, such as a patch, becomes available.

Incident final report

One month after the 72-hour report

For a severe incident, submit the final report within one month after the 72-hour notification.

Do not use one final deadline for both event types

The vulnerability final-report deadline depends on when a corrective measure becomes available. The severe-incident final report uses a one-month deadline after the 72-hour notification.

Common SRP statuses

Draft

Saved but not submitted. Only you can see it.

Early Warning

The initial notification was submitted successfully.

72h Submitted

The detailed 72-hour notification was submitted.

FR Submitted

The final report was submitted. The case can no longer be edited.

What happens after submission?

The designated CSIRT receives and validates the notification.
ENISA receives the notification through the SRP workflow.
Other relevant national CSIRTs can receive it through dissemination.
National CSIRTs may share necessary information with market surveillance authorities.
You receive email and in-platform confirmation and alerts.

In exceptional circumstances, dissemination may be delayed under CRA Article 16 and Delegated Regulation (EU) 2026/881. A delay does not change your submission deadline.

Prepare before an event

Do the organisational work now. Register in the SRP when a real notification is needed.

Create or verify EU Login for the intended representative. Name a Primary and Backup Assigned Representative. Identify your designated national CSIRT and main place of establishment. Keep legal organisation and manufacturer details ready. Define who starts the 24-hour clock and who approves submission. Prepare product, vulnerability, incident, impact, and mitigation data. Rehearse the 24-hour, 72-hour, and final-report handoffs. Bookmark ENISA's guidance and check it for changes before submitting.

Official ENISA sources

ENISA states that its operational instructions may change. Check the latest version when reporting.

SRP FAQs Reporting factsheet Registration guidance Submission guidance

This page simplifies ENISA guidance and CRA requirements. It is preparation support, not legal advice, and it does not replace the SRP or official instructions.

Ready to prepare?

Use the reporting wizard to organise the information for each notification stage, then submit the official notification in ENISA's SRP.

Prepare a notification Read the Article 14 guide