CRA in charging infrastructure & e-mobility

A charge point today is no longer a piece of power electronics — it is a networked mini-computer with payment, billing, load-management and remote-maintenance functions: permanently online, often deployed in the field by the thousand, and with a direct data link to the backend. Precisely these properties make it a product with digital elements (PDE) under the Cyber Resilience Act (Regulation (EU) 2024/2847). Anyone who manufactures, imports or places AC wallboxes, DC fast chargers, charge-point controllers or the related software on the market under their own name should assess CRA applicability early — this is a schematic classification and does not constitute legal advice.

The real pain in this sector is specific: charging infrastructure sits at the seam of the energy and mobility networks, talks to backends (OCPP), to vehicles (ISO 15118, Plug&Charge) and to payment providers — every one of these interfaces is an attack surface. Chargers stand in public space for years, some at sites with shaky cellular connectivity, and must nonetheless remain securely updatable across their entire lifetime. At the same time the sector is energy-adjacent and therefore in the orbit of NIS2 — which makes the compliance landscape doubly confusing for manufacturers.

On top of that comes time pressure. The first hard manufacturer obligation — the reporting duties under Art. 14 — already applies from 11.09.2026. The full product requirements (security-by-design, technical documentation, CE marking) follow on 11.12.2027. For a wallbox or charger manufacturer that means: the reporting process must be in place first, the product engineering has slightly more lead time.

Typical PDE products in the sector and the likely Annex III class

The vast majority of charging hardware is likely to fall, schematically, into the default category — with self-assessment under Module A. It is different for components whose core function is security or network control: a central control/energy-management gateway that manages access or acts as a router/firewall between segments may move into Annex III (class I). The authoritative technical delineation of the important and critical categories is provided by Implementing Regulation (EU) 2025/2392.

Rule of thumb: for most manufacturers the conformity route is self-assessment — provided the technical documentation, the risk assessment and the harmonised standards are properly applied. A notified body only becomes mandatory when a component falls into class I and no harmonised standards are fully applied — or into class II, where a notified body is always required.

Sector standards and delineation from adjacent regimes

Technically, charging infrastructure rests on a well-defined standards stack: IEC 62443 for the security of the control/OT layer, ISO 15118 for vehicle-to-charger communication including certificate and PKI handling for Plug&Charge, and OCPP 2.0.1 with its security profiles (TLS client/server certificates, secure firmware update) for the backend connection. These standards supply the material with which the CRA essential requirements from Annex I can be met and documented concretely. The PKI topic around ISO 15118 is, in our experience, the most demanding part — and a field in which Blackfort Technology is at home.

The clean delineation from neighbouring regimes matters: the CRA addresses product cybersecurity at the manufacturer. NIS2, by contrast, obliges operators of essential and important entities (in the energy sector clearly relevant for the CPO/operator) — that is a separate legal act and must not be equated with the CRA. If a charge point contains radio modules (e.g. for remote maintenance), the RED Delegated Regulation 2022/30 may additionally apply; keep the overlap with the CRA in view. Kept clearly separate are matters of vehicle type-approval (which concern the vehicle, not the charging hardware) and the AI Act, where AI functions (e.g. load forecasting) come into play.

SBOM and supply-chain reality in this sector

Charging firmware is a composite: embedded Linux as the base, a TLS stack for secured communication, an OCPP client, the ISO 15118 communication module and — for direct payment — payment middleware. This very stack is the classic CRA pitfall. Outdated or end-of-life components (say an EOL TLS library) only surface once a vulnerability becomes known — and then a fix has to be rolled out to thousands of field-deployed chargers, some over unstable connectivity.

A machine-readable SBOM is therefore not a form but an early-warning system. Per BSI TR-03183-2 (v2.1.0) it must be in CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1, cover at least the top-level dependencies and be part of the technical documentation (there is no general publication obligation). Concretely it delivers: unambiguous component and version identification, supplier/provenance data and the ability to link to vulnerability databases — so that when a new CVE appears, it is clear in seconds rather than weeks whether and which charger models are affected. In addition: update capability across the support period (guideline of at least 5 years) must be technically demonstrable, including secure OTA.

Reporting capability and PSIRT for charging infrastructure

Once an actively exploited vulnerability or a severe security incident becomes known, the Art. 14 cascade starts from the moment of awareness. It is frequently misrepresented in shortened form — the correct deadlines are:

• 24 hours: early warning to the competent CSIRT and ENISA.
• 72 hours: full notification including initial corrective/mitigating measures.
• 14 days: final report for an actively exploited vulnerability — counted from the availability of a corrective measure.
• 1 month: final report for a severe security incident — after the 72-hour notification.

Reporting goes through the ENISA Single Reporting Platform (SRP) as a single submission to the CSIRT of the main establishment and ENISA. For a charging-infrastructure manufacturer, "reporting capability" means concretely: a named PSIRT/contact team, a published Coordinated Vulnerability Disclosure (CVD) policy over the support period, a rehearsed procedure that meets the deadlines, and the ability to determine via SBOM in minutes which firmware versions are affected.

Which deadline counts first

For manufacturers in this sector there is a clear order. First comes 11.09.2026: from this date the reporting duties (Art. 14) apply. Anyone who discovers an exploitable vulnerability in the OCPP/TLS stack or in the Plug&Charge PKI handling must then be able to report on time — regardless of whether the product requirements already apply in full. The second milestone is 11.12.2027: from then charge points must meet the full product requirements (security-by-design/default, documented risk assessment, SBOM, EU declaration of conformity, CE). In practice: stand up the PSIRT/reporting process with priority, and in parallel align product engineering and technical documentation to 2027.

A worked example

A mid-sized manufacturer offers AC wallboxes and a DC fast charger, plus a charge-point controller with an OCPP 2.0.1 client and ISO 15118 Plug&Charge. Schematically, the devices fall into the default category, so self-assessment (Module A) is the plausible route — provided the harmonised standards and technical documentation are properly applied. He assesses the EMS gateway with firewall character separately for a possible class I classification.

His roadmap: he generates CycloneDX 1.6 SBOMs for each firmware line and spots a soon-to-be-deprecated TLS library, which he replaces. He sets up a secure OTA process that rolls out security fixes over ≥ 5 years, even to chargers with weak connectivity. He hardens the ISO 15118 certificate/PKI handling. He names a PSIRT and publishes a CVD policy so that from 11.09.2026 he can serve the 24h/72h/14-day cascade. And he links his SBOM to vulnerability monitoring so that with the next CVE it is immediately clear which models are affected.

What Blackfort Technology does for you

Blackfort Technology UG (haftungsbeschränkt) supports manufacturers and importers of charging infrastructure pragmatically and sector-specifically:

• Applicability and scope analysis: PDE classification of your portfolio, plausible Annex III category per component, conformity route (Module A vs. notified body) — schematic, not legal advice.
• SBOM setup: machine-readable bills of materials in CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1, EOL/OSS risks in the charging-firmware stack made visible, integrated into the technical documentation.
• PSIRT/CVD: building a reporting-capable process along the Art. 14 cascade, including SRP submission logic and Coordinated Vulnerability Disclosure.
• Risk assessment & threat modeling: for OCPP backend coupling, ISO 15118 PKI and OTA update paths — documented per Art. 13/Annex I.
• Technical documentation: structured, audit-ready, retainable for 10 years, including declaration of conformity and CE basis.

Start with the applicability check, take a look at our CRA overview and the SME guide — or talk to us directly: get in touch.