OCPP 2.0.1 Security for Indian EV Charging Operators (2026): TLS/mTLS, OCSP Revocation, Offline Authorization, and Transaction Reconciliation

Securing an OCPP 2.0.1 network in India is less about the spec PDF and more about what your chargers do at 11pm when the 4G link drops and a stranger plugs in. Get the transport layer right and you have encrypted, authenticated sessions that bill correctly. Get it wrong and an unsigned firmware channel or a never-revoked charger certificate becomes a quiet backdoor into your CSMS, your payment flow, and every station you run.

This is a working operator's guide to the four things that actually decide whether a 2.0.1 network is both secure and paid: TLS and mTLS on the WebSocket, OCSP revocation, offline authorization when connectivity dies, and reconciling those offline sessions into Razorpay without double-charging. We wrote it from running PlugEV, a production OCPP 1.6-J and 2.0.1 CSMS with a Go WebSocket gateway, a Laravel admin, and Razorpay billing behind it.

None of this comes from the spec alone. All of it comes from chargers that dropped, certs that expired, and sessions that tried to bill twice.

The 60-second security answer for a live Indian fleet

Run Profile 2 as your floor, Profile 3 where the contract demands it. OCPP 2.0.1 defines three security profiles. Profile 1 is HTTP Basic over unsecured transport, so skip it. Profile 2 is TLS server authentication plus HTTP Basic Auth, and for a public network in India it is the honest default: real transport encryption without the per-charger certificate provisioning headache. Profile 3 is mutual TLS (mTLS), where the charger presents its own client certificate. Move to it when a B2B fleet contract or CEA compliance actually requires it, not before.

Two more problems this post owns. Offline authorization keeps a charger usable when 4G drops, using the cached LocalAuthorizationList and the AuthCacheCtrlr component (AuthCacheCtrlr.Enabled) so a session can start without the CSMS. Reconciliation then replays the queued TransactionEvent messages so an offline plug-in bills exactly once in Razorpay, no double-charge, no revenue leak.

Scope: this is how to secure 2.0.1 once you are on it. For whether to migrate at all, see the migration playbook; for general build notes, the CSMS build guide. Every claim here comes from running this on 40+ chargers across 2 cities on a Go WebSocket gateway, not the spec PDF.

The three OCPP 2.0.1 security profiles, and which one you should actually run

We just called them a floor and a contract demand. Here is what each profile actually trusts, because they are not "levels of good," they are different trust models.

Profile 1 is HTTP Basic auth (username plus password) sent over plain ws://. There is no transport encryption. The charger's password crosses the network in the clear, so anyone on the path can read it and impersonate the station. This should never touch a public charger. We still see it left on in the field more than operators admit, usually because a commissioning engineer got the WebSocket connected on ws:// and nobody went back to harden it.

Profile 2 is TLS with a server-side certificate (the CSMS proves who it is) plus Basic auth for the charger. Traffic is encrypted, the charger trusts the CSMS, but the charger still authenticates with a password.

Profile 3 is mutual TLS. Both sides present X.509 certificates, and there is no password. The charger's identity is its client cert, provisioned via SignCertificate / CertificateSigned against your PKI.

Our honest India default: Profile 2 is the floor for any public AC or DC charger. Move to Profile 3 when a fleet client, an aggregator, or a CEA/BIS posture wants cryptographic client-cert identity per station.

The downgrade trap: if your CSMS accepts plain ws:// on the same endpoint as wss://, a charger can silently connect on Profile 1 and you will not notice. Terminate ws:// at the load balancer. One endpoint, one profile floor.

Firmware reality check: not every installed model does Profile 3 in 2026. Audit it. Send GetVariables for the SecurityProfile variable (component OCPPCommCtrlr) and read what each station reports.

• Profile 1: no transport encryption, charger identity by password, no CSMS identity, near-zero operational cost. Never on a public charger.
• Profile 2: TLS transport encryption, charger identity by password, CSMS identity by a server cert, low operational cost (one server cert to run).
• Profile 3: mutual TLS transport encryption, charger identity by its own client cert, CSMS identity by server cert, higher operational cost (PKI, rotation, and OCSP to run).

