Navigating EU Cybersecurity Compliance for Connected Products: Expert Answers to Your RED and CRA Questions

By: QIMA Jul 17, 2026
Consumer IoT
CRA
EN 18031
RED

During our webinar, Navigating EU Cybersecurity Compliance for Connected Products, attendees raised detailed questions about the Cyber Resilience Act (CRA), RED cybersecurity requirements, product classification, conformity assessment, incident reporting, cloud systems, and security support periods.

We answered several questions during the live session. For the main webinar takeaways, including RED scoping, EN 18031 risk assessment, documentation, evidence preparation, and CRA reporting readiness, read our RED, EN 18031 and CRA Readiness Guide: Practical Answers from the QIMA Webinar.

We were unable to cover every question during the session, so our cybersecurity experts prepared the additional answers below.

This article reflects the regulatory and standardization status as of July 2026. CRA reporting obligations apply from 11 September 2026, while the main CRA requirements apply from 11 December 2027.

These answers provide general technical guidance. The correct classification and conformity assessment route for a specific product must be determined using its complete technical documentation, intended purpose, reasonably foreseeable use, connectivity, and security architecture.

Question 1: We have a cold crypto wallet in the form of an NFC card. Its core functions are storing, sending, and receiving crypto assets without KYC. It works through a mobile application using NFC. Which harmonized standards and restrictions may apply?

The closest match under Implementing Regulation (EU) 2025/2392 is likely to be “smartcards or similar devices, including secure elements”, which is a Critical product category.

This is because the card’s core functionality appears to be secure cryptographic key storage and transaction signing in a card form factor. However, a precise classification requires a careful assessment.

What chip is inside the card?

The Annex IV technical description requires the secure element to provide resistance to attacks at least at AVA_VAN.4 under Common Criteria.

Depending on the chip, the product may be classified as follows:

What is the true core functionality of the product as a whole?

According to the draft CRA guidance, classification is based on the single core functionality of the product as a whole.

In this case, the core functionality is more accurately described as secure key storage and transaction signing, rather than sending and receiving crypto assets. Broadcasting the transaction to the blockchain is normally performed by the mobile application, not by the card.

This distinction matters when comparing the product with the technical descriptions in the Implementing Regulation.

What is the conformity assessment route if the product is classified as Critical?

CRA Article 32(4) requires European cybersecurity certification for Critical products. The relevant scheme is expected to be EUCC, which is based on Common Criteria and the applicable Protection Profile for secure elements.

Harmonized standards and EUCC certification can both provide presumption of conformity with the CRA Essential Cybersecurity Requirements, but their use depends on the product category and the applicable conditions.

Two points must be checked before relying on an EUCC certificate for CRA conformity.

1. Alignment between the product boundary and the Target of Evaluation

An EUCC certificate only covers what is included within its defined Target of Evaluation, or TOE.

The manufacturer must verify that the TOE boundary covers everything included in the CRA conformity claim. Depending on the product design, this may include:

2. The required CRA delegated act has not yet been issued

The delegated act defining the conditions under which EUCC provides presumption of conformity with the CRA has not yet been adopted.

Until it applies, Critical products must follow the fallback procedure for Important Class II products. This requires mandatory third-party assessment using Module B plus Module C, or Module H, with a notified body.

The delegated act will also define the required EUCC assurance level, which must be at least “substantial” and may be “high”, depending on the identified risk.

Which planned standards may be relevant?

Both platform-level and application-level standards may be relevant:

At the time of writing, these standards have not been cited in the Official Journal of the European Union as CRA harmonized standards. They therefore do not yet provide presumption of conformity.

The next step is to identify the chip and its Common Criteria certification level, define the precise product boundary, document the mobile application’s role, and map the product’s core functionality against the technical descriptions in Implementing Regulation (EU) 2025/2392.

Once prEN 50764 and prEN 18330 are published, their scope sections should be reviewed carefully to determine how they apply to the specific product and how responsibilities are divided between the secure element platform and the application running on it.

