OCPP Security Profiles Explained: Securing Your EV Charging Network

Start with deployment exposure, not protocol purity

Most teams begin with the wrong question:

Which security profile does the charger support?

The more useful question is:

What level of exposure does this deployment have, and what operational process do we have to keep certificates, firmware, and charger identity under control?

That is what should drive profile selection:

• private lab or tightly controlled fleet site
• public charger network
• payment-sensitive or compliance-sensitive environment
• firmware distribution risk
• internal ability to run PKI operations safely

Security profile choice is therefore part of rollout design, not just protocol compliance.

Why EV charging security matters

An EV charger is a network-connected device that handles electricity, payment data, and personal information. A compromised charger can:

• Steal energy — unauthorized sessions at your expense
• Exfiltrate data — session data, user tokens, payment information
• Cause safety hazards — malicious firmware could override safety limits
• Pivot into your network — a charger on your LAN is an attack surface

Yet most EV charging deployments run with minimal security. Many chargers still communicate over unencrypted WebSocket connections with no authentication.

The three OCPP security profiles

OCPP 2.0.1 defines three security profiles, each building on the previous one.

Security Profile 1: Basic Authentication

The simplest option. The charger authenticates to the central system using a username and password sent over TLS.

How it works:

1. Charger establishes a TLS connection to the central system
2. Charger sends credentials in the WebSocket handshake (HTTP Basic Auth)
3. Central system validates credentials and accepts or rejects the connection

When to use it: Private networks with trusted hardware. Company fleet chargers behind a firewall.

Limitations: Anyone who intercepts the credentials can impersonate the charger. No charger identity verification beyond the password.

Security Profile 2: TLS with Client Certificates

Both the charger and central system authenticate each other using X.509 certificates. This is mutual TLS (mTLS).

How it works:

1. Central system presents its server certificate (standard TLS)
2. Charger presents its client certificate
3. Both sides verify each other's certificate chain against a trusted CA
4. Connection established only if both certificates are valid

When to use it: Any public-facing deployment. Networks handling payment data. Compliance-sensitive environments.

Why it matters: A stolen password lets an attacker impersonate a charger. A stolen certificate is useless without the corresponding private key, which is stored in the charger's secure element.

Security Profile 3: Signed Firmware Updates

Builds on Profile 2 by adding cryptographic verification of firmware packages before installation.

How it works:

1. All of Profile 2 (mutual TLS)
2. Firmware packages are signed by the manufacturer or operator
3. Before installing firmware, the charger verifies the signature against a trusted key
4. Unsigned or tampered firmware is rejected

When to use it: Critical infrastructure deployments. When firmware integrity is essential (e.g., chargers with payment terminals).

Certificate management in practice

The hardest part of Profile 2 and 3 isn't the TLS handshake — it's managing certificates at scale.

Certificate lifecycle

Every certificate has a lifecycle:

1. Issuance — generate a key pair, create a CSR, sign the certificate
2. Distribution — install the certificate on the charger
3. Monitoring — track expiry dates across your fleet
4. Renewal — issue new certificates before old ones expire
5. Revocation — invalidate compromised certificates immediately

At 10 chargers, you can manage this manually. At 1,000, you need automation.

Certificate hierarchy

A typical EV charging PKI looks like this:

Root CA (offline, air-gapped)
├── Intermediate CA (CSMS)
│   ├── Central System certificate
│   └── Charger certificates (one per station)
└── Intermediate CA (Manufacturer)
    └── Firmware signing certificate

The root CA should never be online. All day-to-day operations use intermediate CAs.

OCPP certificate messages

OCPP 2.0.1 provides built-in messages for certificate management:

• InstallCertificate — install a CA certificate on the charger
• GetInstalledCertificateIds — list certificates installed on the charger
• DeleteCertificate — remove a certificate from the charger
• SignCertificate / CertificateSigned — charger-initiated certificate renewal via CSR

Common security mistakes

Running OCPP over plain WebSocket (ws://). Always use WSS. There is no valid reason to run unencrypted OCPP in 2026.

Using self-signed certificates without pinning. Self-signed certificates are fine for development but require certificate pinning in production to prevent MITM attacks.

Not rotating certificates before expiry. A certificate expiry takes your entire fleet offline. Set up automated renewal with 30-day lead time.

Storing private keys in firmware images. The private key should be generated on the charger and never leave it. Use a CSR-based enrollment flow.

Ignoring revocation. When a charger is decommissioned or compromised, its certificate must be revoked. Implement CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol) checking.

A realistic rollout sequence

For most serious deployments, the safest sequence looks like this:

1. Eliminate plain WebSocket Move all chargers to WSS before attempting broader security changes.
2. Standardize server trust Make sure chargers validate the central system certificate correctly and consistently.
3. Introduce client certificates Roll out charger identity through Profile 2 on a controlled hardware segment first.
4. Automate renewal and expiry monitoring Do not scale mTLS fleet-wide until renewals and alerts are proven.
5. Add firmware signing controls Only then move critical fleets toward Profile 3 if firmware integrity is part of the threat model.

This is slower than a checkbox rollout, but much safer operationally.

Minimum controls before production

Before you call a secure OCPP deployment production-ready, verify:

• a documented certificate issuance flow
• renewal alerts with lead time
• revocation procedure tested on a real charger
• incident runbook for expired or compromised certificates
• separation of root and intermediate CA responsibilities
• firmware signing and verification tested end to end if Profile 3 is in scope

If one of those is missing, the protocol may be configured correctly while the deployment is still fragile.

How EV Cloud handles security

EV Cloud provides built-in certificate management for OCPP Security Profiles 1, 2, and 3:

• Automated CA — issue and manage charger certificates from the dashboard
• Expiry monitoring — alerts before certificates expire
• CSR-based enrollment — chargers generate their own keys for maximum security
• One-click revocation — instantly revoke compromised certificates
• Firmware signing — sign and distribute firmware with integrity verification

No manual PKI operations required.

Next step for rollout teams

If security profile selection is active in your deployment, continue with:

1. OCPP 1.6 to 2.0.1 migration guide if certificate rollout is part of a protocol transition.
2. How to evaluate an OCPP platform if you need to score vendor security operations, not just feature claims.
3. Talk to EV Cloud if your team needs help with certificate operations, mTLS rollout, or charger identity architecture.