Table of Contents >> Show >> Hide
- Why the EU Data Act hits connected-device manufacturers so hard
- Challenge No. 1: Scope creep is not a bug, it is a feature
- Challenge No. 2: Product design is now part of compliance
- Challenge No. 3: The aftermarket business model gets a new roommate
- Challenge No. 4: Pricing, FRAND terms, and contract surgery
- Challenge No. 5: GDPR, privacy, trade secrets, and cybersecurity all show up to the same meeting
- Challenge No. 6: Enforcement uncertainty still hurts
- Real-world examples of where pressure builds fastest
- What smart manufacturers should do next
- Extended Experience Section: What companies are discovering in the trenches
- Conclusion
- SEO Tags
The EU Data Act sounds tidy on paper: give users better access to data generated by connected products, make sharing fairer, loosen vendor lock-in, and spark more innovation. Lovely. Very European. Very logical. Then a manufacturer opens its engineering diagrams, product roadmap, data map, customer contracts, cloud architecture, privacy notices, reseller agreements, and security controls all at once and realizes this is not a neat little compliance memo. It is a full-body workout.
For manufacturers of connected devices, the law creates a real shift in power. Data that many companies once treated as part of the secret sauce now sits inside a framework that gives users stronger rights to access and share it. That does not mean manufacturers lose all control, and it definitely does not mean trade secrets get tossed out the window like yesterday’s firmware. But it does mean the old habit of “we built the device, so we own the data universe around it” is no longer a safe operating assumption.
This is where the headaches begin. The challenge is not just legal interpretation. It is product design, user interface design, API readiness, cybersecurity, customer support, contract rewriting, data classification, and governance across the entire product lifecycle. In other words, the EU Data Act is not just a law for lawyers. It is a law for engineers, product managers, security teams, and anybody else who has ever said, “We’ll fix the data layer later.” Later has arrived.
Why the EU Data Act hits connected-device manufacturers so hard
The law matters because connected products generate valuable usage data during normal operation. Think industrial machinery, medical technology, smart appliances, vehicles, agricultural equipment, wearables, and advanced sensors. That data can reveal performance trends, maintenance needs, breakdown risks, and service opportunities. For years, many manufacturers used that information to strengthen their own aftermarket services and customer relationships. The EU Data Act does not eliminate that business model, but it does put a large “shared access” sign on the front door.
That shift lands hardest on manufacturers because they sit at the center of the technical stack. They often control device firmware, software interfaces, customer dashboards, dealer networks, cloud services, and maintenance ecosystems. So when regulators say users should be able to access and share product data easily, securely, and without unnecessary delay, the burden naturally rolls downhill toward the company that designed the machine in the first place.
Challenge No. 1: Scope creep is not a bug, it is a feature
The law reaches beyond the EU map
One of the first shocks for non-EU manufacturers is territorial reach. A company does not need to be headquartered in Paris, Berlin, or Amsterdam to get pulled into this framework. If it places an in-scope connected product on the EU market or offers a related service there, the law can apply. That is a major issue for U.S. and global manufacturers that thought the regulation was someone else’s continental problem. Surprise: if your device crosses an EU border, your compliance plan probably should too.
That extraterritorial effect creates practical complications. Multinational companies now have to decide whether to build a single global product architecture that can satisfy EU access expectations, or maintain separate versions by region. Neither path is exactly cheap. One creates worldwide operational change. The other creates complexity, fragmentation, and the joy of maintaining multiple product and support models forever. Pick your favorite headache.
Not all data is equal, but someone has to sort it
Another challenge is figuring out what data is actually in scope. The Data Act focuses heavily on product data and related-service data that is “readily available.” That sounds simple until a real engineering team tries to separate raw telemetry, pre-processed data, metadata, inferred insights, diagnostic models, usage analytics, and proprietary algorithmic outputs. Suddenly the phrase “readily available” starts causing longer meetings than anyone deserves.
Manufacturers need a defensible taxonomy. Raw and pre-processed machine data may be in scope, while highly enriched or inferred data may fall outside it. But drawing that line requires discipline. If the company cannot explain what the data is, where it sits, who can access it, and how it is generated, then the legal argument gets shaky fast. Good luck claiming something is out of scope when your own internal teams cannot agree on what the label means.
Challenge No. 2: Product design is now part of compliance
“Data access by design” is no longer optional fluff
The Data Act is not only about what happens after a user asks for data. It also pushes design and manufacturing obligations. For connected products placed on the market after the relevant date, products and related services must be built so that data is accessible in a usable format. That turns data access into an architecture issue, not just a customer-service workflow.
For manufacturers, this can mean redesigning device interfaces, export tools, dashboards, and data pipelines. Products built mainly to feed a manufacturer-controlled backend may now need to support user access directly or through clear mechanisms that work in practice. In theory, this sounds like good product design. In practice, it can mean rebuilding systems that were never meant to expose clean, user-friendly, shareable outputs.
Legacy products raise another awkward question: what happens when the installed base is old, messy, or built on assumptions from a less regulated era? Even where the strict design duty applies to products placed on the market later, customers will still expect consistency across product families. So companies may find themselves managing not just legal timing but commercial pressure to modernize older platforms anyway.
Transparency before the sale creates new operational work
The law also expects clear information before the contract is signed. That means sellers and service providers need to explain, in understandable terms, what types of data the product can generate, whether data is continuous or real time, where it is stored, how the user can access it, and how sharing can be requested or ended. This sounds simple until you remember how many connected products are sold through distributors, dealers, resellers, and layered service bundles.
Manufacturers therefore need alignment between legal documents and real-world sales channels. If a glossy brochure promises smooth access while the support team later says, “Please submit a ticket and wait,” the business is asking for trouble. Pre-contract transparency is not just about checking a disclosure box. It is about making sure the commercial message matches the technical reality.
Challenge No. 3: The aftermarket business model gets a new roommate
One reason the EU Data Act feels disruptive is that it weakens exclusive control over valuable aftermarket ecosystems. A user may request that data be shared with a third party, such as an independent repair provider, monitoring service, analytics company, or optimization platform. For manufacturers that built recurring revenue around service lock-in, that is not a minor tweak. That is a strategic plot twist.
To be fair, the law does not open the gates to everything for everyone. There are protections, conditions, and restrictions. Certain gatekeepers are blocked from being eligible third parties in this access structure. Data also cannot be used to develop a competing connected product in the prohibited sense. Still, manufacturers should not confuse those protections with business continuity. Independent service markets may gain leverage, and the manufacturer’s historic advantage may become harder to defend with exclusivity alone.
This creates a difficult balancing act. A company still wants to preserve product integrity, safety, and premium service value. But it also has to enable user-directed sharing where the law requires it. The challenge is not merely complying with access rights. It is redesigning the value proposition so customers still choose the manufacturer’s service even when alternatives become easier to reach.
Challenge No. 4: Pricing, FRAND terms, and contract surgery
The Data Act also forces manufacturers to rethink how they price and structure data access in business-to-business settings. Compensation must be reasonable and non-discriminatory, and special protection exists for SMEs and some research organizations. So if a manufacturer imagined charging eye-watering “access administration fees” every time someone asked for a dataset, the law has a pretty clear message: nice try.
This means contract templates, licensing assumptions, and data monetization models need review. Terms that once favored the stronger party may not age well under the Act’s fairness logic. Manufacturers will need sharper documentation for how compensation is calculated, why it is justified, and how similar recipients are treated consistently. That is especially important when the same business sells hardware, software, maintenance, analytics, and cloud-based support in one bundled package. Untangling the economic logic behind each piece can get messy in a hurry.
There is also the less glamorous but very real challenge of contract inventory. Companies may have hundreds of reseller contracts, enterprise service agreements, dealer terms, SaaS addenda, and data-processing provisions that touch the same product ecosystem. Updating all of that is not exciting work. It is the corporate equivalent of cleaning out a garage: nobody wants to start, but everybody notices if it never gets done.
Challenge No. 5: GDPR, privacy, trade secrets, and cybersecurity all show up to the same meeting
Personal and non-personal data rarely stay in neat little boxes
The EU Data Act is not a magic override for privacy law. If personal data is involved, GDPR still matters. That is where compliance becomes more delicate for connected devices, especially in vehicles, health technology, home devices, workplace systems, and tools used by multiple individuals. The same dataset may include operational information, personal identifiers, behavioral patterns, and data relating to more than one person. Legal teams love this. By “love,” I mean they do not sleep.
Manufacturers therefore need strong rules for data minimization, legal basis analysis, separation of user roles, and permissions management. They may need anonymization, pseudonymization, filtering, or segmented access layers. The hard part is that the Data Act pushes toward usability and availability, while privacy law pushes toward necessity and restraint. Those goals can be reconciled, but only with careful design. Sloppy architecture will not survive the collision.
Trade secrets are protected, but not as a universal escape hatch
Many manufacturers hoped trade-secret protection would serve as a broad shield. The law is more nuanced. Trade secrets still matter, and in exceptional cases they may justify refusal or tighter controls. But they are not a blank check to deny access whenever data feels commercially sensitive. Companies must identify protected data carefully, use proportionate technical and organizational safeguards, and be prepared to explain why disclosure would likely cause serious economic harm.
That means trade-secret management needs to be operational, not rhetorical. Labels, access protocols, contractual restrictions, logging, and technical controls all matter. A manufacturer that casually calls everything confidential will look weak. A manufacturer that can specifically identify what is sensitive, why it is sensitive, and what safeguards are in place will be in a much stronger position.
Cybersecurity adds another layer. Exposing data access routes can create new attack surfaces. Manufacturers cannot solve one compliance problem by building another. API security, authentication, role-based access, encryption, auditability, and incident response all become part of the Data Act readiness story. In highly regulated sectors, that work also has to line up with product safety, sector-specific rules, and broader EU cyber obligations.
Challenge No. 6: Enforcement uncertainty still hurts
Even when the legal text is stable, enforcement questions remain. Member States are responsible for penalties, and companies can expect national authorities to play important roles in supervision and complaint handling. For non-EU manufacturers, there is also the requirement to designate a legal representative in the Union. That alone should tell companies this is not theoretical. Regulators intend to know whom to call when the data doors do not open.
The tricky part is that manufacturers are preparing in an environment where more guidance may continue to evolve, but commercial and technical decisions cannot wait. Businesses have to make architecture choices now, product-line choices now, contract choices now, and governance choices now, even though some implementation details may continue to sharpen over time. That is a familiar regulatory pain point: move early, but do not move foolishly.
Real-world examples of where pressure builds fastest
Industrial equipment: A manufacturer of connected compressors or robotics systems may rely on device telemetry to drive maintenance subscriptions. Under the Data Act, customers may want to route that data to a third-party service company. The manufacturer now has to support access without casually giving away proprietary insight layers.
Medical and health devices: These products may generate especially sensitive data and raise higher cybersecurity and privacy expectations. The legal overlap becomes intense because product performance data and personal data may travel together.
Vehicles and fleets: Access requests may involve multiple stakeholders, including owners, lessees, drivers, fleet managers, insurers, and repair providers. Sorting out who the “user” is in practice can become a whole project by itself.
Smart home and consumer devices: Manufacturers may need to reconcile user-friendly portability with embedded ecosystem strategies that were originally designed to keep consumers inside one branded experience. The law is not anti-ecosystem, but it is clearly anti-lock-in.
What smart manufacturers should do next
The best response is not panic. It is disciplined preparation. Manufacturers should map their product and service data, classify what is readily available, identify where personal data and trade secrets sit, test user-access workflows, revisit reseller and customer terms, and review whether product design actually supports the access promises being made. They should also build a repeatable governance model that joins legal, engineering, security, support, and commercial teams. This is not a one-department job.
Just as important, manufacturers should rethink competitive strategy. The winners under the EU Data Act may not be the companies that cling hardest to closed systems. They may be the ones that make compliance usable, trust-building, and commercially smart. If a manufacturer can provide secure access, clear controls, great service, and genuinely valuable analytics, customers may still stick around voluntarily. That is a much sturdier moat than hoping regulation never arrives.
Extended Experience Section: What companies are discovering in the trenches
Across connected-device sectors, the same pattern keeps showing up. At first, leadership teams often assume the Data Act is basically a legal notice problem. They imagine a few new disclosures, a data-request inbox, and maybe one brave intern updating the website footer. Then the internal workshops begin. Engineering says the product was never built for direct user extraction. Security says any new export path needs testing. Sales says distributors are using old product descriptions. Customer support says users already ask for reports the system cannot produce neatly. Legal quietly stares at the ceiling.
Another common experience is the great internal data identity crisis. Teams discover that different departments use different names for the same data, or worse, the same name for different data. Product teams talk about telemetry. Lawyers talk about product data. Data scientists talk about features. Support teams talk about logs. Nobody is technically wrong, but nobody is lined up either. The result is that compliance work becomes a translation exercise before it becomes a legal one.
Manufacturers also find that data sharing is not just a data problem. It is a customer-relationship problem. Once users hear they have stronger rights, they expect simple controls, fast answers, and clean exports. They do not want a philosophical essay on architecture limits. They want the button to work. Businesses that treat this as a pure legal burden may miss the practical reality that user trust often depends on whether access feels smooth rather than grudging.
In sectors with valuable aftermarket revenue, the emotional temperature can rise quickly. Service divisions worry that independent repair providers will free-ride on years of investment. Product teams worry that exposing too much data could reveal performance patterns competitors would love to study. Security teams worry that third-party access could become a weak point. Those concerns are legitimate. But companies that make progress are usually the ones that stop arguing in absolutes and start building layered controls: classify data, separate access levels, protect sensitive fields, document safeguards, and create repeatable decision paths.
There is also a surprisingly human lesson here: the companies that handle the Data Act best tend to be the ones that break down internal silos. When legal writes rules without product input, the rules become unrealistic. When engineers build tools without legal guidance, the tools may miss key restrictions. When sales promises openness without understanding the limits, support inherits the chaos. The best preparation usually comes from cross-functional teams that can speak both compliance and product.
Finally, many manufacturers discover something useful beneath the stress: better data governance often improves the business beyond compliance. Cleaner data maps help product strategy. Better access controls help security. Clearer disclosures reduce customer confusion. More transparent data practices can strengthen trust with enterprise buyers. No one throws a party because a regulation inspired cleaner architecture, but the operational payoff can be real. The trick is getting there before the deadline panic turns the whole exercise into a late-night emergency fueled by coffee, spreadsheets, and regret.
Conclusion
The EU Data Act is a serious challenge for manufacturers of connected devices because it touches the heart of how connected products create value. It changes assumptions about who can access data, how quickly it must be shared, how products should be designed, and how commercial power can be exercised in data-driven ecosystems. The law is not trying to punish manufacturers, but it is clearly trying to rebalance a market that often favored whoever controlled the hardware and the platform.
For manufacturers, the smartest approach is to treat the Data Act as both a compliance obligation and a product strategy issue. The companies that move early, classify data carefully, align privacy and security controls, and rebuild customer-facing access in a practical way will be in a stronger position. Everyone else may spend the next few years discovering that data governance problems age like milk.
