EU Data Act 12 September 2026 Deadline: Article 3(1) Data Access by Design

Last verified: 4 September 2026

The next major EU Data Act date is 12 September 2026.

But the deadline is frequently described incorrectly.

The EU Data Act as a whole does not start on 12 September 2026. Regulation (EU) 2023/2854 has applied generally since 12 September 2025.

What changes after 12 September 2026 is the application of the specific Article 3(1) design obligation to connected products and related services within the Article 50 transition rule.

Article 3(1) requires connected products to be designed and manufactured, and related services designed and provided, so that relevant Product Data and Related Service Data — together with the metadata needed to interpret and use those data — are by default:

• easily accessible;
• securely accessible;
• free of charge;
• comprehensive;
• structured;
• commonly used;
• machine-readable;
• and, where relevant and technically feasible, directly accessible to the user.

This is not primarily a documentation deadline.

It is a product architecture deadline.

If a connected product is being placed on the EU market after the transition date, Product Compliance cannot solve Article 3(1) at the last minute by publishing another legal page. Engineering, firmware, cloud and product architecture need to understand how the user gets the data.

This guide explains exactly what changes, what does not change, what “data access by design” means in practical terms, and what product teams should verify now.

Article 3(2) is different. The Product Data Notice / pre-contractual information workflow has already been relevant under the Data Act's general application from September 2025. See the Product Data Notice Guide.

Important: This guide is informational, not legal advice. Product scope, Article 7, sector-specific law and the actual placing-on-market facts can affect the result.

Quick answer: what happens on 12 September 2026?

Article 50 of the Data Act states that the obligation resulting from Article 3(1) applies to connected products and the services related to them placed on the market after 12 September 2026.

The Regulation itself generally applies from 12 September 2025.

Official legal source:

Regulation (EU) 2023/2854 — Article 50 and Article 3

That means the 2026 milestone should be understood as:

new product/service design/accessibility transition

not:

first day of EU Data Act compliance

The timeline manufacturers should use

11 January 2024

The Data Act entered into force.

12 September 2025

The Regulation generally became applicable.

This includes major Chapter II user/data-sharing rules and the Article 3 pre-contractual information framework, subject to scope and transitional provisions.

After 12 September 2026

Article 3(1)'s design obligation applies under Article 50 to connected products and related services falling within that transition wording.

12 September 2027

Chapter IV unfair-contract-term rules extend to certain older contracts under Article 50's legacy-contract conditions.

The point:

Do not manage the Data Act as one deadline.

Use an obligation-by-obligation calendar.

The European Commission's current Data Act page confirms the general 12 September 2025 application date and continues to publish implementation support.

See:

European Commission — Data Act

Article 3(1): the actual requirement

Article 3(1) states, in substance, that connected products shall be designed/manufactured and related services designed/provided so Product Data and Related Service Data, including relevant metadata necessary to interpret/use them, are by default available:

• easily;
• securely;
• free of charge;
• comprehensively;
• in structured, commonly used, machine-readable format;
• and, where relevant/technically feasible, directly accessible to the user.

This creates several separate engineering questions.

A product can fail the spirit of the requirement even if it has a technically obscure export hidden behind support tickets.

Conversely, the Data Act does not say every product must expose every internal signal or create a public unauthenticated API.

The product architecture needs a defensible access model.

1. “By default” means access cannot be an afterthought

“By default” changes product requirements.

The team should be able to answer during design:

• Which Product Data will the user access?
• Which Related Service Data will the user access?
• What metadata are needed?
• How does the user authenticate?
• What interface provides access?
• Is access direct or through the data holder?
• What format is delivered?
• What security boundaries apply?
• What happens when the product is offline?
• What happens after firmware/service updates?

Do not leave:

“Data export TBD”

in the product spec until after launch.

2. “Easily” accessible: reduce unnecessary friction

The Data Act is intended to make connected-product data usable.

An access process that requires:

• repeated support escalation;
• undocumented proprietary tools;
• manual engineering extraction;
• unclear account ownership;

can create implementation problems.

An easy route might be:

• product UI;
• app;
• web portal;
• documented API;
• standard file export;
• clear request process where indirect access applies.

The exact architecture depends on the product.

“Easy” does not mean “public without authentication.”

Security remains part of the requirement.

3. “Securely” accessible: access control still matters

A product-data access feature must not create a security/privacy vulnerability.

Product teams should define:

• user authentication;
• organisation/admin roles;
• device ownership/assignment;
• authorization;
• API tokens;
• rate limits where appropriate;
• transport encryption;
• sensitive field separation;
• logging/auditability where appropriate.

The requirement to provide access does not mean:

anyone who knows a serial number gets the data.

This matters especially for:

• connected cameras;
• locks/access systems;
• vehicles;
• health devices;
• industrial equipment;
• multi-user enterprise products.

4. “Free of charge” for user access

Article 3(1) includes free-of-charge accessibility.

Article 4's user-access framework also emphasizes user access without charge under the relevant conditions.

Product teams should not design the normal user data-access interface as a paid export add-on solely for Data Act access.

This is separate from the Regulation's rules on compensation when data are made available to certain third-party data recipients.

Do not confuse:

user gets own relevant data

with:

third-party data recipient compensation rules.

5. Comprehensive, structured, commonly used and machine-readable

This is a major engineering requirement.

A PDF screenshot of telemetry is not a strong default machine-readable architecture.

Possible structured formats include, depending on the data:

• JSON;
• CSV;
• XML;
• standardised industry formats;
• documented binary/structured formats;
• API representations.

The Data Act does not prescribe one universal format for every connected product.

The key questions are:

• Can software parse the data?
• Is the structure understandable?
• Is the format actually used/documented?
• Can the user meaningfully reuse it?
• Are units/timestamps/identifiers clear?

A file called:

export_final_2.dat

with no schema/documentation may technically contain data but still be operationally poor.

6. Metadata necessary to interpret and use the data

This is often missed.

Article 3(1) explicitly includes relevant metadata necessary to interpret and use Product Data/Related Service Data.

Depending on the dataset, useful metadata can include:

• timestamp/time zone;
• unit of measurement;
• sensor/channel ID;
• product/device ID;
• event type;
• quality/status flag;
• field description;
• schema version;
• coordinate system;
• sampling interval;
• error-code dictionary;
• enum/code list.

Example

Weak export:

20260904T131500,42.6

Better:

timestamp_utc: 2026-09-04T13:15:00Z
metric: temperature
value: 42.6
unit: C
sensor_id: temp_1
quality: valid

The exact schema varies, but the second is meaningfully interpretable.

7. Direct access — where relevant and technically feasible

Article 3(1) qualifies direct access with:

where relevant and technically feasible.

That means the direct-access obligation is not worded as an absolute universal requirement for every dataset/product.

Connected products can support direct access through:

• on-device storage;
• local wired/wireless interface;
• product/app interface;
• remote server/account architecture where the user can access without a separate data-holder extraction step.

Where the user cannot directly access relevant data, Article 4 contains the data-holder access mechanism for readily available data.

Product teams should therefore define:

Direct-access data

User gets them through the product/service architecture.

Indirect-access data

User needs the data holder to make them available.

Then ensure pre-contractual information explains the access path.

Direct vs indirect access: do not treat them as competitors

A sophisticated product can use both.

Example:

Direct

• current sensor readings via local API;
• recent device history via app export.

Indirect

• large historical cloud dataset;
• service records retained in backend systems.

The architecture should map data categories to their access route.

This improves:

• Article 3(1) design review;
• Article 3(2) Product Data Notice;
• Article 4 request handling;
• marketplace/product documentation.

Does Article 3(1) require manufacturers to store every generated signal?

No.

