Detailed Explanation of Core CRA Cybersecurity Requirements

If you are a small business making smart hardware planning to sell products to the EU market, or an ordinary consumer living in the EU who has bought internet-connected products like smart cameras and smart door locks, you have most likely heard the term “CRA” recently. Some say it is the EU’s cybersecurity access threshold, some say it will cause many small businesses to exit the EU, and others say having a CE mark equals compliance with the CRA. What exactly is the CRA? Which products must comply? What are its core requirements? In this article, we will break down the core requirements of the CRA from beginner to semi-proficient level, so that whether you are an ordinary user or a practitioner, you can understand and apply them.

Beginner’s Guide: Basic Positioning and Applicable Boundaries of the CRA

Plain-Language Positioning

The full name of the CRA is the Cyber Resilience Act, with the official reference number Regulation (EU) 2024/2847. It is a directly applicable EU regulation — as a Regulation, the CRA applies directly in all member states; however, the establishment of competent authorities, supervision and enforcement, and the application of penalties still rely on supporting implementation rules of each member state.
In plain terms, the CRA sets a mandatory cybersecurity access baseline for products that are placed on the EU market or put into service in the EU, have digital elements, and have direct or indirect connectivity capabilities. It is not a voluntary industry standard for enterprises. It mainly addresses three long-standing problems: first, products with high-risk vulnerabilities are launched directly on the market; second, default configurations are insecure (such as universal default passwords); third, manufacturers do not take responsibility for vulnerability fixes after products are sold, leaving users with no responsible party to contact when problems arise.
Put simply: non-compliant products cannot be sold on the EU market, nor can services be provided within the EU. Being free of charge does not automatically exclude applicability; non-commercial open source has separate limited obligation rules, and specific judgments can refer to the explanation of exemption and simplification scenarios later in this article.

Four-Step Judgment Method for Applicable Scope

What confuses many people most is “does my product need to comply with the CRA?” In fact, you can quickly confirm it with the four-step judgment method, no guessing needed:
Step 1: Check market behavior. Is the product placed on the EU market for sale, or put into service within the EU? Services here are not divided into paid or free. For example, if you have developed a free note-taking app promoted to the EU market, and the provision of this app constitutes a commercial activity, commercial operation, or supporting commercial support, even if the price is 0, it should be included in the CRA applicability assessment. If it is a purely public welfare, non-commercial open source project that does not provide commercial support, it will be assessed separately under the limited obligation rules. If the product is only sold outside the EU and all target users are groups outside the EU, it is not subject to the CRA.
Step 2: Check digital elements. Does the product have digital functional components such as software, hardware, firmware, or embedded systems? For example, an ordinary wooden desk does not, but a smart height-adjustable desk with Bluetooth does; an ordinary mechanical watch does not, but a smart watch does.
Step 3: Check connectivity capabilities. Does the product have the ability to connect directly or indirectly to other digital devices or networks? Note that it is not only WiFi connectivity that counts — being able to connect to a mobile phone via Bluetooth, connect to a computer via USB, or connect to the internet indirectly through other devices all count as having connectivity capabilities. Purely standalone digital products that are completely offline and cannot generate data or physical connections with any other digital devices are not covered by the CRA.
Step 4: Verify exclusions and special rules. First confirm whether the product falls within the clearly defined statutory exclusion scope, then verify whether there are sector-specific alignment or simplification rules to avoid misjudgment.
The currently clearly defined statutory exclusion scenarios include:

1. Products specifically designed, developed, and produced for military, national defense, or national security purposes;
2. Purely offline devices without digital functions;
3. Products made by individuals for their own use and not for commercial purposes.
   In addition, for products covered by sector-specific regulations, free/open source software, R&D and test samples, and small-batch customized products that meet EU thresholds, it is necessary to judge whether they are excluded, aligned, or simplified according to corresponding clauses; they do not fall under “automatic full exemption”.
   A special reminder here: general digital products such as ordinary computers for government office use and ordinary routers for critical infrastructure are not within the exclusion scope and must still comply with the CRA. Do not mistakenly believe that “products used by public authorities are exempt”.

