Summary

From August 1, 2025, the EU Radio Equipment Directive (RED) cybersecurity provisions for connected products are enforceable. For EV charging, any charger with Wi-Fi, cellular, or BLE must meet security-by-design requirements; devices that process personal data must add privacy protections; and products enabling payments must implement anti-fraud controls.

The European Commission has listed EN 18031-1/-2/-3:2024 as harmonized standards to presume conformity. The OJ listings include restrictions, so only correctly applied normative clauses grant presumption. Devices without wireless modules are generally outside Article 3(3), but system-level compliance still applies to the charger as a whole.

What changed and why it matters

• Scope now goes beyond RF compliance. Connected functionality carries mandatory security, privacy, and anti-fraud controls.

• A clear conformity route exists. Adopting EN 18031 can provide presumption; otherwise, use a Notified Body route.

• Procurement will tighten. EU tenders and audits will ask for signed updates, credential policies, SBOM, vulnerability handling, and user guidance.

Who is affected in the charging ecosystem

• DC and AC chargers with embedded connectivity (LTE, Wi-Fi, BLE).

• Back-office integrated features that rely on device credentials, logs, or OTA updates.

• Chargers that accept ad-hoc payments or support payment tokens.

• Hardware accessories without wireless modules are usually out of scope, while the charger as a system remains in scope.

Key dates and milestones

Note: The EN 18031 listings in the OJ include restrictions; only correctly applied normative provisions grant presumption of conformity.

Milestone | What it means for EV charging

January 30, 2025 | EN 18031-1/-2/-3:2024 listed in the Official Journal, enabling presumption of conformity when correctly applied.

August 1, 2025 | RED cybersecurity provisions (Articles 3(3)(d)(e)(f)) are enforceable for in-scope radio equipment, including connected chargers.

2025–2026 | Manufacturers and operators align documentation packs (risk assessment, test reports, SBOM, update policy) and roll out field hardening.

Supplier evaluation criteria for EU RED–compliant EV chargers (EN 18031 checklist)

Use the following EN 18031 checklist to review systems quickly.

Firmware security and updates (signed images, rollback protection, encrypted channels, key rotation).

Clarifier: prevent unauthorized code and ensure safe recovery.

Access control (no default or empty passwords, first-login change, lockout and rate limiting, least-privilege accounts).

Clarifier: block easy break-ins and limit lateral movement.

Network abuse protection for OCPP/MQTT/HTTPS (throttling, anomaly detection, replay and flood safeguards, hardened services).

Clarifier: stop botnet enrollment and traffic storms.

Privacy and logs (data minimization, retention schedules, user-facing privacy notice, secure log export).

Clarifier: collect only what you need and keep it safe.

Payments, if present (end-to-end encryption and signing, tamper-evident design, dual control for refunds and settlements).

Clarifier: protect value transfer and reduce fraud risk.

Evidence bundle (EN 18031 coverage matrix, test reports, vulnerability disclosure and patch SLAs, user-manual security section, EU Declaration of Conformity, technical file index).

Clarifier: show proof, not promises.

Requirement-to-use-case map

RED requirement | Typical EV charging use case | Examples of acceptable controls

3(3)(d) Network misuse | Prevent botnet enrollment or DDoS via the charger modem | Firewalling, rate limits, TLS mutual authentication, hardened services

3(3)(e) Data protection | Handle driver identifiers, session data, metadata | Data minimization, pseudonymization, access logging, retention policy

3(3)(f) Fraud prevention | QR-code or card-based ad-hoc payments | Cryptographic proofs, secure elements or HSM, dual control on refunds

How to operationalize compliance (field-ready flow)

Identify scope → Threat and gap assessment → Implement controls (firmware, credentials, communications, payment, privacy) → Validate (internal tests and, if needed, a Notified Body) → Compile technical file (risk analysis, SBOM, test reports, EN 18031 mapping, user instructions) → Issue EU DoC and label → Monitor and patch with defined disclosure and remediation SLAs.

30–60–90 day action plan

Days 0–30: Confirm which models include wireless modules; map Article 3(3)(d)(e)(f) applicability; draft SBOM and initial risk assessment; line up EN 18031 coverage.

Days 31–60: Ship credential policies and secure update; harden OCPP/MQTT/HTTPS; minimize and document data; define fraud controls for payment flows; schedule third-party or Notified Body review if not fully aligned to EN 18031.

Days 61–90: Finalize testing, technical file, and EU DoC; label and release; pilot field hardening on selected sites; publish vulnerability handling and patch SLAs.

Impact on product roadmaps

• 15118-enabled chargers and OCPP 2.x back-ends will emphasize stronger credential and certificate handling.

• RFPs will weigh security update operations and evidence quality as much as nameplate power.

• Reliable OTA reduces site visits and supports lower lifetime cost.

Workersbee note

Workersbee supports EU-bound projects with connector-and-cable assemblies and aligns charger integration guidance with RED cybersecurity controls. For DC programs that seek presumption of conformity, our engineering team can provide a concise EN 18031 coverage checklist and sample technical-file wording through the anchors: Workersbee engineering guidance, Workersbee DC connector know-how.

FAQ

Q: If a charger has no payment feature, does Article 3(3)(f) still apply?

A: No. Only devices enabling payments or transfer of monetary value fall under 3(3)(f). The same charger may still need to meet 3(3)(d) and 3(3)(e).

Q: Do I need a Notified Body if I adopt EN 18031 completely?

A: Full and correct application of the harmonized standards can grant presumption. If only partial adoption or uncertainty exists, a Notified Body route reduces risk.

Q: Do the OJ restrictions mean EN 18031 alone is always enough?

A: No. Only correctly applied normative clauses grant presumption. If you deviate or face ambiguous cases, use a Notified Body route.

Q: What evidence do auditors usually request first?

A: Signed-update policy, password policy, SBOM, vulnerability handling workflow, EN 18031 mapping table, and the EU Declaration of Conformity.