How to comply with the EU Data Act in industrial manufacturing?

The European Commission issued definitive guidance in September 2025 clarifying which vehicle data automotive manufacturers must share under the EU Data Act.

With enforcement beginning September 2026, OEMs must provide access to raw and pre-processed vehicle data while protecting proprietary algorithms. Direct user access is free, but B2B data sharing can be monetized under reasonable compensation rules.

As the September 2026 deadline nears, the European Commission has issued comprehensive guidance that clarifies exactly which vehicle data must be shared and how. For automotive manufacturers still planning their compliance strategy, it’s now essential to understand these details.

Why this guidance matters for automotive OEMs?

EU Data Act becomes enforceable in September 2026, requiring all connected vehicle manufacturers to provide direct data access to end users and their chosen third parties. While the regulation itself established the legal framework, the Commission's guidance document - published September 12, 2025 - provides automotive specific interpretation that removes much of the ambiguity manufacturers have faced.

This is no longer just a paper exercise. If you fall short, expect:

•  Heavy financial consequences
•  Serious business risk and reputational damage
•  Potential legal exposure across EU markets
•  A competitive disadvantage as compliant competitors gain market access

For OEMs without appropriate technological infrastructure or clear understanding of these requirements, the deadline is rapidly approaching.

At Grape Up, our expert team and  Databoostr platform have already helped multiple OEMs achieve compliance before the September deadline.  Learn more about our solution .

What vehicle data must be shared?

The September 2025 guidance establishes clear boundaries between data that falls within and outside the Data Act's scope, resolving one of the most contested issues in implementation planning.

In-scope data: Raw and pre-processed vehicle data

Manufacturers must provide access to data that characterizes vehicle operation or status. The guidance defines two categories that must be shared:

 Raw Data Examples:

•  Sensor signals: wheel speed, tire pressure, brake pressure, yaw rate
•  Position signals: windows, throttle, steering wheel angle
•  Engine metrics: RPM, oxygen sensor readings, mass airflow
•  Raw image/point cloud data from cameras and LiDAR
•  CAN bus messages
•  Manual command results: wiper on/off, air conditioning usage; component status: door locked/unlocked, handbrake engaged

 Pre-Processed Data Examples:

•  Temperature measurements (oil, coolant, engine, battery cells, outside air)
•  Vehicle speed and acceleration
•  Liquid levels (fuel, oil, brake fluid, windshield wiper fluid)
•  GNSS-based location data
•  Odometer readings
•  Fuel/energy consumption rates
•  Battery charge level
•  Normalized tire pressure
•  Brake pad wear percentage
•  Time or distance to next service
•  System status indicators (engine running, battery charging status) and malfunction codes and warning indicators

 Bottom line is this: If the data describes real-world events or conditions captured by vehicle sensors or systems, it's in scope - even when normalized, reformatted, filtered, calibrated, or otherwise refined for use.

The guidance clarifies that basic mathematical operations don't exempt data from sharing requirements. Calculating current fuel consumption from fuel flow rate and vehicle speed still produces in-scope data that must be accessible.

Out-of-scope data: Inferred and derived information

Data excluded from mandatory sharing requirements represents entirely new insights created through complex, proprietary algorithms:

•  Dynamic route optimization and planning algorithms
•  Advanced driver-assistance systems outputs (object detection, trajectory predictions, risk assessment)
•  Engine control algorithms optimizing performance and emissions
•  Driver behavior analysis and eco-scores
•  Crash severity analysis
•  Predictive maintenance calculations using machine learning models

 The main difference is this: The guidance emphasizes that exclusion isn't about technical complexity alone - it's about whether the data represents new information beyond describing vehicle status. Predictions of future events typically fall out of scope due to their inherent uncertainty and the proprietary algorithms required to generate them.

However, if predicted data relates to information that would otherwise be in-scope, and less sophisticated alternatives are readily available, those alternatives must be shared. For example, if a complex machine learning model predicts fuel levels, but a simpler physical fuel sensor provides similar data, the physical sensor data must be accessible.

How must data access be provided?

The Data Act takes a technology-neutral approach as of September 2025, allowing manufacturers to choose how they provide data access - whether through remote backend solutions, onboard access, or data intermediation services. However, three essential requirements apply:

1. Quality equivalence requirement

Data provided to users and third parties must match the quality available to the manufacturer itself. This means:

•  Equivalent accuracy - same precision and correctness
•  Equivalent completeness - no missing data points
•  Equivalent reliability - same uptime and availability
•  Equivalent relevance - contextually useful data
•  Equivalent timeliness - real-time or near-real-time as per manufacturer's own access