Applicability Relationship with Sector-Specific Regulations

Many people ask: I already comply with GDPR/RED, do I still need to comply with the CRA? What is the relationship between the CRA and other common EU digital sector regulations? It should be noted first that there is no unified “full exemption” conclusion, and specific assessments require item-by-item verification of regulatory clauses. We have compiled the general corresponding relationships to facilitate preliminary judgment:

Sector-Specific Regulation/Rule	Applicability Relationship with the CRA
GDPR (General Data Protection Regulation)	The CRA regulates the cybersecurity protection of the product itself (e.g., whether it can be hacked), while GDPR regulates the privacy protection of personal data (e.g., whether data collection is legal). Overlapping areas require separate compliance, and neither replaces the other
NIS2 (Network and Information Systems Security Directive)	The CRA regulates supply chain entities of digital products (e.g., router manufacturers), while NIS2 regulates operators of critical infrastructure (e.g., power grid companies, banks). If an enterprise meets the requirements of both, it must comply with both simultaneously
RED (Radio Equipment Directive)	It is necessary to verify the exclusion clauses of the CRA and the coverage scope of RED. Non-overlapping security requirements still require separate compliance (e.g., RED regulates radio frequency safety, while the CRA regulates cybersecurity; both usually need to be met)
MDR/IVDR (Medical Device Regulations)	Some medical devices have special exclusion or alignment rules, which require item-by-item verification of specific clauses. There is no default full exemption nor default full applicability
Sector-specific vehicle/aviation safety regulations (e.g., UN R155)	For products covered by UN R155 and aviation safety regulations, first verify the exclusion clauses of the CRA, the coverage scope of sector-specific regulations, and alignment rules. Parts fully covered by sector-specific rules are handled under special rules, while uncovered parts should not be automatically deemed exempt

Effective Date and Transitional Arrangements

The CRA does not require full compliance immediately upon its introduction; it has a clear transitional timeline to give enterprises time to prepare:

• Official entry into force of the regulation: December 10, 2024. The regulation itself officially takes legal effect, but not all specific obligations have come into force yet.
• Early application obligations: Starting from September 11, 2026, the obligation to report vulnerabilities and major cybersecurity incidents will take effect first — that is, from this date, as long as a product is on the EU market, if an actively exploited vulnerability or major security incident is discovered, it must be reported to the regulator as required.
• Full compliance entry into force: Starting from December 11, 2027, all obligations of the CRA will officially come into force, and all applicable products must meet the requirements before being placed on the market.
  There are also some transitional exceptions, such as products already on the market that have not undergone major modifications, and small-batch customized products that meet EU thresholds. The specific applicability must be judged based on the original text of the regulation and the implementation requirements of each member state, and cannot be generalized.

Core Logic: Four Underlying Design Principles of the CRA

All specific requirements of the CRA revolve around four underlying principles. Understanding these four principles allows you to predict the general direction of subsequent detailed rules without memorizing clauses by rote:

1. Security by Design

In plain terms, security must be planned into the early stages of product development, rather than being patched temporarily after the product is made, sold, and vulnerabilities are discovered. Security is a basic attribute of a product, not a premium feature that requires extra payment — for example, it is not allowed to set a rule that “the basic version has no security protection, and you need to buy the premium version for security”.

2. Security by Default

The core is that “out-of-the-box use ≠ out-of-the-box risk”. Users have basic security protection even if they do not change anything when they get the product. The responsibility for security configuration cannot be entirely shifted to ordinary users. For example, in the early years, many routers had a default password of “admin”, and users who did not know how to change it were easily hacked. This situation is explicitly prohibited under the CRA.

3. Full Lifecycle Responsibility

