Module 9: Conformity Assessment, CE Marking, and Market Access

Step 1 – Where Conformity Assessment Fits in the CRA Timeline

Under the EU Cyber Resilience Act (CRA), you cannot place covered software products on the EU market until you have shown they comply with the CRA’s essential cybersecurity requirements.

This proof is provided through conformity assessment. Think of it as a structured check that your product:

• Meets the CRA’s security requirements
• Has appropriate technical documentation and risk analysis (see Module 8)
• Is supported by incident and vulnerability processes (see Module 7)

Typical sequence for a manufacturer:

1. Design and risk analysis – Identify cybersecurity risks and mitigation measures.
2. Implement controls – Secure development, vulnerability handling, updates, logging, etc.
3. Prepare technical documentation & SBOM – As required by the CRA (and aligned with other EU laws where relevant).
4. Choose the conformity assessment route – Depends on whether your product is standard, important, or critical under the CRA.
5. Perform assessment – Internal checks or external review by a notified body.
6. Draw up the EU Declaration of Conformity.
7. Affix the CE marking and place the product on the EU market.

Conformity assessment is therefore the bridge between your internal security work and the CE marking that allows EU market access.

Step 2 – CRA Product Categories: Standard, Important, Critical

The CRA uses a risk-based approach. Conformity assessment requirements depend on the product category. (Exact lists and details are defined in the CRA and may be updated by delegated acts, so always check the latest version.)

1. Standard products

These are software products that do not fall into the higher-risk lists. Examples might include:

• A basic note-taking desktop app
• A simple offline image editor

For many standard products, the manufacturer can often use internal control (self-assessment) if they apply harmonised standards or common specifications.

2. Important products

These are products where cybersecurity failure could have significant impact, but not as severe as critical products. Examples (illustrative, not exhaustive):

• Enterprise backup software used by many organisations
• Software components widely reused in other products

Important products typically face stricter conformity assessment than standard ones and may require involvement of a notified body in more cases.

3. Critical products

These are high-risk products where a compromise could have major societal, economic, or safety effects. Examples (illustrative):

• Software for operating critical infrastructure (e.g., energy grid control systems)
• Core network management software for telecoms
• Certain security products (e.g., advanced identity and access management platforms)

Critical products have the most demanding conformity assessment requirements, generally involving third-party assessment by a notified body.

The key idea: The higher the risk category, the more independent and rigorous the conformity assessment must be.

Step 3 – Classify These Products (Thought Exercise)

Consider the following software products. For each one, think about whether it is more likely to be standard, important, or critical under the CRA. There is no single perfect answer, but focus on impact if compromised.

1. Personal fitness tracking app used by individuals on their phones.
2. Hospital patient management system that stores and processes sensitive health data and connects to other hospital systems.
3. Firmware update tool for industrial robots in an automotive factory.
4. Password manager browser extension used by millions of users.

Your task:

• For each product, write down:
• A tentative category (standard / important / critical)
• 1–2 sentences explaining your reasoning based on impact, scale of use, and potential harm.

Then, compare your reasoning with a classmate or imagine how a regulator might argue differently. The goal is to practice risk-based thinking, not to memorize exact lists.

Step 4 – Main Conformity Assessment Routes Under the CRA

The CRA aligns with the New Legislative Framework (NLF) used in other EU product laws. Manufacturers choose among predefined conformity assessment modules. The exact module can vary, but conceptually you will see three main patterns:

A. Internal production control (self-assessment)

Used mainly for standard products (and some important ones) when:

• Relevant harmonised standards or common specifications are applied, and
• The product is not in the highest-risk category.

Manufacturer tasks:

• Perform internal testing and verification.
• Ensure technical documentation and risk analysis are complete and up to date.
• Implement incident and vulnerability processes.
• Issue the EU Declaration of Conformity.

No notified body is required, but the manufacturer is fully responsible.

B. EU-type examination + internal control

Used more often for important and some critical products.

Two stages:

1. EU-type examination by a notified body:

• The notified body examines the product design, documentation, and possibly test results.
• It checks conformity with CRA essential requirements and relevant standards.
• If satisfied, it issues an EU-type examination certificate.

1. Conformity to type based on internal production control by the manufacturer:

• Ensure that every product manufactured matches the approved type.
• Maintain quality and security controls in production.

C. Full quality assurance with notified body involvement

Used typically for critical products.

• The manufacturer implements a comprehensive quality management system (QMS) covering design, development, production, and post-market activities.
• A notified body assesses and audits this QMS and may perform ongoing surveillance.
• The focus is not only on a single product version but on the processes that ensure continuous compliance.

In all cases, the outcome is the same type of legal claim: the manufacturer states, backed by evidence, that the product conforms to the CRA.

Step 5 – Worked Example: Cloud-Based CRM vs Industrial Control Software

Let us compare two fictional products and walk through their likely conformity assessment paths.

Product A: Cloud-based CRM for SMEs

• Hosts customer data
• Used mainly by small and medium enterprises
• Not directly controlling physical processes

Likely category: Standard or lower-end important (depends on scale and integration).

Possible conformity assessment route:

1. Manufacturer applies relevant cybersecurity harmonised standards (e.g., secure development lifecycle, vulnerability handling, encryption practices).
2. Conducts internal testing for authentication, access control, data protection, and secure update mechanisms.
3. Prepares technical documentation and SBOM, including risk analysis and mitigation measures.
4. Uses internal production control (self-assessment) to demonstrate conformity.
5. Issues the EU Declaration of Conformity and affixes CE marking.

