EU Data Act for Connected Microinverters: A Data-Access Checklist for Distributors

Updated 24 September 2026: the EU Data Act has applied generally since 12 September 2025. Its Article 3(1) design obligation now applies to connected products and related services placed on the market after 12 September 2026. For a Wi-Fi microinverter program, data access is therefore a product and contract requirement—not merely a feature inside the monitoring app.

A distributor may see one dashboard, while the connected system generates channel power, voltage, temperature, alarms, gateway status, configuration events and service logs across several layers. Before ordering, the parties need to know which data are generated, which are readily available to a data holder, who the user is, how access works and what may be shared with a third party.

This article is a B2B procurement framework. It does not determine the legal status of a specific dataset or replace the Data Act, GDPR, trade-secret analysis, cybersecurity requirements or advice from a competent authority.

Confirm that the commercial system is a connected product

The Data Act defines a connected product as an item that obtains, generates or collects data about its use or environment, can communicate product data through an electronic communications service, physical connection or on-device access, and is not primarily designed to store, process or transmit data on behalf of another party.

Map the complete saleable configuration:

• Microinverter model, firmware and measurement channels
• Integrated radio or separate gateway/data-transfer unit
• Installer and end-user mobile applications
• Web portal, APIs and downloadable reports
• Cloud analytics, alerting and remote configuration
• Related services that affect product behavior or functions
• Legal manufacturer, seller, installer, user, data holder and service providers

Do not assume that the enclosure generating electricity is the only relevant product. Conversely, do not label every cloud dashboard a related service without testing the statutory definition and contract. Record each role, entity and data flow.

Separate four dates and duties

Requirement	Practical timing	Procurement action
Data Act general application	Since 12 September 2025	Review user access, sharing, contracts and data-holder behavior
Article 3(1) access-by-design	Products/services placed on the market after 12 September 2026	Verify architecture makes data and metadata accessible by default
Pre-contract information	Before purchase, rental or lease contract	Supply a clear data notice before the buyer is bound
Access on simple request	During use where direct access is unavailable	Provide readily available data without undue delay

The date gate is linked to placement on the market, not merely the engineering release date. Keep a controlled record of model, production batch, first EU placement, related-service version and contract template used.

Build a microinverter data inventory

Start with data generated through product use, not every value in the supplier's business systems. Classify raw and pre-processed data separately from inferred or highly enriched analytics.

Data family	Example fields	Buyer question
Generation	AC power, energy, DC input, per-channel output	Granularity, timestamps and units?
Electrical condition	Voltage, frequency, current, power factor	Measured, calculated or filtered?
Device health	Temperature, derating, fault and alarm code	Does export include code definitions?
Connectivity	Gateway status, signal, last contact	Is network/user-identifying data mixed in?
Configuration	Grid profile, limits, update and reset events	Which roles may view or change settings?
Service history	Firmware version, diagnostics, maintenance events	Which records are product data versus service records?

For every field, record source device, sampling interval, aggregation, units, retention, transformation, export format, metadata and whether the data holder can obtain it without disproportionate effort. The Data Act does not create a blanket requirement to generate or indefinitely retain every technically possible value.

Test access instead of accepting an API promise

Article 3(1) requires product data and related-service data, with the metadata needed to interpret and use them, to be accessible by default easily, securely and free of charge in a comprehensive, structured, commonly used and machine-readable format. Direct access is required where relevant and technically feasible.

Where the user cannot access data directly, the data holder must make readily available data accessible on a simple electronic request, without undue delay and at the same quality available to the data holder. Where relevant and technically feasible, access should be continuous and real time.

Run a sample test covering:

1. User identity and entitlement verification
2. Single-site and fleet-level export
3. Date range, timezone, sampling and units
4. Machine-readable format and stable field definitions
5. Metadata, alarm dictionary and missing-data markers
6. Export completeness against portal charts
7. Request status, delivery time and error route
8. Account transfer and access after installer handover

A PDF screenshot is not a machine-readable export. A CSV without timestamps, units or code definitions may be unusable even if it technically opens.

Prepare the pre-contract data notice

Before a sale, rental or lease is concluded, the buyer should receive clear information about the connected product's data. Build a controlled notice containing, as applicable:

