EU Data Act Guide: Data Access, Cloud Switching and Security Obligations

The EU Data Act forces manufacturers to open up the data their connected products generate and forces cloud providers to let customers leave, and both obligations create new security problems that legal teams rarely hand to security teams early enough. Regulation (EU) 2023/2854 has applied since 12 September 2025, with design obligations for new connected products from 12 September 2026 and the end of cloud switching charges on 12 January 2027. It turns data access into an API and identity problem (who is a legitimate user, which third party may receive data, how trade secrets are protected) and turns cloud exit into an operational one (export, functional equivalence, erasure). This guide covers scope, the obligations that matter to security and platform teams, current status as of October 2026, enforcement, and what the Act means for machine identities and AI agents. It is for security architects, product security, cloud platform owners and privacy leads.

Key takeaways

• Two big regimes in one law. Chapter II gives users of connected products and related services a right to their data, and Chapter VI makes switching between data processing services (cloud, PaaS, SaaS) a contractual right with fixed time limits.
• Dates are staggered. General application from 12 September 2025; Art. 3(1) access-by-design for products placed on the market after 12 September 2026; switching and egress charges fully removed from 12 January 2027; unfair terms rules reach older long-term contracts from 12 September 2027.
• Security is a lawful reason to restrict, but only if documented. Data holders may restrict or refuse sharing where it would undermine legal security requirements or expose trade secrets, but must justify it in writing and notify the competent authority.
• Access is an identity problem. Holders must verify who is a user without asking for more than necessary, must not keep access logs longer than needed, and must hand data to third parties the user chooses, except designated gatekeepers.
• Penalties are national, with GDPR-level fines in places. Member States set penalties, and data protection authorities can fine up to the GDPR Art. 83(5) level for infringements of Chapters II, III and V in their area of competence.

Scope: who and what is covered

The Data Act is cross-sectoral. It applies to manufacturers of connected products and providers of related services placed on the EU market, to data holders and recipients, to public bodies requesting data in exceptional situations, and to providers of data processing services offered to customers in the EU, wherever those providers are established.

• Connected product: A product that obtains or generates data about its use or environment and can communicate it, such as vehicles, smart home devices, wearables and industrial machinery.
• Related service: A digital service, other than a basic communications service, connected to the product so that without it the product could not perform a function, such as the companion app or remote control service.
• Data in scope: Raw and pre-processed data that is readily available to the data holder, personal and non-personal, including the metadata needed to use it. Inferred or derived data, and content such as recorded audio or video, are outside Chapter II.
• Roles: The user (consumer or business that owns, rents or leases the product), the data holder (usually the manufacturer or service provider) and the data recipient (a third party the user nominates).
• Exclusions and relief: Designated gatekeepers under the Digital Markets Act cannot be third-party recipients. Micro and small enterprises have fewer Chapter II obligations, and recital 41 describes a one-year transitional period for products placed on the market by medium-sized enterprises.
• Relationship with the GDPR: The Act does not create a lawful basis for personal data. Where the user is not the data subject, personal data can only be shared if a GDPR Art. 6 basis (and Art. 9 condition where relevant) exists. See the GDPR Compliance Guide for Security Teams.

Key obligations

Connected product data access (Chapter II)

• Access by design (Art. 3(1)): Products and related services must be designed so that data is, by default, easily, securely and, where relevant, directly accessible to the user. This applies to products placed on the market after 12 September 2026.
• Pre-contract transparency: Users must be told what data the product generates, its type, volume and collection frequency, and how to access it.
• Access on request (Art. 4(1)): Where the user cannot access data directly, the data holder must provide it without undue delay, free of charge, in a machine-readable format and, where relevant and technically feasible, continuously and in real time, upon a simple electronic request.
• Proportionate user verification (Art. 4(5)): The holder must not require more information than necessary to verify that the requester is a user, and must not keep access-related information such as log data beyond what is needed to execute the request and for security and maintenance.
• Security restriction (Art. 4(2)): Users and holders may contractually restrict access, use or further sharing where it could undermine security requirements set in law and seriously harm health, safety or security. A holder that refuses on this basis must notify the competent authority.
• Trade secrets (Art. 4(6) to (8)): The holder identifies trade secret data, including in metadata, and agrees proportionate confidentiality measures with the user. It may suspend sharing if measures are not agreed or are breached, and in exceptional cases refuse a request where serious economic damage is highly likely. Each decision must be substantiated in writing and notified.
• Sharing with third parties (Art. 5): On the user's request, the holder must make data available to a nominated third party, with the same limits on gatekeepers and competing products.

