The EU Data Act's 12 September 2026 Access-by-design Deadline: What Connected-product Manufacturers Must Now Build In

The eu data acts 12 september 2026 deadline marks a fundamental shift in how connected products must be engineered, sold and contracted for across the European Union. Under Regulation (EU) 2023/2854, the Data Act, connected products and related services placed on the market from that date must be designed so that users can access the data those products generate, by design and by default. For manufacturers, importers, distributors, rental and lease businesses, related-service providers and their in-house counsel, this is no longer a future planning item: it is a live compliance obligation with technical, contractual and data-protection consequences.

This article sets out what the trigger date means in Ireland, what “access by design” actually requires you to build, and the practical steps to bring products and contracts into line.

What the 12 September 2026 trigger means, the statutory basis

The Data Act entered into force on 11 January 2024 and became generally applicable from 12 September 2025 under Article 50 of Regulation (EU) 2023/2854. However, the access-by-design obligation in Article 3(1) applies specifically to connected products and related services placed on the market after 12 September 2026. The eu data acts 12 september 2026 milestone is therefore the point at which the design-stage access rules bite for newly marketed products, while a request-based access regime governs products and services that are already available.

Statutory obligation in plain English

Article 3(1) requires that connected products, and the related services connected to them, be designed and manufactured so that product data and related-service data are, by default, easily, securely, and where relevant and technically feasible, directly accessible to the user. Where data cannot be directly accessed from the product, the data holder must make readily available data accessible to the user in a comprehensive, structured, commonly used and machine-readable format. In practice this means access cannot be an afterthought bolted on when a user asks; the capability must be considered in the product architecture from the point of design.

Who is captured, the “placed on the market” test

Scope turns on whether a product is “placed on the market” in the EU after the trigger date. This captures far more than EU-based manufacturers. An Irish distributor importing smart devices, a non-EU manufacturer selling into the single market, and a related-service provider can all fall within scope where their goods or services reach EU users. If your business makes a connected product available in the EU for the first time after the deadline, the access-by-design regime is capable of applying regardless of where the product was designed or assembled.

What “access by design” requires, the technical and product-architecture baseline

The heart of the eu data acts 12 september 2026 obligations is engineering, not paperwork. Article 3(1) sets a baseline that product teams must satisfy: default availability of data, secure access, and, where readily available data is provided by the data holder, a comprehensive, structured, commonly used and machine-readable format, with direct access from the product where technically feasible. Understanding what each of those elements means in practice is essential to a defensible compliance posture.

Data types you must expose

The Data Act reaches “product data” and “related-service data”, broadly, the data generated by the use of the connected product and the associated digital service. In real deployments this can cover:

• Telemetry. Real-time and near-real-time operational signals, such as sensor readings, GPS position from a telematics unit, or temperature logs from a smart appliance.
• Usage data. How, when and how often a product is used, cycle counts, run hours, activation records.
• Diagnostics. Fault codes, error logs, wear indicators and maintenance-relevant readings.
• Metadata. The contextual data needed to interpret the raw values, units, timestamps, device identifiers, schema descriptions and calibration references.

Metadata deserves particular attention. The Data Act expressly requires that the relevant metadata necessary to interpret and use the data accompany access. Access to raw telemetry that a user cannot interpret does not meet that standard: if your industrial sensor emits numeric arrays without units, timestamps or a schema, you have not made the data usable within the meaning of Article 3.

Formats and interoperability

The regulation requires a “structured, commonly used and machine-readable” format. In engineering terms, that points to widely adopted, non-proprietary structures such as CSV, JSON and XML, ideally aligned to a documented, stable schema. Proprietary binary formats that require the manufacturer’s own tooling to decode will generally fall short. Where common schemas or interoperability standards exist for a product category, for example in telematics or building automation, aligning to them reduces both compliance risk and integration friction for users and third parties. The Data Act also contains dedicated interoperability provisions (Chapter VIII) that are relevant here.

Security and authentication

Access must be secure. Exposing product data cannot open a new attack surface. ENISA’s baseline security recommendations for IoT provide a useful reference frame: strong authentication of the user requesting access, least-privilege authorisation, encryption of data in transit, secure API design, logging and monitoring, and secure credential management. A compliant access mechanism authenticates who is asking, confirms they are entitled to the data, and delivers it over a protected channel. Security-by-design and access-by-design are complementary, not competing, objectives.