This means that selling a product is not the end of responsibility. Throughout the entire product lifecycle, from design, production, sales to final service termination, manufacturers are responsible for security. It is not acceptable to say “we will not handle vulnerabilities after the product warranty period expires”. As long as the product is still within the security support period, the manufacturer must fulfill its repair obligations.

4. Risk-Based Classification

This means that the greater the harm a product can cause if attacked, the stricter its security requirements and the more complex its compliance process. For example, core network equipment used in hospitals, which may affect patients’ life safety if attacked, has much stricter requirements than ordinary smart desk lamps. This not only concentrates regulatory resources on high-risk products, but also avoids adding unnecessary costs to low-risk products, preventing a one-size-fits-all approach.

Core Requirements: Full Breakdown of Basic Cybersecurity Requirements in Annex I

Based on the four principles above, Annex I of the CRA clarifies the basic cybersecurity requirements that all applicable products must meet, which are mainly divided into four categories:

Risk and Vulnerability Management Requirements

This part ensures the security and controllability of products from a process perspective:
First, a cyber risk assessment must be conducted during the design phase to identify possible attack scenarios and develop protective measures in advance. For example, when developing a smart door lock, issues such as “what if the password is brute-forced” and “what if fingerprint data is leaked” must be considered, and protections must be implemented in advance.
Next, a full-process vulnerability management mechanism must be established: there must be a clear vulnerability handling policy, a designated security contact point, and a coordinated vulnerability disclosure process — which is commonly known as the white hat reporting channel. When security researchers discover vulnerabilities in good faith, they have a formal channel to submit them, and manufacturers cannot ignore them nor sue them arbitrarily.
When handling vulnerabilities, priorities must be ranked according to risk level, with high-risk vulnerabilities fixed first; after fixing, it must be verified that the fix is actually effective, and the situation must not be made worse by the fix; there must also be a patch rollback plan, so that if installing a patch makes the product unusable, users can revert to the previous version.

Supply chain security is also very important: manufacturers must grasp the source and known vulnerability status of all software and hardware components used in their products. Software component management can be assisted by a Software Bill of Materials (SBOM) — an SBOM is a machine-readable list that usually records information such as software components, versions, suppliers, and dependency relationships, facilitating the tracking of direct dependencies and related component vulnerabilities; the specific depth of maintenance shall be determined according to product risk, applicable standards, and regulatory requirements. It is necessary to particularly clarify the boundaries of SBOM: it is only an auxiliary tool for vulnerability management. Submitting an SBOM does not equal compliance, nor does it require manufacturers to disclose all source code or all indirect dependencies. Do not be misled by false information.
Regarding coordinated vulnerability disclosure, one more point should be added: it only provides a certain legal protection orientation for good-faith security research activities, and does not exempt all vulnerability reporting behaviors from liability. If someone uses a vulnerability to steal user data or engage in extortion, that is definitely illegal and not protected.
Finally, if a product is to be terminated from support (i.e., stop receiving updates), the residual security risks must be assessed before service termination. If there are risks, users must be informed of the specific situation and mitigation solutions, for example: “This product will no longer receive security updates starting next year. It is recommended that you replace it with a new product, or turn off the remote management function to reduce risks.”

Product Security Protection Requirements

