EU Data Act access-by-design rules reached a decisive milestone on 12 September 2026: connected products and related services placed on the European Union market after that date must be designed so users can obtain the data they generate easily and securely, free of charge, in a structured, commonly used and machine-readable format. The date comes directly from Article 50 of Regulation (EU) 2023/2854. It changes the compliance question for makers of connected cars, industrial machines, medical devices, fitness products, smart-home equipment and their companion services. A manufacturer can no longer treat data delivery only as a support request handled after sale; accessibility must be part of the product architecture.

Everyone else is reporting a compliance date; we are explaining why the EU Data Act turns data access into a product-engineering requirement and what manufacturers must be able to prove.

EU Data Act changes the design baseline

The EU Data Act has generally applied since 12 September 2025, but lawmakers gave the access-by-design obligation a later trigger. Article 50 states that Article 3(1) applies to connected products and related services placed on the market after 12 September 2026. That distinction matters. The regulation is not newly enacted, and the rest of its data-sharing framework did not wait until 2026. The fresh event is that new units entering the market now fall under a design obligation intended to make user access ordinary rather than exceptional.

Article 3(1) says covered data and the metadata needed to interpret and use it should be directly accessible where relevant and technically feasible. Where direct access is not feasible, the product or service must still be designed so the data are easily and securely available. The European Commission’s Data Act explainer says the regime covers data generated through use of connected products and related services, including information from cars, health devices, industrial machinery and smart-home equipment. It does not turn every internal inference or proprietary model into user data; scope depends on the statutory definitions and what is readily available to the data holder.

Policy implementation pathFour-stage path from scope to user outcome.1. IdentifyScope and owner2. DesignControls and data3. OperateDeadline and record4. ProveOutcome and audit
The new duties turn policy text into product and service operations.

What manufacturers need to map first

The first practical task is an inventory. Product teams need to identify which devices communicate data through an electronic service, physical connection or on-device access, and which companion applications qualify as related services. They then need to map raw and pre-processed data generated during use, the metadata required to interpret it, where those records reside and whether the user can retrieve them without a manual intervention. The Netherlands’ official business portal frames the obligation in similarly operational terms: businesses must tell users what data they collect, how collection occurs, how the data can be accessed, what it is used for and whether third parties can receive it.

This inventory should distinguish data that a manufacturer can lawfully obtain without disproportionate effort from data that the product never stores or transmits. The regulation’s recitals clarify that it does not create a blanket obligation to redesign every device so it stores information it otherwise would not retain. That limit is important for constrained sensors, safety systems and privacy-preserving edge products. It is equally important not to overread the limit: a company cannot deliberately make data inaccessible and then use its own architecture as a universal excuse. Engineering decisions, technical feasibility and data minimisation should be documented together.

The access route is now a product feature

DLA Piper’s September 11 analysis captures the mechanism: companies that treated the EU Data Act only as a legal project may discover that their products cannot deliver what the law expects when the first user asks. The access route could be an on-device export, a local interface, a secure application programming interface or another reliable delivery mechanism. The right choice depends on device capability, security risk and the sensitivity of the records. Whatever the route, the user should not need an opaque support escalation to retrieve ordinary in-scope data.

That creates concrete design questions. Teams must choose stable formats, document field meanings, authenticate the requesting user, separate one user’s data from another’s and rate-limit access without making it illusory. They also need a versioning plan because a product can remain in service for years while its firmware, mobile application and cloud schema evolve. A one-time export built for launch day is not enough if later updates silently remove fields or make metadata unusable. The architecture should preserve a predictable path and a clear record of changes.

Privacy and trade secrets still matter

The EU Data Act does not displace the General Data Protection Regulation. A connected product may generate information about passengers, employees, patients, tenants or other people who are not the person requesting access. Authentication and purpose controls therefore remain necessary where personal data are involved. The Commission’s explainer also notes that data holders can rely on trade-secret and security protections in defined circumstances, but refusal is not a casual option. When access is suspended, withheld or denied on those grounds, the data holder may have notification and justification duties.

The better operating model is classification rather than blanket denial. Data teams should tag personal data, confidential technical information, safety-critical fields and ordinary telemetry separately. Legal and security teams can then define which fields are delivered directly, which require identity or authority checks, and which exceptional restrictions need a recorded decision. This is similar to the evidence discipline in other technology rules. Lapaas Voice’s coverage of South Korea’s wider technology-secrets law shows why companies benefit from knowing which information is protected and who approved a transfer before an incident occurs.

