CRA timeline and deadlines

The three dates that matter

• 10 December 2024 — entry into force. The clock starts; obligations are not yet active but the definitions, scope and classification rules are fixed.
• 11 September 2026 — reporting obligations apply. Manufacturers must be able to notify actively exploited vulnerabilities and severe incidents within 24-hour early warning and 72-hour notification windows.
• 11 December 2027 — main obligations apply. Essential requirements, conformity assessment, technical documentation and CE marking under the CRA become mandatory for products placed on the market.

Between these anchor dates, secondary legislation and guidance — including harmonised standards, technical specifications and guidance on classification of important and critical products — is expected to be published progressively. Organisations should track these as they emerge rather than waiting for a single consolidated release, since conformity assessment bodies will apply the standards available at the time.

Why the reporting date arrives first

The reporting obligations are separated from the main body of the regulation because they depend primarily on process and organisational readiness rather than product redesign. Regulators judged that manufacturers could reasonably be expected to have an incident and vulnerability reporting capability in place well before the full technical and conformity assessment regime takes effect. In practice, the reporting date functions as a forcing function: it requires an accurate component inventory, a triage process and a decision chain, all of which are also prerequisites for the 2027 obligations.

Building a realistic internal timeline

A programme that starts work only close to 2027 underestimates how long design and verification changes take to flow through a product line, particularly for products with long development cycles or embedded components that are hard to update in the field. A more realistic internal timeline works backwards from December 2027 and treats September 2026 as an intermediate milestone, not the finish line.

• Now to 12 months out: classify products, gap-assess the development lifecycle, and stand up SBOM tooling.
• 6–12 months before the reporting deadline: build and rehearse the vulnerability intake, triage and notification process end to end.
• 12–24 months before the main obligations deadline: close essential-requirement gaps in architecture and process; begin assembling technical documentation incrementally.
• 6–12 months before the main obligations deadline: run conformity assessment activities, including third-party assessment where the product classification requires it.
• Ongoing: maintain SBOM accuracy, support-period commitments and vulnerability handling as operating processes, not one-off deliverables.

Common scheduling mistakes

The most frequent mistake is scheduling CRA work as a single project with one end date, which hides the fact that some obligations are operational (reporting, vulnerability handling, updates) and persist indefinitely, while others are largely a one-off gate (initial conformity assessment). Teams that plan only for the gate tend to under-resource the operational obligations, which are the ones market surveillance authorities are most likely to test after the product ships.

A second mistake is assuming existing products already on the market are exempt. Products placed on the market before the relevant dates are generally not retroactively required to be redesigned, but any substantial modification after the obligations apply can bring a product back into scope, and the vulnerability handling and reporting obligations apply based on when the product is being sold or supported, not only when it was first placed on the market — manufacturers should confirm the precise transitional provisions for their product line rather than assuming blanket exemption.

What evidence a timeline review should produce

A useful internal timeline review produces a dated list of gaps against the essential requirements, a named owner for each, and a rehearsal record for the reporting process. Reviewers and internal audit functions typically want to see that the organisation can point to concrete milestones and evidence of progress, rather than a policy statement that the CRA 'is being addressed'.

Frequently asked questions