\n| 36 Months (December 2027)<\/b><\/td>\n | Full applicability, including all product requirements and conformity assessment<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n What is noteworthy about this phased approach is the earlier reporting obligations. They come into force more than a year before the product requirements \u2013 meaning that manufacturers must already submit reports whilst their products are not yet formally required to meet the full requirements. Anyone who interprets the transition period as \u2018until the end of 2027\u2019 will miss this earlier deadline. As the deadlines are linked to the entry into force of the Regulation and the Commission is continually adopting supplementary legal acts, the current status should be checked before implementation.<\/p>\n To which products does the Cyber Resilience Act apply?<\/h2>\nThe Cyber Resilience Act applies to products with digital elements \u2013 that is, to hardware and software whose intended or reasonably foreseeable use involves a direct or indirect data connection to a device or network. The scope is deliberately broad: it ranges from operating systems, applications and libraries, through routers, cameras and industrial control systems, to connected toys and wearables. It also covers associated remote processing solutions that are necessary for the product to function.<\/p>\n Excluded are products for which sector-specific EU legislation containing cybersecurity requirements already exists \u2013 in particular medical devices, motor vehicles, civil aviation and marine equipment. Also excluded are products developed exclusively for national security, defence or the processing of classified information.<\/p>\n A key practical distinction concerns open-source software. It does not fall within the scope of the Regulation as long as it is made available outside the context of a commercial activity; however, anyone who commercially exploits open-source software or integrates it into a product and places it on the market bears full manufacturer responsibility for that product. For organisations that maintain and provide ongoing support for open-source components, the Regulation sets out a separate, significantly lighter set of obligations.<\/p>\n Pure cloud services with no product component, on the other hand, do not generally fall under the Cyber Resilience Act, but are covered by NIS-2 \u2013 a distinction that must be carefully drawn on a case-by-case basis for hybrid offerings comprising an app and a backend.<\/p>\n Which product categories does the Cyber Resilience Act distinguish between?<\/h2>\nThe Cyber Resilience Act classifies products into three risk levels, on which the rigour of the conformity assessment depends.<\/p>\n \n\n\nCategory<\/strong><\/td>\nExamples<\/strong><\/td>\nValuation method<\/strong><\/td>\n<\/tr>\n\nStandard products<\/strong><\/td>\n| The vast majority of connected products, such as applications without safety-critical functions<\/td>\n | Self-assessment by the manufacturer<\/td>\n<\/tr>\n | \nKey products, Class I<\/strong><\/td>\n| Password managers, browsers, antivirus software, VPNs, identity management, network management, operating systems, home routers, connected toys<\/td>\n | Self-assessment where harmonised standards are applied in full; otherwise, involvement of a notified body<\/td>\n<\/tr>\n | \nKey products, Class II<\/strong><\/td>\n| Hypervisors, container runtime environments, firewalls and intrusion detection for industrial applications, tamper-proof microcontrollers<\/td>\n | Mandatory involvement of a notified body<\/td>\n<\/tr>\n | \nCritical products<\/strong><\/td>\n| Hardware security modules, smart cards and secure elements, smart meter gateways<\/td>\n | Possible additional requirement for European cybersecurity certification<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n In practical terms, this means that decisions need to be taken at an early stage: the classification determines the effort involved, the timetable and the costs of market authorisation. As notified bodies are only just being established and their capacity is likely to be limited, classifying their own product portfolio is one of the steps that manufacturers should not delay until shortly before the end of the transition period.<\/p>\n What security requirements does the Cyber Resilience Act set out?<\/h2>\nThe Cyber Resilience Act sets out key requirements for the product itself, which must be applied following a risk assessment. The key points are:<\/p>\n \n- Delivery without any known exploitable vulnerabilities<\/strong> at the time of placing on the market<\/li>\n
- Secure default configuration<\/strong>, including the ability to reset the product to this state<\/li>\n
- Protection against unauthorised access<\/strong> through appropriate authentication and access control mechanisms<\/li>\n
- Confidentiality and integrity<\/strong> of stored, transmitted and processed data, in particular through encryption<\/li>\n
- Data minimisation:<\/strong> Processing only the data necessary for the purpose<\/li>\n
- Availability and resilience<\/strong> against denial-of-service attacks<\/li>\n
- Reduction of the attack surface<\/strong>, including the limitation of external interfaces<\/li>\n
- Limitation of the impact of incidents<\/strong> through appropriate segregation and isolation mechanisms<\/li>\n
- Security-related logging<\/strong> of accesses and changes<\/li>\n
- Secure update mechanisms<\/strong>, where possible automatic and with clear user information<\/li>\n<\/ul>\n
It is striking that these requirements are not technically new \u2013 they are in line with what established security standards have been recommending for years. What is new is that they are now mandatory. An ISO 27001<\/a> management system and an established secure development process already cover a significant proportion of the requirements methodologically; the gap usually lies not in the security technology itself, but in documentation, evidence management and ensuring that security measures are consistently embedded throughout the product\u2019s lifecycle.<\/p>\nWhat does the Cyber Resilience Act require in relation to the handling of vulnerabilities?<\/h2>\nThe Cyber Resilience Act requires a continuous process for addressing vulnerabilities throughout the entire support period \u2013 the part of the regulation which, experience shows, demands the greatest organisational restructuring from manufacturers. Among other things, the following are mandatory:<\/p>\n A Software Bill of Materials (SBOM) in a machine-readable format, covering at least the top-level components. This is essential for being able to determine, in the event of a newly discovered vulnerability in a library, which of the manufacturer\u2019s own products are affected.<\/p>\n A procedure for the coordinated disclosure of vulnerabilities, including a published contact address for reports, as well as regular testing and reviews of the product. Any vulnerabilities found must be rectified immediately, and security updates must be provided free of charge and separately from functional updates, so that users can install them without any functional changes.<\/p>\n The support period is crucial. It must reflect the expected product lifecycle and, as a general rule, must be at least five years, unless the product\u2019s lifespan is shorter. Furthermore, security updates provided must remain available for a period of several years. Crucially for buyers: the support period must be specified and thus becomes a comparable product feature \u2013 similar to a warranty statement. The exact timeframes should be checked on a case-by-case basis against the text of the regulation.<\/p>\n What reporting obligations does the Cyber Resilience Act set out?<\/h2>\nThe Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities and serious security incidents that affect product safety. Reports are submitted in stages via a central platform operated by the European Cybersecurity Agency to the relevant national computer emergency response team and the Agency.<\/p>\n The procedure follows the model now familiar from other EU legislation: an early warning within 24 hours of becoming aware of the issue, a more detailed report within 72 hours, and a final report once the issue has been resolved. In addition, affected users must be informed about the vulnerability or incident and the necessary measures, and, where appropriate, the wider public must also be informed.<\/p>\n In practical terms, this means that manufacturers must have a reporting system that is accessible at all times. Twenty-four hours is not enough time to clarify responsibilities, assessment criteria and access to the reporting platform only once an incident has occurred \u2013 particularly as other obligations may apply in parallel, such as those under the GDPR where personal data is affected, or under NIS-2 and DORA for the organisation itself. As an actively exploited vulnerability is often also the entry point for a ransomware<\/a> attack on customers, the reporting process and crisis communication run concurrently in such situations.<\/p>\nHow does the conformity assessment under the Cyber Resilience Act work?<\/h3>\nConformity assessment under the Cyber Resilience Act follows the framework of European product law: the manufacturer carries out a risk assessment, draws up technical documentation, demonstrates compliance with the essential requirements, issues an EU declaration of conformity and affixes the CE marking.<\/p>\n The process involved depends on the product category. For standard products, internal production control is sufficient \u2013 that is, a self-assessment without the involvement of third parties. For Class I essential products, self-assessment is possible if the relevant harmonised standards are fully applied; otherwise, a notified body must be involved. For Class II essential products, the involvement of a notified body is always required; for critical products, European cybersecurity certification may also be required.<\/p>\n The reference to harmonised standards is the key practical consideration here. As long as the relevant European standards have not been finalised and listed in the Official Journal, the presumption of conformity \u2013 which allows manufacturers to demonstrate compliance in a straightforward manner \u2013 does not apply. The status of standardisation is therefore at least as relevant to planning as the deadlines set out in the Regulation itself.<\/p>\n How does the Cyber Resilience Act relate to NIS-2 and DORA?<\/h2>\nThe Cyber Resilience Act regulates products, whilst NIS-2 and DORA regulate organisations. The legislation is interlinked: operators are required to use secure products, and the CRA ensures that such products are available in the first place.<\/p>\n \n\n\nLegal act<\/strong><\/td>\nRecipient<\/strong><\/td>\nSubject<\/strong><\/td>\n<\/tr>\n\n| Cyber Resilience Act<\/b><\/td>\n | Manufacturers, importers, distributors<\/td>\n | Cybersecurity of products with digital elements throughout their lifecycle<\/td>\n<\/tr>\n | \n| NIS-2-Richtlinie<\/b><\/td>\n | Key and important organisations in 18 sectors<\/td>\n | Risk management, reporting requirements and organisational governance<\/td>\n<\/tr>\n | \n| DORA<\/b><\/td>\n | Financial institutions and their ICT service providers<\/td>\n | Digital operational resilience in the financial sector<\/td>\n<\/tr>\n | \n| DSGVO<\/b><\/td>\n | Data controllers and data processors<\/td>\n | Protection of personal data, security of processing<\/td>\n<\/tr>\n | \n| KI-Verordnung<\/b><\/td>\n | Providers and operators of AI systems<\/td>\n | Cybersecurity requirements can be met through CRA compliance<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n For operators, this results in a convenient synergy: in future, some of the requirements that NIS-2 imposes on supplier management can be demonstrated using the manufacturer\u2019s CRA certificates. Conversely, the CE marking does not relieve the operator of their responsibilities \u2013 it provides information about the product, not about its secure configuration or its operation.<\/p>\n What does the Cyber Resilience Act mean for procurement and operators?<\/h2>\nFor operators and procurement bodies, the Cyber Resilience Act is, above all, a tool: it establishes comparable, enforceable product characteristics where, until now, manufacturers\u2019 commitments have varied in their level of binding force. In tenders and supplier evaluations, this allows for specific enquiries regarding:<\/p>\n \n- Specification of the support period and the availability period for security updates<\/li>\n
- Software bill of materials and handling of third-party components<\/li>\n
- Procedures for the coordinated disclosure of vulnerabilities, including a reporting contact<\/li>\n
- Provision of security updates free of charge and separately from functional updates<\/li>\n
- Secure default configuration and documented hardening recommendations<\/li>\n
- Classification of the product and the chosen method of conformity assessment<\/li>\n<\/ul>\n
These points are in any case part of supplier management and can be aligned with the contractual requirements of a data processing agreement as well as with the obligations to provide evidence under NIS-2. For operators of critical infrastructure and public authorities, the support period is particularly relevant, as procurement cycles in these sectors are often longer than the standard update commitments offered by the market.<\/p>\n For communications solutions, it is worth reviewing the same set of questions. How long are security updates guaranteed for, how are they delivered, what is the reporting procedure for identified vulnerabilities, and what standard configuration is provided \u2013 these are questions that can be clarified before deployment and which, once deployment has taken place, can only be addressed with considerable effort.<\/p>\n What penalties does the Cyber Resilience Act provide for?<\/h2>\nThe Cyber Resilience Act provides for graduated fines to be imposed by the national market surveillance authorities. For breaches of the essential security requirements, as well as of the obligations regarding vulnerability management and reporting, the fines range up to 15 million euros or 2.5 per cent of global annual turnover, whichever is higher. Lower fines apply for breaches of other obligations and for providing incorrect or incomplete information to authorities and notified bodies.<\/p>\n In practice, the measures under product law are at least as relevant. Market surveillance authorities may prohibit the placing of products on the market, order recalls and have products withdrawn from the market \u2013 consequences that directly affect a manufacturer\u2019s sales. Which authorities in Germany will be responsible depends on the national implementation and should be checked against the current state of the law.<\/p>\n Summary: Key points on the Cyber Resilience Act<\/h2>\n\n- The Cyber Resilience Act is Regulation<\/strong> (EU) 2024\/2847 and makes cybersecurity a prerequisite for market access for products containing digital elements.<\/li>\n
- It applies to manufacturers, not operators<\/strong>; compliance is demonstrated via the CE marking.<\/li>\n
- The Regulation will be implemented in stages<\/strong>: Reporting obligations come into force well before the product requirements become fully applicable at the end of 2027.<\/li>\n
- Virtually all connected hardware and software products<\/strong> are covered; exceptions include sectors subject to sector-specific regulations and open-source software provided on a non-commercial basis.<\/li>\n
- The risk classification<\/strong> into standard products, essential products in Classes I and II, and critical products determines the conformity assessment procedure.<\/li>\n
- At the heart of the product requirements are \u2018security by design\u2019 and \u2018security by default\u2019<\/strong>, as well as the requirement that products be delivered without any known exploitable vulnerabilities.<\/li>\n
- A software bill of materials (SBOM)<\/strong>, a procedure for the coordinated disclosure of vulnerabilities, and free security updates separate from functional updates are mandatory.<\/li>\n
- The support period is generally at least five years<\/strong> and becomes a comparable product characteristic that must be specified.<\/li>\n
- Actively exploited vulnerabilities and serious incidents<\/strong> must be reported within 24 and 72 hours, respectively, depending on severity, supplemented by a final report.<\/li>\n
- The CRA provides verifiable evidence<\/strong> for procurers and operators \u2013 but does not replace the obligation to ensure secure configuration and secure operation.<\/li>\n<\/ul>\n
<\/p>\n","protected":false},"excerpt":{"rendered":" The Cyber Resilience Act (CRA) is Regulation (EU) 2024\/2847 on horizontal cybersecurity requirements for products with digital elements. The Cyber Resilience Act requires manufacturers to secure hardware and software throughout their entire life cycle, address vulnerabilities, provide security updates and report vulnerabilities that are actively being exploited. Products without proven compliance may no longer be […]<\/p>\n","protected":false},"featured_media":20691,"template":"","class_list":["post-20690","lexicon","type-lexicon","status-publish","has-post-thumbnail","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/teamwire.eu\/en\/wp-json\/wp\/v2\/lexicon\/20690","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/teamwire.eu\/en\/wp-json\/wp\/v2\/lexicon"}],"about":[{"href":"https:\/\/teamwire.eu\/en\/wp-json\/wp\/v2\/types\/lexicon"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/teamwire.eu\/en\/wp-json\/wp\/v2\/media\/20691"}],"wp:attachment":[{"href":"https:\/\/teamwire.eu\/en\/wp-json\/wp\/v2\/media?parent=20690"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} | | | | | | | | | | | | |