Give IoT users their data without opening the whole platform

A Data Act access layer identifies the user, resolves the devices they own, rent or lease, separates in-scope raw and pre-processed data from protected analytics, and delivers an export or stream with the metadata needed to use it. It also handles third-party grants, GDPR checks, trade-secret safeguards and a reviewable decision trail.

See what applies now Scope your data path

The user-access right is live. The by-design deadline is next.

The Data Act has applied generally since 12 September 2025. Article 50 delays only the Article 3(1) obligation to design connected products and related services for accessible data: that duty applies to products and related services placed on the market after 12 September 2026. Do not use that transition to postpone the Article 4 request flow that already applies.

Requirement	Status on review date	Implementation consequence
User access when data are not directly accessible	Binding since 12 September 2025	Provide a simple authenticated request path and deliver readily available data plus usable metadata without undue delay
User-directed sharing with a third party	Binding since 12 September 2025	Create purpose-bound grants, recipient verification, delivery controls and termination or deletion handling
Pre-contract data transparency	Binding since 12 September 2025	Disclose data types, formats, estimated volumes, frequency, access method, retention, intended use and complaint route
Accessible by-design product architecture	Applies to products and related services placed on the market after 12 September 2026	Make data directly accessible where relevant and technically feasible; otherwise preserve a compliant holder-mediated route
Zero cloud switching and egress charges	Starts 12 January 2027 under the current binding text	Remove switching-specific charges while keeping ordinary service fees and permitted early-termination terms distinct

The Commission's Digital Omnibus is a legislative proposal, not adopted law on this review date. Track it as a change risk, but test production behavior against the rules currently in force.

Draw the data boundary field by field

Chapter II is not a right to every row a manufacturer holds. It covers product data and related-service data that are readily available, plus relevant metadata. The Commission's 2026 FAQs help interpret the boundary but are non-binding guidance.

Usually in scope

Raw sensor readings the product makes retrievable
Pre-processed values used to make raw readings understandable
Device status, performance, fault and environment events
User actions and related-service events linked to product operation
Timestamps, units, quality flags and metadata needed for use

Usually outside Chapter II

Highly enriched inferred or derived analytics
Content such as audiovisual works played by a device
Data the holder cannot obtain without disproportionate effort
New data that the product was never designed to store or transmit
Unrelated cloud-hosting data processed solely for another party

Provenance

Device, sensor, firmware, related service and transformation that produced the field

Availability

Whether the holder receives it, retention window, latency and historical depth

Classification

Raw, pre-processed, inferred, content, personal, trade secret or mixed

Delivery

Format, unit, schema version, quality, export path and real-time feasibility

“Readily available” is an architectural fact

Record whether each field is lawfully obtained or can be obtained by a simple operation. Do not expand the definition by promising analytics that require a new pipeline, and do not shrink it by labeling an existing database query “disproportionate.” Product, legal and data-engineering owners should approve the catalog together and version every change.

One request flow, four different decisions

Device possession is not enough. The service must establish who the user is, which device relationship creates the right, whether other people appear in the data, and whether the recipient is the user or a nominated third party.

Establish the user relationship
Verify the natural or legal person and connect them to ownership, rental or lease records for each device. Handle transfers, shared fleets and expired leases explicitly.
Resolve the requested dataset
Translate device IDs, fields, time range, delivery frequency and destination into the versioned data catalog. Return a precise explanation for unavailable or out-of-scope fields.
Run disclosure controls
Evaluate personal-data subjects and legal basis, trade-secret classifications, product security restrictions, third-party eligibility and purpose limitations.
Deliver and preserve evidence
Provide the export or stream with required metadata, same-quality semantics and an auditable record of request, decision, schema, data window, delivery and later revocation.

User receives data

Free of charge. Authenticate the user and deliver the in-scope data and metadata for their devices.

User directs a third party

Capture the requested recipient, purpose and dataset. Sharing terms with a business recipient follow Articles 8 and 9.

Holder uses non-personal data

Tie the holder's own use to the contract agreed with the user; the Act does not grant the holder a new independent use right.

Make the API contract explain the legal decision

These endpoint boundaries are Yarify's implementation recommendation, not prescribed route names. They keep identity, scope, authorization and delivery separable so a rejected field does not turn into an unexplained rejected request.