The guidance clearly prohibits discrimination: data cannot be made available to independent service providers at lower quality than what manufacturers provide to their own subsidiaries, authorized dealers, or partners.

2. Ease of access requirement

The "easily available" mandate means manufacturers cannot impose:

•  Undue technical barriers requiring specialized knowledge
•  Prohibitive costs for end-user access
•  Complex procedural hurdles

 In practice: If data access requires specialized tools like proprietary OBD-II readers, manufacturers must either provide these tools at no additional cost with the vehicle or implement alternative access methods such as remote backend servers.

3. Readily available data obligation

The guidance clarifies that “readily available data” includes:

•  Data manufacturers currently collect and store
•  Data they “can lawfully obtain without disproportionate effort beyond a simple operation”

For OEMs implementing extended vehicle concepts where data flows to backend servers, this has significant implications. Even if certain data points aren’t currently transmitted due to bandwidth limitations, cost considerations, or perceived lack of business use-case, they may still fall within scope if retrievable through simple operations.

When assessing whether obtaining data requires “disproportionate effort,” manufacturers should consider:

•  Technical complexity of data retrieval
•  Cost of implementation
•  Existing vehicle architecture capabilities

What are vehicle-related services under the Data Act?

The September 2025 guidance distinguishes between services requiring Data Act compliance and those that don’t.

Services requiring compliance (vehicle-related services)

Vehicle-related services require bi-directional data exchange affecting vehicle operation:

•     Remote vehicle control:    door locking/unlocking, engine start/stop, climate pre-conditioning, charging management
•     Predictive maintenance:    services displaying alerts on vehicle dashboards based on driver behavior analysis
•     Cloud-based preferences:    storing and applying driver settings (seat position, infotainment, temperature)
•     Dynamic route optimization:    using real-time vehicle data (battery level, fuel, tire pressure) to suggest routes and charging/gas stations

Services NOT requiring compliance

Traditional aftermarket services generally aren't considered related services:

•  Auxiliary consulting and analytics services
•  Financial and insurance services analyzing historical data
•  Regular offline repair and maintenance (brake replacement, oil changes)
•  Services that don't transmit commands back to the vehicle

 The key distinction: services must affect vehicle functioning and involve transmitting data or commands to the vehicle to qualify as "vehicle-related services" under the Data Act.

Understanding the cost framework for data sharing

The guidance issued in September 2025 draws a clear line in the Data Act's cost structure that directly impacts business models.

Free access for end users

When vehicle owners or lessees request their own vehicle data - either directly or through third parties they've authorized - this access must be provided:

•  Easily and without prohibitive costs
•  Without requiring expensive specialized equipment through user-friendly interfaces or methods

Paid access for B2B partners

Under Article 9 of the Data Act, manufacturers can charge reasonable compensation for B2B data access. This applies when business partners request data, including:

•  Fleet management companies
•  Insurance providers
•  Independent service providers
•  Car rental and leasing companies
•  Other commercial third parties

 For context: The Commission plans to issue detailed guidelines on calculating reasonable compensation under Article 9(5), which will provide specific methodologies for determining fair pricing. This forthcoming guidance will be crucial for manufacturers developing their data plans to monetize data while ensuring compliance.

 Key Limitation: These compensation rights have no bearing on other existing regulations governing automotive data access, including technical information necessary for roadworthiness testing. The Data Act's compensation framework applies specifically to the new data sharing obligations it creates.

Practical implementation considerations for September 2026

Backend architecture and extended vehicle obligations

The extended vehicle concept, where data continuously flows from vehicles to manufacturer backend servers, creates both opportunities and obligations. This architecture makes data readily available to OEMs, who must then provide equivalent access to users and third parties.

Action items:

•  Audit which data points your current architecture makes readily available
•  Ensure access mechanisms can deliver this data with equivalent quality to all authorized recipients
•  Evaluate whether data points not currently collected could be obtained "without disproportionate effort"

Edge processing and data retrievability

Data processed "on the edge" within the vehicle and immediately deleted isn't subject to sharing requirements. However, the September 2025 guidance encourages manufacturers to consider the importance of certain data points for independent aftermarket services when deciding whether to design these data points as retrievable.

Critical data points for aftermarket services:

•  Accelerometer readings
•  Vehicle speed
•  GNSS location
•  Odometer values

Making these retrievable benefits the broader automotive ecosystem and may provide competitive advantages in partnerships.

Technology choices and flexibility

