CRA Article 14 for SaaS and remote data processing: when you report

Standalone SaaS vs a product with a cloud backend

Commission CRA implementation FAQ entry 1.2 (ORC WG mirror of the official FAQs) quotes Article 3(1) and 3(2), then draws the service line. Websites that do not support the functionality of a product with digital elements are not themselves such products (Recital 12). Services such as standalone Software-as-a-Service (SaaS) or other cloud solutions designed and developed outside the responsibility of a manufacturer of a product with digital elements are not themselves products with digital elements. Where those services meet the definition of remote data processing, they fall within the scope of the CRA.

Recital 12 adds the policy split: cloud solutions are RDPS only if they meet the Regulation's definition. Manufacturer-provided cloud that lets users control a smart home device at a distance is in. Websites that merely describe a product, or cloud services designed and developed outside the manufacturer's responsibility, are out. The same recital points cloud computing service models (SaaS, PaaS, IaaS) toward Directive (EU) 2022/2555 (NIS2) for many providers.

The Article 3(2) test in one breath

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. Recital 11 stresses that the CRA aims at the product and its integrated RDPS — not at securing the manufacturer's entire corporate network and information systems. A mobile application that needs the manufacturer's API or database is the recital's worked example of an in-scope remote service.

Practical reading for Article 14 triage: if customers receive a software or hardware product you place on the Union market, and that product cannot perform a function without a backend you designed (or had designed under your responsibility), treat actively exploited vulnerabilities and severe security incidents in that stack as product events — not as “just a SaaS outage” outside CRA reporting.

When Article 14 clocks start for product + RDPS

Article 14(1) and (3) require manufacturers to notify actively exploited vulnerabilities contained in the product and severe incidents impacting the product's security, through the ENISA Single Reporting Platform. Because Article 3(1) includes remote data processing solutions in the product, an exploited flaw in the manufacturer-controlled API your app must call can be an Article 14 event for that product. The clocks are the usual chain: early warning within 24 hours of becoming aware, notification within 72 hours, then the final report (14 days after a corrective or mitigating measure is available for an exploited vulnerability; within one month after the 72-hour notification for a severe incident). Overview: reporting deadlines explained. Awareness timing: when the 24-hour clock starts.

Application dates: Article 14 has applied since 11 September 2026 (Article 71(2)). Article 69(3) keeps that reporting duty on products already placed on the market before the wider CRA application date — see Article 14 for legacy products. Do not wait for 11 December 2027 to practice the reporting chain if your client-plus-backend stack is already in scope.

Third-party cloud you integrate is not automatically your RDPS

If the cloud service was designed and developed outside your responsibility, FAQ 1.2 / Recital 12 keep it outside the product definition as standalone cloud. You still assess integration risk; you do not automatically inherit an Article 14 filing duty merely because a vendor you use had an incident. When the issue is a component or library you ship inside a product, use the product-exploitation test in Article 14 for third-party components.

CRA out does not mean “no reporting”

Standalone SaaS that misses the CRA product definition can still face NIS2 (or national) incident duties as a cloud computing service. CRA Article 14 and NIS2 Article 23 do not substitute for each other — details in CRA Article 14 vs NIS2. Separately, products to which the MDR or IVDR apply are outside the CRA under Article 2(2), so Article 14 does not attach to those devices — see Article 14 for medical devices. Type-approved motor vehicles under Regulation (EU) 2019/2144 are likewise out — see Article 14 for motor vehicles. Classify the offering first (CRA product+RDPS, excluded sectoral product, NIS2 entity, both, or neither), then run each clock that actually applies.

Questions people ask

We're a pure browser SaaS — do we have an Article 14 duty?

Usually no. Commission FAQ 1.2 and Recital 12 say standalone Software-as-a-Service and other cloud solutions designed and developed outside the responsibility of a manufacturer of a product with digital elements are not themselves products with digital elements. Those offerings are typically looked at under NIS2 (and similar service regimes), not CRA Article 14. Confirm with counsel if anything you supply to customers is actually a software product placed on the market.

We ship a mobile app / desktop client / agent that calls our cloud. In or out?

The client is a software product with digital elements when placed on the market. Its backend can be remote data processing under Article 3(2) if you (or someone under your responsibility) designed and developed that software and the product would lose a function without it. Then Article 14 looks at the product as a whole — including that RDPS. An actively exploited vulnerability in the API the app needs can start your 24-hour clock.

What is the Article 3(2) remote data processing test?

Remote data processing means 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. Both limbs matter: manufacturer responsibility for the software, and functional necessity for the product. Recital 11 gives the classic case of a mobile app that needs the manufacturer's API or database.

Does a third-party cloud we integrate count as our RDPS?

Not if that service was designed and developed outside your responsibility as manufacturer. FAQ 1.2 and Recital 12 put those outside the product definition as standalone cloud. Treat them closer to third-party components you assess and diligence — see our third-party components guide — rather than as your own remote data processing solution.

If we are in CRA scope for the product+backend, do we also file under NIS2?

Possibly — they are separate regimes. CRA Article 14 is product reporting via the ENISA Single Reporting Platform. NIS2 Article 23 is entity-level incident reporting through national channels. SaaS/cloud providers often sit in NIS2 as cloud computing services even when standalone SaaS is outside the CRA. Filing one does not close the other; see CRA vs NIS2.

When did Article 14 start for in-scope product+RDPS stacks?

Article 14 has applied since 11 September 2026 (Article 71(2)), including for products already on the market before the wider CRA application date (Article 69(3)). The rest of the essential-requirements stack for remote data processing generally tracks the 11 December 2027 application date — reporting does not wait for that.