Introduction

EV charging platforms often look like familiar software products: APIs, cloud infrastructure, mobile apps, identity, CI/CD, Kubernetes, telemetry, admin panels, support workflows, and billing-adjacent logic. But the security model is not the same as a normal web application.

The moment software can enroll charging stations, start or stop charging sessions, push firmware, modify tariffs, affect fleet operations, or support field recovery, Product Security has to protect more than code. It has to protect operational authority.

Why This Article Exists

Many security discussions still begin with a familiar question:

Is the application vulnerable?

That question is useful, but it is too narrow for EVSE and software-defined mobility products.

A better question is:

Can this weakness move from software into operational control?

That small shift changes the whole security program.

In a classic SaaS product, a broken authorization check may expose another user’s record. That is already serious. In an EV charging platform, the same class of weakness can affect a charging session, a charging station, a customer fleet, an admin workflow, a billing-adjacent process, or the ability to disable and recover field infrastructure.

In a classic web platform, a weak CI/CD process may deploy a vulnerable container. In an EVSE platform, the same weakness may sit much closer to firmware delivery, OTA release governance, signed artifacts, device configuration, or fleet rollout.

In a classic cloud environment, missing telemetry can slow down incident response. In an EV charging environment, missing telemetry can make it difficult to understand whether a fleet-wide anomaly is abuse, outage, misconfiguration, failing hardware, certificate lifecycle drift, or a real security incident.

This is why I do not treat EVSE Product Security as a fancy version of AppSec. AppSec is necessary. Cloud security is necessary. DevSecOps is necessary. But the product is a connected operational environment, not just an application.

The System Is Bigger Than the App

A modern EV charging platform may include:

  • customer-facing web and mobile applications;

  • public and internal APIs;

  • identity systems for users, operators, administrators, devices, stations, partners, and service accounts;

  • a Charging Station Management System or Charge Point Management System;

  • OCPP communication between charging stations and backend systems;

  • firmware and OTA update mechanisms;

  • CI/CD pipelines, artifact registries, release approvals, and signing workflows;

  • cloud infrastructure, Kubernetes, data stores, queues, storage, and observability;

  • payment-adjacent flows, RFID, refunds, webhooks, and billing logic;

  • support tools, admin panels, and field maintenance workflows;

  • station enrollment, certificates, and device lifecycle management;

  • logs, detections, SOC runbooks, and recovery procedures.

That is not one application. It is a product ecosystem.

The security program therefore has to track not only vulnerabilities, but authority.

Who can enroll a charging station?
Who can start, stop, or modify a charging session?
Who can change tariffs or billing-adjacent rules?
Who can issue remote commands?
Who can push firmware?
Who can publish, sign, approve, or roll back an OTA package?
Who can impersonate support access?
Who can export customer or operational data?
Who can recover the system when something goes wrong?

These questions belong to Product Security leadership, not only to penetration testing.

A Simple Mental Model: Four Factories at Once

A useful shortcut:

Web security protects the door.
Cloud security protects the building.
CI/CD security protects the factory.
EVSE security protects what the factory ships into the real world.

In EV platforms, all four layers appear at once.

That is why normal security checklists often feel incomplete. A scanner may find a vulnerable dependency. A penetration test may find a broken API endpoint. A cloud audit may find an over-permissioned IAM role. A CI/CD review may find a weak runner model.

All of these findings matter. But in EVSE, they should be connected to one product question:

What operational authority can be affected if this weakness is chained with another weakness?

This is where attack-chain thinking becomes useful.

Not because we want to create dramatic threat stories. Not because we want to invent cinematic attacks. But because real incidents often do not happen through one magical bug. They happen through seams:

  • an exposed admin surface plus weak access control;

  • a support workflow plus excessive permissions;

  • a CI/CD token plus broad cloud access;

  • a backend API bug plus missing tenant isolation;

  • a device identity weakness plus poor station enrollment controls;

  • a signed release process without meaningful approval boundaries;

  • incomplete logs plus no runbook for abnormal fleet behavior.

The seam is the risk.

AppSec vs Product Security in This Domain

Application Security usually focuses on source code, APIs, authentication, authorization, sessions, input validation, dependency risk, secure SDLC, and vulnerability remediation.

In EVSE and software-defined mobility, that is only one layer.

Product Security has to follow the product as it is designed, built, shipped, operated, updated, monitored, and trusted by customers.

