A one-off software product can require CRA analysis just as a mass-market application can. The key questions are what software product is supplied, whether it is made available on the Union market in a commercial activity, who markets it under their name or trademark, how it connects to devices or networks and whether an exclusion applies. Purely internal software raises a separate market-availability question.
The CRA Does Not Create a General Custom-Software Exemption
The Regulation does not establish a blanket rule that bespoke software is outside scope. A custom application can still be software and therefore a potential product with digital elements. The analysis then turns to the normal CRA questions: whether the product is supplied on the Union market in a commercial activity, whether its intended purpose or reasonably foreseeable use includes the relevant data connection and whether any exclusion or special rule applies.
One Customer Does Not Automatically Mean No Market Supply
Making available on the market is defined as supplying a product with digital elements for distribution or use on the Union market in the course of a commercial activity, whether for payment or free of charge. Nothing in that definition requires thousands of buyers. Software created and commercially supplied for use by one customer can therefore require CRA analysis even though it is not sold through a public marketplace.
The CRA Can Apply to Products Made as Individual Units
The CRA recitals explain that the essential cybersecurity requirements apply to each individual product with digital elements when it is placed on the market, irrespective of whether the product is manufactured as an individual unit or in series. This is particularly relevant to bespoke products. A product does not become outside the CRA merely because there is only one installation or one customer-specific build.
Manufacturer Status Depends on Who Develops or Markets the Product
The CRA defines a manufacturer as a natural or legal person who develops or manufactures products with digital elements, or has them designed, developed or manufactured, and markets them under its name or trademark. In custom development arrangements, contract labels such as developer, agency, consultant or customer do not by themselves determine the CRA role. Teams should identify who is responsible for the product and under whose name it is marketed.
A Development Contract Can Contain Both Services and a Product
Custom software engagements often include discovery, consulting, configuration, development, hosting, maintenance and support. The presence of professional services does not by itself answer whether the resulting software is also a product with digital elements. The organisation should define what executable software or digital product is supplied and then assess that product against the CRA's market and technical scope rules.
Customer-Specific Configuration Does Not Necessarily Change the Core Product
A vendor may operate a repeatable software platform but configure it separately for each customer. In that situation, the underlying marketed product may remain substantially the same product even though deployments differ. Conversely, a genuinely bespoke build can have its own architecture, risks and product evidence. The scope record should distinguish configuration from development of a materially different product.
Purely Internal Software Is a Different Question
Software developed solely for use within the same organisation raises a different question because CRA scope is connected to making products available on the Union market. Teams should not automatically transfer conclusions from commercially commissioned software to internal tools. The next part of this cluster contains a dedicated article on internally developed software so that the market-availability issue can be examined separately.
Custom Software Still Needs Product-Level Cybersecurity Evidence
Where bespoke software falls within CRA scope, being custom-built does not remove the manufacturer lifecycle obligations. Product cybersecurity risk assessment, Annex I controls, vulnerability handling, security updates, technical documentation, support-period planning and conformity assessment still need to be addressed in a manner appropriate to the product and its risks.
Define the Custom Product Before Development Is Complete
Custom software teams should record the intended product, customer, functions, deployment model, data connections, remote processing, developer, entity marketing the product, contractual ownership and support model early in the project. This prevents the CRA scope and manufacturer questions from being discovered only after the software has been delivered and makes it easier to build required evidence during development.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.