Agency or client: who is the manufacturer of an app under the CRA?
Short answer: usually the client whose name the app is published under, not the agency that wrote it.
The CRA's manufacturer is the person who develops a product or has it designed or developed, and markets it under its name or trademark (Article 3(13)).
An agency becomes a manufacturer when it markets an app under its own name, supplies its own reusable code or white-label product to clients, or substantially modifies an app and makes it available itself (Article 22).
A contract can decide who does the compliance work. It does not move the legal duties of Articles 13 and 14 away from the manufacturer.
That gap is a service opportunity: the client carries the obligations, and the agency is often the only party able to fulfil them day to day.
What the regulation says
Article 3(13) of the Cyber Resilience Act defines the manufacturer as "a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark, whether for payment, monetisation or free of charge".
Two related definitions matter for apps. Placing on the market is "the first making available" of a product on the Union market (Article 3(21)), and making available means supplying it for distribution or use in the course of a commercial activity, "whether in return for payment or free of charge" (Article 3(22)).
The Commission's guidance of 27 July 2026 (C(2026) 5252) summarises the manufacturer as the person that supplies a product under its name or trademark and does so in the course of a commercial activity (point 47).
The deciding factor is therefore whose name the app goes to market under, not whose developers wrote the code.
Who is the manufacturer in common agency set-ups
| Situation | Likely manufacturer | Why |
|---|---|---|
| Agency builds an app to order; the client publishes it under the client's name and brand | The client | The client "has products designed, developed" and markets them under its name (Article 3(13)). |
| Agency builds and publishes its own app under the agency's name | The agency | It develops the product and markets it under its own name. |
| Agency licenses its own reusable app code, template or white-label platform to several clients | The agency, for the code it supplies; each client for the app it then publishes | The guidance treats source code licensed to another company as placed on the market, even if the customer adapts and compiles it, and says the licensor is not responsible for the customer's later adaptations (point 24, Example 7). |
| Agency takes over maintenance of an existing app; the client keeps publishing it | The client | The app is still marketed under the client's name. Ordinary maintenance and security updates do not change that. |
| Someone other than the original manufacturer substantially modifies an app and makes it available on the market | The person who modified it | Article 22 treats that person as a manufacturer, for the modified part or for the whole product if its overall cybersecurity is affected. |
These rows apply the definitions to typical agency work. Real contracts mix these cases, so check unusual arrangements with a lawyer.
The client is the manufacturer: what that means
Most obligations in the CRA are addressed to "manufacturers", so a client that publishes an app built by an agency carries them directly. In particular:
- designing and developing the app in line with the essential requirements of Annex I, Part I (Article 13(1)) and assessing its cybersecurity risks (Article 13(2));
- due diligence on third-party components, including open-source libraries (Article 13(5));
- handling vulnerabilities effectively during a declared support period, which is generally at least five years (Article 13(8));
- drawing up the technical documentation, carrying out the conformity assessment and the EU declaration of conformity (Article 13(12)), and keeping the documentation and declaration for at least ten years or the support period, whichever is longer (Article 13(13));
- indicating its name, registered trade name or trademark and contact details (Article 13(16));
- notifying actively exploited vulnerabilities and severe incidents through the single reporting platform: an early warning within 24 hours and a notification within 72 hours of becoming aware, and a final report no later than 14 days after a fix is available for a vulnerability (Article 14).
The manufacturer can appoint an authorised representative by written mandate (Article 18(1)), but Article 18(2) excludes the duties of Article 13(1) to (11), the first subparagraph of Article 13(12) and Article 13(14) from that mandate.
In other words, the core design, risk and vulnerability-handling duties cannot be delegated away, even formally. An agency can do the work; the client remains answerable for it.
When the agency becomes the manufacturer
Its own name on the product
If the agency publishes an app under its own name or trademark, it is the manufacturer under Article 3(13), even if the app exists mainly to serve one client.
Check what the store listing, the in-app contact details and the brand say: if they all present the agency, the agency is the one marketing the product under its name.
Reusable code and white-label products
Many agencies reuse a core codebase: a booking engine, a loyalty app template, a white-label platform. When that code is supplied to clients as a product, the guidance's Example 7 applies: a company that licenses source code to another company for a customisable platform is placing that code on the market and is subject to the CRA, but it is not responsible for the client's subsequent adaptations and compilation.
The agency is then the manufacturer of the platform it supplies, and each client is the manufacturer of the app it builds and publishes on top of it.
Substantial modification
A substantial modification is a change after placing on the market that affects compliance with the essential requirements of Annex I, Part I, or that changes the intended purpose for which the product was assessed (Article 3(30)).
Article 21 makes an importer or distributor a manufacturer if it substantially modifies a product, and Article 22 does the same for any other person who substantially modifies a product and makes it available on the market.
The Commission guidance adds several points relevant to app maintenance:
- security updates are generally not substantial modifications (point 108), although one can qualify in specific cases (point 109);
- a substantially modified product is treated as a new product and as newly placed on the market (points 116 and 122);
- a person other than the original manufacturer who makes the modification is regarded as the manufacturer of the modified product, in principle only for the part affected (points 117 to 119), unless the cybersecurity of the product as a whole is negatively affected (point 121);
- integration is a different case: a company that builds a new product from components is the manufacturer of that new product (point 120).
For an agency working under a client's name, the practical effect is usually on the client: a release that changes the app's intended purpose or its compliance with Annex I is a new placing on the market by the client.
An agency that ships its own modified version of someone else's app under its own name is in a different position and should treat itself as a manufacturer.
What to put in the contract
The CRA does not prescribe contract clauses. The list below turns the obligations above into points agencies and clients should settle in writing, so that each legal duty has someone who actually performs it.
| Topic | What to agree | CRA basis |
|---|---|---|
| Roles | Who is the manufacturer of each app (and of any agency platform), whose name and contact details appear in the app and store listing | Art. 3(13), 13(16) |
| Support period | The period declared per app version, and who provides security updates during it | Art. 13(8) |
| Vulnerability handling | Who monitors components, who triages, target times for fixes and releases | Art. 13(8), Annex I Part II |
| Components and SBOM | An SBOM delivered with every release; due diligence on third-party and open-source components | Art. 13(5), Annex I Part II |
| Reporting | How fast the agency tells the client about an actively exploited vulnerability, who drafts the 24-hour, 72-hour and final reports, and who submits them as manufacturer | Art. 14 |
| Documentation | Who drafts the technical documentation and the EU declaration of conformity, where they are kept, and handover when the contract ends | Art. 13(12), 13(13) |
| Changes | How a planned release is checked for substantial modification before it ships | Art. 3(30), 22 |
Pay particular attention to reporting. The 24-hour clock starts when the manufacturer becomes aware, so an agency that sits on a finding for two days can leave its client in breach.
More on the deadlines in CRA vulnerability reporting for app teams.
Offering CRA compliance as a paid maintenance service
Most clients that commission apps have no security team and no one who reads lockfiles. They carry the manufacturer's obligations; their agency holds the code, the build pipeline and the release process. That makes CRA work a natural extension of a maintenance retainer.
A typical package covers:
- an SBOM generated for every release and kept per version;
- continuous monitoring of those components for newly published vulnerabilities, with triage notes the client can rely on;
- security updates within agreed times for the whole declared support period;
- prepared drafts of the early warning, notification and final report, so the client only has to review and submit;
- a maintained documentation pack: risk assessment, SBOMs, vulnerability log and the inputs for the declaration of conformity.
To see what such a deliverable can look like, the sample CRA report shows real SBOMs for four releases of an open-source Flutter app, the vulnerabilities found and how to judge them. The support period calculator helps fix the dates a retainer has to cover.
Try it on your own app: the free Shipmark scanner builds a CycloneDX SBOM from a lockfile in the browser and checks it against OSV.dev. Not sure the CRA applies? Use the six-question CRA check.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex: Articles 3(13), 3(21), 3(22), 3(30), 13, 14, 18, 21 and 22.
- European Commission: guidance on the application of the CRA,
C(2026) 5252, 27 July 2026, points 24, 47 and 108 to 122, Example 7 (also available as a web version by the ORC WG). - Giulio Coraggio (DLA Piper): Cyber Resilience Act guidance: which products, which obligations, from when, August 2026.
- SCHUTZWERK: CRA guidance 2026, five product decisions for manufacturers.
This guide summarises EU law and non-binding Commission guidance for practical use. It is not legal advice.
Related: Does the CRA apply to mobile apps? · CRA vulnerability reporting · Sample CRA report.
Originally published on shipmark.eu, where the guide is kept up to date. More guides for app teams: shipmark.eu/guides.
Comments
No comments yet. Start the discussion.