Data StrategyEU Data Act Enforcement Readiness 2026 — Mandatory Data-Sharing Obligations, Smart Device Data Rights, and Cross-Sector Compliance Architecture
The EU Data Act entered full enforcement in September 2025, and Q1 2026 marks the first wave of national data authority investigations targeting connected-device manufacturers, industrial IoT operators, and cloud-switching service providers for non-compliance with mandatory data-sharing and data portability obligations. Organizations operating connected products in the EU must now provide users with real-time access to device-generated data through standardized APIs, enable switching between cloud providers within 30 days without data-format conversion charges, and maintain contractual frameworks for B2B data sharing that satisfy Article 13 fairness and proportionality requirements. Early enforcement actions in Germany, France, and the Netherlands reveal common compliance gaps including API data-format inconsistencies, inadequate user-consent records for third-party data sharing, and cloud-exit procedures that fail to meet the 30-day switching window mandated under Article 23.
Reviewed for accuracy by Kodi C.
The EU Data Act entered full enforcement in September 2025, and Q1 2026 marks the first wave of national data authority investigations targeting connected-device manufacturers, industrial IoT operators, and cloud-switching service providers. Organizations operating connected products in the EU must now provide users with real-time access to device-generated data through standardized APIs, enable cloud switching within 30 days without conversion charges, and maintain contractual frameworks for B2B data sharing satisfying Article 13 fairness requirements. Early enforcement reveals compliance gaps including API format inconsistencies, inadequate consent records, and cloud-exit procedures failing the 30-day switching window.
Data Act Enforcement environment: Q1 2026 Investigation Patterns
National data authorities in Germany (BfDI), France (CNIL), and the Netherlands (AP) launched coordinated sectoral investigations in February 2026 targeting consumer-IoT manufacturers with significant EU market share. The investigations examine compliance with Chapter II of the Data Act, which requires connected product manufacturers to design devices so users can access generated data in real time, in a structured and machine-readable format, without friction or cost. Initial investigation notices requested API documentation, user-consent records, and technical specifications for data-access mechanisms from approximately 340 manufacturers across automotive, smart-home, and wearable-technology sectors.
Industrial IoT operators face separate investigations under Chapter III examining business-to-business data-sharing obligations. Article 8 requires data holders in B2B relationships to share data with data recipients under fair, reasonable, and non-discriminatory conditions. Investigations focus on cases where manufacturing equipment suppliers bundle data-access fees into service contracts in ways authorities consider inconsistent with FRAND (fair, reasonable, and non-discriminatory) obligations. Preliminary findings suggest that tiered data-access pricing models based on customer revenue are under scrutiny as potentially discriminatory, creating significant uncertainty for suppliers who built commercial models on differentiated data-service tiers.
Cloud service providers are subject to Chapter VI investigations examining switching facilitation requirements under Articles 23 through 29. The 30-day switching window, which requires cloud providers to enable complete customer data export and service migration within 30 days of notice, is being tested against actual switching transactions. Early findings indicate that while major cloud providers have implemented documented switching procedures, technical complexity of migrating stateful workloads including managed databases, serverless functions, and container orchestration creates practical switching barriers that authorities may interpret as inconsistent with the regulation's intent despite nominal procedural compliance.
Financial penalties under the Data Act can reach up to 1% of global annual turnover for violations of user data-access requirements and up to 2% for violations of B2B data-sharing obligations, with the distinction between penalty tiers reflecting the legislature's view that data hoarding by powerful data holders against dependent business partners represents the more serious harm. The regulation also creates civil liability enabling individuals and businesses to claim damages for Data Act violations without requiring an authority investigation, creating litigation risk independent of regulatory enforcement.
Connected Product Compliance Architecture
Organizations manufacturing or importing connected products for the EU market must implement data-access architectures satisfying several concurrent technical requirements. The data generated by the connected product must be technically accessible to the user in real time without requiring connection to manufacturer cloud services — a requirement that significantly affects products currently designed to store data in proprietary cloud backends rather than making it available locally or through open APIs. Products that function only when connected to the manufacturer's cloud must be redesigned or updated to support local data export before cloud transmission or in parallel with it.
The data-format requirement specifies that accessible data must be in a commonly used, structured, and machine-readable format. The Data Act does not mandate a specific format, but ETSI and CEN/CENELEC are developing standardized data models for major product categories including smart meters, HVAC systems, and industrial sensors under mandate from the European Commission. Organizations that adopt emerging standards now gain first-mover advantage in regulatory positioning and avoid potentially costly retrofitting when standards become binding. Organizations that proprietary-lock data formats risk enforcement action and customer demands for format conversion at their expense.
Third-party data-sharing provisions under Article 6 allow users to instruct connected-product manufacturers to share their data with designated third parties, including competing service providers, repair workshops, and research institutions. Organizations must implement consent and authorization mechanisms that allow users to grant, modify, and revoke third-party access rights for specific data categories and time periods. The consent architecture must maintain auditable records sufficient to demonstrate compliance with data-access authorizations and must revoke third-party access within defined timeframes when users withdraw consent.
Design-for-compliance requirements create obligations for new product development that exceed retroactive compliance remediation. Article 3 requires connected products to be designed and manufactured to allow users and third parties to access device data securely, easily, and without undue friction. Legal and engineering teams must integrate Data Act compliance reviews into product-development gates, assessing data-collection scope, storage location, API accessibility, and third-party-sharing architecture before hardware and software designs are finalized. Post-launch compliance remediation through software updates is possible for some requirements but may be technically infeasible for products where data-access mechanisms depend on hardware architecture decisions made before the regulation took effect.
B2B Data Sharing: FRAND Obligation Implementation
The Data Act's FRAND obligations for B2B data sharing represent a significant departure from previous EU data law, which generally treated data as property-like assets that holders could exploit without sharing obligations absent voluntary contractual agreement. Article 8's mandatory sharing framework applies when data generated in the context of a B2B relationship is held by one party and needed by another to fulfill contractual obligations, provide maintenance or repair services, or develop products and services dependent on the data. The scope is sufficiently broad to encompass most industrial IoT deployments where equipment suppliers collect operational data from machines operated by customers.
FRAND compliance requires organizations holding B2B data to assess current data-licensing and data-service commercial practices against the regulation's fairness and non-discrimination requirements. Pricing models that charge data-access fees exceeding the marginal cost of access plus a reasonable return, that apply different rates to similarly situated data recipients, or that condition data access on purchasing additional products or services risk enforcement action. Organizations should conduct internal audits of data-service commercial terms, identifying arrangements that regulators are likely to characterize as exploitative and developing remediation plans that maintain commercial viability while satisfying regulatory requirements.
Contractual frameworks for B2B data sharing must satisfy Article 13's minimum terms, which prohibit contractual provisions that limit the data recipient's ability to use shared data for legitimate purposes, that exclude liability for intentional acts and gross negligence, and that impose terms that create manifestly disproportionate obligations on data recipients. Standard terms developed by trade associations including those in automotive, manufacturing, and agriculture sectors are being updated to reflect Data Act compliance, providing organizations with reference frameworks adaptable to specific commercial contexts. Legal teams should verify that existing data-sharing contracts and new contracts being negotiated include required terms and do not contain provisions the regulation voids.
Small and medium enterprises receive limited protections as data recipients under Chapter IV, which allows SMEs to demand data sharing at reduced cost and provides access to standard contractual clauses developed by the European Commission. Organizations that primarily interact with SME data recipients must design data-sharing programs accommodating SME requests under the chapter's protective provisions, which cannot be contracted around. The SME protections create tiered obligations that complicate data-service commercial models designed for uniform enterprise-customer treatment.
Cloud Switching: Technical and Commercial Compliance
Cloud service providers must implement cloud-switching facilitation services under Articles 23 through 29 that enable customers to migrate to competing providers within 30 days. The regulation covers infrastructure as a service, platform as a service, and software as a service, though implementation requirements vary by service type reflecting different technical migration complexities. Infrastructure-as-a-service providers must support data export in standard formats compatible with receiving providers, while software-as-a-service providers must support data export sufficient for customers to migrate to functionally equivalent services.
The prohibition on switching charges under Article 25 requires providers to eliminate fees associated with data export for switching purposes by September 2027. Organizations currently charging egress fees, API-access fees for data export, or format-conversion fees that apply during switching transactions must develop commercial models that recover these costs through alternative means or absorb them as customer-acquisition and retention costs. The prohibition applies to switching-motivated data transfers; routine operational data transfers remain subject to existing pricing structures, creating potential disputes about whether specific transfers are switching-motivated.
Interoperability requirements under Article 26 mandate that cloud providers implement technical interfaces enabling automated data migration workflows without requiring custom development by the customer. The interoperability standards are being developed by ETSI under European Commission mandate, with draft standards expected in late 2026. Organizations should monitor standards development and participate in industry consultation processes to influence technical specifications that will become binding compliance requirements. Early adoption of emerging interoperability standards creates switching-destination advantages, positioning providers as migration targets for customers dissatisfied with incumbent providers.
Cloud customer organizations must conduct cloud-exit planning as a regulatory-risk-management exercise in addition to its traditional business-continuity function. Exit plans must document the technical procedures, timelines, and resource requirements for migrating each workload class to an alternative provider, validating that migration is achievable within the 30-day regulatory window. For complex stateful workloads including managed databases with large datasets, stateful container orchestration configurations, and SaaS applications with deeply integrated customizations, technical migration complexity may require advance migration preparation that cannot be completed within 30 days of initiating the switching process.
Organizational Governance and Compliance Program Design
Effective Data Act compliance programs require cross-functional governance structures integrating legal, product engineering, data architecture, commercial, and privacy functions. Responsibility for Data Act compliance spans the product lifecycle from design decisions that determine data accessibility to commercial negotiations that determine B2B data-sharing terms to cloud procurement decisions that determine switching feasibility. Organizations that silo Data Act compliance within legal or privacy functions without empowering engineers and commercial teams to implement compliant practices will face persistent gaps between documented policies and operational reality.
Data inventory management is foundational to Data Act compliance but extends beyond GDPR data-mapping conventions in important respects. Organizations must inventory not only personal data but all machine-generated data from connected products, including operational, diagnostic, and telemetry data that does not contain personal information. The inventory must capture where data is generated, where it is stored, which third parties have access, what commercial terms govern access, and whether access mechanisms satisfy Data Act technical requirements. Data inventories must be maintained dynamically as products are updated, data-processing architectures change, and commercial arrangements evolve.
Incident-response procedures must address Data Act violations as a distinct category from GDPR breaches. Data Act violations including failures to provide data access within required timeframes, unauthorized data-sharing limitations, and cloud-switching impediments require different response procedures than personal data breaches. Organizations should establish escalation paths for Data Act compliance failures, including procedures for engaging legal counsel, documenting remediation measures, and assessing whether voluntary regulatory disclosure is appropriate. early engagement with national data authorities following identified compliance gaps generally receives more favorable treatment than reactive response to enforcement investigations.
Strategic Data Governance Investment Priorities
Organizations should prioritize Data Act compliance investments in three categories ordered by enforcement risk and implementation timeline. Immediate priorities include completing API accessibility assessments for EU-market connected products, auditing B2B data-sharing contracts against FRAND standards, and validating cloud-exit procedures against the 30-day switching window. Organizations that have not conducted these assessments face immediate enforcement exposure and should treat compliance remediation as a regulatory-risk-management priority with executive visibility and appropriate resource allocation.
Medium-term priorities include redesigning data-architecture patterns to enable local data access, implementing consent and authorization management for third-party data sharing, and developing interoperability capabilities aligned with emerging technical standards. These investments require multi-quarter engineering effort and should be initiated before regulatory deadlines to avoid concentrated implementation risk. Organizations should establish data-governance program offices with authority to mandate compliant architectural patterns in new product development and to drive remediation timelines for existing products.
Long-term strategic investments include developing data-sharing capabilities that create commercial value from mandatory FRAND obligations, building cloud-portability capabilities that differentiate switching-destination services, and establishing data-governance leadership that enables participation in standards development. Organizations that approach the Data Act as a compliance burden will minimize investment and accept residual risk; organizations that identify strategic value in the transparency, interoperability, and portability requirements will build capabilities that create competitive advantage in EU markets where trust in data governance now influences procurement decisions and customer loyalty.
Continue in the Data Strategy pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Data Interoperability Engineering Guide
Engineer interoperable data exchanges that satisfy the EU Data Act, Data Governance Act, European Interoperability Framework, and ISO/IEC 19941 portability requirements.
-
Data Quality Assurance Guide
Operationalise statutory data quality obligations from GDPR, CSRD, the U.S. Information Quality Act, and ISO 8000 by building enterprise-wide controls, metrics, and assurance…
-
Data Stewardship Operating Model Guide
Establish accountable data stewardship programmes that meet U.S. Evidence Act mandates, Canada’s Directive on Service and Digital, and OECD data governance principles while…
Comments
Community
We publish only high-quality, respectful contributions. Every submission is reviewed for clarity, sourcing, and safety before it appears here.
No approved comments yet. Add the first perspective.