How an EV Charger Is Made: Power, Metering, OCPP and Plug and Charge

An EV charger is made from three layers: a power path (contactors, residual current protection and, for DC, rectifier and DC/DC power modules), a certified energy meter, and a computer. The computer is usually an embedded Linux controller that speaks OCPP to the operator's cloud and ISO 15118 to the car, guarded by a small safety microcontroller.

Each design is safety tested, its meter is evaluated against weights and measures rules such as NIST Handbook 44 Section 3.40, and its software is tested for protocol conformance before units are installed, given certificates and commissioned. This post goes one level deeper than our EV charging security basics with OCPP and ISO 15118 and how a car is made. Charger makers do not publish yields or production test recipes; where no primary source gives a number we say so, and every calculation is labelled as an illustration.

Electrical safety warning. EV chargers connect to mains supplies, and DC fast chargers produce hundreds of volts of DC at hundreds of amperes. Both can kill. Nothing in this post is an instruction to open, modify, repair or test the inside of a charger, a power module or a vehicle inlet. Installation, maintenance and high voltage testing belong to licensed electricians and trained technicians following the manufacturer's procedures and local electrical code. The hands-on section at the end is software only.

Key takeaways

• A Level 2 AC charger is a supervised switch: contactors, residual current detection, a control pilot circuit and a meter. The car's onboard charger converts AC to DC. A DC fast charger contains the converter itself, plus an isolation monitor, over-voltage protection and heavy cooling.
• The control pilot is a 1 kHz, plus or minus 12 V signal. The car pulls the voltage down to signal its state, and the duty cycle advertises the current limit: 53.3 percent means 32 A. A 5 percent duty cycle means "talk to me digitally", which is how DC charging and ISO 15118 start.
• Safety must not depend on Linux. Open source charger reference designs put contactor control, pilot reading and fault trips in a safety microcontroller that acts on its own.
• US retail charger meters fall under NIST Handbook 44 Section 3.40, permanent since 1 January 2023: 1.0 percent acceptance and 2.0 percent maintenance tolerance, with a 5.0 percent Class 5 allowance for DC chargers placed in service before 2025 that expires on 1 January 2034.
• OCPP 1.6 (2015), 2.0.1 (2020) and 2.1 (2025) connect chargers to management systems. OCPP defines three security profiles and a signed firmware update use case.
• Plug and Charge uses an ISO 15118 certificate hierarchy. ISO 15118-20:2022 adds bidirectional power transfer, wireless charging and automatic connection devices.
• Federally funded US chargers under 23 CFR Part 680 must reach 97 percent annual uptime per port, support OCPP 2.0.1 and ISO 15118 Plug and Charge, and accept secure remote software updates.

Raw materials to a commissioned charger: the step table

The table follows one DC fast charger design, with notes where an AC wallbox differs. Steps 1 to 4 happen at suppliers, steps 5 to 9 on the charger maker's line, step 10 once per design, and steps 11 and 12 on site.

Steps 8 and 12 carry most of the software supply chain risk: step 8 is where firmware, keys and open source components enter the product, and step 12 is where the charger joins a network it will talk to for years.

A dated timeline of the standards and rules

What is the difference between a Level 2 AC wallbox and a DC fast charger?

An AC charger hands the car alternating current and lets the car's onboard charger convert it. A DC fast charger does the conversion itself and feeds the battery directly. That one difference decides the size, cost, cooling and how much software sits between grid and battery.

Part 680 defines AC Level 2 as a charger on a 208 to 240 V circuit feeding a converter in the vehicle. ENERGY STAR describes Level 1 as a standard 120 V outlet and Level 2 as a 240 V circuit like an electric dryer's.

What is inside a Level 2 wallbox?

Safety note. A wallbox is permanently connected to a mains circuit. This is a description, not a guide. Do not open a wallbox or work on its supply; that is a job for a licensed electrician.

The hardware architecture guide from EVerest, an open source charger software project under LF Energy, describes an AC power path with fewer parts than DC:

• Output contactors, usually four pole, with a mirror (auxiliary) contact so the controller can confirm the contacts opened. The guide asks for a contact air gap of at least 3 mm, which it traces to IEC 61851-1:2017 and IEC 60664-1.
• Residual current protection. AC charging generally needs a Type B device, which catches AC and smooth DC fault currents. Because Type B devices are expensive, a common design pairs a Type A device with a 6 mA DC fault detector following IEC 62955. If the charger has none, the upstream installation must provide it.
• A control pilot circuit that drives the pilot through a 1 kilohm resistor and reads back the car's response.
• A meter, plus a connector lock if the unit has a socket rather than a tethered cable, and a controller with Wi-Fi, Ethernet or cellular for OCPP.

Funded AC ports under Part 680 need at least 6 kW per port, a permanently attached J1772 connector and ENERGY STAR certification.

What is inside a DC fast charger?

Safety note. DC fast chargers contain high voltage DC buses and capacitors that can stay charged after power is removed. Only trained personnel should work inside one. EVerest's DC bring-up guide warns: "High voltages may cause severe injury including death."

A DC charger adds a conversion chain:

1. Input filtering and protection on a three phase supply.
2. A rectifier with active power factor correction that draws near sinusoidal current and produces a DC link.
3. An isolated DC/DC converter that sets the voltage the battery asks for and isolates the vehicle from the grid.
4. Output contactors, ideally the last part before the plug, so no internal fault can reach the pins while they are open. Some designs add precharge or discharge contactors.
5. An isolation monitoring device that measures insulation resistance between the DC conductors and earth; EVerest cites IEC 61557-8.
6. An over-voltage monitor. EVerest cites IEC 61851-23:2023 as requiring a switch off if the voltage stays above the limit for 9 ms.
7. Cooling, from fans to liquid loops and liquid cooled cables, plus a DC meter, display, payment terminal and controller.

High power units usually parallel several identical power modules, so one design covers several ratings and a failed module can be swapped.

AC wallbox versus DC fast charger at a glance

Worked example 1: power ratings in amperes

Illustrations using I = P / V:

• A 32 A wallbox on 240 V delivers at most 7,680 W, about 7.7 kW. On 208 V the same 32 A gives 6,656 W.
• The Part 680 floor of 6 kW per AC port needs 6,000 / 208 ≈ 28.8 A at 208 V, or 25 A at 240 V.
• A 150 kW DC charger needs 375 A into a 400 V battery but 187.5 A into an 800 V battery. That is why high power cables are often liquid cooled, and why 800 V cars can draw more power at the same current.

How do the J1772 control pilot and proximity signals work?

SAE J1772 covers the physical, electrical and functional requirements for conductive charging in North America; the current revision is J1772_202401, first issued in October 1996. Its full text is sold by SAE, so the values below come from the EVerest bring-up guide, which tests chargers against IEC 61851-1 conventions that J1772 shares.

The control pilot and its states

The charger drives the pilot through a 970 to 1,030 ohm source resistance with either a steady plus 12 V or a square wave between plus and minus 12 V at 980 to 1,020 Hz, with the 12 V levels held within 5 percent. The car pulls the positive half down through resistors:

The A and F levels and the B and C resistances come from EVerest; the 9, 6, 3 and 0 V figures for B to E are the nominal levels commonly cited for J1772 and IEC 61851-1, which we could not check against the paid standard text. EVerest notes that State D existed for batteries that "leak hydrogen gas during charging".

Contactors close only in State C and open as soon as the car returns to B or A. EVerest's checklist asks for the relay to open within 100 ms of a return to State B, and for the safety microcontroller to refuse to close outside State C even if Linux asks.

The duty cycle advertises current

On AC the pilot's duty cycle tells the car how much current it may draw. EVerest states the rule as maximum amperes divided by 0.6 gives the duty cycle percent, and says DC always uses 5 percent. The 5 to 10 percent range is not used for current; 5 percent means "use digital communication".

Worked example 2: reading a pilot signal

Illustrations of the 0.6 rule:

• A 32 A wallbox sets 32 / 0.6 ≈ 53.3 percent, the EVerest example.
• A wallbox limited to 16 A by a smart charging schedule sets about 26.7 percent.
• A car that measures 25 percent may draw 25 × 0.6 = 15 A.
• At 1 kHz a period lasts 1 ms, so a 5 percent pulse is high for 50 microseconds, the figure EVerest asks testers to measure.

