• Cyberexpert
• RED, EN 18031 and CRA Readiness Guide: Practical Answers from the QIMA Webinar

RED, EN 18031 and CRA Readiness Guide: Practical Answers from the QIMA Webinar

The most useful part of QIMA’s webinar, Navigating EU Cybersecurity Compliance for Connected Products, was the Q&A.

Manufacturers asked about standards, scoping, product variants, CRA reporting, support periods, and documentation. These are the questions that come up when RED cyber and CRA start affecting real products, launch timelines, and technical files.

This article turns those questions into practical guidance for product, engineering, compliance, quality, and certification teams.

QIMA built Cyberexpert for the readiness work described in this article: scoping, requirement mapping, evidence preparation, E.Info support, and expert review before a product reaches formal assessment. The article first explains the decisions manufacturers need to make.

This is an educational recap, not legal advice. Manufacturers should verify product-specific obligations against the official legal text, harmonized standards, and their selected conformity assessment route.

The main lesson: do not start with the standard

A common mistake is to ask first: Which standard should we use?

That is too late in the logic.

The best first question is: What does this product need to prove?

The answer depends on the product boundary, intended use, connectivity, data handled, assets, interfaces, core functionality, and whether RED, CRA, or both apply.

RED cyber requirements come from theRadio Equipment Directive and its cybersecurity-related essential requirements under Article 3(3)(d), (e), and (f), covering network protection, personal data and privacy, and fraud protection. Delegated Regulation (EU) 2022/30 activates these requirements for specified classes of radio equipment, and Implementing Decision (EU) 2025/138 concerns harmonized standards supporting those RED cybersecurity requirements.

CRA is broader. It applies to products with digital elements placed on the EU market when their intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. It also creates manufacturer obligations across design, development, production, maintenance, technical documentation, conformity assessment, support periods, and vulnerability handling.

That means the first deliverable should be a product-specific compliance map.

1. Will EN 18031 be replaced by EN 40000?

Question from the webinar: Will EN 18031 be replaced by EN 40000?

Short answer: Not necessarily.

Gergely Bakos explained in the Q&A that EN 18031 and the EN 40000 series have different scope and coverage. EN 18031 is central for RED cybersecurity compliance. EN 40000 brings in other areas, including vulnerability handling, which is important for CRA readiness.

So manufacturers should not assume that one standard simply replaces the other.

For a radio product in RED cyber scope, EN 18031 may still be the central path for RED. But CRA obligations may require additional work, especially around vulnerability handling, reporting, security updates, and support period planning.

Practical takeaway: standard selection should follow product analysis.

A manufacturer should be able to explain:

• why EN 18031 applies, or does not apply

• whether EN 40000 guidance is needed for additional CRA work

• where vulnerability handling is covered

• where Notified Body involvement may be needed

• which evidence supports each decision

If the answer is only “we use EN 18031,” the standard selection is not documented well enough.

2. RED scoping is where manufacturers can get delayed early

Cédric Lévy-Bencheton’s scoping section was one of the most practical parts of the webinar. His point was clear: RED cyber scope is not always obvious.

A product can raise RED cyber questions when it has a wireless interface and Internet-enabled connectivity, even if the Internet-enabled connection is not wireless.

Example 1:

A device has Bluetooth for setup and Ethernet for network communication. The Bluetooth may be local, but the Ethernet connection can still matter for RED cyber scoping.

Example 2:

A product uses Zigbee and connects through a gateway or mobile app. Calling it “local radio” is not enough. If the app or gateway can control the product remotely, indirect connectivity needs to be reviewed.

Useful caveat: processing personal data does not automatically mean there is a privacy effect in every case. A wireless microphone or amplifier may process audio but not store it. The privacy analysis still depends on what the product does with the data.

Practical scoping test

Before deciding scope, manufacturers should answer four questions:

1. Does the product have any radio interface?

2. Does the product have direct or indirect Internet-enabled connectivity?

3. Can another system, app, gateway, or cloud service control the product?

4. Does the product process, store, transmit, or expose data relevant to network protection, privacy, or fraud protection?

A useful scoping file should include a simple connectivity diagram. It should show wireless interfaces, wired interfaces, mobile apps, gateways, cloud or remote processing, update channels, and service or debug interfaces.

This does not need to be complicated. It needs to be accurate.

3. RED risk assessment and cybersecurity risk assessment are different documents

Question from the webinar: EN 18031 does not provide a risk assessment methodology. Does EN 40000 fill that gap?

Short answer: partly, but not completely.

Cédric explained that EN 18031 includes decision trees and mentions STRIDE, but it does not give manufacturers a complete threat modelling or cybersecurity risk assessment method. EN 40000-1-2 was discussed as guidance for risk management steps, but not as a ready-made method that can be copied into every product file.

The distinction is important.

A RED cyber risk assessment helps determine which RED legal requirements apply.

