What is the EU Cyber Resilience Act?

The CRA (Regulation 2024/2847) is an EU regulation requiring manufacturers of products with digital elements to meet cybersecurity requirements throughout the product lifecycle. It covers vulnerability handling, SBOM provision, and incident reporting to ENISA.

When does the CRA take effect?

Reporting obligations start 11 September 2026. All other requirements (vulnerability handling, SBOM, documentation, conformity assessment) apply from 11 December 2027.

Who does the CRA apply to?

Any manufacturer placing a product with digital elements on the EU market, including commercial software, IoT devices, and open-source projects with a commercial activity. SaaS is generally out of scope unless it involves embedded or downloadable components.

What is an SBOM and why does the CRA require it?

A Software Bill of Materials is a machine-readable inventory of all components in your software. The CRA requires it under Article 13(5) and Annex I Part II(1) so that downstream users and market surveillance authorities can identify vulnerable components.

How does Complaro help with CRA compliance?

Complaro helps automate the three hardest parts: classifying your products under CRA Annex III/IV, continuously scanning for known vulnerabilities, and generating pre-filled ENISA-format incident reports when actively exploited vulnerabilities are discovered.

CRA Compliance Checklist: What You Need Before September 2026

The EU Cyber Resilience Act (CRA) vulnerability reporting obligation begins September 11, 2026. Full compliance is required by December 11, 2027. If you manufacture, import, or distribute products with digital elements in the EU, here is exactly what you need to have in place.

This checklist is organized by priority. Start at the top and work your way down.

Phase 1: Know Your Scope (Start Now)

Inventory Your Products

List every product with digital elements that your organization places on the EU market. This includes standalone software, firmware, IoT devices, connected hardware, and software-as-a-service with on-premise components.

For each product, document:

Product name and version
Target market (EU, global, specific member states)
Whether you are the manufacturer, importer, or distributor
Expected product lifetime and support period

Classify Each Product

The CRA defines three risk categories that determine your conformity assessment path:

Default — self-assessment is sufficient. This covers the majority of products.
Important (Annex III) — Class I products (VPNs, SIEM systems, identity management, network tools) and Class II products (firewalls, hypervisors, container runtimes, intrusion detection systems). These may require third-party assessment.
Critical (Annex IV) — hardware security modules, smart meter gateways, and critical infrastructure components. Third-party certification is required.

If you are unsure about classification, err on the side of the higher category and seek legal guidance.

Identify Your Role in the Supply Chain

Your CRA obligations differ based on your role:

Manufacturers bear the full set of obligations: secure design, SBOM, vulnerability handling, ENISA reporting, CE marking, and documentation.
Importers must verify the manufacturer has fulfilled their obligations before placing the product on the EU market.
Distributors must verify CE marking and documentation are in place.

If you modify a product substantially, you may be reclassified as the manufacturer for that product.

Phase 2: SBOM and Vulnerability Infrastructure (By June 2026)

Generate SBOMs for Every Product

The CRA requires a Software Bill of Materials in a machine-readable format. For a detailed walkthrough, see our guide on generating SBOMs for CRA compliance. For each product:

Choose a format: CycloneDX (recommended for security use cases) or SPDX
Generate the SBOM from your build pipeline, not manually
Include all direct dependencies and as many transitive dependencies as feasible
Record component names, versions, and package URLs (purls)
Automate SBOM generation so it updates with every release

Tools that can generate SBOMs: Syft, CycloneDX CLI, Trivy, SPDX SBOM Generator.

Set Up Vulnerability Monitoring

You need continuous monitoring of your dependencies against known vulnerability databases. At minimum, monitor:

NVD (National Vulnerability Database) — the most comprehensive CVE source
OSV.dev — aggregates vulnerabilities per ecosystem with pre-resolved version ranges
CISA KEV (Known Exploited Vulnerabilities) — critical for the 24-hour ENISA reporting obligation, as these are actively exploited

Your monitoring system should alert you immediately when a component in any of your products has a known vulnerability — especially if it appears on the CISA KEV list.