While the Data Act is technology-neutral, chosen access methods must meet quality requirements. If a particular implementation - such as requiring users to physically connect devices to OBD-II ports - results in data that is less accurate, complete, or timely than backend server access, it fails to meet the quality obligation.

Manufacturers should evaluate access methods based on:

•  Data quality delivered to recipients
•  Ease of use for different user types
•  Cost-effectiveness of implementation
•  Scalability for B2B partnerships
•  Integration with existing digital infrastructure

Databoostr: Purpose-built for EU Data Act compliance

Grape Up's Databoostr platform was developed specifically to address the complex requirements of the EU Data Act. The solution combines specialized legal, process, and technological consulting with a proprietary data sharing platform designed for automotive data compliance.

 Learn more about Databoostr and how it can help your organization meet EU Data Act requirements.

Addressing the EU Data Act requirements

Databoostr's architecture directly addresses the key requirements established in the Commission's guidance:

 Quality Equivalence: The platform ensures data shared with end users and third parties matches the quality available to manufacturers, with built-in controls preventing discriminatory access patterns.

 Ease of Access: Multiple access methods—including remote backend integration and user-friendly interfaces - eliminate technical barriers for end users while supporting sophisticated B2B integrations.

 Readily Available Data Management : The platform handles both currently collected data and newly accessible data points, managing the complexity of determining what constitutes "readily available" under the guidance.

 Check our case studies :  EU Data Act Connected Vehicle Portal and  Connected Products Data Sharing Platform

Modular architecture for compliance and monetization

Databoostr's modular design addresses both immediate compliance needs and strategic opportunities. Organizations implementing the platform for EU Data Act requirements can seamlessly activate additional modules for data monetization:

•  Data catalog management for showcasing available data products
•  Subscription and package sales for B2B partners
•  Automatic usage calculation tracking data sharing volumes
•  Billing infrastructure supporting the Article 9 reasonable compensation framework

This setup supports both compliance and revenue growth from a single platform, reducing IT complexity while meeting the guidance's technical requirements.

Comprehensive implementation methodology

The Databoostr implementation approach aligns with the guidance's requirements through:

 Legal Consulting

•  Analyzing regulatory requirements specific to your vehicle types
•  Translating Data Act provisions into specific organizational obligations
•  Interpreting the September 2025 guidance within your business context
•  Creating individual implementation roadmaps

 Process Consulting

•  Designing compliant data sharing workflows for end users and B2B partners
•  Determining which data points fall in-scope based on your architecture
•  Establishing quality equivalence controls
•  Planning for reasonable compensation structures

 Technical Consulting

•  Pre-implementation analysis of existing data infrastructure
•  Solution architecture tailored to your extended vehicle implementation
•  Integration planning with backend systems
•  Addressing readily available data retrieval requirements

 Platform Customization

•  Integration with existing digital ecosystems
•  Custom components for specific vehicle architectures
•  Access method implementation (backend, onboard, or hybrid)
•  Quality assurance mechanisms

 Comprehensive Testing

•  Quality equivalence validation
•  Integration verification with existing IT infrastructure
•  Security testing ensuring compliant data sharing
•  Functional testing confirming alignment with guidance requirements

Post-implementation support

With the extended vehicle concept creating readily available data obligations, manufacturers need ongoing platform management. Databoostr provides:

•  Continuous monitoring of platform operation
•  Response to technical or functional issues
•  Supervision of ongoing compliance with Data Act requirements
•  Platform updates reflecting evolving regulatory interpretations

Timeline: What automotive OEMs should do now

 Now - March 2026: Complete data inventory, classify according to guidance definitions, design technical architecture, begin platform implementation

 March - July 2026: Finalize platform integration, conduct comprehensive testing, establish B2B partnership frameworks, train internal teams

 July - September 2026: Run parallel systems, validate compliance, prepare documentation for regulatory authorities, establish monitoring processes

 September 2026 and Beyond: Full enforcement begins, ongoing compliance monitoring, response to Commission's forthcoming compensation calculation guidelines

The path forward: Clear requirements, fixed deadline

The Commission's September 2025 guidance removes ambiguity that has delayed planning for some organizations. With regulatory requirements now precisely defined and less than eleven months until enforcement begins, manufacturers should be finalizing their compliance plans and beginning implementation.

The guidance encourages affected industry stakeholders to engage in dialogue achieving balanced implementation. The Commission also emphasizes coordination between Data Act enforcement authorities and other automotive regulators, including those overseeing type approval and data protection, to ensure smooth interplay between regulations.