A cybersecurity risk assessment looks at actual product risk: users, data, interfaces, exposure, context of use, attack scenarios, impact, controls, and residual risk.

Cédric’s camera example makes this simple. The same connected camera can carry different risks in a bedroom, a garden, or a parking lot. The hardware may be similar. The context is not.

A weak risk entry says:

✘ Risk is low.

A useful risk entry says:

✓The Ethernet service interface is used only during installation and maintenance in a controlled physical environment. It is not exposed during normal user operation. This assumption is supported by the service procedure, interface configuration, and installation documentation. Based on this use context, access control is treated as not applicable for this asset and interface.

That kind of entry helps engineering, compliance, and assessors understand the decision.

4. EN 18031 is hard because it is asset-based

EN 18031 is not a flat checklist. It asks manufacturers to think in terms of assets, interfaces, entities, security mechanisms, implementation categories, and decision trees.

Assets can include confidential parameters, sensitive parameters, functions, data parameters, security assets, network assets, privacy assets, and financial assets.

This becomes product-specific quickly.

A secure update function, for example, may include retrieving the update, verifying it, installing it, rolling back after failure, and logging the result. A manufacturer may decide to group those as one secure update function. That can be reasonable, but the grouping must not hide details that matter for assessment.

A practical asset register should capture only the fields that are important:

If the asset register is weak, E.Info, E.Just, and decision tree answers will also be weak.

5. Decision trees need evidence, not guesses

Decision trees are central to EN 18031. Manufacturers use them to decide whether a requirement applies. Assessors use them to determine whether the result is PASS, FAIL, or NOT APPLICABLE.

That means a decision tree path should be documented as a decision record.

A decision record should answer:

• which requirement was assessed

• which asset and interface were involved

• which path was followed

• why the result is PASS, FAIL, or NOT APPLICABLE

• what evidence supports the result

• whether this decision affects other requirements

Example: Ethernet and secure communication

Cédric explained that Ethernet can be difficult because it is usually unencrypted and does not have inherent access control. If access control applies to that Ethernet interface, secure communication requirements may follow.

A weak justification would say:

✘ Ethernet is used only by technicians.

A stronger justification would say:

✓ The Ethernet interface is only accessible during installation and maintenance in a controlled physical environment. It is not exposed to end users during normal operation. Access conditions are described in the user and service documentation. The interface is disabled or restricted outside service conditions. Based on this use context, the access control decision tree path leads to NOT APPLICABLE for this asset and interface. Supporting evidence is provided in the service procedure, interface configuration, and product architecture documentation.

That is the difference between an assumption and assessment-ready evidence.

6. E.Info and E.Just should explain the product clearly

EN 18031 documentation is not just a folder of product documents.

It needs to explain what is implemented, why it is relevant, which asset it protects, which decision path was followed, and where the evidence can be checked.

Cédric highlighted that E.Info and E.Just are used during assessment, so they need input from engineering, development, firmware, product, and compliance stakeholders.

Weak answer:

✘ The product uses encryption.

Stronger answer:

✓ The product uses TLS 1.3 for communication between the device and the cloud service. This protects transmitted configuration data and device status information from unauthorized disclosure and modification. The mechanism applies to the network interface used for cloud communication. The implementation is described in the communication architecture and verified in the security test report. Certificate handling is described in the key management section. Evidence references: architecture diagram A-03, test report T-12, firmware configuration extract F-07.

The stronger answer is better because it tells the assessor what is protected, how it is protected, why it matters, and where to verify it.

7. Product variants can reuse work, but only with a rationale

Question from the webinar: If devices have the same functionality but different form factors, do they need separate compliance checks?

Short answer: you may not need to start from zero, but you need to assess the differences.

Manufacturers should start with the product’s core functionality. If variants share the same core function, some work may be reusable. But form factor differences can still affect cybersecurity requirements or CRA compliance.

For example, a card and a ring may share firmware and core functionality. But they may differ in physical exposure, antenna behavior, battery constraints, update process, likelihood of loss, user interaction, or privacy context.

A short reuse table is enough:

The goal is to avoid repeated work without copying evidence that does not fit the product.

8. CRA reporting starts before full CRA application

Question from the webinar: What is the practical difference between September 2026 and December 2027 under CRA?

Short answer: September 2026 is about reporting. December 2027 is about full application.

As of 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The European Commission explains that reporting includes an early warning within 24 hours, a full notification within 72 hours, and final reports within the applicable 14-day or one-month deadline. Reports are made once through the CRA Single Reporting Platform, which ENISA is tasked with establishing.

The CRA’s main provisions apply from 11 December 2027, while reporting obligations apply from 11 September 2026. The Commission summary also states that reporting obligations apply to all products with digital elements made available on the EU market, including products already placed on the market before 11 December 2027.

Mihály Pajerich’s practical point was that reporting cannot work without vulnerability handling. A manufacturer cannot report what it cannot detect, receive, assess, classify, and escalate.

