Module 3: Scope and Product Classification Under the CRA

Step 1 – Where We Are in the CRA Journey

In Modules 1 and 2 you learned what the Cyber Resilience Act (CRA) is and when its obligations start to apply.

Now we focus on who and what it applies to:

• Which products with digital elements are in scope
• Which products are explicitly excluded (because other EU laws cover them)
• How products are grouped into standard, important, and critical classes
• Why this classification matters for conformity assessment and market access

> Throughout this module, assume the CRA text as adopted in 2024 and entering into force in 2024–2025, with obligations starting to apply after the transition period (see Module 2). Always check the latest consolidated text and delegated acts for updates.

Step 2 – Core Concept: “Product with Digital Elements”

The CRA does not only apply to traditional software. Its scope is built around the term “product with digital elements” (PDE).

In simplified terms, a product with digital elements is:

> Any software, hardware, or combination of both that has a direct or indirect logical or physical data connection to a device or network.

This includes:

• Standalone software (e.g., a password manager app, a code editor, a CRM SaaS platform)
• Embedded software / firmware (e.g., firmware in a router, smart TV OS, car infotainment system)
• Hardware that relies on software (e.g., smart thermostats, IoT sensors, connected cameras)

It covers both:

• Products placed on the EU market, whether made in the EU or imported
• Products supplied for free or for payment (so open-source components can be in scope depending on how they are supplied and supported)

> Historical note: Earlier EU rules focused on specific sectors (e.g., medical devices, radio equipment). The CRA is broader and aims to ensure baseline cybersecurity for almost all digital products on the EU market.

Step 3 – Quick Classification Warm-Up

Decide whether each item is likely a product with digital elements under the CRA. Answer Yes or No for each, then check the reasoning below.

1. A mechanical wristwatch with no connectivity.
2. A cloud-based project management tool accessed via a web browser.
3. A USB-C charging cable with no chip inside (just power wires).
4. A smart light bulb controlled via Wi‑Fi.
5. A mobile game app distributed via an app store.

Scroll down for suggested answers and explanations.

---

Suggested answers:

1. Mechanical wristwatch – No. No digital elements or connectivity.
2. Cloud-based project management tool – Yes. Software service accessible over a network.
3. Simple USB-C cable (no chip) – No. No processing or software; just a passive component.
4. Smart light bulb – Yes. Embedded software + network connectivity.
5. Mobile game app – Yes. Standalone software distributed to users.

Step 4 – Key Exclusions: What the CRA Deliberately Leaves Out

The CRA is broad, but not everything digital is covered. Some sectors already have special EU cybersecurity frameworks, so the CRA avoids overlap.

Common exclusions (check the latest CRA text for the exact list and wording):

1. Products already fully covered by other EU sectoral legislation, for example:

• Medical devices and in vitro diagnostic medical devices (covered by MDR/IVDR)
• Civil aviation products (covered by EU aviation safety rules)
• Certain motor vehicles (covered by type-approval rules, including UN/ECE cybersecurity regulations)
• Maritime equipment (covered by maritime safety rules)

1. Services that are not products with digital elements, such as:

• Pure consulting services with no software product delivered
• Some telecom services already covered by the European Electronic Communications Code and NIS2 (though telecom equipment itself may still be in scope)

1. Specific low-risk components, where the CRA or secondary legislation clarifies that they are not in scope (e.g., purely passive hardware components with no digital functionality).

> Practical rule of thumb: if a product’s cybersecurity is already comprehensively regulated by another EU law, it may be excluded from the CRA. But do not assume; always check the actual CRA annexes and sectoral laws.

Step 5 – In or Out? Short Scenario Walkthroughs

Let’s apply the scope rules to a few scenarios.

Scenario A – Smart Insulin Pump

A connected insulin pump with embedded software that communicates with a mobile app.

• Sector: Medical device
• Likely status: Excluded from CRA (covered by EU Medical Device Regulation + sectoral cybersecurity requirements)

Scenario B – Consumer Wi‑Fi Router

A home router sold in electronics stores, with firmware updates from the vendor.

• Sector: General consumer ICT product
• Likely status: In scope as a product with digital elements
• Potential classification: Often treated as important due to its role in network security (check CRA annexes and delegated acts)

Scenario C – On‑Premise Accounting Software

A desktop accounting app sold to small businesses, installed locally, with periodic security updates.

• Sector: Business software
• Likely status: In scope (standard product, unless used in critical environments)

Scenario D – Hospital Network Management System

Software used to configure and monitor a hospital’s internal network, including access control.

• Sector: Supports essential services (healthcare)
• Likely status: In scope and may be classified as important or even critical depending on CRA criteria and its impact on essential services.

> In real compliance work, you would map each product to the exact CRA annex and any implementing or delegated acts to confirm its classification.

Step 6 – Risk-Based Product Classes: Standard, Important, Critical

The CRA uses a risk-based classification. Not all products face the same level of cybersecurity scrutiny.

1. Standard products

