EU Data Act 2026: what manufacturers and cloud providers decide now

What is the EU Data Act? — In brief

The EU Data Act (officially: Regulation (EU) 2023/2854 on harmonised rules on fair access to and use of data) is the European Union's central regulation for the data economy. It sits alongside — not above — the GDPR, and it applies wherever data flows between connected products, users, data recipients, and cloud services. The regulation entered into force on 11 January 2024 and has been generally applicable since 12 September 2025.

Three points carry the understanding of the entire regulation:

• Three core regulatory areas: data-access rights for users of connected products (Chapters II–III, Articles 3–12), provider-switching rights for cloud and edge services (Chapter VI, Articles 23–31), and access by public-sector bodies to private data in exceptional situations (Chapter V, Articles 14–22). Added to this are essential requirements for smart contracts that execute data-sharing agreements (Article 36) and interoperability obligations (Chapter VIII).
• Broad set of addressees: manufacturers of connected products (industrial machinery, Industry 4.0, IoT, smart home), providers of related services, cloud and edge service providers, data recipients, and public-sector bodies — anyone active in the EU or placing products or services on the EU market, regardless of corporate seat.
• Staged applicability, separate penalty regime per Member State: connected-product design obligation from 12 September 2026, complete elimination of cloud-switching charges from 12 January 2027, application to existing contracts from 12 September 2027. Each Member State sets the level of fines — Germany regulates this in the Data Act Implementation Act (DADG, passed by the Bundestag on 26 March 2026).

Anyone wanting to check whether they are in scope will find the answer in Article 1 (scope of application) and Article 2 (definitions) of the regulation, as well as in the European Commission's continuously updated Data Act FAQ (as of May 2026: version 1.4 of 22 January 2026).

Why the Data Act now belongs on the executive agenda

If your company manufactures a connected product — a machine with a cloud back end, an IoT sensor, an industrial device with telemetry — or offers cloud or edge services in the EU, then Regulation 2023/2854 defines what your product portfolio and contractual architecture must deliver from staged deadlines onward. This is not a technical detail. It is whether you can continue to ship to the EU market, whether your customers can use existing contracts to oblige you to release data — and what fine you face for non-compliance.

The regulation has been generally applicable since 12 September 2025. That means: data-access rights for users of connected products, the right to switch cloud providers, and public-sector data access in exceptional situations apply today. By 12 September 2026, all newly placed connected products must be designed so that the data-access obligation under Article 3(1) can be met without retrofit. By 12 January 2027, cloud providers must have abolished switching charges entirely. The decisions you make in 2026 determine whether you ship on time or scramble under deadline pressure — and whether you build the data model cleanly once or patch it twice.

This article maps what the Data Act actually requires — based on the consolidated text on EUR-Lex, the European Commission's FAQ, and the German implementing legislation — and shows which architectural decisions are now on the table. Not a legal guide. A decision aid for management, IT leadership, and product owners — with enough technical depth to evaluate the effort estimates your engineering team will put in front of you.

Who is in scope — and who is surprised

The Data Act's scope (Article 1) is wider than that of many older EU regulations. It covers manufacturers of connected products (from a single industrial sensor to a cloud-connected machine tool), providers of related services (apps, maintenance clouds, analytics platforms), data recipients (e.g. independent workshops requesting machine data on behalf of users), cloud and edge service providers at every layer (IaaS, PaaS, SaaS), and public-sector bodies that may, in exceptional situations, request data. What matters is not the company's seat but whether products or services are placed on the EU market or used by EU users.

The Data Act has no size threshold equivalent to the NIS2 Directive — its obligations apply regardless of headcount or turnover. Article 7, however, provides an important exemption for small and micro-enterprises: the data-sharing obligations of Chapters II and III do not apply to data from products or services manufactured or provided by a micro or small enterprise — provided that enterprise is not part of a larger group. The regulation defines "micro" and "small" by reference to EU Recommendation 2003/361/EC: fewer than 50 employees and annual turnover or balance-sheet total of no more than 10 million €. Medium-sized enterprises receive a one-year transitional period after a product's market launch. Any company that is part of a corporate group, or operates as a subcontractor of a larger entity, falls outside the exemption.

