Put your name
on the software,and it is yours.

Not necessarily, and this is the misunderstanding worth clearing up before money is committed. Under the Cyber Resilience Act the manufacturer is the operator that places the product on the market under its own name or trade mark. If you commission software and then supply it to your customers as your product, that is you. The duties that follow are real work and real cost: conformity with the essential requirements, CE marking, a bill of materials, a disclosure policy, security updates over a support period usually running to at least five years, and a report within twenty-four hours once a vulnerability is known to be exploited. Which party does each of those things, and who pays, belongs in the contract.

That is exactly the boundary that is not settled uniformly, and we would rather say so than give you a confident answer that turns out to be wrong. The Regulation applies to products with digital elements made available on the market; a one-off deliverable supplied to a single business is argued both ways, and the position can turn on how it is supplied and what the client then does with it. Our approach is practical: we decide for your project, record it in writing, and allocate the duties on that basis. If you need a legal opinion on the scope of the Regulation, you need a lawyer, and we will say so.

Two. Since 11 September 2026 the reporting obligations apply: an actively exploited vulnerability or a severe incident has to be notified to the competent CSIRT and to ENISA, starting with an early warning within twenty-four hours. From 11 December 2027 the main body of obligations applies, including the essential cybersecurity requirements, conformity assessment and CE marking. The second date sounds distant and is not, because a product being specified now will still be on the market then, and retrofitting conformity is the expensive way to arrive.

Because it is a different kind of commitment and burying it in a build price misleads everybody. A support period runs for years and carries a cost every one of them: monitoring for vulnerabilities in your own code and in every component you depend on, issuing updates within the expected timescales, and keeping a channel open for anyone who reports a problem. Quoting it separately lets you see the real cost of ownership and decide who should carry it. It also means that where we have not quoted it, there is no doubt that nobody is doing it.

It is an accurate inventory of the third-party and open source components a product contains, with versions and licences. It matters because a vulnerability in a widely used component becomes everybody's vulnerability overnight, and the first question is always which products contain it. Without a list, answering takes days. With one, it takes minutes. We build the inventory as development proceeds rather than reconstructing it at the end, which is also when uncomfortable licence surprises turn up.

No, and be wary of anyone who says yes. What can be committed to is the discipline around it: proportionate measures applied, components tracked, updates issued within agreed times, a route by which a researcher can report something, and prompt disclosure of anything we learn. A guarantee of invulnerability is not a thing that exists, and offering one discourages exactly the precautions that make a real difference.