When “direct access” is technically feasible

Article 3(1) frames direct access as applying where relevant and technically feasible. A connected car with an onboard data port or an in-vehicle interface may support direct access through that hardware. A low-power sensor that only communicates through a manufacturer cloud may not support meaningful on-device access; in that case, access via the data holder’s interface or API is the appropriate route. The feasibility assessment must be genuine and documented, it is not a general escape hatch, and regulators are likely to expect manufacturers to justify why direct access from the product was not provided.

Access-by-design vs request-based access under the eu data acts 12 september 2026 regime

One of the most common points of confusion is the relationship between the two access routes. Products already on the market before the deadline remain subject to the request-based access regime, whereas products placed on the market afterwards must additionally satisfy the design-stage access-by-design standard. The table below summarises the practical differences.

Implementation impact on product QA and lifecycle

The practical consequence is that access-by-design should enter your product development lifecycle as a functional requirement. Access capability, format conformity and metadata completeness become items on the QA checklist, tested before release in the same way you test safety or connectivity. Retrofitting access after launch is far costlier and riskier than designing it in, which is precisely why the eu data acts 12 september 2026 framework focuses on the point of manufacture.

Pre-contract disclosure duties under Article 3

Beyond the engineering obligations, the Data Act imposes information duties that fall on sellers, lessors, renters and related-service providers. Before a user is bound by a contract for a connected product or related service, they must be told, in a clear and comprehensible manner, what data the product generates and how they can get at it. These disclosures cannot be buried in dense technical annexes; they must be genuinely accessible to the person deciding whether to buy, rent or subscribe.

What must be disclosed

The pre-contract information duties centre on giving the prospective user a realistic picture of the data and access arrangements. In practice, disclosure should cover:

• Data types and format. The type, format and estimated volume of product data the product is capable of generating.
• Generation pattern. Whether the product is capable of generating data continuously, in real time, or intermittently.
• Storage and retention. Whether the product is capable of storing data on-device or on a remote server, and, where relevant, the intended retention approach.
• Access and retrieval. How the user can access, retrieve or, where applicable, erase the data, including APIs, ports or physical interfaces.
• Data holder identity and use. The identity of the data holder and how the user can request that data be shared with a third party.

Disclosure timing and format

The information must be provided before the contract is concluded, so it can inform the purchasing decision. That means updating product documentation, online sales flows, quotations and pre-contract packs so the required particulars are presented up front rather than after commitment.

Sales, rental, lease and service contracts

The disclosure duty is not confined to outright sales. A business that rents or leases connected equipment, or that provides a related service, carries equivalent obligations. A plant-hire company leasing telematics-equipped machinery, a subscription provider for a smart building system, and a retailer selling a connected appliance all owe pre-contract disclosures. The precise recipient and phrasing may differ, but the substance, telling the user what data exists and how to access it, remains constant across contract types.

GDPR interaction, personal data belonging to third parties

The Data Act does not displace the GDPR. Where product data includes personal data, and connected-product data very often does, Regulation (EU) 2016/679 continues to apply in full, and the Data Act itself confirms that in the event of conflict the GDPR prevails. The interaction becomes especially delicate where the data concerns persons other than the user requesting access, because granting access to one person may involve disclosing another person’s personal data.

Scenarios where the tension bites

Consider vehicle telematics that capture location data, which may reveal the movements of passengers or other drivers. Consider audio or video sensors in a connected home that capture the images or voices of visitors and household members. In these cases, the user’s Data Act access right must be reconciled with the data-protection rights of third parties whose personal data is caught in the same dataset.

Practical steps

A defensible approach begins with a clear legal-role analysis. Determine whether your organisation is acting as controller or processor for each processing operation, because the eu data acts 12 september 2026 access flows can change those roles. Then apply core GDPR principles, lawful basis, purpose limitation and data minimisation, to the access mechanism itself. Where a request would expose third-party personal data, options include anonymisation, aggregation or redaction so that access is provided without unlawful disclosure. A Data Protection Impact Assessment is required where processing is likely to result in a high risk to individuals, such as systematic monitoring or processing of special categories of data, and the Irish Data Protection Commission’s guidance on DPIAs should inform that exercise.

