What is a CSMS and how is it built? Architecture, standards and security

An EV charger looks, from the outside, like “a socket with power”. In reality it is a networked, remotely controlled device connected to the energy grid and to payment systems. What ties all of this into a working, secure and billable service is the CSMS — Charging Station Management System.

In this article we explain what a CSMS is, how its architecture is built, which communication standards connect it (OCPP, OCPI, ISO 15118) and — most importantly — why security is not an add-on here, but the foundation of the design. If you prefer to see the whole thing on one picture, we prepared an EV24® CSMS architecture diagram.

What is a CSMS?

A CSMS (Charging Station Management System), also called a CPMS (Charge Point Management System), is the backend that manages a network of charging stations. It:

• connects to the chargers and keeps a permanent communication channel,
• monitors their status in real time,
• starts and stops charging sessions,
• manages power, tariffs and access,
• collects metering data (CDR — Charge Detail Record),
• handles payments, settlements and invoices,
• shares data with operators, drivers, maps and roaming partners.

In other words: the charger is the “muscle”, and the CSMS is the “nervous system” of the whole network. Without it you have a set of independent devices; with it you have a charging service you can scale, settle and control.

It is worth distinguishing three roles that are often confused. A CPO (Charge Point Operator) physically runs the stations and is responsible for their operation. An eMSP (e-Mobility Service Provider) delivers the service to the driver — the app, the account, the payment. The CSMS is the software system that runs the CPO’s operations and exchanges data with eMSPs. One entity can play several roles at once, but in the architecture it pays to keep them separate, because they have different requirements and different data.

Why a CSMS is critical infrastructure, not “just software”

Before we get to architecture, it helps to set the right mindset. A CSMS sits at the intersection of three worlds, each with high requirements:

1. Energy — you control devices that draw real power from the grid. A mistake or a takeover is not “a data leak”, it has physical consequences: a blocked station, an overloaded connection, an interrupted session on a road trip.
2. Payments — transactions, card data and terminals go through the system. Industry standards and regulations apply.
3. Law and compliance — AFIR, e-mobility regulations, GDPR, and increasingly cybersecurity requirements (e.g. NIS2 for essential entities).

That is why a good CSMS is designed like a high-availability real-time system, with security built in from the first line of code, not glued on at the end.

High-level architecture

The easiest way to describe a CSMS architecture is as four layers, from left to right:

1. Charging infrastructure — AC stations, DC stations, mobile chargers, controllers and meters in the locations.
2. CSMS core — a set of microservices that accept communication, run sessions, calculate and publish events.
3. Business modules — smart charging, billing and tariffs, roaming, analytics.
4. Consumers — the driver app, the operator panel, the public API and integrations.

The key principle: the layers are loosely coupled and communicate through events, not rigid, direct calls. Thanks to that each part can be developed, scaled and secured independently — and the failure of one element does not bring down the whole.

Layer 1: infrastructure and its diversity

Stations differ in power (AC vs DC), connectivity (eSIM, SIM, WiFi, LTE) and protocol version. In one network OCPP 1.6J, 2.0.1 and 2.1 chargers naturally coexist, alongside controllers and energy meters that talk over, for example, Modbus. The job of the CSMS is to unify this diversity — so that the rest of the system does not need to know exactly what hardware sits in the field.

Layer 2: the microservices core

The core is not one “big program”, but a set of specialized services. In EV24 they look like this:

• OCPP Gateway — keeps the WebSocket connections with the stations, translates commands between OCPP versions and isolates the “dirty” world of devices from the rest of the system. It is the only component that talks to the hardware directly.
• Session Service — handles the start, stop and course of a session and generates the CDR (charge detail record), which is the basis for settlements.
• Chargers Registry — a registry of stations, EVSEs and connectors along with their configuration, statuses and capabilities.
• Event Bus & Streams — the bus of events and real-time telemetry that ties all the services together and lets them react without rigid dependencies.

On top of that work the business modules: Smart Charging (load balancing, DLM), Billing and tariffs, Roaming (OCPI) and Analytics.

Layers 3 and 4: business modules and consumers

The business modules turn raw events into value: they calculate costs, balance power between points, exchange data with other operators and compute metrics. The consumers — the driver app, the operator panel, the public API and integrations — consume this data. Importantly, consumers never reach the devices directly: always through the core, which also matters from a security standpoint.

The standards that hold a CSMS together

An architecture is only as good as the standards it stands on. They decide interoperability and whether you fall into vendor lock-in.

OCPP — the language between charger and system

OCPP (Open Charge Point Protocol) is the open standard for communication between the station and the CSMS. In practice you will meet three versions:

A good CSMS supports all three versions at once, because the fleet in the field is mixed. You cannot replace every charger overnight — which is why the OCPP gateway must speak each of these “dialects” and translate them into a shared, internal model. We write more about the protocol and the differences in the article on the Open Charge Point Protocol (OCPP).

OCPI — roaming between operators

OCPI (Open Charge Point Interface), most often in version 2.2.1, is the roaming standard — it lets a driver of one service provider (eMSP) charge at another operator’s (CPO) station, with correct settlement between the parties. OCPI is split into modules, each responsible for a different part of the data exchange:

Thanks to OCPI your network is visible and usable far beyond your own app — and that translates directly into station utilization.

ISO 15118 — Plug & Charge

ISO 15118 (Plug & Charge) is secure, certificate-based authorization “by the plug”: the driver connects the cable, and authentication and settlement happen automatically, without an app or a card. Underneath it runs a public key infrastructure (PKI): the vehicle and the station exchange and verify certificates, and the whole transmission is encrypted. It is convenience for the driver and a higher level of security — but it requires the CSMS to handle certificate management on the station side.

