One access-layer pattern for any connected product
Every connected product ends up needing the same thing: existing backend or IoT cloud, extended with an access layer that adds an API, an export path, permissions, audit logs and third-party sharing. This page is the vendor-neutral version of that pattern, for product categories not yet covered by one of our dedicated pages.
The same closed loop, the same missing layer
Whether the product is an industrial machine, an appliance, or something with no obvious category yet, the starting point and the fix look the same: a backend that already has the data, and a governed layer that decides who else gets to see it.
Today: a closed loop
Product
Connected product
Backend
Manufacturer/vendor cloud
- Raw & pre-processed product data
- Device state & status
- Event/fault log
- Usage history
Only exit
Manufacturer's own app
- No user-facing export or API
- No route for the user to authorize a third party
- No permissions model, so every request is a one-off exception
- No audit trail if a user or regulator asks what was shared
With a Data Act access layer
Product
Connected product
Backend
Manufacturer/vendor cloud
- Raw & pre-processed product data
- Device state & status
- Event/fault log
- Usage history
New layer
Data Act access layer
- Field catalog
- User & device entitlements
- Consent & grant registry
Customer export & portal
CSV/JSON, self-service, same quality as the manufacturer sees
Third-party API (OAuth)
Purpose-bound grant to a repairer, analytics or energy provider
Audit & compliance log
Request, decision, recipient and delivery evidence for review
Applies broadly, right now
The Data Act has applied generally since 12 September 2025 to essentially any connected product and related service already on the market, subject to the conditional micro/small enterprise exception.
User access-on-request
Provide an authenticated request path for readily available product and related-service data.
User-directed third-party sharing
Support routing data to a third party the user names, subject to the DMA-gatekeeper exception.
Pre-contract data transparency
Disclose data types, formats, volumes, retention and access method before purchase.
Accessible by-design architecture
New products placed after 12 September 2026 should ship the access API built in.
Usually in scope
- Raw and pre-processed product data generated through use
- Device/product state and status
- Event and fault logs
- Usage history and the metadata needed to interpret any of the above
Usually outside Chapter II
- The vendor's own derived/inferred analytics and proprietary algorithms
- Content such as audiovisual works played by a device
- Data the holder cannot obtain without disproportionate effort
- Cross-customer aggregate benchmarking
What we implement, concretely
Existing backend / IoT cloud → Data Act access layer → API + export + permissions + audit logs + third-party sharing — packaged the same way regardless of product category.
| Capability | What it does |
|---|---|
| Field-level data catalog | A governed inventory of every candidate field, its classification and its availability |
| Customer-facing API & export | Authenticated access and CSV/JSON export for the verified user |
| Third-party sharing via OAuth/API keys | Purpose-bound, revocable access for a recipient the user names |
| Entitlement modeling | Ownership/lease/tenant-aware access control matched to how your product is actually used |
| Audit & compliance logging | A reviewable decision log covering requests, grants, deliveries and revocations |
General IoT equipment Data Act FAQ
How do we decide whether our product needs a dedicated compliance approach or fits this general pattern?
Start with this general pattern regardless — catalog, entitlement, export, third-party sharing, audit — and layer in product-specific rules where a category has its own scoping questions (a trade secret that's obviously algorithmic, a security-sensitive field like a lock credential, an overlapping sector regulation). If your product category has enough of those specifics to matter, that's the signal to build a dedicated profile on top of the general layer, not to replace it.
Does 'connected product' have a broad or narrow legal definition?
Broad. The Data Act defines a connected product as an item that obtains, generates or collects data concerning its use or environment and can communicate that data via an electronic communications service, physical connection or on-device access, and whose primary function isn't storing, processing or transmitting data on behalf of another party. That covers most physical products with any data connectivity, well beyond obvious 'smart device' categories.
Can a product with no companion app still be in scope?
Yes. The obligation is about whether the product generates data that's readily available or can be made available without disproportionate effort, not about whether there's a consumer-facing app. A product with only a manufacturer-side telemetry feed and no end-user app can still owe an access-on-request duty to its user.
We sell into several unrelated product categories. Should we build one shared access layer or several?
One shared access layer with per-category scoping profiles, almost always. The catalog, entitlement engine, third-party grant model and audit log are the same architecture regardless of product category — what changes is the field list, the typical user role, and any category-specific trade-secret or safety carve-outs. Building N separate systems multiplies maintenance cost for no compliance benefit.
Does being a micro or small enterprise change anything?
Potentially, yes. Chapter II generally does not apply to data from connected products manufactured, designed or provided by a qualifying micro or small enterprise, though the exception is conditional — it doesn't apply where a non-qualifying partner or linked enterprise exists, or where the small company is subcontracted to manufacture, design or provide the product or service. Document the enterprise-size assessment rather than assuming headcount alone settles it.
Should we start with this general page or one of the dedicated product pages?
If your product falls into one of our dedicated categories — industrial machinery, HVAC, smart appliances, EV charging, and others linked below — start there; the scoping questions and typical field lists are already worked out for that category. Use this general page as the blueprint when your product doesn't fit an existing dedicated page, or when you're building one shared access layer across several product lines at once.
Primary sources and status
Reviewed 9 September 2026. The Data Act and GDPR are binding EU regulations. The Commission FAQs and explainer are non-binding implementation guidance. Yarify's access-layer pattern, entitlement model and delivery sequence are engineering recommendations, not legal advice.
- Regulation (EU) 2023/2854 — the EU Data ActBinding legal text covering connected-product data access, third-party sharing, fair terms and transitional dates
- Regulation (EU) 2016/679 — the General Data Protection RegulationBinding data-protection rules that continue to govern any personal-data element in a connected-product access flow
- European Commission — Data Act FAQs, version 1.4Non-binding implementation FAQs covering scope, roles, access, trade secrets, compensation and cloud switching
- European Commission — Data Act explainedNon-binding overview of in-scope IoT data, user and third-party flows, and safeguards
