EU Cyber Resilience Act

Article 27 establishes a presumption of conformity for PDEs that conform with: (a) harmonised standards or parts thereof published in the Official Journal; (b) European cybersecurity certification schemes adopted under (EU) 2019/881 designating the schemes as offering presumption of conformity with all or part of the essential requirements. Article 28 requires the manufacturer to draw up a written EU declaration of conformity attesting that the demonstrated fulfilment of the essential requirements has been carried out. Annex V sets the content of the EU declaration.

• EU declaration of conformity for each PDE per Annex V
• Mapping of relied-upon harmonised standards or European cybersecurity certification schemes

• EU declaration of conformity missing Annex V required content
• Claim of presumption of conformity against a non-harmonised standard

Article 29 sets the general principles of the CE marking on PDEs (Regulation (EC) 765/2008 framework). Article 30 sets the affixing rules: the CE marking is affixed visibly, legibly and indelibly to the PDE; where the nature of the product does not allow it, the CE marking is affixed to the packaging and the accompanying documents. Where a notified body is involved (Module B+C or Module H per Article 32) the notified body's identification number follows the CE marking.

• CE marking artwork and placement evidence per Article 30
• Notified body identification number alongside CE marking where applicable

• CE marking absent or not affixed visibly/legibly/indelibly
• Notified body identification number absent on Important/Critical PDE conformity assessment

Article 31 requires the manufacturer to draw up the technical documentation for the PDE before it is placed on the market and to keep it up to date during the support period. The technical documentation contains the items in Annex VII: general description, design and manufacturing of the product including risk assessment, system architecture, list of harmonised standards applied, copy of the EU declaration of conformity, vulnerability-handling process, software bill of materials where appropriate, support-period documentation. The technical documentation must be kept available for 10 years after placing on the market. Annex VI permits simplified technical documentation for microenterprises and small enterprises.

• Technical-documentation file aligned with Annex VII
• 10-year retention plan
• Microenterprise / SME simplified-documentation reliance where applicable (Annex VI)

• Technical documentation lacking Annex VII items (e.g. no SBOM, no risk assessment)
• Documentation not kept up to date through the support period

Article 32 sets the conformity assessment routes: (1) Default PDE - Module A (internal production control - self-assessment by the manufacturer); (2) Important PDE Class I (Annex III Class I) - Module A if the manufacturer applies harmonised standards or European cybersecurity certification, otherwise Module B+C (EU type-examination + conformity to type) or Module H (full quality assurance) by a notified body; (3) Important PDE Class II (Annex III Class II) - Module B+C or Module H mandatory by a notified body; (4) Critical PDE (Annex IV) - mandatory European cybersecurity certification at assurance level 'substantial' or higher under (EU) 2019/881.

• Conformity-assessment route selection record per PDE class
• Module B+C / Module H notified-body engagement evidence
• EUCC certification engagement evidence for Critical PDEs

• Self-assessment (Module A) for an Important Class II or Critical PDE
• Conformity assessment route not aligned with the Article 7 / Article 8 classification

Article 33 requires Member States and the Commission to put in place support measures for microenterprises and SMEs, including regulatory sandboxes, simplified technical documentation under Annex VI, conformity-assessment-fee discounts where notified bodies are used, awareness programmes, and one-stop shops at national level.

• Records of any Article 33 support measures the entity has accessed (sandboxes, fee discounts, regulatory clarifications)

Article 61 governs the exercise of the delegation of power (to amend Annex III/Annex IV product lists, the essential requirements, the conformity-assessment thresholds). Article 62 sets the committee procedure. Article 63 imposes confidentiality on information acquired in carrying out tasks under the Regulation, with carve-outs for information sharing with market surveillance, CSIRTs and other competent authorities.

• Tracking of delegated-act updates to Annex III/IV that may re-classify the entity's PDEs

• No tracking of delegated-act updates causing reclassification of PDEs from default to Important/Critical

