EU Cyber Resilience Act (CRA): The Essential Guide for Manufacturers

The Cyber Resilience Act — Regulation (EU) 2024/2847 — is the first EU-wide law setting mandatory cybersecurity requirements for products with digital elements, across their entire lifecycle. It entered into force on December 10, 2024, and it does not wait until 2027 to start biting: reporting obligations are already active, and the classification work that determines your compliance path only gets harder to do retroactively.

This guide covers what the CRA actually requires, who it applies to, and — critically — what is still unresolved about how to comply with it, which is a bigger gap than most manufacturers realize.

Does the CRA Apply to You?

The CRA covers any product with digital elements — hardware or software — that has a direct or indirect connection to a device or network. That threshold catches more than most teams expect. Indirect counts: a sensor that only talks to a local gateway is still in scope. Software counts on its own, with no hardware attached.

A handful of sectoral exclusions apply where other EU legislation already covers the ground: medical devices under Regulation (EU) 2017/745, motor vehicles under UN R155 and Regulation (EU) 2019/2144, civil aviation, marine equipment, and products developed exclusively for defense or national security. Free and open-source software supplied outside a commercial activity is also excluded.

Two things trip people up here. First, an exclusion covers the product as regulated by that other legislation — accessories, companion apps, and service tooling built around an excluded product are frequently in scope on their own, even when the core product is not. Second, classification depends on core functionality, not on what is embedded inside the product. A device that happens to contain a secure element does not automatically become a critical product if that is not what the device is fundamentally for.

If you want a fast answer for a specific product, our CRA Scope Check tool walks through this logic step by step and shows the article citations behind each determination.

Product Classification: Default, Important, Critical

Once you are in scope, the CRA sorts products into three tiers, and the tier determines how you are allowed to prove compliance.

Default covers the vast majority of products — anything not specifically listed in Annex III or Annex IV. Self-assessment is available regardless of which technical specification you use to demonstrate conformity.

Important products are listed in Annex III, split into two classes. Class I includes things like identity management systems, browsers, password managers, VPN products, network management tools, firewalls, boot managers, operating systems, routers, and smart home security products. Class II — a narrower, higher-risk band — includes hypervisors, container runtimes, and standalone firewall/IDS/IPS products.

Critical products, listed in Annex IV, are a short list: hardware security modules, smart meter gateways, secure elements, and smartcards. These require mandatory third-party certification regardless of circumstances.

The Commission published the detailed technical descriptions for these categories in Implementing Regulation (EU) 2025/2392 on November 28, 2025 — that is the document to check against if your product's classification is not obvious from the plain-language Annex III/IV list alone.

The Essential Requirements (Annex I)

Whatever tier you land in, every in-scope product has to meet the same baseline requirements, split into two groups.

Product properties require that a device ships without known exploitable vulnerabilities, defaults to secure configuration out of the box, protects against unauthorized access through appropriate authentication, encrypts data in transit and at rest where relevant, detects unauthorized modification of data or software, minimizes the data it processes, resists denial-of-service conditions, and disables unnecessary ports and services by default.

Process requirements cover the manufacturer's side: an automatic security update capability with a user opt-out, and a documented vulnerability handling process covering identification, remediation, and disclosure — including maintaining an SBOM in a machine-readable format.

That second requirement — vulnerability handling — is the one most manufacturers underbuild. It is not a policy document. It is an operational capability: a way for someone to report a finding, a triage process, and a working update mechanism, all before you ever need them.

Conformity Assessment Routes — and a Gap Worth Knowing About

This is the part of CRA compliance most guides gloss over, and it is the part that actually changes what you should do this year.

Default products self-assess regardless of circumstances. Important Class II products and Critical products require a notified body or an EU cybersecurity certification at substantial assurance level — self-assessment is not an option for them at all.

Important Class I products sit in between: self-assessment (Module A) is available, but only if you fully apply harmonised standards cited in the Official Journal, or hold an equivalent certification. And as of this writing, no CRA harmonised standard has been cited in the Official Journal. Seventeen ETSI product-specific drafts exist, along with several CEN horizontal standards, but none has cleared ratification and citation. The Commission has not confirmed a citation timetable, and the realistic expectation among practitioners tracking this closely is that first citations will not land before 2027.

The practical consequence: if you make a Class I product — a password manager, a router, an operating system — the self-assessment shortcut you have been planning around does not currently exist. You are looking at notified body involvement, and notified body capacity is itself a live constraint. Designation of conformity assessment bodies only began in June 2026, and the CRA anticipates sufficient capacity by December 2026 — which means queues are likely to form well before the December 2027 deadline. If your product falls in this band, this is the year to start that process, not the year before the deadline.

Deadlines Already in Effect

September 11, 2026 — reporting obligations apply. Manufacturers must report actively exploited vulnerabilities and severe incidents to CSIRTs and ENISA, on a 24-hour early warning / 72-hour full notification / 14-day final report timeline. This applies to products already on the market, not just new ones — there is no grandfather clause for reporting.

December 11, 2027 — full application. Essential requirements, conformity assessment, CE marking, and technical documentation obligations take effect in full. Products already placed on the market before this date are only pulled into CRA scope if they undergo a substantial modification after it.

Between now and then, treat the essential requirements and classification work as the thing to have finished well ahead of the deadline — conformity assessment queues, especially for notified bodies, are not going to get shorter as December 2027 approaches.

Penalties

Breaches of the essential requirements or manufacturer obligations carry fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. That is comparable in scale to GDPR penalties, and it applies per breach category, not as a single capped exposure.

How to Prepare Now

• Classify your product line. Do not wait for a single flagship product's classification to stand in for the whole catalog — Default, Important, and Critical products in the same portfolio need different assessment paths.
• Build the vulnerability handling process before you need it. A disclosure contact, a triage workflow, and a tested update mechanism are the pieces most commonly missing.
• Start an SBOM practice now, even if your product's classification does not strictly require one yet. It is the fastest way to answer 'are we exposed?' the next time a widely-used component has a critical CVE.
• If you are in the Class I band, start the notified body conversation early. The self-assessment route is not available today, and capacity is a genuine constraint industry-wide.
• Retain documentation for 10 years. Technical documentation under Annex VII has to survive that long, which changes how you should be structuring records now, not retrofitting them later.

Frequently Asked Questions

Does the CRA apply to products already on the market?

Reporting obligations apply to products already on the market as of September 11, 2026. The essential-requirements and conformity-assessment regime generally applies to products placed on the market after December 11, 2027, or existing products that undergo a substantial modification after that date.

Can I self-assess if my product is Important Class I?

Only if you fully apply a harmonised standard cited in the Official Journal, or hold an equivalent EU cybersecurity certification. As of this writing, no such standard has been cited, so this route is not currently open for any product category.

What counts as a substantial modification?

The CRA does not provide a bright-line numeric test; it generally follows the same concept used elsewhere in EU product law — a change that affects compliance with the essential requirements or alters the product's intended purpose. Firmware updates that only patch vulnerabilities are treated differently from changes that add new functionality.

How does the CRA relate to the EU AI Act?

Where a product with digital elements also qualifies as a high-risk AI system, both regimes can apply, and existing cybersecurity certification under CRA-adjacent frameworks can support the AI Act's own cybersecurity requirements under Article 15.

See our EU AI Act readiness guide for the specifics.

Not sure where your product falls? Run it through our CRA Scope Check for a classification and a documented reasoning trail in about two minutes.

If you'd rather talk it through directly, get in touch .