Understanding the EU Cyber Resilience Act: What Software Manufacturers Need to Do

Cyber Resilience Act (CRA)

An EU Regulation adopted in 2024 that sets horizontal cybersecurity requirements for products with digital elements (PDEs) placed on the EU market, focusing on secure design, development, and lifecycle management.

Product with Digital Elements (PDE)

A product that contains digital components (software, or software + hardware) and is directly or indirectly connected to a network or another device, and is placed on the market as a product.

Manufacturer (CRA context)

The natural or legal person who designs or manufactures a PDE, or has it designed or manufactured, and places it on the EU market under their own name or trademark, bearing primary CRA obligations.

Importer

An EU-based person or company that places a PDE from a non-EU country on the EU market under the manufacturer’s name or trademark, with duties to verify CRA compliance.

Distributor

A person or company in the supply chain, other than the manufacturer or importer, that makes a PDE available on the EU market, with due-diligence obligations (e.g., not selling known non-compliant products).

Secure by design and by default

A principle requiring that security is integrated into the design and development of a product from the start, and that default settings minimize security risks without user intervention.

CRA Entry into Force

The date when the Cyber Resilience Act formally becomes EU law: **11 December 2024**. The regulation exists and the transition period begins, but most obligations are not yet applicable.

Early Reporting Obligations Start

From **11 September 2026**, manufacturers must comply with CRA rules on reporting actively exploited vulnerabilities and incidents to ENISA, even before full CRA applicability.

General Applicability Date

From **11 December 2027**, most CRA obligations apply to products with digital elements placed on the EU market, including risk assessment, security requirements, documentation, and conformity assessment.

Product Already on the Market (Pre‑Dec 2027)

A product lawfully placed on the EU market before **11 December 2027**. It can generally continue to be made available without full CRA re‑certification, unless it is substantially modified.

Substantially Modified Product

A product whose intended purpose or cybersecurity properties are significantly changed (e.g., major new features, architecture changes). After 11 December 2027, such modifications can trigger full CRA obligations, even for older products.

Transition Period (2024–2027)

The phase between CRA entry into force (Dec 2024) and general applicability (Dec 2027), during which organizations must prepare processes, documentation, and product designs for full compliance, with early reporting obligations starting Sept 2026.

Product with digital elements (PDE)

Any software, hardware, or combination that includes digital components and has a direct or indirect data connection to a device or network (e.g., apps, firmware, connected devices). This is the core object regulated by the CRA.

Standard product (CRA)

The default category for products with digital elements that are not listed as important or critical. Typically allowed to follow internal control (self-assessment) for conformity, if they meet CRA requirements.

Important product (CRA)

A higher-risk product type listed in Annex III of the CRA (e.g., many network and security products). Often requires involvement of a notified body for conformity assessment, unless fully compliant with relevant harmonised standards.

Critical product (CRA)

The highest-risk category, listed in Annex IV of the CRA. Typically involves mandatory third-party conformity assessment and more stringent evidence of cybersecurity and secure development.

Notified body

An independent organisation designated by an EU Member State to carry out conformity assessment tasks (e.g., audits, testing, certification) for certain categories of products under the CRA.

Key exclusions under the CRA

Product categories whose cybersecurity is already comprehensively regulated by other EU laws (e.g., medical devices, certain vehicles, civil aviation products), which are therefore excluded from CRA scope.

Security‑by‑Design (under the CRA)

An approach where security is integrated from the earliest stages of product design and development, including threat modelling, secure architecture, secure coding practices, and built‑in protections, rather than added as a late patch.

Security‑by‑Default (under the CRA)

The principle that products must be delivered with secure configurations and minimal privileges enabled by default, so that a typical user ends up with a secure setup without needing expert knowledge.

Attack Surface

The total set of points where an attacker could try to enter or interact with a system (e.g. open ports, APIs, user interfaces). Minimising the attack surface means exposing only what is strictly necessary and hardening each interface.

Product with Digital Elements (PwDE)

Any hardware or software product that relies on digital components (software, data, connectivity). Under the CRA, most standalone software and software embedded in devices fall into this category.

Harmonised Standard