Capability	Contract	Control
Catalog	List available device datasets, fields, metadata, formats, latency and retention	Return only fields visible to the verified user; version descriptions and scope decisions
Entitlements	List device relationships and permitted access windows	Derive from authoritative sale, lease, rental, fleet and transfer records
Access request	Create a user export or continuous-delivery request	Validate dataset, dates, legal basis and delivery feasibility before acceptance
Third-party grant	Create purpose-bound sharing to an eligible recipient	Record user instruction, recipient, purpose, fields, duration and confidentiality measures
Delivery	Retrieve export, poll job, subscribe to stream or receive webhook	Use idempotency, integrity checks, stable schemas, quality flags and delivery evidence
Termination	Stop prospective sharing and close recipient credentials	Keep the audit record; send deletion instructions where Article 6 and the agreement require them

Identity

Use standards such as OIDC/OAuth and stronger client authentication where risk warrants it; do not expose long-lived universal device tokens.

Purpose-bound grants

Represent third-party access as a revocable grant with fields, devices, time range, purpose, recipient and expiration.

Schema registry

Publish machine-readable field definitions, units, enums, quality flags, metadata and compatible change rules.

Same-quality delivery

Avoid silently downsampling, delaying or degrading the shared feed below the quality available to the holder.

Operational fairness

Apply security limits transparently and proportionately; rate controls must not make a valid continuous access right unusable.

Evidence ledger

Store policy version, decision inputs, delivery hashes, failures, retries, suspensions and human overrides without logging disclosed payloads unnecessarily.

Safeguards belong in the decision engine, not a disclaimer

The Data Act operates alongside the GDPR. It also creates a structured trade-secret process and permits narrowly framed security restrictions. A blanket “confidential” or “security” denial is not a compliant workflow.

Personal-data gate

Identify every person represented, not only the device account owner
Record controller, purpose, GDPR legal basis and special-category conditions
Minimise fields and time ranges before export or streaming starts
Preserve data-subject rights, retention rules and processor boundaries
Escalate mixed household, employee, patient or vehicle-user data for review

Trade-secret gate

Identify specific protected fields and the trade-secret holder
Propose proportionate confidentiality and access measures
Record agreement, technical enforcement and recipient compliance
Issue a reasoned written decision for withholding, suspension or refusal
Notify the competent authority where Articles 4 or 5 require it

Decision	When it fits	Required evidence
Deliver	Identity, scope, privacy basis and safeguards pass	Dataset version, grant, decision, delivery quality and timestamp
Deliver with measures	Specific trade-secret data can be protected proportionately	Identified fields, agreed measures, recipient controls and monitoring
Withhold or suspend	Necessary measures are not agreed, implemented or maintained	Written reasons, failed measures, affected fields and authority notification
Refuse specific data	Exceptional serious economic damage is highly likely despite safeguards	Case-specific objective substantiation, written notice and authority notification
Limit for product security	Disclosure risks serious adverse effects to legally defined health, safety or security requirements	Applicable legal requirement, threat analysis, agreed limitation and authority notice

Cloud switching is a separate product track

Chapter VI concerns providers of data processing services, including cloud and edge. It is not the legal basis for a connected-device owner's sensor-data request. Audit the two tracks separately even when the same engineering team owns both APIs.

Contract

State switching rights, notice, transition, exportable data and digital assets, continuity, security, termination and charges in the service agreement.

Export

PaaS and SaaS providers must make open interfaces available and at minimum export customer data in a commonly used, machine-readable format.

IaaS equivalence

Take reasonable measures to help the customer achieve functional equivalence for shared features when switching to the same service type.

Charges

Reduced switching charges cannot exceed directly incurred costs during transition; under current Article 29, switching and egress charges end 12 January 2027.

Continuity

Support the contractual transition period, maintain business continuity, tell the customer about known continuity risks and complete secure erasure after switching.

Change watch

The Digital Omnibus proposes targeted exemptions. Keep the legal policy configurable, but do not apply proposed exemptions before adoption and effect.

Prove one request from device to usable data

A credible pilot starts with one product family and one third-party use case. It proves the hard boundaries — user relationship, field scope, mixed personal data and delivery quality — before expanding the catalog.

Assign legal and system roles
Identify manufacturer, related-service provider, data holder, user, data subjects, processor and likely third-party recipients for the selected product flow.
Build the evidence-backed catalog
Trace every candidate field from device through firmware, broker, lake and analytics; classify availability, metadata, privacy, secrecy and retention.
Model device entitlements
Connect identity to sale, rental, lease, fleet and transfer records, including shared use and relationship end dates.
Implement request decisions
Turn catalog, entitlement, legal basis, purpose and safeguards into explainable allow, partial, suspend and refuse outcomes.
Deliver export and continuous access
Exercise a historical export and, where relevant and feasible, a live feed with stable schemas, quality parity, retries and revocation.
Run abuse and audit scenarios
Test account takeover, overbroad dates, another person's data, ineligible gatekeeper, trade-secret disagreement, device transfer, schema change and service outage.