• Type, format and estimated volume of product data
• Whether data are generated continuously and in real time
• Storage location and intended retention period
• How the user accesses, retrieves or deletes data
• Identity and contact details of the prospective data holder
• Purposes for which the data holder expects to use data
• How users request sharing with a third party or stop sharing
• Complaint route and relevant contract duration/termination terms

Align the notice with the datasheet, quotation, app terms, privacy notice and reseller contract. If sales promises “lifetime monitoring” but the cloud terms permit short retention or paid export, the procurement file contains a commercial contradiction.

Design third-party sharing for EPC and O&M use

A business user may want to send site data to an independent O&M provider, aggregator, energy-management platform or warranty service. The data holder should support sharing readily available data with a third party chosen by the user, subject to the Data Act's conditions and other applicable law.

Define:

• User authorization and revocation method
• Recipient identity and permitted dataset
• API credentials, rate limits and continuity
• Data quality equal to that available to the data holder
• Security controls and audit trail
• Treatment of personal data and confidential information
• Exit, deletion and credential revocation

Do not use “cybersecurity” as an automatic refusal. Access or sharing may be contractually restricted where it could undermine legally required product security and create a serious adverse effect on health, safety or security, but that decision needs a specific risk basis and the required authority notification. Build a review route rather than a blanket clause.

Allocate rights to use non-personal data

The entity operating the cloud is not automatically free to reuse all non-personal data. The Commission's Data Act explanation notes that a data holder needs an agreement with the user governing access, use and sharing of data generated by the connected product or related service.

The contract should state:

• Which entity is the user and which is the data holder
• Data used to deliver monitoring and support
• Optional analytics, benchmarking or product-improvement uses
• Purposes, duration and recipients
• User controls and termination effects
• Treatment of data from multiple owners, tenants or project parties

Keep personal-data legal bases and notices in the GDPR workstream. Data Act rights do not remove GDPR obligations, and the data-access design should respect data minimisation.

Protect trade secrets without making access impossible

Some datasets may expose engineering know-how, diagnostic logic or commercial patterns. Identify trade-secret elements field by field and agree proportionate safeguards such as confidentiality terms, controlled interfaces and access logging. Avoid designating an entire monitoring export as secret without analysis.

The supplier should maintain a decision record for withheld or limited fields, legal basis, risk, safeguards offered and escalation path. This is especially important when a distributor needs data for repair, warranty assessment or independent fleet service.

Keep Data Act, CRA, RED and GDPR files separate

Workstream	Main purpose	Typical output
Data Act	User access, data sharing and fair data terms	Data inventory, export/API test, notice and contract matrix
CRA	Product cybersecurity and vulnerability handling	Risk file, support period, incident-reporting workflow
RED / EN 18031	Cybersecurity conformity for relevant radio equipment	Clause matrix, test evidence and EU declaration route
GDPR	Protection and lawful processing of personal data	Role map, legal basis, notice, retention and rights process
Grid code	Electrical connection and required behavior	Exact-model listing, test reports and grid profile

Use the EU CRA connected-microinverter checklist for product-security lifecycle and incident reporting. Use the EU RED EN 18031 checklist for the radio-equipment conformity route. The controls can share an architecture diagram, but one file does not replace the others.

Add six Data Act gates to the RFQ

1. Role gate: user, seller, manufacturer, data holder and service providers named
2. Inventory gate: generated, readily available and enriched data distinguished
3. Architecture gate: direct or request-based access route and metadata defined
4. Sample gate: export, API, handover, third-party sharing and revocation tested
5. Contract gate: pre-contract notice, permitted use, retention and exit aligned
6. Production gate: model, firmware, cloud and data-schema changes controlled

The Wi-Fi monitoring handover checklist helps verify customer account ownership and transfer. The firmware change-control guide should also cover changes to telemetry fields, API behavior, retention and export formats.

Next step for an EU connected-microinverter RFQ

Send the target EU markets, sales model, brand arrangement, microinverter/gateway models, data-flow diagram, sample export, cloud contract, proposed retention and third-party integration needs through TMG Contact. TMG can organize an exact-product data and supplier evidence matrix; final Data Act, GDPR, cybersecurity and contract decisions remain with the responsible parties and authorities.

For private-label programs, review the OEM microinverter manufacturer solution before fixing cloud ownership, account transfer, API continuity, data-use rights and end-of-service obligations.