Article 69 sets the transitional provisions: PDEs placed on the market before 11 December 2027 are subject to the Regulation only where they are subject to a substantial modification after that date. Article 70 requires the Commission to evaluate and report on the Regulation by 11 December 2030 and every 4 years thereafter. Article 71 sets the entry into force (twentieth day after publication in OJ - 10 December 2024) and the application dates: most provisions apply from 11 December 2027 (36-month transition); the Article 14 reporting regime applies earlier from 11 September 2026; the notified-body provisions apply earlier from 11 June 2026.

• Compliance calendar covering the staggered application dates: 10 Dec 2024 entry into force, 11 Jun 2026 notified-body provisions, 11 Sep 2026 Article 14 reporting, 11 Dec 2027 main obligations
• Substantial-modification policy aligned with the Article 69 grandfathering boundary

• Compliance plan that treats 11 December 2027 as the only date
• Inadvertent loss of grandfathering by substantial modification of a pre-2027 PDE

Article 1 establishes the Regulation's subject matter: horizontal rules for placing products with digital elements (PDEs) on the Union market with cybersecurity requirements, conformity assessment and market surveillance obligations, and obligations on economic operators (manufacturers, importers, distributors, authorised representatives) and on open-source software stewards.

• Internal scope determination linking the entity's products to the CRA subject matter (PDE classification)

• Treating CRA as sectoral cybersecurity legislation - it is HORIZONTAL covering all PDEs not otherwise sector-regulated

Article 11 derogates from the General Product Safety Regulation (GPSR, (EU) 2023/988) for products covered by the CRA on the cybersecurity dimension (CRA takes precedence). Article 12 coordinates with the AI Act (Regulation (EU) 2024/1689): for high-risk AI systems that are also PDEs, compliance with the CRA essential cybersecurity requirements counts toward the AI Act Article 15 accuracy/robustness/cybersecurity obligation (presumption of conformity).

• Documented identification of products that are also high-risk AI systems under the AI Act
• Presumption-of-conformity claim documentation where the entity relies on Article 12 CRA-to-AI-Act coordination

• Dual cybersecurity compliance paths for the same high-risk AI system PDE (Article 12 allows a single CRA path)
• Application of GPSR cybersecurity rules to products covered by CRA (CRA prevails under Article 11)

Article 2 sets the scope: the Regulation applies to PDEs whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Carve-outs include: products covered by sector-specific Union law (medical devices under MDR/IVDR, motor vehicles under (EU) 2019/2144, civil aviation under (EU) 2018/1139, marine equipment); spare parts; products in development not yet placed on the market; pure services. The CRA does NOT apply to non-commercial open-source software (Recital 19 + Article 24 boundary on FOSS stewards).

• Scope-determination matrix for each product (PDE category, applicable sectoral carve-out if any, FOSS-steward boundary)
• CRA-vs-sector-Regulation precedence analysis

• Applying CRA to a medical-device PDE that is in fact governed by MDR cybersecurity requirements (sectoral carve-out applies)
• Applying CRA to FOSS development that is not commercial (out of scope)

Article 3 supplies the definitions used throughout the Regulation. Key definitions include: 'product with digital elements' (a software or hardware product and its remote data processing solutions, including its components placed on the market separately); 'remote data processing'; 'manufacturer'; 'authorised representative'; 'importer'; 'distributor'; 'placing on the market' vs 'making available on the market'; 'substantial modification' (which can re-trigger manufacturer status under Article 21-22); 'critical product with digital elements' (Article 7 + Annex IV); 'important product with digital elements' (Article 6 + Annex III); 'open-source software steward'; 'severe incident'; 'actively exploited vulnerability'.

• Internal terminology glossary aligning the entity's product taxonomy to Article 3 definitions
• Substantial-modification policy aligned with Article 3 and Articles 21-22

• No documented definition of 'substantial modification' creating ambiguity over when an importer/distributor becomes a manufacturer

Article 6 + Annex III defines Important PDEs (Class I and Class II) including identity-management systems, password managers, browser plug-ins, operating systems, microcontrollers with security functionality, routers/modems/switches, network management systems, and similar critical infrastructure components. Article 7 + Annex IV defines Critical PDEs including hardware devices with security boxes, smart-meter gateways with cybersecurity functionality, and smartcards with security elements. Important PDEs trigger third-party conformity assessment by a notified body (Module B+C or Module H per Article 32). Critical PDEs require mandatory European cybersecurity certification under (EU) 2019/881.