Where classification remains uncertain, the manufacturer should consult the relevant market surveillance authority or conformity assessment body before selecting a conformity assessment route.

Question 2: Will EN 18031 be replaced by EN 40000?

EN 18031 should not be seen as being directly replaced by EN 40000.

Under the Radio Equipment Directive, the preferred approach for demonstrating compliance with the cybersecurity requirements in Articles 3(3)(d), 3(3)(e), and 3(3)(f) is to apply the harmonized EN 18031 series, taking into account the restrictions included in its Official Journal citation.

From 11 December 2027, products covered by the CRA will need to comply with the CRA Essential Cybersecurity Requirements and use standards aligned with or harmonized under the CRA.

EN 40000 is a broader CRA-related standard series with several parts. For example, EN 40000-1-3 focuses on vulnerability handling, while other parts address risk-based compliance processes and generic cybersecurity requirements.

Product-specific security requirements must still be selected based on the product’s risk assessment and classification.

EN 18031 may therefore remain useful technical evidence where its requirements are relevant. However, CRA conformity will require the manufacturer to map the product’s risks and the CRA Essential Cybersecurity Requirements against the applicable EN 40000 parts, product-specific standards, or other justified technical specifications.

Question 3: If we have several devices with the same functionality but different form factors, such as cards and rings, do we need to perform the compliance checks twice?

Each distinct product type, including each form factor, must be covered by the conformity assessment and EU Declaration of Conformity. For a card and a ring, this will normally mean assessing both product types.

However, the practical amount of repeated work depends on the selected conformity assessment module.

Module H, full quality assurance

Module H may be the most efficient route in this situation.

The notified body assesses and certifies the manufacturer’s quality management system covering the relevant product types. Adding a new form factor can then be handled as an extension to the existing quality system, rather than as a complete reassessment from the beginning.

Module B plus Module C

Under Module B plus Module C, a separate EU-type examination certificate may be required for each product type.

However, test results, technical documentation, and other evidence from the first assessment can be reused where the underlying technology is identical, including:

Where the core functionality and security architecture are the same, the additional assessment should focus on the differences introduced by the form factor, such as the physical interface, hardware integration, tamper resistance, and attack surface.

Module H may be the more efficient route for manufacturers planning to place multiple related product variants on the market. The treatment of individual models and product types should be confirmed with the selected notified body.

Question 4: Would a gateway, such as a gateway used to control ZigBee lights, be considered a Default or Important product?

The classification requires a thorough analysis of the product’s core functionality based on its complete documentation.

This includes:

The manufacturer must make this determination. A classification cannot be assumed from the word “gateway” alone.

According to the “fully matches” test described in the draft CRA guidance, the product’s core functionality must fully match the technical description of an Annex III or Annex IV category to qualify as Important or Critical.

For a ZigBee gateway whose documented core functionality is local smart home device control, such as switching or dimming lights, two categories may initially appear relevant.

Router

The technical description for routers requires the product to establish and control data flow between different networks using routing protocol mechanisms and algorithms at the network layer.

A protocol bridge used for device control may fall short of this definition, but the result must be verified against the actual technical implementation.

Smart home products with security functionality

This category applies to smart home products whose core functionality is related to the physical security of consumers, such as connected door locks, cameras, and alarm systems.

Light control does not normally fully match this description.

If the product’s core functionality does not fully match any Annex III or Annex IV technical description, it will generally remain in the Default category.

However, the outcome may be different if the complete product documentation shows that internet-facing routing or an explicit security function forms part of its core functionality.

Question 5: Who should report incidents through the Single Reporting Platform if a company consists of several factories operating under the same brand?

The report should not be submitted separately by each factory.

It should be submitted by the company or legal manufacturer responsible for placing the product on the EU market.

In practice, all factories should report relevant issues internally to one central product security or CRA responsible team.

This central team should:

For reporting purposes, the relevant location is normally the manufacturer’s main establishment in the EU.

This generally means the establishment where the main cybersecurity decisions concerning the product are made. If this cannot be determined, it may be linked to the EU establishment with the highest number of employees.

