EU Data Act for Connected Products: Access-by-Design API Checklist

Connected products and related services placed on the EU market after 12 September 2026 must be designed so generated data and necessary metadata are accessible to users easily, securely, free of charge, in a comprehensive, structured, commonly used, machine-readable format, and directly where relevant and technically feasible. Product architecture now determines whether access is real or theoretical.

This guide focuses on the device-to-cloud implementation gap. It does not repeat the cloud-switching analysis in our software-takeover content and is not legal advice.

What must the product make possible?

What data needs an access path?

Build a catalog of raw and pre-processed data generated by use of the product or related service, plus the metadata needed to interpret it. For each class, record the user, holder, source, cadence, volume, format, retention, personal-data status, trade-secret risk, security impact, and access method.

• Separate observed sensor and event data from inferred or derived analytics.
• Map physical ownership, account roles, tenancy, and delegated access to a verified user relationship.
• Expose units, timestamps, device identity, quality flags, and schema version with the data.
• Keep the product disclosure synchronized with actual firmware, app, API, and retention behavior.

What does an access-by-design API look like?

Use explicit resources, stable identifiers, documented schemas, pagination or streaming, scoped authorization, export jobs for large histories, and auditable revocation. Return useful errors and data-availability windows. Do not make users scrape a dashboard or file repeated support tickets.

• Authenticate the user and prove their relationship to the device before issuing access.
• Apply tenant and device boundaries on every query, then regression-test cross-tenant isolation.
• Rate-limit abusive traffic without making normal continuous or real-time access impossible.
• Offer deletion, delegation, and third-party sharing flows consistent with privacy and contract controls.

How should trade secrets and security be handled?

Classify risk per field and access path rather than declaring an entire dataset secret. Apply proportionate technical and organizational measures, preserve reasons for restrictions, and provide escalation. Security controls should narrow abuse without quietly nullifying the user's access right.

• Threat-model device takeover, token theft, enumeration, inference, replay, and bulk extraction.
• Use data minimization, purpose-aware scopes, encryption, monitoring, and time-limited credentials.
• Create an evidence trail for withheld, delayed, or reduced access and the legal basis used.

An eight-step readiness checklist

1. Identify connected products and related services placed on the market after 12 September 2026.
2. Catalog generated data and metadata, including source, volume, cadence, retention, and user.
3. Decide direct, API, export, or assisted access per data class and document feasibility.
4. Implement device-user identity, delegation, authorization, and tenant isolation.
5. Publish versioned schemas and machine-readable outputs with provenance and quality metadata.
6. Align contracts and pre-contract disclosures with actual technical behavior.
7. Load-test continuous access and rehearse security, privacy, trade-secret, and revocation cases.
8. Measure access success, fulfillment time, stale data, authorization failures, and support escalation.

Primary sources

1. Regulation (EU) 2023/2854. Binding Data Act text, including Articles 3 and 4
2. European Commission Data Act explained. Official overview of scope, access, sharing, and switching
3. Bundesnetzagentur Data Act background. Official implementation overview and the September 2026 design date