For Thailand-based exporters, EU Data Act industrial machinery readiness is not a last-minute exercise in adding a CSV button or a cloud endpoint. The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025. Under Article 50, the Article 3(1) access-by-design obligation applies to connected products and related services placed on the EU market after 12 September 2026. That is a market-placement threshold for relevant new products—not an instruction to redesign every legacy machine installed in Europe on that date.
This guide gives machine builders, industrial IoT vendors, systems integrators and factory buyers a practical procurement package: applicability, role allocation, a data inventory, pre-contract disclosure, direct versus data-holder-mediated access, metadata, safeguards, contract ownership and FAT/SAT evidence. The 90-day plan below is a TOMAS TECH project proposal, not a statutory grace period. An API is one implementation option; the law does not mandate a particular API, protocol or product architecture.
Executive decision: who should act and what “ready” looks like
Act now if your company sells or leases connected machines into the EU, supplies a related remote-monitoring service, stores machine data in an OEM cloud, or writes RFPs for equipment used at an EU factory. A Thailand establishment does not by itself remove the issue: the regulation covers manufacturers placing connected products on the EU market and providers of related services irrespective of where they are established.
The useful deliverable is not a generic “compliant” badge. It is a model-specific evidence pack showing who the user and data holder are, which data and metadata are available, how the user obtains them or directs them to a third party, what safeguards apply, and how the complete path was tested.
| Management question | Weak answer | Release-ready answer |
|---|---|---|
| Which products are in scope? | “Our IoT range is covered.” | Model, related service, EU placement date and transaction-specific decision record |
| Which data are supplied? | “Machine logs.” | Field-level inventory of source, processing stage, metadata, frequency and location |
| How are they supplied? | “We have an API.” | Direct/mediated route, identity, format, QoS, outage, retrieval and deletion process |
| What is protected? | “Everything is confidential.” | Item-level trade-secret, personal-data, security and safety assessment with safeguards |
| How is completion proven? | “The dashboard works.” | Contract annex, FAT/SAT cases, logs, exception approvals and user instructions |
Applicability decision tree: date, product, service and roles
Start with the two dates and do not merge them. The Data Act generally started applying on 12 September 2025. The Article 3(1) product-design obligation applies to connected products and related services placed on the EU market after 12 September 2026. There is no general statement in that rule that all installed machines must be rebuilt, nor is there a statutory 90-day grace period.
Next, identify the connected product and any related service at model level. Industrial machinery and robots are examples given by the European Commission. Review whether the product obtains, generates or communicates data about its use, performance or environment, and whether remote monitoring, maintenance or optimisation services are linked to its functions.
Roles follow the transaction and actual control, not a company label. A user can be a business or person that owns, rents or leases the product. The data holder is the party legally or practically able and obliged to make the relevant data available. An OEM, distributor, cloud provider and service company may all be involved, so the contract map must match the real permission model.
| Step | Decision question | Evidence | If unresolved |
|---|---|---|---|
| 1. Market placement | When is the model or unit placed on the EU market? | Import, sale, lease and shipment records | Confirm the scenario with EU counsel |
| 2. Connected product | Does it obtain, generate or communicate relevant data? | Functional specification, architecture, interface list | Obtain model-owner approval |
| 3. Related service | Is the digital service connected to product functionality? | Service description, terms and SLA | Assess product and service together |
| 4. User | Who owns, rents or leases the product? | Commercial and asset-use contracts | Split the assessment by use model |
| 5. Data holder | Who can make the relevant data available? | Access matrix, cloud contract, operating model | Resolve vendor and subcontractor ownership |
Do not treat an FAQ or sales representation as the legal decision. The Commission’s FAQ v1.4 is useful implementation guidance, but it is not legislation. Under Article 7, the Chapter II exemption for a micro- or small enterprise is conditional, including on there being no non-qualifying linked or partner enterprise and on the micro- or small enterprise itself not being subcontracted by another party to manufacture or design a connected product or provide a related service. This concerns work contracted out to the enterprise; it is different from the enterprise hiring its own subcontractor. Confirm the facts with EU counsel.
Define the data boundary before choosing technology
“Machine data” is too broad to procure or test. Commission guidance describes Chapter II as covering raw and pre-processed data readily available to the data holder, together with relevant metadata. Inferred or derived data and content sit outside that described access scope. Classification still requires a technical and legal assessment of each signal and processing step.
| Data class | Machinery example | Practical treatment | Inventory fields |
|---|---|---|---|
| Raw | Temperature, vibration, current, cycle and alarm events | Evaluate field by field as an access candidate | Sensor, unit, timestamp, sampling and missing-data rule |
| Pre-processed | Calibrated value, filtered vibration, normalised state code | Candidate where readily available | Transformation, calibration, quality and source link |
| Inferred/derived | Remaining useful life, failure prediction, proprietary quality score | Review separately; do not assume automatic inclusion | Model, IP, inputs and contractual offer |
| Personal | Operator ID, access history, video or location | Requires a separate GDPR basis and controls | Data subject, purpose, retention and permission |
| Trade-secret-bearing | Recipe, control tuning, unique tolerance or customer condition | Apply proportionate safeguards; avoid blanket refusal | Secrecy basis, scope, NDA and technical control |
| Content | User-authored documents or protected visual content | Assess separately from product data | Rights holder, purpose, location and terms |
Create a field-level inventory, not merely a tag list. Record source, owner, location, processing stage, meaning, unit, time basis, quality or uncertainty, retention, retrieval route, relationship to the user, third-party availability, and personal-data or trade-secret flags. Give every field a stable identifier so product engineering, sales disclosure, contract drafting and FAT/SAT refer to the same object.
Do not confuse this boundary with a Digital Product Passport. A DPP concentrates on product identity and lifecycle information; this project concentrates on data generated through the use of a connected product and related service. For the adjacent DPP workstream, see our Thailand exporter DPP readiness guide.
Turn Article 3(2) disclosure into a sales deliverable
Before contracting, the buyer should be able to understand the type, format and estimated volume of data; whether it is generated continuously or in real time; whether it is stored on-device or remotely and for how long; and how it can be accessed, retrieved or erased. The technical means, terms and quality of service should also be clear.
| Disclosure item | What the proposal should state | Owner after award | Acceptance evidence |
|---|---|---|---|
| Type, format and volume | Data dictionary, format, estimated records and event/time-series class | Product and data engineering | Sample matches the dictionary |
| Generation | Continuous, periodic, event-driven or batch | Controls/IoT engineering | Test at representative load |
| Storage and retention | On-device, edge and cloud location plus policy | IT/service operations | Configuration, deletion and restore evidence |
| Access route | Local, portal, bulk, API or request to data holder | Product owner | Valid, rejected and expired request tests |
| Retrieval and erasure | Identity check, authority, workflow and audit | Support/security | User action and audit trail |
| Terms and QoS | Format, update method, constraints, planned outage and support | Service management | Test against the agreed specification |
Do not invent “EU standard” uptime, retention or latency figures. State values justified by the product and agreed commercial service, then make them testable. Separate data that is useful in real time from data for which a secure batch path is appropriate.
The contract should also govern the data holder’s use of non-personal product data. Do not bundle remote maintenance, benchmarking, product improvement and AI training under one vague “service improvement” purpose. Specify purpose, scope, onward sharing and a practical way to manage the agreement.
Access architecture: direct and mediated paths
Article 3(1) is outcome-oriented: product and related-service data, plus relevant metadata, should be easy and secure to access, free of charge to the user, comprehensive, structured and in a commonly used machine-readable format; where relevant and technically feasible, they should be directly accessible. An API is an implementation example, not a legally mandated technology. A secure file export, bulk download, message stream, local interface or cloud endpoint may all form part of a suitable design.
Direct access lets an authorised user obtain data from the product or a nearby edge layer without a case-by-case request to the data holder. It supports local analytics and data sovereignty, but needs identity management, network separation, resource controls, version compatibility and decommissioning procedures. Mediated access uses a data-holder portal or service. It can simplify central permissions but creates dependencies on request handling, availability, jurisdiction and vendor operations.
| Design factor | Direct access | Data-holder-mediated access | RFP decision |
|---|---|---|---|
| Typical route | On-machine or edge interface | Cloud, portal or request service | Authoritative route per data field |
| Benefit | Local integration and lower dependency | Central identity, updates and sharing | Match the user’s purpose |
| Risk | OT load, rogue access, version drift | Outage, friction and lock-in | Define fallback and incident process |
| Identity | Device, user and application | Tenant, user and recipient | Issue, rotate, revoke and audit |
| Metadata | Versioned with schema | Delivered through catalogue/response | Unit, time, quality and version |
| Test | Load, disconnection, permission, update | Request, sharing, outage, expiry | Expected FAT/SAT result |
Metadata makes the numbers usable. “38.4” is unsafe without knowing the unit, timestamp semantics, calibration state, missing-data policy and firmware context. Describe dataset content, collection method, use restrictions, licence, quality or uncertainty, format, vocabulary and technical access mechanism.
For adjacent implementation detail, our Thailand IIoT interoperability guide helps structure interface evidence, while the ETSI EN 303 645 IoT security evidence guide helps organise product-security evidence. Neither is a substitute certificate for Data Act readiness.
Data contract and RFP responsibility matrix
Technology cannot answer who responds to whose request. The Commission has published non-binding model contractual terms covering data holder–user, user–data recipient and data holder–data recipient relationships. They are voluntary starting points, not compliance certificates or substitutes for legal review.
| Deliverable/activity | Machine OEM | IoT/cloud vendor | EU sales/service | Factory user | Data recipient |
|---|---|---|---|---|---|
| Model and placement decision | R | C | A | I | I |
| Data inventory and metadata | A/R | R | C | C | I |
| Access and identity design | R | A/R | C | C | I |
| Pre-contract disclosure | C | C | A/R | I | I |
| User check and recipient nomination | I | R | A | R | C |
| Trade-secret safeguards | A/R | R | C | C | C |
| FAT/SAT evidence | A | R | C | R | I |
| Incident, deletion and exit | R | A/R | R | R | R |
Here A means accountable, R responsible, C consulted and I informed. In this example the OEM is accountable for the consolidated FAT/SAT evidence; the factory user is responsible for executing and recording site acceptance tests. Replace the assignments with the actual parties. Address subscription termination, machine resale, lease return, user change and cloud-provider replacement before shipment. Specify credential revocation, data return, retention, deletion and audit evidence.
For third-party sharing, build a controlled path for a recipient chosen by the user. Verify the user, identify the recipient, scope data and duration, record the purpose and conditions, enable revocation and preserve an audit trail. That is different from exposing an unrestricted endpoint.
Guardrails for trade secrets, cybersecurity, safety and GDPR
Access does not mean removing protection. For trade-secret-bearing data, combine item-level classification with purpose limits, restricted personnel, confidentiality commitments, controlled environments and logging. A confidential label alone is not a blanket basis to refuse access. The regulation’s stricter route concerning a likelihood of serious economic damage requires careful evidence and process.
Likewise, security is not a generic exemption. Restrictions under Article 4 require the relevant security requirements in EU or national law and a serious adverse effect on health, safety or security, with applicable notification steps. “It is OT” is not a sufficient decision record.
| Risk | Avoid | Practical safeguard | Approval owner |
|---|---|---|---|
| Trade secret | Classify every field as secret | Evidence per field, minimum scope, NDA, controlled environment | Legal and business owner |
| Machine safety | Disable access as a default | Read-only separation, load limits, independent safety path | Machinery safety owner |
| Cybersecurity | Shared permanent credentials | Unique identity, least privilege, revocation, audit and updates | Product security owner |
| Personal data | Export it as ordinary product data | Legal basis, purpose limit, minimisation and rights process | DPO/privacy owner |
| Availability | Unlimited ungoverned streaming | Capacity, priority, rate control and fallback | Product/service owner |
Where operator IDs, video or location are present, the Data Act discussion does not automatically provide a GDPR legal basis. Assess necessity, minimisation, retention, transparency, international transfer and data-subject rights separately. Legal, privacy, safety and product-security owners should approve against the same inventory.
FAT/SAT: break the pathway, not just demo the screen
A FAT should test permissions, disconnection, time drift, schema change, missing data, third-party sharing and contract exit—not only a successful download. SAT repeats critical cases with the real network, user identities, factory policies and intended recipient.
| Test | Condition | Expected result | Evidence | Failure gate |
|---|---|---|---|---|
| DA-01 | Authorised user requests data | Agreed scope, format and metadata | Output, dictionary and audit log | Fix and retest |
| DA-02 | Unauthorised requester | Denial, reason and auditable record | Identity and notification logs | Security stop |
| DA-03 | User nominates a third party | Only approved scope and duration | Authority, token and receipt | Conditional release |
| DA-04 | Network loss and recovery | Documented loss, buffering and duplicate behaviour | Fault and replay logs | Recovery rework |
| DA-05 | Schema/firmware change | Version control, compatibility and notice | Old/new comparison | Change-control stop |
| DA-06 | Clock drift, gap and outlier | Quality and uncertainty are represented | Source and transformation evidence | Data-quality rework |
| DA-07 | Contract end or resale | Revocation, return, retention and deletion execute | Revocation/deletion evidence | Shipment stop |
| DA-08 | High access load | Control and safety remain unaffected | PLC, network and load logs | Safety review |
Include semantic checks: units, time zone, clock synchronisation, quality flag, calibration state, model and firmware version. A value can be technically retrievable and still be unusable or dangerous when interpreted incorrectly.
Classify results as pass, conditional pass, retest or stop. A cosmetic label defect must not be treated like cross-tenant exposure or interference with a safety function. Serious permission, safety and personal-data defects should stop release.
A 90-day readiness plan with release gates
The following is a TOMAS TECH delivery design—not a statutory grace period. The objective is to take one first in-scope model through a release gate, rather than declare an entire portfolio ready.
| Period | Work | Completion condition | Gate |
|---|---|---|---|
| Days 1–15 | Confirm model, placement, roles and related service | Signed applicability and ownership record | STOP for EU counsel if unresolved |
| Days 16–30 | Build inventory, boundary, metadata and risk flags | Every priority field has owner and rationale | REWORK gaps |
| Days 31–45 | Design direct/mediated access, identity, logs and sharing | Architecture, threat and permission reviews pass | STOP on safety impact |
| Days 46–60 | Draft disclosure, data contract, RFP and support procedure | Technical and contractual scope match | REWORK mismatches |
| Days 61–75 | Implement pilot, FAT and fault injection | No critical defect; evidence pack complete | Conditional/retest decision |
| Days 76–90 | SAT, operator training and release review | Owner sign-off, due dates and version lock | RELEASE or STOP |
Complete one vertical chain early: sensor to machine, edge, metadata, authorised user, selected recipient and audit record. Once that chain passes, extend the pattern to additional signals. This avoids building a large endpoint before the data boundary and responsibilities are stable.
The release board should verify five linked outcomes: INVENTORY has rationales and owners; CONTRACT matches the actual implementation; ACCESS works for the user and nominated recipient; TEST covers normal, fault, change and exit; and RELEASE contains no unresolved critical safety, security, privacy or role issue.
Buyer’s RFP checklist
Ask bidders for comparable evidence rather than a “Data Act compliant” claim:
- Identified product, related service, expected placement date, user and data-holder candidates
- Field-level data, metadata, format, volume, frequency, storage, retention and processing stage
- Rationale for raw, pre-processed, derived, personal and trade-secret classifications
- Direct or mediated access choice per dataset and fallback route
- Authentication, authorisation, recipient nomination, revocation and audit process
- Pre-contract disclosure, data-use agreement, sharing terms and support workflow
- Trade-secret, privacy, security and machine-safety safeguards with named approvers
- FAT/SAT cases, data, pass criteria, remediation deadline and handover evidence
- Schema, firmware and cloud change notification, compatibility and retest rules
- Responsibility continuity when a subcontractor or cloud provider changes
Price the operating model as well as development: maintain the dictionary, verify users, enable recipient sharing, answer requests, preserve audit logs, manage schema versions and execute contract exit. Keep user access obligations distinct from value-added analytics or maintenance services.
Frequently asked questions
What does EU Data Act industrial machinery readiness involve?
It combines model and role decisions, a field-level inventory, relevant metadata, a usable access and sharing path, pre-contract disclosure, agreements for use and sharing, safeguards, and FAT/SAT evidence. It is a product-and-contract system, not a single export feature.
Must every installed machine be redesigned on 12 September 2026?
No such blanket claim should be made. Article 50 applies the Article 3(1) design obligation to connected products and related services placed on the EU market after 12 September 2026. Treatment of inventory, upgrades or remanufactured equipment depends on the facts and should be confirmed with EU counsel.
Does the Data Act mandate an API?
No. An API is one practical implementation. The legal requirement is outcome-oriented and does not mandate a specific protocol. Choose direct local access, bulk export, messaging, a portal or an API according to the dataset, user purpose and technical feasibility.
Is there a statutory 90-day grace period?
No. The 90-day programme in this article is TOMAS TECH’s project proposal for reaching a controlled release decision. It is not a grace period granted by the regulation.
Can trade secrets or cybersecurity justify refusal?
Not through a blanket label. Assess the specific data, legal conditions, likely harm, proportionate safeguards and required procedure. Refusal or restriction routes have strict conditions; obtain EU legal advice and involve the competent authority where appropriate.
Conclusion: make data handover part of machinery release
EU Data Act readiness should sit inside the product release gate. Applicability, roles, data boundary, metadata, access, identity, third-party sharing, safeguards, contracts and FAT/SAT must describe the same operating reality. Start with one EU-bound model and one complete data chain; connect every field to its contract term and test case.
TOMAS TECH can help Thailand-based machine builders and factories structure the technical work: model workshop, data inventory, access architecture, RFP annex and FAT/SAT design. Final legal conclusions remain with qualified EU counsel, but the engineering can be made testable from the concept and quotation stage. To discuss an early-stage assessment, contact TOMAS TECH.
Legal note: This article provides general technical and procurement information, not legal advice. Confirm applicability, role allocation, GDPR, trade-secret, security, safety and contractual decisions with qualified EU counsel and, where appropriate, the competent authority.
Primary references
- Regulation (EU) 2023/2854 — official text, especially Articles 1, 3, 4 and 50.
- European Commission — Data Act explained, on connected products, data scope, roles, sharing and trade secrets.
- European Commission — Data Act FAQ v1.4, 22 January 2026, implementation guidance rather than legislation.
- European Commission — Non-binding Model Contractual Terms, voluntary terms for the three principal relationships.
- European Commission — Data Act application announcement, on application from 12 September 2025.
- Interoperable Europe — Rolling Plan for ICT Standardisation 2026: Data interoperability, implementation context for dataset description and access means.