When the operator lowers a limit through OCPP smart charging, the visible effect on the cable is this duty cycle changing.

The proximity signal

The proximity circuit tells the charger or car that a plug is present. On J1772 connectors it is tied to the latch button, so the car can see the release being pressed. On European Type 2 sockets a resistor in the plug encodes the cable's current rating. EVerest notes tethered AC chargers do not use proximity for that purpose and DC chargers normally do not use it. We did not reproduce J1772 proximity resistor values because we could not confirm them on a free primary source.

How does a DC charger negotiate with the car?

DC charging starts on the same wire. The charger sets a 5 percent duty cycle, and the car and charger bring up power line communication over the pilot. A matching step called SLAC makes sure the car talks to the charger it is plugged into rather than its neighbour. Part 680 requires chargers to conform to ISO 15118-3, which covers this layer. The two sides then exchange ISO 15118-2 or ISO 15118-20 messages. EVerest's DC guide refers to the main phases:

1. Discovery and authorization. The car learns what the charger offers and picks a payment method: external identification such as a card or app, or a contract certificate for Plug and Charge.
2. Parameter exchange. Both sides state voltage, current and power limits.
3. Cable check. The charger applies a test voltage while the isolation monitor checks for insulation faults. EVerest warns that a slow monitor self test can make some cars time out here.
4. Precharge. The charger matches the battery voltage so the car can close its own contactors without an inrush.
5. Current demand loop. The car keeps requesting voltage and current; the charger follows within its limits and reports what it measured.
6. Stop. The charger ramps down and both sides open their contactors.

How are power modules built and tested?

Safety note. Power modules hold hazardous voltages in operation and afterwards. Production testing happens in interlocked test cells run by trained staff. This section describes what is tested, not how.

A DC charger's power module is a larger relative of a computer power supply: filter, rectify with power factor correction, convert through an isolating transformer, rectify again.

SiC MOSFETs versus IGBTs

Silicon IGBTs handle high voltage and current cheaply but switch relatively slowly, which keeps switching frequencies down and magnetics large. Silicon carbide MOSFETs block high voltages with lower switching losses, so designers can raise the frequency, shrink the magnetics and gain efficiency, at the cost of price, careful gate drive and fast voltage edges that complicate electromagnetic compatibility. Many recent modules use SiC in at least one stage. We do not rank suppliers or quote market shares, since no primary source we fetched publishes them.

Magnetics and the isolation barrier

The DC/DC transformer isolates the car from the grid. Its insulation system, creepage and clearance distances, and the hi-pot test that proves them are central to product safety. Power factor correction inductors use ferrite, powdered iron or nanocrystalline cores chosen for the switching frequency and acceptable losses.

What the line tests

These are the checks implied by the standards and open source bring-up guides, not one maker's recipe:

• Hi-pot and ground bond on every unit.
• Output accuracy. EVerest cites IEC 61851-1:2023 CC.6.3: voltage within plus or minus 10 V and current within 1.5 percent or 0.5 A, whichever is more.
• Dynamic behaviour. The output should reach the commanded voltage quickly (the EVerest guide checks within 6 seconds), not overshoot when stepping from low to high voltage, and fall to 0 V promptly when switched off.
• Loss of communication. A module whose controller goes silent should switch off; EVerest says most do within 10 to 20 seconds.
• Efficiency and power factor across the load range, including near zero load, which is what the module sees during cable check and precharge.
• Burn-in, where used, to catch early failures. Durations are proprietary.

How is energy metered and certified for billing?

Selling energy by the kilowatt hour turns a charger into a legal measuring instrument, like a fuel dispenser. Part 680 requires the price in dollars per kWh before the session and forbids changing it during the session, but it does not set meter accuracy. That comes from state weights and measures law, which in most states follows NIST Handbook 44.

NIST Handbook 44 Section 3.40

The 2026 edition is current. Section 3.40 was added as a tentative code in 2015 and made permanent effective 1 January 2023. The parts that shape how a charger is made:

