CRA readiness countdown — scope, reporting, assessment and release checkpoints

The legal calendar

CRA Article 71 sets the application dates:

Article 69(2) concerns products placed on the market before 11 December 2027 and later substantial modifications. Article 69(3) expressly brings in-scope legacy products into Article 14 reporting. Manufacturing stock before the date is not the same as placing individual units on the market.

About twelve months before application — December 2026

Establish scope per product. Check the connection condition, intended purpose, associated remote processing and Article 2 exclusions. An MDR medical device is excluded from CRA scope; digital functionality alone does not make every product subject to CRA.

Classify by main functionality. Compare the actual product with Annex III, Annex IV and the technical descriptions in Implementing Regulation (EU) 2025/2392. A component or marketing name does not decide the final product’s class. Record the reasoning and unresolved questions.

Assess modifications. Use Article 3(30)’s test and current guidance. A new interface or SoC needs an impact assessment; it is not automatically a substantial modification merely because that feature changed. Preserve the product, firmware and placement evidence for the decision.

Assign economic-operator roles. Article 18 permits appointment of an authorised representative by written mandate. It does not impose a universal representative requirement. Identify manufacturer and importer duties, any applicable responsible-operator requirement and the actual mandate tasks. See the representative overview.

Plan engineering and assessment capacity. Obtain current information from relevant assessment bodies if the chosen route requires one. This article does not establish a universal three-to-six-month assessment duration or guarantee available CRA capacity.

About six months before application — June 2027

Review the reporting operation immediately. Do not wait for this planning milestone: reporting already applies. Confirm the Single Reporting Platform, authorised staff, escalation and evidence preservation.

Both reporting paths have 24-hour early warnings and 72-hour notifications from awareness. For actively exploited vulnerabilities, Article 14(2)(c) makes the final trigger 14 days after a corrective or mitigating measure becomes available. For severe incidents, Article 14(4)(c) makes it one month after the 72-hour notification.

Make the SBOM and handling process reproducible. Annex I Part II requires a commonly used, machine-readable SBOM covering at least top-level dependencies. Neither automatic generation on every development build nor a named CycloneDX/SPDX format is universally prescribed by that wording. Build a workflow that produces the required release evidence and documents remaining coverage gaps. See embedded tooling.

Verify controls and risk evidence. Connect the Article 13(2) assessment with actual implementation and tests. Establish the support period, update arrangements and vulnerability-handling process. A proposed control is not a completed test.

About three months before application — September 2027

Verify the route against CRA Article 32:

• Products outside the important and critical categories: Article 32(1) offers the stated routes, including internal control. Do not add a universal harmonised-standard prerequisite that applies to every standard product.
• Important Class I: internal control depends on Article 32(2)’s coverage conditions; otherwise B+C or H. Check any qualifying certification route rather than assuming availability.
• Important Class II: generally B+C or H under Article 32(3). Assess the Article 32(5) qualifying free/open-source-software exception separately.
• Critical products: check the Article 8 delegated-act and suitable-certification conditions. Article 32(4) provides B+C or H where the applicable certification conditions are absent. Do not promise a universally available scheme or fixed assurance level.

Document the route, scope, actual applied specifications and completed assessment evidence. For radio products, perform the separate RED assessment; an EN 18031 citation is not automatic CRA coverage.

Release check — 11 December 2027

For units and obligations affected by main application, verify the technical documentation against Annex VII, the declaration against Article 28 and Annex V, marking, instructions, support information and the actual assessment result. Preserve the release configuration, evidence and issuance record.

Do not cite future assessments as completed, or treat a certificate preserved by Article 69(1) as a blanket replacement for all CRA requirements. Resolve the product-specific transition and certificate scope first.

Using Cenitia

Cenitia supports evidence-linked working drafts within its regulatory catalogue. Source-change prompts and document structure support the review; the manufacturer and competent reviewers establish applicability, evidence and the issuance decision.

Related reading

• Existing products and the CRA transition
• CRA reporting workflow
• Technical File overview
• CRA and RED overlap