Your device already exports data. Now govern who gets it.

Usually one catalog with per-vertical scoping, not five separate systems. The device and firmware are shared, but the data holder relationship, the typical user (owner, operator, tenant, fleet manager) and the plausible third parties differ by deployment. Model the catalog once at the field level, then apply a vertical-specific entitlement and disclosure profile on top, rather than rebuilding the access logic for every customer segment.

Not legally, but practically the bar is lower to clear. Telemetry hardware exists specifically to move readings off-site, so the data is almost always already lawfully obtained and machine-readable — the compliance gap is rarely 'can we get this data out' and almost always 'do we have a governed, entitlement-checked, audited path for the specific person now asking for it.'

The response must include the readily available data relevant to the request, of the same quality available to the data holder — which generally includes historical data the holder already retains, not just newly generated readings. There's no duty to generate or retain data the device was never designed to store; your retention policy, not the request itself, sets the practical boundary on how far back an export can reach.

Whoever actually operates the cloud backend and can lawfully make the data available is the practical data holder, which in a white-label arrangement is often the rebranding company, not the original device OEM. This needs to be settled in the OEM supply contract — including who publishes the pre-contract data disclosures — rather than left ambiguous until an end user submits a request neither party expected to own.

Both are generally in scope. Device status, battery level, connectivity and fault events are product data about the connected product itself, just as much as the environmental or asset readings it was deployed to capture — a user monitoring their own equipment through your device has a plausible interest in knowing whether the device itself is healthy, not only what it measured.

They're a separate but related constraint. Delegated Regulation (EU) 2022/30 adds cybersecurity, privacy and fraud-prevention requirements for radio-connected devices under the Radio Equipment Directive. A new external-facing Data Act API is exactly the kind of new attack surface those requirements are meant to cover — authenticate it properly and treat it as part of the device's regulated security posture, not a bolt-on integration endpoint.