Acceptance criteria for the access layer

Scoped

Every exposed field has an approved Chapter II classification, metadata set, availability statement and retention window.

Entitlement-aware

A user sees only devices and time ranges backed by current ownership, rental or lease evidence, including transfer handling.

Privacy-safe

Mixed personal data cannot leave without identified subjects, purpose, legal basis, minimisation and applicable Article 9 or ePrivacy checks.

Third-party ready

Purpose-bound grants enforce recipient, fields, devices, duration, delivery, deletion and trade-secret conditions.

Quality-preserving

Exports and streams are machine-readable, documented and of the same quality available to the holder, with no hidden degradation.

Auditable

Support can reconstruct the request, rule version, reviewer, response, data window, schema and delivery result without copying payloads into logs.

EU Data Act IoT API FAQ

Does the EU Data Act require every IoT manufacturer to publish an API?

No. Article 3(1) requires connected products and related services placed on the market after 12 September 2026 to make in-scope data directly accessible where that is relevant and technically feasible. Where users cannot access data directly, Article 4 requires the data holder to provide readily available data without undue delay in a secure, comprehensive, structured, commonly used and machine-readable format. An authenticated API is often the most operable implementation, especially for continuous data, but the law describes outcomes rather than prescribing one universal public API design.

Which connected-product data must be made available?

Chapter II covers raw and pre-processed product data and related-service data that the data holder lawfully obtains or can lawfully obtain without disproportionate effort beyond a simple operation, plus metadata needed to interpret and use it. Sensor readings, device status and user-action events can qualify. Highly enriched inferred or derived data and content such as audiovisual works are generally outside this Chapter II access scope.

Do we have to provide historical data and real-time streams?

The response must include the readily available data relevant to the request and be of the same quality available to the data holder. Continuous and real-time delivery is required where relevant and technically feasible. The Act does not create a blanket duty to generate new data or redesign an older device so that data never stored or transmitted becomes available. Your catalog and retention policy must make those boundaries visible before a request is accepted.

Can a user send their device data directly to a repair or analytics provider?

Yes. Article 5 lets the user ask the data holder to make readily available data and the necessary metadata available to a third party. The third party must use it only for purposes and under conditions agreed with the user and delete it when no longer necessary unless the user agrees otherwise for non-personal data. A Digital Markets Act gatekeeper is not eligible to receive data through this Article 5 route.

Does a Data Act request override GDPR?

No. The Data Act does not create a new legal basis for processing personal data. If the requesting user is not the person the data relates to, disclosure requires a valid GDPR Article 6 basis and, when relevant, satisfaction of Article 9 and ePrivacy conditions. Build subject identification, purpose, legal-basis and minimisation checks into the access decision rather than treating device ownership as automatic permission to disclose every personal record.

Can we reject a request because the dataset contains trade secrets?

Not as a blanket rule. The trade-secret data must be identified and proportionate confidentiality measures agreed. Sharing may be withheld or suspended when those measures cannot be agreed or are not followed, with a reasoned written decision and notification to the competent authority. Refusal is reserved for exceptional, case-specific situations where serious economic damage is highly likely despite safeguards, and it also requires substantiation and authority notification.

Are micro and small IoT companies exempt?

Chapter II generally does not apply to data from connected products manufactured or designed, or related services provided, by a qualifying micro or small enterprise. The exception is conditional: it is unavailable where a non-qualifying partner or linked enterprise exists or where the small company is subcontracted to manufacture, design or provide the relevant product or service. A time-limited transition also applies to newly medium-sized enterprises. Record the enterprise assessment rather than assuming that headcount alone settles it.

Is IoT data access the same as the Data Act cloud-switching obligation?

No. IoT user access is in Chapter II; cloud and edge switching is a separate Chapter VI obligation for providers of data processing services. Under the binding text reviewed here, switching obstacles must be removed and charges for switching and data egress must disappear from 12 January 2027. The pending Digital Omnibus proposes targeted changes, but a proposal is not a basis for treating existing duties as repealed.

Primary sources and status

Reviewed 2 September 2026. The Data Act and GDPR are binding EU regulations. The Commission FAQs and explainer are non-binding implementation guidance; the explainer itself says it is not representative of an official Commission position. The Legal Helpdesk is an official support channel. COM(2025) 837 is a proposal and has not been treated as adopted law. Yarify's endpoint boundaries, identity model, control design and delivery sequence are engineering recommendations, not legal advice.