A technical standard developed by European standardisation organisations (e.g. CEN, CENELEC, ETSI) and cited in the EU Official Journal. Conformity with such a standard gives a presumption of conformity with the related CRA essential requirements.

Coordinated Vulnerability Disclosure (CVD)

A structured process by which security researchers and other parties can report vulnerabilities to the manufacturer, who then investigates, fixes, and communicates the issue in a coordinated way.

Cybersecurity Risk Assessment (under the CRA)

A documented, systematic analysis of cybersecurity threats, vulnerabilities, likelihood, and impact for a specific product across its lifecycle, used to select and justify security measures and updated when conditions change.

Lifecycle Security Management

The continuous process of planning, implementing, monitoring, and updating cybersecurity measures from product design through deployment, maintenance, and end‑of‑support.

Reasonably Foreseeable Misuse

Ways in which a product might be used incorrectly or insecurely that are realistic and predictable (e.g., weak passwords, exposed debug ports), and therefore must be considered in the risk assessment.

Risk Register

A structured record of identified risks, including their description, likelihood, impact, level, and mitigation measures, maintained and updated as part of CRA technical documentation.

End‑of‑Support (EoS)

The point in time when the manufacturer stops providing security updates and support for a product; under the CRA, users must be informed and residual risks should be documented.

Continuous monitoring (under CRA)

An ongoing process where manufacturers systematically track vulnerabilities, threats, and incidents affecting their products in the field, using tools, feeds, and procedures to detect and assess new risks.

Vulnerability management

A structured process for identifying, assessing, prioritizing, remediating, and documenting vulnerabilities in a product over its lifecycle, including those in third‑party and open‑source components.

Security update obligations

CRA requirements that manufacturers provide free, timely security updates for at least the product’s expected lifetime or a CRA‑mandated minimum period, and clearly inform users about update mechanisms and support duration.

Coordinated Vulnerability Disclosure (CVD)

A process where security researchers and manufacturers work together on vulnerability reporting, fixing, and public disclosure, following agreed timelines and rules to minimize risk to users.

Software Bill of Materials (SBOM)

A detailed list of all software components (including open‑source libraries and third‑party code) used in a product, helping manufacturers identify which vulnerabilities affect their products.

Actively exploited vulnerability

A vulnerability in a product with digital elements for which there is **evidence of real-world exploitation** (successful attacks) against deployed systems, not just theoretical or lab-based proof-of-concept.

Severe incident (CRA context)

An incident affecting a product with digital elements that **significantly impacts** confidentiality, integrity, availability, or safety, especially when it affects critical services, large user bases, or safety of persons.

24h early warning

The **first stage** of reporting: a rapid alert (within 24 hours of becoming aware) to ENISA/national CSIRTs that a severe incident or actively exploited vulnerability is suspected, even if details are incomplete.

72h initial notification

The **second stage** of reporting: a structured notification (within 72 hours) containing technical details, initial impact assessment, and early mitigation steps, enabling authorities to coordinate response.

14‑day final report

The **third stage** of reporting: a comprehensive follow‑up (typically within 14 days) including root cause analysis, final impact, remediation actions, and lessons learned.

CSIRT

Computer Security Incident Response Team – a national or organisational team that receives incident reports, coordinates technical response, and supports mitigation and information sharing.

Technical Documentation (CRA context)

An internal set of documents kept by the manufacturer that demonstrates conformity with CRA cybersecurity requirements, including product description, architecture, security measures, risk management, testing, and lifecycle processes.

Software Bill of Materials (SBOM)

A structured, machine-readable list of all software components (open-source and proprietary) used in a product, including names, versions, suppliers, and relationships, enabling vulnerability tracking and supply-chain transparency.

Risk Assessment Documentation

Records of identified assets, threats, vulnerabilities, likelihood and impact estimates, chosen mitigations, and residual risks, maintained and updated throughout the product lifecycle.

Residual Risk

The level of risk that remains after all reasonably practicable security measures have been applied; under the CRA, significant residual risks must be communicated to users.

End-of-Support (EoS) Information

User-facing notice that tells when security updates will stop for a product, the security implications of this, and recommended user actions (e.g., upgrade or replacement).

Security-by-Design and by-Default