The Data Act recitals make clear that “readily available” concepts and design obligations should not be interpreted as a universal requirement to store every internal/transient datum outside the component/product.

The Regulation also preserves GDPR data minimisation.

This matters because a bad compliance response would be:

“We should start collecting and retaining every sensor signal indefinitely just in case.”

That can create:

• privacy risk;
• security risk;
• storage cost;
• product complexity.

Instead, define the data the product architecture actually generates/retrieves and the obligations that apply.

Does Article 3(1) force collection of more personal data?

No.

The Data Act does not displace GDPR's data-minimisation principle.

Where Product Data are personal data, product architecture should still collect/process only what is appropriate for legitimate purposes.

Article 3(1) is about accessibility of relevant data, not creating unnecessary surveillance.

See:

EU Data Act vs GDPR for Connected Products

What does “placed on the market” mean?

The Data Act defines “placing on the market” as the first making available of a connected product on the Union market.

This makes launch/product-version timing important.

A manufacturer should identify:

• which product/model is being placed on the EU market;
• when;
• whether it is a new model/version;
• which related service is supplied;
• which Article 50 transition applies.

Do not equate:

manufactured before 12 September

with:

placed on the market before 12 September.

Supply-chain/product-law concepts can require legal review.

Existing products: what the 2026 date does NOT mean

A common overstatement is:

“Products sold before 12 September 2026 are exempt from the Data Act.”

That is wrong.

The 2026 transition relates specifically to the Article 3(1) obligation.

Other Data Act provisions already apply under their own timing/scope rules.

For example:

• Article 3(2) pre-contract information;
• Article 4 user access via data holder;
• Article 5 third-party sharing;
• other Chapter II obligations;

are not simply erased because the product was placed earlier.

Therefore maintain two separate questions:

Design-transition question

Is Article 3(1) applicable to this product/service under Article 50?

Current Data Act question

Which other obligations apply now?

Article 3(1) vs Article 3(2)

This distinction should be in every product compliance plan.

Article 3(1)

Product/service design

Questions:

• Is the data accessible by design?
• Format?
• Metadata?
• Direct access?
• Security?

Article 3(2)

Pre-contractual information

Questions:

• What data can the product generate?
• Format?
• Estimated volume?
• Continuous/real-time?
• Storage/retention?
• How does user access/retrieve/erase?
• Terms/QoS?

The Product Data Notice describes the access architecture, but publishing the notice does not itself satisfy the design obligation.

Article 3(1) vs Article 4

Article 4 becomes important where the user cannot directly access data from the connected product/related service.

The data holder must make readily available data and necessary metadata available under the conditions in Article 4.

So product architecture should not stop at:

direct access unavailable.

It should say:

direct access unavailable for these categories; indirect data-holder access is provided through this process.

This mapping should be explicit.

A manufacturer readiness architecture

For each product family, create a table:

This becomes the engineering source for:

• Article 3(1);
• Product Data Notice;
• Article 4;
• API/export design.

Product requirements checklist for Article 3(1)

Data scope

• Product Data categories inventoried.
• Related Service Data inventoried.
• Data not intended to be accessible identified/reasoned.
• Metadata requirements identified.

Format

• Structured format selected.
• Machine-readable output verified.
• Schema documented.
• Units/enums/codes documented.
• Schema versioning defined.

Access

• Direct access assessed per category.
• Technical feasibility documented.
• Indirect access route identified where needed.
• User interface/API/export defined.

Security

• Authentication defined.
• Authorization/roles defined.
• Device ownership/assignment handled.
• Transport security defined.
• Sensitive data handled appropriately.

Cost

• Normal user access does not require a Data Act access fee.

Related service

• Service data included.
• Service provider/data holder identified.
• Product/service contracts aligned.

Privacy

• Personal-data status reviewed.
• GDPR data minimisation preserved.
• Data subjects/users distinguished.
• Privacy notice/access controls aligned.

Documentation