Here is the difference in practical terms:

Area

Classic AppSec Question

Product Security Question in EVSE

API authorization

Can a user access another object?

Can this become unauthorized control over a station, session, tenant, fleet, or admin operation?

CI/CD

Can an attacker modify build or deployment logic?

Can this become a path to firmware, OTA, signed artifacts, production control, or fleet-level deployment?

Cloud IAM

Is a role over-permissioned?

Can this role reach data, secrets, command paths, device identity, telemetry, or release infrastructure?

Device identity

Does the backend authenticate devices?

Can a rogue, cloned, duplicated, or stale identity affect operations or trust in telemetry?

SBOM

Do we know our dependencies?

Can we respond quickly when a vulnerable component affects apps, containers, firmware, or critical third-party services?

Logging

Do we have logs?

Can the SOC distinguish abuse, outage, misconfiguration, field failure, or certificate drift?

Admin tools

Is admin access protected?

Can support or admin authority perform destructive or customer-impacting operations without step-up authentication, approval, or audit?

The Product Security lens is wider because the blast radius is wider.

Operational Authority Is the Crown Jewel

In EVSE, the central asset is not only data. It is operational authority.

Operational authority may include the ability to:

  • enroll or decommission charging stations;

  • authorize charging sessions;

  • start, stop, or modify charging operations;

  • change tariffs or policy rules;

  • manage station certificates;

  • push firmware;

  • pause or roll back updates;

  • manage fleet customers;

  • support users and operators;

  • process payment-adjacent workflows;

  • disable or recover a group of chargers.

In software-defined vehicle ecosystems, operational authority may include the ability to:

  • publish OTA releases;

  • approve software packages;

  • bind users, phones, devices, or accounts;

  • issue remote commands;

  • manage telematics data;

  • influence software near safety-relevant domains;

  • recover from a failed rollout.

This is why a “medium” finding in a generic SaaS rubric can become a high-priority product risk in an EVSE environment.

Severity does not come only from the bug type. It comes from authority, reach, recoverability, and evidence.

A practical severity question:

If this path is abused, what real operation can change, how many customers or devices can be affected, how quickly can we detect it, and how safely can we reverse it?

That question is more useful than arguing whether a finding is “really high” or “just medium.”

Where Trust Boundaries Usually Hide

A simplified EVSE platform can be viewed as several trust zones:

  1. Customer and operator interfaces — web portals, mobile apps, public APIs, admin UI.

  2. Identity and authorization layer — users, admins, tenants, roles, devices, stations, partners.

  3. Control plane — CSMS or CPMS logic, station enrollment, sessions, tariffs, firmware orchestration.

  4. Device communication layer — OCPP, certificates, TLS or mTLS, status updates, security events.

  5. Release and supply chain layer — source repositories, CI/CD, artifact registry, signing, SBOM, provenance.

  6. Cloud and platform layer — IAM, Kubernetes, storage, queues, secrets, observability.

  7. Field and recovery layer — physical stations, maintenance, connectivity, rollback, support operations.

Most severe weaknesses appear between zones.

Examples:

  • A web portal exposes an admin operation without strong step-up authentication.

  • A station identity is treated as a string instead of a managed credential with a lifecycle.

  • A support workflow can impersonate users or tenants without time-bound approval and immutable audit.

  • A build pipeline can publish an artifact without meaningful provenance checks.

  • A cloud workload role can read secrets unrelated to the service.

  • A firmware update can be published, but rollback and customer communication have not been rehearsed.

  • The SOC sees errors but cannot tell whether they represent firmware failure, OCPP identity abuse, or backend outage.

A Product Security review should map these boundaries before arguing about tools.

A Practical Attacker Model Without Exploit Recipes

A useful attacker model does not need payloads, live targets, bypass instructions, or copy-paste exploit steps. It needs realistic pressure points.

A hostile actor rarely thinks in isolated findings. They think in transitions:

  • external surface → authentication weakness;

  • authenticated user → tenant boundary;

  • tenant object → admin operation;

  • web app → cloud secrets;

  • CI/CD token → registry or deployment control;

  • station identity → backend trust;

  • firmware path → fleet impact;

  • support access → customer-impacting action;

  • weak logs → longer dwell time.

Defenders should use the same transition model.

For every transition, ask:

  1. What identity is being trusted?

  2. What authority is being granted?

  3. What evidence is created?

  4. What would detection look like?

  5. What is the safe rollback path?

  6. Who owns the control?