Implement Version-Aware Matching

Not every CVE that mentions a package name affects your version. Your vulnerability matching must be version-aware:

For npm/Cargo ecosystems: use semver range comparison
For Python packages: use PEP 440 version matching
For NVD lookups: use CPE matching with version ranges

False positives erode trust in your process. False negatives on actively exploited vulnerabilities can trigger regulatory consequences.

Phase 3: ENISA Reporting Readiness (By September 2026)

This is the first hard deadline. By September 11, 2026, you must be able to detect and report actively exploited vulnerabilities within 24 hours.

Define Internal Responsibilities

Document who is responsible for:

Monitoring vulnerability feeds for active exploitation
Making the determination that a vulnerability is actively exploited in your product
Drafting and submitting the ENISA early warning within 24 hours
Preparing the 72-hour detailed notification
Completing the 14-day final report
Communicating with affected users

This cannot be an ad-hoc process. Name specific roles and ensure backup coverage.

Prepare Report Templates

The three ENISA report types have specific information requirements:

24-hour early warning: Indication that an actively exploited vulnerability is suspected and preliminary information about the product affected.

72-hour incident notification: General description of the vulnerability, initial assessment of severity, corrective measures taken or planned, and information about whether the vulnerability affects other manufacturers.

14-day final report: Detailed vulnerability description and root cause, severity and impact assessment, complete list of affected products and versions, corrective measures applied, and information shared with users.

Pre-fill as much as possible so your team can focus on the specifics during an incident.

Run a Drill

Before September 2026, simulate an actively exploited vulnerability scenario:

Pick a real CVE from the CISA KEV list that affects a common dependency
Assume it affects one of your products
Walk through the full reporting process within the 24-hour timeline
Identify bottlenecks: who was hard to reach, what information was missing, what tooling gaps existed

Fix whatever breaks during the drill. Then run it again.

Phase 4: Security Practices and Documentation (By December 2027)

Create a Vulnerability Disclosure Policy

Publish a clear policy that tells security researchers and users how to report vulnerabilities in your products. Include:

A dedicated security contact (email or web form)
Expected response time
Your commitment to coordinated disclosure (ISO 29147)
A SECURITY.md file in your code repositories

Implement Secure Development Practices

The CRA requires products to be designed with security in mind. Document and implement:

Threat modeling for new features and products
Secure coding guidelines for your team
Automated dependency updates (Dependabot, Renovate, or similar)
Regular security testing (SAST, DAST, dependency scanning)
Code review processes that include security considerations

Prepare Technical Documentation

For each product, compile:

Description of the product and its intended use
Design and development documentation showing how essential requirements are met
Risk assessment and how identified risks are addressed
SBOM
EU Declaration of Conformity
Instructions for secure installation, operation, and maintenance
Support period and how security updates will be delivered

Apply CE Marking

Once you have completed conformity assessment and compiled technical documentation, apply the CE marking to your product. For default category products, this follows self-assessment. For Important and Critical products, you may need a notified body to certify conformity.

Quick Reference: Deadline Summary

Now — inventory products, classify by risk category, start generating SBOMs
June 2026 — SBOM generation automated, vulnerability monitoring active, internal processes documented
September 11, 2026 — ENISA reporting capability fully operational, 24-hour response tested
December 11, 2027 — all essential requirements met, CE marking applied, technical documentation complete

Tools That Help

SBOM generation: Syft, CycloneDX CLI, Trivy, SPDX tools
Vulnerability monitoring: OSV.dev, NVD API, CISA KEV feed
CRA readiness assessment: cra-scanner (free, open source)
Automated compliance: Complaro — from SBOM analysis to ENISA reporting

Do Not Wait

The companies that struggle with CRA compliance will be the ones that start six months before the deadline. The companies that succeed will be the ones that started a year early.

September 2026 is close. Start with Phase 1 today: inventory your products, classify them, and generate your first SBOM. Everything else builds on that foundation.

Complaro helps engineering teams automate the technical side of CRA compliance. Join the waitlist to get started.