• Product-classification record against Annex III and Annex IV
• Notified-body or EUCC certification engagement records where Class I/II/Critical applies

• Self-certification (Module A) for a product that is in fact an Important or Critical PDE
• No EUCC certification engagement for a Critical PDE

Article 13 imposes the central manufacturer obligations: (1) design, develop and produce the PDE to ensure an appropriate level of cybersecurity based on the cybersecurity risk assessment in Article 13(2); (2) Article 13(6) due diligence on third-party components integrated in the PDE including FOSS dependencies; (3) Article 13(8) documented support period (default 5 years, adjustable per product lifecycle and category) during which security updates are provided free of charge, automatically by default, and separately from feature updates; (4) Article 13(12) information and instructions to users (Annex II); (5) Article 13(15)-(16) cooperation with market surveillance. Annex I Part I sets the essential cybersecurity requirements (secure by default, secure communication, data minimisation, access control, no exploitable known vulnerabilities at time of placing on the market, etc.). Annex I

• Cybersecurity risk assessment per Article 13(2) for each PDE
• Third-party component due-diligence file per Article 13(6) including SBOM and FOSS-component analysis
• Documented support period per Article 13(8) communicated to users and tracked operationally
• User instructions per Annex II including security configuration guidance, vulnerability disclosure contact, support period
• Vulnerability disclosure policy aligned with Annex I Part II
• Records of security updates supplied throughout the support period

• No documented support period or support-period shorter than the product's reasonably expected lifecycle
• No SBOM for products with significant FOSS dependencies
• Vulnerability disclosure contact buried or absent from user instructions
• Security updates bundled with feature updates without a separate security-update channel
• Placing on market with known exploitable vulnerabilities (Annex I Part I prohibition)

Article 14 imposes a layered reporting regime channelled through the Article 16 single reporting platform operated by ENISA and CSIRTs: (1) 24-hour early warning to ENISA and to the CSIRT designated as the coordinator notifying of an actively exploited vulnerability or severe incident; (2) 72-hour notification update; (3) Final report within 14 days (or one month for severe incidents). Article 14(8) requires the manufacturer to notify users without undue delay of any actively exploited vulnerability and any severe incident impacting the security of the PDE, including instructions on corrective measures available to users. Article 14(10)-(11) provides for voluntary notification of other vulnerabilities and incidents, with protection of reporting persons.

• Internal escalation procedure capable of meeting the 24-hour early-warning deadline
• Templates and submission accounts for the ENISA single reporting platform
• User-notification channels for actively exploited vulnerabilities and severe incidents
• Voluntary-notification policy under Article 14(10)

• No 24/7 capability to meet 24-hour early warning for actively exploited vulnerabilities
• User notification only via release notes (which users may not read promptly)
• Late or omitted final report

Article 52 designates market surveillance authorities under Regulation (EU) 2019/1020 and gives them the standard market-surveillance powers (inspect, request information, take samples, demand documentation). Member States may designate the ENISA or the national CSIRT as the market surveillance authority for the cybersecurity dimension.

• Identification of the market surveillance authority for each Member State the entity sells in
• Inspection-readiness records covering technical documentation, vulnerability handling and SBOM

• Engagement only with traditional product-safety MSAs where the cybersecurity MSA is ENISA or the national CSIRT

Article 54 sets the procedure at national level concerning PDEs presenting a significant cybersecurity risk: the market surveillance authority can order corrective action, withdrawal or recall from the market within a reasonable period. Article 55 sets the Union safeguard procedure where Member States disagree on the existence of the risk or the measure taken.

• Internal corrective-action / withdrawal / recall procedure capable of executing within the reasonable period set by the MSA
• Records of any Article 54 procedures involving the entity's PDEs

• No documented corrective-action / withdrawal capability
• Slow response to a market surveillance order