• Marking: voltage rating, maximum current, AC or DC, minimum measured quantity, and any temperature limits narrower than minus 40 to plus 85 °C.
• Minimum measured quantity: no more than 0.5 kWh for AC and 1.0 kWh for DC.
• Tolerances: 1.0 percent acceptance and 2.0 percent maintenance for AC, and for DC unless the unit was placed in service before 1 January 2025 and marked Class 5, in which case both are 5.0 percent until 1 January 2034. They apply equally to over and under registration.
• Repeatability: repeated tests at one load may not spread by more than 25 percent of the maintenance tolerance's absolute value.
• DC type evaluation: one test voltage between 350 and 450 V DC and, if supported, one between 700 and 900 V DC, each at three currents: 10 to 20 percent of maximum deliverable amperes (at least 30 A), 40 to 60 percent, and 70 to 100 percent.
• DC field verification: two current levels, and Handbook 44 anticipates that an electric vehicle may serve as the test load.

Worked example 3: tolerances on a bill

Illustrations, not measurements of any product:

• A new DC charger delivers a session the car records as 60.0 kWh. At 2.0 percent maintenance tolerance, any register reading from 58.8 to 61.2 kWh passes. At 0.50 dollars per kWh, that is plus or minus 0.60 dollars.
• An older Class 5 DC charger may read 57.0 to 63.0 kWh for the same session, plus or minus 1.50 dollars.
• A new AC charger tested at a 0.5 kWh minimum measured quantity under the 1.0 percent acceptance tolerance must register between 0.495 and 0.505 kWh.

Why DC metering is harder, and how Europe signs readings

AC metering uses mature DIN rail meters, typically with a Modbus RS-485 interface, as the EVerest hardware guide notes. DC meters must measure high DC currents accurately, and losses between meter and car matter, which is part of why Handbook 44 gave older DC chargers a 5 percent class and a long transition.

In Germany, Eichrecht calls for signed meter values. EVerest's Eichrecht guide says the meter itself should track transactions and sign the OCMF records; EVerest only carries those signed values to the management system and "does not create, store or modify" them. Its OCMF guide shows the signed record travelling inside the OCPP stop transaction message, and recommends configuring the charger to stop the session on meter failures.

What software runs in an EV charger?

Safety note. Debug ports, service interfaces and firmware flashing on a deployed charger are for the manufacturer's authorized technicians. Do not connect to the internal interfaces of a charger you do not own and are not trained to service.

A modern charger runs two kinds of computer, and the split is deliberate.

The safety microcontroller

EVerest's hardware guide puts it plainly: "the high-level Linux controller cannot guarantee timings or even that it is running at all." A safety microcontroller therefore generates the pilot PWM, reads the pilot state and owns the contactor. It closes the contactor only when its own conditions (pilot in State C, no over-temperature from the connector's PT1000 sensor, earth present) and the Linux request agree, and it opens it on any critical fault without waiting. Residual current, isolation and over-voltage monitors should be able to open the contactors directly too. The guide notes this microcontroller "may require certification for e.g. UL" because it implements safety in software.

The high level controller

The other computer is usually an ARM module running embedded Linux, often built with the Yocto Project. It runs:

• The charging application, for example EVerest, which manages sessions, energy limits and authorization, and talks to power supplies, meters and monitors over CAN, RS-485 or Ethernet.
• An OCPP client holding a WebSocket connection to the charging station management system (CSMS).
• An ISO 15118 stack and SLAC module for the car.
• Authorization front ends: RFID or NFC readers, a contactless card terminal (Part 680 requires contactless debit and credit cards on funded stations) and Plug and Charge.
• The display, which on funded chargers must show the price per kWh.
• The update agent, network stack and TLS libraries everything above depends on.

All of it is compiled into a firmware image, much of it open source. That is where a charger's supply chain looks like any other Linux product's.

How are charger firmware updates delivered?

OCPP puts the management system in charge. The Open Charge Alliance's whitepaper on the UK smart charge point regulations explains that the CSMS notifies the charger of an update, and that OCPP's secure firmware update mechanism requires a manufacturer signing certificate that the charger uses to check the image's integrity. That is use case L01 in the FirmwareManagement section of OCPP 2.0.1, and L01 in the Secure Firmware Update section of the OCPP 1.6 security whitepaper.

