The EU Cyber Resilience Act (CRA): A Complete Guide for Compliance

Introduction

It’s not enough to have the most innovative products in the modern corporate environment without the assurance of foolproof cybersecurity resilience. Users and corporations are more wary than ever before about who they give access to their data. Any device or software that cannot provide sufficient cybersecurity assurances will fail to attract customers.

The Cyber Resilience Act (CRA) establishes a common framework related to the cybersecurity of products and services with digital elements that are to be made available within the EU territory.

Critically, its purpose is not limited to vulnerabilities after the product is released; instead, it introduces cybersecurity requirements that apply across the entire lifecycle, including the design, development, production, maintenance, and vulnerability mitigation.

The CRA represents a significant challenge for organizations that are subject to it owing to both the comprehensive set of obligations it introduces, the complicated phased timetable, and the strict regulatory fines and actions that will follow for those found in breach of it.

Read on to learn more about the CRA, including the most effective and efficient way to facilitate compliance with its requirements.

What Is The Cyber Resilience Act

The Cyber Resilience Act, formally known as Regulation (EU) 2024/2847, is an EU product cybersecurity regulation that establishes a thorough set of cybersecurity requirements for products, specifically those with digital elements.

Its legal structure is built around four vital principal elements, as follows:

• Rules governing when covered products may be made available on the EU market;
• Essential cybersecurity requirements for their design, development, and production;
• Essential requirements governing manufacturers' vulnerability-handling processes;
• Framework for market surveillance and enforcement.

At its core, the CRA is more of a product compliance regime which requires any product to only be made available in the EU market after it has satisfied a set of cybersecurity requirements and its manufacturer’s processes are in line with the vulnerability handling obligations set forth in the regulation.

However, based on how a product is classified, its obligations can vary significantly, with those deemed to be critical products subject to stricter conformity assessments and certification requirements.

Overall, the CRA regulates a facet of product security assurance that was previously considered and addressed through an organization’s internal engineering teams and security policies. The various risk assessments, technical documentation, conformity assessment procedures, and CE marking requirements now standardize these obligations, thereby making responsible cybersecurity engineering, vulnerability management, and product governance regulatory obligations under a single legal framework.

Legislative Background

Originally known as the Regulation (EU) 2024/2847 of the European Parliament and of the Council of October 23, 2024, this particular regulation is meant to establish critical cybersecurity requirements by incorporating digital elements and subsequently amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828.

The Cyber Resilience Act leverages the EU’s New Legislative Framework meant to oversee aspects of product compliance, conformity assessment, accreditation, and market surveillance.

Moreover, the CRA introduces a common EU framework for all products and services with a digital element being placed on the market. All covered products must meet certain cybersecurity requirements, and their manufacturers are required to maintain various vulnerability-related processes to ensure the product or service remains safe to use after it has been made available on the market.

When Does the CRA Apply

In short, the CRA applies to every single product and service with digital elements being made available on the EU market. This is applicable in all cases where the intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

Implementation Dates

The Cyber Resilience Act officially came into force on December 10, 2024. However, on the whole, the regulation has a lengthy enforcement schedule that will run deep into 2027.

• Chapter IV of the regulation will begin applying from June 11, 2026;
• Manufacturer reporting obligations under Article 14 will begin applying from September 11, 2026;
• The regulation in its entirety will become applicable from December 11, 2027.

Organizations that are subject to these various obligations must be prepared to honor these requirements on the date of their enforcement.

Scope of the CRA

Since the CRA applies to any and all products and services with digital elements made available in the EU market, it is critical to understand what “a product with a digital element” means. It refers to any software or hardware product that is placed on the market for the intended purpose or a reasonably foreseeable use, including any direct or indirect logical or physical data connection to a device or network.

The broad scope is by design, as covered products can include standalone software, such as applications and computer programs; hardware with embedded software, including Internet-of-Things devices, laptops and tablets; standalone hardware, such as integrated circuits and motherboards; and combinations of hardware and software supplied separately but intended to operate together.