This part covers the security functions that the product itself must have:
First, identity and access control: Universal default passwords are prohibited (e.g., the administrator password for all products is 123456); the permissions of administrators and ordinary users must be separated, so that ordinary users cannot modify core system settings; high-risk operations (such as changing the administrator password, remotely resetting the device) require strong verification, such as two-factor authentication or SMS verification codes.
Second, data and communication security: Sensitive data must be encrypted during transmission and storage, and the encryption strength must match the risk level and data sensitivity — low-risk consumer devices also cannot use obviously outdated or easily cracked protection measures; the specific encryption strength shall be determined based on whether the data involves personal information, remote control capabilities, the impact after an attack, and applicable harmonized standards. Scenarios such as smart door locks, cameras, and identity credentials usually require higher-strength protection.
Third, attack surface minimization: Unnecessary ports, services, and remote management interfaces must be turned off by default. Functions that can be left disabled should be left disabled to reduce the possibility of attack; undisclosed backdoor access permissions must never be reserved — that is, manufacturers cannot secretly leave a “backdoor” known only to themselves to access users’ devices.
Fourth, security update mechanism: Products should have secure, verifiable, and tamper-proof update capabilities; for products with internet or remote maintenance capabilities and for which risk assessments require remote vulnerability fixes, remote security patch pushing should be supported. The CRA does not require all products to support indefinite remote updates, but necessary security updates must be provided to users during the security support period.
Fifth, logging and recovery capabilities: Necessary security logs must be retained (such as who attempted to log in to the administrator account, and whether there are failed login records), but data protection requirements must also be taken into account, and irrelevant user privacy must not be collected; there must also be fault recovery and post-incident function restoration capabilities, so that the product cannot be completely scrapped after an attack and can be restored to normal use.

User Information Disclosure Requirements

This refers to the security-related information that manufacturers must proactively inform users of:
Three pieces of information must be publicized before purchase: how long security updates will be supported, what known safe usage restrictions there are (e.g., “This product is only suitable for use in home environments and is not recommended for industrial scenarios”), and the access channel for the EU Declaration of Conformity (DoC).
When users use the product for the first time, they must be guided to set up a secure identity verification method. For example, when setting up a router for the first time, users must be forced to change the administrator password and cannot skip this step.
There must also be regular security channels. For example, the official website must have a dedicated security bulletin page for publishing vulnerability notifications, patch download links, and safe usage tips, which users can find at any time.

Security Support Period Requirements

This is also the content that many users and businesses are most concerned about:
In principle, the security support period must match the expected service life of the product, and usually cannot be less than 5 years. If your product’s expected service life is shorter than 5 years, such as some low-cost children’s smart watches that are expected to be replaced after 3 years of use, there must be a reasonable and verifiable basis. You cannot arbitrarily say “our product is only used for 2 years” without basis.
Manufacturers must clearly publicize the length of the security support period, and must provide security updates during the support period without excuses.
As for how long in advance users must be notified before support is terminated, this is still to be determined by subsequent implementation rules and product risk levels. There is no unified number of days requirement, but updates definitely cannot be stopped suddenly, and users must be given time to prepare.

Differentiated Rules: Product Classification, Market Roles, and Exemption Scenarios

Are the compliance requirements the same for all products? Of course not. The CRA divides products into different categories according to risk level, and the responsibilities of different market roles are also different. There are also some exemption and simplification scenarios, which we will explain one by one.

Product Classification Rules

The classification basis must be strictly judged according to the product functions and uses listed in Annex III and Annex IV of the CRA, and cannot be classified based on the product name or one’s own subjective feeling — for example, even if both are called routers, home-use routers and those used for critical infrastructure have completely different grades.

We have compiled the core differences of the four grades into a table for easy comparison:

Product Grade	Risk Level	Classification Basis	Conformity Assessment Method	Reference Examples
Ordinary Digital Products	Low risk	Not listed in Annex III or Annex IV	Enterprise self-assessment of compliance is sufficient	Ordinary consumer-grade smart desk lamps, non-sensitive utility apps
Class I Important Products	Medium risk	Listed in Annex III	For those that meet applicable harmonized standards/common specifications/cybersecurity certification schemes, internal control assessment can be used; for those that do not, third-party notified body intervention is required	Home routers, ordinary identity management software
Class II Important Products	Medium-high risk	Listed in Annex III	Usually requires third-party notified body participation in conformity assessment	Some medical wearable devices, industrial network management tools
Critical Products	Very high risk	Listed in Annex IV	Must be certified by a third-party notified body in combination with Annex IV requirements and applicable certification schemes before being placed on the market	Core network equipment for critical infrastructure, high-risk identity verification systems

