EU Cyber Resilience Act Reporting for Wi-Fi Microinverters: A 24/72-Hour Checklist

Updated 15 September 2026: the Cyber Resilience Act (CRA) reporting duties for manufacturers took effect on 11 September 2026. A Wi-Fi microinverter supplier serving the EU now needs a working notification process—not only a cybersecurity roadmap for the main CRA requirements that apply from 11 December 2027.

The long lead time matters. An actively exploited vulnerability or severe security incident can start in a cloud service, gateway, mobile app, third-party library or microinverter firmware. If no one has mapped the exact product, support chain and decision owner before an event, the first 24 hours will be spent finding records instead of assessing and reporting.

This checklist supports B2B product and supplier due diligence. It does not decide the legal classification of a particular model or replace the CRA, Commission guidance, a conformity assessment or advice from the responsible authority.

Confirm the product boundary and economic operator

The CRA applies broadly to hardware and software products made available on the Union market whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. For a connected solar offer, freeze the commercial configuration before assigning duties:

• Exact microinverter model, hardware and firmware
• Integrated radio or separate gateway/data-transfer unit
• Mobile app, installer portal, user portal and APIs
• Remote data processing necessary for product functions
• Update, device-management and authentication services
• Brand owner, legal manufacturer, EU importer and distributors
• Third-party software and service suppliers

Do not assume that a non-radio microinverter sits outside the product boundary when a required gateway, cloud function or update service is part of the offer. Equally, do not declare every accessory a separate CRA product without documenting how it is marketed and functions. Record the rationale, responsible reviewer and evidence.

An importer or distributor that markets the product under its own name or trademark—or makes a substantial cybersecurity-relevant modification—can be treated as the manufacturer. Private-label responsibility therefore needs to be settled before model names, cloud ownership and firmware authority are frozen.

Separate the 2026 reporting duty from the 2027 product requirements

CRA milestone	Effective date	Procurement meaning
Notification of conformity-assessment bodies	11 June 2026	Assessment capacity and notified-body planning can begin
Manufacturer reporting obligations	11 September 2026	Operational reporting for actively exploited vulnerabilities and severe incidents is required
Main CRA obligations	11 December 2027	Product, process, documentation, conformity assessment and CE-marking duties apply generally

The European Commission states that the 2026 reporting obligation also covers products with digital elements already made available on the EU market before 11 December 2027. A supplier should not postpone incident readiness on the theory that the product was launched under an earlier regime.

Build the 24-hour, 72-hour and final-report clock

Manufacturers submit mandatory notifications through the ENISA CRA Single Reporting Platform (SRP). The official reporting guidance describes these deadlines:

Trigger	First submission	Next submission	Final report
Actively exploited vulnerability	Early warning within 24 hours of awareness	Full notification within 72 hours	No later than 14 days after a corrective or mitigating measure is available
Severe incident affecting product security	Early warning within 24 hours of awareness	Full notification within 72 hours	Within one month of the 72-hour notification

“Awareness” is an operational trigger, not the date of the next management meeting. Define who receives vulnerability reports and service alerts, who determines whether the CRA threshold may be met, who is authorised to submit, and who contacts users or commercial partners.

Register the appropriate representatives and backup users in the SRP before an incident. Keep current legal-entity, product, Member State and contact information ready. Test the internal workflow with a tabletop exercise; do not create a false notification merely to test the live platform.

Create one evidence record for each affected product

A distributor email saying “cloud issue resolved” is not enough for a regulatory decision. The incident record should connect:

1. Affected brand, model, serial/batch range and EU markets
2. Hardware, firmware, gateway, app, cloud and library versions
3. Discovery time, awareness time and decision log
4. Exploitation or incident evidence and security impact
5. Mitigation, corrective update, rollback and validation status
6. SRP submission identifiers and timestamps
7. User, importer, distributor, CSIRT and authority communications
8. Root cause, recurrence controls and technical-file update

Use UTC timestamps alongside local time. Preserve the source of each fact and label assumptions. A single customer report may be incomplete, while cloud telemetry may affect more models than the first ticket suggests.

Make the supplier contract support the reporting clock