Moreover, the concept of a product being made available on the market is also critical, as the CRA covers products with digital elements for distribution or use on the Union market in the course of commercial activity, whether for free or for a price. Hence, a product being free to use does not exempt it from the provisions of the CRA.

Who Must Comply

The CRA imposes various obligations for different actors that apply differently based on their role in the development, planning, and making products available on the EU market.

For starters, the regulation uses the term “economic operator” to include all manufacturers, authorized representatives, importers, distributors, and other natural or legal persons subject to its provisions.

Manufacturers are subject to the most intensive requirements. These are any natural or legal persons that develop or manufacture a product with digital elements or have a product designed, developed, or manufactured, and market it under their own name or trademark. This includes any payment products, regardless of whether they are monetized or free.

Authorized representatives are those that have a legal written mandate from the manufacturer to perform specified tasks on their behalf.

Importers refer to EU-based natural or legal persons that place on the market a product with digital elements bearing the name or trademark of an entity based outside the EU.

Distributors refer to other persons in the supply chain that make products with digital elements available on the EU market without affecting their own properties.

Moreover, the CRA also applies to all open-source software stewards who provide support for such products with digital elements that are available for free but may be used for commercial activities.

Exceptions

Article 2 does exclude certain products from the CRA.

The CRA does not apply to products with digital elements to which Regulation (EU) 2017/745, Regulation (EU) 2017/746 or Regulation (EU) 2019/2144 applies as well as products certified under Regulation (EU) 2018/1139 and equipment falling within the scope of Directive 2014/90/EU.

The CRA does allow for its application to products that are covered by other EU rules that address some of the same risks the CRA is meant to address to be limited or excluded.

Certain spare parts are also excluded when the part is meant to replace an identical component in a product that was manufactured in accordance with CRA requirements.

Products developed or modified specifically for national security or defense purposes, as well as those meant to process classified information, also fall outside the scope of the CRA.

Free and open-source software is more complicated, as they are not treated as automatically exempt. When such a product is made available on the market not in pursuit of commercial activity, it will not be subject to the CRA. However, the persons supporting and governing its use will still be subject to the CRA rules related to stewards of such products. This includes individual contributors that submit code without having control over the development, release, or distribution of the software.

Understanding “Placing on the Market”

“Placing on the market” is a key concept under the Cyber Resilience Act. It determines when a product with digital elements enters the EU regulatory framework, and more importantly, which specific CRA requirements become applicable to that product.

The regulation itself defines it as “first making available of the product with digital elements on the Union market”. Making available can also refer to the distribution or use of the product in the Union market in the course of a commercial activity, whether for a fee or free of charge.

This creates an important distinction. While placing on the market occurs once when the product is first made available, supplies of the product are instances of making it available on the market.

Supply Doesn’t Always Involve Payment

A product does not have to be “sold” to be considered to have been made available in the market. The CRA covers this by stating supply can occur in the course of a commercial activity, whether for a payment or free of charge. For businesses, they can determine whether the CRA applies simply by asking whether users pay directly for the product in question.

Hardware Products

For traditional physical products that have digital elements, such as machinery or radios, the concept of placing on the market follows the same approach as that under the New Legislative Framework, where placing on the market and making available depends on each product, depending on whether it was manufactured as a single unit or as part of a series.

Software Products

For software, the placement occurs once the software’s manufacturing phase is complete and it is first supplied for distribution or use in the EU market in pursuit of a commercial activity.

Moreover, the nature of software distribution is also important, as each download or distribution can lead to identical copies of the software, rather than requiring the manufacturer to produce a new physical unit. Hence, as long as the software is not modified in a way that would alter its CRA obligations, its placement on the market remains linked to the first offering for distribution or use rather than each user download, purchase, or use.

However, in cases where a software update is released, and the new version constitutes a “substantial modification”, it will be considered newly placed on the market.

