The EU Cyber Resilience Act (CRA) is reshaping how connected products are built and certified across the European market. But for many manufacturers, one key question remains: Does the CRA actually apply to my product? The regulation covers Products with Digital Elements (PDEs) - but what does that really mean in practice? Not every electronic device is automatically included. The distinction lies in connectivity and digital functionality.

Defining a PDE

According to Article 3(1), a PDE is “a software or hardware product and its remote data processing solutions, including software or hardware components … placed on the market separately.”

In practice, CRA scope is determined by whether the product is intended to connect in normal use (not just technically capable) and by the connection type: logical (API/driver), physical (USB/Ethernet/radio), or indirect (via a hub/gateway). If none of these are intended in normal operation, CRA is typically not triggered. “remote data processing” provided by or under the manufacturer’s responsibility is part of the PDE and can independently bring a product into scope.

The CRA only applies if:

• The product intends to connect - directly or indirectly - to a device or network (Article 2(1)). “Intends” means in normal use; service/debug ports used only in factory are not scope triggers, while USB-C used by end-users for pairing/configuration is.
• It has digital elements (software or programmable logic), not just analog circuitry. Purely electromechanical devices are not PDEs.

*Purely electronic devices with no software (e.g. a passive sensor or a doorbell with only analogue circuits) are out of scope.

*Devices with digital logic and no data connection (e.g. a microcontroller running local software but no wired/wireless interface) are generally out of scope as well.

*As soon as there is a logical or physical data connection in normal use (USB, Wi-Fi, Ethernet, Bluetooth, cloud), the CRA applies.

Trade-fair allowance: You may show non-compliant prototypes or unfinished software if clearly labelled and not made available on the market; time-limited testing is allowed with visible non-compliance notices

How to Classify PDEs Under CRA

Once a product is confirmed to be in scope, manufacturers must classify it into one of the CRA categories:

• Default - Covered by CRA, but not explicitly listed in Annex III or IV. Most consumer electronics and IoT products will start here. (Often eligible for Module A, internal control, if Annex I requirements and Annex VII documentation are fully met.)
• Important Class I (Annex III) - Products with significant cybersecurity functions or smart-home safety/security features. Examples: operating systems, browsers, VPN, SIEM, routers/modems/switches, identity/PAM, network interfaces, MCUs/MPUs/ASIC/FPGA with security functions, and smart locks/cameras/alarms.
• Important Class II (Annex III) – Higher-risk PDEs such as firewalls, intrusion detection systems, hypervisors. (Often includes container/hypervisor layers for isolation.)
• Critical (Annex IV) – Highest-risk PDEs, such as smart meter gateways, secure elements, or hardware security modules. (Expect EU cybersecurity certification at assurance “substantial” when schemes are designated; otherwise follow Important-II routes.)

Class drives the conformity assessment route

• Default: Module A (internal control).
  • What it is: Self-assessment against Annex I; you compile Annex VII technical docs, draw up the EU DoC, and affix CE. No notified body (NB) involvement.
  • What you must show: Risk assessment mapped to Annex I, SBOM + CVD policy, secure update mechanism (auto-security-updates ON by default), test reports, support-period rationale. Keep evidence ≥10 years or the full support period if longer.

• Important I:
  • When Module A is allowed: Only if you fully apply harmonised standards/common specifications or hold a designated EU cybersecurity certificate at assurance ≥ “substantial” for the relevant Annex I requirements.
  • Otherwise: Module B + C (NB performs EU-type examination of design & vuln-handling → you manufacture to type under internal production control) or Module H (full quality assurance with NB auditing your design/production/vuln-handling QMS + surveillance).

• Important II:
  • Always third-party unless covered by designated certification: choose Module B + C or Module H; designated EU cybersecurity certification at ≥ “substantial” can also be used to demonstrate conformity for the covered requirements.

• Critical:
  • Primary route: EU cybersecurity certification (scheme designated by the Commission; typically, assurance “substantial” as a minimum for CRA).
  • If no scheme yet available/applicable: fall back to Important-II routes (Module B + C or Module H)

Applying harmonised standards or Commission common specifications yields presumption of conformity to Annex I.

