OCPP Security Profiles 1, 2, 3 Explained for CPOs

Start with deployment exposure, not protocol purity

Pick the security profile that matches your deployment's exposure and your team's ability to run certificate operations, not the highest number a datasheet advertises. Profile choice is a rollout decision first and a protocol checkbox second.

Across the OCPP integrations I've worked on, the teams that struggle most are the ones that picked Profile 2 or 3 to satisfy a procurement line, then discovered they had no process to renew or revoke certificates at fleet scale. The protocol was "supported" and the deployment was still fragile.

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

A charger is a network-connected device that controls real electricity and touches payment data, so a compromise is an energy, safety, and data problem at once. Security profiles exist to give that device a verifiable identity and a trusted channel back to your CSMS.

Concretely, 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.

What are the three OCPP security profiles?

OCPP 2.0.1, maintained by the Open Charge Alliance, defines three security profiles that build on each other: Profile 1 is basic authentication over TLS, Profile 2 adds mutual TLS with client certificates, and Profile 3 layers on signed firmware updates. Each step raises both the security guarantee and the certificate operations burden.

The table below summarizes how they compare in practice, before we walk through each one in detail.

Security Profile 1: Basic authentication

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

How it works:

1. Charger establishes a TLS connection to the CSMS
2. Charger sends credentials in the WebSocket handshake (HTTP Basic Auth)
3. The CSMS 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 CSMS authenticate each other using X.509 certificates. This is mutual TLS (mTLS).

How it works:

1. The CSMS 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).

Managing certificates at scale

The hard part of Profiles 2 and 3 is not the TLS handshake, which is solved the moment a connection succeeds in the lab. The real work is the certificate lifecycle: issuing, distributing, monitoring, renewing, and revoking thousands of charger identities without taking the fleet offline.

In mixed-fleet rollouts I've seen, this is reliably where the cracks appear. A single vendor model handles enrollment one way, another expects a pre-loaded certificate, and a third silently ignores renewal messages. The protocol looks identical on paper; the operational reality is anything but. Treat certificate operations as a first-class system, not a deployment afterthought.

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

The most common OCPP security mistakes

The recurring failures in secure OCPP deployments are operational, not cryptographic: plaintext transport, unmanaged certificate expiry, private keys baked into firmware, and no revocation path. Each one is avoidable, and each one tends to surface only under production load or during an incident.

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. An expired certificate takes your entire fleet offline. Set up automated renewal with a 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.

What does a realistic secure rollout sequence look like?

Stage the rollout so each layer is proven before the next is added: encrypt transport, fix server trust, introduce charger certificates on a controlled segment, automate renewal, then add firmware signing. The order matters because a later layer that fails on an unproven earlier one is far harder to diagnose.

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 CSMS 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.

Which controls are non-negotiable before production?

A secure OCPP deployment is production-ready only when the certificate operations are documented, tested, and owned, not just configured. The checklist below is the bar I use before signing off a profile rollout, because every item maps to a failure mode that has taken fleets offline elsewhere.

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.

What should certificate automation in a CSMS provide?

When you evaluate a CSMS for secure OCPP, judge its certificate operations, not its profile checkbox. The platform should remove manual PKI work while keeping the controls auditable, so your team owns policy and the system handles the mechanics at fleet scale.

In practice, the capabilities worth confirming are concrete:

• Automated CA — issue and manage charger certificates without hand-rolling OpenSSL commands per station
• Expiry monitoring — alerts with lead time before certificates expire, across the whole fleet
• CSR-based enrollment — chargers generate their own key pairs so private keys never leave the device
• Fast revocation — invalidate a compromised or decommissioned charger's certificate immediately
• Firmware signing — sign and distribute firmware with on-device integrity verification for Profile 3

These are the same controls we built into EV Cloud after watching manual PKI processes slow secure rollouts down, but the checklist applies to any platform you assess.

What is the next step for rollout teams?

Start from exposure, target Profile 2 as the operational baseline for public networks, and prove certificate renewal and revocation before scaling. If firmware integrity is part of your threat model, plan Profile 3 once mTLS is stable. The profile is the easy decision; the operations around it are the real project.

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 our team if you need help with certificate operations, mTLS rollout, or charger identity architecture.

For a deeper protocol reference, see the OCPP 2.0.1 deep dive.