Contractual safeguards between manufacturers, service providers and users should allocate data-protection responsibilities clearly.

Trade secrets, IP and confidentiality limits

Manufacturers frequently ask whether trade secrets can be used to withhold data. The answer is nuanced. The Data Act recognises the protection of trade secrets, understood by reference to Directive (EU) 2016/943, but it does not treat a bare assertion of confidentiality as a blanket right to refuse. As a general matter access is the default; the regime provides that data holders and users must agree the technical and organisational measures needed to preserve confidentiality, and only in exceptional, justified circumstances may a data holder withhold or suspend sharing of specifically identified trade-secret data.

Practical redaction and protection strategies

Rather than refusing access outright, the more sustainable strategy is to protect genuine trade secrets through targeted technical and contractual measures. That may mean redacting or aggregating the specific elements that constitute a trade secret while releasing the remaining product data, or making access conditional on proportionate confidentiality undertakings. The aim is to satisfy the user’s access right while preserving legitimately protectable information.

Dispute and notice process

Where a manufacturer relies on trade-secret grounds, it should identify precisely which data elements are affected, document the basis for the position, notify the user (and, where required, the competent authority), and be prepared to demonstrate that the measures taken are proportionate. A clear internal notice and escalation process reduces the risk that a defensible confidentiality claim is undermined by an inconsistent or unexplained refusal.

SMEs and microenterprise carve-outs, when small manufacturers are still caught

The Data Act contains carve-outs intended to relieve the smallest businesses of certain data-access obligations. In particular, the data-access and sharing obligations in Chapters II and III do not generally apply to enterprises that qualify as micro or small enterprises where they act as data holders, but these exemptions are narrower than many assume, and a small manufacturer can still be caught, including through the supply chain.

Practical tests for SME status

Assessing whether an exemption applies requires an honest look at enterprise size, using the EU definition of micro, small and medium-sized enterprises (Commission Recommendation 2003/361/EC), including whether the business forms part of a larger group. Headcount and turnover/balance-sheet thresholds determine status, and partner or linked-enterprise relationships can pull an apparently small entity into a larger classification. The exemption analysis must therefore consider ownership and control, not just the standalone company’s figures.

Indirect capture and record-keeping

Even where a manufacturer qualifies for relief, obligations can attach elsewhere in the chain. The exemption can also fall away in certain circumstances, for example where a micro or small enterprise is a subcontractor of a larger enterprise. In practice this means small enterprises should still map their products, understand where in the chain the access obligations land, and keep records adequate to demonstrate their status and their compliance approach. Under the eu data acts 12 september 2026 framework, assuming an exemption without verifying it is a significant risk.

Practical compliance audit, product scoping, data mapping and engineering tasks

With the deadline approaching or passed, the priority is a structured audit that converts the legal obligations into concrete engineering and documentation tasks. The following sequence gives manufacturers a defensible path.

1. Product scoping. Identify which SKUs are connected products or related services, and separate those already on the market from those placed on the market after the trigger date.
2. Data inventory. For each in-scope product, catalogue the product data and related-service data generated, telemetry, usage, diagnostics and metadata.
3. Data flow mapping. Trace where each dataset is captured, transmitted, stored and processed, and identify where personal data or third-party data enters the flow.
4. Metadata catalogue. Document the schema, units, timestamps and identifiers needed to make each dataset interpretable.
5. API and interface readiness. Assess whether existing APIs, ports or physical interfaces can deliver default, secure, machine-readable access, and specify the gaps.
6. Security test plan. Align access mechanisms with recognised IoT security practices, covering authentication, authorisation, encryption and logging.
7. Developer tickets and costing. Convert the gaps into an engineering backlog with owners, estimates and timelines.

Sample data map template

A workable data map lists, for each product: dataset name, data type, format, generation frequency, storage location, retention period, whether it contains personal data, access method and metadata reference. This single artefact supports both the technical build and the pre-contract disclosure obligations, because it captures precisely the particulars users must be told.

Timeline and resource estimate

