The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets mandatory cybersecurity requirements for hardware and software products with digital elements made available on the European Union market. Manufacturers must assess cybersecurity risks, build appropriate security into their products, handle vulnerabilities during the support period, and demonstrate conformity before placing products on the market.
For manufacturers and product security teams, the immediate priority is vulnerability and incident reporting, which has applied since September 11, 2026. The main product-security and vulnerability handling requirements apply from December 11, 2027. This guide explains the scope, product categories, technical requirements, testing evidence, and second-round SECURE funding.
CRA funding: second round now open. Eligible SMEs can apply for up to €30,000, covering 50% of eligible project costs, through December 11, 2026. View SECURE's second open call or see eligible work and exclusions below.
Cyber Resilience Act timeline and deadlines
The Regulation entered into force on December 10, 2024. It applies directly in EU Member States without national transposition.
June 11, 2026: Chapter IV provisions concerning the notification of conformity assessment bodies began applying.
September 11, 2026: Article 14 reporting obligations began applying to manufacturers.
December 11, 2027: the main CRA obligations apply, including Annex I product-security and vulnerability handling requirements.
Article 69 distinguishes products already placed on the market from those placed on the market after the main application date. Products placed on the market before December 11, 2027 are generally subject to the main requirements only if substantially modified from that date. Article 14 reporting duties also cover in-scope products placed on the market before that date. A substantial modification affects conformity with the essential cybersecurity requirements or changes the intended purpose for which the product was assessed.
Legal context
Adopted by the European Parliament and the Council on October 23, 2024, the European Cyber Resilience Act establishes horizontal cybersecurity requirements for the EU market. The CRA addresses cybersecurity across the digital supply chain by attaching obligations to manufacturers, importers, distributors, and other economic operators. It complements the NIS2 Directive, which focuses on cybersecurity risk management and incident reporting by covered entities, and the EU Cybersecurity Act, which establishes European cybersecurity certification schemes.
For digital or connected products, cybersecurity threats can affect design, components, remote functions, and the mechanisms used to deliver security updates. The CRA focuses on those products and their lifecycle. NIS2 focuses on covered organizations and their operations. A business can fall under both frameworks. The European Commission's July 2026 implementation guidance explains scope, support periods, substantial modifications, and reporting through practical examples; that guidance is non-binding.
Which products are affected by the EU Cyber Resilience Act?
Products with digital elements
Article 3(1) defines products with digital elements as software or hardware products and their remote data processing solutions, including software or hardware components placed on the market separately. Article 2(1) brings them within scope where their intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.
Consumer IoT devices and embedded systems
Standalone software and operating systems
Industrial control components
Network infrastructure equipment and security products
Hybrid hardware and software products
The manufacturer's geographic location does not remove these obligations when its products are made available on the EU market.
SaaS and remote data processing solutions
Standalone SaaS services are generally outside the CRA's product scope. However, remote data processing solutions are included where the software is designed and developed by, or under the responsibility of, the manufacturer and its absence would prevent the product from performing one of its functions. For example, a manufacturer-operated cloud function essential to a connected device may form part of the product. Hosting software in the cloud does not by itself settle the scope question.
Exclusions
Article 2 provides specific exclusions, including products covered by the EU medical-device and in vitro diagnostic-device regulations, products covered by the motor-vehicle general safety regulation, aviation products certified under Regulation (EU) 2018/1139, and marine equipment within Directive 2014/90/EU. Products developed or modified exclusively for national security or defense purposes, and products specifically designed to process classified information, are also excluded. Having another cybersecurity obligation does not automatically exempt a product from the CRA.
Product classification
The CRA distinguishes a default category, important products in Annex III, and critical products in Annex IV. Important products are divided into Class I and Class II. Important and critical products are subject to stricter conformity assessment procedures. Classification depends on whether the product has the core functionality of a listed category, rather than simply on whether it contains a listed component.
Important Class I: examples include operating systems, browsers, password managers, antivirus software, VPN products, SIEM systems, routers, and microprocessors or microcontrollers with security-related functionality.
Important Class II: hypervisors and relevant container runtime systems; firewalls and intrusion detection or prevention systems; tamper-resistant microprocessors and microcontrollers.
Critical products: hardware devices with security boxes; smart meter gateways and other listed devices for advanced security purposes; smartcards and similar devices, including secure elements.
Default category: in-scope products whose core functionality does not place them in Annex III or Annex IV.
Use the category definitions in Implementing Regulation (EU) 2025/2392 when classifying a product. Product labels such as “smart speaker,” “chip,” or “security module” alone can be misleading; the technical functionality matters.
Cyber Resilience Act requirements for manufacturers
Annex I has two parts: cybersecurity requirements for product properties and vulnerability handling requirements. Article 13 sets out manufacturer obligations, including the cybersecurity risk assessment that informs how the requirements apply.
1. Security requirements for product properties
Under Article 13(2)–(4), manufacturers must assess cybersecurity risks, take the findings into account throughout planning, design, development, production, delivery, and maintenance, and document and update the assessment as appropriate during the support period. The assessment forms part of the technical documentation required by Article 31 and Annex VII.
Annex I, Part I requires a level of cybersecurity appropriate to the risks. Based on the risk assessment and where applicable, product requirements include:
Making products available without known exploitable vulnerabilities
Secure-by-default configuration, subject to the specified exception for tailor-made business products
Appropriate authentication and access control to protect against unauthorized access
Confidentiality and integrity protection for data, commands, programs, and configurations
Data minimization and protection of essential functions against disruption
Limited attack surfaces and measures that reduce the impact of exploitation
Security-related recording and monitoring, with a user opt-out
Secure update capabilities, including automatic security updates where applicable
Secure, permanent removal of data and settings, and secure transfer where supported
The risk assessment must explain which requirements apply and how they are implemented. Where a requirement does not apply, the technical documentation must clearly justify that conclusion. A secure software development lifecycle, threat modeling, secure coding, and documented validation are practical ways to support this work; they should be selected and scoped to the product’s risks.
2. Vulnerability-handling requirements
The general vulnerability handling requirements apply from December 11, 2027. They arise from Article 13(8) and Annex I, Part II, and should be distinguished from the earlier Article 14 reporting duties.
Identify and document vulnerabilities and components, including a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least top-level dependencies
Apply effective and regular security tests and reviews
Address and remediate vulnerabilities without delay in relation to the risks, including through security updates
Provide security updates separately from functionality updates where technically feasible
Maintain and enforce a coordinated vulnerability disclosure policy and a vulnerability-reporting contact
Distribute security updates securely and without delay, free of charge except for the specified tailor-made business-product exception
Publish information about fixed vulnerabilities after updates are available, with the limited justified delay allowed to give users time to patch
3. Support periods and update availability
Article 13(8) requires a support period reflecting how long the product is expected to be used, considering the product’s purpose, reasonable user expectations, and other relevant factors. The minimum is generally five years; if expected use is shorter, the support period corresponds to that shorter period. Five years is a floor, rather than a default for every product. The Commission’s guidance, Section 5, explains why longer-lived products can require longer support.
Manufacturers must document how they determined the support period and clearly indicate its end date, at least the month and year, at purchase (Article 13(19)). Each security update issued during the support period must remain available for at least 10 years after issue or the remainder of the support period, whichever is longer (Article 13(9)). This availability rule is distinct from the obligation to develop new updates.
CRA vulnerability and incident reporting
Manufacturers have been subject to Article 14 reporting duties since September 11, 2026. Manufacturers must report actively exploited vulnerabilities contained in their products and severe incidents affecting product security. These duties do not mean every newly discovered vulnerability or cybersecurity incident must be reported to authorities.
An actively exploited vulnerability is one for which reliable evidence shows that a malicious actor has exploited it in a system without the system owner's permission. A severe incident meets either Article 14(5) criterion: it harms or could harm the product's ability to protect sensitive or important data or functions, or it causes or could cause malicious code to be introduced or executed in the product or a user's systems. The first criterion concerns availability, authenticity, integrity, or confidentiality. Assess these triggers promptly rather than waiting for a final root-cause report. See the Commission's reporting guidance.
Reports go through ENISA’s Single Reporting Platform to the relevant coordinating computer security incident response team (CSIRT) and the European Union Agency for Cybersecurity (ENISA). Article 14(7) determines the appropriate national endpoint, including for manufacturers without a main establishment in the EU.
Report stage | Actively exploited vulnerability | Severe incident affecting product security |
|---|---|---|
Early warning | Without undue delay, within 24 hours of becoming aware | Without undue delay, within 24 hours of becoming aware |
Vulnerability or incident notification | Without undue delay, within 72 hours of becoming aware, unless already provided | Without undue delay, within 72 hours of becoming aware, unless already provided |
Final report | No later than 14 days after a corrective or mitigating measure becomes available, unless already provided | Within one month after submitting the incident notification, unless already provided |
Article 14(8) also requires manufacturers to inform impacted users, and where appropriate all users, about the vulnerability or incident and necessary mitigation measures without undue delay. Reporting, user communication, and technical remediation need coordinated owners and escalation procedures.
Conformity assessment, technical documentation, and CE marking
Before placing a product on the market under the applicable CRA requirements, the manufacturer must complete the relevant conformity assessment under Article 32 and Annex VIII, compile technical documentation under Article 31 and Annex VII, draw up an EU declaration of conformity under Article 28, and affix the CE marking under Articles 29–30.
Technical documentation must demonstrate how the product and the manufacturer’s processes meet Annex I. It includes the risk assessment, product and development information, vulnerability handling processes, support-period justification, and testing evidence. Article 13(13) requires the documentation and declaration to remain available to market surveillance authorities for at least 10 years after market placement or the support period, whichever is longer.
CRA conformity assessment routes by product category
Category | Example products | Assessment route |
|---|---|---|
Default category | Mobile apps or computer games whose core functionality is not an Annex III or IV category | Internal control (Module A) is permitted; other Article 32(1) routes are available. |
Important Class I — Annex III | Operating systems, antivirus software, password managers, VPN products, routers | Internal control depends on fully applying the relevant harmonized standards, common specifications, or qualifying certification. Otherwise, third-party assessment is required for the requirements concerned. |
Important Class II — Annex III | Firewalls, hypervisors, relevant container runtimes, tamper-resistant processors | EU-type examination plus conformity to type (Modules B+C), full quality assurance (Module H), or a qualifying European cybersecurity certification scheme where available and applicable. |
Critical — Annex IV | Smartcards and secure elements, smart meter gateways, hardware devices with security boxes | Certification under Article 8(1) where required; otherwise the Article 32(3) routes used for Class II products. |
For Class I products, merely following a general security standard does not automatically permit self-assessment. The conditions in Article 32(2) must be met. European cybersecurity certification is a legal route only where the relevant scheme and Commission conditions make it available and applicable. See the Commission's conformity-assessment guidance.
Open source software
Free and open-source software made available outside the course of commercial activity is outside the CRA's product scope. This is not determined by whether the software is in an important or critical category. Manufacturers integrating open-source components into commercial products must exercise due diligence and remain responsible for their own products under Article 13(5)–(6).
The CRA also establishes a separate role for open-source software stewards: legal persons providing sustained, systematic support for specified open-source products intended for commercial activities and ensuring their viability. Their tailored Article 24 obligations include a cybersecurity policy, cooperation with authorities, and specified reporting duties. These apply from December 11, 2027. See the Commission’s open-source explanation.
Article 32(5) provides a conformity-assessment exception for manufacturers of free and open-source products in Annex III: they may use the Article 32(1) procedures, including internal control, if they make the technical documentation public at market placement. This is an assessment-route exception, rather than a general exemption from CRA requirements.
Penalties for non-compliance with EU Cyber Resilience Act
Enforcement of the Cyber Resilience Act is carried out by the Member States through their designated market surveillance authorities. Each Member State is responsible for establishing rules on penalties applicable to infringements of the Regulation and for ensuring their implementation.
Administrative fines may reach up to €15 million or 2.5% of the total worldwide annual turnover of the preceding financial year, whichever is higher, for non-compliance with the essential cybersecurity requirements set out in Annex I and the related obligations imposed on manufacturers.
Market surveillance authorities are empowered to take corrective measures where non-compliance is identified. These measures may include requiring the economic operator to bring the product into conformity, restricting or prohibiting its availability on the market, or ordering its withdrawal or recall in accordance with the applicable market surveillance framework.
CRA compliance checklist for manufacturers
Start with a product inventory, scope and classification decision, then map the applicable requirements to accountable owners and evidence. The examples below are practical preparation records, rather than a universal list of mandatory document formats.
Workstream | Evidence to prepare |
|---|---|
Scope and classification | Product and version inventory; intended use and remote functions; Annex III/IV classification rationale; selected assessment route |
Cybersecurity risk assessment — Article 13(2)–(4) | Documented risks, applicable requirements, design decisions, and justification for requirements deemed inapplicable |
Secure design and development — Annex I, Part I | Threat models, secure configuration decisions, access-control and update validation, and security test results appropriate to the risks |
Vulnerability handling — Article 13(8); Annex I, Part II | Machine-readable SBOM, component inventory, disclosure policy, reporting contact, remediation records, and retest results |
Reporting — Article 14 | Named escalation owners, trigger assessment, 24-hour and 72-hour workflows, platform access, and user communication procedures |
Support and conformity documentation | Support-period rationale and end date; update availability plan; Annex VII technical file; declaration and CE-marking arrangements |
Example: preparing a connected sensor for the CRA
Consider a hypothetical manufacturer selling a connected temperature sensor in the EU. Its cloud service is developed under the manufacturer's responsibility and is required for the sensor's alert function. The manufacturer would assess that remote function alongside the device, while checking the product's classification and any exclusions.
Assess risks: identify how unauthorized access, false readings, or a compromised update could affect the product and its users.
Build and test controls: implement appropriate access controls and update validation, then test device interfaces, cloud APIs, and relevant attack paths. Record findings, fixes, and retest results.
Track components: maintain a machine-readable SBOM and monitor relevant component vulnerabilities.
Plan ongoing support: justify the support period, assign vulnerability-reporting owners, and establish secure update and user-notification procedures.
Prepare conformity evidence: connect the risk assessment, design decisions, security tests, and vulnerability-handling records in the technical documentation for the applicable assessment route.
This example illustrates how the workstreams connect; the product's actual risks and applicable requirements determine the measures and evidence needed.
SECURE's second round of CRA funding
The SECURE project (Strengthening EU SMEs Cyber Resilience), funded under the Digital Europe Programme, provides grants to help eligible European micro, small and medium-sized enterprises prepare for the Cyber Resilience Act. Applicants must demonstrate that their current or planned products and business activities fall within CRA scope.
SECURE’s second funding round is open from October 1 through December 11, 2026, with a total budget of €11.5 million.
Funding detail | Second round |
|---|---|
Maximum grant | €30,000 per project |
Funding rate | 50% of eligible project costs |
Application deadline | December 11, 2026 |
For example, a project with €20,000 in eligible costs could receive €10,000. Receiving the maximum €30,000 grant requires at least €60,000 in eligible project costs.
Eligible work may include:
Product penetration testing, vulnerability assessments and remediation verification
CRA gap assessments, risk analysis and remediation planning
Secure development practices, threat modeling and software bill of materials (SBOM) management
Product cybersecurity training and incident response planning
Formal CRA certification audits, CRA third-party assessment services, and the regulatory obligations and documentation support category are not eligible for funding in this second round.
Check the second SECURE open call for the application documents, eligible countries, ownership and control requirements, and submission instructions. Proposed activities and costs must meet the call’s eligibility rules.
Is penetration testing required under the Cyber Resilience Act?
The CRA does not impose a blanket requirement to perform a named penetration-testing methodology on every product. It does require risk-based product security, products made available without known exploitable vulnerabilities where applicable, and effective, regular security tests and reviews under Annex I, Part II(3).
Penetration testing can provide evidence of how a product resists realistic exploitation. Its scope should follow the cybersecurity risk assessment under Article 13(2)–(4) and cover relevant interfaces, authentication and authorization, update mechanisms, exposed services, and other material attack paths.
A penetration testing report can contribute to the Article 31 technical documentation by recording scope, methods, findings, limitations, and remediation verification. It does not by itself demonstrate conformity with every CRA requirement. Testing should complement design review, dependency management, secure development, and ongoing vulnerability handling.
Conclusion
CRA preparation connects product engineering, vulnerability management, reporting, and conformity documentation. Manufacturers should have reporting workflows operating now and use the period before December 2027 to address product-security gaps, establish support commitments, and prepare evidence for the correct assessment route. Eligible SMEs can also consider SECURE's second funding round to support practical cybersecurity improvements.