Unfinished Software & Testing Versions

Member States cannot prevent unfinished software that is not compliant with the CRA from becoming available on the market if it is only supplied for a limited period necessary for testing and is accompanied by a label indicating that it does not comply with the CRA and will not be available for any purpose other than testing. This can include alpha, beta, and release candidates.

Pre-existing Products

Products with digital elements that were placed on the market before December 11, 2027, will only become subject to the CRA requirements if they subsequently undergo a substantial modification. However, under Article 14’s reporting obligations, these obligations will also apply to products that were placed on the market before December 11, 2027.

Manufacturer Obligations Under The CRA

Under the CRA, manufacturers have the primary compliance responsibility. In addition to ensuring the product is designed, developed, and produced in accordance with the cybersecurity requirements, they must also adhere to various other obligations related to cybersecurity risk assessment, third-party components, vulnerability handling, security updates, technical documentation, conformity assessment, and continued compliance after the product has entered the market.

Central to these obligations is the cybersecurity risk assessment, where manufacturers must assess all cybersecurity risks related to the product and take the results into account throughout the planning, design, development, production, delivery, and maintenance stages.

Cybersecurity By Design & By Default

CRA requires cybersecurity considerations to be built directly into the product design. It cannot be treated as a post-release activity, or something manufacturers address only after a vulnerability has been discovered.

Hence, based on the results of their cybersecurity risk assessment, manufacturers must ensure their products:

• Are made available on the market without known exploitable vulnerabilities;
• Have a secure-by-default configuration, including the possibility of resetting the product to its original state, subject to the CRA's specific exception for tailor-made products supplied to business users;
• Allow vulnerabilities to be addressed through security updates, including automatic security updates where applicable;
• Protect against unauthorized access through appropriate authentication, identity or access-management controls;
• Protect the confidentiality of stored, transmitted or otherwise processed data;
• Protect the integrity of data, commands, programs and configurations against unauthorized manipulation;
• Process only data that is adequate, relevant and limited to what is necessary for the product's intended purpose;
• Protect the availability of essential and basic functions, including following an incident;
• Minimize the negative impact of the product or connected devices on the availability of services provided by other devices or networks;
• Limit attack surfaces, including external interfaces;
• Reduce the impact of incidents through appropriate exploitation-mitigation mechanisms;
• Provide relevant security information through recording and monitoring internal activity, with an opt-out mechanism for users;
• Enable users to securely and easily remove data and settings permanently and, where data can be transferred elsewhere, ensure that the transfer is secure.

Moreover, any cybersecurity shortcoming discovered cannot be transferred to users or third parties. While user instructions can help in secure deployment, communicate residual risks, and define an appropriate operating environment, they do not compensate for an insecure product design.

Due Diligence For Third Party Components

Manufacturers are required to exercise due diligence when integrating third-party components. This is required when integrating free and open-source software components as well.

However, there are two subtle differences. The cybersecurity risk assessment needs to cover the product as a whole, including risks originating from its internal environment. Due diligence concerns components that form part of that product but have been obtained from third parties.

Hence, manufacturers must determine what cybersecurity properties are required from an integrated component and verify whether that component satisfies those requirements. Evidence to support such verification can include technical specifications, security documentation, conformity or assurance documentation obtained from the component manufacturer and, where appropriate, tests performed by the manufacturer to verify the component's security-relevant functionality.

The risk assessment must also take into consideration all external systems, networks, infrastructure and services on which the product depends even where they do not themselves form part of the product.

In case a vulnerability is identified in the integrated component, the manufacturer must let the manufacturer of that particular component know and move on to address and remediate the vulnerability in its own product.

When a security fix is developed for such a component, it should be provided upstream in a machine-readable and readily verifiable format. However, the CRA does not require the upstream maintainer to accept or integrate the shared proposed fix.

Vulnerability Handling