Product B: Industrial Control Software for a Power Plant

• Manages critical grid operations
• Directly impacts energy supply and safety

Likely category: Critical.

Possible conformity assessment route:

1. Manufacturer designs the product following stringent security-by-design principles and applies relevant harmonised standards.
2. Establishes a robust quality management system (QMS) for cybersecurity across design, development, and maintenance.
3. Engages a notified body to:

• Review design and technical documentation
• Assess the QMS and incident response/vulnerability handling processes
• Possibly conduct penetration testing or review independent test reports

1. Notified body issues appropriate certificates (e.g., for EU-type examination or QMS approval).
2. Manufacturer ensures ongoing compliance, issues the EU Declaration of Conformity, and affixes CE marking.

This comparison shows how product risk level drives the depth and independence of the conformity assessment.

Step 6 – Notified Bodies and Their Role

A notified body is an independent organisation designated by an EU Member State to carry out conformity assessment tasks under a specific EU law (here, the CRA).

What notified bodies do for CRA products

Depending on the chosen module and product category, a notified body may:

• Review technical documentation and risk analysis
• Assess the manufacturer’s secure development and maintenance processes
• Evaluate incident and vulnerability handling procedures (linking to Module 7)
• Examine test results or perform independent testing
• Audit the manufacturer’s quality management system
• Issue certificates (e.g., EU-type examination certificate, QMS approval)

When you must involve a notified body

You typically need a notified body when:

• Your product is classified as critical, or
• The CRA or related implementing/delegated acts specify that a particular category of important product requires third-party assessment, or
• You do not fully apply relevant harmonised standards or common specifications and need independent verification.

How notified bodies are chosen

• Each Member State publishes a list of notified bodies; the European Commission maintains an EU-wide database (similar to NANDO for other product laws).
• Manufacturers are free to choose any notified body notified for the CRA and the relevant product category.

The presence of a notified body adds credibility and independence to the conformity assessment, especially for high-risk software products.

Step 7 – Quick Check: Do You Need a Notified Body?

Test your understanding of when a notified body is required under the CRA.

Step 8 – From Conformity Assessment to CE Marking and Market Access

Once conformity assessment is successfully completed, the manufacturer can legally claim that the product complies with the CRA.

Key outputs of conformity assessment

1. Technical documentation (including SBOM, risk analysis, test reports)
2. Records of the conformity assessment (internal checks, notified body certificates where applicable)
3. EU Declaration of Conformity (DoC) – a formal document in which the manufacturer:

• Identifies the product and its versions
• States that the product meets the CRA’s essential requirements
• Lists applied standards and specifications
• Identifies any notified body involved

CE marking

After drawing up the DoC, the manufacturer must:

• Affix the CE marking visibly, legibly, and indelibly on the product, its packaging, or accompanying documentation (for pure software, often on the about screen, download page, and documentation).
• If a notified body was involved in certain modules, its identification number may accompany the CE marking (depending on the exact module used).

Market access

With CE marking and a valid DoC:

• The product can be placed on the EU market (made available for the first time) and put into service.
• Other EU Member States must not impose additional national cybersecurity requirements that would contradict or duplicate the CRA for the same aspects (principle of free movement of goods in the internal market).

In short, conformity assessment → DoC → CE marking → EU market access.

Step 9 – Interaction with Other EU Product Safety Frameworks

Software products may fall under multiple EU laws at the same time. The CRA is designed to complement, not replace, other frameworks.

Common overlaps

• Radio Equipment Directive (RED) – for connected devices with radio interfaces (e.g., Wi‑Fi, 5G). Certain RED provisions already address cybersecurity; the CRA extends and systematises requirements for a broader range of digital products.
• Machinery Regulation, Medical Devices Regulation (MDR), In Vitro Diagnostic Regulation (IVDR) – when software is embedded in or acts as a component of regulated machinery or medical devices.
• General Product Safety Regulation (GPSR) – for consumer products not specifically covered by sectoral rules.

How conformity assessment works in overlaps

• A single product may need to comply with multiple sets of essential requirements (e.g., safety under the Machinery Regulation and cybersecurity under the CRA).
• Where possible, manufacturers can combine conformity assessment procedures, so that one technical file and one assessment process demonstrate compliance with several acts.
• The result is still one CE marking on the product, but the Declaration of Conformity must list all applicable EU acts.

Practical implication

Manufacturers should:

• Map all applicable EU legislation early in the design phase.
• Design their QMS and technical documentation to cover overlapping requirements once, not multiple times.

This integrated approach reduces duplication and supports a coherent compliance strategy.

Step 10 – Map the Compliance Path (Thought Exercise)

Imagine you are the compliance lead for a company releasing a smart home energy management app that:

• Controls connected thermostats and smart plugs (radio-connected devices)
• Collects consumption data and sends it to a cloud backend
• Offers a web dashboard to users

Your task:

1. List at least two EU legal frameworks (including the CRA) that might apply to this product ecosystem.
2. For each framework, note:

• One key type of requirement (e.g., cybersecurity, safety, data protection)
• Whether you expect conformity assessment to be mainly internal or to involve a notified body (and why).

1. Sketch a high-level conformity assessment plan:

• What documentation would you prepare?
• Which parts could be reused across frameworks?

This exercise helps you think like a manufacturer who must manage multiple overlapping compliance obligations efficiently.

Step 11 – Review Key Terms

Flip the cards to review the main concepts from this module.