Note: The examples in the table are only for helping understand risk levels and do not constitute final classification conclusions. Products with the same name may fall into different categories due to differences in function, use, and deployment scenarios. The final classification shall be subject to the items listed in Annex III/IV of the CRA, applicable harmonized standards/common specifications, and subsequent supporting rules.
Put simply, the higher the product grade, the stricter the compliance assessment process, and the more detailed the technical documents that need to be prepared. Currently, the critical product categories in Annex IV are still relatively principled, and will be further refined through supporting rules in the future.

Division of Responsibilities for Different Market Roles

Many people are confused: “I am an OEM, do I need to be responsible? I am a platform seller, do I need to be responsible?” In fact, there is only one core criterion for judging responsibility: whether you place the product on the EU market or put it into service.

• Manufacturer: The core responsible entity, responsible for the entire process from design compliance, conformity assessment, and CE marking to post-market security maintenance.
• Authorized representative: An entity designated by the manufacturer within the EU, which performs part of the compliance cooperation obligations on behalf of the manufacturer, such as being contactable when regulatory authorities come to inquire.
• Importer: An entity that introduces products into the EU market from outside the EU. It must verify that the manufacturer has completed compliance, and non-compliant products cannot be imported.
• Distributor: That is, retailers and platform sellers. They must check the product’s labeling and compliance documents, and cannot sell products that they know are non-compliant.
  There is also a special type of responsible entity: if you make major modifications to a product already on the market, or re-sell someone else’s product under your own brand, you must bear all the responsibilities of a manufacturer and cannot shift the blame to the original manufacturer.

Exemption and Simplification Scenarios

It is important to pay attention to the boundaries here. Many people think that “exemption” means you don’t have to worry about it, but in most cases it is only partial simplification, not full exemption:
The first category is products covered by sector-specific regulations: the principle of “no repeated compliance for overlapping parts, and uncovered parts still need to be met” applies. It is necessary to verify the exclusion/alignment clauses of sector-specific regulations and the CRA item by item, and full exemption cannot be directly presumed.
The second category is special rules for free/open source software: if it is a free open source project that is purely public welfare, non-commercially distributed, and does not provide commercial support, the project maintainers only bear limited vulnerability cooperation and documentation obligations, and do not have to bear full manufacturer responsibilities. However, if it is commercially distributed open source software, open source components are integrated into one’s own commercial product, or paid support is provided for open source software, then compliance must be carried out as required, and the manufacturer’s responsibility cannot be shifted to the maintainers of the open source community — for example, if you use the open source Linux system to make a router, you are responsible for any vulnerabilities, and you cannot ask users to go to the open source community.
The third category is R&D and test samples, and small-batch customized products that meet EU thresholds. Some compliance processes can be simplified, but compliance is not completely unnecessary.
The fourth category is micro and small enterprises: note that micro and small enterprises only enjoy some procedural conveniences and guidance support. Core security requirements, vulnerability handling obligations, technical document preparation, and incident reporting obligations cannot be exempted. Do not think that just because your company is small, you don’t have to worry about the CRA.

Post-Market Obligations: Vulnerability Response and Incident Reporting Processes

Many people think that compliance is just completing the assessment and affixing the CE mark before the product is launched. In fact, a large part of the CRA’s obligations are after the product is on the market — after all, “full lifecycle responsibility” is one of the core principles.

Basic Rules for Vulnerability Response

Manufacturers must set up public vulnerability reporting channels and clarify coordinated disclosure policies, so that security researchers know how to report vulnerabilities and how they will be handled after reporting.
After receiving a vulnerability report, it must be verified and handled in a timely manner according to the risk level, repair feasibility, and impact on users, and cannot be delayed.
After the vulnerability is fixed, users must be informed of the patch information through security bulletin channels, as well as any temporary mitigation measures if the fix cannot be implemented temporarily, for example: “You can turn off the remote management function first, and we will release a patch next week.”
Malicious retaliation against good-faith vulnerability reporters is absolutely prohibited. For example, if someone reports a vulnerability in good faith and you sue them instead, this violates the requirements of the CRA.