Technical protection measures (Art. 11)

Data holders may apply technical protection measures, including encryption and smart contracts, to prevent unauthorised access to data and metadata and to enforce agreed terms, provided they do not discriminate between recipients or block the user's rights. Users and recipients must not alter or remove them without agreement. Where a recipient obtains data by deception, exploits gaps in protection measures, or uses data for unauthorised purposes, the holder can require erasure of the data and all copies, a halt to products or services built on it in serious cases, notification of the user and compensation.

Cloud and data processing switching (Chapter VI)

Art. 25 sets mandatory contract terms. The table summarises the time limits.

PaaS and SaaS providers must offer open interfaces and export in a commonly used, machine-readable format, and IaaS providers must support functional equivalence when a customer moves to a service of the same type. For exit planning beyond the Data Act, see the Cloud Concentration Risk and Exit Strategy Guide.

Third-country governmental access (Art. 32)

Providers of data processing services must take technical, organisational and legal measures to prevent foreign government access to non-personal data held in the EU where it would conflict with EU or Member State law. A foreign court or administrative order is only recognised if based on an international agreement such as a mutual legal assistance treaty; otherwise strict conditions apply. Where access goes ahead, only the minimum data may be disclosed, and the customer must be informed before compliance unless that would undermine a law enforcement investigation.

Timeline and current status

• Commission guidance: The Commission has published Data Act FAQs (version 1.4, 22 January 2026), a draft recommendation on non-binding model contractual terms for data access and use and standard contractual clauses for cloud contracts, guidance on vehicle data, and a Data Act Legal Helpdesk. Guidance on reasonable compensation for Chapter III sharing is still to come.
• Possible amendments: The Commission's Digital Omnibus package of November 2025 proposed simplification changes across EU data rules, including the Data Act. Commentary from August 2026 reports that the Council adopted its position on the data part in June 2026, with the Parliament's position and trilogues still pending, and that existing rules remain fully in force until then. Check the final text before relying on any proposed relief.

Enforcement and penalties

• Competent authorities: Each Member State designates one or more competent authorities and, where there are several, a data coordinator as single point of contact. The Commission keeps a public register. GDPR supervisory authorities handle the personal data aspects.
• Penalties (Art. 40): Member States set effective, proportionate and dissuasive penalties, taking into account the nature, gravity, scale and duration of the infringement, mitigation, previous infringements, financial benefit and the infringer's annual Union turnover. For Chapters II, III and V, data protection authorities may impose fines under GDPR Art. 83 up to the Art. 83(5) amount, and the EDPS may fine EU institutions for Chapter V infringements.
• Complaints and disputes: Users can complain to the competent authority, for example about a refusal on trade secret or security grounds, and parties may use certified dispute settlement bodies. Courts remain available.

What it means for AI agents and non-human identities

Most Data Act flows are machine to machine: product telemetry pipelines, user-authorised third-party APIs, cloud export jobs and migration tooling. Each runs on a non-human identity.

• Third-party access credentials: When a user nominates a recipient, the holder will typically issue an OAuth client, API key or certificate. Scope it to the user's product and data, make it revocable by the user, and expire it when the contract ends. See the API Key Management Guide.
• AI agents as recipients: A third-party service may hand Data Act data to an AI agent for analytics or maintenance. Art. 4(10) and Art. 6 limits on use (for example, no use of the data to develop a competing connected product) must be enforced in the agent's permissions, not just in its contract. See the Identity Governance for AI Agents Guide.
• Logging limits: Art. 4(5) caps retention of access-related information such as log data to what is needed for the request, security and maintenance. Define that retention explicitly so security logging is justified rather than accidental.
• Switching and secrets: Exportable data and digital assets in a cloud exit include configuration, and in practice secrets, keys and workload identities have to be rebuilt in the destination, not copied. Plan key rotation and certificate reissue as part of the transitional period. See the Cryptographic Key Management Guide.
• Erasure proof: After the retrieval period, confirm the old provider has erased data and revoked service principals, access keys and cross-account roles that pointed at it.

