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.

If you ask someone what an EV charger is, they'll probably say it's a device that charges electric vehicles. Technically, they're right. But after spending time assessing these systems, I've started looking at them very differently.

A modern EV charger is not just a piece of electrical equipment. It runs embedded software, communicates with cloud platforms, authenticates users, exchanges data with mobile applications, processes payments, receives firmware updates and, in many deployments, even communicates directly with the vehicle. In many ways, it's a connected computer installed in a public place, expected to operate reliably 24 hours a day.

The EV industry has done an incredible job of making charging faster, smarter and more convenient. As electric vehicles become part of our everyday lives, charging infrastructure is growing at an impressive pace. But with every new feature comes another communication interface, another software component and another trust relationship. That's exactly where cybersecurity becomes important.

Over the last few months, I've had the opportunity to assess different parts of the EV charging ecosystem, from embedded devices and wireless interfaces to OCPP communication, backend platforms and mobile applications. Every assessment has been different, but one observation has remained surprisingly consistent.

The industry has moved quickly in building connected charging infrastructure. Security now needs to move at the same pace.

The Charger isn't just Charger Anymore

When people think about automotive cybersecurity, they usually imagine someone attacking a vehicle. In reality, the charging station has quietly become an equally interesting target.

An EV charger sits between multiple systems that all need to trust each other. It communicates with vehicles, charging management systems, mobile applications, payment services and, in some cases, roaming platforms that allow drivers to use chargers across different networks.

Figure 1. A modern EV charging ecosystem consists of multiple interconnected systems, each introducing its own trust boundaries and security considerations.

Every one of these connections exists for a reason. Every one of them also creates another trust boundary.

That trust isn't necessarily a problem. It's how modern infrastructure works. The challenge begins when those trust relationships are assumed instead of verified.

As penetration testers, we rarely start by asking, "Can I hack this charger?" We start by asking, "What assumptions is this charger making?"

Those assumptions often tell us far more than the software version or protocol specification.

Looking beyond OCPP

One thing I've noticed is that almost every conversation about EV charging security eventually turns to OCPP. That's understandable because OCPP is the backbone of communication between the Charge Point (EVSE) and the Central System (CSMS). I often start there myself when introducing someone to EV charging security because it's the easiest way to understand how the ecosystem works. But over time, I've also realised that focusing only on OCPP tells only part of the story.

OCPP alone doesn't define whether a charging station is secure. During an assessment, I usually begin with much simpler questions.

• Is Bluetooth enabled even though commissioning is complete?

• Does the charger expose a local maintenance interface?

• How are firmware updates verified before installation?

• Can certificates be replaced without proper authorization?

• Does the backend validate what the charger sends, or does it simply trust incoming data?

• Can configuration changes be performed securely?

These questions often reveal much more about the security posture than simply checking whether TLS has been enabled.

OCPP is an important protocol, but it's only one piece of a much larger ecosystem.

Understanding the Real Attack Surfaces

One of the biggest misconceptions is that an attacker only interacts with a charger over the internet.

In reality, an EV charger exposes multiple interfaces that serve different purposes throughout its lifecycle.

Figure 2. EV Charger's Attack Surface

Wireless interfaces such as Bluetooth or WiFi may be used during installation or maintenance. RFID readers authenticate users. Ethernet and cellular connectivity keep the charger connected to backend systems. USB or debug interfaces may exist for servicing the device. Mobile applications interact with cloud APIs, while firmware updates introduce another layer of trust that needs careful protection.

Individually, none of these interfaces are inherently insecure.

The risk appears when they remain exposed longer than necessary, lack proper authentication or trust data that hasn't been adequately verified.

This is why securing an EV charger isn't about protecting one protocol. It's about understanding the entire system and ensuring every interface follows the same security principles.

Small Assumptions Create Big Problems

If there's one lesson I've learned while assessing connected systems, it's that security incidents rarely begin with one catastrophic vulnerability.

More often, they begin with a chain of small assumptions. A charger assumes the backend is legitimate. The backend assumes the charger is genuine. A maintenance interface assumes only technicians will use it. A mobile application assumes the connected device is authentic. Each individual assumption may seem reasonable.

But when multiple assumptions fail together, they create opportunities that attackers can exploit.

That's why modern penetration testing isn't just about finding vulnerabilities. It's about understanding how trust moves through the system and identifying where those assumptions can be challenged.

Compliance is Raising the Bar

The conversation around EV charging security is changing.

For many years, cybersecurity was treated as something manufacturers could improve over time. Today, regulations such as the Cyber Resilience Act (CRA), NIS2 and industry guidance around secure EV charging are changing those expectations.

Compliance is encouraging manufacturers and operators to think differently about software updates, vulnerability management, secure development practices and incident response.

That's a positive step for the industry.

However, compliance should never become the final objective. Attackers don't check whether a product complies with a regulation, they interact with the system exactly as it exists in the real world.

Compliance establishes a baseline. Engineering determines whether that baseline can withstand real attacks.

Security Does Not End after Deployment

One topic that doesn't receive enough attention is operational security.

A penetration test provides a snapshot of the current security posture, but it doesn't guarantee that a system will remain secure six months later.

• Firmware evolves.

• New features are introduced.

• Certificates expire.

• Configurations change.

• New vulnerabilities are discovered.

Security therefore needs to become an ongoing process rather than a one-time exercise.

Figure 3. Manufacturer vs Operator Responsibilities