Less discussed but strategically decisive: if you are a Mittelstand supplier of a connected product that a larger customer integrates into its value chain, your customer's contractual demands will pull you into their data-sharing architecture — even without your own direct obligation. The question "How do we deliver machine data to our customer's maintenance partners, in what format, with what authentication?" lands on your desk regardless of whether the regulation directly compels you.

What the Data Act actually requires

The regulation has eleven chapters and 50 articles. Four areas matter from an architecture perspective.

Data-access rights for users of connected products (Articles 3–12)

Users of a connected product are entitled to easy, secure, free-of-charge, and direct access to the product data and related-service data generated by their use. Article 3(1) goes further and requires the product to be designed and constructed so that this access is possible without disproportionate effort — meaning structurally, not via after-the-fact data exports. This design obligation applies only to products placed on the market after 12 September 2026.

Users may also instruct the data holder to forward data to a data recipient of their choice — for example an independent workshop, a data-analytics provider, or a competitor. The data holder must comply with that instruction; it may charge only a limited (FRAND-conformant) compensation to the data recipient, and it may not use the data for purposes that compete with the recipient.

Cloud provider switching (Articles 23–31)

Providers of data-processing services — IaaS, PaaS, SaaS — must actively enable customers to switch to another provider. Concretely: a contractual notice period of no more than two months, a transitional period of 30 days as standard (extendable to up to seven months in exceptional cases), and a structural obligation to provide exportable data and metadata in a commonly used, machine-readable format. Until 12 January 2027, providers may still levy cost-based switching charges — after that date, switching charges and data-egress fees must disappear entirely. This affects the much-discussed "egress fees" of the major hyperscalers as well.

Public-sector access (Articles 14–22)

In exceptional situations — natural disasters, pandemics, or other extraordinary events — public-sector bodies may oblige private companies to make non-personal data available. This is a tightly bounded mechanism with high formal hurdles, but anyone working in critical infrastructure, energy, transport, or healthcare should know the provision exists.

Smart contracts for data-sharing agreements (Article 36)

Anyone who deploys or offers smart contracts for executing data-sharing agreements must meet a set of essential requirements: robustness against functional errors and manipulation, access control, safe termination and interruption, data archiving and auditability, consistency with contractual terms, and protection against breach of conformity. Smart contracts implemented in line with harmonised standards — once the European Commission tasks CEN/CENELEC with their development and the standards are published in the Official Journal — benefit from a presumption of conformity. As of May 2026, those harmonised standards have not yet been published; until then, providers carry the burden of demonstrating conformity through alternative paths. The article has provoked debate in the industry because the requirement of "safe termination" is hard to reconcile with immutable public-blockchain architectures.

Interplay with the GDPR

Article 1(5) is explicit: where personal data, or mixed datasets in which personal and non-personal data are inextricably linked, are processed, the GDPR's rules and protections prevail. The Data Act complements the GDPR; it does not replace it. In practice that means: a data-sharing obligation under Article 4 of the Data Act does not relieve you of the lawful-basis check under Article 6 GDPR. If machine data carries personal aspects (e.g. operator-specific usage profiles), forwarding data to a recipient still requires an independent GDPR legal basis — typically the user's consent or a contractual obligation.

Architecture implications — where this actually lands

The Data Act is not a compliance exercise you can paper over with a PDF at the end. It changes what a connected platform must do. Five points matter from an architecture perspective.

Data-access API as a product feature, not an attachment

Article 3(1) requires the product to be designed so that the data-access obligation can be met "easily, securely, free of charge, and directly". From an architecture perspective that means: a dedicated API surface (ideally REST/JSON or gRPC with an OpenAPI specification), authentication that cleanly separates the end user from the data recipient (OIDC with token delegation), rate limits, and audit logging of data retrievals. The legacy "Excel export on request" feature does not cut it. Neither does the proprietary cloud console only you can see into. The regulation's expectation is that users can retrieve their data without your manual intervention.

Data model — structured event logs instead of opaque telemetry

