EU Data Act 2026: Product Data Requirements for Connected Products

Article 3 of the EU Data Act changes how manufacturers and providers must plan access to data from connected products and related services. For products placed on the EU market after 12 September 2026, the Article 3(1) design obligation makes data access an architecture concern, not just a response to an individual request.

The central requirement is that product data and related-service data—including the relevant metadata needed to interpret and use it—must, by default, be easy and secure for the user to access, free of charge, in a comprehensive, structured, commonly used and machine-readable format. Direct access is required where it is relevant and technically feasible.

The 12 September 2026 milestone

The Data Act generally became applicable on 12 September 2025. Article 50 sets a later date for the design duty in Article 3(1): it applies to connected products and the services related to them that are placed on the market after 12 September 2026.

That distinction matters. The milestone is not a general one-year postponement of the Regulation, and it is not simply a deadline to publish a data-export file. It affects the design of in-scope products and services so that the required data and interpretive metadata can be accessed under the conditions in Article 3(1).

What counts as a connected product?

The Regulation defines a connected product around what it does: it obtains, generates or collects data about its use, performance or environment and can communicate product data through an electronic communications service, physical connection or on-device access. Its primary function is not storing, processing or transmitting data on behalf of another party.

Depending on the facts, examples may include industrial machinery, connected HVAC equipment, vehicles, medical and health devices, home appliances or energy equipment. A related service is a digital service connected to the product in a way that affects its functions or is later connected to add, update or adapt functions.

Scope should be assessed product by product. A network connection alone does not replace the definition, and calling something “IoT” does not settle the legal analysis.

What Article 3 requires

1. Design accessible data and metadata into the product or service

Article 3(1) identifies several qualities for the data-access design:

• Data is available to the user by default and free of charge.
• Access is easy and secure.
• The output is comprehensive, structured, commonly used and machine-readable.
• Relevant metadata needed to interpret and use the data travels with it.
• The user can access data directly where relevant and technically feasible.

“Machine-readable” is more than downloadable. A CSV, JSON or API response can still be unusable if fields have unstable names, units are missing, timestamps have no timezone, status codes lack definitions, or records cannot be tied to an asset.

2. Give information before the contract is concluded

Article 3(2) requires the seller, renter or lessor to provide specified information clearly and comprehensibly before a user enters a contract for a connected product. That includes matters such as:

• the nature, estimated volume and collection frequency of product data;
• whether data is generated continuously and in real time;
• how long data is retained and whether it is stored on-device or on a remote server;
• how the user can access, retrieve or, where relevant, erase data, including the technical means and terms of use; and
• how the user can request sharing with a third party.

For a related service, Article 3(3) sets out a separate pre-contract information list. Among other matters, it covers the prospective data holder’s identity, the nature and estimated volume of data to be obtained, the intended uses of readily available data, retention duration, sharing with third parties and the user’s options when the service contract ends.

Do not let the disclosure exercise become separate from engineering reality. Product, service, legal and data teams should derive the disclosure from the same inventory that controls actual collection, retention and access.

3. Preserve the context needed to use each observation

Consider an export containing:

timestamp = 2026-09-12T14:03:28Z
temperature = 72
runtime = 4182
error = E42

The values are syntactically structured, but key questions remain. Is the temperature Celsius or Fahrenheit? Is runtime measured in hours? Which firmware defines E42? Which physical unit sent the event? Which model and variant determine the valid operating range?

A useful record may therefore need:

This is the product-identity connection: product-generated data only becomes operationally useful when it can be linked to the correct product, model, variant and installed asset.

A practical readiness model

1. Inventory connected products and related services. Record market-placement plans, connectivity, data-generation behavior, access paths, service relationships and owners. Flag assumptions for legal review rather than treating every connected device as automatically in or out of scope.

2. Catalog retrievable data. For each model and service version, list the data the manufacturer designed to be retrievable. Capture source, field definition, format, unit, frequency, estimated volume, retention and whether access can be direct.

3. Build the identity chain. Relate manufacturer, model, variant and configuration to each serialised installed asset. Preserve identifiers from manufacturing, sales, installation and service systems rather than forcing one identifier to do every job.

4. Version the interpretive metadata. Maintain schemas, code lists, units, timestamp conventions and firmware-specific meanings. An error-code dictionary updated in place can make historical events impossible to interpret correctly.

5. Test a real user export. Retrieve data through the intended mechanism, validate it against the published schema and confirm that an independent team can identify the asset and interpret the observations without private tribal knowledge.

6. Add governance and safeguards. Define authorization, authentication, personal-data handling, security controls, trade-secret review, retention and third-party sharing workflows with the appropriate specialists.

The role of a product identity layer

Claro is not an EU Data Act legal platform, an IoT telemetry platform or a system for deciding legal scope. Its relevant role is narrower: resolving inconsistent supplier and internal identifiers into trusted relationships among the product, model and variant records that operational systems use.

That foundation can help a manufacturer or distributor:

• reconcile model numbers, MPNs, GTINs and internal SKUs;
• keep variant attributes separate instead of attaching one specification to a whole family;
• associate technical documentation and code definitions with the right product revision; and
• provide downstream data platforms with a stable product reference for installed-asset mappings.

Telemetry collection, user-access mechanisms, consent, cybersecurity, contract disclosures and legal determinations remain responsibilities of the relevant product, platform and specialist teams.

EU Data Act vs Digital Product Passport

Do not use the terms interchangeably.

Both benefit from governed identifiers and machine-readable semantics, but a shared technical foundation does not make them the same legal obligation. See Digital Product Passport (DPP) for the separate concept.

Readiness questions for product-data teams

• Can every data-producing asset be resolved to one model, variant and configuration?
• Does every exposed field have a definition, unit, datatype and schema version?
• Are code lists and meanings versioned alongside firmware or service releases?
• Can the team state what is collected, how often, where it is stored and for how long?
• Has the planned access route been tested for structure, security and usability?
• Are legal, privacy, trade-secret and cybersecurity decisions owned and documented?

The goal is not merely to produce a file. It is to make an authorized data point portable without separating it from the identity and meaning that make it useful.

FAQ

When does Article 3(1) apply to connected products? +

The Article 3(1) design obligation applies to connected products and related services placed on the market after 12 September 2026. Most other Data Act provisions have applied since 12 September 2025.

Does the EU Data Act require every connected product to expose every piece of data? +

No. The access duties concern data that the manufacturer designed the connected product to make retrievable, along with the relevant metadata needed to interpret and use it. Trade-secret, security, personal-data and technical-feasibility considerations still require case-specific assessment.

Is EU Data Act product data the same as a Digital Product Passport? +

No. The Data Act governs access to data generated by the use of connected products and related services. A Digital Product Passport is a separate product-information mechanism introduced through product-specific rules under the Ecodesign for Sustainable Products Regulation.

Where does product identity fit? +

Identity links each observation to the correct product, model, variant and installed asset. Without those relationships, a machine-readable temperature, runtime or error code may be technically accessible but operationally ambiguous.