The legal manufacturer cannot meet a 24-hour deadline if an OEM, cloud operator or component vendor waits several business days to escalate. Set shorter contractual notification targets for upstream parties and define always-available security contacts.

Supplier evidence	RFQ question	Weak response
Product security contact	Who is available outside sales-office hours?	“Contact your account manager”
Vulnerability process	How are reports triaged, reproduced and escalated?	Policy URL with no owner
Component inventory	Which versions and suppliers are in each release?	Unversioned BOM only
Update process	How is authenticity, staged rollout and recovery controlled?	Remote update claimed without records
Incident support	What data arrives inside the buyer's escalation window?	Best-effort assistance
Installed-base traceability	Which customers and batches need action?	Shipment totals without serial mapping

Require the supplier to preserve logs and evidence long enough for investigation. Define who can access cloud telemetry lawfully, how confidential vulnerability information is shared, and how a corrective update is approved across affected grid profiles.

Prepare now for the 2027 technical file

The main CRA duties introduce secure-by-design and vulnerability-handling requirements across the support period. A practical readiness file for a Wi-Fi microinverter family should include:

• Cybersecurity risk assessment and product architecture
• Security requirements linked to verification results
• Component and software dependency inventory, with version traceability
• Known-vulnerability review and remediation decisions
• Secure configuration and least-privilege access design
• Update authenticity, automatic-update defaults, failure recovery and rollback
• Vulnerability disclosure and coordinated remediation process
• Defined support-period end date, stated by month and year
• User security information, installation assumptions and decommissioning route
• EU Declaration of Conformity and applicable conformity-assessment evidence when required

The CRA requires manufacturers to determine a support period that reflects expected use, reasonable user expectations and product nature. Do not copy the commercial warranty duration automatically. For a roof-mounted product expected to remain installed for years, procurement should challenge a support period that is disconnected from the expected service life.

The regulation requires a software bill of materials in a commonly used, machine-readable format covering at least the product's top-level dependencies, but it does not generally require the manufacturer to publish the SBOM to every user. Agree who maintains it, how components map to releases and how importers obtain sufficient evidence without exposing it publicly.

Keep CRA, RED cybersecurity and operating security separate

Workstream	Primary purpose	Buyer control
CRA	Horizontal product cybersecurity and vulnerability handling	Product boundary, lifecycle file, reporting and operator roles
RED / EN 18031	Radio-equipment essential requirements and conformity route	Exact radio configuration, standards, reports and declaration
GDPR/data protection	Lawful processing of account and monitoring data	Roles, notices, retention and access
Grid code	Connection and behavior of the generating equipment	Exact model, firmware/profile and network route
Commercial security SLA	Availability and support performance	Response, recovery, ownership and service exit

The EU RED EN 18031 importer checklist covers the radio-equipment conformity file. The firmware change-control guide covers release approval and recovery. Neither replaces the CRA reporting workflow.

For UK sales, use the separate PSTI Wi-Fi microinverter checklist. Similar controls can be reused, but the legal statements, deadlines and authorities differ.

Apply six release and incident hold points

1. Scope gate: connected-product boundary, classification and economic operators documented
2. Supplier gate: security contacts, component evidence and escalation SLA accepted
3. Sample gate: credentials, update, logging, recovery and ownership transfer tested
4. Release gate: hardware, firmware, gateway, app, cloud and documentation baseline frozen
5. Incident gate: 24/72-hour assessment, SRP submission and communication owners available
6. Shipment gate: support end date, user information, traceability and current conformity route verified

For public or utility procurement, also review the EU renewable-energy auction cybersecurity clause guide. Tender security clauses can exceed the minimum product-law baseline.

Next step for an EU connected-microinverter RFQ

Send the target Member States, brand arrangement, exact microinverter and gateway models, connectivity diagram, cloud ownership, planned support period, annual volume and current incident workflow through TMG Contact. TMG can structure an exact-product evidence and supplier matrix; final CRA classification, reporting and conformity decisions remain with the responsible economic operators and authorities.

For own-brand programs, review the OEM microinverter manufacturer solution before fixing brand, model, firmware authority, cloud roles, security contacts and change-notification terms.