The data-access obligation covers "product data" and "related-service data". What that means in practice depends on the product — the regulation limits itself to function and usage data, and excludes sensitive trade secrets and AI model weights. In practice that means: your telemetry must be available in a structured form, not as a binary blob that only your own analytics software can read. Append-only event logs in the platform database, with a clear schema per event type, timestamps, device IDs, and semantically meaningful fields, form the foundation. The same data model that carries the audit trail for the CRA, NIS2, and ISO 9001 can also serve the Data Act's access right — if you build it cleanly once.

Cloud portability — data model and interfaces, not a marketing slide

The provider-switching obligation forces cloud providers to open their data and metadata structures in a way that customers can actually migrate. That is more than a data export — it includes configurations, identity mappings, service topologies, contract data. Any SaaS provider running a proprietary data structure today must, by 12 January 2027 at the latest (when switching charges disappear), have an export strategy compatible with industry-common standards. Customers of cloud providers who have already balanced their architecture between provider-specific services and portable open-source components have less to worry about — and for that very architectural discipline, the Data Act is a tailwind. Data sovereignty across every layer of the architecture, not just in marketing.

Smart contracts — anyone using them documents the lifecycle mechanics

If you use smart contracts to execute data-sharing agreements — for instance, to automate compensation for data made available to a recipient — Article 36 requires you to demonstrate robustness, access control, safe termination, and auditability. That effectively rules out public permissionless blockchains unless they offer a termination mechanism. Practical options are permissioned-ledger architectures (Hyperledger, Corda) or classical signed off-chain agreements with a verifiable logging pipeline. Anyone newly introducing smart contracts should, until the harmonised standards are published, measure and document their solution against the requirements explicitly listed in Article 36.

Convergence with CRA, NIS2, AI Act — one data layer for four regulations

The Data Act does not stand alone. It meets the Cyber Resilience Act (applicable from 11 December 2027 — connected products with cybersecurity obligations), the NIS2 Directive (in force in Germany since 6 December 2025 — risk management and incident reporting), the AI Act (staged applicability, from 2 August 2026 for high-risk systems), and the GDPR. Four regulations reaching into the same data model — field telemetry, usage data, maintenance logs, model inputs. A platform that stitches these obligations together after the fact accumulates debt. A platform that tracks data origin, purpose binding, retention policy, access rights, and audit trail as fields in the data model can answer all four without reinventing itself. Compliance anchored in the data model and the API layer — not bolted on afterwards.

Status of EU applicability (May 2026)

The regulation entered into force on 11 January 2024 (Article 50). The staged application dates are:

• 12 September 2025: general applicability — data-access rights (Chapter II, Articles 4–5), cloud-provider switching obligations (Chapter VI, Articles 23 ff., with transitional rules for switching charges), data-sharing contract requirements (Chapter IV), and all other core obligations
• 12 September 2026: design obligation under Article 3(1) — applies to connected products and related services placed on the market for the first time after this date
• 12 January 2027: complete elimination of cloud switching charges and egress fees (before that date: cost-based charging is permitted)
• 12 September 2027: extension of Chapter IV (rules on unfair contract terms) to existing contracts of indefinite duration or with at least 10 years remaining from entry into force

The harmonised standards for smart contracts (Article 36) had not been published in the Official Journal as of May 2026. The European Commission has issued the standardisation request to CEN/CENELEC; publication is expected over the next 12–18 months. Until then, providers carry the burden of demonstrating conformity through alternative paths.

The European Commission's FAQ is updated continuously (as of May 2026: version 1.4 of 22 January 2026) and is recommended as a practical interpretation aid. It is not formally binding — final interpretation rests with national supervisory authorities and the Court of Justice of the European Union.

Status of German implementation (May 2026)

Germany did not wait for applicability but transposed the national framework with significant delay. The Act implementing Regulation (EU) 2023/2854 (Data Act Implementation Act, DADG) was passed by the Bundestag on 26 March 2026. It defines competences and the fine regime under Article 40 of the regulation.

The central supervisory authority is the Federal Network Agency (BNetzA) — designated as the single point of contact and sole competent authority under Article 37(1) of the Data Act, responsible for market surveillance, complaints handling, and fining procedures. The Federal Commissioner for Data Protection and Freedom of Information (BfDI) has a special role: where personal data is involved, the BfDI is responsible for the data-protection assessment and may impose its own sanctions under the GDPR's regime. BNetzA and BfDI cooperate — the BfDI's assessment cannot be challenged in isolation, only as part of the BNetzA's overall decision.