Reporting Requirements for Actively Exploited Vulnerabilities

That is, when it is discovered that a vulnerability has been actively used by attackers to launch attacks, or there is a risk of large-scale attacks, it must be reported to the regulator:

• Reporting channel: Submit to the Computer Security Incident Response Team (CSIRT) of the relevant member state or the European Union Agency for Cybersecurity (ENISA) through the EU single reporting platform.
• Time nodes: Submit an early warning within 24 hours of becoming aware of the situation (first inform the regulator of the incident), submit a formal notification within 72 hours (explain the detailed situation), and submit a final report within 14 days after security updates or corrective measures are available.
• Report content: includes the basic situation of the vulnerability, scope of impact, measures already taken, subsequent repair plans, etc.

Reporting Requirements for Major Cybersecurity Incidents

That is, when a major incident occurs that affects the normal use of the product or user safety, such as a large number of smart cameras being hacked leading to user privacy leakage:

• The reporting channel is the same as above: the EU single reporting platform, submitted to the member state’s CSIRT or ENISA.
• Time nodes: Submit an early warning within 24 hours of becoming aware, submit a formal notification within 72 hours. The deadline for the final report shall be determined according to the complexity of the incident and the requirements of the regulatory authority, and is not fixed at 14 days.
• Report content: includes the basic situation of the incident, scope of impact, handling measures, subsequent prevention plans, etc.

User Notification Obligation

If a vulnerability or incident affects users’ safe use, users must be promptly informed of the risk situation, temporary mitigation measures, and how to obtain security updates. Security risks that have a direct impact on users must not be concealed.

Full Compliance Chain: Implementation Steps from Design to Market Launch

For merchants and developers, what steps should be followed from product design to market launch to meet the CRA requirements? We have compiled the full chain implementation steps, corresponding to the technical document requirements in Annex V and the assessment process in Annex VII of the regulation. Following these steps will prevent confusion:

Preliminary Assessment Phase

First, use the four-step judgment method mentioned earlier to confirm whether the product falls within the applicable scope of the CRA; then determine the product’s classification grade according to the content of Annex III and IV; finally, clarify what market role you are and what corresponding responsibilities you need to bear.

Design and Production Phase

Against the basic security requirements of Annex I, conduct a risk assessment and implement protective measures into product design and production; sort out all components in the supply chain, and establish an SBOM and vulnerability management mechanism; at the same time, prepare the technical documents required by Annex V, recording all security information of the entire process of design, production, and testing. These documents are for inspection by regulatory authorities and must be properly preserved.

Pre-Market Conformity Assessment Phase

Carry out the corresponding assessment according to the product’s classification grade: ordinary digital products can usually undergo self-assessment; for Class I important products, if they meet applicable harmonized standards, common specifications, or cybersecurity certification schemes, internal control assessment can be used, and if not, third-party notified body intervention is required; Class II important products usually require third-party notified body participation in conformity assessment; critical products must be certified by a third-party notified body in combination with Annex IV requirements and applicable certification schemes before being placed on the market.
After passing the assessment, sign the EU Declaration of Conformity (DoC) — that is, the enterprise itself declares that the product meets all applicable CRA requirements. This declaration carries legal responsibility and cannot be signed casually.
Finally, affix the CE mark as required. It should be particularly emphasized here: the CE mark is a compliance access mark for the EU market, not a quality award, nor does it mean that the product is absolutely safe. Manufacturers bear legal responsibility when affixing the CE mark and signing the DoC; for Class II important products, critical products, etc., the product may also require third-party notified body participation in assessment or certification before the CE mark is affixed. Not all products covered by the CRA need to bear the CE mark; only products that require CE marking according to regulatory requirements need to be affixed with it.