On the device, EVerest uses RAUC, an open source updater: bundles are signed and optionally encrypted, the signature is checked during installation, and A/B partitions mean a power cut mid update cannot brick the unit. Because trust comes from the signature, a bundle can come over plain HTTP or a USB stick, and RAUC can stream only the changed blocks. In the OCPP flow the operator hosts the bundle on an HTTP server with range request support, the CSMS sends the URL, and the charger triggers RAUC.

Part 680 requires funded chargers to "receive and implement secure, remote software updates." EVerest's security best practices add the device side: secure boot so unsigned code cannot run, no UART console login, locked SWD and JTAG ports, private keys in a secure vault, signed updates for every component, charging modules not running as root, and careful custody of the root key: "If you loose the private root key, the hardware in the field is lost."

How does ISO 15118 Plug and Charge use certificates?

Plug and Charge lets a driver plug in and charge with no card or app. The car proves its contract with a certificate, and the charger forwards that proof to the operator's backend.

The certificates on the charger

EVerest's Plug and Charge explanation lists what the charger needs:

• V2G root certificate(s), the trust anchors of the charging PKI.
• The SECC leaf certificate with its sub CA chain and private key. SECC is the supply equipment communication controller, the charger side of ISO 15118; this certificate identifies the charger in the TLS handshake.
• Mobility operator root certificates, optional, needed only to verify contract certificates locally.

These can be installed at the factory or over OCPP. If Plug and Charge is enabled and the SECC leaf certificate is missing or expires within 30 days, EVerest creates a certificate signing request and sends it to the CSMS in an OCPP SignCertificate message.

The session

1. The car plugs in, the pilot goes to 5 percent and SLAC pairs the modems.
2. The charger's ISO 15118 module starts a TLS server with its SECC certificate chain. Plug and Charge requires TLS.
3. Both sides agree on "Contract" as the payment method, and the car sends its contract certificate chain.
4. The charger passes the contract certificate and OCSP request data to its OCPP module.
5. The OCPP module validates locally or asks the CSMS, which checks with the mobility operator and returns accepted or rejected.
6. Charging proceeds and the metered energy is billed to that contract.

What changes in ISO 15118-20?

ISO 15118-20:2022 is the second generation network and application protocol. ISO's abstract says it defines messages for bidirectional power transfer, wireless communication for conductive and wireless charging, communication for automatic connection devices, and information services about charging status. OCPP 2.1 added support for it, with new functional blocks for bidirectional charging and distributed energy resource control. EVerest ships a separate module for the -20 stack and documents a migration path from its older ISO 15118-2 module.

Part 680 spans both: hardware capable of ISO 15118-2 and -20, and ISO 15118-2 software with Plug and Charge by 28 February 2024.

Why the PKI is the hard part

Certificates expire, roots are added and retired, and every charger, car and backend must agree on what to trust. NIST IR 8473, the cybersecurity framework profile for extreme fast charging, treats software and firmware certificates, credential management and verified updates as core controls across vehicle, charger, cloud and utility domains. Operators need an inventory of which certificates sit on which charger and when each expires, and a tested rotation process over OCPP.

What do US federal minimum standards for funded chargers require?

23 CFR Part 680 sets minimum standards for chargers funded under the National Electric Vehicle Infrastructure (NEVI) Formula Program and for public chargers built with other Title 23 funds. The final rule was published on 28 February 2023 and took effect on 30 March 2023. The table is taken from the current eCFR text.

The topic brief behind this post suggested Part 680 cites Handbook 44. The eCFR text we fetched does not; it asks chargers to "securely measure" energy and leaves accuracy to state weights and measures law. NIST IR 8473 does list Handbook 44 among its references. Program guidance can change, so check the eCFR and your state's deployment plan before relying on this summary.

Worked example 4: the 97 percent uptime formula

Part 680 defines port uptime as μ = ((525,600 − (T_outage − T_excluded)) / 525,600) × 100. 525,600 is the minutes in a year; T_excluded covers outages outside the operator's control, such as utility interruptions, vehicle faults, scheduled maintenance, vandalism and natural disasters. Illustrations:

• Staying above 97 percent allows under 15,768 minutes of net outage a year, about 263 hours or just under 11 days per port.
• A port with 20,000 outage minutes, 6,000 of them excluded, has 14,000 net minutes: (525,600 − 14,000) / 525,600 × 100 ≈ 97.34 percent, a pass.
• Add a failed firmware update that takes the port down for 3 more days (4,320 minutes). A failed update is not on the excluded list, so net outage becomes 18,320 minutes and uptime falls to about 96.5 percent, a fail. Signed A/B updates with automatic rollback are a commercial requirement as much as a security one.

The Open Charge Alliance publishes a whitepaper on improving uptime monitoring with OCPP that lists the standard error codes used in the US and Korea.

Where does a charger's software supply chain risk come from?

A charger is a long lived, internet connected Linux device bolted to the grid. NIST IR 8473 flags "outdated kernels, unsigned firmware" and remotely accessible services and recommends regularly updating the software and firmware of all components. The main areas:

• Open source components in firmware: kernel, TLS library, WebSocket and JSON libraries in the OCPP client, the ISO 15118 stack, the local commissioning web UI. A charger designed in 2022 and maintained until 2030 will see many security releases of each.
• The backend. Management systems are ordinary cloud software. CitrineOS, the open source OCPP 2.0.1 system used below, is a pnpm monorepo that runs with RabbitMQ, PostgreSQL and Hasura.
• Keys and certificates: secure boot, update signing, OCPP client and ISO 15118 certificates, all with lifecycles.
• Configuration drift, such as a charger left on security profile 1 after commissioning.
• Third party modules: payment terminals, modems and power modules carry their own firmware from their own suppliers.

Step by step: run an OCPP central system in a lab and require client certificates

This walkthrough is software only. It runs an open source OCPP 2.0.1 management system and a simulated charge point on your own computer and touches no charger or mains equipment. Do not point it at chargers you do not own.

You need Git, Node.js 24.16.0 or newer, pnpm, Docker 20.10 or newer (versions from the CitrineOS README), Python 3 and OpenSSL.

1. Start CitrineOS

git clone https://github.com/citrineos/citrineos-core
cd citrineos-core
pnpm install
pnpm run build
pnpm citrine

The launcher starts the OCPP server, operator UI, RabbitMQ, PostgreSQL and Hasura from published images. Per the README, the operator UI is at http://localhost:3000 and the server listens on:

OCPP itself defines profiles 1 to 3: unsecured transport with basic authentication, TLS with basic authentication, and TLS with client side certificates. Profile 0 is a CitrineOS test convenience; never use it outside a lab.

2. Connect a simulated charge point without security

python3 -m venv ocpp-lab && . ocpp-lab/bin/activate
pip install ocpp websockets

Save this as cp_plain.py. It is adapted from the open source Python OCPP library's own v2.0.1 example and only sends a BootNotification:

import asyncio
import logging
import websockets
from ocpp.v201 import ChargePoint as cp
from ocpp.v201 import call

logging.basicConfig(level=logging.INFO)

class ChargePoint(cp):
    async def send_boot_notification(self):
        request = call.BootNotification(
            charging_station={"model": "LabWallbox", "vendor_name": "Lab"},
            reason="PowerUp",
        )
        response = await self.call(request)
        print("BootNotification status:", response.status)

async def main():
    async with websockets.connect(
        "ws://localhost:8081/lab-cp-001", subprotocols=["ocpp2.0.1"]
    ) as ws:
        charge_point = ChargePoint("lab-cp-001", ws)
        await asyncio.gather(charge_point.start(), charge_point.send_boot_notification())

asyncio.run(main())

Run python cp_plain.py and watch the CitrineOS logs and UI. Depending on configuration you may need to register the station identifier in the UI first.

3. Create a lab CA and a client certificate

These keys are for the lab only.

mkdir -p lab-pki && cd lab-pki
# Lab root CA
openssl ecparam -name prime256v1 -genkey -noout -out lab-ca.key
openssl req -x509 -new -key lab-ca.key -sha256 -days 365 \
  -subj "/CN=OCPP Lab Root CA" -out lab-ca.pem
