Building EU Data Act Compliant Data Sharing Infrastructure: A Technical Guide

The EU Data Act requires organisations to share connected product data in structured, machine-readable formats through secure channels. For engineering teams tasked with building this infrastructure, the Act provides principles but not a blueprint. This guide covers the technical architecture, data formats, security requirements, and implementation patterns you need to know.

Architecture Overview

EU Data Act compliant data-sharing infrastructure consists of four core layers:

1. Data collection and storage — ingesting data from connected products and storing it in a format suitable for sharing
2. API layer — exposing data through standardised, documented APIs that third parties can consume
3. Consent and access control — managing user-directed data sharing, authentication, and authorization
4. Audit and compliance — logging all data access events and generating compliance reports

How you build each layer depends on your scale, product architecture, and whether you are building in-house or using a managed platform.

Layer 1: Data Collection and Storage

Data Ingestion

Connected products typically transmit data through one or more channels:

• MQTT / message queues — common for IoT devices pushing telemetry data at regular intervals
• HTTP APIs — devices making periodic API calls to report status and events
• Edge processing — data processed at the device or gateway level before transmission
• Batch uploads — devices that store data locally and upload in batches when connected

Whatever your ingestion method, you need to ensure the raw data is retained in a format that can be converted to the machine-readable output formats required by the Act.

Storage Considerations

• Retention periods — the Act does not specify a retention period, but you need to define one that balances user access rights with storage costs and GDPR requirements (if personal data is involved)
• Data segregation — separate raw user-generated data (which must be shared) from derived/inferred data (which may be protected as a trade secret)
• Multi-tenancy — if you serve multiple users (e.g., fleet vehicles with multiple drivers), your storage needs to support per-user data isolation

Layer 2: API Design

API Style

The Act does not mandate a specific API style, but REST APIs are the most practical choice for most implementations:

• Well-understood by third-party developers
• Tooling and documentation standards are mature (OpenAPI/Swagger)
• Easy to version and evolve
• Compatible with standard security frameworks (OAuth 2.0)

For high-frequency, real-time data (industrial sensors, vehicle telematics), consider supplementing REST APIs with:

• WebSocket connections for streaming data
• Server-Sent Events (SSE) for push-based updates
• Webhook callbacks for event-driven notifications

Endpoint Design

A minimal compliant API for a connected product data holder might include:

GET /products/{productId}/data
  — Returns available data types for a product

GET /products/{productId}/data/{dataType}
  — Returns data of a specific type (e.g., telemetry, diagnostics)
  — Supports date range filtering, pagination

GET /products/{productId}/data/{dataType}/stream
  — Real-time data stream (WebSocket or SSE)

GET /users/{userId}/consents
  — Lists active data-sharing consents for a user

POST /users/{userId}/consents
  — Creates a new consent (user directing data to a third party)

DELETE /users/{userId}/consents/{consentId}
  — Revokes a consent

Response Formats

The Act requires structured, commonly used, machine-readable formats. In practice:

• JSON — preferred for API responses; widely supported, human-readable
• CSV — acceptable for bulk data exports; less suitable for nested or complex data structures
• XML — supported but less commonly used in modern APIs

Avoid proprietary binary formats. If your products currently export data in proprietary formats, you will need a transformation layer that converts to standard formats.

API Documentation

While not explicitly required by the Act, well-documented APIs are essential for third-party access. Provide:

• OpenAPI/Swagger specification
• Authentication and authorization guide
• Data model documentation (what each field means, units, precision)
• Rate limiting and usage policies
• Sandbox or test environment

Layer 3: Consent and Access Control

Authentication

You need two levels of authentication:

1. User authentication — verifying that the person requesting data access or directing data sharing is the actual user of the product. Integrate with your existing customer identity system.
2. Third-party authentication — verifying that the third party requesting data on behalf of a user is legitimate. OAuth 2.0 client credentials with registered client IDs is the standard approach.

Consent Management

The consent system is the most complex component. It needs to handle:

• Consent creation — user specifies what data to share, with which third party, for how long
• Scope enforcement — API requests are filtered to only return data within the consented scope
• Expiry — consent automatically expires after the defined period
• Revocation — user can revoke consent at any time, immediately terminating data access
• Records — maintain an immutable record of all consent decisions for audit purposes

Access Control Patterns

Use policy-based access control to manage data sharing rules:

• Field-level controls — allow or deny access to specific data fields based on the third party's authorisation level
• Rate limiting — prevent abuse by limiting request frequency per third party
• Data masking — redact sensitive fields when providing data to third parties with limited access
• Geographic restrictions — enforce data residency requirements where applicable

Layer 4: Audit and Compliance

Audit Logging

Every data access event must be logged with sufficient detail for regulatory compliance:

• Who requested the data (user ID, third-party ID)
• What data was accessed (data types, fields, date range)
• When the access occurred (timestamp with timezone)
• The consent that authorised the access (consent ID, scope)
• The outcome (success, partial, denied, error)

Logs must be immutable (append-only) and retained for a sufficient period to support regulatory inquiries and dispute resolution.

Compliance Reporting

Build reporting capabilities that can answer regulatory questions:

• How many data access requests have you received and fulfilled?
• What is your average response time for data requests?
• How many active consents exist, broken down by third party?
• How many consent revocations have occurred?
• What is your FRAND pricing schedule, and how is it applied?

Interoperability and Data Spaces

The EU Data Act is designed to feed into the broader European Data Space initiative. While participation in EU Data Spaces is not yet mandatory, building with interoperability in mind positions your infrastructure for the future:

• Use standard data models where they exist (e.g., NGSI-LD for IoT, DTDL for digital twins)
• Support standard protocols (HTTP/REST, MQTT, AMQP)
• Consider the Eclipse Dataspace Connector (EDC) as a reference for data exchange patterns
• Implement standard identity and trust mechanisms (OAuth 2.0, X.509 certificates)

Build vs. Buy Decision

Factor	Build In-House	Managed Platform	Open-Source (EDC/IDSA)
Time to production	6-18 months	6-8 weeks	3-6 months
Ongoing maintenance	Dedicated team	Provider handles	Community + your team
Customisation	Full control	Configurable	Full control (open source)
Compliance updates	Your responsibility	Provider handles	Community-driven
Security certifications	Must achieve independently	Pre-certified (SOC 2, etc.)	Must achieve independently
Cost model	Capex + opex	Subscription	Opex (team time)

For most organisations that need to comply quickly and don't have a large API engineering team, a managed platform offers the fastest and lowest-risk path. For organisations with strong engineering capabilities and complex custom requirements, building in-house or extending open-source components may be more appropriate.

Fiskil's Data Provider platform provides the API layer, consent management, access controls, and audit logging needed for EU Data Act compliance — with SOC 2 Type II certification and deployment in 6-8 weeks. Explore our EU Data Act solution.