EU CRA explained: requirements, timeline, and compliance

What is the EU Cyber Resilience Act (EU CRA)?

The EU Cyber Resilience Act (CRA) is a sweeping regulation that mandates security by design and uniform cybersecurity standards for all hardware and software products with digital elements sold in the European Union.

The CRA officially entered into force in December 2024, with compliance enforcement phased in over the coming years:

• September 11, 2026: Mandatory vulnerability and incident reporting obligations take effect for manufacturers.
• December 11, 2027: Full compliance becomes mandatory, requiring CE markings, technical documentation, and detailed risk assessments for all covered products.

Under the EU CRA, manufacturers, importers, and distributors are responsible for making sure their products comply with these cybersecurity requirements before being made available in the EU. The act also mandates ongoing obligations such as vulnerability management, security updates, and incident reporting. By creating a unified set of cybersecurity standards, the EU CRA seeks to raise the baseline of digital product security and build greater trust in the digital single market.

This is part of a series of articles about AI governance.

Why was the EU Cyber Resilience Act introduced?

Increasing security risks in connected products

The proliferation of connected products has expanded the attack surface for cybercriminals. As more devices become internet-enabled, vulnerabilities in hardware and software are exploited to gain unauthorized access, disrupt services, or steal sensitive information. High-profile incidents involving compromised smart devices and critical infrastructure have highlighted the need for stronger security measures. The EU CRA was introduced in response to this threat landscape, aiming to make cybersecurity a foundational requirement rather than an afterthought.

Manufacturers often prioritize rapid time-to-market and new features over security, leaving products exposed to exploitation. The lack of standard security practices across industries and product categories has led to inconsistent protection, making it easier for attackers to find and exploit weaknesses.

How the act helps: The EU CRA addresses this by enforcing uniform security requirements, requiring manufacturers to integrate security into product design and lifecycle management from the outset.

Inconsistent cybersecurity requirements across the EU

Before the EU CRA, member states implemented their own cybersecurity regulations, resulting in a fragmented regulatory environment. This inconsistency created challenges for businesses operating across multiple EU countries, as they had to navigate varying compliance obligations. The lack of harmonization also led to uneven levels of consumer protection, with some regions having stricter requirements than others. The EU CRA was introduced to establish a single framework, eliminating regulatory fragmentation and ensuring equal security standards throughout the EU.

How the act helps: By introducing consistent cybersecurity requirements, the EU CRA simplifies the compliance process for manufacturers, importers, and distributors. Companies can design and certify their products according to a common set of rules, reducing administrative overhead and compliance costs. This harmonized approach improves product security and enhances the competitiveness of the European digital market by putting every participant on equal footing.

Limited manufacturer responsibility after a product is sold

Historically, manufacturers often viewed their responsibility for a product’s security as ending once it was sold. This approach left consumers and businesses vulnerable when new threats emerged or undiscovered vulnerabilities were found post-sale. With connected devices frequently targeted long after deployment, the lack of ongoing support and updates created persistent security risks. The EU CRA addresses this gap by mandating continued responsibility for product security throughout its operational life.

How the act helps: The act requires manufacturers to monitor for vulnerabilities, provide timely security updates, and communicate risks to users even after products have entered the market. That keeps security an ongoing obligation, not a one-time requirement. By holding manufacturers accountable for post-sale cybersecurity, the EU CRA strengthens the resilience of digital products and provides greater protection for end users.

When does the EU Cyber Resilience Act take effect?

The EU Cyber Resilience Act entered into force on December 10, 2024, 20 days after its publication in the Official Journal of the European Union. However, most of its requirements don’t apply immediately. The regulation establishes a three-year transition period, with its main obligations becoming applicable on December 11, 2027. From that date, manufacturers, importers, and distributors must make sure covered products placed on the EU market comply with the applicable cybersecurity, vulnerability management, documentation, conformity assessment, and CE marking requirements.

Some provisions apply earlier. Requirements concerning the notification and operation of conformity assessment bodies apply from June 11, 2026. Mandatory reporting obligations take effect on September 11, 2026. From that date, manufacturers must report actively exploited vulnerabilities and severe security incidents affecting products with digital elements within the specified reporting deadlines.

Products placed on the EU market before December 11, 2027, are generally subject to the CRA only if they undergo a substantial modification after that date. However, the earlier incident and vulnerability reporting requirements can also apply to products made available before the main application date when the manufacturer’s reporting obligations are triggered. Organizations should prepare their vulnerability intake, product security, incident reporting, technical documentation, and conformity assessment processes well before full enforcement begins.