This is not an exploit model. It is a defensive review model.

Case Pattern 1: Weak Station Identity

OCPP is an open protocol used for communication between charging stations and charging management systems. Its interoperability is valuable, but it also means station identity and backend trust deserve serious design attention.

A weak implementation may treat a station identifier as sufficient proof of identity. That is not enough for a professional platform.

A mature implementation should be able to answer:

  • Which physical or logical device is connecting?

  • How was its identity provisioned?

  • Is the credential unique, valid, rotated, and revocable?

  • Does the station belong to the expected tenant, site, or fleet?

  • Is the firmware version expected?

  • Are boot, status, and heartbeat patterns normal?

  • Has the same identity appeared in two places at once?

  • Can the backend quarantine the station without taking down unrelated infrastructure?

A good defensive backlog for station identity includes:

  • TLS or mTLS where possible;

  • unique device identity;

  • secure enrollment;

  • certificate lifecycle management;

  • station quarantine states;

  • duplicate identity detection;

  • firmware and configuration inventory;

  • monitoring for OCPP security events;

  • controlled re-enrollment and revocation workflows;

  • tabletop exercises for rogue or misconfigured station behavior.

This is a good example of why Product Security cannot stop at the web layer.

Case Pattern 2: BOLA in a Multi-Tenant EVSE Platform

Broken Object Level Authorization remains one of the most important API security problems because APIs often expose object identifiers in paths, query parameters, headers, or payloads.

In a normal SaaS system, BOLA can leak another user’s data.

In an EVSE platform, BOLA can become more than data exposure if the affected object is a station, charging session, fleet account, invoice, certificate, admin operation, or support workflow.

Defensive design should include:

  • centralized authorization checks instead of scattered controller logic;

  • tenant-bound data models;

  • deny-by-default object access;

  • synthetic tenants in automated negative tests;

  • authorization checks for background jobs and exports, not only API endpoints;

  • logs that record subject, object, tenant, action, decision, and reason;

  • detection for 403 and 404 anomalies;

  • regression tests for every high-risk object type.

A useful test design question:

Can a user, station, operator, or support role perform a state-changing action on an object outside its authorized tenant or fleet?

The question is simple. It finds real risk.

Control Map: Prevent, Detect, Respond, Recover

Security programs often over-index on prevention. Prevention matters, but EVSE environments also need detection and recovery because field systems are messy.

Connectivity fails. Stations behave differently. Certificates expire. Staged rollouts produce mixed fleet states. Telemetry may be incomplete. Hardware failures can look like software failures. Software failures can look like attacks.

A practical control map should connect each domain to four outcomes:

Domain

Prevent

Detect

Respond / Recover

Attack surface

Private admin surfaces, ZTNA, WAF, owner tags, exception expiry

External ASM, DNS and certificate drift, ingress drift

Rapid exposure removal, owner escalation, compensating controls

OCPP / station identity

mTLS, certificate lifecycle, secure enrollment, quarantine

Duplicate identity, failed enrollment, abnormal boot and status patterns

Revoke certificate, re-enroll, quarantine, collect forensic package

Firmware / OTA

Signed artifacts, KMS or HSM, anti-rollback, staged rollout, dual approval

Unexpected publish, invalid signature, rollback attempts, device rejection

Pause rollout, revoke package, safe rollback, customer communication

CI/CD / registry

Protected branches, CODEOWNERS, OIDC, ephemeral runners, signed images

Workflow edits, new runners, unsigned images, secret access anomalies

Revoke tokens, rebuild trusted artifacts, rotate secrets, redeploy clean images

Cloud / Kubernetes

Least privilege, workload identity, network policy, secret scoping

Pod exec, secret reads, anomalous cloud API calls, egress anomalies

Isolate namespace, rotate secrets, rebuild workload, incident timeline

Admin operations

Passkeys or MFA, JIT access, step-up authentication, dual control, immutable audit

Privileged action spikes, support impersonation anomalies

Suspend session, reverse safe actions, preserve audit evidence

This table turns a scary scenario into an executable backlog.

Minimum Viable Baseline for EVSE Product Security

A mature EVSE platform does not need to be perfect before launch. But it should not operate professionally without a minimum baseline.

