Module 1: Cyber Resilience Act Essentials for Software Manufacturers

1. What is the EU Cyber Resilience Act (CRA)?

The Cyber Resilience Act (CRA) is a new EU Regulation that sets cybersecurity requirements for products with digital elements (PDEs).

Current status (late 2024)

• The CRA was formally adopted in 2024 as an EU Regulation.
• It will apply after a transition period (expected around 2027 for most obligations, with some earlier reporting duties).
• As a Regulation, it is directly applicable in all EU Member States (unlike older Directives that needed national implementation).

Why it was created

• Software and connected devices often reach the market with weak security by design.
• Security updates are inconsistent or stop too early.
• Users (including companies and public bodies) struggle to assess and compare security of digital products.

Main goals of the CRA

1. Ensure that PDEs are secure by design and by default across their whole life cycle.
2. Create common cybersecurity rules for manufacturers, importers, and distributors in the EU market.
3. Improve transparency (e.g., about vulnerabilities, security support period, and software composition).
4. Reduce fragmentation between Member States and align with other EU cybersecurity rules.

Keep in mind: The CRA is part of a broader EU cybersecurity strategy that also includes NIS2, the AI Act, the Data Act, the EU Cybersecurity Act, and sector-specific rules (e.g., for medical devices, cars).

2. CRA in the EU Cybersecurity Strategy (vs NIS2 & others)

To understand the CRA, you need to see where it fits among other EU rules.

CRA vs NIS2 (Network and Information Security Directive 2)

• NIS2 (in force, national transposition by Oct 2024):
• Targets operators of essential and important entities (e.g., hospitals, energy providers, large digital platforms).
• Focus: organizational and operational cybersecurity (risk management, incident reporting, governance).
• CRA:
• Targets products with digital elements and their economic operators (manufacturers, importers, distributors).
• Focus: product-level security (secure design, development, vulnerability handling, documentation).

How they interact

• A hospital (covered by NIS2) using a vulnerable medical device (covered by CRA) faces overlapping risk.
• CRA aims to improve the baseline security of products that NIS2 entities use.
• NIS2 entities still need their own security measures, even if devices are CRA-compliant.

CRA vs other EU rules (high-level)

• EU Cybersecurity Act: Creates EU cybersecurity certification schemes (voluntary or mandatory). CRA may reference such schemes as a way to show compliance for some products.
• AI Act: Focuses on AI systems and their risks (e.g., high-risk AI). If an AI system is embedded in a PDE, both CRA and AI Act can apply.
• Sectoral rules (e.g., Radio Equipment Regulation, Medical Device Regulation, Type-Approval for vehicles): Some already include cybersecurity requirements. CRA is designed to complement, not duplicate, these. In overlapping areas, CRA often provides horizontal (baseline) rules.

Key takeaway:

• NIS2 = secure operation of essential/important services.
• CRA = secure design and lifecycle of digital products placed on the EU market.

3. What is a Product with Digital Elements (PDE)?

The CRA uses the term Product with Digital Elements (PDE) as its central concept.

A PDE is, in simplified terms:

> A product that has digital components (software, or software + hardware) and is connected or can be connected directly or indirectly to a network or another device.

Typical PDEs

• Pure software:
• Operating systems (e.g., Linux distributions, Windows)
• Productivity apps (e.g., office suites, project management tools)
• Developer tools (e.g., IDEs, CI/CD platforms)
• Security software (e.g., antivirus, EDR)
• Software + hardware:
• Smart home devices (cameras, thermostats, smart locks)
• Routers and Wi‑Fi access points
• Industrial control devices (PLCs, SCADA components)
• Connected cars’ onboard units

Key point for software manufacturers

• The CRA explicitly covers standalone software if it is placed on the market as a product (commercial or sometimes even free, if there is an economic activity around it).

What is usually NOT a PDE under CRA (typical exclusions or borderline cases)

• Purely offline software that cannot connect to networks or other devices in any way (rare in practice).
• Custom software developed on order for a single client and not made available as a general product on the market (depends on exact business model).
• Open-source software developed and shared outside a commercial activity (e.g., volunteer-maintained FOSS without paid support or monetization). However, open-source used within a commercial product is still part of that product’s CRA obligations.

When in doubt, ask:

> Is there digital functionality, and is there (direct or indirect) connectivity? Is this offered as a product on the market?

If yes, it is likely a PDE under the CRA.

4. Thought Exercise: Is this a PDE under the CRA?

Consider the following scenarios. For each, decide YES (likely a PDE) or NO (likely outside CRA scope) and briefly justify your reasoning.

1. A mobile game app, distributed via an app store, that connects to a remote server for leaderboards and in‑app purchases.
2. A simple local text editor that never connects to the internet and has no update mechanism, sold as a one-time download.
3. An open-source encryption library published on GitHub by a student, no company involved, no paid support, no monetization.
4. A smart light bulb controlled via a mobile app over Wi‑Fi, sold in EU retail stores.
5. Custom ERP software developed once for a single manufacturing company, with a contract that prohibits resale to others.

Try to answer before reading the sample reasoning below.

---

Sample reasoning (self-check)

1. Mobile game app → YES: standalone software, connects to servers, offered on the market.
2. Local text editor → Borderline: if there is truly no connectivity (no activation, no telemetry, no updates), it may fall outside CRA. In practice, most software has some connectivity.
3. Open-source library (non-commercial) → NO (usually): if there is no commercial activity around it, the CRA typically does not treat the maintainer as a manufacturer.
4. Smart light bulb → YES: hardware + software, network-connected, sold as a product.
5. Custom ERP for one client → Often NO: if it is a one-off service contract and not a general product placed on the market, CRA may not apply as a PDE. But if the developer later sells it as a standard product, CRA becomes relevant.