Manufacturers’ responsibilities continue after the product’s release. Manufacturers are required to identify and document vulnerabilities and components within their products. This includes drawing up a software bill of materials (SBOM) that covers at the very least the product’s top-level dependencies.

In case of an issue, they must address and remediate any vulnerabilities without delay, including any security updates. Where technically feasible, such updates must be supplied separately from the functional updates.

Additional manufacturer responsibilities in this regard include:

• Carrying out effective and regular security tests and reviews;
• Publicly disclosing information about fixed vulnerabilities once a security update has been made available;
• Maintaining and enforcing a coordinated vulnerability disclosure policy;
• Facilitating the sharing of information concerning vulnerabilities in the product and its third-party components;
• Providing a contact address through which vulnerabilities can be reported;
• Maintaining mechanisms for the secure and timely distribution of updates;
• Disseminating security updates without delay and, subject to the CRA's specific exception for tailor-made products supplied to business users, free of charge and accompanied by appropriate advisory information.

Public disclosures of such vulnerability fixes must include information that allows users to identify the affected product, the vulnerability's impact and severity, and clear information explaining how users can remediate it. Such disclosures can be delayed in instances where the cybersecurity risks associated with its publication would outweigh its benefits.

Support Period Requirements

The support period is the period during which the manufacturer is required to handle vulnerabilities in its components. The manufacturer must determine this period by reference to the length of time the product is reasonably expected to remain in use. In such determinations, the manufacturers must consider the following:

• Reasonable user expectations;
• The nature of the product;
• Its intended purpose;
• Relevant Union law determining the product's lifetime.

As a rule, the support period must be at least five years. In instances where the product’s use is expected to be less than five years, the support period must correspond to that shorter expected use period. Similarly, if the expected use period is longer than five years, the support period should correspond accordingly.

All information used to make the aforementioned determination must be included in the technical documentation with the manufacturer required to disclose the end date of their support period. However, any security updates made available during the support period must remain available for at least 10 years after it was issued or the remainder of the support period.

Special rules apply to continuously evolving software. If a manufacturer places substantially modified versions of the software on the market, the requirement to address and remediate vulnerabilities applies only for the latest version.

Documentation Requirements

Per CRA, the manufacturer must be able to demonstrate compliance. To that end, they must have technical documentation as well as complete any conformity assessment procedures.

Once done, the manufacturer must then draw up an EU declaration of conformity and affix the CE marking. The aforementioned technical documentation must contain:

• A general description of the product and its intended purpose;
• Software versions affecting compliance with the essential cybersecurity requirements;
• Where applicable, illustrations or photographs of hardware products;
• The required user information and instructions;
• Information concerning the product's design, development and production;
• A description of its system architecture and the interaction between software components, where applicable;
• Details of the manufacturer's vulnerability-handling processes;
• The software bill of materials;
• The coordinated vulnerability disclosure policy;
• Evidence of a vulnerability-reporting contact address;
• A description of the mechanisms used to distribute updates securely;
• Information concerning production and monitoring processes;
• The cybersecurity risk assessment;
• Information used to determine the support period;
• Relevant harmonized standards, common specifications, certification schemes or other technical solutions relied upon;
• Reports of tests used to verify conformity;
• A copy of the EU declaration of conformity;
• Where applicable and following a reasoned request, the SBOM required by a market surveillance authority to assess compliance.

Manufacturers must retain the technical documentation and declaration of conformity for at least 10 years after the product is placed on the market or for the support period.

The product must also come with prescribed information and instructions for users, such as manufacturer contact information, the vulnerability-reporting point of contact, product identification, the intended purpose, relevant security properties, known or foreseeable circumstances that may create significant cybersecurity risks, the type of technical security support available and the support period end date.

Additionally, throughout the support period, the users must continuously receive instructions addressing secure commissioning and use throughout the product's lifetime, the security implications of product changes, installation of security updates, secure decommissioning and deletion of user data, and the operation of automatic security updates.