Running your own PKI adds real ops load, so budget for it. In our experience, all in (tooling plus the loaded engineering time to run rotation, revocation, and audits) a self-operated PKI costs roughly INR 3 to 6 lakh per year. Managed tiers cost less in tooling and shift the tradeoff, and we break the tiers down below. Pricing here is indicative for 2026 and reflects our own estimates; confirm current quotes before you budget.

Inside the wss:// handshake: TLS and mTLS on the WebSocket gateway

Those profiles are abstractions until you watch a charger actually connect. When a charger boots, it dials wss://csms.example.in/ocpp/CP-2201 and starts a normal TLS handshake: ClientHello, then our gateway returns its server certificate chain, and only after the TLS session is up does the HTTP Upgrade happen. The subprotocol is negotiated right there in the headers, Sec-WebSocket-Protocol: ocpp2.0.1. If the charger sends ocpp1.6 and we only speak 2.0.1, the Upgrade fails before a single BootNotification is sent. Watch that header first when a "working" charger will not connect.

Security Profile 2 is server-auth TLS. The charger validates our leaf against a trusted root, checks the SAN matches the host, and reads SNI so we can serve the right cert on a shared IP. Chain order matters: leaf, then intermediate, or older embedded clients fail path building. The classic field failure is a charger that trusts any cert because validation is stubbed in firmware. We have seen units happily connect to a self-signed test cert. Test that deliberately before you sign a fleet contract.

Security Profile 3 is mutual TLS. The charger presents its own client certificate, our gateway validates it against the CPO sub-CA, and we map the cert's CN or SAN to a chargePointId. That identity replaces the Basic-auth password entirely, no shared secret to leak. Running mTLS means running PKI, and an entry managed tier starts around INR 40,000 to 1,20,000 per year in tooling. More on the cost tiers in the next section.

TLS terminates at the Go gateway. It holds the WebSocket and speaks OCPP over an internal channel to the Laravel admin, which never touches a raw socket. This is why a dumb L4 load balancer breaks you: if it passes TLS straight through, nothing extracts the client-cert identity, so mTLS becomes decoration. Terminate where you can read the cert.

Posture: enforce TLS 1.2 minimum (1.3 where firmware allows), disable renegotiation on the TLS 1.2 path (TLS 1.3 has no renegotiation to disable), and pin an allowed cipher list because embedded charger stacks are often years old.

Keepalive uses WebSocket ping/pong. Aggressive idle timeouts on Indian 4G/NB-IoT links drop sessions, and every drop redoes the full TLS handshake, so tune timeouts generously to avoid reconnect storms.

PKI you actually have to run: certificate provisioning, rotation, and the ISO 15118 problem

Once you turn on Security Profile 2 or 3, you stop being a charging company and start being a small certificate authority. Plan for it.

The hierarchy you end up owning. A CPO root (offline, or an intermediate under a managed CA), then two sub-CAs: one that issues charger client certs, one that anchors the CSMS server cert. Do not sign the server cert directly off your root. If that root key leaks or the server cert has to be reissued in a hurry, you want to revoke an intermediate, not rebuild trust on every charger in the field.

Provisioning the first cert. Either the factory installs a client cert, or you field-provision. In practice the charger boots with a bootstrap cert, sends SignCertificate with a CSR, and the CSMS replies CertificateSigned with the issued chain. To seed or replace CA certs you use InstallCertificate, and GetInstalledCertificateIds / DeleteCertificate to audit what is actually on the box. All of it rides the live OCPP WebSocket, so no truck roll.

Rotation without site visits. An expired cert on a remote charger is a self-inflicted outage. We schedule reissue well before expiry and alarm any charger whose cert is inside 30 days of lapsing. That is our operator choice, not a spec rule: we alarm at 30 days and you tune it to your own reissue lead time, driven off GetInstalledCertificateIds sweeps, not hope.

Keep the three families separate. 2.0.1 distinguishes CSMS/server, charger/client, and V2G/ISO 15118 certs. Conflating them is the most common InstallCertificate failure we see: right cert, wrong certificateType.