Minimum process before September 2026

Before the reporting obligation starts, manufacturers should have:

1. A public vulnerability reporting contact or web form.

2. An internal owner for routing reports.

3. A way to identify affected products, versions, and components.

4. A severity and exploitation assessment process.

5. A decision path for reportability.

6. A process for user communication.

7. An incident record template.

This is a practical minimum. It does not need to be perfect, but it needs to be usable.

9. Multiple factories need one reporting decision path

Question from the webinar: Who reports incidents if a company has multiple factories under the same board?

Not every factory should report separately. Factories or sites should have internal reporting routes. A central manufacturer function should assess whether the case must be reported through the Single Reporting Platform. If the manufacturer is outside the EU, the authorized representative, importer, or distributor may be involved depending on the case.

A useful test is a tabletop exercise.

Scenario:

A supplier reports a vulnerability in a communication module used in three products. One product is already on the EU market. One is in production. One is still in development. Active exploitation is unclear. A patch exists, but it has not been tested on every product.

The manufacturer should be able to answer within the reporting timeline:

• which products and versions are affected

• whether the vulnerability is actively exploited

• whether users need mitigation guidance

• whether reporting is required

• who approves the report

• where the evidence is stored

If this cannot be done in a test, the process is not ready.

10. Support period planning affects engineering, not just compliance

Question from the webinar: How should manufacturers decide the correct security support period?

Gergely explained that five years is the default starting point, but the intended lifetime of the product matters. Long-life industrial or OT products may need longer planning.

The CRA legal text requires manufacturers to determine a support period reflecting the time the product is expected to be in use. It also states that the support period shall be at least five years, unless the product is expected to be used for less than five years. Official EUR-Lex text also refers to the requirement that security updates remain available for a minimum of 10 years or for the remainder of the support period.

This affects product planning.

Before launch, manufacturers should know:

• how updates will be delivered

• who maintains security patches

• which supplier commitments are needed

• how third-party component vulnerabilities will be monitored

• how end of support will be communicated

• how long issued security updates will remain available

For long-life products, this decision should involve product, engineering, support, legal, and commercial owners.

Where Cyberexpert fits

The hard part is not reading the regulation. The hard part is collecting product information, mapping requirements, writing usable E.Info and E.Just, connecting evidence to claims, and knowing when expert review is needed.

That is the readiness work Cyberexpert is built to support.

Cyberexpert helps manufacturers structure product information, identify applicable requirements, map E.Info expectations, prepare evidence, involve suppliers, and prepare for self-assessment, expert review, or lab evaluation.

If you are preparing for RED cyber now, or CRA reporting next, use Cyberexpert to check what applies to your product, identify documentation gaps, and prepare your evidence before formal assessment.

A 30-day readiness plan

Week 1: Scope the product

Create a product boundary, connectivity map, data map, interface list, intended use summary, RED scope note, and CRA scope note.

Output: the team knows what product is being assessed and why it may be in scope.

Week 2: Build the EN 18031 base

Create the asset register, entity list, interface map, initial security mechanism mapping, and decision tree assumptions that need evidence.

Output: the team can see where EN 18031 work is clear and where product information is missing.

Week 3: Check evidence gaps

Review E.Info, E.Just, SBOM, HBOM, user manual, configuration documentation, exposed services, update process, logging, test evidence, and architecture diagrams.

Output: the team knows what evidence exists and what still needs work.

Week 4: Prepare CRA vulnerability readiness

Set up the vulnerability reporting contact, CVD policy draft, intake process, component inventory, severity assessment method, reporting owner, user notification process, and incident record template.

Output: the manufacturer has a basic process before the CRA reporting obligation starts.

What is important to remember

The webinar questions point to one practical conclusion:

Manufacturers need to move cybersecurity compliance earlier into product development.

RED cyber can affect market access now. CRA reporting starts before full CRA application. EN 18031 requires product-specific evidence, not generic claims. EN 40000 may help with additional areas, but it does not remove the need to understand the product first.

Before the next RED or CRA planning meeting, manufacturers should be able to answer:

• Is the product in RED cyber scope?

• Is the product in CRA scope?

• What is the product boundary?

• What is the product’s core functionality?

• Which interfaces and connectivity paths exist?

• Which assets need protection?

• Which EN 18031 decision tree paths have been followed?

• Can PASS, FAIL, and NOT APPLICABLE outcomes be justified?

• Are E.Info and E.Just validated by engineering?

• Is there an SBOM or component inventory?

• Is there a public vulnerability reporting contact?

• Who owns CRA reporting internally?

• What is the support period?

• Which evidence can be reused across product variants?

• Is the product ready for self-assessment, expert review, or lab evaluation?

If several answers are unclear, the product is still in the readiness stage.

That is the right time to fix the gaps before they affect assessment, certification, or market access.

To put these steps into practice, download the practical checklist below and use it to review your RED cyber and CRA readiness.