Compliance After Market Placement

Manufacturers are required to maintain procedures to ensure continued conformity under the CRA. To that end, they must take into account any changes to development and production processes, product design or characteristics, harmonized standards, common specifications and relevant cybersecurity certification schemes.

In cases where the manufacturer plans on ceasing operations and will no longer be able to meet its CRA obligations, it must notify the relevant market surveillance authorities before such a cessation can take effect. To whatever extent possible, it must inform users of the affected product about the impending cessation.

Essential Cybersecurity Requirements

Under the CRA, meeting certain cybersecurity requirements is a critical condition before a product with digital elements can be made available on the EU market. In addition to the Act’s cybersecurity requirements under Part 1 of Annex I, there are additional requirements for manufacturers under Part II of Annex I as covered in the aforementioned section.

The cybersecurity requirements are risk-based. This means any product with digital elements must be designed, developed, and produced with an appropriate level of cybersecurity considerations built in based on the risks identified during the manufacturer’s cybersecurity risk assessment. The individual requirements under Part I apply wherever relevant based on this risk assessment rather than requiring identical controls regardless of purpose or risk profile.

Based on that assessment and wherever applicable, the manufacturers must ensure that products:

• Do not contain known exploitable vulnerabilities when made available on the market;
• Are secure by default;
• Can receive security updates;
• Protect against unauthorized access;
• Protect the confidentiality of data;
• Protect the data and system integrity;
• Apply data minimization;
• Protect the availability of essential and basic functions;
• Minimize the negative effects on other devices and networks;
• Limit the attack surface;
• Reduce the potential impact of incidents;
• Provide security-related monitoring information;
• Enable the secure removal and transfer of data.

These aforementioned requirements constitute the security characteristics that the CRA expects from the product. These requirements operate alongside the critical vulnerability handling requirements also imposed upon manufacturers.

Vulnerability Handling Requirements

Manufacturers must have processes in place to identify, address, and communicate all vulnerabilities throughout the relevant support period. These apply not only to the vulnerabilities in the manufacturer’s own code but also to any vulnerabilities affecting the components within the product.

Vulnerability Identification & SBOM Maintenance

Manufacturers must identify and document all vulnerabilities and components within their products. This includes creating a Software Bill of Materials (SBOM) that covers all the product’s main top-level dependencies.

Address & Remediate Vulnerabilities

All identified vulnerabilities must be addressed without delay. This can include taking steps such as providing security updates, aside from the updates that are to be introduced to change the product UI or functionality.

Conduct Regular Security Testing

Regular security tests and reviews are necessary to ensure no lapses in security maintenance occur. Moreover, the Commission recommends these shouldn’t be repetitively identical tests at fixed intervals, with each test being instead tailored for newly identified threats, vulnerabilities, or product changes. Similarly, the testing frequency and depth should also take these factors into account.

Disclose Fixed Vulnerabilities

Once these security updates are available, the manufacturers need to be open and publicly disclose all information about the vulnerabilities that have been fixed. This information should enable users to identify the affected product and understand the potential impact and severity of the vulnerability.

However, these disclosures can be delayed in circumstances where their publication would cause greater cybersecurity risks than benefits.

Maintain A Coherent Vulnerability Disclosure Policy

Through a coordinated vulnerability disclosure policy, manufacturers can provide their users clarity about potential vulnerabilities that may affect them as well as the correct contact information about whom to get in touch with if necessary.

Incident Reporting

The reporting obligations under the CRA are distinct from the general vulnerability handling obligations. Manufacturers are required to report both actively exploited vulnerabilities as well as severe incidents that may have an impact on the security of the product itself.

These reporting obligations come into effect from September 2026 for all products that are subject to CRA obligations, including products that are to be placed on the market before December 11, 2027.

Reporting deadlines and other obligations come into effect when the manufacturer becomes aware of the reportable event. The manufacturer will be considered to have become aware of the event after its initial assessment provides a reasonable degree of certainty.