The company should therefore have one central reporting owner and a clear internal escalation process covering all factories and sites.

Question 6: EN 18031 does not explain how to perform the risk assessment or provide a template. Does EN 40000 fill this gap?

The CRA does not require manufacturers to use one specific cybersecurity risk assessment methodology.

Manufacturers may select their own approach, provided that it enables them to document:

The risk assessment must support the obligations set out in CRA Article 13 and the technical documentation requirements in Annex VII.

Current sources of guidance include:

The developing prEN 40000-1-2 standard is expected to provide a structured risk-based compliance process. However, it should not be treated as one mandatory template that can be applied unchanged to every product.

Question 7: Does the CRA apply to products that connect to each other, such as linked smoke alarms, even if they do not connect to the internet or an application?

Yes, they can fall within CRA scope.

The CRA defines a product with digital elements as a product whose intended purpose or reasonably foreseeable use includes a direct or indirect, logical or physical data connection to a device or network.

An internet connection or mobile application is therefore not required.

Linked smoke alarms that exchange data directly with each other can meet this definition because they have a direct connection to another device or network.

Whether the product is Default, Important, or Critical must then be assessed separately based on its core functionality.

Question 8. How does the CRA affect distributors that add value by installing a custom Windows or Linux operating system image?

Installing a custom operating system image will most likely require the distributor to assess whether it has taken on manufacturer obligations under the CRA.

There are two main situations in which a distributor becomes a manufacturer under CRA Article 21:

A substantial modification is a change that:

A custom operating system image can change:

These changes are likely to affect compliance with the CRA Essential Cybersecurity Requirements and may therefore qualify as a substantial modification.

Where the modification is substantial, the distributor becomes the manufacturer of the modified product and takes on the relevant CRA obligations.

These can include:

The distributor cannot rely only on the CRA compliance of Microsoft, a Linux distributor, or the original device manufacturer. Compliance must be assessed and demonstrated for the final configured product placed on the market.

Question 9. How are cloud systems evaluated under the CRA if we do not use AWS, Azure, or Google Cloud infrastructure?

The cloud provider is not the deciding factor.

What matters is whether the cloud or backend processing qualifies as a Remote Data Processing Solution, or RDPS.

The CRA includes an RDPS within the definition of a product with digital elements when the following conditions are met:

  1. Data is processed at a distance, outside the user’s device or local environment.

  2. The processing solution was designed or developed by, or under the responsibility of, the manufacturer.

  3. Without that processing, the product could not perform one of its functions.

When these conditions are met, the backend forms part of the product with digital elements and must comply with the applicable CRA Annex I requirements.

An RDPS does not need to run on third-party public cloud infrastructure.

Remote processing can qualify as an RDPS when it runs on:

Not using AWS, Azure, or Google Cloud does not create an exemption.

Standalone SaaS, PaaS, or IaaS services designed and developed independently of a specific product generally fall outside the CRA product definition. Other legislation, including NIS2, may still apply to these services.

Manufacturers must assess their backend systems against the RDPS criteria on a case-by-case basis. Where they qualify, they must be included within the product boundary, risk assessment, technical documentation, and conformity assessment.

Question 10. Multimedia controllers in the entertainment industry use Wi-Fi and Ethernet ports to control products. The protocol used, Art-Net, is different from the internet. Are these products within the scope of RED cybersecurity or the CRA?

For the CRA, the relevant point is the definition of a product with digital elements.

A product is within the general CRA scope when its intended purpose or reasonably foreseeable use includes a direct or indirect, logical or physical data connection to a device or network.

A multimedia controller communicating through Wi-Fi or Ethernet can therefore fall within CRA scope, even if the application protocol is Art-Net.

The specific protocol name does not determine whether the product is in scope.

For RED cybersecurity, a more detailed assessment is required.

The manufacturer must assess whether the radio equipment can communicate over the internet, either directly or through other equipment.

