The dates that matter

Regulation (EU) 2024/2847, the Cyber Resilience Act, entered into force after publication in 2024. Article 71 sets staged application dates. Article 14 applies from September 11, 2026. Chapter IV, covering notification and conformity-assessment bodies, applies from June 11, 2026. The regulation generally applies from December 11, 2027.

Article 14 contains manufacturer reporting obligations concerning actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The regulation itself is the authoritative source; this page is technical planning guidance, not legal advice.

Why engineering teams cannot wait for 2027

Teams that focus only on the broader 2027 application date can miss an earlier operational obligation. Reporting requires more than adding an email alias. A manufacturer needs to recognize a potentially reportable event, gather reliable facts under time pressure, route decisions to the correct legal entity, preserve evidence, and communicate without creating new security or privacy harm.

The early date also changes engineering priorities. Product inventory, supported versions, vulnerability intake, incident telemetry, customer contact paths, and PSIRT ownership need to work before a reportable event occurs.

The CRA applies according to its definitions, scope, exclusions, roles, and transition provisions. Manufacturers of products with digital elements are central to Article 14, while importers, distributors, open-source software stewards, and other actors have obligations defined elsewhere in the regulation.

IoT device makers, connected-product software teams, platform providers shipping in-scope products, legal and compliance teams, security response teams, customer support, and executive incident owners should assess applicability together. A technical team should not decide legal scope from a blog summary.

Build and rehearse the reporting path

Obtain legal interpretation for the organization’s products and roles. Map each in-scope product to manufacturer entity, supported versions, deployed components, contact owner, and incident-response process. Connect vulnerability reports, product telemetry, supplier notifications, and customer escalation to one triage path.

Define who determines whether evidence indicates active exploitation or a severe incident, who authorizes each notification stage, and who can act if the primary owner is unavailable. Preserve timestamps, affected versions, exploitation evidence, mitigations, and decision records. Keep data minimization and access control in the incident workflow.

Rehearse the process with a realistic scenario. The exercise should include incomplete information, a supplier dependency, multiple product versions, weekends, customer communication, and correction of an initial report. Confirm access to the required reporting mechanism and current official guidance.

Engineering should make deployed-version and component inventory queryable. An SBOM alone is insufficient if the organization cannot link a vulnerable component to shipped firmware and affected customers.

Do not declare every software defect reportable. Qualification depends on the regulation and facts. Do not wait for perfect certainty before establishing the escalation clock, but do not automate external legal notifications from a scanner finding.

Do not collect excessive personal data “just in case.” Do not publish exploitable detail before coordinated disclosure and mitigation planning. Do not assume a security mailbox, vulnerability disclosure policy, or existing NIS2 process automatically satisfies CRA product obligations.

Keep the process tied to current guidance

Track official European Commission and ENISA material on the reporting platform, notification process, templates, and interpretation. Keep legal ownership of that monitoring explicit; engineers should not learn about a changed procedure during an incident. Review supplier and open-source coordination contracts as well, because the manufacturer may need facts from another party inside the reporting timeline. Record which official guidance version each exercise used. Retest the workflow whenever those official procedures change. Keep evidence of each completed rehearsal.

The application dates above come directly from Article 71. The description of Article 14 is a high-level reading of the regulation. The workflow recommendations are IoT 01 analysis. Applicability, report content, recipients, timing in a specific event, and interaction with later implementing guidance require current legal and official advice.

Use the EUR-Lex text linked below and monitor European Commission and ENISA guidance. If official reporting procedures or implementing acts change operational expectations, this signal should be reviewed before its scheduled date rather than silently retaining an older workflow.