For automotive manufacturers, three facts are now clear:

1.     The requirements are defined:    The September 2025 guidance specifies exactly which data must be shared, at what quality level, and through what access methods
2.     The deadline is fixed:    September 2026 enforcement is approaching rapidly
3.     The consequences are significant:    Non-compliance risks financial penalties, business disruption, and competitive disadvantage

Organizations that haven't yet begun implementation should treat the Commission's guidance as a final call to action.

As we enter 2026, the EU Data Act (Regulation (EU) 2023/2854), which is now in force across the entire European Union, is mandatory for all "connected" home appliance manufacturers. It has been applicable since 12 September 2025.

Compared to other industries, like automotive or agriculture, the situation is far more complicated. The implementation of connected services varies between manufacturers, and lack of connectivity is not often considered an important factor, especially for lower-segment devices.

The core approaches to connectivity in home appliances are:

• Devices connected to a Wi-Fi network and constantly sharing data with the cloud.
• Devices that can be connected via Bluetooth and a mobile app (these devices technically expose a local API that should be accessible to the owner).
• Devices with no connectivity available to the customer (no mobile app), but still collecting data for diagnostic and repair purposes, accessible through an undocumented service interface.
• Devices with no data collection at all (not even diagnostic data).

Apart from the last bullet point, all of the mentioned approaches to building smart home appliances require EU Data Act compliance, and such devices are considered "connected products", even without actual internet connectivity.

The rule of thumb is: if there is data collected by the home appliance or a mobile app associated with its functions, it falls under the EU Data Act.

Short overview of the EU Data Act

To make the discussion more concrete, it helps to name the key roles and the types of data upfront. Under EU Data Act, the user is the person or entity entitled to access and share the data; the data holder is typically the manufacturer and/or provider of the related service (mobile app, cloud platform); and a data recipient is the third party selected by the user to receive the data. In home appliances, “data” usually means both product data (device signals, status, events) and related-service data (app/cloud configuration, diagnostics, alerts, usage history, metadata), and access often needs to cover both historical and near-real-time datasets.

Another important dimension is balancing data access with trade secrets, security, and abuse prevention. Home appliances are not read-only devices. Many can be controlled remotely, and exposing interfaces too broadly can create safety and cybersecurity risks, so strong authentication and fine-grained authorization are essential. On top of that, direct access must be robust: rate limiting, anti-scraping protections, and audit logs help prevent misuse. Direct access should be self-service, but not unrestricted.

Current market situation

As of January 2026, most home appliance manufacturers (over 85% of the 40 manufacturers researched, responsible for 165 home appliance brands currently present on the European market) either provide data access through a manual process (ticket, contact form, email, chatbot) or do not recognize the need to share data with the owner at all.

If we look at the market from the perspective of how manufacturers treat the requirements the EU Data Act imposes on them, we can see that only 12.5% of the 40 companies researched (which means 5 manufacturers) provide full data access with a portal allowing users to easily access their data in a self-service manner (green on the chart below). 55% of the companies researched (yellow on the diagram below) recognize the need to share data with their customers, but only as a manual service request or email, not in an automated or direct way.

‍

‍

The red group (32.5%) consists of manufacturers who, according to our research:

• do not provide an easy way to access your data,
• do not recognize EU Data Act legislation at all,
• recognize the EDA, but their interpretation is that they don’t need to share data with device owners.

A contact form or email can be treated as a temporary solution, but it fails to fulfill the additional requirements regarding direct data access. Although direct access can be understood differently and fulfilled in various ways, a manual request requiring manufacturer permission and interaction is generally not considered "direct". (Notably, "access by design" expectations intensify for products placed on the market from September 2026.)

API access

We can't talk about EU Data Act implementation without understanding the current technical landscape. For the home appliance industry, especially high-end devices, the competitive edge is smart features and smart home integration support. That's why many manufacturers already have cloud API access to their devices.

Major manufacturers, like Samsung, LG, and Bosch, allow users to access appliance data (such as electric ovens, air conditioning systems, humidifiers, or dishwashers) and control their functions. This API is then used by mobile apps (which are related services in terms of the EU Data Act) or by owners integrating with popular smart home systems.

There are two approaches: either the device itself provides a local API through a server running on it (very rare), or the API is provided in the manufacturer's cloud (most common), making access easier from the outside world, securely through their authentication mechanism, but requiring data storage in the cloud.

Both approaches, in light of the EDA, can be treated as direct access. The access does not require specific permission from the manufacturer, anyone can configure it, and if all functions and data are available, this might be considered a compliant solution.

