OCPP security profile post-quantum TLS: is it quantum safe?

OCPP security profile post-quantum TLS means upgrading the TLS connections that OCPP security profiles 2 and 3 use between EV chargers and a charging station management system (CSMS) so that they resist a future quantum computer. In practice this means adding hybrid ML-KEM key agreement under TLS 1.3 first, and moving to post-quantum certificate signatures later.

For charge point operators this is an engineering problem, not a theoretical one. Charger fleets stay in the field for a decade or more, firmware updates are slow, and the hardware security modules and secure elements that hold charger keys were chosen years before ML-KEM was standardised. This article covers what OCPP specifies today, which parts can be upgraded now, and how to handle the chargers that cannot be upgraded.

Which OCPP security profiles use TLS, and are they quantum safe?

Security profiles 2 and 3 use TLS, profile 1 does not, and none of the three is quantum safe today. All of them depend on classical elliptic-curve or RSA cryptography for key exchange and authentication.

The Open Charge Alliance defines three profiles in OCPP 2.0.1 (and in the security whitepaper that backports them to OCPP 1.6-J). OCPP 2 can operate according to three security profiles: Unsecured Transport with Basic Authentication, TLS with Basic Authentication and TLS with Client-Side Certificates. In profile 2 the charger proves its identity at the application layer. OCPP in all but its highest security profile uses some form of static credential as a secret to identify and authenticate the client to the server, and most versions of OCPP use username/password combinations.

The cipher suites OCPP 2.0.1 requires are ECDHE suites with ECDSA or RSA authentication and AES-GCM. AES-GCM itself is not the weak point. The weak points are the ECDHE handshake and the certificate signatures, which are exactly the algorithms on NIST’s deprecation list.

Is harvest now, decrypt later a real risk for EV charging backend traffic?

Yes, for some of the traffic. The risk depends on how long the data stays sensitive, and some OCPP payloads stay sensitive far longer than a charging session lasts.

Harvest now, decrypt later means recording encrypted traffic today in order to decrypt it once a cryptographically relevant quantum computer exists. Much of what OCPP carries, such as meter values or connector status, loses its value within days. Other content does not:

• Profile 2 Basic Auth passwords. Many fleets never rotate them. A password that is still valid in ten years is a long-lived secret travelling inside a classical TLS session.
• idTokens and transaction records. RFID identifiers linked to charging locations and times are personal data, and that data stays sensitive for years.
• Charging profiles and grid signals. Aggregated smart charging data shows load patterns and flexibility at sites that may count as critical infrastructure.
• Firmware update metadata and certificate operations. These describe the trust structure of the whole fleet.

Public authorities treat the threat as a planning input. All EU Member States should start transitioning to post-quantum cryptography by the end of 2026, and the protection of critical infrastructures should be transitioned to PQC as soon as possible, no later than by the end of 2030.

Can EV chargers negotiate hybrid ML-KEM with a self-hosted charging station management system?

Yes, but only when the charger firmware and the CSMS TLS endpoint both support TLS 1.3 with a hybrid ML-KEM group. On the server side you can usually arrange that yourself. On the charger side it depends on the TLS stack the manufacturer ships.

Hybrid key agreement for TLS is specified as an IETF draft built on RFC 8446 (TLS 1.3). It defines three hybrid key agreement mechanisms for TLS 1.3, X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, that combine the post-quantum ML-KEM with an ECDHE exchange. The IETF TLS Working Group describes the aim as to “provide security against both classical and quantum adversaries while maintaining compatibility with existing infrastructure and protocols.”

A self-hosted CSMS has an advantage here: you control the TLS termination point, whether that is the CSMS process itself or a reverse proxy in front of it. Practical points:

• Offer hybrid and classical groups side by side. TLS 1.3 negotiates the key share, so chargers that do not offer ML-KEM fall back to classical ECDHE without breaking. Log which group each charger negotiates. That log becomes your migration dashboard.
• Choose the group with your certificate profile in mind. OCPP fleets commonly use P-256. The group that uses secp256r1 (NIST P-256) supports use cases that require both shared secrets to be generated by FIPS-approved mechanisms.
• Test on the real transport. Hybrid key shares are much larger than classical ones, which matters on cellular modems and behind middleboxes that inspect ClientHello messages.