The DADG fine regime is tiered: up to €5 million or 2 % of worldwide annual turnover for companies above 250 million € turnover for the most serious infringements (especially circumvention offences under Article 6 in conjunction with the obligations of Articles 8–11), up to €500,000 for breaches of core obligations, up to €100,000 for information and cooperation obligations, and up to €50,000 for minor administrative offences. In an unusual move compared with the typical GDPR pattern, the legislator explicitly recommends that authorities pursue disgorgement of economic benefits arising from infringements under § 17(4) OWiG. Anyone gaining a competitive advantage by refusing to share data risks the disgorgement of those gains on top of the fine.

What to actually do in 2026

For a greenfield project the answer is straightforward: build the data model, the access API, and cloud portability from day one so that you meet Article 3(1) without retrofitting. Concretely: structured event logs with a clear schema, a dedicated data-access API with OIDC-based authentication, a documented data schema in OpenAPI form, audit logging of data retrievals in tamper-evident form, a documented export path between cloud layers. None of this is new effort — it is clean platform architecture, becoming a regulatory obligation under the Data Act.

For existing systems — the Mittelstand norm — the Data Act is a refactor trigger. The law does not require you to rebuild a 15-year-old telemetry back end. It requires that, for products you place on the market after 12 September 2026, you meet the design obligation — and that, for all in-market products, you can operationally satisfy the access obligation since 12 September 2025 (even without structural redesign). Pragmatic approach: identify the data-access gap concretely. What data does your product collect today, in what form is it available, what is missing for an API-first experience? Experience shows the top three issues in Mittelstand setups are a missing authentication model for data recipients, an unstructured telemetry format, and a missing audit-logging layer. Refactor and extension beat full rebuild in almost every case.

For cloud and edge providers the strategic task is clear: by 12 January 2027 the switching mechanics, data-export interfaces, and contractual clauses have to stand up. That is more than marketing language — it is an operational migration path that customers will test. Anyone preparing it gains a defensible differentiator over competitors retrofitting under deadline pressure. Anyone who fails to prepare risks not just fines but the erosion of the contractual base — customers can terminate with two months' notice, with the old lock-in mechanisms no longer biting.

How we approach this

We don't sell "EU Data Act compliance as a service". Compliance is not a product — it is the consequence of a cleanly built architecture. What we do: we build platforms for connected products in which the obligations from the Data Act, CRA, NIS2, and GDPR are not retrofitted but anchored in the data model and the API layer. Data-access API with token delegation, append-only event log per device instance, documented data schema, audit trail in tamper-evident form, cloud portability as an architectural principle — as architectural patterns we have implemented in production.

The B2B IoT project LITE BLOX is a practical example: connected industrial units in the field, lifecycle data model with an immutable birth snapshot per unit, append-only event log for security-relevant and usage events, hosting in the EU and Switzerland. If you are responsible for a comparable initiative — a new platform or a refactor of an existing system under Data Act obligations — we are happy to talk architecture before the spec sheet hits the first sprint.

Resources

• EU Regulation 2023/2854 (Data Act), consolidated text: eur-lex.europa.eu/eli/reg/2023/2854
• European Commission, Data Act policy page: digital-strategy.ec.europa.eu/en/policies/data-act
• European Commission, Data Act FAQ (version 1.4 of 22 January 2026): digital-strategy.ec.europa.eu — Data Act FAQ
• European Commission, Data Act explained: digital-strategy.ec.europa.eu/en/factpages/data-act-explained
• Federal Ministry for Digital Affairs (BMDS), Data Act Implementation Act (legislative procedure): bmds.bund.de — Gesetz zur Durchführung des Data Act
• German Bundestag, adoption of DADG on 26 March 2026: bundestag.de — Bundestag adopts EU rules on data access and use
• BfDI, data protection and the EU Data Act: bfdi.bund.de

As of May 2026. The interpretation of individual articles may change through implementing acts, harmonised standards for smart contracts (Article 36), and sector-specific regulations. For a legally binding assessment of your specific case, please consult qualified legal counsel.