EC REP for software products under the CRA: when SaaS, pure software, and firmware need an EU authorised representative

If you ship software into the EU from outside the EU — a SaaS backend tied to a smart device, a firmware image sold as a separate SKU, a desktop application, a developer SDK — the question is no longer whether the Cyber Resilience Act touches you. It does. The question is who, on EU soil, is going to hold your technical file and answer the phone when a market surveillance authority calls. That role is the EU authorised representative, often shortened to EC REP, and the CRA reshapes what it means for software.

This guide walks through three connected things: when software falls inside the CRA's 'product with digital elements' definition, when a non-EU software manufacturer effectively needs an EC REP, and exactly what that representative can — and cannot — do for you. For the broader hardware-oriented view of the role, see our companion piece on the EU authorised representative (EC REP) guide, and for the underlying conformity framework see Declaration of Conformity 101 and CE marking 101.

Is your software a 'product with digital elements'?

The CRA's scope hinges on a single definition. Article 3(1) defines a 'product with digital elements' as 'a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately' (Article 3(1), CRA). That clause does three things at once:

• It puts software products on the same footing as hardware. A downloadable application, a firmware binary sold separately, an on-premise enterprise system — all are products.
• It pulls in components placed on the market separately, which captures software libraries, modules and SDKs sold as standalone offerings.
• It pulls in remote data processing solutions that belong to the product.

The 'remote data processing' hook is the SaaS test. Article 3(2) defines it as 'data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions' (Article 3(2), CRA).

Read literally, that means a cloud backend qualifies as part of the regulated product when two conditions are met: (a) the manufacturer is responsible for that backend's software, and (b) the product would not be able to perform one of its functions without it. A connected camera whose video upload pipeline lives in your AWS account satisfies both. A pure marketing website does not.

This is why 'is SaaS in the CRA?' is the wrong question. The CRA does not regulate SaaS as a category — it regulates SaaS components that are functionally inseparable from a product with digital elements.

Free and open-source software: no blanket exclusion

Founders often assume FOSS is out of scope. It is not — at least not by virtue of Article 2.

Article 3(48) defines FOSS as 'software the source code of which is openly shared and which is made available under a free and open-source licence which provides for all rights to make it freely accessible, usable, modifiable and redistributable' (Article 3(48), CRA). Crucially, the CRA does not then add a clause to Article 2 saying 'this Regulation does not apply to FOSS'. The Article 2 exclusions are about product categories — medical devices under Regulation (EU) 2017/745, in-vitro diagnostics under Regulation (EU) 2017/746, and type-approved motor vehicle systems under Regulation (EU) 2019/2144 (Article 2(2), CRA); civil aviation products certified under Regulation (EU) 2018/1139 (Article 2(3), CRA); and marine equipment under Directive 2014/90/EU (Article 2(4), CRA).

Instead, the CRA handles FOSS through two distinct mechanisms.

First, Article 3(14) introduces the open-source software steward: 'a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products' (Article 3(14), CRA). Stewards have lighter obligations than full manufacturers, set out elsewhere in the Regulation.

Second, Article 25 empowers the Commission 'to adopt delegated acts in accordance with Article 61 to supplement this Regulation by establishing voluntary security attestation programmes' for FOSS products with digital elements (Article 25, CRA).

The practical takeaway: if you wrap FOSS into a commercial product with digital elements that you place on the EU market, your role is 'manufacturer', not 'steward', and you carry the full obligation set — including the EC REP retention duty if you sit outside the EU.

Why a non-EU software manufacturer needs an EC REP in practice

Article 18(1) reads, on its face, as optional: 'A manufacturer may, by a written mandate, appoint an authorised representative' (Article 18(1), CRA).

But the document retention rule converts that 'may' into a 'must' for anyone established outside the EU. Article 13(13) requires manufacturers to 'keep the technical documentation and the EU declaration of conformity at the disposal of the market surveillance authorities for at least 10 years' (Article 13(13), CRA). EU market surveillance authorities expect to be able to obtain that documentation from someone with an EU presence within reasonable timeframes. If you have no EU-established legal entity, the practical answer is an EC REP — the same logic that has applied across the New Legislative Framework for years.

The retention period is anchored not just to ten years but to the product's support period. Article 13(8) third subparagraph provides that 'the support period shall be at least five years' (Article 13(8), CRA), and Article 18(3)(a) makes the EC REP's retention duty run for 'at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer' (Article 18(3)(a), CRA). For most software, ten years is the operative floor.

For a deeper review of how that timeline interacts with documentation duties, see Technical file retention requirements.

What an EC REP can — and cannot — do for software

Article 18(2) is the critical ringfence: 'the obligations laid down in Article 13(1) to (11), Article 13(12), first subparagraph, and Article 13(14) shall not form part of the authorised representative's mandate' (Article 18(2), CRA).

Translated into a software vendor's working list, an EC REP cannot:

• Design or develop your software product or sign off on essential requirements.
• Carry out conformity assessment, including the procedures under conformity assessment modules A to H.
• Draw up the technical documentation.
• Draw up or sign the EU declaration of conformity.
• Affix the CE marking on behalf of the manufacturer.
• Determine your support period or vulnerability handling programme.

The EC REP can — and under Article 18(3) must — do three things:

• Article 18(3)(a) — 'keep the EU declaration of conformity referred to in Article 28 and the technical documentation referred to in Article 31 at the disposal of the market surveillance authorities' for at least 10 years or the support period, whichever is longer (Article 18(3)(a), CRA).
• Article 18(3)(b) — 'further to a reasoned request from a market surveillance authority, provide that authority with all the information and documentation necessary to demonstrate the conformity of the product with digital elements' (Article 18(3)(b), CRA).
• Article 18(3)(c) — 'cooperate with the market surveillance authorities, at their request, on any action taken to eliminate the risks posed by a product with digital elements covered by the authorised representative's mandate' (Article 18(3)(c), CRA).

For software companies used to GDPR Article 27 representatives, that document-custody and authority-liaison shape is the same family — but the substance is product safety and cybersecurity rather than data protection.

Common mistakes

A handful of recurring errors show up when software vendors design an EC REP arrangement:

1. Treating the EC REP as a signing authority for the DoC. Article 18(2) is explicit that drawing up the DoC sits with the manufacturer under Article 13(12) first subparagraph and is excluded from the mandate. The DoC is signed by the manufacturer; the EC REP holds it.
2. Assuming FOSS is out of scope. There is no FOSS exclusion in Article 2. Steward status under Article 3(14) and voluntary attestation under Article 25 are alternatives to the full manufacturer regime, not blanket carve-outs.
3. Forgetting SaaS components. If your cloud backend is necessary for the product to perform one of its functions, Article 3(2) brings it into the product boundary — and into the technical file the EC REP must keep.
4. Stopping the retention clock at ten years. Article 18(3)(a) requires the longer of ten years or the support period. For a long-lived enterprise software product with a fifteen-year support commitment, the EC REP retention obligation is fifteen years.
5. Confusing the EC REP with the importer or distributor. They are distinct roles with distinct obligations. Many of the mistakes that show up here also show up in our top 10 CE marking mistakes list.

How Cenitia helps

Cenitia models your software product as a CRA 'product with digital elements' from day one — including its remote data processing solutions, its FOSS components, and its support period. The platform builds and version-controls the technical documentation under Article 31 and the EU declaration of conformity under Article 28, scopes the mandate to exactly what Article 18(2) permits, and holds the document set in EU-resident storage so an EC REP can respond to an Article 18(3)(b) reasoned request without scrambling for files.

When a cited regulation amends — a new EN harmonised standard, a delegated act under Article 25, a change to Annex I — Cenitia flags the affected technical file, DoC, and EC REP mandate clauses for review, so the documentation an authorised representative holds stays current through the product's support period.

Frequently asked questions

Is pure software a 'product' under the CRA, or only embedded software?

Yes — pure software is a product under the CRA. Article 3(1) defines a 'product with digital elements' as 'a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately'. That includes standalone commercial software, firmware sold as a separate SKU, and downloadable applications. The historical CE-marking intuition that 'CE is for hardware' does not apply to the CRA.

Does the CRA cover SaaS?

Only conditionally. Article 3(2) defines remote data processing as 'data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions'. A SaaS backend tied to a smart device or to a software product — without which the product cannot function — is in scope. A pure standalone cloud service that is not a component of any other product with digital elements is not the target of the CRA.

Does free and open-source software (FOSS) need an EC REP?

Not by default, but not because of a blanket exclusion. Article 3(48) defines FOSS as software whose source code is openly shared under a free licence. The CRA does not contain an FOSS scope carve-out in Article 2; instead it creates the 'open-source software steward' role in Article 3(14) for legal persons that systematically sustain FOSS intended for commercial activities, and Article 25 empowers the Commission to set up voluntary security attestation programmes for FOSS. If you commercialise an FOSS-derived product with digital elements, the normal CRA obligations — including the EC REP retention duty — still apply.

Can my EC REP sign the EU declaration of conformity for me?

No. Article 18(2) is explicit: 'the obligations laid down in Article 13(1) to (11), Article 13(12), first subparagraph, and Article 13(14) shall not form part of the authorised representative's mandate'. That carve-out includes design and development of the product, conformity assessment, drawing up the technical documentation, drawing up and signing the EU declaration of conformity, and affixing the CE marking. The EC REP holds and presents the DoC to authorities — it does not sign it.

How long must my EC REP keep my software's technical documentation?

Article 18(3)(a) requires the EC REP to keep the EU declaration of conformity (Article 28) and the technical documentation (Article 31) available to market surveillance authorities 'for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer'. The manufacturer has a parallel ten-year duty under Article 13(13), and the CRA's minimum support period under Article 13(8) third subparagraph is five years (or shorter only if the expected use time is shorter), so the practical retention floor for most software is ten years.

When do these EC REP obligations actually start applying?

The CRA entered into force on 10 December 2024. Most provisions are not yet enforceable. Chapter IV on the notification of conformity assessment bodies applies from 11 June 2026; the Article 14 reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026; the main manufacturer obligations — including EC REP appointment, conformity assessment, CE marking and the documentation duties relevant to the EC REP mandate — apply fully from 11 December 2027.

Related from the Library

• EU authorised representative (EC REP) guide
• CRA December 2027 readiness
• CRA timeline and reporting obligations
• Technical file retention requirements

Further reading

• Cyber Resilience Act — consolidated text and article-by-article view
• European Commission summary of the CRA timeline
• EUR-Lex summary: horizontal cybersecurity requirements for products with digital elements
• Regulation (EU) 2017/745 — Medical Devices Regulation (cross-reference to CRA Article 2 exclusion)
• Regulation (EU) 2018/1139 — civil aviation safety (CRA Article 2(3) exclusion)
• Directive 2014/90/EU — marine equipment (CRA Article 2(4) exclusion)

Last reviewed: 5 July 2026. Cited regulations watched continuously by Cenitia — when one amends, this article is flagged for update.