The EU Data Act: what it means if you make connected products or sell cloud services

The EU Data Act is not a privacy law, and reading it as one is the first mistake. It governs access to data — who may use the data a connected product generates, and how easily a customer can leave a cloud provider. It applies to personal and non-personal data alike, and it sits alongside GDPR rather than replacing any part of it.

Two obligations, two audiences

Most organisations are affected by one half or the other, rarely both.

• If you make connected products or related services — industrial equipment, vehicles, smart devices, medical devices — users gain rights to access the data their use generates, and to have it shared with a third party of their choosing.
• If you provide cloud or edge services — you face obligations around switching: enabling customers to move to another provider, removing contractual and technical obstacles, and constraining what you may charge for egress.

The connected products side

The practical requirements:

• Design for access. Products and services should be built so that data is accessible to the user by default — a design obligation, not a support process you can bolt on.
• Transparency before purchase about what data the product generates, how it is accessed, and whether the manufacturer will use it.
• Sharing on request with third parties the user nominates — including, notably, competing aftermarket service providers.
• Limits on your own use. You generally cannot use non-personal product data to derive insights that compete with the user, nor share it onward without a basis.

The strategic point often missed: this is aimed squarely at aftermarket competition. A manufacturer who has treated device telemetry as a proprietary moat — for maintenance, servicing or analytics — should expect that position to be tested by customers exercising these rights.

The cloud switching side

• Contract terms enabling switching within defined notice and transition periods.
• Removing obstacles — commercial, technical and organisational — that prevent a customer moving to another provider or bringing workloads in-house.
• Egress charges constrained, with the regulation moving toward their withdrawal.
• Interoperability and information sufficient for a customer to actually port, including formats and structures.

This is engineering and commercial work rather than a policy update. Export capability, documented data formats and a genuine exit path have to exist — and if your commercial model relied on egress revenue or switching friction, that assumption needs revisiting.

Interaction with GDPR

Where product data includes personal data, GDPR continues to apply in full. The Data Act does not create a lawful basis, and a sharing request from a user does not override data protection duties toward other individuals whose data may be entangled in the same records — a real complication in shared vehicles, households and workplaces.

Where to start

1. Establish which half applies to you — connected products, cloud services, or both.
2. Inventory the data your products generate and where it flows today.
3. Assess whether access is technically feasible, and what it would take to build.
4. Review contracts and pre-contract information for the required disclosures.
5. For cloud services, test whether a customer could genuinely exit — and time it.
6. Confirm current timelines and any sector guidance with counsel; the application dates and implementing detail have been phased.

Key takeaways

• It is an access and portability regulation, not a privacy one.
• Connected-product obligations are design requirements, not support processes.
• Cloud switching duties are engineering and commercial work.
• GDPR still applies in full where the data is personal.