Modbus, meters and payments

At the location level you also have energy meters and controllers, often communicating over Modbus (consumption metering, power control). And payments: terminals (e.g. Payter, PAX), mobile payment, cards. The CSMS has to tie these worlds together — but, importantly, keep them in separate, well-isolated domains.

Security — the foundation, not an add-on

This is the most important part of the article. In a CSMS security has to be considered on several levels at once, because an attacker does not pick the “nice” path — they pick the weakest link.

1. Securing the OCPP layer

This is the most sensitive channel: it is how you send the device the “start”, “stop”, configuration change or update commands. OCPP 2.0.1 defines Security Profiles worth knowing:

The direction is clear: ultimately Profile 3 (mTLS), where the station and the CSMS confirm their identity to each other, and the connection always goes over TLS (WSS), never a “bare” WebSocket. On top of that comes certificate lifecycle management — issuing, rotation and revocation. Without it “anyone” could pretend to be a station or a server.

2. Isolation and segmentation (defense in depth)

The world of field devices is untrusted by definition. That is why the OCPP Gateway runs as a separate, isolated service — a gateway that accepts traffic from stations and separates it from the business core. Even if a single station is compromised, there is no direct path to the customer database, payments or invoices. This is defense in depth — many layers of protection instead of a single wall.

3. Authentication and authorization (least privilege)

Inside the system the principle of least privilege applies: no single service “can do everything”. The session service has no access to card data; the payment service does not control the charger. On top of that comes role-based access control (RBAC) for operators in the panel and strong user authentication. Access to administrative functions is separated and audited — every operation leaves a trail (who, what and when).

4. Payment security

Payments are a separate trust domain. Terminals (Payter, PAX), mobile payment and cards require compliance with industry standards (the PCI DSS family), tokenization of card data and separation from the rest. A CSMS should not store sensitive payment data “along the way” — that data lives in a separate, secured path, and the charging operations system only sees the authorization result, not the card number.

5. Data protection and privacy

Session, location and driver data are subject to GDPR. Good practices are processing data within the European Economic Area, minimizing the scope of data, encryption “at rest” and “in transit” and full auditability. It is worth remembering that charging data can reveal a user’s habits and locations — which is why we treat it as sensitive data.

6. Resilience and threat detection

• High availability (HA) — no single point of failure; key components are redundant.
• Monitoring and telemetry — constant insight into the state of the stations and the system, alerts on anomalies.
• Abuse protection — rate limiting, detection of unusual patterns, resilience to volumetric (DoS) attacks.
• Secure firmware updates — remote, but signed and verified, so an update does not become an attack vector.

7. Regulatory compliance

Security is also compliance: AFIR (including ad-hoc payment and price transparency), e-mobility regulations, obligations toward the relevant authorities, and increasingly, for larger operators, NIS2 cybersecurity requirements for essential entities. A good CSMS should support these requirements out of the box, rather than dumping them entirely on the operator.

Scalability and reliability

Traffic in a charging network is not linear: evening peaks, frosts, holidays, a sudden onboarding of a new operator with hundreds of stations. That is where the microservices architecture pays off:

• Independent scaling — is OCPP traffic growing? Only the OCPP Gateway scales, not the whole system.
• Event-driven communication — the event bus decouples the services, so a momentary slowdown of one does not block the others (a backpressure mechanism protects the system from being flooded).
• Idempotency and consistency — events are designed so that reprocessing does not break settlements. This matters especially for invoices and CDRs: the same session must not be charged twice.
• HA cluster for the OCPP gateway — the persistent WebSocket connections with stations have to survive a restart or the failure of a single node, otherwise stations “drop off” the system.

We cover one of the modules — power management — in more depth in the article on EV charging load balancing.

Integrations with the outside world

A CSMS does not operate in a vacuum. Typical integrations are:

• Maps (Google Maps, Apple Maps) — publishing locations and availability where drivers actually look for charging.
• Registries and supervisory systems — the operator’s reporting obligations.
• Invoicing — automatic issuing and delivery of invoices and accounting documents.
• Roaming (OCPI) — exchange with other operators and service providers.

Settlement is, by the way, a topic that is easy to get wrong — we gathered practical notes in the article on EV charging station billing.

How it looks in EV24®

In EV24 the CSMS is built exactly along these lines: an isolated OCPP gateway supporting 1.6J / 2.0.1 / 2.1, an event-driven microservices core, separate domains for payments and settlements, roaming over OCPI and full telemetry and monitoring. The whole thing designed like critical infrastructure — because it is.

The best way to see it is on a picture: we prepared an EV24 CSMS architecture diagram — from the stations, through OCPP and microservices, to payments, roaming and the invoice. If you are interested in the product side, take a look at the charge point management system too.

Summary

A CSMS is not “an app for chargers”. It is a real-time system that turns a set of devices into a secure, scalable and billable service. Three things decide its quality:

1. Security — encrypted and authenticated OCPP (ultimately mTLS), gateway isolation, least privilege, payment and data protection, compliance (AFIR, GDPR, NIS2). This is the foundation, not an option.
2. Standards — OCPP (1.6J/2.0.1/2.1), OCPI 2.2.1, ISO 15118. They provide interoperability and protect against vendor lock-in.
3. Scalability — microservices architecture, event-driven communication, high availability, idempotent settlements.

If you are planning a charging network or choosing an operator, do not only ask “does the charger support OCPP?”. The real question is: is the whole system — from security, through standards, to scaling — built to carry critical infrastructure.