Is API access enough?

The unfortunate part is that it rarely is, and for more than one reason. Let's go through all of them to understand why Samsung, which has a great SmartThings ecosystem, still developed a separate EU Data Act portal for data access.

1. The APIs do not make all data accessible

The APIs are mostly developed for smart home and integration purposes, not with the goal of sharing all the data collected by the appliance or by the related service (mobile app).

Adding endpoints for every single data point, especially for metadata, will be costly and not really useful for either customers or the manufacturer. It's easier and better to provide all supplementary data as a single package.

2. The APIs were developed with the device owner in mind

The EU Data Act streamlines data access for all data market participants - not only device owners, but also other businesses in B2B scenarios. Sharing data with other business entities under fair, reasonable, and non-discriminatory terms is the core of the EDA.

This means that there must be a way to share data with the company selected by the device owner in a simple and secure way. This effectively means that the sharing must be coordinated by the manufacturer, or at least the device should be designed in a way that allows for secure data sharing, which in most cases requires a separate B2B account or API.

3. The APIs lack consent management capabilities

B2B data access scenarios require a carefully designed consent management system to make sure the owner has full control regarding the scope of data sharing, the way it's shared, and with whom. The owner can also revoke data sharing permission at any time.

This functionality falls under the scope of a partner portal, not a smart home API. Some global manufacturers already have partner portals that can be used for this purpose, but an API alone is not enough.

If an API is not enough - what is?

The EU Data Act challenge is not really about expanding the API with new endpoints. The recommended approach, as taken by the previously mentioned Samsung, is to create a separate portal solving compliance problems. Let's also briefly look at potential solutions for direct access to data:

• Self-service export - download package, machine-readable + human-readable, as long as the export is fast, automatic, and allows users to access the data without undue delay.‍
• Delegated access to a third party - OAuth-style authorization, scoped consent, logs.

• Continuous data feed - webhook/stream for authorized recipients.

These are the approaches OEMs currently take to solve the problem.

Other challenges specific to the home appliance market

Home appliance connectivity is different from the automotive market. Because devices are bound to Wi-Fi or Bluetooth networks, or in rare cases smart home protocols (ZigBee, Z-Wave, Matter), they do not move or change owners that often.

Device ownership change happens only when the whole residence changes owners, which is either the specific situation of businesses like Airbnb, or current owners moving out - which very often means the Wi-Fi and/or ISP (Internet Service Provider) is changed anyway.

On the other hand, it is hard to point to the specific "device owner". If there is more than one resident - effectively any scenario outside of a single-person household - there is no way to effectively separate the data applicable to specific individuals. Of course, every reasonable system would include a checkbox or notification stating that data can only be requested when there is a legal basis under the GDPR, but selecting the correct user or admin to authorize data sharing is challenging.

From a business perspective, a challenge also arises from the fact that there are white-label OEMs manufacturing for global brands in specific market segments. A good example here is the TV market - to access system data, there can be a Google/Android access point, while diagnostic data is separate and should be provided by the manufacturer (which may or may not be the brand selling the device). If you purchase a TV branded by Toshiba, Sharp, or Hitachi, it can all be manufactured by Vestel. At the same time, other home appliances with the same brand can be manufactured elsewhere. Gathering all the data and helping users understand where their data is can be tricky, to say the least.

Another important challenge is the broad spectrum of devices with different functions and collecting different signals. This requires complex data catalogs, potentially integrating different data sources and different data formats. Users often purchase multiple different devices from the same brand and request access to all data at once. The user shouldn't have to guess whether the brand, OEM, or platform provider holds specific datasets - the compliance experience must reconcile identities and data sources to make it easy to use.

Conclusion

Navigating the EU Data Act is complicated, no matter which industry we focus on. When we were researching the home appliance market, we saw very different approaches—from a state-of-the-art system created by Samsung, compliant with all EDA requirements, to manufacturers who explain in the user manual that to "access the data" you need to open system settings and reset the device to factory settings, effectively removing the data instead of sharing it. The market as a whole is clearly not ready.

Making your company compliant with the EU Data Act is not that difficult. The overall idea and approach is similar regardless of the industry you represent, but building or procuring a new system to fulfill all requirements is a must for most manufacturers.

For manufacturers seeking a faster path to compliance, Grape Up designed and developed Databoostr, the EU Data Act compliance platform that can be either installed on customer infrastructure or integrated as a SaaS system. This is the quickest and most cost-effective way to become compliant, especially considering the shrinking timeline, while also enabling data monetization.