• Article 3(2) notice matches the real access architecture.
• User documentation explains access.
• API/export docs exist.
• Support team knows indirect route.

Release

• Placing-on-market date documented.
• Article 50 applicability reviewed.
• Product Compliance sign-off included in release gate.

Engineering release gate

A useful release checklist can ask:

Data map complete?

Yes / No

User-readable schema available?

Yes / No

Machine-readable export/API tested?

Yes / No

Required metadata included?

Yes / No

Direct access decision documented?

Yes / No

Indirect access route tested?

Yes / No

Security test complete?

Yes / No

Product Data Notice matches production?

Yes / No

GDPR/privacy review complete?

Yes / No

Support/data-request owner assigned?

Yes / No

This makes Article 3(1) part of product delivery rather than a legal memo.

Example: environmental sensor

Fictional product:

AirSense 300

Data:

• temperature;
• humidity;
• PM2.5;
• device diagnostics.

Strong design

User can:

• retrieve current/recent sensor values through local API;
• export history from web portal;
• receive JSON/CSV;
• interpret timestamps/units using documented schema.

Diagnostics not directly exposed:

• available through authenticated request/export process.

Product Data Notice describes both.

This is the kind of architecture Article 3 encourages.

Example: industrial equipment with proprietary binary format

The machine stores data in a proprietary binary file.

Questions:

• Is the format comprehensive/structured/machine-readable?
• Can users interpret it?
• Is metadata/schema/documentation available?
• Could a commonly used structured export be provided?
• Is conversion technically feasible?

Do not assume “machine-readable” means “human can open file in Notepad.”

A technically parseable but undocumented format can still create usability questions.

Example: cloud-dependent related service

The connected product relies on a cloud service.

Service data include:

• user schedules;
• remote commands;
• cloud configuration;
• events.

Article 3(1) is not only a hardware firmware question.

The related service must also be designed/provided with the relevant data-access architecture.

This brings:

• backend;
• identity;
• API;
• data export;
• retention;
• privacy;

into the release process.

Existing pipeline products: what to do eight days before the date

As of this article's publication, 12 September 2026 is imminent.

For products already in late-stage development:

1. Do not panic-add a fake export

Identify the real architecture first.

2. Run a product-family triage

Classify:

• launch date;
• placing-on-market status;
• data categories;
• existing access mechanisms;
• gaps.

3. Document direct/indirect access

Even if architecture changes cannot be made overnight, understand the actual state.

4. Align Product Data Notice

Do not let marketing/legal documentation promise access that engineering does not support.

5. Escalate legal uncertainty

Use counsel and, where useful, the Commission's Data Act Legal Helpdesk.

See:

European Commission — Data Act Legal Helpdesk

Common Article 3(1) mistakes

Mistake 1: “The Data Act starts on 12 September 2026”

It generally applied from 12 September 2025.

Mistake 2: treating it as a notice deadline

Article 3(1) is a design requirement.

Mistake 3: “Everything must be directly accessible”

Direct access is qualified by relevance and technical feasibility.

Mistake 4: “If direct access is not available, we're done”

Article 4 indirect/data-holder access still matters.

Mistake 5: “CSV is mandatory”

No universal single format is mandated. The legal qualities are structured, commonly used, machine-readable, etc.

Mistake 6: forgetting metadata

Article 3(1) explicitly includes relevant metadata needed to interpret/use data.

Mistake 7: exposing data without authentication

Security is part of the requirement.

Mistake 8: creating extra personal-data retention

Data minimisation still applies.

Mistake 9: assuming existing products have no Data Act obligations

The Article 3(1) transition does not remove other obligations.

Mistake 10: confusing manufactured date with placing-on-market date

Review the actual product-law timing.

Mistake 11: designing hardware but ignoring the related service

Article 3(1) covers both.

Mistake 12: letting the Product Data Notice contradict the actual system

Documentation and implementation should match.