# Charge point client certificate; put the station identifier in the subject
openssl ecparam -name prime256v1 -genkey -noout -out lab-cp-001.key
openssl req -new -key lab-cp-001.key -subj "/O=Lab/CN=lab-cp-001" -out lab-cp-001.csr
openssl x509 -req -in lab-cp-001.csr -CA lab-ca.pem -CAkey lab-ca.key \
  -CAcreateserial -days 90 -sha256 -out lab-cp-001.pem
openssl verify -CAfile lab-ca.pem lab-cp-001.pem

Configure the CitrineOS profile 3 listener with a server certificate and lab-ca.pem as the trusted client CA. Configuration keys move between releases, so follow the current CitrineOS documentation rather than a path copied from a blog post.

4. Check what the server demands

# Without a client certificate: the handshake should fail
openssl s_client -connect localhost:8444 -CAfile lab-ca.pem </dev/null
# With the client certificate: the handshake should complete
openssl s_client -connect localhost:8444 -CAfile lab-ca.pem \
  -cert lab-cp-001.pem -key lab-cp-001.key </dev/null

Check the verify return code and that the server's certificate request lists your CA.

5. Connect over mutual TLS

Copy cp_plain.py to cp_mtls.py and change only the connection:

import ssl

ctx = ssl.create_default_context(ssl.Purpose.SERVER_AUTH, cafile="lab-pki/lab-ca.pem")
ctx.load_cert_chain(certfile="lab-pki/lab-cp-001.pem", keyfile="lab-pki/lab-cp-001.key")
ctx.minimum_version = ssl.TLSVersion.TLSv1_2

async def main():
    async with websockets.connect(
        "wss://localhost:8444/lab-cp-001", subprotocols=["ocpp2.0.1"], ssl=ctx
    ) as ws:
        charge_point = ChargePoint("lab-cp-001", ws)
        await asyncio.gather(charge_point.start(), charge_point.send_boot_notification())

If the server certificate names a different host than localhost, fix the certificate rather than disabling host name checks.

6. Prove the negative cases

A control is real only if it fails closed. Confirm each of these is refused: no client certificate; a certificate from a different CA; an expired certificate; a certificate whose common name does not match the station identifier in the URL. If your CSMS accepts the last one, that is a configuration finding.

7. Record what you ran

Note the CitrineOS release, pip show ocpp, openssl version and the negotiated TLS version. Done for real chargers, that habit is the start of a firmware and backend inventory.

Common mistakes

• Treating Linux as the safety system. Contactor control and fault trips belong in hardware and a safety microcontroller.
• Commissioning on security profile 1 and never moving on. The Open Charge Alliance recommends profile 2 or 3, both of which use TLS.
• Relying on TLS instead of image signatures. TLS protects the download; only a signature checked at install time protects against a tampered image from any source.
• Single partition updates. A power cut mid update can brick a charger, and that outage is not excluded from Part 680 uptime.
• Losing or exposing the signing key. Without it, fielded chargers cannot be updated.
• Forgetting certificate expiry. SECC, OCPP client and update signing certificates all expire; plan rotation over OCPP.
• Leaving debug ports open. UART, JTAG and SWD on a public charger should be locked for production.
• Inventorying hardware but not software. Many operators know every serial number but not which kernel, TLS library or OCPP stack each charger runs, or what the backend's containers contain.

FAQ

What is inside an EV charger?

A Level 2 AC charger contains contactors, residual current protection, a control pilot circuit, a meter, a controller and a network interface. A DC fast charger adds rectifier and DC/DC power modules, an isolation monitor, an over-voltage monitor, cooling, a DC meter, a payment terminal and a display.

What is the difference between Level 2 and DC fast charging?

Level 2 delivers AC at 208 to 240 V and relies on the car's onboard charger. DC fast charging converts power inside the charger and feeds the battery directly; funded US corridor chargers must deliver at least 150 kW per port.

How does the J1772 pilot signal set charging current?

The charger sends a 1 kHz square wave between plus and minus 12 V. Multiply the duty cycle percent by 0.6 to get the current limit: 53.3 percent means 32 A. A 5 percent duty cycle tells the car to use digital communication.

