By September 2026, your connected products must support "access by design" under the EU Data Act. This means users can directly access telemetry, sensor outputs, and machine-generated insights from your devices in structured, machine-readable formats. You'll also need to honor user requests to share that data with third parties they choose.
If you manufacture industrial equipment, smart appliances, or medical devices sold in the EU, you're facing a dilemma: how do you grant broad data access without exposing the diagnostic algorithms, performance models, and operational logic that differentiate your products from competitors?
Some teams argue that opening up device data threatens intellectual property. Others see it as an opportunity to unlock new revenue streams and strengthen customer relationships. The regulation acknowledges this tension by including a "trade secrets handbrake" mechanism that lets you withhold certain data under specific conditions.
Let's examine both positions.
Prioritizing IP Protection
Your engineering team spent years refining algorithms that predict equipment failures or optimize energy consumption. These models are trained on proprietary datasets, and the telemetry they generate can reveal how your system makes decisions. If you hand over raw sensor data and diagnostic outputs to third-party service providers, you're essentially giving competitors a roadmap to reverse-engineer your competitive advantage.
The trade secrets handbrake exists for this reason. Before disclosing data that may contain commercially sensitive information, you can identify which elements constitute trade secrets, require confidentiality agreements, and demand technical safeguards like anonymization or aggregation. If the requesting party can't agree to adequate protections, you can refuse disclosure.
This isn't a loophole. You can't blanket-label everything as proprietary. But you can draw defensible boundaries around production methods, algorithmic performance metrics, and design insights that genuinely differentiate your product. If your diagnostic logic is what customers pay for, protecting it is a legitimate business interest.
Once data leaves your control, you lose visibility into how it's used. The Data Act prohibits third parties from using shared data to create competing products, but enforcement depends on detecting violations after the fact. If a maintenance provider builds a diagnostics platform using telemetry from dozens of manufacturers, proving misuse becomes complicated.
For companies where margins depend on proprietary analytics or where after-market services represent significant revenue, the instinct to protect first and share later makes sense.
Embracing Data Access
The counterargument is that you're already losing control of the data relationship, and the Data Act formalizes what customers increasingly expect. Industrial buyers want vendor-neutral monitoring platforms. Fleet operators want to consolidate telemetry from multiple equipment types. Hospitals want interoperable medical device data that feeds into unified patient records.
If you design for restricted access, you're positioning yourself as the bottleneck in ecosystems moving toward openness. Competitors who build transparent, user-centric data architectures will win contracts you lose.
There's also an economic opportunity here. Companies that modernize their data infrastructure now can offer premium analytics services, expand into maintenance markets previously closed by proprietary constraints, and build trust by marketing themselves as Data Act-ready. When users can pull data easily, they're more likely to buy additional products from you because integration is frictionless.
The trade secrets handbrake isn't a shield, it's a negotiation tool. Instead of treating every data request as a threat, you can use it to structure partnerships with third-party providers. Require confidentiality agreements, limit data use to specific purposes, and build monitoring into your sharing workflows. The regulation already prohibits misuse of trade secret-protected data and imposes legal consequences for violations.
And let's be clear about what the Data Act actually covers: usage-generated data, not your underlying IP. Your algorithms, source code, and training datasets remain protected. What you're sharing is the output, and if you can't differentiate your product based on the value you add to that output, you have a bigger problem than regulatory compliance.
Where Practitioners Actually Land
In practice, most teams are splitting the difference. They're building tiered access models that provide basic telemetry to all users while reserving advanced diagnostics and predictive insights for customers who contract directly with the manufacturer.
They're also investing in data classification frameworks that distinguish between commodity telemetry (which poses little IP risk) and proprietary analytics (which require safeguards). This lets them respond to access requests quickly for low-risk data while triggering the trade secrets handbrake only when necessary.
On the commercial side, forward-looking companies are using the Data Act as a catalyst to rethink their service models. Instead of locking customers into closed ecosystems, they're offering data-enabled services that compete on quality, not exclusivity. If your diagnostics are genuinely better than what third-party providers can build, customers will pay for them even when they have access to the underlying telemetry.
Next Steps
You can't ignore the IP risks, but treating the Data Act as purely a compliance burden misses the strategic opportunity. The regulation applies extraterritorially, so if you serve EU users, you're in scope regardless of where you're headquartered. By September 2026, your new products must support direct data access. That deadline isn't negotiable.
The smarter move is to design your architecture and contracts now with both access and protection in mind. Map which telemetry genuinely contains trade secrets and which is commodity data. Build confidentiality requirements into your third-party sharing workflows. Update your user agreements to reflect data access rights while specifying the safeguards you'll require for sensitive information.
And recognize that the trade secrets handbrake is a scalpel, not a sledgehammer. Use it to protect the specific elements of your system that deliver competitive advantage, but don't use it to block access to data that users have a statutory right to receive. Courts and regulators will scrutinize overly broad assertions, and customers will remember which vendors made data access easy and which made it a fight.
The companies that will thrive under the Data Act are the ones that treat user data rights as a design constraint that forces better products, not a threat that requires defensive posturing. If your value proposition depends on restricting access to machine-generated outputs, you're competing on control rather than capability. That's not a sustainable position in a market moving toward interoperability.