What Must Be Reported

The first and most important category to report is the actively exploited vulnerability that has been identified in the product with digital elements. This needs to be a vulnerability that a malicious actor has exploited without the owner’s permission.

Hence, not every vulnerability needs to be reported, with the reporting obligations only coming into effect in case of an active exploitation.

The second category is a severe incident that has an impact on the security of the product with digital elements. An incident will be considered severe when it negatively affects the product’s ability to protect the availability, authenticity, integrity, or confidentiality of sensitive data or functions. Moreover, it can also be considered severe when it leads to or is capable of leading to an introduction of malicious code in the product or the network or information system of one of its users.

Lastly, the CRA does allow for voluntary reporting. Manufacturers and other legal persons may voluntarily report vulnerabilities and cyber threats based on their own internal ethical codes or requirements.

Reporting Timelines

For Actively Exploited Vulnerabilities

A progress structure is in place, allowing manufacturers to provide more information as their internal investigations move forward.

The early warning needs to be submitted without delay, within 24 hours after the manufacturer becomes aware of the exploited vulnerability. Where applicable, it should identify the member states in which the manufacturer is aware the product is available.

A more detailed vulnerability notification should then be submitted within 72 hours of becoming aware, with information on the affected product, the nature of the exploit and vulnerability, corrective measures being taken, mitigation steps available to the user, and the manufacturer’s own assessment of the sensitivity of the information affected.

A final report should be the next ot follow within 14 days after the mitigation measure first becomes available.

For Severe Incidents

Severe incidents will follow an almost identical timeline as that of actively exploited vulnerabilities.

However, the final report needs to be submitted within 1 month after the 72-hour incident notification is sent out, with details on the incident including the severity and impact, the likely threat type, and mitigation measures that have been taken or are in the process.

The CSIRT receiving this report must also require an intermediate report containing relevant status updates.

Reporting Channel

Notifications must be sent through a single reporting platform through any of the electronic notification methods of the CSIRT designated as coordination for the member state in which the manufacturer has its main establishment within the EU.

Conformity Assessment & CE Marking

Compliance with the CRA needs to be demonstrated long before a product can be placed on the market. Hence, manufacturers must assess both the product and the processes behind the product to determine whether it has met all the relevant requirements.

The CRA has several conformity assessment routes, depending on product category and applicable conditions; these can include the internal control procedure (Module A), EU-type examination (Module B) followed by conformity to EU type based on internal production control (Module C), full quality assurance (Module H) or, where available and applicable, an eligible European cybersecurity certification scheme.

Standard Products

For products that are not subject to special conformity assessment rules applicable to important or critical products, manufacturers may demonstrate conformity through any of the processes available under Article 32(1), including internal controls.

Under the internal controls, the manufacturer must have the relevant technical documentation in place, with its design, development, production, and vulnerability handling processes all duly compliant, in addition to the EU declaration of conformity and the CE marking.

Important Products – Class I

For such products, the manufacturer’s ability to use internal control depends on how conformity has been demonstrated.

When the manufacturer has not applied common specifications, harmonized standards, or qualifying European cybersecurity certification schemes, the product must undergo either the EU-type examination followed by Module C, or the full quality assurance under Module H.

Important Products – Class II

Class II products will be subject to stricter requirements, with manufacturers required to demonstrate conformity through EU-type examination followed by Module C, full quality assurance under Module H, or a European cybersecurity certification scheme at an assurance level labeled at least “substantial”.

Critical Products

Critical products must demonstrate conformity through a European cybersecurity certification scheme where conditions from Article 8(1) apply. If the conditions are not met, the procedure used for Class II products will apply instead.

EU Declaration Of Conformity

After a successful conformity assessment, the manufacturer is required to draw up an EU declaration of conformity that states its compliance with the applicable essential cybersecurity requirements.