Where products are already non-compliant, remediation typically requires cross-functional effort spanning product engineering, security, legal and commercial teams. Prioritise the highest-volume and highest-risk SKUs, and treat access capability as a release-blocking requirement for any new product launched into the EU market.

Contracts and commercial remediation, updating supply and distribution agreements

Compliance is not only an engineering exercise; it must be reflected in the contracts that move products through the supply chain. Manufacturers, importers and distributors should revisit their supply and distribution agreements to allocate the new obligations and risks clearly. Key items to address include compliance warranties, indemnities, disclosure obligations, API service levels, liability allocation, trade-secret handling, audit rights and change-control mechanisms. Note that the Data Act also restricts unfair contractual terms unilaterally imposed on micro, small and medium-sized enterprises in relation to data access and use, which is relevant when drafting these clauses.

Sample clause drafts

• Disclosure clause. “The Supplier shall provide to the Distributor, in a clear and comprehensible form, all information required to satisfy the pre-contract disclosure obligations under Article 3 of Regulation (EU) 2023/2854 in respect of each connected product supplied, including the type, format and estimated volume of data, whether data is generated continuously or in real time, storage location and access mechanisms.”
• Compliance warranty. “The Supplier warrants that each connected product placed on the market after 12 September 2026 is designed and manufactured so that product data and related-service data are, by default, easily and securely accessible to the user, free of charge, and, where the data holder makes readily available data accessible, provided in a structured, commonly used and machine-readable format, in accordance with Article 3(1) of Regulation (EU) 2023/2854.”
• Confidentiality and trade-secret protection. “Where product data includes trade secrets within the meaning of Directive (EU) 2016/943, the parties shall agree and implement proportionate technical and organisational measures, including redaction, aggregation and confidentiality undertakings, to enable lawful user access while preserving such trade secrets.”

Negotiation tips with distributors and importers

Where you place products on the EU market as an importer, insist on back-to-back compliance warranties and disclosure support from upstream manufacturers, because the market-facing obligations may rest with you. Conversely, manufacturers should ensure indemnities are proportionate and tied to demonstrable breach rather than open-ended commercial risk. Clear audit rights and change-control provisions keep the arrangement workable as interpretive guidance evolves.

Enforcement, penalties and dispute handling

Enforcement of the Data Act falls to competent authorities designated by each Member State, working alongside data-protection and market-surveillance structures. Ireland must designate one or more competent authorities and provide for penalties that are effective, proportionate and dissuasive; readers should confirm the current Irish designation and any implementing measures before relying on specific enforcement details. Non-compliance exposes businesses to regulatory action and to civil litigation risk from users or third parties denied their access rights. Because the eu data acts 12 september 2026 obligations apply to newly marketed products, authorities can act against products and disclosures that fall short.

Practical dispute-handling steps

Businesses should establish a clear internal process for handling access requests and disputes: log the request, verify the requester’s entitlement, assess any data-protection or trade-secret considerations, respond within a reasonable time, and document the decision. The Data Act also provides for dispute-settlement mechanisms and the possibility of complaints to competent authorities. A consistent, well-evidenced process is the strongest protection against both regulatory criticism and civil claims.

Conclusion and next steps

The eu data acts 12 september 2026 access-by-design regime changes the baseline for connected products newly entering the EU market, and Irish manufacturers, importers and their counsel should act on it rather than treat it as a distant planning item. In the first 30 days, identify which SKUs are in scope and begin a data inventory. Within 60 days, map data flows, catalogue metadata and assess API and security readiness. Within 90 days, close the highest-priority engineering gaps, update pre-contract disclosures, and remediate supply and distribution contracts. For an Ireland-specific review of your products, disclosures and agreements against the Data Act, seek tailored legal advice before your next product launch or contract cycle.

You may also find our Information Technology Lawyer Ireland, practical guide a useful starting point.

Sources

1. Regulation (EU) 2023/2854 (Data Act), official text (EUR-Lex)
2. European Commission, Data Act policy page
3. Regulation (EU) 2016/679 (GDPR), official text (EUR-Lex)
4. Directive (EU) 2016/943 on the protection of trade secrets (EUR-Lex)
5. Data Protection Commission (Ireland)
6. ENISA, Baseline Security Recommendations for IoT
7. European Data Protection Board (EDPB)