IoT Data Access by Design: Engineering Connected Products for Data Act User-Access Rights

Since 12 September 2025 a user can demand the data their connected product generates, and answering that with a support ticket and a CSV emailed a fortnight later is neither compliant nor survivable at scale.

The EU Data Act — Regulation (EU) 2023/2854 — turns product data into something users are entitled to reach into. Most of the commentary treats this as a legal event: a new right, a new clause for the contracts team to draft. It is really an engineering event. The obligation lands on the systems that hold the telemetry, and the only durable way to meet it is to build data access into the product as a capability, not to bolt a manual process onto the side of a compliance function that was never sized for it.

What you actually have to hand over

Two obligations are already live. Under Article 4, on a user’s request the data holder must make the readily available product and related-service data available to that user without undue delay, of the same quality as is available to the holder, easily, securely, free of charge, and in a comprehensive, structured, commonly used and machine-readable format — and, where relevant and technically feasible, continuously and in real time. Under Article 5, that same data must be made available, at the user’s direction, to a third party of their choosing. That third party may be a competitor, but it excludes the large platforms designated as gatekeepers under the Digital Markets Act. Both articles have applied since 12 September 2025.

A third obligation is coming. The design duty in Article 3(1) — that products be built so this data is accessible to the user by default — applies from 12 September 2026 to connected products placed on the market after that date. So you have a live access obligation now and a design deadline on the horizon. This is not the only demand the Act places on your architecture, either; the same Regulation hands cloud customers a right to leave their provider, which is a separate engineering problem with the same origin.

Why the support ticket loses

The manual path fails on two fronts at once. The first is volume. “Without undue delay” is not satisfied by a human pulling a database export when the request rate rises; the moment you have thousands of devices and any meaningful demand, a ticket queue becomes a backlog, and a backlog is undue delay by definition. The second is format. A PDF or a hand-curated spreadsheet is not structured, commonly used and machine-readable in the sense the Act means — which is a format a receiving system can parse without a person in the loop, precisely so the user can route it onward to a third party under Article 5. A manual response can, at best, satisfy one of these tests. It cannot satisfy both.

The three surfaces you build

The pattern has three parts, and they are separable — you can ship them in order rather than as one programme.

• The access API. An authenticated endpoint that returns the readily available data for a given product, in a stable machine-readable schema, scoped to what the requester is entitled to see. This is the load-bearing piece.
• Authorisation and consent. Resolving who is asking and what they may see. A user acting for themselves is one kind of grant; a third party the user has authorised under Article 5 is another. The API must never assume the caller is the registered owner.
• The data-holder response path. The policy behind the API: what counts as readily available data, what you are entitled to withhold as a protected trade secret, how you log each disclosure, and how you meet the real-time expectation where it applies.

A minimal access endpoint

Here is the shape of the first surface. It is deliberately small: authorise against a resolved grant rather than an assumed owner, expose only the fields that grant permits, and return structured JSON a downstream system can consume.

# GET /v1/products/{product_id}/data
# Returns the readily available product and related-service data to the
# authorised requester, per Data Act Articles 4 and 5. Machine-readable
# JSON, scoped to what the caller is actually entitled to see.

from fastapi import FastAPI, Depends, HTTPException, Query

app = FastAPI()

def authorise(product_id: str, principal = Depends(current_principal)):
    # The caller may be the user themselves, or a third party the user
    # has authorised under Article 5. Resolve the grant explicitly;
    # never assume the caller is the registered owner.
    grant = grants.resolve(principal.id, product_id)
    if grant is None:
        raise HTTPException(403, "No access grant for this product")
    return grant

@app.get("/v1/products/{product_id}/data")
def get_product_data(
    product_id: str,
    since: str | None = Query(None, description="ISO-8601 lower bound"),
    grant = Depends(authorise),
):
    # Expose only the data classes this grant covers. Exclude anything
    # you are entitled to withhold as a genuine trade secret (Art. 4).
    records = telemetry.read(
        product_id,
        fields=grant.permitted_fields,
        since=since,
    )
    return {
        "product_id": product_id,
        "schema": "https://example.com/schemas/telemetry/v1",
        "generated_at": now_iso(),
        "records": records,  # structured, commonly used, machine-readable
    }

The endpoint is unremarkable engineering, and that is the point. The Data Act does not ask for novel technology; it asks you to expose data you already hold, through an interface you control, to people you can authenticate. If your telemetry platform can already answer “what did this device report between these times”, most of the remaining work is authorisation and schema discipline rather than data plumbing — the same data-contract and governance-by-design practice you would want on any pipeline that leaves the building.

The decisions the code will not make for you

The hard part is not the handler; it is the policy the handler enforces. Three decisions dominate, and none of them is a coding problem.

What is in scope. The right covers readily available data — the product and related-service data the holder can obtain without disproportionate effort — not every derived analytic you have ever computed on top of it. Draw that line deliberately and write it down, because a user or a regulator will eventually ask where it sits and why.

What you may withhold. Article 4 lets you protect genuine trade secrets, but the threshold is real and the burden of justifying it is yours. “Commercially sensitive” is not a trade secret. Over-withholding is the failure mode that feels safe and is not — it is the position least likely to survive a complaint.

Where the data goes next. Because of Article 5, your access API is also, in effect, a sharing API. The moment a user directs their data to a third party, your authorisation model has to represent that third party as a first-class principal with its own scoped grant — and enforce the gatekeeper exclusion the Act carves out. If your consent model can only describe the owner, it cannot describe the obligation.

None of this is exotic. It is a product duty you engineer in rather than a document you file, much like the crypto-agility duty under the Cyber Resilience Act — an obligation that only becomes real when it is built into the thing you ship, not asserted about it.

The firms that treat this as a contracts problem will discover the contract commits them to an interface they have not built. Build the interface first; the clause is easy once the endpoint is real.