CRA: Implementation Timeline
| 10/12/2024 | 11/06/2026 | 11/09/2026 | 11/12/2027 |
| Entry into force | Conformity assessment bodies | Article 14 reporting obligations NOW APPLICABLE | General application of the Regulation |
| What changes after 11 September? Organizations can no longer limit their CRA efforts to planning for 2027. They must already have an operational mechanism in place for the detection, escalation, decision-making, and reporting of Article 14 events. At the same time, they must continue progressing toward full compliance with the requirements that will become generally applicable in December 2027. |
|||
Scope: Which Organizations and Products Should Assess It
As a general rule, the CRA applies to hardware and software products placed on the market in the European Union, including components placed on the market separately and certain remote data processing solutions whose absence would prevent the product from performing one of its functions. Not every digital service automatically falls within scope: the assessment must be carried out based on the product, the way it is marketed, its intended or reasonably foreseeable connectivity, the role of the organization, and any exclusions or sector-specific regimes that may apply. [1–2]
In practice, the first mistake to avoid is drafting procedures before having identified the catalog of products, versions, components, markets, and economic operators involved. A properly executed applicability and classification analysis prevents effort from being invested in products that fall outside the scope and, more importantly, prevents products that do generate obligations from being overlooked.
Roles and Implications Across the Value Chain
The CRA distributes responsibilities throughout the supply chain. The most significant obligations fall on the manufacturer, but importers and distributors are not mere intermediaries: they must verify certain conformity elements and act when they know or suspect that a product does not comply. In addition, an importer or distributor may be considered a manufacturer if it markets the product under its own name or trademark, or carries out a substantial modification. [1–2]
| Rol | What It Means | Main Implication |
| Manufacturer | Designs, develops, or manufactures, or has a product designed, developed, or manufactured on its behalf, and markets it under its name or trademark. | Risk assessment, essential requirements, vulnerability management, technical documentation, conformity assessment, CE marking, support, and Article 14 notifications. |
| Authorized Representative | Acts within the EU under a written mandate from the manufacturer for specifically delegated tasks. | Retain or provide documentation where required, cooperate with market surveillance authorities, and carry out the obligations set out in the mandate. |
| Importer | Places on the EU market a product manufactured outside the Union. | Verify conformity assessment, technical documentation, CE marking, EU declaration of conformity, user information, and compliance with manufacturer obligations before placing the product on the market. |
| Distributor | Makes a product available on the market without being the manufacturer or importer. | Act with due care, verify markings and documentation, and refrain from making products available where there is reason to believe that the product or the manufacturer’s processes are not compliant. |
| Own-Branding / Substantial Modification | An importer, distributor, or other entity that rebrands a product under its own trademark or makes a substantial modification to a product already placed on the market. | May legally assume the status and obligations of a manufacturer with respect to the product or the affected part of it. |
| Open-Source Software Steward | An entity that provides sustained support for the development of free and open-source software intended for commercial activities. | Subject to the specific regime established under Article 24; its obligations must not be confused with those of a conventional manufacturer and apply according to the general timeline established by the Regulation. |
| Critical Point for Corporate Groups and Distributors The role is not determined by the internal name of a department or by how the company describes itself commercially. It is determined by what the organization actually does with the product: who places it on the market, under which brand, who modifies it, and who assumes responsibility for its lifecycle. |
||
Manufacturer Obligations: Security Throughout the Entire Lifecycle
Article 13 and Annex I make cybersecurity a requirement of the product itself. The manufacturer must perform and document a cybersecurity risk assessment and use it throughout planning, design, development, production, delivery, and maintenance. The product must achieve a level of security appropriate to the risk, reduce attack surfaces, protect data and functions, enable secure vulnerability management, and facilitate security updates. [1–2]
Vulnerability management takes on particular importance. The manufacturer must identify and document vulnerabilities and components, including a software bill of materials in a common, machine-readable format covering, at a minimum, first-level dependencies; maintain a coordinated vulnerability disclosure policy; provide a point of contact; address vulnerabilities throughout the support period; and exercise due diligence regarding third-party components, including free and open-source software. [1]
The support period must also be defined and justified. As a general rule, it will be at least five years, unless the expected product lifetime is shorter. The technical documentation, EU declaration of conformity, user information, and associated evidence must be retained for the required periods, and published security updates must remain available for the period established by the Regulation. [1]
Classification and Conformity Assessment
Not all products follow the same assessment pathway. The CRA distinguishes between a general category and categories of important products, Class I and Class II, as well as critical products, based on their essential functionality. The classification determines whether the manufacturer may use internal control procedures or whether a third-party assessment by a notified body or, where applicable, a European cybersecurity certification scheme is required. [1–2, 5]
| Category | General Approach | Practical Implication |
| General | Internal control self-assessment may be used. | The manufacturer must independently demonstrate and document compliance with the applicable requirements. |
| Important – Class I | Self-assessment is conditional upon the use of harmonized standards, common specifications, or accepted schemes; otherwise, a third-party assessment is required. | The standards and evidence strategy should be decided early to avoid reworking the technical documentation. |
| Important – Class II | Third-party assessment is required, or alternatively, certification as provided for under the CRA when available. | Capacity and timelines with notified bodies should be planned in advance. |
| Critical | European cybersecurity certification may be required, subject to the conditions established by the European Commission. | The classification should be validated before finalizing the conformity strategy. |
| An internal assessment performed by an independent consultancy or auditor can be highly valuable in preparing for conformity assessment, but it does not replace a notified body when the CRA requires third-party evaluation. | ||
Vulnerability and Incident Reporting: An Obligation Already in Force
Since 11 September 2026, manufacturers must use ENISA’s Single Reporting Platform to report actively exploited vulnerabilities and severe incidents affecting the security of their products. This obligation also applies to products placed on the market before 11 December 2027. [1, 3–4]
| Deadline | Deliverable | What It Requires from the Organization |
| 24 hours | Early warning notification | Rapidly detect, escalate, and confirm whether the event meets the reporting criteria. |
| 72 hours | Complete notification | Consolidate technical information, impact assessment, scope, affected products/versions, and initial mitigation measures. |
| Final report | 14 days after a corrective measure is available for an actively exploited vulnerability; one month after the 72-hour notification for a severe incident. | Maintain traceability of the investigation, root cause analysis, corrective actions, user communications, and closure activities. |
The challenge is not filling out a form. The real challenge is being able to determine which products and versions are affected, which components they contain, who has the authority to make decisions, what information can be disclosed, and how evidence is preserved. For this reason, compliance with Article 14 must be integrated with vulnerability management, incident response, the product security team, support functions, legal teams, and the supply chain.
| Non-Compliance | Maximum Penalty Under the CRA |
| Essential requirements of Annex I and obligations under Articles 13 and 14 | €15 million or 2.5% |
| Obligations listed in Article 64(3), including obligations of economic operators and conformity assessment requirements | €10 million or 2% |
| Providing incorrect, incomplete, or misleading information to notified bodies or market surveillance authorities | €5 million or 1% |
| Clarification Regarding the Enforcement Timeline Article 14 has been applicable since 11 September 2026, but Article 64 forms part of the CRA's general enforcement regime, which is scheduled to apply from 11 December 2027. For this reason, it is important to distinguish between the operational obligation that is already in force and the implementation timeline of the CRA's specific penalty regime, without prejudice to any other liabilities or national legal frameworks that may also apply. [1] |
|
Compliance Approach: Gap Assessment, Implementation, and Internal Evaluation
The most effective way to address the CRA is to treat it as a product program with assigned owners, supporting evidence, and target completion dates. At Internet Security Auditors, we propose a progressive approach that enables organizations to understand their actual level of readiness, prioritize investment, and reach conformity assessment with a consistent technical file and validated controls. This approach aligns with our CRA Compliance Assessment and Support Service. [6]
| ISecAuditors Phase | Objetive | Main Deliverables |
| 1. GAP Assessment and Scope Definition |
Determine applicability, role, classification, and the actual level of compliance. | Product and version inventory; applicability matrix; product classification; GAP analysis against relevant articles and annexes; Article 14 readiness review; prioritized action plan. |
| 2. Implementation | Address identified gaps and integrate CRA requirements into the product lifecycle. | Risk and threat assessments; secure development processes; component management and SBOM; vulnerability and update management; support processes; technical testing; procedures; technical documentation and user information. |
| 3. Internal Assessment / Audit | Verify that measures have been implemented and that the available evidence supports a conformity assessment. | Internal audit of applicable requirements; product sampling; requirement-to-evidence traceability; validation of corrective actions; readiness assessment report and recommendations prior to self-assessment or evaluation by a notified body. |
The value of a GAP analysis is not to generate a simple “compliant/non-compliant” checklist, but to identify which products require architectural, development, or support changes, and which shortcomings are primarily related to governance or evidence. Implementation activities should close those gaps using verifiable criteria. Finally, the internal audit should aim to demonstrate compliance in the same way a third party would: by selecting products and versions, following the trail from risk assessment through testing activities, and verifying that the documentation accurately reflects operational reality.
Internet Security Auditors can support manufacturers, importers, distributors, and other affected economic operators throughout all three stages: scope determination and classification, GAP analysis and action planning; technical and documentary support during implementation; and readiness assessments or internal audits. Where product classification requires third-party assessment, this work serves as preparation and does not replace the involvement of the notified body.
For more information about Internet Security Auditors' CRA service: CRA Compliance Assessment and Support Service
Conclusions
11 September 2026 marks the transition from preparation to obligations that are already operational. A manufacturer that identifies an actively exploited vulnerability or a severe incident must be able to make decisions and submit notifications promptly. At the same time, the December 2027 deadline requires organizations to already be progressing in security by design, vulnerability management, support processes, documentation, classification, conformity assessment, and CE marking.
The risk is discovering too late that compliance requires changes to products or processes. An early GAP assessment, a structured implementation program, and an independent internal evaluation transform CRA compliance into a manageable project, with clear priorities and verifiable evidence.
References
Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act).
European Commission – Cyber Resilience Act: Summary of the legislative text and explanation of scope, economic operators, annexes, and implementation timeline.
European Commission – Cyber Resilience Act: Reporting Obligations. Reporting requirements applicable from 11 September 2026.
ENISA – CRA Single Reporting Platform (SRP). Guidance and frequently asked questions regarding Article 14 reporting obligations.
European Commission – Cyber Resilience Act: Conformity Assessment. Product categories and conformity assessment pathways.
Internet Security Auditors – CRA Compliance Assessment and Support. Scope determination, GAP analysis, implementation support, and compliance evaluation services.
European Commission – Cyber Resilience Act Implementation: Frequently Asked Questions (updated 4 September 2026).
Sources consulted on 11 September 2026. Tables and summaries prepared by the authors based on the cited sources.
