The EU Data Act: Data Access by Design and the End of Cloud Lock-In

The Data Act is the quietest of the current EU regulations and one of the most structural. It does not add a banner to your website or a label to your product. It changes who owns the data your products generate, and it makes cloud switching a legal right rather than a commercial negotiation.

Regulation (EU) 2023/2854 became applicable on 12 September 2025. The obligation that requires actual engineering, designing products for data access by default, applies from 12 September 2026. The ban on cloud switching charges completes on 12 January 2027.

If you build connected products or operate a data processing service, this one is on your roadmap whether it is on your roadmap or not.

Two Regulations in One

The Data Act does two quite different things, and it helps to treat them separately.

Part one gives users of connected products a right to the data those products generate, and a right to have it shared with a third party of their choosing.

Part two obliges providers of data processing services, meaning cloud and edge services, to make switching to a competitor practical, and eventually free.

Both are aimed at the same problem: data generated by users ends up locked inside the vendor that collected it.

Connected Products: Data Access by Default

A connected product is any physical item that obtains, generates or collects data about its use or environment and can communicate that data. That is deliberately broad. Vehicles, industrial machinery, agricultural equipment, medical devices, home appliances, wearables, smart meters, building systems and consumer electronics all sit inside it.

A related service is software that makes the product function as intended, and it is in scope alongside the hardware.

What users get

Users have the right to access product data and related service data generated by their use, easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format. Where technically feasible, that access should be direct and continuous rather than a periodic export.

They can also require the data holder to share it with a third party they nominate. That third party might be a competitor's service, a repair shop, an insurer or an analytics provider. The data holder cannot use contractual terms to block it, and cannot use the shared data to compete against the user.

What changes on 12 September 2026

From that date, connected products placed on the market and their related services must be designed and manufactured so that product data and related service data are accessible to the user by default, and where relevant and technically feasible, directly.

That word "designed" is what makes this an engineering deadline rather than a legal one. You cannot satisfy a design obligation with a support process. It has to be in the product.

What it looks like as work

For most teams the gap is not the API, it is everything underneath.

Data model. You need to distinguish data generated by a user's use of the product from data you derive, enrich or infer. Users have a right to the former. That distinction often does not exist in current schemas, where telemetry, derived metrics and internal analytics live in the same tables.

Access interfaces. A real API with authentication, authorisation, pagination and rate limiting, plus a self-service route for non-technical users. A CSV emailed on request does not satisfy "easily and, where relevant and technically feasible, directly".

Third-party delegation. The user can nominate a recipient. That means a consent and authorisation model where the user grants scoped access to a party you have no relationship with, and can revoke it. If your platform has no concept of delegated access, this is the largest single piece of work.

Trade secret handling. The Act tries to balance data access against trade secret protection. You can require proportionate measures to preserve confidentiality, and in narrow circumstances refuse or suspend sharing. This needs to be a documented, defensible position rather than a blanket refusal, and it is worth getting counsel involved early.

Pre-contractual information. Before a sale, you have to tell the buyer what data the product generates, how it is accessed, whether it is continuous and real time, and whether you intend to use it yourself. That is product page and documentation content, and it belongs in the same review as the product information obligations landing in September 2026.

Cloud Switching: The End of Lock-In

The second half of the Data Act targets data processing services, which covers IaaS, PaaS and SaaS.

Providers must:

• Remove commercial, technical, contractual and organisational obstacles to switching.
• Complete a switch within a maximum transitional period, generally 30 days after a notice period of up to two months, extendable where technically unfeasible.
• Support export of all exportable data and digital assets in a structured, commonly used, machine-readable format.
• Provide open interfaces and, for infrastructure services, functional equivalence after the switch.
• Offer a 30 day minimum retrieval period after termination.

On charges, switching costs were reduced from the date of application and are abolished entirely from 12 January 2027. After that a provider may not charge for the switching process at all.

Contract terms have to reflect this, including the switching procedure, the transitional period, the exhaustive data categories that are exportable, and the assistance offered.

If you buy cloud services

This is genuinely useful leverage and most buyers are not using it.

At your next renewal, ask for the switching clause, the exportable data categories, and the exit assistance commitments. You are entitled to them. If the answer is vague, that is information about how difficult an exit would actually be.

It is also worth running an export test rather than trusting a documentation page. Export everything, try to make sense of it, and see whether it would actually reconstitute your service somewhere else. The gap between what a provider says is exportable and what is usable is usually where the lock-in lives.

If you sell cloud services

You need the switching clause in your contracts, a documented switching procedure, an export mechanism that produces something genuinely usable, and a plan for the January 2027 zero fee point if you currently charge egress or exit fees.

Egress pricing in particular deserves attention. Charging for data transfer out is a longstanding industry practice, and the distinction between ordinary egress charges and switching charges is one that regulators will be looking at.

Public Sector Access and B2B Terms

Two smaller pieces worth knowing about.

The Act gives public sector bodies a right to request data from private companies in cases of exceptional need, primarily public emergencies. It is narrow, but if you hold data of public significance, you should know the process exists.

It also introduces an unfairness test for contractual terms about data access and use imposed unilaterally on another business. A term that grossly deviates from good commercial practice is not binding. That is a useful check on take-it-or-leave-it data clauses in vendor agreements.

What We Would Do Now

If you make connected products, the September 2026 date should already be in a sprint plan. The design obligation applies to products placed on the market from that date, so anything currently in development is in scope. Start with the data model separation, because everything else depends on it.

If you operate a data processing service, review your contracts, your export tooling and your fee structure. The January 2027 zero fee point is not far away, and the revenue implications need a decision at management level rather than in engineering.

If you buy cloud services, use your leverage at renewal and test your export path. This costs a day and tells you something valuable about your actual risk.

Everyone else should still check scope. The definition of connected product is broader than the phrase suggests, and companies that think of themselves as software businesses sometimes ship hardware without registering that fact internally.

The Bigger Picture

The Data Act is part of a set of rules that between them are rebuilding the assumptions European software is built on. The 2026 EU digital compliance guide maps the whole surface, including the deadlines that arrive alongside this one.

There is real overlap to exploit. Data access APIs built for the Data Act share infrastructure with GDPR portability requests. Component inventories built for the Cyber Resilience Act tell you where product data actually lives. Building these as one platform capability rather than three projects is the difference between a quarter and a year.

We design and build data platforms, APIs and cloud infrastructure for companies operating in Europe, including the delegated access and export machinery this regulation assumes. If you want help scoping what the September 2026 design obligation means for a specific product, write to office@c9group.dev, or read more about our work with AWS infrastructure and European market entry.

We build systems rather than give legal advice. Scoping and trade secret positions belong with your counsel.