The key distinction for in-house software is development versus market supply. Software used only inside the same organisation without being supplied on the Union market generally does not meet the CRA making-available concept. A later external deployment, productisation or supply arrangement can require a fresh analysis.
Internal Development Alone Does Not Trigger CRA Product Obligations
The CRA regulates products with digital elements made available on the Union market. Writing software inside an organisation does not by itself amount to making that software available on the market. Where an application is developed and used solely within the same organisation and is not supplied to another person for distribution or use on the Union market in the course of a commercial activity, the normal market-supply element of CRA product scope is absent.
The CRA Distinguishes Development From Market Supply
This distinction is important because software can be technically identical in two organisations but have a different market position. An internal application can remain an internal information-system tool, while the same code packaged and supplied externally can become a software product with digital elements. Teams should therefore avoid treating the location of the developers as the decisive CRA test. The relevant question is what happens to the resulting software after development.
Internal Use Within the Same Legal Person Is Different From External Supply
A company deploying software to its own employees or infrastructure is different from supplying that software to another customer or legal person. As a practical scope assessment, teams should document who owns and operates the software and whether another legal person receives it for distribution or use. Organisational labels such as internal platform or enterprise tool are not enough if the software is in fact being supplied outside the legal person that developed or commissioned it.
Group Companies Need a More Careful Analysis
A corporate group can contain multiple separate legal persons. Software described operationally as an internal group platform may therefore be supplied from one company to another company in the group. That arrangement should not automatically be treated as equivalent to use inside the same legal person. The contractual relationship, legal entities involved, commercial context and manner in which the software is supplied should be recorded before reaching a CRA scope conclusion.
Internal Software Can Later Become a Marketed Product
Many software products begin as internal tools. If an organisation later licenses, sells, distributes or otherwise supplies an internal application to external users on the Union market in the course of a commercial activity, its CRA position needs to be reassessed. Productisation can introduce a manufacturer role, conformity obligations, user-information requirements, support commitments and other responsibilities that were not relevant while the software remained purely internal.
Having Software Developed by a Contractor Does Not Remove the Question
An organisation can have software designed or developed by a contractor and later market the resulting product under its own name or trademark. The CRA manufacturer definition expressly accounts for products developed or manufactured on behalf of another person. Teams should therefore distinguish the developer who writes the code from the organisation that assumes the product-manufacturer role when the software is placed on the market.
Cloud Hosting Does Not by Itself Turn Internal Software Into a CRA Product
An internal application can run on public-cloud infrastructure without automatically becoming a product made available on the Union market. Hosting location and market supply are different questions. The organisation should determine who is permitted to use the software, whether it is supplied externally and whether the deployment constitutes a commercial product offering rather than relying on the fact that cloud infrastructure is involved.
Internal Cybersecurity Duties May Still Come From Other Rules
A conclusion that purely internal software is not a product made available under the CRA does not mean that the organisation has no cybersecurity obligations. Other Union or national rules can regulate the security of entities, networks, information systems, personal data or sector-specific systems. The CRA scope assessment should therefore be kept separate from the organisation's broader cybersecurity compliance analysis.
Document the Point at Which Internal Software Becomes External
Maintain a record of the software owner, legal entity operating it, intended users, external users, contractual supply model and commercialisation plans. Add a CRA review trigger when an internal tool is licensed externally, transferred to another legal entity, bundled with a commercial service or converted into a product offering. That makes scope reassessment part of productisation rather than an afterthought.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.