Operational details that matter in practice (What this means for your engineering workflow)

• Module B (EU-type exam): Notified Body (NB) assesses technical design, secure-development evidence, and vulnerability-handling process; result is an EU-type examination certificate → you then run Module C to control production to the approved type.
• Module H (full QA): NB assesses and surveils your QMS (Quality Management System) covering design, development, production, and vulnerability handling for the product family; suitable if you want to ship frequent variants without re-running Module B each time.
• Documentation & retention: For any route, you must keep the EU DoC and Annex VII file available for authorities ≥10 years or support period, whichever is longer
• Micro/small enterprises: Fees for third-party assessments should be reduced proportionately (Member State measure).

Presumption of conformity (why standards/certification help)

Using harmonised standards or Commission common specifications creates a presumption of conformity for the Annex I requirements they cover. An EU cybersecurity certificate at assurance level “substantial” (or higher) can likewise establish that presumption and, for those covered requirements, remove the need for notified-body involvement in the corresponding modules.

Practical Example: Doorbell

Doorbells are a way to illustrate how CRA scope and classification work:

Example 1: Smart Wi-Fi Doorbell with OTA Updates + Cloud Integration

• In Scope: Yes, it has wireless network connectivity and uses remote data processing.
• Classification:
• If it has a camera or home security features → Important, Class I (Annex III: smart home products with security functions).
• If it’s just a connected notification device (no security role) → Default PDE.
• Why: Communication brings it into CRA scope. Annex III determines whether it rises above Default. (Classification follows product role, not just “has Wi-Fi”.)

Example 2: Doorbell with Local Software Logic but No Network Communication

• In Scope: Normally out of scope - no logical or physical data connection in normal operation.

• Exception: If it includes a data port used in intended use (USB, wired bus for smart home systems) → Default PDE. (End-user intended use matters.)

• Why: CRA applies only when a product is designed for data exchange beyond its own internal logic.

Example 3: Purely Hardware Doorbell (no software, only analog electronics)

• In Scope: Not covered - without any programmable digital elements or connectivity, it is not a PDE under Article 3(1).
• Classification: Out of scope - CRA does not apply.
• Why: The CRA regulates products with digital elements. A purely electromechanical device (button + chime) falls outside scope entirely, regardless of whether it has wiring to a power source and or the actual bell.

Key takeaway:

• Pure hardware / analog electronics → out of scope.
• Digital logic but no connectivity/connection → usually out of scope.
• Digital + connectivity → CRA applies → classification depends on product function (Annex III/IV vs. Default).

What Manufacturers Should Consider

When determining CRA classification, a manufacturer should ask:

1. Scope Check:

• Does the product connect (wired/wireless) to other devices or networks in normal use?
• Does the product connect (wired/wireless) to other devices or networks in normal use?
• Does it rely on remote data processing provided by the manufacturer?
• Are “service” ports part of intended use for end-users (e.g., pairing, syncing)? If yes, they count as physical connections.

2. Product Type Mapping:

• Is the product explicitly listed in Annex III (Important I/II) or Annex IV (Critical)?
• If not, it defaults to Default PDE. (Then select the conformity route — often Module A — and plan evidence early.)

3. Function Over Features:

• Classification is based primarily on what the product is (e.g., “a doorbell,” “a firewall”), not the individual features like “it has Wi-Fi.”
• Communication features determine whether CRA applies at all, but classification depends on product category. (Annex III/IV group by function/security role)

Conclusion

For manufacturers, the key to CRA readiness is systematic classification:

Step 1: Confirm scope (is there connectivity?).

Step 2: Identify the product type and check Annex III/IV.

Step 3: If not listed, it defaults to “Default PDE.”

This structured approach avoids over- or under-classifying and ensures the right conformity assessment pathway is chosen.

Why Training Matters

The Cyber Resilience Act is not just another piece of legislation — it reshapes how products are designed, classified, and maintained across the EU market. Even seemingly simple devices like doorbells can fall into different categories depending on their connectivity and functions. Misclassification or missed obligations could mean blocked market access, financial penalties, or reputational damage. 

Getting CRA right requires more than a quick read of the regulation, it demands structured knowledge and practical guidance