A buyer can spend six figures on a connected pump, chiller, compressor or production cell and still discover after commissioning that its most useful operating data lives behind a supplier portal. The dashboard may show a trend, yet the maintenance team cannot export the underlying events. A service contractor may receive screenshots instead of a feed. When the warranty ends, years of history can remain tied to an account controlled by somebody else. The machine works, but the buyer has acquired a narrower operating position than expected.
The EU Data Act changes the legal background to that negotiation. It has applied since 12 September 2025 and covers data generated by connected products and related services, including industrial machinery. The European Commission describes rights for a user that owns, rents or leases a connected product to access data generated through its use and, subject to the Regulation's conditions, ask for that data to be shared with a chosen third party. Those rights help. They do not choose tags, define an API, preserve five years of history or tell a maintenance contractor how to authenticate. Procurement still has to turn the right into a usable deliverable.
What the confirmed rules give the buyer
The Commission's January 2026 FAQ separates direct and indirect access. Direct access lets the user stream or download data without the data holder intervening. Indirect access can use a request through a portal or another approval path. The FAQ says a manufacturer has discretion to choose direct access where relevant and technically feasible, and can combine direct and indirect routes. Buyers should therefore avoid treating the word access as a complete technical answer. Two compliant offers may leave the operator with very different latency, effort and dependence on the supplier.
The material in scope is also bounded. The Commission describes raw and pre-processed data generated through use that is readily available to the data holder, together with relevant metadata. It does not turn every derived insight, service report or proprietary model into user data. The FAQ says required data should be comprehensive and supplied in a structured, commonly used, machine-readable format, with the same quality available to the data holder and without undue delay. Continuous or real-time access applies where relevant and technically feasible. Each of those qualifiers needs a procurement interpretation tied to the asset and the maintenance job.
Write the data map before asking for an interface
An interface specification written before a data map often produces a clean connection to the wrong information. Start with the decisions the buyer expects to make: diagnose a trip, compare duty and standby performance, verify an energy anomaly, plan a service interval, investigate a warranty event or give an independent maintainer enough evidence to propose a repair. Then map the minimum data needed for those decisions.
- Signals and events: named measurements, states, alarms, commands, operating modes and counters, including units and valid ranges.
- Context: asset identity, serial number, firmware, configuration, sensor location, site time zone and the operating state that gives each value meaning.
- Time: sampling frequency, event resolution, clock source, timestamp format, latency and the treatment of gaps or delayed uploads.
- History: on-device and cloud retention, archive format, export limits, deletion rules and what remains available after a service or contract ends.
- Quality: calibration status, precision, missing-value markers, transformations and any difference between the data shown to the supplier and the data delivered to the user.
- Authority: which buyer roles and approved third parties can view, export, stream or administer access, and how each permission can be revoked.
This map also exposes an easy category error. A PDF alarm report may be useful evidence, but it is not an event stream. A portal chart may answer one visual question, but it cannot automatically populate the buyer's historian. A monthly export may support reporting while failing a live fault investigation. Name the job first, then request the smallest data product that can perform it.
The RFQ data schedule
Attach the schedule to the technical requirements and require a line-by-line supplier response. A useful answer says native, configuration required, optional service, unavailable or proposed alternative for each field. Blank cells and references to a generic platform brochure should score as unresolved. The schedule should cover at least the following terms.
- Dataset: the exact tags, events, metadata and history included, plus a sample payload and data dictionary.
- Access route: local interface, customer-controlled endpoint, supplier API, scheduled export or request portal; state which routes require supplier intervention.
- Format and transport: for example CSV or JSON for exports and the agreed industrial or web protocol for streams, including versioning and rate limits.
- Service level: expected latency, availability, export turnaround, maintenance windows, incident notice and support route.
- Identity and permissions: account owner, machine-to-machine authentication, role model, third-party access, audit log, revocation and credential recovery.
- Commercial boundary: charges for connectors, historical export, API volume, additional users, third-party sharing, support and access after warranty or subscription expiry.
- Lifecycle: how schema, firmware and endpoint changes are announced; migration period; backward compatibility; full exit export; and deletion confirmation.
- Exceptions: data claimed as outside scope, unavailable, security-sensitive or a trade secret, with the specific reason and proposed safe alternative.
Keep legal classification and operational acceptance as separate columns. Counsel may need to decide how the Data Act, data protection law, sector rules and contract terms apply to the transaction. Engineering still needs to decide whether the proposed feed can support the maintenance decision. A legal right that requires a manual request can coexist with a procurement requirement for a continuously available local interface. The contract should make clear which promise the supplier is pricing and which statutory rights remain unaffected.
Illustrative test case: a connected cooling plant
This example is synthetic. A facilities operator is buying two connected chillers for a critical site. Its stated jobs are to investigate trips without waiting for the manufacturer's helpdesk, let an approved independent specialist review performance, and retain evidence across the equipment's service life. The RFQ requests alarm and state changes at event resolution, a defined set of temperatures, pressures, valve positions and energy counters, five years of history, a local read-only interface, a documented export, and revocable third-party access.
Bidder A includes a polished cloud dashboard. Live values are visible to named employees, while bulk export is a support request and independent access needs a separate commercial agreement. The offer does not state retention after the service subscription ends. Bidder B includes a narrower dashboard but supplies a local read-only feed, a versioned data dictionary, daily export to buyer-controlled storage and a role for the buyer's maintainer. It marks three diagnostic values as supplier-derived analytics rather than product data and offers the underlying raw signals instead.
Without a schedule, Bidder A can appear more complete. Against the operating jobs, Bidder B resolves more of the buyer's risk even though it exposes fewer finished analytics. The buyer can test the feed, retain its own history and replace the maintenance specialist without rebuilding the data path. The three excluded values also become a visible point for legal and technical review instead of an argument discovered during an outage. This example does not establish that either design complies with the Data Act; it shows how a buyer can compare the operational result.
Run an acceptance test, not a dashboard tour
The factory or site acceptance test should use the buyer's own people, destination system and third-party role. Ask the supplier to generate a harmless known event, then trace it from the equipment to the buyer's store. Export a defined historical window. Check timestamps and missing values. Revoke and restore a maintainer's access. Rotate a credential. Compare a portal value with the machine-readable record. Retrieve the data dictionary without help from the bid team. Finally, simulate subscription expiry or supplier unavailability on paper and show which data path continues.
Record each result as passed, failed, conditional or not tested, with the artifact and responsible party. A successful login proves only that one account reached one screen. Acceptance requires the promised data, route, quality, timing and authority boundary to work together. Any deferred item needs an owner, date and contractual consequence before the equipment is accepted.
Limits that belong in the decision
Trade secrets, security and personal data remain real constraints. The Commission explains that parties can agree measures to protect trade secrets and that sharing may be withheld or suspended in defined circumstances. It also describes a narrow security route where sharing could undermine legal security requirements and cause serious adverse effects to people's health, safety or security. Personal-data access and sharing still require the applicable data-protection basis. The useful response is a specific control or bounded exception, such as a confidentiality term, filtered field, secure environment or named role. A blanket statement that all machine data is proprietary leaves the buyer unable to assess the actual boundary.
Several practical failures remain possible even with a detailed schedule. The data holder may be different from the equipment seller or change when a related service is added. A remote service may end while the physical asset remains. The supplier may expose current values but retain too little history for fault analysis. A technically open format can still use undocumented codes. A buyer may also demand a broad feed without securing its own storage, access reviews, cybersecurity controls or data stewardship. The schedule creates a testable boundary; it does not operate the data estate for either party.
The 15-minute move
Take one connected asset currently being specified or renewed. Write down one maintenance decision that depends on its data. Under it, list the five signals or events needed, the required history, the acceptable delay, the destination system and the outside role that may need access. Send that single page to engineering, IT, security, procurement and legal for gaps. It is enough to expose whether the current RFQ is buying an operating data path or hoping one appears after award.