YarifyStart a conversation

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.

CapabilityWhat it does
Field-level data catalogA governed inventory of every candidate field, its classification and its availability
Customer-facing API & exportAuthenticated access and CSV/JSON export for the verified user
Third-party sharing via OAuth/API keysPurpose-bound, revocable access for a recipient the user names
Entitlement modelingOwnership/lease/tenant-aware access control matched to how your product is actually used
Audit & compliance loggingA 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.

Tell us what your product actually is.

Tell us your product category, current backend or IoT cloud, what you already log, and who's asking for access. We'll scope a pilot that proves one field-level access decision end to end, whether or not it fits one of our dedicated product pages.