CRA for EV Charging: Wallboxes and OCPP

CRA in charging infrastructure & e-mobility

Last updated: 2026-10-09

A charge point today is a networked mini-computer with payment, billing, load-management and remote-maintenance functions: permanently online, deployed across the field in large numbers, 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 requirements doubly confusing for manufacturers.

On top of that comes time pressure. The first hard manufacturer obligation, the reporting duties under Art. 14, has already applied since 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 already be in place, and product engineering must be completed by 11 December 2027.

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

Charging hardware without an Annex III core function is likely to fall, schematically, into the default category - with self-assessment under Module A. It is different for components whose core function is a listed category (Article 7(1)): a central control/energy-management gateway whose core function is routing falls under Annex III class I (No. 12); if the firewall is its core function, class II. A built-in filtering function alone is not enough. The technical descriptions of the important and critical categories are provided by Implementing Regulation (EU) 2025/2392.

Product	Likely classification	Rationale	Conformity route
AC wallbox (private/semi-public)	Default	Networked PDE, but no Annex III core function	Self-assessment (Module A)
DC fast charger / HPC	Default	As above; complexity raises risk but does not, as such, change the category	Self-assessment (Module A)
Charge-point controller / OCPP client	Default, possibly class I	Class I only if an Annex III category is its core function, for example routing (No. 12)	Class I: Module A only with full application of harmonised standards, common specifications or a European cybersecurity certification scheme (at least “substantial”), otherwise Module B+C or H
Central control/EMS gateway	Class I or II only if routing (class I) or firewall/IDS (class II) is the device's core function	A built-in filtering function alone is not enough	Class I as above; class II: Module B+C, Module H or a European scheme of at least “substantial”
ISO 15118 / PKI module (Plug&Charge)	Default, possibly class I	Class I (No. 9) only if the product itself issues certificates; managing certificates in the charger is not enough	Depends on the specific PKI function
OCPP backend/CPMS as a software product	Default	PDE if delivered as a product; pure operation is separate (NIS2)	Self-assessment (Module A)

Matrix with the schematic classification of typical products in charging infrastructure and e-mobility into the bands default (not in Annex III/IV), class I and class II (Annex III) and critical (Annex IV). AC wallbox: default; DC fast charger, HPC: default; OCPP backend/CPMS as a software product: default; Charge-point controller, OCPP client: default or class I (depending on core function or scope); ISO 15118 / PKI module (Plug&Charge): default or class I (depending on core function or scope); Central control/EMS gateway: default (depending on core function or scope) or class I (depending on core function or scope) or class II (depending on core function or scope). Assessment routes: default self-assessment (module A), module B+C, H or an EU scheme also possible; class I module A only if harmonised standards, common specifications or a European cybersecurity certification scheme (assurance level at least substantial) are fully applied, otherwise modules B+C or H; class II modules B+C, module H or a European cybersecurity certification scheme at assurance level at least substantial; critical a European cybersecurity certification scheme where required by delegated act, otherwise as class II. What counts is the core function (Art. 7(1)); integrating a component with an Annex III core functionality does not in itself trigger the class I or II procedures (Art. 7(1), second sentence); schematic orientation, not a classification of an individual case. — Typical products in charging infrastructure and e-mobility and their schematic classification; sources: Art. 7, Art. 8, Art. 32, Annexes III and IV of Regulation (EU) 2024/2847.

Rule of thumb: for default-category products the conformity route is self-assessment (Module A) - provided the technical documentation and the risk assessment are properly prepared. A notified body becomes necessary when a component falls into class I and neither harmonised standards nor common specifications nor a European cybersecurity certification scheme (at least “substantial”) are fully applied (then Module B+C or H). Class II requires Module B+C, Module H or a European scheme of at least “substantial”.

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 demanding; Blackfort Technology brings PKI experience from other sectors.

The clean delineation from neighbouring regimes matters: the CRA addresses product cybersecurity at the manufacturer. NIS2, by contrast, obliges 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. Manufacturers of electronic products or electrical equipment can themselves fall under NIS2 from medium size upwards (Annex II point 5); that concerns the organisation, not product conformity. If a charge point contains radio modules through which it communicates with the internet (e.g. for remote maintenance), the RED Delegated Regulation 2022/30 may additionally apply until it is repealed with effect from 11 Dec 2027; until then, keep the overlap with the CRA in view. Kept clearly separate are Type-Approval Regulation (EU) 2019/2144 (which concerns the vehicle and components designed for vehicles, not stationary charging hardware) and the AI Act, which applies in addition as soon as an AI system (e.g. for load forecasting) is built in.

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.

