- Who it's for
- Manufacturers and operators of connected products: machinery and plant engineering, IoT, service and the spare parts market.
- What you can do next
- Work out for one product line which data is created, who may access it, and what a newly placed product has to have designed in.
- As of
- March 2026
The EU Data Act applies from 12 Sep 2025 — and for new connected products, additional obligations (design for data access) apply for products placed on the market after 12 Sep 2026. For classic Mittelstand manufacturers and operators, this is not “a legal topic”. It’s product + contracts + integration.
The two key dates at a glance
From 12 Sep 2025 the Data Act applies in general. From 12 Sep 2026 the obligation from Art. 3(1) is added on top, for connected products and related services placed on the market after 12 Sep 2026. The primary source for both is Regulation (EU) 2023/2854.
Translation: whatever you’re designing now must be “data-access-ready” by 2026 — otherwise you’ll pay in retrofits and support.
Who this typically hits in the Mittelstand
If you’re one of these, you should care:
- Machine/plant builders with sensors, remote monitoring, service portals
- OEMs/manufacturers of connected products (IoT/telematics)
- Service providers around the product (maintenance, optimisation, predictive maintenance)
- Aftermarket ecosystems (repair, spare parts, third-party services)
What “data access” means in practice (no legal poetry)
You need crisp answers to four questions:
- What data is generated? (product data / related service data; raw vs derived insights)
- Who is the “user” and who is the “data holder” in your setup?
- How does the user access the data? (UI, export, API, on-device)
- How do we enable third-party access without blowing up security/GDPR/IP?
5 failure modes I keep seeing (and how to fix them)
- 01No real data inventoryFix: one data map per product line.
- 02Contracts aren’t data-sharing-readyFix: standard clauses and a decision matrix — what’s default, what needs approval.
- 03A portal is not an interfaceFix: a minimal API with scopes, audit logs, quotas and versioning.
- 04The cost model is ignoredFix: an internal cost model and a clear “standard vs custom” boundary.
- 05Nobody owns itFix: one owner and a small steering group of product, legal, IT/security and service.
1) No real data inventory (or it’s fantasy)
A sensor list is not a usable data product, and the metadata that actually matters is usually missing: timestamps, units, context.
Fix: one data map per product line (workshop + cleanup).
2) Contracts aren’t “data-sharing-ready”
Rights and responsibilities are vague in the B2B contracts, and standard clauses for user access and third parties don’t exist in the first place.
Fix: standard clauses + a decision matrix (what’s default, what needs approval).
3) Interfaces: “we have a portal” is not enough
A UI without export or API becomes a support nightmare — and an API without scopes and rate limits becomes a security nightmare.
Fix: a minimal API with scopes, audit logs, quotas, and versioning.
4) Cost model is ignored
Data access isn’t free: it costs operations, meaning infrastructure and support. It costs security, meaning monitoring and incident response. And it costs product maintenance as soon as the schema changes.
Fix: an internal cost model + a clear “standard vs custom” boundary.
5) Nobody owns it
Legal says IT will do it. IT says product will do it. And product says legal will do it.
Fix: one owner + a small steering group (product, legal, IT/security, service).
- list of connected products + related services (per product line)
- roles clarified: user / data holder / third party (typical scenarios)
- data map: what data exists, where it’s generated, how it’s accessible
- minimum access mechanism decided (UI/export/API/on-device)
- standard contract clauses for access + third parties
- security/GDPR: scopes, auth, logging, retention
- support process: requests, SLAs, abuse, suspension
- cost model + “standard vs custom” decision
2026 is a product deadline (not just a legal date)
If you plan to ship new devices or services in 2026, the Data Act is a design constraint: the data must be accessible rather than trapped in a black-box cloud silo, the interfaces must be maintainable and secure, and every change to them needs versioning and compatibility.
- schemas/data model defined (units, time, context)
- export/API designed (scopes, rate limits, audit trail)
- derived insights clearly separated from raw/product data
- monitoring: access, errors, cost, abuse
- versioning: v1/v2, deprecation policy, migration path
- documentation: what’s available, examples, limits
- security by default: least privilege, key rotation, incident playbook
Quick win: an internal “Data Act” mini app instead of Excel chaos
No one wants a 6‑month programme. Fair.
I build a small internal app that covers what teams actually need: a product and service catalog with roles (user, data holder), a data map per product line with data, interface and owner, the tasks and deadlines for everything placed on the market after 12 Sep 2026 — and reusable templates for contract and security checks.
Give me 30 minutes: I’ll outline Data Act readiness for your top 1–2 product lines and show which internal mini app gives you the biggest leverage.
Primary source (for reference): Regulation (EU) 2023/2854 (Data Act), in particular the general applicability (“shall apply from 12 September 2025”) and the additional applicability of the Art. 3(1) obligation for products “placed on the market after 12 September 2026”.