Here is a condensed baseline:

  1. SSO for workforce and admin access.

  2. Phishing-resistant MFA or passkeys for privileged users.

  3. Step-up authentication for destructive or customer-impacting operations.

  4. Immutable audit logs for firmware push, station disablement, tariff changes, support impersonation, and fleet operations.

  5. Tenant isolation tests for APIs, admin UI, background jobs, and exports.

  6. Protected branches, CODEOWNERS, required checks, and protected environments for crown-jewel repositories.

  7. Secret scanning with push protection and custom patterns for cloud, OCPP, vendor, and payment-adjacent tokens.

  8. CI/CD runners that are ephemeral or strongly isolated.

  9. Signed production artifacts and immutable image tags.

  10. SBOM generation for applications, containers, firmware packages, and critical third-party services.

  11. Cloud audit logging and least-privilege IAM.

  12. Kubernetes admission policy, network policy, runtime detection, and image scanning.

  13. OCPP TLS or mTLS, unique station identity, certificate lifecycle, and secure enrollment controls.

  14. OTA packages and firmware that are signed, targeted, staged, rollback-aware, and verified on the device side.

  15. Incident runbooks for account takeover, CI/CD compromise, fleet anomaly, OTA rollback, data leak, and ransomware.

My favorite baseline rule:

If a control cannot produce evidence, it is a wish.

A screenshot of a policy is not enough. A mature team needs evidence that the control works: a blocked deployment, a rejected rogue enrollment, a successful restore test, an immutable audit sample, a synthetic tenant negative test, tabletop notes, signed artifact verification, or a replay-protected webhook test.

What a Product Security Leader Should Do in the First 30 Days

If I were dropped into an EVSE or software-defined mobility company, I would not start by buying another scanner.

I would start with authority mapping.

Week 1: Map Product Authority

Create an authority inventory:

  • user authority;

  • tenant authority;

  • operator authority;

  • support authority;

  • admin authority;

  • station authority;

  • firmware authority;

  • release authority;

  • cloud authority;

  • recovery authority.

For each authority, document:

  • owner;

  • entry point;

  • identity type;

  • approval path;

  • logging;

  • detection;

  • rollback;

  • evidence.

Week 2: Identify Crown-Jewel Workflows

Focus on workflows where a weakness can create the largest blast radius:

  • station enrollment;

  • session authorization;

  • firmware and OTA release;

  • admin destructive actions;

  • support impersonation;

  • tenant data exports;

  • cloud secrets;

  • CI/CD deployment;

  • incident recovery.

Week 3: Run a Defensive Attack-Chain Review

Pick three realistic chains:

  • web app bug → tenant breach;

  • CI/CD weakness → signed artifact risk;

  • station identity issue → operational disruption.

For each chain, ask:

  • where the organization can prevent the chain;

  • where it can detect the chain;

  • where it can limit the impact;

  • where it can recover safely;

  • what evidence will exist;

  • what executive decision may be required.

Week 4: Convert Findings Into Decisions

Do not present 200 findings as a flat spreadsheet.

Present 10 decisions:

  • Which authority is under-protected?

  • Which control gap creates fleet-level blast radius?

  • Which detection is missing?

  • Which recovery path has not been rehearsed?

  • Where is budget required?

  • Where is ownership missing?

  • Where is an architecture change needed?

  • Where should SDLC change?

  • Where should vendor requirements change?

  • Where do we need an incident exercise?

This is how Product Security becomes a leadership function, not just ticket management.

Final Thought

EVSE and software-defined mobility security is not only about finding vulnerabilities.

It is about protecting operational authority across cloud, APIs, identity, CI/CD, firmware, OTA, device trust, field operations, telemetry, and recovery.

The strongest Product Security programs in this domain will not be the ones with the most tools. They will be the ones that can answer hard questions clearly:

  • What are our crown-jewel operations?

  • Who can perform them?

  • What trust boundaries protect them?

  • What happens if one layer fails?

  • Can the SOC detect abnormal behavior?

  • Can engineering recover safely?

  • Can leadership understand the risk before the incident?

That is the difference between “we scanned the app” and “we protect the product.”

Author’s Note

This article is based on material from a larger EVSE and electric vehicle product security casebook that I am currently finalizing. The full version expands these ideas into defensive case studies, reference architectures, audit playbooks, risk scoring, SBOM governance, detection logic, and security leadership notes.

I also publish practical cybersecurity notes, references, and defensive security materials in my Telegram channel: White2Hack

References and Further Reading