The SBOM is therefore your early-warning system. The CRA requires a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)), as part of the technical documentation (there is no general publication obligation). The Regulation does not prescribe a specific format; the Commission may specify format and elements by implementing act (Article 13(24)). The German BSI guideline TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. Well maintained, the SBOM 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 (as a rule at least five years, shorter only where the expected period of use is shorter, Article 13(8)) must be technically demonstrable, including secure OTA.

Reporting capability and PSIRT for charging infrastructure

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

24 hours: early warning, without undue delay and in any event within 24 hours of becoming aware.
72 hours: notification, without undue delay and in any event within 72 hours of becoming aware, with the general information available and the corrective or mitigating measures taken.
14 days: final report for an actively exploited vulnerability - counted from the availability of a corrective or mitigating measure.
1 month: final report for a severe incident - after the 72-hour notification.

Reporting goes via the single reporting platform (Article 16), through the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment, simultaneously accessible to ENISA - a single submission. 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 came 11.09.2026: since this date the reporting duties (Art. 14) have applied. Anyone who discovers an exploitable vulnerability in the OCPP/TLS stack or in the Plug&Charge PKI handling must 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; the technical documentation must still be complete. He assesses the EMS gateway separately: if routing is its core function it falls under class I, if the firewall is, class II.

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 across the entire support period, 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 he can serve the cascade that has applied since 11.09.2026 (early warning without undue delay and within 24 hours at the latest, notification within 72 hours at the latest, final report). 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 supports manufacturers and importers of charging infrastructure pragmatically and sector-specifically:

Applicability and scope analysis: a technical assessment of the PDE classification of your portfolio, the plausible Annex III category per component and the conformity route (Module A vs. notified body) - schematic, not legal advice.
SBOM setup: machine-readable bills of materials, for example in CycloneDX or SPDX, 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 connection to the single reporting platform 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: building the documentation under Annex VII up to the EU declaration of conformity, retained for at least ten years or the longer support period (Article 13(13)).

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

Frequently asked questions

Does the OCPP backend count as a CRA product?+

If it is provided as a software product, it is schematically to be treated as a PDE. A service operated purely for a single customer must be considered separately and tends toward operator logic (incl. NIS2) rather than the CRA product obligations. This is a schematic classification, not legal advice.

Does our wallbox fall into the default or an Annex III class?+

Wallboxes and chargers without an Annex III core function are likely to fall, schematically, into the default category (self-assessment, Module A). Class I comes into play for components whose core function is a listed category, such as routing (No. 12) or issuing digital certificates (No. 9); a gateway with a firewall as its core function would be class II. A built-in filtering function alone is not enough. The technical descriptions are set out in Implementing Regulation (EU) 2025/2392; the specific classification should be assessed per component.

How do we secure Plug&Charge (ISO 15118) and PKI handling in line with the CRA?+

ISO 15118 provides certificate and PKI handling for Plug&Charge; the CRA essential requirements from Annex I can be met and documented concretely on that basis. Key are secure key/certificate management, hardening of the trust chains and an update path for compromised certificates. Threat modeling of the PKI and OCPP interfaces makes the Art. 13 risk assessment demonstrable.

How do we meet the update obligation for field-deployed chargers without stable connectivity?+

The CRA requires security updates across the support period (as a rule at least five years, shorter only where the expected period of use is shorter, Article 13(8)). For field-deployed chargers, a secure OTA process with signed packages, resumable downloads and fallback mechanisms for weak links works well. The SBOM helps target fixes only at affected firmware lines.

What must we implement first - reporting process or product requirements?+

The reporting process first: the reporting duties under Art. 14 have applied since 11.09.2026, the full product requirements apply only from 11.12.2027. In practice that means standing up the PSIRT and CVD policy immediately if not yet done, and in parallel aligning product engineering, SBOM and technical documentation to 2027.

How does the CRA delineate from NIS2 for us?+

The CRA addresses product cybersecurity at the manufacturer of the charging hardware/software. NIS2 obliges essential and important entities - in the energy sector, for example, the charge-point operator (CPO). Both legal acts are separate: as a manufacturer you may fall under the CRA, while your operating customer additionally has NIS2 obligations. Manufacturers of electronic products or electrical equipment can also themselves fall under NIS2 from medium size upwards (Annex II point 5); that concerns the organisation, not product conformity.

Sources

This content provides general technical and organizational information on the Cyber Resilience Act (Regulation (EU) 2024/2847) and does not constitute legal advice (no legal services within the meaning of the German RDG).