ISO 15118 Plug and Charge in India. The V2G root and contract-certificate ecosystem here is still thin, with no established Indian V2G Root CA or contract-certificate operator ecosystem to build against. PnC is design-for-later, not a reason to stand up a full V2G PKI in 2026. Build the hooks, skip the CA. (See our migration playbook.)

Tooling. Use step-ca or a managed PKI over hand-rolled OpenSSL scripts. The cost tiers we see, indicative for 2026: an entry managed tier that handles issuance and OCSP runs roughly INR 40,000 to 1,20,000 per year in tooling; a fuller managed CA tier with HSM-backed key storage, more certificate families, and higher assurance runs roughly INR 1.5 to 4 lakh per year; and running the whole thing yourself, all in with the loaded engineering time to operate it, lands around INR 3 to 6 lakh per year. Once B2B fleet contracts start auditing you, key storage matters: an HSM, or at minimum sealed secrets, never keys sitting in plaintext on disk.

OCSP and certificate revocation: proving a cert is still valid

Issuing certs is the easy half. Killing one you no longer trust is the half everyone skips. A charger cert stays cryptographically valid until its expiry date, even if the unit was stolen off a wall or decommissioned last month. If you cannot revoke a cert and then actually check revocation on connect, a lifted charger can keep opening a TLS session to your CSMS for the full cert lifetime. That is the gap.

You have three tools. CRLs are full revocation lists. A full CRL can be large, and on a charger sitting on a metered mobile SIM, pulling it on every check is painful and eats data you pay for. OCSP asks a responder about one cert only, which is lighter. OCSP stapling is lighter still.

OCPP 2.0.1 helps here. The charger does not need its own route to a public OCSP responder. It sends GetCertificateStatus with the OCSP request data, and the CSMS relays it to the responder and returns the signed answer. Your CSMS becomes the OCSP proxy, which matters for chargers behind NAT or on a locked-down APN.

On our gateway we staple the responder answer straight into the TLS handshake. The charger gets a fresh, signed status with no second round trip on a flaky link. We cache staples and refresh before they go stale.

Then the offline dilemma. If nothing can reach a responder, do you soft-fail (allow) or hard-fail (reject)? On unattended public sites we soft-fail with a short grace window, because hard-fail bricks a whole site when the responder blips.

Operational must-haves: put revoke-on-decommission in the charger offboarding checklist so a pulled unit is dead the same day, and alert when OCSP responses go stale past your refresh threshold. A stale-staple alarm has caught silent responder outages for us more than once.

Signed firmware updates: why unsigned OTA is a backdoor

Revocation stops a bad cert. Signed firmware stops a bad image, and it is the higher-stakes control, because firmware is root on the charger. If your OTA channel accepts an unsigned or unverified image, anyone who can reach that channel gets remote code execution on every charger you operate. That is not a bug, it is a backdoor into the whole fleet, and it reaches your CSMS, your OCPP WebSocket, and the payment flows behind them.

OCPP 2.0.1 fixes the transport with UpdateFirmware. Its firmware object carries the firmware location plus a signingCertificate and a signature. The charger verifies that signature against a trusted manufacturer or CPO key before it flashes anything. No valid chain, no flash.

What the CSMS must enforce. Reject unsigned images at the source. Verify the signing chain yourself before you ever send the request. Then log every FirmwareStatusNotification transition (Downloading, SignatureVerified, InvalidSignature, Installing, InstallRebooting, Installed) so a stuck, failed, or downgraded update is visible instead of silent.

Rollout, not blast. A bad flash on about 40 chargers at once is a field-visit disaster and lost revenue while sites sit dark. We push to one canary charger, watch it complete a full session, then move in rings. In our experience, recovery visits in tier-2 cities cost real money, roughly INR 1,500 to 4,000 per site.

India field reality. Vendor firmware maturity is mixed. Some models advertise signing but do not actually reject a bad signature. We test rejection per model before we trust the mechanism on that hardware.

Offline authorization: what the charger decides when 4G drops