Article 64 establishes penalties: (a) breach of essential cybersecurity requirements (Annex I) and Article 13/14 manufacturer obligations and reporting - administrative fines up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher; (b) breach of other obligations - administrative fines up to EUR 10 million or 2% of worldwide annual turnover, whichever is higher; (c) supply of incorrect, incomplete or misleading information to notified bodies or market surveillance authorities - administrative fines up to EUR 5 million or 1% of worldwide annual turnover, whichever is higher.

• Internal CRA compliance program documenting risk management against the Article 64 penalty tiers

Article 35 requires Member States to notify the Commission and the other Member States of the bodies authorised to carry out third-party conformity-assessment tasks under the Regulation. Article 36 sets the requirements for notifying authorities (legally distinct from notified bodies, no conflict of interest). Article 37 sets the substantive requirements for notified bodies (independence, competence, no conflict of interest, accreditation by the national accreditation body, professional liability insurance).

• Engagement records with the relevant notified bodies including accreditation certificates

• Engagement of a body that is not a CRA-notified body for Module B+C / Module H assessments

Article 39 sets the operational requirements for notified bodies (impartiality, transparency, fees, conflict-of-interest management, ongoing competence). Article 41 governs subsidiaries of and subcontracting by notified bodies: the notified body retains full responsibility for the tasks performed by subcontractors and subsidiaries.

• Records of notified-body subcontracting arrangements affecting the entity's PDE assessments

Article 18 requires non-EU manufacturers placing PDEs on the Union market to appoint, by written mandate, an authorised representative established in the Union. The authorised representative carries enumerated tasks: keep the EU declaration of conformity and the technical documentation at the disposal of market surveillance for 10 years, cooperate with market surveillance, terminate the mandate if the manufacturer acts contrary to the Regulation and inform competent authorities.

• Authorised-representative mandate in writing for each non-EU manufacturer brand the entity represents
• 10-year retention plan for EU declaration of conformity + technical documentation

• Non-EU manufacturer placing PDEs on the EU market without an authorised representative
• Authorised representative without access to the technical documentation

Article 19 requires importers to verify before placing a PDE on the market that the manufacturer has carried out the conformity assessment procedure, that CE marking and EU declaration of conformity are present, that technical documentation is available, that the importer's contact details are on the product or its packaging, and that documentation is available to market surveillance for 10 years. Article 20 imposes parallel due-care obligations on distributors when making PDEs available, including verifying that CE marking and required documentation are present, and acting with due care in storage and transport.

• Import-acceptance checklist verifying conformity-assessment, CE marking, technical documentation availability and importer contact data
• Distributor due-care procedure

• Importing PDEs without verifying CE marking and EU declaration of conformity
• Distributors with no due-care procedure

Article 21 provides that an importer or distributor is considered to be the manufacturer for the purposes of the Regulation, and is subject to the corresponding obligations, where the importer or distributor places a PDE on the market under their own name or trademark, or substantially modifies a PDE already placed on the market. Article 22 covers other cases where manufacturer obligations apply (open-source contributions integrated into a commercial PDE by the manufacturer).

• Substantial-modification policy aligned with Article 3 + Articles 21-22
• Own-brand / private-label review process triggering Article 21 manufacturer status

• Substantial modification of a placed-on-market PDE without re-running conformity assessment as the new manufacturer

Article 23 requires economic operators to identify, upon request from a market surveillance authority, any other economic operator that supplied them with a PDE and to whom they have supplied a PDE, for a period of 10 years from the date when the operator was supplied or supplied the PDE.

• 10-year supplier and customer records by PDE for production traceability

• No 10-year supply-chain records

Article 24 introduces the new 'open-source software steward' role: 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, that are intended for commercial activities, and ensures the viability of those products. Stewards have a lighter compliance regime than manufacturers including a documented cybersecurity policy, cooperation with market surveillance, and a vulnerability-handling process aligned with Annex I Part II. Article 25 enables voluntary security attestation of FOSS to facilitate due diligence by manufacturers integrating FOSS components.

• Steward cybersecurity policy and vulnerability-handling procedure where the entity is a FOSS steward
• FOSS security attestation reliance records where the entity integrates FOSS as a manufacturer

• FOSS steward without a documented cybersecurity policy
• Reliance on FOSS attestations that lack the Article 25 supporting evidence