Does the Cyber Resilience Act cover a website, or a SaaS?

Regulation (EU) 2024/2847 covers products with digital elements made available on the market, but only those that can connect to a device or network. The test is whether their intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

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 placed on the market separately.

Article 3(2) defines remote data processing as data processing at a distance whose software the manufacturer designed and developed, or had designed and developed under its responsibility. It counts only if the product could not perform one of its functions without it.

Those two definitions are the whole scope test. Everything below applies them.

Recital 12 is explicit. Cloud solutions are remote data processing solutions within the meaning of the Regulation only where they meet its definition. Cloud services designed and developed outside the responsibility of a manufacturer of a product with digital elements do not fall within scope. The recital goes on to say that Directive (EU) 2022/2555, NIS2, applies to cloud computing services including Software as a Service.

A product a customer only ever reaches through a browser, where nothing is installed and nothing is embedded, is not a product with digital elements.

A website is treated the same way. Recital 12 says websites that do not support the functionality of a product with digital elements do not fall within scope. A marketing site, a brochure site or an ordinary online shop is not in this Regulation.

One question does most of the work: does the customer install, embed or run any part of it themselves?

Recital 18 says that providing free and open-source software that its manufacturers do not monetise should not be considered a commercial activity. It also says the Regulation does not apply to individuals or organisations who contribute source code to free and open-source products that are not under their responsibility. Recital 20 adds that merely hosting software on an open repository or a package manager does not count as making it available on the market.

There is a middle category the Regulation invented for this. An open-source software steward is an organisation, other than a manufacturer, whose purpose is to give systematic, sustained support to the development of specific free and open-source products intended for commercial activities. It also ensures those products remain viable.

A steward's duties under Article 24 are lighter than a manufacturer's. It needs a documented cybersecurity policy, and it must cooperate with market surveillance authorities on request. It must report actively exploited vulnerabilities to the extent it is involved in development. It must also meet the duties on severe incidents to the extent an incident affects the systems it provides for that development. Recital 19 says a steward should not be permitted to affix the CE marking.

There is no turnover threshold and no headcount exemption anywhere in the scope provisions.

What the Regulation does give smaller firms is some help with the process. Article 33(5) lets micro and small enterprises use a simplified technical documentation form, which notified bodies must accept. Article 32(6) requires conformity assessment fees to be reduced proportionately for SMEs. Article 33 asks member states, where appropriate, to run awareness-raising and training, and to provide a dedicated channel for microenterprises and small enterprises.

None of that changes whether you are in scope. A two-person Irish company placing a connected product or commercial software on the EU market is a manufacturer with a manufacturer's obligations.

Article 2 carves out products already governed by their own sectoral regimes: medical devices under Regulation (EU) 2017/745 and in vitro diagnostics under Regulation (EU) 2017/746, motor vehicle type approval under Regulation (EU) 2019/2144, products certified under the civil aviation regulation, and marine equipment under Directive 2014/90/EU.

It also excludes spare parts made to replace identical components to the same specifications, and products developed or modified exclusively for national security or defence, or specifically designed to process classified information.

If you are in one of those, you are not free of cybersecurity obligations. You are in a different regime.

Article 71 sets three dates. Chapter IV, the notified body framework, applied from 11 June 2026. Article 14, reporting, has applied since 11 September 2026. Everything else, including the essential requirements and CE marking, applies from 11 December 2027.

Article 69 decides the timing. Paragraph 2 exempts products placed on the market before 11 December 2027 from the requirements unless they undergo a substantial modification after that date. Paragraph 3 then says that exemption does not apply to Article 14. The reporting duty therefore reaches every in-scope product already in customers' hands, fifteen months before the requirements those products would be judged against apply at all.

The reporting clocks and what they measure from are set out separately.

As at 29 September 2026, we have not found any published decision naming the Irish body that polices products under the Cyber Resilience Act (its market surveillance authority). The National Cyber Security Centre's own CRA page, last updated on 11 September 2026, names none. It sends reporting through the single reporting platform run by ENISA, the EU cybersecurity agency. From there, reports reach the national incident response team (CSIRT) and ENISA at the same time.

That is a statement about what is published. A designation may exist that has not been published, and this article names only bodies it can source.

The reporting duty applies directly under a Regulation, and the platform it runs through is a European one.