Amb 11. September 2026 the first operational obligation under the Cyber Resilience Act begins: Anyone who launches a product with digital elements in the EU must report actively exploited vulnerabilities within 24 hours. The real hurdle is not the deadline, but the question before it – namely whether one is meant at all. Many medium-sized companies answer this question with “we are not a manufacturer” and are wrong. How we support software projects that have to support these requirements is on our side individual software development.
What starts on September 11, 2026
The Cyber Resilience Act – Regulation (EU) 2024/2847 – applies in large parts only from 11. December 2027. The reporting requirements laid down in Article 14 are brought forward and are already applicable from 11. September 2026. It is reported via the central platform of the EU agency ENISA to the responsible CSIRT, in Germany in cooperation with the BSI.
Two things trigger duty: one actively exploited vulnerability in your own product and an serious security incidentwhich affects the safety of the product. The message then proceeds in stages:
- 24 hours: Early warning as soon as the company becomes aware. It may be scarce – it is crucial that it is out in time at all.
- 72 hours: the actual report containing information on the vulnerability and any countermeasures already taken.
- 14 days or one month: the final report – 14 days after provision of a corrective action for vulnerabilities, at the latest one month after reporting of incidents.
Anyone who has already dealt with NIS2 recognizes the cascade. It is deliberately built similarly, but concerns a different addressee: NIS2 is aimed at operators and their own network and information systems, the CRA at the person who places a product on the market. A machine manufacturer can be both – as operator of his own IT and as manufacturer of his machines. What this means for registration at the BSI, we have in the contribution to NIS2 registration described.
24 hours is not a technical requirement, but an organizational one. The deadline also runs on Friday evening – and it presupposes that someone in the house even notices that a vulnerability is being exploited.
“We are not a manufacturer”
This is the most common error, and it does not stand the definition. In the sense of the CRA, manufacturers are those who launch a product with digital elements under their own name or brand in the EU – or significantly change an existing product. This leads to a number of cases that are regularly overlooked in SMEs:
- Machinery and plant engineering. Once control, control panel or remote maintenance includes software, the machine is a product with digital elements. This affects virtually every modern facility.
- Pure software products. The BSI explicitly mentions accounting software and mobile apps. Anyone who offers an app commercially is a manufacturer.
- Purchased development under its own name. If you have software developed externally and distributed under your brand Size the manufacturer – not the development house. This assignment regularly surprises in projects.
- Substantial change. Anyone who rebuilds a foreign product in such a way that his risk profile changes enters into the manufacturer’s obligations.
Excluded is non-commercially provided open source software; mitigated obligations apply to open source managers. However, the exception no longer applies as soon as open source components become part of a commercially distributed product – then the manufacturer is responsible for the entire product.
What is realistically possible by mid-September
Five weeks are not enough for conformity – they do not have to be enough for it, because the content requirements will not come until the end of 2027. Until September, it is all about reporting capability. Realistic are four steps.
First we need a Inventory: Which products do we market with digital elements, and what software is there? Without this list, none of the following questions can be answered. Then the Responsibility – a named person with representation, because a 24-hour period without a call is a fiction. Thirdly Reporting route: Clarify access to the ENISA platform and internally record who reports and who decides. And finally Detection: There is no point in a process if no one notices that a vulnerability is being exploited. This includes an accessible channel for safety instructions from the outside and a look at which third-party components are in their own products.
The real date is December 2027
From 11. Only products that meet the safety requirements of the CRA – with conformity assessment, technical documentation and CE marking – may be placed on the market by December 2027. In addition, there is a duty, weaknesses over a Support period of at least five years or over the entire product life, if this is shorter. For machines that are in the field for ten years or more, this is a new planning logic: security updates become a calculated duty to operate, not a goodwill.
The fine framework underlines this – for violations of the essential requirements and the central manufacturer and reporting obligations up to 15 million euros or 2.5 percent of the worldwide annual turnover, whichever is higher.
In practice, this means that what is created in software today is 2027 under these requirements. Verifiable origin of the components, logging, an update path for shipped devices and documented security decisions are difficult to retrofit if architecture and delivery are not designed for them. Anyone who develops or lets develop now already makes these decisions – consciously or not.
Conclusion
September 11, 2026 is not a certification date, but an organizational date. It does not require a compliant product range, but the ability to respond and report within a day. The necessary preparatory work – knowing which products you put on the market and knowing who is reachable at night – can be done in five weeks. The substantive work for December 2027 does not, and therefore it should begin in parallel. If you want to classify whether your products fall under the CRA and what that means for ongoing development projects, talk to us.
Additional sources
- BSI – Cyber Resilience Act: deadlines, obligations, affected products
- EUR-Lex – Regulation (EU) 2024/2847 (Cyber Resilience Act)
Note: This post gives the status of 6. August 2026 again and serves for general information. It does not replace legal advice; whether and how your company is affected should be examined on a case-by-case basis.
Would you like to implement this in your company? We support you pragmatically – from the idea to the operation.