Practitioners working in the EU market are mostly familiar with the CE mark — it is the basic access credential for many products to enter the EU market. However, the CRA (Cyber Resilience Act), which has officially entered into force with its main obligations applied in phases, has caused confusion for many people: Is it a new certification parallel to the CE mark? Are the original CE Declaration of Conformity and CE mark still sufficient? Do we need to affix a new label to the product? This article will clarify the correlation between the two from basic concepts to practical judgment.
Core Literacy: Basic Relationship Between the CRA and the CE Mark
To understand the correlation between the two, we must first thoroughly explain the two core concepts to avoid going astray at the very beginning.
Let’s start with the CE mark. Many people think the CE mark is a “quality certification medal” issued by the EU, and others think all products entering the EU must bear the CE mark — in fact, both are wrong. Its full name is Conformité Européenne, and it is a mark of the manufacturer’s self-declaration, only applicable to products covered by EU harmonized regulations. It represents that the product meets the statutory safety requirements specified in the corresponding regulations, and is the access threshold for corresponding categories to enter the EU market, rather than an official endorsement of product quality. In addition, not all CE categories only require self-declaration: for some high-risk product categories, the conformity assessment must involve an EU-recognized notified body (a third-party compliance audit agency). Simply put, affixing the CE mark means the enterprise promises that “our product has passed the EU safety red line for the corresponding category”; it does not mean how good the product’s quality is, nor do all products need to bear it.
Now let’s talk about the CRA. Its full name is the Cyber Resilience Act, a mandatory cybersecurity regulation issued by the EU for digital products, and it is itself part of the CE harmonized regulatory system. Its core requirements are actually very simple: first, safety protection must be done well at the product design stage to minimize the risk of hacker attacks; second, after the product is launched on the market, if security vulnerabilities are found, the manufacturer must promptly release patches to fix them, and cannot walk away after selling the product.
After understanding the two concepts, let’s look at their core correlation logic: the CRA does not have its own independent certification system, nor does it create a new set of market access procedures. Instead, it directly embeds cybersecurity requirements into the existing CE compliance framework. In other words, as long as your product falls within the scope of the CRA’s jurisdiction, CE compliance must add the requirement of the cybersecurity dimension, and the CE mark can only be affixed after all requirements are met — there is no need to apply for an additional “CRA certificate”, nor to affix a special CRA mark.
Here we must first clarify two common cognitive deviations to help you fix the general direction: first, the CRA is not an independent certification parallel to the CE mark, but a new cybersecurity requirement under the CE compliance framework; second, not all products bearing the CE mark need to comply with the CRA, only products falling within the scope of products with digital elements defined by the CRA need to supplement the corresponding requirements, and purely mechanical products without software are usually not affected.
Applicable Boundaries: Which Products Need to Include CRA Requirements in CE Compliance
Many people think that only products that first comply with traditional CE directives such as RED and LVD need to consider the CRA, but that is not the case — the CRA itself is part of the EU’s CE harmonized regulations, and products that meet its applicable scope will directly trigger the CE mark obligation. To determine whether a product needs to include CRA requirements in its CE compliance, it must meet three core conditions at the same time; if any one is missing, there is no need to comply:
Condition 1: The product is placed on or made available on the EU market in a commercial manner;
Condition 2: It falls under the “products with digital elements (PDE)” defined by the CRA;
Condition 3: It is not within the scope of products explicitly excluded by the CRA.
A special reminder here: the CRA has no exemption based on enterprise size. Even a small company with only a few people must comply as long as its products meet the first two conditions and are not within the exclusion scope, and cannot use “small enterprise” as a reason for exemption. If a product is subject to multiple CE regulations at the same time (such as being bound by both the CRA and the RED Radio Equipment Directive), the CE Declaration of Conformity needs to cover all applicable requirements, and cannot only meet one of them.
Judgment Criteria for Products with Digital Elements
Many people’s understanding of “with digital elements” only stops at “connected to Wi-Fi”. In fact, the CRA’s definition has a clear judgment logic, focusing on three characteristics:
First, the product contains digital elements in the form of software or hardware;
Second, the digital element can directly or indirectly connect to other devices, networks, or data processing environments;
Third, if the product relies on remote data processing services, such services must be an indispensable part of the product’s function realization.
It should be noted that connection forms such as Wi-Fi, Bluetooth, Zigbee, and local area networks, as well as offline firmware updates via USB flash drives and reliance on remote cloud services, are only reference clues for judgment, not absolute standards for automatic inclusion or exclusion. The core judgment basis is always whether the digital element of the product has the ability to directly or indirectly connect to other devices, networks, or data processing environments, or whether it relies on remote data processing services to realize core functions. For example, a purely offline device that only supports firmware updates via USB flash drive and has no connection or data interaction capability of its own needs to be comprehensively judged in combination with its overall functions, and cannot be directly included or excluded just because it supports offline updates.
Common typical covered products include: smart home appliances, smart door locks, home routers, wearable devices such as sports bracelets, connected children’s toys, industrial programmable controllers, independently sold commercial software, as well as functional mobile phone apps and firmware update packages supporting hardware products. Whether they are finally included still needs to be confirmed in combination with functions and the official list.
Products Clearly Not Affected by the CRA
So which products clearly do not need to comply with the CRA? There are mainly four categories:
The first category is purely non-digital products, such as ordinary manual screwdrivers, wired earphones without Bluetooth and built-in software, and traditional power strips without smart charging functions. These products have no digital elements, so naturally there is no need to consider cybersecurity.
The second category is products explicitly excluded by the text and annexes of the CRA and regulated by special regulations, including some medical devices, in vitro diagnostic medical devices, motor vehicles and their related systems, marine equipment, civil aviation-related products, and products specifically used for national defense, national security, or law enforcement activities. The specific scope shall be subject to the list officially published by the EU and the applicable relationship of corresponding special regulations.
The third category is purely non-commercial open source software activities. The application of the CRA to open source software depends on whether it is provided in commercial activities and whether there is commercial systematic support; open source projects released for free by individuals or communities without commercial promotion or systematic commercial support are not directly bound by the CRA, and the liability of open source contributors shall be judged according to the nature of their specific activities. If open source components are integrated into a commercial product and placed on the EU market, the manufacturer of the commercial product shall bear the overall CRA compliance responsibility.
The fourth category is purely general online services. Only when remote data processing services are indispensable for the realization of product functions will they be included in the CRA judgment scope together with the corresponding products; ordinary SaaS office tools and other online services provided independently without being bound to hardware do not fall within the product scope of the CRA.
3-Step Quick Self-Check Method
If you want to conduct a quick preliminary self-check, you can use these 3 steps:
Step 1: Confirm that the product is placed on or made available on the EU market in a commercial manner;
Step 2: Check whether the product falls within the category of products with digital elements;
Step 3: Check the CRA exclusion list officially published by the EU to confirm that the product is not within the exclusion scope.
If all the above are met, the CE compliance of your product must include the cybersecurity requirements of the CRA; if other CE regulations are applicable at the same time, all requirements must also be covered.
Core Correlation Requirements: New Obligations Added by the CRA to CE Compliance
If your product is within the coverage of the CRA, what new obligations are required compared with the original CE compliance? We will sort them out in order from pre-launch to post-launch.
New Content Added to Pre-Launch Technical Documentation
Technical documentation is originally required for CE compliance, and core content related to cybersecurity needs to be added under the CRA framework — these contents do not have to be split into four independent documents, but serve as core modules that need to be covered in the technical documentation to jointly prove that the product meets cybersecurity requirements, mainly including:
The first category is records related to cybersecurity risk assessment. It is not a simple list of vulnerabilities, but needs to cover the threat scenarios faced by the product, attack surface analysis, potential abuse scenarios, vulnerability risk level classification, mitigation measures taken, and the acceptability judgment of residual risks.
The second category is evidence of security design and verification. It is necessary to clearly explain what security designs the product has adopted, such as whether it has default security configurations when leaving the factory (for example, requiring users to change their password on first use instead of using a unified initial weak password), whether there is an access control mechanism, whether data transmission is encrypted, and whether easily attacked entry points are minimized, along with corresponding security test and verification records.
The third category is documentation of vulnerability remediation and security update mechanisms. That is, pre-agreed procedures, time limits, push methods, and user notification mechanisms for remediation in case vulnerabilities are found, covering security support arrangements throughout the entire life cycle.
The fourth category is the Software Bill of Materials (SBOM, which can be understood as the software “ingredient list” of the product). It needs to be established and continuously updated in accordance with the CRA and related implementation requirements, covering software components and dependencies within the specified scope, and provided as required when needed for regulatory inspection or conformity assessment.
New Requirements for the EU Declaration of Conformity (DoC)
The EU Declaration of Conformity (DoC) is a compliance guarantee issued by the enterprise itself, and is also one of the core documents of CE compliance.
For products subject to the CRA, the DoC has two core new requirements: first, the CRA must be clearly listed as an applicable regulation, with fields such as product identification information and conformity assessment basis specified, and all content must be completely consistent with the technical documentation; second, the cybersecurity support period of the product must be clearly marked.
Regarding the cybersecurity support period, there are two key rules: first, the period must cover the expected use time of the product and meet the minimum period requirements specified in the CRA; if it can be proven that the expected use time of the product is shorter than the statutory minimum requirement, it can be set according to the actual expected duration, but reasonable basis must be provided. Second, the support period on the DoC must be completely consistent with the information in the technical documentation and product publicity, and there must be no contradiction such as “the manual states 5 years of support, but the DoC only states 3 years”.
In addition to being specified in the DoC, the cybersecurity support period must also be publicized simultaneously with the product: for physical products, it must be printed on the packaging or in the manual; for software products, it must be placed in a prominent position in electronic documents or on the interface to ensure that users can easily find it.
New Rules for the Use of the CE Mark
Under the CRA framework, there are three core supplements to the rules for the use of the CE mark:
First, products that have not completed CRA compliance assessment shall not bear the CE mark; at the same time, there is no need to additionally affix any CRA-exclusive mark, and the style, size, and affixing position of the CE mark shall follow the original general specifications.
Second, in principle, the CE mark must be affixed to the product or its data plate in a visible, clear, and indelible manner; for products such as pure software that cannot be physically affixed due to their nature, it can be provided in electronic form permitted by the CRA and CE horizontal rules, and must meet the requirements of being visible, readable, and searchable.
Third, the cybersecurity support period must be publicized simultaneously with the product as required to ensure that users and regulatory authorities can easily obtain it.
Post-Launch Continuous Compliance and Subject Liability
Many people think that everything is fine once the CE mark is affixed, but the CRA breaks this perception — it requires full life cycle compliance, and continuous responsibility is required after launch. The statutory obligations of different subjects are clearly divided, and the final responsibility of the manufacturer will not be transferred due to entrusting other subjects:
| Subject | Core Statutory Obligations |
|---|---|
| Manufacturer | Bears the final responsibility for product compliance; responsible for the preparation and retention of technical documentation and DoC; establishes public vulnerability reception channels; reports serious vulnerabilities and security incidents within the statutory time limit; pushes security patches for free during the support period; ensures that EU regulators can contact the corresponding responsible subject |
| EU Authorized Representative | Performs corresponding obligations only within the scope of the manufacturer’s written entrustment, and does not replace the manufacturer’s final responsibility |
| Importer | Verifies whether the product has the CE mark and whether compliance documents are complete before import; non-compliant products shall not be imported; notifies the manufacturer in time when compliance problems are found and cooperates with regulatory investigations and recalls |
| Distributor | Verifies the integrity of the CE mark and compliance documents before sale; non-compliant products shall not be sold; takes measures such as suspending supply and notification when risks are found, and cooperates with regulatory work |
Among them, there are clear statutory requirements for the reporting of serious vulnerabilities and security incidents: manufacturers need to fulfill phased reporting obligations through the single reporting platform designated by the CRA: submit an early warning within 24 hours from the date when they know or should know about a serious vulnerability or security incident that is being actively exploited; submit a complete formal notice within 72 hours explaining the incident situation, impact scope, and measures taken; the submission deadline for the final report varies according to the specific type of vulnerability or incident (such as actively exploited vulnerabilities, serious security incidents, etc.), and shall be subject to EU official rules.
Operation Process: Complete Steps of CE Compliance Under the CRA Framework (with Checkpoints)
Now that we know what to do, we will string these requirements into a complete and implementable process, with clear checkpoints for each step. If you do them properly, you will not miss any items.
Step 1: Determination of Product Scope and Risk Level
This step is the foundation. First, figure out whether it needs to be done and according to what standards.
- Checkpoint 1: Confirm that the product is placed on the EU market in a commercial manner, is a product with digital elements, and is not on the CRA exclusion list. Only when the core premises are met at the same time is it necessary to proceed.
- Checkpoint 2: Against the CRA product list officially published by the EU, determine whether the product belongs to the non-critical category, important category, or critical category. Different categories have different compliance paths.
Step 2: Cybersecurity Design and Verification
After confirming that compliance is required, first integrate security requirements into product design, don’t wait until it’s finished to make up for it.
- Checkpoint 1: Complete the basic security design required by the CRA and complete the vulnerability risk assessment to ensure that security risks are reduced to a level that meets the requirements at the design stage.
- Checkpoint 2: If the product belongs to the important or critical category, verify the conformity assessment path in advance, confirm whether it is necessary to connect with an EU notified body with CRA qualification, and reserve sufficient time for audit or certification. Don’t wait until the product is about to be launched to find one temporarily, which is easy to delay the progress.
Step 3: Organize Technical Documentation and Declaration of Conformity
After the design and verification are completed, organize all materials into standardized compliance documents.
- Checkpoint: The technical documentation includes all new content required by the CRA, the DoC clearly lists the CRA as an applicable regulation, and key information such as product model and support period are completely consistent in the technical documentation, DoC, and product publicity materials, with no contradictions.
Step 4: CE Mark Affixing and Launch Preparation
When the documents are in order, you can make the final preparations before launch.
- Checkpoint: The style and affixing or display position of the CE mark comply with EU general specifications, the cybersecurity support period is publicized as required, and the information of the manufacturer, EU responsible subject, and importer is complete and verifiable, ensuring that regulators can find the corresponding responsible person.
Step 5: Post-Launch Continuous Compliance Maintenance
Product launch is not the end, but the beginning of continuous compliance.
- Checkpoint: The vulnerability reception channel operates normally, serious vulnerabilities can be reported within the specified time limit, security patches can be pushed on time, and cooperate with the daily compliance inspections of EU market surveillance authorities.
Advanced Judgment: Differences in Requirements Under Different Scenarios
The above are general basic requirements. If you want to plan compliance costs more accurately and judge compliance requirements for special scenarios, you also need to understand the differences under different scenarios.
Differences in Compliance Paths by Product Category
The CRA divides products with digital elements into three levels: non-critical category, important product category, and critical product category (simplified expressions for ease of understanding; the official classification shall be subject to the CRA annexes and the EU official list). The higher the level, the stricter the compliance requirements. The specific conformity assessment path will also be affected by factors such as the applicability of harmonized standards and whether there is a corresponding EU cybersecurity certification scheme. The core differences can be referred to in this table:
| Product Category | Core Judgment Basis | Conventional Conformity Assessment Path | Typical Reference Examples |
|---|---|---|---|
| Non-critical category products | Not included in the list of important and critical products in the CRA annexes | Usually, the manufacturer can complete the conformity assessment through internal control, be responsible for the results on its own, and no mandatory third-party participation is required | Ordinary smart home appliances, consumer-grade wearable devices, etc. (final subject to the official list) |
| Important product category | Included in the list of important products in the CRA annexes | If the product fully applies EU harmonized standards, common specifications, or eligible EU cybersecurity certification schemes, internal control procedures can be adopted; if it does not fully apply or lacks corresponding standards/schemes, the technical documentation must be audited by an EU notified body with CRA qualification | Home routers, some industrial control components, etc. (final subject to the official list) |
| Critical product category | Included in the list of critical products in the CRA annexes, with the highest security risk | Stricter conformity assessment procedures apply, usually requiring a notified body to conduct a comprehensive audit, or requiring compliance with the requirements of the EU cybersecurity certification scheme | The specific list is dynamically updated by the EU, subject to official publication |
It should be noted that if the product subsequently adds digital/connected functions, undergoes major design changes, or has its risk level adjusted, the CRA compliance requirements need to be re-evaluated, and the original conclusion cannot be directly applied.
Compliance Judgment for Special Scenarios
There are two common special scenarios that many people tend to judge incorrectly:
The first category is commercial products containing open source components. No matter how many free open source components you use, as long as it is a commercial product launched by you as the manufacturer, you shall bear the overall CRA compliance responsibility, and the liability of open source contributors shall be judged according to the nature of their specific activities.
The second category is software products. Independently sold commercial software falls within the coverage of the CRA and needs to bear the CE mark in electronic form as required; whether purely online services fall within the scope needs to be judged in combination with specific functions — if only online services are provided without being bound to hardware, and the service itself is not an essential part of the product’s functions, it generally does not fall within the product scope; if it is sold bundled with hardware and is a supporting cloud service essential for the product’s functions, it must be included in the compliance scope together with the hardware.
Judgment of the Relationship with Other EU Regulations
Many people confuse the CRA with other EU regulations. In fact, each regulates its own area and does not replace the other. We will clarify the core differences with a table:
| Regulation/Directive | Core Jurisdiction Scope | Target Subjects |
|---|---|---|
| CRA (Cyber Resilience Act) | Cybersecurity of digital products themselves (attack prevention, vulnerability remediation) | Economic operators such as manufacturers, importers, and distributors of CE products with digital elements |
| Other CE directives (RED/LVD/EMC, etc.) | Different safety dimensions of products (radio spectrum, electrical safety, electromagnetic compatibility, etc.) | Products within the corresponding CE scope |
| GDPR | Processing activities such as collection, use, and storage of personal data | All subjects processing personal data of EU users |
| NIS2 | Organizational-level cybersecurity management capabilities of enterprises in key industries | Operators of critical infrastructure and important service providers in EU member states |
Simply put, other CE directives regulate the physical, electrical, wireless and other safety of products, while the CRA regulates the cybersecurity of products. They are all part of CE compliance and need to be met at the same time, not either/or; while GDPR regulates how user data is processed, and NIS2 regulates the enterprise’s own security management, which are completely different regulations from the CRA. Your product may need to comply with several of them at the same time.
Judgment of Transition Period and Time Nodes
Finally, let’s talk about the time issue that everyone is most concerned about: the CRA regulation officially entered into force on December 10, 2024, and different obligations are applied in phases. The core time nodes currently officially confirmed are:
- Obligation to report actively exploited vulnerabilities and serious security incidents: applicable from September 11, 2026;
- Main product cybersecurity compliance requirements (including design, documentation, CE mark, etc.): applicable from December 11, 2027.
Relevant arrangements such as notified body qualification recognition and supporting implementation rules will be gradually implemented before the main obligations take effect, and the specifics shall be subject to the latest official EU text and the implementation arrangements of member states.
The above are the statutory applicable times. From the perspective of enterprise practice, for important and critical category products, since they may involve notified body audits, it is recommended to start compliance work 3-6 months or even earlier to reserve scheduling time — this recommendation is only a reference based on project experience and is not a statutory time node.
Regarding the transition rules for products already on the market, they need to be judged item by item in combination with four conditions: whether the product has been legally placed on the EU market before the applicable date of the corresponding obligation, whether there have been major substantive modifications, whether it has been re-placed on the market in a new version, and whether the obligations of other applicable regulations have changed. Generally speaking, products that have been legally placed on the market before the obligation takes effect and have no major modifications do not need to make up compliance due to the entry into force of the CRA; the continued sale of ordinary inventory generally does not trigger re-compliance, but if the product undergoes major software/function modifications, is re-manufactured, or is re-placed on the market in a new version after the applicable date, it is necessary to re-judge whether it triggers CRA compliance requirements.
Pitfall Avoidance Guide: Common Misconceptions and Violation Consequences
We have sorted out the four most common practical cognitive misconceptions that many people have fallen into. Avoiding them in advance can save a lot of trouble.
- Misconception: Having the CE mark automatically complies with the CRA → Correction: Original CE compliance usually does not cover the cybersecurity requirements of the CRA, and relevant content needs to be separately checked and supplemented.
- Misconception: Only hardware products need to comply with the CRA → Correction: Products with digital elements such as software, firmware, and supporting functional apps may all be bound by the CRA.
- Misconception: The CRA requires that EU institutions must be found for testing → Correction: For non-critical category products, the manufacturer can complete the conformity assessment on its own, and only some important and critical products require the participation of a notified body.
- Misconception: All compliance is completed after affixing the CE mark → Correction: The CRA requires full life cycle compliance, and obligations such as vulnerability management and security updates must be continuously fulfilled after launch.
If you violate the relevant requirements of the CRA, you may face the following statutory consequences:
First, market surveillance measures: products may be refused release, restricted from being placed on the market or sold, required to take corrective measures, removed from shelves, or subject to mandatory recall; the implementation of border control measures depends on the specific product category, the implementation mechanism of member states, and regulatory instructions, and not all violations will be directly detained by customs.
Second, administrative fines: the CRA sets tiered fine caps for different types of illegal acts: for violations of core requirements such as core cybersecurity design, vulnerability management, and conformity assessment, the maximum fine is 15 million euros or 2.5% of the total global turnover in the previous fiscal year, whichever is higher; for violations of other statutory obligations such as reporting obligations and information publicity, a lower tier of fine cap applies; for providing false, incomplete, or misleading compliance information, the fine cap is further reduced. The specific fine standards and implementation rules shall be subject to the official EU text and local regulations of member states.
To quickly avoid pitfalls, remember two practical methods:
First, complete the scope judgment of “CE + CRA” before launch. Don’t wait until the product is fully produced to find that compliance needs to be made up, as the cost of modifying the design and supplementing materials will be much higher then.
Second, if your product belongs to the important or critical risk level, verify the conformity assessment path in advance, confirm whether it is necessary to connect with a notified body with CRA qualification, and reserve sufficient audit time to avoid starting work just before the launch date and delaying the progress.
Learning Summary
By now, you have a complete basic understanding of the correlation between the CRA and the CE mark. Now you can:
- Quickly judge whether a product falls within the coverage of the CRA, and clarify that the CRA is a new cybersecurity requirement under the CE compliance framework, rather than an independent certification system;
- Self-check whether the existing CE compliance misses the core content related to the CRA according to the process, and judge the subsequent compliance path based on the preliminary classification of the product;
- Distinguish the different roles of the CRA from common EU regulations such as GDPR, NIS2, and other CE directives;
- Avoid common cognitive misconceptions and be clear about the core statutory consequences of violations.
The final compliance judgment shall be subject to the official EU text, the actual functions of the product, and the latest applicable list.