The Cyber Resilience Act: The Reporting Obligations Are Already Running

On 11 September 2026 — eleven days ago — the first real obligation under the Cyber Resilience Act took effect. From that date every manufacturer of a product with digital elements placed on the EU market must issue an early warning within 24 hours of becoming aware of an actively exploited vulnerability in its product.

Most companies are waiting for December 2027, because that is when the Regulation applies in full. That is a misreading: the reporting duty does not wait for 2027, and it covers products placed on the market before full application.

What the CRA is and who it affects

The Cyber Resilience Act is Regulation (EU) 2024/2847 — horizontal legislation introducing cybersecurity requirements for products with digital elements across their entire lifecycle. It follows the logic of EU product law: essential requirements, conformity assessment, technical documentation, declaration and CE marking.

A product with digital elements is any software or hardware product intended for direct or indirect data connection to another device or network. That is deliberately broad: routers and cameras are in scope, but so is the embedded software in a production machine, the companion mobile app for your product, and the libraries you distribute.

The timeline

An important nuance: the reporting duty from September 2026 also covers products placed on the market before full application. Your 2023 portfolio is not exempt — only the CE marking regime for it is.

Reporting: 24 hours, 72 hours, 14 days

1. Within 24 hours — early warning. From the moment the manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting the security of the product, an early warning goes to ENISA and the national CSIRT.
2. Within 72 hours — notification. Fuller information on the vulnerability or incident, including the corrective or mitigating measures taken.
3. Within 14 days — final report. Once the vulnerability has been fixed or the incident handled, a final report describes the vulnerability, its impact and the solution applied.

The four product classes and the route to CE marking

Where a product falls into more than one category, the stricter class applies. The lists of important and critical products sit in the annexes to the Regulation — and that is the first check to run, because it determines whether you will need a notified body at all.

The essential requirements

• Security by design and by default. The product ships with a secure configuration out of the box and a minimised attack surface.
• No known exploitable vulnerabilities at the point of placing on the market.
• A vulnerability handling process — identification, documentation, remediation and coordinated disclosure.
• Free security updates throughout the support period, which by default is a minimum of five years and is set against the product’s expected use.
• SBOM — a software bill of materials in a machine-readable, commonly used format.
• Technical documentation retained for ten years, an EU declaration of conformity and CE marking.

SBOM is the requirement that surprises most teams. It means knowing which open-source libraries go into your product — and being able to answer “does this vulnerability affect us” in hours rather than weeks.

Who counts as the manufacturer

As with machinery, the manufacturer role is assumed more easily than most companies expect. You are a manufacturer under the CRA when you:

• place a product on the market under your own brand, even if someone else built it;
• carry out a substantial modification of a product already on the market;
• integrate third-party components into your product — you then owe due diligence in selecting them.

The third point matters most for integrators: assembling a solution from third-party modules does not push responsibility up the chain. You must verify that the components meet the requirements — and act when they do not.

What happens with open source

Non-commercial open-source software developed outside a commercial activity is largely outside the scope. The Regulation creates a separate, lighter category — open-source stewards — for organisations that maintain such software with structural support.

None of that helps the company that uses open source in a commercial product. There, responsibility sits entirely with the manufacturer of the final product, regardless of who wrote the library.

Penalties

The maximum is EUR 15 million or 2.5 % of worldwide annual turnover for the preceding financial year, whichever is higher, for breaches of the essential requirements and of manufacturer obligations. Lower ceilings apply to other infringements, with a separate penalty for supplying incorrect or misleading information to the authorities.

How ISO 27001 helps and what it does not cover

An ISO 27001 certificate is not evidence of CRA compliance. The CRA is product legislation; ISO 27001 is a standard for the organisation’s information security management system. They complement each other; they do not substitute for each other.

The practical conclusion: if you already run an ISO 27001 system, you have the process foundation and need to add the product layer. If you do not, you will be building both at once — and then December 2027 is suddenly not far away. The same applies to companies working on NIS2: there the obligations attach to the organisation as an entity, here to the product.

Preparation plan

1. List your products with digital elements. Include embedded software, companion apps and the cloud services the product cannot work without.
2. Classify them. Default, important class I, important class II or critical — this determines whether a notified body is required.
3. Get reporting-ready now. This obligation is already live: duty contact, decision rule, platform registrations.
4. Build SBOM into development. Generated automatically on every release, not assembled by hand once.
5. Set the support period for each product and publish it — it is also a contractual commitment to customers.
6. Review contracts with component suppliers. Require an SBOM, remediation deadlines and notification duties.
7. Prepare the technical file alongside development, not at the end — for integrated products it is very hard to write retrospectively.

Conclusion

The CRA changes something fundamental: cybersecurity stops being a promise in a datasheet and becomes a product requirement, with verification and a fine attached. For makers of connected devices and embedded software this is the same shift CE marking brought to mechanical safety thirty years ago.

December 2027 is far away. September 2026 has already passed. If you cannot answer the question “who here receives a vulnerability report on a Saturday, and what do they do in the next 24 hours”, start there — it is the one CRA obligation that can catch you this month.