Using Art-Net does not automatically place the product outside RED cybersecurity scope. The manufacturer should review the complete connectivity architecture, including gateways, routers, remote control systems, and any possible internet access.

Question 11. Can you provide guidance on selecting the correct security support period?

The default support period under the CRA is at least five years.

However, the manufacturer must also consider the foreseeable lifetime of the product.

A shorter period may be justified where the product is reasonably expected to be used for less than five years. A longer period is required where the product is expected to remain in use for longer.

The support period should consider:

Products used in operational technology, industrial systems, building infrastructure, or other long-life environments may require a support period significantly longer than five years.

The selected support period should be justified in the risk assessment, documented in the technical documentation, and communicated to users.

Question 12. Does the CRA require separate reporting of the same vulnerability for different devices, such as a card and a ring available in several colors?

One report can cover the same vulnerability across all affected product variants.

CRA Article 14 requires manufacturers to report actively exploited vulnerabilities contained in a product with digital elements. The notification must include general information about the products concerned.

The CRA does not require separate reports for every:

If the same vulnerability affects both the card and ring because they share the same firmware, software, secure element, or other vulnerable component, one notification covering all affected variants is appropriate.

The notification should clearly identify all affected:

If the card and ring use different firmware or security implementations and only one is affected, separate reporting may be appropriate because the products are technically different.

The manufacturer should list all affected variants explicitly in the notification. This allows the same report to cover the full affected product family without unnecessary duplicate submissions.

Question 13. Is Cyberexpert a cloud-based platform? Does it use a public API, and how is the consistency of its outputs ensured?

Yes. Cyberexpert is a cloud-based SaaS platform.

Users access it through a secure web interface where product information, assessments, requirements, and evidence are centrally managed.

This allows teams to:

Cyberexpert is designed as an extensible platform rather than a standalone AI application.

It can integrate with external services such as:

The expert answer confirms that external integrations are supported. The availability of a public API and specific integration options should be confirmed directly with the Cyberexpert team.

Consistency of outputs is supported through several layers:

Cyberexpert’s core value comes from its compliance logic and structured workflow. AI assists with the process, but outputs are grounded in controlled sources, product information, and defined assessment rules.

Question 14. Does a smart radio used mainly for internet radio, Spotify, and media playback fall within the CRA?

Yes.

A smart radio falls within CRA scope because its intended purpose includes a direct connection to a network.

The device initiates and maintains bidirectional IP communication. For example, it sends connection and session requests and receives audio stream data.

This constitutes a direct logical connection to a network.

The fact that the product’s main purpose is radio listening or media playback does not remove it from the CRA’s general scope.

Its classification as a Default, Important, or Critical product must be assessed separately based on its core functionality and the technical descriptions in Implementing Regulation (EU) 2025/2392.

Where the product uses Wi-Fi, Bluetooth, or another radio technology, it may also fall within the Radio Equipment Directive and require a separate RED cybersecurity assessment.

Preparing for RED and CRA compliance

Product names and connectivity labels are not enough to determine RED or CRA obligations.

Manufacturers need to define the product boundary, document the product’s core functionality, identify every connectivity path, determine the applicable product category, and connect each compliance conclusion to technical evidence.

Cyberexpert helps manufacturers structure this work, identify applicable requirements, prepare evidence, and determine where expert review or formal conformity assessment is needed.

Start a free Cyberexpert assessment.
Consumer IoT
CRA
EN 18031
RED

Related Articles

QIMA Cyberexpert hero image for a practical guide on RED, EN 18031 and CRA readiness for connected products.

Jul 14, 2026

RED, EN 18031 and CRA Readiness Guide: Practical Answers from the QIMA Webinar
EN 18031
RED
he CRA replaces voluntary standards with mandatory lifecycle security and security-by-design for all digital products. Source: Freepik

May 18, 2026

The CRA as the Cornerstone of the EU Cybersecurity Ecosystem
CRA
Cybersecurity
Europe

Apr 9, 2026

Is Your Radio Device High-Risk? The AI Act & RED Overlap Explained
Certifications
Cybersecurity
RED
/