Cyber Resilience Act
Securing a smarter energy future.
Explore our approach to the EU Cyber Resilience Act and help us protect connected energy products through coordinated vulnerability reporting.
Cybersecurity throughout the product lifecycle.
-
Secure Development
-
Vulnerability Handling
-
Coordinated Response
The EU Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets cybersecurity requirements for hardware and software with digital elements placed on the EU market. It covers product design and development, vulnerability handling and security maintenance.
For connected energy equipment, security is part of long-term reliability. TBEA Xi'an Electric Technology's CRA preparation builds on our information security management and secure product development practices, with a focus on inverter firmware, component visibility and incident reporting.
Building on recognised
security standards.
Our preparation connects information security management with secure industrial product development. IEC 62443-4-2 work remains in progress.
-
Achieved In ProgressISO/IEC 27001
Information Security Management
An established management framework for identifying, managing and improving information security practices.
-
Achieved In ProgressIEC 62443-4-1
Secure Product Development Lifecycle
A foundation for product development security, including the processes used to handle security findings.
-
Achieved In ProgressIEC 62443-4-2
Technical Security Requirements
Ongoing work on security requirements for industrial automation and control system components.
Certification applies to its stated scope. ISO/IEC 27001 or IEC 62443 certification alone does not establish CRA conformity; applicable requirements and harmonised standards must be assessed for the relevant product.
CRA Preparation Priorities
-
01
PSIRT Workflow
Build on the IEC 62443-4-1 process to formalise a Product Security Incident Response Team and a clear channel for vulnerability reports.
-
02
Software Component Visibility
Develop an automated software bill of materials (SBOM) pipeline for inverter firmware to identify open-source dependencies and vulnerabilities.
-
03
EU Reporting Coordination
Prepare responsibilities and communication protocols for regulatory notifications through ENISA and the relevant national CSIRT.
The CRA at a glance.
A phased introduction sets the path from entry into force to reporting duties and the application of the main requirements.
-
10 December 2024
Entry into Force
The Cyber Resilience Act enters into force across the European Union.
REGULATORY FOUNDATION -
11 June 2026
Conformity Assessment Bodies
Provisions concerning the notification of conformity assessment bodies begin to apply.
ASSESSMENT FRAMEWORK -
11 September 2026
Reporting Obligations
Mandatory reporting of actively exploited vulnerabilities and severe product security incidents applies.
APPLICABLE -
11 December 2027
Main Requirements Apply
The principal CRA requirements for products with digital elements become applicable.
NEXT MAJOR MILESTONE -
10 December 2024
Entry into Force
The Cyber Resilience Act enters into force across the European Union.
REGULATORY FOUNDATION -
11 June 2026
Conformity Assessment Bodies
Provisions concerning the notification of conformity assessment bodies begin to apply.
ASSESSMENT FRAMEWORK -
11 September 2026
Reporting Obligations
Mandatory reporting of actively exploited vulnerabilities and severe product security incidents applies.
APPLICABLE -
11 December 2027
Main Requirements Apply
The principal CRA requirements for products with digital elements become applicable.
NEXT MAJOR MILESTONE
CRA standardisation request M/606 includes 41 horizontal and product-specific standards. The applicable harmonised standards and their publication status should be checked against the current EU framework.
Prompt reporting.
Coordinated response.
For an actively exploited vulnerability, the CRA reporting clock starts when the manufacturer becomes aware of exploitation, before investigation or remediation is complete.
-
24 hours
Early Warning
Notify the relevant authorities within 24 hours of awareness, with the initial available facts.
-
72 hours
Vulnerability Notification
Provide the fuller notification within 72 hours of awareness, including available technical information.
-
14 days
Final Vulnerability Report
Submit the final report no later than 14 days after a corrective or mitigating measure becomes available.
These are manufacturer-to-authority deadlines, rather than response promises to individual researchers. Severe incidents have the same 24-hour and 72-hour initial stages, with a final report within one month of the 72-hour notification.
Help us strengthen
product security.
Researchers, customers and partners can help identify potential security issues affecting our connected products. Clear technical information supports assessment and coordinated remediation.
-
STEP 01
Share Your Findings
Identify the affected product and firmware, describe the issue and explain how it can be reproduced. Include evidence of potential impact where available.
You may omit your name and e-mail. Providing an e-mail allows follow-up questions.
-
STEP 02
Assess & Investigate
The PSIRT workflow is intended to support technical validation, assessment of affected versions and coordination with the relevant product teams.
Include whether the issue is public or is known to be actively exploited.
-
STEP 03
Coordinate Remediation
Security findings inform corrective measures, mitigation guidance and any applicable regulatory notifications. Coordinate disclosure to help protect affected users.
Discuss disclosure timing with the responsible product security contact.
-
What should a vulnerability report include?
-
How can research and disclosure be coordinated?
-
How are EU regulatory notifications coordinated?
Report a security vulnerability.
Prepare the details of a potential product security issue using the form. For the designated security-reporting contact, please contact our Technical Support team.
Europe Head of After-Sales Service
Xin Li
This is the published technical support contact. Request the designated security-reporting channel before sharing sensitive vulnerability details.
Share only what is necessary.
Avoid including passwords, private keys or personal customer data. Use an agreed secure channel for sensitive technical evidence.