# CVD Portal

> CVD Portal is a free, multi-tenant SaaS platform that gives EU manufacturers a whitelabel Coordinated Vulnerability Disclosure (CVD) portal and helps them comply with the EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847). From 11 September 2026, manufacturers of products with digital elements sold into the EU must receive vulnerability reports through a single point of contact and notify ENISA and national CSIRTs on fixed deadlines (Article 13 publication, Article 14 24-hour/72-hour/14-day reporting); the full regulation, including CE marking, applies from 11 December 2027. CVD Portal provides a branded HTTPS intake portal, 48-hour acknowledgment tracking, ENISA-aligned triage with CVSS scoring, and SRP-ready Article 14 filing packages prepared for manual submission.

## Core pages

- [Homepage](https://cvdportal.com/): What CVD Portal is and the CRA deadline it addresses.
- [How it works](https://cvdportal.com/how-it-works): Product walkthrough from portal setup to authority reporting.
- [Features](https://cvdportal.com/features): Article 13/14 SLA tracking, branded SPOC portal, ENISA-aligned triage.
- [Pricing](https://cvdportal.com/pricing): Free, Pro, and Enterprise plans (intake is free).
- [For researchers](https://cvdportal.com/researchers): How security researchers submit vulnerability reports.
- [Compare alternatives](https://cvdportal.com/compare): CVD Portal vs bug-bounty and VDP platforms for CRA use.
- [About](https://cvdportal.com/about): Company background.
- [Contact](https://cvdportal.com/contact): Get in touch.

## CRA compliance

- [EU Cyber Resilience Act: the complete guide](https://cvdportal.com/cra/articles): What the CRA is, who is in scope, the 11 September 2026 and 11 December 2027 deadlines, every obligation, penalties, and all 40 articles and annexes explained.
- [CRA hub](https://cvdportal.com/cra): Index of Cyber Resilience Act article explainers.
- [CRA timeline countdown](https://cvdportal.com/countdown): Key dates table and live countdown to 11 September 2026.
- [CRA checklist](https://cvdportal.com/cra-checklist): Step-by-step compliance checklist.
- [CRA tracker](https://cvdportal.com/cra-tracker): Regulatory deadline tracker.
- [CRA Exposure Study 2026](https://cvdportal.com/research/cra-exposure-2026): Original measured research. 145 EU manufacturers across four sectors scanned for RFC 9116 security.txt and a discoverable CVD policy; fewer than one in ten publish a valid security contact. Open methodology, CC BY 4.0 dataset, no company named.
- [Article 14 compliance](https://cvdportal.com/cra-article-14-compliance): The 24h/72h/14-day reporting obligation.
- [Coordinated Vulnerability Disclosure](https://cvdportal.com/coordinated-vulnerability-disclosure): CVD concepts and process.

## CRA FAQ

- [Do I have to wait for the EN 40000 standards before I can comply with the CRA?](https://cvdportal.com/faq/do-i-have-to-wait-for-the-en-40000-standards): Waiting is the wrong plan. No part of the EN 40000 series has been cited in the Official Journal, so the Article 27 presumption of conformity is unavailable, and Article 32(2) escalates a Class I important product to third-party assessment precisely where a manufacturer has not applied a harmonised standard or where none exists. Compliance is owed from 11 December 2027 whatever the standards do. The series is drafted under Commission standardisation request M/606, with parts 1-1, 1-2 and 1-3 past public enquiry and awaiting approval.
- [Do I have to report the same incident under the CRA, NIS2 and GDPR?](https://cvdportal.com/faq/do-i-report-the-same-incident-under-cra-nis2-and-gdpr): One event can trigger all three, and none of them excuses the others. CRA Article 14 binds the manufacturer when a vulnerability in its product is actively exploited or a severe incident affects product security, filed to a coordinating CSIRT and ENISA. NIS2 Article 23 binds essential and important entities when a significant incident disrupts their own services. GDPR Article 33 binds the controller within 72 hours of a personal data breach. The triggers, the subjects and the recipients differ, so the filings run in parallel.
- [Does the EU Cyber Resilience Act apply to open source software?](https://cvdportal.com/faq/does-the-cra-apply-to-open-source-software): The Cyber Resilience Act (Regulation (EU) 2024/2847) covers free and open source software only where it is supplied for distribution or use in the course of a commercial activity. Software its manufacturer does not monetise stays outside the scope. A paid or enterprise edition is placed on the market and carries the full manufacturer obligations. Legal persons who sustain a project intended for commercial use fall under the lighter steward regime in Article 24, which carries no CE marking and no administrative fines.
- [Does the CRA cover my web application?](https://cvdportal.com/faq/does-the-cra-cover-my-web-application): Generally no. Commission guidance confirms that software which executes remotely and is merely accessed by the user is not, on that basis alone, a product with digital elements. A web application reached exclusively through a browser therefore falls outside the CRA, as does a website that only presents information. Two things pull you back in. Shipping a client that users install and run locally is in scope, even where it is built with web technologies. And your backend enters scope where it supports a function of some other product.
- [Is my software update a substantial modification under the CRA?](https://cvdportal.com/faq/is-my-software-update-a-substantial-modification): Ask four questions from Commission guidance point 110. Does the update introduce new threat vectors, enable new attack scenarios, change the likelihood of previously identified attack scenarios, or change their impact? Where all four are negative and the assumptions in your risk assessment still hold, the update is unlikely to be substantial. Any single yes makes it substantial, as does a change to the intended purpose the product was assessed against. The size of the change is irrelevant.
- [Is there a CRA harmonised standard for my product category yet?](https://cvdportal.com/faq/is-there-a-cra-harmonised-standard-for-my-product-category): A draft or a work item exists for every Annex III category, and none of it is cited in the Official Journal, so the Article 27 presumption of conformity is unavailable for every product category without exception. Standardisation request M/606 splits into horizontal standards covering all products and vertical standards covering one category each. ETSI drafts most verticals as the EN 304 6xx series, where the number is 304 600 plus the mandate line item. CEN and CENELEC hold the semiconductor, smartcard, identity and metering categories.
- [What do I actually have to do to comply with the Cyber Resilience Act?](https://cvdportal.com/faq/what-do-i-actually-have-to-do-to-comply-with-the-cra): Compliance runs as an ordered sequence where each step feeds the next. Confirm the product is in scope and that you are its manufacturer, then classify it as default, Annex III important class I or II, or Annex IV critical. Run the Article 13(2) risk assessment, which determines which Annex I Part I requirements apply. Build to those, meet the Part II vulnerability handling requirements, compile Article 31 technical documentation, complete the Article 32 conformity assessment, draw up the EU declaration of conformity, affix the CE marking, and report under Article 14.
- [What documents and reports does the Cyber Resilience Act require me to produce?](https://cvdportal.com/faq/what-documents-does-the-cra-require-me-to-produce): The Cyber Resilience Act requires six artefacts. Technical documentation under Article 31 and Annex VII, which contains the risk assessment. An EU declaration of conformity under Article 28 and Annex V. A software bill of materials and a coordinated vulnerability disclosure policy, both under Annex I Part II. Information and instructions to the user under Annex II. Then the Article 14 filings once reporting begins. Technical documentation and the declaration are kept available to market surveillance authorities for at least 10 years or the support period, whichever is longer.
- [What does the Cyber Resilience Act require in a cybersecurity risk assessment?](https://cvdportal.com/faq/what-does-the-cra-require-in-a-risk-assessment): Article 13(2) of the Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to assess the cybersecurity risks of a product with digital elements and to carry the outcome through the planning, design, development, production, delivery and maintenance phases. Article 13(3) requires that assessment to be documented, kept updated across the support period, and to state which Annex I Part I point 2 requirements apply and how they are met. It forms part of the technical documentation under Article 31 and Annex VII, and the duty applies from 11 December 2027.
- [When does the CRA reporting clock start?](https://cvdportal.com/faq/when-does-the-cra-reporting-clock-start): The clock starts when you become aware, and Commission guidance now defines that moment. On detecting a suspicious event or receiving a report from a researcher, customer or authority, assess it immediately. You become aware once that initial assessment gives you a reasonable degree of certainty that a vulnerability in your product is being actively exploited, or that a severe incident has compromised your product's security. Receiving a report does not by itself start the clock, and neither does a vague suspicion you have not yet examined.
- [Which CSIRT do I report to under the CRA, and how does the ENISA single reporting platform work?](https://cvdportal.com/faq/which-csirt-do-i-report-to-under-the-cra): Article 14(7) of the Cyber Resilience Act routes every notification to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment in the Union, meaning where decisions about the cybersecurity of its products are predominantly taken. A manufacturer with no establishment in the Union follows a four-step fallback based on authorised representative, importer, distributor, then users. One submission through the ENISA single reporting platform reaches that CSIRT and ENISA simultaneously, and the deadlines run from 11 September 2026.

## Commission guidance worked examples (C(2026) 5252, verbatim)

- [How does core functionality decide a product's CRA classification?](https://cvdportal.com/cra-guidance/examples/core-functionality-and-product-classification): Classification follows core functionality, judged against the technical descriptions in Implementing Regulation (EU) 2025/2392. A product that merely integrates an operating system does not take on the core functionality of one. SOAR software generally exceeds the SIEM category and log viewers fall short of it. Modules offered on separate subscriptions are separate products, each classified on its own. Extra functions do not push a product into a stricter conformity route, and the presumption of conformity covers only what the harmonised standard covers.
- [How does the CRA cybersecurity risk assessment justify design decisions?](https://cvdportal.com/cra-guidance/examples/cra-risk-assessment-worked-examples): The Commission's risk assessment examples all turn on the same move. The Article 13(2) assessment decides what a product needs, and it can justify choices that look like gaps. Supporting a legacy protocol for interoperability, integrating a component bought before the CRA applied, placing an older design on the market without redesign, limiting a sensor's intended purpose instead of hardening it, and relying on the operating system's cryptography rather than writing your own are each defensible where the assessment carries them.
- [How long must a CRA support period be, and does a substantial modification extend it?](https://cvdportal.com/cra-guidance/examples/how-long-must-my-support-period-be): Article 13(8) sets the support period by reference to the time the product is expected to be in use. The five year figure is a safeguard floor rather than a default, and products expected to last longer need correspondingly longer periods. Article 13(10) lets a manufacturer remediate only the version last placed on the market, provided users can upgrade free of charge and without additional costs. A substantial modification triggers a reassessment but does not automatically reset or extend the period.
- [Is my cloud back end a remote data processing solution under the CRA?](https://cvdportal.com/cra-guidance/examples/is-my-backend-a-remote-data-processing-solution): Remote data processing is part of your product when two things hold together. The product cannot perform one of its functions without it, and the software was designed and developed by you or under your responsibility. Your own back end qualifies even when it runs on third-party infrastructure. A general purpose third-party SaaS does not, and is treated as a component instead. Systems your product never talks to directly fall outside, and a cellular network is neither a solution nor a component.
- [Are spare parts and repairs subject to the Cyber Resilience Act?](https://cvdportal.com/cra-guidance/examples/repairs-and-spare-parts-under-the-cra): Article 2(6) takes spare parts outside the CRA where they replace identical components in a product with digital elements. The Commission's examples turn on what identical means. A replacement module built to the same specifications is exempt, whether the host product predates the CRA or not. A newer chip with a different cryptographic implementation and secure boot mechanism is not identical and is a product in its own right. A different chipset can still be identical where the protocols and security mechanisms are unchanged.
- [Which software updates has the Commission called substantial modifications?](https://cvdportal.com/cra-guidance/examples/substantial-modification-worked-examples): The Commission tests a software update by its effect on the cybersecurity risk profile rather than by its size. A persistent login feature storing authentication tokens locally is a substantial modification. So is a diagnostics export that leaves sensitive operational data unencrypted. Enabling control features that shipped disabled but assessed is not, and neither is group messaging the original assessment anticipated. Security updates generally fall outside, until they change the intended purpose or add new external dependencies.
- [What counts as a product with digital elements under the Cyber Resilience Act?](https://cvdportal.com/cra-guidance/examples/what-counts-as-a-product-with-digital-elements): The Cyber Resilience Act reaches software that is supplied to a user and executes on that user's device. A mobile application, a desktop application built with web technologies, and source code licensed in a text file are all products with digital elements. A web application used only through a browser is not, unless it supports the functionality of a product that is. Hardware and software that cannot deliver their purpose without each other form one product, even when they are supplied through different channels.
- [When is open source software supplied in the course of a commercial activity?](https://cvdportal.com/cra-guidance/examples/when-open-source-falls-under-the-cra): The Cyber Resilience Act reaches free and open-source software only where it is supplied in the course of a commercial activity. The Commission's twenty-two examples locate that line. Charging for a paid version, gating releases or security fixes behind donations, monetising what is sold through the software, and requiring unrelated personal data processing all cross it. Voluntary donations, separately sold consultancy, funded features released openly, and contributing to someone else's project do not.

## CRA article explainers

- [Essential Cybersecurity Requirements for Products with Digital Elements](https://cvdportal.com/cra/annex-i): The full list of CRA Annex I essential cybersecurity requirements every product with digital elements must meet, across secure design, development, and vulnerability handling.
- [Information and Instructions to Users Required Under the CRA](https://cvdportal.com/cra/annex-ii): CRA Annex II specifies the mandatory information manufacturers must provide to users, including CVD contact details, support period, CE marking reference, and security update information.
- [Important Products with Digital Elements - Class I and Class II Classification](https://cvdportal.com/cra/annex-iii): The full CRA Annex III list of Important Products in Class I and Class II, which ones need third-party conformity assessment, and what each class means for CE marking.
- [Critical Products with Digital Elements - Highest-Risk Classification](https://cvdportal.com/cra/annex-iv): The CRA Annex IV list of Critical Products, the three categories it covers, and the strictest CRA conformity route under Article 32(4).
- [EU Declaration of Conformity: Required Fields and Structure](https://cvdportal.com/cra/annex-v): CRA Annex V specifies the model structure of the EU Declaration of Conformity: product identification, manufacturer details, the sole-responsibility statement, standards applied, notified body details and signature.
- [Simplified EU Declaration of Conformity: Model Structure](https://cvdportal.com/cra/annex-vi): CRA Annex VI sets the model structure for the simplified EU Declaration of Conformity: a short conformity statement plus the internet address where the full Annex V declaration is available.
- [Technical Documentation Requirements Under the CRA](https://cvdportal.com/cra/annex-vii): CRA Annex VII specifies the required contents of the technical file: product description, design docs, risk assessment, SBOM, test results, and CVD policy reference.
- [Conformity Assessment Procedures: Modules A, B, C and H](https://cvdportal.com/cra/annex-viii): CRA Annex VIII sets out the conformity assessment procedures: internal control (Module A), EU type-examination (Module B), conformity to type (Module C) and full quality assurance (Module H).
- [Subject Matter and Purpose of the Cyber Resilience Act](https://cvdportal.com/cra/article-1): CRA Article 1 defines the subject matter of the EU Cyber Resilience Act: mandatory cybersecurity requirements for all products with digital elements placed on the EU market.
- [Obligations of Manufacturers](https://cvdportal.com/cra/article-13): CRA Article 13 sets the core manufacturer duties under the Cyber Resilience Act, covering security by design, risk assessment, SBOM, security updates, and coordinated vulnerability disclosure.
- [Active Exploitation and Incident Reporting - 24h, 72h, and 14-Day Obligations](https://cvdportal.com/cra/article-14): CRA Article 14 explained. The 24-hour early warning, 72-hour notification, and 14-day final report deadlines to ENISA and your CSIRT, in force from September 2026.
- [Voluntary Reporting of Vulnerabilities and Incidents](https://cvdportal.com/cra/article-15): CRA Article 15 allows manufacturers and other parties to voluntarily notify national CSIRTs and ENISA of vulnerabilities and incidents that do not trigger Article 14 mandatory reporting, supporting proactive intelligence sharing.
- [Establishment of the Single Reporting Platform and ENISA's Vulnerability Coordination Role](https://cvdportal.com/cra/article-16): CRA Article 16 establishes ENISA's single reporting platform for Article 14 notifications, the European Vulnerability Database (EVDB), and ENISA's coordination role in EU-wide vulnerability disclosure.
- [Other Provisions Related to Reporting](https://cvdportal.com/cra/article-17): CRA Article 17 covers what happens around your Article 14 and 15 notifications: EU-CyCLONe sharing, CSIRT public disclosure powers, the no-increased-liability shield, EU vulnerability database entries, and CSIRT helpdesk support for SMEs.
- [Authorised Representatives: EU Presence for Non-EU Manufacturers](https://cvdportal.com/cra/article-18): CRA Article 18 requires non-EU manufacturers selling products in the EU to appoint an EU-based authorised representative who can act on their behalf for CRA compliance purposes.
- [Importer Obligations Under the Cyber Resilience Act](https://cvdportal.com/cra/article-19): CRA Article 19 sets out the due diligence and verification obligations of importers who place non-EU-manufactured products with digital elements on the EU market.
- [Scope and Exclusions Under the Cyber Resilience Act](https://cvdportal.com/cra/article-2): CRA Article 2 defines which products fall within scope and lists key exclusions: medical devices, aviation, vehicles, military, and national security products.
- [Distributor Obligations Under the Cyber Resilience Act](https://cvdportal.com/cra/article-20): CRA Article 20 defines the due diligence obligations of distributors who make products with digital elements available in the EU market without being the original importer.
- [When Importers and Distributors Are Treated as Manufacturers](https://cvdportal.com/cra/article-21): CRA Article 21 explains when importers or distributors who modify products or sell under their own brand take on full manufacturer obligations under the Cyber Resilience Act.
- [Identification and Obligations of Economic Operators](https://cvdportal.com/cra/article-23): CRA Article 23 sets out when and how manufacturers must report incidents and vulnerabilities to market surveillance authorities and ENISA beyond Article 14.
- [Obligations of Open-Source Software Stewards Under the CRA](https://cvdportal.com/cra/article-24): CRA Article 24 defines 'open-source software stewards' and sets out their specific obligations — lighter than full manufacturer duties but requiring a security policy, CVD process, and cooperation with market surveillance authorities.
- [Security Attestation of Free and Open-Source Software](https://cvdportal.com/cra/article-25): CRA Article 25 establishes a voluntary EU security attestation programme for free and open-source software components, run by ENISA, to help manufacturers meet their component due diligence obligations under Article 13.
- [Presumption of Conformity, Harmonised Standards, and Common Specifications](https://cvdportal.com/cra/article-27): CRA Article 27 establishes the presumption of conformity for products that apply EU harmonised standards or common specifications, and covers formal objection procedures for inadequate standards.
- [EU Declaration of Conformity: Content, Structure, and Requirements](https://cvdportal.com/cra/article-28): CRA Article 28 specifies the required content of the EU Declaration of Conformity that manufacturers must draw up before affixing the CE marking to products with digital elements.
- [Definitions: Key Terms in the Cyber Resilience Act](https://cvdportal.com/cra/article-3): CRA Article 3 sets out the statutory definitions for the Cyber Resilience Act, including 'product with digital elements', 'manufacturer', 'importer', 'distributor', and related terms that determine who the regulation applies to and what it covers.
- [Rules and Conditions for Affixing the CE Marking](https://cvdportal.com/cra/article-30): CRA Article 30 sets the technical rules for affixing the CE marking to products with digital elements: where, when, how, and what the marking must include — including the notified body identification number for Module H assessments.
- [Conformity Assessment Procedures: Module A vs Third-Party Assessment](https://cvdportal.com/cra/article-32): CRA Article 32 explains when manufacturers can self-certify (Module A) versus when third-party notified body assessment is required for Class I and Class II products.
- [Support Measures for Microenterprises and SMEs](https://cvdportal.com/cra/article-33): CRA Article 33 obliges member states and the Commission to support small manufacturers with awareness raising, training, simplified documentation, sandboxes, and dedicated channels. What SMEs can actually claim.
- [Notification of Conformity Assessment Bodies to the European Commission](https://cvdportal.com/cra/article-35): CRA Article 35 governs how member states notify conformity assessment bodies (notified bodies) to the European Commission for the purpose of CRA third-party assessments.
- [Notification of Conformity Assessment Bodies](https://cvdportal.com/cra/article-39): CRA Article 39 establishes the requirements member states must meet before notifying a conformity assessment body to the European Commission for CRA third-party assessment purposes.
- [Free Movement of CRA-Compliant Products in the EU Single Market](https://cvdportal.com/cra/article-4): CRA Article 4 grants CE-marked products with digital elements the right to free movement across the EU single market, provided they meet essential cybersecurity requirements.
- [Procurement and Professional Use of Products with Digital Elements](https://cvdportal.com/cra/article-5): CRA Article 5 addresses cybersecurity obligations for organisations that procure or professionally use products with digital elements, including public sector bodies and critical infrastructure operators.
- [Market Surveillance Coordination Between EU Member States](https://cvdportal.com/cra/article-52): CRA Article 52 establishes coordination mechanisms between national market surveillance authorities to ensure consistent CRA enforcement across the EU single market.
- [Joint Activities of Market Surveillance Authorities](https://cvdportal.com/cra/article-59): CRA Article 59 empowers national market surveillance authorities to conduct joint investigations and coordinated enforcement actions against manufacturers suspected of CRA non-compliance, particularly where cybersecurity risks have cross-border implications.
- [Essential Cybersecurity Requirements for Products with Digital Elements](https://cvdportal.com/cra/article-6): CRA Article 6 requires products with digital elements to meet the essential security requirements in Annex I, covering both security properties and vulnerability handling obligations.
- [Administrative Fines for CRA Non-Compliance](https://cvdportal.com/cra/article-64): CRA Article 64 establishes a three-tier administrative fine regime: up to €15M or 2.5% of global turnover for essential requirements violations, €10M or 2% for other obligations, and €5M or 1% for misleading authorities.
- [Important Products with Digital Elements - Annex III Classification](https://cvdportal.com/cra/article-7): CRA Article 7 defines 'important products with digital elements' under Annex III — two classes of higher-risk products subject to stricter conformity assessment requirements, including mandatory third-party involvement for Class II.
- [Critical Products with Digital Elements - Annex IV Classification](https://cvdportal.com/cra/article-8): CRA Article 8 defines 'critical products with digital elements' listed in Annex IV — the highest-risk product category requiring mandatory third-party conformity assessment via an EU cybersecurity certification scheme.

## Industry guides

- [Access Control & Physical Security Vendors](https://cvdportal.com/guides/access-control-systems): EU Cyber Resilience Act compliance guide for access control and physical security vendors. Covers Class I classification, Annex I security requirements, Article 13 CVD obligations, Article 14 incident reporting, and conformity assessment for electronic access and security products.
- [Agricultural IoT & Precision Farming Vendors](https://cvdportal.com/guides/agricultural-iot): EU Cyber Resilience Act compliance guide for agricultural IoT and precision farming vendors. Covers product classification for farm sensors and controllers, Annex I obligations, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment.
- [Professional Audio-Visual Equipment Vendors](https://cvdportal.com/guides/audio-visual-equipment): EU Cyber Resilience Act compliance guide for professional audio-visual equipment vendors. Covers CRA classification for AV hardware, Annex I security requirements, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for professional AV products.
- [Automotive OEMs & Tier-1 Suppliers](https://cvdportal.com/guides/automotive-oems): EU Cyber Resilience Act compliance guide for automotive OEMs and Tier-1 suppliers. Covers product classification, Article 13 CVD obligations, Article 14 incident reporting, and conformity assessment pathways for connected vehicle components.
- [Avionics & Aerospace Systems Manufacturers](https://cvdportal.com/guides/avionics-manufacturers): EU CRA obligations for avionics manufacturers: scope, safety-critical product classification, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment pathways.
- [Chemical & Process Plant Automation Vendors](https://cvdportal.com/guides/chemical-plant-automation): EU CRA obligations for chemical process automation vendors: Seveso interaction, Class II classification, Article 13 CVD requirements, Article 14 incident reporting, and conformity assessment.
- [Connected Vehicle Platform & V2X Vendors](https://cvdportal.com/guides/connected-vehicle-platforms): EU CRA obligations for connected vehicle platform and V2X vendors: automotive product scope, Article 13 CVD requirements, Article 14 incident reporting, and UNECE WP.29 interaction.
- [Consumer Electronics Brands](https://cvdportal.com/guides/consumer-electronics-brands): EU Cyber Resilience Act compliance guide for consumer electronics brands. Covers product classification, Annex I security requirements, Article 13 CVD policy obligations, Article 14 incident reporting, and conformity assessment for connected consumer products.
- [Cybersecurity Product Vendors](https://cvdportal.com/guides/cybersecurity-product-vendors): EU Cyber Resilience Act compliance guide for cybersecurity product vendors. Covers Class I and Class II classification for security tools, Annex I obligations, Article 13 CVD policy requirements, Article 14 incident reporting, and conformity assessment.
- [Digital Signage & Kiosk Vendors](https://cvdportal.com/guides/digital-signage-vendors): EU Cyber Resilience Act compliance guide for digital signage and kiosk vendors. Covers product classification, Annex I security requirements for signage hardware, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for interactive kiosks.
- [Drone & UAV Manufacturers](https://cvdportal.com/guides/drone-uav-manufacturers): EU Cyber Resilience Act compliance guide for drone and UAV manufacturers. Covers product classification, Annex I security requirements for UAS, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for commercial and consumer drone products.
- [Electronic Health Record & Clinical IT Vendors](https://cvdportal.com/guides/electronic-health-records): EU CRA obligations for EHR and clinical IT vendors: EHDS interaction, Important Product classification, Article 13 CVD requirements, Article 14 incident reporting, and CE marking pathways.
- [Electronic Lock & Smart Door Manufacturers](https://cvdportal.com/guides/electronic-locks-vendors): EU CRA obligations for electronic lock and smart door manufacturers: product classification, Annex I security requirements, Article 13 CVD policy, and CE marking pathways.
- [Energy Management System Vendors](https://cvdportal.com/guides/energy-management-systems): EU Cyber Resilience Act compliance guide for energy management system vendors. Covers Critical Class II classification, Annex I security obligations, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for energy sector software and hardware.
- [Enterprise Networking Equipment Vendors](https://cvdportal.com/guides/enterprise-networking-vendors): EU Cyber Resilience Act compliance guide for enterprise networking equipment vendors. Covers Class I classification for switches and routers, Annex I obligations, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment pathways.
- [EV Charging & EVSE Manufacturers](https://cvdportal.com/guides/ev-charging-manufacturers): EU Cyber Resilience Act compliance for EV chargers and EVSE manufacturers. Compliance for EV chargers covering product classification, OCPP and ISO 15118 security under Annex I, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment. How AFIR and the CRA fit together.
- [Facilities Management & CAFM System Vendors](https://cvdportal.com/guides/facilities-management-systems): EU CRA obligations for CAFM and facilities management system vendors: product scope, Article 13 CVD requirements, Article 14 incident reporting, and conformity assessment pathways.
- [Firewall & Network Security Appliance Manufacturers](https://cvdportal.com/guides/firewall-manufacturers): EU CRA obligations for firewall and network security appliance manufacturers: Class II classification, Article 13 CVD policy, Article 14 reporting, and notified body assessment requirements.
- [Fleet Management & Telematics Vendors](https://cvdportal.com/guides/fleet-management-vendors): EU Cyber Resilience Act compliance guide for fleet management and telematics vendors. Covers product classification for OBD and telematics hardware, Annex I security requirements, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment.
- [Food & Beverage Automation System Vendors](https://cvdportal.com/guides/food-beverage-automation): EU CRA obligations for food and beverage automation vendors: product classification, Annex I security requirements, Article 13 CVD policy, Article 14 incident reporting, and CE marking.
- [Gaming Hardware Manufacturers](https://cvdportal.com/guides/gaming-hardware-manufacturers): EU Cyber Resilience Act compliance guide for gaming hardware manufacturers. Covers product classification for consoles and peripherals, Annex I security requirements, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for gaming products.
- [Healthcare IT & Clinical Software Vendors](https://cvdportal.com/guides/healthcare-it-providers): EU Cyber Resilience Act compliance guide for healthcare IT and clinical software vendors. Covers product classification for clinical software, Annex I obligations, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for health information systems.
- [Home Health Monitoring Device Manufacturers](https://cvdportal.com/guides/home-health-monitoring): EU CRA obligations for home health monitoring device manufacturers: MDR interaction, Article 13 CVD requirements, Article 14 reporting, consumer device security, and CE marking.
- [HVAC & Climate Control Manufacturers](https://cvdportal.com/guides/hvac-manufacturers): EU Cyber Resilience Act compliance guide for HVAC and climate control manufacturers. Covers product classification for connected HVAC systems, Annex I security requirements, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment.
- [Industrial Automation & PLC Vendors](https://cvdportal.com/guides/industrial-automation-vendors): EU Cyber Resilience Act compliance guide for industrial automation and PLC vendors. Covers OT product classification, Annex I security requirements, Article 13 CVD policy obligations, Article 14 incident reporting, and conformity assessment for ICS products.
- [Connected Laboratory Instrument Manufacturers](https://cvdportal.com/guides/laboratory-instruments): EU CRA obligations for connected laboratory instrument manufacturers: product scope, security-by-design, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment.
- [Livestock Monitoring & Precision Livestock Farming](https://cvdportal.com/guides/livestock-monitoring): EU CRA obligations for livestock monitoring and precision livestock farming vendors: IoT device scope, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment pathways.
- [Managed Service Providers with On-Premises Software](https://cvdportal.com/guides/managed-service-providers): EU CRA obligations for managed service providers distributing on-premises software: product scope, Article 13 CVD requirements, Article 14 incident reporting, and CE marking guidance.
- [Maritime Navigation & Vessel Systems Vendors](https://cvdportal.com/guides/maritime-navigation-systems): EU Cyber Resilience Act obligations for maritime navigation and vessel system vendors: product scope, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment pathways.
- [Medical Device Manufacturers](https://cvdportal.com/guides/medical-device-manufacturers): EU Cyber Resilience Act compliance guide for medical device manufacturers. Covers MDR/CRA overlap, Class I classification, Article 13 CVD obligations, Article 14 incident reporting, and conformity assessment for connected medical devices.
- [Oil & Gas Automation Vendors](https://cvdportal.com/guides/oil-gas-automation): EU Cyber Resilience Act obligations for oil and gas automation vendors: scope, Article 13 CVD requirements, Article 14 incident reporting, and conformity assessment pathways.
- [Parking Management & Smart Parking Vendors](https://cvdportal.com/guides/parking-management-systems): EU Cyber Resilience Act obligations for smart parking and parking management system vendors: classification, CVD policy, Article 14 incident reporting, and CE marking requirements.
- [Pharmaceutical Manufacturing Automation Vendors](https://cvdportal.com/guides/pharmaceutical-manufacturing): EU CRA obligations for pharmaceutical automation vendors: GMP interaction, product classification, Article 13 CVD requirements, Article 14 incident reporting, and conformity assessment.
- [Point-of-Care Diagnostics & IVD Manufacturers](https://cvdportal.com/guides/point-of-care-diagnostics): EU CRA requirements for point-of-care diagnostics and IVD manufacturers: IVDR interaction, CRA classification, CVD policy under Article 13, incident reporting, and conformity assessment.
- [Port & Logistics Automation System Vendors](https://cvdportal.com/guides/port-automation-systems): EU CRA obligations for port and logistics automation vendors: critical infrastructure classification, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment.
- [Point-of-Sale & Payment Terminal Vendors](https://cvdportal.com/guides/pos-system-vendors): EU Cyber Resilience Act compliance guide for point-of-sale and payment terminal vendors. Covers Class I classification, Annex I security requirements, PCI DSS alignment, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for payment products.
- [Precision Agriculture & AgTech Vendors](https://cvdportal.com/guides/precision-agriculture): EU Cyber Resilience Act compliance guide for precision agriculture and AgTech vendors. Covers CRA classification for farm automation hardware, Annex I security obligations, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for agricultural technology.
- [Private 5G & Industrial Wireless Vendors](https://cvdportal.com/guides/private-5g-vendors): EU CRA obligations for private 5G and industrial wireless vendors: network equipment classification, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment requirements.
- [Railway Signalling & Train Control Vendors](https://cvdportal.com/guides/railway-signalling-systems): EU CRA obligations for railway signalling and train control vendors: safety-critical classification, Article 13 CVD requirements, Article 14 incident reporting, and conformity assessment.
- [Robotics & Collaborative Robot Manufacturers](https://cvdportal.com/guides/robotics-manufacturers): EU Cyber Resilience Act compliance guide for robotics and collaborative robot manufacturers. Covers product classification, Annex I security obligations, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for industrial and collaborative robots.
- [Smart Appliance Manufacturers](https://cvdportal.com/guides/smart-appliance-manufacturers): EU Cyber Resilience Act compliance guide for smart appliance manufacturers. Covers product classification for connected white goods, Annex I security requirements, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for smart home appliances.
- [Smart City Infrastructure Vendors](https://cvdportal.com/guides/smart-city-infrastructure): EU CRA obligations for smart city infrastructure vendors: product classification, Article 13 CVD requirements, Article 14 incident reporting, public sector procurement, and CE marking.
- [Smart Home Device Manufacturers](https://cvdportal.com/guides/smart-home-manufacturers): EU Cyber Resilience Act compliance guide for smart home device manufacturers. Covers product classification for IoT devices, Annex I security requirements, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for connected home products.
- [Smart Meter & AMI Manufacturers](https://cvdportal.com/guides/smart-meter-manufacturers): EU Cyber Resilience Act compliance guide for smart meter and AMI manufacturers. Covers Class I classification, Annex I security obligations for metering hardware, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for smart metering products.
- [Smart Traffic Management System Vendors](https://cvdportal.com/guides/smart-traffic-management): EU CRA obligations for smart traffic management vendors: Important Product classification, Article 13 CVD requirements, Article 14 incident reporting, and conformity assessment guidance.
- [Solar & Renewable Energy Monitoring Vendors](https://cvdportal.com/guides/solar-monitoring-vendors): CRA obligations for solar and renewable energy monitoring vendors: product classification, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment requirements.
- [Telecom Equipment Vendors](https://cvdportal.com/guides/telecom-equipment-vendors): EU Cyber Resilience Act compliance guide for telecom equipment vendors. Covers Class I and Class II classification for network hardware, Annex I security obligations, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for telecom products.
- [Telemedicine & Remote Patient Monitoring Vendors](https://cvdportal.com/guides/telemedicine-devices): EU CRA obligations for telemedicine and remote patient monitoring vendors: dual MDR/CRA compliance, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment.
- [Video Surveillance & CCTV Vendors](https://cvdportal.com/guides/video-surveillance-vendors): EU Cyber Resilience Act compliance guide for video surveillance and CCTV vendors. Covers Class I classification for IP cameras, Annex I security requirements, Article 13 CVD policy, Article 14 incident reporting, and conformity assessment for surveillance products.
- [Water Treatment & Utilities Automation Vendors](https://cvdportal.com/guides/water-treatment-automation): EU CRA obligations for water treatment automation vendors: critical infrastructure classification, CVD requirements under Article 13, Article 14 reporting, and conformity assessment pathways.
- [Wearable Technology Brands](https://cvdportal.com/guides/wearable-tech-brands): EU Cyber Resilience Act compliance for wearable and smartwatch brands. Product classification, Annex I security requirements, Article 13 CVD policy, and Article 14 reporting for fitness trackers.

## Compliance checklists

- [Access Control & Physical Security Systems](https://cvdportal.com/compliance/access-control): CRA compliance for access control and physical security system manufacturers. Electronic locks, card readers, biometric systems and IP-connected security hardware requirements.
- [Assistive Technologies & AAC Devices](https://cvdportal.com/compliance/assistive-devices): CRA compliance for assistive technology and AAC device manufacturers. Covers non-MDR assistive devices, augmentative communication systems, and connected accessibility equipment.
- [Professional Audio/Video Equipment](https://cvdportal.com/compliance/audio-video-pro): CRA compliance for professional audio and video equipment manufacturers. Networked broadcast systems, IP audio, live production equipment, and AV-over-IP under the Cyber Resilience Act.
- [Automotive Electronics & In-Vehicle Systems](https://cvdportal.com/compliance/automotive-electronics): CRA compliance for automotive electronics manufacturers. UN R155/R156 and CRA intersection, ECU security, OTA updates, and in-vehicle cybersecurity requirements explained.
- [Building Automation & Smart Buildings](https://cvdportal.com/compliance/building-automation): CRA compliance for building automation, HVAC controllers, BMS, and smart building systems. Annex III classification, Article 14 reporting, BACnet/Modbus security, and CVD obligations.
- [CCTV & Video Surveillance](https://cvdportal.com/compliance/cctv-surveillance): CRA compliance for CCTV and video surveillance manufacturers. Covers IP cameras, NVR/DVR systems, VMS software, and biometric surveillance under the Cyber Resilience Act.
- [CNC Machines & Industrial 3D Printers](https://cvdportal.com/compliance/cnc-3d-printing): CRA compliance for CNC machine and industrial 3D printer manufacturers. Annex I security requirements, SBOM, CVD policy, and CE marking under the Cyber Resilience Act.
- [Consumer Routers & Modems](https://cvdportal.com/compliance/consumer-routers): CRA compliance checklist for consumer router and modem manufacturers. Article 13 CVD policy, Article 14 reporting, Annex I security requirements, and CE marking.
- [Dental Equipment & Devices](https://cvdportal.com/compliance/dental-devices): CRA compliance for dental equipment manufacturers. Understand when dental devices fall under MDR exclusion vs full CRA scope. Covers digital imaging, practice management software.
- [Digital Signage & Display Systems](https://cvdportal.com/compliance/digital-signage): CRA compliance for digital signage and display system manufacturers. Connected displays, media players, signage management platforms, and interactive display requirements.
- [Drones & Unmanned Aerial Vehicles](https://cvdportal.com/compliance/drone-uav): CRA compliance for drone and UAV manufacturers. Annex III Class II likely for higher-category drones. Interaction with EU Drone Regulation (2019/947) and UAS category requirements.
- [E-Readers & Consumer Tablets](https://cvdportal.com/compliance/e-readers-tablets): CRA compliance checklist for e-reader and consumer tablet manufacturers. Article 13 CVD policy, Annex I security requirements, firmware updates, and CE marking obligations.
- [Edge Computing Devices & Gateways](https://cvdportal.com/compliance/edge-computing): CRA compliance for edge computing device and gateway manufacturers. Industrial IoT gateways, edge AI appliances, and fog computing nodes under the Cyber Resilience Act.
- [Embedded Linux Devices](https://cvdportal.com/compliance/embedded-linux-devices): CRA compliance for embedded Linux device manufacturers. SBOM for open-source components, kernel security, CVD policy, and firmware update requirements under the Cyber Resilience Act.
- [Energy Management Systems](https://cvdportal.com/compliance/energy-management): CRA compliance checklist for energy management system manufacturers. Annex III Class II requirements for critical infrastructure energy systems under the Cyber Resilience Act.
- [Enterprise Networking Equipment](https://cvdportal.com/compliance/enterprise-networking): CRA compliance for enterprise switches, firewalls, and networking equipment. Annex III classification, CVD obligations, Article 14 reporting, and conformity assessment.
- [Environmental Monitoring Sensors](https://cvdportal.com/compliance/environmental-monitoring): CRA compliance for environmental monitoring sensor manufacturers. Air quality, water quality, weather, and soil sensors under the Cyber Resilience Act requirements.
- [EV Charging Equipment](https://cvdportal.com/compliance/ev-charging): CRA compliance for EV charger manufacturers. Annex III classification for public charging networks, Article 14 reporting, OCPP security, CVD obligations, and CE marking.
- [Fire Safety & Detection Systems](https://cvdportal.com/compliance/fire-safety-systems): CRA compliance for fire safety and detection system manufacturers. Annex III Class II for networked fire safety systems. Covers fire alarms, suppression controllers, and life safety systems.
- [Fleet Management & Telematics](https://cvdportal.com/compliance/fleet-management): CRA compliance for fleet management and telematics manufacturers. Covers OBD trackers, tachographs, ELD devices, and connected fleet management platforms.
- [Gaming Consoles & Peripherals](https://cvdportal.com/compliance/gaming-devices): CRA compliance checklist for gaming console and peripheral manufacturers. Covers firmware security, online services, vulnerability disclosure and CE marking requirements.
- [Health Monitoring Wearables](https://cvdportal.com/compliance/health-wearables): CRA compliance for health wearable manufacturers. Non-MDR health devices fall under full CRA scope. Covers firmware security, health data protection, CVD policy and CE marking.
- [Hospital IT & Clinical Information Systems](https://cvdportal.com/compliance/hospital-systems): CRA compliance for hospital IT and clinical information system manufacturers. Non-MDR healthcare software falls under full CRA scope - checklist covering all key obligations.
- [Hotel & Hospitality Systems](https://cvdportal.com/compliance/hotel-systems): CRA compliance for hotel and hospitality technology manufacturers. Smart locks, in-room controls, property management systems, and guest Wi-Fi under the Cyber Resilience Act.
- [Industrial Controllers & PLCs](https://cvdportal.com/compliance/industrial-controllers): CRA compliance checklist for industrial controller and PLC manufacturers. Covers Article 13 CVD obligations, Article 14 reporting, Annex I requirements, and conformity assessment.
- [Industrial Robotics & Collaborative Robots](https://cvdportal.com/compliance/industrial-robotics): CRA compliance for industrial robot and cobot manufacturers. Annex I security requirements, safety-security intersection, CVD policy, and CE marking under the Cyber Resilience Act.
- [Intruder Alarm & Security Systems](https://cvdportal.com/compliance/intruder-alarm): CRA compliance for intruder alarm and security system manufacturers. Annex III Class II for critical facility protection. Covers alarm panels, PIR sensors, and monitoring system requirements.
- [IoT Sensors & Connected Devices](https://cvdportal.com/compliance/iot-sensors): CRA compliance checklist for IoT sensor and connected device manufacturers. Article 13 CVD obligations, Annex I security requirements, firmware update obligations.
- [Laboratory Instruments & Scientific Equipment](https://cvdportal.com/compliance/laboratory-instruments): CRA compliance for laboratory instrument and scientific equipment manufacturers. Networked analysers, laboratory information systems, and connected scientific instruments under the CRA.
- [Livestock Monitoring Systems](https://cvdportal.com/compliance/livestock-monitoring): CRA compliance for livestock monitoring system manufacturers. Connected ear tags, health sensors, automated feeding systems, and farm analytics platforms under the Cyber Resilience Act.
- [Marine Electronics & Navigation Systems](https://cvdportal.com/compliance/marine-electronics): CRA compliance for marine electronics and navigation system manufacturers. Covers AIS, ECDIS, chartplotters, VHF radio, and connected marine systems under the Cyber Resilience Act.
- [Medical Devices](https://cvdportal.com/compliance/medical-devices): Medical device manufacturers: understand the overlap between CRA and MDR cybersecurity requirements. Checklist of where MDR satisfies CRA and where additional steps are needed.
- [Network Attached Storage (NAS)](https://cvdportal.com/compliance/network-attached-storage): CRA compliance checklist for NAS manufacturers. Covers firmware security, ransomware resilience, CVD policy, remote access security, and CE marking requirements.
- [Open Source Hardware](https://cvdportal.com/compliance/open-source-hardware): CRA compliance for open source hardware projects. When is open source hardware in scope? Commercial production vs hobby use, steward responsibilities, and conformity for OSH products.
- [Payment Terminals & ATMs](https://cvdportal.com/compliance/payment-terminals): CRA compliance for payment terminal and ATM manufacturers. PCI DSS intersection, PSD2 SCA requirements, and Annex III Class I obligations for financial transaction hardware.
- [Perimeter Security & Smart Barriers](https://cvdportal.com/compliance/perimeter-security): CRA compliance for perimeter security and smart barrier manufacturers. Connected vehicle barriers, electric fencing, and perimeter detection systems under the Cyber Resilience Act.
- [Point of Sale & Payment Terminals](https://cvdportal.com/compliance/point-of-sale): CRA compliance for POS and payment terminal manufacturers. Intersection with PCI DSS, PSD2 SCA requirements, and Cyber Resilience Act for payment hardware and software.
- [Precision Agriculture & Smart Farming](https://cvdportal.com/compliance/precision-agriculture): CRA compliance for precision agriculture and smart farming manufacturers. Covers connected tractors, field sensors, drone sprayers, and farm management software requirements.
- [Process Control & SCADA Systems](https://cvdportal.com/compliance/process-control): CRA compliance for SCADA and process control manufacturers. Annex III Class II critical infrastructure requirements, IEC 62443 alignment, and third-party conformity assessment.
- [Satellite & Space Technology](https://cvdportal.com/compliance/satellite-space): CRA compliance for satellite and space technology manufacturers. Annex III Class II for ground segment and user terminals. Covers satellite communication systems and space cybersecurity.
- [Smart Appliances & White Goods](https://cvdportal.com/compliance/smart-appliances): CRA compliance checklist for smart appliance manufacturers. Covers washing machines, fridges, ovens and other connected white goods under EU Cyber Resilience Act.
- [Smart Cameras & Video Surveillance](https://cvdportal.com/compliance/smart-cameras): CRA compliance for IP cameras, smart doorbells, and video surveillance systems. Article 13 CVD obligations, default credential requirements, Annex I security, and CE marking.
- [Smart Greenhouse Automation](https://cvdportal.com/compliance/smart-greenhouse): CRA compliance for smart greenhouse automation manufacturers. Climate control systems, irrigation automation, lighting control, and connected greenhouse management platforms.
- [Smart Grid & Energy Infrastructure](https://cvdportal.com/compliance/smart-grid): CRA compliance for smart grid and energy infrastructure manufacturers. Annex III Class II for grid-connected systems. Covers smart meters, grid controllers, and NIS2 intersection.
- [Smart Home Devices](https://cvdportal.com/compliance/smart-home-devices): Complete CRA compliance checklist for smart home device manufacturers. Covers Article 13 CVD policy, Article 14 reporting, Annex I security requirements, and CE marking obligations.
- [Smart Toys & Connected Children's Products](https://cvdportal.com/compliance/smart-toys): CRA compliance for smart toy manufacturers. Annex III Class II requirements for AI-enabled and data-collecting children's products. Third-party conformity assessment required.
- [Telecommunications Equipment](https://cvdportal.com/compliance/telecom-equipment): CRA compliance for telecommunications equipment manufacturers. Annex III Class II for core network components. Covers 5G, fixed network equipment, and regulatory intersections.
- [Vending Machines & Interactive Kiosks](https://cvdportal.com/compliance/vending-kiosk): CRA compliance for vending machine and interactive kiosk manufacturers. Connected kiosks, payment-integrated vending, self-service terminals, and Cyber Resilience Act requirements.
- [Warehouse Automation & Logistics Systems](https://cvdportal.com/compliance/warehouse-logistics): CRA compliance checklist for warehouse automation and logistics system manufacturers. Covers AGVs, WMS software, conveyor control, and connected logistics devices.
- [Wearable Devices & Fitness Trackers](https://cvdportal.com/compliance/wearable-devices): CRA compliance for fitness trackers, smartwatches, and health wearables. Article 13 CVD policy, Annex I security requirements, Bluetooth data security, and CE marking.

## Role guides

- [Board Director & Executive Leadership](https://cvdportal.com/for/board-director): Board directors and executives bear ultimate accountability for CRA compliance. This guide explains liability exposure, governance frameworks, and the resource allocation decisions required to achieve and maintain conformity under the Cyber Resilience Act.
- [Chief Information Security Officer (CISO)](https://cvdportal.com/for/ciso): How CISOs own CVD policy, lead PSIRT operations, execute Article 14 incident reporting, and build the security testing programme required by the EU Cyber Resilience Act.
- [Cloud & Backend Engineer](https://cvdportal.com/for/cloud-engineer): Cloud and backend engineers' EU CRA obligations - API security, secure CI/CD, SBOM for backend services, and dependency management for connected products.
- [Compliance Officer](https://cvdportal.com/for/compliance-officer): Compliance Officers' CRA obligations: conformity assessment management, Annex IV technical documentation, CE marking process, audit readiness, and monitoring delegated acts.
- [Chief Operating Officer (COO)](https://cvdportal.com/for/coo): COO's operational guide to EU CRA compliance - cross-team programme governance, supply chain obligations, and Article 14 incident operational readiness.
- [Chief Technology Officer (CTO)](https://cvdportal.com/for/cto): How CTOs lead CRA compliance programmes: SBOM governance, secure update infrastructure, Declaration of Conformity signing authority, and technical architecture obligations.
- [Customer Success Manager](https://cvdportal.com/for/customer-success): Customer Success Managers' EU CRA role - customer vulnerability communications, EOL conversations, due diligence requests, and proactive security disclosure.
- [DevOps & Platform Engineer](https://cvdportal.com/for/devops-engineer): CRA obligations for DevOps engineers: secure CI/CD pipelines, automated SBOM generation, signed artifact delivery, vulnerability scanning, and OTA update infrastructure.
- [Embedded Systems Engineer](https://cvdportal.com/for/embedded-systems-engineer): How embedded systems engineers meet CRA requirements: secure boot, HSM integration, memory safety, hardware CVE triage, and chip-level SBOM for EU market products.
- [Firmware & Embedded Software Developer](https://cvdportal.com/for/firmware-developer): Firmware and embedded software developers face direct CRA obligations around secure coding, signed builds, secure boot, and SBOM. This guide explains what the Cyber Resilience Act requires at the firmware layer.
- [General Counsel](https://cvdportal.com/for/general-counsel): General Counsel must manage CRA legal exposure, Declaration of Conformity obligations, EU Authorised Representative requirements, NCA enforcement response, and the intersection with the EU Product Liability Directive. This guide covers each area.
- [Hardware & PCB Design Engineer](https://cvdportal.com/for/hardware-engineer): Hardware engineers' EU CRA obligations - secure boot, HSM design, hardware SBOM, tamper resistance requirements under Annex I for products with digital elements.
- [IT Manager (Internal Tools & Infrastructure)](https://cvdportal.com/for/it-manager): IT managers' EU CRA role - supporting PSIRT infrastructure, internal SBOM and vulnerability tracking tooling, and patch management systems for connected products.
- [Legal Counsel & Data Protection Officer](https://cvdportal.com/for/legal-counsel): Legal Counsel's CRA obligations: regulatory interpretation, Declaration of Conformity sign-off, supply chain contract requirements, GDPR overlap, and managing regulator correspondence.
- [Open-Source Project Maintainer](https://cvdportal.com/for/open-source-maintainer): Does the CRA apply to open-source projects? The stewardship exemption protects non-commercial maintainers, but commercial OSS projects face obligations. This guide explains the CRA's open-source rules, CVD policy requirements, and SBOM obligations.
- [Penetration Tester & Red Team Lead](https://cvdportal.com/for/pen-tester): Penetration testers' EU CRA obligations - using pen test results as conformity evidence, Annex I scope requirements, and coordinating findings with the PSIRT.
- [Procurement & Supply Chain Manager](https://cvdportal.com/for/procurement-manager): Procurement managers must enforce CRA supply chain security obligations through vendor contracts, security questionnaires, and SBOM collection. This guide explains what to require from suppliers under the Cyber Resilience Act.
- [Product Manager](https://cvdportal.com/for/product-manager): How Product Managers embed CRA requirements into roadmaps, define support lifecycle obligations, manage EOL policy, and communicate security disclosures to users under EU law.
- [PSIRT Manager](https://cvdportal.com/for/psirt-manager): PSIRT managers carry the Article 14 notification obligations under the CRA. This guide covers CVD process requirements, the 24h/72h/14-day reporting timeline to ENISA, and CSAF advisory authoring.
- [Quality Assurance & Test Engineer](https://cvdportal.com/for/quality-assurance): QA engineers play a direct role in CRA conformity by executing security test coverage, managing vulnerability regression testing, and contributing test evidence to the technical file. This guide explains each obligation.
- [Regulatory Affairs Manager](https://cvdportal.com/for/regulatory-affairs): Regulatory Affairs Managers coordinate CRA conformity assessment, NCA relationships, and multi-regulation overlap with NIS2 and MDR. This guide maps the key obligations and governance touchpoints under the Cyber Resilience Act.
- [Sales Engineer & Pre-Sales Consultant](https://cvdportal.com/for/sales-engineer): Sales engineers are on the front line when enterprise customers ask about CRA compliance, DoC documentation, and EOL support timelines. This guide prepares you to answer security questionnaires and communicate CRA readiness with confidence.
- [Security Analyst & SOC Analyst](https://cvdportal.com/for/security-analyst): Security and SOC analysts' EU CRA role - threat intelligence, CVE monitoring against the SBOM, PSIRT triage escalation, and Article 14 early warning process.
- [Security Architect](https://cvdportal.com/for/security-architect): How Security Architects drive EU Cyber Resilience Act compliance - secure-by-design principles, threat modelling, Annex I controls and conformity evidence.
- [Security Engineer](https://cvdportal.com/for/security-engineer): Security engineers are at the heart of CRA conformity. This guide covers Annex I technical requirements, SBOM management, CVE triage, and PSIRT collaboration obligations under the Cyber Resilience Act.
- [Software Architect](https://cvdportal.com/for/software-architect): Software architects' EU CRA obligations - secure dependency selection, updatability design, data handling architecture, and technical file evidence under Annex I.
- [Startup Founder & CEO (First-Time CRA Compliance)](https://cvdportal.com/for/startup-founder): If your startup sells connected hardware or software products into the EU, the Cyber Resilience Act applies to you. This guide explains minimum viable CRA compliance, build vs buy decisions, and how investor due diligence is changing.
- [Supply Chain & Vendor Risk Manager](https://cvdportal.com/for/supply-chain-manager): Supply chain managers' EU CRA obligations - vendor security assessments, SBOM collection, open-source governance, and contractual requirements under Annex I §10.
- [Technical Writer & Documentation Lead](https://cvdportal.com/for/technical-writer): CRA obligations for technical writers: CVD policy documentation, security.txt authoring, CSAF advisory writing, user-facing vulnerability disclosures, and technical file docs.
- [VP of Engineering](https://cvdportal.com/for/vp-engineering): CRA obligations for VPs of Engineering: team readiness, secure SDLC adoption, resource allocation for security work, cross-team vulnerability coordination, and CRA tooling decisions.

## EU country guides

- [Austria](https://cvdportal.com/eu/austria): CRA compliance for Austrian manufacturers: GovCERT Austria/BMI as national authority, incident reporting, market surveillance, and alignment with Austrian cybersecurity strategy.
- [Belgium](https://cvdportal.com/eu/belgium): CRA compliance for Belgian manufacturers: CCB as national authority, CERT.be incident reporting, market surveillance, and alignment with Belgium's national cybersecurity strategy.
- [Bulgaria](https://cvdportal.com/eu/bulgaria): CRA compliance for Bulgarian manufacturers: State e-Government Agency as national authority, CERT Bulgaria incident reporting, market surveillance, and national cybersecurity framework.
- [Croatia](https://cvdportal.com/eu/croatia): CRA compliance for Croatian manufacturers: HAKOM as national authority, CERT.hr incident reporting, market surveillance, and Croatian cybersecurity framework alignment.
- [Czech Republic](https://cvdportal.com/eu/czech-republic): CRA compliance for Czech manufacturers: NUKIB as national authority, CSIRT.CZ incident reporting, market surveillance, and alignment with Czech cybersecurity law.
- [Denmark](https://cvdportal.com/eu/denmark): CRA compliance for Danish manufacturers: SAMSIK as national authority, Article 14 incident reporting, market surveillance, and alignment with Danish cybersecurity strategy.
- [Estonia](https://cvdportal.com/eu/estonia): CRA compliance for Estonian manufacturers: RIA as national authority, CERT-EE incident reporting, market surveillance, and Estonia's world-leading digital governance alignment.
- [Finland](https://cvdportal.com/eu/finland): CRA compliance for Finnish manufacturers: Traficom/NCSC-FI as national authority, Article 14 incident reporting, market surveillance, and Finnish cybersecurity framework alignment.
- [France](https://cvdportal.com/eu/france): CRA compliance for French manufacturers: ANSSI as national authority, CERT-FR incident reporting, market surveillance under French law, and alignment with the Loi de Programmation Militaire.
- [Germany](https://cvdportal.com/eu/germany): How German manufacturers comply with the EU Cyber Resilience Act: BSI as the national authority, CERT-Bund incident reporting, market surveillance, and national cybersecurity law alignment.
- [Greece](https://cvdportal.com/eu/greece): CRA compliance for Greek manufacturers: Ministry of Digital Governance as national authority, GR-CSIRT incident reporting, market surveillance, and Greek cybersecurity framework alignment.
- [Hungary](https://cvdportal.com/eu/hungary): CRA compliance for Hungarian manufacturers: SZTFH as national authority, GovCERT Hungary incident reporting, market surveillance, and alignment with Hungarian cybersecurity law.
- [Ireland](https://cvdportal.com/eu/ireland): CRA compliance for Irish manufacturers: NCSC Ireland as national authority, CSIRT-IE incident reporting, market surveillance, and alignment with Ireland's National Cyber Security Strategy.
- [Italy](https://cvdportal.com/eu/italy): CRA compliance for Italian manufacturers: ACN as national authority, CSIRT Italia incident reporting, market surveillance, and alignment with Italy's Perimetro di Sicurezza Nazionale Cibernetica.
- [Latvia](https://cvdportal.com/eu/latvia): CRA compliance for Latvian manufacturers: CERT.LV as national authority and CSIRT, Article 14 incident reporting, market surveillance, and Latvian cybersecurity framework.
- [Lithuania](https://cvdportal.com/eu/lithuania): CRA compliance for Lithuanian manufacturers: NKSC as national authority, CERT-LT incident reporting, market surveillance, and Lithuanian cybersecurity law alignment.
- [Luxembourg](https://cvdportal.com/eu/luxembourg): CRA compliance for Luxembourg manufacturers: ILNAS and CIRCL as national authorities, CIRCL incident reporting, market surveillance, and Luxembourg's cybersecurity framework.
- [Malta](https://cvdportal.com/eu/malta): CRA compliance for Maltese manufacturers: MDIA/CIPD as national authority, MDIA/CIPD-CSIRT incident reporting, market surveillance, and Malta's national cybersecurity strategy.
- [Netherlands](https://cvdportal.com/eu/netherlands): CRA compliance for Dutch manufacturers: NCSC-NL as national authority, Article 14 incident reporting, market surveillance by RDI, and alignment with Dutch cybersecurity frameworks.
- [Norway](https://cvdportal.com/eu/norway): CRA compliance for Norwegian manufacturers: NSM as EEA national authority, NorCERT incident reporting, market surveillance, and alignment with Norwegian cybersecurity law.
- [Poland](https://cvdportal.com/eu/poland): CRA compliance for Polish manufacturers: CERT Polska/NASK as national authority, Article 14 incident reporting, market surveillance, and alignment with Poland's national cybersecurity framework.
- [Portugal](https://cvdportal.com/eu/portugal): CRA compliance for Portuguese manufacturers: CNCS as national authority, CERT.PT incident reporting, market surveillance, and alignment with Portugal's national cybersecurity strategy.
- [Romania](https://cvdportal.com/eu/romania): CRA compliance for Romanian manufacturers: DNSC as national authority, incident reporting, market surveillance, and alignment with Romania's national cybersecurity framework.
- [Slovakia](https://cvdportal.com/eu/slovakia): CRA compliance for Slovak manufacturers: NBU as national authority, SK-CERT incident reporting, market surveillance, and alignment with Slovak cybersecurity law.
- [Slovenia](https://cvdportal.com/eu/slovenia): CRA compliance for Slovenian manufacturers: SI-CERT and AKOS as national authorities, SI-CERT incident reporting, market surveillance, and Slovenian cybersecurity framework.
- [Spain](https://cvdportal.com/eu/spain): CRA compliance for Spanish manufacturers: CCN and INCIBE as national authorities, INCIBE-CERT incident reporting, market surveillance, and the Esquema Nacional de Seguridad framework.
- [Sweden](https://cvdportal.com/eu/sweden): CRA compliance for Swedish manufacturers: NCSC-SE as national authority, CERT-SE incident reporting, market surveillance, and alignment with Swedish cybersecurity strategy.

## Glossary

- [Actively Exploited Vulnerability](https://cvdportal.com/glossary/actively-exploited-vulnerability): What an actively exploited vulnerability means under the CRA, the 24-hour ENISA notification requirement, and how to determine exploitation status.
- [Advisory Embargo](https://cvdportal.com/glossary/advisory-embargo): What an advisory embargo is in coordinated vulnerability disclosure, how embargo periods work, and when they may be shortened or broken under CRA obligations.
- [Annex I Essential Requirements](https://cvdportal.com/glossary/annex-i-requirements): Understand the CRA's Annex I essential requirements - both Part I product security properties and Part II vulnerability handling obligations - and what they mean for manufacturers.
- [Annex II User Information Requirements](https://cvdportal.com/glossary/annex-ii-user-information): What CRA Annex II requires manufacturers to communicate to users - product identifiers, support periods, vulnerability contacts, and security update information.
- [Annex III Important Product Classification](https://cvdportal.com/glossary/annex-iii-classification): How the CRA classifies products as Important Class I, Class II, or Critical under Annex III, the criteria for each tier, and what your classification means for conformity assessment.
- [Annex VII Technical Documentation File](https://cvdportal.com/glossary/annex-vii-technical-file): What CRA Annex VII requires in a manufacturer's technical documentation file - from risk assessments and SBOMs to CVD policies and test reports.
- [Attack Surface](https://cvdportal.com/glossary/attack-surface): What is attack surface in cybersecurity? Learn how the EU Cyber Resilience Act requires manufacturers to minimise attack surface in connected products with digital elements.
- [Bug Bounty Programme](https://cvdportal.com/glossary/bug-bounty): What is a bug bounty programme and how does it relate to EU Cyber Resilience Act compliance? Learn the difference between bug bounty and mandatory CVD obligations under the CRA.
- [CE Marking (Cybersecurity)](https://cvdportal.com/glossary/ce-marking): Learn what CE marking means in the context of the CRA, what it requires manufacturers to demonstrate, and how it relates to conformity assessment and the Declaration of Conformity.
- [CISA Known Exploited Vulnerabilities (KEV) Catalogue](https://cvdportal.com/glossary/cisa-kev): What is the CISA Known Exploited Vulnerabilities (KEV) catalogue? Learn how EU manufacturers must use KEV data to meet EU Cyber Resilience Act notification and patching obligations.
- [Common Vulnerability Scoring System (CVSS) - Full Guide](https://cvdportal.com/glossary/common-vulnerability-scoring-system): A complete guide to CVSS for EU Cyber Resilience Act compliance. Learn how CVSS base, temporal, and environmental scores work, and how manufacturers use CVSS in CRA vulnerability management.
- [Conformity Assessment](https://cvdportal.com/glossary/conformity-assessment): Understand CRA conformity assessment routes, what each classification requires, and how manufacturers prepare technical documentation for notified body review.
- [Conformity Assessment Procedure](https://cvdportal.com/glossary/conformity-assessment-procedure): Learn about CRA conformity assessment procedures - which route applies to your product class, what self-certification covers, and when a Notified Body is required.
- [Coordinated Vulnerability Disclosure (CVD)](https://cvdportal.com/glossary/coordinated-vulnerability-disclosure): Learn what Coordinated Vulnerability Disclosure (CVD) means under the EU Cyber Resilience Act, why it is legally required, and how manufacturers must implement it.
- [Coordinating CSIRT](https://cvdportal.com/glossary/coordinating-csirt): What a Coordinating CSIRT does under the CRA - how national CSIRTs facilitate multi-party vulnerability disclosures and support CRA Article 14 notification processes.
- [Critical Vulnerability](https://cvdportal.com/glossary/critical-vulnerability): What a critical vulnerability is, how CVSS defines the critical severity band, and what CRA-compliant manufacturers must do when one is discovered.
- [Cryptographic Agility](https://cvdportal.com/glossary/cryptographic-agility): What cryptographic agility means for CRA-compliant product design, how to implement it, and why post-quantum readiness makes it critical for long-lived products.
- [Common Security Advisory Framework (CSAF)](https://cvdportal.com/glossary/csaf): What CSAF is, why ENISA recommends it for CRA compliance, and how manufacturers use CSAF 2.0 to publish machine-readable security advisories instead of PDF bulletins.
- [CSIRT - Computer Security Incident Response Team](https://cvdportal.com/glossary/csirt): Learn what CSIRTs are, which national CSIRTs EU manufacturers must notify under Article 14 of the CRA, and how CSIRT coordination works in the EU cybersecurity ecosystem.
- [CVD Coordinator](https://cvdportal.com/glossary/cvd-coordinator): What a CVD Coordinator does, when to involve one in multi-vendor vulnerability disclosures, and how ENISA's coordination role works under the Cyber Resilience Act.
- [CVD Policy](https://cvdportal.com/glossary/cvd-policy): Understand what a CVD policy must contain under the EU Cyber Resilience Act, how to publish one, and what manufacturers get wrong when drafting their first policy.
- [Common Vulnerabilities and Exposures (CVE)](https://cvdportal.com/glossary/cve): Learn what CVE identifiers are, how the CVE programme works, and how EU manufacturers must use CVE in CRA-compliant vulnerability handling and security advisories.
- [Common Vulnerability Scoring System (CVSS)](https://cvdportal.com/glossary/cvss): Understand CVSS scoring, how it applies to CRA vulnerability handling obligations, and how manufacturers use CVSS in security advisories and patch prioritisation.
- [CVSS v4.0](https://cvdportal.com/glossary/cvss-v4): What CVSS v4.0 changes versus v3.1, the new base metrics for IoT and OT products, and what CRA manufacturers need when adopting the FIRST scoring standard.
- [Common Weakness Enumeration (CWE)](https://cvdportal.com/glossary/cwe): What CWE is, how it differs from CVE, and how manufacturers use CWE mappings for threat modelling, root cause analysis, and CRA-compliant secure development.
- [EU Cyber Resilience Act (CRA)](https://cvdportal.com/glossary/cyber-resilience-act): Definition of the EU Cyber Resilience Act (Regulation (EU) 2024/2847): what the term means, the scope, key dates, and penalties, in glossary form with links to the full guide.
- [CycloneDX](https://cvdportal.com/glossary/cyclonedx): What CycloneDX is, how it supports CRA SBOM requirements, its key features for vulnerability management, and how it compares to SPDX.
- [EU Declaration of Conformity (DoC)](https://cvdportal.com/glossary/declaration-of-conformity): Learn what a CRA Declaration of Conformity must contain, who signs it, how long it must be retained, and what triggers the need for a new DoC.
- [Default Class Product (CRA)](https://cvdportal.com/glossary/default-class): What is a Default Class product under the EU Cyber Resilience Act? Learn which products qualify, how self-certification works, and what compliance obligations still apply.
- [Defence in Depth](https://cvdportal.com/glossary/defence-in-depth): What defence in depth means for CRA product security, how layered controls reduce risk, and how to apply the principle across hardware, firmware, and software.
- [Dependency-Track](https://cvdportal.com/glossary/dependency-track): What Dependency-Track is, how it enables continuous SBOM-based vulnerability monitoring for CRA compliance, and how to integrate it into a PSIRT workflow.
- [DevSecOps](https://cvdportal.com/glossary/devsecops): What DevSecOps is, how it supports CRA SDLC obligations, and which pipeline security controls are most relevant for manufacturers of CRA-covered products.
- [Disclosure Timeline](https://cvdportal.com/glossary/disclosure-timeline): What a vulnerability disclosure timeline means, the industry standard 90-day practice, how grace periods work, and what the CRA expects from manufacturers.
- [Economic Operator (CRA)](https://cvdportal.com/glossary/economic-operator): Who are economic operators under the EU Cyber Resilience Act? Understand the obligations of manufacturers, importers, distributors, and authorised representatives.
- [End-of-Life Policy](https://cvdportal.com/glossary/end-of-life-policy): What is an end-of-life policy under the EU Cyber Resilience Act? Learn how manufacturers must communicate EOL dates and meet minimum support period requirements for CRA compliance.
- [ENISA - EU Agency for Cybersecurity](https://cvdportal.com/glossary/enisa): Learn ENISA's role under the EU Cyber Resilience Act: vulnerability registry operation, Article 14 notifications, guidance publication, and support for manufacturers.
- [Exploit Prediction Scoring System (EPSS)](https://cvdportal.com/glossary/epss): What EPSS is, how it differs from CVSS, and how manufacturers use EPSS scores to prioritise vulnerability remediation under CRA compliance requirements.
- [Essential Cybersecurity Requirements](https://cvdportal.com/glossary/essential-cybersecurity-requirements): Learn what the CRA's essential cybersecurity requirements cover, how they map to Annex I, and what manufacturers must demonstrate to meet them.
- [EU Type-Examination](https://cvdportal.com/glossary/eu-type-examination): Understand EU Type-Examination under the Cyber Resilience Act - what the procedure involves, when it is required for Important Class II products, and how certificates work.
- [European Vulnerability Database (EUVDB)](https://cvdportal.com/glossary/european-vulnerability-database): What the EU's European Vulnerability Database (EUVDB) is, how CRA manufacturers must notify it, and how it relates to the US NVD and CVE programme.
- [Exploit](https://cvdportal.com/glossary/exploit): Understand what an exploit is, how it relates to vulnerabilities, and why the EU Cyber Resilience Act requires manufacturers to respond before exploits are developed.
- [Firmware Update & OTA Security](https://cvdportal.com/glossary/firmware-update): What are firmware updates and OTA security under the EU Cyber Resilience Act? Learn how manufacturers must deliver and secure software updates for connected products.
- [Hardware Security Module (HSM)](https://cvdportal.com/glossary/hardware-security-module): What an HSM is, how it protects cryptographic keys in CRA-covered products, and when HSMs are required for secure boot and firmware signing infrastructure.
- [Harmonised Standard](https://cvdportal.com/glossary/harmonised-standard): What Harmonised Standards mean for EU Cyber Resilience Act compliance, how they create a presumption of conformity, and which standards bodies are developing CRA standards.
- [Important Product Class I](https://cvdportal.com/glossary/important-class-i): What is Important Product Class I under the EU Cyber Resilience Act? Understand which products qualify, the conformity assessment requirements, and compliance obligations.
- [Important Product Class II](https://cvdportal.com/glossary/important-class-ii): Which products are Important Class II under the CRA, such as firewalls, IDS/IPS, and tamper-resistant microprocessors, and why they need mandatory third-party conformity assessment.
- [Incident Response](https://cvdportal.com/glossary/incident-response): What is incident response under the EU Cyber Resilience Act? Learn how manufacturers must prepare for, manage, and report security incidents affecting products with digital elements.
- [Indicator of Compromise (IoC)](https://cvdportal.com/glossary/indicator-of-compromise): What Indicators of Compromise (IoCs) are, how they are used in incident detection and response, and their role in detecting CRA Article 14 notification triggers.
- [Principle of Least Privilege](https://cvdportal.com/glossary/least-privilege): What the Principle of Least Privilege means for CRA product design, how it limits exploit impact, and how to implement it across firmware, OS, and application layers.
- [Manufacturer Obligations (CRA)](https://cvdportal.com/glossary/manufacturer-obligation): What are manufacturer obligations under the EU Cyber Resilience Act? A complete overview of design, vulnerability handling, reporting, and post-market security duties for EU manufacturers.
- [Market Surveillance Authority (MSA)](https://cvdportal.com/glossary/market-surveillance-authority): Understand the role of Market Surveillance Authorities under the EU Cyber Resilience Act - who they are, what powers they hold, and how they enforce CRA compliance.
- [Mean Time to Remediate (MTTR)](https://cvdportal.com/glossary/mean-time-to-remediate): What MTTR is, how to calculate it, why it matters for CRA compliance, and benchmark values for different vulnerability severity levels.
- [National Vulnerability Database (NVD)](https://cvdportal.com/glossary/national-vulnerability-database): What is the National Vulnerability Database (NVD)? Learn how NVD supports EU Cyber Resilience Act compliance and why it is central to vulnerability management for EU manufacturers.
- [Network Segmentation](https://cvdportal.com/glossary/network-segmentation): What network segmentation means for CRA product security design, how it limits exploit blast radius, and what manufacturers must consider for enterprise and OT deployments.
- [NIS2 Directive](https://cvdportal.com/glossary/nis2-directive): Understand the NIS2 Directive and its relationship to the EU Cyber Resilience Act - how they differ, where they overlap, and what manufacturers operating digital services must do.
- [Notified Body](https://cvdportal.com/glossary/notified-body): Learn what a Notified Body is under the EU Cyber Resilience Act, which product classes require one, and how third-party conformity assessment works for CRA compliance.
- [Open Source Component](https://cvdportal.com/glossary/open-source-component): What open source components mean for CRA compliance - manufacturer obligations, SBOM requirements, and how to manage vulnerabilities in open source dependencies.
- [Open Source Steward](https://cvdportal.com/glossary/open-source-steward): What the CRA's Open Source Steward category means, which obligations apply, and how it differs from the manufacturer classification for commercial products.
- [Open Source Vulnerability (OSV) Format](https://cvdportal.com/glossary/osv): What the OSV format and database are, how they enable SBOM-based vulnerability detection, and why OSV complements NVD for CRA-compliant software composition analysis.
- [Over-the-Air (OTA) Update](https://cvdportal.com/glossary/ota-update): What OTA updates are, why they are critical for CRA compliance, and the security requirements for a safe and reliable OTA update mechanism.
- [Patch Management](https://cvdportal.com/glossary/patch-management): Learn what patch management means under the EU Cyber Resilience Act, what timelines apply, and how manufacturers must deliver security updates to remain compliant.
- [Penetration Testing](https://cvdportal.com/glossary/penetration-testing): Learn what penetration testing is, how it supports EU Cyber Resilience Act compliance, and what manufacturers of products with digital elements must do before market placement.
- [Product Liability Directive](https://cvdportal.com/glossary/product-liability-directive): How the revised EU Product Liability Directive interacts with the CRA - why cybersecurity defects in products with digital elements can now trigger civil liability claims.
- [Products with Digital Elements (PDE)](https://cvdportal.com/glossary/products-with-digital-elements): Understand what the CRA means by 'products with digital elements', which products are in scope, which are excluded, and how the definition affects manufacturers.
- [Proof-of-Concept (PoC) Exploit](https://cvdportal.com/glossary/proof-of-concept): Understand what a proof-of-concept exploit is, how it affects CRA vulnerability response timelines, and what manufacturers must do when a public PoC for their product is released.
- [Product Security Incident Response Team (PSIRT)](https://cvdportal.com/glossary/psirt): What a Product Security Incident Response Team (PSIRT) does, how it differs from a CSIRT, and the PSIRT capabilities the EU Cyber Resilience Act requires manufacturers to maintain.
- [Package URL (PURL)](https://cvdportal.com/glossary/purl): What a Package URL (PURL) is, why it matters for SBOM accuracy, and how PURLs enable CRA-compliant vulnerability management through precise component identification.
- [Radio Equipment Directive (RED)](https://cvdportal.com/glossary/red-directive): Understand the Radio Equipment Directive and its cybersecurity requirements - how RED Article 3.3(d)(e)(f) relates to CRA compliance for wireless and connected devices.
- [Remediation Timeline](https://cvdportal.com/glossary/remediation-timeline): What remediation timelines mean for CRA compliance - how to set severity-based SLAs, what 'without undue delay' means in practice, and how to measure performance.
- [Responsible Disclosure](https://cvdportal.com/glossary/responsible-disclosure): Understand responsible disclosure, how it relates to coordinated vulnerability disclosure under the CRA, and what obligations it creates for EU manufacturers.
- [Cybersecurity Risk Assessment](https://cvdportal.com/glossary/risk-assessment): What is a cybersecurity risk assessment under the EU Cyber Resilience Act? Learn what manufacturers must document, assess, and mitigate before placing products on the EU market.
- [Safe Harbour Clause](https://cvdportal.com/glossary/safe-harbour-clause): What a safe harbour clause is in a CVD policy, why it is essential for CRA compliance, and how manufacturers should draft one to protect good-faith security researchers.
- [Software Bill of Materials (SBOM)](https://cvdportal.com/glossary/sbom): Learn what an SBOM is, why the EU Cyber Resilience Act requires one, which formats to use, and how manufacturers maintain SBOMs for CRA compliance.
- [Secure Development Lifecycle (SDLC)](https://cvdportal.com/glossary/sdlc): What a Secure Development Lifecycle is, which SDLC activities are required for CRA compliance, and how to implement SDLC practices in hardware and software product development.
- [Secure Boot](https://cvdportal.com/glossary/secure-boot): What Secure Boot is, how it prevents firmware tampering, and why it is an essential security requirement for CRA-covered embedded and IoT products.
- [Secure by Default](https://cvdportal.com/glossary/secure-by-default): What does 'secure by default' mean under the EU Cyber Resilience Act? Learn how Annex I requires manufacturers to ship products with security enabled out of the box.
- [Secure by Design](https://cvdportal.com/glossary/secure-by-design): What does 'secure by design' mean under the EU Cyber Resilience Act? Learn how Annex I requires manufacturers to embed security throughout the product development lifecycle.
- [Security Advisory](https://cvdportal.com/glossary/security-advisory): Learn what a CRA-compliant security advisory must contain, why CSAF format is preferred, and how to publish advisories effectively for EU regulatory compliance.
- [Security Researcher](https://cvdportal.com/glossary/security-researcher): Who is a security researcher under the EU Cyber Resilience Act? Learn how the CRA protects researchers, what manufacturers owe them, and the role researchers play in CRA compliance.
- [security.txt](https://cvdportal.com/glossary/security-txt): Learn what security.txt is, how it relates to EU CRA compliance, and how to create an RFC 9116-compliant security.txt file for your product's domain.
- [Security Information and Event Management (SIEM)](https://cvdportal.com/glossary/siem): What SIEM is, how it supports CRA compliance through incident detection and audit logging, and which log sources are most relevant for manufacturers of CRA-covered products.
- [Security Operations Centre (SOC)](https://cvdportal.com/glossary/soc): What a Security Operations Centre does, how it supports CRA compliance for product manufacturers, and when internal vs managed SOC services are appropriate.
- [Software Composition Analysis (SCA)](https://cvdportal.com/glossary/software-composition-analysis): What is Software Composition Analysis (SCA) and how does it support EU Cyber Resilience Act compliance? Learn how manufacturers use SCA to manage open-source vulnerabilities.
- [Software Identifier](https://cvdportal.com/glossary/software-identifier): What software identifiers are, how CPE, PURL, and SWID tags differ, and why precise identification matters for CRA-compliant SBOM and vulnerability management.
- [SPDX (Software Package Data Exchange)](https://cvdportal.com/glossary/spdx): What SPDX is, how it supports CRA SBOM requirements, its ISO standardisation status, and how it compares to CycloneDX for product security compliance.
- [Software Supply Chain Security](https://cvdportal.com/glossary/supply-chain-security): What is software supply chain security and how does the EU Cyber Resilience Act regulate it? Key obligations for manufacturers using open-source or third-party components.
- [Support Period (CRA)](https://cvdportal.com/glossary/support-period): What is the support period under the EU Cyber Resilience Act? Learn the minimum 5-year requirement, how it is calculated, and how manufacturers must communicate it to buyers.
- [Technical Documentation (CRA)](https://cvdportal.com/glossary/technical-documentation): Learn what the CRA requires in technical documentation, which records manufacturers must keep, how long to retain them, and how to structure a compliant documentation package.
- [Threat Actor](https://cvdportal.com/glossary/threat-actor): What threat actors are, how different actor types pose different risks to CRA-covered products, and how to use threat actor profiles in CRA-required risk assessments.
- [Threat Intelligence](https://cvdportal.com/glossary/threat-intelligence): What threat intelligence is, how it supports CRA compliance through threat modelling and exploitation monitoring, and the key sources manufacturers should use.
- [Threat Modeling](https://cvdportal.com/glossary/threat-modeling): What is threat modeling and how does it support EU Cyber Resilience Act compliance? Learn how manufacturers use threat modeling to satisfy CRA risk assessment and secure-by-design obligations.
- [Transitive Dependency](https://cvdportal.com/glossary/transitive-dependency): What transitive dependencies are, why they create hidden vulnerability exposure in CRA-covered products, and how SBOM practices can surface and manage them.
- [Security Triage](https://cvdportal.com/glossary/triage): How to triage and prioritise incoming security reports in a PSIRT, build a CRA-ready triage workflow, and use CVSS and EPSS to rank vulnerabilities by risk.
- [VEX - Vulnerability Exploitability eXchange](https://cvdportal.com/glossary/vex-document): What is a VEX document and why does it matter for EU Cyber Resilience Act compliance? Learn how VEX helps manufacturers communicate exploitability status of vulnerabilities in their products.
- [Vulnerability Disclosure Policy (VDP)](https://cvdportal.com/glossary/vulnerability-disclosure-policy): What a Vulnerability Disclosure Policy (VDP) is, what it must contain for CRA compliance, and how it differs from a bug bounty programme.
- [Vulnerability Handling](https://cvdportal.com/glossary/vulnerability-handling): Learn what CRA-compliant vulnerability handling requires, what processes manufacturers must establish, and how Annex I Part II defines the mandatory obligations.
- [Vulnerability Scanning](https://cvdportal.com/glossary/vulnerability-scanning): What is vulnerability scanning and how does it support EU Cyber Resilience Act compliance? Learn how manufacturers use automated scanning to meet ongoing security monitoring obligations.
- [Vulnerability Triage](https://cvdportal.com/glossary/vulnerability-triage): What vulnerability triage involves, how CVSS and EPSS are used to prioritise, and how triage feeds CRA-compliant vulnerability handling workflows.
- [Security War Room / Incident Bridge](https://cvdportal.com/glossary/war-room): What a security war room is, how to structure one for CRA-relevant incidents, and how war room activities connect to CRA Article 14 notification obligations.
- [Zero-Day Vulnerability](https://cvdportal.com/glossary/zero-day): Learn what a zero-day vulnerability is, how it differs from other vulnerabilities, and what the EU Cyber Resilience Act requires manufacturers to do when one is exploited.

## Free tools

- [Article 14 Deadline Calculator](https://cvdportal.com/tools/article-14-timeline): Calculate your CRA Article 14 notification deadlines instantly. Enter when you became aware of an actively exploited vulnerability and get your 24-hour, 72-hour, and 14-day ENISA reporting deadlines.
- [CRA Vulnerability Disclosure Readiness Check](https://cvdportal.com/tools/cra-readiness-score): Are you ready to receive, handle and report vulnerabilities under the CRA? Answer 20 questions on your coordinated disclosure and Article 14 reporting process and get a readiness score with prioritised gaps.
- [CSAF 2.0 Advisory Validator](https://cvdportal.com/tools/csaf-validator): Validate your CSAF 2.0 security advisory JSON against the required schema. Check for missing mandatory fields, invalid structure, and CRA Annex I compliance indicators.
- [CVD Policy Generator](https://cvdportal.com/tools/cvd-policy-generator): Generate a ready-to-publish coordinated vulnerability disclosure policy in minutes. Step-by-step wizard covering CRA Article 13 obligations, response timelines, and CSAF commitments.
- [CVSS 4.0 Calculator](https://cvdportal.com/tools/cvss-4-calculator): Free CVSS v4.0 calculator covering Base, Threat and Environmental metrics, with the MacroVector shown so the score can be checked. Scoring is a port of the FIRST.ORG reference implementation. No signup.
- [CVSS Calculator](https://cvdportal.com/tools/cvss-calculator): Calculate CVSS 3.1 vulnerability severity scores with CRA Article 14 context. Free tool - select base metrics and get your score, severity rating, and Article 14 notification threshold assessment.
- [Disclosure Deadline Tracker](https://cvdportal.com/tools/disclosure-deadline-tracker): Track every CRA Article 14 ENISA notification deadline and researcher 90-day embargo from a single report date. Colour-coded UPCOMING / DUE TODAY / OVERDUE status for each milestone.
- [Article 14 Notification Template Builder](https://cvdportal.com/tools/notification-template-builder): Generate a complete CRA Article 14 early-warning notification draft for ENISA in seconds. Fill in product, CVE, exploitation status, and affected users - get a submission-ready text block.
- [SBOM Component CVE Checker](https://cvdportal.com/tools/sbom-checker): Paste your component list (package@version or CPE format) and generate direct NVD CVE search links for each component. Fast triage for your SBOM against known vulnerability databases.
- [SBOM Validator (BSI TR-03183-2 and CISA 2026 Minimum Elements)](https://cvdportal.com/tools/sbom-validator): Validate your CycloneDX or SPDX SBOM against two frameworks side by side: BSI TR-03183-2 format versions and required fields, and the 2026 CISA Minimum Elements with its 17 data fields. Runs in your browser, nothing is uploaded.
- [security.txt Generator](https://cvdportal.com/tools/security-txt-generator): Generate a compliant security.txt file for your product or website in seconds. Free tool - fills all RFC 9116 fields including CRA-required contact and policy URLs.

## Policy templates

- [Article 14 Early Warning Notification Template](https://cvdportal.com/templates/article-14-notification-template): A free Article 14 early warning notification template for EU manufacturers. Use this to notify ENISA within 24 hours of discovering an actively exploited vulnerability, as required by the Cyber Resilience Act.
- [Coordinated Vulnerability Disclosure Policy Template](https://cvdportal.com/templates/coordinated-disclosure-policy): A free coordinated vulnerability disclosure (CVD) policy template aligned with ISO/IEC 29147 and the EU Cyber Resilience Act. Covers disclosure timelines, safe harbour, and researcher coordination.
- [Basic CVD Policy Template](https://cvdportal.com/templates/cvd-policy-basic): Download a free coordinated vulnerability disclosure policy template aligned with ISO/IEC 29147. Ready to customise - used by EU manufacturers to meet CRA Article 13 obligations.
- [CVD Policy Template for Contract Manufacturers](https://cvdportal.com/templates/cvd-policy-contract-manufacturer): A free CVD policy template for contract manufacturers (EMS/ODM providers) building products on behalf of brand owners. Covers CRA Article 13 obligations, brand owner coordination, and manufacturing process security.
- [CRA-Compliant CVD Policy Template](https://cvdportal.com/templates/cvd-policy-cra-compliant): A free vulnerability disclosure policy template that meets EU Cyber Resilience Act Articles 13 and 14. Includes Article 14 notification timelines, CSAF advisory language, and supply chain coordination.
- [CVD Policy Template for Industrial and OT Manufacturers](https://cvdportal.com/templates/cvd-policy-industrial): A free CVD policy template for industrial control system and operational technology manufacturers. Covers CRA Article 13/14, ICS-CERT coordination, operational continuity, and critical infrastructure obligations.
- [CVD Policy Template for IoT Manufacturers](https://cvdportal.com/templates/cvd-policy-iot): A free vulnerability disclosure policy template for IoT and connected device manufacturers. Addresses CRA Article 13 obligations, firmware update requirements, and constrained-device considerations.
- [CVD Policy Template for Medical Device Manufacturers](https://cvdportal.com/templates/cvd-policy-medical): A free vulnerability disclosure policy template for medical device manufacturers. Addresses CRA, MDR, and FDA Cybersecurity guidance obligations including patient safety escalation and regulatory notification.
- [CVD Policy Template for OEM Manufacturers](https://cvdportal.com/templates/cvd-policy-oem): A free CVD policy template for OEM manufacturers supplying components to branded product makers. Covers CRA supply chain obligations, upstream/downstream coordination, and component-level vulnerability disclosure.
- [EU Declaration of Conformity Template (CRA Annex V)](https://cvdportal.com/templates/declaration-of-conformity-template): A free EU Declaration of Conformity template based on CRA Annex V. One section per required field, with practical guidance for manufacturers drawing up the DoC under Article 28 before CE marking.
- [EU CVD Policy Template](https://cvdportal.com/templates/eu-cvd-policy): A free coordinated vulnerability disclosure policy template for EU manufacturers under the Cyber Resilience Act. Covers Article 13 obligations, ENISA reporting, and researcher safe harbour.
- [PSIRT Charter Template](https://cvdportal.com/templates/psirt-charter): A free PSIRT charter template for establishing a Product Security Incident Response Team. Defines mandate, scope, roles, and escalation procedures aligned with CRA Article 13 and ISO/IEC 30111.
- [Responsible Disclosure Policy Template](https://cvdportal.com/templates/responsible-disclosure-policy): A free responsible disclosure policy template for manufacturers and software companies. Covers researcher commitments, safe harbour, and disclosure timelines. CRA Article 13 compliant.
- [Agricultural IoT gateway CRA Risk Assessment Starter](https://cvdportal.com/templates/risk-assessment-starter-agricultural-iot): A free CRA risk assessment starter for agriculture: classification, asset inventory, 10 STRIDE threats and risk criteria you can copy or seed straight into CVD Portal.
- [Vehicle telematics backend CRA Risk Assessment Starter](https://cvdportal.com/templates/risk-assessment-starter-automotive-oem): A free CRA risk assessment starter for automotive: classification, asset inventory, 10 STRIDE threats and risk criteria you can copy or seed straight into CVD Portal.
- [Network management system CRA Risk Assessment Starter](https://cvdportal.com/templates/risk-assessment-starter-enterprise-networking): A free CRA risk assessment starter for enterprise networking: classification, asset inventory, 10 STRIDE threats and risk criteria you can copy or seed straight into CVD Portal.
- [Firewall / IDS-IPS appliance CRA Risk Assessment Starter](https://cvdportal.com/templates/risk-assessment-starter-firewall-appliance): A free CRA risk assessment starter for network security: classification, asset inventory, 10 STRIDE threats and risk criteria you can copy or seed straight into CVD Portal.
- [Industrial controller (PLC) CRA Risk Assessment Starter](https://cvdportal.com/templates/risk-assessment-starter-industrial-automation): A free CRA risk assessment starter for industrial automation: classification, asset inventory, 10 STRIDE threats and risk criteria you can copy or seed straight into CVD Portal.
- [Mobile robot controller CRA Risk Assessment Starter](https://cvdportal.com/templates/risk-assessment-starter-robotics): A free CRA risk assessment starter for robotics: classification, asset inventory, 10 STRIDE threats and risk criteria you can copy or seed straight into CVD Portal.
- [Smart home security hub CRA Risk Assessment Starter](https://cvdportal.com/templates/risk-assessment-starter-smart-home): A free CRA risk assessment starter for consumer iot: classification, asset inventory, 10 STRIDE threats and risk criteria you can copy or seed straight into CVD Portal.
- [Smart meter gateway CRA Risk Assessment Starter](https://cvdportal.com/templates/risk-assessment-starter-smart-meter): A free CRA risk assessment starter for energy metering: classification, asset inventory, 10 STRIDE threats and risk criteria you can copy or seed straight into CVD Portal.
- [Carrier router / CPE CRA Risk Assessment Starter](https://cvdportal.com/templates/risk-assessment-starter-telecom-equipment): A free CRA risk assessment starter for telecommunications: classification, asset inventory, 10 STRIDE threats and risk criteria you can copy or seed straight into CVD Portal.
- [Network camera / NVR CRA Risk Assessment Starter](https://cvdportal.com/templates/risk-assessment-starter-video-surveillance): A free CRA risk assessment starter for video surveillance: classification, asset inventory, 10 STRIDE threats and risk criteria you can copy or seed straight into CVD Portal.
- [Security Incident Notification Policy Template](https://cvdportal.com/templates/security-incident-notification): A free security incident notification policy for EU manufacturers under the Cyber Resilience Act. Covers internal escalation, ENISA notification, and user communication procedures.
- [security.txt Template (RFC 9116)](https://cvdportal.com/templates/security-txt-template): Free security.txt generator following RFC 9116. Fill in the contact, expires, and policy fields to meet the CRA Article 13 point-of-contact requirement and help researchers reach you.
- [CRA Technical Documentation Template (Annex VII)](https://cvdportal.com/templates/technical-documentation-template): A free CRA technical documentation template structured around Annex VII. Assemble the technical file market surveillance authorities can request, from product description and risk assessment to test reports and the EU Declaration of Conformity.
- [CRA User Information Template (Annex II)](https://cvdportal.com/templates/user-information-template): A free template for the CRA Annex II information and instructions supplied with products with digital elements. Covers the vulnerability reporting contact, support period end date, DoC access, and secure use instructions.
- [Vulnerability Reporting Process Template](https://cvdportal.com/templates/vulnerability-reporting-process): A free internal vulnerability reporting process template for security teams. Covers intake, triage, severity scoring, remediation tracking, and Article 14 escalation under the EU Cyber Resilience Act.

## Competitor comparisons

- [CVD Portal vs HackerOne](https://cvdportal.com/compare/hackerone): Crowdsourced vulnerability discovery aimed at large security teams.
- [CVD Portal vs Bugcrowd](https://cvdportal.com/compare/bugcrowd): Crowdsourced security testing across bounty, VDP, and pentest formats.
- [CVD Portal vs Intigriti](https://cvdportal.com/compare/intigriti): European crowdsourced security platform with a curated researcher community.
- [CVD Portal vs YesWeHack](https://cvdportal.com/compare/yeswehack): European bug bounty, VDP, and attack surface platform.
- [CVD Portal vs Open Bug Bounty](https://cvdportal.com/compare/openbugbounty): Free community-run platform for coordinated web vulnerability disclosure.
- [CVD Portal vs disclose.io](https://cvdportal.com/compare/disclose-io): Community-maintained safe-harbor language and CVD policy templates.
- [CVD Portal vs Vicarius](https://cvdportal.com/compare/vicarius): Vulnerability remediation platform focused on patch deployment.
- [CVD Portal vs VulnCheck](https://cvdportal.com/compare/vulncheck): Vulnerability intelligence, exploit data, and KEV-style enrichment.
- [CVD Portal vs Vanta](https://cvdportal.com/compare/vanta): Compliance automation for organisation-level frameworks such as SOC 2 and ISO 27001.
- [CVD Portal vs Drata](https://cvdportal.com/compare/drata): Continuous control monitoring and multi-framework compliance automation for security teams.
- [CVD Portal vs CRA consulting](https://cvdportal.com/compare/cra-consulting): Expert-led CRA readiness delivered as an engagement rather than as a system.

## Blog

- [The ETSI EN 304 Series: One CRA Standard Per Annex III Product Category](https://cvdportal.com/blog/etsi-en-304-vertical-cra-standards): Everyone tracking CRA standardisation is watching the horizontal prEN 40000 series. The other half of standardisation request M/606 is 18 vertical standards, EN 304 617 to EN 304 642, one per Annex III product category, and ETSI has public drafts out for most of them. Here is the full mapping, the categories ETSI is not covering, and why none of it changes your Article 32 route yet.
- [The 2026 SBOM Minimum Elements: What Changed, and Where It Collides With the CRA](https://cvdportal.com/blog/sbom-minimum-elements-2026-what-changed): CISA and seventeen partner agencies, seven of them EU national authorities, have replaced the 2021 NTIA SBOM minimum elements. The field count goes from seven to seventeen, Supplier Name becomes Component Producer, and Depth becomes Coverage with no minimum depth. That last change means a CRA-minimal SBOM fails the new baseline by construction. Here is the full delta, and why your SBOM can now pass one framework and fail another.
- [Every Worked Example in the Commission's CRA Guidance, and What Changed From the Draft](https://cvdportal.com/blog/commission-cra-guidance-worked-examples): C(2026) 5252 carries 67 numbered examples and 5 remote data processing use cases. Fourteen of them are new since the consultation draft and one was deleted. Here is what the additions tell you about where the Commission thinks manufacturers are getting it wrong.
- [The Commission's CRA Guidance: Reading the Four-Factor Test and the Support Period Rules](https://cvdportal.com/blog/cra-commission-guidance-substantial-modification-support-period): C(2026) 5252 gives manufacturers two things they have been working without. A four-factor test for whether a software update is a substantial modification, and a clear statement that five years of support is a floor rather than a default. This walks through both using the Commission's own worked examples.
- [What an Empty Risk Assessment Leaves Out](https://cvdportal.com/blog/cra-risk-assessment-blank-page-problem): A CRA risk assessment has to be the manufacturer's own determination, which is the strongest argument for starting from an empty document. The trouble is what an empty document selects for. Teams write down the threats they already discuss and leave out the interface nobody owns, the decommissioning path, and the failure that only appears at fleet scale. What a starting draft is for, and the one property it needs to stay safe.
- [Your CRA Technical File Is Mostly Written Already](https://cvdportal.com/blog/mapping-existing-documents-to-cra-requirements): Most manufacturers approaching the CRA technical file treat it as a writing project. It is a mapping project first. Annex VII asks you to demonstrate that specific evidence satisfies specific essential requirements, and the architecture diagrams, test reports and user documentation that demonstrate them usually already exist. Here is why the mapping is the hard part, and why a gap list computed before mapping measures the wrong thing.
- [Your CRA Evidence Already Lives in Jira: Importing It Instead of Rewriting It](https://cvdportal.com/blog/importing-cra-evidence-from-jira-and-confluence): Annex VII asks for records of work that engineering teams already produce, in tickets and wiki pages. Most compliance tooling asks you to transcribe that record into a second set of documents, which then starts decaying immediately. CVD Portal now reads Jira and Confluence directly, so the technical file is built from the systems where the work actually happened.
- [Keeping CRA Documentation Up to Date: What the Regulation Actually Requires](https://cvdportal.com/blog/keeping-cra-documentation-up-to-date): The CRA makes the technical file, the risk assessment and the EU Declaration of Conformity living documents. Article 31(2) says continuously updated, Article 13(3) says updated during the support period, and market surveillance can ask for the file a decade later. Here are the update duties, the events that trigger them, and a cadence that survives an inspection.
- [Running the CRA Risk Assessment in Practice: CVD Portal and Draft prEN 40000-1-2](https://cvdportal.com/blog/risk-assessment-in-practice-en-40000-1-2): Article 13 requires a documented cybersecurity risk assessment, and the draft European standard prEN 40000-1-2 describes the process a manufacturer should run to produce one. This post walks through how that process works in CVD Portal's products workspace, from product context and risk acceptance criteria to the Annex I applicability table, and maps every step to the regulation and to the draft standard's clauses.
- [What the New Joint CISA CVD Guidance Means for CRA Manufacturers](https://cvdportal.com/blog/cisa-cvd-guidance-cra-manufacturers): Five national cyber agencies published a joint guide on working with security researchers. It reads like a checklist for the CRA's vulnerability handling requirements. Here is the mapping, and what to do about each recommendation.
- [Running a Bug Bounty Programme Alongside Your CVD Process](https://cvdportal.com/blog/running-a-bug-bounty-programme-alongside-cvd): Bug bounties pay researchers for valid reports. The CRA does not require them, but it does require a coordinated vulnerability disclosure policy. Here is how the two approaches relate, what CVD Portal provides as the disclosure layer, and how AI triage keeps up when report volume grows.
- [Annex II in Practice: The User Information the CRA Makes You Publish](https://cvdportal.com/blog/annex-ii-user-information-in-practice): Annex II of the Cyber Resilience Act prescribes the information and instructions every product with digital elements must ship with, from the vulnerability reporting contact to the support period end date. Here is each required item with practical examples, where the information must live, and the mistakes market surveillance will notice first.
- [CE Marking Under the Cyber Resilience Act: What Changes for Manufacturers](https://cvdportal.com/blog/ce-marking-under-the-cra): From 11 December 2027 the CE mark on a product with digital elements attests cybersecurity conformity. Here are the Article 30 affixing rules, when a notified body number must accompany the mark, the sequence that must be complete before you affix it, and what market surveillance does about a wrongly marked product.
- [The CRA Cybersecurity Risk Assessment: A Working Methodology](https://cvdportal.com/blog/cra-product-risk-assessment-methodology): Article 13 makes a documented cybersecurity risk assessment the foundation of every CRA conformity claim. Here is a working methodology, from STRIDE threat modelling per component and data flow to likelihood and impact scoring, and how the results decide which Annex I requirements apply.
- [The Complete CRA Guide for SMEs: Every Obligation in One Place](https://cvdportal.com/blog/cra-sme-guide-complete-obligations): A single walkthrough of every Cyber Resilience Act obligation for a small manufacturer, from the first scope check through classification, Module A self-assessment, documentation, and CE marking to the reporting duties that begin on 11 September 2026.

## News

- [ENISA Publishes SRP Registration and Notification Guidance](https://cvdportal.com/news/enisa-srp-registration-guidance): Filing an Article 14 notification requires an EU Login account, your coordinating CSIRT has to validate your reporters after you first sign in, and ENISA has confirmed there will be no submission API. All three have lead times, and the platform opens on the same day the 24-hour clock starts.
- [ENISA Publishes a Secure by Design and Default Playbook](https://cvdportal.com/news/enisa-secure-by-design-playbook): Twenty-two playbooks covering secure by design and secure by default across a product life cycle, aimed at SMEs and published on GitHub under CC BY 4.0. It is ENISA guidance rather than a harmonised standard, so applying it confers no presumption of conformity.
- [CISA Publishes the 2026 SBOM Minimum Elements, Co-Signed by Seven EU Authorities](https://cvdportal.com/news/cisa-2026-sbom-minimum-elements): Version 2.1 replaces the 2021 NTIA baseline and takes the field count from seven to seventeen. It is not Union law. Seven EU national cybersecurity agencies co-authored it anyway, so expect procurement to follow it, and an SBOM built to the CRA floor fails it by construction.
- [ETSI Opens Public Drafts of the EN 304 Vertical CRA Standards](https://cvdportal.com/news/etsi-en-304-vertical-standards): ETSI TC CYBER has published draft Cyber Resilience Act standards for anti-malware software, firewalls, routers, hypervisors and other Annex III product categories, the first of 18 product-specific deliverables under standardisation request M/606.
- [Commission Adopts Its Guidance on Applying the Cyber Resilience Act](https://cvdportal.com/news/commission-cra-guidance-adopted): C(2026) 5252 sets out the Commission's own reading of the CRA across 84 pages and 67 worked examples. It defines when the Article 14 reporting clock starts, gives a four-factor test for substantial modification, and confirms that five years of support is a floor rather than a default.
- [Why CRA Documentation Never Stops Being Due](https://cvdportal.com/news/keeping-cra-documentation-up-to-date): Article 31(2) requires the technical file to be continuously updated during the support period, Article 13(3) puts the same clock on the risk assessment, and Article 28 keeps the Declaration of Conformity current. A new walkthrough covers the update duties, the trigger events and a review cadence that holds up.
- [Five Cyber Agencies Publish Joint CVD Guidance, and It Reads Like a CRA Checklist](https://cvdportal.com/news/cisa-cvd-guidance-cra-manufacturers): CISA, NSA, JPCERT/CC, NCSC-NL, and NCSC-UK published a joint guide on establishing a coordinated vulnerability disclosure programme. It names the EU Cyber Resilience Act directly.
- [Five National Cyber Agencies Publish Joint Guide on Establishing a CVD Program. Here Is How CVD Portal Measures Up](https://cvdportal.com/news/joint-guide-cvd-program-security-researchers): CISA, NSA, JPCERT/CC, NCSC-NL and NCSC-UK released joint guidance on building a coordinated vulnerability disclosure program. We mapped every recommendation against CVD Portal.
- [Bug Bounty or CVD? What the CRA Requires and How to Run Both](https://cvdportal.com/news/running-a-bug-bounty-programme-alongside-cvd): The CRA requires a coordinated vulnerability disclosure policy, a bug bounty is optional. Our new guide explains how the two approaches relate and how AI triage keeps up when report volume grows.
- [CVD Portal at GITEX Europe Berlin 2026](https://cvdportal.com/news/cvdportal-at-gitex-europe-2026): CVD Portal will be at GITEX AI Europe in Berlin on 30 June and 1 July 2026, stand H2.2-B90 at Messe Berlin. Come see how manufacturers run Coordinated Vulnerability Disclosure and meet the EU Cyber Resilience Act reporting obligations that start applying on 11 September 2026.

## API and machine-readable resources

- [Documentation](https://docs.cvdportal.com): Product guides for CVD Portal, including the CRA conformity workspace.
- [API reference](https://docs.cvdportal.com/cvd/api-overview): REST API developer guide (v1, Bearer auth).
- [OpenAPI specification](https://cvdportal.com/openapi.json): Machine-readable REST API spec (v1, Bearer auth, Enterprise plan).
- [API catalog](https://cvdportal.com/.well-known/api-catalog): RFC 9727 linkset to spec, docs, and status.
- [Security policy](https://cvdportal.com/.well-known/security.txt): RFC 9116 disclosure contact.
- [RSS feed](https://cvdportal.com/feed.xml): Latest blog posts and product news.
- [Sitemap](https://cvdportal.com/sitemap.xml): Full URL index.


---

# Full content

## CRA FAQ

### Do I have to wait for the EN 40000 standards before I can comply with the CRA?
URL: https://cvdportal.com/faq/do-i-have-to-wait-for-the-en-40000-standards
Last reviewed: 2026-07-27
Verified against: Regulation (EU) 2024/2847 as published in OJ L, 20.11.2024, read at EUR-Lex on 27 July 2026, with series status checked against CEN-CENELEC and the Commission standardisation page on the same date

Waiting is the wrong plan. No part of the EN 40000 series has been cited in the Official Journal, so the Article 27 presumption of conformity is unavailable, and Article 32(2) escalates a Class I important product to third-party assessment precisely where a manufacturer has not applied a harmonised standard or where none exists. Compliance is owed from 11 December 2027 whatever the standards do. The series is drafted under Commission standardisation request M/606, with parts 1-1, 1-2 and 1-3 past public enquiry and awaiting approval.

Applying the current drafts, and the recognised standards they build on, is the low-regret path. A technical file argued against those is far easier to migrate than one argued from scratch.

| Fact | Value |
| --- | --- |
| Standardisation request | M/606, Commission Implementing Decision C(2025) 618 final |
| Accepted by the ESOs | 3 April 2025, by CEN, CENELEC and ETSI |
| Scope of the request | 41 standards, horizontal and product-specific |
| Horizontal drafting body | CEN-CLC/JTC 13 WG 9 |
| Cited in the Official Journal | None, as at 27 July 2026 |
| Effect of that | No presumption of conformity under Article 27 |

#### What is the EN 40000 series and who is drafting it?
Article 27(1) obliges the Commission to ask one or more European standardisation organisations to draft harmonised standards for the Annex I essential cybersecurity requirements. It did so through standardisation request M/606, issued by Commission Implementing Decision C(2025) 618 final of 3 February 2025 and accepted by CEN, CENELEC and ETSI on 3 April 2025. The request covers 41 standards, split between horizontal standards that apply to every product with digital elements and vertical standards for specific product categories, with priority given to the important and critical categories in Annexes III and IV.

EN 40000 is the horizontal family. It is drafted by CEN-CLC/JTC 13 WG 9 and is structured in parts:

- prEN 40000-1-1, vocabulary and terminology across the series.
- prEN 40000-1-2, principles for cyber resilience, covering the risk methodology and lifecycle activities behind Annex I Part I.
- prEN 40000-1-3, vulnerability handling, mapping to Annex I Part II.
- prEN 40000-1-4, generic security requirements, the catalogue mapping to the Annex I Part I requirements.
- TR 40000-1-5, a Technical Report on threats and security objectives. It is informative rather than normative.

The [part-by-part breakdown](/standards/en-40000) covers what each one contains. This answer is about whether their absence blocks you.

#### What does citation in the Official Journal actually buy you?
Article 27(1) is precise about the trigger. Products and processes in conformity with harmonised standards, or parts of them, the references of which have been published in the Official Journal of the European Union, are presumed to conform to the essential requirements in Annex I covered by those standards.

Two consequences follow from that wording.

The presumption attaches to publication of the reference in the Official Journal, not to a standard existing, being approved, or being useful. A draft carrying the pr prefix confers nothing under Article 27, however closely a product follows it.

The presumption is also partial. It reaches only the requirements the cited standard covers. Since the EN 40000 parts are horizontal and split across Annex I Part I and Part II, no single part will ever cover the whole of Annex I, and a manufacturer will still have to argue the remainder directly.

Presumption of conformity is an evidentiary shortcut. Its absence removes the shortcut and leaves the obligation intact.

#### What waiting actually costs, under Article 32
For most products the answer is the assessment route, and it is a budget question rather than a paperwork one.

Article 32(1) lets a manufacturer demonstrate conformity through the internal control procedure based on module A, which is self-assessment, among other routes. Article 32(2) then removes that option for important products in Annex III Class I in a specific circumstance. Where the manufacturer has not applied, or has applied only in part, harmonised standards, common specifications or European cybersecurity certification schemes at assurance level at least substantial, or where such standards do not exist, the product has to go through EU-type examination (module B followed by module C) or full quality assurance (module H).

Read that against the current state of the series. No CRA harmonised standard is cited, so for Annex III Class I products the "where such harmonised standards do not exist" limb is satisfied today, and third-party assessment is the live route. Article 32(3) puts Class II products on third-party assessment regardless.

So waiting does not defer the work. It defers the option of avoiding a notified body, and notified body capacity is itself a scheduling constraint ahead of 11 December 2027.

One route out is worth knowing. Article 32(5) allows a manufacturer of an Annex III product qualifying as free and open source software to use any Article 32(1) procedure, including module A, provided the Article 31 technical documentation is made public when the product is placed on the market.

#### Which standards carry weight before EN 40000 is cited?
Conformity still has to be demonstrated, and a technical file argued against recognised standards is the strongest available evidence short of a presumption. The practical set:

- ETSI EN 303 645 for consumer IoT. Baseline provisions widely referenced in Europe and a natural fit for Annex I Part I arguments on consumer products.
- IEC 62443-4-1 for the secure product development lifecycle and IEC 62443-4-2 for component security requirements, drawn from industrial automation and control systems.
- ISO/IEC 29147 for vulnerability disclosure and ISO/IEC 30111 for vulnerability handling. These are the base standards behind the Annex I Part II process requirements.
- BSI TR-03183, parts 1 to 3, the most concrete official mapping to CRA obligations published by a national authority, covering general requirements, SBOM and vulnerability report intake.
- EN 18031, harmonised under the Radio Equipment Directive delegated regulation. Already citable for radio equipment and a likely input to the CRA product standards.

None of these confers presumption of conformity under the CRA. What they buy is a defensible file and a migration path, because the harmonised set is being built on the same material.

The risk assessment is the piece to start with regardless of standards, since Article 13(3) makes it the thing that determines which Annex I requirements apply to your product in the first place.

#### Where the parts stand today
As at 27 July 2026, parts 1-1, 1-2 and 1-3 have completed their CEN public enquiry and sit in approval. Part 1-4 remains in development, with a target of 30 October 2027. Delivery of EN 40000-1-2 and EN 40000-1-3 has been indicated for the second half of 2026.

No CRA harmonised standard has been ratified as an EN or had its reference published in the Official Journal, so the Article 27 presumption is available for no product category.

The gap between the 30 October 2027 target for the later deliverables and the 11 December 2027 application date is about six weeks. That is not enough time to build a technical file from nothing, which is the practical reason the wait-and-see plan fails even if every deadline is met.

Status here moves. Check the Official Journal citations directly rather than working from any draft list, including this one.

#### What if the standards are not cited before December 2027?
The obligation does not move. Article 71(2) applies the Regulation from 11 December 2027, and Article 27 offers a presumption rather than a precondition. A manufacturer demonstrates conformity with Annex I by whatever evidence it can stand behind, and the technical documentation under Article 31 and Annex VII is where that argument lives.

The Regulation anticipates the standards being late. Article 27(2) empowers the Commission to adopt implementing acts establishing common specifications covering technical requirements that provide a means to comply with Annex I, and it may do so where a standardisation request has not been accepted, where the requested standard is not delivered within the deadline, or where the resulting standard does not satisfy the request. Common specifications carry the same presumption of conformity as a cited harmonised standard.

A second route runs through certification. Article 27 extends the presumption, to the extent specified, to European cybersecurity certification schemes adopted under Regulation (EU) 2019/881. A delegated act setting out the presumption granted by the EUCC scheme has been signalled for late 2026.

None of those fallbacks helps a manufacturer that has not done the underlying work. Each one is a shortcut for demonstrating conformity that already exists.

Sources:
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 27 (Presumption of conformity)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_27). Publications Office of the European Union, Article 27(1) and (2), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 32 (Conformity assessment procedures)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_32). Publications Office of the European Union, Article 32(1), (2), (3) and (5), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 71 (Entry into force and application)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_71). Publications Office of the European Union, Article 71(2), CELEX:32024R2847
- [Commission Implementing Decision on a standardisation request to CEN, CENELEC and ETSI in support of Regulation (EU) 2024/2847](https://digital-strategy.ec.europa.eu/en/policies/cra-standardisation). European Commission, Standardisation request M/606, Annex, C(2025) 618 final, request M/606
- [Cyber Resilience Act, standardisation](https://digital-strategy.ec.europa.eu/en/policies/cra-standardisation). European Commission, DG CONNECT, Scope of request M/606 and priority product categories, As published, July 2026 (non-binding)
- [prEN 40000 series, horizontal standards for the Cyber Resilience Act, and the acceptance of request M/606](https://www.cencenelec.eu/news-events/news/2025/newsletter/ots-62-cra/). CEN-CENELEC, CEN-CLC/JTC 13 WG 9, Series status and drafting committee, prEN 40000-1-1 to 1-4, TR 40000-1-5, Drafts. Parts 1-1, 1-2 and 1-3 past enquiry, none cited in the Official Journal (non-binding)
- [ETSI EN 303 645, Cyber Security for Consumer Internet of Things, baseline requirements](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/). ETSI, ETSI EN 303 645 (non-binding)
- [IEC 62443-4-1 (secure product development lifecycle) and IEC 62443-4-2 (technical security requirements for components)](https://www.iec.ch/blog/understanding-iec-62443). International Electrotechnical Commission, IEC 62443-4-1, IEC 62443-4-2 (non-binding)
- [ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling processes)](https://www.iso.org/standard/72311.html). ISO/IEC JTC 1/SC 27, ISO/IEC 29147:2018, ISO/IEC 30111:2019 (non-binding)
- [BSI TR-03183, Cyber Resilience Requirements for Manufacturers and Products, parts 1 to 3](https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html). Bundesamt für Sicherheit in der Informationstechnik, BSI TR-03183 (non-binding)
- [EN 18031 series, common security requirements for radio equipment](https://www.cencenelec.eu/areas-of-work/cen-cenelec-topics/cybersecurity-and-data-protection/). CEN-CENELEC, EN 18031-1, EN 18031-2, EN 18031-3 (non-binding)

### Do I have to report the same incident under the CRA, NIS2 and GDPR?
URL: https://cvdportal.com/faq/do-i-report-the-same-incident-under-cra-nis2-and-gdpr
Last reviewed: 2026-07-27
Verified against: The final texts of Regulation (EU) 2024/2847, Directive (EU) 2022/2555 and Regulation (EU) 2016/679, all read at EUR-Lex on 27 July 2026

One event can trigger all three, and none of them excuses the others. CRA Article 14 binds the manufacturer when a vulnerability in its product is actively exploited or a severe incident affects product security, filed to a coordinating CSIRT and ENISA. NIS2 Article 23 binds essential and important entities when a significant incident disrupts their own services. GDPR Article 33 binds the controller within 72 hours of a personal data breach. The triggers, the subjects and the recipients differ, so the filings run in parallel.

The 24 and 72 hour rhythm is deliberately similar across the CRA and NIS2, which is what makes the two easy to confuse and dangerous to conflate.

| Fact | Value |
| --- | --- |
| CRA Article 14 trigger | Actively exploited vulnerability, or severe incident affecting product security |
| NIS2 Article 23 trigger | Significant incident affecting the entity's own service provision |
| GDPR Article 33 trigger | Personal data breach with a risk to rights and freedoms |
| CRA recipients | Coordinating CSIRT and ENISA, via the single reporting platform |
| GDPR deadline | 72 hours to the supervisory authority, no 24-hour stage |
| Overlap relief | None. The CRA is without prejudice to GDPR |

#### Why one event lands in three regimes
The regimes do not overlap because they are badly drafted. They overlap because each asks a different question about the same event.

CRA Article 14 asks about the product. A manufacturer notifies any actively exploited vulnerability contained in its product with digital elements, and any severe incident having an impact on the security of the product. Article 14(5) defines severe as negatively affecting, or being capable of negatively affecting, the ability of the product to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or leading to the introduction or execution of malicious code in the product or in a user's network and information systems.

NIS2 Article 23 asks about your service. An essential or important entity notifies any incident having a significant impact on the provision of its services. Article 23(3) treats an incident as significant where it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or where it has affected or is capable of affecting others by causing considerable material or non-material damage.

GDPR Article 33 asks about personal data. The controller notifies a personal data breach to the competent supervisory authority unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.

A single exploited vulnerability in a product you manufacture and also operate, which exposes customer records, satisfies all three descriptions at once. It is one event and three regulatory subjects: you as manufacturer, you as operator, you as controller.

#### The clocks, side by side
The CRA and NIS2 run a deliberately parallel three-stage rhythm. GDPR does not.

CRA Article 14(2), for an actively exploited vulnerability:

1. Early warning within 24 hours of becoming aware.
2. Vulnerability notification within 72 hours.
3. Final report no later than 14 days after a corrective or mitigating measure is available.

CRA Article 14(4), for a severe incident: 24 hours, then 72 hours, then a final report within one month after the 72-hour notification.

NIS2 Article 23(4), for a significant incident: an early warning within 24 hours, an incident notification within 72 hours, an intermediate report on request, and a final report no later than one month after the 72-hour notification. Where the incident is still ongoing at that point, a progress report is due instead and the final report follows within one month of the incident being handled.

GDPR Article 33(1): notification to the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware. There is no 24-hour stage and no scheduled final report. A notification made later than 72 hours has to be accompanied by reasons for the delay.

The trap is the CRA vulnerability track. Its 14-day final report is the only one of the five clocks anchored to a remedy being available rather than to a prior filing, so it cannot be diarised at the point of notification the way the others can.

#### Different recipients, different routes
The filings do not converge on one desk.

Under the CRA, notification goes simultaneously to the CSIRT designated as coordinator and to ENISA, through one submission on the single reporting platform. Article 14(7) picks the CSIRT by the manufacturer's main establishment in the Union. The [routing rules and platform mechanics](/faq/which-csirt-do-i-report-to-under-the-cra) work through that determination.

Under NIS2, notification goes to the entity's CSIRT or, where applicable, its competent authority, determined by the Member State's own transposition. Where an entity notifies the competent authority, that authority forwards the notification to the CSIRT.

Under GDPR, notification goes to the supervisory authority competent under Article 55, which for cross-border processing runs through the lead supervisory authority mechanism.

The CSIRT that receives your CRA notification and the CSIRT that receives your NIS2 notification can be different bodies in different Member States, because the CRA routes by main establishment while NIS2 routes by where you are established as an entity providing services. Assuming they are the same body is a common and expensive shortcut.

#### The notifications that go to people rather than regulators
Each regime carries a separate duty toward the people affected, and these are the ones most often forgotten in the first 72 hours.

CRA Article 14(8) requires the manufacturer, after becoming aware of an actively exploited vulnerability or a severe incident, to inform impacted users and where appropriate all users, and where necessary of the mitigation and corrective measures they can deploy. Where appropriate this should be in a structured, machine-readable format that is easily automatically processable. That clause is the practical case for issuing a CSAF advisory.

NIS2 Article 23(1) requires entities, where appropriate, to notify recipients of their services of significant incidents likely to adversely affect the provision of those services. Article 23(2) adds a duty to communicate available measures or remedies to recipients potentially affected by a significant cyber threat.

GDPR Article 34 requires communication to the data subject without undue delay where the breach is likely to result in a high risk to their rights and freedoms.

There is also an involuntary route. CRA Article 17(2) allows the coordinating CSIRT, after consulting the manufacturer and where appropriate with ENISA, to inform the public about a severe incident or to require the manufacturer to do so, where public awareness is necessary to prevent or mitigate it or disclosure is otherwise in the public interest. Article 14(8) carries a similar fallback where a manufacturer fails to inform users in a timely manner.

#### Does any one filing discharge the others?
No, and the CRA says so about GDPR in terms. Recital 32 states that the Regulation should be without prejudice to Regulation (EU) 2016/679.

On NIS2 the relationship is one of layering rather than substitution. The CRA regulates products placed on the market. NIS2 regulates the cybersecurity risk management and reporting of essential and important entities. The CRA recognises that NIS2 sets risk-management measures for those entities which can require products meeting stricter requirements than the CRA lays down, and that Member States may impose additional requirements for the use of ICT products by those entities under the NIS2 minimum harmonisation principle. That is the language of two regimes operating together, not one displacing the other.

What the CRA does simplify is reporting within its own scope. Article 16(1) establishes the single reporting platform expressly to simplify manufacturers' reporting obligations, and Article 14(1) achieves simultaneous notification of the coordinating CSIRT and ENISA in one submission. That single filing covers the CRA. It does nothing for NIS2 or GDPR.

Information does move between authorities. Article 17(1) allows ENISA to submit notified information to EU-CyCLONe where relevant for coordinated management of large-scale incidents and crises. That is coordination between authorities, and it is not a substitute for the notifying entity's own obligations.

#### How to run it when the clock is live
The decisions worth making before an incident, because none of them can be made well inside 24 hours:

- Decide which regimes you are subject to, in which capacity. Manufacturer, essential or important entity, controller, or several at once. Record the reasoning.
- Identify each recipient in advance. Your CRA coordinating CSIRT under Article 14(7), your NIS2 CSIRT or competent authority under national transposition, and your GDPR supervisory authority.
- Build one intake that answers all three trigger tests from the same facts. The assessments differ, and the underlying evidence is largely the same.
- Treat 24 hours as the binding constraint. Where the CRA or NIS2 applies, the first filing is due a full 48 hours before the GDPR deadline.
- Diarise the divergence. Two of the final reports run one month from the 72-hour notification. The CRA vulnerability final report runs 14 days from a fix being available and cannot be scheduled up front.

One clarification worth holding onto. CRA Article 14 reporting applies from 11 September 2026, and Article 69(3) extends it to products placed on the market before 11 December 2027. NIS2 and GDPR obligations are already in force, so an incident today can already carry two of the three.

Sources:
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 (Reporting obligations of manufacturers)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_14). Publications Office of the European Union, Article 14(1) to (8), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 16 (Establishment of a single reporting platform)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_16). Publications Office of the European Union, Article 16(1) and (2), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 17 (Other provisions related to reporting)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_17). Publications Office of the European Union, Article 17(1) and (2), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 69 (Transitional provisions)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_69). Publications Office of the European Union, Article 69(3), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 71 (Entry into force and application)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_71). Publications Office of the European Union, Article 71(2), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Recital 23](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#rct_23). Publications Office of the European Union, Recital 23, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Recital 32](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#rct_32). Publications Office of the European Union, Recital 32, CELEX:32024R2847
- [Directive (EU) 2022/2555 (NIS 2), Article 23 (Reporting obligations)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32022L2555#art_23). Publications Office of the European Union, Article 23(1) to (4), CELEX:32022L2555
- [Regulation (EU) 2016/679 (GDPR), Article 33 (Notification of a personal data breach to the supervisory authority)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#art_33). Publications Office of the European Union, Article 33(1), CELEX:32016R0679
- [Regulation (EU) 2016/679 (GDPR), Article 34 (Communication of a personal data breach to the data subject)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#art_34). Publications Office of the European Union, Article 34(1), CELEX:32016R0679
- [Common Security Advisory Framework (CSAF) Version 2.0](https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html). OASIS Open, OASIS Standard, CSAF 2.0 (non-binding)

### Does the EU Cyber Resilience Act apply to open source software?
URL: https://cvdportal.com/faq/does-the-cra-apply-to-open-source-software
Last reviewed: 2026-07-27
Verified against: The final text of Regulation (EU) 2024/2847 as published in OJ L, 20.11.2024, read at EUR-Lex on 27 July 2026

The Cyber Resilience Act (Regulation (EU) 2024/2847) covers free and open source software only where it is supplied for distribution or use in the course of a commercial activity. Software its manufacturer does not monetise stays outside the scope. A paid or enterprise edition is placed on the market and carries the full manufacturer obligations. Legal persons who sustain a project intended for commercial use fall under the lighter steward regime in Article 24, which carries no CE marking and no administrative fines.

The commercial activity test applies to how the software is supplied. How the project was developed or financed stays out of the assessment.

| Fact | Value |
| --- | --- |
| Test that decides it | Commercial activity, applied to the supply (Recital 18) |
| Definition of FOSS | Article 3, point (48) |
| Steward regime | Article 24, light-touch, CE marking withheld |
| Fines for stewards | None. Article 64(10), point (b) |
| Applies from | 11 September 2026 (Article 14), 11 December 2027 (rest) |

#### What counts as supplying open source in the course of a commercial activity?
The CRA reaches products with digital elements made available on the Union market, meaning supplied for distribution or use in the course of a commercial activity. Recital 18 applies that test to the supply of the software. The circumstances under which the software was developed, and the way that development was financed, stay out of the assessment.

Recital 18 settles several cases that come up constantly:

- Free and open source software that its manufacturer does not monetise is outside the scope.
- A FOSS component supplied for integration into another manufacturer's product counts as making available on the market only where the original manufacturer monetises the component.
- Financial support from manufacturers, corporate code contributions and donations leave the activity non-commercial on their own.
- Regular releases on their own say nothing about commercial supply.
- A not-for-profit organisation set up so that all earnings after costs go to not-for-profit objectives is outside commercial activity.
- People who contribute source code to a project that is not under their responsibility fall outside the Regulation entirely.

Recital 20 covers the point maintainers ask about most. Hosting a product on open repositories, including through package managers or on collaboration platforms, is not by itself making it available on the market. The provider of such a service is a distributor only where it supplies the software for distribution or use on the Union market in the course of a commercial activity.

The Commission guidance sharpens the monetisation question. Its decisive factor is whether access to the software itself, including a specific version or bundled benefits such as technical assistance, is conditioned on remuneration. A paid enterprise edition is placed on the market even where a functionally equivalent free version exists under a FOSS licence, and the two count as different products. Optional support or consultancy sold around a freely downloadable product leaves that product off the market. This guidance is interpretive and carries no binding force.

#### Which software qualifies as free and open source software under the CRA?
Article 3, point (48) defines free and open source software as software whose source code is openly shared and which is made available under a free and open-source licence providing for all rights to make it freely accessible, usable, modifiable and redistributable.

Two conditions have to hold together:

1. The licence grants the full set of rights, covering access, use, modification and redistribution.
2. The source code is openly shared, meaning publicly available.

Software released under a permissive licence whose source reaches only paying customers or a closed group falls outside this definition, so none of the FOSS provisions apply to it. Such a product is assessed as any other product with digital elements.

#### What is an open-source software steward, and what does Article 24 require?
Article 3, point (14) defines an open-source software steward as a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements qualifying as free and open source software and intended for commercial activities, and that ensures the viability of those products.

Recital 19 names software foundations and entities that develop and publish FOSS in a business context, including not-for-profit entities. It counts hosting and managing development collaboration platforms, hosting source code, governing a product and steering its development as sustained support.

Article 24 sets three obligations.

1. Put in place and document, in a verifiable manner, a cybersecurity policy fostering secure development and effective vulnerability handling by the product's developers, fostering voluntary reporting under Article 15, and promoting the sharing of vulnerability information within the open-source community.
2. Cooperate with market surveillance authorities at their request, and supply that documentation on a reasoned request in a language the authority understands.
3. Report under Article 14 on a restricted footing. Article 14(1) applies to the extent the steward is involved in developing the product. Article 14(3) and (8) apply to the extent severe incidents affect network and information systems the steward provides for that development.

Two consequences carry real commercial weight. Recital 19 withholds the CE marking from stewards for the products whose development they support, because the regime does not impose the manufacturer obligations on them. Article 64(10), point (b), disapplies the administrative fines of Article 64(3) to (9) for any infringement of the Regulation by an open-source software steward.

Steward status is assessed per product. One legal entity can be the manufacturer of the paid edition it places on the market and the steward of the free community edition it publishes without monetisation.

#### What do I owe if I integrate open source components into a commercial product?
Integrating FOSS into a product you place on the market makes you the manufacturer of that product, and the CRA obligations cover it in its entirety, every integrated component included.

Article 13(5) requires manufacturers to exercise due diligence when integrating components sourced from third parties, so those components do not compromise the cybersecurity of the product. The paragraph says so expressly for free and open source components that have not been made available on the market in the course of a commercial activity.

Article 13(6) adds the upstream duty. On identifying a vulnerability in an integrated component, including an open source component, you report it to the person or entity manufacturing or maintaining that component, and you address and remediate it under the vulnerability handling requirements of Annex I Part II.

Integration leaves the component's own status under the Regulation unchanged. You do not take on responsibility for the component's compliance, even where you contribute code to it or fund its development.

Article 25 empowers the Commission to adopt delegated acts establishing voluntary security attestation programmes for FOSS products, so that developers, users and third parties can assess conformity and ease exactly this due diligence burden. No such programme is in force yet.

#### Do open source manufacturers get any conformity assessment relief?
Yes, on one route. Article 32(5) lets a manufacturer of a product qualifying as free and open source software that falls under the important categories in Annex III demonstrate conformity using any of the procedures in Article 32(1). Those include the internal control procedure based on module A set out in Annex VIII, which is self-assessment. The concession carries one condition. The technical documentation referred to in Article 31 has to be made available to the public at the time the product is placed on the market.

That matters because of what Article 32(2) and (3) otherwise require. A Class I important product escalates to third-party assessment, meaning module B plus C, module H, or a European cybersecurity certification scheme, wherever the manufacturer has not fully applied a harmonised standard, common specification or certification scheme at assurance level at least substantial, or where none exists. Harmonised standards under the CRA are still being developed, so that escalation is the live case for most manufacturers today. Publishing the technical documentation buys a FOSS manufacturer out of it.

#### When do these obligations start to apply?
Article 71(2) sets the calendar. The Regulation applies from 11 December 2027. Article 14, covering reporting of actively exploited vulnerabilities and severe incidents, applies earlier, from 11 September 2026. Chapter IV, Articles 35 to 51 on notifying conformity assessment bodies, applies from 11 June 2026.

For a steward the practical consequence is a split. The Article 24(3) reporting duties follow Article 14 and bite from 11 September 2026. The cybersecurity policy and cooperation duties in Article 24(1) and (2) bite from 11 December 2027.

Sources:
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Recital 18](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#rct_18). Publications Office of the European Union, Recital 18, CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Recital 19](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#rct_19). Publications Office of the European Union, Recital 19, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Recital 20](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#rct_20). Publications Office of the European Union, Recital 20, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 3 (Definitions)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_3). Publications Office of the European Union, Article 3, points (14) and (48), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 13 (Obligations of manufacturers)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_13). Publications Office of the European Union, Article 13(5) and (6), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 24 (Obligations of open-source software stewards)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_24). Publications Office of the European Union, Article 24(1) to (3), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 25 (Security attestation of free and open-source software)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_25). Publications Office of the European Union, Article 25, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 32 (Conformity assessment procedures)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_32). Publications Office of the European Union, Article 32(1), (2) and (5), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 64 (Penalties)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_64). Publications Office of the European Union, Article 64(10), point (b), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 71 (Entry into force and application)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_71). Publications Office of the European Union, Article 71(2), CELEX:32024R2847
- [Commission guidance on the application of Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)](https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation). European Commission, Section 3, free and open-source software, points 44 to 89, C(2026) 5252 final, Final, adopted 27 July 2026 (non-binding)
- [Cyber Resilience Act implementation, frequently asked questions](https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions). European Commission services, Sections 1 and 2, scope and exemptions, Version 1.3, 2 July 2026 (non-binding)
- [ORC WG CRA Hub, stewards FAQ](https://github.com/orcwg/cra-hub/tree/main/faq/stewards). Open Regulatory Compliance Working Group (non-binding)

### Does the CRA cover my web application?
URL: https://cvdportal.com/faq/does-the-cra-cover-my-web-application
Last reviewed: 2026-07-27
Verified against: Regulation (EU) 2024/2847 Articles 2, 3 and 24 and recitals 11 and 12 as published in OJ L, 20.11.2024, and Commission guidance C(2026) 5252 final of 27 July 2026, points 17 to 24.

Generally no. Commission guidance confirms that software which executes remotely and is merely accessed by the user is not, on that basis alone, a product with digital elements. A web application reached exclusively through a browser therefore falls outside the CRA, as does a website that only presents information. Two things pull you back in. Shipping a client that users install and run locally is in scope, even where it is built with web technologies. And your backend enters scope where it supports a function of some other product.

Falling outside the CRA does not mean falling outside EU cybersecurity law. NIS2 covers cloud computing service providers, and DORA covers financial entities and their ICT providers.

| Fact | Value |
| --- | --- |
| Browser-only web app | Not a product with digital elements |
| Informational website | Not a product with digital elements |
| Downloadable or installed client | In scope, even if built with web technologies |
| Backend supporting another product | In scope as remote data processing |
| Source | Guidance C(2026) 5252 points 20 to 21, Examples 3 to 6 |

#### Where the line sits
Article 3(1) defines a product with digital elements as a software or hardware product and its remote data processing solutions. Commission guidance C(2026) 5252 explains what that requires of software. For software to fall in scope, it must be provided to a user, obtained by that user, and operated on or as part of an electronic information system on the user's side.

Software that executes remotely and is merely accessed by the user does not meet that description. The guidance names web applications, including progressive web apps, where they are accessed exclusively through a web browser. Recitals 11 and 12 support the reading, treating processing at a distance as relevant only to the extent it is necessary for a product to perform its functions.

Websites get the same treatment. Even though a website technically executes to a limited extent on the user's device, recital 12 means websites are not themselves products with digital elements. A site that merely presents information to visitors is outside the CRA even where a product links to it.

#### What pulls you back into scope
The delivery model decides this, and the technology stack does not. A desktop application built using web technologies but packaged for local installation is supplied to the user and executes on the user's device, so it is a product with digital elements. The same applies to a browser extension. A mobile application downloaded from an app store is squarely in scope.

So the common pattern of a browser-based product that also ships a desktop or mobile client splits. The browser-accessed part is out of scope on its own account. The installed client is in scope. Where that client relies on data processing at a distance in order to perform one of its functions, and that software was designed and developed by you or under your responsibility, the processing is part of the product as a remote data processing solution.

That last point catches many teams by surprise. Your backend does not escape the CRA because it lives on a server. It escapes because nothing you place on the market depends on it.

#### The second gate, commercial activity
Scope also requires that the product is made available on the EU market in the course of a commercial activity. The guidance devotes a full section to what that means for free and open-source software, and the tests are decisive rather than cumulative.

Charging a price puts you in. So does monetising other services through the software, or requiring the processing of personal data as a condition of use for reasons beyond security, compatibility or interoperability. Selling optional professional services around software that anyone can download freely does not. Accepting donations generally does not, unless access or updates are in practice conditioned on donating.

Where free and open-source software is published but not placed on the market, the publisher may still be an open-source software steward under Article 24, with a narrower and graduated set of obligations.

#### What applies instead
A browser-only web application sits outside the CRA and inside other regimes. Recital 12 of the CRA itself points to Directive (EU) 2022/2555, which establishes cybersecurity risk-management requirements for cloud computing service providers, further specified by Implementing Regulation (EU) 2024/2690.

Financial entities and their ICT service providers face Regulation (EU) 2022/2554 on digital operational resilience. Any service processing personal data remains subject to the GDPR, including its own breach-notification timetable. The Commission has said it may issue further guidance on how the CRA interacts with the AI Act and with DORA.

The practical step is to establish scope before doing classification work. Determining whether you are in scope at all takes minutes, and it decides whether the Annex III and IV classification exercise is relevant to you.

Sources:
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 2 (Scope)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_2). Publications Office of the European Union, Article 2(1), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 3 (Definitions)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_3). Publications Office of the European Union, Article 3(1) and 3(2), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 24 (Obligations of open-source software stewards)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_24). Publications Office of the European Union, Article 24(1) to (3), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), recitals 11 and 12](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847). Publications Office of the European Union, Recitals 11 and 12, CELEX:32024R2847, OJ L, 20.11.2024
- [Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, points 17 to 24 and 40 to 68](https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation). European Commission, C(2026) 5252 (non-binding)
- [Commission Implementing Regulation (EU) 2024/2690 laying down rules for the application of Directive (EU) 2022/2555 as regards cloud computing service providers and others](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj). Publications Office of the European Union, Article 1 and the Annex, CELEX:32024R2690

### Is my software update a substantial modification under the CRA?
URL: https://cvdportal.com/faq/is-my-software-update-a-substantial-modification
Last reviewed: 2026-07-27
Verified against: Regulation (EU) 2024/2847 Articles 3(30), 21 and 22 and recitals 39 and 41 as published in OJ L, 20.11.2024, and Commission guidance C(2026) 5252 final of 27 July 2026, points 90 to 124.

Ask four questions from Commission guidance point 110. Does the update introduce new threat vectors, enable new attack scenarios, change the likelihood of previously identified attack scenarios, or change their impact? Where all four are negative and the assumptions in your risk assessment still hold, the update is unlikely to be substantial. Any single yes makes it substantial, as does a change to the intended purpose the product was assessed against. The size of the change is irrelevant.

A substantially modified product is newly placed on the market, which triggers a fresh conformity assessment and its own declared support period. Conformity work may focus on the modified parts where the change does not harm the product's cybersecurity as a whole.

| Fact | Value |
| --- | --- |
| Definition | CRA Article 3(30) |
| Test | Four factors, guidance C(2026) 5252 point 110 |
| Scale | Not a factor. A small change can be substantial |
| Security updates | Generally not substantial, unless they alter intended purpose or dependencies |
| Consequence | Newly placed on the market, needs its own support period |

#### The four-factor test
Article 3(30) defines a substantial modification as a change after placing on the market which affects compliance with the Annex I Part I essential requirements, or results in a modification to the intended purpose the product was assessed for. Commission guidance C(2026) 5252 point 110 turns that into four questions a manufacturer can actually apply.

Does the update introduce new threat vectors, such as additional interfaces, communication channels, execution environments or external dependencies? Does it enable new attack scenarios? Does it change the likelihood of previously identified attack scenarios, for example by lowering the effort required to exploit them or weakening existing safeguards? Does it change their potential impact, including the scope of affected data or functions, or the ability to detect, contain or recover from an incident?

The negative branch is cumulative. All four must be negative and the assumptions and mitigation measures relied on in the risk assessment must remain valid and effective.

#### Why the size of the change does not matter
Point 107 is explicit that the assessment turns on the potential adverse impact on the product's cybersecurity risk profile rather than on the scale or complexity of the change. The guidance illustrates this in both directions.

Adding a persistent login feature that stores authentication tokens locally is a substantial modification, because it introduces risks of token theft, unauthorised access and session hijacking that the risk assessment never considered. A diagnostics feature that exports detailed logs is substantial where it results in sensitive operational data being stored unencrypted.

In the other direction, enabling automated control features that were present in the architecture but shipped disabled, and whose activation the risk assessment already covered together with its safeguards, is not a substantial modification. Neither is adding group messaging to a messaging application where the original risk assessment anticipated it.

#### The security-update carve-out and its limits
Recital 39 and guidance point 108 treat security updates as generally not substantial modifications, because their purpose is to reduce risk. Tightening firewall rules, disabling unused ports, changing default password policies, making multi-factor authentication mandatory where it already existed, and disabling a deprecated cryptographic algorithm in favour of one already supported and assessed all fall inside the carve-out, even where the technical change is significant.

The carve-out is conditional. It falls away where the update alters the intended purpose or the dependency structure. Replacing local file encryption with a remote encryption service operated by the manufacturer is a substantial modification despite its security motive, because the product no longer does what it was assessed to do. So is swapping an internally managed key lifecycle for a third-party key management service, because it introduces new external interfaces and reliance not considered in the risk assessment.

#### What follows from a substantial verdict
A substantially modified product made available on the market is treated as a new product, and making it available is a new placing on the market. The original manufacturer stays the manufacturer, but a fresh conformity assessment is owed.

That assessment is proportionate. Existing documentation and test results may be reused for parts the modification did not touch, and a third-party assessment should focus on the modified parts. Where someone other than the original manufacturer carries out the modification, Article 22 makes them the manufacturer, and their Article 13 and 14 obligations extend only to the modified part where the change does not harm the product's cybersecurity as a whole.

The support period needs re-deriving rather than resetting. Each substantially modified version needs its own declared period under Article 13(8), but a substantial modification does not automatically reset or extend it. The question is whether the modification changed the factors that set the expected use time.

Sources:
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 3 (Definitions)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_3). Publications Office of the European Union, Article 3(30), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 22 (Cases in which obligations of manufacturers apply to other persons)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_22). Publications Office of the European Union, Article 22, CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), recitals 39 and 41](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847). Publications Office of the European Union, Recitals 39 and 41, CELEX:32024R2847, OJ L, 20.11.2024
- [Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, points 90 to 124 and 208](https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation). European Commission, C(2026) 5252 (non-binding)
- [Commission notice, The 'Blue Guide' on the implementation of EU product rules 2022, Section 2.1](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52022XC0629(04)). European Commission, 2022/C 247/01 (non-binding)

### Is there a CRA harmonised standard for my product category yet?
URL: https://cvdportal.com/faq/is-there-a-cra-harmonised-standard-for-my-product-category
Last reviewed: 2026-07-29
Verified against: Regulation (EU) 2024/2847 as published in OJ L, 20.11.2024, read at EUR-Lex on 29 July 2026, with the vertical standard list and draft stages checked against the ETSI CYBER-EUSR open consultation area and the Commission standardisation page on the same date

A draft or a work item exists for every Annex III category, and none of it is cited in the Official Journal, so the Article 27 presumption of conformity is unavailable for every product category without exception. Standardisation request M/606 splits into horizontal standards covering all products and vertical standards covering one category each. ETSI drafts most verticals as the EN 304 6xx series, where the number is 304 600 plus the mandate line item. CEN and CENELEC hold the semiconductor, smartcard, identity and metering categories.

Knowing which committee drafts your category tells you which work programme to watch. It does not change your conformity assessment route today, because nothing in either family is cited.

| Fact | Value |
| --- | --- |
| Standardisation request | M/606, Commission Implementing Decision C(2025) 618 final |
| Vertical standards at ETSI | 18 deliverables, EN 304 617 to EN 304 642 |
| Numbering rule | Deliverable number is 304 600 plus the M/606 line item |
| Drafting body for most verticals | ETSI TC CYBER, EUSR group |
| Annex III and IV points outside ETSI | Nine, held by CEN/TC 224, CLC/TC 47X and CEN-CLC/JTC 13 WG 6 |
| Cited in the Official Journal | None, as at 29 July 2026 |

#### Horizontal and vertical standards under M/606
Article 27(1) obliges the Commission to request harmonised standards for the Annex I essential requirements. It did so through standardisation request M/606, issued by Commission Implementing Decision C(2025) 618 final and accepted by CEN, CENELEC and ETSI on 3 April 2025. The request covers 41 standards.

They divide into two kinds, and the distinction decides which work programme is relevant to you.

Horizontal standards apply to every product with digital elements and express the essential requirements in general terms. That is the [EN 40000 series](/standards/en-40000) from CEN-CENELEC JTC 13, covering vocabulary, cyber resilience principles, vulnerability handling and generic security requirements.

Vertical standards cover one Annex III product category each. Most went to ETSI TC CYBER, which is drafting them as the EN 304 6xx series. A manufacturer of an important product will likely need both families: the horizontal standards for the general requirements and the vulnerability handling process, and the vertical standard for what that specific product type has to do.

#### Which deliverable covers your category
The ETSI numbering is mechanical rather than arbitrary. A deliverable number is 304 600 plus its M/606 line item, so line item 17 for standalone and embedded browsers becomes EN 304 617, and line item 36 for firewalls and intrusion detection or prevention systems becomes EN 304 636.

That rule explains the gaps. There is no EN 304 628, 629 or 630 because those line items cover microprocessors, microcontrollers and programmable circuits with security functionalities, which went to CENELEC rather than ETSI.

The categories ETSI is not covering are worth knowing early, because watching the ETSI work programme will tell a manufacturer in one of them nothing at all:

- Identity management and privileged access management, at CEN/TC 224 WG 17.
- Microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities, and their tamper-resistant variants, at CENELEC CLC/TC 47X.
- All three Annex IV critical categories: hardware devices with security boxes, smart meter gateways, and smartcards including secure elements.

The [full mapping from every Annex III and Annex IV point to its standard](/standards/etsi-en-304) sets out which committee holds each one.

#### What a draft vertical standard changes, and what it does not
Article 27(1) attaches the presumption to harmonised standards, or parts of them, the references of which have been published in the Official Journal of the European Union. A draft confers nothing under that article, however closely a product follows it and however advanced the draft is.

That matters most for Annex III Class I products. Article 32(2) removes the module A self-assessment option where the manufacturer has not applied, or has applied only in part, harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial, or where such standards do not exist. With nothing cited, the final limb is satisfied today for every category, so third-party assessment through module B and C or module H is the live route. Article 32(3) puts Class II products there regardless.

What a public draft does buy is a preview of the requirements. Several ETSI deliverables are open for comment, so a manufacturer can read what its category will be measured against and build the evidence now rather than after citation.

#### Six product types are being standardised twice
Firewalls, network management systems, physical and virtual network interfaces, VPN products, routers and switches, and SIEM systems each have two deliverables in progress. Alongside the ETSI vertical, CENELEC CLC/TC 65X WG 3 is drafting the prEN 50770 series on IEC 62443 foundations, aimed at operational technology.

The overlap is deliberate rather than accidental. The M/606 wording for the firewall line item reaches products intended for industrial use explicitly, and industrial deployments of these product types have a different threat model and a different installed base than their IT equivalents.

For a manufacturer selling the same product into both IT and OT markets, this may eventually become a choice of which standard to apply, or a need to satisfy both. Neither track is cited in the Official Journal, so it is a decision to revisit once citations appear rather than one to make now. What is worth doing today is reading whichever draft is closer to your market, since the underlying engineering will carry across either way.

Sources:
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 27 (Presumption of conformity)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_27). Publications Office of the European Union, Article 27(1), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 32 (Conformity assessment procedures)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_32). Publications Office of the European Union, Article 32(2) and (3), CELEX:32024R2847
- [Commission Implementing Decision on a standardisation request to CEN, CENELEC and ETSI in support of Regulation (EU) 2024/2847](https://digital-strategy.ec.europa.eu/en/policies/cra-standardisation). European Commission, Standardisation request M/606, Annex I, C(2025) 618 final, request M/606
- [Cyber Resilience Act, standardisation](https://digital-strategy.ec.europa.eu/en/policies/cra-standardisation). European Commission, DG CONNECT, Scope of request M/606 and the split between horizontal and vertical standards, As published, July 2026 (non-binding)
- [ETSI TC CYBER EUSR open consultation area, draft EN 304 6xx vertical standards for the Cyber Resilience Act](https://docbox.etsi.org/CYBER/EUSR/Open/). ETSI, EN 304 617 to EN 304 642, Drafts at mature, enquiry and final draft stage, none cited in the Official Journal (non-binding)
- [prEN 50770 series, security for operational technologies, and the prEN 50764 to prEN 50766 semiconductor deliverables](https://www.cencenelec.eu/areas-of-work/cen-cenelec-topics/cybersecurity-and-data-protection/). CENELEC, CLC/TC 65X WG 3 and CLC/TC 47X, prEN 50770-1 to prEN 50770-6, prEN 50764, prEN 50765, prEN 50766 (non-binding)

### What do I actually have to do to comply with the Cyber Resilience Act?
URL: https://cvdportal.com/faq/what-do-i-actually-have-to-do-to-comply-with-the-cra
Last reviewed: 2026-07-27
Verified against: The final text of Regulation (EU) 2024/2847 as published in OJ L, 20.11.2024, read at EUR-Lex on 27 July 2026

Compliance runs as an ordered sequence where each step feeds the next. Confirm the product is in scope and that you are its manufacturer, then classify it as default, Annex III important class I or II, or Annex IV critical. Run the Article 13(2) risk assessment, which determines which Annex I Part I requirements apply. Build to those, meet the Part II vulnerability handling requirements, compile Article 31 technical documentation, complete the Article 32 conformity assessment, draw up the EU declaration of conformity, affix the CE marking, and report under Article 14.

The order matters. The risk assessment sets the scope of everything downstream, and the conformity assessment route depends on the classification settled before it.

| Fact | Value |
| --- | --- |
| Gateway condition | Article 6, Annex I Part I for the product and Part II for your processes |
| What sets the scope | The Article 13(2) risk assessment |
| Where the evidence lives | Technical documentation, Article 31 and Annex VII |
| Support period | At least five years, or expected use time if shorter (Article 13(8)) |
| Reporting starts | 11 September 2026 (Article 14) |
| Everything else starts | 11 December 2027 |

#### Step 1. Confirm you are in scope, and in which role
Article 6 states the gateway condition. Products with digital elements may be made available on the market only where they meet the Annex I Part I essential cybersecurity requirements, provided they are properly installed, maintained and used for their intended purpose or under reasonably foreseeable conditions, and where the processes put in place by the manufacturer comply with Annex I Part II.

Two checks come before anything else.

Is the product excluded? Article 2 carves out products already covered by sectoral Union law, including medical devices under Regulations (EU) 2017/745 and 2017/746, motor vehicles under Regulation (EU) 2019/2144, civil aviation under Regulation (EU) 2018/1139 and marine equipment under Directive 2014/90/EU.

Are you the manufacturer? The obligations in this answer are Article 13 manufacturer obligations. Importers carry Article 19 duties and distributors Article 20 duties, which are verification rather than construction obligations. Article 21 pulls an importer or distributor into the manufacturer's shoes where they place a product on the market under their own name or trademark, and Article 22 does the same in other cases including substantial modification.

Free and open source software supplied outside a commercial activity sits outside scope, and open-source software stewards fall under the lighter Article 24 regime instead of Article 13.

#### Step 2. Classify the product
Classification decides the conformity assessment route later, so it is settled early even though nothing is produced at this stage.

There are four tiers.

1. Default. Any product with digital elements not listed elsewhere. Self-assessment is available.
2. Important, Annex III class I, under Article 7.
3. Important, Annex III class II, under Article 7.
4. Critical, Annex IV, under Article 8, where the Commission is empowered to require a European cybersecurity certification scheme.

The practical effect appears at Article 32. A class I product may use self-assessment only where harmonised standards, common specifications or a certification scheme have been fully applied. Otherwise it escalates to third-party assessment. A class II product goes to third-party assessment regardless.

Since no CRA harmonised standard has been cited in the Official Journal, the escalation limb currently bites for class I products. The [EN 40000 timing question](/faq/do-i-have-to-wait-for-the-en-40000-standards) covers what that means for budget and scheduling.

An implementing act adopted on 28 November 2025 sets out technical descriptions of the Annex III and Annex IV categories. That is the document to read when a product sits near a boundary.

#### Step 3. Run the risk assessment, because it scopes everything after it
Article 13(2) requires an assessment of the cybersecurity risks associated with the product, whose outcome is taken into account during planning, design, development, production, delivery and maintenance.

This is the pivot of the whole sequence. Annex I Part I point (2) opens with the words "On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable", so the security requirements listed there are conditional, and the assessment is what establishes which apply. Article 13(4) then requires a clear justification in the technical documentation for every essential requirement treated as not applicable.

Article 13(3) sets the minimum content and requires the assessment to be documented and updated as appropriate across the support period. It also has to indicate how the manufacturer applies Annex I Part I point (1) and the Part II vulnerability handling requirements.

Running this step late is the most expensive sequencing error available, because a requirement discovered as applicable after design is frozen is a redesign rather than a document change. The [full risk assessment requirements](/faq/what-does-the-cra-require-in-a-risk-assessment) go through it provision by provision.

#### Step 4. Build to Annex I, both parts
Annex I has two halves and they are commonly treated as one.

Part I is about the product. Point (1) requires products to be designed, developed and produced so as to ensure an appropriate level of cybersecurity based on the risks. Point (2) lists the specific security properties, applicable on the basis of the risk assessment, running from (a) to (m) and covering release without known exploitable vulnerabilities, secure by default configuration, security updates, access protection, confidentiality and integrity of data, data minimisation, availability, attack surface reduction, exploitation mitigation, logging and monitoring, and secure removal of data.

Part II is about your processes, and it applies whatever the risk assessment says. It requires identifying and documenting vulnerabilities and components including an SBOM covering at least top-level dependencies, remediating without delay through security updates, applying effective and regular testing, publicly disclosing fixed vulnerabilities with descriptions and remediation information, putting a coordinated vulnerability disclosure policy in place, providing a contact address for reporting, and distributing security updates without delay and free of charge.

Part II is where a coordinated vulnerability disclosure capability stops being good practice and becomes a legal requirement, and it is the part with the longest lead time to build.

#### Step 5. Compile the technical documentation
Article 31 requires technical documentation containing all relevant data and details of the means used to demonstrate conformity with the essential requirements, drawn up before the product is placed on the market and kept up to date. Its elements are set out in Annex VII.

Article 13(4) requires the cybersecurity risk assessment to be included in it, along with a clear justification wherever an essential requirement is treated as not applicable.

Annex II is separate and often confused with it. That is the information and instructions supplied to the user, and it includes the manufacturer's contact details, the single point of contact for vulnerability reports and where the CVD policy can be found, the intended purpose and security properties, any known or foreseeable circumstance related to intended use or reasonably foreseeable misuse that may lead to significant cybersecurity risks, the technical security support offered, and the end date of the support period.

Microenterprises and small enterprises get relief on form rather than substance. Article 33(5) allows them to provide all Annex VII elements using a simplified format specified by the Commission, and notified bodies must accept it.

#### Step 6. Conformity assessment, declaration, CE marking
Article 32(1) offers four routes: internal control based on module A, EU-type examination based on module B followed by conformity to type based on module C, full quality assurance based on module H, or a European cybersecurity certification scheme under Article 27(9) where available and applicable. Which are open to you was decided by the classification in step 2.

Article 28 then requires the manufacturer to draw up the EU declaration of conformity, stating that fulfilment of the applicable Annex I essential requirements has been demonstrated. It follows the model structure in Annex V, contains the elements specified in the relevant Annex VIII procedure, and is updated as appropriate.

CE marking comes last. Article 29 applies the general principles of the CE marking, and Article 30 sets the rules and conditions for affixing it.

The order is load-bearing. The CE marking asserts that the preceding steps happened, so affixing it before the documentation and the declaration exist is the failure mode market surveillance authorities are equipped to detect.

#### Step 7. The obligations that begin when you ship
Compliance is not discharged at placing on the market. Three duties run afterwards.

The support period. Article 13(8) requires the manufacturer to determine it so that it reflects how long the product is expected to be in use, taking into account reasonable user expectations, the nature and intended purpose of the product, and relevant Union law. It carries a floor: the support period shall be at least five years, and where the product is expected to be in use for less than five years, it corresponds to the expected use time.

Vulnerability handling. The Annex I Part II process obligations run across that whole period, including remediation through security updates and public disclosure of fixed vulnerabilities.

Reporting. Article 14 requires notification of actively exploited vulnerabilities and severe incidents to a coordinating CSIRT and ENISA through the single reporting platform, on a 24 hour, 72 hour and final report cadence, plus a separate duty under Article 14(8) to inform impacted users. The [CSIRT routing and platform mechanics](/faq/which-csirt-do-i-report-to-under-the-cra) work through the operational side.

#### What is due when
Article 71(2) splits the calendar three ways. Chapter IV, Articles 35 to 51 on notifying conformity assessment bodies, applies from 11 June 2026. Article 14 reporting applies from 11 September 2026. Everything else applies from 11 December 2027.

The sequencing consequence is that reporting arrives first, roughly 15 months ahead of the design and conformity obligations, and it reaches further. Article 69(2) generally exempts products placed on the market before 11 December 2027 unless they are substantially modified, and Article 69(3) derogates from that specifically for Article 14.

So an existing product line needs a working reporting capability well before it needs a technical file. Building steps 1 to 6 in order remains right for anything new, and step 7's reporting duty is the one with the nearest deadline.

Sources:
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 6 (Requirements for products with digital elements)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_6). Publications Office of the European Union, Article 6, points (a) and (b), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 2 (Scope)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_2). Publications Office of the European Union, Article 2(2) to (7), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 7 (Important products with digital elements)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_7). Publications Office of the European Union, Article 7, with Annex III, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 8 (Critical products with digital elements)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_8). Publications Office of the European Union, Article 8, with Annex IV, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 13 (Obligations of manufacturers)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_13). Publications Office of the European Union, Article 13(2), (3), (4) and (8), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 (Reporting obligations of manufacturers)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_14). Publications Office of the European Union, Article 14(1) to (8), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 19 to 22 (Importers, distributors, and cases where manufacturer obligations apply)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_21). Publications Office of the European Union, Articles 19, 20, 21 and 22, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 28 (EU declaration of conformity)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_28). Publications Office of the European Union, Article 28(1) and (2), with Annex V, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 29 (General principles of the CE marking)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_29). Publications Office of the European Union, Article 29, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 30 (Rules and conditions for affixing the CE marking)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_30). Publications Office of the European Union, Article 30, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 31 (Technical documentation)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_31). Publications Office of the European Union, Article 31, with Annex VII, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 32 (Conformity assessment procedures)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_32). Publications Office of the European Union, Article 32(1), (2) and (3), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 33 (Support measures for microenterprises and SMEs)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_33). Publications Office of the European Union, Article 33(5), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 69 (Transitional provisions)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_69). Publications Office of the European Union, Article 69(2) and (3), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 71 (Entry into force and application)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_71). Publications Office of the European Union, Article 71(2), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I (Essential cybersecurity requirements)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#anx_I). Publications Office of the European Union, Annex I, Parts I and II, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex II (Information and instructions to the user)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#anx_II). Publications Office of the European Union, Annex II, points 1 to 7, CELEX:32024R2847
- [Commission Implementing Regulation on the technical description of the important and critical product categories in Annexes III and IV](https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation). European Commission, Technical descriptions of Annex III and Annex IV categories, Implementing Regulation (EU) 2025/2392

### What documents and reports does the Cyber Resilience Act require me to produce?
URL: https://cvdportal.com/faq/what-documents-does-the-cra-require-me-to-produce
Last reviewed: 2026-07-27
Verified against: The final text of Regulation (EU) 2024/2847 as published in OJ L, 20.11.2024, read at EUR-Lex on 27 July 2026

The Cyber Resilience Act requires six artefacts. Technical documentation under Article 31 and Annex VII, which contains the risk assessment. An EU declaration of conformity under Article 28 and Annex V. A software bill of materials and a coordinated vulnerability disclosure policy, both under Annex I Part II. Information and instructions to the user under Annex II. Then the Article 14 filings once reporting begins. Technical documentation and the declaration are kept available to market surveillance authorities for at least 10 years or the support period, whichever is longer.

Only the Annex II user information and the CE marking travel with the product. Everything else is held and produced on request, which is why the retention rule matters as much as the drafting.

| Fact | Value |
| --- | --- |
| Technical documentation | Article 31 and Annex VII, includes the risk assessment |
| EU declaration of conformity | Article 28 and Annex V |
| SBOM | Annex I Part II(1), machine-readable, top-level dependencies minimum |
| CVD policy | Annex I Part II(5), plus a reporting contact address |
| User information | Annex II, supplied with the product |
| Retention | At least 10 years, or the support period if longer |

#### Technical documentation, the file everything else feeds
Article 31 requires technical documentation containing all relevant data and details of the means used to demonstrate conformity with the essential requirements, drawn up before the product is placed on the market and kept up to date.

Annex VII sets the contents, and it is broader than a design dossier. It requires:

1. A general description of the product, covering its intended purpose, the software versions affecting compliance, photographs or illustrations of external features, marking and internal layout for hardware, and the Annex II user information.
2. A description of design, development and production and of the vulnerability handling processes. This is where the software bill of materials, the coordinated vulnerability disclosure policy, evidence of a reporting contact address and a description of the secure update distribution mechanism all live.
3. An assessment of the cybersecurity risks the product is designed, developed, produced, delivered and maintained against, pursuant to Article 13.

Two consequences follow. The SBOM and the CVD policy are Annex I obligations in their own right, and they are also line items in the technical file, so producing them without filing them leaves the file incomplete. And Article 13(4) requires the risk assessment to be included here, along with a clear justification wherever an essential requirement is treated as not applicable.

#### The EU declaration of conformity
Article 28 requires the manufacturer to draw up the EU declaration of conformity, stating that fulfilment of the applicable Annex I essential requirements has been demonstrated. It follows the model structure in Annex V, carries the elements specified in the relevant Annex VIII conformity assessment procedure, and is updated as appropriate.

Annex V lists what it must contain, including the name and type and any additional information uniquely identifying the product, the name and address of the manufacturer or authorised representative, a statement that the declaration is issued under sole responsibility, the object of the declaration allowing traceability, a statement of conformity with the relevant Union harmonisation legislation, and references to any harmonised standards, common specifications or cybersecurity certification relied on.

That last element is the one to watch. It records which standards you leaned on, and since no CRA harmonised standard is yet cited in the Official Journal, most declarations drawn up today will have nothing to put there. The [EN 40000 timing question](/faq/do-i-have-to-wait-for-the-en-40000-standards) covers what that means for the assessment route.

Article 13(12) sequences it. Once the conformity assessment procedure has demonstrated compliance, the manufacturer draws up the declaration under Article 28 and affixes the CE marking under Article 30.

#### The SBOM and the disclosure policy
Both come from Annex I Part II, the process half of the essential requirements, and both apply regardless of what the risk assessment concludes.

Part II point (1) requires manufacturers to identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product.

Two details in that wording carry weight. Machine-readable rules out a spreadsheet of component names, which points at SPDX or CycloneDX. And top-level dependencies is a floor rather than a target, so deeper transitive coverage is permitted and often necessary to answer a vulnerability question quickly.

Part II point (5) requires a policy on coordinated vulnerability disclosure to be put in place and enforced. Point (4) requires public disclosure of fixed vulnerabilities once a security update is available, including a description, information letting users identify affected products, the impacts, the severity, and clear information helping users remediate. Where a manufacturer judges the security risks of publication to outweigh the benefits, publication may be delayed in duly justified cases until users have had the chance to apply the patch.

Annex II point 2 then requires the single point of contact for vulnerability reports, and where the CVD policy can be found, to be supplied with the product.

#### Annex II, the only document that ships with the product
Annex VII is held for authorities. Annex II goes to users, and the two are regularly confused.

Annex II requires the product to be accompanied, at minimum, by the manufacturer's name and contact details, the single point of contact for vulnerability reports and where the CVD policy can be found, information uniquely identifying the product, the intended purpose including the security environment provided by the manufacturer and the product's essential functionalities and security properties, any known or foreseeable circumstance related to intended use or reasonably foreseeable misuse that may lead to significant cybersecurity risks, where applicable the internet address for the EU declaration of conformity, and the type of technical security support offered with the end date of the support period.

Article 13 sets the quality bar and the retention. The information and instructions must be in a language easily understood by users and market surveillance authorities, and be clear, understandable, intelligible and legible. They are kept at the disposal of users and market surveillance authorities for at least 10 years after the product is placed on the market, or for the support period, whichever is longer.

Publishing the support period end date here is the commitment most manufacturers underestimate, because it fixes in public the date their Annex I Part II obligations stop.

#### The reports you file rather than hold
Everything above is produced once and maintained. The Article 14 reports are events.

For an actively exploited vulnerability: an early warning within 24 hours, 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: 24 hours, 72 hours, and a final report within one month of the 72-hour notification. All filed through the ENISA single reporting platform to a coordinating CSIRT, and simultaneously accessible to ENISA.

Article 14(8) adds a communication to users, which where appropriate should be in a structured, machine-readable format that is easily automatically processable. That clause is the practical case for issuing a CSAF advisory rather than a prose bulletin.

The [CSIRT routing and platform mechanics](/faq/which-csirt-do-i-report-to-under-the-cra) work through who receives these and how. Note also that where the same event engages NIS2 or GDPR, those regimes require their own separate filings on their own clocks.

#### Who can ask, and how long you keep it
The retention rules are separate obligations and they outlive the support period.

Article 13(13) requires manufacturers to keep the technical documentation and the EU declaration of conformity at the disposal of market surveillance authorities for at least 10 years after the product has been placed on the market, or for the support period, whichever is longer.

The same 10-year-or-support-period rule applies to the Annex II information and instructions, held at the disposal of users as well as authorities.

Article 13(9) runs a different clock that is easy to misread. Each security update made available during the support period must remain available after it has been issued for a minimum of 10 years, or for the remainder of the support period, whichever is longer. The clock starts when the update is issued, not when the product was placed on the market, so an update shipped in year eight of a product's life has to stay available into year eighteen.

Market surveillance authorities are the audience with a right of access, under the Chapter V powers. Notified bodies see the documentation where a third-party conformity assessment route applies. Users receive Annex II and the security updates.

#### What actually satisfies an authority
Two structural features of the Regulation decide whether a document set holds up.

It has to be current. Article 31 requires the technical documentation to be kept up to date, and Article 13(3) requires the risk assessment to be documented and updated as appropriate during the support period. A file that reflects the product as launched, on a product that has shipped eleven releases since, is a file that no longer describes the product on the market.

It has to explain its own gaps. Article 13(4) requires a clear justification in the technical documentation wherever an essential cybersecurity requirement is not applicable. Since Annex I Part I point (2) applies its requirements only on the basis of the risk assessment and where applicable, the exclusions are as load-bearing as the inclusions, and an unexplained absence reads as an omission.

There is one form-level concession. Article 33(5) allows microenterprises and small enterprises to supply all Annex VII elements using a simplified format specified by the Commission in an implementing act, and notified bodies have to accept it. It changes the form, and the substance is unchanged.

Sources:
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 13 (Obligations of manufacturers)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_13). Publications Office of the European Union, Article 13(3), (4), (9), (12), (13) and (18), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 28 (EU declaration of conformity)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_28). Publications Office of the European Union, Article 28(1) and (2), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 31 (Technical documentation)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_31). Publications Office of the European Union, Article 31, with Annex VII, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 (Reporting obligations of manufacturers)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_14). Publications Office of the European Union, Article 14(2), (4) and (8), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 33 (Support measures for microenterprises and SMEs)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_33). Publications Office of the European Union, Article 33(5), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I (Essential cybersecurity requirements)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#anx_I). Publications Office of the European Union, Annex I Part II, points (1), (4) and (5), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex II (Information and instructions to the user)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#anx_II). Publications Office of the European Union, Annex II, points 1 to 7, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex V (EU declaration of conformity)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#anx_V). Publications Office of the European Union, Annex V, points 1 to 6, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex VII (Technical documentation)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#anx_VII). Publications Office of the European Union, Annex VII, points 1 to 3, CELEX:32024R2847
- [Common Security Advisory Framework (CSAF) Version 2.0](https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html). OASIS Open, OASIS Standard, CSAF 2.0 (non-binding)
- [SPDX (ISO/IEC 5962) and CycloneDX, machine-readable SBOM formats](https://spdx.dev/). Linux Foundation and OASIS Open, ISO/IEC 5962:2021 (SPDX), CycloneDX (non-binding)
- [BSI TR-03183 Part 2, Software Bill of Materials (SBOM)](https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html). Bundesamt für Sicherheit in der Informationstechnik, BSI TR-03183-2 (non-binding)

### What does the Cyber Resilience Act require in a cybersecurity risk assessment?
URL: https://cvdportal.com/faq/what-does-the-cra-require-in-a-risk-assessment
Last reviewed: 2026-07-27
Verified against: The final text of Regulation (EU) 2024/2847 as published in OJ L, 20.11.2024, read at EUR-Lex on 27 July 2026

Article 13(2) of the Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers to assess the cybersecurity risks of a product with digital elements and to carry the outcome through the planning, design, development, production, delivery and maintenance phases. Article 13(3) requires that assessment to be documented, kept updated across the support period, and to state which Annex I Part I point 2 requirements apply and how they are met. It forms part of the technical documentation under Article 31 and Annex VII, and the duty applies from 11 December 2027.

Products placed on the market before 11 December 2027 sit outside that duty unless they undergo a substantial modification, although the Article 14 reporting obligations still reach them.

| Fact | Value |
| --- | --- |
| Governing provision | Article 13(2) to (4) |
| What it drives | Annex I Part I, points (1) and (2) |
| Where it is filed | Technical documentation, Article 31 and Annex VII |
| Update cadence | Documented and updated as appropriate across the support period |
| Legacy products | Out of scope unless substantially modified (Article 69(2)) |
| Methodology | Not prescribed. The Regulation names no framework |

#### What exactly does Article 13 require?
Article 13(1) obliges manufacturers to ensure a product with digital elements has been designed, developed and produced in accordance with the essential cybersecurity requirements in Annex I Part I. The risk assessment is the mechanism for doing that.

Article 13(2) requires manufacturers to undertake an assessment of the cybersecurity risks associated with the product and to take the outcome into account during the planning, design, development, production, delivery and maintenance phases, with a view to minimising cybersecurity risks, preventing incidents and minimising their impact, including in relation to the health and safety of users.

Article 13(3) sets the minimum content. The assessment has to comprise at least an analysis of cybersecurity risks based on the intended purpose and reasonably foreseeable use, as well as the conditions of use, such as the operational environment or the assets to be protected, taking into account how long the product is expected to be in use. It then has to do three specific jobs:

1. Indicate whether, and if so in what manner, the security requirements in Annex I Part I point (2) apply to the product, and how those requirements are implemented as informed by the assessment.
2. Indicate how the manufacturer applies Annex I Part I point (1), the general obligation to ensure an appropriate level of cybersecurity based on the risks.
3. Indicate how the manufacturer applies the vulnerability handling requirements in Annex I Part II.

That third job is the one most summaries drop. The risk assessment reaches the vulnerability handling side of Annex I, not only the product properties in Part I.

#### How does the assessment decide which Annex I requirements apply?
This is the part that changes how the work is scoped. Annex I Part I point (2) opens with the words "On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable", and then lists the product security requirements from (a) to (m).

So the requirements in point (2) are conditional. The risk assessment is what establishes which of them apply to a given product and how. Article 13(4) closes the loop. Where certain essential cybersecurity requirements are not applicable, the manufacturer has to include a clear justification to that effect in the technical documentation.

Annex I Part I point (1) works differently. It requires products to be designed, developed and produced so as to ensure an appropriate level of cybersecurity based on the risks, with no applicability condition attached. The Commission guidance treats point (1) as a catch-all. Where every relevant risk is already treated by measures implementing the other requirements, point (1) is satisfied. Where the assessment surfaces risks the other requirements do not reach, point (1) demands product-level measures for those as well.

The practical consequence is that "which requirements apply to us" is an output of the assessment rather than an input to it, and every exclusion has to be written down and defended.

#### What does the assessment have to cover, and where does misuse come in?
Article 13(3) fixes the scope of the analysis to the intended purpose and reasonably foreseeable use, as well as the conditions of use of the product, such as the operational environment or the assets to be protected, and the expected length of time in use.

Reasonably foreseeable misuse is a defined term in the Regulation. Article 3, point (25) defines it as the use of a product in a way that is not in accordance with its intended purpose, but which may result from reasonably foreseeable human behaviour or technical operations or interactions.

The distinction worth getting right is where that term operates. Misuse does not appear in Article 13(3). It appears in Annex II point 5, which requires the product to be accompanied by any known or foreseeable circumstance, related to use in accordance with the intended purpose or under conditions of reasonably foreseeable misuse, that may lead to significant cybersecurity risks.

In practice the two connect. Annex II point 5 cannot be completed without an assessment that has considered foreseeable misuse, so misuse belongs in the analysis. Attributing the requirement to Article 13(3) misstates the provision, and the New Legislative Framework and the Blue Guide are the wrong citation when the Regulation defines the term itself.

#### Can a manufacturer accept residual risk or pass it to the user?
The phrase "residual risk" does not appear anywhere in the Regulation. The binding requirement is Annex I Part I point (1), an appropriate level of cybersecurity based on the risks, and the Annex II point 5 duty to tell users about circumstances that may lead to significant cybersecurity risks.

The Commission guidance is where the residual risk question is addressed directly, and it is firm. Residual risk is measured against a regulatory threshold rather than against the manufacturer's internal risk appetite. Internal risk tolerance, commercial strategy and cost are irrelevant to whether the essential requirements are met. Residual risk always exists, and a product may be placed on the market only once residual risks are addressed sufficiently to meet the essential requirements. The guidance also states that the CRA does not allow cybersecurity risk or responsibility to be transferred to users or third parties. User information can support secure deployment and inform users of residual risks, and it cannot compensate for design shortcomings. Where identified risks cannot be adequately addressed, compliance may require changing the design, the functionality or the intended purpose, and cost alone is not a ground to leave a risk untreated.

That guidance is interpretive and not binding, so the position is best stated as what the Commission services expect rather than as a rule the Regulation spells out.

#### How must the assessment be documented and kept current?
Article 13(3) requires the assessment to be documented and updated as appropriate during the support period, which Article 13(8) derives from the time the product is expected to be in use, with five years as a floor. That makes it a maintained artefact across the product's supported life.

Article 13(4) requires the manufacturer to include the assessment in the technical documentation required under Article 31 and Annex VII when placing the product on the market. For products covered by Article 12, high-risk AI systems, the cybersecurity risk assessment may form part of the risk assessment required under the other Union act rather than being duplicated.

There is a documentation concession that broad summaries usually miss. Article 33(5) allows microenterprises and small enterprises to provide all elements of the Annex VII technical documentation using a simplified format specified by the Commission in an implementing act, and notified bodies have to accept that form. The concession runs to the form of the documentation. The substance of the assessment is unchanged, so this is not a lighter assessment for smaller manufacturers.

#### How do third-party and open source components fit in?
Two obligations run in parallel and are often collapsed into one.

The Article 13(2) risk assessment covers the product as a whole, including risks that originate outside it such as external networks, the operating environment, and back-end systems the product depends on. The Commission guidance is clear that a manufacturer is not expected to control the external environment, only to mitigate external risks through the product's own design, for example by authenticating remote commands, verifying the integrity of configuration changes, logging abnormal behaviour, or ensuring that an outage of a remote service does not leave the product in an insecure state.

Article 13(5) is separate. It requires due diligence when integrating components sourced from third parties, so those components do not compromise the cybersecurity of the product, and it says so expressly for free and open source components that have not been made available on the market in the course of a commercial activity. Article 13(6) adds that on identifying a vulnerability in an integrated component the manufacturer reports it to whoever maintains that component and remediates it under the Annex I Part II requirements.

One widespread overstatement is worth correcting. A manufacturer is responsible for its own product in its entirety and owes due diligence on what it integrates. The Commission guidance states that manufacturers do not become responsible for an integrated component's own compliance with the Regulation, even where they contribute to its development.

#### Which methodology or standard should be used?
The Regulation names no methodology. Article 13 sets out what the assessment must cover and what it must conclude, and leaves the method to the manufacturer. What the technical documentation has to show is a repeatable process and a defensible result.

Two standard families are the practical anchors.

- The prEN 40000 series, drafted by CEN-CENELEC JTC 13 under Commission standardisation request M/606, is the horizontal set of harmonised standards for the CRA. prEN 40000-1-2 covers the Annex I Part I product security and risk requirements, and prEN 40000-1-3 covers the Annex I Part II vulnerability handling requirements. The parts carry the pr prefix because they are still drafts, and none is yet cited in the Official Journal, so none currently confers a presumption of conformity.
- IEC 62443 comes from industrial automation and control systems. IEC 62443-4-1 covers the secure product development lifecycle and IEC 62443-4-2 covers technical security requirements for components. Neither is a harmonised standard under the CRA, so alignment with them is evidence of a sound process and never a presumption of conformity.

Waiting for the harmonised standards to be cited is the wrong move. Article 32(2) escalates a Class I important product to third-party assessment precisely where the manufacturer has not applied a harmonised standard, a common specification or a certification scheme, or where none exists. Until the EN 40000 parts are cited, that escalation is the live case for most manufacturers of Annex III products.

#### Which products does this reach, and from when?
Article 71(2) sets the calendar. The Regulation applies from 11 December 2027, so the Article 13 risk assessment duty bites on that date. Article 14 applies earlier, from 11 September 2026, and Chapter IV, Articles 35 to 51, from 11 June 2026.

Article 69(2) carries a genuine carve-out that is often reported as though it did not exist. Products placed on the market before 11 December 2027 are subject to the requirements of the Regulation only if, from that date, they undergo a substantial modification. Article 69(3) then overrides that for one obligation. The Article 14 reporting duties apply to all products within scope placed on the market before 11 December 2027 regardless.

Two points of precision follow. The trigger is placing on the market, not when a product was designed. And the exposure on a legacy portfolio is the reverse of the common assumption. Article 13 risk assessment generally does not reach it, while Article 14 reporting does.

Scope exclusions also apply. Article 2 carves out products already covered by sectoral Union law, including medical devices under Regulations (EU) 2017/745 and 2017/746, motor vehicles under Regulation (EU) 2019/2144, civil aviation under Regulation (EU) 2018/1139 and marine equipment under Directive 2014/90/EU. Free and open source software supplied outside a commercial activity is outside scope as well, and open-source software stewards are subject to Article 24 rather than the Article 13 manufacturer obligations.

Sources:
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 13 (Obligations of manufacturers)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_13). Publications Office of the European Union, Article 13(1) to (6) and (8), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I (Essential cybersecurity requirements)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#anx_I). Publications Office of the European Union, Annex I, Part I, points (1) and (2), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex II (Information and instructions to the user)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#anx_II). Publications Office of the European Union, Annex II, point 5, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 3 (Definitions)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_3). Publications Office of the European Union, Article 3, point (25), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 2 (Scope)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_2). Publications Office of the European Union, Article 2(2) to (7), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 31 (Technical documentation)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_31). Publications Office of the European Union, Article 31, with Annex VII, CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 32 (Conformity assessment procedures)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_32). Publications Office of the European Union, Article 32(2) and (3), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 33 (Support measures for microenterprises and SMEs)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_33). Publications Office of the European Union, Article 33(5), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 69 (Transitional provisions)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_69). Publications Office of the European Union, Article 69(2) and (3), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 71 (Entry into force and application)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_71). Publications Office of the European Union, Article 71(2), CELEX:32024R2847
- [Commission guidance on the application of Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)](https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation). European Commission, Section 7, evaluation and treatment of cybersecurity risks, points 156 to 177, C(2026) 5252 final, Final, adopted 27 July 2026 (non-binding)
- [Commission guidance on the application of Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)](https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation). European Commission, Section 3, free and open-source software, points 44 to 89, C(2026) 5252 final, Final, adopted 27 July 2026 (non-binding)
- [prEN 40000 series, horizontal harmonised standards for the Cyber Resilience Act](https://www.cencenelec.eu/areas-of-work/cen-cenelec-topics/cybersecurity-and-data-protection/). CEN-CENELEC JTC 13, prEN 40000-1-2 (Annex I Part I), prEN 40000-1-3 (Annex I Part II), Standardisation request M/606, Drafts, not yet cited in the Official Journal (non-binding)
- [IEC 62443-4-1 (secure product development lifecycle) and IEC 62443-4-2 (technical security requirements for components)](https://www.iec.ch/blog/understanding-iec-62443). International Electrotechnical Commission, IEC 62443-4-1, IEC 62443-4-2 (non-binding)

### When does the CRA reporting clock start?
URL: https://cvdportal.com/faq/when-does-the-cra-reporting-clock-start
Last reviewed: 2026-07-27
Verified against: Regulation (EU) 2024/2847 Articles 14, 15 and 69(3) as published in OJ L, 20.11.2024, and Commission guidance C(2026) 5252 final of 27 July 2026, points 209 to 221.

The clock starts when you become aware, and Commission guidance now defines that moment. On detecting a suspicious event or receiving a report from a researcher, customer or authority, assess it immediately. You become aware once that initial assessment gives you a reasonable degree of certainty that a vulnerability in your product is being actively exploited, or that a severe incident has compromised your product's security. Receiving a report does not by itself start the clock, and neither does a vague suspicion you have not yet examined.

The Commission deliberately aligned this test with the NIS2 implementing regulation and the EDPB breach-notification guidelines, so a manufacturer caught by several regimes can apply one awareness standard rather than three.

| Fact | Value |
| --- | --- |
| Trigger | Reasonable degree of certainty after an immediate initial assessment |
| Early warning | Without undue delay and within 24 hours of becoming aware |
| Notification | Without undue delay and within 72 hours of becoming aware |
| Final report, exploited vulnerability | Within 14 days of a corrective or mitigating measure being available |
| Final report, severe incident | Within one month of the 72-hour notification |
| Obligation starts | 11 September 2026 |

#### What counts as becoming aware
Article 14 sets every deadline by reference to the moment the manufacturer becomes aware, but the regulation does not define that moment. Commission guidance C(2026) 5252 fills the gap. Where a manufacturer detects a suspicious event, or a third party such as a researcher, customer, authority or media organisation brings something to its attention, the manufacturer should assess it immediately. Awareness arises when, after that initial assessment, there is a reasonable degree of certainty that a vulnerability contained in the product is being actively exploited, or that a severe incident has occurred and has compromised the security of the product.

The practical consequence is that a short, documented triage window sits before the clock starts. That window is not open-ended. The guidance stresses prompt action to carry out the initial assessment, particularly where the vulnerability may pose a significant risk.

#### Why the test matches NIS2 and GDPR
The Commission did not invent a new standard. It aligned the CRA reading with recital 31 of Implementing Regulation (EU) 2024/2690 under NIS2, and with Section II(A) of the EDPB guidelines on personal data breach notification under the GDPR. The stated purpose is to let manufacturers subject to comparable obligations under different EU acts apply the concept consistently.

That matters operationally. One event can trigger CRA, NIS2 and GDPR notification duties at once. A single documented awareness determination, recorded with its timestamp and the reasoning behind it, can anchor all three timelines instead of three separate judgements that later turn out to disagree.

#### What the clock then requires
Once awareness is established, the cadence is fixed. An early warning notification goes to the coordinating CSIRT and ENISA without undue delay and in any event within 24 hours. A fuller notification follows within 72 hours. The complete report is due within 14 days after a corrective or mitigating measure becomes available for an actively exploited vulnerability, or within one month after the 72-hour notification for a severe incident.

Manufacturers are expected to update notifications progressively as the investigation advances. The 24-hour filing is an early warning containing limited information, so a thin first submission is the design rather than a failure.

#### Three limits worth knowing
First, there is no retroactive reporting. Active exploitation a manufacturer had already become aware of before 11 September 2026 does not have to be reported. Where a vulnerability was known before that date but its exploitation was not, and exploitation occurs or comes to light afterwards, the obligation applies.

Second, a vulnerability in an integrated third-party component is only reportable where it is actively exploited in your product. Where the vulnerable code is unreachable, or exploitation has not occurred in your product, no mandatory report arises, although voluntary notification under Article 15 stays open and upstream reporting under Article 13(6) is still required.

Third, the reporting obligations outlive the support period. Vulnerability handling under Annex I Part II stops when support ends, and Article 14 reporting does not.

Sources:
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 (Reporting obligations of manufacturers)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_14). Publications Office of the European Union, Article 14(1) to (8), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 13 (Obligations of manufacturers)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_13). Publications Office of the European Union, Article 13(6), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 15 (Voluntary reporting)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_15). Publications Office of the European Union, Article 15, CELEX:32024R2847, OJ L, 20.11.2024
- [Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act), C(2026) 5252 final, points 209 to 221](https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation). European Commission, C(2026) 5252 (non-binding)
- [Commission Implementing Regulation (EU) 2024/2690 laying down rules for the application of Directive (EU) 2022/2555](https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj). Publications Office of the European Union, Recital 31, CELEX:32024R2690
- [Regulation (EU) 2016/679 (GDPR), Article 33 (Notification of a personal data breach to the supervisory authority)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679#art_33). Publications Office of the European Union, Article 33(1), CELEX:32016R0679

### Which CSIRT do I report to under the CRA, and how does the ENISA single reporting platform work?
URL: https://cvdportal.com/faq/which-csirt-do-i-report-to-under-the-cra
Last reviewed: 2026-08-03
Verified against: The final text of Regulation (EU) 2024/2847 as published in OJ L, 20.11.2024, read at EUR-Lex on 27 July 2026, and the ENISA CRA SRP FAQ with its registration, submission and factsheet sub-resources, read on 3 August 2026

Article 14(7) of the Cyber Resilience Act routes every notification to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment in the Union, meaning where decisions about the cybersecurity of its products are predominantly taken. A manufacturer with no establishment in the Union follows a four-step fallback based on authorised representative, importer, distributor, then users. One submission through the ENISA single reporting platform reaches that CSIRT and ENISA simultaneously, and the deadlines run from 11 September 2026.

The determination is made once and recorded, because the 24-hour clock leaves no room to work out the routing after a vulnerability is already being exploited.

| Fact | Value |
| --- | --- |
| Primary rule | CSIRT of the Member State of main establishment (Article 14(7)) |
| Main establishment test | Where product cybersecurity decisions are predominantly taken |
| Tie-break | Establishment with the highest number of EU employees |
| No EU establishment | Authorised representative, importer, distributor, then users |
| Recipients | Coordinating CSIRT and ENISA, simultaneously, in one submission |
| Applies from | 11 September 2026, including for products already on the market |

#### Which CSIRT is yours, exactly?
Article 14(1) and (3) require a manufacturer to notify an actively exploited vulnerability, and a severe incident having an impact on the security of the product, simultaneously to the CSIRT designated as coordinator and to ENISA, through the single reporting platform.

Article 14(7) decides which CSIRT that is. The notification goes to the electronic notification end-point of the CSIRT designated as coordinator of the Member State where the manufacturer has its main establishment in the Union, and is simultaneously accessible to ENISA.

Main establishment has a specific meaning here. It is the Member State where the decisions related to the cybersecurity of the manufacturer's products with digital elements are predominantly taken. Where that Member State cannot be determined, it is the Member State in which the manufacturer has the establishment with the highest number of employees in the Union.

Note what the test is not. It does not follow the registered office, the group headquarters, the place of incorporation or the largest market. It follows where product security decisions actually get made, which for many groups is an engineering site rather than a corporate seat.

A manufacturer with no main establishment in the Union works down a strict order, based on the information available to it:

1. The Member State where the authorised representative acting for the highest number of that manufacturer's products is established.
2. The Member State where the importer placing the highest number of those products on the market is established.
3. The Member State where the distributor making the highest number of those products available is established.
4. The Member State where the highest number of users of those products are located.

There is a stability provision attached to the fourth limb. Where a manufacturer reaches step 4, it may submit notifications about any subsequent actively exploited vulnerability or severe incident to the same coordinating CSIRT it first reported to, rather than recalculating user distribution each time.

#### What the single reporting platform actually does
Article 16(1) requires ENISA to establish the single reporting platform for the notifications under Article 14(1) and (3) and Article 15(1) and (2), expressly in order to simplify manufacturers' reporting obligations. ENISA manages and maintains its day-to-day operations, and its architecture allows Member States and ENISA to put in place their own electronic notification end-points.

The practical consequence is the one manufacturers most often get wrong. You file once, at your coordinating CSIRT's end-point, and that single submission is simultaneously accessible to ENISA. There is no separate ENISA filing, and no obligation to notify each Member State where the product is sold.

Distribution is handled for you. Under Article 16(2), the coordinating CSIRT that initially receives the notification must without delay disseminate it via the platform to the coordinating CSIRTs of the Member States where the manufacturer has indicated the product has been made available.

That indication is your job, and it is made at the first step. Article 14(2), point (a), requires the 24-hour early warning to indicate, where applicable, the Member States on whose territory the manufacturer is aware the product has been made available. Getting that list wrong at hour 24 is what narrows or misdirects the dissemination that follows.

The [Article 16 explainer](/cra/article-16) covers the platform architecture, the European Vulnerability Database and ENISA's wider coordination role.

#### What you file, and when
Two tracks run on the same clock shape and diverge at the final report. Both start when the manufacturer becomes aware.

For an actively exploited vulnerability, under Article 14(2):

1. Early warning, without undue delay and in any event within 24 hours, indicating where applicable the Member States where the product has been made available.
2. Vulnerability notification, within 72 hours, giving general information about the product, the general nature of the exploit and of the vulnerability, corrective or mitigating measures taken, and measures users can take. This is also where the manufacturer indicates how sensitive it considers the information to be.
3. Final report, no later than 14 days after a corrective or mitigating measure is available, describing the vulnerability including severity and impact, any information on the malicious actor exploiting it, and details of the security update or other corrective measures.

For a severe incident, under Article 14(4):

1. Early warning within 24 hours, including at least whether the incident is suspected of being caused by unlawful or malicious acts.
2. Incident notification within 72 hours, with the nature of the incident, an initial assessment, and corrective or mitigating measures.
3. Final report within one month after the submission of the incident notification, with a detailed description including severity and impact, the type of threat or likely root cause, and applied and ongoing mitigation measures.

The two final-report clocks are the most commonly swapped pair in this Regulation. A vulnerability final report runs 14 days from a fix being available. An incident final report runs one month from the 72-hour notification, so it is anchored to a filing rather than to a remedy.

#### The obligation that is not a filing
Article 14(8) sits alongside the notifications and is easy to miss because it points at customers rather than authorities.

After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer has to inform the impacted users of the product, and where appropriate all users, of that vulnerability or incident, and where necessary of any risk mitigation and corrective measures users can deploy. Where appropriate this should be in a structured, machine-readable format that is easily automatically processable.

That last clause is the practical argument for producing a CSAF advisory rather than a prose security bulletin, since CSAF is the machine-readable advisory format the ecosystem has settled on.

There is an enforcement tail. Where the manufacturer fails to inform users in a timely manner, the notified coordinating CSIRTs may provide that information to users themselves, where considered proportionate and necessary to prevent or mitigate impact. Losing control of your own disclosure to a national CSIRT is a reputational outcome worth engineering against.

#### Can you stop your report reaching every Member State?
Partly, and the decision is never yours.

Article 16(2) allows dissemination of a notification to be delayed on justified cybersecurity-related grounds for a period that is strictly necessary, in exceptional circumstances and in particular on the manufacturer's request, taking into account the sensitivity the manufacturer indicated under Article 14(2), point (a). It names an ongoing coordinated vulnerability disclosure procedure under Article 12(1) of Directive (EU) 2022/2555 as an example. A CSIRT that withholds a notification must immediately inform ENISA of the decision, the justification and when it intends to disseminate.

In particularly exceptional circumstances the restriction goes further, where the manufacturer indicates that the vulnerability has been actively exploited and, on available information, in no Member State other than that of the receiving CSIRT, and that immediate further dissemination would carry the risks the provision sets out.

Commission Delegated Regulation (EU) 2026/881, adopted under Article 14(9) on 11 December 2025 and published in the Official Journal on 20 April 2026, specifies the terms and conditions for applying those cybersecurity-related grounds.

Two points of realism. The receiving CSIRT decides, and it is permitted to delay rather than obliged to. And the mechanism affects dissemination between CSIRTs, so it does nothing to the 24-hour and 72-hour deadlines that apply to you.

#### From when, and does it reach products already sold?
Article 71(2) applies Article 14 from 11 September 2026, more than a year before the rest of the Regulation applies on 11 December 2027.

The part that catches people out is the legacy portfolio. Article 69(2) generally exempts products placed on the market before 11 December 2027 from the Regulation unless they undergo a substantial modification. Article 69(3) then derogates from that specifically for Article 14, so the reporting obligations apply to all products within scope that were placed on the market before that date.

So the exposure on an existing product line is the reverse of the common assumption. The Article 13 design and risk assessment duties generally do not reach it. The Article 14 reporting duties do, and they start first.

Voluntary reporting is available on the same platform. Article 15 lets manufacturers, and other natural or legal persons, voluntarily notify vulnerabilities, cyber threats and incidents that fall outside the mandatory triggers.

#### Is the platform live, and what should you do before September 2026?
Not yet. ENISA states that the platform is scheduled to be operational by 11 September 2026, the date the mandatory reporting obligations enter into application, with a testing period before then.

That leaves no slack. The platform becomes available on the same day the 24-hour clock starts running, so there is no grace period in which to discover how it works.

On 31 July 2026 ENISA published the operational guidance for it, as separate documents on user registration and on notification submission, alongside a two-page reporting factsheet.

Three things follow from that guidance, and the first has a lead time outside your control.

- Create an EU Login account in advance. Access to the platform runs through the Commission's authentication service, and this applies to manufacturers and to the authorised representatives of open-source software stewards alike.
- Expect validation to happen after first access rather than before it. ENISA indicates that the CSIRT designated as coordinator validates that a representative may submit a report on behalf of a specific manufacturer, and that this happens subsequently rather than as a prerequisite you can complete and tick off beforehand.
- Budget for a person at a keyboard. ENISA states that no application programming interfaces will be provided at this stage, so there is no way to file programmatically. Whatever your vulnerability management tooling produces, someone signs in and submits it inside 24 hours.

The work that genuinely cannot wait is the determination in the first section. Establish which CSIRT is yours under Article 14(7), write down the reasoning, and keep the record with your technical documentation. That question has a defensible answer today, and answering it during an active exploitation is how a 24-hour deadline gets missed.

ENISA maintains a dedicated FAQ for the platform, updated as implementation proceeds. Treat it as the operational source and this answer as the legal one.

Sources:
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 14 (Reporting obligations of manufacturers)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_14). Publications Office of the European Union, Article 14(1) to (9), CELEX:32024R2847, OJ L, 20.11.2024
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 15 (Voluntary reporting)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_15). Publications Office of the European Union, Article 15(1) and (2), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 16 (Establishment of a single reporting platform)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_16). Publications Office of the European Union, Article 16(1) and (2), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 69 (Transitional provisions)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_69). Publications Office of the European Union, Article 69(2) and (3), CELEX:32024R2847
- [Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 71 (Entry into force and application)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32024R2847#art_71). Publications Office of the European Union, Article 71(2), CELEX:32024R2847
- [Commission Delegated Regulation (EU) 2026/881 specifying the terms and conditions for applying cybersecurity-related grounds to delay dissemination of notifications](https://eur-lex.europa.eu/eli/reg_del/2026/881/oj). Publications Office of the European Union, Adopted under Article 14(9) CRA, Delegated Regulation (EU) 2026/881, Published in the Official Journal on 20 April 2026
- [Directive (EU) 2022/2555 (NIS 2), Article 12 (Coordinated vulnerability disclosure and European vulnerability database)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj). Publications Office of the European Union, Article 12(1), CELEX:32022L2555
- [Common Security Advisory Framework (CSAF) Version 2.0](https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html). OASIS Open, OASIS Standard, CSAF 2.0 (non-binding)
- [Single Reporting Platform (SRP), including the CRA SRP frequently asked questions](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp). European Union Agency for Cybersecurity (ENISA), Platform status, onboarding and EU Login registration, FAQ updated 31 July 2026 (non-binding)
- [Reporting under the Cyber Resilience Act, factsheet](https://www.enisa.europa.eu/media/57221). European Union Agency for Cybersecurity (ENISA), Two-page overview of the reporting stages and their deadlines (non-binding)
- [CRA SRP, authorised representative user registration](https://www.enisa.europa.eu/cra-srp-ar-user-registration). European Union Agency for Cybersecurity (ENISA), EU Login prerequisite and the coordinating CSIRT validation step, Updated 31 July 2026 (non-binding)
- [CRA SRP, notification submission and update](https://www.enisa.europa.eu/cra-srp-ar-notification-submission-and-update). European Union Agency for Cybersecurity (ENISA), How a notification is submitted and subsequently updated, Updated 31 July 2026 (non-binding)
- [Cyber Resilience Act, reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting). European Commission, DG CONNECT, Single reporting platform readiness and reporting deadlines, As published, July 2026 (non-binding)
- [EU Login, the European Commission authentication service](https://ecas.ec.europa.eu/cas/login). European Commission, Account registration required before using the platform, by manufacturers and by open-source steward authorised representatives alike (non-binding)

## Commission guidance worked examples (C(2026) 5252 final)

Reproduced verbatim from the Annex to Commission Communication C(2026) 5252 final of 27 July 2026. The guidance is not binding on economic operators. Verdict lines are CVD Portal's summary of the outcome and are not part of the source text.

### How does core functionality decide a product's CRA classification?
URL: https://cvdportal.com/cra-guidance/examples/core-functionality-and-product-classification
Last reviewed: 2026-07-27

Classification follows core functionality, judged against the technical descriptions in Implementing Regulation (EU) 2025/2392. A product that merely integrates an operating system does not take on the core functionality of one. SOAR software generally exceeds the SIEM category and log viewers fall short of it. Modules offered on separate subscriptions are separate products, each classified on its own. Extra functions do not push a product into a stricter conformity route, and the presumption of conformity covers only what the harmonised standard covers.

The harmonised standards under the CRA are not yet cited in the Official Journal, so the presumption of conformity described in Examples 64 and 65 is not yet available in practice.

#### Core functionality is what the product is for, not what it contains
Example 57 walks through the positive case. A product providing an abstraction layer over hardware, managing process and memory, handling input-output, scheduling, resource allocation and exposing system APIs has the core functionality of an operating system as described in Annex I, point 11, to Implementing Regulation (EU) 2025/2392.

Example 58 is the one that saves manufacturers from over-classifying. A smartphone integrates an operating system, and the smartphone as a whole still has a different core functionality. Mere integration does not transfer the category.

Examples 59 and 60 show the category boundary cutting in both directions for SIEM. SOAR software is generally not a SIEM, because its core functionality substantially exceeds the category and includes incident response. Log collection and visualisation tools are generally not SIEM either, because they do not correlate data or provide actionable security insights. Falling short and overshooting both put a product outside.

#### Bundled suites are classified module by module where the modules are sold separately
Example 61 handles the unified security suite. Where a manufacturer offers a SIEM, an intrusion detection system and an analytics module on separate subscriptions, each is a distinct product classified on its own core functionality.

The outcome in that example spans all three regimes at once. The SIEM module is important class I. The intrusion detection system is important class II, under the firewalls, intrusion detection and prevention systems category. The analytics module is a default product. One suite, three conformity assessment routes.

#### Extra functions do not change the route, and the presumption follows the standard
Examples 62 and 63 confirm that a product is assessed as a whole against its core functionality. Antivirus software with disk-cleaning and anti-tracking functions, and a router that integrates a firewall component, may both use the internal control procedure covering the product in its entirety. The manufacturer assesses the whole product and may apply an additional harmonised standard, such as the firewall standard, to cover the extra functions.

Examples 64 and 65 separate the conformity route from the presumption of conformity, which is where the practical exposure sits. Applying the harmonised standard for the core functionality earns a presumption for the risks associated with that core functionality only. Risks from the additional functions carry no presumption until the standard is updated to cover them, and Example 65 shows the presumption widening one function at a time as that happens.

#### Example 57 (Section 6.1 Core functionality, point 139, page 49)
Verdict (CVD Portal): Core functionality of an operating system, per Annex I point 11 to Implementing Regulation (EU) 2025/2392

A software product with digital elements provides an abstraction layer over the underlying hardware and manages the execution of software components. Its main features include hardware and peripheral initialisation, process and memory management, input – output control, scheduling, resource allocation, and the exposure of system services and application programming interfaces (APIs) through which applications interact with the device's hardware and software resources. The technical documentation indicates that the product with digital elements orchestrates computing resources, enforces system configurations, and provides standardised interfaces for software modules and connected peripherals. The manufacturer highlights these capabilities as enabling the platform to serve as the central software environment on which applications can reliably run. The product with digital elements has the core functionality of an operating system, as described in Annex I, point 11, to Implementing Regulation (EU) 2025/2392.

#### Example 58 (Section 6.1 Core functionality, point 141, page 50)
Verdict (CVD Portal): Integrating an operating system does not give the host product the core functionality of one

A smartphone integrates an operating system that provides the functionalities described in Annex I, point 11, to Implementing Regulation (EU) 2025/2392. While the operating system enables the management of hardware resources and execution of software applications, the smartphone as a whole has a different core functionality (e.g. that of enabling users to communicate and access information and services). The mere integration of an operating system does not mean that the smartphone has the core functionality of an operating system.

#### Example 59 (Section 6.1 Core functionality, point 142, page 50)
Verdict (CVD Portal): SOAR is generally not a SIEM. Its core functionality substantially exceeds the category

A security orchestration, automation and response (SOAR) software often has the ability to perform the functions of products with digital elements in the category of 'security information and event management (SIEM) systems', i.e. collect data from multiple sources, analyse and correlate that data and present it as actionable information for security-related purposes. However, the software's core functionality substantially exceeds that of a SIEM, including services such as incident response as core elements of its technical capabilities. Therefore, SOAR software is generally not considered to have the core functionality of SIEM systems.

#### Example 60 (Section 6.1 Core functionality, point 142, page 50)
Verdict (CVD Portal): Log collection and dashboards are generally not a SIEM. No correlation, no actionable security insight

Certain log collection and visualisation tools have the ability to ingest log data and present basic dashboards showing system events. While these tools can support security monitoring activities, their core functionality falls short of that of SIEM systems, as they do not perform data correlation, nor do they provide actionable security insights. Therefore, such tools are generally not to be considered to have the core functionality of SIEM systems.

#### Example 61 (Section 6.1 Core functionality, point 145, page 52)
Verdict (CVD Portal): Separately subscribable modules are separate products, each classified on its own core functionality

a manufacturer places on the market a unified security suite combining multiple modules, including a SIEM, an intrusion detection system, and an analytics module. The manufacturer also offers those modules for separate subscriptions. In this scenario, each module is a distinct product with digital elements and is classified on the basis of its own core functionality. The SIEM module is subject to the conformity assessment regime for important products with digital elements of class I, as its core functionality is that of 'Security information and event management (SIEM) systems'. The intrusion detection system is subject to the conformity assessment regime for important products with digital elements of class II, as its core functionality is that of 'Firewalls, intrusion detection and prevention systems'. The analytics module is subject to the conformity assessment regime for 'default' products with digital elements, as its core functionality is not that of an important or critical product category.

#### Example 62 (Section 6.2 Conformity assessment for important and critical products with digital elements, point 151, page 54)
Verdict (CVD Portal): Internal control remains available for the whole product, including functions outside the core category

An antivirus software has the core functionality of software that searches for, removes, or quarantines malicious software, as described in Annex I, point 4, to Implementing Regulation (EU) 2025/2392. That product with digital elements also includes additional features, namely a disk-cleaning function and an anti-tracking function protecting the user when navigating on the web. The manufacturer carries out a risk assessment covering the product with digital elements in its entirety, including the antivirus's core functionality, the disk-cleaning and the anti-tracking functions. It applies a harmonised standard covering the risks associated with the antivirus's core functionality, and additional measures to deal with risks stemming from additional functions. The manufacturer is allowed to make use of the internal control procedure for its conformity assessment, covering the product with digital elements as a whole, including the disk-cleaning and the anti-tracking functions.

#### Example 63 (Section 6.2 Conformity assessment for important and critical products with digital elements, point 152, page 55)
Verdict (CVD Portal): A router with a firewall component is still classified as a router

A hardware product with digital elements has the core functionality of a router, as described in Annex I, point 12, to Implementing Regulation (EU) 2025/2392. That product with digital elements also includes additional functionalities, including firewalling capabilities, as it integrates a firewall component. The manufacturer carries out a risk assessment covering the product with digital elements in its entirety, including the router's core functionality and the firewall functionality. It applies a harmonised standard covering the risks associated with the router's core functionality, and additional measures to deal with risks stemming from additional functions. For instance, the manufacturer may apply the harmonised standard for firewalls to cover the risks associated with the firewall functionality. The manufacturer is allowed to make use of the internal control procedure for its conformity assessment, covering the product with digital elements as a whole, including the firewall functionality.

#### Example 64 (Section 6.3 Implications for presumption of conformity, point 155, page 56)
Verdict (CVD Portal): Presumption of conformity attaches to the core functionality only, not to the extra functions

An antivirus software has the core functionality of software that searches for, removes, or quarantines malicious software, and risks associated with that core functionality are covered by the harmonised standard. That product with digital elements also includes additional functionalities, namely a disk-cleaning function and an anti-tracking functionality protecting the user when navigating on the web, whose risks are not covered by the harmonised standard. If the harmonised standard is applied, the manufacturer is allowed to make use of the internal control procedure for its conformity assessment. It will benefit from presumption of conformity for the risks associated with that product's core functionality, but not for the risks associated with additional functionalities.

#### Example 65 (Section 6.3 Implications for presumption of conformity, point 155, page 56)
Verdict (CVD Portal): Presumption widens as the harmonised standard widens, function by function

In the same scenario as the previous example, the harmonised standard has now been updated to also cover risks associated with one of the additional functionalities, namely the disk-cleaning function, but not the other (i.e. the anti-tracking function). If the harmonised standard is applied, the manufacturer is allowed to make use of the internal control procedure for its conformity assessment. It will benefit from a presumption of conformity for the risks associated with that product's core functionality and for the disk-cleaning functionality, but not for the risks related to the anti-tracking functionality.

### How does the CRA cybersecurity risk assessment justify design decisions?
URL: https://cvdportal.com/cra-guidance/examples/cra-risk-assessment-worked-examples
Last reviewed: 2026-07-27

The Commission's risk assessment examples all turn on the same move. The Article 13(2) assessment decides what a product needs, and it can justify choices that look like gaps. Supporting a legacy protocol for interoperability, integrating a component bought before the CRA applied, placing an older design on the market without redesign, limiting a sensor's intended purpose instead of hardening it, and relying on the operating system's cryptography rather than writing your own are each defensible where the assessment carries them.

The assessment has to be documented and kept under review under Article 13(3). An undocumented judgement call is not a treated risk.

#### Interoperability can justify a weaker protocol, but not as the default
Example 10 is the one manufacturers of industrial equipment reach for. Where the intended purpose includes talking to systems that only speak an older protocol, that protocol may be implemented, provided the risks are identified and mitigated by other means.

The condition is the part that gets missed. Where the product can technically support both, the manufacturer is expected to implement the secure protocol and enable it by default. The weaker one is allowed only where interoperability requires it. Shipping the legacy protocol as the default and calling it interoperability does not survive this example.

#### Older designs and older components do not force a redesign
Examples 11 and 12 answer the question every hardware manufacturer asked during the transition. Components purchased before the CRA applied can be integrated, provided the assessment finds no specific risk in doing so and the finished product meets the essential requirements as a whole.

Example 12 goes further for products designed before the date of application. Where a current assessment shows the existing design already incorporates appropriate measures, the product may be placed on the market without redesign. The manufacturer documents a current assessment explaining how the existing design mitigates the identified risks. It is not required to recreate historical design or test documentation, because doing so would not make the product any safer. Representative evidence may cover a family of variants sharing a risk profile.

#### Two ways to treat a risk without building a control for it
Examples 66 and 67 sit in the section on evaluating and treating cybersecurity risks, and both describe treatments that add no security feature to the product.

In Example 66 the manufacturer of an industrial sensor cannot protect against physical attack without breaking the sensor's function, so it limits the intended purpose to trusted environments and says so clearly in the information and instructions to users. The limitation is the mitigation, and it only works because it reaches the user.

In Example 67 the manufacturer of a professional application declines to write its own encryption and relies on the operating system's native encryption and key management, on the reasoning that those services are mature and regularly maintained. Both are ordinary risk treatment, documented as such.

#### Example 10 (Section 2.6 Complex systems, point 32, page 13)
Verdict (CVD Portal): A legacy protocol may be supported for interoperability, but the secure one is implemented and on by default

A manufacturer places on the market a product with digital elements that communicates with external systems using a network protocol. As part of the application of the essential requirements, the manufacturer determines, on the basis of the cybersecurity risk assessment, that the use of a secure communication protocol is necessary to ensure the confidentiality and integrity of data exchanged by the product with digital elements.

However, its intended purpose includes interoperability with existing systems that only support an older or less secure protocol. In such cases, the manufacturer may implement that protocol where this is necessary to achieve interoperability, provided that the associated cybersecurity risks are identified and mitigated through other means.

Where it is technically feasible for the product with digital elements to support both the secure protocol and the less secure protocol, the manufacturer is expected to implement the secure protocol and to enable its use by default. The less secure protocol would be allowed only where required for interoperability.

#### Example 11 (Section 2.6 Complex systems, point 32, page 14)
Verdict (CVD Portal): Components bought before the CRA applied can be integrated, provided the whole product meets the essential requirements

A manufacturer of an industrial automation system purchases some microcontrollers before the CRA enters into application. The manufacturer undertakes the cybersecurity risk assessment for its industrial automation system to be placed on the market after the CRA enters into application. On the basis of that cybersecurity risk assessment, the manufacturer does not identify specific cybersecurity risks associated with using one of those microcontrollers. The manufacturer integrates it into its industrial automation system and ensures that the product with digital elements as a whole (the industrial automation system) meets the essential requirements.

#### Example 12 (Section 2.7 Products with digital elements designed before the CRA entered into application, point 39, page 16)
Verdict (CVD Portal): No redesign, and no recreated historical paperwork, where a current risk assessment shows the existing design already meets the requirements

A manufacturer places on the market a microcontroller that was designed and developed before the date of application of the CRA. The microcontroller is intended to be integrated into a range of electronic products with digital elements, including products with digital elements with connectivity functionalities.

Before placing new units of the microcontroller on the market after the CRA applies, the manufacturer carries out a cybersecurity risk assessment in accordance with Article 13(2). On the basis of the intended purpose of the microcontroller and its reasonably foreseeable use, the manufacturer identifies relevant cybersecurity risks, such as unauthorised access, manipulation of software or data, and misuse of available interfaces.

The outcome of the risk assessment shows that the microcontroller, as originally designed, already incorporates appropriate and effective security measures addressing the identified risks. The manufacturer therefore concludes that the product with digital elements meets the relevant essential requirements set out in Part I of Annex I and that no redesign or introduction of additional security functionalities is necessary.

Where it is not possible to demonstrate how a cybersecurity risk assessment was taken into account during the original design and development phase, the manufacturer documents a current cybersecurity risk assessment and explains how the existing design and measures mitigate the identified risks. The manufacturer is not required to recreate historical design or test documentation, as this would not contribute to enhancing the cybersecurity of the product with digital elements. Where several variants of the microcontroller are based on the same design and share the same cybersecurity risk profile, the manufacturer may also rely on representative evidence covering the relevant product family.

The manufacturer also ensures compliance with the vulnerability handling requirements laid down in Part II of Annex I, including by maintaining processes to address and remediate vulnerabilities and by keeping the cybersecurity risk assessment under review in accordance with Article 13(3).

In these circumstances, the microcontroller designed before the date of application of the CRA may be placed on the market without redesign, provided that the manufacturer can demonstrate, through the cybersecurity risk assessment and the technical documentation, that it achieves an appropriate level of cybersecurity in light of its intended purpose and reasonably foreseeable use and complies with the applicable essential requirements.

#### Example 66 (Section 7.1 On the evaluation and treatment of cybersecurity risks, point 162, page 59)
Verdict (CVD Portal): Risk treated by limiting the intended purpose, with the limitation stated in the user information

A manufacturer develops an industrial sensor for use in trusted environments. For the sensor to perform its functionality correctly, the manufacturer does not implement measures to protect against physical attacks on the sensor itself. To mitigate the associated risks identified in the risk assessment, the manufacturer limits the sensor's intended purpose to use only in trusted environments where unauthorised physical access to the product with digital elements is prevented. Information and instructions to the users provide clear information on these limitations on the sensor's use, in a manner that is appropriate to the nature of the product with digital elements and its intended users.

#### Example 67 (Section 7.1 On the evaluation and treatment of cybersecurity risks, point 162, page 59)
Verdict (CVD Portal): Relying on mature operating system cryptography rather than rolling your own

A manufacturer develops a software application for professional use on managed desktop and mobile devices. The application processes locally stored sensitive data and user-generated content. During the risk assessment, the manufacturer identifies the risk of unauthorised access to such data if they are stored in clear text on the device. Rather than designing and implementing a proprietary encryption mechanism within the application itself, the manufacturer chooses to rely on the encryption and key management functions provided natively by the operating system on which the application is intended to run, as the operating system's built-in cryptographic services are mature and regularly maintained.

### How long must a CRA support period be, and does a substantial modification extend it?
URL: https://cvdportal.com/cra-guidance/examples/how-long-must-my-support-period-be
Last reviewed: 2026-07-27

Article 13(8) sets the support period by reference to the time the product is expected to be in use. The five year figure is a safeguard floor rather than a default, and products expected to last longer need correspondingly longer periods. Article 13(10) lets a manufacturer remediate only the version last placed on the market, provided users can upgrade free of charge and without additional costs. A substantial modification triggers a reassessment but does not automatically reset or extend the period.

The other Annex I Part II requirements continue for every version. Article 13(10) relieves remediation, not coordinated vulnerability disclosure or information sharing.

#### Five years is a floor, and reading it as a default is the common error
Article 13(8) derives the support period from the time the product is expected to be in use, judged against reasonable user expectations, the nature of the product including its intended purpose, and relevant Union law determining product lifetimes.

Point 126 of the guidance states that the five year minimum operates only as a safeguard, and that a support period of five years is not to be considered the default for all products. Recital 60 means products reasonably expected to be in use for longer should have correspondingly longer support periods. A ten year industrial controller declared with a five year support period is not compliant because it cleared the floor.

Article 13(8) itself lists further matters a manufacturer may take into account, and they are worth recording in the technical file. The support periods of similar products placed on the market by other manufacturers, the availability of the operating environment, the support periods of integrated third-party components that provide core functions, and relevant guidance from the dedicated administrative cooperation group established under Article 52(15). Article 13(8) also requires those matters to be considered in a manner that ensures proportionality.

#### Article 13(10) relief for software that ships every few months
Examples 52 and 53 apply the relief to a smartphone operating system and to enterprise software released every few months. In both, the manufacturer may address and remediate vulnerabilities only for the version last placed on the market, provided earlier versions can be upgraded free of charge and without additional costs.

Point 130 reads additional costs narrowly, and Example 53 puts the reading in a scenario. Personnel time, routine testing, configuration adjustments and upgrading dependencies to deal with end-of-life components are ordinary operational effort and do not count. Mandatory purchases of new hardware, infrastructure replacement and fundamental changes to the operating environment do.

The relief is narrow in another way that gets missed. Each substantially modified version still needs its own declared support period under Article 13(8), and the other Annex I Part II obligations continue for all of them, including the coordinated vulnerability disclosure policy and measures to facilitate information sharing. Where remediation for earlier versions stops, users who have not upgraded should be informed where technically feasible under Article 13(19).

#### A substantial modification reopens the question without answering it
Points 133 to 135 require a reassessment against the Article 13(8) criteria after a substantial modification, and Examples 54 to 56 show the reassessment landing in both directions.

Adding cleaning modes and navigation features to a robot vacuum does not change the period, because the update affects neither the physical durability of the hardware nor reasonable user expectations. Rearchitecting the cloud back end of industrial machinery, even with new APIs and data flows, does not change it either, for the same reason.

Replacing a programmable logic controller's embedded computing platform, including the processor, memory and runtime environment, with components designed for a significantly longer operational lifetime does change it. The user may now reasonably expect the controller to stay in productive use beyond the originally declared expected use time, so the criteria indicate a longer period and the manufacturer recalculates.

#### Example 52 (Section 5 Support period, point 131, page 45)
Verdict (CVD Portal): Article 13(10) relief. Remediate the latest OS version only, where upgrades are free and need no new hardware

A manufacturer places a smartphone model on the EU market and declares a support period of X years from the date of placement on the market, during which it will provide security updates addressing vulnerabilities. During that period, the manufacturer releases regular software updates and substantially modified versions of the operating system, which users can install free of charge without requiring new hardware.

The manufacturer may, in accordance with Article 13(10), address and remediate vulnerabilities for the latest version of the operating system made available for that smartphone model, provided that earlier versions can be upgraded free of charge and without additional costs. For the duration of the support period, the manufacturer remains subject to the other vulnerability handling requirements, such as coordinated vulnerability disclosure and information-sharing measures.

#### Example 53 (Section 5 Support period, point 131, page 45)
Verdict (CVD Portal): Article 13(10) relief for iterative enterprise software. Testing and configuration effort is not an additional cost

A manufacturer places an enterprise software product with digital elements on the market and releases substantially modified versions every few months, reflecting security improvements, new features and compatibility with updated operating systems and platforms. Each version is placed on the market with a declared support period in accordance with Article 13(8). The manufacturer expects users to upgrade regularly as part of normal operation and provides access to the latest version free of charge. Applying upgrades may require reasonable operational effort, such as testing or configuration adjustments, but does not require additional costs, such as the purchase of new hardware or fundamental infrastructure changes. In this context, the manufacturer may rely on Article 13(10) to discontinue addressing and remediating vulnerabilities for earlier versions once users can upgrade to the latest version, while continuing to comply with the other vulnerability-handling requirements for all subsequent substantially modified versions.

#### Example 54 (Section 5.1 Substantial modifications and the support period, point 134, page 46)
Verdict (CVD Portal): Support period unchanged. New cleaning modes do not alter hardware durability or user expectations

A manufacturer places on the market a robot vacuum cleaner with an expected use time of X years, determined on the basis of the nature of the product with digital elements, including the physical durability and wear characteristics of the hardware components, and taking into account reasonable user expectations as to that product's lifetime. The manufacturer sets a support period of X years. After Y years, the manufacturer releases a software update that qualifies as a substantial modification, adding new cleaning modes and navigation features. The software update does not affect the physical durability of the hardware and does not alter reasonable user expectations as to that product's lifetime. The Article 13(8) criteria therefore continue to indicate the same expected use time. The support period of the modified product with digital elements aligns with the remaining expected use time as originally determined.

#### Example 55 (Section 5.1 Substantial modifications and the support period, point 134, page 46)
Verdict (CVD Portal): Support period unchanged. Rearchitecting the cloud back end does not change the nature of the machinery

A manufacturer places on the market a complex industrial machinery product with digital elements, with a cloud back-end that constitutes a remote data processing solution. The expected use time is X years, determined in light of reasonable user expectations and the nature of the product with digital elements, such as the physical durability of the machinery hardware and expected wear and tear. The support period is set to align with that expected use time at X years. After Y years, the manufacturer rearchitects the cloud back-end (the remote data processing solution), introducing new APIs and data flows, in a manner that qualifies as a substantial modification of the product with digital elements but does not alter the nature of that product or affect user expectations. The Article 13(8) criteria therefore continue to indicate the same expected use time. The support period of the modified product with digital elements aligns with the remaining expected use time as originally determined.

#### Example 56 (Section 5.1 Substantial modifications and the support period, point 135, page 47)
Verdict (CVD Portal): Support period recalculated upwards. A new computing platform changes the expected use time

A manufacturer places on the market a programmable logic controller (PLC) with an expected use time of X years, determined primarily on the basis of the nature of the product with digital elements and the durability of the underlying hardware. The support period is set accordingly. Several years after the initial placing on the market, the manufacturer carries out a substantial modification consisting of the replacement of the PLC's embedded computing platform, including the processor, memory and runtime environment, with a new generation of components designed for a significantly longer operational lifetime. As a result of the modification, reasonable user expectations and the nature of the product with digital elements change: the PLC's user may now reasonably expect the PLC to remain in productive use beyond its originally declared expected use time, supported by the new computing platform. The Article 13(8) criteria therefore indicate a longer expected use time, and the manufacturer recalculates the support period for that specific PLC accordingly.

### Is my cloud back end a remote data processing solution under the CRA?
URL: https://cvdportal.com/cra-guidance/examples/is-my-backend-a-remote-data-processing-solution
Last reviewed: 2026-07-27

Remote data processing is part of your product when two things hold together. The product cannot perform one of its functions without it, and the software was designed and developed by you or under your responsibility. Your own back end qualifies even when it runs on third-party infrastructure. A general purpose third-party SaaS does not, and is treated as a component instead. Systems your product never talks to directly fall outside, and a cellular network is neither a solution nor a component.

Falling outside the definition does not remove the risk. Anything your product depends on still has to be assessed and mitigated through product-level measures.

#### Two questions, and both have to be answered yes
Article 3, point (2) defines remote data processing as data processing at a distance for which the software is designed and developed by the manufacturer, or under the manufacturer's responsibility, and the absence of which would prevent the product from performing one of its functions.

The smart thermostat and the industrial robot both answer yes twice. The thermostat cannot do anything smart without the exchange and storage functions, and the manufacturer wrote them. The robot cannot pick up parts without the vision service, and the manufacturer wrote that too. In both, the software runs on infrastructure a third party provides, and that changes nothing about ownership of the software.

What it does change is the paperwork. The manufacturer documents the solution and the reliance on the third-party infrastructure in the technical documentation, including details of the contracted service, and considers both in the risk assessment. The guidance suggests asking the infrastructure provider for evidence that its NIS 2 obligations have been met.

#### Three ways to fall outside, with three different consequences
The e-Reader case fails the second question. A general purpose third-party SaaS storage service is necessary for the product to work and was not developed under the manufacturer's responsibility, so it is not a remote data processing solution. It is treated like a component instead, which means due diligence on selection and integration plus product-level measures such as secure authentication, encryption and integrity protection of communications.

The banking use case fails on directness. The account-management and ledger systems sit behind the banking interface, and the app never interacts with them. The CRA covers only the parts of the system that interact directly with the product. They still generate real risk, and the guidance names the scenario, which is an attacker compromising the ledger to influence transaction results the app then displays.

The cellular network fails both and is not even a component. A network is an enabler of connectivity rather than data processing whose absence stops a function, in the same way as an ethernet cable, a router or a Wi-Fi signal. No due diligence is owed to the network operator.

#### The banking case is the one to read twice
It is the only use case where one product contains all three answers at once.

The self-hosted banking interface is a remote data processing solution, because the app authenticates, submits instructions and receives status through it, and the financial entity built it. It goes into the risk assessment and the essential requirements for the product as a whole.

The account-management and ledger systems behind it are not, on directness. The third-party support chat inside the app is not, on responsibility, and is treated as a component with its own product-level mitigations such as isolating it from core banking features and validating content.

The practical lesson for anyone drawing a system boundary is that the definition follows the first hop. What your product talks to directly and you built is in. What sits one layer further back is out of the definition and still inside your risk assessment.

#### 8.3.1 Mobile banking application (Section 8.3.1 Mobile banking application)
Verdict (CVD Portal): The banking interface is a remote data processing solution. The ledger and account systems behind it are not, but their risks still have to be managed

A financial entity places a mobile banking application on the market. The app's back-end systems support, among others, authentication, authorisation, account management, and payments. The financial entity uses a hybrid strategy relying on in-house infrastructure as well as third-party remote solutions to support the app's functionalities. These include:

Self-hosted infrastructure developed by the financial entity:

The customer opens the mobile banking application and is authenticated through the banking interface, a self-hosted solution developed by the financial entity that receives the app's requests and returns the corresponding responses. The banking interface verifies the customer's identity by querying the account management system and grants access to the application.

The customer initiates a transfer via the app. The app transmits the instruction to the banking interface, which submits a corresponding request to the ledger system.

The account-management system and ledger system, both self-hosted but logically segregated from the banking interface, record the transaction.

The ledger system returns the transaction status to the banking interface, which presents the result to the customer.

Implications for RDPS:

The banking interface is necessary for the app to perform its functions, namely authenticating the customer, submitting the customer's instructions, including payment and transfer instructions, and returning the resulting status. The banking interface is designed and developed under the responsibility of the manufacturer. As the answer to both questions presented in earlier sections is affirmative, the banking interface is to be considered an RDPS. It must therefore be included in the cybersecurity risk assessment and in the implementation of the essential requirements for the product with digital elements as a whole. The subsequent processing of an instruction once submitted, in particular the recording of the transaction in the account-management and ledger systems, settlement and clearing, is carried out by systems with which the app does not interact directly and does not, on that basis, constitute an RDPS.

The account-management system and the ledger system do not qualify as RDPS for the banking application. The app does not interact directly with them (interacting instead with the banking interface, which in turn relies upon them). Although their availability may be necessary for a function to be completed, the CRA covers only those parts of the system that interact directly with the product with digital elements. They therefore fall outside the definition of RDPS for the purposes of the CRA. However, those systems remain external dependencies that may give rise to significant cybersecurity risks for the product with digital elements. For example, compromise of the ledger system could allow an attacker to influence transaction results that are subsequently displayed in the application. The manufacturer is therefore required to identify and assess those risks as part of the cybersecurity risk assessment and to mitigate them through product-level measures, such as strong authentication of back-end interfaces, integrity protection of transaction data, secure communication channels and verification of responses received by the app.

Third-party SaaS for customer support:

The financial entity integrates into its app a customer support chat solution developed and operated by a third-party provider; the third-party provider has written the chat server code, built the user interface and operates the infrastructure where the chat is deployed (i.e. SaaS model).

When the customer initiates a request for support, the app connects the customer to the third-party service to establish a chat session and handle the messaging flow, without providing the third party with access to core banking systems.

Implications for RDPS:

The support chat solution is necessary for the product with digital elements to perform one of its functions, but is not designed and developed by the financial entity, or under its responsibility; it therefore is not an RDPS. However, it should be treated like a third-party component. The reliance on that third-party service may create cybersecurity risks for the banking application, for example if an attacker were to use the chat channel to impersonate the bank or to deliver malicious content to users. The financial entity must take those risks into account in its cybersecurity risk assessment and mitigate them through product-level measures, such as isolating the chat function from core banking features, controlling data flows and validating content. Due diligence on the SaaS should also be exercised.

#### 8.3.2 Smart thermostat (Section 8.3.2 Smart thermostat)
Verdict (CVD Portal): Remote data processing solution. Manufacturer-developed software on third-party infrastructure

A smart thermostat enables users to control the temperature of their homes via a mobile application. The mobile application and the smart thermostat rely on remote data processing to exchange data (e.g. request to increase the temperature) and store data (e.g. user preferences). These functions were developed and designed under the responsibility of the manufacturer but run on an underlying physical and virtual infrastructure provided by a third party (third-party IaaS). As the smart thermostat would not be able to perform its smart functionalities without this remote data processing, its absence would prevent the product with digital elements from performing one or more of its functions. Additionally, the software was developed and designed under the responsibility of the smart thermostat manufacturer. Therefore, the remote data processing qualifies as RDPS as defined in the CRA.

For the purpose of CRA compliance, the manufacturer of the smart thermostat needs to document the RDPS as well as the reliance on the third-party IaaS in the technical documentation of the product with digital elements, including details of the contracted service. The manufacturer needs to consider those elements in the risk assessment, which includes the intended purpose and reasonably foreseeable use of the product with digital elements. The manufacturer implements the CRA's essential requirements based on the risks on the RDPS. For the third-party IaaS, the manufacturer needs to ensure that the security measures provided by the third-party provider are appropriate and/or take relevant measures vis-à-vis the infrastructure. For the former, the manufacturer could, for example, ask for evidence that NIS 2 obligations have been met.

#### 8.3.3 e-Reader (Section 8.3.3 e-Reader)
Verdict (CVD Portal): Not a remote data processing solution. A general-purpose third-party SaaS is treated like a component

The manufacturer of an e-Reader software uses a third-party SaaS storage service to store electronic books purchased by customers and enable them to access their books. The absence of this storage service would prevent the product with digital elements from performing one of its functions, but the third-party SaaS storage service is not developed by or under the responsibility of the manufacturer; the SaaS provider makes it available to customers for any use case.

The SaaS storage service does not meet the definition of RDPS. However, the e-Reader manufacturer relies on that external service for the functioning of its product with digital elements and must therefore take the associated risks into account in its cybersecurity risk assessment. The e-Reader manufacturer should treat the SaaS like a component. The manufacturer must implement appropriate product-level security measures, such as secure authentication, encryption and integrity protection of communications with the storage service. Due diligence when selecting and integrating the SaaS provider will also support the manufacturer's obligations, so that the product with digital elements as a whole can comply with the essential requirements.

#### 8.3.4 Industrial robot (Section 8.3.4 Industrial robot)
Verdict (CVD Portal): Remote data processing solution. The manufacturer's vision service is what makes the robot able to pick up parts

An industrial robot has the task of picking up parts. The robot sends information collected via cameras to a remote service designed and developed by the manufacturer. This service runs on an underlying physical and virtual infrastructure provided by a third-party service provider (third-party IaaS). The cloud service calculates the position of a part based on the camera feeds and sends commands back to the robot to pick up the parts.

The absence of this data processing would prevent the industrial robot from picking up parts, hence from performing one of its functions. Furthermore, the software running on top of the infrastructure has been designed and developed by the manufacturer. The software designed and developed by the manufacturer meets the definition of RDPS.

The manufacturer of the industrial robot needs to document the RDPS as well as the reliance on the third-party IaaS in the technical documentation of the product with digital elements (including details of the contracted service). The manufacturer also needs to consider those elements in the risk assessment, which includes the intended purpose and reasonably foreseeable use of the product with digital elements. The manufacturer implements the CRA's essential requirements on the product with digital elements, including its RDPS, on the basis of the risks. Due diligence when selecting the IaaS provider will also support the manufacturer's obligations. For example, the manufacturer could ask for evidence that NIS 2 obligations have been met.

#### 8.3.5 Cellular network (Section 8.3.5 Cellular network)
Verdict (CVD Portal): Not a remote data processing solution and not a component. A network is an enabler of connectivity, so no due diligence is owed to the operator

A smartphone relies on a 5G network to provide internet connection, phone calls and messages to its users (mobile connectivity). The cellular network is developed and designed by telecommunication operators. The network comprises small cells and cell towers, and other network equipment.

The product with digital elements should be able to connect to a network correctly; this is one of its functions. However, whether that network is in operation or not is not relevant to ascertain if the product with digital elements is working correctly. The network is only a communication channel and is not necessary for the product with digital elements to perform its function of 'connecting to a network correctly'. Likewise, an ethernet cable, a router or Wi-Fi signal is not considered data processing whose absence would prevent the product with digital elements from performing one of its functions, but rather an enabler of communication/connectivity.

Consequently, the cellular network does not meet the definition of RDPS. The network should not be considered like a third-party component, as there is no software integrated into the product with digital elements, the product instead merely relying on this network. As such, it is not necessary for the manufacturer to exercise due diligence obligations towards the network provider.

### Are spare parts and repairs subject to the Cyber Resilience Act?
URL: https://cvdportal.com/cra-guidance/examples/repairs-and-spare-parts-under-the-cra
Last reviewed: 2026-07-27

Article 2(6) takes spare parts outside the CRA where they replace identical components in a product with digital elements. The Commission's examples turn on what identical means. A replacement module built to the same specifications is exempt, whether the host product predates the CRA or not. A newer chip with a different cryptographic implementation and secure boot mechanism is not identical and is a product in its own right. A different chipset can still be identical where the protocols and security mechanisms are unchanged.

The exemption covers the spare part. Whether the repair substantially modifies the host product is a separate question answered by the same risk-impact test.

#### Identical is judged on cybersecurity properties, not part numbers
Examples 36 to 38 are the useful trio, because they show the test cutting both ways.

A replacement communication module that is identical and built to the same specifications is exempt under Article 2(6), and the guidance confirms this holds whether the controller it repairs was placed on the market in 2026 or in 2028.

A newer chip supplied because the original is discontinued is not identical where it has a different cryptographic implementation and an updated secure boot mechanism, because those differences affect its cybersecurity properties. It becomes a product with digital elements subject to the CRA, assessed in light of its intended purpose including interoperability with the older host.

A module built on a different chipset with updated firmware can still be identical, provided it performs the same function using the same communication protocols and security mechanisms and the firmware does not alter characteristics relevant to cybersecurity. The silicon is not the test.

#### A repair that stays inside the assessed intended use is not a modification
Example 35 handles the ordinary case. Swapping a defective RAM module for a better performing one does not substantially modify a server, because compliance with the essential requirements is unaffected and the improved performance stays within the intended use already considered in the risk assessment.

Example 39 confirms the exemption does not depend on how deep in the assembly the replacement sits. Where a programmable logic controller's CPU fails, supplying either an identical CPU or an identical complete PLC as a spare part falls within Article 2(6), provided it goes through the after-sales channel and the system it is intended for is clearly identified.

#### The counter-example that did not survive to adoption
The March 2026 consultation draft carried a second physical repair example immediately after the RAM case. It described a similar operation that significantly changed the server's behaviour by altering how core functions are executed, a change the original risk assessment had not considered, and concluded the server was substantially modified.

That example is not in the adopted text. The rule it illustrated survives at point 95, so the deletion narrows the illustration rather than the rule. It is reproduced below because readers working from the draft will remember it, and because it is the clearest statement of what a repair has to do before it crosses the line.

#### Example 35 (Section 4.1 Physical repairs, point 95, page 32)
Verdict (CVD Portal): Not a substantial modification. Better-performing RAM, still inside the assessed intended use

The manufacturer of a computer server performs a repair operation, switching out a defective RAM with a new, better performing one. The server's compliance with the essential requirements is not affected. The server performs better, but its new performance remains within the server's intended use as considered in the cybersecurity risk assessment. The computer server is not considered to be substantially modified.

#### Example 36 (Section 4.2 Spare parts, point 101, page 33)
Verdict (CVD Portal): Exempt under Article 2(6). An identical replacement module, whether the host product predates the CRA or not

A manufacturer has placed connected controllers on the EU market. In one case, the controller was placed on the market in 2026, before the date of application of the CRA. In another case, the controller was placed on the market in 2028, in compliance with the CRA. In 2028, a digital communication module in both types of controllers fails. The manufacturer supplies as a spare part a replacement module that is identical and manufactured according to the same specifications as the original.

In both cases, the replacement module falls within the scope of the exemption in Article 2(6). The spare part is not itself subject to the CRA, even though it is a product with digital elements, because it replaces an identical component in a product with digital elements. The repair does not constitute a substantial modification of the product with digital elements.

#### Example 37 (Section 4.2 Spare parts, point 101, page 34)
Verdict (CVD Portal): Not exempt. Different cryptographic implementation and secure boot means the part is not identical

A manufacturer placed a connected industrial controller on the EU market in 2026, before the date of application of the CRA. In 2028, a communication chip in that controller fails. As the manufacturer no longer manufactures that chip, it supplies as a spare part a newer chip with equivalent functionality, but with a different cryptographic implementation and updated secure boot mechanism, in order to maintain compatibility and continued operation.

In this case, the replacement chip cannot be considered identical, as the differences in the cryptographic implementation and secure boot mechanism affect the chip's cybersecurity properties. It therefore does not benefit from the exemption in Article 2(6) and constitutes a product with digital elements subject to the CRA. Compliance of the replacement part must be assessed in light of its intended purpose, including its role in ensuring interoperability with the product with digital elements placed on the market before the CRA entered into application.

#### Example 38 (Section 4.2 Spare parts, point 101, page 34)
Verdict (CVD Portal): Exempt. A different chipset can still be identical where the security mechanisms are unchanged

A manufacturer places on the market a smart building controller in 2028 in compliance with the CRA. In 2029, the wireless module in that controller fails. As the manufacturer no longer manufactures that module, it supplies as a spare part a new module that performs the same function using the same communication protocols and security mechanisms, but is based on a different chipset and has updated firmware that does not alter characteristics that may be relevant to cybersecurity.

In this case, the replacement module can be considered identical. The module therefore benefits from the exemption in Article 2(6) and is not subject to the CRA.

#### Example 39 (Section 4.2 Spare parts, point 102, page 34)
Verdict (CVD Portal): Exempt either way. The exemption applies whether the spare part is a component or the whole subassembly

In 2027, a manufacturer places on the market an industrial automation system that incorporates a programmable logic controller (PLC) as one of its components. In 2031, the PLC's central processing unit (CPU) fails. The manufacturer offers two repair options: (i) the supply of a replacement CPU unit, which can be considered identical to the CPU originally installed; or (ii) the supply of a complete replacement PLC, which can be considered identical to the PLC originally installed. In each case, the replacement is supplied through the manufacturer's after-sales service channel as a spare part, and the industrial automation system for which the replacement is intended is clearly identified. In both cases, the replacement falls within the scope of the exemption in Article 2(6), whether the replacement concerns a component within the PLC, or the PLC as a whole.

#### 4.1 Physical repairs (earlier draft only) (Section 4.1 Physical repairs (earlier draft only), point 90, page 28)
Verdict (CVD Portal): Deleted before adoption. The draft's counter-example, a repair that does amount to a substantial modification

The manufacturer of the computer server performs a similar operation as in example 1, but the operation leads to a significant change in the server's behaviour by altering the way core functions are executed. The manufacturer had not considered the server's new behaviour in its original risk assessment, thereby potentially affecting the product's compliance with the essential requirement. The computer server is considered to be substantially modified.

### Which software updates has the Commission called substantial modifications?
URL: https://cvdportal.com/cra-guidance/examples/substantial-modification-worked-examples
Last reviewed: 2026-07-27

The Commission tests a software update by its effect on the cybersecurity risk profile rather than by its size. A persistent login feature storing authentication tokens locally is a substantial modification. So is a diagnostics export that leaves sensitive operational data unencrypted. Enabling control features that shipped disabled but assessed is not, and neither is group messaging the original assessment anticipated. Security updates generally fall outside, until they change the intended purpose or add new external dependencies.

A substantially modified product is treated as a new product and constitutes a new placing on the market. The reassessment focuses on the modified parts, and existing documentation may be reused for the rest.

#### Size is not the test
Article 3, point (30) defines a substantial modification as a change after placing on the market that affects compliance with the essential requirements in Part I of Annex I, or that modifies the intended purpose for which the product was assessed.

Point 107 of the guidance is explicit that the assessment should not be based on the scale or complexity of the change but on its potential adverse impact on the cybersecurity risk profile. Examples 44 and 45 make that concrete. A remember me feature storing authentication tokens locally is limited in scope and is still a substantial modification, because it introduces token theft, unauthorised access and session hijacking risks nobody assessed. A logging and diagnostics export is minor on its face and is still a substantial modification, because it ends up storing sensitive operational data unencrypted.

#### What the original risk assessment already covers stays outside
Examples 42 and 43 are the reward for a thorough original assessment. Group messaging with administrator controls and moderation tools is not a substantial modification where the assessment already covered its later introduction, including the increased complexity of message routing. Enabling automated control loops that shipped present but disabled is not a substantial modification where the assessment explicitly covered their future activation, the closed-loop risks and the safeguards.

Examples 40 and 41 show the other end. A monitoring dashboard that gains the ability to adjust operating parameters and restart machines has moved from situational awareness to operational control. A personal data organiser that starts generating behavioural profiles and making automated decisions without user intervention has become an automated decision-making system. In both the intended purpose evolved beyond what the assessment envisaged.

#### The security update carve-out and where it stops
Recital 39 and point 108 keep security updates outside, even where they are technically significant. Fixing an input validation error or an authentication bypass sits inside the carve-out. So does hardening configuration, including tightening firewall rules, disabling unused ports, changing default administrator password policies and making multi-factor authentication mandatory where the functionality already existed. So does disabling a deprecated cryptographic algorithm in favour of a stronger one the original assessment already covered.

Point 109 closes the carve-out where the update modifies the intended purpose beyond what was foreseen or introduces new or increased risk. Replacing local file encryption with a remote service operated by the manufacturer qualifies as a substantial modification, and so does swapping an internally managed key lifecycle for a third-party key management service. Both are security-driven. Both materially alter data flows or add externally reachable interfaces nobody assessed.

#### Integration is not modification
Example 51 answers a question integrators ask constantly. A company that buys off-the-shelf microcontroller modules and connectivity components, writes its own firmware and a sensor package, and assembles a connected agricultural monitor placed on the market under its own name is not substantially modifying anything. It is placing a new product on the market, and it owns compliance for that product as a whole.

Where someone other than the original manufacturer genuinely does modify a product already on the market, Articles 21 and 22 make them the manufacturer, with obligations limited to the modified part where the change does not negatively affect the cybersecurity of the product as a whole.

#### Example 40 (Section 4.3 Software updates as substantial modifications, point 105, page 35)
Verdict (CVD Portal): Substantial modification. Monitoring dashboard gains operational control over the machines

A manufacturer places on the market a dashboard that collects data from machines and displays trends and alerts, without having the ability to control such machines. The manufacturer subsequently develops a new version of that dashboard, introducing functionalities that enable it to control the machines, including by adjusting operating parameters and restarting machines following fault conditions. As a result of these changes, the dashboard's intended purpose has evolved beyond what was envisaged in the risk assessment, shifting from a situational awareness tool to a product with digital elements intended to exercise operational control over other devices. The dashboard has therefore been substantially modified.

#### Example 41 (Section 4.3 Software updates as substantial modifications, point 105, page 35)
Verdict (CVD Portal): Substantial modification. A user-controlled tool becomes an automated decision-making system

A manufacturer places on the market a consumer software application intended to organise and display personal data, such as emails, messages, or documents, and to support basic search and filtering functions. The manufacturer subsequently introduces an update that enables the application to automatically analyse user content in order to generate behavioural profiles and make automated decisions affecting the prioritisation, suppression, or recommendation of content without user intervention. As a result of this change, the software's intended purpose shifts from a user-controlled information management tool to an automated decision-making system, which was not envisaged in the risk assessment. The application has therefore been substantially modified.

#### Example 42 (Section 4.3 Software updates as substantial modifications, point 106, page 36)
Verdict (CVD Portal): Not a substantial modification. Group messaging was already inside the original risk assessment

A messaging application is initially released with functionality limited to one-to-one messaging. The manufacturer's risk assessment covers the later introduction of group messaging, including for example the increased complexity of message routing. In a subsequent update, the manufacturer adds a group chat functionality together with administrator controls and moderation tools that were already foreseen and assessed in the original design. The update implements functionalities that fall within the scope of the original intended purpose and risk assessment. The messaging application has therefore not been substantially modified.

#### Example 43 (Section 4.3 Software updates as substantial modifications, point 106, page 36)
Verdict (CVD Portal): Not a substantial modification. Enabling control features that shipped disabled but assessed

A production monitoring system is placed on the market with read-only dashboards enabled, while automated control features are present in the system architecture but remain disabled. The manufacturer's risk assessment explicitly covers the future activation of automated control loops, including the cybersecurity risks associated with closed-loop control, as well as safeguards such as operator override mechanisms and fail-safe states. In a later update, the manufacturer enables the automated control features and activates the safeguards as originally assessed. The production monitoring system has therefore not been substantially modified.

#### Example 44 (Section 4.3 Software updates as substantial modifications, point 107, page 36)
Verdict (CVD Portal): Substantial modification. A small convenience feature introducing token theft and session hijacking risk

A manufacturer introduces an update to a software application adding a 'remember me' or persistent login feature that stores authentication tokens locally to improve user convenience. Although the functionality is limited in scope, it introduces new risks related to token theft, unauthorised access, and session hijacking that were not considered in the risk assessment. The update therefore affects compliance with the essential requirements. The software application has been substantially modified.

#### Example 45 (Section 4.3 Software updates as substantial modifications, point 107, page 36)
Verdict (CVD Portal): Substantial modification. Diagnostics logging that stores sensitive operational data unencrypted

A manufacturer adds a new logging and diagnostics feature to an existing software product with digital elements, enabling detailed system logs to be exported for troubleshooting purposes. While the functionality appears minor, it results in the collection and storage of sensitive operational data in an unencrypted format, introducing risks of data exposure that were not previously assessed or mitigated. The change may therefore have a significant impact on the cybersecurity risk profile of the product with digital elements. The software product with digital elements has been substantially modified.

#### Example 46 (Section 4.3 Software updates as substantial modifications, point 108, page 37)
Verdict (CVD Portal): Not a substantial modification. A security update fixing a buffer overflow or an authentication bypass

A manufacturer deploys a security update to address a vulnerability in the codebase of a product with digital elements by correcting an input validation error that could lead to a buffer overflow, or by fixing a logic flaw allowing authentication bypass through improper session token validation. The update modifies the internal implementation of the software without affecting that product's intended purpose or introducing new exposure. Such an update is intended exclusively to reduce the cybersecurity risk. The security update should not be considered a substantial modification.

#### Example 47 (Section 4.3 Software updates as substantial modifications, point 108, page 37)
Verdict (CVD Portal): Not a substantial modification. Hardening configuration, even where users must change how they access the product

A manufacturer introduces a security update that strengthens existing security configurations, such as tightening firewall rules, disabling unused network ports, changing default administrator password policies, or making multi-factor authentication mandatory where such functionality was already available or foreseen. Although the update may affect how users configure or access the product with digital elements, it does not alter its intended purpose and serves solely to enhance its security posture. The security update should not be considered a substantial modification.

#### Example 48 (Section 4.3 Software updates as substantial modifications, point 108, page 37)
Verdict (CVD Portal): Not a substantial modification. Deprecating an algorithm the original risk assessment already anticipated

A manufacturer places on the market a software product with digital elements that secures communications using a configurable encryption framework supporting multiple cryptographic algorithms and key sizes, as described in the product's technical documentation and risk assessment. The risk assessment covers all the cryptographic options provided in the product with digital elements and anticipates the future deprecation of certain algorithms. The risk assessment also includes mitigation measures, such as cryptographic agility, internal key management, and compatibility testing. In response to emerging cryptographic guidance, the manufacturer deploys a security update that disables a deprecated algorithm and activates a stronger, already supported alternative, without introducing new external dependencies or altering data flows. As the update implements a security measure that was foreseen and assessed as part of the original design, and it does not introduce new cybersecurity risks, the security update should not be considered a substantial modification.

#### Example 49 (Section 4.3 Software updates as substantial modifications, point 109, page 38)
Verdict (CVD Portal): Substantial modification despite the security motive. Local encryption replaced by a remote service

A manufacturer places on the market a software product with digital elements intended to provide local file encryption for data stored on a user's device, enabling users to encrypt and decrypt files on demand. Following the discovery of a vulnerability in the encryption workflow, the manufacturer deploys a security update that removes local encryption functionality and instead requires all files to be uploaded to, stored in, and processed by a remote encryption service operated by the manufacturer. As a result of this change, the product with digital elements no longer performs local encryption as originally intended, instead functioning as a remote encryption and data processing service. Although the update is introduced for security reasons, it fundamentally alters that product's intended purpose in a manner not foreseen in the risk assessment and therefore qualifies as a substantial modification.

#### Example 50 (Section 4.3 Software updates as substantial modifications, point 109, page 38)
Verdict (CVD Portal): Substantial modification despite the security motive. A new dependency on a third-party key management service

A manufacturer places on the market a software product with digital elements that relies on an established encryption protocol and an internally managed key lifecycle to secure communications between components of the product with digital elements. In response to newly identified cryptographic weaknesses, the manufacturer introduces a security update that replaces the existing encryption mechanism with a different protocol requiring the use of an external key management service operated by a third party. As a result of this change, the dependencies and data flows of the product with digital elements are materially altered, introducing new external interfaces and reliance on third-party services not considered in the risk assessment. Although the update is security-driven, it introduces new cybersecurity risks, and therefore qualifies as a substantial modification.

#### Example 51 (Section 4.4.1 Substantial modifications carried out by a person other than the original manufacturer, point 120, page 41)
Verdict (CVD Portal): Not a modification at all. Integrating third-party components into a new product makes you its manufacturer

A company purchases off-the-shelf microcontroller modules and connectivity components from third-party suppliers, develops proprietary firmware and a sensor package, and assembles them into a connected agricultural monitoring product with digital elements that it places on the market under its own name. Although the company has modified the underlying microcontroller modules and combined them with other components, it is not substantially modifying a product with digital elements already placed on the market; rather, it is placing a new product with digital elements on the market. The company is the manufacturer of the agricultural monitor for the purposes of the CRA and is required to comply with the Regulation in respect of the agricultural monitor as a whole.

### What counts as a product with digital elements under the Cyber Resilience Act?
URL: https://cvdportal.com/cra-guidance/examples/what-counts-as-a-product-with-digital-elements
Last reviewed: 2026-07-27

The Cyber Resilience Act reaches software that is supplied to a user and executes on that user's device. A mobile application, a desktop application built with web technologies, and source code licensed in a text file are all products with digital elements. A web application used only through a browser is not, unless it supports the functionality of a product that is. Hardware and software that cannot deliver their purpose without each other form one product, even when they are supplied through different channels.

Scope also requires the supply to be in the course of a commercial activity. The examples below settle what a product is, not whether your supply of it is commercial.

#### Every copy of a version is placed on the market on the same day
Article 3, point (21) defines placing on the market as the first making available of a product on the Union market. The guidance applies that to software versions rather than to individual copies. A copy sold two weeks after the version was first supplied was still placed on the market on the day the version was.

This matters for the transitional dates. A version first supplied before 11 December 2027 does not become newly subject to the CRA because someone downloads it afterwards. An update that is not a substantial modification does not restart the clock either, which is what Example 2 is for.

#### The dividing line for software is where it executes
Examples 3 to 6 draw one line four times. Software supplied to the user and executing on the user's device is a product with digital elements. Software the user only reaches through a browser is not.

The packaging technology is irrelevant. A desktop application built with web technologies but installed locally is in scope, because what matters is that it is supplied and runs on the device. An informational website is out of scope entirely.

Example 5 carries the sting. If a locally installed client depends on data processing at a distance in order to perform one of its functions, that remote processing is part of the product. Moving logic to your back end does not move it out of scope.

#### Source code counts, and so do products split across two supply channels
Example 7 confirms that licensing source code in a text file is placing a product on the market, even where the licensee must adapt and compile it before use. Responsibility stops at the code as supplied. The licensee owns whatever it does next.

Examples 8 and 9 handle the case where a product arrives in two pieces. A network printer and its downloadable drivers are one product, because the printer cannot fulfil its intended purpose without them. A fitness wearable and the app that displays and configures it are one product, because they are designed and intended to operate together. Different distribution channels do not create different products.

#### Being in scope of the CRA does not put you out of scope of anything else
Version 1.3 of the Commission's FAQs adds a scope example the guidance does not. Software procured by a hospital to store and view patient summaries can be a product with digital elements under the CRA and an EHR system under the European Health Data Space Regulation at the same time.

Overlap is the norm rather than the exception. Article 26(2) required the guidance to address the interplay between the CRA and other Union law, and the Commission has signalled that further guidance may follow on the AI Act and DORA.

#### Example 1 (Section 2.1 Placing on the market, point 14, page 8)
Verdict (CVD Portal): Every copy of a version is placed on the market on the day that version is first supplied

On 1 January 2028, company A first supplies for distribution via its website version 1.0.0 of its software X. On the same day, customer 1 purchases a copy of version 1.0.0 of software X. On 15 January 2028, customer 2 purchases a copy of version 1.0.0 of software X. Both copies of version 1.0.0 of software X are placed on the market on 1 January 2028.

#### Example 2 (Section 2.1 Placing on the market, point 15, page 8)
Verdict (CVD Portal): An update that is not a substantial modification does not create a new placing on the market

On 1 January 2028, company A first supplies for distribution via its website version 1.0.0 of software X. On the same day, customer 1 purchases a copy of version 1.0.0 of software X. On 15 January 2028, company A issues an updated version 1.0.1 of software X that does not constitute a substantial modification. On 30 January 2028, customer 2 purchases a copy of version 1.0.1 of software X. Both copies of version 1.0.0 and 1.0.1 of software X are considered to be placed on the market on 1 January 2028.

#### Example 3 (Section 2.2 Software as a product with digital elements, point 21, page 10)
Verdict (CVD Portal): In scope. A mobile app executes on the user's device

a mobile application that a user downloads from an app store and installs on their smartphone is supplied to the user and executes on the user's device and is therefore a product with digital elements. Where it is placed on the market in the course of a commercial activity, it may fall within the scope of the CRA.

#### Example 4 (Section 2.2 Software as a product with digital elements, point 21, page 10)
Verdict (CVD Portal): In scope. Web technology packaged for local installation is still local software

a desktop application built using web technologies but packaged for local installation is supplied to the user and executes on the user's device, and is therefore a product with digital elements. Where it is placed on the market in the course of a commercial activity, it may fall within the scope of the CRA.

#### Example 5 (Section 2.2 Software as a product with digital elements, point 21, page 10)
Verdict (CVD Portal): Browser-only web application is out of scope. A local client is in scope, and pulls its remote data processing with it

a web application accessed by the user exclusively through a web browser is not a product with digital elements. Unless it supports the functionality of a product with digital elements, it does not fall within the scope of the CRA. By contrast, an application supplied to the user as a locally installed client that executes on the user's device is a product with digital elements. Where it is placed on the market in the course of a commercial activity, it may fall within the scope of the CRA. If that client relies, in order to perform one or more of its functions, on data processing at a distance which meets the definition of remote data processing, that data processing at a distance is also part of the product with digital elements.

#### Example 6 (Section 2.2 Software as a product with digital elements, point 21, page 10)
Verdict (CVD Portal): Out of scope. An informational website is not a product with digital elements

a website that merely presents information to its visitors and does not support the functionality of a product with digital elements is not itself a product with digital elements. It therefore does not fall within the scope of the CRA.

#### Example 7 (Section 2.3 Computer code, point 24, page 11)
Verdict (CVD Portal): Licensing source code is placing it on the market, even before compilation

Company A licences source code to company B for a customisable internal platform, and provides that source code in a text file. Even if that source code requires further adaptation and compilation by company B before being used, company A is placing that source code on the market and is therefore subject to the CRA. Company A is not responsible for the compliance with the CRA of company B's subsequent adaptations and compilation of that code.

#### Example 8 (Section 2.4 Combination of hardware and software forming a product with digital elements, point 25, page 11)
Verdict (CVD Portal): Printer plus separately downloaded drivers is one product

A network printer is placed on the market as a hardware product with digital elements, while the software drivers required to send print jobs, configure the device and manage its operation are made available for download from the manufacturer's website. Although the printer and the drivers are supplied through different channels, they together constitute a single product with digital elements, because the printer cannot fulfil its intended purpose without the drivers.

#### Example 9 (Section 2.4 Combination of hardware and software forming a product with digital elements, point 25, page 12)
Verdict (CVD Portal): Wearable plus companion app is one product

A fitness wearable is placed on the market to measure a user's heart rate and activity, while a smartphone application provided by the manufacturer is required to display the measurements, show history and allow configuration of the device. Although the application is downloaded separately through an app store, the wearable and the application together constitute a single product with digital elements, because they are designed and intended to operate together to deliver the functionality of the product with digital elements.

#### 2.7.1 What is the interplay between the CRA and the European Health Data Space Regulation? (Section 2.7.1 What is the interplay between the CRA and the European Health Data Space Regulation?, page 19)
Verdict (CVD Portal): One product can be both a product with digital elements and an EHR system

A computer or a software that has been marketed and procured by a hospital designed for storing and viewing patient summaries while delivering healthcare services, could be a product with digital elements within the meaning of the CRA that is also an EHR system, within the meaning of the EHDS Regulation.

### When is open source software supplied in the course of a commercial activity?
URL: https://cvdportal.com/cra-guidance/examples/when-open-source-falls-under-the-cra
Last reviewed: 2026-07-27

The Cyber Resilience Act reaches free and open-source software only where it is supplied in the course of a commercial activity. The Commission's twenty-two examples locate that line. Charging for a paid version, gating releases or security fixes behind donations, monetising what is sold through the software, and requiring unrelated personal data processing all cross it. Voluntary donations, separately sold consultancy, funded features released openly, and contributing to someone else's project do not.

Falling outside placing on the market does not always mean falling outside the CRA. A publisher who supports a component others integrate may be a steward under Article 24.

#### What makes the supply commercial
Recital 18 applies the commercial activity test to the supply of the software rather than to how the project was developed or financed. Examples 14 to 22 work through the ways a supply becomes commercial without anyone charging for the software itself.

Monetising what flows through the application counts. A free marketplace app earning advertising, commission or subscription revenue is commercial, and so is a free VPN selling access to extra servers. Requiring users to accept personal data processing for advertising or unrelated analytics counts as well.

Support services split the two ways. Selling a paid edition of the operating system that bundles technical assistance is commercial. Selling optional consultancy alongside a freely available command line tool is not.

#### Donations turn on whether they gate access
Three examples settle the donations question that dominated the consultation. Example 20 confirms that inviting voluntary donations changes nothing where access to the software, its source and its updates is unconditional.

Examples 21 and 22 draw the other side. Providing downloadable releases and security updates only to donors makes the donation a de facto condition of access, which amounts to charging a price. Publishing the source publicly while reserving pre-compiled binaries, regular updates and guaranteed security fixes for donors does the same, because donations then buy access to essential aspects of the product.

#### Stewards, manufacturers and everyone else
Examples 24 to 34 sort the roles. A publisher who provides sustained support for a component intended for integration into other products, without monetising the supply, is a steward under Article 24. That covers a not-for-profit foundation, a company publishing an unmonetised library it also uses itself, and a not-for-profit publishing an SDK funded by membership fees.

A publisher who sells a paid version with benefits is a manufacturer, whatever outside contributors do.

Everyone else is generally outside. Contributors submitting pull requests have no obligations, because they exercise no primary control over releases or distribution. A manufacturer funding a feature that is released openly does not become the manufacturer of the project. Package repositories have no obligations for what they host. In every one of these scenarios the integrator still owes due diligence under Article 13(5).

#### Example 13 (Section 3.1 Determining if free and open-source software is under one's responsibility, point 49, page 19)
Verdict (CVD Portal): A contributor sending a pull request is not subject to the CRA

An individual developer or an employee of a company submits a 'pull' or 'merge' request containing a security patch or a new feature to a FOSS project. The project's maintainers review, accept and merge the code into the main repository, subsequently including it in a new release. In this scenario, the person who submitted the pull request is a 'contributor' and is not subject to the CRA. Although that person contributed source code, they do not exercise primary control over the development, releases or distribution decisions.

#### Example 14 (Section 3.2.2 Monetisation of other services or requiring the processing of personal data, point 54, page 20)
Verdict (CVD Portal): Commercial. A free marketplace app that monetises what is sold through it

A natural or legal person publishes a free and open-source marketplace application. The application is available free of charge and enables users to purchase goods or services through it. The app allows the person that published it to monetise other products with digital elements and services offered through it (e.g. through advertisements, commission fees or subscription fees). Therefore, the application is considered placed on the market in the course of a commercial activity.

#### Example 15 (Section 3.2.2 Monetisation of other services or requiring the processing of personal data, point 54, page 20)
Verdict (CVD Portal): Commercial. A free VPN with paid servers or dedicated addresses

A natural or legal person publishes a free and open-source VPN. The application is available free of charge, but it enables users to pay to access additional servers or dedicated IP addresses. That application allows that person to monetise other services offered through it, therefore it is considered placed on the market in the course of a commercial activity.

#### Example 16 (Section 3.2.2 Monetisation of other services or requiring the processing of personal data, point 54, page 20)
Verdict (CVD Portal): Commercial. Use conditional on personal data processing unrelated to security or interoperability

A natural or legal person publishes a free and open-source fitness tracking application. The application is available free of charge, but its use is conditional upon the processing of users' personal data for purposes such as targeted advertising or analytics unrelated to the security, compatibility or interoperability of the software. By requiring such data processing as a condition for use, the application is therefore considered placed on the market in the course of a commercial activity.

#### Example 17 (Section 3.2.3 Support services, point 57, page 21)
Verdict (CVD Portal): Commercial. A paid version of the operating system bundling support

A natural or legal person publishes a free and open-source operating system, offering a paid version of that operating system which includes support services, such as technical assistance or performance optimisation. The paid version of the operating system is considered placed on the market in the course of a commercial activity.

#### Example 18 (Section 3.2.3 Support services, point 57, page 21)
Verdict (CVD Portal): Not commercial. Optional consultancy sold separately from the software

A natural or legal person publishes a free and open-source command line tool. The tool is freely accessible and anyone can download and install it. That natural or legal person separately offers professional services, such as optional consultancy services to train users and support them in installing and using the tool. That FOSS is not considered placed on the market within the meaning of the CRA.

#### Example 19 (Section 3.2.3 Support services, point 59, page 22)
Verdict (CVD Portal): Not placing on the market. Installing someone else's FOSS for a customer without substantially modifying it

A service provider does not publish a FOSS, but helps a customer install it on the customer's on-premises server. It does so without performing a substantial modification of that FOSS. The service provider is therefore not considered to be placing the FOSS on the market.

#### Example 20 (Section 3.2.4 Donations, point 61, page 22)
Verdict (CVD Portal): Not commercial. Voluntary donations with unconditional access to the software

A natural or legal person publishes a FOSS tool in a public online repository, allowing anyone to download, use, modify and redistribute it under a free and open-source licence. The publisher invites users to make voluntary donations via a donation platform to support the project's continued development and maintenance. Access to the software, its source code and its updates is not conditional on making a donation. That FOSS is not considered to be supplied in the course of a commercial activity and is not considered to be placed on the market within the meaning of the CRA.

#### Example 21 (Section 3.2.4 Donations, point 62, page 22)
Verdict (CVD Portal): Commercial. Donations gate the releases and the security updates

A natural or legal person publishes a software product with digital elements under a free and open-source licence, but provides downloadable releases and security updates only to users who make a donation. Users who do not make a donation do not have access to the software's current version.

In this case, the donations are de facto a condition for access to the product with digital elements and therefore amount to charging a price. That FOSS is therefore considered to be placed on the market within the meaning of the CRA.

#### Example 22 (Section 3.2.4 Donations, point 62, page 23)
Verdict (CVD Portal): Commercial. Source is public but binaries, updates and fixes are donor-only

A natural or legal person makes the source code of a FOSS publicly available, but provides pre-compiled binaries, regular updates and guaranteed security fixes only to donors. In this case, the donations are linked to access to essential aspects of the product with digital elements and constitute remuneration for that product's supply. That FOSS is therefore considered to be placed on the market in the course of a commercial activity.

#### Example 23 (Section 3.2.5 Financing of free and open-source software, point 65, page 23)
Verdict (CVD Portal): Not placing on the market. A manufacturer funding a feature that is released openly to everyone

An individual developer publishes a FOSS project and actively maintains it. Manufacturer A requests that the individual developer add a specific feature for that FOSS, and funds that development. The developer adds the feature to the FOSS codebase, openly sharing it and making it freely available for all to access, use, modify and redistribute. The individual developer is not considered to have placed that FOSS on the market. If the manufacturer integrates the FOSS into its product with digital elements, it needs to exercise due diligence in accordance with Article 13(5).

#### Example 24 (Section 3.2.6 Not-for-profit entities set up to achieve not-for-profit objectives, point 66, page 24)
Verdict (CVD Portal): Steward, not manufacturer. Direct monetisation, but all earnings after costs go to not-for-profit objectives

A legal person publishes a free and open-source browser that is directly monetised via search engine partnerships, but all its earnings after costs are used for not-for-profit objectives. The browser is not considered to be placed on the market within the meaning of the CRA. The legal person publishing it is subject to the obligations applicable to stewards.

#### Example 25 (Section 3.2.7 Integration by other manufacturers, point 68, page 24)
Verdict (CVD Portal): Steward. A published library the publisher also integrates into its own product

A legal person publishes a FOSS library for building user interfaces. It does not monetise the supply of that library, but integrates it into one of its products with digital elements (which is in turn placed on the market). The library is not considered placed on the market within the meaning of the CRA, but it is intended for integration into products with digital elements. The legal person that publishes it is its steward.

#### Example 26 (Section 3.2.7 Integration by other manufacturers, point 68, page 24)
Verdict (CVD Portal): Steward. Reference implementations published alongside a commercial operating system

A legal person places an operating system on the market, and also publishes FOSS libraries to serve as reference implementations for users of that operating system. The legal person does not monetise the FOSS libraries, which are intended for integration into other products with digital elements. The legal person that publishes them is a steward to those FOSS libraries.

#### Example 27 (Section 3.5 Illustrative scenarios, point 89, page 28)
Verdict (CVD Portal): No obligations at all for the developer. Donations from integrators do not make the supply commercial

Individual developer A has developed a FOSS. Developer A publishes that FOSS under its own name or trademark, but does not charge a price for its use. The software is openly shared and freely available for all to access, use, modify and redistribute. Developer A also includes a link to a platform to collect voluntary donations.

Companies B, C and D integrate that FOSS into their own products with digital elements. To support ongoing maintenance, companies B, C and D make voluntary donations to developer A. These donations enable developer A to keep the project actively maintained.

That FOSS is not placed on the market within the meaning of the CRA. Developer A has no obligations under the CRA. Companies B, C, and D are to exercise due diligence in accordance with Article 13(5) when integrating that FOSS into their own products with digital elements.

#### Example 28 (Section 3.5 Illustrative scenarios, point 89, page 28)
Verdict (CVD Portal): Steward. A not-for-profit foundation providing sustained support to a component others integrate

Not-for-profit foundation F publishes a FOSS component for integration into other commercial products with digital elements. Foundation F commits to providing sustained support to that FOSS, to ensure its viability and uptake. Companies A, B and C integrate that FOSS into their own products with digital elements. Companies A and B voluntarily contribute some of their developers' time to development and maintenance of FOSS projects within foundation F, including for that FOSS.

As foundation F is a not-for-profit entity set up in such a way that its earnings after costs are used to achieve not-for-profit objectives, the FOSS is not considered to be placed on the market within the meaning of the CRA. Foundation F is the FOSS steward and is subject to the corresponding obligations laid down in Article 24. Companies A, B and C are to exercise due diligence in accordance with Article 13(5) when integrating that FOSS into their own products with digital elements.

#### Example 29 (Section 3.5 Illustrative scenarios, point 89, page 28)
Verdict (CVD Portal): Steward, not manufacturer. A company publishing an unmonetised component it also uses itself

Company A has developed a FOSS component for integration into its own products with digital elements. It also publishes that FOSS separately under its own name or trademark and actively maintains it. However, it does not charge for its use or monetise in other ways. Companies B, C and D integrate that FOSS into their own products with digital elements, and voluntarily contribute some of their developers' time to its maintenance.

That FOSS is not considered to be placed on the market within the meaning of the CRA. Company A is not its manufacturer, but is its steward. Companies B, C, and D are to exercise due diligence in accordance with Article 13(5) when integrating the FOSS into their own products with digital elements.

#### Example 30 (Section 3.5 Illustrative scenarios, point 89, page 28)
Verdict (CVD Portal): Manufacturer. A paid version with benefits, notwithstanding outside contributors

Company A publishes a FOSS under its own name or trademark and offers it as a paid version, which includes certain benefits such as technical assistance or performance optimisation. Developers from companies B, C and D contribute to the FOSS's maintenance, but it remains under the control of company A.

Company A is considered a manufacturer to that FOSS. Companies B, C and D are not subject to obligations under the CRA for that specific FOSS. If they integrate that FOSS into their own products with digital elements, they are required to exercise due diligence in accordance with Article 13(5).

#### Example 31 (Section 3.5 Illustrative scenarios, point 89, page 29)
Verdict (CVD Portal): Steward. Support services sold independently by a contributor create no obligations for that contributor

Company A publishes a FOSS under its own name or trademark and provides ongoing maintenance to ensure its long-term viability, to enable that software to be integrated into other companies' products with digital elements. Company A does not charge for its use, process personal data it collects through the product with digital elements, or sell support services associated with publishing the FOSS.

Company B contributes code and developers' time to the FOSS's maintenance, but does not distribute it commercially. Company B offers technical support services independently from the FOSS's distribution. Company A is deemed to be the steward for that FOSS, whereas company B has no obligations under the CRA for that FOSS.

#### Example 32 (Section 3.5 Illustrative scenarios, point 89, page 29)
Verdict (CVD Portal): Steward. Funding a feature does not make the funder the manufacturer of the component

A FOSS component is published by a not-for-profit entity set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives. The entity provides sustained support to ensure the project's long-term viability. Maintenance is financed through public funding, such as research grants. Additional developments, including new features, are funded through donations and specific projects, carried out in partnership with manufacturers that integrate that FOSS into their products with digital elements. Such features are incorporated into the FOSS's codebase.

The not-for-profit entity that publishes the FOSS is deemed the steward for that FOSS component. A manufacturer that has contributed to the development of certain features does not become the manufacturer of that FOSS component. Where the manufacturer integrates that FOSS component into its own product with digital elements, it needs to exercise due diligence in accordance with Article 13(5).

#### Example 33 (Section 3.5 Illustrative scenarios, point 89, page 29)
Verdict (CVD Portal): Steward. Membership fees and seconded developers do not shift responsibility to the members

A not-for-profit entity set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives publishes a FOSS software development kit (SDK) and ensures its ongoing maintenance. The SDK is openly shared and is freely available for all to access, use, modify and redistribute. Funding is provided through membership fees paid to the not-for-profit entity, and developers employed by member organisations contribute code and other resources to the SDK's development. Manufacturers use the SDK as a component to build other products with digital elements.

The not-for-profit entity that publishes that SDK is the steward for it. The foundation's members are not responsible for the SDK's compliance with the CRA. Where manufacturers use the SDK to build their own product with digital elements, they need to exercise due diligence in accordance with Article 13(5).

#### Example 34 (Section 3.5 Illustrative scenarios, point 89, page 30)
Verdict (CVD Portal): No obligations for the developer or the package repository. Due diligence sits with the integrator

An individual developer publishes a FOSS library on a public package repository for a given programming language and actively maintains it. In the package documentation, the developer adds a link to collect donations. A manufacturer downloads that library from the repository for free and integrates it into its own product with digital elements.

The individual developer and the package repository do not have any obligations under the CRA. The manufacturer that integrates the library needs to exercise due diligence in accordance with Article 13(5).

## CRA article explainers

### Essential Cybersecurity Requirements for Products with Digital Elements
URL: https://cvdportal.com/cra/annex-i

Annex I of the EU Cyber Resilience Act lists the essential cybersecurity requirements every product with digital elements must satisfy for CE marking and EU market access from 11 December 2027. It covers two sets of requirements: Part I covers product security properties (design and development), and Part II covers vulnerability handling processes (post-market obligations).

#### Structure: Part I and Part II
Annex I is divided into two parts:

**Part I - Product Properties**: Security requirements that must be built into the product before it is placed on the market. These are engineering and design requirements.

**Part II - Vulnerability Handling**: Post-market obligations for how manufacturers manage vulnerabilities discovered after the product is sold. These are operational and process requirements.

Both parts are mandatory for all in-scope products. Part I determines whether a product can receive CE marking. Part II governs ongoing obligations throughout the product's supported life.

#### Part I: Product Security Properties (Design Requirements)
Part I requires that products be designed and developed to:

1. **No known exploitable vulnerabilities** - Products must be placed on the market without known vulnerabilities that could be exploited.
2. **Secure default configurations** - Default settings must be secure; insecure defaults must be opt-in, not opt-out.
3. **Protection against unauthorised access** - Authentication, access controls, and least-privilege principles must be implemented.
4. **Data protection** - Personal and sensitive data must be protected at rest and in transit using appropriate cryptography.
5. **Attack surface minimisation** - Unnecessary interfaces, ports, and services must be disabled or removed.
6. **Availability protection** - Products must be resilient against denial-of-service attacks.
7. **Limited data collection** - Products must collect only the minimum data necessary for their function (data minimisation).
8. **Auditability** - Security-relevant events must be logged in a way that supports incident investigation.
9. **Secure update capability** - Products must support a mechanism for receiving and verifying security updates.

#### Part II: Vulnerability Handling Requirements
Part II sets out what manufacturers must do after a product is on the market:

1. **CVD policy** - Maintain a publicly accessible coordinated vulnerability disclosure policy (implements Article 13).
2. **Vulnerability remediation** - Address discovered vulnerabilities without undue delay, including distributing security updates.
3. **Disclosure of vulnerability information** - Publish information about fixed vulnerabilities, including CVE identifiers where applicable.
4. **No-charge security updates** - Security updates must be provided free of charge to users for the product's supported life.
5. **CSAF advisories** - Publish machine-readable security advisories in CSAF 2.0 format for significant vulnerabilities.
6. **Support period** - Products must have a defined security support period reflecting their expected use time, with five years as a floor rather than a default.

#### The 'No Known Vulnerabilities' Requirement
One of the most operationally significant Part I requirements is that products must be placed on the market **without known exploitable vulnerabilities**.

This does not mean products must be free of all theoretical security weaknesses. It means:
- Known vulnerabilities in third-party components (checked against CVE databases, vendor advisories, and SBOMs) must be addressed before release.
- Security testing must be conducted before placing products on the market.
- A Software Bill of Materials (SBOM) should be maintained to track component vulnerabilities.

This requirement places a practical obligation on manufacturers to perform pre-release vulnerability scanning and to maintain SBOM data for all components.

#### Secure Update Requirements
Annex I Part I(9) requires that products support a **secure update mechanism**. This means:

- Updates must be digitally signed or otherwise verifiable by the device.
- The update mechanism itself must be resistant to attack (e.g., update-in-transit attacks, rollback attacks).
- Users must be notified when security updates are available.
- For products that cannot receive over-the-air updates, there must be a documented alternative update process.

This requirement has major implications for embedded systems, industrial IoT, and medical devices where over-the-air updates are not standard practice.

#### Free Security Updates and Support Period
Annex I Part II(4) requires that **security updates be provided free of charge** throughout the product's supported life. Combined with the support period requirement, this means:

- You must define and publicly disclose the security support period for each product.
- Security patches cannot be paywalled or tied to a paid support contract.
- The support period should be commensurate with the expected use life of the product - which for many IoT and industrial products can be 10–20 years.

This requirement has significant commercial implications for manufacturers who currently monetise ongoing security support.

#### Conformity Assessment Against Annex I
To obtain CE marking for a product with digital elements, manufacturers must demonstrate conformity with Annex I requirements through one of three conformity assessment routes:

1. **Self-assessment** - Available for most products (Default Class). The manufacturer conducts and documents their own conformity assessment.
2. **Third-party audit** - Required for Important Class products (listed in Annex III). A notified body reviews the technical documentation.
3. **EU type-examination** - Required for Critical Class products. Full third-party examination of the product.

For all routes, the manufacturer must maintain a **technical file** documenting how each Annex I requirement is met.

### Information and Instructions to Users Required Under the CRA
URL: https://cvdportal.com/cra/annex-ii

Annex II defines the minimum information and instructions that manufacturers must provide to users of products with digital elements. This user-facing information package is a legally required element of CRA compliance - it enables users to assess the security properties of a product before purchase and to take appropriate action throughout the product's lifetime. Failure to provide the required information is a CRA violation subject to penalties under Article 64.

#### Mandatory User Information: What Must Be Provided
Annex II specifies the categories of information that manufacturers must provide to users. At minimum, the following must be included:

1. **Manufacturer identity and contact details**: Name, registered trade name, address, and contact point (email or website) for the manufacturer. Where an authorised representative is appointed, their details must also be included.

2. **Product identification**: The product's name, type, batch or serial number, or other identifier enabling unambiguous product identification.

3. **Intended purpose and conditions of use**: A clear description of the product's intended purpose, including the environment for which it is designed (for example, residential, commercial, or industrial use).

4. **CVD contact information**: The address or URL where vulnerability reports can be submitted - this is typically the security contact in the `security.txt` file, a dedicated security email, or a vulnerability submission portal.

5. **Support period**: The expected duration during which the manufacturer will provide security updates, expressed as a specific date or as a period from the date of purchase.

6. **Instructions for secure operation**: Guidance on how to configure the product securely, including how to change default credentials, how to enable automatic updates, and any security-relevant settings the user should be aware of.

#### The CVD Contact Requirement
Among the most operationally important Annex II requirements is the obligation to provide users with a clear, accessible means of reporting vulnerabilities. This CVD contact information must be:

- **Accurate and functional**: The email address, URL, or other contact mechanism must be monitored and operational throughout the product's support period.
- **Easily discoverable**: The contact information should be provided in the product's packaging, quick start guide, and user manual, and should be findable online through the manufacturer's website.
- **Accompanied by the CVD policy**: Ideally, the CVD contact points directly to the manufacturer's full CVD policy, which outlines the disclosure process, timelines, and safe harbour commitments.

A `security.txt` file at `/.well-known/security.txt` on the manufacturer's website is the technical standard for publishing security contact information and is strongly recommended as the primary means of fulfilling this requirement. CVD Portal can generate and host your `security.txt` file.

#### Support Period Communication
Manufacturers must communicate the support period to users clearly - ideally before purchase, so users can make informed decisions. The support period disclosure must state either:

- A specific end date (for example, 'Security updates provided until 31 December 2031'), or
- A period calculated from the purchase or first use date (for example, 'Security updates provided for five years from date of purchase')

Ambiguous or conditional support period statements (such as 'We will provide updates as long as it is commercially viable') do not meet the Annex II requirement. Users must be able to determine a concrete timeframe.

Where a manufacturer extends the support period beyond the original commitment, they should update their documentation and notify users. Where a manufacturer shortens the support period (which should only occur in exceptional circumstances), they must notify users with sufficient advance notice and provide information on alternative products.

#### Format and Accessibility of User Information
Annex II requires that user information be provided in a form that users can easily understand and access. Key format requirements include:

**Language**: Information must be in a language easily understood by users in the member state where the product is sold. For products sold across multiple member states, multi-language information packages are typically required.

**Accessibility**: Information should be available in physical form with the product (in the packaging or user manual) and also accessible online (on the manufacturer's website) for the duration of the support period. Digital-only information provision may not be adequate for all product categories.

**Plain language**: Technical security information must be expressed in terms comprehensible to the intended user audience. Consumer products must use plain consumer language; professional products may use technical terminology appropriate to the professional user base.

**Durability**: Physical documentation included with the product should be printed on materials that remain legible throughout normal product use.

#### CE Marking and Declaration of Conformity Reference
Annex II requires that user documentation include information about the CE marking and how to access the EU Declaration of Conformity. Users must be informed that the CE marking signifies compliance with applicable EU requirements, and they must be provided with a means to access the full EU Declaration of Conformity.

For most products, the DoC is made available online at a stable URL that the manufacturer maintains throughout the product's active life. The user documentation must include this URL or otherwise clearly indicate where the DoC can be obtained.

For products using the simplified declaration format (Annex IX), the abbreviated declaration included with the product must direct users to the full online declaration. The URL referenced in the simplified declaration must remain accessible for as long as the product is on the market.

### Important Products with Digital Elements - Class I and Class II Classification
URL: https://cvdportal.com/cra/annex-iii

Annex III of the EU Cyber Resilience Act lists the 'important' product categories that face stricter conformity assessment before CE marking, split into Class I (lower-risk important) and Class II (higher-risk important). Class I products can keep self-assessment only by fully applying harmonised standards, while Class II products need third-party involvement.

#### Why Annex III Matters: Three-Tier Product Classification
The CRA classifies products into three risk tiers, each with different conformity assessment requirements:

| Tier | Classification | Conformity Assessment |
|------|---------------|----------------------|
| Default | Not in Annex III or IV | Self-assessment (Module A) allowed |
| Important, Class I | Annex III Class I | Self-assessment only if harmonised standards are fully applied, otherwise third party |
| Important, Class II | Annex III Class II | Third party always required |
| Critical | Listed in Annex IV | European cybersecurity certification scheme where mandated, otherwise the Class II routes |

The split inside Annex III matters commercially. A **Class I** product keeps the self-assessment route as long as harmonised standards, common specifications, or a European cybersecurity certification scheme cover all of the applicable essential requirements. A **Class II** product loses that option outright and must involve a notified body or a certification scheme at assurance level at least substantial.

#### Annex III Class I - Important Products
Class I covers important products that have significant cybersecurity implications but where existing security standards or market maturity provide some assurance baseline. It is the longer of the two lists, with 19 categories:

- **Identity and access management** - Identity management systems, privileged access management software and hardware, authentication and access control readers including biometric readers
- **Browsers** - Standalone and embedded browsers
- **Password managers** - Software designed primarily to store and manage credentials
- **Malware detection software** - Products that search for, remove, or quarantine malicious software
- **VPN products** - Products with a virtual private network function
- **Network management systems** - Products managing network devices and configurations
- **SIEM systems** - Security information and event management software
- **Boot managers** - Secure boot and firmware management tools
- **Public key infrastructure** - Certificate issuance and PKI software
- **Network interfaces** - Physical and virtual network interfaces
- **Operating systems**
- **Routers, modems intended for connection to the internet, and switches** - Including consumer models
- **Microprocessors with security-related functionalities**
- **Microcontrollers with security-related functionalities**
- **ASICs and FPGAs with security-related functionalities**
- **Smart home general purpose virtual assistants**
- **Smart home products with security functionalities** - Smart door locks, security cameras, baby monitors, alarm systems
- **Internet-connected toys** - Those with social interactive features or location tracking, covered by Directive 2009/48/EC
- **Personal wearables** - Health monitoring wearables and wearables intended for children

For Class I, the manufacturer keeps the **Module A self-assessment** route when harmonised standards, common specifications, or a European cybersecurity certification scheme cover all applicable essential requirements. Where that coverage is missing, a notified body route applies.

#### Annex III Class II - Important Products (Higher Risk)
Class II covers important products where a compromise would have more severe consequences, often affecting critical infrastructure or large populations. The list is short and closed, with four categories:

- **Hypervisors and container runtime systems** - Products supporting virtualised execution of operating systems and similar environments
- **Firewalls, intrusion detection and prevention systems** - In hardware or software form
- **Tamper-resistant microprocessors**
- **Tamper-resistant microcontrollers**

Anything outside those four is not Class II. Hardware security modules, smart meter gateways, and smartcards or secure elements sit one tier higher, in Annex IV. Routers, modems, switches, and microprocessors or microcontrollers with security-related functionality that are not tamper-resistant sit one tier lower, in Class I.

For Class II, self-assessment is unavailable in every case. The manufacturer uses EU type-examination followed by conformity to type (Module B + C), full quality assurance (Module H), or a European cybersecurity certification scheme at assurance level at least substantial.

#### How to Determine If Your Product Is Annex III
Determining Annex III classification requires careful analysis:

1. **Read the Annex III text** - The classification is based on product function, not product name. A general-purpose microcontroller is a Default product; the same part shipped with security-related functionality such as secure boot or key storage is Class I, and a tamper-resistant version of it is Class II.

2. **Check the intended use** - The classification often depends on the primary use case and typical deployment environment.

3. **Review draft delegated acts** - The European Commission may add products to Annex III via delegated regulation. Monitor ENISA and Commission publications for updates.

4. **Seek legal counsel** - For borderline cases, the product classification has significant commercial implications (mandatory third-party audit costs, delays to market). Professional legal and technical advice is recommended.

#### Conformity Assessment for Annex III Products
For Class I Important Products, the conformity assessment options are:
- **Module A**: Internal control, available only where harmonised standards, common specifications, or a European cybersecurity certification scheme cover all applicable essential requirements
- **Module B + C**: Notified body reviews technical documentation (Module B) + manufacturer declares conformity to assessed type (Module C)
- **Module H**: Full quality assurance - notified body audits the manufacturer's quality management system

For Class II Important Products, Module A is unavailable in every case. The options are:
- **Module B + C**
- **Module H**
- A European cybersecurity certification scheme at assurance level at least substantial

Where a notified body is involved, the CE marking is followed by that body's identification number, and the EU declaration of conformity records the route taken.

#### Finding an Accredited Notified Body
Notified bodies for CRA conformity assessment are designated by EU member state accreditation bodies and listed in the **NANDO database** (New Approach Notified and Designated Organisations).

When selecting a notified body:
- Ensure they are notified specifically for CRA assessment (designations will expand as September 2026 approaches)
- Check their experience with your product category
- Factor in lead times - notified bodies are expected to face significant demand backlogs before the September 2026 deadline

Early engagement with a notified body is strongly recommended for Annex III manufacturers.

#### Reading the categories after the Commission guidance
The technical descriptions of the categories are set out in Commission Implementing Regulation (EU) 2025/2392. Commission guidance C(2026) 5252 explains how to apply them.

A product belongs to a category where it has the core functionality of that category, meaning its main features and technical capabilities without which it could not meet its intended purpose. A product has only one core functionality for classification purposes, and it must be identified in the technical documentation.

Additional functions do not change the classification, and merely integrating a listed product does not pull the host product into the category. A smartphone that contains an operating system does not thereby have the core functionality of an operating system.

Where a product substantially exceeds or substantially falls short of a category, it is outside it. Security orchestration, automation and response software generally exceeds the SIEM category, because incident response forms a core part of its capabilities. A log collection and visualisation tool that performs no correlation and provides no actionable security insight falls short of it. This is judged objectively on the product's actual technical characteristics rather than on how it is marketed.

Where the manufacturer also offers modules of an integrated product separately, for separate purchase, licensing or subscription, each module is a standalone product classified on its own core functionality. A suite sold with separately available SIEM, intrusion detection and analytics modules yields a class I product, a class II product and a default-category product respectively.

### Critical Products with Digital Elements - Highest-Risk Classification
URL: https://cvdportal.com/cra/annex-iv

Annex IV of the EU Cyber Resilience Act identifies Critical Products - those whose compromise would have the most severe societal or infrastructure impact. Products in Annex IV take the most rigorous conformity route: a European cybersecurity certification scheme where the Commission has mandated one, and otherwise the third-party routes that apply to Annex III Class II. These products cannot self-certify under any circumstance.

#### What Makes a Product 'Critical' Under the CRA?
Critical products are those whose cybersecurity failure could have the most severe systemic impact - affecting critical infrastructure, large populations, or fundamental societal functions. Annex IV is a closed list of three categories:

- **Hardware devices with security boxes** - HSMs (Hardware Security Modules), secure cryptoprocessors, trusted execution environments
- **Smart meter gateways** - Gateways within smart metering systems as defined in the Electricity Market Directive, and other devices for advanced security purposes including secure cryptoprocessing
- **Smartcards and similar devices** - Including secure elements

Anything outside those three is not Annex IV. Industrial control systems, automotive microcontrollers, and tamper-resistant microprocessors are not critical products under the CRA. Tamper-resistant microprocessors and microcontrollers sit in Annex III Class II, and the Commission can add categories to either annex by delegated act.

#### Conformity Assessment for Critical Products
Article 32(4) sets the route for Annex IV Critical Products, and it has two branches:

1. **Where the Commission has mandated certification** - by delegated act under Article 8(1), the manufacturer must demonstrate conformity through a **European cybersecurity certification scheme** at assurance level at least **substantial**
2. **Where no such scheme is mandated or available** - the manufacturer uses the same third-party routes as Annex III Class II: EU type-examination followed by conformity to type (Module B + C), or full quality assurance (Module H)

Self-assessment under Module A is unavailable in both branches. Where a notified body is involved it must be designated for the CRA and for the relevant product category.

No delegated act mandating a certification scheme has been adopted yet, so in practice a Critical product today follows the Class II routes. Plan for the scheme requirement to arrive, because it changes the evidence and the lead time.

#### Timeline and Cost Implications
Third-party conformity assessment for Annex IV products can take **6–18 months** and cost significantly more than other conformity routes. For manufacturers whose products may be classified as Critical:

- Start notified body engagement **immediately** - lead times are long and capacity is limited
- Budget for iterative testing - the first examination often identifies non-conformities requiring remediation and re-test
- Allow time for documentation review - notified bodies will scrutinise the security risk assessment, technical file, and vulnerability management processes

Conformity is due by **11 December 2027**, when the CRA applies in full. Working back from that date with a 6-18 month assessment, and with the Article 14 reporting duty already live from 11 September 2026, a Critical-product manufacturer that has not yet engaged a notified body is behind.

#### Reading the categories after the Commission guidance
The technical descriptions of the categories are set out in Commission Implementing Regulation (EU) 2025/2392. Commission guidance C(2026) 5252 explains how to apply them.

A product belongs to a category where it has the core functionality of that category, meaning its main features and technical capabilities without which it could not meet its intended purpose. A product has only one core functionality for classification purposes, and it must be identified in the technical documentation.

Additional functions do not change the classification, and merely integrating a listed product does not pull the host product into the category. A smartphone that contains an operating system does not thereby have the core functionality of an operating system.

Where a product substantially exceeds or substantially falls short of a category, it is outside it. Security orchestration, automation and response software generally exceeds the SIEM category, because incident response forms a core part of its capabilities. A log collection and visualisation tool that performs no correlation and provides no actionable security insight falls short of it. This is judged objectively on the product's actual technical characteristics rather than on how it is marketed.

Where the manufacturer also offers modules of an integrated product separately, for separate purchase, licensing or subscription, each module is a standalone product classified on its own core functionality. A suite sold with separately available SIEM, intrusion detection and analytics modules yields a class I product, a class II product and a default-category product respectively.

### EU Declaration of Conformity: Required Fields and Structure
URL: https://cvdportal.com/cra/annex-v

Annex V provides the model structure for the EU Declaration of Conformity required under Article 28. It specifies every element that must appear, from product identification through to the conformity assessment procedure used and the signatory's details. Manufacturers preparing a declaration should use Annex V as the checklist that ensures no required element is missing, and Annex VI where the short form pointing to it is supplied with the product instead.

#### Required Elements of the EU Declaration of Conformity
Annex V sets out the model structure. A declaration under the CRA contains:

1. **Product identification**: a number, type, batch or serial reference sufficient to identify the product with digital elements covered by the declaration.

2. **Name and address**: the manufacturer's name and address, and where one is appointed, those of the authorised representative.

3. **Sole responsibility statement**: an express statement that the declaration is issued under the sole responsibility of the manufacturer. This holds on every conformity route, including where a notified body was involved.

4. **Object of the declaration**: identification of the product allowing traceability, which may include a photograph where that helps.

5. **Conformity statement**: a statement that the object described is in conformity with the relevant Union harmonisation legislation, namely Regulation (EU) 2024/2847 and its essential cybersecurity requirements in Annex I.

6. **Standards and specifications applied**: references to the harmonised standards, common specifications or other technical specifications applied, with their number and version.

7. **Notified body details, where applicable**: the name and four-digit identification number of any notified body involved, a description of the conformity assessment procedure performed, and the certificate number.

8. **Additional information**: the entity the declaration is signed for and on behalf of, the place and date of issue, and the name, function and signature of the signatory.

#### Drafting the Product Identification Section
The identification must enable unambiguous identification of what the declaration covers. For physical products this usually means the model name, model number, hardware revision and the firmware version at the time of the declaration.

For software, the declaration should cover a specific version or version range. A declaration for 'version 2.x' covering an entire line is defensible only if every version in the range genuinely meets the essential requirements the declaration asserts. Where a particular release is what brings the product into conformity, separate declarations for each conforming range are the honest approach.

Where a product has several hardware variants - different form factors or connectivity options - the declaration either covers each variant explicitly or defines its scope so that a reader can tell whether the unit in front of them falls inside it.

#### Referencing Standards and Technical Specifications
This section of the declaration is evidence of how conformity was demonstrated. Manufacturers should reference:

- The specific harmonised standard number and version or date, for example 'ETSI EN 303 645 V2.1.1 (2020-04)'
- Any common specifications adopted by the Commission under Article 27
- Other standards applied as supporting evidence, such as IEC 62443-4-1 or ISO/IEC 29147, noting that these do not confer presumption of conformity unless cited in the Official Journal for the CRA

Vague references such as 'applicable ETSI standards' or 'industry best practices' are inadequate. The declaration has to be specific enough for a market surveillance authority to judge whether the referenced standards cover the requirements claimed.

Where no harmonised standard has been applied - often because none is yet cited for the product category - the declaration should say what was applied instead, and the technical documentation must carry the detailed evidence. Note that a Class I product's access to internal control under Article 32(2) depends on fully applying such a standard, common specification or qualifying certification scheme, so partial application is worth stating precisely.

#### Recording the Conformity Assessment Procedure
Where a notified body was involved, the declaration names it, gives its four-digit identification number, describes the procedure performed and quotes the certificate number. The procedures themselves are set out in Annex VIII and selected under Article 32:

- **Module A, internal control**: no notified body is involved, so this field records that fact.
- **Module B plus Module C**: EU type-examination followed by conformity to type based on internal production control.
- **Module H**: conformity based on full quality assurance.
- **A European cybersecurity certification scheme** at assurance level at least substantial, where the product's class allows or requires it.

A declaration naming a route the product's class does not permit is the most visible defect an authority can find, because it needs no technical analysis: a Class II product claiming internal control contradicts Article 32(3) on the face of the document.

#### Signing, Maintaining and Updating the Declaration
The declaration is signed by a person with authority to bind the manufacturer, with their printed name and function alongside the signature, plus the place and date of issue. Electronic signatures are generally accepted under eIDAS, though national market surveillance practice is worth checking for specific products.

The declaration must be translated into the language or languages required by the Member State where the product is placed or made available.

It is then kept at the disposal of market surveillance authorities for at least ten years after the product was placed on the market, or for the support period where that is longer - the same retention rule that applies to the technical documentation. Where a change affects conformity, such as a substantial modification, a revised declaration is issued for the modified product. Version control matters: each version should state which product version it covers, and superseded versions should be archived rather than deleted, since they may be the ones covering units still in the field.

Where supplying the full declaration with every unit is impractical, the simplified form in Annex VI may accompany the product instead, carrying a short conformity statement and the internet address where this declaration can be obtained.

### Simplified EU Declaration of Conformity: Model Structure
URL: https://cvdportal.com/cra/annex-vi

Annex VI gives the model structure for the simplified EU Declaration of Conformity. Instead of reproducing the full Annex V declaration with every unit, the manufacturer supplies a short statement identifying itself and the product, declaring conformity with Regulation (EU) 2024/2847, and pointing to an internet address where the full declaration can be obtained. The simplified form is a delivery mechanism, not a lighter obligation: the full Annex V declaration must still exist, be signed and be kept available.

#### What the Simplified Declaration Contains
The simplified EU Declaration of Conformity is deliberately short. Following the model structure in Annex VI, it consists of:

1. **The manufacturer's identity**: the name of the manufacturer drawing up the declaration.

2. **Product identification**: the product with digital elements, identified by type, model or another reference sufficient to identify it.

3. **The conformity statement**: a declaration that the identified product with digital elements is in conformity with Regulation (EU) 2024/2847.

4. **The internet address of the full declaration**: the address at which the complete EU Declaration of Conformity drawn up under Annex V can be obtained.

A typical rendering reads: *"Hereby, [manufacturer] declares that the product with digital elements [type / model] is in conformity with Regulation (EU) 2024/2847. The full text of the EU declaration of conformity is available at the following internet address: [URL]."*

Nothing else is required in the simplified form. The detail - standards applied, conformity assessment procedure, notified body where one was involved, signature and date - lives in the full Annex V declaration behind the link.

#### When to Use the Simplified Form
The simplified declaration exists because supplying the full declaration with every unit is impractical for many products. Common cases include small-format hardware with no room for a printed document, embedded modules sold in volume to integrators, and software distributed by download where a multi-page PDF alongside the installer serves nobody.

Using the simplified form is the manufacturer's choice rather than a concession that must be justified. What matters is that the user receives the short declaration with the product or its documentation, and that the address in it resolves to the full declaration.

The simplified form does not reduce the underlying obligations. The manufacturer must still complete the conformity assessment under Article 32, compile the technical documentation under Article 31 and Annex VII, draw up and sign the full declaration under Article 28 and Annex V, and affix the CE marking under Article 30.

#### The Internet Address Is Load-Bearing
The simplified declaration is only as good as the link it carries. The address must lead to the full declaration, and it has to keep working for as long as users and market surveillance authorities may need it - which, given the retention rule in Article 13(19), means at least ten years after the product was placed on the market, or the support period where that is longer.

Practical consequences worth designing for:

- **Use a stable, product-specific URL.** A link to a general marketing page forces the reader to hunt for the document, and a site restructure breaks it.
- **Do not put the declaration behind a login.** Gating it defeats the point, since the address exists so that anyone holding the product can reach the declaration.
- **Keep superseded declarations available.** A product on the market for a decade may have several declaration versions, and an authority examining a historic unit needs the version that covered it.
- **Print the address so it survives the packaging.** A URL that only appears on a discarded box is not available to the user who owns the device.

#### How Annex VI Relates to Annex V
Annex V and Annex VI describe the same declaration in two forms. Annex V is the full model structure: product identification, the manufacturer or authorised representative, the statement of sole responsibility, the object of the declaration, the conformity statement, the standards and specifications applied, the notified body details where a third-party route was used, and the signature block. Annex VI is the short public-facing form that points to it.

One consequence is that the simplified declaration cannot be drafted first. The full declaration has to exist, because the simplified form asserts a conformity that only the full declaration and the technical file behind it can support.

Where a product falls under several Union acts requiring a declaration, a single declaration may be drawn up covering all of them, identifying each act concerned. The simplified form can then point at that combined document.

#### Common Mistakes with the Simplified Declaration
Four failure modes account for most problems seen in practice:

**Treating it as the only declaration.** The simplified form is a pointer. A manufacturer that has drafted only the short statement has no declaration of conformity at all, since there is nothing at the other end of the link.

**A dead or redirected link.** Site migrations quietly break declaration URLs. The link belongs in whatever change-control process protects other regulated artefacts.

**Vague product identification.** "Our smart sensor range" does not identify the product. The type or model reference must let a reader determine whether the unit in their hand is covered.

**Omitting the regulation.** The statement must reference Regulation (EU) 2024/2847. A generic assertion of CE conformity does not tell the reader which legislation is being declared against, particularly where the product also carries other CE obligations.

### Technical Documentation Requirements Under the CRA
URL: https://cvdportal.com/cra/annex-vii

Annex VII specifies the content of the technical documentation that manufacturers must prepare and maintain to support CRA compliance. The technical file is the complete evidence base demonstrating that a product meets the essential requirements - it includes product design documentation, cybersecurity risk assessments, software bills of materials, test results, and references to the CVD policy. This documentation must be available to market surveillance authorities on request and must be maintained for 10 years after the last product is placed on the market.

#### Overview of Technical Documentation Structure
Annex VII requires manufacturers to compile and maintain a technical file for each product with digital elements. The technical file is not a single document - it is a collection of documents, test reports, design specifications, and records that together constitute the evidence base for CRA compliance.

The technical file must contain sufficient information to demonstrate that the product meets the essential requirements in Annex I, and to enable a competent authority or notified body to assess that compliance independently. The documentation must be coherent, consistent with the actual product, and kept up to date when product changes occur.

For software products with frequent update cycles, maintaining an up-to-date technical file requires ongoing documentation discipline - not just a one-time documentation exercise at product launch.

#### Product Description and Intended Use
The technical file must begin with a clear product description that covers:

- **General description**: What the product is, what it does, and who it is intended for
- **Intended purpose and environment**: The deployment context (residential, commercial, industrial, medical) and the user population
- **Product versions and configurations**: All hardware variants, firmware versions, and software configurations covered by the technical file
- **Network connectivity**: How the product connects to networks and other devices, including protocols used and network interfaces exposed
- **Data handled**: What data the product processes, stores, or transmits, including any personal data or sensitive information
- **Dependencies**: Hardware dependencies, third-party software components, and cloud services relied upon

A thorough product description forms the foundation for the cybersecurity risk assessment that follows - you cannot adequately assess risks without first understanding what the product does and in what environment it operates.

#### Cybersecurity Risk Assessment
The Annex VII technical file must include a documented cybersecurity risk assessment for the product. This assessment must:

- **Identify threats**: Enumerate the realistic threats to the product - who might attack it, how, and with what goals
- **Assess vulnerabilities**: Identify weaknesses in the product design or implementation that could be exploited
- **Evaluate impact**: Assess the potential harm to users, third parties, and systems if an attack succeeds
- **Document controls**: Describe the security measures implemented to address each identified risk
- **Residual risk**: Identify any risks that cannot be fully mitigated and the rationale for accepting them

The risk assessment must be proportionate to the product's threat profile. A consumer smart light bulb requires a less extensive risk assessment than an industrial control system, but both require a genuine risk-based analysis.

The risk assessment also provides the justification for compliance decisions: why certain security measures were implemented, why certain Annex I requirements are addressed in specific ways, and why certain approaches were deemed sufficient.

#### Software Bill of Materials and Component Documentation
The Annex VII technical file must include documentation of all software components in the product - effectively a Software Bill of Materials (SBOM). The SBOM must identify:

- All first-party software components developed by the manufacturer
- All third-party commercial components and their versions
- All open-source components and their versions, including licence information
- The dependency relationships between components

The SBOM must be accurate and up to date. When a product update is released that changes component versions, the SBOM in the technical file must be updated accordingly.

SBOMs should be produced in a machine-readable format - SPDX or CycloneDX are the dominant standards - to enable automated vulnerability monitoring and facilitate sharing with downstream customers on request.

The SBOM serves a dual purpose in the technical file: it documents the product's composition for compliance purposes, and it enables ongoing vulnerability monitoring under Article 15 by providing the definitive list of components against which new CVE disclosures must be checked.

#### Security Test Results and CVD Policy Reference
The technical file must include evidence that the product has been tested against the essential requirements. This evidence typically includes:

**Security testing reports**: Results of penetration testing, vulnerability scanning, static and dynamic code analysis, and any other security testing conducted. Reports should be prepared by qualified security professionals and should document the testing scope, methodology, findings, and remediation actions taken.

**Harmonised standard compliance evidence**: Where harmonised standards were applied, documentation demonstrating that the product meets the standard's requirements - for example, test results from standard-specified test cases.

**CVD policy reference**: A copy of or reference to the manufacturer's publicly available CVD policy under Article 13. The technical file should document how the CVD policy meets the Article 13 requirements.

**Security update mechanism description**: Technical documentation explaining how security updates are delivered to users, including the update authentication mechanism, rollback prevention, and the process for testing updates before distribution.

**Support period documentation**: Documentation of the stated support period and the processes in place to deliver security updates throughout that period.

### Conformity Assessment Procedures: Modules A, B, C and H
URL: https://cvdportal.com/cra/annex-viii

Annex VIII contains the conformity assessment procedures a manufacturer follows to demonstrate that a product with digital elements meets the essential requirements in Annex I. It describes internal control (Module A), EU type-examination (Module B), conformity to type based on internal production control (Module C) and conformity based on full quality assurance (Module H). Article 32 decides which of these are open to a given product, based on whether it is a default, important or critical product.

#### Module A: Internal Control
Internal control is the self-assessment route. No notified body is involved, and the manufacturer carries the entire evidentiary burden. Under Module A the manufacturer:

1. **Carries out a cybersecurity risk assessment** for the product and takes its outcome into account during design, development, production and vulnerability handling.
2. **Designs, develops and produces the product** in line with the essential requirements in Annex I Part I, and operates the vulnerability-handling requirements in Annex I Part II.
3. **Compiles the technical documentation** containing the Annex VII elements, including the applicability position for each Annex I Part I(2) requirement with justifications for anything marked not applicable.
4. **Takes measures so that series production stays in conformity**, accounting for changes in design, in components and in the standards or specifications applied.
5. **Draws up the EU Declaration of Conformity** under Article 28 and Annex V, under its sole responsibility.
6. **Affixes the CE marking** under Article 30 before the product is placed on the market. No notified body identification number follows the marking on this route.

Module A is available to default products under Article 32(1). For an Annex III Class I product it is available only where the manufacturer fully applies the relevant harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial.

#### Module B: EU Type-Examination
EU type-examination is the design-stage half of the most common third-party route. The manufacturer submits an application to a single notified body of its choice, together with the technical documentation and a specimen or description of the type representative of the production envisaged.

The notified body examines the technical documentation and the evidence supporting the design, and carries out or arranges the examinations and tests needed to establish whether the type meets the essential requirements. Where it does, the body issues an EU type-examination certificate identifying the manufacturer, the conclusions of the examination, the conditions of validity and the data needed to identify the approved type.

Two obligations follow the certificate and are routinely underestimated. The manufacturer must inform the notified body of modifications to the approved type that may affect conformity, since such modifications require additional approval. The notified body, for its part, keeps itself informed of changes in the generally acknowledged state of the art that suggest the approved type may no longer comply.

#### Module C: Conformity to Type Based on Internal Production Control
Module C is the production-stage half that follows Module B. Having obtained the type-examination certificate, the manufacturer declares that the products concerned conform to the approved type described in it and meet the applicable essential requirements.

The manufacturer takes the measures needed so that the production process and its monitoring keep products conforming to the approved type. It then draws up the EU Declaration of Conformity for each product model and affixes the CE marking.

Module B and Module C are quoted together as a pair for this reason: type-examination alone says nothing about the units actually shipped, and conformity to type has no meaning without an approved type to conform to.

#### Module H: Conformity Based on Full Quality Assurance
Module H approves the manufacturer's quality system rather than an individual product type. It suits portfolios with many variants or frequent releases, where repeated type-examinations would be impractical.

The manufacturer operates an approved quality system covering design, development, production and final product inspection and testing, and submits it to a notified body for assessment. The body audits the system, determines whether it satisfies the requirements, and notifies the manufacturer of its decision. The manufacturer then undertakes to fulfil the obligations arising from the approved system and to keep it adequate and efficient.

Surveillance follows: the notified body carries out periodic audits, may make unannounced visits, and must be informed of intended changes to the quality system. Because a notified body is involved in the production-control phase, the CE marking on this route is followed by that body's four-digit identification number.

#### Which Procedure Applies to Which Product
Annex VIII describes the procedures; Article 32 decides which are open to a given product:

- **Default products** may use internal control (Module A), or voluntarily Module B plus Module C, or Module H.
- **Annex III Class I important products** may use Module A only where the relevant harmonised standards, common specifications or a European cybersecurity certification scheme at level at least substantial are fully applied. Otherwise Module B plus Module C, or Module H, applies.
- **Annex III Class II important products** always require a third party: Module B plus Module C, Module H, or a European cybersecurity certification scheme at assurance level at least substantial.
- **Annex IV critical products** are assessed through a European cybersecurity certification scheme where the Commission has required one by delegated act under Article 8(1). Where that condition is not met, the Class II routes apply.

The practical consequence is that classification has to be settled early, because it determines whether a notified body is needed and therefore how much lead time the launch plan must absorb.

### Subject Matter and Purpose of the Cyber Resilience Act
URL: https://cvdportal.com/cra/article-1

Article 1 establishes the overarching purpose of the EU Cyber Resilience Act: to ensure that products with digital elements placed on the EU market meet baseline cybersecurity requirements throughout their lifecycle. It sets the foundation for all subsequent obligations by defining what the regulation aims to achieve and why. Manufacturers, importers, and distributors operating in the EU single market must understand Article 1 as the lens through which all other provisions are interpreted.

#### What Article 1 Establishes
Article 1 defines the subject matter of the Cyber Resilience Act. The regulation lays down rules concerning the placing on the market, making available on the market, or putting into service of products with digital elements to ensure an adequate level of cybersecurity for those products.

The core objective is to address two distinct problems that the EU legislature identified in the digital product market. First, many products are placed on the market with inadequate security properties, leaving consumers and businesses exposed to preventable vulnerabilities. Second, manufacturers frequently fail to provide security updates throughout the reasonable lifetime of their products, leaving users unable to protect themselves after purchase.

Article 1 frames the CRA as a product regulation - meaning its primary enforcement mechanism is market access. Products that do not meet CRA requirements cannot lawfully bear the CE marking and cannot be placed on the EU market.

#### The Two Pillars of CRA Obligations
Article 1, read together with the regulation's recitals, establishes that CRA obligations fall into two broad categories. The first pillar covers security properties of products at the point of design and manufacture - these are the technical requirements in Annex I Part I, such as secure default configurations, minimal attack surfaces, and data protection by design.

The second pillar covers vulnerability handling obligations that persist after the product is placed on the market. These include the coordinated vulnerability disclosure requirements in Article 13, the 24-hour early warning and 72-hour notification obligations in Article 14, and the requirement to provide free security updates for at least five years (or the expected product lifetime, whichever is shorter).

Together, these two pillars reflect the EU legislature's recognition that cybersecurity is not a one-time activity at product launch but a continuing responsibility throughout the product's supported lifetime.

#### Products with Digital Elements Defined
Although Article 1 does not itself define 'products with digital elements', it is the provision that triggers the definition in Article 3. A product with digital elements is any hardware or software product that features a data connection - direct or indirect - to a device or network. This broad definition intentionally captures a wide range of products: consumer IoT devices, industrial control systems, routers, smartphones, operating systems, and standalone software applications.

The breadth of this definition reflects the EU legislature's concern that the digital supply chain is deeply interconnected and that a vulnerability in any component can cascade across many products and systems. Article 1's purpose statement provides important interpretive guidance when applying the definitions in Article 3 to borderline products.

#### Relationship to the New Legislative Framework
The CRA fits within the EU's New Legislative Framework (NLF) for product regulation. This means it follows the same general architecture as other CE marking directives and regulations: essential requirements, presumption of conformity through harmonised standards, conformity assessment procedures, and market surveillance by national authorities.

Article 1 positions the CRA explicitly within this framework, which has important practical implications. Compliance evidence gathered for the CRA (technical documentation, declarations of conformity, testing records) follows established NLF conventions. Manufacturers with existing CE marking experience will find many of the procedural requirements familiar, even if the cybersecurity substance is new.

#### Lifecycle Security as a Legal Requirement
One of the most significant innovations of the CRA, established in principle by Article 1 and operationalised in subsequent provisions, is the requirement for post-market security support. Prior to the CRA, no EU-wide rule required manufacturers to continue providing security updates after initial sale.

Article 1 establishes that the regulation's goals include ensuring products remain secure throughout their lifecycle. This principle translates into concrete obligations: manufacturers must define a support period, communicate it to consumers, and actually deliver security updates during that period. The support period must reflect the time the product is expected to be in use, with five years as a floor rather than a default, creating a significant long-term commitment for manufacturers that has not previously existed under EU law.

### Obligations of Manufacturers
URL: https://cvdportal.com/cra/article-13

Article 13 of the EU Cyber Resilience Act is the master obligations article for manufacturers, and it applies in full to products placed on the EU market from 11 December 2027. It is one of the longest and most operationally significant provisions in the regulation, covering the full lifecycle of a product's security: initial design and risk assessment (paragraphs 1–5), SBOM and component due diligence (paragraphs 6–8), security updates and support periods (paragraphs 9–11), post-market monitoring and vulnerability handling (paragraphs 12–14), coordinated vulnerability disclosure (paragraphs 15–17), and cooperation with market surveillance authorities and users (paragraphs 18–20).

#### What does security by design require under Article 13?
Article 13(1)–(5) requires manufacturers to ensure that products with digital elements are **designed, developed, and produced** in accordance with the essential cybersecurity requirements set out in [Annex I Part I of Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj). This is not a post-production checklist — it is a design-phase obligation.

At the core of this is the **cybersecurity risk assessment**: before placing a product on the market, manufacturers must carry out an assessment of the cybersecurity risks associated with the product and use the results to inform the design, development, and production process. The risk assessment must be documented and kept as part of the technical documentation required under Article 30.

Key design-phase obligations include:
- **Default secure configuration**: Products must ship in a secure default state (no universal default passwords, minimal attack surface, secure by default settings).
- **Access control**: Authentication mechanisms must be appropriate to the risk level of the product and the data it processes.
- **Confidentiality and integrity**: Data stored and transmitted by the product must be protected at a level appropriate to the risk.
- **Minimal data collection**: The product must be designed to limit data collection to what is necessary for the product's functions.
- **Resilience against attacks**: Products must be able to tolerate and recover from denial-of-service attacks and common exploitation techniques.

Manufacturers must be able to demonstrate that the risk assessment was performed and influenced the design. A risk assessment completed after the product design is finalised does not satisfy Article 13.

#### SBOM and Component Due Diligence
Article 13(6)–(8) introduces the **Software Bill of Materials (SBOM)** requirement: manufacturers must identify and document the components in their products — both software components and, where relevant, hardware components with software interfaces — with sufficient granularity to assess vulnerability exposure.

The SBOM is not required to be publicly disclosed, but it must be maintained as part of the technical documentation and must be available to market surveillance authorities on request. The level of detail required includes, at minimum, the component names, versions, and, where applicable, CVE references for known vulnerabilities affecting those components.

**Component due diligence** is the related obligation: where a manufacturer integrates third-party components (open-source libraries, commercially licensed software, off-the-shelf hardware modules), they must exercise due diligence to ensure those components do not compromise the cybersecurity of the final product. This includes:
- Checking components against known vulnerability databases before integration
- Including components in the ongoing vulnerability monitoring process after market placement
- Ensuring that the support lifecycle of integrated components aligns with the manufacturer's own support commitment

Manufacturers cannot outsource their Article 13 obligations to third-party component suppliers. The manufacturer of the final product remains responsible for the security of all components in their product.

#### Security Updates and Support Period Obligations
Article 13(9)–(11) sets out the manufacturer's obligation to provide **security updates** for the duration of the product's support period, and to communicate that support period to users.

Key requirements:

**Support period duration**: The support period must be commensurate with the expected product lifetime and the nature of the product. For most consumer products, the Commission has indicated that five years is the expected minimum; products intended for longer deployment (industrial control systems, embedded systems) should have correspondingly longer support periods. The support period is set by the manufacturer but must be disclosed.

**Security updates during the support period**: Manufacturers must provide security updates promptly — meaning as quickly as practicable given the severity of the vulnerability. Updates must be provided separately from feature updates where technically feasible, so users can apply security fixes without being forced to accept other changes.

**Automatic updates**: Where the product supports automatic updates, the automatic update mechanism should be enabled by default, with users able to opt out. Where automatic updates are not technically feasible, manufacturers must provide a mechanism for users to check for and apply updates manually.

**Post-support communication**: When the support period ends, manufacturers must clearly communicate to users that the product will no longer receive security updates, and must provide information about available alternatives where possible. Products sold after the support period ends must clearly disclose this to buyers.

#### Post-Market Monitoring and Vulnerability Handling
Article 13(12)–(14) requires manufacturers to actively monitor products after market placement, not merely respond reactively to reported vulnerabilities.

**Active monitoring** means maintaining awareness of:
- New vulnerabilities in the product's own code (through internal security testing, automated scanning, penetration testing)
- New vulnerabilities in third-party components used in the product (by monitoring CVE databases, component vendor advisories, and relevant CERT publications)
- Threat intelligence relevant to the product category

**Corrective actions**: Where a vulnerability is identified through monitoring or reported by a third party, manufacturers must take timely corrective action. The required actions include:
- Assessing the severity of the vulnerability using a recognised scoring system (CVSS or equivalent)
- Developing and testing a patch or workaround
- Deploying the fix to affected users promptly
- Where a fix cannot be deployed immediately, providing interim risk mitigation guidance to users

**Documentation of corrective actions**: Manufacturers must keep records of all identified vulnerabilities and the corrective actions taken. These records must be available to market surveillance authorities on request and must be retained for the duration of the support period plus at least ten years.

#### What Article 13 Requires (CVD Overview)
Article 13(15)–(17) — the coordinated vulnerability disclosure provisions — require manufacturers to:

1. **Establish a CVD policy** — A publicly accessible, documented process for how security researchers and others can report vulnerabilities in your products.
2. **Acknowledge receipt** — Confirm to the reporter that the report has arrived. The CRA sets no deadline for this step. The widely used 48-hour target comes from ISO/IEC 29147 practice.
3. **Inform the reporter** — Provide the reporter with an initial assessment and expected timeline for a fix.
4. **Coordinate disclosure** — Work with the reporter before any public disclosure to agree on timing and content.
5. **Publish advisories** — Issue a security advisory when a vulnerability is fixed or when a workaround is available.

All of these obligations apply from 11 December 2027.

#### Where the 48-Hour Acknowledgment Comes From
The **48-hour acknowledgment window** is the single most misquoted number in CRA advice, including in material sold by consultants. It is worth being precise about where it comes from.

**What the CRA says.** Article 13 requires a coordinated vulnerability disclosure policy and requires manufacturers to address and remediate vulnerabilities **without delay**. It sets no fixed clock for acknowledging a report to its reporter. The regulation's hard reporting deadlines (24 hours, 72 hours, 14 days) live in Article 14 and run to CSIRTs and ENISA, for actively exploited vulnerabilities and severe incidents.

**Where 48 hours comes from.** ISO/IEC 29147 sets an expectation that a receiving organisation acknowledges a report promptly, and 48 hours is the figure the disclosure community has settled on. It is best practice, and market surveillance authorities will read a documented, met SLA as evidence of a functioning process.

**Why treat it as binding anyway.** A reporter who hears nothing goes public. An unacknowledged report that turns into a zero-day is an Article 14 problem with a paper trail showing you were told first. CVD Portal tracks the 48-hour acknowledgment as an SLA with breach alerts for exactly this reason.

**Practical implication**: You need a monitored inbox, ticketing system, or dedicated vulnerability disclosure portal so that no report goes unacknowledged.

#### What Your CVD Policy Must Cover
Your CVD policy is the public-facing document that explains your vulnerability disclosure process. At a minimum, it must include:

- **Contact information**: How to reach your security team (email, submission form, or both). This is typically enforced via a `security.txt` file at `/.well-known/security.txt`, as defined by [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116).
- **Scope**: Which products and versions are covered.
- **Process**: What happens after you receive a report - acknowledgment timeline, triage, remediation, and disclosure.
- **Safe harbour**: A commitment not to pursue legal action against researchers who act in good faith.
- **Disclosure timeline**: When and how you will publicly disclose the vulnerability.

The CVD policy should be publicly accessible - typically linked from your product documentation, website, or `security.txt` file.

#### Coordinated Disclosure vs. Responsible Disclosure
Article 13 specifically mandates **coordinated** vulnerability disclosure, not simply responsible disclosure. The distinction matters:

- **Responsible disclosure** traditionally means the researcher gives you time to fix the issue before going public, with the researcher setting the timeline.
- **Coordinated disclosure** means both parties - you and the researcher - agree on the disclosure timeline and content. The CRA requires this mutual coordination.

In practice, this means you must actively engage with researchers, not simply receive their reports and act unilaterally. If a researcher sets a 90-day deadline for public disclosure, you need to either fix the vulnerability, provide a workaround, or negotiate an extension - not ignore the deadline.

#### Cooperation with Market Surveillance Authorities and Users
Article 13(18)–(20) sets out manufacturers' obligations to cooperate with market surveillance authorities (MSAs) and to communicate security information to users.

**MSA cooperation**: Manufacturers must cooperate with national MSAs when requested to do so, including by providing technical documentation, product samples, access to test instances, and information about the manufacturer's supply chain. Where an MSA issues a corrective action order, manufacturers must comply within the timeframe specified.

**User communication**: Manufacturers must provide users with information about identified vulnerabilities and available remediation. This includes:
- Publishing security advisories in accessible language for the product's intended audience
- Notifying users of available security updates through the update mechanism or other appropriate channels
- Providing clear information about the product's support period end date and what it means for users

**Single point of contact**: Manufacturers must designate a single point of contact to enable users and researchers to communicate directly and rapidly with them about security issues. This contact point must be easily identifiable from the product documentation or website. A generic customer support email is not sufficient if it does not route to staff with the authority and competence to handle security reports.

#### The Role of ENISA and National CSIRTs
Article 13 establishes a role for the European Union Agency for Cybersecurity (ENISA) and national Computer Security Incident Response Teams (CSIRTs) in the vulnerability disclosure process.

Manufacturers may voluntarily notify their national CSIRT of vulnerabilities discovered in their products. In some cases - particularly where vulnerabilities may affect critical infrastructure or large numbers of users - CSIRTs may act as coordinators between manufacturers and researchers.

[ENISA](https://www.enisa.europa.eu/) also maintains the [European Vulnerability Database (EUVD)](https://euvd.enisa.europa.eu/), which manufacturers should use when registering CVEs (Common Vulnerabilities and Exposures) for vulnerabilities in their products.

#### CSAF Advisories
When you publish a security advisory under Article 13, the CRA recommends (and market practice is moving toward requiring) that you publish it in **CSAF 2.0 format** (Common Security Advisory Framework).

[CSAF 2.0](https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html) is a machine-readable JSON format, standardised by OASIS, that enables automated vulnerability management tools to ingest your advisories. Publishing CSAF advisories alongside human-readable advisories is increasingly expected by enterprise customers and conformity assessment bodies.

CVD Portal can automatically generate CSAF 2.0 advisories from your vulnerability tracking data.

#### How This Differs from ISO/IEC 29147
If your organisation already follows **ISO/IEC 29147** (Vulnerability Disclosure) and **ISO/IEC 30111** (Vulnerability Handling Processes), you are well-positioned for the CVD provisions of Article 13 compliance. The CRA's CVD requirements largely align with these international standards.

Key differences:
- The CRA adds **statutory timelines** that ISO 29147 has no equivalent for, in Article 14: a 24-hour early warning, a 72-hour notification, and a final report. The 48-hour acknowledgment is the other way round, an ISO 29147 practice with no CRA deadline behind it.
- The CRA ties non-compliance to **market access** - non-compliant products can be withdrawn from the EU market.
- The CRA introduces **ENISA reporting** for severe vulnerabilities (see Article 14).
- The CRA goes beyond ISO 29147 by also requiring security-by-design, SBOM, update obligations, and post-market monitoring — obligations that have no equivalent in the ISO CVD standards.

Following ISO 29147 addresses only the CVD provisions of Article 13. Manufacturers need to address the full scope of Art 13 obligations separately.

#### How long must the support period be?
Article 13(8) sets the support period by reference to the time the product is expected to be in use, judged against reasonable user expectations, the nature of the product including its intended purpose, and relevant Union law determining product lifetimes. It must be at least five years unless the product is expected to be in use for less.

Commission guidance C(2026) 5252 point 126 corrects a common misreading. The five-year minimum operates only as a safeguard, and recital 60 means products reasonably expected to be in use for longer than five years should have correspondingly longer support periods. Five years is not the default for all products.

Each substantially modified version placed on the market needs its own declared support period complying with Article 13(8). Article 13(10) provides relief for iterative software, allowing a manufacturer to address and remediate vulnerabilities only for the version last placed on the market where users of earlier versions can upgrade free of charge without additional costs. The guidance reads additional costs narrowly. Personnel time, routine testing, configuration adjustments and dependency upgrades are ordinary and do not count. Mandatory new hardware, infrastructure replacement or fundamental changes to the operating environment do.

#### What does reporting upstream under Article 13(6) require?
Article 13(6) requires manufacturers to report vulnerabilities in integrated components to whoever manufactures or maintains that component, and to share any software modification they develop to fix such a vulnerability.

Commission guidance C(2026) 5252 narrows this usefully. You report only in respect of the version of the component you integrate. Where the maintainer has a security policy, a coordinated vulnerability disclosure process or a designated reporting channel, use it. You are not required to report where you can confirm the maintainer already knows, and manufacturers are encouraged to check public vulnerability databases, project advisories and issue trackers first to avoid duplicate reports burdening open-source maintainers. No report is owed where the component no longer has a maintainer, or where you no longer rely on that maintainer for new versions or fixes, although informing users through community mechanisms or public vulnerability records is encouraged.

Only vulnerabilities in the component itself are reportable upstream, rather than defects arising from how you integrated it. Where integration reveals behaviour that was not apparent in isolation, sharing that is encouraged. Security fixes should be shared in a machine-readable, verifiable form, under a licence compatible with the component. Neither side is obliged to accept the other's proposed fix.

### Active Exploitation and Incident Reporting - 24h, 72h, and 14-Day Obligations
URL: https://cvdportal.com/cra/article-14

Article 14 of the EU Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities and severe incidents to ENISA and their coordinator CSIRT from 11 September 2026, with an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days. It is the first CRA obligation to apply, fifteen months ahead of the rest of the regulation.

#### What are the three Article 14 reporting deadlines?
Article 14 establishes a three-stage notification process triggered by **active exploitation** of a vulnerability or a **severe security incident**:

| Stage | Deadline | What to Report |
|-------|----------|----------------|
| Early Warning | 24 hours | Notification that exploitation is occurring; basic product and vulnerability information |
| Vulnerability Notification | 72 hours | Full notification including CVSS score, affected versions, initial mitigations |
| Final Report | 14 days after a fix is available (vulnerability), or one month after the 72-hour notification (incident) | Complete analysis, root cause, patch or workaround, supply chain impact |

The first two deadlines are calculated from the moment the manufacturer **becomes aware** of the active exploitation or incident - not from when exploitation began. The final report runs on a different clock, and this is the detail most summaries get wrong. For an actively exploited vulnerability, Article 14(2)(c) gives you 14 days from the moment a corrective or mitigating measure **is available**, not from awareness. For a severe incident, Article 14(4)(c) gives you one month from the submission of the 72-hour incident notification. The full legal text is set out in [Article 14 of Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) on EUR-Lex.

#### When does a manufacturer 'become aware'?
Every Article 14 deadline runs from the moment the manufacturer becomes aware, and the Regulation does not define that moment. Commission guidance C(2026) 5252 does. On detecting a suspicious event, or on a third party such as a researcher, customer, authority or media organisation bringing something to its attention, the manufacturer should assess it immediately. Awareness arises when, after that initial assessment, there is a reasonable degree of certainty that a vulnerability contained in the product is being actively exploited, or that a severe incident has occurred and has compromised the security of the product.

Receiving a report therefore does not by itself start the clock, and neither does an unexamined suspicion. A short triage window sits in front of the 24 hours. It is not open-ended, and the guidance stresses prompt action to carry out the initial assessment, particularly where the vulnerability may pose a significant risk.

The Commission deliberately aligned this reading with recital 31 of Implementing Regulation (EU) 2024/2690 under NIS2 and with Section II(A) of the EDPB guidelines on personal data breach notification under the GDPR, so that a manufacturer subject to several regimes can apply one awareness standard. The guidance is non-binding, and only the Court of Justice of the European Union can give an authoritative interpretation.

#### What triggers Article 14 reporting?
Two conditions trigger Article 14 notification:

1. **Active exploitation** - A vulnerability in your product is being actively exploited in the wild. This means there is evidence of real-world attacks using the vulnerability, not just proof-of-concept code.

2. **Severe security incident** - A security incident that has (or may have) a significant impact on the security of users of your product, or a significant impact on the internal operations of your organisation.

**Not triggered by**: Theoretical vulnerabilities, vulnerabilities with no known exploitation, low-severity bugs, or normal vulnerability reports received through your CVD programme that are not actively exploited.

#### Where do you submit an Article 14 report?
Notifications must be submitted to the **CSIRT designated as coordinator** in the member state where you have your main establishment, and to [ENISA](https://www.enisa.europa.eu/). Each EU member state designates a coordinator CSIRT for this purpose.

ENISA is establishing a **Single Reporting Platform** for Article 14 notifications. Until this is operational, manufacturers should contact their national CSIRT directly.

**National CSIRT contacts** include:
- Germany: [BSI (Federal Office for Information Security)](https://www.bsi.bund.de/)
- France: [ANSSI](https://www.ssi.gouv.fr/)
- Netherlands: [NCSC-NL](https://www.ncsc.nl/)
- Sweden: NCSC-SE
- Spain: [INCIBE-CERT](https://www.incibe.es/en/incibe-cert)

CVD Portal can draft Article 14 notifications in the required format and alert you when deadlines are approaching.

#### The 24-Hour Early Warning
The **24-hour early warning** is not a full technical report - it is a rapid notification that exploitation is occurring. ENISA uses this signal to coordinate cross-border incident response before the full picture is known.

Required content for the 24-hour early warning:
- Product name and affected version(s)
- Nature of the vulnerability or incident (brief description)
- Indication that active exploitation is occurring
- Geographic scope if known
- Initial mitigation actions taken (if any)

You do not need to have a root cause analysis or patch ready at this stage. Speed of notification is the priority.

#### The 72-Hour Full Notification
Within **72 hours** of becoming aware of active exploitation, you must submit a full vulnerability notification. This expands on the early warning with:

- CVSS 3.1 (or 4.0) score and vector string
- CVE identifier (or a request for one if not yet assigned)
- Affected products, versions, and configurations
- Description of the impact on confidentiality, integrity, and availability
- Known attack vectors and exploitation techniques
- Mitigations available (patches, workarounds, configuration changes)
- Supply chain impact assessment (are other products affected?)

**72 hours is a very tight window** for a complete analysis. This means your incident response process must be able to move very quickly when an active exploitation is confirmed.

#### The 14-Day Final Report
The **final report** closes the case with ENISA and the coordinating CSIRT. Its deadline depends on which trigger you are reporting. For an actively exploited vulnerability, Article 14(2)(c) gives you 14 days from the moment a corrective or mitigating measure is available. For a severe incident, Article 14(4)(c) gives you one month from the submission of the 72-hour incident notification. It must include:

- Root cause analysis
- Complete remediation details (patch release, advisory publication)
- CSAF advisory (if applicable)
- Supply chain coordination actions taken
- Steps taken to prevent recurrence
- Lessons learned

If the case is still open when your clock runs out, submit what you have and explain what remains under investigation. Separately, under Article 14(6) the coordinating CSIRT that received your notification can request an intermediate report on status updates at any point between the stages.

#### What are the Article 14 supply chain obligations?
Article 14 has significant **supply chain implications**. If a vulnerability affects components you source from third-party vendors, you are still responsible for the Article 14 notification for your product - but you must also:

1. Notify the component vendor if the vulnerability originates in their component
2. Coordinate with them on remediation timelines
3. Report the supply chain dimension in your Article 14 notifications

Conversely, if you are a **component supplier** and your component is found to be vulnerable, you must notify downstream manufacturers who integrate your component. This creates a notification cascade up and down the supply chain.

#### Does the obligation apply retroactively or after support ends?
No to the first and yes to the second. Commission guidance C(2026) 5252 confirms that Article 14 applies from 11 September 2026 to all products with digital elements in scope, including products placed on the market before 11 December 2027, and that the reporting obligations continue after a product is no longer supported. Vulnerability handling under Annex I Part II behaves differently and stops with the support period.

There is no retroactive reporting. A manufacturer is not required to report active exploitation it had already become aware of before 11 September 2026. Where a vulnerability was known before that date but its active exploitation was not, either because none had occurred or because the manufacturer had not learned of it, and exploitation occurs or comes to light after that date, the vulnerability is reportable.

A vulnerability originating in an integrated third-party component is reportable only where it is actively exploited in your product. Where the vulnerable code is unreachable, or exploitation has not occurred in your product, no mandatory report arises. Voluntary notification under Article 15 remains available, the Annex I Part II handling requirements still apply, and Article 13(6) still requires the vulnerability to be reported upstream to whoever maintains the component.

### Voluntary Reporting of Vulnerabilities and Incidents
URL: https://cvdportal.com/cra/article-15

Article 15 of the EU Cyber Resilience Act creates a voluntary reporting pathway alongside the mandatory Article 14 deadlines, letting manufacturers and other parties notify a national CSIRT of vulnerabilities that are not yet actively exploited, near-misses, and security-relevant information that could benefit the broader cybersecurity community. Voluntary notifications are encouraged and acknowledge reporters' good-faith cooperation with EU cybersecurity objectives.

#### What Can Be Voluntarily Reported Under Article 15
Article 15 covers notifications that go beyond — or fall below — the mandatory reporting thresholds of Article 14. Examples of voluntary reports include:

- **Non-actively-exploited vulnerabilities**: A vulnerability discovered internally or through your CVD programme that poses risk but is not being exploited in the wild
- **Near-misses and threat intelligence**: Attacks that were detected and blocked before causing significant impact, but which indicate emerging threat patterns
- **Supply chain security concerns**: Information about vulnerabilities in third-party components that affect your product but are being remediated by the component supplier
- **Systemic security patterns**: Observations about recurring vulnerability types or attack patterns affecting a product category that would be useful to national CSIRTs and ENISA

Voluntary notifications supplement the mandatory system and help build a richer picture of the EU's cybersecurity threat landscape.

#### Who Can Submit Voluntary Reports
Unlike Article 14, which applies specifically to manufacturers, Article 15 is broader in scope. Voluntary reports under Article 15 can be submitted by:

- **Manufacturers** reporting issues below the Article 14 threshold
- **Open-source software stewards** under Article 24 (who are not subject to Article 14)
- **Security researchers** who discover vulnerabilities in CRA-regulated products
- **Importers and distributors** who become aware of security concerns through the supply chain
- **Users** of critical infrastructure who identify security issues in products they deploy

The voluntary nature of Article 15 means there is no penalty for not reporting. However, proactive reporting may be considered positively by market surveillance authorities when assessing a manufacturer's overall good-faith compliance posture.

#### How Voluntary Reports Are Handled
Voluntary notifications under Article 15 are routed through the same national CSIRT infrastructure used for Article 14 mandatory reports. National CSIRTs are required to acknowledge voluntary notifications and may share them with ENISA and other member states' CSIRTs where the information has broader relevance.

Key protections for voluntary reporters:
- **No enforcement consequences**: Submitting a voluntary report does not trigger an investigation or enforcement action against the reporter under the CRA
- **Coordinated disclosure support**: National CSIRTs can assist in coordinating disclosure with other affected manufacturers or component suppliers
- **Confidentiality**: Sensitive information disclosed in voluntary reports is handled with the same confidentiality protections as mandatory notifications

Manufacturers are encouraged to use the Article 16 single reporting platform for voluntary submissions where it is operationally available.

### Establishment of the Single Reporting Platform and ENISA's Vulnerability Coordination Role
URL: https://cvdportal.com/cra/article-16

Article 16 of the EU Cyber Resilience Act mandates ENISA to create and operate the single reporting platform that receives Article 14 vulnerability and incident notifications when reporting begins on 11 September 2026. It also covers ENISA's role in establishing the European Vulnerability Database (EVDB) as the EU's authoritative registry for vulnerabilities in CRA-regulated products, and ENISA's coordination function across national CSIRTs for cross-border vulnerability disclosure.

#### The Single Reporting Platform
Article 16 establishes that ENISA shall set up, maintain, and operate a single reporting platform through which manufacturers submit their Article 14 notifications. This platform provides a standardised, secure channel for the early warning (24-hour), notification (72-hour), and final report submissions required under Article 14.

The single reporting platform is designed to eliminate the fragmentation that would result if each member state operated its own bespoke notification system. Without a single platform, manufacturers selling across multiple EU member states would need to file separate notifications in each jurisdiction's system, with potentially different formats, authentication requirements, and submission procedures.

By providing a single submission point, the platform reduces administrative burden on manufacturers while ensuring that all notifications reach the appropriate national CSIRT and are simultaneously available to ENISA for EU-level coordination.

#### Notification Routing to National CSIRTs
Although submissions go through a single platform, Article 16 ensures that notifications are routed to the appropriate national CSIRT based on the manufacturer's location or the affected product's market. The platform handles this routing automatically, so manufacturers need not identify the correct national authority for each submission.

Where a vulnerability affects products sold in multiple member states, the platform may route notifications to multiple national CSIRTs simultaneously or sequentially, ensuring all relevant national authorities receive the information. ENISA also receives a copy of all notifications, enabling the EU-level picture to be maintained.

The routing logic also accounts for situations where the manufacturer is established in a third country - in such cases, notifications may be routed through the national CSIRT in the member state where the product is primarily marketed or where the authorised representative is established.

#### Technical Format and Standardisation
Article 16 requires that the single reporting platform use standardised technical formats for notifications. Standardisation enables automated processing, reduces errors, and facilitates integration with vulnerability management systems at national CSIRTs and ENISA.

The expected format for notifications aligns with CSAF (Common Security Advisory Framework) conventions and STIX/TAXII threat intelligence standards where applicable. Manufacturers should design their internal vulnerability management workflows to produce outputs in formats compatible with the platform's submission requirements.

ENISA publishes technical specifications for the submission format, which manufacturers should integrate into their CVD tooling well before the CRA application date. CVD Portal supports automated submission-ready report generation in the required formats.

#### Confidentiality and Data Handling
Article 16 requires that the single reporting platform handle notification data with appropriate confidentiality protections. Vulnerability information submitted before a patch is publicly available is commercially sensitive and, if leaked, could facilitate exploitation of the reported vulnerability. The platform must therefore implement strong access controls ensuring that notification data is accessible only to authorised national CSIRT personnel and ENISA staff.

Manufacturers submitting notifications can expect that:

- Notification content will not be shared with third parties without the manufacturer's consent, except as necessary for coordination with national authorities
- Published vulnerability information (for example, EVDB entries) will be delayed or redacted until a fix or workaround is available
- Personal data included in notifications (such as security researcher contact details) will be handled in accordance with GDPR

Manufacturers should review the platform's terms of use and privacy notice before first submission to understand the data handling framework.

#### Integration with Manufacturer CVD Systems
For manufacturers with significant product portfolios and active vulnerability management programmes, the Article 16 platform has to fit around internal CVD tooling rather than the other way around. Manual submission for every vulnerability in a large portfolio is operationally demanding, so the capacity to file quickly and correctly has to be planned for.

ENISA has confirmed that no application programming interfaces will be provided at this stage, so there is no programmatic route onto the platform. Filing is a person signing in with an EU Login account and completing the notification form. Manufacturers who assumed an API would absorb the volume should re-plan on the basis that it will not.

CVD Portal produces an SRP-ready submission package, with the required fields populated from the vulnerability record and the 24-hour and 72-hour deadlines tracked automatically, so what remains is filing that package in one manual step. Direct programmatic submission is only possible if ENISA publishes an API later.

#### ENISA's Role in the Reporting Infrastructure
ENISA is responsible for establishing and operating the single reporting platform and the European Vulnerability Database (EVDB) that underpins it. The following sections describe ENISA's specific functions under Article 16.

#### The European Vulnerability Database
Article 16 tasks ENISA with establishing and maintaining the European Vulnerability Database (EVDB). The EVDB serves as the EU-level registry for vulnerabilities affecting CRA-regulated products, complementing the global CVE programme coordinated by MITRE/NVD.

The EVDB allows manufacturers to register vulnerabilities in their products with standardised identifiers (European Vulnerability Identifiers or EVIs), enabling structured tracking and reporting of vulnerability lifecycles. For manufacturers subject to Article 14 reporting obligations, the EVDB is the downstream repository where their notifications ultimately contribute to an EU-wide vulnerability intelligence picture.

The EVDB is also intended to serve as a resource for market surveillance authorities, security researchers, and downstream users who need to assess their exposure to known vulnerabilities. By centralising vulnerability information, the EVDB aims to improve the EU's collective ability to monitor the security state of digital products and respond to emerging threats.

#### ENISA's Coordination Function in Vulnerability Disclosure
Article 16 gives ENISA a coordination role in the EU's vulnerability disclosure ecosystem. Where a vulnerability in a CRA-regulated product affects multiple manufacturers, multiple product categories, or has systemic implications for critical infrastructure, ENISA may coordinate the disclosure process to ensure:

- All affected manufacturers are notified simultaneously
- Disclosure timelines are coordinated to avoid one manufacturer's advisory revealing the vulnerability before others are ready
- National CSIRTs in affected member states receive timely and accurate information
- The EVDB entry for the vulnerability is comprehensive and accurate

This coordination role is particularly important for vulnerabilities affecting widely-deployed standards, protocols, or common components - situations where a single CVE may affect hundreds of manufacturers and millions of products simultaneously.

#### Interface Between the EVDB and Global Vulnerability Databases
Article 16 recognises that the EVDB does not operate in isolation - it must interface with the global vulnerability management ecosystem, including the MITRE CVE programme, the NVD, and national vulnerability databases maintained by CERT organisations in member states.

ENISA is responsible for establishing data exchange arrangements with these international databases to avoid duplication and to ensure that vulnerability information registered in the EVDB is synchronised with global CVE records. For manufacturers, this means that vulnerabilities disclosed through the CRA Article 14 process will contribute to both EU-specific and global vulnerability intelligence.

Manufacturers should familiarise themselves with both the EVDB and the global CVE programme. The processes for registering CVEs (through CNA - CVE Numbering Authorities) are established, and ENISA is expected to become a CNA covering EU-specific vulnerabilities.

#### ENISA's Advisory and Guidance Functions
Beyond database operations, Article 16 establishes ENISA as a source of guidance and advice for manufacturers, national authorities, and other stakeholders on CRA implementation. ENISA's advisory functions include:

- Publishing implementation guidance on CRA obligations for manufacturers across different product categories
- Developing technical guidelines on CVD policy best practices, SBOM formats, and CSAF advisory standards
- Providing guidance to national CSIRTs on handling Article 14 notifications
- Advising the Commission on the development of implementing acts and common specifications
- Publishing annual reports on the state of CRA implementation and the vulnerability landscape for digital products

Manufacturers should actively monitor ENISA's publications as the CRA's application date approaches, as guidance documents will clarify many practical compliance questions that the regulation itself leaves open.

#### ENISA's Role in Article 14 Notification Processing
Article 16 connects with Article 14 to establish ENISA's central role in processing vulnerability and incident notifications from manufacturers. Under Article 14, manufacturers report severe vulnerabilities to their national CSIRT, which forwards notifications to ENISA. ENISA aggregates these notifications, maintains statistics, identifies trends, and coordinates cross-border responses.

The practical infrastructure for this - the single reporting platform referenced in Article 16 - is designed and operated under ENISA's coordination. Manufacturers who submit Article 14 notifications to their national CSIRT are indirectly contributing to the EU-wide vulnerability intelligence that ENISA maintains.

ENISA also plays a role in the early warning process: where a notification indicates a vulnerability that may affect critical infrastructure or a large number of users, ENISA can escalate the alert to national cybersecurity authorities across the EU.

### Other Provisions Related to Reporting
URL: https://cvdportal.com/cra/article-17

Article 17 wraps up the CRA's reporting chapter. It lets ENISA share notification information with EU-CyCLONe for large-scale incident coordination, empowers the coordinating CSIRT to inform the public about a severe incident (or require the manufacturer to do so), provides that notifying does not by itself increase the notifier's liability, has ENISA add fixed, publicly known vulnerabilities to the European vulnerability database, gives manufacturers, especially SMEs, helpdesk support from the coordinating CSIRTs, and sets up ENISA's 24-month technical report on emerging cybersecurity risk trends.

#### Where Article 17 Sits in the Reporting Chapter
The final text of the CRA organises reporting across four articles:

- **Article 14**: the manufacturer's obligation to report actively exploited vulnerabilities and severe incidents to the coordinating CSIRT and ENISA on the 24-hour, 72-hour, and 14-day (or one-month) timelines, and to inform impacted users under Article 14(8).
- **Article 15**: voluntary reporting of vulnerabilities, incidents, near misses, and cyber threats by manufacturers and third parties.
- **Article 16**: the single reporting platform (SRP) that ENISA establishes and the national electronic notification end-points on it.
- **Article 17**: the provisions around those notifications, covering onward information sharing, public disclosure, liability, the European vulnerability database, and helpdesk support.

If you are looking for the user-notification duty that older commentary sometimes filed under Article 17, in the final Regulation (EU) 2024/2847 it lives in Article 14(8).

#### Information Sharing with EU-CyCLONe
ENISA may submit information notified under Article 14(1) and (3) and Article 15(1) and (2) to EU-CyCLONe, the European cyber crisis liaison organisation network established under the NIS 2 Directive, where that information is relevant to the coordinated management of large-scale cybersecurity incidents and crises at an operational level. In judging relevance, ENISA may draw on technical analyses performed by the CSIRTs network.

For manufacturers this changes nothing about what you file or when, but it is worth understanding the audience: a severe-incident notification can feed the EU's operational crisis picture, which is one reason the early-warning content should be accurate even when it is brief.

#### Public Disclosure by the Coordinating CSIRT
Where public awareness is necessary to prevent or mitigate a severe incident having an impact on the security of the product, or to handle an ongoing incident, or where disclosure is otherwise in the public interest, the CSIRT designated as coordinator of the relevant Member State may, after consulting the manufacturer concerned and, where appropriate, in cooperation with ENISA, inform the public about the incident or require the manufacturer to do so.

Practical consequences:

- An incident you notify under Article 14 can become public on the authority's initiative, on a timeline you do not fully control.
- The consultation step is your opportunity to align disclosure with the availability of a fix, so keep remediation status current in every stage of the notification.
- Prepare a public advisory draft alongside the authority notification rather than after it, so a required disclosure does not catch you without user-facing language.

#### ENISA's 24-Month Trend Report
On the basis of the notifications it receives under Articles 14 and 15, ENISA prepares a technical report on emerging trends regarding cybersecurity risks in products with digital elements every 24 months and submits it to the Cooperation Group established under the NIS 2 Directive, with the first report due within 24 months of the Article 14 obligations applying. Relevant findings also feed ENISA's report on the state of cybersecurity in the Union.

Aggregated notification data therefore has a policy afterlife: it shapes future guidance and enforcement focus, which is another reason accurate classification of your reports matters beyond the individual filing.

#### No Increased Liability for Notifying
The mere act of notifying in accordance with Article 14(1) and (3) or Article 15(1) and (2) does not subject the notifying natural or legal person to increased liability.

This is the CRA's answer to the classic in-house objection that filing a report creates legal exposure. The notification itself cannot be held against you. Liability, if any, attaches to the underlying non-compliance, not to the act of reporting it, so the shield removes the incentive to sit on a report while the 24-hour clock runs.

#### The European Vulnerability Database Entry
After a security update or another corrective or mitigating measure is available, ENISA adds a publicly known vulnerability notified under Article 14(1) or Article 15(1) to the European vulnerability database (EUVD) established under the NIS 2 Directive, in agreement with the manufacturer concerned.

Plan for this in your disclosure timeline: once your fix ships, the vulnerability can gain a formal EU-level record. Your public advisory, CVE assignment, and EUVD entry should tell one consistent story about affected versions and remediation.

#### Helpdesk Support from the Coordinating CSIRTs
The CSIRTs designated as coordinators provide helpdesk support in relation to the Article 14 reporting obligations to manufacturers, and in particular to manufacturers that qualify as microenterprises or as small or medium-sized enterprises.

If you are an SME facing your first 24-hour early warning, your national coordinating CSIRT is a resource you are entitled to use, not only the authority you report to. Identify your designated CSIRT before an incident so the first contact is not made under deadline pressure.

### Authorised Representatives: EU Presence for Non-EU Manufacturers
URL: https://cvdportal.com/cra/article-18

Article 18 requires manufacturers established outside the European Union who place products with digital elements on the EU market to appoint an authorised representative established within the EU. The authorised representative is the legal point of contact for national market surveillance authorities, ENISA, and other competent bodies. This provision ensures that there is always an EU-based entity accountable for CRA compliance, regardless of where the manufacturer is located.

#### Who Needs an Authorised Representative
Article 18 applies to manufacturers established outside the European Union who place products with digital elements on the EU market. This includes manufacturers in countries such as the United States, China, South Korea, Japan, Taiwan, and any other non-EU jurisdiction whose products are sold in the EU.

The requirement exists because EU regulatory enforcement relies on the ability of national authorities to contact and interact with responsible legal entities within their jurisdiction. A manufacturer established in a third country cannot easily be reached by an EU market surveillance authority, cannot be summoned before EU courts in the ordinary way, and may not be subject to EU financial penalties. The authorised representative solves this problem by providing an EU-based point of accountability.

The authorised representative must be formally designated in writing by the manufacturer before the product is placed on the EU market. This designation is a prerequisite for CE marking, not an afterthought.

#### What the Authorised Representative Must Do
The authorised representative has significant legal responsibilities under Article 18. Key obligations include:

**Register with market surveillance authorities**: The authorised representative's name and address must appear in the EU Declaration of Conformity and in the product's user-facing information, enabling authorities and consumers to contact them.

**Maintain the technical file**: The authorised representative must hold a copy of the technical documentation and EU Declaration of Conformity and be able to provide them to national authorities on request, typically within a short timeframe (often 10 working days under similar EU regulations).

**Cooperate with authorities**: When national market surveillance authorities require information, conduct investigations, or require corrective action, the authorised representative is the primary point of contact and must cooperate fully.

**Relay Article 14 notifications**: Where the manufacturer must report a vulnerability under Article 14, the authorised representative may be responsible for ensuring these notifications reach the relevant national CSIRT.

**Notify the manufacturer of enforcement actions**: If authorities take corrective action or require product withdrawal, the representative must promptly inform the manufacturer.

#### Choosing an Authorised Representative
The authorised representative must be a legal entity or natural person established in the EU. They can be a specialist compliance service provider, an EU subsidiary of the manufacturer, an importer who takes on this role, or a dedicated EU regulatory representative firm.

When choosing a representative, manufacturers should consider:

**Competence**: Does the representative understand cybersecurity product regulation and the CRA specifically? Authorised representative services provided by general compliance firms may not have the technical depth needed for CRA.

**Liability**: The authorised representative can incur personal liability for CRA violations where the manufacturer has failed to comply. Representatives should have adequate indemnification arrangements and professional liability insurance.

**Accessibility**: National authorities may require urgent responses. The representative must be reachable quickly and be able to respond within required timeframes.

**Mandate scope**: The written mandate between manufacturer and representative must clearly define what the representative is authorised to do, particularly whether they can make compliance decisions on behalf of the manufacturer or merely relay communications.

#### Relationship Between the Authorised Representative and the Importer
Article 18 and Article 13 create two overlapping categories: authorised representatives and importers. Both have EU-based obligations, but they serve different functions.

The authorised representative is specifically appointed by the manufacturer through a written mandate and acts as the manufacturer's legal representative for regulatory purposes. The importer is the entity that physically places the product on the EU market by importing it into EU territory.

In practice, the same entity can be both the authorised representative and the importer. An EU distributor who imports a US manufacturer's products and is also formally appointed as the authorised representative wears both hats simultaneously.

Where they are different entities, the obligations differ: the importer has specific obligations under Article 13 related to verification before placing products on the market, while the authorised representative has the broader mandate to interact with authorities on the manufacturer's behalf.

#### Termination and Change of Authorised Representative
When an authorised representative relationship ends - because the representative withdraws, the manufacturer terminates the mandate, or the representative entity ceases to exist - the manufacturer must appoint a replacement before continuing to place products on the EU market. Products already on the market under a previous representative's watch do not become non-compliant simply because the representative changes, but ongoing market activity requires a valid representative at all times.

Changes of authorised representative must be reflected in updated EU Declarations of Conformity and in product documentation where the representative's contact details are provided. Where the CE marking documentation references the former representative, updated documentation must be prepared and made available.

Manufacturers should ensure authorised representative agreements include clear provisions for continuity obligations during transition periods to avoid regulatory gaps.

### Importer Obligations Under the Cyber Resilience Act
URL: https://cvdportal.com/cra/article-19

Article 19 places specific obligations on importers - entities that bring products with digital elements manufactured outside the EU into the EU market for the first time. Importers must verify that manufacturers have met their CRA obligations before placing products on the market, and they bear personal liability for non-compliant products they import. This provision creates a compliance gateway role for importers within the EU supply chain.

#### The Importer's Verification Obligation
Article 19 requires importers to perform due diligence before placing a non-EU-manufactured product on the EU market. Specifically, importers must verify that:

1. The manufacturer has performed the applicable conformity assessment procedure
2. The manufacturer has drawn up the technical documentation under Annex VII
3. The product bears the CE marking
4. The manufacturer has drawn up the EU Declaration of Conformity
5. The manufacturer has appointed an authorised representative (where required under Article 18)
6. The product is accompanied by the required user information under Article 13 and Annex II

This verification obligation makes the importer a compliance gatekeeper - they cannot simply pass through products without checking that manufacturers have met their obligations. Importers who knowingly place non-compliant products on the market can face penalties under Article 64.

#### What Importers Must Do When Non-Compliance Is Found
If an importer finds that a product does not comply with the CRA essential requirements, or that the manufacturer has not completed the required conformity assessment, the importer must not place the product on the market until compliance is achieved. The importer must inform both the manufacturer and the market surveillance authorities of the non-compliance.

Where a product presents a serious risk, the importer must immediately inform the national market surveillance authority and the manufacturer. Importers should have processes for handling compliance holds - including storage of non-compliant products, communication with manufacturers, and documentation of the non-compliance findings.

This obligation creates a practical need for importers to have some technical competence in cybersecurity requirements, or to engage technical advisors who can assess manufacturer compliance claims. Simply accepting a manufacturer's declaration without meaningful verification may not meet the Article 19 standard.

#### Importer Information and Traceability Requirements
Article 19 requires importers to ensure traceability - specifically, that their name, registered trade name or mark, and postal address (and website or email address where applicable) are indicated on the product or on its packaging. This enables market surveillance authorities and consumers to identify the EU entity responsible for the product's market entry.

For digital products where physical labelling is not practicable, these details may be provided in the accompanying documentation or in a prominent location on the product's digital interface. The importer's contact details must be in a language easily understood by end users and national authorities in the member state where the product is sold.

Importers must also keep copies of the EU Declaration of Conformity for 10 years after placing the product on the market, and must make these available to authorities on request.

#### Obligations Regarding Products Already on the Market
Once a product is on the market, importers retain ongoing obligations. Where an importer has reason to believe a product no longer complies with the essential requirements - for example, because new vulnerabilities have been discovered or because the manufacturer has failed to provide security updates - the importer must take corrective action.

Correctional actions available to importers include:
- Requiring the manufacturer to provide security updates or remediation
- Withdrawing the product from sale pending remediation
- Recalling products already in users' hands where they present a serious risk
- Notifying national market surveillance authorities of a risk

Importers should maintain ongoing communications with manufacturers to receive alerts about newly discovered vulnerabilities and available security updates. Supply agreements with non-EU manufacturers should include contractual obligations requiring manufacturers to inform importers of CRA-relevant events.

#### Sample Testing and Documentation Checks
Article 19 permits importers to carry out sample testing of products that have been placed on the market and to investigate complaints. This is not a requirement to test every product, but rather an authorisation to conduct quality-control checks as part of the ongoing verification obligation.

Practically, importers serving high-volume markets should consider periodic testing of product samples to verify that the conformity documentation reflects the actual product. Discrepancies between declared specifications and actual product characteristics are a compliance risk - both for the manufacturer and for the importer who placed the product on the market.

Importers should document their verification activities, including records of documentation checks, sample testing results, and any communications with manufacturers regarding compliance issues. This documentation demonstrates due diligence in the event of a market surveillance investigation.

### Scope and Exclusions Under the Cyber Resilience Act
URL: https://cvdportal.com/cra/article-2

Article 2 defines the scope of the CRA - which products and economic operators are covered - and sets out important exclusions for sectors already regulated under other EU frameworks. Understanding the scope boundaries is critical for manufacturers who operate across multiple product categories or who supply products to regulated industries such as medical devices, aviation, or automotive. Where exclusions apply, the CRA does not impose additional obligations, but the underlying sector regulation typically has its own cybersecurity requirements.

#### General Scope: Products with Digital Elements
Article 2(1) applies the CRA to products with digital elements that are placed on the market or put into service in the EU, where those products have a direct or indirect logical or physical data connection to a device or network. This captures a very broad range of hardware and software products - from consumer IoT devices and industrial sensors to operating systems, firmware, and standalone software applications.

The key qualifying condition is the network or device connection. A purely mechanical product with no digital components falls outside the scope. However, a product that includes an embedded microcontroller with network capability, even if that capability is not its primary function, is likely within scope. Manufacturers of complex multi-component systems should assess each component independently as well as the system as a whole.

#### Excluded Sectors: Medical Devices and IVDs
Products regulated under the EU Medical Device Regulation (MDR, Regulation 2017/745) and the In Vitro Diagnostic Medical Devices Regulation (IVDR, Regulation 2017/746) are excluded from CRA scope. These regulations already impose cybersecurity requirements on medical devices, including post-market surveillance and incident reporting obligations.

Manufacturers of medical devices that connect to networks must still comply with MDR/IVDR cybersecurity requirements, which are enforced through notified bodies and the EUDAMED database. The practical effect of the exclusion is that medical device manufacturers do not face dual obligations under both the CRA and MDR/IVDR - the sector-specific regime prevails.

Note that this exclusion applies to the device itself. Software that is a medical device (SaMD) is excluded, but general-purpose software that interfaces with a medical device but is not itself a medical device is not automatically excluded.

#### Excluded Sectors: Aviation, Vehicles, and Maritime
Products regulated under EU aviation safety rules (EASA Regulation 2018/1139) are excluded from the CRA. Aviation-specific cybersecurity requirements apply through EASA certification processes, which include security assessments for software and systems in aircraft.

Vehicles type-approved under UNECE WP.29 cybersecurity regulations (implemented in the EU through Regulation 2019/2144) are similarly excluded. The UNECE WP.29 framework already requires vehicle manufacturers to implement cybersecurity management systems and maintain them throughout the vehicle lifecycle.

These exclusions reflect the EU legislature's preference for avoiding regulatory duplication in safety-critical sectors where sector-specific cybersecurity frameworks already exist and are enforced by specialist bodies. Manufacturers operating in these sectors should document which regulatory framework applies to each product line.

#### Excluded Sectors: Military and National Security
Products intended exclusively for military or national security purposes are excluded from the CRA's scope. This exclusion reflects the constitutional limits of EU competence in defence and national security matters, which remain primarily within member state jurisdiction.

The exclusion applies to products specifically designed, manufactured, and used for military or national security purposes. Dual-use products - those sold to both civilian and military customers - are not automatically excluded. If a product is placed on the general civilian market, even if the manufacturer also supplies it to defence customers, the CRA applies to the civilian market version.

Manufacturers of dual-use products should carefully assess which version of their product is subject to CRA obligations and ensure that civilian market versions comply accordingly.

#### Open-Source Software and the CRA
Article 2 makes clear that not-for-profit open-source software distributed freely is generally outside the CRA's commercial scope. However, this exclusion is narrower than it might appear. Open-source software that is monetised - through support contracts, managed services, or integration into commercial products - falls within scope through the commercial entity that monetises it.

The CRA introduces the concept of 'open-source software stewards' - foundations and organisations that systematically supply open-source software - and creates a lighter-touch obligation regime for them. Stewards do not bear the full obligations of a manufacturer but must cooperate with manufacturers who use their components and must maintain a CVD policy.

For most commercial software companies that use open-source components, the CRA obligations flow to the manufacturer of the final product, not to the upstream open-source project maintainers.

#### Products Placed on the Market vs. Custom-Built Products
The CRA applies to products 'placed on the market' - meaning made available to third parties through a commercial distribution channel. Custom-built products manufactured for a single customer's specific use, and not made available more broadly, occupy a grey zone that may be addressed in implementing guidance.

Products developed entirely in-house for internal use, with no distribution to third parties, are generally not within scope. However, manufacturers who sell or license products to external customers, even under bespoke contracts, are likely within scope. The key question is whether the product is made available to parties beyond the manufacturer's own organisation.

#### Are web applications and websites in scope?
Generally not. Commission guidance C(2026) 5252 explains that for software to fall within the CRA it must be provided to a user, obtained by that user, and operated on or as part of an electronic information system on the user's side. Software that executes remotely and is merely accessed by the user does not meet that description, which is typically the case for web applications, including progressive web apps, accessed exclusively through a browser. Websites are not themselves products with digital elements, and enter scope only where they support the functionality of a product, meaning they qualify as remote data processing.

The delivery model decides this rather than the technology. A desktop application built with web technologies but packaged for local installation is a product with digital elements, as is a browser extension and a mobile application downloaded from an app store.

Hardware and the software necessary for it to perform its intended functions form a single product, even where the software is obtained through a separate channel after the hardware was placed on the market. Printer drivers and companion apps for wearables both fall on this side of the line.

Components designed and constructed exclusively for integration into vehicles covered by Regulation (EU) 2019/2144 or Regulation (EU) No 168/2013 are out of scope. Selling a generic equivalent through channels open to the general public brings it back in, whatever the stated intended use.

### Distributor Obligations Under the Cyber Resilience Act
URL: https://cvdportal.com/cra/article-20

Article 20 addresses distributors - entities in the supply chain that make products with digital elements available on the EU market but who are not the manufacturer or importer. Distributors have lighter obligations than manufacturers and importers, but they still have a duty to verify that products are compliant before making them available and to cooperate with authorities when issues arise. Distributors who modify products or sell them under their own name take on manufacturer-level obligations.

#### Who Is a Distributor Under the CRA
A distributor is any entity in the supply chain other than the manufacturer or importer that makes a product with digital elements available on the EU market. This covers retailers, resellers, wholesalers, and online marketplaces that sell third-party products to EU consumers.

The key distinction from an importer is that the distributor makes products available on the market - typically through an existing EU supply chain - rather than placing them on the market for the first time. Retailers, department stores, electronics resellers, and online platforms are the most common distributor category under the CRA.

Distributors who act only as passive intermediaries - passing products from the supply chain to end users without modification - have lighter obligations than manufacturers and importers. However, 'passive' is interpreted strictly: any modification of the product, its packaging, or its labelling that could affect compliance converts the distributor to a manufacturer under Article 19.

#### Verification Obligations Before Making Products Available
Before making a product available on the EU market, distributors must verify that the product bears the CE marking and that the required documentation accompanies the product. Specifically, distributors should check:

1. That the CE marking is affixed to the product or its packaging
2. That the product is accompanied by required information under Annex II
3. That the manufacturer's name and contact details are indicated
4. That where required, the authorised representative's details are provided

Distributors are not required to conduct deep technical assessments of manufacturer compliance - their verification obligation is primarily documentary and visual. However, where a distributor has reason to believe a product is non-compliant - for example, if the CE marking appears incorrectly applied or if there are obvious security concerns - they must not make the product available until the concern is resolved.

#### Storage and Transport Obligations
Article 20 requires distributors to ensure that while a product is in their possession, storage and transport conditions do not compromise the product's compliance. For physical products with digital elements, this primarily means ensuring that products are stored and handled in ways that prevent physical tampering with security features.

For software products distributed digitally, distributors must ensure that distribution mechanisms (download links, update servers, application stores) maintain the integrity of the software. Tampered or modified software distributed under the manufacturer's name creates serious compliance risks for the distributor.

Distributors using third-party logistics or distribution platforms should include appropriate contractual requirements regarding product integrity in their logistics agreements.

#### Actions When Non-Compliance Is Suspected or Confirmed
Where a distributor has reason to believe that a product they have made available on the market does not meet CRA requirements, they must immediately inform the manufacturer or importer and ensure that corrective action is taken. Where the risk is serious, the distributor must also immediately inform national market surveillance authorities.

Distributors must cooperate with national authorities on their request, providing information and documentation necessary to verify compliance. This includes providing records of supply chain transactions, product documentation, and communications with manufacturers and importers.

Where corrective action requires product recall or withdrawal, distributors must cooperate with the recall process - for example, by ceasing sales, contacting customers who purchased affected products, and facilitating returns where necessary.

#### Traceability and Record Keeping
Distributors must be able to identify the manufacturer and importer for any product they make available. This traceability requirement exists to enable authorities to trace non-compliant products back to their source and to enable recalls to be executed effectively.

Practically, distributors should maintain records of their suppliers, the products they supply, and the relevant compliance documentation provided. Purchase orders, delivery records, and supplier documentation should be retained for a sufficient period to enable traceability. Many distributors maintain these records as part of normal commercial practice, but the CRA creates a legal obligation to ensure traceability specifically for compliance purposes.

Distributors operating at scale - particularly large retailers and online marketplaces - should consider whether their existing supplier management and documentation systems are adequate to meet this traceability requirement across their full product range.

### When Importers and Distributors Are Treated as Manufacturers
URL: https://cvdportal.com/cra/article-21

Article 21 closes a potential compliance gap by treating importers and distributors as manufacturers - with the full weight of manufacturer obligations - in two key scenarios: when they place a product on the market under their own name or brand, and when they modify a product in a way that could affect its compliance with CRA requirements. This provision prevents companies from avoiding CRA obligations by acting as intermediaries while substantively behaving as manufacturers.

#### The Own-Brand / Own-Name Scenario
Article 21(1)(a) provides that an importer or distributor who places a product on the EU market under their own name or brand is treated as a manufacturer for the purposes of all CRA obligations. This is commonly known as the 'own-label' or 'private-label' scenario.

The practical implication is significant: a company that sources a product from an Asian manufacturer and sells it in Europe under its own brand name cannot rely on the original manufacturer's CE marking and conformity documentation. It must:

- Conduct its own conformity assessment
- Prepare its own technical documentation under Annex VII
- Draw up and sign its own EU Declaration of Conformity
- Affix the CE marking under its own responsibility
- Take on the full Article 13 CVD obligations
- Bear all post-market monitoring and update obligations

This provision affects a large number of retailers and resellers who operate own-label electronics, home automation devices, and consumer IoT products sourced from third-party manufacturers.

#### The Product Modification Scenario
Article 21(1)(b) provides that an importer or distributor who modifies a product already placed on the EU market in a way that could affect its compliance with CRA requirements is treated as a manufacturer. This applies to substantive modifications - changes that affect the product's security properties, its software, or its compliance documentation.

Examples of modifications that would trigger Article 21 treatment include:

- Replacing the product's operating system or firmware with a modified version
- Adding software components not covered by the original manufacturer's assessment
- Changing the product's network connectivity or communication protocols
- Modifying the product's authentication or access control mechanisms
- Altering the product's update mechanism in ways that affect its ability to receive security patches

Cosmetic changes that have no bearing on cybersecurity compliance - such as changing the product's colour, packaging, or adding the company's own branding sticker - do not trigger Article 21. The test is whether the modification could affect the product's compliance with the CRA's essential requirements.

#### Practical Consequences of Article 21 Status
A company treated as a manufacturer under Article 21 takes on all the obligations of a manufacturer - including the most demanding post-market obligations. These include:

**Full CVD policy**: Must establish and publicly maintain a coordinated vulnerability disclosure policy under Article 13.

**Article 14 reporting**: Must report severe vulnerabilities and security incidents to ENISA through the national CSIRT within the required timeframes.

**Security updates**: Must provide free security updates for the full support period and cannot rely on the original manufacturer's update infrastructure.

**Technical documentation**: Must prepare and maintain the full technical file under Annex VII, including the risk assessment, security testing evidence, and SBOM.

**Post-market monitoring**: Must actively monitor for vulnerabilities in the product, including those that might originate in components sourced from the original manufacturer.

For companies that were previously operating as distributors, the transition to Article 21 manufacturer status involves significant operational changes and compliance investments.

#### Distinguishing Own-Label from Authorised Reselling
Article 21 creates an important distinction between selling under your own name and authorised reselling. An authorised reseller who sells a product under the original manufacturer's brand, with the original manufacturer's documentation and CE marking, remains a distributor. The manufacturer retains compliance responsibility.

However, companies must be careful about the extent to which they customise product presentation. Adding a significant co-brand or selling under a product name that differs substantially from the manufacturer's original designation can blur the line between authorised reselling and own-label. Companies should obtain clear written guidance from their legal advisors about whether their specific commercial model constitutes own-labelling under Article 21.

Contractual arrangements between the original manufacturer and the reseller can allocate compliance responsibilities, but these contractual arrangements do not override the regulatory obligations - they merely provide a basis for cost recovery and indemnification if the reseller incurs compliance liability.

#### Due Diligence Before Assuming Article 21 Status
Companies that know they will be treated as manufacturers under Article 21 should build their compliance obligations into the product sourcing and development process from the outset. This means:

**Technical due diligence on source products**: Before committing to an own-label product, assess whether it can meet CRA essential requirements. Request SBOM information, security testing evidence, and vulnerability history from the original manufacturer.

**Contractual provisions**: Include provisions in OEM/ODM agreements that require the original manufacturer to provide security-related information, disclose known vulnerabilities, and continue to supply security update capability for your products.

**Security testing budget**: Factor in the cost of independent security testing for own-label products as part of the product development and launch budget.

**CVD infrastructure**: Build or procure CVD process infrastructure - monitoring inbox, triage processes, tracking systems, advisory publication capability - before the product reaches the market.

### Identification and Obligations of Economic Operators
URL: https://cvdportal.com/cra/article-23

Article 23 complements Article 14 by specifying reporting obligations to market surveillance authorities (MSAs) in addition to ENISA. It also addresses how reports are shared between national authorities and what information manufacturers must provide to users affected by security incidents.

#### Article 23 vs Article 14: What Is the Difference?
Articles 11 and 14 both deal with reporting, but to different recipients:

- **Article 14**: Report actively exploited vulnerabilities and severe incidents to **ENISA** (via your national CSIRT) within 24h/72h/14d timelines.
- **Article 23**: Additional obligations to notify **market surveillance authorities (MSAs)** and **users** of your products about incidents and their impact.

In practice, most critical incidents will trigger both Article 14 (ENISA reporting) and Article 23 (user notification and MSA cooperation) obligations simultaneously.

#### User Notification Requirements
Article 23 requires manufacturers to **notify users** of their products when a security incident or actively exploited vulnerability may affect them. This notification must:

- Be provided without undue delay after the manufacturer becomes aware of the incident
- Include information about the nature of the impact
- Explain what users can do to protect themselves (mitigations, workarounds)
- Describe when a security update will be available

For consumer products, this typically means a public security advisory on your website. For enterprise products, this may require direct notification to customers via email, support portal, or account managers.

#### Cooperation with Market Surveillance Authorities
Article 23 establishes manufacturers' obligations to cooperate with national market surveillance authorities (MSAs). MSAs have broad investigative powers under the CRA, including the right to:

- Request technical documentation and conformity assessment records
- Conduct product testing
- Require manufacturers to take corrective action
- Order product recalls or market withdrawals

Manufacturers must maintain records in a format that can be quickly provided to MSAs, and must designate a contact point for regulatory communications.

### Obligations of Open-Source Software Stewards Under the CRA
URL: https://cvdportal.com/cra/article-24

Article 24 introduces the concept of 'open-source software steward' — an entity that provides a platform or support for the ongoing development of open-source software used in products with digital elements, without placing a product on the market itself. Open-source stewards are not manufacturers and are not subject to CE marking or EU Declaration of Conformity obligations. However, they must put a cybersecurity policy in place, publish a vulnerability disclosure process, and cooperate with market surveillance authorities — recognising their structural role in the supply chain.

#### Who Is an Open-Source Software Steward?
An open-source software steward is defined as a legal person (not an individual) that:

1. **Provides a platform or environment** for the development or distribution of open-source software intended for integration into products with digital elements
2. **Does so on a non-commercial basis** — or where commercial activities do not constitute the primary purpose
3. **Does not place products on the market itself** in a way that makes it a manufacturer under Article 13

Typical examples include:
- Linux foundations and similar non-profit organisations managing major open-source projects
- Public benefit entities maintaining security libraries, cryptographic toolkits, or operating system components
- Academic institutions managing software repositories used in commercial products

Individual developers who contribute to open-source projects — but do not manage the overall platform — are explicitly excluded from the steward definition.

#### The Cybersecurity Policy Requirement
Article 24 requires open-source software stewards to put in place and document a **cybersecurity policy** covering:

- How security vulnerabilities in the managed software are identified, assessed, and addressed
- The processes by which security patches and updates are developed and released
- How external vulnerability reports are received and handled
- How the steward communicates security information to downstream users (manufacturers integrating the software)

This policy need not be as comprehensive as a manufacturer's full security development lifecycle documentation, but it must be documented and publicly accessible. The policy demonstrates that the steward takes a structured approach to security rather than an ad hoc one.

#### Vulnerability Disclosure for Open-Source Stewards
Article 24 requires open-source software stewards to operate a process for receiving and handling vulnerability reports — essentially a CVD policy equivalent. This process must:

- Provide a publicly accessible mechanism for reporting vulnerabilities (typically a security.txt file, a SECURITY.md in the repository, or a dedicated reporting form)
- Acknowledge receipt of vulnerability reports
- Provide reporters with a process timeline and coordinate disclosure
- Publish security advisories when vulnerabilities are fixed

Article 24(3) does extend parts of Article 14 to stewards, so the 24-hour and 72-hour clocks are not switched off across the board. How far they reach depends on the kind of support the steward provides, which is set out further below. Where a reporting duty does not apply, voluntary reporting under Article 15 stays open.

#### Cooperation with Market Surveillance Authorities
Article 24 requires open-source software stewards to cooperate with national market surveillance authorities (MSAs) when requested. This may involve:

- Providing information about the software's security properties, architecture, or known vulnerabilities
- Assisting MSAs in understanding the supply chain implications of a vulnerability in the managed software
- Providing technical documentation about the software's development processes and security controls

The cooperation obligation is less extensive than a manufacturer's obligations — MSAs cannot order product recall or CE marking withdrawal from an open-source steward. However, the cooperation obligation ensures that MSAs can get the information they need to assess the risk posed by vulnerable open-source components integrated into regulated products.

#### What Open-Source Stewards Are NOT Required to Do
To avoid chilling open-source development, Article 24 explicitly carves out several obligations that manufacturers face but stewards do not:

- **No CE marking** — open-source stewards do not need to affix CE markings to software
- **No EU Declaration of Conformity** — no formal conformity declaration is required
- **No conformity assessment** — no notified body involvement is required
- **Article 14 reporting only where the steward is involved** — a steward that neither develops the product nor provides the systems used to develop it carries no 24h/72h duty, but Article 24(3) does apply Article 14(1), (3) and (8) to those that do
- **No SBOM requirements** — no formal software bill of materials obligation under Article 13(6)

Manufacturers who **commercialise** open-source software (sell it, monetise it, bundle it in commercial products) become manufacturers under Article 13 and lose the steward carve-out. The line between steward and manufacturer is primarily drawn by commercialisation.

#### How far do a steward's reporting duties actually go?
Article 24(3) applies Article 14(1), (3) and (8) to stewards, and Commission guidance C(2026) 5252 makes clear that how far they apply depends on the kind of support the steward provides.

A steward providing only non-technical support, such as managing project branding, laying down governance rules, organising community events or collecting donations, is by definition not involved in developing the product and provides no network and information systems for it. It is not required to report actively exploited vulnerabilities, and not required to report severe incidents. Where it does become aware of an actively exploited vulnerability, for example through a security researcher, it should share the information with the maintainers in line with its cybersecurity policy, and voluntary reporting under Article 15 should be considered.

A steward that provides the underlying IT infrastructure, such as hosting source code repositories, version control or signing keys, must notify ENISA and the CSIRTs under Article 14(3) of severe incidents affecting that infrastructure which have an impact on the security of the products, and inform users where appropriate.

A steward that contributes engineering resources, by employing developers, coordinating development, reviewing or merging code, managing releases or handling vulnerability reports, must additionally notify actively exploited vulnerabilities under Article 14(1) and, where it has a direct relationship with impacted users, inform them under Article 14(8).

A steward is likely to learn of active exploitation through downstream reports, because the component sits inside other products. An entity that stops providing sustained support may cease to be a steward, and is encouraged to communicate that change clearly.

### Security Attestation of Free and Open-Source Software
URL: https://cvdportal.com/cra/article-25

Article 25 establishes a voluntary security attestation programme for free and open-source software (FOSS). ENISA runs the programme, which enables open-source components to undergo a structured security assessment and receive an attestation certificate. Manufacturers integrating attested FOSS components into their products can reference the attestation as evidence of component due diligence under Article 13. The programme bridges the gap between the CRA's manufacturer obligations and the open-source ecosystem's development model.

#### What Is Security Attestation Under Article 25?
Security attestation is a voluntary, structured assessment of a free and open-source software component's security properties, carried out under a programme administered by ENISA. A successful attestation results in a certificate confirming that the assessed component meets specified security criteria.

Attestation is distinct from the mandatory conformity assessment under Articles 7 and 8. It does not create CE marking obligations or an EU Declaration of Conformity for the open-source component. Instead, it provides a third-party-validated security credential that manufacturers can reference when documenting their component due diligence under Article 13(6)-(8).

The attestation is particularly valuable for widely-used open-source libraries and components that are integrated into dozens or hundreds of commercial products — enabling manufacturers to rely on a single assessment rather than each independently evaluating the component.

#### How the Attestation Programme Works
ENISA establishes the technical criteria and procedural framework for the attestation programme. The expected process is:

1. **Application**: The open-source steward (or a manufacturer on behalf of a component they extensively use) applies to ENISA or an accredited assessment body
2. **Technical assessment**: The component undergoes security assessment covering source code analysis, dependency review, vulnerability history, and development security practices
3. **Attestation decision**: The assessor issues an attestation certificate if the criteria are met, specifying the component version(s) assessed, the scope of the assessment, and the validity period
4. **Public listing**: Attested components are listed in a public ENISA registry, enabling manufacturers to identify and reference attested components
5. **Renewal**: Attestations are time-limited; stewards must re-apply for renewed attestation when software versions change materially

ENISA publishes the technical criteria for attestation, which manufacturers can use to assess whether unattested components meet equivalent standards.

#### Value for Manufacturers Under Article 13
For manufacturers integrating FOSS components into their products, Article 25 attestation provides practical value for Article 13(6)-(8) component due diligence:

- **Reduced assessment burden**: A manufacturer can rely on ENISA's attestation rather than conducting an independent security review of the component
- **Documented due diligence**: The attestation certificate is a concrete, auditable record of component security assessment
- **Conformity assessment support**: For Annex III products, a notified body assessing the product can take comfort from attested components, potentially reducing assessment scope

Manufacturers should note that using an attested component does not transfer compliance responsibility. The manufacturer remains responsible for ensuring the component is correctly integrated and remains free from newly discovered vulnerabilities after attestation. Attestation is evidence of due diligence at a point in time, not a guarantee of ongoing security.

#### Interaction with Existing Security Certifications
Article 25 attestation is designed to complement — not duplicate — existing security certifications for open-source software. Where a component already holds a relevant certification (e.g., Common Criteria EAL for a cryptographic library), ENISA may accept this as equivalent to or supporting evidence for attestation, avoiding unnecessary duplication.

The programme also interfaces with the broader EU cybersecurity certification framework under the EU Cybersecurity Act. For components used in Annex IV (critical) products, the attestation level may need to meet the 'substantial' assurance threshold.

### Presumption of Conformity, Harmonised Standards, and Common Specifications
URL: https://cvdportal.com/cra/article-27

Article 27 governs how harmonised European standards and common specifications create a legal presumption of conformity with the CRA's essential cybersecurity requirements. When a manufacturer applies a harmonised standard published in the EU Official Journal, their product is presumed to meet the essential requirements that standard covers. Article 27 also governs the Commission's power to object to harmonised standards that do not adequately cover the essential requirements.

#### What Harmonised Standards Are
Harmonised standards are European standards (EN standards) developed by European standardisation organisations - CEN, CENELEC, or ETSI - following a mandate from the European Commission. Unlike general ISO or IEC standards, harmonised standards are specifically aligned with the essential requirements of EU legislation and, once published in the EU Official Journal, carry the legal presumption of conformity benefit.

For the CRA, the Commission will issue standardisation mandates to ETSI and CEN/CENELEC to develop harmonised standards covering the essential requirements in Annex I. These standards will provide detailed, product-category-specific technical specifications for how to meet each requirement.

Prior to harmonised standards becoming available, manufacturers may use existing technical specifications such as ETSI EN 303 645 (consumer IoT), IEC 62443 (industrial automation), or ENISA guidelines as supporting evidence, though these do not provide the formal presumption of conformity.

#### How to Identify Applicable Harmonised Standards
Harmonised standards applicable to the CRA will be published in the EU Official Journal with references indicating which essential requirements they cover. Manufacturers should monitor the Official Journal regularly to identify newly published standards relevant to their product categories.

The European Commission's standardisation database also provides searchable access to published harmonised standards by regulation. ETSI's portal and CEN/CENELEC's standards catalogue list standards under development, giving manufacturers advance notice of upcoming standards they may wish to follow.

For product categories where no harmonised standard yet exists, manufacturers must use alternative means to demonstrate compliance - typically through technical documentation, third-party testing, or reference to relevant ISO/IEC standards - while accepting that no formal presumption of conformity applies.

#### Partial Application of Harmonised Standards
Manufacturers are not required to apply harmonised standards in their entirety. Where a standard covers requirements that are not applicable to a specific product, or where a manufacturer has achieved compliance through different technical means, partial application is permissible. However, the presumption of conformity only applies to the requirements actually covered by the portions of the standard that are applied.

Where a manufacturer deviates from a harmonised standard - for example, by using a different cryptographic algorithm than specified - they must document the deviation and provide alternative evidence that the essential requirement is met. This documentation forms part of the technical file that must be maintained under Annex VII.

Audit trails and version control of standard references are important: where a harmonised standard is revised, manufacturers should assess whether the updated version affects their compliance position.

#### Common Specifications as an Alternative
Where harmonised standards are not yet available or are considered inadequate, Article 27 allows the Commission to adopt 'common specifications' - implementing acts that set out the technical requirements manufacturers may use as an alternative compliance pathway. Common specifications also provide a presumption of conformity for the requirements they cover.

Common specifications are typically used as a transitional measure while the standardisation process catches up with new regulatory requirements, or in areas where the standardisation bodies have not produced suitable standards within a reasonable timeframe. They have the same legal status as harmonised standards for the purposes of the presumption of conformity but are issued by the Commission rather than developed through the European standardisation process.

#### The Legal Effect of Conformity
Article 27 establishes a legal presumption: where a product conforms to a harmonised standard published in the EU Official Journal under Article 7, it is presumed to comply with the essential requirements of Annex I that are covered by that standard. This is a procedural advantage with significant practical value.

Without the presumption, a manufacturer facing scrutiny from a market surveillance authority would need to affirmatively prove compliance with each essential requirement. With the presumption, the burden shifts - the authority must demonstrate that the product fails to meet the requirement despite application of the standard.

The presumption applies to the specific requirements covered by the harmonised standard. Standards typically include an annex or scope statement identifying which regulatory requirements they address. Manufacturers should carefully check this mapping to confirm which essential requirements are covered.

#### Scope and Limits of the Presumption
The presumption of conformity is not unlimited. It applies only to:

1. The specific harmonised standard actually applied (not merely referenced)
2. The essential requirements that the standard covers
3. The version of the standard that is currently referenced in the Official Journal

A manufacturer who applies an outdated version of a harmonised standard, or who applies only parts of the standard, benefits from the presumption only to the extent of their actual compliance. Where a product deviates from the standard's requirements - even in minor ways - the presumption may be weakened or lost for the affected requirements.

The presumption also operates at the product level, not the batch level. If a manufacturer discovers a defect in a specific production batch that results in products not meeting the standard, the presumption does not protect those units even if the product design meets the standard.

#### Common Specifications as an Equivalent Pathway
Article 27 extends the presumption of conformity to products conforming to common specifications adopted under Article 7(4). Common specifications are Commission implementing acts that provide technical requirements as an alternative to harmonised standards, typically used where harmonised standards are not yet available or are considered insufficient.

From the manufacturer's perspective, common specifications and harmonised standards are functionally equivalent for presumption purposes - both create the same legal presumption when applied. The procedural differences are on the standards development side: harmonised standards are developed by European standardisation organisations through consultation processes, while common specifications are adopted directly by the Commission.

Manufacturers monitoring the compliance landscape should track both the Official Journal harmonised standards references and any Commission implementing acts adopting common specifications.

#### Interaction with Third-Party Conformity Assessment
For products in the default product class (not listed in Annex III), Article 25 allows self-certification through Module A internal control. The presumption of conformity from Article 27 supports this self-certification pathway - a manufacturer who applies a harmonised standard and self-certifies has strong legal grounds for the CE marking.

For Annex III Class I products, third-party involvement is required (either a quality assurance review of technical documentation or a third-party audit). Even in these cases, application of a harmonised standard streamlines the third-party assessment because the assessor can verify conformance to the standard rather than independently evaluating compliance with each essential requirement.

For Annex III Class II products, the most stringent third-party assessment is required, but harmonised standards still reduce the assessment workload by providing a structured framework for evaluation.

#### Maintaining the Presumption Over Time
The presumption of conformity is based on the product's compliance with the harmonised standard at the time of assessment. Manufacturers must maintain their compliance over time - particularly as standards are updated and as new vulnerabilities are discovered.

When a harmonised standard is revised and the new version is published in the Official Journal, manufacturers typically have a transition period to update their products and documentation to the new standard. During the transition period, compliance with the old version continues to create the presumption. After the transition period expires, only the new version maintains the presumption.

Manufacturers should establish a process for monitoring standard updates and assessing whether product updates are required to maintain compliance with current versions.

#### The Commission's Power to Object
Article 27 gives the European Commission the power to raise a formal objection to a harmonised standard where it considers that the standard does not fully satisfy the essential requirements it is intended to cover. This power exists as a quality-control mechanism over the standardisation process - ensuring that harmonised standards actually provide the level of protection the CRA requires.

An objection under Article 27 can result in the partial or full withdrawal of a standard's presumption of conformity. Once an objection is raised and implemented through the Official Journal, manufacturers relying on the objected standard can no longer benefit from the presumption of conformity for the disputed requirements. They must find alternative evidence of compliance.

The Commission's objection power is distinct from minor technical corrections to standards, which are handled through the normal standardisation revision process. Article 27 applies where there is a substantive disagreement about whether a standard meets the regulation's requirements.

#### Process for Raising Objections
Before raising a formal objection, the Commission consults with member states and stakeholder committees. This process typically involves the Standing Committee established under the relevant standardisation regulation, and may include consultation with the relevant standardisation body.

If the Commission decides to proceed with the objection, it issues an implementing act withdrawing or restricting the reference to the harmonised standard in the Official Journal. This act takes effect from its publication date, though transitional provisions may allow manufacturers a period to adjust.

The standardisation body is then responsible for revising the standard to address the Commission's concerns. The revised standard may be submitted for a new Official Journal reference, restoring the presumption of conformity once the Commission is satisfied that the deficiencies have been resolved.

#### Implications for Manufacturers
For manufacturers, Article 27 creates a risk that must be managed as part of their compliance strategy. A harmonised standard on which they have based their CE marking and technical documentation could be partially or fully invalidated, requiring them to reassess compliance and potentially update products or documentation.

Manufacturers should monitor the EU Official Journal and Commission communications for any Article 27 proceedings. Best practice is to maintain technical documentation that demonstrates compliance with the underlying essential requirements independently - not solely by reference to the harmonised standard. This provides resilience against standard objections.

Where a standard is objected to, manufacturers should assess whether the objection affects their specific product's compliance. Not all objections will affect every product - an objection to a specific requirement may not be relevant to products that are compliant with that requirement through other means.

#### Distinguishing Article 9 from Standard Revisions
It is important to distinguish Article 27 formal objections from the routine process of harmonised standard revision. Standards are regularly updated by standardisation bodies to reflect new technical developments, emerging threats, and improved understanding of security requirements. These routine revisions do not involve the Commission's formal objection process.

When a harmonised standard is revised through normal standardisation processes, the new version is published in the Official Journal, the old version's reference is typically withdrawn after a transition period, and manufacturers migrate to the new version during the transition period. This is a normal part of the compliance lifecycle and should be planned for.

Article 27 proceedings are more exceptional and represent a finding by the Commission that the standard is substantively deficient. They are expected to be relatively rare events rather than routine occurrences.

### EU Declaration of Conformity: Content, Structure, and Requirements
URL: https://cvdportal.com/cra/article-28

Article 28 requires manufacturers to draw up an EU Declaration of Conformity (DoC) before placing a product with digital elements on the EU market. The DoC is the formal document in which the manufacturer declares that the product meets all applicable CRA essential requirements. Article 28 specifies exactly what information the DoC must contain, making it a legally binding compliance statement that supports the CE marking.

#### What the EU Declaration of Conformity Must Contain
Article 28 specifies the minimum information that must appear in the EU Declaration of Conformity. The declaration must include:

1. **Product identification**: The product name, type, batch, serial number, or other element allowing unambiguous identification
2. **Manufacturer details**: Name and address of the manufacturer; if applicable, the authorised representative's name and address
3. **Declaration statement**: A statement that the manufacturer takes sole responsibility for the declaration of conformity
4. **Regulatory basis**: Identification of the CRA as the legislation to which the declaration relates, with specific references to Article 6 and Annex I
5. **Standards or specifications**: References to relevant harmonised standards applied, or to common specifications or other technical specifications used
6. **Conformity assessment procedure**: Identification of the conformity assessment procedure used (the relevant Module from Annex VI)
7. **Notified body details**: Where a notified body was involved, its name, identification number, and the certificate reference
8. **Additional certifications**: References to any other EU legislation under which CE marking is affixed
9. **Signature information**: Place and date of issue, name and function of the signatory

#### Language and Accessibility Requirements
The EU Declaration of Conformity must be drawn up in one of the official languages of the EU member states where the product is placed on the market. Where a product is sold across multiple EU member states, the declaration may need to be available in multiple languages, or member states may accept an English version for imported products - national rules vary.

The DoC must be kept available and must be accessible to market surveillance authorities throughout the product's active market life and for 10 years afterwards. Manufacturers should have systems for archiving declarations against product identifiers so that the correct version can be retrieved for any product unit.

For products sold in digital formats, the DoC may be made available electronically - for example, as a downloadable PDF on the manufacturer's website - rather than as a physical document accompanying the product. However, Article 28 requires that the DoC is available on request, so digital-only distribution must ensure reliable long-term accessibility.

#### The Simplified Declaration and Annex IX
Where a product is too small for a full EU Declaration of Conformity to accompany it (for example, a microchip or small embedded component), or where including the full DoC would be disproportionate, Article 28 allows the use of a simplified declaration format.

The simplified declaration, set out in Annex IX, contains a short statement that the full DoC is available at a specified URL. This is particularly relevant for embedded components, IoT devices in miniaturised form factors, and products where packaging space is severely constrained.

Manufacturers using the simplified declaration must ensure that the full DoC is genuinely available at the referenced URL throughout the relevant period and that the URL remains stable. Linking to a corporate homepage that might change structure is not adequate - the URL must resolve directly to the declaration document.

#### Single Declaration for Multiple Regulations
Many products are subject to multiple EU regulations simultaneously - for example, a Wi-Fi router may be subject to both the CRA and the Radio Equipment Directive (RED). Article 28 permits manufacturers to draw up a single EU Declaration of Conformity that addresses all applicable EU legislation, rather than separate declarations for each regulation.

A combined declaration must clearly identify each regulation to which it applies and the specific essential requirements and conformity assessment procedures relevant to each. Manufacturers taking this approach should ensure the declaration template is comprehensive and that no regulatory reference is overlooked.

The advantage of a combined declaration is administrative simplicity - a single document covers all CE marking obligations. The potential risk is that errors or omissions in the declaration may affect compliance under multiple regulations simultaneously.

#### Keeping the Declaration Up to Date
The EU Declaration of Conformity is not a static document - it must be updated when product changes occur that affect the product's compliance. If a significant software update changes the product's security properties, or if a new conformity assessment is required due to a material product modification, the DoC must be revised to reflect the updated compliance basis.

Manufacturers should establish version control for their DoCs and maintain a record of which version of the declaration applies to which product versions or production batches. When a declaration is revised, the previous version should be archived but should not be destroyed - authorities may need to review the declaration applicable to a specific historical product batch.

Minor product updates that do not affect compliance - such as software updates that fix bugs without changing security-relevant functionality - generally do not require DoC revision. The threshold for requiring a new declaration should be assessed against the materiality of the change to the product's compliance position.

### Definitions: Key Terms in the Cyber Resilience Act
URL: https://cvdportal.com/cra/article-3

Article 3 contains the statutory definitions that underpin the entire Cyber Resilience Act. The most consequential definition is 'product with digital elements' — any hardware or software product capable of connecting, directly or indirectly, to a device or network. Other defined terms establish who bears obligations (manufacturer, importer, distributor, authorised representative) and what types of activity are regulated (placing on the market, making available, substantial modification). Correctly applying these definitions is the essential first step in CRA compliance planning.

#### What Is a 'Product with Digital Elements'?
The CRA defines a **product with digital elements** as any software or hardware product (and its remote data processing solutions) that:

1. Can connect - directly or indirectly - to another device or network
2. Is placed on the EU market (sold to EU customers) after the application date

This is an intentionally broad definition. It covers:
- Physical hardware devices with embedded software (IoT devices, routers, industrial controllers)
- Standalone software applications (both desktop and mobile)
- Operating systems and firmware
- Software components sold as part of a larger product

**Key test**: Does the product have any form of network connectivity, even indirect? If yes, it is likely in scope.

#### What Is Excluded from CRA Scope?
Article 3 excludes products already subject to equivalent cybersecurity requirements under other EU regulations:

- **Medical devices** - Covered by MDR (Medical Device Regulation) and IVDR
- **Motor vehicles** - Covered by UNECE WP.29 and the EU type-approval framework
- **Civil aviation products** - Covered by EASA regulations
- **Marine equipment** - Covered under the Marine Equipment Directive
- **Military and national security products** - Excluded from EU internal market law entirely

Important: Products that partially overlap with these sectors but are not specifically regulated by sector-specific legislation may still be in scope. For example, a health and fitness tracker that is not classified as a medical device is not excluded from the CRA.

#### The SaaS and Cloud Services Question
Pure **Software as a Service (SaaS)** and cloud services are generally **not covered** by the CRA. The CRA focuses on products placed on the market - i.e., products that are downloaded, installed, or shipped as physical goods.

However:
- Software that is downloaded and installed on a device (mobile apps, desktop applications) is in scope.
- Hardware products that rely on cloud connectivity for their primary function are in scope (the hardware product, not the cloud service itself).
- If a vendor offers both a downloadable product and a cloud-hosted version, the downloadable product is likely in scope.

This distinction is important for software vendors who offer both SaaS and on-premise deployment options.

#### Who Has Obligations Under the CRA?
The CRA distinguishes between three roles in the supply chain:

1. **Manufacturers** - Companies that design, develop, and produce products, or have them designed/produced and sell them under their own name or trademark. Manufacturers bear the primary compliance obligations.

2. **Importers** - Companies that bring non-EU products into the EU market. Importers must verify manufacturer compliance and may bear liability if a manufacturer is unreachable.

3. **Distributors** - Companies that make products available on the EU market without placing them on the market themselves. Distributors have lighter obligations but must verify that products bear proper CE marking.

For global manufacturers with EU customers, the manufacturer obligations apply regardless of where the manufacturer is based.

#### How the Commission guidance reads the key definitions
Commission guidance C(2026) 5252 works through several Article 3 definitions in detail.

Remote data processing under Article 3(2) reduces to two cumulative questions. Would its absence prevent the product performing one of its functions, which is not limited to the core functionality or the intended purpose, and was the software designed and developed by the manufacturer or under its responsibility, meaning tailor-made to its own designs and specifications. Both yes makes the module part of the product. Your own software on a third-party IaaS or PaaS qualifies. A third-party SaaS application you integrate does not, and is treated as a component attracting Article 13(5) due diligence. Who operates the solution is irrelevant, so on-premises and private cloud qualify on the same terms as public cloud.

Substantial modification under Article 3(30) gains a four-factor test at guidance point 110. Does the change introduce new threat vectors, enable new attack scenarios, change the likelihood of previously identified attack scenarios, or change their impact. The scale of the change is expressly not part of the test.

Free and open-source software under Article 3(48) requires two things cumulatively. A licence granting the full set of rights, and source code that is openly shared. Software under a free licence whose source is shared only with paying customers or a limited group does not qualify.

### Rules and Conditions for Affixing the CE Marking
URL: https://cvdportal.com/cra/article-30

Article 30 is the technical 'how-to' provision for the CE marking under the Cyber Resilience Act. It tells manufacturers where the CE marking must physically appear (on the product, packaging, EU Declaration of Conformity, or accompanying website for software), how visible and legible it must be, when it must be affixed (before the product is placed on the market), and what must follow it (a pictogram, a notified body identification number for Module H assessments, or markings from other applicable Union harmonisation legislation). It also empowers the Commission to specify additional technical labelling rules through implementing acts and obliges Member States to act against improper CE marking use.

#### Where the CE Marking Must Be Affixed
Article 30(1) sets out a clear hierarchy for where the CE marking must appear:

1. **Primary location** — visibly, legibly, and indelibly on the product itself.
2. **Secondary location, if the product nature does not allow or warrant primary affixing** — on the packaging and on the EU Declaration of Conformity referred to in Article 28.
3. **For software products** — either on the EU Declaration of Conformity or on the website accompanying the software product. If the marking is on the website, the relevant section must be easily and directly accessible to consumers.

In practice this means physical hardware products carry a CE mark on the product surface or label. Embedded firmware or integrated software inherits the marking of the host hardware. Standalone applications and downloadable software products use the digital channel — DoC or website — because affixing a physical marking is not possible.

The hierarchy is not optional: a hardware manufacturer cannot choose to display the CE marking only on a website if it could reasonably be affixed to the product or its packaging.

#### Size and Legibility Requirements
Article 30(2) addresses the physical size of the CE marking. Under the EU's general New Legislative Framework rules and Regulation (EC) No 765/2008 — which Article 16 of the CRA explicitly imports — the CE marking is normally at least 5 mm high. Article 30(2) provides flexibility: the height may be lower than 5 mm where the nature of the product warrants it, provided the marking remains visible and legible.

This matters most for small IoT devices, embedded sensors, and miniature hardware where 5 mm exceeds available surface area. The test is whether the marking can be read in normal product use. A marking smaller than 5 mm that requires magnification to read does not meet the legibility requirement, even if the size reduction is otherwise justified by the product's nature.

#### Timing — CE Marking Before Market Placement
Article 30(3) establishes a strict timing rule: the CE marking must be affixed before the product is placed on the market. 'Placing on the market' is defined in Article 3 and refers to the first making available of a specific product on the Union market in the course of a commercial activity.

The practical consequence is that the entire compliance chain must be complete before market placement: conformity assessment, technical documentation, EU Declaration of Conformity, registration where applicable, and then — only after all of these are done — the CE marking. Affixing the marking prematurely, before the conformity assessment is complete, is a violation regardless of whether the product would have been compliant after the assessment.

Article 30(3) also permits the CE marking to be followed by a pictogram or other mark indicating a special cybersecurity risk or use, where such marks are set out in Commission implementing acts under Article 30(6). These pictograms are a forward-looking provision: at the date of writing, the Commission has not yet specified them.

#### Notified Body Identification Number for Module H Assessments
Article 30(4) addresses the marking requirements for products whose conformity assessment involved a notified body. Where the conformity assessment procedure is based on full quality assurance (Module H) under Article 32, the CE marking must be followed by the identification number of the notified body that conducted the assessment.

Who physically affixes the number is also specified: either the notified body itself, or — under the notified body's instructions — the manufacturer or the manufacturer's authorised representative. The instruction-based delegation is essential in practice, because notified bodies do not typically operate on manufacturer production lines; the delegation allows the manufacturer to apply the number while the notified body retains responsibility for its correct use.

Note the scope: Article 30(4) applies specifically to Module H assessments. Other conformity assessment modules under Article 32 do not require the notified body number to follow the CE marking. For Default class products using Module A self-assessment, no notified body number is involved.

#### Member State Enforcement of CE Marking Integrity
Article 30(5) directs Member States to build on existing mechanisms — those already established for the CE marking regime under Regulation (EC) No 765/2008 and other product legislation — to ensure correct application of the CE marking under the CRA, and to take appropriate action against improper use.

Improper use covers a range of scenarios: affixing the CE marking to a non-compliant product, affixing it before the conformity assessment is complete, using a CE-resembling mark on a product that is not subject to CE marking legislation, omitting the notified body identification number where Module H was used, or applying a CE marking that is not visible, legible, or indelible.

Member States typically rely on their national market surveillance authorities to enforce these rules, using the powers set out in Regulation (EU) 2019/1020 as applied by Article 52 of the CRA. Penalties for incorrect CE marking fall under Article 64 of the CRA (Penalties) and can reach the fines applicable to other obligations — up to €10 million or 2% of global annual turnover.

#### Multi-Regulation Products and the Single CE Marking
Many products with digital elements are also subject to other Union harmonisation legislation requiring CE marking — for example, the Radio Equipment Directive (RED), the Low Voltage Directive, the Machinery Regulation, or the Medical Device Regulation. Article 30 does not require multiple CE markings on the same product; a single CE marking suffices, and it indicates conformity with all applicable Union harmonisation legislation simultaneously.

Manufacturers must, however, ensure the EU Declaration of Conformity and technical documentation reference each applicable regulation. A CE marking on a product subject to both the CRA and the RED must be backed by a DoC that addresses both regulations and a technical file demonstrating conformity with both sets of essential requirements.

#### Implementing Acts on Labels, Pictograms, and Cybersecurity Marks
Article 30(6) empowers the European Commission to adopt implementing acts laying down technical specifications for labels, pictograms, or other marks related to:

- the security of products with digital elements;
- their support periods; and
- mechanisms to promote the use of such marks and to increase public awareness about product security.

Before drafting an implementing act, the Commission must consult relevant stakeholders and — once it has been established under Article 52(15) — the Administrative Cooperation Group on Cyber Resilience (ADCO). At the date of writing, no such implementing acts have been adopted, but they are anticipated as the CRA application date approaches. Manufacturers should track Commission consultations in this area, particularly any consultation related to a 'support period' indication that may need to appear alongside the CE marking.

#### Article 30 in the Broader CE Marking Workflow
Article 30 is the last step in a sequence — not a standalone obligation. Before reaching Article 30, manufacturers must complete:

1. Confirmation that the product is a 'product with digital elements' within scope (Articles 2 and 3).
2. Classification of the product as Default, Important Class I, Important Class II, or Critical (Annex III, Annex IV).
3. Completion of the cybersecurity risk assessment and Annex I conformity (Articles 6 and 13).
4. Selection and completion of the applicable conformity assessment procedure under Article 32 (self-assessment, Module B+C, or Module H).
5. Compilation of the technical documentation under Article 30 and Annex VII.
6. Drafting and signing the EU Declaration of Conformity under Article 28.
7. Compliance with the general principles of the CE marking set out in Article 16 — which itself imports the general CE marking principles of Regulation (EC) No 765/2008.

Only when all of these are complete does the manufacturer affix the CE marking under Article 30 and place the product on the market.

#### When the CE Marking Can Be Affixed
Article 30 establishes a strict sequencing requirement: the CE marking must only be affixed after the manufacturer has completed all applicable conformity assessment procedures. For default-class products, this means completing the Module A self-certification process, preparing the technical documentation under Annex VII, and drawing up the EU Declaration of Conformity. For Annex III products, the relevant notified body involvement must also be complete.

Affixing the CE marking before completing these steps - even if the manufacturer intends to complete them later - is a violation. The CE marking is a declaration that conformity has been achieved, not an aspiration or a work-in-progress indicator.

Manufacturers should build the conformity assessment process into their product launch timeline, treating it as a mandatory pre-launch gate rather than a parallel or post-launch activity.

#### Visibility, Legibility, and Indelibility
Article 30 requires the CE marking to be visible, legible, and indelible. These three requirements have specific practical implications:

**Visible**: The CE marking must be placed in a position where it can be seen by the user without disassembly or special tools. On physical products, this typically means placement on the product casing, its packaging, or an accompanying label. For digital products, the marking must be accessible in a readily accessible location in the product's interface or documentation.

**Legible**: The marking must be clear and easy to read. The CE marking has a minimum height of 5mm under EU product regulation conventions. It must be printed or affixed with sufficient contrast against its background to be readable.

**Indelible**: The marking must not be easily removed or defaced during normal product use, transport, or storage. Adhesive labels that peel off easily may not satisfy the indelibility requirement for physical products - the marking should be engraved, moulded, printed, or otherwise permanently affixed.

#### CE Marking on Product Packaging and Documentation
Where the nature of the product makes it impossible to affix the CE marking on the product itself (for example, a software-only product distributed electronically, or a very small component), Article 30 allows the marking to appear on the packaging, on a label attached to the product, or in the accompanying documentation.

For purely digital software products, the CE marking can be included in the installation interface, the product's 'about' section, the product's user interface, or in documentation provided with the product. The key requirement is that it is accessible to the user and clearly associated with the product.

For products sold with multiple items (for example, a device with accessories and documentation), the CE marking must be visible on the primary product - placing it only on a box insert that users may discard is not sufficient.

#### Prohibited Markings That Could Be Confused with CE
Article 30 prohibits the affixing of any marking, sign, or inscription that could be confused with the CE marking or that could mislead users about the product's compliance status. This prohibition targets spurious markings designed to give the impression of compliance when none exists.

Specific examples of prohibited markings include imitations of the CE marking format (the two-letter stylised logo), claims of 'EU cybersecurity certified' without a formal certification process, or third-party security seals that imply regulatory compliance without a proper basis.

Manufacturers using legitimate third-party security certifications - such as Common Criteria, SOC 2, or sector-specific security labels - may display those certifications alongside the CE marking, but must ensure they are clearly distinguished from the CE marking and do not create confusion about the regulatory basis of compliance.

#### CE Marking and the Notified Body Number
For Annex III products where a notified body has been involved in the conformity assessment, the notified body's identification number must appear alongside the CE marking. The number must be in the same field of vision as the CE marking and must be visible without any disassembly.

The notified body number is a four-digit identifier assigned to the body at the time of its notification and listed in the NANDO database. Including this number signals to market surveillance authorities and users that a third-party assessment was conducted, enabling them to identify the assessing body and retrieve the assessment records.

For default-class products (no notified body involvement), the CE marking appears alone without any notified body number - the absence of a number is not an error but rather the correct presentation for self-certified products.

### Conformity Assessment Procedures: Module A vs Third-Party Assessment
URL: https://cvdportal.com/cra/article-32

Article 32 decides which conformity assessment procedure applies to a product with digital elements. Default products may use internal control (Module A). Annex III Class I products may use it only where the relevant harmonised standards, common specifications or a qualifying European cybersecurity certification scheme are fully applied; otherwise a third-party route applies. Class II products always require a third party, and Annex IV critical products follow a certification scheme where the Commission has required one. The procedures themselves are set out in Annex VIII.

#### The Product Tiers Article 32 Works From
Article 32 assigns routes by product tier, and the tiers come from Articles 7 and 8:

**Default**: any product with digital elements listed in neither Annex III nor Annex IV. This is the largest category by far.

**Important, Annex III Class I**: nineteen categories, among them identity and privileged access management, browsers, password managers, anti-malware software, VPNs, network management systems, SIEM, boot managers, PKI and certificate issuance software, network interfaces, operating systems, routers, modems and switches, microprocessors and microcontrollers with security-related functionality, smart home assistants, smart home products with security functions such as locks and cameras, connected toys with social or location features, and personal wearables with a health monitoring purpose.

**Important, Annex III Class II**: four higher-risk categories - hypervisors and container runtimes, firewalls and intrusion detection or prevention systems, tamper-resistant microprocessors, and tamper-resistant microcontrollers.

**Critical, Annex IV**: hardware devices with security boxes, smart meter gateways and other devices for advanced security purposes including secure cryptoprocessing, and smartcards or similar devices including secure elements.

Classification follows what a product does rather than what it is called, and it is the manufacturer's own determination, evidenced in the technical documentation.

#### Module A: Internal Control
Internal control is the self-assessment route in Annex VIII. Under Module A the manufacturer carries out the cybersecurity risk assessment, designs and produces the product to meet Annex I, compiles the Annex VII technical documentation, keeps series production in conformity, draws up the EU Declaration of Conformity under Article 28, and affixes the CE marking under Article 30. No notified body is involved, so no identification number follows the marking.

Article 32(1) makes Module A available to default products, which may also choose Module B plus Module C, or Module H, voluntarily - buyers in regulated sectors often ask for one.

For an Annex III Class I product the position is conditional. Article 32(2) opens Module A only where the manufacturer fully applies the relevant harmonised standards, common specifications, or a European cybersecurity certification scheme at assurance level at least substantial. Partial application does not satisfy the condition. Presumption of conformity itself comes from Article 27, and it only reaches the requirements the applied standard actually covers.

#### Annex III Class I: When a Third Party Becomes Necessary
Where the Article 32(2) condition is not met - because no harmonised standard is yet cited for the product category, or because the manufacturer applies one only in part - a Class I product takes a third-party route:

**EU type-examination (Module B) plus conformity to type (Module C)**: a notified body examines the design and issues a type-examination certificate; the manufacturer then declares that production units conform to the approved type and keeps production controlled. Modifications to the approved type that may affect conformity require further approval from the body.

**Full quality assurance (Module H)**: a notified body approves and then surveils a quality system covering design, development, production and final inspection. This suits portfolios with many variants or frequent releases, where anchoring on a single approved type is impractical.

There is no lighter 'documentation review' route in the CRA. Either the Article 32(2) condition is satisfied and internal control is available, or one of the two third-party procedures applies.

#### Annex III Class II: A Third Party in Every Case
Article 32(3) closes internal control to Class II products entirely. Whatever standards the manufacturer applies, one of three routes is required: Module B plus Module C, Module H, or a European cybersecurity certification scheme at assurance level at least substantial.

The four Class II categories are hypervisors and container runtime systems, firewalls and intrusion detection or prevention systems, tamper-resistant microprocessors, and tamper-resistant microcontrollers. Note what is not in that list: hardware security modules and smart meter gateways are Annex IV critical products, and industrial control components are classified on their own function like anything else.

Because a notified body takes part in the production-control phase on these routes, the CE marking is followed by that body's four-digit identification number under Article 30(6). Assessment capacity is the practical constraint: bodies could only be designated from 11 June 2026, and demand concentrates ahead of full application on 11 December 2027, so engagement belongs on the launch plan early rather than at the end.

#### Annex IV Critical Products and Certification Schemes
Article 32(4) deals with the critical products listed in Annex IV. Conformity is demonstrated through a European cybersecurity certification scheme under Regulation (EU) 2019/881 where the Commission has required one by delegated act under Article 8(1). Where that condition is not met, the Class II routes apply: Module B plus Module C, Module H, or a qualifying certification scheme.

For important products, a European cybersecurity certification scheme at assurance level at least substantial can serve as the route in its own right. The EUCC, adopted by implementing regulation and based on Common Criteria, is the first such scheme in place.

Certificates issued under other regimes are useful evidence for the technical file, but they do not substitute for a CRA conformity assessment: a certificate proves conformity with whatever it was issued against.

#### When can a class I product still self-assess?
Important products of class I escape third-party conformity assessment only where the manufacturer has applied relevant harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial. Commission guidance C(2026) 5252 sets two conditions that must both hold.

All the applicable requirements of a relevant harmonised standard need to be applied, and the standard's scope needs to cover at least all the cybersecurity risks associated with the product's core functionality. Applying a standard in part does not qualify.

A product will often be broader than the standard. The manufacturer must still carry out the Article 13(2) risk assessment across the whole product, and where the standard does not cover every risk, document the additional measures taken to treat the rest. Doing so preserves eligibility for the internal control procedure across the product as a whole.

Presumption of conformity behaves differently from eligibility. It extends only as far as the standard reaches. An antivirus product whose core functionality is covered by a harmonised standard, but which also offers disk cleaning and anti-tracking features the standard does not address, may use internal control for the whole product while benefiting from presumption of conformity only for the core functionality.

Important products qualifying as free and open-source software may follow the default-category procedures under Article 32(5), whether they are class I or class II.

### Support Measures for Microenterprises and SMEs
URL: https://cvdportal.com/cra/article-33

Article 33 requires member states and the European Commission to support microenterprises and small and medium-sized enterprises in meeting their Cyber Resilience Act obligations. The support covers awareness raising, training, testing assistance, dedicated communication channels, and a simplified technical documentation format. It reduces the cost of complying. It does not reduce the obligations themselves.

#### What Article 33 Obliges States and the Commission to Do
Article 33 is addressed to member states and the European Commission rather than to manufacturers. Member states must organise awareness raising and training on the application of the regulation, support small manufacturers in strengthening their cybersecurity skills, and may establish dedicated channels for SME communication with market surveillance authorities. Member states may also provide financial support and testing assistance for conformity assessment activities. The obligations run toward the small manufacturer as the beneficiary, which means the practical question for an SME is what support exists in its own member state and how to claim it.

#### The Simplified Technical Documentation Format
The most concrete benefit for a small manufacturer is the simplified technical documentation form. The Commission is empowered to specify, by implementing act, a simplified format that microenterprises and small enterprises can use to satisfy the Annex VII technical documentation requirement. The content obligations remain, covering the product description, the cybersecurity risk assessment, the vulnerability handling documentation, and the declaration content, but the format is designed so a small team can complete it without a compliance department. Until the implementing act is adopted, small manufacturers should structure their technical file against Annex VII directly.

#### Regulatory Sandboxes
Article 33 connects to the regulation's provisions on regulatory sandboxes, controlled environments in which innovative products can be tested against CRA requirements with guidance from authorities before being placed on the market. For a startup with a novel connected product, a sandbox offers a route to resolve classification and conformity questions with the authority rather than discovering problems in market surveillance after launch. Availability varies by member state.

#### What Article 33 Does Not Do
Article 33 provides support measures only. The essential cybersecurity requirements of Annex I, the vulnerability handling obligations, the technical documentation duty, the EU Declaration of Conformity, CE marking, and the Article 14 reporting obligations apply to a two-person company exactly as they apply to a multinational. A small manufacturer that relies on informal practices rather than documented processes carries the same exposure to the Article 64 penalty regime, with fines reaching 15 million euros or 2.5 percent of worldwide annual turnover for breaches of the essential obligations. The correct reading of Article 33 is that the cost of compliance is reduced where support exists, while the standard of compliance is unchanged.

#### How SMEs Should Use the Support in Practice
Three steps extract the value. First, check what your national cybersecurity authority and market surveillance authority have published for CRA support, including training programmes, guidance documents, and any dedicated SME contact channel. Second, plan your technical documentation against Annex VII now and adopt the simplified format when the implementing act lands, rather than waiting for it. Third, if your product raises novel classification or conformity questions, ask your authority about sandbox participation before you commit to a conformity route. Combined with the Module A self-assessment route that most default-class products qualify for, the support measures make an in-house compliance process realistic for a small team.

### Notification of Conformity Assessment Bodies to the European Commission
URL: https://cvdportal.com/cra/article-35

Article 35 establishes the process by which member states notify the European Commission of conformity assessment bodies authorised to perform third-party CRA assessments. Notified bodies are the organisations that conduct mandatory third-party conformity assessments for Class I and Class II products listed in Annex III. Understanding the notified body framework is essential for manufacturers of higher-risk products who require third-party certification rather than self-declaration.

#### What a Notified Body Is
A notified body is a conformity assessment organisation that has been assessed, authorised, and notified to the European Commission by a member state national authority. Notified bodies are the third-party organisations that can conduct conformity assessments under Module B (type examination), Module H (quality management system assessment), and other modules that require third-party involvement.

Under the CRA, notified bodies are required for manufacturers of products in the higher-risk classes defined in Annex III - Class I (important products) and Class II (critical products). Default-class products can use Module A self-declaration without any notified body involvement.

Notified bodies are listed in NANDO (New Approach Notified and Designated Organisations), the European Commission's database of notified bodies. Manufacturers seeking third-party assessment should verify that their chosen assessment body is listed in NANDO for the relevant CRA assessment modules before engaging them.

#### The Notification Process
Member states notify conformity assessment bodies to the Commission through the NANDO notification system. Before notifying a body, the member state must ensure the body meets the requirements set out in the CRA regarding competence, impartiality, independence from manufacturers, and financial stability.

The notification must specify the types of products and assessment tasks the body is authorised to handle. A notified body's scope is defined at notification - a body notified for consumer IoT assessments may not be authorised to assess industrial control systems without a separate or expanded notification.

Once a body is notified and appears in NANDO, manufacturers across all EU member states can engage it for assessments - not only manufacturers in the member state that notified the body. This cross-border validity is important for manufacturers seeking to choose assessment bodies based on expertise and commercial terms rather than geography.

#### Requirements for Notified Body Accreditation
Before a conformity assessment body can be notified under the CRA, it must typically be accredited by a national accreditation body recognised under Regulation (EC) 765/2008 (the accreditation regulation). Accreditation demonstrates that the body meets the competence and impartiality requirements - typically assessed against ISO/IEC 17065 (product certification bodies) or relevant standards depending on the assessment activity.

The CRA specifies specific competence requirements for cybersecurity assessment bodies, including technical knowledge of the relevant product categories, familiarity with cybersecurity testing methodologies, and understanding of the CRA's essential requirements. Bodies without accreditation in cybersecurity-relevant domains should not be used for CRA assessments, even if they are notified for other regulatory purposes.

Manufacturers should request evidence of the notified body's NANDO listing and accreditation scope before commissioning an assessment.

#### Monitoring and Withdrawal of Notified Body Status
Member states are responsible for ongoing monitoring of the notified bodies they have authorised. If a notified body ceases to meet the requirements - for example, due to loss of accreditation, financial instability, or demonstrated incompetence - the member state must restrict, suspend, or withdraw its notification.

When a body's notification is withdrawn or suspended, this information is updated in NANDO and the Commission is informed. Certificates and assessment reports issued by a body before withdrawal remain valid unless the withdrawal was based on fraud or fundamental competence failure.

Manufacturers should periodically verify that the notified body that issued their assessment remains active and authorised. If a body's notification is withdrawn, they should assess whether a re-assessment by an alternative body is required.

#### Practical Implications for Manufacturers of Higher-Risk Products
For manufacturers of Annex III products, the availability of appropriately notified bodies is a practical constraint on market readiness. At the time of the CRA's application, the notified body market for cybersecurity assessments is still developing. Not all EU member states have notified bodies with cybersecurity expertise across all product categories.

Manufacturers should engage potential assessment bodies early - ideally 12 to 18 months before their target product launch date - to understand assessment timelines, costs, and documentation requirements. Capacity constraints at notified bodies could delay product launches if manufacturers leave engagement too late.

Product design choices that simplify the assessment process - such as using harmonised standards, maintaining rigorous technical documentation from the start of the development cycle, and building in security testing as a standard development step - can significantly reduce assessment time and cost.

### Notification of Conformity Assessment Bodies
URL: https://cvdportal.com/cra/article-39

Article 39 specifies the requirements that conformity assessment bodies must meet before a member state can notify them to the European Commission for CRA purposes. It establishes the competence, independence, and impartiality criteria that notified bodies must demonstrate, and the ongoing obligations they bear once notified. For manufacturers, understanding Article 39 helps in evaluating whether a potential assessment body genuinely qualifies to conduct CRA conformity assessments.

#### Requirements for Notified Body Qualification
Article 39 sets out the requirements that conformity assessment bodies must satisfy to be notified under the CRA. These requirements cover:

**Legal establishment**: The body must be established under the law of an EU member state and have legal personality - it must be a formal legal entity, not an informal group.

**Independence**: The body must be independent from the organisations it assesses. Specifically, it must not be the manufacturer, the manufacturer's supplier, customer, or economic partner in ways that could compromise objectivity. Employees of the body must not have been involved in the design, production, or marketing of products they assess.

**Technical competence**: The body must have the expertise, facilities, and equipment necessary to perform the conformity assessment tasks for which it seeks notification. For CRA assessments, this requires genuine cybersecurity expertise and the technical capability to evaluate security properties against the Annex I requirements.

**Financial stability**: The body must have sufficient financial resources to perform assessment activities professionally and to carry liability for assessments conducted.

#### Impartiality and Conflict of Interest Controls
Article 39 places strong emphasis on impartiality. Notified bodies must be structured and managed in a way that ensures their assessments are not influenced by commercial, financial, or other pressures from the organisations being assessed.

Key impartiality requirements include:

- Assessment fees must not depend on the result of the assessment
- Assessors must disclose potential conflicts of interest and recuse themselves where such conflicts exist
- The body must have documented procedures for managing conflicts of interest
- Senior personnel must not simultaneously hold positions in organisations whose products they assess

These requirements reflect the critical role that notified bodies play in the EU market surveillance system. An assessment that is compromised by commercial pressure provides false assurance to regulators and consumers and undermines the entire CE marking system.

#### Accreditation as Evidence of Qualification
Article 39 recognises accreditation by a national accreditation body as the primary mechanism for demonstrating that a conformity assessment body meets the notification requirements. Accreditation under ISO/IEC 17065 (for product certification bodies) or ISO/IEC 17020 (for inspection bodies) against the CRA-relevant scope provides a presumption that the body meets the competence and impartiality requirements.

National accreditation bodies are designated under Regulation (EC) 765/2008 and are members of the European co-operation for Accreditation (EA). They conduct assessments of conformity assessment bodies through peer-reviewed processes that are internationally recognised.

Manufacturers selecting a notified body for CRA assessments should request confirmation of the body's accreditation scope and verify that the scope covers CRA-relevant assessment activities. Accreditation scope documents are typically publicly available from the accreditation body.

#### Ongoing Obligations of Notified Bodies
Once notified, bodies bear ongoing obligations under Article 39 and related provisions. These include:

**Continuous qualification**: Notified bodies must maintain the competence, impartiality, and financial stability that led to their notification. Significant changes - such as mergers, ownership changes, or loss of accreditation - must be reported to the notifying authority.

**Transparency**: Notified bodies must participate in coordination activities with other notified bodies and the Commission to ensure consistent application of assessment standards across the EU.

**Record keeping**: Bodies must maintain records of all assessments conducted, including the documentation reviewed, the testing performed, the findings made, and the certificates issued or refused. These records must be available to authorities on request.

**Communication of non-compliance**: Where a notified body finds non-compliance during an assessment, it must refuse to issue a certificate and inform the national authority. It may not issue a certificate conditional on the manufacturer correcting deficiencies without a reassessment.

#### Subsidiary Bodies and Subcontracting
Article 39 addresses the circumstances under which notified bodies can use subsidiary bodies or subcontract assessment activities. Subcontracting is permitted in limited circumstances where the subcontracted activity involves specialist expertise not available in-house, and where the notified body retains full responsibility for the subcontracted work.

Manufacturers should be aware that if their notified body subcontracts significant portions of the assessment, they should verify that the subcontractor meets equivalent competence standards. Subcontractors' work counts as the notified body's work for the purposes of the assessment certificate, but the notified body cannot excuse assessment failures by pointing to the subcontractor's errors.

Manufacturers should ask notified bodies to disclose any planned subcontracting at the assessment engagement stage and to confirm the qualifications of proposed subcontractors.

### Free Movement of CRA-Compliant Products in the EU Single Market
URL: https://cvdportal.com/cra/article-4

Article 4 is the market access provision at the heart of the CRA's regulatory logic: products that satisfy the essential cybersecurity requirements and bear the CE marking are entitled to free movement throughout the EU single market. Member states cannot impose additional national cybersecurity requirements on CE-marked products without specific EU authorisation. This provision benefits manufacturers by creating a single compliance pathway for the entire EU market rather than requiring country-by-country certification.

#### The Free Movement Principle
Article 4(1) states that member states shall not prohibit or restrict the placing on the market of products with digital elements that comply with the CRA. This is the foundational free movement guarantee of the regulation, giving CRA-compliant products the right to circulate freely throughout all 27 EU member states.

This principle is fundamental to the EU single market and is one of the primary reasons manufacturers should seek CRA compliance proactively. A single EU-wide compliance exercise - completing the relevant conformity assessment, preparing technical documentation, and affixing the CE marking - creates market access for the entire EU, rather than requiring separate national filings or certifications in each member state.

The practical implication is that once your product carries a valid CE marking under the CRA, no member state can block its sale on cybersecurity grounds without invoking the specific safeguard procedures set out in the regulation.

#### What CE Marking Signifies Under the CRA
The CE marking affixed under the CRA signals that the manufacturer has completed the applicable conformity assessment, that the product meets the essential cybersecurity requirements in Annex I, and that an EU Declaration of Conformity has been drawn up in accordance with Article 28.

The CE marking is not a quality mark or security certification issued by a third party - for most products (default class), it is a manufacturer's self-declaration supported by technical documentation. For Class I and Class II products listed in Annex III, third-party involvement is required, but the CE marking is still ultimately affixed by the manufacturer.

Affixing a CE marking on a non-compliant product is a serious violation that can attract penalties under Article 64 and may result in product recall. Manufacturers must ensure that CE marking is only applied to products that genuinely meet the essential requirements.

#### Restrictions Permitted by Member States
The free movement guarantee is not absolute. Article 4 permits member states to apply existing national provisions that restrict the use of certain products for public security, public order, or public health reasons, where these national rules are compatible with EU law. This is a narrow exception and does not permit general cybersecurity requirements that duplicate or exceed the CRA.

In addition, the CRA's market surveillance provisions allow national authorities to require product withdrawal or recall where a specific product presents an unacceptable risk, even if it bears the CE marking. This is a product-specific remedy, not a general restriction on a product category.

Manufacturers should be aware that the free movement guarantee operates at the level of the product design, not at the level of individual units. If a market surveillance authority identifies a specific defective unit or batch, corrective action may be required for those units without affecting the broader market authorisation.

#### Trade Shows and Demonstrations
Article 4 also addresses a practical edge case: products displayed at trade shows, exhibitions, or demonstrations may be exhibited even if they do not yet fully comply with the CRA, provided potential users are clearly informed of the non-compliance and that the product will not be placed on the market until it achieves compliance.

This provision is important for manufacturers in pre-market product development phases who wish to demonstrate working prototypes at EU trade events. The notification to users must be explicit and visible - it is not sufficient to mention non-compliance in small print or to assume visitors are aware that prototypes may not be fully compliant.

#### Implications for Multi-Market Manufacturers
For manufacturers who sell into markets beyond the EU - for example, the United States, United Kingdom, Japan, or Australia - CRA compliance provides a CE marking that is specific to the EU. Other markets have their own cybersecurity product frameworks: the US Cyber Trust Mark, the UK PSTI Act requirements, or Japan's IoT security labels.

While some technical requirements overlap (particularly around patch management and vulnerability disclosure), CRA compliance alone does not automatically satisfy the requirements of other markets. However, the rigorous technical documentation and conformity assessment processes required for CRA compliance will generate evidence that can be leveraged for other market certifications, potentially reducing the overall compliance burden.

### Procurement and Professional Use of Products with Digital Elements
URL: https://cvdportal.com/cra/article-5

Article 5 addresses the obligations of organisations that procure or professionally deploy products with digital elements — particularly public sector bodies and operators of critical infrastructure. While most CRA obligations fall on manufacturers, Article 5 ensures that buyers and users of CRA-regulated products also play a role in maintaining cybersecurity, including applying security updates, considering cybersecurity in procurement decisions, and cooperating with manufacturers on security issues.

#### Cybersecurity in Procurement Decisions
Article 5 requires that organisations procuring products with digital elements — particularly public sector bodies and essential entities under the NIS2 Directive — take cybersecurity into account when making procurement decisions. In practice, this means:

- Evaluating whether products under consideration meet CRA essential requirements (Annex I)
- Preferring products with a published CVD policy and a track record of timely security updates
- Verifying that suppliers have adequate vulnerability handling processes
- Including cybersecurity requirements in tender specifications and supplier contracts

Organisations are encouraged to refer to ENISA's published guidance on secure ICT procurement when designing their procurement processes.

#### Obligations to Apply Security Updates
Article 5 establishes that professional users of products with digital elements must apply security updates provided by the manufacturer within a reasonable time. This obligation exists alongside — and reinforces — the manufacturer's obligation to provide updates under Article 13.

For organisations managing large fleets of devices or software deployments, this requires:
- Establishing patch management processes capable of applying security updates promptly
- Prioritising critical security updates over routine maintenance windows
- Maintaining records of update applications for audit purposes
- Where auto-update mechanisms are available and risk-appropriate, enabling them

The obligation to apply updates applies to the extent that updates are available and applicable to the specific deployment. Organisations that customise or modify products may need to assess the applicability of manufacturer updates to their modified versions.

#### Cooperation with Manufacturers on Security Issues
Article 5 encourages professional users to cooperate with manufacturers when they identify security vulnerabilities or incidents in products they deploy. While reporting vulnerabilities to manufacturers is not mandated for users, Article 5 recognises that users often discover vulnerabilities through operational experience and that their reports are valuable to the CRA's vulnerability disclosure ecosystem.

Organisations that identify vulnerabilities in CRA-regulated products are encouraged to:
- Report findings to the manufacturer through its published CVD process
- Consider coordinated disclosure to avoid facilitating exploitation before a patch is available
- Engage with national CSIRTs where the vulnerability may have sectoral implications

Public sector bodies and essential entities that discover vulnerabilities may also consider whether they have separate reporting obligations under the NIS2 Directive or sector-specific regulation.

### Market Surveillance Coordination Between EU Member States
URL: https://cvdportal.com/cra/article-52

Article 52 establishes the framework for coordinating market surveillance activities across EU member states. Because the EU single market means products flow freely across borders, a non-compliant product identified in one member state may be on sale in 26 others. Article 52 ensures national surveillance authorities share information, coordinate investigations, and apply consistent enforcement standards so that manufacturers cannot exploit differences in national enforcement capacity.

#### The Need for Coordinated Market Surveillance
Market surveillance of CRA-regulated products faces an inherent challenge: the single market means products are sold across all 27 member states simultaneously. A non-compliant IoT device manufactured in China, imported through the Netherlands, and sold in France, Germany, and Spain presents a coordination challenge for national authorities with jurisdictional limits.

Article 52 addresses this by establishing coordination mechanisms through which national market surveillance authorities (MSAs) share information about products under investigation, coordinate corrective action requests, and ensure that a product withdrawn from sale in one member state is also addressed in others where it is sold.

The Information and Communication System for Market Surveillance (ICSMS) is the EU-wide database through which authorities share product compliance information, inspection results, and enforcement actions. National MSAs are required to use ICSMS to record CRA-related actions, providing a shared intelligence picture across the EU.

#### Information Sharing Obligations
Article 52 requires national market surveillance authorities to share information with each other and with the Commission when they identify non-compliant products or products presenting a risk. Key information-sharing obligations include:

**Safety Gate notifications**: Where a product presents a serious risk, authorities must notify the Safety Gate (formerly RAPEX) database, alerting all other member states immediately. Safety Gate notifications for CRA-relevant products trigger automatic review by other national MSAs.

**ICSMS entries**: All market surveillance activities - inspections, investigations, test results, corrective action orders - should be recorded in ICSMS to enable coordination.

**Direct communications**: For urgent or sensitive cases, direct communication between national MSAs may precede formal database entries. Article 52 encourages informal information sharing as a complement to formal notification systems.

Manufacturers subject to enforcement action in one member state should anticipate that the action will be visible to authorities across the EU and that parallel actions in other member states may follow.

#### ENISA's Role in Market Surveillance Coordination
Article 52 gives ENISA a coordination role in CRA market surveillance activities. ENISA's specific cybersecurity expertise positions it to provide technical support to national MSAs that may lack in-house cybersecurity assessment capacity.

ENISA's coordination functions include:

- Developing common testing methodologies and assessment guidelines for national MSAs
- Maintaining and operating the European Vulnerability Database to support surveillance activities
- Coordinating joint market surveillance campaigns targeting high-risk product categories
- Supporting capacity building for national MSAs in less advanced member states
- Facilitating information sharing between national cybersecurity agencies and MSAs

ENISA's role does not replace national MSA authority - enforcement remains a national responsibility. But ENISA provides the technical and coordination infrastructure that makes consistent enforcement across 27 member states feasible.

#### Joint Market Surveillance Actions
Article 52 enables national MSAs to conduct joint market surveillance actions - coordinated campaigns in which multiple member states simultaneously investigate the same product category or manufacturer. Joint actions are particularly effective against manufacturers who might otherwise play member states off against each other by cooperating minimally in high-enforcement jurisdictions and continuing sales in lower-enforcement jurisdictions.

Joint actions can include coordinated sampling of products for testing, simultaneous requests for technical documentation, and coordinated corrective action orders that prevent a manufacturer from withdrawing a product in one country while continuing to sell it in others.

For manufacturers, the possibility of joint market surveillance actions means that compliance cannot be geo-targeted. A manufacturer who invests in compliance for the German market but not the Romanian market may find that German MSA findings trigger EU-wide enforcement.

#### Safeguard Procedures for Disputed Products
Article 52 establishes safeguard procedures for situations where a national MSA requires corrective action for a product that bears a CE marking. If a manufacturer disputes the MSA's finding of non-compliance, the regulation provides for Commission review of the national measure.

Where the Commission agrees with the national MSA that the product is non-compliant, it can adopt an implementing act confirming the measure, which then applies EU-wide. Where the Commission finds the product is compliant, the national measure must be withdrawn.

These safeguard procedures protect manufacturers from incorrectly applied national enforcement while ensuring that confirmed non-compliance is addressed uniformly. Manufacturers facing disputed enforcement actions should engage legal counsel familiar with EU administrative proceedings and be prepared for the possibility of Commission involvement.

### Joint Activities of Market Surveillance Authorities
URL: https://cvdportal.com/cra/article-59

Article 59 establishes the legal framework for national market surveillance authorities (MSAs) to carry out joint activities — principally joint investigations and coordinated enforcement actions — when addressing CRA non-compliance that has cross-border implications. Joint activities allow multiple national authorities to pool investigative resources, share evidence, and issue coordinated corrective measures against manufacturers whose products are sold across more than one EU member state. ENISA can participate in a technical advisory capacity and the Commission can support coordination. Joint activities under Article 59 are a significant escalation tool because their cross-border reach makes them much harder for manufacturers to outmanoeuvre than unilateral national enforcement.

#### When Joint Activities Are Used
Article 59 provides for joint activities where coordination between multiple national market surveillance authorities is necessary for effective enforcement. Circumstances typically warranting a joint investigation include:

- A manufacturer whose products are sold across multiple EU member states and where a unilateral national action would be ineffective
- A manufacturer established in a third country where the MSA of a single member state lacks adequate leverage
- A cybersecurity risk identified in a product category where coordinated market-wide action is needed to protect all EU users
- A vulnerability that exploits a systemic issue affecting products from multiple manufacturers
- A risk identified through ENISA's European vulnerability database (EVDB) or a CSIRT cross-border notification

Joint activities leverage the collective legal authority of multiple national MSAs, making it harder for manufacturers to deflect or delay enforcement by focusing on procedural differences between member states.

#### Structure and Coordination of Joint Investigations
Article 59 provides for joint investigation structures that allocate lead and supporting roles to national MSAs. A lead authority is typically designated — usually the MSA of the member state where the manufacturer is established (for EU manufacturers) or where the authorised representative is located (for non-EU manufacturers). Supporting authorities contribute investigative resources and share jurisdiction over their national markets.

ENISA can participate in joint activities in a technical advisory capacity, providing cybersecurity expertise and access to EVDB data that informs the investigation. ENISA does not have enforcement powers of its own but can significantly enhance joint activities through technical analysis.

The Commission can also support joint activities — particularly where they involve products affecting critical infrastructure or where the findings may lead to EU-wide corrective measures under Article 59 (Union safeguard procedure).

#### Information Exchange Between Investigating Authorities
Article 59 requires participating national MSAs to share information gathered in the course of joint activities. This includes technical test results, communications with the manufacturer, legal assessments, and enforcement plans. The sharing must be timely to enable coordinated action.

The ICSMS (Information and Communication System for Market Surveillance) database and the Safety Gate rapid alert system serve as primary information-sharing mechanisms, supplemented by direct communications through established authority networks.

Manufacturers under joint investigation should expect that information they provide to one national authority will be shared with all participating authorities. There is no advantage in providing different or inconsistent information to different authorities — discrepancies will be identified through information exchange and may be treated as evidence of non-cooperation.

#### Outcomes of Joint Activities
Joint activities can result in coordinated enforcement outcomes applied simultaneously across multiple member states. Where a joint investigation confirms non-compliance, participating MSAs can issue coordinated corrective action orders, product withdrawal requirements, or prohibitions on market placement. Coordinated outcomes ensure the manufacturer cannot continue sales in less active enforcement jurisdictions while complying with requirements in others.

Where joint activities result in significant findings about systemic non-compliance, the findings may be shared with the Commission, potentially triggering EU-wide implementing acts under the Union safeguard procedure in Article 59. This escalation pathway makes joint activities a powerful enforcement tool for addressing widespread or structural compliance failures.

Manufacturers facing joint investigations should engage experienced EU regulatory legal counsel who can navigate the multi-jurisdiction procedural complexity and ensure consistent, appropriate responses to all participating authorities.

#### Relationship to the Union Safeguard Procedure
Article 59 joint activities are distinct from but complementary to the Union safeguard procedure in Article 59. Joint activities are initiated by national MSAs acting collectively; the Union safeguard procedure is triggered when one MSA takes national restrictive measures and the Commission must assess whether those measures are justified at the Union level.

In practice, a joint investigation under Article 59 may precede a Union safeguard procedure: the joint investigation gathers evidence of non-compliance, leading to coordinated national measures, which in turn trigger the Article 59 procedure if the Commission needs to determine a Union-wide position. The two provisions form part of a connected enforcement escalation chain.

For critical products (Annex IV) or products presenting a serious cybersecurity risk, Article 59 joint activities may move faster and carry greater legal weight because they do not require the sequential national measure / Commission review sequence that the Article 59 safeguard procedure entails.

### Essential Cybersecurity Requirements for Products with Digital Elements
URL: https://cvdportal.com/cra/article-6

Article 6 is the pivotal compliance provision of the CRA: it requires manufacturers to ensure their products with digital elements satisfy the essential requirements set out in Annex I. Annex I is divided into two parts - Part I covers the security properties products must have at the point of design and manufacture, and Part II covers the vulnerability handling processes manufacturers must maintain after placing products on the market. Compliance with Article 6 is the condition for bearing the CE marking and accessing the EU single market.

#### The Two-Part Structure of Essential Requirements
Article 6 requires manufacturers to ensure their products comply with the essential cybersecurity requirements in Annex I. Those requirements are organised into two distinct parts, each addressing a different phase of the product lifecycle.

Annex I Part I deals with security properties that must be built into the product before it is placed on the market. These include requirements around no known exploitable vulnerabilities, secure default configurations, minimal attack surface, protection of data at rest and in transit, confidentiality, integrity, availability, access control, and the ability to update securely.

Annex I Part II deals with vulnerability handling processes that manufacturers must maintain throughout the product's supported lifetime. These include the obligation to identify and document vulnerabilities, establish a CVD policy, provide security updates, publish security advisories, and report severe vulnerabilities to ENISA through national CSIRTs.

Meeting both sets of requirements is necessary for CRA compliance - a product with excellent security properties but no vulnerability management process is not compliant.

#### Security by Design: Annex I Part I Requirements
The Annex I Part I requirements represent a codification of secure development best practices into legally binding obligations. Key requirements include:

**No known exploitable vulnerabilities**: Products must be placed on the market without known exploitable vulnerabilities in their components. This has significant implications for supply chain management - manufacturers must assess the security of third-party components, including open-source libraries, before integration.

**Secure default configuration**: Products must be delivered with secure default settings. Insecure defaults (such as blank administrator passwords or open network ports) that users must manually harden are not acceptable.

**Minimal attack surface**: Products must minimise their attack surface, exposing only the network interfaces and services genuinely necessary for operation.

**Data protection**: Products must protect data at rest and in transit using appropriate cryptographic mechanisms. Sensitive authentication credentials must not be transmitted in cleartext.

**Software integrity**: Products must be able to verify the integrity of updates and software components to prevent tampering.

#### Vulnerability Handling: Annex I Part II Requirements
Annex I Part II translates the post-market vulnerability management obligations into specific technical and procedural requirements. These are the operational backbone of ongoing CRA compliance and include:

**Vulnerability identification**: Manufacturers must identify and document vulnerabilities and components in their products, including by maintaining a Software Bill of Materials (SBOM).

**Security updates**: Manufacturers must address vulnerabilities through security updates provided free of charge to users, disseminated without undue delay and, where technically feasible, automatically.

**CVD policy**: Manufacturers must establish and maintain a coordinated vulnerability disclosure policy (see Article 13 for full requirements).

**Security advisories**: When a vulnerability is addressed or a workaround is available, manufacturers must publish a security advisory in a standard format. CSAF 2.0 is the recommended format.

**Support period disclosure**: Manufacturers must state the expected support period for their products, during which they commit to providing security updates.

#### Handling Third-Party Components and Dependencies
One of the most operationally challenging aspects of Article 6 compliance is the requirement that products be placed on the market without known exploitable vulnerabilities - including in third-party components and open-source dependencies. This creates a supply chain security obligation that extends beyond a manufacturer's own code.

Manufacturers must perform Software Composition Analysis (SCA) of their products to identify all components and their known vulnerabilities. Integrating a library with an unpatched critical vulnerability at the time of product release is likely to constitute an Annex I violation. Manufacturers should establish processes for:

- Inventorying all third-party components and their versions
- Monitoring CVE databases for new vulnerabilities in those components
- Updating or patching components prior to product release
- Maintaining an SBOM that can be provided to customers and regulators on request

The SBOM requirement in Annex I Part II also means that manufacturers must be able to produce an accurate component inventory on an ongoing basis, not just at product launch.

#### Proportionality and Risk-Based Application
Article 6 applies the essential requirements in a risk-proportionate manner. The CRA does not require perfection - it requires that manufacturers take appropriate measures commensurate with the risks associated with their specific product. A consumer smart plug and an industrial control system network gateway face different threat profiles and require different levels of security control.

Manufacturers must conduct a cybersecurity risk assessment for each product (documented in the technical file under Annex VII) and use this assessment to justify the security measures implemented. The risk assessment should consider the product's intended use, the likely user population, the sensitivity of data processed, and the potential impact of a security breach.

Harmonised standards published under Article 7 provide detailed, product-category-specific guidance on how to meet the essential requirements proportionately. Following an applicable harmonised standard creates a presumption of conformity with the corresponding essential requirements.

### Administrative Fines for CRA Non-Compliance
URL: https://cvdportal.com/cra/article-64

Article 64 sets out the administrative fine regime for CRA violations. It creates a graduated penalty structure calibrated to the seriousness of the infringement: the most severe fines apply to products that fail the essential cybersecurity requirements or lack vulnerability handling processes; lower tiers apply to other obligation breaches; and a separate tier covers the provision of incorrect or misleading information to authorities. Member state market surveillance authorities apply these fines, subject to national procedural law.

#### Tier 1: Fines for Essential Requirements and Vulnerability Handling Violations
The most serious category of CRA violations attracts fines of up to **€15,000,000 or 2.5% of total worldwide annual turnover** in the preceding financial year, whichever is higher.

This tier applies to:
- Products placed on the market that do not conform to the essential cybersecurity requirements in Annex I (security properties, documentation, and reporting obligations)
- Manufacturers who fail to meet the vulnerability handling requirements in Part II of Annex I (vulnerability disclosure, SBOM, CVD policies, coordinated disclosure)

For SMEs and microenterprises, regulators are expected to apply the percentage cap, since the absolute figure may be disproportionate. The dual cap (higher of absolute or percentage) ensures large multinationals cannot rely on low absolute thresholds relative to their scale.

#### Tier 2: Fines for Other Manufacturer, Importer, and Distributor Obligations
A mid-tier fine of up to **€10,000,000 or 2% of total worldwide annual turnover** applies to violations of a broad set of other CRA obligations, including:

- Failure to register products or maintain a SBOM as required
- Non-compliance with conformity assessment procedures (Module A, third-party assessment for Annex III products)
- Placing CE marking without completing the required assessment
- Failure to draw up or maintain a proper EU Declaration of Conformity or technical documentation
- Non-compliance with importer obligations (Article 19) or distributor obligations (Article 20)
- Failure of authorised representatives to carry out their mandated functions
- Non-compliance with corrective action orders from market surveillance authorities

This tier captures procedural and documentation violations that, while serious, do not necessarily mean the product itself is insecure.

#### Tier 3: Fines for Incorrect or Misleading Information
The lowest fine tier of up to **€5,000,000 or 1% of total worldwide annual turnover** applies to the provision of incorrect, incomplete, or misleading information to notified bodies, market surveillance authorities, or the Commission in response to requests for information.

This tier reflects the importance of maintaining information integrity in the CRA's enforcement framework. Market surveillance relies on accurate technical documentation and responsive cooperation from economic operators. Deliberate misrepresentation or systematic failure to provide accurate information undermines the entire enforcement architecture.

Note that this tier addresses informational obligations — a manufacturer who provides false information in a Declaration of Conformity or to a notified body during assessment may also face Tier 1 or Tier 2 fines for the underlying substantive violation.

#### Factors in Setting Fine Levels
Article 64 does not prescribe fixed fines — it sets maximum caps. Market surveillance authorities and, where relevant, data protection or competition-adjacent enforcement bodies, apply national procedural law when determining the appropriate fine within the cap. Key factors typically include:

- **Severity of the security risk**: A vulnerability in safety-critical infrastructure attracts heavier fines than one in low-risk consumer software
- **Duration of the infringement**: Ongoing failures treated more seriously than isolated incidents
- **Degree of cooperation**: Manufacturers who proactively report and remediate are treated more favourably
- **History of compliance**: Prior violations or systemic non-compliance are aggravating factors
- **Size of the manufacturer**: The dual cap structure (absolute or percentage) inherently scales penalties to company size
- **Nature of affected products**: Annex III Class II or Annex IV products in critical infrastructure contexts attract higher scrutiny

The CRA recitals emphasise that fines should be effective, proportionate, and dissuasive.

#### Interaction with Other EU Regulatory Penalties
The CRA fine regime coexists with other EU regulatory fine frameworks. Key interactions:

**GDPR**: Where a cybersecurity incident also constitutes a personal data breach, GDPR Article 83 fines (up to €20M or 4% of global turnover) may apply in addition to CRA fines. Regulators are expected to coordinate to avoid double-counting the same conduct, but they operate under different legal bases.

**NIS2 Directive**: Essential entities and important entities under NIS2 face separate fines under that regime for security failures. A CRA-non-compliant product deployed in an NIS2-regulated entity may trigger enforcement actions under both frameworks.

**Product liability**: The new EU Product Liability Directive (2024/2853) creates civil liability for damage caused by defective digital products. CRA non-compliance is not directly relevant to product liability, but evidence of regulatory violations may be relevant in liability proceedings.

#### Application to SMEs and Microenterprises
The CRA includes specific provisions requiring that fines imposed on SMEs and microenterprises be proportionate to their size, nature, and resources. Article 64 must be read alongside these proportionality requirements.

In practice:
- National authorities are expected to take a graduated approach, reserving maximum fines for large manufacturers with significant resources
- First-time, minor procedural violations by SMEs are unlikely to attract fines near the maximum
- The SME support structures under Article 25 (including technical assistance from ENISA and member states) are relevant context — a manufacturer who sought assistance and acted in good faith is in a different position from one who ignored compliance requirements

SMEs should not assume they are exempt from fines — the percentage cap applies equally and can still represent a material sum for growing companies.

### Important Products with Digital Elements - Annex III Classification
URL: https://cvdportal.com/cra/article-7

Article 7 designates certain products with digital elements as 'important' because their cybersecurity properties are critical to other systems or pose elevated risks. Products listed in Annex III fall into two classes: Class I (significant cybersecurity functions) and Class II (higher-risk products performing critical security roles). Important products face stricter conformity assessment — self-certification alone is not sufficient; Class I requires third-party documentation review and Class II requires full EU-type examination or quality assurance assessment.

#### What Makes a Product 'Important' Under Article 7
Article 7 designates as 'important' those products that either:

1. **Primarily perform functions critical to the cybersecurity of other products, networks or services** — such as identity management systems, password managers, VPN software, network security tools, or PKI components. These products are security infrastructure: if they are compromised, other systems' security is undermined.

2. **Perform functions that pose a significant risk of adverse effects** through capabilities such as network management, asset management, or data processing at scale — including industrial control systems (SCADA/ICS), robotics, automotive components, medical devices with network interfaces, and smart grid equipment.

The full list of important products is in Annex III. The Commission may update Annex III by delegated act as technology evolves.

#### Class I vs Class II: The Two Tiers
Annex III divides important products into two classes with different conformity assessment requirements:

**Class I** examples include:
- Identity and access management software
- Password managers
- Standalone and embedded browsers
- VPN software (client-side)
- Network traffic management and monitoring tools
- Network routers for home use
- Microcontrollers with security functions
- Smart home products (general consumer IoT)

**Class II** examples include:
- Operating systems for servers, desktops, and mobile devices
- Hypervisors and container runtimes
- Hardware security modules (HSMs)
- Firewalls and intrusion detection systems (industrial)
- Tamper-resistant microprocessors / secure elements
- Industrial automation and control systems with direct safety impact

Class II carries the highest conformity assessment burden short of Critical (Annex IV) products.

#### Conformity Assessment for Class I Products
Manufacturers of Class I products cannot self-certify using Module A alone. They must choose between:

**Option A: Third-party technical documentation review** — Submit the product's technical documentation to a notified body, which reviews it against the essential requirements. The notified body does not test the product itself but assesses whether the documentation demonstrates compliance.

**Option B: Quality management system audit (Module H)** — Have a notified body audit and certify the manufacturer's quality management system, which must cover the security development lifecycle. This approach is suited to manufacturers with multiple products.

In both cases, the notified body issues a certificate, which the manufacturer references in their EU Declaration of Conformity. The manufacturer retains ongoing responsibility for the product's compliance.

#### Conformity Assessment for Class II Products
Class II products must undergo the most stringent assessment available for important products: **EU-type examination (Module B)** followed by conformity to type (Module C), or **full quality assurance assessment (Module H)**.

- **Module B** involves the notified body examining the product design and, where appropriate, representative production samples against the essential requirements and any applicable harmonised standards.
- **Module C** confirms that production units conform to the approved type.
- **Module H** provides an alternative if the manufacturer's entire quality management system — including development, production, and testing — is assessed and certified by the notified body.

Class II manufacturers should engage with notified bodies early, as assessment timelines for complex products can be 6–18 months.

#### The Commission's Power to Update Annex III
Article 7 grants the European Commission the power to amend Annex III by delegated act, adding or removing product categories as the threat landscape and technology evolve. When the Commission proposes to add a product category, it must provide a **minimum transitional period of 12 months** before the new classification takes effect, giving affected manufacturers time to adapt their conformity assessment processes.

Manufacturers of products in adjacent categories — or of products whose security properties are becoming more critical — should monitor Commission delegated acts under Article 7. ENISA publishes analysis of product category risk profiles that may inform future Annex III amendments.

#### What counts as the 'core functionality'?
Core functionality is not defined in the Regulation. Commission guidance C(2026) 5252 describes it as the product's main features and technical capabilities, without which it would not be able to meet its intended purpose, assessed in light of the information the manufacturer supplies in the instructions for use, in promotional and sales materials, and in the technical documentation.

Four rules follow. A product has only one core functionality for the purposes of determining the conformity assessment regime, and it must be identified in the technical documentation. Functions additional to the core functionality do not change the classification. Merely integrating an important or critical product does not make the host product important or critical, so a smartphone containing an operating system does not have the core functionality of an operating system. And where a product's core functionality substantially exceeds or substantially falls short of a category, it does not belong to it. Security orchestration, automation and response software generally exceeds the SIEM category because incident response is core to it, while a log collection and visualisation tool that performs no correlation falls short of it.

Modules of an integrated product that the manufacturer also makes available separately, for separate purchase, licensing or subscription, are standalone products classified on their own core functionality.

A manufacturer may not misrepresent core functionality to escape a more stringent regime. Clear inconsistency between promotional materials, instructions for use and the technical documentation is the signal, and non-compliance with Article 32 can attract administrative fines under Article 64(3).

### Critical Products with Digital Elements - Annex IV Classification
URL: https://cvdportal.com/cra/article-8

Article 8 designates a narrow category of products with digital elements as 'critical' — those whose compromise could have the most severe systemic impact on cybersecurity. Products listed in Annex IV must use an EU cybersecurity certification scheme under the EUCS (EU Cybersecurity Certification Scheme) for their conformity assessment, rather than the notified body routes available to Annex III products. This makes critical products the only CRA product category linked directly to ENISA's certification framework.

#### What Makes a Product 'Critical' Under Article 8
Article 8 and Annex IV identify critical products as those with the most significant potential for systemic cybersecurity impact. As of the CRA's adoption, Annex IV includes:

- **Hardware devices with security boxes** — dedicated security hardware (HSMs, security enclaves) protecting cryptographic keys and sensitive data in critical infrastructure
- **Smartcard ICs and similar devices** — integrated circuits used in identity documents, payment cards, and secure credential storage
- **Trusted Platform Modules (TPMs)** — hardware components providing root-of-trust functions for device integrity verification
- **CPU microprocessors with security features** — processors incorporating trusted execution environments or hardware security features
- **Cellular IoT modules** — modules providing cellular connectivity to IoT devices, particularly for critical infrastructure applications

The Commission may extend Annex IV by delegated act. The category is deliberately narrow — most products, even security-sensitive ones, fall under Annex III.

#### Conformity Assessment via EU Cybersecurity Certification
Unlike Annex III products (which use notified bodies under the NLF framework), Article 8 products must use a **European cybersecurity certification scheme** adopted under the EU Cybersecurity Act (Regulation 2019/881). ENISA is responsible for developing these schemes in cooperation with member states.

In practice, this means:
- The manufacturer must obtain certification under the applicable EU cybersecurity scheme at the **substantial** or **high** assurance level
- If no specific EU scheme exists for a product category, the Commission must adopt implementing acts specifying which scheme applies or mandate a new one
- Certification is issued by accredited Conformity Assessment Bodies (CABs) designated under the EUCS framework, not by the notified bodies used for Annex III products

Manufacturers of Annex IV products should engage with ENISA's published roadmap for cybersecurity certification schemes and begin planning for certification well in advance of the CRA application date.

#### Interaction with the EU Cybersecurity Act
The CRA and the EU Cybersecurity Act (EUCS) interact directly for Annex IV products. The EUCS provides the overall framework for EU cybersecurity certification, while the CRA mandates its use for the critical product category.

Key practical implications:
- **EUCS assurance levels**: Article 8 products must be certified at the 'substantial' or 'high' assurance level. The 'basic' level is not sufficient.
- **Scheme availability**: Where an appropriate EUCS scheme does not yet exist for a specific product type, the Commission must act. Until a scheme is available, there may be transitional provisions or alternative paths.
- **Mutual recognition**: EU cybersecurity certifications under EUCS schemes are recognised across all EU member states — manufacturers do not need country-by-country assessments.

#### The Commission's Power to Update Annex IV
As with Annex III, the Commission can amend Annex IV by delegated act to add new product categories as critical infrastructure dependencies and attack surfaces evolve. Given the narrow scope of Annex IV, such additions are expected to be infrequent and subject to careful technical analysis.

A minimum 12-month transition period must be provided when new products are added to Annex IV, giving manufacturers time to undergo the certification process — which, at the substantial or high assurance level, can take 12-24 months for complex hardware products.

#### What counts as the 'core functionality'?
Core functionality is not defined in the Regulation. Commission guidance C(2026) 5252 describes it as the product's main features and technical capabilities, without which it would not be able to meet its intended purpose, assessed in light of the information the manufacturer supplies in the instructions for use, in promotional and sales materials, and in the technical documentation.

Four rules follow. A product has only one core functionality for the purposes of determining the conformity assessment regime, and it must be identified in the technical documentation. Functions additional to the core functionality do not change the classification. Merely integrating an important or critical product does not make the host product important or critical, so a smartphone containing an operating system does not have the core functionality of an operating system. And where a product's core functionality substantially exceeds or substantially falls short of a category, it does not belong to it. Security orchestration, automation and response software generally exceeds the SIEM category because incident response is core to it, while a log collection and visualisation tool that performs no correlation falls short of it.

Modules of an integrated product that the manufacturer also makes available separately, for separate purchase, licensing or subscription, are standalone products classified on their own core functionality.

A manufacturer may not misrepresent core functionality to escape a more stringent regime. Clear inconsistency between promotional materials, instructions for use and the technical documentation is the signal, and non-compliance with Article 32 can attract administrative fines under Article 64(3).