For manufacturers, that means designing products with secure boot, firmware signing, strong authentication, certificate lifecycle management and secure provisioning from the beginning.

For Charge Point Operators (CPOs), it means continuously monitoring deployed infrastructure, maintaining software updates, reviewing configurations and validating that security controls remain effective over time.

Perhaps the most important question isn't, "Can this charger be attacked?" It's, "If someone tried, would we know?"

Detection, monitoring and incident response deserve just as much attention as prevention.

Building More Resilient Charging Infrastructure

The encouraging part is that the industry doesn't need to invent entirely new security technologies.

• The foundations already exist.

• We know how to build secure embedded systems.

• We know how to authenticate devices.

• We know how to manage certificates securely.

• We know how to verify firmware integrity.

• We know how to protect communication channels.

The challenge isn't discovering new solutions. It's applying these principles consistently across every layer of the EV charging ecosystem.

Security shouldn't be something added after a product is deployed. It should influence architectural decisions from the very beginning, from hardware design and software development to backend services and operational monitoring.

Final Thoughts

I've spent enough time looking at EV charging systems to know that there are some excellent products in the market. I've also seen implementations where functionality clearly arrived before security.

Neither observation is surprising. The EV industry is growing rapidly, and innovation naturally moves faster than hardening. What gives me confidence is that the path forward is already clear.

As an industry, we understand secure software development. We understand embedded security. We understand certificate management, secure communications and vulnerability management. The challenge now is bringing those practices into every connected charger, every backend platform and every deployment.

The future of mobility won't be defined only by how fast we can charge a vehicle. It will also be defined by how confidently we can trust the infrastructure behind it. Because in the end, people don't just plug into an EV charger, they plug into an entire connected ecosystem. And that ecosystem deserves to be secure.

This post is a map of where the interesting seams are, not a how-to. Think of it as the outline I'd want before diving into any one piece in depth.

The actors in an EVSE deployment

A charging session typically touches:

• The vehicle — battery management system, onboard charger, communication controller

• The EVSE (charge point) — the physical charger, usually running embedded Linux or an RTOS

• The Charge Point Operator (CPO) backend — the cloud system managing the fleet of chargers

• The e-Mobility Service Provider (eMSP) — handles billing, roaming, apps

• The driver's app/RFID card — the authentication token

Each boundary between these is a potential attack surface, and each is usually built by a different vendor.

Surface 1: OCPP (charger ↔ backend)

OCPP is the dominant protocol between charge points and CPO backends. Versions matter a lot here:

• OCPP 1.6J (WebSocket/JSON) is still extremely common in the field, and its security depends almost entirely on how the implementer layered TLS and authentication on top — the spec itself doesn't mandate much.

• OCPP 2.0.1 improves on this with better security profiles, but adoption lags because rip-and-replace of deployed hardware is expensive.

Interesting angles: weak or absent mutual TLS, predictable charge point identifiers, backend APIs that trust whatever a charger claims about itself (meter values, transaction IDs) without independent verification.

Surface 2: ISO 15118 (vehicle ↔ charger)

This is the protocol for Plug & Charge — the vehicle authenticates to the charger (and vice versa) using certificates, without the driver tapping an app or card. It's elegant when it works, but it introduces a whole PKI trust chain:

• Root CAs, sub-CAs, provisioning certificates, contract certificates

• Certificate revocation handling (or the lack of it) in constrained embedded environments

• The physical layer underneath it (PLC over the charging cable) has its own history of implementation quirks

A compromised or misissued certificate anywhere in that chain has outsized consequences because Plug & Charge is designed to require no other authentication step.

Surface 3: The physical charger itself

Public chargers are, by definition, physically accessible to anyone. That means:

• Exposed debug ports (UART, JTAG) on units that weren't hardened for field deployment

• Firmware update mechanisms — how is a new firmware image authenticated before a charger accepts it?

• Local diagnostic interfaces meant for technicians, sometimes left reachable

This is the surface that most resembles classic embedded/IoT hardware hacking, and it's often the least mature from a security-engineering standpoint because chargers were historically treated as "dumb" appliances.

Surface 4: The backend and app layer

This is standard web/API security territory, but with automotive-specific consequences:

• BOLA/IDOR in fleet management APIs (start/stop someone else's charging session, pull their session history)

• Billing logic — can meter values or session duration be manipulated to under-report usage?

• Roaming — CPOs interconnect through the Open Charge Point Interface (OCPI) or similar; trust between operators who've never security-reviewed each other's systems is its own can of worms

Surface 5: Grid-facing and smart-charging features

Newer deployments add demand-response and V2G (vehicle-to-grid) features, where the charger can throttle or schedule charging based on grid signals. This is early-stage but worth watching — it's a new remote-control surface with real physical-world consequences (load manipulation at scale) if backend trust boundaries aren't solid.

Where I'd focus first

If I were prioritizing based on impact-per-effort, in rough order:

1. OCPP backend trust assumptions (surface 1) — most deployments, least mature TLS/auth hygiene

2. Physical charger debug/firmware surface (surface 3) — highest "someone will find this eventually" risk given public accessibility

3. ISO 15118 PKI (surface 2) — lower current prevalence (Plug & Charge adoption is still growing) but highest blast radius when it matters

Future posts will probably go deep on one of these at a time — likely starting with OCPP backend assumptions, since that's the one my pocket-charger build is already poking at.