Post-Market Continuous Compliance Phase

Proactively carry out post-market security monitoring, and proactively collect vulnerability and incident information. You cannot wait for users to come to you to find out there is a problem; fulfill the obligations of vulnerability repair, incident reporting, and user notification as required; if regulatory authorities of member states come to inspect, cooperate and provide technical documents as required.

Practical Checklists

After talking about so much, some people may find it too complicated. Is there a quick inspection method that can be used? We have compiled practical checklists for two roles: ordinary consumers, and small merchants/developers, which can be used right away.

Ordinary Consumer Version: 3 Steps to Judge Basic Compliance of Products Sold in the EU

1. Check labeling: Check whether the product has a CE mark, and whether the supporting EU Declaration of Conformity (DoC) is publicly queryable (e.g., whether it can be downloaded from the product’s official website).
2. Check information: Check whether the product detail page or manual publicizes the number of years of security update support, and whether there is a public security bulletin channel.
3. Distinguish boundaries: CE is a market access compliance mark. When consumers see CE and DoC, it only means that the enterprise claims to have completed compliance according to the applicable path, and does not mean that the regulatory authority has confirmed technical safety item by item. There is no need to blindly believe in it.

Small Merchant/Developer Version: 5 Steps to Self-Assess Compliance Requirements

1. Confirm whether the product is placed on the EU market or put into service within the EU.
2. Judge whether the product has digital elements and connectivity capabilities.
3. Check whether it falls under exemption or simplification scenarios (note that most are only simplifications, not full exemptions).
4. Determine the product’s classification grade according to Annex III and IV of the CRA.
5. Clarify your own market role and the corresponding scope of responsibility to be borne.

Key Points for Quick Judgment of CE Mark and DoC

• A compliant DoC must clearly list applicable regulations, product models, and manufacturer information. Be wary of those with vague content or incomplete information;
• Technical documents are internal materials for regulatory review. Ordinary consumers generally cannot obtain them, and there is no need to force merchants to provide them.

Common Misconceptions and Pitfall Avoidance Guide

In actual contact, we find that many people have many misunderstandings about the CRA. At best, they waste money for nothing; at worst, they are fined for violations. We have compiled the most common cognitive misconceptions and pitfall avoidance reminders to help you avoid detours.

Core Cognitive Misconceptions

1. Only large companies need to comply: Wrong. As long as a product enters the EU market, entities of any size need to comply. Micro and small enterprises only enjoy procedural conveniences, and core obligations cannot be exempted (see the previous explanation of exemption and simplification scenarios for details).
2. Complying with the CRA means you won’t be hacked: Wrong. The CRA is only a passing baseline requirement. Compliance does not equal zero vulnerabilities. It only ensures that products have basic security protection, that manufacturers are responsible for fixing problems, and that there are channels to obtain patches. It does not mean absolute safety.
3. The CRA only covers hardware/only covers software: Wrong. Standalone software, embedded software, and hardware with digital functions are all within the coverage scope. For example, mobile apps, smart door locks, and WiFi-enabled refrigerators all need to comply.
4. All products require third-party testing: Wrong. Ordinary digital products can usually undergo self-assessment; Class I important products can undergo internal control assessment if they meet applicable harmonized standards, common specifications, or cybersecurity certification schemes, and may still require third-party notified body intervention if they do not; Class II important products and critical products usually require stricter third-party assessment or certification. Don’t waste money for nothing.
5. Open source software is fully exempt: Wrong. Free open source projects that are purely public welfare, non-commercially distributed, and do not provide commercial support usually only bear limited vulnerability cooperation and documentation obligations; once commercially distributed, integrated into commercial products, or provided with paid support, the relevant manufacturers/operators still need to bear compliance responsibilities under the CRA.
6. Complying with GDPR means complying with the CRA: Wrong. The goals of the two are completely different. GDPR regulates data privacy, while the CRA regulates product cybersecurity. GDPR compliance does not mean CRA compliance, and separate assessments are required.
7. Being covered by sector-specific regulations means full exemption: Wrong. For medical, radio, vehicle, aviation and other products, the exclusion clauses of the CRA and the coverage scope of sector-specific regulations must be verified item by item; only requirements that have been fully covered by sector-specific rules avoid repeated application, and uncovered cybersecurity, vulnerability handling, and information disclosure obligations still need to be judged for applicability.

