A field report on implementing Article 14 of the Cyber Resilience Act in an eight-person automation company.
A great deal has been written about the Cyber Resilience Act over the past months, mostly by law firms and consultancies. What I missed was an account from someone who had to do the implementation themselves – without a compliance department, without any dedicated staff function, alongside day-to-day business. We have built this for ASKS over the past months. This text describes what turned out different than expected.
It is not legal advice. For a binding assessment of your own situation you need your own review.
What applies on 11 September 2026
From that day, Article 14 of Regulation (EU) 2024/2847 applies. Anyone who makes a product with digital elements available on the Union market and learns of an actively exploited vulnerability or a severe incident having an impact on the security of the product must report it – in stages, counted in hours.
Two things about this are regularly underestimated.
First: the clock does not start with confirmation, but from the moment you become aware. The moment you learned of the matter is therefore itself a fact you must document. Anyone who fails to record it can later neither prove that a deadline was met nor explain a late report.
Second: informing the affected users is not a consequence of the authority notification, but a separate obligation running in parallel. So you need not only a reporting channel to the authority, but also a reliable answer to the question of whom you would even have to reach in such a case – and how.
The exception that isn't one
For micro and small enterprises, the penalty situation was eased by the corrigendum of 2 July 2025: fines do not apply if the only breach is against the deadlines for the early warning (Article 14(2)(a) and (4)(a)).
You should read that sentence to the end. Only the 24-hour deadline is relieved. The 72-hour notification, the final report and the notification of users are not covered. And the exception only holds as long as nothing else was missed – anyone who misses the early warning and then also the 72 hours has no longer breached “only” the early-warning deadline. The reporting obligation itself remains unchanged in any case; what fell away is a penalty, not a duty.
Anyone who reads this as meaning the 24 hours do not apply to them has overlooked the decisive half-sentence.
The installed base was the shock, not the deadline
The big manufacturer obligations – conformity assessment, technical documentation, CE marking – only take effect on 11 December 2027 and essentially for new products. In conversations this quickly turns into the conclusion: there is time until then, and existing installations are grandfathered anyway.
For the reporting obligation that is not true. It also covers products that have long been in the field. The controller that has been running in an installation since 2019, that no one develops any further, whose developer has left the company – for that one you must be able to report from September.
That is the point at which the task takes on its real size for a small manufacturer. The problem is not the next product, but the list of all products ever shipped, and the question of who uses them today.
The effort was organisational, not technical
That was the most surprising insight for me, and it is the most practically useful.
The report itself is a form. Entering it via ENISA's central reporting platform is done in a manageable amount of time; the fields requested at the first stage are deliberately few. Anyone expecting to solve a tooling problem here is looking in the wrong place.
The work is in the questions around it:
Who reads the security mailbox on a Saturday evening? A 24-hour deadline that begins on a Friday afternoon knows no weekend. A mailbox that is in practice only read on business days is not a reporting channel.
Who decides, and who decides in that person's absence? “Actively exploited” is an assessment, not a measurement. Someone who is professionally able to make that assessment must be allowed to make it – and in case that one person is on holiday, there must be a named deputy, not an implicit one.
Exactly when does the deadline start? With a clear report from a security researcher, that is obvious. With a vague customer hint about an installation behaving oddly, it is not. We introduced a simple assessment step for this, which is logged with a timestamp.
For us this turned into a handful of pages of process: named roles, a mailbox with a deputy rule, a decision path with names and phone numbers, a place to file the evidence. Not a single new tool.
The question no one answers for you: who is actually the manufacturer?
We supply software components that run in other companies' machines. This raises a question that appears in no legal text with your name in it: if the vulnerability sits in the bought-in component – who reports?
For us the resolution was a split by type of business. For our own products, sold under our own name, we bear the manufacturer role. In contract development, where the customer places the product on the market under their name, we are a supplier – with different obligations and different contractual commitments.
Drawing this line cleanly and reflecting it consistently in contracts, processes and product documentation cost more time than anything else. But it is the core of the matter, because without it neither you nor your customer knows, in an emergency, who owes the 24 hours.
If you supply components, that is the conversation you should have with your customers – now, not during the incident.
The support period that isn't yours
A point that is almost entirely missing from the debate and that is uncomfortable precisely in machine and plant engineering.
The same corrigendum of July 2025 also clarified Article 13(8). Originally it spoke of the expected product lifetime and the support period; as corrected, only the support period remains. The obligation to handle vulnerabilities thus clearly ends with support, not with the machine.
That sounds like relief. Above all, though, it shifts the question. The support period is not a figure that falls to you – you set it, and you must be able to justify the decision, on the basis of intended purpose, user expectation and comparable products. And this decision is squeezed from two sides.
From above, your supply chain caps it. Look at what your platform supplier commits to. In the CRA whitepaper of CODESYS GmbH (version 1.0, dated 11 June 2025) it is stated unambiguously: the current service pack is fully maintained, previous service packs are not maintained. That is an understandable product decision. For everyone building on this basis, it means: your support period cannot be longer than that of your foundation, unless you take on the gap yourself.
From below, user expectation caps it. An installation runs ten to fifteen years. Anyone who writes three years into the product documentation for such an installation must explain that to the operator – and will find it again in the next invitation to tender. That is not a legal limit, but it works more reliably than any authority.
That leaves three honest paths: you regularly move your customers to the current service pack, which on a running, accepted installation is often not straightforward. Or you commit to a shorter support period than the machine's life cycle suggests, and you tell the customer so. Or you plan for the effort you would have to bear yourself in such a case.
What does not work: writing a support period into the product data sheet that your own supply chain does not carry. If you are currently revising product documentation or licence terms, that is the place where I would look twice.
What I would advise a team of my size
If four weeks still remain today, then in this order:
1. A reachable security mailbox with a named deputy. Published, documented, actually read. Without it you have no inbox, and without an inbox you cannot control when the clock starts. 2. One page of decision path. Who assesses, who reports, who deputises, with names and phone numbers. One page is enough. You write the twenty pages later, when a customer asks. 3. A list of the products in the field together with contacts. For the parallel user notification. Creating this list takes longer than you think, and it is missing exactly when there is no time for it.
Everything else can wait. These three things cannot.
What is still open
For the sake of honesty, not everything is finished on the other side either. ENISA's single reporting platform was not yet in production at the time of writing; the agency names 11 September as the date. At the end of July 2026 the Commission presented its guidelines on the application of the CRA – around eighty pages with examples and decision trees, not legally binding, but the best interpretation aid available.
That changes nothing about the deadline. It changes something about expectations: no one expects an eight-person company to run a situation room. What is expected is that you are reachable, that someone decides, and that you can prove when you knew what.
Anyone in machine and plant engineering standing at the same point: I am happy to compare notes. The questions are the same for all of us.
— Jürgen Renner, Managing Director, ASKS GmbH