Data Act, 12 September 2026: in a month, connected products must open up data by default
7 min read
A continuous fibre-monitoring (RFTS) system scanning the dark fibres of a route generates thousands of OTDR measurements every night. An instrumented splice closure with a water sensor generates an event every time it crosses its threshold. A patch frame with port-level traceability generates a state for every connector. A data centre’s DCIM generates temperature, humidity and UPS load, minute by minute. Ask whoever supplies you with one of these devices what format that data comes out in, whether it is real-time, where it is stored and for how long, and what technical means you have to retrieve it. In most of the specifications that cross our desk, that line simply is not there. In thirty days, for products placed on the market from that point on, this stops being a question you can choose not to ask: it becomes a legal obligation.
12 September 2026 is not when the Regulation started
Regulation (EU) 2023/2854, the Data Act, has already applied since 12 September 2025: this is not new territory, and it is the same Regulation we wrote about regarding switching to another cloud provider and the jurisdiction of the infrastructure that processes your data. What comes into force in a month is different: it concerns not the cloud but the manufacturing of products. Article 50, third paragraph, states it without room for interpretation: “The obligation resulting from Article 3(1) shall apply to connected products and the services related to them placed on the market after 12 September 2026.” It does not concern what you have already installed: it concerns what you will buy, or be offered, from that date onward.
And Article 3(1) is the design requirement that comes with that date: “Connected products shall be designed and manufactured, and related services shall be designed and provided, in such a manner that product data and related service data, including the relevant metadata necessary to interpret and use those data, are, by default, easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format, and, where relevant and technically feasible, directly accessible to the user.” Not access on written request to the supplier, not a paid export, not a PDF: default access, free of charge, in a format a machine can read without human intervention.
The two definitions that decide whether a device is in scope
Everything depends on two definitions in Article 2. A “connected product” is defined as “an item that obtains, generates or collects data concerning its use or environment and that is able to communicate product data via an electronic communications service, physical connection or on-device access, and whose primary function is not the storing, processing or transmission of data on behalf of any party other than the user”. A “related service” is defined as “a digital service, other than an electronic communications service, including software, which is connected with the product at the time of the purchase, rent or lease in such a way that its absence would prevent the connected product from performing one or more of its functions, or which is subsequently connected to the product by the manufacturer or a third party to add to, update or adapt the functions of the connected product”.
We are not, in this piece, qualifying any specific device: that depends on the actual product and the contract, and we do not make that call on anyone’s behalf. But the definition is written broadly — “an item that obtains, generates or collects data” — and in a network or a data centre the candidates are everywhere: a continuous RFTS monitoring system, an instrumented splice closure with a water sensor, an OTDR or a measurement probe left in the field, a patch frame with port-level traceability, a DCIM and its room sensors, uninterruptible power supplies, meters. All of them obtain or generate data about their own use or environment; almost none of them, today, states what format that data comes out in.
Four pieces of information, before signature
Article 3(2) does not wait for delivery: it fixes what the seller, rentor or lessor must disclose before the contract, “in a clear and comprehensible manner”. Four points, verbatim: “(a) the type, format and estimated volume of product data which the connected product is capable of generating; (b) whether the connected product is capable of generating data continuously and in real-time; (c) whether the connected product is capable of storing data on-device or on a remote server, including, where applicable, the intended duration of retention; (d) how the user may access, retrieve or, where relevant, erase the data, including the technical means to do so, as well as their terms of use and quality of service.” Four lines, already written for you: they only need copying into a request for quotation.
Paragraph 3 extends a similar obligation to whoever provides a related service: the nature, estimated volume and collection frequency of the data the provider is expected to obtain, and how the user can access or retrieve it. Whoever outsources the remote management of a DCIM or an optical monitoring system is the user receiving that related service: the same questions apply to the management contract, not only to the purchase of the device.
See the service · Talk to an engineer
What we don’t know, and where we stop
The obligation under Article 3(1) is not retroactive: it applies to connected products and related services placed on the market after 12 September 2026, not to the RFTS systems, splice closures or patch frames already installed on your network. We do not address which specific devices fall within the definition of a connected product: that depends on the product and the contract. We have not checked whether or how individual manufacturers are adapting, and we make no claim either way.
We found two relevant exemptions in the text, both worth naming precisely. Recital 14 explicitly excludes prototypes from the scope of connected products. And Article 7 exempts, from the obligations of the Chapter containing Article 3, data generated by products manufactured or designed by a microenterprise or a small enterprise, on conditions the article ties to partner or linked enterprises and to subcontracting, and allows one year for products placed on the market by a medium-sized enterprise. Recital 41 explains those conditions more clearly than the enacting terms do: if you are buying from a small manufacturer, the check belongs to the specific case. We found no further exemptions in the text of Articles 2, 3, 7 and 50. This is regulatory reading of primary sources, not legal advice.
The two axes, applied to this obligation
The four pieces of information in Article 3(2) become four lines in the spec for the next device you buy after 12 September: the type, format and volume of the data; whether it is continuous and real-time; where it is stored and for how long; the technical means to access, retrieve and erase it, and on what terms of use and quality of service. And acceptance testing does not check the supplier’s promise: it checks the extraction. You actually download a sample of data in the declared format, and keep it as dated evidence.
The data those devices generate — RFTS measurements, splice-closure alarms, patch-frame port states — stop being a file left sitting in a supplier’s portal. With CSIDIA, the other company in the group, they become part of the single map of the network — the same one behind our work on the as-built register — on which an AI makes the diagnosis and the team closes the fault. That is why the format matters more than the promise: data that comes out “machine-readable”, as Article 3 requires, feeds the operational model that cross-references alarms and as-built records; a PDF downloaded once a year does not. Within the client’s perimeter: on-premises on self-contained machines with no deep integration, or dedicated cloud with a data centre in Italy, always with shared management.
From the site survey, at no cost, comes the list of devices generating data on your network — RFTS, splice-closure sensors, patch frames, DCIM — with, for each one, what format it comes out in, whether it is real-time, where it is stored and who can retrieve it, including the boxes that stay empty. It is yours to keep even if we don’t go on to work together. Talk to an engineer.