OCPP Security Profiles Explained

Introduction

Whenever EV charging security comes up, one of the first questions I usually hear is: "Which OCPP Security Profile should we use?"

It's a fair question. After all, OCPP is the backbone of communication between the Charge Point (EVSE) and the Central System (CSMS), so protecting that communication is fundamental.

I often start my own discussions with OCPP as well because it's one of the easiest ways to explain how an EV charger communicates with the backend. But after spending time assessing EV charging infrastructure, I've realised that many people unintentionally give Security Profiles more responsibility than they were designed to provide.

I've heard statements like:

"We're using Security Profile 3, so our chargers are secure."

Unfortunately, security isn't that simple.

Security Profiles are incredibly important, but they protect one specific part of the EV charging ecosystem. Understanding where their responsibility starts and ends is just as important as understanding how they work.

Why OCPP Introduced Security Profiles

When OCPP 1.6 became widely adopted, deployments varied significantly. Some chargers operated entirely inside private networks. Others communicated over the public internet, some operators relied on VPNs and others relied on firewalls.

As EV charging networks expanded, protecting communication between the Charge Point and the CSMS became increasingly important.

This led to the introduction of three Security Profiles, allowing operators to choose different levels of communication security depending on their deployment.

Each profile builds upon the previous one by introducing stronger authentication and better protection for communication. That doesn't necessarily make older profiles "broken." They simply provide different levels of protection.

Security Profile 1

The first profile is the simplest.

The Charge Point authenticates using HTTP Basic Authentication, while communication itself is not protected using TLS. This means credentials are used for authentication, but the transport layer remains unencrypted.

Historically, this profile was intended for deployments operating inside trusted environments such as private networks. Today's production deployments are very different.

Most chargers communicate over public or semi-public infrastructure, making Profile 1 unsuitable for modern internet-connected deployments.

Security Profile 2

Security Profile 2 introduces TLS encryption.

Communication between the Charge Point and the CSMS is now encrypted, protecting data against interception during transport. The Central System authenticates itself using a TLS certificate, while the Charge Point continues to authenticate using HTTP Basic Authentication.

This significantly improves communication security compared to Profile 1. However, only one side of the connection is authenticated using certificates.

Security Profile 3

Security Profile 3 provides the strongest security model defined by the OCPP 1.6 Security Whitepaper.

Both the Charge Point and the Central System authenticate using TLS certificates. Communication is encrypted and mutual authentication is established through client certificates. This dramatically reduces the risk of charger impersonation and strengthens trust between both systems.

For modern deployments, Profile 3 should generally be considered the target wherever operationally feasible.

Where the Misunderstanding Begins

This is where I think many discussions become misleading. I've seen Security Profile 3 presented as though it "secures the EV charger."

It doesn't. It secures communication between the Charge Point and the Central System. That's an important distinction.

Security Profiles do not automatically secure:

• Bluetooth interfaces

• Wi-Fi provisioning

• USB maintenance ports

• Firmware validation

• Local web interfaces

• Operating system hardening

• Secure Boot

• Backend authorization logic

• Physical access

Those areas remain the responsibility of the overall product design. That doesn't reduce the importance of Security Profiles. It simply defines their scope.

What I Look For During an Assessment

When assessing an EV charger, confirming the configured Security Profile is usually one of the first checks I perform. But it rarely becomes the last. The questions that follow are often more interesting.

• How are certificates provisioned?

• Can certificates be rotated securely?

• What happens when a certificate expires?

• How are firmware updates verified?

• Can local interfaces still modify charger configuration?

• Can it be configured with other third-party CSMS?

Those answers usually reveal much more about the overall security posture than the configured Security Profile alone.

Security Profile 3 Is Not the Finish Line

Choosing Security Profile 3 is a good engineering decision. It demonstrates that communication security has been taken seriously. But communication security is only one layer of a secure EV charging ecosystem.

A charger can implement mutual TLS perfectly and still expose unnecessary local interfaces. It can authenticate every OCPP message while accepting insecure firmware updates. It can encrypt communication yet still trust backend decisions that were never properly validated.

That's why I believe EV charging security should always be viewed as a complete system rather than a single protocol.

Beyond Security Profiles: Can OCPP Help Secure the Charger Itself?

While writing this article, I reminded of an interesting discussion that followed one of my previous LinkedIn posts. The conversation started with OCPP Security but quickly shifted to a broader question:

Can OCPP be used not only to secure communication, but also to manage the security posture of the charger itself?

It's an interesting idea because today's Security Profiles focus on protecting the communication channel between the Charge Point and the Central System. They ensure that messages exchanged over OCPP are encrypted and that both systems can authenticate each other according to the selected profile. Once that secure channel is established, however, the protocol has historically had limited visibility into many of the charger's local security controls.

During the discussion, one point stood out to me. Modern charge points often include several interfaces that exist outside the normal charging workflow. Bluetooth may be enabled for commissioning, Wi-Fi may be used during installation, local web interfaces may expose diagnostic functions, and USB or engineering ports may remain available for maintenance. These interfaces are useful throughout the product lifecycle, but they also require operational control once the charger is deployed.

This raises an interesting question. If OCPP already provides a trusted and authenticated communication channel between the CSMS and the charger, could that same channel also be used to centrally manage certain security controls?

Imagine a CSMS allowing an operator to disable Bluetooth once commissioning is complete, restrict local maintenance interfaces outside approved maintenance windows, enforce firmware update policies, rotate certificates, or verify that required security features remain enabled across thousands of deployed chargers. Rather than relying on vendor-specific management mechanisms, these capabilities could potentially be managed through standardized interfaces.

Of course, this isn't as simple as adding a few new OCPP messages. Every additional capability introduces new design considerations. Security policies would need strong authorization controls, clear ownership, auditability, and safeguards to prevent misuse. Standardization would also require agreement across charger manufacturers, CPOs, CSMS providers, and the Open Charge Alliance. Not every security function belongs inside OCPP, and some controls may always remain vendor-specific.

Even so, I believe the discussion reflects how EV charging security is evolving. The focus is gradually moving beyond protecting communication to managing the operational security of deployed infrastructure. Secure communication establishes trust between the charger and the backend, but maintaining that trust throughout the charger's lifecycle increasingly depends on centralized visibility, configuration management, and continuous monitoring.

Whether future versions of OCPP incorporate more standardized security management capabilities remains to be seen. However, as charging networks continue to scale, giving operators better visibility and control over the security posture of their deployed chargers seems like a natural direction for the ecosystem.

Final Thoughts

The introduction of OCPP Security Profiles has significantly improved the security of EV charging infrastructure. Every modern deployment should aim to use the strongest profile that fits its operational environment.

At the same time, it's important to remember what Security Profiles were designed to do.

• They secure communication.

• They don't secure every component inside an EV charger.

Real security comes from combining secure communication with secure hardware, secure firmware, secure provisioning, strong authentication, continuous monitoring and thoughtful engineering decisions throughout the entire product lifecycle.

Because attackers don't stop where OCPP ends. Neither should defenders.