YarifyStart a conversation

Turn machine telemetry into a Data Act-ready customer API

Most industrial machine builders already collect production counts, runtime, alarms and maintenance history on a proprietary backend. The Data Act doesn't ask you to open that backend — it asks you to give the operator who owns, rents or leases the machine a governed way to get their own data out, and to share it with a repair shop or analytics provider they choose.

The operator's access right is already live

The Data Act has applied generally since 12 September 2025, so the access-on-request duty already covers machines sold before that date. The Article 3(1) by-design duty is separate and forward-looking: it reaches machines placed on the market after 12 September 2026, roughly the same window as the Machinery Regulation's digital-instructions rules taking effect from 20 January 2027.

RequirementStatus on review dateWhat it means for a machine builder
Operator access-on-requestBinding since 12 September 2025Provide an authenticated request path for production, runtime, alarm and maintenance data already generated by installed machines
Operator-directed third-party sharingBinding since 12 September 2025Let an operator route their own machine data to a repair partner, energy consultant or analytics provider of their choice
Pre-contract data transparencyBinding since 12 September 2025Disclose what data a new machine generates, in what format, at what frequency, before the sale or lease is signed
Accessible by-design architectureApplies to machines placed on the market after 12 September 2026New machine platforms should ship with the access API built in, not bolted on after a request arrives

Operational data is in scope. Control logic isn't.

Chapter II covers the data a machine generates through use, plus the metadata needed to interpret it — not the software or engineering know-how that makes the machine run.

Usually in scope

  • Production and cycle counters, throughput, runtime hours
  • Alarm and fault codes, downtime events and causes
  • Energy and utility consumption per machine or line
  • Scheduled and unscheduled maintenance and service records
  • Environmental sensor readings tied to a specific unit (temperature, vibration, pressure)

Usually outside Chapter II

  • PLC ladder logic, firmware and control-system source code
  • Proprietary process-optimization or recipe parameters
  • Predictive-maintenance model internals and training data
  • Cross-customer benchmarking or fleet-wide aggregate analytics
  • Data the historian never captured and cannot retrieve without disproportionate effort
Field groupTypical sourceDelivery format
Runtime & cycle countersPLC counters via OPC-UA/MQTT gatewayTime-series export, CSV/JSON, or streaming API
Alarms & fault codesSCADA/HMI event logStructured export with code, timestamp, severity and duration
Energy consumptionPower meter or drive telemetryInterval export aligned to production shifts
Maintenance eventsCMMS or service-technician logStructured export linking event to affected component
Device & connectivity statusEdge gateway heartbeatStatus API for uptime and last-seen checks

From a closed historian to a governed access layer

Most machine fleets already have the data. The gap is a customer-facing layer between the historian and the outside world — one that knows who is asking, what they're entitled to, and what happened to the answer.

Today: a closed loop

Product

Industrial machine / PLC

Backend

Machine builder IoT cloud

  • Cycle count & runtime
  • Alarm & fault codes
  • Energy consumption
  • Maintenance events

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

Industrial machine / PLC

Backend

Machine builder IoT cloud

  • Cycle count & runtime
  • Alarm & fault codes
  • Energy consumption
  • Maintenance events

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

What we implement, concretely

A machine telemetry API, an export path, a third-party sharing flow and a customer portal — built on your existing historian, not a replacement for it.

CapabilityWhat it does
Machine telemetry APIAuthenticated REST/GraphQL access to runtime, cycle, alarm and energy data per machine or fleet
Production & runtime exportScheduled or on-demand CSV/JSON export sized for ERP and BI ingestion
Alarm & maintenance data feedStructured event stream linking faults to service actions and downtime
Customer portalSelf-service export, entitlement view and third-party grant management for operators
Third-party sharing & OAuth grantsPurpose-bound, revocable access for repair partners, energy auditors or fleet analytics providers
Entitlement & audit layerSale/rental/lease-aware access control with a reviewable decision log

Prove it on one machine family first

Start with one product line and one third-party use case — usually a repair partner or energy auditor — before rolling the access layer out across the fleet.

  1. Trace the telemetry pipeline

    Map every candidate field from PLC/sensor through gateway, historian and analytics, and classify each as raw, pre-processed, or derived.

  2. Model entitlements

    Connect machine identity to sale, rental and lease records, including operator changes and fleet reassignment.

  3. Design the API contract

    Define catalog, access-request, third-party grant and delivery endpoints separate from your internal engineering APIs.

  4. Build the decision engine

    Turn catalog, entitlement, trade-secret and privacy checks into explainable allow, partial and refuse outcomes.

  5. Ship export and streaming

    Deliver a historical export and, where useful, a live feed with stable schemas and delivery evidence.

  6. Test the edge cases

    Run through leased-machine handoffs, multi-operator sites, disputed trade-secret fields and third-party revocation.

Industrial machinery Data Act FAQ

Does the Data Act apply to a machine builder that sells worldwide, not just in the EU?

It applies where the connected product's user is located in the EU at the time of the request, regardless of where the manufacturer is established. An EU-based factory operating a machine built outside the EU can still exercise Chapter II rights against the manufacturer or its EU-established data holder. Track user location, not manufacturing origin, when deciding whether a request is in scope.

Do we have to expose PLC ladder logic or control-system source code?

No. Chapter II covers product and related-service data generated by use — production counts, runtime, alarms, energy consumption and comparable operational records — not the control software, firmware or source code that produces it. Ladder logic, ML model weights and proprietary control algorithms are not the readily available data the Act targets, though they may separately be protected as trade secrets if a request ever brushes against them.

Can we withhold data because it reveals our process-optimization know-how?

Only through the Act's structured trade-secret process, not as a blanket refusal. Identify the specific fields that would reveal protected know-how, propose proportionate confidentiality measures for the recipient, and document the decision. A dataset can mix protected and non-protected fields — separate them rather than denying the whole request because one derived metric is sensitive.

How does this interact with the Machinery Regulation's digital instructions requirement?

They are separate obligations that will often share the same telemetry pipeline. The Machinery Regulation governs safety instructions, including a digital-format option, for machinery placed on the market from 20 January 2027. The Data Act governs who can access the operational data the machine generates once it's running. A machine's connectivity architecture should account for both rather than treating one as a substitute for the other.

Who is entitled to request data when a machine is leased, not owned?

The Data Act extends the access right to users, including renters and lessees for the duration of a rental or leasing agreement, not only to the registered owner. A leasing arrangement needs an entitlement model that resolves overlapping claims between the leasing company and the operating business, with a clear end-of-lease handoff so access doesn't silently persist or silently vanish.

Does connecting a machine to this kind of API create new Cyber Resilience Act obligations?

Potentially, yes, separately from the Data Act. If the machine or its remote-monitoring component is itself a product with digital elements under the Cyber Resilience Act, exposing a new external API is a security-relevant architecture change that should go through the same vulnerability-handling and secure-development expectations as the rest of the connected product, not be treated as pure data-access plumbing.

Send us your machine data pipeline.

Tell us your machine family, current historian or IoT cloud, what you already log, and who's asking for access — an operator, a repair partner, or a lessor. We'll scope a pilot that proves one field-level access decision end to end.