Who must comply with the EU CRA?

The EU CRA applies to economic operators involved in placing products with digital elements on the EU market.

Manufacturers carry the primary responsibility for ensuring that covered products are designed, developed, and produced in accordance with the act’s essential cybersecurity requirements. This applies to manufacturers established inside or outside the EU when their products are made available to customers in the European market. Manufacturers must:

• Perform cybersecurity risk assessments
• Manage vulnerabilities
• Maintain technical documentation
• Complete the appropriate conformity assessment
• Issue an EU declaration of conformity
• Apply the CE marking

Importers must verify that products manufactured outside the EU comply with the CRA before placing them on the market. They are expected to confirm that the manufacturer has completed the required conformity assessment, prepared the necessary documentation, applied the CE marking, and provided appropriate user information.

Distributors must also exercise due care by checking for required markings, documentation, and manufacturer or importer information before making a product available.

Other parties may assume the obligations of a manufacturer in certain circumstances. An importer, distributor, or other organization can be treated as the manufacturer when it markets a product under its own name or trademark or makes a substantial modification that affects the product’s compliance with the CRA. Authorized representatives may perform tasks on behalf of manufacturers, but the manufacturer remains responsible for product design, cybersecurity risk assessment, and overall conformity.

What products are covered by the EU CRA?

1. Software products

The EU CRA covers software products made available on the EU market when their intended or reasonably foreseeable use involves a direct or indirect logical or physical connection to a device or network. This includes:

• Operating systems
• Business applications
• Development tools
• Communication software
• Data management products
• Other commercial software distributed as standalone products

Both paid software and software supplied as part of another commercial offering may fall within the act’s scope. The requirements also apply to software components that are placed on the market separately, even when those components are intended to be integrated into another product.

Manufacturers must evaluate the cybersecurity risks associated with the software, minimize exploitable vulnerabilities, provide security updates during the support period, and supply users with information needed to configure and operate the product securely. Certain free and open source software developed or supplied outside a commercial activity is excluded, although commercial products that incorporate open source components remain subject to the CRA.

2. Connected hardware and Internet of Things (IoT) devices

Connected hardware is a central area of coverage under the EU CRA. The act applies to devices that can communicate directly or indirectly with other devices or networks, including:

• Smart home products
• Connected appliances
• Wearable devices
• Industrial equipment
• Sensors
• Connected toys
• Cameras
• Other IoT devices

A product doesn’t need to maintain a permanent internet connection to be covered; the ability to connect through wired, wireless, physical, or logical interfaces may be sufficient.

Manufacturers of connected devices must address cybersecurity throughout the product lifecycle. Products must be designed to reduce attack surfaces, protect data and essential functions, prevent unauthorized access, and withstand known or foreseeable threats. Manufacturers must also define a support period, monitor vulnerabilities, distribute security updates, and provide users with information about secure installation, configuration, operation, and maintenance.

3. Network and security products

The EU CRA covers products used to operate, connect, monitor, or secure digital networks. Examples include:

• Routers
• Modems
• Switches
• Firewalls
• Virtual private network products
• Intrusion detection and prevention systems
• Network management systems
• Identity management products
• Other network security tools

Because weaknesses in these products can provide access to multiple systems or users, many are subject to additional scrutiny under the act’s product classification framework. Certain network and security products are classified as important or critical products with digital elements. Depending on their category and core functionality, they may require stricter conformity assessment procedures, including assessment by an independent third party.

Manufacturers must confirm that security controls function as intended, sensitive information stays protected, vulnerabilities are handled, and security-relevant events can be recorded where appropriate.

4. Mobile and desktop applications

Mobile and desktop applications are generally covered when they are placed on the EU market as software products and can connect directly or indirectly to a device or network. This includes:

• Productivity software
• Communication applications
• Media applications
• Security tools
• Business software
• Other downloadable or installed programs

Applications distributed through app stores, vendor websites, physical media, or enterprise channels may all fall within the act’s scope. Applications that integrate third-party libraries, software development kits, or open source components must also manage the cybersecurity risks created by those dependencies.

Application developers acting as manufacturers must incorporate cybersecurity into application design and development rather than relying only on post-release fixes. They must identify cybersecurity risks, prevent products from being released with known exploitable vulnerabilities, protect stored and transmitted data, and provide security updates for the declared support period.

5. Embedded software and firmware

Embedded software and firmware are covered when they form part of a product with digital elements or are placed on the market separately for integration into hardware. This includes:

• Device firmware
• Embedded operating systems
• Boot software
• Control software
• Code used within connected appliances, industrial systems, network equipment, and IoT devices

These components are essential to the secure operation of the hardware and may create risks if they contain exploitable vulnerabilities. Where firmware can be updated, the update process must be secure and prevent malicious or unauthorized code from being installed.

Manufacturers must consider embedded software and firmware as part of the product’s overall cybersecurity risk assessment. They must protect products against unauthorized modification, use secure update mechanisms, maintain the confidentiality and integrity of relevant data, and address vulnerabilities in both proprietary and third-party components.

6. Remote data processing solutions

The EU CRA can cover remote data processing solutions when they are necessary for a product with digital elements to perform one of its functions and are designed and developed by, or on behalf of, the product’s manufacturer. These solutions may include:

• Cloud-based functionality
• Remote computing services
• Backend platforms
• Online components that support the operation of connected hardware or software

Coverage is limited to remote processing that forms an integral part of the product’s functioning. General-purpose cloud or online services that aren’t developed under the responsibility of the product manufacturer aren’t automatically treated as part of the product under the CRA. Where a remote data processing solution is included, the manufacturer must assess its cybersecurity risks, address vulnerabilities, protect communications and data, and confirm that the complete product, including its remote components, meets the applicable requirements.

Essential cybersecurity requirements under the EU CRA

Secure-by-design and secure-by-default development

Products with digital elements must be designed, developed, and produced to provide a level of cybersecurity appropriate to their risks. Manufacturers must conduct a cybersecurity risk assessment and use its findings throughout product planning, design, development, production, delivery, and maintenance. Security controls should be built into the product rather than added only after vulnerabilities or incidents are discovered.

Products must also be supplied with secure default configurations. Default settings should minimize unnecessary exposure and should not require users to possess advanced security knowledge before operating the product safely. Where applicable, automatic security updates should be enabled by default, while users should receive clear notifications and have a way to opt out or temporarily postpone an update. Products should also support resetting to their original secure state.

Protection against unauthorized access

Products must include appropriate controls to prevent unauthorized access to their systems, data, services, and functions. Depending on the product and its risk profile, these controls can include authentication, identity management, access management, authorization rules, session controls, and restrictions on administrative privileges.

Access controls should reflect the intended use of the product and the sensitivity of the resources being protected. Manufacturers must also enable the product to identify or report possible unauthorized access where appropriate, allowing users or administrators to investigate suspicious activity and take corrective action.

Data confidentiality and encryption

Products must protect the confidentiality of personal and nonpersonal data that they store, transmit, or process. Unauthorized parties should not be able to read sensitive data through intercepted communications, compromised storage, exposed interfaces, or improperly configured product features.

Manufacturers may use encryption and other technical safeguards to meet this requirement. Relevant data should be protected at rest and in transit using mechanisms that reflect current technical capabilities and the identified risks. Additional measures can include secure key management, protected communication channels, credential safeguards, and controls that prevent sensitive information from being exposed through logs or interfaces.

Data integrity and protection against manipulation

Products must preserve the integrity of stored, transmitted, and processed information. This applies not only to user data but also to commands, programs, firmware, configurations, and other information that affects how the product operates. The product should prevent changes that have not been authorized by the user or another permitted party.

Protections can include digital signatures, cryptographic verification, secure boot processes, integrity checks, controlled configuration changes, and protections against unauthorized code execution. Products should also be capable of reporting detected corruption or unauthorized modification so that affected components or data can be investigated and restored.

Availability and resilience

Products must protect the availability of their essential and basic functions, including after a cybersecurity incident. Manufacturers should design products to remain operational where possible, recover securely, or maintain a minimum level of functionality when systems, networks, or components are disrupted.

Resilience measures should address risks such as denial-of-service attacks, resource exhaustion, component failures, and malicious attempts to interrupt services. The product should also minimize its potential negative impact on the availability of other connected devices, networks, and services, preventing a compromised or malfunctioning product from causing broader disruption.

Minimizing attack surfaces

Products must be designed, developed, and produced to limit their attack surfaces, including the number and exposure of external interfaces. Features, services, ports, communication pathways, accounts, and permissions that are not required for the product’s intended purpose should be removed, disabled, or restricted.

Manufacturers should consider how every exposed interface could be discovered or abused by an attacker. Attack-surface reduction can involve disabling unnecessary services by default, restricting administrative interfaces, applying least-privilege principles, isolating sensitive components, validating inputs, and limiting access to debugging or maintenance functionality in production products.

