The problem: Your products are connected devices sold in the EU. Customers are starting to ask about the CRA, and the regulation text is long enough that nobody has read it end to end.
The dates
| Date | What applies |
|---|---|
| 2024-12-10 | Regulation entered into force |
| 2026-09-11 | Manufacturer reporting obligations (Article 14) apply |
| 2027-12-11 | Main obligations apply, including conformity assessment and CE marking |
Products already placed on the market before 11 December 2027 are affected when they undergo a substantial modification after that date. There are separate transitional rules for reporting. Confirm the current text before planning a launch date.
Scope and role
The CRA covers products with digital elements made available on the EU market in the course of commercial activity, where the product's intended or reasonably foreseeable use includes a direct or indirect data connection. Services alone are not products. Some sectors are excluded, and some connected products fall into the more regulated Annex III or Annex IV categories.
- Manufacturer: full obligations, conformity assessment and CE marking.
- Importer: verification duties; can become the manufacturer when supplying under its own name or substantially modifying the product.
- Distributor: due diligence duties; the same reclassification risk applies.
- Open-source software steward: a narrower regime with its own dates.
Use the scope checker, then read the article
The CRA Scope Checker links each question to the article or guidance it comes from, so the result can be reviewed rather than trusted.
What manufacturers actually have to be able to show
- A cybersecurity risk assessment for the product, kept current.
- Products designed, developed and produced with appropriate cybersecurity measures, with no known exploitable vulnerabilities at release.
- A software bill of materials covering at least the top-level dependencies, with the component information needed for vulnerability handling.
- Vulnerability handling: identify and document components, address vulnerabilities without delay, apply regular security updates, publish a disclosure policy, provide a contact point, and share information about fixed vulnerabilities.
- Security updates for a support period that reflects the expected product lifetime, stated explicitly.
- Technical documentation sufficient to assess conformity, retained for the required period.
- A written declaration of conformity and CE marking at the point of placing on the market.
- Reporting of actively exploited vulnerabilities and severe incidents within the Article 14 deadlines.
Reporting is a separate clock
Reporting obligations for actively exploited vulnerabilities and severe security incidents start from awareness, not from your release schedule: an early warning within 24 hours, a notification within 72 hours, and a final report within the prescribed period after a corrective measure becomes available or after the notification, depending on the trigger.
Build a documented path for this before you need it: who decides that a report is required, where the facts are recorded, and how submissions are tracked. A local record is not a submission.
What to do this quarter
- Scope every shipping product with the CRA Scope Checker and keep the result with its citations.
- Confirm the Annex III/IV classification question with legal review, not with a tool.
- Make SBOM generation part of the build and validation part of the release gate.
- Fix identity quality in the SBOM so advisory matching is possible at all.
- Write down the vulnerability handling process, the support periods and the disclosure contact.
- Review supplier contracts for the component and vulnerability information you will be asked for.
Scope and limits
- This is an orientation summary, not legal advice.
- Article numbers and dates reflect the regulation and published guidance as of the updated date; verify against the official text.
- The CRA Scope Checker is indicative and cannot establish conformity.