Cyber Resilience Act (CRA) Explained: Who It Affects, Requirements & Penalties

The Cyber Resilience Act (CRA) is the EU’s regulation for ensuring that products with digital elements — hardware and software — are secure by design. If you sell digital, you must secure it. From smart thermostats to SaaS platforms, from IoT sensors to mobile apps, the CRA demands that cybersecurity is built in, not bolted on.

The CRA fills a critical gap: until now, you could sell a connected product in the EU with zero security testing, no vulnerability management, and no commitment to security updates. Those days are over.

Who Does the CRA Affect?

The CRA applies to manufacturers and distributors of products with digital elements placed on the EU market. The scope is enormous:

Products in Scope

Software: Operating systems, browsers, VPNs, password managers, antivirus, firewalls, SaaS platforms, mobile apps, desktop applications
Hardware with digital elements: IoT devices, smart home products, routers, industrial controllers, connected medical devices, wearables
Components: Libraries, SDKs, and firmware that are placed on the market independently

Who Is Responsible

Manufacturers — anyone who develops or has a product developed and places it on the market under their own name
Importers — entities that place a third-country product on the EU market
Distributors — anyone who makes a product available on the EU market without affecting its properties
Open source stewards — specific (lighter) obligations for open source foundations that facilitate commercial software development

Important Exclusions

SaaS-only services (no downloadable component) are excluded — but if your SaaS includes a client app or API library, those components are in scope
Products already covered by sector-specific regulations (medical devices, aviation, vehicles) have tailored requirements

Product Categories

Category	Security Level	Examples
Default	Self-assessment	Most consumer IoT, basic software
Class I (Important)	Third-party or self-assessment with harmonized standards	VPNs, password managers, routers, OS, microcontrollers
Class II (Critical)	Mandatory third-party assessment	Firewalls, intrusion detection, HSMs, smart meter gateways, smartcard readers

Key Requirements

1. Security by Design

Products must be designed, developed, and produced to ensure an appropriate level of cybersecurity. This means:

No known exploitable vulnerabilities at the time of market placement
Secure default configuration (no default passwords, minimal attack surface)
Protection against unauthorized access
Confidentiality of stored and transmitted data
Data integrity
Availability and resilience

2. Vulnerability Handling

Manufacturers must establish a coordinated vulnerability disclosure policy and process:

Accept and process vulnerability reports from any source
Identify and remediate vulnerabilities in a timely manner
Provide security updates for the expected product lifetime (minimum 5 years)
Distribute updates free of charge

3. Software Bill of Materials (SBOM)

This is new for most manufacturers. You must create and maintain a machine-readable SBOM that documents all components in your product, including:

Direct and transitive dependencies
Open source libraries and their versions
Known vulnerabilities in components

4. Incident and Vulnerability Reporting

Manufacturers must report to ENISA (EU Agency for Cybersecurity):

Event	Timeline
Actively exploited vulnerability	24 hours after discovery
Severe incident affecting product security	24 hours after becoming aware
Full vulnerability notification	72 hours with mitigation details

5. CE Marking

Products that meet CRA requirements will carry the CE marking for cybersecurity. Without it, the product cannot legally be sold in the EU market.

6. Security Updates

Manufacturers must provide security updates for the entire expected lifetime of the product (minimum 5 years from market placement). Updates must be automatic by default, with the option for users to opt out.

Why the CRA Matters

Closing the IoT gap: Billions of connected devices with zero security requirements. The CRA changes that permanently.
Supply chain visibility: SBOMs give organizations and consumers visibility into what’s inside their products — no more hidden vulnerable libraries.
Market access: CE marking for cybersecurity becomes mandatory. No compliance = no EU market.
Liability shift: Manufacturers, not users, are responsible for product security. The era of “use at your own risk” is ending.

What Happens If You Don’t Comply

The Fines

Up to €15 million or 2.5% of global annual turnover (whichever is higher) for non-compliance with essential requirements
Products can be withdrawn from the EU market
National market surveillance authorities can order product recalls

A Scenario That Ruins Companies

This is an illustrative scenario based on real product security failures.

A Spanish startup sells a smart home hub to 50,000 European households. The device controls lighting, heating, security cameras, and door locks. It connects to Wi-Fi and is managed through a mobile app.

A security researcher discovers a hardcoded admin password that gives remote access to every device on the network — including live camera feeds. The vulnerability exists in a third-party library the startup never audited. They don’t even know it’s in their product.

Under CRA:

The startup has no SBOM — they can’t identify which products are affected
They miss the 24-hour ENISA reporting deadline by two weeks
They have no vulnerability handling process — the researcher’s report sat in a generic inbox for a month
The CE marking was applied without proper conformity assessment
Market surveillance authority orders a mandatory recall of all 50,000 devices
Fine: up to €15 million
Media coverage: “Smart home cameras exposed to strangers” — the brand is destroyed

The vulnerability was in 50 lines of code in a library they didn’t write. But under CRA, it’s their responsibility.

How to Get Started

1. Inventory Your Products

Identify all products with digital elements that you place on the EU market. Classify them by CRA category (default, Class I, Class II).

2. Create Your SBOM

Document every component in every product: libraries, frameworks, SDKs, firmware. Automate SBOM generation as part of your CI/CD pipeline.

3. Establish Vulnerability Handling

Create a vulnerability disclosure policy, set up intake channels, and define response timelines. You need to be able to receive, triage, and fix vulnerability reports consistently.

4. Plan Security Updates

Ensure you can deliver security updates for at least 5 years after market placement. This affects architecture decisions, support commitments, and business planning.

5. Prepare for Conformity Assessment

Depending on your product category, prepare documentation for self-assessment or engage a notified body for third-party assessment.

The CRA makes one thing clear: if you profit from selling digital products, you’re responsible for their security. Not the user. Not “the community.” You. Start building security in now, or stop selling in the EU market.