How accurate do EV charger meters have to be?

In the US, NIST Handbook 44 Section 3.40 sets 1.0 percent acceptance and 2.0 percent maintenance tolerance for new AC and DC chargers. DC chargers placed in service before 2025 can be marked Class 5 and held to 5.0 percent until 1 January 2034.

What is OCPP and which version should a new charger support?

OCPP is the open protocol between chargers and management systems, maintained by the Open Charge Alliance. Versions 1.6, 2.0.1 and 2.1 are current, and 1.6 and 2.0.1 are not compatible. Funded US chargers must support OCPP 2.0.1.

What are OCPP security profiles 1, 2 and 3?

Profile 1 is unsecured transport with basic authentication, profile 2 is TLS with basic authentication, and profile 3 is TLS with client side certificates. The Open Charge Alliance recommends profile 2 or 3.

How are EV charger firmware updates secured?

The management system tells the charger where to download an update, and the charger checks the image with a manufacturer signing certificate before installing it. On the device, signed A/B updates with rollback protect against tampering and failed installs.

What is Plug and Charge?

It is the ISO 15118 feature that lets a car authorize a session with a contract certificate instead of a card or app. The charger presents its own certificate over TLS, receives the car's contract certificate and forwards it to the backend for validation.

What uptime must NEVI funded chargers meet?

Each port must average more than 97 percent uptime over the previous 12 months, calculated monthly with the formula in 23 CFR 680.116(b). Utility interruptions, vehicle faults, scheduled maintenance, vandalism and natural disasters can be excluded.

Fix it without waiting for upstream

A charger's power electronics and meter are hardware problems, but the controller, the OCPP and ISO 15118 stacks, the update agent and the management system behind them are built from open source dependencies and container images that need patching for years after a charger is installed. Safeguard does not analyze charger hardware, power modules, meters or firmware images, so its fit here is the software your team builds and ships around the charger: the backend, the commissioning tools and, if a supplier gives you one, a firmware SBOM file you can scan.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE in a repository. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same flow applies to a Node.js charging management backend like the one in the lab above.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Charger software teams that build Yocto images or backend containers on internal build hosts can keep scans on that hardware.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how to choose which tools Claude can use. An engineer can then ask which projects carry a given TLS or WebSocket library version without granting more access than intended.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Open Charge Alliance, Open Charge Point Protocol versions 1.6, 2.0.1 and 2.1
• Open Charge Alliance, OCPP and UK Electric Vehicles (Smart Charge Points) Regulations 2021 whitepaper page
• Open Charge Alliance, OCPP and UK EV regulation whitepaper v1.0 (PDF)
• Open Charge Alliance, Improving uptime monitoring with OCPP (v1.3)
• SAE International, J1772_202401 Electric Vehicle and Plug in Hybrid Electric Vehicle Conductive Charge Coupler
• ISO, ISO 15118-20:2022
• IEC, IEC 61851-1:2017
• eCFR, 23 CFR Part 680, National Electric Vehicle Infrastructure Standards and Requirements
• Federal Register, National Electric Vehicle Infrastructure Standards and Requirements, 88 FR 12724 (28 February 2023)
• NIST, Handbook 44 current edition (2026)
• NIST, Handbook 44 2026, Section 3.40 Electric Vehicle Fueling Systems (PDF)
• NIST, IR 8473 Cybersecurity Framework Profile for Electric Vehicle Extreme Fast Charging Infrastructure (October 2023)
• US EPA, ENERGY STAR EV chargers
• EVerest documentation, hardware architecture
• EVerest documentation, basic bring-up (control pilot, relays, proximity pilot)
• EVerest documentation, AC bring-up
• EVerest documentation, DC bring-up
• EVerest documentation, the Plug and Charge process
• EVerest documentation, powermeter OCMF handling
• EVerest documentation, over the air updates
• EVerest documentation, security best practices
• RAUC documentation, basics
• CitrineOS core repository and README
• OCPP Python library repository
• OCPP Python library, v2.0.1 charge point example

Last reviewed: 24 October 2026.