Skip to content

EU Cyber Resilience Act (CRA) Guide

Here's a problem you might not have thought about: before the Cyber Resilience Act, most hardware and software products had no mandatory cybersecurity requirements at all. A smart camera, a connected thermostat, a SaaS platform — none of them needed to meet any baseline security standard to be sold in the EU. The CRA (Regulation 2024/2847) changes that, and it's going to affect every company that makes or sells products with digital elements.

The Act entered into force in 2024, with obligations phasing in through 2027. If you make connected devices, operating systems, or even mobile apps sold in the EU, you're in scope.

Which Products Are in Scope

The CRA applies to any product with digital elements — meaning any software or hardware product and its remote data processing solutions — placed on the EU market. This includes:

  • Connected hardware (cameras, routers, smart home devices, wearables, industrial controllers)
  • Standalone software (operating systems, applications, mobile apps, SaaS platforms)
  • Components and sub-assemblies (microprocessors, embedded modules, firmware)
  • IoT and IIoT devices (sensors, gateways, actuators)

Exclusions

Products already covered by sector-specific cybersecurity rules are excluded from most CRA provisions:

  • Medical devices under MDR/IVDR
  • Aviation products under Regulation 2018/1139
  • Motor vehicles under the UNECE type-approval framework (including cybersecurity management systems)
  • Spare parts equivalent to the original product

Product Classification: Default vs Critical

The CRA splits products into three tiers, and the conformity route gets significantly heavier as you move up. Default products — smart speakers, connected kitchen appliances, productivity software, mobile apps — can self-declare using internal control based on harmonised standards. Critical Class I products (operating systems, firewalls, VPNs, identity management) can also self-declare, but only if they apply harmonised standards in full; otherwise they need a notified body assessment. Critical Class II products (smart meters, secure microcontrollers, hardware security modules) require mandatory third-party conformity assessment.

The Commission maintains a delegated act listing specific product types within each class. Expect this list to evolve as the CRA bed in.

Essential Cybersecurity Requirements

Products with digital elements must meet essential requirements across three areas:

Product Security Properties

Products must be secure by default — no default passwords, minimal attack surface, least-privilege principles applied out of the box. Manufacturers need a vulnerability management process throughout the product lifecycle. Updates must be cryptographically signed with tamper protection for critical components. Security features must respect data protection principles (encryption, access controls, secure storage). The attack surface must be minimised — only essential ports and services enabled by default. Products must log security events for forensic analysis. And the update mechanism must be automated, verifiable, and user-notified.

Vulnerability Handling

The CRA's vulnerability reporting timelines are tight. If a vulnerability is being actively exploited, you have 24 hours to report it to ENISA. Confirmed vulnerabilities (even if not exploited) get 72 hours. A final analysis report is due within 14 days. Security updates must be provided to users promptly, and vulnerability advisories must be published either after the fix is deployed or within 90 days, whichever comes first.

Support Period

Manufacturers must define and communicate the support period during which security updates will be provided. The support period must reflect the reasonably expected useful life of the product and be at least 5 years unless the product has a shorter expected lifecycle.

During the support period, manufacturers must:

  • Provide security updates for at least 5 years (or the product's expected lifecycle, if shorter)
  • Maintain a coordinated vulnerability disclosure policy
  • Document vulnerabilities and remediation actions
  • Make vulnerability information available to users and, where applicable, to independent researchers

Vulnerability Disclosure and ENISA Reporting

The CRA establishes a structured vulnerability disclosure framework. Manufacturers must:

  1. Establish a vulnerability disclosure policy — Provide a clear channel for researchers and users to report vulnerabilities, including contact information and expected response times.
  2. Track vulnerabilities — Maintain an internal registry of all reported and identified vulnerabilities, their severity, and remediation status.
  3. Report to ENISA — Submit structured reports for actively exploited vulnerabilities within 24 hours, complete vulnerability reports within 72 hours, and final analysis within 14 days.
  4. Notify users — Inform affected users of vulnerabilities and available fixes. For products sold through distributors, the manufacturer is responsible for ensuring the notification reaches end users.

Software Bill of Materials (SBOM)

Manufacturers must create and maintain a Software Bill of Materials for their products. The SBOM must:

  • List all software components, dependencies, and libraries included in the product
  • Identify each component by supplier, version, and license
  • Be machine-readable (CycloneDX or SPDX format)
  • Be maintained and updated as components change

While the SBOM is not automatically public, manufacturers must provide it to regulators upon request and may share it with notified bodies during conformity assessment.

Conformity Assessment and CE Marking

Classification Assessment Route
Default products Internal control (Module A) — manufacturer self-declares conformity based on harmonised standards
Critical Class I Internal control if harmonised standards are fully applied; otherwise EU-type examination (Module B) + internal control (Module C)
Critical Class II Full quality assurance (Module H) — notified body assesses the manufacturer's quality system and product design

The manufacturer draws up an EU Declaration of Conformity referencing the CRA and affixes the CE Mark. The CRA declaration may be combined with declarations for other applicable legislation (e.g., Radio Equipment Directive, Machinery Regulation, AI Act) into a single DoC.

Penalties

Fines can reach €15 million or 2.5% of global annual turnover for failing to meet essential cybersecurity requirements or failing to provide security updates. Vulnerability reporting failures carry up to €10 million or 2%. Providing incorrect or misleading information to authorities costs up to €5 million or 1%. And market surveillance authorities can order product recalls, withdrawals, or outright bans on top of the fines.

Timeline

The CRA phases in over three years. The regulation entered into force in 2024. Vulnerability reporting obligations started applying in 2025 — including for existing product designs sold after that date. 2026 sees harmonised standards published and reporting obligations fully operational. 2027 is the big one: full application of essential requirements, conformity assessment, and CE marking for all new products.

Products already on the market before the full application date benefit from transitional arrangements. But don't assume that covers you — vulnerability reporting obligations apply from 2025 regardless of when the product was first placed on the market.

Frequently Asked Questions

Does the CRA apply to free and open-source software?

Yes and no. Software developed and supplied outside the course of a commercial activity — including free and open-source software not monetised through a commercial service — is exempt. However, if you integrate open-source components into a commercial product, that product is fully subject to the CRA.

How does the CRA interact with NIS2?

NIS2 is the EU's cybersecurity directive for essential and important entities (energy, transport, healthcare, digital infrastructure). The CRA covers the products themselves. A product that is CRA-compliant supports its operator's NIS2 compliance, but the two frameworks are separate legal instruments with different scopes and enforcement mechanisms.

What if my product receives security updates through a third-party platform?

The manufacturer remains responsible for ensuring updates reach users regardless of the distribution channel. If you rely on a mobile app store, cloud platform, or distributor to deliver updates, your contractual agreements must ensure updates are deployed promptly and verifiably.

Can I sell existing inventory after the CRA's full application date?

Products that were already placed on the market — meaning ownership was transferred or the product was made available for use — before the applicable compliance date can continue to circulate. However, products still in a manufacturer's or distributor's warehouse on that date must comply.