EU Cyber Resilience Act Guide for EV Charging & EVSE Manufacturers

EV charging products within CRA scope include: connected home AC wallboxes with WiFi or Ethernet and companion-app control, commercial and public AC charge points, DC fast chargers, the embedded charge-point controller and its OCPP client, and the charging station management system (CSMS) back office that operates a fleet of chargers. Each of these is a product with digital elements, and the CSMS software is in scope in its own right.

Basic home AC wallboxes with limited connectivity and no payment handling are typically Default Class, which allows self-assessment under Module A. Public and commercial charging changes the picture. A networked DC fast charger that handles cardholder or account payment data, speaks OCPP to a back office, authenticates drivers, and participates in smart charging or grid demand response has a materially larger attack surface and is more likely to be Important Class I. Chargers deployed as part of critical energy infrastructure, or CSMS platforms operating large public networks, warrant a Class I assessment even where an individual charge point looks modest.

EV chargers sit between a payment system, a driver's vehicle, a back-office platform, and the electricity grid, which is exactly the multi-interface exposure the CRA Annex I essential requirements target. Security research has repeatedly demonstrated OCPP man-in-the-middle interception and vulnerabilities in public charge points, so these requirements are concrete rather than theoretical:

• Default credential elimination: Charge-point controllers and CSMS admin interfaces must not ship with factory default credentials that are shared across a product line.
• Encrypted back-office communication: OCPP connections must run over WSS/TLS, not plaintext WebSocket, and certificates must be validated. OCPP 2.0.1 security profiles 2 and 3 provide the transport and mutual-authentication baseline.
• ISO 15118 Plug and Charge PKI: Where Plug and Charge is implemented, the TLS and contract-certificate handling defined by ISO 15118 must be correctly deployed, with certificate validation and revocation handled rather than stubbed.
• Authenticated firmware updates: Over-the-air firmware delivered to field chargers must be cryptographically signed and verified before installation.
• SBOM maintenance: The embedded Linux or RTOS stack, the OCPP library, and the payment and ISO 15118 components must be documented in a maintained SBOM.

Most EV charging manufacturers, from established power-electronics companies to newer charge-point startups, do not yet run a formal coordinated vulnerability disclosure programme. Researchers who find flaws in a charger's web interface, OCPP implementation, or mobile app often have no structured way to report them. Article 13 makes a published CVD policy and a single point of contact mandatory.

• Cover the charge point, the CSMS back office, the driver mobile app, and any Plug and Charge components
• Be reachable from the corporate security.txt and the product security page
• Give security researchers and charge-point operators a clear submission channel for suspected vulnerabilities or anomalous charger behaviour
• Define response timelines that reflect the operational reality that a fix often has to be rolled out across thousands of field-deployed chargers
• Coordinate with charge-point operators (CPOs) and e-mobility service providers who deploy and manage the hardware

CRA Portal lets charging manufacturers without a dedicated security team stand up a structured CVD programme, with intake, triage, and advisory publication, under their own brand.

• Abuse of an OCPP or CSMS weakness to take control of, disable, or manipulate a fleet of public chargers
• Theft of driver payment or account data through a charge point or the back office
• Manipulation of charging sessions or smart-charging setpoints in a way that affects grid stability at scale

When exploitation is confirmed, the 24-hour early warning to ENISA and the relevant national CSIRT applies, followed by the 72-hour detailed report and the final report. Because compromised public charging can have energy-sector and safety implications, manufacturers should pre-establish notification channels with their major charge-point operators so that a coordinated response is possible inside the Article 14 timeline. CRA Portal tracks these deadlines with hard timers and produces an SRP-ready package for the ENISA Single Reporting Platform.

Default Class home chargers may self-assess under Module A. Important Class I public and DC fast charging products require the appropriate third-party route. A manufacturer whose range spans home wallboxes and public DC chargers will run separate conformity pathways for the two product families.

For a Class I charging product, the conformity assessment will examine OCPP transport security and authentication, ISO 15118 certificate handling where Plug and Charge is used, the firmware-update signing mechanism, payment-data protection, the SBOM, and the operational status of the CVD policy. Evidence from existing security testing against OCPP 2.0.1 security profiles and ISO 15118 conformance can support the technical file.

Compliance for EV chargers also has to be read alongside the Alternative Fuels Infrastructure Regulation (AFIR), which governs deployment, payment interoperability, and data access for public recharging points. AFIR and the CRA are separate instruments and must both be satisfied. AFIR drives the connectivity, payment, and roaming features that expand the charger's attack surface, and those features must be implemented in line with CRA Annex I. Charge-point operators may additionally fall under NIS2 as essential or important entities, which is distinct from the manufacturer's CRA product obligations.