Everything so far assumes the charger can reach you. Most of our public sites cannot, reliably. They run on a single 4G SIM for backhaul, and in practice that link drops several times a day, sometimes for a few seconds during a tower handover, sometimes for twenty minutes when it rains. A charger that can only authorize online is a charger that stops earning during every one of those windows. So the real question is not "does it support OCPP 2.0.1," it is "what does the charger decide on its own when the CSMS is unreachable."

2.0.1 gives you two local mechanisms. The Local Authorization List is an operator-pushed allow-list you sync with SendLocalList and check with GetLocalListVersion. The Authorization Cache is the charger auto-remembering idTokens it has already seen the CSMS approve.

The decision flow. Online, the charger sends Authorize and waits for the CSMS authorizationStatus. Offline, behaviour is governed by config. LocalAuthorizeOffline lets it fall back to the local list, then the cache. LocalPreAuthorize lets it start energy immediately on a local hit without round-tripping. OfflineTxForUnknownIdEnabled is the dangerous one: set true, it will start a session for a token it has never seen.

This is a policy call, not a default. A fleet depot with 30 known drivers runs a tight local list and turns unknown-token offline start off. An open public charger that authorizes unknown tokens offline is choosing revenue continuity over fraud risk. Choose it deliberately, per site, and write it down.

Keep the list fresh or it breaks quietly. SendLocalList supports Full and Differential updates against a version number. Push differentials on membership changes, full only on drift. A stale list rejects a valid driver; large local lists can overflow the flash on cheaper AC units.

What happens to the meter. On an offline start the charger opens the transaction, stamps transactionId, and stores its sampledValue meter readings inside each queued TransactionEventRequest (eventType Started, Updated, Ended) locally. When the link returns it replays the queue. That replay is the handoff into reconciliation, and where Razorpay either gets billed correctly or leaks.

Transaction reconciliation: settling offline sessions in Razorpay without double-charging

An offline session is a real transaction the CSMS never watched happen. The charger delivered kWh, logged it locally, and only when the WebSocket comes back does it flush a burst of queued TransactionEventRequest messages (eventType Started, Updated, Ended, each carrying offline: true and a seqNo). Those queued events must collapse into exactly one correct charge.

Idempotency is the whole game. We dedupe on the charger-generated transactionInfo.transactionId plus seqNo, with a unique constraint in Postgres. A charger that reconnects and retries the same Ended event (common) hits the constraint and no second billing row is born. Same discipline we use on the payment side: see Razorpay webhooks, idempotency and reconciliation.

Trust the meter, not the clock. We compute energy from the first and last sampledValue readings inside the TransactionEvent stream, never from wall-clock duration. Offline chargers drift; their RTC can be minutes or hours off, so we treat the charger timestamp as advisory and stamp our own received-at time for ordering.

The billing sequence we run: queued transaction closes -> compute kWh (last sampledValue minus first sampledValue) -> price it in INR with GST as applicable (commonly treated as 18% for charging-as-a-service) -> capture the pre-auth or raise a Razorpay invoice -> mark settled. Pre-auth vs post-paid decides whether we can actually collect: for walk-in users we hold a pre-auth of around INR 500 (our configured hold) at the Started event, so an offline session still has money to capture. Post-paid fleet accounts we invoice monthly, so offline just means late, not unpaid.

Revenue-leakage cases each get an explicit rule, never a silent skip: charger stopped mid-session offline (bill on last good meter reading, flag partial); missing Updated events (interpolate nothing, use endpoints only); duplicate TransactionEvent Started after a reboot (same transactionId wins, reboot copy is dropped); negative or rollback meter readings (reject, route to disputed).

The reconciliation ledger is a state machine per transaction in the Laravel admin: open -> offline-queued -> replayed -> priced -> settled -> disputed. Finance sees every offline session and why it was billed what it was.

Auditability for B2B and CEA: an immutable, append-only transaction log plus signed MeterValues (2.0.1 signedMeterValue in each sampledValue). When a fleet client disputes an invoice, we answer with the cryptographically signed start and stop readings, not a spreadsheet.

CEA, BIS, and the India compliance picture for secured public chargers