• Default category for products with digital elements
• Typical examples:
• Office productivity tools
• Most consumer apps and games
• Basic smart home devices (depending on detailed lists)
• Conformity route: Often self-assessment against harmonised standards, unless specific conditions trigger third-party assessment.

2. Important products

• Listed in Annex III of the CRA (and may be updated by delegated acts)
• Typically products that:
• Provide network or security functions (e.g., firewalls, VPNs, identity management software)
• Are used in industrial control systems or critical processes
• Conformity route: Usually requires involvement of a notified body (third-party conformity assessment), unless fully compliant with relevant harmonised standards that allow self-assessment.

3. Critical products

• Listed in Annex IV of the CRA
• Typically products whose failure can have very high impact on essential services or critical infrastructure, e.g.:
• Core network management systems
• High-assurance security modules
• Conformity route: Strongest requirements, typically mandatory third‑party assessment and possibly more stringent documentation and testing.

> The exact lists of important and critical products are in the CRA annexes and may evolve over time. Always consult the latest version and any delegated acts that update these lists.

Step 7 – Apply the Risk Classes to Real Products

For each product, think: standard, important, or critical? Then compare with the suggested reasoning.

1. Password manager app used by individual consumers.
2. Industrial PLC (programmable logic controller) used in a power plant.
3. Enterprise firewall appliance used by ISPs.

---

Suggested reasoning:

1. Password manager app (consumer)

• Likely standard or important, depending on final annex lists and its impact. It protects sensitive data but is not necessarily core infrastructure.

1. Industrial PLC in a power plant

• Likely at least important, possibly critical, because it directly affects the operation of essential services and safety.

1. Enterprise firewall for ISPs

• Likely important or critical, since it is central to network security and may be explicitly listed in the CRA annexes.

Step 8 – Why Classification Matters: Conformity Assessment Impact

Your product’s class (standard / important / critical) directly affects how you prove compliance before placing it on the EU market.

In simplified terms:

• Standard products
• Often: Internal control (self‑assessment) against CRA essential requirements
• You prepare technical documentation and a Declaration of Conformity
• You may rely on harmonised standards to show presumption of conformity

• Important products (Annex III)
• Typically: Conformity assessment with involvement of a notified body (e.g., EU type examination), unless you fully apply relevant harmonised standards that allow internal control
• More rigorous testing and documentation

• Critical products (Annex IV)
• Typically: Mandatory third‑party assessment with a notified body
• Stronger evidence required (e.g., more extensive testing, secure development lifecycle proof)

> For manufacturers, this means classification drives cost, time, and complexity of market access. Misclassification (e.g., treating an important product as standard) can lead to non‑compliance, market withdrawal, or penalties once the CRA applies.

Step 9 – Quick Check: Scope and Classification

Test your understanding of CRA scope and product classes.

Step 10 – Key Terms Review

Flip the cards (mentally) to reinforce the core concepts before we move on.

Step 11 – Mini Case Study: Classify a New Product

Imagine your startup is launching “SecureHome Hub”, a device + app bundle:

• A hub device connected to the home router
• Controls smart locks, cameras, and sensors
• Mobile app for remote access
• Cloud backend for alerts and data storage

Task:

1. Is this likely a product with digital elements under the CRA? Why?
2. Which class is it most likely to fall into (standard, important, or critical)? Give a short justification.
3. What is one consequence of that classification for your conformity assessment strategy?

Take 2–3 minutes to think or jot down answers, then compare with the suggested reasoning below.

---

Suggested reasoning (high level):

1. Yes, it is clearly a product with digital elements: hardware with embedded software, network connectivity, plus associated software services.
2. It likely falls into standard or important, depending on how CRA annexes treat smart home security devices and whether they are seen as having significant impact on security or safety. Because it controls physical access (locks), regulators may lean toward higher scrutiny.
3. If treated as important, you should plan for notified body involvement (unless you can fully rely on relevant harmonised standards) and more extensive documentation and testing before placing it on the EU market.

Step 12 – Summary: How to Approach Scope and Classification in Practice

To determine whether a product is in CRA scope and how it is classified, follow this practical checklist:

1. Identify the product

• What exactly are you offering: hardware, software, cloud service, or a bundle?

1. Check if it is a product with digital elements

• Does it contain software or programmable logic?
• Does it connect to a network or other devices (directly or indirectly)?

1. Check for exclusions

• Is it a medical device, civil aviation product, certain vehicle type, or other sector with its own EU cybersecurity regime?
• If yes, it may be excluded from the CRA.

1. Map to CRA classes

• If in scope, start with standard as the default.
• Check Annex III: if listed, it is important.
• Check Annex IV: if listed, it is critical.
• Monitor delegated acts that can update these lists.

1. Derive conformity assessment route

• Standard: usually self‑assessment, unless exceptions apply.
• Important: typically involves a notified body, unless fully aligned with relevant harmonised standards.
• Critical: mandatory third‑party assessment.

This structured approach will help you, as a future engineer or product manager, to quickly judge whether a given software product is in CRA scope and what level of scrutiny to expect.

In the next modules, you would build on this by learning specific security requirements and documentation obligations for each class.