Layered compliance controlsFour layers from governance to evidence.Board ownership and accountable policyProduct, process and customer controlsExceptions, escalation and remediationTimestamped evidence and review
Effective compliance connects governance, operating controls and evidence.

Aftermarkets are a central economic objective

The Commission describes user control as a way to create more choice in repair, maintenance and other data-based services. A factory owner that can retrieve machine data may be able to use an independent maintenance provider. A driver may authorise a repair shop or insurance service to use relevant vehicle information. A farmer may combine equipment data with another analytics platform. These possibilities explain why access must be usable, not merely technically present. A proprietary dump with undocumented fields would preserve the manufacturer’s practical lock-in even if a file could be downloaded.

For startups, the rule can open markets while also raising implementation costs. New service providers may gain lawful access to inputs previously controlled by equipment makers, but startups that manufacture connected products inherit the same design burden as larger rivals unless a specific statutory exemption applies. Product roadmaps should therefore price in export interfaces, consent management, metadata documentation, security review and support. The policy opportunity is real, but it rewards companies that can turn rights into dependable workflows.

What the September milestone does not mean

The date does not mean every device already in use became non-compliant overnight. The Article 3(1) trigger is linked to products and related services placed on the market after 12 September 2026. Nor does the rule require a manufacturer to expose secret algorithms, generate data the device does not otherwise hold or abandon cybersecurity controls. It also does not resolve every dispute over who is a user, what counts as readily available data or when direct access is technically feasible. Those questions will be shaped by regulator guidance, enforcement and eventually court decisions.

Businesses should resist two opposite mistakes. The first is assuming the delayed date made the entire EU Data Act irrelevant until now; most of the regulation has applied since 2025. The second is treating the new milestone as a command to publish all device data without authentication or safeguards. The statute requires easy and secure access. Both words matter. A defensible design lets authorised users obtain in-scope information while preserving privacy, safety and legitimate confidentiality.

An implementation checklist for connected-product teams

Start with a release-by-release placement-on-market record. For every product line, record the first distribution or use event relevant to the EU market and tie it to the hardware, firmware and service version. Next, maintain a data dictionary that names each generated field, its source, retention period, sensitivity, lawful basis and delivery route. Assign an accountable product owner, not only a lawyer, because the obligation lives in architecture and user experience.

Then test access as a customer would. Can an authorised user find the export route, understand the format, retrieve complete data and use the metadata without contacting engineering? Can the system distinguish business users, consumers and authorised third parties? Are error messages and refusals recorded with reasons? Finally, rehearse conflict cases involving another person’s data, safety limits or trade secrets. The strongest evidence is not a policy slide; it is a repeatable test showing that a real user can obtain the right data securely.

The broader lesson resembles the operational shift described in our report on bank-fintech risk guidance: a statutory clock or design rule exposes gaps that cannot be repaired by legal wording alone. It also connects with the Hyundai data flywheel, because trustworthy connected-product data depends on identity, integrity and auditable systems.

EU Data Act facts table

Regulation Regulation (EU) 2023/2854
Fresh milestone Article 3(1) applies after 12 September 2026
Who is affected Manufacturers of connected products and providers of related services placed on the EU market
Required outcome Easy, secure, free access to in-scope data and necessary metadata
Format Comprehensive, structured, commonly used and machine-readable
Key safeguards Privacy, security, trade secrets and technical feasibility

EU Data Act FAQs

What changed on 12 September 2026?

The access-by-design obligation in Article 3(1) began applying to connected products and related services placed on the market after that date.

Does the EU Data Act apply only to consumer gadgets?

No. Connected cars, industrial and agricultural machinery, health devices, fitness products and smart-home equipment can all fall within scope.

Must companies expose algorithms and trade secrets?

Not automatically. The regime covers defined product and related-service data, while preserving safeguards for privacy, security and trade secrets.

What should a product team do first?

Map products, generated data, metadata, users and delivery routes, then test whether an authorised user can retrieve the information securely without a manual support workaround.

Sources

Get the day’s top stories in your inbox

One concise email. No spam, unsubscribe anytime.