Plug & Charge: charging without a card, an app or an account

The process Plug & Charge describes is unspectacular: plug in the cable, charging starts, billing happens. No card, no app, no QR code, no registration at the charger. That unspectacular quality is precisely the point — it is why the method is sold as a convenience feature, and why the technology behind it is more involved than the result suggests.

What actually happens

The basis is the ISO 15118 series of standards, which describes communication between vehicle and charge point. Instead of a mere control signal, a real data connection runs over the charging cable — for CCS, via powerline on the control pilot contact.

Over that connection the vehicle presents a contract certificate. This is not a vehicle identification number or a serial number but cryptographic proof that a charging contract with a mobility provider exists for this vehicle. The charge point validates the certificate against a chain of trust, reports the identity to its backend, and the backend decides on authorisation and tariff.

For this to work across manufacturers, a shared public key infrastructure is required: root certificates, intermediates, issuance and revocation processes. In practice that means an operator joins an existing ecosystem rather than building its own chain of trust.

Two editions of the standard matter: ISO 15118-2 is the widespread version the vehicles in the field today build on. ISO 15118-20 is the newer generation — more modern cryptography and, decisive for the future, the description of bidirectional charging. Anyone procuring today should know which of the two a charger speaks; it is also the key fork for V2G.

Autocharge is something else

In practice you frequently meet Autocharge, and it is readily lumped together with Plug & Charge. The difference is substantial.

Autocharge uses the MAC address the vehicle announces anyway when establishing the powerline connection as an identifier. The backend keeps a list of which identifier belongs to which customer. No certificate, no validation, no standard.

That has a real advantage: it works with many vehicles immediately and essentially requires backend support from the operator. And it has an equally real drawback: a MAC address is an identifier, not proof. It is not cryptographically validated and it can be spoofed. For a closed depot with known vehicles that is a defensible trade-off. For public charging with open billing it is a different discussion.

What the operator needs

Four things have to come together, and three of them are not in the vehicle:

1. Charge points with suitable hardware and firmware. A powerline modem in the charge point is a precondition. Whether an existing charger has one is a question for the manufacturer — it can rarely be retrofitted.
2. A backend that models the certificate processes. Here OCPP 2.0.1 is the practical precondition: only there are installation, update and revocation of certificates cleanly modelled. Under OCPP 1.6 it works only through vendor-specific extensions — which narrows your freedom when buying chargers. aCharge Cloud speaks OCPP 1.6, OCPP 1.6 Security and OCPP 2.0.1, so the protocol side is prepared.
3. A connection to a PKI. Chain of trust, certificate supply, revocation lists — that is a contract, not a configuration checkbox.
4. A mobility provider that issues contract certificates. Without a counterpart on the contract side, the best charger helps nothing.

The mistake that gets expensive

Plug & Charge does not replace ad-hoc payment. It is a convenience path for customers with a contract; anyone standing at the charger without one must still be able to charge and pay spontaneously — for new public charge points that is required under European law. A site concept that plans Plug & Charge as a substitute for card payment or a QR code misses the requirement.

Conversely: for closed applications the benefit is greatest and the hurdle lowest. In a depot, vehicle-bound identification solves exactly the problem RFID cards chronically have there — they get swapped, mislaid and forgotten, and at month end the cost centre does not add up. Why attribution belongs to the vehicle rather than the driver is covered in more detail in the article on fleet optimisation.

What to check

1. Which standard do your chargers speak? ISO 15118-2, -20 or nothing at all. Ask for the specific firmware version, not the product family.
2. Which OCPP does your backend speak? Without 2.0.1, every Plug & Charge rollout becomes vendor-specific.
3. Is Autocharge enough? For a closed depot, often yes — and it is orders of magnitude faster to introduce.
4. Is ad-hoc payment assured independently? It remains mandatory.
5. What happens with an expired certificate? The failure case belongs in operational planning, not in the first support call.

If you want an assessment of what your estate supports: get in touch.

As of 16 March 2021. Availability and implementation of Plug & Charge differ considerably by vehicle, charge point and mobility provider; this article describes the general framework.