The Cyber Resilience Act: Reporting Obligations Start on 11 September 2026
The EU Cyber Resilience Act reporting obligation starts on 11 September 2026: 24-hour early warning, 72-hour notification, 14-day final report.
A manufacturer in Gaziantep selling machinery into Europe almost always ships software with it today: a PLC program, a touch panel interface, a remote service module, perhaps a mobile app. For years that software counted as an accessory to the product. From 11 September 2026, European law starts treating it as part of the product itself.
The EU Cyber Resilience Act (Regulation (EU) 2024/2847) sets cybersecurity obligations for products with digital elements. It entered into force on 10 December 2024 and applies in stages. The first real milestone is the reporting obligation: 11 September 2026.
This article covers what a manufacturer of digitally enabled products should have in place on the software side by that date. To be clear from the start: scope assessment and conformity are matters to run with your product compliance adviser. The framework here is for technical readiness.
Who Counts as a "Manufacturer"?
The CRA covers products with digital elements: hardware and software products that connect, directly or indirectly, to a device or network. If you place a product on the European market under your own brand, the manufacturer's responsibility is yours regardless of where it was produced.
For exporters from Türkiye the practical consequence is straightforward. If the machine you sell into Europe carries embedded software, a connectivity module or an accompanying application, you are one of the parties addressed by this regulation. For manufacturers not established in the EU, the national team to which reports are made is determined by where your authorised representative or importer is established. That is a clause worth settling in your contracts now.
What Exactly Starts on 11 September 2026?
The obligation beginning on this date is not about how the product was designed. It is about how quickly you raise your hand when something goes wrong. There are two triggers: an actively exploited vulnerability and a severe incident.
| Stage | Actively exploited vulnerability | Severe incident |
|---|---|---|
| Early warning | 24 hours | 24 hours |
| Notification (description and measures taken) | 72 hours | 72 hours |
| Final report | 14 days | 1 month |
Reports go to the relevant national computer security incident response team (CSIRT), and are circulated from there to ENISA and other teams through a single European platform.
The real difficulty is not visible in the table: 24 hours is an organisational deadline, not a technical one. If the distance between the person who learns of the flaw and the person who files the report is undefined, the clock runs down in email threads rather than in engineering.
Where It Breaks in the Field: "Which Customer Has Which Version?"
What the reporting obligation actually demands is not a legal document but an inventory. When a vulnerability is announced, these are the questions you must answer:
- Which of our product models contain this component?
- Which versions of those models are running in the field?
- Which customer has which version, and since when?
- How will we deliver the update, and how will we confirm it arrived?
A manufacturer who cannot answer these four questions within hours will not meet a 24-hour deadline. The structure that produces the answers is not a new system; it is a disciplined record of products, versions and components. In embedded systems and IoT teams this record usually exists, but scattered: partly in the service log, partly on a developer's laptop, partly in sales records.
SBOM: A 2027 Obligation, a 2026 Necessity
A software bill of materials (SBOM) is the inventory of every library and dependency inside your product. As a formal requirement it sits within the technical documentation obligations on the 2027 timeline. But the sequence should be read backwards: you cannot report within 24 hours on a component you never inventoried.
The common scenario runs like this. A vulnerability is disclosed publicly, spreads through trade press, and your customer asks you about it. With a component list, the answer takes ten minutes. Without one, the answer is "we are checking", and that sentence consumes both the clock and the customer's confidence. Producing that list and keeping it version by version is exactly the work we do in SBOM and product security.
Not Every Product Sits in the Same Basket
The regulation does not treat all products with digital elements identically. For ordinary products the manufacturer's own declaration of conformity is sufficient, while categories considered more critical face a heavier conformity assessment, with third-party involvement in some cases. Certain product groups governed by their own sectoral legislation, such as medical devices, motor vehicles, civil aviation and marine equipment, are left outside the CRA and continue under their own regimes.
The practical consequence: you cannot estimate the cost of readiness before you know which category your product falls into. Category determination comes before technical preparation and is a decision to make with your product compliance adviser. Two production lines in the same factory can land in different categories, which means readiness has to be planned line by line.
CRA, NIS2 and Türkiye's Cybersecurity Law Are Not the Same Thing
This is the most frequently confused heading. All three concern cybersecurity, but they address different parties.
| Regulation | What it governs | Who it addresses |
|---|---|---|
| CRA | The security of a product placed on the market | Manufacturers, importers, distributors |
| NIS2 | The security of an organisation's network and information systems | Entities in the sectors within scope |
| Law no. 7545 (Türkiye) | Cybersecurity governance and reporting in Türkiye | Institutions and companies within its scope |
A manufacturer can fall under more than one, and often does. The good news is that the underlying building blocks overlap. An asset inventory, record-keeping, an incident response procedure and clear ownership, once built properly, serve all three. That is why we build readiness as a single audit and compliance foundation rather than as separate projects per regulation.
What to Do in the Next Three Months
A modest but working preparation looks like this:
- Product and version inventory. Every product model in the field, its software version and the matching customer, in one record.
- Component list. At minimum for critical products, the third-party libraries and dependencies.
- A reporting channel and an owner. An address where security reports arrive, a person who monitors it, and a deputy for when that person is away.
- A response procedure. Who assesses, who decides, who reports, using which template. A written one-page procedure ends the argument during a crisis.
- Supplier clauses. Where you source software components, write into the contract how quickly the supplier must inform you. Your 24 hours mean nothing if your supplier tells you three days later.
- One rehearsal. Run the process end to end against a hypothetical vulnerability. Whatever fails on the first attempt is what will fail in a real event.
None of these six requires developing a new product; they are record discipline and clarity of ownership. In our application security work, the most common gap is not technical either. It is the third item: nobody knows who owns the address where the report will arrive.
Where We Draw the Line
Let us state plainly what we do and do not do here. The legal characterisation of whether your product falls within the CRA, and the conformity assessment itself, are not our work; that belongs with your product compliance adviser or a notified body. Penetration testing and independent security auditing are a separate discipline, and it is methodologically wrong for a development team to perform them on its own product.
What we do is this: produce the inventory and the component list, build the record-keeping infrastructure, write the update distribution mechanism, and put in place a software arrangement in which the reporting process can actually run. The technical ground of compliance, in other words.
Conclusion
The CRA moves software from being an accessory alongside the product to being part of it. The reporting obligation starting on 11 September 2026 is the first concrete step of that shift, and what it asks of a manufacturer is not technological innovation but the ability to know and to notify. For a company that knows its products, versions and components in the field, this obligation is a procedure. For a company that does not, every vulnerability disclosure will be a crisis.
To build the software inventory for the products you sell into Europe and make the reporting process workable, get in touch. The work usually starts with the product list, and within the first week it shows how visible each product really is.
Related reading: