Cyber Resilience Act: the countdown has started for connected products

July 16, 2026 · 4 min read · SOVALYX Technologies

The Cyber Resilience Act (CRA) is the EU regulation imposing cybersecurity requirements on every product with digital elements placed on the Union market — hardware and software alike. Its first concrete deadline lands on 11 September 2026 with the reporting obligations for actively exploited vulnerabilities; the bulk of the obligations apply on 11 December 2027. For a manufacturer or software vendor, preparation starts now.

Who is covered: far more than connected gadgets

The CRA's scope is deliberately broad: it covers products with digital elements, meaning connected hardware (network equipment, sensors, controllable industrial machines, consumer electronics) but also software placed on the European market — applications, embedded systems, components. The official description of the text is available on the European Commission's website.

Three points widen the circle of organisations concerned:

• Where you are headquartered does not shield you. As with other EU texts, it is placing a product on the Union market that triggers the obligations. A Mauritian vendor selling software or equipment to European customers falls in scope as a manufacturer, exactly as the NIS2 cascade catches non-EU suppliers.
• The whole chain is mobilised. The text primarily targets manufacturers, but also assigns responsibilities to importers and distributors, who will have to verify the compliance of what they put on the shelf.
• Buyers will use it. Even a company that manufactures nothing will see the CRA arrive in its tenders: the compliance of purchased products will become a selection criterion and a contractual requirement.

Two dates to remember

The application timeline is staged, with two structuring milestones:

• 11 September 2026: the reporting obligations for actively exploited vulnerabilities (Article 14) become applicable for manufacturers. It is the first operational deadline, and it arrives before the rest of the text.
• 11 December 2027: the bulk of the obligations apply — security requirements from the design stage, vulnerability handling across the product's lifetime, technical documentation and marking attesting conformity.

The order of these deadlines is a message in itself: the legislator starts with the ability to detect and report that a product is under attack, before even requiring full conformity. A necessary note: this article is an information summary, not legal advice — the exact scope of your obligations should be confirmed with your advisors.

Article 14: what "reporting" demands in practice

Reporting an actively exploited vulnerability presupposes a complete chain that, in many organisations, does not yet exist:

• Knowing it exists. You need a channel through which researchers, customers and partners can reach you — a published coordinated disclosure policy, a dedicated address, an intake process that loses nothing.
• Knowing it is exploited. Telling a theoretical flaw apart from active exploitation requires telemetry, usable logs and analysis capability — in plain terms, real monitoring of what happens on and around the product.
• Qualifying and notifying quickly. Reporting to the authorities runs on tight deadlines: without a written, tested process with defined roles and on-call coverage, paper compliance will not survive a real incident.
• Fixing and informing. Reporting is not the end: you must be able to produce a fix, distribute it and inform the affected users.

What to prepare in 2026

The foundations the CRA demands are the same as those of serious product hygiene — better to build them once, properly:

• Product and component inventory: which products are placed on the European market, in which versions, with which dependencies and third-party components.
• SBOM (Software Bill of Materials): a software bill of materials generated automatically at every build, not a document written by hand once a year. It is what lets you answer "are we exposed?" quickly when a vulnerability hits a widespread component.
• Vulnerability management process: monitoring of components, triage, remediation, update distribution, a support policy per version.
• Disclosure channel: published disclosure policy, security point of contact, internal qualification and notification procedure with roles and backups.
• Evidence: everything above must be documented and demonstrable — regulators and customers alike will ask for proof, not intentions. A security audit measures the gap between what exists and these requirements.

CRA checklist: where do you stand?

• We have established whether our products (hardware or software) are placed on the EU market.
• Our role in the chain (manufacturer, importer, distributor) is qualified product by product.
• An inventory of products, versions and third-party components exists and is kept up to date.
• An SBOM is generated automatically for every shipped version.
• A coordinated disclosure policy is published, with a reachable security contact.
• The process for qualifying active exploitation is written and tested.
• The notification chain (who decides, who notifies, who communicates) is defined with backups.
• Patch distribution to customers is tooled and measured.
• Contracts with our own component suppliers cover vulnerability reporting.

If the Article 14 deadline feels distant, remember that it demands operational capabilities, not documents: a disclosure channel, telemetry, on-call coverage. These building blocks take months. A diagnostic of your product chain lets you sequence the work before the calendar does it for you.

🧰 The companion tool: Are you ready for the AI Act? — free · 2 minutes.

Reviewed and optimised by AI.