If you have bought smart cameras or routers in Europe, or run a cross-border e-commerce business selling digital products to the EU, you have most likely heard the term “CRA” recently. Some say it is the EU access threshold for digital products, some confuse it with the GDPR, and small merchants worry that it will affect their European business. What exactly is the EU Cyber Resilience Act? What does it regulate, and what does it not? What does it have to do with you? This article starts from the very basics; after reading it, you will not only understand the core logic but also be able to judge for yourself whether you need to comply.
First, get the basics right: What exactly is the CRA
In plain terms, the CRA is a mandatory cybersecurity access rule set by the EU specifically for products with digital functions. Its full English name is Cyber Resilience Act, abbreviated as CRA. Its core logic is simple: previously, product cybersecurity was a “bonus item” that manufacturers could choose to implement, but now it has become a hard threshold for entering the EU market — products that do not meet the requirements cannot be legally put on sale.
Legally, the CRA is an EU Regulation, which has universal applicability and takes direct effect in all EU member states, without requiring each country to enact separate legislation to transpose it. That is to say, as long as a product is sold to any EU country, it only needs to comply with the same set of CRA rules, without doing compliance for each country one by one.
Many people find the term “cyber resilience” mysterious, thinking it requires products to “never be hacked by hackers”, but that is not the case at all. You can understand it as the “seismic resistance” of digital products: it does not mean that a house will not be damaged at all when an earthquake hits, but that it is as unlikely to collapse as possible, can be repaired quickly if damaged, and the loss is minimized. Cyber resilience follows the same logic, and its core corresponds to four things: leaving as few vulnerabilities as possible during design, being able to quickly detect and fix vulnerabilities when they occur, maintaining normal operation as much as possible when attacked, and keeping losses controllable even if problems occur. For products, this translates to four links: secure design, vulnerability management, security updates, and user notification.
It is also important to note its difference from traditional product safety regulations: previously, EU rules such as the Low Voltage Directive and the Machinery Directive regulated physical or health risks such as whether electrical appliances would leak electricity, catch fire, or cause mechanical injuries. But even if a smart camera does not leak electricity and works normally, if its default password is admin and hackers can easily crack it to use it as part of a “botnet” to attack others, such digital security issues were not regulated by unified rules before. The CRA is specifically designed to fill this gap — a product that works normally does not mean it meets CRA requirements.
Why did the EU introduce the CRA? It addresses three real pain points
The CRA is not a rule thought up on a whim; it is formulated in response to the real security problems of digital products over the past decade, and it mainly solves three pain points:
The first pain point is that the baseline of factory security is generally too low. Many cheap smart devices use universal default passwords when they leave the factory, open unnecessary network ports indiscriminately, and use outdated components that already have vulnerabilities, which is equivalent to leaving the door wide open for hackers. The 2016 Mirai botnet incident was when hackers scanned smart cameras and routers on the Internet, used the default admin password to take control of hundreds of thousands of devices in batches, and used them to launch large-scale cyber attacks, which caused interruptions or impacts on access to some large websites, DNS services, and Internet services in the United States and Europe. The root cause of such problems is that manufacturers simply do not take cybersecurity as a necessary requirement for factory production.
The second pain point is that no one takes long-term security responsibility after products are launched. When many people buy smart door locks or routers, manufacturers do not say how long they will provide security updates at all. After more than a year of use, the manufacturer goes bankrupt or simply stops updating patches, and no one fixes subsequent vulnerabilities. Users’ devices are equivalent to being unprotected online, and they cannot find a responsible party even if they want to defend their rights. The CRA is meant to clarify this responsibility: if you sell a product, you have to take care of subsequent security, and you cannot just walk away after selling.
The third pain point is that rules within the EU are not unified, and there are regulatory gaps. Previously, different countries had different security requirements for digital products: Germany had its own rules, France had its own standards. If small merchants wanted to sell their products to the entire EU, they had to prepare multiple sets of compliance materials, which was very costly. There are also many new types of digital products, such as standalone software and apps supporting smart hardware, which did not have unified security rules before, leaving regulatory loopholes. As a unified rule at the EU level, the CRA can not only fill the gaps but also reduce the cross-border compliance costs of enterprises.
Of course, the CRA does not regulate everything. It has clear jurisdictional boundaries, and it has its own division of labor with other EU regulations such as the GDPR, NIS2, and AI Act, which will be explained in detail later.
What does the CRA regulate, and what does it not? Scope of application and boundary judgment
Many people ask right away, “Does the XX product I sell need to comply?” In fact, you don’t have to memorize the product list by rote; you can make a pretty accurate judgment using two plain-language criteria:
First step, check if the product has digital functions — whether it is software, firmware, or programmable logic, as long as it has digital elements (officially called “products with digital elements”, abbreviated as PDE) it counts;
Second step, check if the product can connect to the Internet, or can be affected by remote instructions — if yes, it is most likely regulated.
One boundary needs to be added here: if it is a remote data processing function (such as cloud services), it is only included in the CRA assessment scope if it is an indispensable part of the normal operation of the product and is within the control of the manufacturer. For example, the cloud verification function of a smart door lock is necessary for unlocking, so it counts; but ordinary standalone SaaS services and pure websites, if they are not an essential component of a certain hardware/software product, are not directly included in the product scope of the CRA.
Territorial scope: How to judge whether you will be regulated?
The core trigger condition of the CRA is that the product is actively placed on or made available on the EU market — for example, cross-border e-commerce targeted sales to EU consumers, independent sites that explicitly support EU regional delivery and payment, and products listed on offline or online platforms within the EU all count as triggers. It cannot be directly determined that a product is placed on the market just because EU users can passively access a certain website or download software; the size of sales usually does not change the judgment of “whether it is placed on the market”, but the specific situation still needs to be confirmed based on facts such as sales arrangements and targeted promotion.
What are the common regulated products?
You don’t need to memorize complex classifications; common ones are roughly divided into three categories:
- Consumer-grade products: smart door locks, cameras, routers, smart watches, connected home appliances, as well as supporting mobile apps necessary for the functions of these products;
- Enterprise-grade products: firewalls, identity management software, industrial controllers, network storage devices;
- Standalone software: operating systems, password managers, VPN software, desktop or mobile applications actively made available to the EU market.
Clearly exempted situations (must meet corresponding conditions)
Not all products with digital functions are regulated. The following categories are explicitly excluded or exempted by the CRA:
The first category is purely mechanical or traditional electronic devices with no digital functions at all, such as purely mechanical door locks, ordinary flashlights without software control, and simple electric heaters without programmable logic. These are completely unregulated.
The second category is products explicitly excluded by the CRA and whose cybersecurity requirements are fully covered by special regulations, such as medical devices that meet the cybersecurity requirements of the EU Medical Device Regulation (MDR), motor vehicles that comply with UN R155 regulations, civil aviation equipment, etc. — Note: not all products with industry regulations are automatically exempt. Only the exclusion categories explicitly listed in the CRA, and where the special regulations have covered the corresponding security obligations, are subject to the priority or exclusion of special regulations. You cannot directly judge that you are not subject to the CRA just based on the industry you belong to.
The third category is prototype equipment and custom-made products for non-commercial research, testing or development purposes only, such as prototype equipment used for R&D testing in laboratories, and self-made smart devices for personal use only. These are excluded; once the product enters the commercial placement or sales link, it can no longer be exempted on the grounds of “prototype” or “custom-made”.
The fourth category is non-commercial community-driven pure open source code projects: open source code itself that is only maintained jointly by the community and not distributed commercially or provided with commercial services does not bear CRA responsibility; if an enterprise or individual packages open source code into a commercial product for placement on the market, as part of a commercial service, or is led by an enterprise to distribute and provide paid support, it shall bear corresponding compliance responsibilities. In short: open source itself does not directly equal exemption; the core depends on whether the open source content is pushed to the EU market as part of a commercial product/service.
Who shall bear compliance responsibility? Each link in the whole chain has its own division of labor
CRA responsibilities cover the entire product supply chain, but different entities have different responsibilities, and there is no situation where one party “bears full responsibility on behalf of the manufacturer”:
- Manufacturer: the first responsible party, responsible for product security design, risk assessment, technical documentation preparation, conformity assessment, and issuance of the EU Declaration of Conformity. No matter where it is registered, as long as the product is actively placed on the EU market, it shall bear the core responsibility for the product’s compliance with CRA requirements.
- Importer within the EU: when the manufacturer is not located within the EU, the importer is responsible for verifying whether the manufacturer has completed the compliance procedures and whether the necessary technical documentation is retained, responsible for transmitting product compliance-related information to regulatory authorities, and cooperating with regulatory investigations, but does not replace the manufacturer in bearing the core responsibility for product compliance.
- Authorized representative: an entity within the EU designated in writing by the manufacturer, which undertakes corresponding compliance liaison obligations within the scope of authorization, and also does not replace the manufacturer’s core responsibility.
- Distributors (including offline retailers and online sellers): responsible for verifying whether the product bears the CE mark, whether it has compliance markings and manufacturer information, shall not sell products that they know are non-compliant, and cooperate with regulatory traceability and recall work.
- Online marketplace service providers: bear platform responsibilities in accordance with the CRA and other relevant EU rules, such as verifying the compliance information of settled merchants and removing non-compliant products. The specific obligations depend on their role (whether they are importers/distributors); not all platforms bear the same verification responsibility as manufacturers.
Core requirements of the CRA: Security obligations throughout the life cycle
The CRA requirements are not only for pre-launch, but cover the entire life cycle of the product, with four core parts:
Pre-launch: Secure design + security by default
Security must be embedded from the product design stage, and cannot be added after the product is made. For example, manufacturers are prohibited from reserving hidden backdoors, and the highest security configuration must be enabled by default — universal default passwords like admin/admin can no longer be used, unnecessary network functions must be turned off by default, following the “principle of least privilege”: open one less interface and request one less permission if possible, to minimize the entry points that hackers can attack. Before launch, a cybersecurity risk assessment must also be completed, and technical documentation must be retained for regulatory spot checks.
Post-launch: Vulnerability management + security updates
Selling a product is not the end of the matter; security must be continuously managed. Manufacturers must set up public vulnerability feedback channels, such as dedicated security email addresses and vulnerability disclosure pages, to promptly handle vulnerabilities reported by users or security researchers.
In terms of security updates, manufacturers shall determine the security support period based on the nature of the product, the expected service life, and the reasonable expectations of users, and clearly publicize it in the product information. They cannot arbitrarily promise unreasonably short or long periods without basis; security updates must be tamper-proof and must not reduce the security level of the product. If they plan to stop security support in the future, they must inform users in advance to give them time to prepare.
If vulnerabilities that are being actively exploited or serious cybersecurity incidents are found, the manufacturer shall report in accordance with the phased process specified in the CRA: first give advance notice of the preliminary situation, then submit a subsequent detailed report, and finally submit a complete disposal report. The reporting recipients include the European Union Agency for Cybersecurity (ENISA) and the Computer Security Incident Response Teams (CSIRT) of affected member states. The specific trigger conditions, time limits, and report formats shall be subject to the formal provisions of the CRA and supporting implementing rules. Note: not all serious vulnerabilities need to be reported; only those that are actively exploited or cause serious incidents trigger the corresponding reporting obligation.
Transparency: Two types of information must be distinguished
The CRA’s transparency requirements are divided into two categories, which should not be confused:
One category is public information for ordinary users: users must be clearly informed of security configuration methods, how to obtain security updates, and the duration of security support. This information must be easy to understand, so that ordinary users can understand basic operations without technical knowledge.
The other category is technical documentation that manufacturers must retain: including the Software Bill of Materials (SBOM, which is the “parts list” of software, listing the names and versions of third-party components and open source code used), for vulnerability tracking, supply chain security management, and regulatory spot checks; ordinary consumers will not directly get the complete SBOM, and this type of documentation is mainly used for regulatory or compliance assessment purposes.
Risk classification: Different products have different compliance intensities
Not all products have the same strict requirements. The CRA divides products into four categories according to their risk levels. The specific classification is subject to the CRA annexes and the official list subsequently issued by the EU. Different levels have different conformity assessment requirements:
- Ordinary products: the vast majority, such as smart light bulbs, ordinary connected sockets and other consumer-grade low-risk products. After the manufacturer completes internal control and self-assessment, it can issue the EU Declaration of Conformity and affix the CE mark.
- Important products (Class I): such as home routers, ordinary identity management software, etc., with medium risk. If the manufacturer fully adopts EU-recognized harmonized standards, common specifications or existing cybersecurity certification schemes, it can complete the assessment on its own; if not, it needs to be assessed by a third-party body (Notified Body) officially recognized by the EU.
- Important products (Class II): such as enterprise-grade firewalls, core network access equipment, etc., with higher risk. The requirements for internal control and assessment processes are stricter, and usually require a Notified Body to participate in the conformity assessment, depending on whether harmonized standards are adopted.
- Critical products: specific high-risk digital products explicitly listed in the CRA annexes (not all components used in critical infrastructure count). Such products may need to comply with EU-designated European cybersecurity certification schemes. The specific schemes, assurance levels and applicable times are subject to subsequent implementing acts of the EU, with the strictest assessment requirements.
Here we need to focus on the most familiar CE mark: for products that fall within the scope of application of the CRA and enter the corresponding obligation application period, the manufacturer can only draw up the EU Declaration of Conformity and affix the CE mark in accordance with the CRA and other applicable regulations after completing the applicable conformity assessment. The CE is essentially the manufacturer’s self-declaration of compliance, meaning “I declare that the product meets all applicable EU regulatory requirements”. It is not an official EU safety certification, nor does it mean that the product is absolutely safe. Regulatory authorities will conduct spot checks afterwards, and non-compliance will be punished. When purchasing products, you cannot only look at the CE mark; you must also make a comprehensive judgment based on update duration, manufacturer information, etc.
Don’t confuse: Core differences between the CRA and other popular EU regulations
Many people confuse the CRA with several other popular EU regulations. In fact, they have different regulatory focuses, and may overlap in some scenarios. The core differences can be quickly clarified with a table:
| Regulation Name | Core Regulatory Content | Main Applicable Objects | Quick Judgment Mnemonic |
|---|---|---|---|
| CRA (Cyber Resilience Act) | Cybersecurity of digital products themselves (vulnerabilities, updates, default configurations, etc.) | Manufacturers, importers, sellers of digital products | Selling digital products to the EU? Look to the CRA |
| GDPR (General Data Protection Regulation) | Privacy protection of personal data (collection, use, storage, etc.) | Entities that process personal data of EU users | Involving personal data privacy? Look to the GDPR |
| NIS2 Directive | Internal cybersecurity management of key industries | Operators of key services such as energy, finance, and transportation in the EU | Operating EU key services? Look to NIS2 |
| AI Act (Artificial Intelligence Act) | Risk and usage rules for artificial intelligence systems | Developers and deployers of AI systems | Compliance involving AI functions? Look to the AI Act |
In overlapping scenarios, parallel obligations only arise when the trigger conditions of both types of regulations are met at the same time:
- Overlap with the GDPR: if a product vulnerability leads to a personal data breach, both reporting obligations will only be triggered at the same time if the CRA’s vulnerability/incident reporting conditions and the GDPR’s personal data breach notification conditions (usually high risk to users’ rights and freedoms, reported by the data controller to the regulatory authority within 72 hours) are both met. The reporting subjects, recipients and requirements of the two are different and do not conflict.
- Overlap with NIS2: if a digital product purchased by an enterprise has a vulnerability, both types of responsibilities will only be triggered at the same time if the manufacturer violates CRA obligations and the enterprise operating key services fails to fulfill the internal security management obligations specified in NIS2.
- Overlap with the AI Act: for products with AI functions, first determine whether they constitute an AI system as defined in the AI Act and which risk level they belong to, then correspond to the requirements of the AI Act; at the same time, the cybersecurity of the product itself still needs to comply with CRA requirements, and the two sets of rules run parallel without conflict.
As for special regulations for industries such as medical devices, automobiles, and aviation, the CRA has explicitly excluded some corresponding categories, and the specific situation is subject to the exclusion clauses of the scope of application.
How do different roles judge whether it has anything to do with them?
You don’t have to memorize all the rules. People with different identities can use corresponding methods to make quick judgments:
Ordinary consumers: 3-step preliminary risk screening
When buying smart products, you don’t need to understand technology; you can do a rough risk screening by checking three places. But note: these three points can only help find obvious gaps in security information, and cannot directly prove that the product meets or does not meet CRA requirements. The final compliance shall be subject to the manufacturer’s conformity assessment and regulatory determination:
First, check the packaging or product detail page for the CE mark (note that CE may correspond to multiple EU regulations, and you cannot judge CRA compliance solely by the mark), and whether there is clear information about the manufacturer’s name and the responsible entity within the EU (importer/authorized representative);
Second, check the update instructions to see if the support period for security updates is clearly marked — if it is not mentioned at all, it is an important risk signal, and it is recommended to prioritize products that clearly publicize the support period;
Third, look for feedback channels to see if you can find the manufacturer’s security contact information, such as a dedicated security email address or vulnerability feedback page — manufacturers without public feedback channels may have unguaranteed vulnerability response efficiency, and it is recommended to choose carefully.
Merchants/Developers: 4-step self-check on whether compliance is needed
If you sell products or do development, just follow these four steps:
First step, first determine whether the product has digital functions, whether it can connect to the Internet or be affected remotely;
Second step, confirm whether the product is actively placed on or made available on the EU market;
Third step, check whether it belongs to the exempt category, such as whether it is a purely mechanical product, or a product covered by special regulations explicitly excluded by the CRA;
Fourth step, compare the requirements according to the product’s risk level (ordinary/important Class I/important Class II/critical) to make up for shortcomings, and prepare compliance materials in advance.
Open source/free software: 2-step judgment on whether you need to bear responsibility
Many developers care about whether open source software needs to comply. In fact, it only depends on two points:
First, is the project itself a non-commercial community-driven pure open source project? That is, open source code itself that is jointly maintained by the global community, has no commercial distribution, and has no enterprise-led operation and paid services, usually does not need to bear CRA responsibility;
Second, have you packaged the open source code into a commercial product/service and actively placed it on the EU market? For example, putting open source code into a router for sale, making paid software based on open source code, or providing commercial open source technical support services — as long as it is a commercial placement act, you need to bear corresponding compliance responsibilities.
Are there simplified policies for small and medium-sized enterprises?
Micro-enterprises that meet the EU definition (fewer than 10 employees and with an annual turnover or balance sheet total not exceeding 2 million euros) can obtain certain guidance, support and proportional arrangements under the CRA framework, such as simplification of some documentation requirements and assessment processes. But note: simplification does not equal exemption. Core security requirements (such as default security configuration, vulnerability handling, security update obligations) and applicable conformity assessment requirements will not be automatically exempted due to the status of micro-enterprises.
Consequences of non-compliance and implementation timeline
What are the penalties for non-compliance?
The CRA sets different upper limits of fines according to the type of violation. Fines apply to responsible economic operators and are enforced by the market regulatory authorities of each member state. The specific penalty scale is determined according to the circumstances of the violation, duration, degree of harm, etc.:
- Violating core cybersecurity obligations (such as failing to conduct security design as required, failing to provide security updates, reserving backdoors, etc.): a maximum fine of 15 million euros, or 2.5% of the enterprise’s global annual turnover in the previous fiscal year, whichever is higher;
- Violating other compliance obligations (such as failing to retain technical documentation as required, failing to fulfill notification obligations, non-compliant use of the CE mark, etc.): a maximum fine of 10 million euros, or 2% of the enterprise’s global annual turnover in the previous fiscal year, whichever is higher;
- Providing false, incomplete or misleading compliance information: a maximum fine of 5 million euros, or 1% of the enterprise’s global annual turnover in the previous fiscal year, whichever is higher.
In addition to fines, non-compliant products may also be subject to market regulatory measures such as EU-wide sales ban, removal from shelves, and recall; importers, distributors, and platforms that fail to fulfill their corresponding obligations will also be punished accordingly.
The CRA sets the upper limit of fines and the market regulatory framework at the EU level. Specific law enforcement is carried out by the market regulatory authorities of member states in accordance with their own procedures, and is discretionary based on the circumstances of the violation.
Key time nodes and transition rules
The CRA enters into force on the 20th day after its publication in the Official Journal of the European Union, and the actual effective date is December 10, 2024. Different obligations have different transition periods and are not implemented simultaneously:
- Vulnerability and serious incident reporting obligations: applicable from September 11, 2026;
- Most core compliance obligations for ordinary digital products and important products: applicable from December 11, 2027;
- The applicable time for compliance obligations of critical products is subject to subsequent supporting guidelines and official notices issued by the EU.
As for products already placed on the EU market before December 11, 2027, whether they need to comply depends on the situation: if the product has no major functional changes after the obligations take effect, and the manufacturer has stopped providing security support and other related services, it usually does not need to be retroactively compliant; if the product undergoes major functional updates after the obligations take effect, or the manufacturer continues to provide security updates, remote services and other services related to product security, it must meet the corresponding requirements of the CRA. Don’t just remember “takes effect in 2027”; you need to check the applicable time combined with the product status and specific obligation types.
6 most common cognitive misconceptions
Finally, let’s clarify a few most common cognitive pitfalls, don’t get them wrong and waste effort or step on a mine:
- Only hardware needs to comply, software/APPs do not — Wrong. As long as it is a product with digital functions actively placed on the EU market, software, hardware, firmware, supporting apps necessary for product functions, and remote processing functions all need to meet the requirements.
- Products not produced in the EU do not need to comply with the CRA — Wrong. As long as the product is actively placed on or made available on the EU market, it must comply no matter where it is produced. Targeted sales by cross-border e-commerce and independent sites supplying EU users all count.
- The CE mark is an official safety certification — Wrong. CE is the manufacturer’s self-declaration of compliance, not an official endorsement, and does not mean that the product is absolutely safe. Regulators will conduct spot checks afterwards.
- All open source software is exempt — Wrong. Only non-commercial pure community open source projects are exempt. Those who use open source code in commercial products and place them on the EU market need to bear compliance responsibilities.
- Only large companies need to comply — Wrong. As long as the product is placed on the EU market, small merchants and independent developers must also comply. Only eligible micro-enterprises can enjoy partial process simplification.
- Compliance is a one-time action — Wrong. Compliance covers the entire product life cycle. After launch, it is necessary to continuously handle vulnerabilities and push updates, and products with major changes need to be re-evaluated.
Final summary
Overall, the core of the CRA is to turn the cybersecurity of digital products from a voluntary “bonus item” for manufacturers into a hard threshold for the EU market, requiring manufacturers to be responsible for the full life cycle security of products from design, launch to service termination, and ultimately improve the security level of digital products in the entire EU market.
Whether you are an ordinary consumer, cross-border merchant, or developer, you can quickly judge your own relevance to the CRA through the three basic questions: “does it have digital functions, can it connect to the Internet/be affected remotely, and is it actively placed on the EU market”, and then correspond to specific requirements based on your own role. If you need more detailed operational guidelines, you can pay attention to the subsequent supporting implementing rules released on the official website of the European Union Agency for Cybersecurity (ENISA).