Compliance steps

1. Classify your roles. Decide, per product line and per service, whether you are a manufacturer, data holder, recipient, data processing service provider or customer. Many organisations are several at once.
2. Inventory readily available data. For each connected product and related service, list the data and metadata generated, where it lands and which data is personal, trade secret or security-sensitive. See the Data Classification Guide.
3. Design the access channel. Build or adapt an authenticated, machine-readable access API with user verification that collects only what is necessary, consent capture for third-party sharing, gatekeeper screening and rate limits. Test it in a pilot with a small user group before general release.
4. Document restrictions. Write the security and trade secret justification for any data you will restrict, agree confidentiality measures, and prepare the notification template for the competent authority.
5. Apply technical protection measures. Use encryption, scoped tokens, watermarking or smart contracts where they protect trade secrets without blocking legitimate access, and monitor recipients for misuse.
6. Prepare for switching, on both sides. Providers update contracts for Art. 25 terms, export formats and charge schedules ending 12 January 2027. Customers test a real export and restore into another environment, including identity and key rebuild, and keep the old environment live as a rollback until the retrieval period closes.
7. Handle foreign access requests. Providers set up a legal review route for third-country orders, minimisation, and customer notification under Art. 32.
8. Track the Omnibus. Assign an owner to monitor amendments and the Commission's final model terms, and re-baseline when they land.

Decision guidance

Measuring it

• Access request time: Median time from verified user request to data delivery.
• Restriction rate: Percentage of requests restricted on security or trade secret grounds, each with written justification and notification.
• Recipient credential hygiene: Percentage of third-party credentials with scope, expiry and an owner.
• Export test success: Whether a full export and restore completed within the contractual transitional period in the last 12 months.
• Post-switch clean-up: Number of stale keys, roles or service principals left pointing at the former provider.

Common failure patterns

• Over-collection at verification: Demanding full identity documents to release telemetry breaches Art. 4(5) and creates a new store of sensitive data.
• Security as a blanket excuse: Refusing all third-party access "for security" without written justification and notification invites complaints.
• Forgotten personal data: Treating product data as non-personal when it identifies a driver or householder, and sharing it without a GDPR basis.
• Exit plans that skip identity: Exporting data but not rebuilding service accounts, keys and federation, so the new environment fails or the old one stays reachable.
• Long-lived recipient keys: API keys issued to third parties that outlive the user's consent.

Framework mapping

Practitioner checklist

• Map your roles under the Data Act for each product line and service.
• Inventory readily available product and service data, flagging personal, trade secret and security-sensitive data.
• Confirm new connected products placed on the market after 12 September 2026 meet Art. 3(1).
• Build user verification that collects only what is necessary and set log retention explicitly.
• Issue scoped, expiring, revocable credentials to third-party recipients and screen out gatekeepers.
• Write and notify every security or trade secret restriction.
• Update cloud contracts for Art. 25 terms and the 12 January 2027 end of switching charges.
• Run an export and restore test that includes rebuilding keys and workload identities.
• Monitor the Digital Omnibus and final Commission model terms.

Standards and references

• EUR-Lex: Regulation (EU) 2023/2854 (Data Act)
• European Commission: Data Act explained
• European Commission: Data Act
• European Commission: Frequently asked questions about the Data Act
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Cloud Concentration Risk and Exit Strategy Guide · GDPR Compliance Guide for Security Teams · IoT Security Guide · EU Cyber Resilience Act Guide · API Security Guide. This guide summarises Regulation (EU) 2023/2854 (the Data Act) as of October 2026 and is not legal advice.