Digital Omnibus: has it cancelled the 2026 deadline?

As of 4 September 2026, the Commission's Digital Omnibus proposal, COM(2025) 837, remains in an ongoing ordinary legislative procedure.

The proposal would amend parts of the Data Act and other EU digital legislation, but a proposal is not current law simply because it has been published.

Manufacturers should therefore implement the Data Act currently in force unless and until adopted legislation changes the applicable rule.

Current proposal/procedure:

• Digital Omnibus proposal — EUR-Lex
• Procedure 2025/0360/COD

Do not base a September product launch on an assumption that pending legislation will remove an obligation.

How RegCatalog fits the 2026 design requirement

RegCatalog does not design the product's firmware or API.

Its role is documentation/product-data structure.

The generator can help teams record:

• Product Data categories;
• format;
• estimated volume;
• real-time/continuous behavior;
• storage;
• access/retrieval;
• technical means;
• terms/QoS.

That information is useful for Article 3(2) and also exposes design gaps:

“We say users can access data — but through what technical route?”

Use:

Free EU Data Act Product Data Notice Generator

For a copyable template:

EU Data Act Product Data Notice Template

Frequently asked questions

Does the EU Data Act start on 12 September 2026?

No. The Data Act generally applies from 12 September 2025. The 2026 date is the Article 3(1) design-obligation transition under Article 50.

What does Article 3(1) require?

Connected products and related services must be designed/provided so relevant Product Data/Related Service Data and necessary metadata are by default easily, securely and freely accessible in comprehensive, structured, commonly used, machine-readable format, with direct access where relevant and technically feasible.

Which products are affected by the 2026 transition?

Article 50 ties the Article 3(1) obligation to connected products and services related to them placed on the market after 12 September 2026. Product-specific transition analysis may require legal review.

Are existing products exempt from the whole Data Act?

No. The 2026 transition is specific to Article 3(1). Other Data Act obligations have their own application/scope rules.

Is direct access always mandatory?

Article 3(1) qualifies direct access with “where relevant and technically feasible.” Where the user cannot directly access data, Article 4's data-holder access mechanism matters.

What is machine-readable data?

Data in a format software can process systematically. The Data Act does not prescribe one universal file type for every product.

Is JSON required?

No. JSON can be a practical format but is not a universal mandatory format.

Do manufacturers need to provide metadata?

Article 3(1) includes relevant metadata necessary to interpret and use the data.

Can manufacturers charge users for access?

Article 3(1) specifies free-of-charge accessibility; Article 4 also provides user access without charge under its conditions.

Does the deadline require a public API?

Not necessarily. The appropriate access method depends on relevance/technical feasibility/product architecture. A public unauthenticated API is not a requirement.

Does Article 3(1) require storage of all sensor data?

No. The Data Act should not be interpreted as requiring storage/collection of every internal signal, and GDPR data minimisation remains relevant.

Do related services also need design changes?

Potentially yes. Article 3(1) expressly addresses related services as well as connected products.

Is the Product Data Notice enough to satisfy Article 3(1)?

No. A notice documents information. Article 3(1) is a product/service design obligation.

Has the Digital Omnibus removed the deadline?

As of 4 September 2026, the relevant proposal remains in the legislative process. Apply current law unless adopted amendments change it.

Primary sources and current guidance

1. Regulation (EU) 2023/2854 — EU Data Act
2. European Commission — Data Act
3. European Commission — Data Act explained
4. European Commission — Data Act implementation FAQs
5. European Commission — Data Act Legal Helpdesk
6. Digital Omnibus proposal COM(2025) 837
7. Digital Omnibus procedure 2025/0360/COD

Useful implementation commentary

1. KPMG Law — EU Data Act upcoming deadlines 2026–2027

RegCatalog provides informational product-data tooling, not legal advice or product conformity certification. Article 3(1) implementation depends on the actual connected product, related service, data architecture and placing-on-market facts.