Reducing the impact of security incidents

Products must include mechanisms and techniques that reduce the consequences of a successful attack. Manufacturers must assume that some vulnerabilities or defenses may be bypassed and design products to contain the resulting damage.

Impact-reduction measures can include process isolation, privilege separation, memory protections, sandboxing, segmentation, secure recovery mechanisms, rate limiting, and restrictions on lateral movement. These controls should prevent a compromise of one component from automatically giving an attacker unrestricted access to the entire product, connected systems, or sensitive data.

Security logging and monitoring

Products must provide security-related information by recording and monitoring relevant internal activity. This can include access to data, changes to services or settings, use of privileged functions, authentication events, and modifications that may indicate misuse or compromise.

Logging should provide enough context to support incident detection, investigation, and response without creating unnecessary security or privacy risks. Logs should be protected against unauthorized alteration and access, and retention should be appropriate to the product’s purpose. The CRA also requires an opt-out mechanism for users where this security monitoring functionality applies.

Secure data deletion and portability

Products must allow users to securely and easily remove all stored data and settings on a permanent basis. Deletion functions should keep information from staying accessible through ordinary product use after a device is sold, returned, transferred, decommissioned, or reset.

Where the product allows data to be transferred to another product or system, that transfer must be performed securely. Manufacturers should protect exported data against unauthorized access, alteration, or interception and provide users with procedures for deleting local copies, resetting configurations, and moving information without exposing it during the process.

Protection against known exploitable vulnerabilities

Products must not be placed on the EU market with known exploitable vulnerabilities. Manufacturers must identify security weaknesses before release through testing, reviews, risk assessments, and vulnerability management processes. They must also consider vulnerabilities in third-party and open source components incorporated into the product.

This obligation continues after the product is released. Manufacturers must document product components and vulnerabilities, remediate identified weaknesses without delay, and provide security updates throughout the applicable support period. Updates must be distributed securely and, where appropriate, automatically, allowing customers to receive fixes before known weaknesses can be widely exploited.

EU CRA penalties and enforcement

The EU CRA is enforced primarily through market surveillance authorities designated by each EU member state. These authorities can investigate products with digital elements, request technical documentation and internal data, evaluate whether products and vulnerability-handling processes comply with the regulation, and require economic operators to cooperate with enforcement activities. Authorities may also conduct coordinated inspections and market-wide sweeps targeting particular products or categories associated with cybersecurity risks.

When a product is found to be noncompliant or to present a serious cybersecurity risk, the responsible authority can order the manufacturer, importer, or distributor to take corrective action within a specified period. This may include fixing the product, addressing inadequate vulnerability management processes, restricting its availability, withdrawing it from the market, or recalling products already supplied to users. If the economic operator doesn’t take sufficient action, authorities can impose these restrictions directly and coordinate enforcement across other member states.

The most serious violations can lead to administrative fines of up to €15 million or, for an undertaking, 2.5 percent of its total worldwide annual turnover for the preceding financial year, whichever is higher. This penalty tier applies to breaches of the essential cybersecurity requirements and key manufacturer obligations, including vulnerability handling and mandatory reporting requirements.

EU Cyber Resilience Act compliance best practices

1. Create an inventory of products with digital elements

Start by identifying every product with digital elements that the organization manufactures or places on the EU market. The inventory should include hardware, software, firmware, and any remote data processing components that are required for the product to function. Record product versions, supported platforms, release dates, support periods, and the teams responsible for development and maintenance.

A complete inventory helps determine which products fall within the scope of the EU CRA and which conformity assessment procedures may apply. It also provides the foundation for vulnerability management, technical documentation, security updates, and incident response. Without an accurate inventory, it becomes difficult to demonstrate compliance or guarantee that all affected products receive required security fixes.

Key actions:

• Maintain an inventory of all products with digital elements.
• Record product owners, versions, and support periods.
• Identify hardware, software, firmware, and remote components.
• Review the inventory whenever products are released or updated.

2. Generate and continuously update SBOMs

Create a software bill of materials (SBOM) for each product to document the software components it contains. The SBOM should include proprietary code, open source libraries, third-party packages, dependencies, versions, and licensing information. It should be generated automatically during the build process and updated whenever components change.

Maintaining current SBOMs improves visibility into the software supply chain and makes it easier to identify products affected by newly disclosed vulnerabilities. When a security issue is discovered in a dependency, manufacturers can determine which products are impacted, prioritize remediation, and provide security updates in line with the CRA’s vulnerability management requirements.