Pitfall Avoidance Reminders for Ordinary Consumers

Before buying, prioritize products with longer security support periods, and try to avoid unbranded “one-off sale” devices that have no security update commitment. For example, a smart socket that costs a few dollars may have no manufacturer to contact after being sold; after buying home, install security patches as soon as possible, and turn off unused internet-connected functions, such as turning off the camera of a smart TV when not in use; if you find non-compliant products, you can complain to the market regulatory authority of the EU member state where you are located.

Pitfall Avoidance Reminders for Small Merchants New to the EU Market

First, don’t take chances. After the transition period ends, non-compliant products will be directly removed from the market. Administrative fines are divided into three tiers according to the type of violation (all take the higher of the amount or the percentage of turnover):

• Violating basic cybersecurity requirements or vulnerability handling obligations: up to 15 million euros or 2.5% of the previous fiscal year’s global turnover
• Violating other compliance obligations such as information disclosure and labeling requirements: up to 10 million euros or 2% of the previous fiscal year’s global turnover
• Providing false information or documents: up to 5 million euros or 1% of the previous fiscal year’s global turnover
  The actual fine shall be determined by the competent authority of the member state in accordance with the law, based on the principle of proportionality, the circumstances of the violation, etc. It will not be imposed at the maximum amount in all cases, but the cost of violation is extremely high and must never be underestimated.
  Second, don’t affix the CE mark randomly. Affixing the CE mark casually without conducting a compliance assessment is an illegal act with serious consequences.
  Third, don’t ignore the supply chain. As a manufacturer, you are also responsible for vulnerabilities in third-party components and open source components you use. Therefore, you must sort out the component list clearly in advance, and don’t wait until a vulnerability occurs to find out that you used that component.

Official Information Channels and Learning Summary

Finally, it should be reminded that the supporting implementation rules, harmonized standards, and certification schemes of the CRA are still being rolled out one after another. Specific requirements shall be subject to the latest official documents. Do not use outdated information as the standard. We have compiled the most authoritative information channels to facilitate your follow-up:

• EU official channels: EUR-Lex allows querying the original text of regulations; the European Commission’s internal market directorate page (DG GROW, which undertakes the relevant internal market regulatory functions of the former DG MARKT) allows querying implementation rules, harmonized standard updates, and supporting rules; the official website of ENISA (European Union Agency for Cybersecurity) allows querying technical guidelines and reporting mechanism information.
• Local implementation channels: The official websites of the market regulatory authorities and CSIRT of the member state where you are located allow querying local specific implementation requirements.

After reading this article, you can match your mastery level according to your own needs:
If you are a beginner learner, you should now be able to quickly judge three things: you can use the four-step judgment method to confirm whether a product falls within the jurisdiction of the CRA; you can judge whether the basic compliance labels and public information of ordinary consumer-grade products are complete; you can name the three major directions of the CRA’s core requirements: product security protection, information disclosure, and post-market responsibility.
If you want to reach a semi-proficient level, you can further master three things: you can judge the corresponding conformity assessment path (self-assessment/internal control/third-party assessment/certification) according to the product’s classification; you can judge the scope of responsibility to be borne according to your own market role; you can avoid common CRA cognitive misconceptions and accurately verify the alignment rules with other sector-specific regulations.

Actual compliance judgment shall be subject to product functions, market roles, classification grades, and the latest official documents.