EU Data Act Trade Secrets and Protection Measures

Trade secret handling under the Data Act depends on who is asking and why. Article 4 covers access by the user of a connected product or related service. Article 5 covers sharing with a third party chosen by that user. Articles 8 and 9 then govern B2B conditions and compensation where a data holder is obliged to make data available to a data recipient.

Before adding confidentiality controls, separate product data, related service data, and the metadata needed to interpret and use those data from inferred or derived information that is outside the Chapter II access obligation unless separately agreed.

Articles 4(6) and 5(9) preserve trade secrets, but they require practical measures before disclosure. The data holder or trade secret holder must identify the protected data, including relevant metadata, and agree proportionate technical and organisational measures with the user or third party.

Useful safeguards are specific to the recipient and the data. A generic NDA can be part of the package, but the Data Act examples also point to strict access protocols, technical standards, model contractual terms, confidentiality agreements, and codes of conduct.

The Data Act distinguishes three different positions. First, the data holder may withhold or suspend sharing of identified trade secret data if the necessary measures are not agreed, are not implemented, or confidentiality is undermined. Second, the data holder who is also the trade secret holder may refuse access only in exceptional circumstances. Third, security-based contractual restrictions under Article 4(2) are a separate route tied to serious adverse effects on health, safety, or security.

A refusal based on trade secrets must be case-by-case and specific to the data in question. The data holder must be able to demonstrate that serious economic damage is highly likely despite the agreed measures, using objective elements such as enforceability of trade secret protection in third countries, confidentiality level, and the uniqueness and novelty of the connected product.

Article 11 allows appropriate technical protection measures, including smart contracts and encryption, to prevent unauthorised access to data and metadata and to enforce agreed terms. Those measures cannot discriminate between data recipients or hinder the user's Article 4 and Article 5 rights.

The control design should therefore separate access enablement from misuse prevention. Encryption, access tokens, data rooms, signed logs, API scopes, watermarking, and smart-contract controls may help preserve confidentiality, but they should not make the Data Act request right practically unusable.

Trade secret protection continues after delivery. Users may not use accessed data to develop a competing connected product or share the data with a third party for that intent, and they may not use the data to derive insights about the manufacturer's or data holder's economic situation, assets, or production methods.

Third parties receiving data at the user's request face additional limits. They must process the data only for the agreed purposes and conditions, erase it when no longer necessary unless otherwise agreed for non-personal data, avoid unauthorised onward sharing, preserve trade secret measures, and avoid gatekeeper onward sharing.

A useful Data Act trade secret file shows the request, the actor roles, the protected data, the safeguards proposed and agreed, the delivered data, and any written decision to withhold, suspend, or refuse. It should also show that verification and access logs were kept only as needed for request execution and infrastructure security or maintenance.

If a user or third party challenges a withholding, suspension, or refusal, the file should support the competent-authority complaint path, dispute settlement, or court review without requiring teams to reconstruct the facts later.

The most common implementation error is treating trade secret protection as a broad exception to access. The Data Act instead expects identification, proportionate safeguards, narrow written restrictions, and challenge routes.

Another error is relying on contractual language while ignoring technical access design. A recipient can sign confidentiality terms and still create unacceptable risk if API scopes, logs, subcontractor access, export controls, or deletion controls are missing.

The practical output should be a maintained access pack that legal, product, security, and data engineering can use before a live request arrives. It should be narrow enough to avoid blocking lawful access and detailed enough to support a written Data Act decision.

For each product or related service, the pack should connect datasets, metadata, trade secret claims, recipient terms, technical measures, and escalation steps. That makes the page useful for both first-party user access and B2B third-party sharing.