5. Who is the Manufacturer under the CRA?

The CRA defines roles similar to other EU product rules (e.g., CE-marking frameworks).

Manufacturer

A manufacturer is the natural or legal person who:

• Develops or manufactures a PDE, or has it designed/manufactured, and
• Places it on the EU market under their own name or trademark.

For software, this often means:

• The software company whose name/brand appears on the product and who controls its design and updates is the manufacturer.

Importer

An importer is a person or company in the EU who:

• Places a PDE from a non-EU country on the EU market under the manufacturer’s name or trademark.

Example: An EU company reselling a US-made security camera in the EU, under the original US brand, acts as an importer.

Distributor

A distributor is a person or company in the supply chain, other than the manufacturer or importer, who:

• Makes a PDE available on the market, e.g., retailers, online marketplaces, app stores (depending on the exact role).

Why the role matters

• Manufacturers carry the main obligations: secure design, vulnerability handling, documentation, conformity assessment, CE marking, etc.
• Importers must verify that the manufacturer has met CRA requirements before placing the product on the EU market.
• Distributors must act with due care: e.g., not selling products they know are non-compliant, cooperating with recalls, etc.

If you develop and brand the software and make it available in the EU, you are very likely the manufacturer under the CRA.

6. Practical Examples: Identifying the Manufacturer

Here are some realistic software business models and how CRA roles might apply.

Example A: SaaS project management tool

• A Berlin-based startup develops a web-based project management platform (SaaS) and sells subscriptions to EU customers.
• The platform is accessible via browser and mobile app, and the company’s brand is on all interfaces.

CRA view:

• The platform + apps are PDEs (software with network connectivity).
• The Berlin startup is the manufacturer.
• Cloud hosting provider is not the manufacturer; they are a service provider.

Example B: EU reseller of a US-developed security camera

• A US company designs and develops a Wi‑Fi security camera and sells it under its own brand.
• An EU company imports the camera and sells it in EU retail stores under the US brand.

CRA view:

• US company: manufacturer (non-EU).
• EU company: importer, responsible for checking that the product is CRA-compliant before placing it on the EU market.

Example C: White-label password manager

• Company X in Asia develops a password manager app.
• An EU company Y buys the rights, rebrands it as “SecureVault EU”, and sells subscriptions in the EU under this new brand.

CRA view:

• Company Y (EU) is treated as the manufacturer, because it places the product on the market under its own name or trademark, even though it did not write the original code.
• Company X is typically a supplier to Y.

Example D: Open-source library in a commercial product

• A volunteer project publishes an open-source JSON parser on GitHub (no company, no monetization).
• A commercial company integrates this parser into its cloud backup solution and sells it in the EU.

CRA view:

• The volunteer maintainers are not manufacturers under CRA (no commercial activity).
• The commercial company selling the backup solution is the manufacturer of the PDE and must manage security, including vulnerabilities in the third-party library.

7. Quiz: Are You a Manufacturer under the CRA?

Test your understanding of manufacturer vs importer vs distributor.

8. High-Level Obligations for Software Manufacturers

At a high level, manufacturers of PDEs under the CRA must:

1. Design and develop secure products

• Implement secure-by-design and secure-by-default principles.
• Follow state-of-the-art security practices (e.g., secure coding, threat modeling, secure configuration).

1. Manage vulnerabilities throughout the product life cycle

• Have a vulnerability handling process (e.g., intake, triage, fix, release).
• Provide security updates for a defined support period and communicate this clearly to users.
• Report actively exploited vulnerabilities and incidents to relevant EU bodies within set timeframes (exact timelines are defined in the Regulation and may be further specified by implementing acts).

1. Provide documentation and transparency

• Supply user-facing security information (e.g., configuration guidance, update policy).
• Maintain technical documentation showing compliance with CRA requirements.
• Often, provide information about software components (e.g., open-source dependencies) to support vulnerability management.

1. Conformity assessment and CE marking

• Perform a conformity assessment (self-assessment for most products, third-party assessment for higher-risk classes).
• Affix the CE marking to indicate compliance.
• Keep technical files available for market surveillance authorities.

Details such as risk classes, timelines, and reporting channels are specified in the CRA text and may be refined by delegated/implementing acts and guidance from the European Commission and ENISA.

9. Quiz: CRA vs NIS2 Responsibilities

Distinguish product-focused obligations (CRA) from organization-focused obligations (NIS2).

10. Flashcards: Key CRA Terms

Flip through these cards to review essential concepts from this module.

11. Mini-Assignment: Apply CRA Concepts to Your Own (Hypothetical) Product

Imagine you are part of a startup developing a new software product.

1. Describe your product in 2–3 sentences:

• What does it do?
• Is it standalone software, or software + hardware?
• How does it connect to networks or other devices?

1. Decide if it is a PDE under the CRA:

• What features make it a PDE (or not)?

1. Identify your role:

• Are you the manufacturer, importer, or distributor? Why?

1. List 2–3 CRA-relevant obligations you would need to think about as a manufacturer:

• Example: vulnerability handling process, security update policy, technical documentation.

Write your answers in bullet points as if you were preparing a short internal memo for your team. This exercise helps you connect CRA concepts to practical product decisions.