EU Data Act Article 4(2): the cybersecurity exception for connected product data access

The Data Act is the EU's horizontal rule on who can access data generated by connected products and related services. Article 3(1) requires connected products to be designed and manufactured, and related services designed and provided, so that product data and related-service data are, by default, "easily, securely, free of charge... directly accessible to the user." Articles 4 and 5 then give the user a right to get that data from the data holder (typically the manufacturer or its cloud back end) and to direct it to a third party of the user's choosing. For a company that builds a networked device, this is a data-access law layered on top of — not a replacement for — the product-security duties in the Cyber Resilience Act, RED/EN 18031 and similar rules: see our Cyber Resilience Act guide and EN 18031 guide for those separate obligations.

Article 2(5) defines a connected product as an item that "obtains, generates or collects data concerning its use or environment" and "is able to communicate product data via an electronic communications service, physical connection or on-device access," provided its primary function is not storing, processing or transmitting data on behalf of someone else — that last clause is what excludes pure data-processing equipment like servers. A "related service" under Article 2(6) is any digital service, including software, connected to the product in a way that the product could not perform some of its functions without it, or added later by the manufacturer or a third party. Article 2(12) defines the "user" as whoever owns the product, has temporary rights to use it, or receives the related service, and Article 2(13) defines the "data holder" as whoever has the right or obligation to use and make the data available — usually the manufacturer, but it can be a related-service provider instead.

Article 4(2) sets three conditions together, not any one alone: the restriction must be agreed contractually between the user and the data holder; the processing being restricted (access, use, or further sharing) must be capable of undermining a "security requirement of the connected product... laid down by Union or national law"; and the result must be "a serious adverse effect on the health, safety or security of natural persons." Article 4(2) also says "sectoral authorities may provide users and data holders with technical expertise in that context," and requires that where a data holder refuses to share data under this paragraph, it "shall notify the competent authority designated pursuant to Article 37." A user who disputes the restriction can, per Article 4(3), complain to that competent authority or agree with the data holder to use a dispute-settlement body under Article 10(1).

Article 4(2)'s own wording already extends to "further sharing," so a restriction justified under Article 4(2) is not limited to the user's direct access request — it can also block a downstream Article 5 request to share the same data with a third party. Separately, Article 6(2)(f) imposes an independent obligation on the third party itself once it has received data: the third party "shall not... use the data it receives in a manner that has an adverse impact on the security of the connected product or related service." That means a manufacturer has two distinct hooks in the text — a pre-emptive restriction on sharing under Article 4(2), and a standing prohibition on the recipient's use of already-shared data under Article 6(2)(f) — rather than one clause covering both stages.

The Data Act keeps the security exception and the trade-secret regime separate. Article 4(6)-(8) (for the user) and Article 5(9)-(10) (for third parties) require the data holder to identify trade-secret-protected data and agree proportionate confidentiality measures, such as access protocols or confidentiality agreements, before any disclosure; a data holder can only withhold or suspend sharing of that specific data if no agreement on those measures is reached or the measures are not implemented. A full refusal on trade-secret grounds is available only in the "exceptional circumstances" of Article 5(11), where the data holder demonstrates it is "highly likely to suffer serious economic damage" from disclosure despite those measures. Neither trade-secret path asks about health, safety or security at all — that test lives only in Article 4(2). A manufacturer with both a trade-secret interest and a genuine security concern in the same dataset needs to separately satisfy each provision's own conditions; one does not substitute for the other.

Per Article 50, Regulation (EU) 2023/2854 entered into force on 11 January 2024, twenty days after its 22 December 2023 publication, and applies generally from 12 September 2025 — including the Article 4(2) security exception and the Article 37 notification duty. Article 3(1)'s "secure by default" data-access design obligation is delayed further: it applies only to connected products and related services placed on the market after 12 September 2026, so products already on sale before that date are not retroactively required to be redesigned. Chapters III and IV (statutory and business-to-business data-sharing obligations) have their own later trigger dates tied to when the relevant obligation or contract arose, set out in the remainder of Article 50.

No. Article 40 requires Member States to set their own "effective, proportionate and dissuasive" penalties for Data Act infringements and to notify the Commission of those rules, with factors such as the infringement's nature, duration, prior infringements and the infringing party's annual turnover listed as non-exhaustive criteria. Unlike the Cyber Resilience Act, which sets EU-wide maximum fine percentages, the Data Act leaves the actual fine schedule to national law, so the penalty exposure for misusing — or wrongly refusing to apply — the Article 4(2) exception depends on where the data holder or third party is established or enforced against.

Treat Article 4(2) as a documented exception process, not a blanket policy: identify which specific legal security requirement (for example, a CRA or RED/EN 18031 obligation, or a national equivalent) a given data-access or sharing request would undermine, record the resulting health/safety/security risk, and put the resulting restriction into the user contract rather than applying it informally. Keep the Article 37 notification step in the same process, since the paragraph makes it mandatory whenever a data holder actually refuses to share on security grounds. SoftWSP's firmware and device security reviews can document the underlying security requirements and risk analysis a manufacturer needs to support an Article 4(2) restriction, alongside the separate Cyber Resilience Act and RED/EN 18031 work already required for the same product — see device firmware security.

This guide is based on the full text of Regulation (EU) 2023/2854 (Articles 1-9, 37, 40 and 50, and the related recitals) read directly on EUR-Lex for this guide, cross-checked against the European Commission's Data Act policy page. It explains the clauses as published; it is not legal advice, and a security restriction under Article 4(2) should be assessed against your own product and national transposing measures.