If a product is subject to several EU legal acts that require a declaration of conformity, the manufacturer must draw up a single declaration covering all of these acts.

CE Marking

The CE marking must be affixed visibly, legibly, and indelibly to the product. If this cannot be done because of the nature of the product, the marking should be done on the packaging and accompanying EU declaration of conformity.

For software, the CE marking must be declared on the declaration of conformity or the website itself.

The CE marking should be affixed before the product is placed on the market, with the product certified under Module H making its identification number similarly available.

Enforcement

The CRA is backed up by a market surveillance and enforcement framework, thereby ensuring the products with digital elements remain compliant not only when they’re placed on the market but throughout the period where the CRA obligations apply.

Enforcement goes beyond just the imposition of financial penalties, as depending on circumstances, authorities can require corrective measures, restrict and prohibit further market availability, order product withdrawals and recalls, obtain access to internal documentation, and coordinate extensive investigations across the member states. In specific circumstances, the European Commission may also intervene at the Union level where a significant cybersecurity risk requires a coordinated response.

Market Surveillance Authorities

Each member state is required to designate at least one market surveillance authority to ensure effective implementation of the CRA. This can be assigned to either an existing authority or a newly established one.

These authorities also cooperate with the wider cybersecurity enforcement network, with possible exchange of information with national cybersecurity certification authorities when necessary.

For specific Article 14 obligations, they must cooperate with the relevant Computer Security Incident Response Team (CSIRT) and the European Union Agency for Cybersecurity (ENISA), requesting their technical advice and carrying out investigations into all products that pose a significant cybersecurity threat. This cooperation may also extend to other product-market surveillance authorities as well as data protection authorities when necessary.

However, in cases where a product with digital elements is also classified as a high-risk AI system under the AI Act, the designated market surveillance authorities are responsible for the market-surveillance activities required under the CRA for those products. They must cooperate with the relevant CRA authorities, CSIRTs and ENISA.

Such investigations are not limited to only technical considerations, as authorities can also take into account relevant non-technical risk factors, such as factors identified through Union-level coordinated security-risk assessments of critical supply chains. If these factors are found to pose a significant threat, the authority must inform and cooperate with the relevant competent authorities under the NIS2 framework.

Investigations

In cases where the market surveillance authority has sufficient reason to believe a product with digital elements represents a risk, it must assess its compliance with the CRA immediately. Such evaluations may also be conducted jointly with the relevant CSIRT.

Restrictions, Withdrawals, & Recalls

In case the appropriate corrective actions are not taken within the period specified by the market surveillance authority, they can impose provisional restrictive measures such as:

• Prohibiting the product from being made available on the national market;
• Restricting its availability;
• Withdrawing it from the national market; or
• Recalling it.

In such cases, the authority must inform the Commission and member states of such measures, with details that identify the product, its origin, the nature of the alleged non-compliance and cybersecurity risk, the measures imposed and their duration, as well as counterarguments provided by the entity that failed to take the corrective actions.

If no member state or the Commission objects to these restrictive measures within three months, the measures stand justified. However, if a member state or the Commission does object to the measures, the Union safeguard procedure comes into effect.

Commission Intervention At Union Level

The Commission may become directly involved where the product presents a significant cybersecurity threat that requires an EU-wide response.

When the Commission has sufficient reason to believe a product is non-compliant and represents a significant cybersecurity risk, it can inform the relevant national market surveillance authority and trigger the appropriate national and Union procedures. It then conducts a compliance evaluation, with additional support from ENISA for technical analysis.

Following these investigations as well as consultations with Member States, the Commission can adopt implementing acts that impose corrective or restrictive measures at Union level. These measures can include the affected product being withdrawn from the market or recalled within a reasonable period.

Coordinated Enforcement

CRA enforcement can be coordinated across multiple authorities.

Market surveillance authorities can undertake joint activities with other relevant authorities to protect cybersecurity and consumers. The Commission or ENISA can propose all such joint activities where indications of potential non-compliance exist.

