There is a date ten days out that almost nobody in Irish software is talking about. On 12 September 2026, Article 3(1) of the EU Data Act starts applying to connected products and related services placed on the market from that day onward. It is short, prescriptive, and unlike most of what arrives from Brussels it is not a policy document. It is a build requirement.
The obligations hide in the adverbs. Connected products must be designed and manufactured, and related services designed and provided, so that product data and related service data, including the metadata needed to interpret and use them, 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”. Every one of those words is a specification you can fail.
TL;DR
- The EU Data Act has applied since 12 September 2025, but that was access on request. From 12 September 2026, Article 3(1) requires access by design for products placed on the market after that date.
- Scope is wider than vehicles and factory kit: IoT devices, smart home and heating controllers, monitoring equipment, and the companion apps and portals that go with them.
- The duty covers raw and pre-processed data readily available on the device, plus metadata. Significantly enriched or inferred data sits outside it, and that boundary is where most product teams draw the line in the wrong place.
- Ireland has not enacted its Data Bill, and the obligation lands on 12 September regardless, because it attaches to placing on the market rather than to Irish commencement.
- A support ticket producing a CSV in three working days does not satisfy “by default”. An API, an on-device interface or a self-serve export does.
What changes, and what already applied
The Data Act has been live for a year. Since September 2025, data holders have had to make product and related service data available to the user on request under Article 4, and to nominated third parties under Article 5. Plenty of teams answered that with a process: a form, an inbox, someone in support who knows how to pull the export. That was a defensible reading of the obligation as it stood then.
Article 3(1) removes the request from the loop. Access has to be the default state of the product, not a workflow triggered by a user who knows to ask. That is the difference between being able to produce data and having designed for it to be reachable, and it is why this clause got an extra year of lead time. The trigger is placing on the market, so it is prospective: a product on sale on 11 September does not retroactively acquire the design duty, and one that goes on sale on the 13th does. If you have hardware or a connected service in a release window this autumn, the ship date is now a compliance fact.
You are probably in scope
The common misreading is that this is a story about cars and industrial machinery. A connected product under the Act is any item that obtains, generates or collects data about its use or environment and can communicate it. That takes in smart home and heating controllers, building management kit, access control, environmental and asset monitoring, EV chargers, and much of the commodity hardware that ends up wired into an automation platform. Related services are in scope alongside the hardware, so if the device is inert without the cloud service, both sit inside the obligation, and the compliance surface for many teams is the mobile app and the tenant portal rather than the board inside the enclosure. It applies irrespective of where the manufacturer is established.
The line most teams draw in the wrong place
The obligation reaches raw and pre-processed data readily available on the product, plus the metadata a user needs to interpret it. Data that has been through further processing or inference to produce significantly enriched output sits outside it, a carve-out that exists deliberately to protect the analytics layer manufacturers invest in.
The mistake we see is teams reading that generously in their own favour. A temperature series with timestamps and units is raw data with metadata, and it is in scope. Applying a calibration curve does not make it a proprietary analytic, and neither does resampling it, cleaning it or storing it in your own schema. What is genuinely out is the model output on top: the predictive maintenance score, the anomaly classification, the benchmark against a fleet. If your export carries only the enriched layer and not the underlying series, you have almost certainly withheld something you owed.
“Directly accessible” is an engineering artefact
The phrase “where relevant and technically feasible, directly accessible to the user” is doing real work. It contemplates the user reaching the data without the manufacturer standing in the middle: an on-device interface, an API with credentials the user controls, a self-serve export inside the product. Where that is genuinely not feasible, the data must still be available easily and free of charge, a lower bar but not an open one.
Two patterns fail. The first is the support ticket, where a human fulfils each request; it is neither by default nor free of friction. The second is the download button that produces something structured for humans instead of machines: machine-readable means JSON, CSV or a documented API response with metadata alongside it, not a spreadsheet whose column headers are the only documentation that exists. Two further requirements are missed most often: access has to be secure, meaning real authentication against a defined user identity rather than an unguessable URL, and free of charge, which rules out putting the export behind a paid tier.
Trade secrets need a documented position
The Act does allow a data holder to protect trade secrets, but the mechanism is narrow: identified secrets, agreed safeguards, and, in exceptional circumstances, a specific documented refusal that can be put in front of the competent authority. A general assertion that the data reflects commercially sensitive know-how is not enough.
Telemetry also rarely arrives cleanly separated. A shared device generates data about people who are not the requesting user, and the Data Act does not override the GDPR, so the lawful basis needs settling before you build the export. It is a schema problem: know which fields are personal, know whose, and design the export so the non-user portion can be filtered.
Ireland has not enacted this, and it does not move your date
The General Scheme of the Data Bill was published on 4 February 2026, running to 99 heads. It appoints ComReg and the Competition and Consumer Protection Commission as dual competent authorities, with the CCPC as Data Coordinator and single point of contact. It went through public consultation, closing in April, and has been prioritised for drafting. It is not law yet.
The temptation is to read that as breathing room. The Data Act is a Regulation, directly applicable, and the Article 3(1) trigger is placing a product on the EU market after 12 September 2026. Irish commencement determines who enforces and how quickly, not whether the obligation exists. The gap creates a compliance debt that accrues quietly and gets assessed later against whatever you shipped in the interim.
What the Scheme proposes is not trivial either: administrative fines of up to 4% of annual EU turnover; on indictment, individual penalties of up to €500,000 and ten years’ imprisonment; and, for data sharing infringements involving personal data, the Data Protection Commission applying GDPR Article 83 levels, the higher of €20 million or 4% of worldwide turnover. Those figures are proposals and may change in drafting, but nobody writing them thinks this is a paperwork regime. The same argument applied to NIS2 earlier this year: the enactment date is not the date your buyers and enterprise customers start asking.
What to do before the 12th
- Decide scope per product, in writing, with a name and a date. Is it a connected product? Is there a related service? What is the placing-on-the-market date for the next version?
- Inventory what the device and service hold, separating raw and pre-processed data from enriched and inferred output, field by field. Most teams have never drawn that line explicitly and are surprised by where it falls.
- Design the access path as a product feature. An authenticated API or a self-serve export, structured and machine-readable, with metadata and units documented. Budget it as engineering work, because it is.
- Write the pre-contract disclosures. Articles 3(2) and 3(3) require users to be told, before they buy or sign, what data the product generates, whether collection is continuous, how long it is retained, how to access and erase it, and who else may receive it.
- Name the trade secrets and safeguards if you intend to rely on the carve-out, and settle the GDPR basis for any non-user personal data in the same stream.
The pattern behind the deadline
This is the third piece of EU regulation in eighteen months to land as a specification rather than a principle, after the AI Act’s marking duties and the Cyber Resilience Act’s reporting clock. Each resolves to an API, a schema and a shipped feature, and the teams treating them as engineering work finish months ahead of those treating them as governance.
At REPTILEHAUS we build the connected product layer this lands on: device integrations, n8n and automation workflows, tenant portals, and the API and DevOps architecture underneath. If you have hardware or a connected service going to market this autumn and nobody has answered how a user gets their data out without emailing you, get in touch. It is a cheaper conversation before the 12th than after it.
📷 Photo by Arthur Lambillotte on Unsplash