Statistic: Hybrid X25519MLKEM768 increases the client and server key share entries to 1216 and 1120 bytes, respectively (arXiv 2608.22683, 2026). A ClientHello that grows past one packet can expose MTU issues or fragile inspection devices along an LTE path.

Also check that your CSMS still meets the OCPP 2.0.1 requirement to support TLS 1.2 for chargers that need it. A TLS 1.3-only endpoint would cut those chargers off.

How do I migrate charger client certificates in OCPP security profile 3 to post-quantum algorithms?

Treat it as a separate, slower project that starts with crypto agility in your PKI rather than with new certificates. OCPP’s certificate flows are largely algorithm-neutral, but charger secure elements and the specification’s algorithm lists are not yet ready for ML-DSA.

In OCPP 2.0.1 the charger generates its own key pair and sends a certificate signing request through SignCertificate. The CSMS returns the signed certificate through CertificateSigned, and root certificates are managed with InstallCertificate. Because the CSR is a standard PKCS#10 structure, the message flow can in principle carry a post-quantum public key. The obstacles are elsewhere:

1. Key storage. Many chargers keep the private key in a secure element that supports only P-256 or RSA. A firmware update cannot add ML-DSA to fixed silicon.
2. Specification alignment. OCPP 2.0.1 lists classical algorithms. Until the Open Charge Alliance publishes updated guidance, ML-DSA certificates are a bilateral arrangement between you and the charger manufacturer. Parallel work in IEC 63110 on managing charging infrastructure will need the same alignment.
3. CA readiness. Your issuing CA and any HSM behind it must be able to sign with ML-DSA, and the CSMS TLS stack must be able to verify the result.

A workable sequence: inventory which charger models use which secure element; shorten certificate lifetimes so rotation becomes routine; stand up a separate post-quantum test CA; and run ML-DSA client certificates against a dedicated CSMS endpoint on a small pilot group before touching production trust anchors. NIST’s guidance is that organizations must identify where vulnerable algorithms are used and plan to replace or update them.

Statistic: NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035 (NIST IR 8547, October 2026). Chargers installed today with ECDSA-only secure elements will still be in service when that window closes.

What can operators do for chargers whose firmware only supports TLS 1.2?

Keep TLS 1.2 for authentication and add a quantum-safe layer underneath it on the path between site and CSMS. No standardised hybrid ML-KEM exists for TLS 1.2, and the IETF hybrid groups are defined for TLS 1.3 only.

A network-layer tunnel works well for sites where many chargers share one uplink, such as depots, parking garages and highway hubs. Quantum Network’s QPN, for example, is a gateway placed at each end of a connection. It encrypts at Layer 3 using hybrid key agreement that combines a classical part with ML-KEM (FIPS 203), and it needs no software on the chargers behind it. With a gateway at the site and a virtual gateway next to a self-hosted CSMS, the OCPP TLS 1.2 session runs unchanged inside the tunnel. Note that such a gateway protects data in transit only. It does not replace the CSMS firewall or the charger’s own authentication.

When do charge point operators need post-quantum TLS in place?

The deadlines that matter most in Europe point to 2030 for critical use cases. Operators should therefore be testing hybrid key exchange now, because fleet-wide firmware cycles take years.

Directive (EU) 2022/2555 (NIS2) lists operators of recharging points in its energy sector annex, and Article 21 expects policies on cryptography and encryption. The European Commission says critical infrastructure should be “transitioned to PQC as soon as possible, no later than by the end of 2030,” building on Commission Recommendation (EU) 2024/1101 of 11 April 2024 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography.

Statistic: A Council of the EU document on the NIS framework aims at achieving the migration to PQC by 2030 for critical use cases and by 2035 for medium and low level use cases (Council document 5627/26, 22 January 2026).

Statistic: In the United States, OMB Memorandum M-26-15 requires high value assets, high impact systems, and other systems with highly sensitive data to transition to quantum-resistant key establishment by December 31, 2030 (NIST IR 8547, October 2026).