Market surveillance authorities can subsequently use information gathered through such joint activities in their own investigations.

The CRA allows for coordinated control actions known as “sweeps” that are simultaneous inspections of particular products or categories of products meant to identify infringements of the CRA.

Monitoring Support Periods

Market surveillance extends to a manufacturer’s decisions related to product support.

The CRA’s administrative cooperation group, ADCO, must publish user-friendly statistics concerning product categories, including average manufacturer-determined support periods, and provide guidance containing indicative support periods.

In case the available data suggests support periods for particular categories of products are inadequate, the ADCO may recommend market surveillance authorities focus enforcement activities against such categories.

Penalties

The CRA establishes strict penalties for any infringement of the regulation. The exact figures depend on the type of infringement, with its implementation and enforcement operating through the member state systems.

Up to €15 Million Or 2.5% Of Worldwide Annual Turnover

This is the higher tier, applying to all non-compliance with:

• The essential cybersecurity requirements;
• The manufacturer obligations under Articles 13 and 14, including the core manufacturer and mandatory reporting obligations.

Up to €10 Million Or 2% Of Worldwide Annual Turnover

The second tier applies to non-compliance with specific obligations established in Articles 18–23, Article 28, Article 30(1)–(4), Article 31(1)–(4), Article 32(1)–(3), Article 33(5), and Articles 39, 41, 47, 49 and 53.

These are also applicable to obligations related to economic operators such as importers and distributors, the EU declaration of conformity, CE-marking requirements, technical documentation, conformity assessment and access to documentation required by authorities.

Up to €5 Million Or 1% Of Worldwide Annual Turnover

Non-compliant acts such as supplying incorrect, incomplete or misleading information to a notified body or market surveillance authority in response to a request can result in fines of up to €5 million.

The ceiling is set at 1% of its total worldwide annual turnover for the preceding financial year, whichever is higher.

Exceptions

The CRA does provide for narrowly framed exceptions for certain manufacturers that qualify as microenterprises or small businesses.

Administrative fines under Article 64 do not apply to those manufacturers specifically for failure to meet the 24-hour early-warning deadlines under Article 14(2)(a) for actively exploited vulnerabilities or Article 14(4)(a) for severe incidents.

However, this should not be considered a general exemption for such businesses as it is specifically linked to failure to meet the Article 14’s early warning deadlines.

Similarly, administrative fines do not apply to infringements committed by open-source software stewards. This does not mean such stewards are outside the CRA's enforcement framework altogether, as market surveillance authorities are responsible for supervising their obligations and taking corrective actions when needed.

How Securiti Helps

The Cyber Resilience Act elevates the bar for organizations planning on developing or supplying products with digital elements. It does so by placing a strict requirement for all cybersecurity risks to be identified, addressed, documented, and managed throughout the product lifecycle.

Meeting these requirements and thereby achieving compliance with the CRA requires extensive collaboration and coordination between the security, engineering, compliance, data governance, and risk teams.

Securiti, a Veeam company, has the DataAI Command Center that helps organizations strengthen their data security, risk visibility, and compliance processes that support broader CRA readiness.

Moreover, its Data Security Posture Management (DSPM) is a comprehensive solution that provides holistic insights into the security posture of any organization’s data assets and automatically remediates misconfigurations, allowing your sensitive data to stay protected at all times.

As a result, organizations can gain complete visibility into their sensitive data and associated risks, identify and reduce cybersecurity exposure, operationalize risk and compliance assessments, continuously monitor and remediate security risks, and strengthen incident investigations and response plans. All of this allows for a unified compliance operation model, providing the entire organization the foundation needed to operationalize many of the risk-management activities that surround those requirements.

Request a demo today and learn more about how Securiti, a Veeam company, can help you gain greater visibility into security risks, automate compliance processes, strengthen data security controls, and improve continuous compliance readiness.