Key actions:

• Generate SBOMs automatically during the build process.
• Include proprietary, open source, and third-party components.
• Track component versions and licensing information.
• Update SBOMs whenever dependencies change.

Related content: Learn how to build an AI bill of materials (AI-BOM).

3. Scan dependencies for known and malicious components

Regularly scan software dependencies to identify known vulnerabilities, outdated packages, and malicious or compromised components before products are released. Security scanning should cover both direct and transitive dependencies, as vulnerabilities often originate in nested libraries that developers do not use directly.

Dependency scanning should be performed continuously rather than only before release. Integrating vulnerability databases, malware detection, and policy checks into the development process helps prevent products from being shipped with known exploitable vulnerabilities and supports ongoing monitoring throughout the product lifecycle.

Key actions:

• Scan direct and transitive dependencies continuously.
• Detect known vulnerabilities and malicious packages.
• Block builds containing prohibited or high-risk components.
• Prioritize remediation based on risk and exploitability.

4. Automate security testing across the CI/CD pipeline

Integrate automated security testing into every stage of the CI/CD pipeline so security issues are detected as early as possible. Common practices include static application security testing (SAST), software composition analysis (SCA), secret detection, infrastructure-as-code scanning, container image scanning, and dynamic application security testing (DAST) where appropriate.

Automated testing provides consistent security validation for every build and reduces the likelihood that vulnerabilities reach production. Combined with defined security gates, these controls help confirm that products meet organizational security requirements before release while providing evidence that secure development practices are followed.

Key actions:

• Integrate SAST, SCA, and secret scanning into CI/CD.
• Scan containers and infrastructure-as-code templates.
• Enforce security gates before deployment.
• Retain test results as compliance evidence.

5. Evaluate supplier and third-party component security

Many products rely on third-party software, hardware, cloud services, and development partners, making supplier security an important part of CRA compliance. Assess suppliers using security questionnaires, contractual requirements, certifications, audit results, and evidence of secure development and vulnerability management practices.

Supplier assessments shouldn’t be treated as a one-time activity. Review critical suppliers regularly, monitor newly disclosed vulnerabilities affecting their products, and establish processes for receiving security notifications and updates. Ongoing oversight reduces supply chain risk and helps keep third-party components from introducing unmanaged cybersecurity weaknesses into products.

Key actions:

• Assess suppliers using defined security criteria.
• Review third-party security documentation and certifications.
• Monitor supplier vulnerabilities and security advisories.
• Define contractual requirements for vulnerability reporting and updates.

Related content: Read our guide to AI compliance.

Meeting EU CRA requirements with Mend AppSec

Complying with the EU CRA means building security into every stage of the product lifecycle: identifying vulnerable and malicious components before release, maintaining an accurate software inventory, and remediating issues quickly across the supply chain. Mend AppSec brings these controls together by unifying SAST, SCA, and container scanning, pairing high-precision detection with reachability-based prioritization and AI powered fixes so your team reduces real risk without slowing developers down.

Key capabilities of Mend AppSec:

• Unified SAST and SCA in one signal: Mend AppSec combines high-precision differential SAST with reachability-driven SCA, prioritized by EPSS and CVSS 4.0, to surface exploitable open source and container risk first rather than chasing raw severity scores.
• Continuous SBOM and AI-BOM output: The audit log and continuously updated SBOM and AI-BOM support customer security reviews and regulator requests, aligning directly with CRA documentation and transparency obligations.
• Software supply chain protection: Mend AppSec halts malicious packages throughout the SDLC and scans containers, base images, and layered dependencies across the full supply chain, addressing the CRA’s focus on known exploitable and third-party component risk.
• Faster remediation with AI and automation: AI powered code fixes and automated dependency management help teams reduce remediation effort by 75 percent, resolving vulnerabilities within the timeframes CRA vulnerability handling demands.
• Security inside developer workflows: Deep integrations across IDEs, pull requests, repositories, CI/CD, and AI coding assistants like Cursor, Windsurf, and Copilot catch vulnerabilities as code is written, supporting a secure-by-design approach.
• Built-in governance and compliance: Real-time open source license policy enforcement, automated remediation SLA tracking, and blocking of noncompliant components before merge keep every repository audit-ready, backed by SOC 2 Type II, ISO 27001, and GDPR.

Ready to build CRA-aligned security into your development lifecycle? See how Mend AppSec supports EU CRA compliance.