CRA principle that products must be designed and configured with cybersecurity in mind from the outset, and shipped with secure default settings that do not require expert users to be safe.

Conformity assessment (under the CRA)

A structured process by which a manufacturer demonstrates that a software product meets the Cyber Resilience Act’s essential cybersecurity requirements, using specified assessment modules that may involve internal checks and/or a notified body.

Standard vs Important vs Critical products

A CRA risk-based categorization of products: standard (lower risk, often self-assessed), important (higher impact, more stringent assessment), and critical (highest impact, typically requiring notified body involvement).

Notified body

An independent organisation designated by an EU Member State and notified to the European Commission to carry out specific conformity assessment tasks such as EU-type examination or quality system audits.

EU Declaration of Conformity (DoC)

A legal document in which the manufacturer declares that the product complies with all applicable EU legislation (including the CRA), listing the product, relevant acts, standards, and any notified body involved.

CE marking

A symbol affixed to a product indicating that it conforms to all applicable EU harmonisation legislation, enabling its free movement and sale within the EU internal market.

Harmonised standards and common specifications

Technical documents referenced in the Official Journal of the EU that, when applied, provide a presumption of conformity with specific legal requirements, simplifying conformity assessment.

Manufacturer (under the CRA)

An entity that develops or has a product with digital elements designed and manufactured, and places it on the EU market under its own name or trademark, or substantially modifies a product in a way that affects compliance. Bears the main CRA obligations (risk assessment, technical documentation, CE marking, updates, vulnerability handling).

Importer

An EU‑based economic operator that places a CRA‑covered product from a non‑EU manufacturer on the EU market. Must verify CE marking, documentation, and not place products that are known to be non‑compliant.

Distributor

An operator in the supply chain (e.g., reseller, marketplace) that makes a CRA‑covered product available on the EU market without being a manufacturer or importer. Must check CE marking and information, and ensure proper handling and cooperation with authorities.

SBOM (Software Bill of Materials)

A structured list of all components (including open‑source libraries) in a software product. Under the CRA, it supports transparency, vulnerability management, and technical documentation duties.

Secure Development Lifecycle (SDL)

A set of processes integrating security into all stages of software development (requirements, design, implementation, testing, deployment, maintenance). Often required contractually to support CRA security‑by‑design obligations.

Audit rights (in contracts)

Clauses giving a customer the right to review a supplier’s processes, documentation, or facilities, or to receive independent audit reports, to verify compliance with security and CRA obligations.

Market Surveillance Authority (MSA)

A national authority responsible for checking products already on the market, ensuring they comply with EU rules (including the CRA), and taking action such as inspections, corrective orders, withdrawals, and recalls.

Corrective Measure

An action ordered by an authority to bring a non-compliant product into conformity, such as issuing a security patch, changing configurations, updating documentation, or improving processes.

Withdrawal

A measure requiring that a product be removed from the supply chain so it is no longer made available on the market, while existing users may still keep using it.

Recall

A measure requiring action on products already supplied to end users, such as asking users to return, disable, or update the product because it is unsafe or insecure.

Turnover-Based Fine

An administrative fine calculated as a percentage of the company’s global annual turnover, used for serious CRA infringements to ensure penalties are effective and dissuasive.

Periodic Penalty Payment

A daily or recurring financial penalty imposed until the company complies with an authority’s order, such as releasing a security patch or withdrawing a product.

Cyber Resilience Act (CRA)

An EU Regulation that sets cybersecurity requirements for products with digital elements throughout their lifecycle, including design, development, vulnerability handling, and post-market monitoring.

Product with Digital Elements (PDE)

Any software or hardware product that directly or indirectly has a data connection or digital functionality; core scope of the CRA.

Gap Analysis

A structured comparison between current practices and CRA requirements to identify missing controls, processes, and documentation.

Vulnerability Handling Process

A defined set of activities to receive, assess, remediate, and communicate security vulnerabilities in products, including reporting to authorities where required.

Secure SDLC (Secure Software Development Lifecycle)

A software development process that integrates security activities (e.g., threat modelling, code review, security testing) at each phase.

Post-Market Monitoring

Ongoing activities after a product is placed on the market to detect new vulnerabilities, incidents, and security issues and respond with updates or mitigations.