We help manufacturers of industrial, IoT, embedded and software products classify them under Regulation (EU) 2024/2847, meet Annex I and prepare the evidence for CE marking. We work in English and Spanish with manufacturers across the EU.
For
You receive
The Cyber Resilience Act applies to hardware and software products with digital elements made available on the EU market. It applies in full from 11 December 2027, but the reporting obligations of Article 14 have applied since 11 September 2026 (Article 71), and they also cover products placed on the market before December 2027 (Article 69(3)). Products must meet the essential cybersecurity requirements of Annex I Part I, and the manufacturer's processes must meet the vulnerability handling requirements of Annex I Part II: a software bill of materials, regular security testing, a coordinated vulnerability disclosure policy, secure update distribution and security updates throughout a support period of at least five years, unless the product is expected to be in use for less time (Article 13(8)).
The conformity assessment route depends on classification. Most products are in the default category and can use internal control (Module A). Important products are listed in Annex III in two classes, and Implementing Regulation (EU) 2025/2392 gives the technical description of each category. Class I products can use Module A only if the manufacturer has applied in full harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least ‘substantial’; otherwise a notified body takes part through EU-type examination (Module B followed by Module C) or full quality assurance (Module H) (Article 32(2)). Class II products must use Module B and C, Module H or such a certification scheme (Article 32(3)). Critical products in Annex IV, such as hardware devices with security boxes, smart meter gateways, smartcards and secure elements, may be required to hold a European cybersecurity certificate under Article 8(1); where that requirement does not apply, they follow the class II procedures (Article 32(4)).
Presumption of conformity comes from harmonised standards whose references are published in the Official Journal, from common specifications, and from European cybersecurity certificates or EU statements of conformity to the extent they cover Annex I (Article 27). The Commission asked CEN, CENELEC and ETSI to draft these standards in Implementing Decision C(2025) 618 of 3 February 2025: CEN and CENELEC lead the horizontal standards, and ETSI TC CYBER develops product-specific vertical standards in the EN 304 6xx series. A standard gives presumption only from the date its reference is cited in the Official Journal; until then it can guide your design and documentation but does not replace the conformity assessment route of your product class. The same applies to evidence produced against IEC 62443-4-1 and IEC 62443-4-2: it can be mapped to Annex I, but it gives no presumption of conformity on its own. Whatever the route, the manufacturer draws up the technical documentation of Annex VII before placing the product on the market, signs the EU declaration of conformity (Article 28) and affixes the CE marking. We are not a notified body and do not issue certificates. We prepare your products, processes and documentation for the assessment, drawing on our work in CEN/CENELEC technical committees, ISO working groups, the ENISA ad hoc working groups for the EUCC scheme and the EUMSS candidate scheme, and ETSI, which we joined as a full member in 2026 to work in the EUSR group of TC CYBER. In an EU-funded review of three draft CRA harmonised standards, 34 of the 37 comments we submitted were taken up.
Analysis of each product's core functionality against Annex III, Annex IV and Implementing Regulation (EU) 2025/2392, including the integrated components such as network interfaces, real-time operating systems or security microcontrollers, with the conformity assessment routes open to you and whether a notified body is needed.
Typical duration: 1 to 2 weeks per product family
Review of design, code, configuration and processes against each requirement in Annex I Parts I and II, delivered as a prioritised engineering backlog your teams can plan against.
Typical duration: 4 to 8 weeks
Criteria for actively exploited vulnerabilities and severe incidents, roles and escalation, templates for the 24-hour early warning, the 72-hour notification and the final report, user information under Article 14(8), and a coordinated vulnerability disclosure policy with a single point of contact.
Typical duration: 3 to 5 weeks
SBOM generation in a commonly used machine-readable format from your build pipeline, component monitoring, a documented support period under Article 13(8), and the update distribution evidence that Annex VII asks for.
Typical duration: 4 to 6 weeks
Traceability from your IEC 62443-4-1 process evidence, IEC 62443-4-2 component evidence and, for radio equipment, EN 18031 assessments to each Annex I requirement, with the remaining gaps, so existing assessments are reused rather than repeated.
Typical duration: 3 to 6 weeks
An Annex VII structure for your product with the cybersecurity risk assessment, test report index, list of standards applied and a draft EU declaration of conformity following Annex V, ready to complete and to hand to a notified body where one is involved.
Typical duration: 3 to 4 weeks
Classification follows the product's core functionality. Class I of Annex III includes, among others, operating systems, routers, modems and switches, network management systems, boot managers, and microprocessors and microcontrollers with security-related functionalities. Class II covers hypervisors and container runtime systems, firewalls, intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers. Class II products always involve a third party: Module B and C, Module H or a European cybersecurity certification scheme at assurance level at least ‘substantial’ (Article 32(3)). Class I products can use internal control only where harmonised standards, common specifications or such a scheme have been applied in full (Article 32(2)). Integrating an Annex III component does not by itself make the host product important (Article 7(1)), so an industrial controller is not an important product just because it contains a security microcontroller or a network interface.
Not on their own. Under Article 27(1), presumption of conformity comes from harmonised standards whose references are published in the Official Journal for the CRA. IEC 62443-4-1 maps well to the development and vulnerability handling processes of Annex I Part II, and IEC 62443-4-2 to many of the product properties in Annex I Part I. EN 18031-1, -2 and -3 are harmonised standards under the Radio Equipment Directive, cited with restrictions by Implementing Decision (EU) 2025/138, for the cybersecurity requirements that Delegated Regulation (EU) 2022/30 has applied to certain radio equipment since 1 August 2025. Delegated Regulation (EU) 2026/339 repeals that act with effect from 11 December 2027, because the CRA's essential requirements include all the elements of those radio requirements; from then on the cybersecurity requirements for that equipment come from the CRA. Recital 30 of the CRA asks for the EN 18031 work to be taken into account in the CRA harmonised standards, so it is a good starting point. Some obligations have no counterpart in either series, such as Article 14 reporting, the minimum support period of Article 13(8) and the user information of Annex II. A traceability matrix lets you reuse the evidence in your technical documentation and close the gaps explicitly.
Since 11 September 2026, manufacturers must notify every actively exploited vulnerability in their products, and every severe incident having an impact on their security, through the single reporting platform established by ENISA (Articles 14 and 16). The notification goes to the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment and is simultaneously accessible to ENISA. For an exploited vulnerability: an early warning within 24 hours of becoming aware of it, a vulnerability notification within 72 hours and a final report no later than 14 days after a corrective or mitigating measure is available. For a severe incident: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month of the incident notification. The obligation also covers products placed on the market before 11 December 2027 (Article 69(3)), and you must inform affected users (Article 14(8)).
Annex I Part II(1) requires a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies of the product. It is part of the technical documentation (Annex VII, point 2(b)), and a market surveillance authority can ask for it on a reasoned request. Publishing it is your decision: Annex II only requires you to tell users where to find it if you choose to make it available. The Commission may specify its format and elements by implementing act (Article 13(24)). In practice we generate SPDX or CycloneDX from the build and go deeper than top-level dependencies, because the SBOM is what drives your vulnerability monitoring.
Annex VII sets the minimum: a general description of the product and its intended purpose; design, development and production information, including the system architecture; the vulnerability handling processes with the SBOM, the coordinated vulnerability disclosure policy and the update distribution solution; the cybersecurity risk assessment required by Article 13; the information used to set the support period; the harmonised standards or other solutions applied; test reports; and a copy of the EU declaration of conformity. It is drawn up before the product is placed on the market, kept up to date during the support period (Article 31) and kept available for at least 10 years or the support period, whichever is longer (Article 13(13)).
If you integrate open-source components, you remain responsible for them: Article 13(5) requires due diligence, and Article 13(6) requires you to report the vulnerabilities you find to the maintainer and to remediate them. A legal person other than a manufacturer that supports, on a sustained basis, the development of free and open-source products intended for commercial activities is an open-source software steward (Article 3(14)). Stewards have a lighter regime under Article 24: a documented cybersecurity policy, cooperation with market surveillance authorities, and notification of actively exploited vulnerabilities to the extent they are involved in development. Administrative fines do not apply to them (Article 64(10)).
Annex III has no category for programmable logic controllers or industrial controllers as such, so classification turns on each product's core functionality, read against the technical descriptions in Implementing Regulation (EU) 2025/2392. A router that controls the flow of data between networks is class I, whether wired, wireless or virtual; the same category covers cellular modems, managed switches and wireless access points. A gateway that mainly converts protocols needs a closer reading against that description. Network interface cards, controllers and adapters sold as products, including for Fieldbus, are physical network interfaces (class I); real-time operating systems are operating systems (class I); VPN gateways and privileged access management controlling access to IT or OT systems are also class I; firewalls and intrusion detection and prevention systems are class II. A microcontroller is class I only if its security functionalities aim to secure other products, networks or services beyond the microcontroller itself. A controller whose core functionality is control is not an important product because it integrates one of these components (Article 7(1)), but you must still show that the product as a whole meets Annex I. Machinery under Regulation (EU) 2023/1230 must meet both regulations and follow both conformity assessment procedures; recital 53 of the CRA notes that meeting the CRA can help with the requirements on protection against corruption and on the safety and reliability of control systems in sections 1.1.9 and 1.2.1 of Annex III to that Regulation.
Yes, where that is their core functionality. Class I point 1 of Annex III covers ‘identity management systems and privileged access management software and hardware, including authentication and access control readers, including biometric readers’. Implementing Regulation (EU) 2025/2392 describes identity management systems as products that provide authentication or authorisation, including access to digital resources or physical locations, and names single sign-on, federated identity, one-time password, authentication and multi-factor authentication software, and hardware authentication devices. As class I products, they can use internal control only where harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least ‘substantial’ have been applied in full (Article 32(2)). A cloud back end is part of your product if it is remote data processing: software you design and develop, or that is developed under your responsibility, without which the product cannot perform one of its functions (Article 3(2)). An enrolment or matching service that you develop and that your reader or app needs is therefore in scope; a cloud service developed outside your responsibility is not (recital 12). If the product is also a high-risk AI system under Article 6 of Regulation (EU) 2024/1689, meeting Annex I and stating it in the EU declaration of conformity means it is deemed to comply with the cybersecurity requirements of Article 15 of that Regulation (Article 12(1)).