You now have a secure, billable network. The next question every operator asks is which of this is actually required. Be honest about what is law versus what is signal. As of mid-2026, the Ministry of Power's "Guidelines and Standards for Charging Infrastructure" (the Model EV Charging Infrastructure guidelines) and the CEA rules they sit on mostly cover electrical safety, connector standards, and network connectivity, not a hard OCPP security-profile mandate. CEA's cyber-security guidelines and the push toward BIS-tested hardware point at TLS and authenticated firmware as direction of travel, but we have not seen a notified clause that says "run OCPP 2.0.1 Security Profile 3." Treat anyone claiming a strict mandate with suspicion.

The real near-term forcing function is commercial, not regulatory. B2B and fleet contracts are where mTLS, signed firmware, and audit trails become non-negotiable. A logistics fleet buying charging as a service wants revocation handling and tamper-evident logs written into the SLA, long before a regulator asks.

Data residency and PII is the sharper edge. RFID idToken values, app identities, and TransactionEvent records are personal data under the DPDP Act. Know where that data lives, why you hold it, and how to erase it. We cover the mechanics in our DPDP compliance guide.

In the RFPs we have responded to, security posture is now a tender differentiator: government and large-CPO tenders increasingly list TLS, OCSP revocation, and signed firmware as scored line items. The honest gap: much Indian field hardware still ships with weak or default TLS config, so compliance is as much a fleet-audit exercise (charger by charger) as a backend one.

Rolling security onto a live fleet without bricking chargers

