Compliance
Cyber Resilience Act and custom software: is contract development in scope, and what must your supplier deliver by 11 September 2026?
Published:
The Cyber Resilience Act (Regulation (EU) 2024/2847) covers products with digital elements made available on the EU market in the course of a commercial activity, and European Commission guidance describes software built for one specific customer, and not otherwise supplied on the market, as outside that scope — so most contract development is not directly in scope. The test is market placement, not who paid for the code: license it, resell it, brand it as your own or ship it inside a connected device, and the obligations attach, with the client normally counting as manufacturer. From 11 September 2026 an actively exploited vulnerability must be reported within 24 hours, with a fuller notification within 72 hours and a final report within 14 days of a fix becoming available; full application follows on 11 December 2027. Whether or not your system is in scope, the practical question is what your development partner hands over — SBOM per release, vulnerability intake, a reporting runbook and an exit clause.
The Cyber Resilience Act applies to products with digital elements made available on the EU market in the course of a commercial activity. European Commission guidance treats software built for a single customer, and not otherwise supplied on the market, as outside that scope. Resell it, license it, brand it as your own or ship it inside a device, and the obligations attach. From 11 September 2026, an actively exploited vulnerability must reach the coordinating CSIRT and ENISA within 24 hours.
Is bespoke development in or out of scope?
Regulation (EU) 2024/2847 entered into force on 10 December 2024 and applies in full from 11 December 2027. The regulation covers products with digital elements made available on the EU market in the course of a commercial activity, and the European Commission's published guidance describes software developed for one specific customer, and not otherwise supplied on the market, as falling outside it.
For most contract development the working answer is therefore "not directly in scope". Treat that as a starting point rather than a verdict. The words that decide are "made available on the market", not "who paid for the code" — and the assessment is made per product and per route to market, by your own legal counsel. What follows is general information, not legal advice.
The moment custom code becomes a regulated product
Four everyday situations move a bespoke system back inside the regulation:
- The client licenses or resells the system to third parties.
- The client offers it to its own customers under its own brand.
- The supplier reuses a module across several customers, at which point the module starts behaving like a product.
- The software ships inside a connected device.
The manufacturer is whoever places the product on the EU market under their own name or trademark — in contract development, usually the client rather than the development house. The asymmetry is the real problem: the duty sits with the client, while the component inventory, the build pipeline and the judgement on whether a vulnerability is being actively exploited all sit with the development partner. A contract silent on this leaves the client legally exposed and operationally blind at the same time.
What changes on 11 September 2026
From 11 September 2026, an actively exploited vulnerability must be reported within 24 hours of the manufacturer becoming aware. A fuller vulnerability notification follows within 72 hours, and a final report within 14 days of a corrective or mitigating measure becoming available. For a severe incident affecting the security of the product the timeline differs: early warning in 24 hours, notification in 72 hours, and a final report within one month of that notification. Reports run through the single reporting platform to the CSIRT designated as coordinator and to ENISA. Routine patches, precautionary updates and vulnerabilities nobody is exploiting stay outside the obligation.
Read those deadlines as a business process rather than a paperwork exercise. Twenty-four hours means somebody has to notice, somebody has to classify the finding as active exploitation, and somebody has to be authorised to file — on a Saturday, in August, when the person who wrote the module is on leave. That chain either exists in your contract or it does not exist at all.
What your development partner should hand over
The Cyber Resilience Act sets a support period of at least five years for most products with digital elements, unless the expected use is shorter. Whether or not your system is in scope today, the same seven items decide whether you can act when a component you depend on turns out to be exploited. Work through them against your current agreement:
- Scope statement. In writing: is the deliverable intended to be placed on the market, and under whose name?
- SBOM per release. A machine-readable software bill of materials covering transitive dependencies, not a spreadsheet written once at go-live.
- Vulnerability intake. A named channel, a named person on each side, and an agreed triage path.
- Reporting runbook. Who files within 24 hours, 72 hours and the final deadline — including out-of-hours escalation.
- Patch commitment. How long security fixes are supplied after the last release, and what happens when the contract ends.
- Secure defaults and documentation. Default configuration, hardening notes and the risk assessment record.
- Exit clause. Source code, build pipeline, signing keys and documentation, so patching survives a change of supplier.
If more than one of the seven has no named owner on either side, that is your first gap. Send us the points you cannot answer and we will mark which ones belong to a development partner and which belong to your legal counsel — that split alone usually removes half the anxiety.
Why the handover matters more than the code
Primessio’s team experience covers 50+ delivered projects, including a system for the Headquarters of the State Fire Service used by 22,000 people; that project carried a budget of PLN 20.3m. The team’s experience comes from projects for organisations including T-Mobile, BNP Paribas, PKN Orlen and UKE — environments where documentation, handover and incident procedure were never optional extras. These names describe the team’s experience from those projects, not as a client roster of Primessio.
That is also the working principle at Primessio, led by Dariusz Wtykło, Owner and CEO: a team that delivers solutions, not promises — business understood first, technology chosen second.
That is the honest framing for the Cyber Resilience Act. It is far less a coding regulation than a discipline regulation: inventories, support periods, named responsibilities, evidence you can produce under time pressure. We bring project management discipline (PRINCE2, Agile, IPMA) to exactly that layer, keep data in the EU, and build GDPR and security considerations in from the start. We support your compliance work — we do not provide legal advice and we do not guarantee legal compliance; classifying your specific product is a job for your legal counsel.
Working with a development partner inside the EU
Warsaw is 1–2 hours' flight from the DACH region, and Primessio delivers from Warsaw. Your supplier stays inside EU jurisdiction, which keeps the contractual and data questions in one legal space rather than three. The team's experience spans 20+ years of IT projects and delivery teams of 5–75 people, and we take responsibility for the end result rather than for tickets closed.
Bring your contract and your component list to an intro call — about 30 minutes, no charge: we walk the seven-point handover checklist with you and mark which items a development partner can close and which need your legal counsel. Write to info@primessio.com or use the contact form at primessio.com/en/contact/ — messages sent on a business day are usually answered the same or the next business day, and we sign an NDA before details are exchanged when the project calls for it.
Author: Dariusz Wtykło, Owner and CEO of Primessio (ACTIVE IT) — PRINCE2 / Agile / IPMA; the team's experience spans 20+ years of IT projects. Status: 17 August 2026. This article is general information about Regulation (EU) 2024/2847 and does not constitute legal advice; the classification of your product belongs to your legal counsel.
Frequently asked questions
Does the Cyber Resilience Act apply to custom software?
Not directly, in most contract development. The regulation covers products with digital elements made available on the EU market in the course of a commercial activity, and European Commission guidance describes software developed for one specific customer, and not otherwise supplied on the market, as outside that scope. The test is market placement, not who wrote or financed the code — so the exemption falls away the moment the same software is placed on the market by anyone, including your own company. The classification of your specific product is a question for your legal counsel.
What happens on 11 September 2026 under the CRA?
Reporting obligations start. Manufacturers of products with digital elements must report an actively exploited vulnerability through the single reporting platform: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of a corrective or mitigating measure becoming available. For a severe incident affecting the security of the product, the final report is due within one month of the 72-hour notification. Routine patches and vulnerabilities nobody is exploiting are not covered. Full application of the regulation follows on 11 December 2027.
Who is the manufacturer under the CRA if a contractor built the software?
The party that places the product on the EU market under its own name or trademark. In contract development that is normally the client, not the development house. The practical consequence is uncomfortable: the legal obligation sits with the client while the knowledge needed to meet it — the component inventory, the build pipeline, the ability to judge whether a vulnerability is being actively exploited — usually sits with the supplier.
Does the CRA apply to SaaS and to software we only use internally?
Software used purely inside your own organisation and never supplied on the market falls outside the regulation. Software as a service sits on a genuinely contested line and depends on how the service is delivered and what is installed at the customer. Treat this as a question for your legal counsel rather than a settled point — the article you are reading is general information, not legal advice.
What is an SBOM and do we need one for bespoke software?
A software bill of materials is a machine-readable inventory of the components a build contains, including transitive dependencies. The CRA requires manufacturers to maintain one for products with digital elements. Even where your bespoke system is out of scope, ask for an SBOM per release: without a component list you cannot answer the only question that matters when a widely used library is exploited — am I affected?
What should a CRA clause in a software development contract cover?
Seven things, at minimum: whether the deliverable is intended to be placed on the market and under whose name; delivery of a machine-readable SBOM per release; a named vulnerability intake channel with response expectations on both sides; who files within the 24-hour, 72-hour and final-report windows and who is authorised to do it out of hours; how long security fixes are supplied after the final release; secure defaults with hardening notes and the risk assessment record; and an exit clause covering source code, build pipeline, signing keys and documentation.
Related service: Software & IT systems →