Do not flag-day this. Stand up your plain endpoint (wss:// on Security Profile 1) and your hardened endpoint side by side, and migrate chargers in rings, not all at once. Keep a rollback URL live until a given firmware build has proven itself on Profile 2/3 for a couple of weeks. A charger you cannot reach is a charger you cannot fix remotely.

The order that worked for us:

1. TLS server-auth first (Profile 2): CSMS presents a cert, charger validates the chain.
2. Push client certs via SignCertificate / CertificateSigned, confirm with GetInstalledCertificateIds.
3. Flip to mTLS (Profile 3) per charger.
4. Enable OCSP revocation checking.
5. Turn on signed firmware enforcement last.

Qualify per model. Certify each vendor firmware version against your exact security config in a lab or single-charger canary before it touches a ring. Vendor TLS stacks ship bugs (wrong SNI handling, broken chain validation, clock-skew cert failures) far more often than not. Assume it.

Get observability up before you touch anything: per-charger BootNotification/Heartbeat connection state, cert-expiry dashboards (Prometheus plus Grafana works), reconnect-rate alarms, and offline-transaction backlog depth from queued TransactionEvent messages. A security change that silently kills connectivity should page you in minutes, not surface as a Razorpay reconciliation gap next week.

For the CFO: in our estimate this is roughly 2 to 4 engineer-weeks of work plus existing infra, not new hardware, the kind of security and backend engineering we take on. The payoff is B2B fleet contracts that demand it, and not being the operator in the next charger-hack headline.

Failure modes we hit in production (and the fix)

We learned most of this the hard way. Here is the short list.

Cert expiry killed a live charger. Rotation was manual, someone missed a renewal, and the site dropped off during a busy evening. Now we run scheduled rotation via InstallCertificate / CertificateSigned and alert at 30 days before expiry, per charger.

Reconnect storm after a tower outage. When a Jio tower recovered, about a dozen chargers slammed the gateway with simultaneous TLS handshakes and CPU spiked. Fix: jittered reconnect backoff on the charger side plus handshake rate-limiting at the Go gateway, so BootNotification arrivals spread out.

Duplicate billing from replayed offline transactions. After reconnect, queued TransactionEvent messages replayed and some settled twice. We now key on transactionId + seqNo as an idempotency key and hold a settled-once ledger state, so Razorpay only ever charges the delta once.

A charger trusted a bad cert. Firmware cert validation was permissive and accepted the wrong CA. We only caught it by testing with a deliberately wrong cert. That test is now part of per-model qualification.

Offline meter drift produced a wrong INR amount. We had billed off the charger wall-clock timestamp. Now we bill on metered kWh delta from the first to the last sampledValue reading in the TransactionEvent stream, never on clock time.

2.0.1 security is not a feature you switch on. It is a discipline you run every day: certs, revocation, offline policy, reconciliation.

Where this leaves you

None of this is exotic. It is TLS you enforce properly, a small CA you actually run, revocation you actually check, an offline policy you decide on purpose, and a reconciliation ledger that bills each session exactly once. The hard part is not the spec, it is doing all of it every day across real hardware that ships with real bugs.

Frequently asked questions about OCPP 2.0.1 security

Do I need OCPP Security Profile 3 (mTLS), or is Profile 2 (TLS plus Basic auth) enough for a public charging network in India in 2026?

Profile 2 is the honest floor for a public network. It gives you real transport encryption with a single server cert and no per-charger PKI to run day one. Move to Profile 3 (mTLS) when a B2B fleet contract, an aggregator, or a CEA/BIS posture actually demands cryptographic per-station identity, not before. We run Profile 2 as our default and flip specific chargers to Profile 3 when a contract requires it.

Who issues the TLS certificates for my chargers, and how do I rotate them across a remote fleet without a site visit to each charger?

You do, effectively. Once you turn on Profile 2 or 3 you run a small CA: a CPO root, a sub-CA for charger client certs, and a sub-CA anchoring the CSMS server cert. Rotation rides the live OCPP WebSocket via SignCertificate, CertificateSigned, and InstallCertificate, so there is no truck roll. We alarm any charger whose cert is inside 30 days of expiry and reissue ahead of it, because an expired cert on a remote charger is a self-inflicted outage.

How does a charger authorize a user and start a session when the 4G/mobile network drops mid-site, and is it safe on a public charger?

It falls back to two local mechanisms: the operator-pushed Local Authorization List and the Authorization Cache of previously approved idTokens. With LocalAuthorizeOffline and LocalPreAuthorize on, a known token starts energy immediately without the CSMS. Safety is a policy call: OfflineTxForUnknownIdEnabled controls whether an unknown token can start offline, and on an open public charger that is a deliberate revenue-versus-fraud trade-off you set per site and write down.

If a charging session runs entirely offline, how do I bill it through Razorpay when connectivity returns without double-charging the user or losing the revenue?

The charger stores the transaction locally and replays queued TransactionEvent messages when the link returns. We dedupe on the charger's transactionId plus seqNo with a unique constraint in Postgres, so a retried Ended event cannot create a second charge. For walk-in users we hold a pre-auth of around INR 500 at session start, so there is money to capture even if the session ran dark; fleet accounts get invoiced monthly instead.

Is ISO 15118 Plug and Charge actually usable in India yet, and do I have to stand up a full PKI to support it?

Not really, not yet. The V2G root and contract-certificate ecosystem in India is still thin, so Plug and Charge is design-for-later, not a 2026 requirement. Build the hooks in your data model and keep V2G certs as a separate certificate family so you are not conflating them later. Do not stand up a full V2G PKI now to chase a feature the market cannot use.

How does the charger check whether a certificate has been revoked (OCSP), and what should it do when it cannot reach the OCSP responder?

In 2.0.1 the charger sends GetCertificateStatus with the OCSP request and the CSMS relays it to the responder, so the charger needs no direct route out. We staple the signed answer into the TLS handshake to save a round trip on flaky links, and we cache and refresh staples before they go stale. When nothing can reach a responder we soft-fail with a short grace window on unattended public sites, because hard-fail bricks a whole site when the responder blips, and we alarm on stale staples.

What do CEA and BIS actually require for security on public EV chargers in 2026, and will regulators or fleet clients force me to mTLS first?

As of mid-2026 we have not seen a notified clause mandating a specific OCPP security profile; the Ministry of Power's "Guidelines and Standards for Charging Infrastructure" mostly cover electrical safety, connectors, and connectivity, with TLS and signed firmware reading as direction of travel. The real forcing function is commercial: B2B and fleet contracts write mTLS, revocation, and tamper-evident logs into the SLA long before a regulator does. Plan your PKI around the next fleet tender, not around a mandate that is not on paper yet.